Subject: [Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm

From: Wes Hardaker <[email-masked]>
Date: Wed, 05 May 2010 13:34:37 -0700

Enclosed is a very long document describing in detail exactly where all
the outstanding items are (in my view) with respect to the IESG member
comment and discuss topics.

I've updated my marking list a bit to reflect who's got the current ball
on a given topic.  Responses from each person involved in the discussion
are prefixed with their name.

Outstanding marks I'm waiting actively to hear back on:

  DISCUSS: The state is still considered in "discussion" (regardless of
            whether it's an IESG DISCUSS or COMMENT)

Marks that I consider "will assume closed at some point if they don't
respond with additional problems based on the proposed resolution.

  DONE:     The suggestion/issue was acted on and the changes are described
  WONTDO:   Nothing was done; refer to the WH: response for reasons why
            I'm proposing nothing be done.
  ANSWERED: A question was answered but had no action resulting from it.

Marks that indicate formal closure because the commenting party has
indicated all is well for the given topic:

  CLOSED:   Affirmation has been received that the results are good.
            (in some cases when a direct suggestion was followed
            verbatim this mark was applied as a response really isn't needed)

Most of the CLOSED/DONE changes have been already placed in the updated
-11 document, though there are a few changes locally that were done
after -11 was published yesterday.

                   IESG DISCUSS and COMMENT Review
                   ===============================

Date: 2010-05-05 13:23:35 PDT

Table of Contents
=================
1 David Harrington <[email-masked]> DISCUSS and COMMENTS 
    1.1 Discuss Items 
        1.1.1 3.1.1, 4. Per RFC3365 (BCP61), 
        1.1.2 4.1.1 "Enterprise configurations are encouraged" 
        1.1.3 4.4.1.1 3rd para., "the tmSecurityName is presented to the 
        1.1.4 5.1.1 "If demultiplexing ..." Should this be strengthened? 
        1.1.5 5.2 4) "an implementation SHOULD ... an implementation MAY 
        1.1.6 5.4 4) Why SHOULD instead of MUST? What circumstances make 
        1.1.7 6. The MIB is included in the document to make it 
        1.1.8 MIB related issues 
        1.1.9 SnmpTLSAddress - "This textual convention SHOULD NOT be used 
        1.1.10 Fingerprint - should this be SnmpTLSFingerprint, to be 
        1.1.11 SnmpTlstmCertSANDNSName - will the requirement to use 
        1.1.12 SnmpTlstmCertSANiPAddress - the IPv6 support for this 
        1.1.13 snmpTlstmCertToTSNTable - "... then additional rows MUST 
        1.1.14 snmpTlstmCertToTSNTable and snmpTlstmCertToTSNMapType - It 
        1.1.15 snmpTlstmCertToTSNTable - the example text in the paragraph 
        1.1.16 snmpTlstmCertToTSNTable - Commonname field is 
        1.1.17 snmpTlstmCertToTSNData - what is this? there is no 
        1.1.18 8.1 "Implementations SHOULD limit the lifetime ..." Can you 
        1.1.19 8.3 I found this difficult to understand. The "default 
        1.1.20 9.2 I think this section does not describe the implications 
        1.1.21 10 IANA Considerations: 
    1.2 Comments: 
        1.2.1 section 1: s/standard defined/specification/ 
        1.2.2 section 3: ist paragraph, second sentence - I had trouble 
        1.2.3 3.1.2 last sentence, s/should/SHOULD/ 
        1.2.4 4.1.0 s/are are/are/ 
        1.2.5 4.3.1 s/Outgoing message field/Outgoing message/ 
        1.2.6 4.3.2 s/Incoming message field/Incoming message/ 
        1.2.7 4.3.1 tmState (first usage - a reference?) 
        1.2.8 4.3.2 incomingMessage: I found this sentence hard to 
        1.2.9 4.4.1.1 s/through an TLSTM session/through a single TSLTM 
        1.2.10 SnmpTLSAddress - references rfc3986 and 5246 are never 
        1.2.11 snmpTlstmCertToTSNTable - instead of an example of 
        1.2.12 11. s/defined by David Harrington/documented by David Harrington/ 
        1.2.13 The Appendix is too verbose 
2 Dan Romascanu <[email-masked]> DISCUSS from IESG 
    2.1 Discuss Items: 
        2.1.1 1. There are a number of objects in the MIB module with a 
        2.1.2 2. I could not make sense what section 9.2 tries to 
        2.1.3 3. I know that the paragraph starting with 'Further, 
    2.2 Comments: 
        2.2.1 1. For consistency purposes (as TLS is expanded) expand 
        2.2.2 2. In a couple of places (section 1, section 9.1) I 
        2.2.3 3. In Section 3.3 
        2.2.4 4. In Section 4.1 
        2.2.5 5. In Section 5.2 5b) s/If there is not a corresponding 
        2.2.6 6. In Section 5.4.4 
        2.2.7 7. Some of the references in the MIB module are not 
3 Alexey Melnikov <[email-masked]>: 
    3.1 Discuss: 
        3.1.1 1) In Section 7: 
        3.1.2 2) In Section 7: 
        3.1.3 3) In Section 7: 
        3.1.4 4) In Section 7: 
        3.1.5 5). 
    3.2 Comment: 
        3.2.1 In Section 3.1.2, the last sentence of the last paragraph: 
        3.2.2 3.1.3.  (D)TLS Connections 
        3.2.3 In Section 5.1.1: 
        3.2.4 In Section 7: 
        3.2.5 Also in Section 7: 
        3.2.6 8.1.  Sessions 
4 Peter Saint-Andre <[email-masked]> 
    4.1 Discuss: 
        4.1.1 The definition of snmpTlstmCertSANIpAddress mentions that 
        4.1.2 The definition of SnmpTLSAddress states that 
    4.2 Comment: 
        4.2.1 Section 1.1 has: 
        4.2.2 I realize that RFC 3411 talks about "privacy", but the 
        4.2.3 Forgive my ignorance regarding SNMP/SMI, but I can't seem 
        4.2.4 The definition of snmpTlstmCertSANDNSName mentions 
        4.2.5 Is there any provision for supporting subjectAltName 
        4.2.6 Is there a preferred order of matching subjectAltName 
        4.2.7 How exactly does an entity prepare for matching of 
        4.2.8 It might be appropriate for this specification to say 
5 Tim Polk <[email-masked]> 
    5.1 RFC 5590 states: 
    5.2 The document requires use of TLS, and mandates 

1 David Harrington <[email-masked]> DISCUSS and COMMENTS 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1.1 Discuss Items 
=======================

1.1.1 CLOSED 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."

        + WH: I'm actually fine with this, and someone else had a
          similar comment.  But the original USM had a goal of not
          requiring encryption and thus I tried to carry that forward.
          I'll change it to a "MUST support" but I'll note that you
          referenced RFC3365, but actually RFC3365 specifically says you
          don't need to necessarily require encryption if it's not
          needed and I can envision SNMP implementations that don't need
          encryption for the data the CR or NG may be distributing.
          I.E., SNMP certainly can carry sensitive information that
          should not be disclosed, but I don't know that we require all
          usages of the protocol to carry such information.  Certainly
          most probably do, however.

        + WH: Never heard directly back, but since I took his text I'm
          assuming this is resolved.

