Updating the MIB security guidelines

["C. M. Heard" <heard@pobox.com>]

On Tue, 5 Nov 2002, Wijnen, Bert (Bert) wrote:

> OK, I have seen a number of supportive statements for the
> text (new MIB Boiler plate) below.
> I have not heard any objections yet. If there are any,
> please speak up ASAP. Sooner is better than later.

I'm not raising any objections to the new boilerplate proposal;
as the subject line indicates, I want to discuss the security
section.  Specifically, I would like to make sure, before we
finalize this decision, that we consider the relationship
between the front-end boilerplate and the MIB security section.

The current MIB boilerplate contains a more-or-less self-contained
exposition of the whole document map for all of the versions of
the SNMP and includes references to the protocol documents.  The
proposed replacement points to Section 7 of RFC 2570bis, which
just has the document map for SMIv2 and SNMPv3

Now, it seems to me that the following mandatory text in the
current version of the MIB security section guidelines
at http://www.ops.ietf.org/security.html) makes sense only
if you've already introduced SNMPv1, which the new boilerplate
won't do.  It also has references to 2474 and 2475, which
don't make much sense in a vacuum.

   SNMPv1 by itself is not a secure environment.  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.

   It is recommended that the implementers consider the security
   features as provided by the SNMPv3 framework.  Specifically, the use
   of the User-based Security Model RFC 2574 [RFC2574] and the View-
   based Access Control Model RFC 2575 [RFC2575] is recommended.

   It is then a customer/user responsibility to ensure that the SNMP
   entity giving access to an instance of this MIB, 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.

Is there a way to re-craft this text to avoid having to put the
protocol documents back in the reference list, e.g., by making
appropriate references to RFC 2570bis?  Maybe we ought to say
something different altogether, e.g., to remind people that only
SNMPv3 is recommended (in which case we could point to Section 8
of RFC 2570bis for the explanation).

Thoughts?

Mike