Subject: [MIB-DOCTORS] Security Guidelines for IETF MIB Modules: normative or informative references?

From: Benoit Claise <[email-masked]>
Date: Wed, 02 Jan 2013 12:33:08 +0100

Dear all,

In the AUTH48 process for draft-ietf-adslmib-gbond-mib-11.txt 
(https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mib&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=), 
we discussed with the RFC editor whether the following RFCs should be 
normative or informative:

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

I thought that they should be normative, based on the justification at 
http://www.ietf.org/iesg/statement/normative-informative.html

    Normative references specify documents that must be read to
    understand or implement the technology in the new RFC, or whose
    technology must be present for the technology in the new RFC to work. 

The RFC editors answered:

    Thank you for the email.  We see your point and agree that it makes
    sense that the references would be listed as normative, but we do
    not make calls on which documents are listed as informative vs
    normative.  We note that
    https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists the
    six references in question -- RFCs 3410, 3414,3826, 5591, 5592, and
    6353 -- as informative. Please request that the wiki be
    updated, if necessary.

So normative or informative references?
Shall I update the WIKI?

Regards, Benoit

---

From: "Bert Wijnen" <[email-masked]>
Date: Wed, 2 Jan 2013 13:52:51 +0100

RFC3410 is an informational document and has ALWAYS been listed as informational.
So... if you make it Normative, you have a downref.
The 3414 and 3826 might be listed as Normative.

The otehr 3 are only listed as MAY implement. So would it then have to be normative?

For me the most important thing is that the pointers to all this
documents are listed, so you can quickly find them.

Bert

  ----- Original Message ----- 
  From: Benoit Claise 
  To: [email-masked] ; MIB Doctors (E-mail) 
  Cc: [email-masked] ; Lynne Bartholomew ; Edward Beili ; Moti Morgenstern 
  Sent: Wednesday, January 02, 2013 12:33 PM
  Subject: [MIB-DOCTORS] Security Guidelines for IETF MIB Modules: normative or informative references?

  Dear all,

  In the AUTH48 process for draft-ietf-adslmib-gbond-mib-11.txt (https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mib&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=), we discussed with the RFC editor whether the following RFCs should be normative or informative: 

   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].I thought that they should be normative, based on the justification at http://www.ietf.org/iesg/statement/normative-informative.html

    Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. 
  The RFC editors answered:

    Thank you for the email.  We see your point and agree that it makes sense that the references would be listed as normative, but we do not make calls on which documents are listed as informative vs normative.  We note that https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists the six references in question -- RFCs 3410, 3414, 3826, 5591, 5592, and 6353 -- as informative. Please request that the wiki be
    updated, if necessary.

  Regards, Benoit

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

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

---

From: David Harrington <[email-masked]>
Date: Thu, 03 Jan 2013 11:20:13 -0500

Hi,

The mib security boilerplate changed in December of 2011, following
discussion between the OPS and Security ADs and the MIB Doctors.

