RE: MIB

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

Comments inline

Bert

> ----------
> From: 	RJ Atkinson[SMTP:rja@inet.org]
> Sent: 	Monday, June 05, 2000 2:31 PM
> To: 	Juergen Schoenwaelder
> Cc: 	Wijnen, Bert (Bert); Spencer.Giacalone@predictive.com;
> djoyal@nortelnetworks.com; mibs@ops.ietf.org
> Subject: 	Re: MIB
> 
> At 06:41 05/06/00 , Juergen Schoenwaelder wrote:
> 
> >I am not sure I fully understand the problem. In any way, there is a
> >big difference between MAX-ACCESS and MIN-ACCESS and access control.
> 
> OK
> 
> >The MAX-ACCESS clause defines the maximum access that makes sense for
> >a certain object type definition. The MIN-ACCESS clause defines the
> >minimum access that must be implemented in order to be compliant to
> >the MODULE-COMPLIANCE statement. All this has nothing to do with
> >access control rules, which allow or deny access to read/write/notify
> >operations on certain object type instances. Note that these access
> >control rules are usually under control of the network security
> >administrator. So the MUST below is questionable.
> >
> >   "If the SNMP agent associated with a system implementing OSPF does
> >    not fully comply with SNMPv3 specifications (including full
> >    implementation of cryptographic authentication), that SNMP agent
> >    MUST handle this object as having a MAX-ACCESS value of read-only
> >    because of security risks."
> >
> >What you are probably trying to say in the quoted text above is that
> >the access control subsystem must deny write accesses with a security
> >level of noAuth/noPriv. In other words, you want to require that the
> >ASI call
> >
> >        isAccessAllowed(*,*,noAuth/noPriv,write,*,<object-type>)
> >
> >fails (a * is used as a wildcard here). What this boils down to in
> >most implementations is an access control configuration rule. We
> >currently have no mechanism in the SMI to properly express things like
> >this and hence you have to revert to pure text in the description
> >clause. So, considering RFC 2571, the text above translates to:
> >
> >    "An SNMP agent associated with a system implementing OSPF MUST 
> >     be configured to prevent write access to this object with a
> >     noAuth/noPriv security level because of security risks."
> 
> If we changed the above to also disallow access with cleartext passwords,
> and s/MUST be/by default MUST be/, then we would achieve the objective
> coming from OSPF-land.
> 
> >The question is whether this still makes sense since the MUST is on a
> >configuration option. Of course, you can take out the "be configured
> >to" phrase, in which case you require the access control models to
> >enforce certain MIB specific builtin access control rules, which is a
> >pretty drastic thing to do. If people think that this is needed in
> >order to achieve a high degree of security, then the SMI should have
> >language constructs so that tools can extract hard-wired access
> >control rules and turn them into relevant access control model
> >extensions.
> 
> Please consider this.  There are a number of objects where there
> are really severe security issues that we really ought not be ignoring.
> A number of OIDs ought not be writable unless at least MD5 Auth is
> in use.  Some OIDs ought not be readable without DES, IMHO, as well.
> 
OK., so explain that VERY CLEARLY in the security section and explain
in the security section that these MIB objects (maybe the whole MIB?) should
only be used with SNMPv3. I can live with that. You can even repeat such a 
statement in the MODULE description clause so it stays with the MIB when
the MIB gets extracted via a MIB compiler.

If some MIB objects are OK, and others not, then maybe you can do
two MODULE-COMPLIANCE statements: one that lists the objects
that are always OK. and others that can/should only allowed/implemented
when using SNMPv3 with DES etc etc.

> >Until we have this, I believe that a clear discussion of the security
> >aspects in the security considerations sections plus some concrete
> >VACM rules that people can cut & paste are the best way to deal with
> >things like this.
> 
> VACM isn't available in deployed SNMPv1 implementations.  Most OSPF
> routers do NOT now implement SNMPv3, so VACM just isn't available
> (nor is MD5 Auth, which is the real issue here).
> 
> The discussion in Security Considerations is universally ignored by
> implementers.  Sad, but true.  WHile I agree documentation is necessary,
> I don't think its close to being sufficient for situations like the
> particular one in the OSPF MIB.
> 
Mmm... so why the heck are we in the IETF making so much trouble when
authors/editors do not specify such a security section correctly???

In any event, the SNMP/MIB/VACM approach is such that we provide the
tools for people to use proper access control to sensitive objects. We do 
not want to prescribe as the IETF how people treat risks. Some people
may decide that their network is secure in some other way...... 
  - In any event, we give them the tools.
  - we make good recommendations
  - they (user/customer) must take the responsibility to properly deploy.

For all I know, we (IETF/IESG) do require that protocols provide the
proper security tools/mechanisms. I do not believe that we require that
a user/customer MUST use them... even though we strongly recommend so.

Bert