Subject: Re: [MIB-DOCTORS] Updates to the Guidelines of the Security Considerations section of the MIB documents

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 7 Nov 2011 13:06:52 +0100

Hi,

One month passed since the last comment was made on this thread. It's
time to implement the change based on Sean's proposal with the amendment
from Juergen:  

OLD:

   It is RECOMMENDED that implementers consider the security features
   as provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

NEW: 

   It is RECOMMENDED that implementers consider the security features
   as provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for authentication and privacy via the
   User-based Security Model (USM) [RFC3414] with the AES cipher
   algorithm [RFC3826] and the Transport Security Model (TSM)
   [RFC5591] in combination with a secure transport such as SSH
   [RFC5592] or TLS/DTLS [RFC6353].

If no further comments are posted in the next 48 hours I will make the
changes on the wiki and Web pages and this will become the new reference
text for authors and reviewers of MIB documents. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Sean Turner [mailto:[email-masked]]
> Sent: Thursday, October 06, 2011 12:14 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [MIB-DOCTORS] Updates to the Guidelines of the Security
> Considerations section of the MIB documents
> 
> On 10/6/11 4:58 AM, Romascanu, Dan (Dan) wrote:
> > See in-line.
> >
> > Regards,
> >
> > Dan
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:mib-doctors-
> >> [email-masked]] On Behalf Of Sean Turner
> >> Sent: Wednesday, October 05, 2011 11:32 PM
> >> To: [email-masked]
> >> Subject: Re: [MIB-DOCTORS] Updates to the Guidelines of the
Security
> >> Considerations section of the MIB documents
> >>
> >> On 10/5/11 4:13 PM, Juergen Schoenwaelder wrote:
> >>> On Wed, Oct 05, 2011 at 02:29:12PM -0400, Sean Turner wrote:
> >>>> Hi,
> >>>>
> >>>> After the publication of RFC 5591 and the fact that SNMP+DES
> really
> >>>> ought to be replaced with SNMP+AES, I'd like to propose the
> >>>> following change to the MIB security considerations:
> >>>>
> >>>> OLD:
> >>>>
> >>>>      It is RECOMMENDED that implementers consider the security
> >> features
> >>>>      as provided by the SNMPv3 framework (see [RFC3410], section
> 8),
> >>>>      including full support for the SNMPv3 cryptographic
> mechanisms
> >> (for
> >>>>      authentication and privacy).
> >>>>
> >>>> NEW:
> >>>>
> >>>>      It is RECOMMENDED that implementers consider the security
> >> features
> >>>>      as provided by the SNMPv3 framework (see [RFC3410], section
> 8),
> >>>>      including full support for the USM [RFC3414][RFC3826] and
> >> Transport
> >>>>      Security Model [RFC5591] cryptographic mechanisms (for
> >> authentication
> >>>>      and privacy).
> >>>>
> >>>> What I'm proposing is just being specific by listing the two
> >>>> mechanisms.  But, we can't just point to 3414 becaue it requires
> >>>> DES, hence the 3826 reference.  And, the reference to 5591
expands
> >>>> the options to allow RFC 6353.
> >>>
> >>> RFC 5591 does not have any "cryptographic mechanisms", so this is
> >> even
> >>> worse that RFC 3414 alone (which at least has DES). What about
> this:
> >>>
> >>>      It is RECOMMENDED that implementers consider the security
> >> features
> >>>      as provided by the SNMPv3 framework (see [RFC3410], section
> 8),
> >>>      including full support for authentication and privacy via the
> >>>      User-based Security Model (USM) [RFC3414] with the AES cipher
> >>>      algorithm [RFC3826] and the Transport Security Model (TSM)
> >>>      [RFC5591] in combination with a secure transport such as SSH
> >>>      [RFC5592] or TLS/DTLS [RFC6353].
> >>>
> >>> Probably a bit long. Here is a less verbose version:
> >>>
> >>>      It is RECOMMENDED that implementers consider the security
> >> features
> >>>      provided by the SNMPv3 framework (see [RFC3410], section 8),
> >>>      including full support for authentication and privacy via the
> >>>      User-based Security Model (USM) [RFC3414] [RFC3826] and the
> >>>      Transport Security Model (TSM) [RFC5591] [RFC5592] [RFC6353].
> >>
> >> I'd take either of these actually.  But, I like the former slightly
> >> more
> >> because it explains why 3826 is included and the includes the
> >> SSH/TLS/DTLS mechanisms.
> >>
> > [[DR]] I also prefer the first of the two versions as it makes clear
> the
> > models and the associated secure transports with the options.
> >
> >
> >>> Anyway, if we open up the security considerations template, we may
> >>> want to look at other wordings that often caused people to make
> >>> changed, e.g. the "even then" in the IPsec phrase (which IMHO
> should
> >>> simply be taken out).
> >>
> >> I'm okay with this too.
> >>
> >>> OLD:
> >>>
> >>>      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.
> >>>
> >>> NEW
> >>>
> >>>      SNMP versions prior to SNMPv3 did not include adequate
> security.
> >>>      Even if the network itself is secure (for example by using
> >> IPsec),
> >>>      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.
> >>
> >> I'm fine with this.
> >>
> >>> /js
> >>>
> >>> PS: Another good action would be to advance RFC3826 on the
> standards
> >>>       track - this is still a proposed standard...
> >>
> >> I'm willing to help out.  If we've got two interoperable
> >> implementations
> >> let's get'r done.
> >>
> > [[DR]] This could be done in OPSAWG. I do not remember if 3826 was
> done
> > in OPS or in SEC.
> 
> [spt] I think it was done in SEC because Steve Bellovin was the
> sponsoring AD.  However, I'm definitely not hard over having to
sponsor
> it.  ISMS is closed now so maybe it's better to do this via OPSAWG.
> 
> spt

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 07 Nov 2011 14:02:54 +0100

