RE: Updating the MIB security guidelines

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

Thanks for your support of the boiler plate and for bringing up 
the relation to the MIB Security Guidelines.

W.r.t. to your proposal:
> 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).

I can say that I in fact like that too. 
But I am not sure we can get away with it. The security folk
(ADs and such) have been bothering me that we need to be much
more specific. But let me try to formulate a proposed text 
first and check with sec ADs what they feel is needed in terms
of SNMPv3 vs earlier versions.

Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: dinsdag 5 november 2002 3:44
> To: mibs@ops.ietf.org
> Subject: Updating the MIB security guidelines
> 
> 
> 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
> 
>