1.1.2 DONE 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?

        + WH: Enterprise wasn't the right word, you're right.  I've
          changed the text to:

              Deployments SHOULD map the "subjectAltName" component of
              X.509 certificates to the TLSTM specific tmSecurityNames.

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

        + WH: All of the above text is functionally a copy with slight
          modifications (SSH -> TLS) from section 4.1.1 of RFC5592,
          which you authored.  I find it amusing that you're marking the
          text you wrote in 5592 as a DISCUSS!

          More seriously, I think cleaning up the text is fine.  In
          general I tried to copy text from 5592 for consistency between
          the documents.

          How about this (your text was used for the second paragraph):

              <t>
                On the (D)TLS client side of a connection the
                tmSecurityName is presented to the TLS Transport Model
                by the Security Model.  The Security Model likely
                derived the tmSecurityName from the securityName
                presented to the Security Model by the application
                (possibly because of configuration specified in the
                SNMP-TARGET-MIB).
              </t>
              
              <t>
                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
                so operators will know what to use when configuring MIB
                modules that use securityNames derived from
                tmSecurityNames.  The TLSTM generates predictable
                tmSecurityNames based on the configuration found in the
                SNMP-TLS-TM-MIB's snmpTlstmCertToTSNTable and relies on
                the network operators to have configured this table
                appropriately.
              </t>

1.1.4 WONTDO 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."

        + WH: I don't think that it's appropriate for us to dive into
          the various different ways that a SNMP implementation may need
          to get involved with a TLS implementation.  I think that's way
          too deep to be recommending things.  All we should be saying
          is that if you're going the route of doing it in the SNMP
          stack, use these steps.  I don't think it's appropriate for us
          to dictate how they make the decision about where to put the
          demultiplexing as it may depend on many stack issues that we
          can't possibly enumerate or predict.

1.1.5 ANSWERED 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?

        + WH: I believe there may be implementations where internally to
          that particular point in the code it may not be possible to
          open a new transport connection.  Specifically, I'm not
          positive it's safe to assume that a connection can be opened
          that can modify or access connection parameters that may be
          stored in a data structure higher up in the calling stack that
          isn't accessible in the lower-level code that is actually
          trying to send out an outgoing packet.

          I know in Net-SNMP this actually looked like it might be a
          problem, in fact, given the currently defined (and published
          and thus non-modifiable) API.  We've actually worked around it
          but I'm not sure every stack could.  It all depends on how the
          API works between the various levels of stack.  It becomes
          rather implementation dependent as to whether you can open a
          new connection when you've noticed that an existing one is no
          longer usable.

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

        + WH: I was worried there would be cases where it wouldn't be
          possible.  But since I can't think any, I'll assume that there
          aren't any.  I've changed it to a MUST.  Turns out RFC5246
          actually indicates a MUST as well.

1.1.7 DONE 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".

        + WH: The "can" was meant to indicate that a management station
          "can" use them, but you're right the wording isn't clear in
          that regard.  I've reworded to:

            The SNMP-TLS-TM-MIB defines counters that provide network
            management stations with information about session usage and
            potential errors that a MIB-instrumented device may be
            experiencing.

1.1.8 TODO MIB related issues 
------------------------------

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

        + WH: That's another example of text that comes directly from
          the text you wrote in RFC5592 with no modifications at all.

          Looking further, though, I find that you copied it directly
          from the objects in the TRANSPORT-ADDRESS-MIB.

          I believe the goal of the wording was to say that the address
          TCs should not be used directly in a MIB but instead a pair of
          generic TDomain and the generic TAddress objects should be
          used instead.

          IE, don't do this:

             snmpFooBarAddress  OBJECT-TYPE
                 SYNTAX         SnmpTLSAddress

          but instead do:

             snmpFooBarDomain   OBJECT-TYPE
                 SYNTAX         TDomain

             snmpFooBarAddress  OBJECT-TYPE
                 SYNTAX               TAddress

          So...  I'm not sure what to do with this.  I'm going to mark
          it as WONTDO unless you come up with text you'd like to
          replace it with.  Sound good?

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

        + WH: The object was originally designed to be used
          generically but was then later TLSized but the name was
          never made specific again.  Changed.

        + WH: Never heard directly back, but since I took his text I'm
          assuming this is resolved.

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

        + WH: the subjectAltName dNSName is defined to be case-insensitive
          so you must compare it in a case insensitive way thus we
          need to deal with it on the mapping side to ensure that no
          matter what case mix is put into the certificate value it
          maps to the same securityName

        + Alexey Melnikov <[email-masked]>:
          Hi David,
          I am agreeing with many of the points you raised in your DISCUSS, but
          I would like to comment on one which I think it incorrect:

          David Harrington wrote:

          >SnmpTlstmCertSANDNSName - will the requirement to use lowercase be problematic re: newPrep?
          >
          >
          The document defines snmpTlstmCertSANDNSName as:

          snmpTlstmCertSANDNSName OBJECT-IDENTITY
             STATUS        current
             DESCRIPTION  "Maps a subjectAltName's dNSName to a
                           tmSecurityName after first converting it to all
                           lower case."
             ::= { snmpTlstmCertToTSNMIdentities 3 }

          Due to character restriction on subjectAltName's dNSName, it can't
          contain Internationalized (non-US-ASCII) domains. So this is not an
          issue.

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

        + WH: How about something like the following new section in
          the operational considerations:

          8.5.  IPv6 and securityName mapping when used with TSM and VACM

             It is possible to create a condition where it is
             impossible to map a subjectAltName to a securityName when
             all of the following conditions are true:

             o  The snmpTlstmCertToTSNMapType object of a
                snmpTlstmCertToTSNEntry is set to the
                snmpTlstmCertSANIpAddress identity value.

             o  The X.509 certificate presented by the client contains a
                subjectAltName with an IPv6 address in it.

             o  The security model in use is the Transport Security Model.

             o  The snmpTsmConfigurationUsePrefix object in the SNMP-TSM-MIB is
                set to 'true'.

             o  The View-based Access Control Model is being used to authorize
                requests.

             If all of these conditions are true then the length of
             the generated tmSecurityName will always be 32 octet
             characters and the securityName generated by the TSM will
             be at least 36, which is longer than the length allowed
             by the VACM.

             Thus, the use of IPv6 subjectAltName to tmSecurityName
             mapping is NOT RECOMMENDED when
             snmpTsmConfigurationUsePrefix is set to true.

         + David H: I recommend something a bit more succinct than
           your proposed section 8.5:

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

           This would satisfy my concerns. (Your original text made it seem like
           the easy solution was to not use VACM.)

           Does this work for you?

         + WH: I think that's fine too and have done as you've
           described.

         + WH: Never heard directly back, but since I took his text I'm
           assuming this is resolved.

