Re: MIB

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Wijnen, Bert (Bert) writes:

Bert> I think that from RFC2578, I must conclude that you can indeed
Bert> specify a MAX-ACCESS of read-write and then specify that under
Bert> certain circumstances, the access will only be read-only. After
Bert> all a MAX-ACCESS specifies the maximum access that makes sense,
Bert> and it does not mean that such access must always be provided.

Bert> However, it also seems to me that the most proper place to
Bert> specify this is in a MODULE-COMPLIANCE statement, using a
Bert> MIN-ACCESS clause where you can list under what circumstances or
Bert> why a MIN-ACCESS of less than MAX-ACCESS should be used.

Bert> However... it seems to me that the reason you list below is not
Bert> a proper reason to make something a MIN-ACCESS of read-only.  In
Bert> my view, you would use the VACM table (can also be used with
Bert> SNMPv1, see RFC2576) to exlcude access without proper
Bert> authentication and/or privqacy.

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.

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

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.

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.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>