Subject: [MIB-DOCTORS] FW: Need for an update to the "Security Guidelines for IETF MIB" boilerplate

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 14 Apr 2011 13:09:36 +0200

Hi MIB Doctors, 

Please see Vincent's comments triggered by his SecDir review of
http://www.ietf.org/id/draft-ietf-netlmm-pmipv6-mib-05.txt

Your advice is required. 

Thanks and Regards,

Dan 

-----Original Message-----
From: Vincent Roca [mailto:[email-masked]] 
Sent: Thursday, April 14, 2011 11:58 AM
To: Romascanu, Dan (Dan)
Cc: Vincent Roca; Sean Turner; [email-masked]
Subject: Need for an update to the "Security Guidelines for IETF MIB"
boilerplate

Hello Dan,

While doing the SecDir review of the pmipv6 MIB document, I've spotted
two issues concerning the official "Security Considerations"
boilerplate for MIB I-Ds that may require a small update.

More precisely:

1- the boilerplate references a wrong section in RFC3410 
    (see my comment below)

2- section 7.8 of RFC3410, when describing the User-based Security
  Model, only refers to DES. It's somewhat outdated. So I suggest
  adding a reference to RFC3826 (AES in SNMPv3) in the boilerplate,
  in addition to RFC3410.
  (BTW I didn't search if similar, more recent RFCs exist in addition to
   RFC3826).

  I don't know what Sean/Stephen think about it.

> ** Wrong reference:
> It is said:
>  "It is RECOMMENDED that implementers consider the security features
as
>   provided by the SNMPv3 framework (see [RFC3410], section 8) [...]"
> Section 8 is not the section of interest as it only focuses on the 
> standardization status. More interesting sections in RFC3410
> are:
> - section 6.3 "SNMPv3 security and administration", and in particular
> - section 7, in particular section 7.8 "user based security model".
> 
> NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an 
> issue, now it is. The last sentence of RFC3410/section 7.8 mentions 
> on-going work on using AES in the user-based security model. If this 
> work gave birth to an RFC, that's probably a good document to refer 
> too.

Cheers,

   Vincent

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 15 Apr 2011 10:03:54 +0200

I would leave the reference to 3410 as is. It points to the place where you can find the
an explanation as to why to NOT use SNMPv1/v2c. From there, I think people
will find their way to SNMP security related text.

Adding a pointer to 3826 may indeed make sense.
I wonder however how many implementations/deployments there are.
If there are enough, then maybe the document should become DS or Full Standard.

I will note, that everytime that the security template needed change... there have been
looooong discussions.

my 2 cts
Bert

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

---

From: Vincent Roca <[email-masked]>
Date: Mon, 18 Apr 2011 15:33:28 +0200

Hello Bert,

> will find their way to SNMP security related text.

Of course, RFC3410 is very important for clarifying why version 1 or 2c MUST NOT
or SHOULD NOT be used. Keep this reference in the boilerplate.

> I will note, that everytime that the security template needed change... there have been

Put very simply, the situation is the following. The boilerplate, today,
RECOMMENDs to follow the security guidelines of RFC3410 . This latter
says:

 "The USM utilizes MD5 [31] and the Secure Hash Algorithm [32] as keyed
    hashing algorithms [33] for digest computation to provide data integrity:"

  "The USM uses the Data Encryption Standard (DES) [34] in the cipher
    block chaining mode (CBC) if disclosure protection is desired."

Since the boilerplate does not reference anything else, by transitivity,
I understand that it RECOMMENDS the use of both MD5 and DES!!!
No IETF standard would be allowed with such recommendations, today.

Whether or not there are implementations/deployments that use more
recent cryptosystems (e.g. RFC3826) is a different question. The problem
is more fundamental and should be treated as such IMHO. Especially as
it should be easy to fix (i.e. by adding a reference).

I'm CCing our Security ADs.

Cheers,

   Vincent

---

From: Sean Turner <[email-masked]>
Date: Tue, 19 Apr 2011 09:41:38 -0400

> I'm CCing our Security ADs.

I think the bit Vincent quotes is about the USM, which "defines the 
Elements of Procedure for providing SNMP message-level security".  RFC 
5591 and 5592 provide alternatives as noted in RFC 5590:

   The Transport Security Model [RFC5591] and the Secure Shell Transport
   Model [RFC5592] utilize the Transport Subsystem.  The Transport
   Security Model is an alternative to the existing SNMPv1 Security
   Model [RFC3584], the SNMPv2c Security Model [RFC3584], and the User-
   based Security Model [RFC3414].  The Secure Shell Transport Model is
   an alternative to existing transport mappings as described in
   [RFC3417].