IIRC, we always made implementation of SNMPv3 recommended but not required.
No MIB module (except those specifically related to managing SNMPv3)
should require SNMPv3 to work.
Any MIB theoretically should work with any version of SNMP (given known
interoperability issues of SNMPv1 vs SMIv2, etc.).
Theoretically (and according to IAB recommendations in RFC1052), the MIB
should also be able to work with protocols other than SNMP, since "The
MIB" is just a database that (theoretically) is independent of the
protocol used to access it.
So no MIB module (with exceptions) should REQUIRE a specific protocol or
protocol version to access it.
(yawn. I'm sure you guys are tired of hearing this from me ;-)

We deliberately made RFC3410 Informational to avoid downrefs.
IIRC, you cannot implement RFC3410 because it doesn't define a protocol;
it's just a roadmap.

SNMPv3 was designed as something of a framework that could be built from
multiple pieces - a messaging model, a security model, an ACM model, etc.
RFC3411 ***describes*** an architecture suitable for SNMPv3 usage, but it
was definitely an SNMPv3 WG decision that this was AN architecture, not
THE architecture for SNMPv3, to allow for alternative approaches (such as
ISMS work on transport models) and to allow for implementation-specific
decisions that would not affect the on-the-wire protocol.

The 12/2011 security boilerplate makes SNMPv3 support a MUST, which would
make the defining SNMPv3 RFCs Normative (otherwise it is ambiguous which
RFCs actually make up SNMPv3, and are MUST implement).
But that seems to fly in the face of the SNMPv3 WG intention to NOT make a
certain set of RFCs **THE** SNMPv3 definition.
(Of course, the IESG approved an IETF Standard called SNMPv3, which
contained the RFC34xx series as a set of RFCs within the somewhat-abstract
SNMPv3 Standard, to ensure base interoperability.)

I think if SNMPv3 is a MUST, the boilerplate should spell out which RFCs
MUST be implemented, and make those references normative.
I.e., what you would be doing is defining THE set of RFCs that define
SNMPv3.

I personally think it best not to require a specific version of SNMP as
part of the boilerplate for a MIB module.

--
David Harrington
[email-masked]
+1-603-828-1401

On 1/2/13 7:52 AM, "Bert Wijnen" <[email-masked]> wrote:

>  From: 
>  Benoit Claise <mailto:[email-masked]>
>  
>  To: [email-masked] ; MIB Doctors
>  (E-mail) <mailto:[email-masked]>
>  Cc: [email-masked] ; Lynne
>  Bartholomew <mailto:[email-masked]> ; Edward Beili
><mailto:[email-masked]> ; Moti Morgenstern
><mailto:[email-masked]>
>  Subject: [MIB-DOCTORS] Security
>  Guidelines for IETF MIB Modules: normative or informative references?
>  
>Dear all,
>
>(https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mi
>b&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=),
>   [RFC3414] with the AES cipher algorithm [RFC3826].I thought that they
>  should be normative, based on the justification at
>technology 
>    must be present for the technology in the new RFC to work.
>
>The 
>  RFC editors answered:
>  
>    Thank you for the email.  We see your point and agree that it
>    makes sense that the references would be listed as normative, but we
>do not 
>    make calls on which documents are listed as informative vs normative.
>     We note that 
>https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists
>    the six references in question -- RFCs 3410, 3414, 3826, 5591, 5592,
>and 6353 -- as informative. Please request that the wiki
>    be
>updated, if necessary.
>
>
>________________________________________
>
>MIB-DOCTORS mailing
>  list
>OPS-DIR mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ops-dir

---

From: Benoit Claise <[email-masked]>
Date: Tue, 08 Jan 2013 16:27:07 +0100

Hi Dave,

I understand your argument, and I tend to agree with you.

The problem statement is: the following sentence is kind of broken , 
because RFC 3414 and RFC 3826 are informative references;

There are two things we can do

1. do nothing, because it's not worth it.

2. Correct the sentence

OLD (the 3 paragraphs are copied for completeness, while only the second 
and third one are changed):

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

    Further, deployment of SNMP versions prior to SNMPv3 is NOT
    RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
    enable cryptographic security.  It is then a customer/operator
    responsibility to ensure that the SNMP entity giving access to an
    instance of this MIB module 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.

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])._W__hen implementing SNMPv3, full support for
    authentication and privacy via the User-based Security Model (USM)
    [RFC3414] with the AES cipher algorithm [RFC3826] is RECOMMENDED._
    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].

    Further, deployment of SNMP versions prior to SNMPv3 is NOT
    RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
    enable cryptographic security.  It is then a customer/operator
    responsibility to ensure that the SNMP entity giving access to an
    instance of this MIB module 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.

And we move the following references from informative to normative

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

I want to go for solution 2. If we redo the full discussion, and the 
discussion goes nowhere, I'll go for solution 1 (I have a few documents 
in AUTH48 waiting on this)

Feedback?
Unless I hear otherwise, I will apply the changes in a week from now.

Thanks Dan for helping on this issue.

Regards, Benoit

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 8 Jan 2013 16:11:28 -0500

Hi Benoit,

Unless it is an SNMPv3-specific MIB module, a MIB module will usually not be
broken by using SNMPv1 or SNMPv2.

And, a MIB module typically will not be broken by the use of SNMPv3 with a
security model other than USM with AES.

And, a MIB module will not be broken by using a protocol other than SNMP.

