Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)
draft-ietf-isms-dtls-tm-14

[Ballot discuss]
Much as I would love to believe that changing a bit of text in Section 7 solves the problem of moving SNMP-over-TLS from IDNA2003 to IDNA2008 (and recognizing that I provided that bit of text to the responsible AD!), I fear that it does not. I realize that probably few if any implementations of RFC 5953 have been deployed with internationalized domain names, which might be why the implementation report does not mention IDNs. However, from the standpoint of both protocol development and technology deployment I think there's more work to be done here. I look forward to discussing this on the IESG telechat.

[Ballot discuss]
1) There are several normative references in this document to RFCs that are not ready to progress to Draft Standard. It's not clear that the parts of those drafts that are used are stable. In particular, this RFC currently references RFC3490 - the RFC Editor note updates the reference to 5890, but did the interop testing cover implementations of this protocol using the techniques in 5890? Would any further changes to IDNA impact what's specified in this draft? Similarly, the draft references RFC5280, which has errata and a clarification draft in progress. Are the parts of 5280 this protocol uses stable?

2) I believe asking the RFC Editor to issue a new RFC based on the existing RFC and a set of RFC Editor notes is likely to lead to unexpected trouble that could be avoided by processing this as a draft. At a minimum:
  - Is it clear what boilerplate the RFC Editor should use on the new RFC?
  - Who signs off on the new RFC in AUTH48?

[Ballot discuss]
I'd like to understand this bit of text in the interop report:

        Neither implementation claims to be a complete, bug-free
        production ready implementation, and occasional differences have
        been found noted between the implementations. To date, however,
        all the differences have fallen into one of these categories:

          - object not implemented yet
          - corner cases not handled yet
          - code needs to be refactored to meet requirement

        In other words, so far all issues are with a particular
        implementation, not with the specification.

These are very general statements and I'm simply not clear on how it
was determined that this wasn't a specification problem.

[Ballot discuss]
I'd like to understand this bit of text in the interop report:

        Neither implementation claims to be a complete, bug-free
        production ready implementation, and occasional differences have
        been found noted between the implementations. To date, however,
        all the differences have fallen into one of these categories:

          - object not implemented yet
          - corner cases not handled yet
          - code needs to be refactored to meet requirement

        In other words, so far all issues are with a particular
        implementation, not with the specification.

These are very general statements and I'm simply not clear on how it was determined that this wasn't a specification problem.

[Ballot comment]
4.4.1.1 3rd para., "the tmSecurityName is presented to the TLS Transport Model by the application" is still inaccurate;

the new text re: demultiplex is a bit incorrect.

Wes will correct both at auth48.

[Ballot discuss]
updated after reviewing -12-

4.1.1 I am concerned that "SHOULD map" is not specific enough; it does not recommend a 1:1 mapping, just a mapping. A single user certificate could generate different results on different implementations when using the snmpTlstmCertSANAny transform. If a Cisco implementation took a subjectAltName of "David Harrington" and ***derived*** a tmSecurityName of "David", while a Huawei implementation took a subjectAltName of "David Harrington" and ***derived*** a tmSecurityName of "Harrington", these may be predictable derivations, but they are not consistent across vendors. An operator or a configuration application would need to know which vendor produced the implementation in order to configure the VACM and TARGET MIB modules with appropriate securityNames.  I believe this document should specify a 1:1 mapping for the snmpTlstmCertSANAny transform between the value extracted from the certificate and the tmSecurityName, so both implementations would map "David Harrington" to "David Harrington". Otherwise it becomes significantly more difficult to configure SNMPv3, which would defeat the purpose of ISMS.
In particular, ISMS is developing support for central AAA authentication and authorization, where the user is identified by the securityName (see draft-ietf-isms-radius-vacm-05.txt section 4.3). If different vendors generate inconsistent tmSecurityNames (which then become securityNames), the AAA servers will need to know which implementation they are dealing with, and AAA admins will need to understand all the different mappings to securityname that could occur from the same corporate-assigned certificate. I believe this is a bad thing that can be reduced by specifying that the snmpTlstmCertSANAny mapping to tmSecurityName MUST be 1:1 from the certificate source field.

4.4.1.1 3rd para., "the tmSecurityName is presented to the TLS Transport Model by the application" is still inaccurate;
>Wes proposed a change that was good, but it doesn't seem to have made it into -11- or -12-

5.1.1 demultiplexing must be available to operators and applications that need demultiplexing when using SNMP/DTLS/UDP.
  Depending on the DTLS implementation, for DTLS
  over UDP, this demultiplexing may need to be done by the TLSTM
  implementation.
"may need to" is not consistent with RFC2119 keywords. Please use RFC2119 keywords to explain what MUST be implemented to be compliant. If demultiplexing is not mandatory-to-implement for TLSTM, please explain in the document the operational impact of it not being available.

[Ballot comment]
I am still quite concerned about the following issues and I don't think I've heard convincing enough answers other than "this was discussed in the WG" and "some security people like Pasi and Jeffrey Hutzelman". So I am reluctantly clearing this. I am leaving the text in the Comment section:

In Section 7:

snmpTlstmCertSANAny OBJECT-IDENTITY
    STATUS        current
    DESCRIPTION  "Maps any of the following fields using the
                  corresponding mapping algorithms:

                  |------------+------------------------|
                  | Type      | Algorithm              |
                  |------------+------------------------|
                  | rfc822Name | snmpTlstmCertSANRFC822Name |
                  | dNSName    | snmpTlstmCertSANDNSName    |
                  | iPAddress  | snmpTlstmCertSANIpAddress  |
                  |------------+------------------------|

                  The first matching subjectAltName value found in the
                  certificate of the above types MUST be used when
                  deriving the tmSecurityName."
    ::= { snmpTlstmCertToTSNMIdentities 5 }

