Re: Updating the MIB security guidelines

["Tom Petch" <nwnetworks@dial.pipex.com>]

Good; but if NOTIFY access is being added to the paragraph starting
'Some of the readable objects...' (and I think it should), then I
think it should also be included in the last sentence which currently
specifies only GET or SET.  I also find that last sentence a bit
awkward to follow (because of the multiple 'to's - give access to
objects to principals).

So how about

"It is 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 objects only for those principals (users)
that have legitimate rights to access them."

Subsidiary thought; is "grant access" better than "give access"?  I
think that "grant" is more the terminology of security -  eg VACM [RFC
3415] - while "give" is more the terminology of SNMP applications.

Tom Petch
nwnetworks@dial.pipex.com
-----Original Message-----
From: Wijnen, Bert (Bert) <bwijnen@lucent.com>
To: mibs@ops.ietf.org <mibs@ops.ietf.org>
Date: 27 December 2002 23:40


>----------- draft new Security Guidelines for MIB documents ------
>
>x. Security Considerations
>
>-- if you have any read-write and/or read-create objects, please
>-- describe their specific sensitivity or vulnerability.
>-- RFC 2669 has a very good example.
>
>   There are a number of management objects defined in this MIB
module
>   with a MAX-ACCESS clause of read-write and/or read-create.  Such
>   objects may be considered sensitive or vulnerable in some network
>   environments.  The support for SET operations in a non-secure
>   environment without proper protection can have a negative effect
on
>   network operations.  These are the tables and objects and their
>   sensitivity/vulnerability:
>
>    <list the tables and objects and state why they are sensitive>
>
>-- else if there are no read-write objects in your MIB module
>
>   There are no management objects defined in this MIB module that
have
>   a MAX-ACCESS clause of read-write and/or read-create.  So, if this
>   MIB module is implemented correctly, then there is no risk that an
>   intruder can alter or create any management objects of this MIB
>   module via direct SNMP SET operations.
>
>-- for all MIBs you must evaluate
>
>   Some of the readable objects in this MIB module may be considered
>   sensitive or vulnerable in some network environments.  It is thus
>   important to control even GET access to these objects and possibly
>   to even encrypt the values of these objects when sending them over
>   the network via SNMP.  These are the tables and objects and their
>   sensitivity/vulnerability:
>
>    <list the tables and objects and state why they are sensitive>
>
>   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 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.
>
>