Hence, I think that MUST is being used inappropriately when the boilerplate
says SNMPv3 MUST be supported for a particular MIB module.

I think what we really want to say is that we RECOMMEND SNMPv3 - for
purposes of security - with USM/AES for purposes of interoperability.

I recommend the text read:

   Implementations SHOULD provide the security features described by the
   SNMPv3 framework (see [RFC3410]), and implementations claiming compliance
to the SNMPv3 standard MUST include full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].
 
Of course, it can be debated whether every MIB module document should
include compliance requirements for ONE of the protocols that COULD be used
to access the MIB.
If we are going to add SNMPv3-compliance requirements to every MIB document,
and syslog and netconf and ipfix and others can also be used to carry the
data described in the MIB module, should we include compliance requirements
for specific versions of the syslog protocol, the netconf protocol, the
ipfix protocol, and so on in the MIB boilerplate as well?

As one of the developers of SNMPv3, I certainly would like to see it
implemented, but I think this boilerplate is being heavy handed by saying,
in every IETF MIB module published, that SNMPv3+USM+AES MUST be supported.

The original MIB boilerplate combination said SNMP was typically used for
carrying MIB data, and version 3 of SNMP was RECOMMENDED because of its
security properties. That makes sense to me. The MUST does not.

That said, I am fine with the current boilerplate if that's what the IESG
wants; I just think it's not very accurate.

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: Benoit Claise [mailto:[email-masked]] 
Sent: Tuesday, January 08, 2013 10:27 AM
To: David Harrington
Cc: Bert Wijnen; [email-masked]; MIB Doctors (E-mail); Lynne Bartholomew
Subject: Re: [OPS-DIR] [MIB-DOCTORS] Security Guidelines for IETF MIB
Modules: normative or informative references?

Hi Dave, 

The problem statement is: the following sentence is kind of broken , because
RFC 3414 and RFC 3826 are informative references;

2. Correct the sentence 

OLD (the 3 paragraphs are copied for completeness, while only the second and
third one are changed):

 

NEW: 

   SNMPv3 framework (see [RFC3410]). When implementing SNMPv3, full support
for
   [RFC3414] with the AES cipher algorithm [RFC3826] is RECOMMENDED.
   Implementations MAY also provide support for the Transport Security Model
(TSM)

 

I want to go for solution 2. If we redo the full discussion, and the
discussion goes nowhere, I'll go for solution 1 (I have a few documents in
AUTH48 waiting on this)

Feedback?

Regards, Benoit

Hi,

 

 

--
David Harrington
[email-masked]
+1-603-828-1401

On 1/2/13 7:52 AM, "Bert Wijnen"  <mailto:[email-masked]>
<[email-masked]> wrote:

RFC3410 is an informational document and has ALWAYS been
listed as informational.
So... if you make it Normative, you have a
downref.
The 3414 and 3826 might be listed as Normative.
 
The otehr 3 are only listed as MAY implement. So would it then
have to be normative?
 
For me the most important thing is that the pointers to all
this
documents are listed, so you can quickly find
them.
 
Bert

 ----- Original Message -----
 From: 
 Benoit Claise  <mailto:[email-masked]> <mailto:[email-masked]>
 
 To: [email-masked] ; MIB Doctors
 (E-mail)  <mailto:[email-masked]> <mailto:[email-masked]>
 Cc: [email-masked] ; Lynne
 Bartholomew  <mailto:[email-masked]> <mailto:[email-masked]>
; Edward Beili
 <mailto:[email-masked]> <mailto:[email-masked]> ; Moti
Morgenstern
 <mailto:[email-masked]> <mailto:[email-masked]>
 Sent: Wednesday, January 02, 2013 12:33
 PM
 Subject: [MIB-DOCTORS] Security
 Guidelines for IETF MIB Modules: normative or informative references?
 
Dear all,
 
In the AUTH48 process for
 draft-ietf-adslmib-gbond-mib-11.txt
 
The 
 RFC editors answered:

So normative or informative
 references?
Shall I update the WIKI?
 
Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Wed, 09 Jan 2013 14:50:27 +0100