1.1.13 DONE snmpTlstmCertToTSNTable - "... then additional rows MUST 
---------------------------------------------------------------------
        be searched ..." I think SecCons [Ed: security considerations]
        should discuss whether this could be used by DoS attacks.

        + WH: I added the following sentence to the security
          consideration section that discusses the
          snmpTlstmCertToTSNTable:

            When this table contains a significant number of rows it
            may affect the system performance when accepting new
            (D)TLS connections.

          Note that I suspect it'd take a lot of rows to check before
          it would surpass the length of time it takes to verify the
          certificate cryptographically.

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

        + WH: I've addressed this with a few changes:

          1. Modification to the "accepting a session" section text so
             the new sentence reads:

               If the session can not be opened for any reason at all,
               including cryptographic verification failures +++and
               snmpTlstmCertToTSNTable lookup failures+++, then the
               snmpTlstmSessionOpenErrors counter is incremented and
               processing stops.

          2. In the snmpTlstmCertToTSNTable text a new paragraph was
             added (after the "once a matching row has been found"
             paragraph):

               If no matching and valid row can be found, the
               connection MUST be closed and SNMP messages MUST NOT be
               accepted over it.

             (the previous paragraph already discusses that VACM
             requirements may dictate that future rows are searched).

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

        + WH: This is a duplicate of your other comment below in your
          "comments" section.  The text was revised based on your
          suggestions below, so I'll refer you to those and if you
          have further issues here that aren't addressed by the other
          changes please let me know.

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

        + WH: Deprecated but still in very very very heavy use.  In
          fact (IMO), it's still the most commonly used form of
          identifying the subject of a certificate.  Yes we hope to
          have subjectAltName's take over most of that role but until
          it does we need to support using those certificates.

