[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Review: IESG Agenda and Package for January 22, 2004 Telechat
Here are some of my reservations:
1. Section 1.7
Basis For Testing and Certification. As a basis for testing and
certification of security features of networked products.
I would be reluctant to include this use. As a BCP and non-normative document, I fail to see how this can be a basis for certification. Some of our customers are taking very seriously certification of security, and if IETF is to issue a normative reference for such an activity, we need a more serious (and normative) document.
2. Use of term 'password'
This document takes a very odd approach for the use of term password, especially for a security document. It starts by claiming in Section 1.8 that 'password' will be used in a very broad way, kind of an alias for 'security token'. However, this is not consistently followed and almost all other instances of 'password' in the document refer to the old good interpretation that we all knew. On the other hand, other types of 'passwords' like SNMP community strings get special treatment in some sections.
3. Requirement 2.5.3 - If this requirement is to be followed for SNMP, any remote discovery or remote operation for an SNMP managed device would be impossible without the presence of a on-site operator to configure locally SNMP through some local craft interface. I do not think that this is BCP - at least not for some classes of networks and devices.
4. Same about requirement 2.12.9
5. It is odd that while talking about SNMP in the context of secure management, the document does not mention the need to activate the auth and priv modes, and the need to use access control with different rights for different sections of the MIB. Maybe if the authors were aware about how these can be used, their concerns reflected in requirements 2.5.3 and 2.12.9 would have been alleviated.
6. The way the first paragraph in Section 2.2 is written it makes a strong case against using in-band management. I would observe that this is far from being a BCP. I suggest that this paragraph be re-formulated. While showing up the increased risks and mentioning the attacks related to usage of in-band management, in should emphasize that there are means to defend, hence the requirements in the following sections.
7. The 'Warning' section in 2.3.1 is a strong argument in favor of RS-232, but has little to do with Security.
8. Sections 2.4.1 to 2.4.4 would belong to a 'CLI Requirements' document, but why should they be part of a 'Operational Requirements for Security' BCP? I would also observe that there is no 'standard CLI' - not in IETF at least - at this point in time.
9. However, if we are dealing with proprietary interfaces, why are requirements for 'Web interfaces' - quite widely used in device and server management almost totally absent?
Please do not interpret this as a fully negative view of the document. Quite the opposite, I find it very valuable, and there are many useful and accurate items. Most of my reservations are related to the management aspects, and to the fact that it provides requirements which are not aligned with a BCP. Maybe dropping 'BCP' from the title, and making the document just an Informational at this point in time would be better.
I also apologize for not having caught these during the IETF Last Call period.
Regards,
Dan
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: 21 January, 2004 4:12 PM
> To: Romascanu, Dan (Dan); Mreview (E-mail)
> Cc: ops-area@ops.ietf.org
> Subject: RE: Review: IESG Agenda and Package for January 22,
> 2004 Telechat
>
>
> Dan writes/asks:
> > > o draft-jones-opsec-03.txt
> > > Operational Security Requirements for IP Network
> Infrastructure
> > > (BCP) - 2 of 2
> > > Token: Steve Bellovin
> >
> > To what extent is this document
> > (http://www.ietf.cnri.reston.va.us/internet-drafts/draft-jones
> > -opsec-03.txt - on the IESG agenda tomorrow) known and was it
> > reviewed in the Operations and Management Area?
>
> Well, it went through a 4-week IETF Last Call, so everyone in IETF
> should/could have seen it.
>
> It has been reviewed on OPS-Directorate list, and we are evaluating
> feedback we received through that path.
>
> And of course, my posting of the IESG agenda to the MIB Doctors list
> enocurages the OPS NM folk to review documents from a NM perspective.
>
> > Although it has been categorized to belong in the Security Area it
> > has quite a consistent amount of REQUIREMENTS related to
> > management. As the document is supposed to become a BCP, and
> > it also establishes as one of the goals to become 'a basis
> > for testing and certification of security features of
> > networked products', I think that it deserves a close look
> > from the management community.
> >
> Yep.
>
> > I am still reading through it. It does include very useful
> > stuff, but it may also have some problems - for example with
> > the very crisp approach wrt. to in-band management.
> >
> Let me know your review results. And if any other NM-folk have
> review comments, by all means please DO send them.
>
> Bert
> > Regards,
> >
> > Dan
> >
> >
> >
>