Re: Gen-ART review of draft-ietf-isms-dtls-tm-09

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Spencer,

I've reviewed your comments about the draft-ietf-isms-dtls-tm-09
document and am responding to them below.  Thanks again for the review
and please let me know if you want to discuss any of the items further!

My responses are prefixed below with "WH:" if you want to search for
them.  The status of each item is as follows:

  DONE:     Suggestion was acted on
  WONTDO:   Nothing was done; refer to the WH: response for reasons why
  DISCUSS:  There is an outstanding question back to you
  ANSWERED: A question was answered but had no action resulting from it

Comments and responses:


1 DONE 3.  How the TLSTM fits into the Transport Subsystem 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

          "The diagram below depicts where the TLS Transport Model
          fits into the architecture described in RFC3411 and the
          Transport Subsystem:"

          + Spencer (clarity): the words "TLS Transport Model" appears
            nowhere in the following figure that I could see. I'm pretty
            sure I know what you're talking about (the box labeled
            "(D)TLS TM"), but I'm guessing. My suggestion is to rephrase
            so that the reader can match the previous sentence and the
            figure - perhaps "... the TLS Transport Model, shown as
            (D)TLS TM, fits ..."

          + WH: Good point; I've not only changed the reference to
            that diagram but also to the diagram in a previous section
            which suffered from a similar problem.


2 WONTDO 3.1.1.  Threats 
~~~~~~~~~~~~~~~~~~~~~~~~~

          "(D)TLS provides protection against the disclosure of information
          to unauthorized recipients or eavesdroppers by allowing for
          encryption of all traffic between SNMP engines.  A TLS Transport
          Model implementation SHOULD support the message encryption to
          protect sensitive data from eavesdropping attacks."

          + Spencer (minor): OK, I'm completely out of my depth here,
            but I'm confused by the SHOULD. Is this saying that an
            implementation SHOULD support at least one non-NULL
            encryption TLS cipher suite? Or something else? If not,
            color me clueless, of course. But if so ... I don't think
            this is a 2119 SHOULD, because IIUC, you're basically
            saying, "if you don't support message encryption, then any
            eavesdropper can read the messages", right?

          + WH: Your guess is correct.  The SHOULD is saying you
            SHOULD support a non-NULL encryption algorithm.  But I'm
            not sure why you're saying the SHOULD is out of place or
            being used incorrectly.  The first half of the paragraph
            is really there to justify the SHOULD in the first place:
            you SHOULD implement encryption so that bad things can't
            happen.

            Feel free to clarify your comment further as to why you
            think the sentence should be deleted, but I don't (yet?) see
            a reason to delete it.

            (note that another comment received during last call
            indicated that the word "the" shouldn't appear in "the
            message encryption" and has since been removed).

3 DONE 5.1.1.  DTLS over UDP Processing for Incoming Messages 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

          "2)  The TLS Transport Model queries the LCD using the transport
              parameters (source and destination IP addresses and ports) to
              determine if a session already exists.

              2a)  f a matching entry in the LCD does not exist, then the UDP"

          + Spencer (nit): s/f a/If a/

          + WH: yep, thanks!  (other reviewers caught this too).

4 DONE 5.3.1.  Establishing a Session as a Client 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        "The following describes the procedure to follow when establishing a
        SNMP over (D)TLS connection between SNMP engines for exchanging SNMP
        messages.  This process is followed by any SNMP client's engine when
        establishing a session for subsequent use.

        This MAY be done automatically for an SNMP application that initiates"

        + Spencer (clarity): I was having pronoun problems here - perhaps "This
          primative MAY be invoked automatically for an SNMP application..."?

        + WH: changed to "This procedure" 

5 WONTDO 2) 
~~~~~~~~~~~~
        "The client selects the appropriate certificate and cipher_suites
        for the key agreement based on the tmSecurityName and the
        tmRequestedSecurityLevel for the session.  For sessions being
        established as a result of a SNMP-TARGET-MIB based operation, the
        certificate will potentially have been identified via the
        tlstmParamsTable mapping and the cipher_suites will have to be
        taken from system-wide or implementation-specific configuration.
        If no row in the tlstmParamsTable exists then implementations MAY
        choose to establish the connection using a default client
        certificate available to the application.  Otherwise, the
        certificate and appropriate cipher_suites will need to be passed
        to the openSession() ASI as supplemental information or
        configured through an implementation-dependent mechanism.  It is
        also implementation-dependent and possibly policy-dependent how
        tmRequestedSecurityLevel will be used to influence the security
        capabilities provided by the (D)TLS connection.  However this is
        done, the security capabilities provided by (D)TLS MUST be at
        least as high as the level of security indicated by the
        tmRequestedSecurityLevel parameter.  The actual security level of
        the session is reported in the tmStateReference cache as
        tmSecurityLevel.  For (D)TLS to provide strong authentication,
        each principal acting as a command generator SHOULD have its own
        certificate."

        + Spencer (minor): again, this doesn't sound like 2119
          language to me - it sounds like a statement of fact. Are you
          saying something like "If multiple principals acting as
          command generators share a certificate, (D)TLS cannot
          provide strong authentication"?

        + Functionally, yes.  We're saying you SHOULD use separate
          certificates for each command generator principal to achieve
          stronger security.  It's important that implementations
          support this so that the protocol can be used securely.

