FW: Updating the MIB security guidelines

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

So, I have been talking to some Security AD/IAB Security experts
I expect nmore input, but here is something that we can use as
a start.

It seems that RFC2669 actually has a very good security section
(using the old guidelines). Maybe something we need to point to
as an example? I did in a "comment" line.

The proposal below only references RFC2570bis.

What do people think of the below?
I would like to seem comments/responses/support/concerns
rather sooner than later.

Thanks.,
Bert

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

   There are a number of managed objects in this MIB module with a 
   MAX-ACCESS claise of read-only and/or notify-only. Some of these
   objects 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),
   inluding 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.