< draft-ietf-isms-dtls-tm-04.txt   draft-ietf-isms-dtls-tm-05.txt >
ISMS W. Hardaker ISMS W. Hardaker
Internet-Draft Sparta, Inc. Internet-Draft Sparta, Inc.
Intended status: Standards Track December 30, 2009 Intended status: Standards Track January 8, 2010
Expires: July 3, 2010 Expires: July 12, 2010
Transport Layer Security (TLS) Transport Model for SNMP Transport Layer Security (TLS) Transport Model for SNMP
draft-ietf-isms-dtls-tm-04.txt draft-ietf-isms-dtls-tm-05.txt
Abstract Abstract
This document describes a Transport Model for the Simple Network This document describes a Transport Model for the Simple Network
Management Protocol (SNMP), that uses either the Transport Layer Management Protocol (SNMP), that uses either the Transport Layer
Security protocol or the Datagram Transport Layer Security (DTLS) Security protocol or the Datagram Transport Layer Security (DTLS)
protocol. The TLS and DTLS protocols provide authentication and protocol. The TLS and DTLS protocols provide authentication and
privacy services for SNMP applications. This document describes how privacy services for SNMP applications. This document describes how
the TLS Transport Model (TLSTM) implements the needed features of a the TLS Transport Model (TLSTM) implements the needed features of a
SNMP Transport Subsystem to make this protection possible in an SNMP Transport Subsystem to make this protection possible in an
skipping to change at page 2, line 9 skipping to change at page 2, line 9
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 3, 2010. This Internet-Draft will expire on July 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 45 skipping to change at page 3, line 45
5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 27 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 27
6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 28 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 28
6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28
6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 28 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 28
6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 28 6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 28
6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 28 6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 28
6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 29 6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 29
6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29 6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29
6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29 6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29
7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29
8. Operational Considerations . . . . . . . . . . . . . . . . . . 51 8. Operational Considerations . . . . . . . . . . . . . . . . . . 50
8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.2. Notification Receiver Credential Selection . . . . . . . . 51 8.2. Notification Receiver Credential Selection . . . . . . . . 51
8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 52 8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 52
8.4. Transport Considerations . . . . . . . . . . . . . . . . . 52 8.4. Transport Considerations . . . . . . . . . . . . . . . . . 52
9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 9. Security Considerations . . . . . . . . . . . . . . . . . . . 52
9.1. Certificates, Authentication, and Authorization . . . . . 53 9.1. Certificates, Authentication, and Authorization . . . . . 52
9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 53 9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 53
9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 54 9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 54
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
12.1. Normative References . . . . . . . . . . . . . . . . . . . 57 12.1. Normative References . . . . . . . . . . . . . . . . . . . 57
12.2. Informative References . . . . . . . . . . . . . . . . . . 58 12.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 59 Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 59
A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 60 A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 59
A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 60 A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 60
Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 61 Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 61
Appendix C. Target and Notificaton Configuration Example . . . . 62 Appendix C. Target and Notificaton Configuration Example . . . . 62
C.1. Configuring the Notification Generator . . . . . . . . . . 63 C.1. Configuring the Notification Generator . . . . . . . . . . 63
C.2. Configuring the Command Responder . . . . . . . . . . . . 63 C.2. Configuring the Command Responder . . . . . . . . . . . . 63
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
It is important to understand the modular SNMPv3 architecture as It is important to understand the modular SNMPv3 architecture as
skipping to change at page 8, line 11 skipping to change at page 8, line 11
the statement applies to either or both protocols as appropriate. the statement applies to either or both protocols as appropriate.
When a distinction between the protocols is needed they are referred When a distinction between the protocols is needed they are referred
to independently through the use of "TLS" or "DTLS". The Transport to independently through the use of "TLS" or "DTLS". The Transport
Model, however, is named "TLS Transport Model" and refers not to the Model, however, is named "TLS Transport Model" and refers not to the
TLS or DTLS protocol but to the standard defined in this document, TLS or DTLS protocol but to the standard defined in this document,
which includes support for both TLS and DTLS. which includes support for both TLS and DTLS.
Throughout this document, the terms "client" and "server" are used to Throughout this document, the terms "client" and "server" are used to
refer to the two ends of the (D)TLS transport connection. The client refer to the two ends of the (D)TLS transport connection. The client
actively opens the (D)TLS connection, and the server passively actively opens the (D)TLS connection, and the server passively
listens for the incoming (D)TLS connection. Either SNMP entity may listens for the incoming (D)TLS connection. An SNMP entity may act
act as client or as server. as a (D)TLS client or server or both, depending on the SNMP
applications supported.
The User-Based Security Model (USM) [RFC3414] is a mandatory-to- The User-Based Security Model (USM) [RFC3414] is a mandatory-to-
implement Security Model in STD 62. While (D)TLS and USM frequently implement Security Model in STD 62. While (D)TLS and USM frequently
refer to a user, the terminology preferred in RFC3411 and in this refer to a user, the terminology preferred in RFC3411 and in this
memo is "principal". A principal is the "who" on whose behalf memo is "principal". A principal is the "who" on whose behalf
services are provided or processing takes place. A principal can be, services are provided or processing takes place. A principal can be,
among other things, an individual acting in a particular role; a set among other things, an individual acting in a particular role; a set
of individuals, with each acting in a particular role; an application of individuals, with each acting in a particular role; an application
or a set of applications, or a combination of these within an or a set of applications, or a combination of these within an
administrative domain. administrative domain.
skipping to change at page 11, line 12 skipping to change at page 11, line 12
message has not been modified during its transmission through the message has not been modified during its transmission through the
network, data has not been altered or destroyed in an network, data has not been altered or destroyed in an
unauthorized manner, and data sequences have not been altered to unauthorized manner, and data sequences have not been altered to
an extent greater than can occur non-maliciously. an extent greater than can occur non-maliciously.
2. Masquerade - The masquerade threat is the danger that management 2. Masquerade - The masquerade threat is the danger that management
operations unauthorized for a given principal may be attempted by operations unauthorized for a given principal may be attempted by
assuming the identity of another principal that has the assuming the identity of another principal that has the
appropriate authorizations. appropriate authorizations.
The TLSTM provides for verification of the identity of the (D)TLS The TLSTM verifies of the identity of the (D)TLS server through
server through the use of the (D)TLS protocol and the X.509 the use of the (D)TLS protocol and X.509 certificates. The TLS
certificates. The TLS Transport Model MUST support Transport Model MUST support authentication of both the server
authentication of both the server and the client. and the client.
3. Message stream modification - The re-ordering, delay or replay of 3. Message stream modification - The re-ordering, delay or replay of
messages can and does occur through the natural operation of many messages can and does occur through the natural operation of many
connectionless transport services. The message stream connectionless transport services. The message stream
modification threat is the danger that messages may be modification threat is the danger that messages may be
maliciously re-ordered, delayed or replayed to an extent which is maliciously re-ordered, delayed or replayed to an extent which is
greater than can occur through the natural operation of greater than can occur through the natural operation of
connectionless transport services, in order to effect connectionless transport services, in order to effect
unauthorized management operations. unauthorized management operations.
skipping to change at page 11, line 44 skipping to change at page 11, line 44
(D)TLS provides protection against the disclosure of information (D)TLS provides protection against the disclosure of information
to unauthorized recipients or eavesdroppers by allowing for to unauthorized recipients or eavesdroppers by allowing for
encryption of all traffic between SNMP engines. The TLS encryption of all traffic between SNMP engines. The TLS
Transport Model SHOULD support the message encryption to protect Transport Model SHOULD support the message encryption to protect
sensitive data from eavesdropping attacks. sensitive data from eavesdropping attacks.
5. Denial of Service - the RFC 3411 architecture [RFC3411] states 5. Denial of Service - the RFC 3411 architecture [RFC3411] states
that denial of service (DoS) attacks need not be addressed by an that denial of service (DoS) attacks need not be addressed by an
SNMP security protocol. However, datagram-based security SNMP security protocol. However, datagram-based security
protocols like DTLS are susceptible to a variety of denial of protocols like DTLS are susceptible to a variety of denial of
service attacks because it is more vulnerable to spoofed service attacks because they are more vulnerable to spoofed
messages. messages.
In order to counter these attacks, DTLS borrows the stateless In order to counter these attacks, DTLS borrows the stateless
cookie technique used by Photuris [RFC2522] and IKEv2 [RFC4306] cookie technique used by Photuris [RFC2522] and IKEv2 [RFC4306]
and is described fully in section 4.2.1 of [RFC4347]. This and is described fully in section 4.2.1 of [RFC4347]. This
mechanism, though, does not provide any defense against denial of mechanism, though, does not provide any defense against denial of
service attacks mounted from valid IP addresses. DTLS Transport service attacks mounted from valid IP addresses. DTLS Transport
Model server implementations MUST support DTLS cookies. Model server implementations MUST support DTLS cookies.
Implementations are not required to perform the stateless cookie Implementations are not required to perform the stateless cookie
skipping to change at page 12, line 26 skipping to change at page 12, line 26
The RFC 3411 architecture recognizes three levels of security: The RFC 3411 architecture recognizes three levels of security:
o without authentication and without privacy (noAuthNoPriv) o without authentication and without privacy (noAuthNoPriv)
o with authentication but without privacy (authNoPriv) o with authentication but without privacy (authNoPriv)
o with authentication and with privacy (authPriv) o with authentication and with privacy (authPriv)
The TLS Transport Model determines from (D)TLS the identity of the The TLS Transport Model determines from (D)TLS the identity of the
authenticated principal, and the type and address associated with an authenticated principal, the transport type and the transport address
incoming message. The TLS Transport Model provides the identity and associated with an incoming message. The TLS Transport Model
destination type and address to (D)TLS for outgoing messages. provides the identity and destination type and address to (D)TLS for
outgoing messages.
When an application requests a session for a message, through the When an application requests a session for a message, through the
cache, the application requests a security level for that session. cache, the application requests a security level for that session.
The TLS Transport Model MUST ensure that the (D)TLS session provides The TLS Transport Model MUST ensure that the (D)TLS session provides
security at least as high as the requested level of security. How security at least as high as the requested level of security. How
the security level is translated into the algorithms used to provide the security level is translated into the algorithms used to provide
data integrity and privacy is implementation-dependent. However, the data integrity and privacy is implementation-dependent. However, the
NULL integrity and encryption algorithms MUST NOT be used to fulfill NULL integrity and encryption algorithms MUST NOT be used to fulfill
security level requests for authentication or privacy. security level requests for authentication or privacy.
Implementations MAY choose to force (D)TLS to only allow Implementations MAY choose to force (D)TLS to only allow
skipping to change at page 13, line 26 skipping to change at page 13, line 27
anticipation of outgoing messages. This approach might be useful to anticipation of outgoing messages. This approach might be useful to
ensure that a (D)TLS session to a given target can be established ensure that a (D)TLS session to a given target can be established
before it becomes important to send a message over the (D)TLS before it becomes important to send a message over the (D)TLS
session. Of course, there is no guarantee that a pre-established session. Of course, there is no guarantee that a pre-established
session will still be valid when needed. session will still be valid when needed.
DTLS sessions, when used over UDP, are uniquely identified within the DTLS sessions, when used over UDP, are uniquely identified within the
TLS Transport Model by the combination of transportDomain, TLS Transport Model by the combination of transportDomain,
transportAddress, tmSecurityName, and requestedSecurityLevel transportAddress, tmSecurityName, and requestedSecurityLevel
associated with each session. Each unique combination of these associated with each session. Each unique combination of these
parameters MUST have a locally-chosen unique tlstmSessionID parameters MUST have a locally-chosen unique tlstmSessionID for each
associated for active sessions. For further information see active session. For further information see Section 5. TLS over TCP
Section 5. TLS and DTLS over SCTP sessions, on the other hand, do and DTLS over SCTP sessions, on the other hand, do not require a
not require a unique pairing of address and port attributes since unique pairing of address and port attributes since their lower layer
their lower layer protocols (TCP and SCTP) already provide adequate protocols (TCP and SCTP) already provide adequate session framing.
session framing. But they must still provide a unique tlstmSessionID But they must still provide a unique tlstmSessionID for referencing
for referencing the session. the session.
The tlstmSessionID MAY be the same as the (D)TLS internal SessionID As an implementation hint: although the tlstmSessionID may be the
but caution must be exercised since the (D)TLS internal SessionID may same as the (D)TLS internal SessionID caution must be exercised since
change over the life of the connection as seen by the TLSTM (for the (D)TLS internal SessionID may change over the life of the
example during renegotiation). The tlstmSessionID identifier MUST connection as seen by the TLSTM (for example during renegotiation).
NOT change during the entire duration of the connection from the The tlstmSessionID identifier MUST NOT change during the entire
TLSTM's perspective. duration of the session from the TLSTM's perspective even if the TLS
internal session identifier does change.
3.2. Security Parameter Passing 3.2. Security Parameter Passing
For the (D)TLS server-side, (D)TLS-specific security parameters For the (D)TLS server-side, (D)TLS-specific security parameters
(i.e., cipher_suites, X.509 certificate fields, IP address and port) (i.e., cipher_suites, X.509 certificate fields, IP address and port)
are translated by the TLS Transport Model into security parameters are translated by the TLS Transport Model into security parameters
for the TLS Transport Model and security model (e.g.., for the TLS Transport Model and security model (e.g.,
tmSecurityLevel, tmSecurityName, transportDomain, transportAddress). tmSecurityLevel, tmSecurityName, transportDomain, transportAddress).
The transport- related and (D)TLS-security-related information, The transport- related and (D)TLS-security-related information,
including the authenticated identity, are stored in a cache including the authenticated identity, are stored in a cache
referenced by tmStateReference. referenced by tmStateReference.
For the (D)TLS client-side, the TLS Transport Model takes input For the (D)TLS client-side, the TLS Transport Model takes input
provided by the Dispatcher in the sendMessage() Abstract Service provided by the Dispatcher in the sendMessage() Abstract Service
Interface (ASI) and input from the tmStateReference cache. The Interface (ASI) and input from the tmStateReference cache. The
(D)TLS Transport Model converts that information into suitable (D)TLS Transport Model converts that information into suitable
security parameters for (D)TLS and establishes sessions as needed. security parameters for (D)TLS and establishes sessions as needed.
skipping to change at page 15, line 50 skipping to change at page 15, line 50
tlstmCertToTSNTable. This table allows mapping of incoming tlstmCertToTSNTable. This table allows mapping of incoming
connections to tmSecurityNames through defined transformations. The connections to tmSecurityNames through defined transformations. The
transformations defined in the TLSTM-MIB include: transformations defined in the TLSTM-MIB include:
o Mapping a certificate's fingerprint type and value to a directly o Mapping a certificate's fingerprint type and value to a directly
specified tmSecurityName, or specified tmSecurityName, or
o Mapping a certificate's subjectAltName or CommonName components to o Mapping a certificate's subjectAltName or CommonName components to
a tmSecurityName. a tmSecurityName.
Implementations MAY choose to discard any connections for which no As an implementation hint: implementations may choose to discard any
potential tlstmCertToTSNTable mapping exists before performing connections for which no potential tlstmCertToTSNTable mapping exists
certificate verification to avoid expending computational resources before performing certificate verification to avoid expending
associated with certificate verification. computational resources associated with certificate verification.
Enterprise configurations are encouraged to map a "subjectAltName" Enterprise configurations are encouraged to map a "subjectAltName"
component of the X.509 certificate to the TLSTM specific component of the X.509 certificate to the TLSTM specific
tmSecurityName. The authenticated identity can be obtained by the tmSecurityName. The authenticated identity can be obtained by the
TLS Transport Model by extracting the subjectAltName(s) from the TLS Transport Model by extracting the subjectAltName(s) from the
peer's certificate. The receiving application will then have an peer's certificate. The receiving application will then have an
appropriate tmSecurityName for use by other SNMPv3 components like an appropriate tmSecurityName for use by other SNMPv3 components like an
access control model. access control model.
An example of this type of mapping setup can be found in Appendix C. An example of this type of mapping setup can be found in Appendix C.
skipping to change at page 19, line 10 skipping to change at page 19, line 10
a request-response pair, and potentially longer-term state relating a request-response pair, and potentially longer-term state relating
to transport and security. "Transport Subsystem for the Simple to transport and security. "Transport Subsystem for the Simple
Network Management Protocol" [RFC5590] defines general requirements Network Management Protocol" [RFC5590] defines general requirements
for caches and references. for caches and references.
4.4.1. TLS Transport Model Cached Information 4.4.1. TLS Transport Model Cached Information
The TLS Transport Model has specific responsibilities regarding the The TLS Transport Model has specific responsibilities regarding the
cached information. See the Elements of Procedure in Section 5 for cached information. See the Elements of Procedure in Section 5 for
detailed processing instructions on the use of the tmStateReference detailed processing instructions on the use of the tmStateReference
fields by the TLS Transport Model fields by the TLS Transport Model.
4.4.1.1. tmSecurityName 4.4.1.1. tmSecurityName
The tmSecurityName MUST be a human-readable name (in snmpAdminString The tmSecurityName MUST be a human-readable name (in snmpAdminString
format) representing the identity that has been set according to the format) representing the identity that has been set according to the
procedures in Section 5. The tmSecurityName MUST be constant for all procedures in Section 5. The tmSecurityName MUST be constant for all
traffic passing through an TLSTM session. Messages MUST NOT be sent traffic passing through an TLSTM session. Messages MUST NOT be sent
through an existing (D)TLS session that was established using a through an existing (D)TLS session that was established using a
different tmSecurityName. different tmSecurityName.
skipping to change at page 22, line 14 skipping to change at page 22, line 14
3) Retrieve the tlstmSessionID from the LCD. 3) Retrieve the tlstmSessionID from the LCD.
4) The UDP packet and the tlstmSessionID are passed to DTLS for 4) The UDP packet and the tlstmSessionID are passed to DTLS for
integrity checking and decryption. integrity checking and decryption.
If the message fails integrity checks or other (D)TLS security If the message fails integrity checks or other (D)TLS security
processing then increment the tlstmDTLSProtectionErrors counter, processing then increment the tlstmDTLSProtectionErrors counter,
discard and stop processing the message. discard and stop processing the message.
5) (D)TLS should return an incomingMessage and an 5) DTLS should return an incomingMessage and an
incomingMessageLength. These results and the tlstmSessionID are incomingMessageLength. These results and the tlstmSessionID are
used below in the Section 5.1.2 to complete the processing of the used below in the Section 5.1.2 to complete the processing of the
incoming message. incoming message.
5.1.2. Transport Processing for Incoming SNMP Messages 5.1.2. Transport Processing for Incoming SNMP Messages
The procedures in this section describe how the TLS Transport Model The procedures in this section describe how the TLS Transport Model
should process messages that have already been properly extracted should process messages that have already been properly extracted
from the (D)TLS stream. Note that care must be taken when processing from the (D)TLS stream. Note that care must be taken when processing
messages originating from either TLS or DTLS to ensure they're messages originating from either TLS or DTLS to ensure they're
skipping to change at page 24, line 29 skipping to change at page 24, line 29
new session using the openSession() ASI (described in greater new session using the openSession() ASI (described in greater
detail in step 4b). Instead of opening a new session an detail in step 4b). Instead of opening a new session an
implementation MAY return a snmpTlstmSessionNoSessions error to implementation MAY return a snmpTlstmSessionNoSessions error to
the calling module and stop processing of the message. the calling module and stop processing of the message.
5) If tmSessionID is undefined, then use tmTransportDomain, 5) If tmSessionID is undefined, then use tmTransportDomain,
tmTransportAddress, tmSecurityName and tmRequestedSecurityLevel tmTransportAddress, tmSecurityName and tmRequestedSecurityLevel
to see if there is a corresponding entry in the LCD suitable to to see if there is a corresponding entry in the LCD suitable to
send the message over. send the message over.
4a) If there is a corresponding LCD entry, then this session 5a) If there is a corresponding LCD entry, then this session
will be used to send the message. will be used to send the message.
4b) If there is not a corresponding LCD entry, then open a 5b) If there is not a corresponding LCD entry, then open a
session using the openSession() ASI (discussed further in session using the openSession() ASI (discussed further in
Section 5.3). Implementations MAY wish to offer message Section 5.3). Implementations MAY wish to offer message
buffering to prevent redundant openSession() calls for the buffering to prevent redundant openSession() calls for the
same cache entry. If an error is returned from same cache entry. If an error is returned from
openSession(), then discard the message, discard the openSession(), then discard the message, discard the
tmStateReferenc, increment the snmpTlstmSessionOpenErrors, tmStateReference, increment the snmpTlstmSessionOpenErrors,
return an error indication to the calling module and stop return an error indication to the calling module and stop
processing of the message. processing of the message.
6) Using either the session indicated by the tmSessionID if there 6) Using either the session indicated by the tmSessionID if there
was one or the session resulting from a previous step (3 or 4), was one or the session resulting from a previous step (3 or 4),
pass the outgoingMessage to (D)TLS for encapsulation and pass the outgoingMessage to (D)TLS for encapsulation and
transmission. transmission.
5.3. Establishing a Session 5.3. Establishing a Session
skipping to change at page 26, line 33 skipping to change at page 26, line 33
tmStateReference cache as tmSecurityName. The details of the tmStateReference cache as tmSecurityName. The details of the
lookup process are fully described in the DESCRIPTION clause lookup process are fully described in the DESCRIPTION clause
of the tlstmCertToTSNTable MIB object. If any verification of the tlstmCertToTSNTable MIB object. If any verification
fails in any way (for example because of failures in fails in any way (for example because of failures in
cryptographic verification or because of the lack of an cryptographic verification or because of the lack of an
appropriate row in the tlstmCertToTSNTable) then the session appropriate row in the tlstmCertToTSNTable) then the session
establishment MUST fail, the establishment MUST fail, the
snmpTlstmSessionInvalidClientCertificates object is snmpTlstmSessionInvalidClientCertificates object is
incremented and processing stops. incremented and processing stops.
b) The (D)TLS client side of the connection MUST verify that b) The (D)TLS client side of the connection MUST verify that the
authenticated identity of the (D)TLS server's presented (D)TLS server's presented certificate is the expected
certificate is the expected certificate. The (D)TLS client certificate. The (D)TLS client MUST NOT transmit SNMP
MUST NOT transmit SNMP messages until the server certificate messages until the server certificate has been authenticated
has been authenticated and the client certificate has been and the client certificate has been transmitted.
transmitted.
If the connection is being established from configuration If the connection is being established from configuration
based on SNMP-TARGET-MIB configuration then the procedures in based on SNMP-TARGET-MIB configuration then the procedures in
the tlstmAddrTable DESCRIPTION clause should be followed to the tlstmAddrTable DESCRIPTION clause should be followed to
determine if the presented identity matches the expectations determine if the presented identity matches the expectations
of the configuration. Path validation procedures (like those of the configuration. Path validation procedures (like those
defined in [RFC5280]) MUST be followed. If a server identity defined in [RFC5280]) MUST be followed. If a server identity
name has been configured in the tlstmAddrServerIdentity name has been configured in the tlstmAddrServerIdentity
column then this reference identity must be compared against column then this reference identity must be compared against
the presented identity (for example using procedures the presented identity (for example using procedures
skipping to change at page 27, line 17 skipping to change at page 27, line 16
(D)TLS provides assurance that the authenticated identity has (D)TLS provides assurance that the authenticated identity has
been signed by a trusted configured certificate authority. been signed by a trusted configured certificate authority.
If verification of the server's certificate fails in any way If verification of the server's certificate fails in any way
(for example because of failures in cryptographic (for example because of failures in cryptographic
verification or the presented identity did not match the verification or the presented identity did not match the
expected named entity) then the session establishment MUST expected named entity) then the session establishment MUST
fail, the snmpTlstmSessionInvalidServerCertificates object is fail, the snmpTlstmSessionInvalidServerCertificates object is
incremented and processing stops. incremented and processing stops.
4) The TLSTM-specific session identifier (tlstmSessionID) is set in 4) The TLSTM-specific session identifier (tlstmSessionID) is set in
the sessionID of the tmStateReference passed to the TLS Transport the tmSessionID of the tmStateReference passed to the TLS
Model to indicate that the session has been established Transport Model to indicate that the session has been established
successfully and to point to a specific (D)TLS session for future successfully and to point to a specific (D)TLS session for future
use. use.
Servers that wish to support multiple principals at a particular port Servers that wish to support multiple principals at a particular port
SHOULD make use of the Server Name Indication extension defined in SHOULD make use of a (D)TLS extension that allows server-side
Section 3.1 of [RFC4366]. Supporting this will allow, for example, principal selection like the Server Name Indication extension defined
sending notifications to a specific principal at a given TCP, UDP or in Section 3.1 of [RFC4366]. Supporting this will allow, for
SCTP port. example, sending notifications to a specific principal at a given
TCP, UDP or SCTP port.
5.4. Closing a Session 5.4. Closing a Session
The TLS Transport Model provides the following primitive to close a The TLS Transport Model provides the following primitive to close a
session: session:
statusInformation = statusInformation =
closeSession( closeSession(
IN tmSessionID -- session ID of the session to be closed IN tmSessionID -- session ID of the session to be closed
) )
skipping to change at page 30, line 6 skipping to change at page 30, line 6
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
SnmpAdminString SnmpAdminString
FROM SNMP-FRAMEWORK-MIB FROM SNMP-FRAMEWORK-MIB
snmpTargetParamsName, snmpTargetAddrName snmpTargetParamsName, snmpTargetAddrName
FROM SNMP-TARGET-MIB FROM SNMP-TARGET-MIB
; ;
tlstmMIB MODULE-IDENTITY tlstmMIB MODULE-IDENTITY
LAST-UPDATED "200912300000Z" LAST-UPDATED "201001080000Z"
ORGANIZATION "ISMS Working Group" ORGANIZATION "ISMS Working Group"
CONTACT-INFO "WG-EMail: isms@lists.ietf.org CONTACT-INFO "WG-EMail: isms@lists.ietf.org
Subscribe: isms-request@lists.ietf.org Subscribe: isms-request@lists.ietf.org
Chairs: Chairs:
Juergen Schoenwaelder Juergen Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
Campus Ring 1 Campus Ring 1
28725 Bremen 28725 Bremen
Germany Germany
skipping to change at page 30, line 38 skipping to change at page 30, line 38
Sparta, Inc. Sparta, Inc.
P.O. Box 382 P.O. Box 382
Davis, CA 95617 Davis, CA 95617
USA USA
ietf@hardakers.net ietf@hardakers.net
" "
DESCRIPTION " DESCRIPTION "
The TLS Transport Model MIB The TLS Transport Model MIB
Copyright (c) 2009 IETF Trust and the persons identified as Copyright (c) 2010 IETF Trust and the persons identified as
the document authors. All rights reserved. the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this MIB module is part of RFC XXXX; This version of this MIB module is part of RFC XXXX;
see the RFC itself for full legal notices." see the RFC itself for full legal notices."
-- NOTE to RFC editor: replace XXXX with actual RFC number -- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document and remove this note -- for this document and remove this note
REVISION "200912300000Z" REVISION "201001080000Z"
DESCRIPTION "The initial version, published in RFC XXXX." DESCRIPTION "The initial version, published in RFC XXXX."
-- NOTE to RFC editor: replace XXXX with actual RFC number -- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document and remove this note -- for this document and remove this note
::= { snmpModules xxxx } ::= { snmpModules xxxx }
-- RFC Ed.: replace xxxx with IANA-assigned number and -- RFC Ed.: replace xxxx with IANA-assigned number and
-- remove this note -- remove this note
-- ************************************************ -- ************************************************
-- subtrees of the TLSTM-MIB -- subtrees of the TLSTM-MIB
skipping to change at page 44, line 40 skipping to change at page 44, line 40
In particular, a newly created row cannot be made active until In particular, a newly created row cannot be made active until
the corresponding tlstmParamsClientFingerprint column has the corresponding tlstmParamsClientFingerprint column has
been set. been set.
The tlstmParamsClientFingerprint object may not be modified The tlstmParamsClientFingerprint object may not be modified
while the value of this object is active(1). while the value of this object is active(1).
An attempt to set these objects while the value of An attempt to set these objects while the value of
tlstmParamsRowStatus is active(1) will result in tlstmParamsRowStatus is active(1) will result in
an inconsistentValue error. an inconsistentValue error."
If this row is deleted it has no effect on the corresponding
row in the targetParamsTable.
If the corresponding row in the targetParamsTable is deleted
then this row must be automatically removed."
::= { tlstmParamsEntry 3 } ::= { tlstmParamsEntry 3 }
-- Lists expected certificate fingerprints to be presented by a DTLS -- Lists expected certificate fingerprints to be presented by a DTLS
-- server -- server
tlstmAddrCount OBJECT-TYPE tlstmAddrCount OBJECT-TYPE
SYNTAX Unsigned32 SYNTAX Unsigned32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A count of the number of entries in the tlstmAddrTable" "A count of the number of entries in the tlstmAddrTable"
::= { tlstmCertificateMapping 7 } ::= { tlstmCertificateMapping 7 }
tlstmAddrTableLastChanged OBJECT-TYPE tlstmAddrTableLastChanged OBJECT-TYPE
SYNTAX TimeStamp SYNTAX TimeStamp
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of sysUpTime.0 when the tlstmAddrTable "The value of sysUpTime.0 when the tlstmAddrTable
was last modified through any means, or 0 if it has not been was last modified through any means, or 0 if it has not been
modified since the command responder was started." modified since the command responder was started."
skipping to change at page 48, line 7 skipping to change at page 47, line 48
In particular, a newly created row cannot be made active until In particular, a newly created row cannot be made active until
the corresponding tlstmAddrServerFingerprint column has been the corresponding tlstmAddrServerFingerprint column has been
set. set.
The tlstmAddrServerFingerprint object may not be modified The tlstmAddrServerFingerprint object may not be modified
while the value of this object is active(1). while the value of this object is active(1).
An attempt to set these objects while the value of An attempt to set these objects while the value of
tlstmAddrRowStatus is active(1) will result in tlstmAddrRowStatus is active(1) will result in
an inconsistentValue error. an inconsistentValue error."
If this row is deleted it has no effect on the corresponding
row in the targetAddrTable.
If the corresponding row in the targetAddrTable is deleted
then this row must be automatically removed."
::= { tlstmAddrEntry 4 } ::= { tlstmAddrEntry 4 }
-- ************************************************ -- ************************************************
-- tlstmNotifications - Notifications Information -- tlstmNotifications - Notifications Information
-- ************************************************ -- ************************************************
tlstmServerCertificateUnknown NOTIFICATION-TYPE tlstmServerCertificateUnknown NOTIFICATION-TYPE
OBJECTS { snmpTlstmSessionUnknownServerCertificate } OBJECTS { snmpTlstmSessionUnknownServerCertificate }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
 End of changes. 31 change blocks. 
71 lines changed or deleted 64 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/