RE: Pls review documents on IESG Agenda October 27, 2005 Telechat

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

It looks OK for all practical purposes, but is there any special reason
to have left out the phrase that David suggested about the
standardization status of SNMP?

'The IETF has declared those prior versions Historic, and RECOMMENDS
that deployments upgrade to SNMP version 3'.

Dan


 
 

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
> Sent: Thursday, October 27, 2005 3:34 PM
> To: ietfdbh@comcast.net; Romascanu, Dan (Dan); 'Mreview (E-mail)'
> Subject: RE: Pls review documents on IESG Agenda October 27, 
> 2005 Telechat
> 
> I have recorded the below. Does that address your concerns?
> I have recorded it as a COMMENT (i.e. non-blocking), but I 
> have brough it to the attention of the security ADs to let 
> them advise if we should block on it or not.
> 
> Makes sense?
> 
> Bert
> -----------------
> 
> 
> Bert Wijnen:
> Comment:
> [2005-10-25] I see:
>   3.8 MIB
> 
>   Management Information Bases (MIBs) SHOULD be defined for mechanisms
>   specifically in place to support ETS.  These MIBs MAY 
> include objects
>   representing accounting, policy, authorization.
> 
> I suggest to change to:
> 
>   3.8 MIB
> 
>   Management Information Base (MIB) modules SHOULD be defined for
>   mechanisms specifically in place to support ETS.  These MIB
>   modules MAY include objects representing accounting, policy,
>   authorization.
> 
> That is: there is one single MIB, which is composed of many 
> MIB modules.
> I am not sure I understand the capitalized MAY in the 2nd 
> sentence. I can live withit, but porbably better to just use 
> lowercase "may".
> 
> The discussion about MIB and SNMP in the Security 
> Considerations section is porbably best changed/updated to 
> state a subset of the text in the common MIB Security 
> Template as found at
>   http://ops.ietf.org/mib-security.html
> 
> Specifically, I think I would like to see text aka:
> 
> SNMP versions prior to SNMPv3 did not include adequate security.
>   Even if the network itself is secure (for example by using IPsec),
>   even then, there is no control as to who on the secure network is
>   allowed to access and GET/SET (read/change/create/delete) 
> the objects
>   in this MIB module.
> 
>   It is RECOMMENDED that implementers consider the security 
> features as
>   provided by the SNMPv3 framework (see [RFC3410], section 8),
>   including full support for the SNMPv3 cryptographic mechanisms (for
>   authentication and privacy).
> 
>   Further, deployment of SNMP versions prior to SNMPv3 is NOT
>   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
>   enable cryptographic security.  It is then a customer/operator
>   responsibility to ensure that the SNMP entity giving access to an
>   instance of this MIB module is properly configured to give access to
>   the objects only to those principals (users) that have legitimate
>   rights to indeed GET or SET (change/create/delete) them.
> 
> Which I think covers the considreations that are relevant for 
> this MIB document.
> 
> > -----Original Message-----
> > From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org]On
> > Behalf Of David B Harrington
> > Sent: Wednesday, October 26, 2005 18:08
> > To: 'Romascanu, Dan (Dan)'; 'Wijnen, Bert (Bert)'; 'Mreview 
> (E-mail)'
> > Subject: RE: Pls review documents on IESG Agenda October 27, 2005 
> > Telechat
> > 
> > 
> > Hi,
> > 
> > I have suggestions to improve the wordings here. All the 
> lines I have 
> > changed have no '>' preceding the line.
> > 
> > > http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-i
> > eprep-doma
> > > in-req-05.txt includes in the Security Consideration section the
> > > following: 
> > > 
> > >   - Most current deployments of SNMP are of versions prior to
> > >        SNMPv3, even though there are well-known security
> > >        vulnerabilities in those versions of SNMP. The IETF has
> >          declared those prior versions Historic, and RECOMMENDS
> >          that deployments upgrade to SNMP version 3.
> > > 
> > >   - SNMP versions prior to SNMPv3 cannot support cryptographic
> > >        security mechanisms.  Hence, any use of SNMP prior to
> > > old:   version 3 to write or modify MIB objects do so in a
> >   new:   version 3 to read or write or modify MIB objects do so in a
> > >        non-secure manner.  As a result, it may be best to 
> constrain
> >          the use of SNMP to SNMPv3-capable agents and managers
> >          (i.e. to SNMPv3 messages). 
> > > 
> > >   - Finally, any MIB defining writable objects should carefully
> > >        consider the security implications of an SNMP compromise on
> > >        the mechanism(s) being controlled by those writable MIB
> >          objects. It is already a requirement of all IETF standard 
> >          MIB modules that a detailed Security 
> Considerations section 
> >          accompany the MIB module. It is RECOMMENDED that 
> MIB modules 
> >          developed by other organizations include a comparable 
> > Security
> >          Consideration section.
> > 
> > Dave Harrington
> > dbharrington@comcast.net
> >  
> > 
> > 
> > 
>