6 DONE 2) continued: 
~~~~~~~~~~~~~~~~~~~~~
        "If the connection is being established for reasons other than
        configuration found in the SNMP-TARGET-MIB then configuration and
        procedures outside the scope of this document should be followed."

        + Spencer (clarity): I couldn't parse "reasons other than connection
          found in the SNMP-TARGET-MIB" at all - not enough to make a
          suggestion. Is "connection found in the SNMP-TARGET-MIB" a "reason"?
          If so, I'd suggest putting it in quotes.

        + WH: this was recently changed to the following in order to
          clairfy the text.  Does this new text work for you as well?

                If the connection is being established for reasons
                other than configuration found in the SNMP-TARGET-MIB
                then configuration and procedures outside the scope of
                this document should be followed.  Configuration

7 DONE 8.4.  Transport Considerations 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        "This document defines how SNMP messages can be transmitted
        over the TLS and DTLS based protocols.  Each of these
        protocols are additionally based on other transports (TCP and
        UDP).  These three protocols also have operational
        considerations that must be taken into consideration when
        selecting a (D)TLS based protocol to use such as its
        performance in degraded or limited networks.  It is beyond the"

        + Spencer (clarity): I'm counting SNMP, TLS, DTLS, TCP, and
          UDP, so I'm not sure which three protocols you're talking
          about here. I'm guessing you meant SNMP, TLS/TCP, and
          DTLS/UDP, but I'm guessing. Not sure you even need a number,
          but "three" wasn't helpful to me.
          
        + WH: Good catch!  The three was a left-over from when the
          document discussed both DTLS/UDP and DTLS/SCTP.  The "three"
          should now be "two" and I've changed it to additional
          include the word "base" for further clarity:

          "These two base protocols also have operational..."

8 DONE 9.  Security Considerations 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        "This document describes a transport model that permits SNMP
        to utilize (D)TLS security services.  The security threats and
        how the (D)TLS transport model mitigates these threats are
        covered in detail throughout this document.  Security
        considerations for DTLS are covered in [RFC4347] and security
        considerations for TLS are described in Section 11 and
        Appendices D, E, and F of TLS 1.2 [RFC5246].  When run over
        UDP, DTLS is more vulnerable to denial of service attacks from
        spoofed IP addresses; see Section 4.2 for details how the
        cookie exchange is used to address this issue."

        + Spencer (minor): I'm confused by "When run over UDP"
          here. My (hurried) read of
          [http://www.rfc-editor.org/rfc/rfc4347.txt] seemed to point to
          DTLS only making sense for datagram transport protocols. Is
          this "Because it runs over a datagram transport, which does
          not rely on return routability to set up a session, DTLS is
          more vulnerable ..."? I'd strongly agree with that, if it's
          what you are saying.

        + WH: That's functionally what I'm saying.  (FYI, note that
          DTLS also runs over both SCTP and DCCP).  How does the
          following wording sound as a replacement:

          "When run over a connectionless transport such as UDP, DTLS
          is more vulnerable to denial of service attacks from spoofed
          IP addresses"

9 WONTDO 9.3.  MIB Module Security 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        "SNMP versions prior to SNMPv3 did not include adequate security.
        Even if the network itself is secure (for example by using IPsec),
        even then, there is no control as to who on the secure network is
        allowed to access and GET/SET (read/change/create/delete) the objects
        in this MIB module."

        + Spencer (nit): I don't think you need "even then, " in this
          sentence, which already has one "Even" at the beginning.

        + WH: I agree, but this is functionally template text that is
          required from the mib boiler plate.  In fact it's so common
          place that the exact phrasing above exists in 145 other
          published RFCs ;-)

10 DONE 10.  IANA Considerations 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        + Spencer (minor): Is this a note to remind the editor (not the
          RFC-Editor) to replace text during AUTH48? Not sure I've ever seen one
          like it before :D

        + WH: Ha!  Good point; thanks (and fixed).



-- 
Wes Hardaker
Cobham Analytic Solutions
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]