RE: MIB

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

So you describe the vulnerabilities of such an object in the security 
section of the MIB document and then you explain how an
operator/user SHOULD/MUST control access to it.

Bert

> ----------
> From: 	RJ Atkinson[SMTP:rja@inet.org]
> Sent: 	Monday, June 05, 2000 2:26 PM
> To: 	Wijnen, Bert (Bert)
> Cc: 	Spencer.Giacalone@predictive.com; djoyal@nortelnetworks.com;
> mibs@ops.ietf.org; John Moy
> Subject: 	RE: MIB 
> 
> At 05:55 05/06/00 , Wijnen, Bert (Bert) wrote:
> >However... it seems to me that the reason you list below is
> >not a proper reason to make something a MIN-ACCESS of read-only.
> >In my view, you would use the VACM table (can also be used with
> >SNMPv1, see RFC2576) to exlcude access without proper 
> >authentication and/or privqacy.
> 
> In practice, which deployed SNMPv1 implementations support VACM today ?
> 
>          My experience is that --zero-- support VACM today and that
> --zero-- are likely to support VACM anytime in the near future.  
> 
>          However, I think VACM is actually *irrelevant* here.  The reason
> to 
> make the object READ-ONLY unless SNMPv3 is implemented in the agent
> is because that OSPF MIB object permits one to downgrade OSPF
> authentication 
> from cryptographic strength to cleartext-password (i.e. zero) strength.  
> If  we at least ensure that the object can only be twiddled when a SNMP 
> implementation has cryptographic protections (i.e. MD5 Auth) available 
> to the operator [1], we significantly reduce the risk to the operational 
> OSPF system. [2]
> 
> Ran
> rja@Inet.org
> 
> [1] One cannot legislate that an operator actually enable MD5 Auth as
>          that is an operational policy matter.  It is reasonable (IMHO)
>          to legislate that an implementation treats the object as RO
>          unless it at least has reasonable protections available to the
>          operator so the operator has a chance to do the right thing.
> [2] This is probably the point where Randy Bush would point out that no
>          operator that he knows actually enables any SNMP SETs anyway...
> 
>