Hi David,
>
> Hi Benoit,
>
> Unless it is an SNMPv3-specific MIB module, a MIB module will usually 
> not be broken by using SNMPv1 or SNMPv2.
>
> And, a MIB module typically will not be broken by the use of SNMPv3 
> with a security model other than USM with AES.
>
> Hence, I think that MUST is being used inappropriately when the 
> boilerplate says SNMPv3 MUST be supported for a particular MIB module.
>
> I think what we really want to say is that we RECOMMEND SNMPv3 -- for 
> purposes of security -- with USM/AES for purposes of interoperability.
>
>     Implementations_SHOULD_  provide the security features described by the
>     SNMPv3 framework (see [RFC3410]),_and implementations claiming compliance to the SNMPv3 standard_  MUST include full support for
That would be in the spirit of your proposition. Fine with me.

Regards, Benoit
>   
> Of course, it can be debated whether every MIB module document should include compliance requirements for ONE of the protocols that COULD be used to access the MIB.
> If we are going to add SNMPv3-compliance requirements to every MIB document, and syslog and netconf and ipfix and others can also be used to carry the data described in the MIB module, should we include compliance requirements for specific versions of the syslog protocol, the netconf protocol, the ipfix protocol, and so on in the MIB boilerplate as well?
>   
>
> implemented, but I think this boilerplate is being heavy handed by 
> saying, in every IETF MIB module published, that SNMPv3+USM+AES MUST 
> be supported.
>
> The original MIB boilerplate combination said SNMP was typically used 
> for carrying MIB data, and version 3 of SNMP was RECOMMENDED because 
> of its security properties. That makes sense to me. The MUST does not.
>
> That said, I am fine with the current boilerplate if that's what the 
> IESG wants; I just think it's not very accurate.
>
> David Harrington
>
> [email-masked] <mailto:[email-masked]>
>
> +1-603-828-1401
>
> *From:*Benoit Claise [mailto:[email-masked]]
> *Sent:* Tuesday, January 08, 2013 10:27 AM
> *To:* David Harrington
> *Cc:* Bert Wijnen; [email-masked]; MIB Doctors (E-mail); Lynne 
> Bartholomew
> *Subject:* Re: [OPS-DIR] [MIB-DOCTORS] Security Guidelines for IETF 
> MIB Modules: normative or informative references?
>
> Hi Dave,
>
> OLD (the 3 paragraphs are copied for completeness, while only the 
> second and third one are changed):
>
>     SNMPv3 framework (see [RFC3410])._When implementing SNMPv3, full support for_
> _    authentication and privacy via the User-based Security Model (USM)_
> _    [RFC3414] with the AES cipher algorithm [RFC3826] is RECOMMENDED._
> discussion goes nowhere, I'll go for solution 1 (I have a few 
> documents in AUTH48 waiting on this)
>
> Feedback?
>     [email-masked]  <mailto:[email-masked]>
>
>     +1-603-828-1401
>
>       
>
>       
>
>       
>
>       
>
>       
>
>     On 1/2/13 7:52 AM, "Bert Wijnen"<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>       
>
>           Benoit Claise<mailto:[email-masked]>  <mailto:[email-masked]>
>
>           
>
>           To:[email-masked]  <mailto:[email-masked]>  ; MIB Doctors
>
>           (E-mail)<mailto:[email-masked]>  <mailto:[email-masked]>
>
>           Cc:[email-masked]  <mailto:[email-masked]>  ; Lynne
>
>           Bartholomew<mailto:[email-masked]>  <mailto:[email-masked]>  ; Edward Beili
>
>         <mailto:[email-masked]>  <mailto:[email-masked]>  ; Moti Morgenstern
>
>         [email-masked]  <mailto:[email-masked]>
>
>         [email-masked]  <mailto:[email-masked]>
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 16 Jan 2013 10:29:06 +0100

Hi,

The deadline is now passed.
I received the green light from the two security ADs.
Therefore https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security has 
been  updated.
And the 4 ADLSMIB documents will now progress.

Regards, Benoit

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 16 Jan 2013 11:22:35 +0100

SO I guess this means that all MIB documents in progress need to be
updated with this new text too.

Bert