1.1.17 DISCUSS 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
        <please provde details> 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.

        + WH: If you re-read the description of the
          "snmpTlstmCertSpecified" object identity you'll find it is
          used elsewhere in the MIB.  It's not a vendor specific
          extension, it's a generic parameter extension mechanism that
          may be needed for certain mapping types.  This object is the
          direct result of a WG discussion that occurred in Sweden
          (I'm pretty sure) and it was decided that this route was
          better than the other alternatives discussed that day.  In
          particular, Jeff H. brought up the details of a
          to-be-standardized-in-the-future otherName mapping that
          would require a parameter as well.

          Does this already-documented mapping
          (snmpTlstmCertSpecified) meet your requirement for an
          example, or did you want an example in the text itself.
          There is also an example in appendix A for using it but the
          interesting thing is that the example text used the old
          object name and no one has caught that to date.  So if
          nothing else, thanks for making me catch that!  I've double
          checked that the rest of the objects in the appendix match
          the current text.

          The object clearly states that the value is used by the
          mapping type specified via the snmpTlstmCertToTSNMapType (be
          a standards based mapping or a enterprise extension).  Given
          that I'm not sure what MUST NOT clause you're wanting to
          insert.  If you have text, please supply it as I can't
          extract it from your problem description.

          It's in the mandatory to implement object group because the
          directly specified securityName mapping was one the working
          group considered to be important and it is needed to fulfill
          that mapping objective.

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

        + WH: generally the security area has shied away from
         recommending lifetimes in fixed documents since it's both
          hardware dependent, cryptographic algorithm dependent and
          timeline-of-the-world dependent.  So the answer is "no".  It's
          likely implementation and/or deployment dependent.

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

        + WH: does the following text work for you?  I'm not sure we
          needed the last line of the above paragraphs so I removed it.

              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.

              <xref target="RFC5343" /> introduces a well-known
              localEngineID and a discovery mechanism that can be used
              to learn the snmpEngineID of a remote SNMP protocol
              engine.  Implementations are RECOMMENDED to support and
              use the contextEngineID discovery mechanism defined in
              <xref target="RFC5343" />.

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

        + WH: again, this is an identical copy (except SSH -> TLS) to
          what you put in RFC5592.  That being said, I've added a new
          paragraph:

            Using a non-transport-aware Security Model with a secure
            Transport Model is NOT RECOMMENDED.  See <xref
            target="RFC5590" /> Section 7.1 for additional details on
            the coexistence of security-aware transports and
            non-transport-aware security models.

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

        + WH: changed.  Note that the table in question was actually
          from IANA originally as they reviewed the document during last
          call.  Because there was some confusion I copied it into the
          document and fixed it so it made the assignments we wanted.
          But I've now also changed it so it doesn't have "v3" in it.

1.2 Comments: 
===================

1.2.1 CLOSED section 1: s/standard defined/specification/ 
----------------------------------------------------------

        + WH: done as suggested.

1.2.2 CLOSED 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"

        + WH: I think your suggestion is the right approach and made
          that change.

1.2.3 CLOSED 3.1.2 last sentence, s/should/SHOULD/ 
---------------------------------------------------

        + WH: done as suggested.

1.2.4 CLOSED 4.1.0 s/are are/are/ 
----------------------------------

        + WH: done as suggested.

1.2.5 CLOSED 4.3.1 s/Outgoing message field/Outgoing message/ 
--------------------------------------------------------------

        + WH: done as suggested.

1.2.6 CLOSED 4.3.2 s/Incoming message field/Incoming message/ 
--------------------------------------------------------------

        + WH: done as suggested.

1.2.7 DONE 4.3.1 tmState (first usage - a reference?) 
------------------------------------------------------

        + WH: I changed the description to:

              <t hangText="tmStateReference:">
                A reference used to pass model-specific and
                mechanism-specific parameters between the Transport
                Subsystem and transport-aware Security Models.
              </t>

        Which came from RFC5590 and is the best text I found for
        describing the generic cache.

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

        + WH: This wording has repeatedly been a problem.  How about
          just removing the "remove the DTLS bits" part of it since
          that's what keeps causing problems.  How about just:

          The whole SNMP message after being processed by (D)TLS.

1.2.9 CLOSED 4.4.1.1 s/through an TLSTM session/through a single TSLTM 
-----------------------------------------------------------------------
        session/

        + WH: done as suggested.

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

        + WH: removed.

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

        + WH: changed to:

          It is recommended that administrators skip index values to
          leave room for insertion the of future rows (E.G., use
          values of 10 and 20 when creating initial rows).

1.2.12 CLOSED 11. s/defined by David Harrington/documented by David Harrington/ 
--------------------------------------------------------------------------------

        + WH: done as suggested.

1.2.13 CLOSED The Appendix is too verbose 
------------------------------------------

        Offline David H and I had discussions about the example
        Appendix A being too long and verbose.  We came to agreement
        about what is in version -11 and beyond, which is functionally
        the same example but with reduced verbiage surrounding it.

2 Dan Romascanu <[email-masked]> DISCUSS from IESG 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2.1 Discuss Items: 
===========================

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

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

        + WH: Last I checked it's fairly common not to require special
          discontinuity checks or objects when there is no reason not
          to use the SNMP standard mechanisms for handling
          discontinuity.  EG, the TARGET-MIB, the sister-MIB
          SNMP-SSH-TM-MIB don't have special objects or special text.
          It's expected that managers will use the sysUpTime.0 scalar
          for detecting discontinuity as there isn't really a special
          need for these having discontinuity issues beyond what
          typical counters have.  Is there a reason you believe this
          MIB and it's counters should be different than other
          published MIBs?

        + Dan: Let us put aside the 'sister-MIB', because the comment
          may apply to it as well. My understanding is that using the
          'standard' sysUpTime.0 mechanism assumes that the process
          that implements the counters is the same as the process that
          counts sysUpTime, or the two are tightly coupled so that all
          events that lead to discontinuities are shared and lead to a
          reboot. While this is obviously true for core SNMP engine
          MIB modules like the TARGET-MIB I wonder and ask loud if
          this is true for the TLS/DTLS transport.

        + JS: Not necessarily a reboot - all that is needed is to reset
          sysUpTime when a discontinuity occurs.

          + DanR: Right.

        + JS: For those code bases I am familiar with, I think the
          answer is very clearly yes. The transport subsystem not only
          architecturally is part of an SNMP engine, also
          implementation wise I have not seen someone inventing a
          protocol between the transport model and the dispatcher in
          order to separate things such that they would have different
          discontinuity properties. For me, the transport models are
          clearly part of the core SNMP engine.

          + DanR: This was exactly the issue I was raising, and the
            question I was asking loud. If no different opinions or
            experiences are shared I would rest my case on this
            matter.

        + WH: I certainly know enough about one major SNMP stack to
          say that the discontinuities would always be the same
          because the transport system is definitely part of the rest
          of the code and can't be 'rebooted' (or otherwise)
          independently.  In fact, the statistics information for the
          transports and the rest of the code base are all kept in the
          same place. For the other major SNMP stack, based on my
          discussions with them but not based on direct code-reading,
          I believe their transport system is also closely tied to the
          rest of their infrastructure.

2.1.2 CLOSED 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?
        
        + WH: This is actually text copied almost verbatim from
          RFC5592, our sister-RFC.  Would adding the following
          sentence to the end of the paragraph make it more clear:

             It is RECOMMENDED that only SNMPv3 messages using the
             Transport Security Model (TSM) or another
             secure-transport aware security model be sent over the
             TLSTM transport.

        + Dan: Yes, thanks.

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

        + WH: I'm not sure I understand your point here.  The text
          already recommends against anything less than SNMPv3 and
          already recommends secure mechanisms.  NOT RECOMMENDED is
          already equal to SHOULD NOT and I don't think it's
          appropriate to switch to a MUST level requirement.  Can you
          provide example text for what you're wishing to say, as I
          believe I may be missing your point?

        + Dan: Why do you think that in this very specific instance
          switching to a MUST level requirement is not appropriate?

        + WH: The text will fundamentally only apply to people
          deploying it.  I certainly don't think it's appropriate to
          put in special access-control checks surrounding particular
          objects to ensure that no one is allowed to modify certain
          objects except with secured SNMPv3.  We (or at least
          I) have heard of many deployment situations where the physically
          protected management network is utilizing SNMPv1 or SNMPv2c
          for the speed benefits it can offer and they don't have a
          security need on their management back-plane.  But they may
          desire to configure our new tables for those cases they need
          their customers to be able to access counters, etc, or want
          to allow themselves access externally over (D)TLS.

          IMHO, it's not the job of the IETF to say "you MUST NOT do
          stupid things in the real world" or even "you MUST NOT use
          any management architecture different than what we envision
          to be best for you".  It's our job to ensure that
          implementations *can* support secured networks in an
          interoperable way.

2.2 Comments: 
===================

2.2.1 CLOSED 1. For consistency purposes (as TLS is expanded) expand 
---------------------------------------------------------------------
        SNMP in the title.

        + WH: Expanded per request for -11

        + Dan: OK

2.2.2 CLOSED 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?

        + WH: receiver is the correct term; changed!

        + Dan: OK.

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

        + WH: I've changed all instances of "should" to "SHOULD" in
          that paragraph.

        + Dan: OK.

2.2.4 CLOSED 4. In Section 4.1 
-------------------------------

        Quoting the draft:

           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.

        + WH: David H. brought up a similar issue.  I've changed the
          text to:

            Deployments SHOULD map the "subjectAltName" component of
            X.509 certificates to the TLSTM specific tmSecurityNames.

          Does this work for you?

        + Dan: Yes.

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

        + WH: thanks; changed!

        + Dan: OK.

2.2.6 CLOSED 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/

        + WH: Yep; David H. mentioned this as well.

        + Dan: OK.

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

        + WH: I've added those two references to the Informative section.

        + Dan: OK.

3 Alexey Melnikov <[email-masked]>: 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

      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:

3.1 Discuss: 
==================

3.1.1 DONE 1) In Section 7: 
----------------------------

        Quoting the draft:

          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
                  initiating a (D)TLS connection as a (D)TLS client."
              ::= { snmpTlstmParamsEntry 1 }

        How is the private key stored?

        + WH: That's implementation dependent as it should be, IMHO.
          I'd expect different implementations to store private keys
          in different ways, as is already done now with X.509
          certificates used in other applications.  Transfer and
          maintenance of the certificate store is out of scope of this
          working group.  (multiple people have indicated interest in
          eventually creating a MIB for generic X.509 management; it's
          just not within the charter of ISMS to accomplish this).

        + Alexey: Ok. The "(along with the corresponding private key)"
          text made me think that the private key is a part of the
          snmpTlstmParamsClientFingerprint. Please reword to make it
          clear that that is not the case.

        + WH: How does this sound?

             "A cryptographic hash of a X.509 certificate.  This
             object should store the hash of the public portion of a
             locally held X.509 certificate that should be used (along
             with the corresponding private key) when initiating a
             (D)TLS connection as a (D)TLS client."

        + Juergen S:  Why not simply this:

             xxx

        + WH: Because previous people were concerned that we needed to
          mention the private key as being in existence locally and
          needed.  That's where the wording "along with the
          corresponding private key" came from.

        + JS: Once you implement things, I think it will become pretty
          obvious in which situations you need to have access to the
          private key.  But anyway, then it might be useful to discuss
          the fact that there is also a private key in a separate
          sentence to avoid confusion that the private key is part of
          the MIB object.

        + Alexey: +1

        + WH: As I mentioned the original text didn't discuss
          public/private keys but some people found this confusing and
          created the existing suggested text as a replacement.
          Because of their opinions were voiced during the WG
          discussions I'm unwilling to ignore their original complaint
          on the text.  Thus I think that we have to discuss the fact
          that the fingerprint is taken only over the public key and
          that the private key is needed to actually perform the
          tasks.  Those two semi-separate issues are in the text as a
          direct result of WG discussions (IE, the text didn't even
          come from me).

          So...  How about the following:

             "This object should store the hash of the public portion of a
              locally held X.509 certificate.  The public key from the
              certificate and the corresponding private key should be
              used when initiating a (D)TLS connection as a (D)TLS
              client."

          Which simplifies the text a bit, gets rid of the redundancy
          that Juergen pointed out and separates the fingerprint
          portion of the text from the usage portion of the text while
          still mentioning how the public/private key split works.

        + WH: I decided that wasn't right either.  How about this:
          
              This object stores the hash of the public portion of a
              locally held X.509 certificate.  The X.509 certificate,
              its public key, and the corresponding private key will
              be used when initiating a (D)TLS connection as a (D)TLS
              client.
          
        + Alexey: This is better. You can also clarify that the
          private key is not accessible over SNMP, if you want.

        + WH: I'll stick with the text as is unless you think it's
          important to include; there are no objects that specify
          private key access so it's implied by the object set.

        + JS: I tend to agree with Wes here. We generally do not list
          what a MIB does not contain.