I am generally concerned about 2 things here:
A) too many identity extraction algorithm choices presented in the document
B) snmpTlstmCertSANAny in particular relies on certain ordering of subjectAltName types. I don't think existing TLS APIs are geared toward iterating over subjectAltName types, they are usually allow retrieval of a certain subjectAltName item by type.

[Ballot comment]
A few thoughts about the MIB module. Nothing of any great importance.

It would be helpful if the Imports clause indicated (through comments)
the source documents for the MIB modules from which things are being
imported.

---

SnmpTLSAddress

Since I-D.ietf-6man-text-addr-representation is ahead of this document
in the process-chain, it would be good if you could include an RFC
Editor note requesting the reference to be changed where it appears in
the Description and Reference clause in the MIB module in this
document.

So the comment
-- RFC Editor: if I-D.ietf-6man-text-addr-representation fails to get
-- published ahead of this draft, RFC3513 has been agreed to be a
-- sufficient replacement instead.
could also be clarified as a specific instruction.

Note that since the I-D is a normative reference, you don't have to
worry about the order of publication.

---

SnmpTLSFingerprint

Some problem with line feeds?

---

Do you need to worry about discontinuities with your counters?

[Ballot comment]
(new) 6. The MIB is included in the document to make it SNMP-manageable, but
> the problems can be experienced whether the device is MIB-instrumented or not.
s/MIB-instrumented device may be experiencing/device may be experiencing/
in 6.4, only a MIB-instrumented device will have these tables
s/MIB-instrumented device/device/

(new) in A.2 s/subjecwAltName/subjectAltName/
and s/.././

[Ballot discuss]
updated after reviewing -11-

4.1.1 "Enterprise configurations are encouraged to map" -
> the change in -11- to "Deployments SHOULD" addresses this, but I am concerned that "SHOULD map" is not specific enough; it does not recommend a 1:1 mapping, just a mapping. Should this specify a 1:1 mapping for interoperability?

4.4.1.1 3rd para., "the tmSecurityName is presented to the TLS Transport Model by the application" is inaccurate;
>Wes proposed a change that was good, but it doesn't seem to have made it into -11-

5.1.1 "If demultiplexing ..." Should this be strengthened?
> my earlier suggestion was too implementation-detailed.
I think this should be MUST implement, to ensure it is available to operators and applications that need demultiplexing.
it should have an enable/disable control. if the underlying DTLS has demultiplexing, the TLSTM demultiplexing can be disabled.

SnmpTlstmCertSANiPAddress - the IPv6 support for this object and the TSM prefix feature are impossible to use together in combination with the mandatory-to-implement VACM. Yet no recommendation is made about which
>The new text in -11- section 8.5 seems too detailed.
>Wes and I agreed on an alternative text change:
> eliminate 8.5 and add the following in section 4.1:
"The standard VACM access control model constrains securityNames to be 32 octets or less in length. A TLSTM generated tmSecurityName, possibly in combination with a messaging or security model that increases the length of the securityName, might cause the securityName length to exceed 32 octets. For example, a 32 octet tmSecurityName derived from an IPv6 address, paired with a TSM prefix, will generate a 36 octet securityName. Such a securityName will not be able to be used with standard VACM or TARGET MIB modules. Operators should be careful to select algorithms and subjectAltNames to avoid this situation."
This might be best in section 4.1 where there is already a discussion of generation of tmSecurityName and subsequent mapping into securityName used in MIB modules. I recommend placing such advice after the paragraph that starts "This tmSecurityName may be later translated".

[Ballot discuss]
This is an updated discuss - adding a new second issue.

(1) RFC 5590 states:

  It is considered desirable by some industry segments that SNMP
  Transport Models utilize transport-layer security that addresses
  perfect forward secrecy at least for encryption keys.  Perfect
  forward secrecy guarantees that compromise of long-term secret keys
  does not result in disclosure of past session keys.  Each proposed
  Transport Model should include a discussion in its security
  considerations of whether perfect forward secrecy is appropriate for
  that Transport Model.

This document does not appear to include any such discussion.

(2) The document requires use of  TLS, and mandates certificate-based
authentication for both the client and server.  This provides a nice baseline
with a reasonably consistent level of security. However, many people
consider SSL and TLS to be interchangeable, and early versions of SSL do
not provide an acceptable level of security.  I would like to see text along
the following lines added to this specification:

  Implementations of TLS typically support multiple versions of the
  Transport Layer Security protocol as well as the older Secure
  Sockets Layer (SSL) protocol.  Because of known security
  vulnerabilities, TLSTM clients and servers MUST
  NOT request, offer, or use SSL 2.0.  See Appendix E.2 of [TLS]
  for further details.

The Security Considerations would be one possible location for this
text, but the exact placement is not an issue...

[Ballot discuss]
I agree that this document is important, however there is a list of issues I would like to discuss before recommending approval of this document:

2) In Section 7:

snmpTlstmCertSANAny OBJECT-IDENTITY
    STATUS        current
    DESCRIPTION  "Maps any of the following fields using the
                  corresponding mapping algorithms:

                  |------------+------------------------|
                  | Type      | Algorithm              |
                  |------------+------------------------|
                  | rfc822Name | snmpTlstmCertSANRFC822Name |
                  | dNSName    | snmpTlstmCertSANDNSName    |
                  | iPAddress  | snmpTlstmCertSANIpAddress  |
                  |------------+------------------------|

                  The first matching subjectAltName value found in the
                  certificate of the above types MUST be used when
                  deriving the tmSecurityName."
    ::= { snmpTlstmCertToTSNMIdentities 5 }