Sounds fine.

Note that the template at
    http://ops.ietf.org/mib-security.html
and the templates here:
    http://tools.ietf.org/tools/templates/

Not only need the updated text below, but also need
to add additional normative/informative references.

Bert

On 11/7/11 1:06 PM, Romascanu, Dan (Dan) wrote:
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 7 Nov 2011 14:12:52 +0100

Of course. Also: 

https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security

Does anybody believe that the references to be added (to 3414, 3826,
5591, 5592, 6353) need to be other than Informative? 

Dan

> From: Bert Wijnen (IETF) [mailto:[email-masked]]
> Sent: Monday, November 07, 2011 3:03 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
Security

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 07 Nov 2011 14:21:42 +0100

Informative seems fine to me.

Bert

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 7 Nov 2011 10:48:31 -0800

Hi -

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, November 07, 2011 4:06 AM
> Subject: Re: [MIB-DOCTORS] Updates to the Guidelines of the SecurityConsiderations section of the MIB documents
>

>    [RFC5592] or TLS/DTLS [RFC6353].

(1) I think the new text is easily mis-read.  The scope of the various "ands"
and the "or" is unclear.  My suggestion would be to replace the line reading 

-    algorithm [RFC3826] and the Transport Security Model (TSM)

with one reading

+    algorithm [RFC3826]; or the Transport Security Model (TSM)

(2) I think this recommendation goes against the spirit of having at least
one mandatory-to-implement security mechanism, something essential
to interoperability.  I'd be more comfortable if it were clearer which of
these mechanisms could be expected of most implementations.  (And
if the expectation is that most implementations should support all of
these, it should say that, too.)  My suggested "minimum mandatory"
would be USM with AES.  Words to make that so:

>    including, at a minimum, full support for authentication and privacy via the
>    algorithm [RFC3826].  In addition, in some environments it will be
>    appropriate to provide support for the Transport Security Model (TSM)

(3)  The weasel words "it is RECOMMENDED that implementers
consider" seem to me to be the combined baggage of the politics
and naivete of a much different time - we wanted folks implementing
MIBs in SNMPv2c environments to still be able to claim conformance
to the MIB.  I'd question whether this is still reasonable or desirable.
Suggested change:

>   At a minimum, implementions MUST provide the security features
>   described by the SNMPv3 framework (see [RFC3410], section 8),
>   including, at a minimum, full support for authentication and privacy via the
>   algorithm [RFC3826].   Implementations MAY also provide support
>   for   the Transport Security Model (TSM)  [RFC5591] in combination
>   with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353].

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 8 Nov 2011 11:01:05 +0100

So we have now a new proposal on the table (Randy's with a typo
correction): 

 OLD:

