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

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2009 15:39:54 +0200

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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Acee Lindem <[email-masked]>
Date: Wed, 10 Jun 2009 11:06:30 -0400

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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2009 18:21:41 +0200

> considerations but I don't see any attachments.

Sorry, I am trying again to attach the attachment. But this
boilerplate is really just an extended version of the boilerplate
posted on the OPS web site. Lines beginning with # are comment
lines.
 
> from the end of the IETF last call.

I understand your feelings. But on the other hand, the requested
changes do not affect in any way how the MIB module works - it is all
about properly writing up the security considerations - so this is
mainly some additional editing work.

/js

---

From: Acee Lindem <[email-masked]>
Date: Mon, 15 Jun 2009 19:41:07 -0400

Juergen,
I think what I'll ask the authors to do is talk about the risks in  
general terms for read=create and read-only variables. We're NOT  
going have a separate set of security considerations per variable.  
That would be the type of work that was carried out in the now- 
defunct RPSEC WG.
Thanks,
Acee
On Jun 10, 2009, at 12:21 PM, Juergen Schoenwaelder wrote:

> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/ 
> ><OSPFV3-MIB-boilerplate.txt>