I am generally concerned about 2 things here:
A) too many identity extraction algorithm choices presented in the document
B) snmpTlstmCertSANAny in particular relies on certain ordering of subjectAltName types. I don't think existing TLS APIs are geared toward iterating over subjectAltName types, they are usually allow retrieval of a certain subjectAltName item by type.

[Ballot discuss]
RFC 5590 states:

  It is considered desirable by some industry segments that SNMP
  Transport Models utilize transport-layer security that addresses
  perfect forward secrecy at least for encryption keys.  Perfect
  forward secrecy guarantees that compromise of long-term secret keys
  does not result in disclosure of past session keys.  Each proposed
  Transport Model should include a discussion in its security
  considerations of whether perfect forward secrecy is appropriate for
  that Transport Model.

This document does not appear to include any such discussion.

[Ballot comment]
RFC 5590 states:


  It is considered desirable by some industry segments that SNMP
  Transport Models utilize transport-layer security that addresses
  perfect forward secrecy at least for encryption keys.  Perfect
  forward secrecy guarantees that compromise of long-term secret keys
  does not result in disclosure of past session keys.  Each proposed
  Transport Model should include a discussion in its security
  considerations of whether perfect forward secrecy is appropriate for
  that Transport Model.

This document does not appear to include any such discussion.

[Ballot comment]
Section 1.1 has:

  "Authentication" in this document typically refers to the English
  meaning of "serving to prove the authenticity of" the message, not
  data source authentication or peer identity authentication.

Why not reference the definition from RFC 4949?

I realize that RFC 3411 talks about "privacy", but the more modern term is "data confidentiality" (see, again, RFC 4949).

Forgive my ignorance regarding SNMP/SMI, but I can't seem to find a definition of "transport domain"; is it a DNS domain name, a trust domain, or something else? (It seems to be more like an address type.) It might help to make this clearer in the definitions of the snmpTLSTCPDomain and snmpDTLSUDPDomain transport domains.

The definition of snmpTlstmCertSANDNSName mentions converting the DNS domain name to lower case. Is the handling of internationalized domain names inherited from dNSName in RFC 5280 (i.e., convert to the ACE encoding)?

Is there any provision for supporting subjectAltName extension types other than dNSName, rfc822name, and iPAddress, such as SRVName (RFC 4395) or uniformResourceIdentifier (cf. RFC 4088)?

Is there a preferred order of matching subjectAltName extensions?

How exactly does an entity prepare for matching of subjectAltName extensions? See the discussion in draft-saintandre-tls-server-id-check for related material.

It might be appropriate for this specification to say that checking of the Common Name is a fallback and that checking of subjectAltName extensions is preferred.

[Ballot discuss]
The definition of snmpTlstmCertSANIpAddress mentions that securityName lengths might exceed what VACM can handle; doesn't this introduce possible interoperability problems?

The definition of SnmpTLSAddress states that "internationalized hostnames are encoded in US-ASCII as specified in RFC 3490", but I think this could be defined more precisely because (1) RFC 3490 does not talk about "internationalized hostnames", (2) you need to state that you are using the ToASCII operation, and (3) you need to specify whether the UseSTD3ASCIIRules flag is set. This definition also appears to make normative references to RFC 1033 and RFC 3490, but those specifications are not included in the Normative References section. Finally, this definition references RFC 3986 but that specification is never used here.

[Ballot comment]
Section 1.1 has:

  "Authentication" in this document typically refers to the English
  meaning of "serving to prove the authenticity of" the message, not
  data source authentication or peer identity authentication.

Why not reference the definition from RFC 4949?

I realize that RFC 3411 talks about "privacy", but the more modern term is "data confidentiality" (see, again, RFC 4949).

[Ballot comment]
[RFC5292]  Chen, E. and S. Sangli, "Address-Prefix-Based Outbound
              Route Filter for BGP-4", RFC 5292, August 2008.

This reference looks incorrect, considering the following text in Section 11:

  This document closely follows and copies the Secure Shell Transport
  Model for SNMP defined by David Harrington and Joseph Salowey in
  [RFC5292].

In Section 3.1.2, the last sentence of the last paragraph:

  Implementations should offer

s/should/SHOULD ?

  configuration settings for mapping algorithms to SNMPv3 security
  levels.


3.1.3.  (D)TLS Connections

  As an implementation hint: note
  that the (D)TLS internal SessionID does not meet these requirements,
  since it can change over the life of the connection as seen by the
  TLSTM (for example, during renegotiation), and does not necessarily
  uniquely idenfify a TLSTM session (there can be multiple TLSTM

typo: identify

  sessions sharing the same D(TLS) internal SessionID).

In Section 5.1.1:

The first reference to acronym LCD should be expanded and should point to where it is defined.

In Section 7:

snmpTlstmCertToTSNRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The status of this conceptual row.  This object may be used
        to create or remove rows from this table.

        To create a row in this table, an administrator must set this
        object to either createAndGo(4) or createAndWait(5).

        Until instances of all corresponding columns are appropriately
        configured, the value of the corresponding instance of the
        snmpTlstmParamsRowStatus column is 'notReady'.

Is 'notReady' correspond to an actual value of this field?
(Similar question regarding 'notReady' value in snmpTlstmParamsRowStatus
and snmpTlstmAddrRowStatus.)

Also in Section 7:

snmpTlstmServerInvalidCertificate NOTIFICATION-TYPE
    OBJECTS { snmpTlstmAddrServerFingerprint,
              snmpTlstmSessionInvalidServerCertificates}
    STATUS  current
    DESCRIPTION
        "Notification that the server certificate presented by an SNMP
        over (D)TLS server could not be validated even if the
        fingerprint or expected validation path was known.  I.E., a
        cryptographic validation occurred during certificate

