Re: MIB

[RJ Atkinson <rja@inet.org>]

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.

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

Ran
rja@inet.org