3.1.2 DISCUSS 2) In Section 7: 
-------------------------------

        Quoting the draft:

           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 }

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

        + WH: No, each "mapping algorithm" can prescribe it's own
          method of searching in order to keep the table generic.
          In fact, the table doesn't (by design) talk about
          subjectAltNames themselves and that's left up to the mapping
          objects that define how to map certificate contents into
          SNMPv3 securityNames.

        + Alexey: I might be missing something. This choice allows
          different implementations to do different things. This
          doesn't seem to encourage interoperability.

        + WH: I'm sorry if I've inadequately explained things.
          Interoperability is definitely assured because all the
          mapping algorithms we're defining in the document have
          deterministic results.

          So, using this example taken straight from the appendix we
          have the following mapping set up:

              snmpTlstmCertToTSNID          = 1
                                              (chosen by ordering preference)
              snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint)
              snmpTlstmCertToTSNMapType     = snmpTlstmCertSANAny
              snmpTlstmCertToTSNData        = ""  (not used)
              snmpTlstmCertToTSNStorageType = 3   (nonVolatile)
              snmpTlstmCertToTSNRowStatus   = 4   (createAndGo)

          This says that if the incoming connection contains a public
          key in the verification tree that matches the HASH then it
          should use the 'snmpTlstmCertSANAny' mapping algorithm
          (which is assigned a unique OID within the MIB tree so it
          can't be confused by another conflicting definition).

          So, looking up the rules for snmpTlstmCertSANAny we find:

              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.

          The last paragraph clearly indicates we take the *first* SAN
          of the above types in order to do the mapping with.  So if
          the certificate in use had 300 different SANs but the first
          was a rfc822Name containing [email-masked] then
          that is the value that every implementation MUST pick in
          order to meet the standard.  There is no ambiguity about
          what happens if you follow all the rules for the
          configuration specified in the MIB.

          The only extensibility is that future standards or
          enterprises can define their own mapping algorithms,
          assigned to their own unique OIDs that can be used in the
          snmpTlstmCertToTSNMapType column.  We're actually expecting
          at some point in the future within the IETF to define a
          standard for mapping (deterministically of course) the
          kerberos principal from an otherName field.  (But since that
          doesn't exist now, it can't be used yet.)

          Make more sense?

        + David Harrington:

          I think the text you quote is not deterministic because it
          says the tmSecurityName is derived, but doesn't specify how
          the derivation is done:

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

          You do not specify a 1:1 identity mapping MUST be
          used. Something derived is usually different than the
          original. So if the subjectAltName was "David Harrington", I
          could derive a tmSecurityName of "David", "Harrington", or
          "David Harrington H73653" and still meet the definition you
          quote. And if this was used in a securityName in a MIB
          module, and read by a remote operator, it would not be
          apparent that agent A's "David" was the same principal as
          agent B's "Harrington".

          And I have to agree that if everybody gets to define their
          own additional algorithms for derivation, even if they are
          registered by OID, that doesn't lend itself to
          interoperability. Is "IETF Review" required for every
          algorithm so the algorithm is at least published publicly?

        + WH: Well, it does.  But if you missed it then more text is
          needed to clarify it further.

          In particular:

              DESCRIPTION  "Maps any of the following fields using the
                            corresponding mapping algorithms:

                              Type         Algorithm                   

          Note that the mapping algorithm is specified in the second
          column, and each of those mapping algorithms are
          deterministic in nature (we worked hard to make sure that
          all case-sensitivity, etc, was dealt with in the
          sub-algorithms).

          If you're concerned about the above not being enforced
          properly then I'll add the following new text (surrounded be
          ***s) to ensure compliance.

              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.  ***The mapping algorithm
                            specified in the 'Algorithm' column MUST be used to
                            derive the tmSecurityName.***"

          Does that appropriately address your concerns with respect
          to the "determinsticness" of the mapping?

        + WH: Regarding everyone defining their own algorithms: this
          is nothing new to the IETF or to SNMPv3.  We already allow
          USM users, standards bodies and developers to define their
          own security algorithms (i.e., auth and priv) via a
          specified OID usable in the usmUserTable.  If you want an
          IETF standardized algorithm, you likely need to publish it
          via IETF process and get an assignment in the MIB tree
          from IANA.  However, if you work at a device-vendor and
          want to create your own then it's sort of up to you to get
          it right.  E.G. Supposedly there is an OID that was
          created to allow interoperable 3DES encryption between
          certain SNMP stacks that supported that
          enterprise-specific assigned encryption
          identifier. Knowing the people that defined how it was
          supposed to work, I'm sure they got it right and
          interoperability problems haven't resulted. However, there
          was nothing stopping them in the USM wording that required
          IETF review for them to publish said OID.  Nor do I think
          there should be.  We also allow enterprise-specific
          security-model identifiers to be defined, but yet we don't
          mandate IETF-review for them to start implementing or
          publishing documentation about them.  How is this
          different?

          The important aspect in my mind is that if two
          implementations implement a mapping algorithm registered
          at an OID and there are no flaws in the language that
          define the OID then will interoperability succeed?  The
          answer is certainly yes.  If the definition or the
          implementation is flawed then interoperability will
          certainly fail, just as it would for USM auth/priv
          algorithms and SNMPv3 security model algorithms.

        + Alexey:

          Sorry, I've missed the text about ordering.

          However there is another more subtle problem with this
          approach. My understanding is that many TLS APIs don't
          necessarily allow to iterate through subjectAltName types in
          the order are specified in the certificate. It is more
          common to have APIs that return SAN of a specific type. So
          this choice really makes it hard for applications to
          implement the mapping.
          
        + WH:

          I'm not sure about all the stacks.  If this is true I
          suppose making the Any algorithm optional is the only way to
          recover.  We're implementing this using OpenSSL and it seems
          to return stuff in order, but I'll double check that
          tomorrow.

          If other popular TLS X.509 manipulation stacks don't allow
          for this we have the choice of:

          1) Deleting the snmpTlstmCertSANAny entirely.
             (I don't favor this one at all)

          2) Making the snmpTlstmCertSANAny optional.
             (My preference)

          3) Requiring everyone to implement it :-) 

        + Alexey:

          I generally feel you have too many choices for extracting identity
          from certificates. I think this is David's point as well.
          And when you add algorithms that combine multiple other choices in a
          certain way, you increase the number of choices.

          But anyway, I think I need to think more about this and we should
          discuss this with the rest of IESG.

        + WH:

          It should be noted that the WG had this exact discussion (in
          Sweden) and the WG members were of the opinion that we
          needed the "Any" option for ease of configuration.  I'm
          reluctant to change the current behavior given these past
          discussions.

          The output is deterministic so there is no issue with
          interoperability unless the APIs can't handle it.