Is the word "error" missing after the word "validation"?

        validation processing.

8.1.  Sessions

  Whenever possible, implementations
  SHOULD provide graceful session termination through the use of
  disconnect messages.

Did you mean TLS disconnect messages here?

[Ballot discuss]
I agree that this document is important, however there is a list of issues I would like to discuss before recommending approval of this document:

1) In Section 7:

snmpTlstmParamsClientFingerprint OBJECT-TYPE
    SYNTAX      Fingerprint
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "A cryptographic hash of a X.509 certificate.  This object
        should store the hash of a locally held X.509 certificate that
        should be used (along with the corresponding private key) when

How is the private key stored?

        initiating a (D)TLS connection as a (D)TLS client."
    ::= { snmpTlstmParamsEntry 1 }

2) In Section 7:

snmpTlstmCertSANAny OBJECT-IDENTITY
    STATUS        current
    DESCRIPTION  "Maps any of the following fields using the
                  corresponding mapping algorithms:

                  |------------+------------------------|
                  | Type      | Algorithm              |
                  |------------+------------------------|
                  | rfc822Name | snmpTlstmCertSANRFC822Name |
                  | dNSName    | snmpTlstmCertSANDNSName    |
                  | iPAddress  | snmpTlstmCertSANIpAddress  |
                  |------------+------------------------|

                  The first matching subjectAltName value found in the
                  certificate of the above types MUST be used when

Does the table prescribe the order in which various subjectAltName types are checked?

                  deriving the tmSecurityName."
    ::= { snmpTlstmCertToTSNMIdentities 5 }

3) In Section 7:

snmpTlstmCertToTSNMapType OBJECT-TYPE
    SYNTAX      AutonomousType
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Specifies the mapping type for deriving a tmSecurityName from
        a certificate.

I couldn't find where allowed values for this are defined. Can you please help me find it?

4) In Section 7:

SnmpTLSAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1a"
    STATUS      current
    DESCRIPTION
        "Represents a IPv4 address, an IPv6 address or an US-ASCII
        encoded hostname and port number.

        An IPv4 address must be in dotted decimal format followed by a
        colon ':' (US-ASCII character 0x3A) and a decimal port number
        in US-ASCII.

        An IPv6 address must be a colon separated format, surrounded
        by square brackets ('[', US-ASCII character 0x5B, and ']',
        US-ASCII character 0x5D), followed by a colon ':' (US-ASCII
        character 0x3A) and a decimal port number in US-ASCII.

This is missing a reference to a document defining the exact IPv6 format.

5).
  [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

DISCUSS DISCUSS:
I think this reference is Normative, as it is a recommended procedure (SHOULD level requirement) for allowing the client to tell the server which hostname it is connecting to.

[Ballot comment]
In Section 3.1.2, the last sentence of the last paragraph:

  Implementations should offer

s/should/SHOULD ?

  configuration settings for mapping algorithms to SNMPv3 security
  levels.


3.1.3.  (D)TLS Connections

  As an implementation hint: note
  that the (D)TLS internal SessionID does not meet these requirements,
  since it can change over the life of the connection as seen by the
  TLSTM (for example, during renegotiation), and does not necessarily
  uniquely idenfify a TLSTM session (there can be multiple TLSTM

typo: identify

  sessions sharing the same D(TLS) internal SessionID).

In Section 5.1.1:

The first reference to acronym LCD should be expanded and should point to where it is defined.

In Section 7:

snmpTlstmCertToTSNRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The status of this conceptual row.  This object may be used
        to create or remove rows from this table.

        To create a row in this table, an administrator must set this
        object to either createAndGo(4) or createAndWait(5).

        Until instances of all corresponding columns are appropriately
        configured, the value of the corresponding instance of the
        snmpTlstmParamsRowStatus column is 'notReady'.

Is 'notReady' correspond to an actual value of this field?
(Similar question regarding 'notReady' value in snmpTlstmParamsRowStatus
and snmpTlstmAddrRowStatus.)

Also in Section 7:

snmpTlstmServerInvalidCertificate NOTIFICATION-TYPE
    OBJECTS { snmpTlstmAddrServerFingerprint,
              snmpTlstmSessionInvalidServerCertificates}
    STATUS  current
    DESCRIPTION
        "Notification that the server certificate presented by an SNMP
        over (D)TLS server could not be validated even if the
        fingerprint or expected validation path was known.  I.E., a
        cryptographic validation occurred during certificate

Is the word "error" missing after the word "validation"?

        validation processing.

8.1.  Sessions

  Whenever possible, implementations
  SHOULD provide graceful session termination through the use of
  disconnect messages.

Did you mean TLS disconnect messages here?

[Ballot discuss]
I agree that this document is important, however there is a list of issues I would like to discuss before recommending approval of this document:

1) In Section 7:

snmpTlstmParamsClientFingerprint OBJECT-TYPE
    SYNTAX      Fingerprint
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "A cryptographic hash of a X.509 certificate.  This object
        should store the hash of a locally held X.509 certificate that
        should be used (along with the corresponding private key) when

How is the private key stored?

        initiating a (D)TLS connection as a (D)TLS client."
    ::= { snmpTlstmParamsEntry 1 }

2) In Section 7:

snmpTlstmCertSANAny OBJECT-IDENTITY
    STATUS        current
    DESCRIPTION  "Maps any of the following fields using the
                  corresponding mapping algorithms:

                  |------------+------------------------|
                  | Type      | Algorithm              |
                  |------------+------------------------|
                  | rfc822Name | snmpTlstmCertSANRFC822Name |
                  | dNSName    | snmpTlstmCertSANDNSName    |
                  | iPAddress  | snmpTlstmCertSANIpAddress  |
                  |------------+------------------------|

                  The first matching subjectAltName value found in the
                  certificate of the above types MUST be used when

