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

From: Sean Turner <[email-masked]>
Date: Wed, 05 Oct 2011 14:29:12 -0400

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.

Thoughts?

spt

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 5 Oct 2011 12:19:49 -0700

Hi -

> From: "Sean Turner" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, October 05, 2011 11:29 AM
> Subject: [MIB-DOCTORS] Updates to the Guidelines of the Security Considerations section of the MIB documents
...
> 3826 reference.  And, the reference to 5591 expands the options to allow 

Since RFC 3826 incorporates RFC 3414 as a normative reference, I don't
see why RFC 3414 needs to be cited.  Since there is no point in implementing
RFC 5591 *unless* one actually needs something like 6353 (which in turn
incorporates RFC 5591 as a normative reference) I also don't see any
point in mentioning RFC 5591 here, unless you intend to actuall recommend/
require 6353.  So here's a counter-proposal:

NEW':
    It is RECOMMENDED that implementers consider the security features
    as provided by the SNMPv3 framework (see [RFC3410], section 8),
    as well as full support for the Advanced Encryption Standard (AES)
    Cipher Algorithm in the SNMP User-based Security Model [RFC3826].

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Oct 2011 22:13:35 +0200

On Wed, Oct 05, 2011 at 02:29:12PM -0400, Sean Turner wrote:
> ought to be replaced with SNMP+AES, I'd like to propose the
> following change to the MIB security considerations:
> 
> OLD:
> 
> 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].

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).

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.

/js

PS: Another good action would be to advance RFC3826 on the standards
    track - this is still a proposed standard...

-- 
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: Sean Turner <[email-masked]>
Date: Wed, 05 Oct 2011 17:31:33 -0400

>     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.

> changed, e.g. the "even then" in the IPsec phrase (which IMHO should

I'm okay with this too.

>     allowed to access and GET/SET (read/change/create/delete) the objects

I'm fine with this.

>      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.

spt

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 6 Oct 2011 10:58:05 +0200

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
> 
[[DR]] I also prefer the first of the two versions as it makes clear the
models and the associated secure transports with the options. 

> I'm willing to help out.  If we've got two interoperable
[[DR]] This could be done in OPSAWG. I do not remember if 3826 was done
in OPS or in SEC. 

> spt
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Sean Turner <[email-masked]>
Date: Thu, 06 Oct 2011 06:14:29 -0400

> [[DR]] This could be done in OPSAWG. I do not remember if 3826 was done

[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