NEW: 

    At a minimum, implementations MUST provide the security features
    described by the SNMPv3 framework (see [RFC3410], section 8),
    including, at a minimum, full support for authentication and privacy
via the
    User-based Security Model (USM) [RFC3414] with the AES cipher
    algorithm [RFC3826].   Implementations MAY also provide support
    for   the Transport Security Model (TSM)  [RFC5591] in combination
    with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353].

We need first of all agreement from Sean that the change is OK from the
perspective of the Security ADs. 

Also, Juergen, Bert, and all other MIB Doctors, please comment. 

Dan

> [email-masked]] On Behalf Of Randy Presuhn
> Sent: Monday, November 07, 2011 8:49 PM
> To: [email-masked]
> Subject: Re: [MIB-DOCTORS] Updates to the Guidelines of
> theSecurityConsiderations section of the MIB documents
> 
> Hi -
> 
> SecurityConsiderations section of the MIB documents
> >
> 
> > Hi,
> >
features
features
features

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Nov 2011 11:23:59 +0100

> Also, Juergen, Bert, and all other MIB Doctors, please comment. 

Do we also remove the 'even then,' from the previous paragraph? Can we
also drop some of the 'at a minimum' phrases from the text suggested
by Randy? And why do we refer to section 8 of RFC 3410, which talks
about standardization status and movement of SNMPv1 to historic? So
summing up, I have:

OLD

   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),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

NEW

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   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.

   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]), including full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].  Implementations
   MAY also provide support for the Transport Security Model (TSM)
   [RFC5591] in combination with a secure transport such as SSH
   [RFC5592] or TLS/DTLS [RFC6353].

(I am not sure "described by" is the best wording but I happily leave
 it to native speakers to figure this out.)

/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: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 08 Nov 2011 13:38:02 +0100

I am fine with Juergens proposed wording.

Bert

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 8 Nov 2011 08:44:50 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Romascanu, Dan (Dan)" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, November 08, 2011 2:23 AM
> Subject: Re: [MIB-DOCTORS] Updates to the Guidelines of theSecurityConsiderations section of the MIB documents
...
>  it to native speakers to figure this out.)

Juergen's proposed text looks good to me.  (Definitely better than what
I sent out.)

As a native speaker...  I think the "described" is ok (other possibilities
might be "outlined", or "identified", because RFC 3410 doesn't really
go very far in describing them).  The "by" is also ok, though I think
"in" might be slightly better; it would be less anthropomorphic.

(RFC 3410 section 4 just gives a laundry list of generic requirements,
and section 6.4 lists the original SNMPv3 specifications related
to security.  For practical purposes, this normative reference to an
informational document just functions as a shorthand for "STD 62",
in my opinion.)

Randy

---

From: Sean Turner <[email-masked]>
Date: Tue, 08 Nov 2011 16:38:50 -0500

On 11/8/11 11:44 AM, Randy Presuhn wrote:
> Hi -
>
>> From: "Juergen Schoenwaelder"<[email-masked]>
>> To: "Romascanu, Dan (Dan)"<[email-masked]>
>> Cc: "Randy Presuhn"<[email-masked]>;<[email-masked]>

+1

spt

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 9 Nov 2011 14:21:37 +0100

I think that we can declare consensus on the proposed change. 

We also need to add the following Informative References: 

   [RFC3414] Blumenthal, U., and B. Wijnen, 
             "User-based Security Model (USM) for version 3 of the
             Simple Network Management Protocol (SNMPv3)", RFC 3414,
             December 2002.

   [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie,
             "The Advanced Encryption Standard (AES) Cipher 
             Algorithm in the SNMP User-based Security Model",
             RFC 3826, June 2004.

   [RFC5591] Harrington, D., and W. Hardaker,
             "Transport Security Model for the Simple Network 
             Management Protocol (SNMP)", June 2009.

   [RFC5592] Harrington, D., Saloway, J., and W. Hardaker,
             "Secure Shell Transport Model for the Simple Network 
             Management Protocol (SNMP)", June 2009.

   [RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport 
             Model for the Simple Network Management Protocol (SNMP)",
             July 2011.

Dan

------------------------------------------------------------------------
--------

> Sent: Tuesday, November 08, 2011 11:39 PM
> To: [email-masked]
security.
> features as
security.