Does the table prescribe the order in which various subjectAltName types are checked?

                  deriving the tmSecurityName."
    ::= { snmpTlstmCertToTSNMIdentities 5 }

3) In Section 7:

snmpTlstmCertToTSNMapType OBJECT-TYPE
    SYNTAX      AutonomousType
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Specifies the mapping type for deriving a tmSecurityName from
        a certificate.

I couldn't find where allowed values for this are defined. Can you please help me find it?

4) In Section 7:

SnmpTLSAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1a"
    STATUS      current
    DESCRIPTION
        "Represents a IPv4 address, an IPv6 address or an US-ASCII
        encoded hostname and port number.

        An IPv4 address must be in dotted decimal format followed by a
        colon ':' (US-ASCII character 0x3A) and a decimal port number
        in US-ASCII.

        An IPv6 address must be a colon separated format, surrounded
        by square brackets ('[', US-ASCII character 0x5B, and ']',
        US-ASCII character 0x5D), followed by a colon ':' (US-ASCII
        character 0x3A) and a decimal port number in US-ASCII.

This is missing a reference to a document defining the exact IPv6 format.

5).
  [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

DISCUSS DISCUSS:
I think this reference is Normative, as it is a recommended procedure (SHOULD level requirement) for allowing the client to tell the server which hostname it is connecting to.

[Ballot comment]
In Section 3.1.2, the last sentence of the last paragraph:

  Implementations should offer

s/should/SHOULD ?

  configuration settings for mapping algorithms to SNMPv3 security
  levels.


3.1.3.  (D)TLS Connections

  As an implementation hint: note
  that the (D)TLS internal SessionID does not meet these requirements,
  since it can change over the life of the connection as seen by the
  TLSTM (for example, during renegotiation), and does not necessarily
  uniquely idenfify a TLSTM session (there can be multiple TLSTM

typo: identify

  sessions sharing the same D(TLS) internal SessionID).

In Section 7:

snmpTlstmCertToTSNRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The status of this conceptual row.  This object may be used
        to create or remove rows from this table.

        To create a row in this table, an administrator must set this
        object to either createAndGo(4) or createAndWait(5).

        Until instances of all corresponding columns are appropriately
        configured, the value of the corresponding instance of the
        snmpTlstmParamsRowStatus column is 'notReady'.

Is 'notReady' correspond to an actual value of this field?
(Similar question regarding 'notReady' value in snmpTlstmParamsRowStatus
and snmpTlstmAddrRowStatus.)

Also in Section 7:

snmpTlstmServerInvalidCertificate NOTIFICATION-TYPE
    OBJECTS { snmpTlstmAddrServerFingerprint,
              snmpTlstmSessionInvalidServerCertificates}
    STATUS  current
    DESCRIPTION
        "Notification that the server certificate presented by an SNMP
        over (D)TLS server could not be validated even if the
        fingerprint or expected validation path was known.  I.E., a
        cryptographic validation occurred during certificate

Is the word "error" missing after the word "validation"?

        validation processing.

8.1.  Sessions

  Whenever possible, implementations
  SHOULD provide graceful session termination through the use of
  disconnect messages.

Did you mean TLS disconnect messages here?

[Ballot discuss]
I agree that this document is important, however there is a list of issues I would like to discuss before recommending approval of this document:

In Section 7:

snmpTlstmParamsClientFingerprint OBJECT-TYPE
    SYNTAX      Fingerprint
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "A cryptographic hash of a X.509 certificate.  This object
        should store the hash of a locally held X.509 certificate that
        should be used (along with the corresponding private key) when

DISCUSS: how is the private key stored?

        initiating a (D)TLS connection as a (D)TLS client."
    ::= { snmpTlstmParamsEntry 1 }


Also in Section 7:

snmpTlstmCertSANAny OBJECT-IDENTITY
    STATUS        current
    DESCRIPTION  "Maps any of the following fields using the
                  corresponding mapping algorithms:

                  |------------+------------------------|
                  | Type      | Algorithm              |
                  |------------+------------------------|
                  | rfc822Name | snmpTlstmCertSANRFC822Name |
                  | dNSName    | snmpTlstmCertSANDNSName    |
                  | iPAddress  | snmpTlstmCertSANIpAddress  |
                  |------------+------------------------|

                  The first matching subjectAltName value found in the
                  certificate of the above types MUST be used when

Does the table prescribe the order in which various subjectAltName types are checked?

                  deriving the tmSecurityName."
    ::= { snmpTlstmCertToTSNMIdentities 5 }

[Ballot comment]
In Section 3.1.2, the last sentence of the last paragraph:

  Implementations should offer

s/should/SHOULD ?

  configuration settings for mapping algorithms to SNMPv3 security
  levels.


3.1.3.  (D)TLS Connections

  As an implementation hint: note
  that the (D)TLS internal SessionID does not meet these requirements,
  since it can change over the life of the connection as seen by the
  TLSTM (for example, during renegotiation), and does not necessarily
  uniquely idenfify a TLSTM session (there can be multiple TLSTM

typo: identify

  sessions sharing the same D(TLS) internal SessionID).

In Section 7:

snmpTlstmCertToTSNRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The status of this conceptual row.  This object may be used
        to create or remove rows from this table.

        To create a row in this table, an administrator must set this
        object to either createAndGo(4) or createAndWait(5).

        Until instances of all corresponding columns are appropriately
        configured, the value of the corresponding instance of the
        snmpTlstmParamsRowStatus column is 'notReady'.

Is 'notReady' correspond to an actual value of this field?
(Similar question regarding 'notReady' value in snmpTlstmParamsRowStatus
and snmpTlstmAddrRowStatus.)

Also in Section 7:

snmpTlstmServerInvalidCertificate NOTIFICATION-TYPE
    OBJECTS { snmpTlstmAddrServerFingerprint,
              snmpTlstmSessionInvalidServerCertificates}
    STATUS  current
    DESCRIPTION
        "Notification that the server certificate presented by an SNMP
        over (D)TLS server could not be validated even if the
        fingerprint or expected validation path was known.  I.E., a
        cryptographic validation occurred during certificate

Is the word "error" missing after the word "validation"?

        validation processing.

8.1.  Sessions

  Whenever possible, implementations
  SHOULD provide graceful session termination through the use of
  disconnect messages.

Did you mean TLS disconnect messages here?

[Ballot discuss]
I agree that this document is important, however there is a list of issues I would like to discuss before recommending approval of this document:

In Section 7:

snmpTlstmParamsClientFingerprint OBJECT-TYPE
    SYNTAX      Fingerprint
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "A cryptographic hash of a X.509 certificate.  This object
        should store the hash of a locally held X.509 certificate that
        should be used (along with the corresponding private key) when

DISCUSS: how is the private key stored?

        initiating a (D)TLS connection as a (D)TLS client."
    ::= { snmpTlstmParamsEntry 1 }

[Ballot comment]
1. For consistency purposes (as TLS is expanded) expand SNMP in the title.

2. In a couple of places (section 1, section 9.1) I encountered the term 'notification responder' while in all other places 'notification receiver' is used. The terms are not exactly synonims, is the inconsistency intentional?

3. In Section 3.3

  When configuring a (D)TLS target, the snmpTargetAddrTDomain and
  snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be
  set to the snmpTLSTCPDomain or snmpDTLSUDPDomain object and an
  appropriate snmpTLSAddress value.  When used with the SNMPv3 message
  processing model, the snmpTargetParamsMPModel column of the
  snmpTargetParamsTable should be set to a value of 3.  The
  snmpTargetParamsSecurityName should be set to an appropriate
  securityName value and the snmpTlstmParamsClientFingerprint parameter
  of the snmpTlstmParamsTable should be set a value that refers to a
  locally held certificate (and the corresponding private key) to be
  used.

All 'should' seem to need to be capitalized.

4. In Section 4.1

  Enterprise configurations are encouraged to map a "subjectAltName"
  component of the X.509 certificate to the TLSTM specific
  tmSecurityName.

I do not think that we have a clear notion of what an 'enterprise configuration' is and why it would be more appropriate for such a mapping. It looks like a (non-capitalized) may is more appropriate here.

5. In Section 5.2 5b) s/If there is not a corresponding LCD entry/If there is no corresponding LCD entry/

