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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf