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

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

 



Document: draft-ietf-isms-dtls-tm-09
Reviewer: Spencer Dawkins
Review Date: 2010-04-14 (epic fail on getting review done - sorry!)
Last Call ends: 2010-04-02
IESG Telechat date: 2010-05-06

Summary: This specification is almost ready for publication as a Proposed Standard. I do have some (late Last Call) questions, almost all of which are around either 2119 language or clarity.

Thanks,

Spencer


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


  +------------------------------+
  |    Network                   |
  +------------------------------+
     ^       ^              ^
     |       |              |
     v       v              v
  +-------------------------------------------------------------------+
  | +--------------------------------------------------+              |
  | |  Transport Subsystem                             |  +--------+  |
  | | +-----+ +-----+ +-------+             +-------+  |  |        |  |
  | | | UDP | | SSH | |(D)TLS |    . . .    | other |<--->| Cache  |  |
  | | |     | | TM  | | TM    |             |       |  |  |        |  |
  | | +-----+ +-----+ +-------+             +-------+  |  +--------+  |
  | +--------------------------------------------------+         ^    |
  |              ^                                               |    |
  |              |                                               |    |
  | Dispatcher   v                                               |    |
  | +--------------+ +---------------------+  +----------------+ |    |
  | | Transport    | | Message Processing  |  | Security       | |    |
  | | Dispatch     | | Subsystem           |  | Subsystem      | |    |
  | |              | |     +------------+  |  | +------------+ | |    |
  | |              | |  +->| v1MP       |<--->| | USM        | | |    |
  | |              | |  |  +------------+  |  | +------------+ | |    |
  | |              | |  |  +------------+  |  | +------------+ | |    |
  | |              | |  +->| v2cMP      |<--->| | Transport  | | |    |
  | | Message      | |  |  +------------+  |  | | Security   |<--+    |
  | | Dispatch    <---->|  +------------+  |  | | Model      | |      |
  | |              | |  +->| v3MP       |<--->| +------------+ |      |
  | |              | |  |  +------------+  |  | +------------+ |      |
  | | PDU Dispatch | |  |  +------------+  |  | | Other      | |      |
  | +--------------+ |  +->| otherMP    |<--->| | Model(s)   | |      |
  |              ^   |     +------------+  |  | +------------+ |      |
  |              |   +---------------------+  +----------------+      |
  |              v                                                    |
  |      +-------+-------------------------+---------------+          |
  |      ^                                 ^               ^          |
  |      |                                 |               |          |
  |      v                                 v               v          |
  | +-------------+   +---------+   +--------------+  +-------------+ |
  | |   COMMAND   |   | ACCESS  |   | NOTIFICATION |  |    PROXY    | |
  | |  RESPONDER  |<->| CONTROL |<->|  ORIGINATOR  |  |  FORWARDER  | |
  | | application |   |         |   | applications |  | application | |
  | +-------------+   +---------+   +--------------+  +-------------+ |
  |      ^                                 ^                          |
  |      |                                 |                          |
  |      v                                 v                          |
  | +----------------------------------------------+                  |
  | |             MIB instrumentation              |      SNMP entity |
  +-------------------------------------------------------------------+

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?

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/

           packet is passed to the DTLS implementation for processing.
           If the DTLS implementation decides to continue with the
           connection and allocate state for it, it returns a new DTLS
           connection handle (an implementation dependent detail).  In
           this case, TLSTM selects a new tlstmSessionId, and caches
           this and the DTLS connection handle as a new entry in the
           LCD (indexed by the transport parameters).  If the DTLS
           implementation returns an error or does not allocate
           connection state (which can happen with the stateless cookie
           exchange), processing stops.

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

  a transaction, such as a command generator, a notification
  originator, or a proxy forwarder.

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

      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.

      Configuration mechanisms SHOULD be similar in nature to those
      defined in the tlstmAddrTable to ensure consistency across
      management configuration systems.  For example, a command-line
      tool for generating SNMP GETs might support specifying either the
      server's certificate fingerprint or the expected host name as a
      command line argument.

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.

  scope of this document to summarize the characteristics of these
  transport mechanisms.  Please refer to the base protocol documents
  for details on messaging considerations with respect to MTU size,
  fragmentation, performance in lossy-networks, etc.


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.

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.

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