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