Re: [secdir] secdir review of draft-ietf-ospf-ospfv3-mib.txt

[Acee Lindem <[e-mail]>]

Juergen,

You refer to an an attached boiler plate for MIB security  
considerations but I don't see any attachments.

In the future, I'd hope the secdir could register their comments  
earlier in the process. We have taken this document all the way  
through the IESG and MIB doctors reviews and are not one day away  
from the end of the IETF last call.

Thanks,
Acee - OSPF Co-Chair.

On Jun 10, 2009, at 9:39 AM, Juergen Schoenwaelder wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> The document defines a MIB module and I have not spent time reviewing
> the MIB module itself. Instead, I have been focusing on the security
> considerations section and I believe the security considerations
> section needs some improvement in order to comply to RFC 4181 section
> 3.4 and the current MIB module security template. Let me go through
> the security considerations in draft-ietf-ospf-ospfv3-mib-13.txt:
>
>   6. Security Considerations
>
>      There are a number of management objects defined in this MIB that
>      have 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.
>
> Up to here, this is standard boilerplate text. What is missing is next
> is the discussion of the sensitivity / vulnerability of the objects /
> tables. See RFC 4181 section 3.4 and the boilerplate text posted at
> <http://www.ops.ietf.org/mib-security.html>.
>
>      It is recommended that attention be specifically given to
>      implementing the MAX-ACCESS clause in objects in scenarios
>      that DO NOT use SNMPv3 strong security (i.e. authentication and
>      encryption). Extreme caution must be used to minimize the risk of
>      cascading security vulnerabilities when SNMPv3 strong security is
>      not used. When SNMPv3 strong security is not used, these objects
>      should have access of read-only, not read-create.
>
> This is new text and I dislike it because it recommends to not
> implement objects as writable objects. I believe this is not what we
> want to achieve; we want writable objects implemented since we want
> operators to decide via access control configuration rules which
> objects are accessible to whom. Having the implementors take the
> decision by implemting them read-only makes it impossible for
> operators to do what they might want to do.
>
>      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 3414 [RFC3414] and the
>      View-based Access Control Model RFC 3415 [RFC3415] 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.
>
> The text in these three paragraphs does not match the current
> boilerplate and I think it is also wrong since it ignores SNMPv2c and
> SNMPv3 in noAuth/noPriv mode. This text is also misleading since you
> can have access control with SNMPv1 - all you miss in that scenario is
> a secure binding to an authenticated principal. So I suggest to use
> the current boilerplate text.
>
> I am attaching a boilerplate template generated by smidump. Since the
> MIB module is large, you end up with a long list of objects and it
> likely makes sense to group them and to discuss things at the level of
> table rows instead of individual objects or so (smidump is currently
> not smart enough to do this). Take this as a starting point if you
> want.
>
> /js
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>