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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

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
>  
> 
> 
>