Couldn't just update the following blurb in the boilerplate to point to 
5591 and 5592:

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

Gotta ask: why does it point to Section 8 which is Standardization Status?

spt

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 26 Apr 2011 12:59:04 +0200

> Gotta ask: why does it point to Section 8 which is 

Because that section explains the status of SNMPv1/v2c. 

Dan

> From: Sean Turner [mailto:[email-masked]] 
> Sent: Tuesday, April 19, 2011 4:42 PM
> To: Vincent Roca; Bert (IETF) Wijnen; Romascanu, Dan (Dan)
> Cc: [email-masked]; Stephen Farrell
> Subject: Re: [MIB-DOCTORS] FW: Need for an update to the 
> "Security Guidelines for IETF MIB" boilerplate
> 
> >> I would leave the reference to 3410 as is. It points to the place 
> >> where you can find the an explanation as to why to NOT use 
> >> SNMPv1/v2c. From there, I think people will find their way 
> to SNMP security related text.
> >
> > Of course, RFC3410 is very important for clarifying why 
> version 1 or 
> > 2c MUST NOT or SHOULD NOT be used. Keep this reference in 
> the boilerplate.
> >
> >
> >> I will note, that everytime that the security template needed 
> >> change... there have been looooong discussions.
> >
> > Put very simply, the situation is the following. The boilerplate, 
> > today, RECOMMENDs to follow the security guidelines of 
> RFC3410 . This 
> > latter
> > says:
> >
> > Since the boilerplate does not reference anything else, by 
> > transitivity, I understand that it RECOMMENDS the use of 
> both MD5 and DES!!!
> > recent cryptosystems (e.g. RFC3826) is a different question. The 
> > problem is more fundamental and should be treated as such IMHO. 
> > Especially as it should be easy to fix (i.e. by adding a reference).
> >
> I think the bit Vincent quotes is about the USM, which 
> "defines the Elements of Procedure for providing SNMP 
> message-level security".  RFC
> >>> While doing the SecDir review of the pmipv6 MIB document, I've 
> >>> spotted two issues concerning the official "Security 
> Considerations"
> >>>> on-going work on using AES in the user-based security model. If 
> >>>> this work gave birth to an RFC, that's probably a good 
> document to 
> >>>> refer too.
> >>>
> >>> Cheers,
> >>>
> >>>     Vincent

---

From: Sean Turner <[email-masked]>
Date: Tue, 26 Apr 2011 07:37:18 -0400

Dan,

So maybe it's point to the wrong section?  The text from the MIB boiler 
plate follows:

  It is RECOMMENDED that implementers consider the security
  features as
  provided by the SNMPv3 framework (see [RFC3410], section 8),

If it's talking about the SNMPv3 framework and the security features it 
supports wouldn't it seems like it ought to be pointing to section 7.8 
and 7.9 of 3410 and not the standardization status of SNMP v1 and v2?

spt

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 26 Apr 2011 13:45:59 +0200

Hi Sean,

You are truncating the phrase - the continuation of it speaks about the
full support for SNMPv3 :-) 

> >>    It is RECOMMENDED that implementers consider the security
features 
> >>    as provided by the SNMPv3 framework (see [RFC3410], section 8),

I read it as 'do SNMPv3 (first of all) because this is the only
non-historic version of SNMP in town (as pointed by the referred
section)'

Dan 

> Sent: Tuesday, April 26, 2011 2:37 PM
> To: Romascanu, Dan (Dan)
> Cc: Vincent Roca; Bert (IETF) Wijnen; [email-masked]; 
> Stephen Farrell
> So maybe it's point to the wrong section?  The text from the 
> MIB boiler plate follows:
> 
> If it's talking about the SNMPv3 framework and the security 
> features it supports wouldn't it seems like it ought to be 
> pointing to section 7.8 and 7.9 of 3410 and not the 
> standardization status of SNMP v1 and v2?
> 
> spt
> 
> >> Subject: Re: [MIB-DOCTORS] FW: Need for an update to the "Security 
> >> Guidelines for IETF MIB" boilerplate
> >>
> "defines the 
> >>     based Security Model [RFC3414].  The Secure Shell 
> Transport Model 
> >> is
> >> Couldn't just update the following blurb in the 
> boilerplate to point 
> >> to
> >> 5591 and 5592:
> >>
> >>    It is RECOMMENDED that implementers consider the 
> security features 
> >> as

---

From: Sean Turner <[email-masked]>
Date: Tue, 26 Apr 2011 07:57:26 -0400

> non-historic version of SNMP in town (as pointed by the referred

Ah I see now.  I totally wasn't reading it that way.  I was reading it 
as a pointer for the security features of the SNMPv3 framework.