3.1.3 CLOSED 3) In Section 7: 
------------------------------

        Quoting the draft:

          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?

        + WH: In this MIB document the defined values are:

            snmpTlstmCertSpecified
            snmpTlstmCertSANRFC822Name
            snmpTlstmCertSANDNSName
            snmpTlstmCertSANIpAddress
            snmpTlstmCertSANAny
            snmpTlstmCertCommonName

          But AutonomousType is a SNMP-ism for allowing other MIB
          documents to define future mapping algorithms as well as
          long as they're assigned to a unique OID (like those in this
          document are).  E.G. it's already been discussed that
          eventually Kerberos users may wish to have a mapping
          algorithm for extracting kerberos principal names from the
          otherName type.

          To make things more clear about where in the current MIB the
          appropriate values are I've added the following text to the
          object DESCRIPTION clause for the snmpTlstmCertToTSNMapType
          column:

            Suitable values for assigning to this object that are
            defined within the SNMP-TLS-TM-MIB can be found in the
            snmpTlstmCertToTSNMIdentities portion of the MIB tree."

          I believe this will help future readers from needing to ask
          the same question.

        + Alexey: Yes, this will help.

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

        + WH: so is RFC5592 which I copied that text from!  I added a
          reference to RFC3513 to fix this (both in the MIB and in the
          normative references).

        + Alexey: This should be fine, but pointing to
          draft-ietf-6man-text-addr-representation-07.txt would be
          even better (it is in RFC Editor queue now).

        + WH: Ok, I've changed it to the above reference with the
          following note added for the rfc editor:

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

        + Alexey:  Works for me.

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

        + WH: I agree and have moved it to the normative section.

        + WH: Never heard directly back, but since I took his text I'm
          assuming this is resolved.

3.2 Comments: 
==================

3.2.1 CLOSED In Section 3.1.2, the last sentence of the last paragraph: 
------------------------------------------------------------------------

           Implementations should offer configuration settings for
           mapping algorithms to SNMPv3 security levels.

        s/should/SHOULD ?

        + WH: Another IESG member suggested the same thing and I've
          changed it to a SHOULD

        + WH: Never heard directly back, but since I took his text I'm
          assuming this is resolved.

3.2.2 CLOSED 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 sessions sharing the same D(TLS) internal
           SessionID).

        typo: identify

        + WH: thanks, fixed!

        + WH: Never heard directly back, but since I took his text I'm
          assuming this is resolved.

3.2.3 DONE In Section 5.1.1: 
-----------------------------

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

        + WH: I've changed the source text of the initial acronym use
          to read:

            The TLS Transport Model queries the Local
            Configuration Datastore (LCD) (see <xref
            target="RFC3411" /> Section 3.4.2) using the transport
            parameters (source and destination IP addresses and
            ports) to determine if a session already exists.

3.2.4 DONE In Section 7: 
-------------------------

        Quoting the draft:

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

        + WH: It's a standard value for the RowStatus type, so yes it
          corresponds to an actual value.  I've gone ahead and
          modified the text so it reads notReady(3) in all three
          places to make it match the rest of the text style when
          referring to enum values.  Thanks for the suggestion.

3.2.5 CLOSED Also in Section 7: 
--------------------------------

        Quoting the draft:

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

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

        + WH: Yes it is; thanks for catching it.

        + WH: Never heard directly back, but since I took his text I'm
          assuming this is resolved.

3.2.6 CLOSED 8.1.  Sessions 
----------------------------

        Quoting the draft:

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

        Did you mean TLS disconnect messages here?

        + WH: Yep; I added "TLS" per your recommendation

        + WH: Never heard directly back, but since I took his text I'm
          assuming this is resolved.

4 Peter Saint-Andre <[email-masked]> 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

4.1 Discuss: 
====================

4.1.1 CLOSED The definition of snmpTlstmCertSANIpAddress mentions that 
-----------------------------------------------------------------------
        securityName lengths might exceed what VACM can handle;
        doesn't this introduce possible interoperability problems?

        + WH: The end result would need to be the same, based on the
          definition of the VACM processing rules: the message would be
          discarded.  The 32-octet limitation of the VACM is not
          something we can fix within the scope of the ISMS working
          group (though many people would like this problem to go
          away).

          So in the end, no that no interoperability problem exists as
          all implementations MUST do the same thing: discard the
          packet (since no access rule would exist allowing it
          through).  That doesn't mean we're left in a wonderful
          position and the best we can do is warn the operators; hence
          the warning in the MIB.

        + Peter: OK, I see your point: it's not an interoperability
          problem, but those who deploy the technology need to be
          aware of the limitation and plan accordingly.

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

        + WH: I've changed the text to the following to address your
          concerns; please let me know if you believe it needs further
          changes.

            A hostname is always in US-ASCII (as per RFC1033);
            internationalized hostnames are encoded in US-ASCII as
            domain names after transformation via the ToASCII
            operation specified in RFC 3490.  The ToASCII operation
            MUST be performed with the UseSTD3ASCIIRules flag set.
            The hostname is followed by a colon ':' (US-ASCII
            character 0x3A) and a decimal port number in US-ASCII.
            The name SHOULD be fully qualified whenever possible.

        + WH: references for 3490 and 1033 moved to the normative section.

        + WH: The 3986 reference has been removed (in the process of
          responding to other similar comments).

        + Peter: Excellent.

4.2 Comments: 
==================

4.2.1 CLOSED Section 1.1 has: 
------------------------------

        Quoting the draft:

           "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?

        + David H:

        Let me wade in as co-chair of the SNMPv3 WG, concluded.

        [quoted above]

        because then the definition used in this document would
        not be consistent with definitions used in the SNMPv3
        standard (RFC3411-3418) or the SNMP Transport subsystem
        extension (RFC5590), the Transport Security Model
        (RFC5591) the SSHTM (RFC5592), multiple (now mostly
        Historic) versions of SNMPv2, the SNMP Coexistence BCP,
        and a range of other SNMP documents, including every MIB
        module that has the required MIB Security boilerplate.

        For example, the term privacy has existed in SNMP at least
        since RFC1352 (July 1992). It doesn't mean the rights of
        an individual to decide how their information can be
        shared; it means protecting the confidentiality of
        information in SNMP messages. When SNMPv3 was advanced
        from proposed standard (1998) to draft (1999) to full
        standard (2002), the IESG accepted that it was better to
        have consistency within the long list of SNMP security
        documents than to rewrite everything to match the
        (contentious) glossary document that was still in the
        process of being written in 2000.

        my $.02 ;-)
        dbh

        + WH: I agree with David; if we were to rewrite the whole SNMP
          system we'd likely use consistent terminology.  But as this
          new document is a small piece of a much larger system it
          helps if all the terminology is consistent first within the
          system itself.

        + Peter: OK, mostly I was just checking because it seems good
          for us all to use consistent terminology, where possible.

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

        + WH: duplicate response as the above as it's really the same
          issue.

        + Peter: See above.

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

        + WH: Well, this document is really an standards
          implementation of what is defined in RFC5590.  It's
          important to understand that document before reading this
          one, as it says in the first sentence of the introduction.
          In fact, RFC5590 is titled "Transport Subsystem for the
          Simple Network Management Protocol".  That being said,
          transport domains are very much an SNMP-ism and it would
          certainly be hard to understand if this was the first SNMP
          document you had read.  I'll put in a reference to RFC2579
          in the object references section which I think is the best
          that can really be done.

        + Peter: Thanks for the clarification.