On 1/16/13 10:29 AM, Benoit Claise wrote:
> Therefore https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security has been  updated.
>>> Unless it is an SNMPv3-specific MIB module, a MIB module will usually not be broken by using SNMPv1 or SNMPv2.
>>>
>>> And, a MIB module typically will not be broken by the use of SNMPv3 with a security model other than USM with AES.
>>>
>>> Hence, I think that MUST is being used inappropriately when the boilerplate says SNMPv3 MUST be supported for a particular MIB
>>> module.
>>>
>>> I think what we really want to say is that we RECOMMEND SNMPv3 – for purposes of security – with USM/AES for purposes of
>>> interoperability.
>>>
>>> As one of the developers of SNMPv3, I certainly would like to see it implemented, but I think this boilerplate is being heavy
>>> handed by saying, in every IETF MIB module published, that SNMPv3+USM+AES MUST be supported.
>>>
>>> The original MIB boilerplate combination said SNMP was typically used for carrying MIB data, and version 3 of SNMP was
>>> RECOMMENDED because of its security properties. That makes sense to me. The MUST does not.
>>>
>>> That said, I am fine with the current boilerplate if that’s what the IESG wants; I just think it’s not very accurate.
>>>
>>> David Harrington
>>>
>>> *Cc:* Bert Wijnen; [email-masked]; MIB Doctors (E-mail); Lynne Bartholomew
>>> *Subject:* Re: [OPS-DIR] [MIB-DOCTORS] Security Guidelines for IETF MIB Modules: normative or informative references?
>>>
>>> Hi Dave,
>>>
>>> The problem statement is: the following sentence is kind of broken , because RFC 3414 and RFC 3826 are informative references;
>>>
>>> OLD (the 3 paragraphs are copied for completeness, while only the second and third one are changed):
>>>
>>> I want to go for solution 2. If we redo the full discussion, and the discussion goes nowhere, I'll go for solution 1 (I have a
>>> few documents in AUTH48 waiting on this)
>>>
>>> Feedback?

---

From: Benoit Claise <[email-masked]>
Date: Wed, 16 Jan 2013 11:36:47 +0100

> updated with this new text too.
Yes.
And the RFC editors have been warned.
This is actually the RFC editors who checked the consistency with 
https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security

Regards, Benoit
>>>> Unless it is an SNMPv3-specific MIB module, a MIB module will 
>>>> usually not be broken by using SNMPv1 or SNMPv2.
>>>>
>>>> I think what we really want to say is that we RECOMMEND SNMPv3 – 
>>>> for purposes of security – with USM/AES for purposes of
>>>> interoperability.
>>>>
>>>>     SNMPv3 framework (see [RFC3410]),_and implementations claiming 
>>>> compliance to the SNMPv3 standard_  MUST include full support for
>>>> Of course, it can be debated whether every MIB module document 
>>>> should include compliance requirements for ONE of the protocols 
>>>> that COULD be used to access the MIB.
>>>> If we are going to add SNMPv3-compliance requirements to every MIB 
>>>> document, and syslog and netconf and ipfix and others can also be 
>>>> used to carry the data described in the MIB module, should we 
>>>> include compliance requirements for specific versions of the syslog 
>>>> protocol, the netconf protocol, the ipfix protocol, and so on in 
>>>> the MIB boilerplate as well?
>>>>
>>>>
>>>> As one of the developers of SNMPv3, I certainly would like to see 
>>>> it implemented, but I think this boilerplate is being heavy
>>>> The original MIB boilerplate combination said SNMP was typically 
>>>> used for carrying MIB data, and version 3 of SNMP was
>>>> That said, I am fine with the current boilerplate if that’s what 
>>>> the IESG wants; I just think it’s not very accurate.
>>>>
>>>> David Harrington
>>>>
>>>> The problem statement is: the following sentence is kind of broken 
>>>> , because RFC 3414 and RFC 3826 are informative references;
>>>>
>>>> I want to go for solution 2. If we redo the full discussion, and 
>>>> the discussion goes nowhere, I'll go for solution 1 (I have a
>>>>           Bartholomew<mailto:[email-masked]> 
>>>> <mailto:[email-masked]>  ; Edward Beili
>>>>