6. In Section 5.4.4

4)  Have (D)TLS close the specified connection.  This SHOULD include
      sending a close_notify TLS Alert to inform the other side that
      session cleanup may be performed.

Unless I miss something sending the close_notify TLS Alert is always part of the closing sequence, so s/SHOULD/MUST/

7. Some of the references in the MIB module are not included as Informative References - for example RFC 1033, RFC 3490

[Ballot discuss]
This is a very important and well written document, and before baloting a YES vote I would like to clarify a few issues:

1. There are a number of objects in the MIB module with a SYNTAX of Counter32, but there is no indication of the behavior at discontinuity, or reference to a discontinuity indicator.

2. I could not make sense what section 9.2 tries to say. Is there a warning, describing a threat, a recommendation to not use the model with older versions of SNMP?

3. I know that the paragraph starting with 'Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED.' is part of the security boilerplate for all MIB documents. I am wondering if this is not exactly the place to add text which in a stronger language warns that configuring with a lower version of SNMP the TLS transport model for SNMP is something not to do.

[Ballot comment]
section 1: s/standard defined/specification/

section 3: ist paragraph, second sentence - I had trouble parsing this. You seem to have a message passing between three things, but really you should only have two. I think you should drop "and the Transport Subsystem"

3.1.2 last sentence, s/should/SHOULD/

4.1.0 s/are are/are/

4.3.1 s/Outgoing message field/Outgoing message/
4.3.2 s/Incoming message field/Incoming message/

4.3.1 tmState (first usage - a reference?)

4.3.2 incomingMessage: I found this sentence hard to parse. I could benefit from rewriting.

4.4.1.1 s/through an TLSTM session/through a single TSLTM session/

SnmpTLSAddress - references rfc3986 and 5246 are never used in the description; I'm not sure why they are needed in the REFERENCE clause.

snmpTlstmCertToTSNTable - instead of an example of non-consecutive indices, I recommend advice recommending non-consecutive indices in case an admin wants insert an entry; using non-consecutive indices means they can insert a new entry into the gap between entries and won't need to renumber all following entries.

11. s/defined by David Harrington/documented by David Harrington/

A.1 I have a recomendation for much more succinct text in the examples. I'll send that COMMENT separately and send a copy to IESG.

[Ballot discuss]
3.1.1, 4. Per RFC3365 (BCP61),
  However security must be a MUST IMPLEMENT so that end users will have
  the option of enabling it when the situation calls for it.
OLD:
"A TLS Transport Model implementation SHOULD support message encryption to protect sensitive data from eavesdropping attacks."
NEW:
"A TLS Transport Model implementation MUST support message encryption to allow users to protect sensitive data from eavesdropping attacks."