4.2.4 DONE 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)?

        + WH: RFC5280 specifically mentions that DNS names are
          compared in a case-insensitive manner.  And therefore since
          the value 'Foo.example.com' must be equal within the
          resulting derived tmSecurityName the working group decided
          to make all DNS name instances lower case so that no matter
          what was in the certificate we'd use names that would also
          be comparatively the same.

        + Peter: OK, thanks for the clarification. It might be good to
          add a short note to the effect that this requires one step
          beyond the comparison rules specified in Section 7.2 of RFC
          5280.

        + WH: Well, we're not actually doing a comparison at this
          particular point.  We're taking data out of the certificate
          to make use of.  The reason for requiring the lower-casing
          is to make sure that because certificates *can* be
          constructed with two values that are supposed to be the same
          from the certificate's point of view and that our resulting
          derived label (tmSecurityName) will also be unique per value
          from the certificate.  But we're not doing a comparison,
          we're deriving a value from a X.509 field.

        + Peter:

          Change "comparison" to "canonicalization" or whatever term
          you prefer and I think my comment still makes sense as an
          implementation note -- you could take the output of a string
          preparation library that supports the Nameprep profile or a
          security library that supports RFC 5280 but you would then
          need to perform an additional step of lowercasing the domain
          name before you could correctly do something useful with the
          output.

          I'm talking about something like the following parenthetical
          remark:

          snmpTlstmCertSANDNSName OBJECT-IDENTITY
              STATUS        current
              DESCRIPTION  "Maps a subjectAltName's dNSName to a
                            tmSecurityName after first converting it to all
                            lower case (note that [RFC5280] does not specify
                            converting to lower case so this involves an
                            extra step)."

        + WH: Ok, I'll add that to the MIB objects minus the []s
          around the RFC5280 since hard references aren't allowed in
          MIBs.  Thanks for suggesting the text you wished to see in place.

4.2.5 CLOSED 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)?

        + WH: Not at the moment.  Others were discussed as "future
          desires" but the system as-is can be extended in the future
          with future mapping algorithms.  So this document only
          defines a few of the possibilities, there is nothing
          preventing a future (potentially short) document from
          defining new ones.

        + Peter: OK

4.2.6 CLOSED Is there a preferred order of matching subjectAltName 
-------------------------------------------------------------------
        extensions?

        + WH: The objects specifically call out that you MUST pick the
          first one in the list that is a match.

        + Peter: I must have missed that. My apologies.

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

        + WH: I'm not entirely sure I'm exactly matching what you're
          asking about.  Certificate SAN to tmSecurityName mapping was
          what you were last asking about, but I suspect you've now
          switched to checking for name validity when making
          connections?

          The working group recognized that there was new work being
          undertaken in this area.  The current text in the
          tlstmAddrTable object was added in an effort to put in
          wording that addressed the issue of connection setup.  If
          you have suggested changes or additions that you feel are
          important I'd gladly consider them.

        + Peter: By "prepare for" I mean that connecting party must
          have some inputs to the matching operation so that it has a
          canonical reference identifier that it expects the other
          party to present in a certificate. For example, if I type
          "[https://www.example.com/]" into the URL line of my browser
          then my browser might expect the presented certificate to
          include one of the following identifiers:

          uniformResourceIdentifier = [https://www.example.com/]
          dNSName = www.example.com
          dNSName = *.example.com
          CN = www.example.com

          etc.

          We have a discussion about this in
          draft-saintandre-tls-server-id-check for various application
          protocols, which might provide some concepts that you could
          re-use.

        + WH: This is the text from the document that describes
          setting up connections and what to expect from the
          certificate contents.  Is this text insufficient in your
          mind then?

            If the server's presented certificate has passed
            certification path validation [RFC5280] to a configured
            trust anchor, and an active row exists with a zero-length
            snmpTlstmAddrServerFingerprint value, then the
            snmpTlstmAddrServerIdentity column contains the expected
            host name.  This expected host name is then compared against
            the server's certificate as follows:

              - Implementations MUST support matching the expected host
              name against a dNSName in the subjectAltName extension
              field and MAY support checking the name against the
              CommonName portion of the subject distinguished name.

              - The '*' (ASCII 0x2a) wildcard character is allowed in the
              dNSName of the subjectAltName extension (and in common
              name, if used to store the host name), but only as the
              left-most (least significant) DNS label in that value.
              This wildcard matches any left-most DNS label in the
              server name.  That is, the subject *.example.com matches
              the server names a.example.com and b.example.com, but does
              not match example.com or a.b.example.com.  Implementations
              MUST support wildcards in certificates as specified above,
              but MAY provide a configuration option to disable them.
              
              - If the locally configured name is an internationalized
              domain name, conforming implementations MUST convert it to
              the ASCII Compatible Encoding (ACE) format for performing
              comparisons, as specified in Section 7 of [RFC5280].
              
            If the expected host name fails these conditions then the
            connection MUST be closed.

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

        + WH: The snmpTlstmCertToTSNTable table description says this
          already.  I'd be happy to mention it in other places too if
          you feel it was appropriate and had places that you think
          such a NOT RECOMMENDED statement belongs. 

        + Peter: The specification contains the following text
          regarding the Common Name:

          ###

          7. MIB Module Definition

          <snip/>

          snmpTlstmCertCommonName OBJECT-IDENTITY
              STATUS        current

              DESCRIPTION  "Maps a certificate's CommonName to a tmSecurityName
                            after converting it to a UTF-8 encoding."

          [...No mention that this usage is NOT RECOMMENDED or that objects of
          type snmpTlstmCertSAN* are preferred...]

          <snip/>

          snmpTlstmCertToTSNTable OBJECT-TYPE
              SYNTAX      SEQUENCE OF SnmpTlstmCertToTSNEntry
              MAX-ACCESS  not-accessible
              STATUS      current
              DESCRIPTION

          <snip/>

                  Users are encouraged to make use of certificates with
                  subjectAltName fields that can be used as tmSecurityNames so
                  that a single root CA certificate can allow all child
                  certificate's subjectAltName to map directly to a
                  tmSecurityName via a 1:1 transformation.  However, this table
                  is flexible to allow for situations where existing deployed
                  certificate infrastructures do not provide adequate
                  subjectAltName values for use as tmSecurityNames.
                  Certificates may also be mapped to tmSecurityNames using the
                  CommonName portion of the Subject field.  However, the usage
                  of the CommonName field is deprecated and thus this usage is
                  NOT RECOMMENDED.  Direct mapping from each individual
                  certificate fingerprint to a tmSecurityName is also possible
                  but requires one entry in the table per tmSecurityName and
                  requires more management operations to completely configure a
                  device."

          <snip/>

          snmpTlstmAddrTable OBJECT-TYPE
              SYNTAX      SEQUENCE OF SnmpTlstmAddrEntry
              MAX-ACCESS  not-accessible
              STATUS      current
              DESCRIPTION

          <snip/>

                      - Implementations MUST support matching the expected host
                      name against a dNSName in the subjectAltName extension
                      field and SHOULD support checking the name against the
                      common name portion of the subject distinguished name.

          [...Here Common Name appears to be a SHOULD...]

          <snip/>

          A.2. Configuring the Command Responder

          <snip/>

             The above is an example of how to map a particular certificate to a
             particular tmSecurityName.  It is recommended, however, that users
             make use of direct subjectAltName or CommonName mappings where
             possible as it provides a more scalable approach to certificate
             management.

          [...Here Common Name appears to be RECOMMENDED...]

          ###

          Thus it appears that there are some inconsistencies in the text
          regarding whether Common Name is NOT RECOMMENDED or RECOMMENDED.

          Peter

        + WH: Ok, I'll make the following changes to strengthen the
          text.  The last text you discussed was in the appedix and
          was complete rewritten lately by David H. and myself and no
          longer contains that recommendation at all.

          + Changed text 1 (addition of second sentence)

            DESCRIPTION  "Maps a certificate's CommonName to a tmSecurityName
                          after converting it to a UTF-8 encoding.
                          The usage of CommonNames is deprecated and
                          users are encouraged to use subjectAltName
                          mapping methods instead."

          + Changed text 2 (SHOULD -> MAY):

            - Implementations MUST support matching the expected host
            name against a dNSName in the subjectAltName extension
            field and MAY support checking the name against the
            common name portion of the subject distinguished name.

           Look good?

5 Tim Polk <[email-masked]> 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

      + WH: Would the addition of the following text to the security
        considerations section satisfy this in your eyes:

        The use of Perfect Forward Secrecy is RECOMMENDED and can be provided
        by TLS with appropriately selected cipher suites, as discussed in
        appendix F of [RFC5246].

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

      + WH: I've added that exact text to a new security
        considerations sub-section entitled "TLS Version
        Requirements".

      + WH: Never heard directly back, but since I took his text I'm
        assuming this is resolved.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "David Harrington" <[email-masked]>
Date: Wed, 5 May 2010 19:07:41 -0400

Hi,

>       baloting a YES vote I would like to clarify a few issues:
I agree this is a well-written document, except those portions copied
from my document ;-)