4.1.1 "Enterprise configurations are encouraged" - why enterprises specifically? This purpose of this text is to encourage the use of subjectAltName in preference to other alterantives, right? Could this be strengthened to a SHOULD or RECOMMENDED to promote a common interoperable configuration?

4.4.1.1 3rd para., "the tmSecurityName is presented to the TLS Transport Model by the application" is inaccurate; securityName (possibly from snmpTargetParamsSecurityname) is presented by the application to the Security Model, which transforms the securityName into a tmSecurityname. An application should have no access to tmState.

I am a bit uneasy with the wording that says "The securityName MAY be derived ... and MAY be used ..." This looks like it is making the behavior optional. I recommend "Transport-model-aware security models derive tmSecurityName from a securityName, possibly configured in MIB modules for notifications and access controls. Transport models SHOULD use predictable tmSecurityNames ..."; I debated whether this should be a comment or a DISCUSS, but decided on DISCUSS because I think it is important to make clear the "MAY" behavior is well-specified in models designed for interoperability.

5.1.1 "If demultiplexing ..." Should this be strengthened?  "MUST implement if DTLS implementation does not provide. If the implementation is, say, a toolkit, and it is unknown whether the DTLS implementation it will be used with does provide demultiplexing, then it is MUST implement, but the demultiplexing function in the implementation SHOULD be able to be bypassed by a subsequent implementer if the DTLS provides demultiplexing."

5.2 4) "an implementation SHOULD ... an implementation MAY return a snmpTlstmSessionNoSessions" - when is it appropriate to not follow the SHOULD? Why do we need the extra complexity of this option? Why not just
make it a MUST so all implementatioins behave in the same way?

5.4 4) Why SHOULD instead of MUST? What circumstances make this acceptable? Why not make the behavior consistent across implementations with a MUST?

6. The MIB is included in the document to make it SNMP-manageable, but then there are places, like 6.3, that say "can be used"; Is the MIB mandatory-to-implement for compliance? It doesn't seem to say that explicitly. I recommend tightening the text that says things like implementers "can".

SnmpTLSAddress - "This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used it MAY be used either on its own or ..." I'm a MIB Doctor and I don't understand what this is talking about. I could not provide advice to an implementer or future MIB writer interpreting this text. I don't understand why a textual convention that restricts the format SHOULD NOT be used - isn't that the purpose of a TC - to refine the semantics and/or the format? And if it is SHOULD NOT, why do we follow that with a MAY that really doesn't discuss the circumstances when ignoring the SHOULD NOT is appropriate.

Fingerprint - should this be SnmpTLSFingerprint, to be consistent with RFC4181 naming conventions?

SnmpTlstmCertSANDNSName - will the requirement to use lowercase be problematic re: newPrep?

SnmpTlstmCertSANiPAddress - the IPv6 support for this object and the TSM prefix feature are impossible to use together in combination with the mandatory-to-implement VACM. Yet no recommendation is made about which is the feature to be preferred, or how to make such a decision. If I remember correctly, the enable/disable for the TSM prefix feature would apply to ALL transport models, not just TLSTM. I think there should be text, probably in the Security Considerations or Operations Considerations that discuss the implications and tradeoffs for SNMP security if the ipAddress field is used in an IPv6 environment, or the prefix feature is disabled to permit IPv6 ipAddress field authentication, and what to watch for in terms of VACM errors if both ipAddress authentication and TSM prefixing are enabled.

snmpTlstmCertToTSNTable - "... then additional rows MUST be searched ..." I think SecCons should discuss whether this could be used by DoS attacks.
snmpTlstmCertToTSNTable and snmpTlstmCertToTSNMapType - It is unclear what the next steps are if a) an entry is found that violates the VACM length requirement, and b) no other matching entry is found.

snmpTlstmCertToTSNTable - the example text in the paragraph "Missing values ..." is unclear and ambiguous. "may legally contain only two rows" makes it seem that the table MUST have two and only two rows. Persoanlly, I don't think readers need an example with two non-consecutive indices; that's normal SNMP.

snmpTlstmCertToTSNTable - Commonname field is deprecated. Should we be writing support for it into new standards?

snmpTlstmCertToTSNData - what is this? there is no description here of what this fields contains other than "auxiliary data" - so is this an OPAQUE value? SMIv2 deliberately obsoletes the OPAQUE data type because it fostered non-interoperable implementaitons; why are we defining opaque fields here? If a vendor wants an opaque, proprietary field that is MIB-accessible, let them put it into a vendor MIB extension. We don't need it specified (opaquely) in the standard. If there is real justification for standardization, then at least provide an example of what it is and how it will be used. And please include why the value is not necessary for some rows, but it MUST be set before modifying the RowStatus, and is in a mandatory-to-implement OBJECT-GROUP? I think MUST be ignored should be strengthened to MUST NOT be used except for a  standardized purpose (to prevent implementers from deicindg to use it for something totally different that could cause interoperability problems later). This object is just way underspecified as to its purpose.

8.1 "Implementations SHOULD limit the lifetime ..." Can you provide a reasonable default lifetime?

8.3 I found this difficult to understand. The "default contextEngineID" is a self-identifying value that matches snmpEngineID from the SNMP-FRAMEWORK-MIB(?). The securityEngineID that you mention is the engineID for a remote target. I don't think there is a default value for a remote target. RFC3411 says that the value of a remote engineID is determined in an implementation-dependent manner. Since RFC5434 updates the SNMP architecture defined in RFC3411, I think it would be appropriate to RECOMMEND (much more strongly than the current text) using RFC5343 to perform snmpEngineID discovery that is independent of the messaging, security, and transport models. I strongly recommend using the much-clearer text from the abstract of RFC5343:

  The Simple Network Management Protocol (SNMP) version three (SNMPv3)
  requires that an application know the identifier (snmpEngineID) of
  the remote SNMP protocol engine in order to retrieve or manipulate
  objects maintained on the remote SNMP entity.

  [RFC5343] introduces a well-known localEngineID and a discovery
  mechanism that can be used to learn the snmpEngineID of a remote SNMP
  protocol engine.  The proposed mechanism is independent of the
  features provided by SNMP security models and may also be used by
  other protocol interfaces providing access to managed objects.

I would add:
Implementations SHOULD provide RFC5343 support for engineID discovery.

9.2 I think this section does not describe the implications of using TLSTM with an SNMPv1/v2c message, or specifying USM as the securityModel in an SNMPv3 message sent over (D)TLS. This section should state clearly that:
  Using a non-transport-aware Security Model with a secure Transport
  Model is NOT RECOMMENDED .
and there should be a reference to RFC5590 section 7.1 which describes the reasons in detail.

10 IANA Considerations:
(I hate the fact we called the standard SNMPv3, but only one model within the SNMPv3 standard actually is version 3 - the SNMP message version 3; it makes things confusing).
RFC3411 defines a modular approach where one model should not place dependencies on another model, or work only with another specific model.
SNMPv3 is a messaging model, and TLSTM should be able to work with any messaging model.
The SNMPv3 prefix in the IANA request should be just SNMP, to allow TLSTM to be used with other messaging models, such as a future SNMP messaging model version 4:
s/SNMPv3-TLS/SNMP-TLS/, s/SNMPv3-DTLS/SNMP-DTLS/, etc.

IANA comments:

Action #1:

Upon approval of this document, IANA will assign the following mib-2
number at
http://www.iana.org/assignments/smi-numbers

Decimal Name Description References
------- ---- ----------- ----------
xxxx tlstm The TLS Transport [RFC-isms-dtls-tm-09]


Action #2:

Upon approval of this document, IANA will make the following
assignments in "iso.org.dod.internet.snmpv2.snmpDomains (1.3.6.1.6.1)" at
http://www.iana.org/assignments/smi-numbers

Decimal Name Description Reference
------- ----------------- ----------------------------- ---------
xx snmpTLSTCPDomain SNMP over TLS via TCP [RFC-isms-dtls-tm-09]
yy snmpTLSDUDPDomain SNMP over TLS via TCP [RFC-isms-dtls-tm-09]


Action #3

Upon approval of this document, IANA will make the following
assignments in the "SNMP Transport Domains" registry at
http://www.iana.org/assignments/snmp-number-spaces

Prefix snmpDomains Reference
------- ----------------------------- ---------
tls snmpTLSTCPDomain [RFC-isms-dtls-tm-09]
dudp snmpDTLSUDPDomain [RFC-isms-dtls-tm-09]


Action #4:

Upon approval of this document, IANA will assign the following
registered port numbers at
http://www.iana.org/assignments/port-numbers

Keyword Decimal Description References
------- ------- ----------- ----------
smtptls TBD1/tcp SNMPv3-TLS [RFC-isms-dtls-tm-09]
TBD1/udp SNMPv3-TLS [RFC-isms-dtls-tm-09]
smtpltls-trap TBD2/tcp SNMPv3-Trap-TLS [RFC-isms-dtls-tm-09]
TBD2/udp SNMPv3-Trap-TLS [RFC-isms-dtls-tm-09]

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Juergen Schoenwaelder is the document shepherd. I have reviewed the
document several times including thef latest version and I believe it
is ready for forwarding it to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has received WG last call reviews from

- Andrew Donati
- Pasi Eronen
- Juergen Schoenwaelder
- Hamid Mukhtar
- Alan Luchuk
- Joe Salowey
- David Harrington
- Tom Petch
- Robert Story

and I do not have any concerns regarding the level of review for this
document.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

The document might benefit from a review of the TLS certificate
handling procedures by some TLS expert; perhaps this can be dealt with
as part of the security directorate review. Note that there are TLS
transport mapping documents for other management protocol produced by
other working groups (NETCONF over TLS [RFC 5539], SYSLOG over TLS
[RFC5425], SYSLOG over DTLS [draft-ietf-syslog-dtls-01.txt]); while
the authors/editors of these documents were aware of the other
documents and tried to align things, an independent review of
consistency of operations between these protocols might be useful.
Sections 5.1, 5.1.1, 5.1.2 should be reviewed by the transport area
directors (or the transport directorate) to ensure the multiplexing
language is correct.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I do not have any specific concerns.
No IPR disclosure been filed as far as we know.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The document has WG consensus and the WG wants the document to be
published as a Proposed Standard.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No-one has threatened with an appeal or expressed extreme discontent.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The document has been checked with idnits 2.12.00 and the warnings
generated are all intentional or bugs in the tool. The document
contains a MIB module and should go through the MIB doctor review
processs.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References are split in Normative and Informative. All normative
documents have been published.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The document requests a number of assignment in existing registries.
It does not create any new registries. I believe the IANA instructions
are clear.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The MIB module has been checked using smilint for syntactic
correctness.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This document describes a Transport Model for the Simple
Network Management Protocol (SNMP), that uses either the
Transport Layer Security protocol or the Datagram Transport
Layer Security (DTLS) protocol. The TLS and DTLS protocols
provide authentication and privacy services for SNMP
applications. This document describes how the TLS Transport
Model (TLSTM) implements the needed features of a SNMP
Transport Subsystem to make this protection possible in an
interoperable way.

Working Group Summary

The working group went over several revisions of this document
and the document and all WG last call comments have been
resolved. There has been strong WG consensus to publish this
document as Proposed Standard.

Document Quality
There are two known implementations in progress of the
(D)TLS Transport Model.