> ***The mapping algorithm

I still have concerns about interoperability. I think we'll talk about
this during the telechat tomorrow.

> ----------
>            Implementations SHOULD offer configuration settings for

If we say it SHOULD, then shouldn't we provide the appropriate tables
in the MIB module?
I am not certain what such a mapping would look like.

> ---------

Actually, 3417 is probably the preferred reference.

dbh

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 05 May 2010 16:20:39 -0700

>           interoperability unless the APIs can't handle it.

DH> I still have concerns about interoperability. I think we'll talk
DH> about this during the telechat tomorrow.

I'd love to see a case that points out where something isn't
deterministic given the existing specifications.  Please provide!
 
> 3.2.1 CLOSED In Section 3.1.2, the last sentence of the last 

DH> If we say it SHOULD, then shouldn't we provide the appropriate
DH> tables in the MIB module?  I am not certain what such a mapping
DH> would look like.

We even agreed in the WG at one point that such infrastructure tables
would be nice to have but would need to be defined in PKIX, not in ISMS.

> 4.2.3 CLOSED Forgive my ignorance regarding SNMP/SMI, but I 

DH> Actually, 3417 is probably the preferred reference.

3417 defines the current transport mechanisms (e.g. UDP).  RFC2579, on
the other-hand, defines the TDomain and TAddress TC which is the base
for them all.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "David Harrington" <[email-masked]>
Date: Wed, 5 May 2010 19:47:54 -0400

> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Wednesday, May 05, 2010 7:21 PM
> To: David Harrington
> Cc: 'Wes Hardaker'; [email-masked]; [email-masked]
> Subject: Re: Status of IESG-review changes for
draft-ietf-isms-dtls-tm
> deterministic given the existing specifications.  Please provide!

My concerns are not about deterministic; they are about
interoperability.

> would be nice to have but would need to be defined in PKIX, 

PKIX would not be the right place to define how to ***map them to
SNMPv3*** security levels. Or do I not understand what mappings you
think should be provided? Maybe I am confused because this spec talks
a lot about "mapping algorithms"; maybe you are thinking of something
else here than I am. As I said, I am not certain what such a mapping
would look like. Can you tell us what you think it would look like?

> the other-hand, defines the TDomain and TAddress TC which is the
base

OK.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 05 May 2010 21:49:02 -0700

>>>>> On Wed, 5 May 2010 19:47:54 -0400, "David Harrington" <[email-masked]> said:

>> deterministic given the existing specifications.  Please provide!

DH> My concerns are not about deterministic; they are about
DH> interoperability.

Ah; then I'd love to have the concerns explained!  More specifically, I
haven't heard a description of an actual problem (and I love to fix
problems, but I can't do so without the described complaint ;-).

The only issue I have in my head is that an operator MAY create a
situation where multiple certificates all map to a given
tmSecurityName.  This is possible a feature in their eyes, but it could
be done by mistake.  But certificates already contain this problem as
if you have two CAs as trust anchors there is nothing that says the
CommonName or any other value in a certificate can't conflict between
the two CAs.  IE, the problem isn't unique to SNMP.  What operators
should do is avoid those situations and ensure they understand and trust
their CA's publication policies.

DH> PKIX would not be the right place to define how to ***map them to
DH> SNMPv3*** security levels.

I think I misread a sentence early on and I apologize for that because I
missed the original point.

Defining a mapping table to security levels is technically possible and
would probably look something close to:

  |------------------------------+-------------------------------|
  | TLS Suite (index(es))        | securityLevel (output column) |
  |------------------------------+-------------------------------|
  | TLS_RSA_WITH_AES_128_CBC_SHA | authPriv                      |
  | TLS_NULL_WITH_NULL_NULL      | noAuthNoPriv                  |
  | TLS_RSA_WITH_NULL_SHA256     | authNoPriv                    |
  | ...                          | ...                           |
  |------------------------------+-------------------------------|

I don't think it would be a complex table.  But we decided not to go
there and simply declare than "NULL" must not be used to fulfill an
"auth" or "priv" flag (which the document already says).

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 May 2010 08:33:57 +0200

> would probably look something close to:

And this approach seems to be consistent with what RFC 5592 does.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>