< draft-ietf-isms-dtls-tm-02.txt   draft-ietf-isms-dtls-tm-03.txt >
ISMS W. Hardaker ISMS W. Hardaker
Internet-Draft Sparta, Inc. Internet-Draft Sparta, Inc.
Intended status: Standards Track December 8, 2009 Intended status: Standards Track December 23, 2009
Expires: June 11, 2010 Expires: June 26, 2010
Transport Layer Security (TLS) Transport Model for SNMP Transport Layer Security (TLS) Transport Model for SNMP
draft-ietf-isms-dtls-tm-02.txt draft-ietf-isms-dtls-tm-03.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 June 11, 2010. This Internet-Draft will expire on June 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
2. The Transport Layer Security Protocol . . . . . . . . . . . . 8 2. The Transport Layer Security Protocol . . . . . . . . . . . . 8
2.1. SNMP requirements of (D)TLS . . . . . . . . . . . . . . . 8
3. How the TLSTM fits into the Transport Subsystem . . . . . . . 9 3. How the TLSTM fits into the Transport Subsystem . . . . . . . 9
3.1. Security Capabilities of this Model . . . . . . . . . . . 10 3.1. Security Capabilities of this Model . . . . . . . . . . . 10
3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 12 3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 12
3.1.3. (D)TLS Sessions . . . . . . . . . . . . . . . . . . . 13 3.1.3. (D)TLS Sessions . . . . . . . . . . . . . . . . . . . 13
3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 13 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 13
3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14
4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 14 4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 15
4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 15 4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Provisioning for the Certificate . . . . . . . . . . . 15 4.1.1. Provisioning for the Certificate . . . . . . . . . . . 15
4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 16 4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 17 4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 17
4.3.2. SNMP Services for an Incoming Message . . . . . . . . 17 4.3.2. SNMP Services for an Incoming Message . . . . . . . . 18
4.4. Cached Information and References . . . . . . . . . . . . 18 4.4. Cached Information and References . . . . . . . . . . . . 18
4.4.1. TLS Transport Model Cached Information . . . . . . . . 18 4.4.1. TLS Transport Model Cached Information . . . . . . . . 19
5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19 4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 19
5.1. Procedures for an Incoming Message . . . . . . . . . . . . 19 4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 19
5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 19 4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 19
5.1.2. Transport Processing for Incoming SNMP Messages . . . 21 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20
5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 22 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 20
5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 23 5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 20
5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 26 5.1.2. Transport Processing for Incoming SNMP Messages . . . 22
6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 26 5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 23
6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 26 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 24
6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 27 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 27
6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 27 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 27
6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 27 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28
6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 27 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 28
6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 27 6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 28
6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 28 6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 28
7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 28 6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 28
6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29
6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29
7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29
8. Operational Considerations . . . . . . . . . . . . . . . . . . 50 8. Operational Considerations . . . . . . . . . . . . . . . . . . 50
8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 50 8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.2. Notification Receiver Credential Selection . . . . . . . . 50 8.2. Notification Receiver Credential Selection . . . . . . . . 51
8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 51 8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 51
8.4. Transport Considerations . . . . . . . . . . . . . . . . . 51 8.4. Transport Considerations . . . . . . . . . . . . . . . . . 52
9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 9. Security Considerations . . . . . . . . . . . . . . . . . . . 52
9.1. Certificates, Authentication, and Authorization . . . . . 52 9.1. Certificates, Authentication, and Authorization . . . . . 52
9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 52 9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 53
9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 53 9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 53
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
12.1. Normative References . . . . . . . . . . . . . . . . . . . 56 12.1. Normative References . . . . . . . . . . . . . . . . . . . 57
12.2. Informative References . . . . . . . . . . . . . . . . . . 57 12.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 58 Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 59
A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 59 A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 59
A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 59 A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 60
Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 60 Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 61
Appendix C. Target and Notificaton Configuration Example . . . . 61 Appendix C. Target and Notificaton Configuration Example . . . . 62
C.1. Configuring the Notification Generator . . . . . . . . . . 62 C.1. Configuring the Notification Generator . . . . . . . . . . 63
C.2. Configuring the Command Responder . . . . . . . . . . . . 62 C.2. Configuring the Command Responder . . . . . . . . . . . . 63
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 63 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
defined by [RFC3411] and enhanced by the Transport Subsystem defined by [RFC3411] and enhanced by the Transport Subsystem
[RFC5590]. It is also important to understand the terminology of the [RFC5590]. It is also important to understand the terminology of the
SNMPv3 architecture in order to understand where the Transport Model SNMPv3 architecture in order to understand where the Transport Model
described in this document fits into the architecture and how it described in this document fits into the architecture and how it
interacts with the other architecture subsystems. For a detailed interacts with the other architecture subsystems. For a detailed
overview of the documents that describe the current Internet-Standard overview of the documents that describe the current Internet-Standard
skipping to change at page 5, line 33 skipping to change at page 5, line 33
keying infrastructure [RFC5280]. While (D)TLS supports multiple keying infrastructure [RFC5280]. While (D)TLS supports multiple
authentication mechanisms, this document only discusses X.509 authentication mechanisms, this document only discusses X.509
certificate based authentication. Although other forms of certificate based authentication. Although other forms of
authentication are possible they are outside the scope of this authentication are possible they are outside the scope of this
specification. This transport model is designed to meet the security specification. This transport model is designed to meet the security
and operational needs of network administrators, operating in both and operational needs of network administrators, operating in both
environments where a connectionless (e.g. UDP or SCTP) transport is environments where a connectionless (e.g. UDP or SCTP) transport is
preferred and in environments where large quantities of data need to preferred and in environments where large quantities of data need to
be sent (e.g. over a TCP based stream). Both TLS and DTLS integrate be sent (e.g. over a TCP based stream). Both TLS and DTLS integrate
well into existing public keying infrastructures. This document well into existing public keying infrastructures. This document
defines supports sending of SNMP messages over TLS/TCP, DTLS/UDP and supports sending of SNMP messages over TLS/TCP, DTLS/UDP and DTLS/
DTLS/SCTP. SCTP.
This document also defines a portion of the Management Information This document also defines a portion of the Management Information
Base (MIB) for use with network management protocols. In particular Base (MIB) for use with network management protocols. In particular
it defines objects for managing the TLS Transport Model for SNMP. it defines objects for managing the TLS Transport Model for SNMP.
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC [RFC3410].
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP). accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58: module that is compliant to the SMIv2, which is described in STD 58:
[RFC2578], [RFC2579] and [RFC2580]. [RFC2578], [RFC2579] and [RFC2580].
The diagram shown below gives a conceptual overview of two SNMP The diagram shown below gives a conceptual overview of two SNMP
entities communicating using the TLS Transport Model. One entity entities communicating using the TLS Transport Model. One entity
contains a Command Responder and Notification Originator application, contains a command responder and notification originator application,
and the other a Command Generator and Notification Responder and the other a command generator and notification responder
application. It should be understood that this particular mix of application. It should be understood that this particular mix of
application types is an example only and other combinations are application types is an example only and other combinations are
equally valid. equally valid. Note: this diagram shows the Transport Security Model
(TSM) being used as the security model which is defined in [RFC5591].
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| Network | | Network |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
^ | ^ | ^ | ^ |
|Notifications |Commands |Commands |Notifications |Notifications |Commands |Commands |Notifications
+---|---------------------|--------+ +--|---------------|-------------+ +---|---------------------|--------+ +--|---------------|-------------+
| | V | | | V | | | V | | | V |
| +------------+ +------------+ | | +-----------+ +----------+ | | +------------+ +------------+ | | +-----------+ +----------+ |
| | (D)TLS | | (D)TLS | | | | (D)TLS | | (D)TLS | | | | (D)TLS | | (D)TLS | | | | (D)TLS | | (D)TLS | |
| | Service | | Service | | | | Service | | Service | | | | Service | | Service | | | | Service | | Service | |
| | (Client) | | (Server) | | | | (Client) | | (Server)| | | | (Client) | | (Server) | | | | (Client) | | (Server)| |
| +------------+ +------------+ | | +-----------+ +----------+ | | +------------+ +------------+ | | +-----------+ +----------+ |
| ^ ^ | | ^ ^ | | ^ ^ | | ^ ^ |
| | | | | | | | | | | | | | | |
| +--+----------+ | | +-+--------------+ | | +--+----------+ | | +-+--------------+ |
| +-----|---------+----+ | | +---|--------+----+ | | +-----|---------+----+ | | +---|--------+----+ |
| | V |LCD | +-------+ | | | V |LCD | +--------+ | | | V |LCD | +-------+ | | | V |LCD | +--------+ |
| | +------+ +----+ | | | | | +------+ +----+ | | | | | +------+ +----+ | | | | | +------+ +----+ | | |
| | | DTLS | <---------->| Cache | | | | | DTLS | <---->| Cache | | | | | TLS | <---------->| Cache | | | | | TLS | <---->| Cache | |
| | | TM | | | | | | | | TM | | | | | | | | TM | | | | | | | | TM | | | | |
| | +------+ | +-------+ | | | +------+ | +--------+ | | | +------+ | +-------+ | | | +------+ | +--------+ |
| |Transport Subsystem | ^ | | |Transport Sub. | ^ | | |Transport Subsystem | ^ | | |Transport Sub. | ^ |
| +--------------------+ | | | +-----------------+ | | | +--------------------+ | | | +-----------------+ | |
| ^ +----+ | | ^ | | | ^ +----+ | | ^ | |
| | | | | | | | | | | | | | | |
| v | | | V | | | v | | | V | |
| +-------+ +----------+ +-----+ | | | +-----+ +------+ +-----+ | | | +-------+ +----------+ +-----+ | | | +-----+ +------+ +-----+ | |
| | | |Message | |Sec. | | | | | | | MP | |Sec. | | | | | | |Message | |Sec. | | | | | | | MP | |Sec. | | |
| | Disp. | |Processing| |Sub- | | | | |Disp.| | Sub- | |Sub- | | | | | Disp. | |Processing| |Sub- | | | | |Disp.| | Sub- | |Sub- | | |
skipping to change at page 7, line 8 skipping to change at page 7, line 5
| | | | +-----+ | || || | | | | |+----+| || || | | | | | +-----+ | || || | | | | |+----+| || || |
| +-------+ | | |+---+| | | +-----+ | | |+---+| | | +-------+ | | |+---+| | | +-----+ | | |+---+| |
| ^ | | | | | | ^ | | | | | | ^ | | | | | | ^ | | | | |
| | +----------+ +-----+ | | | +------+ +-----+ | | | +----------+ +-----+ | | | +------+ +-----+ |
| +-+------------+ | | +-+------------+ | | +-+------------+ | | +-+------------+ |
| ^ ^ | | ^ ^ | | ^ ^ | | ^ ^ |
| | | | | | | | | | | | | | | |
| v v | | V V | | v v | | V V |
| +-------------+ +--------------+ | | +-----------+ +--------------+ | | +-------------+ +--------------+ | | +-----------+ +--------------+ |
| | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | |
| | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RESPONDER | | | | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RECEIVER | |
| | application | | applications | | | |application| | application | | | | application | | application | | | |application| | application | |
| +-------------+ +--------------+ | | +-----------+ +--------------+ | | +-------------+ +--------------+ | | +-----------+ +--------------+ |
| SNMP entity | | SNMP entity | | SNMP entity | | SNMP entity |
+----------------------------------+ +--------------------------------+ +----------------------------------+ +--------------------------------+
1.1. Conventions 1.1. Conventions
For consistency with SNMP-related specifications, this document For consistency with SNMP-related specifications, this document
favors terminology as defined in STD62 rather than favoring favors terminology as defined in STD 62, rather than favoring
terminology that is consistent with non-SNMP specifications. This is terminology that is consistent with non-SNMP specifications. This is
consistent with the IESG decision to not require the SNMPv3 consistent with the IESG decision to not require the SNMPv3
terminology be modified to match the usage of other non-SNMP terminology be modified to match the usage of other non-SNMP
specifications when SNMPv3 was advanced to Full Standard. specifications when SNMPv3 was advanced to Full Standard.
"Authentication" in this document typically refers to the English
meaning of "serving to prove the authenticity of" the message, not
data source authentication or peer identity authentication.
The terms "manager" and "agent" are not used in this document
because, in the RFC 3411 architecture, all SNMP entities have the
capability of acting as manager, agent, or both depending on the SNMP
application types supported in the implementation. Where distinction
is required, the application names of command generator, command
responder, notification originator, notification receiver, and proxy
forwarder are used. See "SNMP Applications" [RFC3413] for further
information.
Authentication in this document typically refers to the English Authentication in this document typically refers to the English
meaning of "serving to prove the authenticity of" the message, not meaning of "serving to prove the authenticity of" the message, not
data source authentication or peer identity authentication. data source authentication or peer identity authentication.
The terms "manager" and "agent" are not used in this document,
because in the RFC 3411 architecture [RFC3411], all SNMP entities
have the capability of acting in either manager or agent or in both
roles depending on the SNMP application types supported in the
implementation. Where distinction is required, the application names
of command generator, command responder, notification originator,
Notification Receiver, and proxy forwarder are used. See "SNMP
Applications" [RFC3413] for further information.
Large portions of this document simultaneously refer to both TLS and Large portions of this document simultaneously refer to both TLS and
DTLS when discussing TLSTM components that function equally with DTLS when discussing TLSTM components that function equally with
either protocol. "(D)TLS" is used in these places to indicate that either protocol. "(D)TLS" is used in these places to indicate that
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.
The terms "manager" and "agent" are not used in this document,
because in the RFC 3411 architecture [RFC3411], all SNMP entities
have the capability of acting in either manager or agent or in both
roles depending on the SNMP application types supported in the
implementation. Where distinction is required, the application names
of Command Generator, Command Responder, Notification Originator,
Notification Receiver, and Proxy Forwarder are used. See "SNMP
Applications" [RFC3413] for further information.
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. Either SNMP entity may
act as client or as server. act as client or as server.
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
skipping to change at page 8, line 33 skipping to change at page 8, line 42
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. The Transport Layer Security Protocol 2. The Transport Layer Security Protocol
(D)TLS provides authentication, data message integrity, and privacy (D)TLS provides authentication, data message integrity, and privacy
at the transport layer. (See [RFC4347]) at the transport layer. (See [RFC4347])
The primary goals of the TLS Transport Model are to provide privacy, The primary goals of the TLS Transport Model are to provide privacy,
source authentication and data integrity between two communicating peer identity authentication and data integrity between two
SNMP entities. The TLS and DTLS protocols provide a secure transport communicating SNMP entities. The TLS and DTLS protocols provide a
upon which the TLSTM is based. An overview of (D)TLS can be found in secure transport upon which the TLSTM is based. An overview of
section Appendix A. Please refer to [RFC5246] and [RFC4347] for (D)TLS can be found in section Appendix A. Please refer to [RFC5246]
complete descriptions of the protocols. and [RFC4347] for complete descriptions of the protocols.
2.1. SNMP requirements of (D)TLS
To properly support the SNMP over TLS Transport Model, the (D)TLS
implementation requires the following:
o The TLS Transport Model MUST support authentication of both the
server and the client.
o The TLS Transport Model SHOULD support the message encryption to
protect sensitive data from eavesdropping attacks.
3. How the TLSTM fits into the Transport Subsystem 3. How the TLSTM fits into the Transport Subsystem
A transport model is a component of the Transport Subsystem. The TLS A transport model is a component of the Transport Subsystem. The TLS
Transport Model thus fits between the underlying (D)TLS transport Transport Model thus fits between the underlying (D)TLS transport
layer and the message dispatcher [RFC3411] component of the SNMP layer and the Message Dispatcher [RFC3411] component of the SNMP
engine and the Transport Subsystem. engine and the Transport Subsystem.
The TLS Transport Model will establish a session between itself and The TLS Transport Model will establish a session between itself and
the TLS Transport Model of another SNMP engine. The sending the TLS Transport Model of another SNMP engine. The sending
transport model passes unprotected messages from the dispatcher to transport model passes unencrypted and unauthenticated messages from
(D)TLS to be protected, and the receiving transport model accepts the Dispatcher to (D)TLS to be encrypted and authenticated, and the
decrypted and authenticated/integrity-checked incoming messages from receiving transport model accepts decrypted and authenticated/
(D)TLS and passes them to the dispatcher. integrity-checked incoming messages from (D)TLS and passes them to
the Dispatcher.
After a TLS Transport Model session is established, SNMP messages can After a TLS Transport Model session is established, SNMP messages can
conceptually be sent through the session from one SNMP message conceptually be sent through the session from one SNMP message
dispatcher to another SNMP message dispatcher. If multiple SNMP Dispatcher to another SNMP Message Dispatcher. If multiple SNMP
messages are needed to be passed between two SNMP applications they messages are needed to be passed between two SNMP applications they
SHOULD be passed through the same session. A TLSTM implementation MAY be passed through the same session. A TLSTM implementation
engine MAY choose to close a (D)TLS session to conserve resources. engine MAY choose to close a (D)TLS session to conserve resources.
The TLS Transport Model of an SNMP engine will perform the The TLS Transport Model of an SNMP engine will perform the
translation between (D)TLS-specific security parameters and SNMP- translation between (D)TLS-specific security parameters and SNMP-
specific, model-independent parameters. specific, model-independent parameters.
The diagram below depicts where the TLS Transport Model fits into the The diagram below depicts where the TLS Transport Model fits into the
architecture described in RFC3411 and the Transport Subsystem: architecture described in RFC3411 and the Transport Subsystem:
+------------------------------+ +------------------------------+
skipping to change at page 11, line 11 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 authentication of the Command Generator, The TLSTM provides for verification of the identity of the (D)TLS
Command Responder, Notification Generator, Notification Responder server through the use of the (D)TLS protocol and the X.509
and Proxy Forwarder through the use of X.509 certificates. certificates. The TLS Transport Model MUST support
authentication of both the server and the client.
The masquerade threat can be mitigated against by using an
appropriate Access Control Model (ACM) such as the View-based
Access Control Module (VACM) [RFC3415].
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.
(D)TLS provides replay protection with a MAC that includes a (D)TLS provides replay protection with a MAC that includes a
sequence number. Since UDP provides no sequencing ability DTLS sequence number. Since UDP provides no sequencing ability DTLS
uses a sliding window protocol with the sequence number for uses a sliding window protocol with the sequence number for
replay protection (see [RFC4347]). replay protection (see [RFC4347]).
4. Disclosure - The disclosure threat is the danger of eavesdropping 4. Disclosure - The disclosure threat is the danger of eavesdropping
on the exchanges between SNMP engines. on the exchanges between SNMP engines.
The TLS and DTLS protocols provide support for data privacy (D)TLS provides protection against the disclosure of information
through TLS cipher suites that provide encryption. to unauthorized recipients or eavesdroppers by allowing for
encryption of all traffic between SNMP engines. The TLS
Transport Model SHOULD support the message encryption to protect
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 it is 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
exchange for every DTLS handshake, but in environments where an exchange for every DTLS handshake, but in environments where an
overload on server side resources is detectable it is RECOMMENDED overload on server side resources is detectable by the
that the cookie exchange is utilized. implementation it is RECOMMENDED that the cookie exchange is
utilized by the implementation.
See Section 9 for more detail on the security considerations See Section 9 for more detail on the security considerations
associated with the DTLSTM and these security threats. associated with the TLSTM and these security threats.
3.1.2. Message Protection 3.1.2. Message Protection
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, and the type and address associated with an
incoming message. The TLS Transport Model provides this information incoming message. The TLS Transport Model provides the identity and
to (D)TLS for an outgoing message. 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 12, line 50 skipping to change at page 13, line 4
If a suitable interface between the TLS Transport Model and the If a suitable interface between the TLS Transport Model and the
(D)TLS Handshake Protocol is implemented to allow the selection of (D)TLS Handshake Protocol is implemented to allow the selection of
security level dependent algorithms (for example a security level to security level dependent algorithms (for example a security level to
cipher_suites mapping table) then different security levels may be cipher_suites mapping table) then different security levels may be
utilized by the application. utilized by the application.
The authentication, integrity and privacy algorithms used by the The authentication, integrity and privacy algorithms used by the
(D)TLS Protocols may vary over time as the science of cryptography (D)TLS Protocols may vary over time as the science of cryptography
continues to evolve and the development of (D)TLS continues over continues to evolve and the development of (D)TLS continues over
time. Implementers are encouraged to plan for changes in operator time. Implementers are encouraged to plan for changes in operator
trust of particular algorithms and implementations should offer trust of particular algorithms. Implementations should offer
configuration settings for mapping algorithms to SNMPv3 security configuration settings for mapping algorithms to SNMPv3 security
levels. levels.
3.1.3. (D)TLS Sessions 3.1.3. (D)TLS Sessions
(D)TLS sessions are opened by the TLS Transport Model during the (D)TLS sessions are opened by the TLS Transport Model during the
elements of procedure for an outgoing SNMP message. Since the sender elements of procedure for an outgoing SNMP message. Since the sender
of a message initiates the creation of a (D)TLS session if needed, of a message initiates the creation of a (D)TLS session if needed,
the (D)TLS session will already exist for an incoming message. the (D)TLS session will already exist for an incoming message.
skipping to change at page 13, line 23 skipping to change at page 13, line 26
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 tlsSnmpSessionID parameters MUST have a locally-chosen unique tlstmSessionID
associated for active sessions. For further information see associated for active sessions. For further information see
Section 5. TLS and DTLS over SCTP sessions, on the other hand, do Section 5. TLS and DTLS over SCTP sessions, on the other hand, do
not require a unique pairing of address and port attributes since not require a unique pairing of address and port attributes since
their lower layer protocols (TCP and SCTP) already provide adequate their lower layer protocols (TCP and SCTP) already provide adequate
session framing. But they must still provide a unique session framing. But they must still provide a unique tlstmSessionID
tlsSnmpSessionID for referencing the session. for referencing the session.
The tlsSnmpSessionID MAY be the same as the (D)TLS internal SessionID The tlstmSessionID MAY be the same as the (D)TLS internal SessionID
but caution must be exercised since the (D)TLS internal SessionID may but caution must be exercised since the (D)TLS internal SessionID may
change over the life of the connection as seen by the TLSTM (for change over the life of the connection as seen by the TLSTM (for
example during renegotiation). The tlsSnmpSessionID identifier MUST example during renegotiation). The tlstmSessionID identifier MUST
NOT change during the entire duration of the connection from the NOT change during the entire duration of the connection from the
TLSTM's perspective. TLSTM's perspective.
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 (i.e., securityLevel, for the TLS Transport Model and security model (e.g..,
tmSecurityName, transportDomain, transportAddress). The transport- tmSecurityLevel, tmSecurityName, transportDomain, transportAddress).
related and (D)TLS-security-related information, including the The transport- related and (D)TLS-security-related information,
authenticated identity, are stored in a cache referenced by including the authenticated identity, are stored in a cache
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.
The elements of procedure in Section 5 discuss these concepts in much The elements of procedure in Section 5 discuss these concepts in much
greater detail. greater detail.
3.3. Notifications and Proxy 3.3. Notifications and Proxy
(D)TLS sessions may be initiated by (D)TLS clients on behalf of (D)TLS sessions may be initiated by (D)TLS clients on behalf of
command generators, notification originators or proxy forwarders. command generators, notification originators, proxy forwarders or
Command generators are frequently operated by a human, but other applications. Command generators are frequently operated by a
notification originators and proxy forwarders are usually unmanned human, but notification originators and proxy forwarders are usually
automated processes. The targets to whom notifications should be unmanned automated processes. The targets to whom notifications and
sent is typically determined and configured by a network proxied requests should be sent is typically determined and
administrator. configured by a network administrator.
The SNMP-TARGET-MIB module [RFC3413] contains objects for defining The SNMP-TARGET-MIB module [RFC3413] contains objects for defining
management targets, including transportDomain, transportAddress, management targets, including transportDomain, transportAddress,
securityName, securityModel, and securityLevel parameters, for securityName, securityModel, and securityLevel parameters, for
Notification Generator, Proxy Forwarder, and SNMP-controllable notification generator, proxy forwarder, and SNMP-controllable
Command Generator applications. Transport domains and transport command generator applications. Transport domains and transport
addresses are configured in the snmpTargetAddrTable, and the addresses are configured in the snmpTargetAddrTable, and the
securityModel, securityName, and securityLevel parameters are securityModel, securityName, and securityLevel parameters are
configured in the snmpTargetParamsTable. This document defines a MIB configured in the snmpTargetParamsTable. This document defines a MIB
module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to
specify a (D)TLS client-side certificate to use for the connection. specify a (D)TLS client-side certificate to use for the connection.
When configuring a (D)TLS target, the snmpTargetAddrTDomain and When configuring a (D)TLS target, the snmpTargetAddrTDomain and
snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be
set to the snmpTLSTCPDomain, snmpDTLSUDPDomain, or snmpDTLSSCTPDomain set to the snmpTLSTCPDomain, snmpDTLSUDPDomain, or snmpDTLSSCTPDomain
object and an appropriate snmpTLSAddress value. The object and an appropriate snmpTLSAddress value. When used with the
snmpTargetParamsMPModel column of the snmpTargetParamsTable should be SNMPv3 message processing model, the snmpTargetParamsMPModel column
set to a value of 3 to indicate the SNMPv3 message processing model. of the snmpTargetParamsTable should be set to a value of 3. The
The snmpTargetParamsSecurityName should be set to an appropriate snmpTargetParamsSecurityName should be set to an appropriate
securityName value and the tlstmParamsClientFingerprint parameter of securityName value and the tlstmParamsClientFingerprint parameter of
the tlstmParamsTable should be set a value that refers to a locally the tlstmParamsTable should be set a value that refers to a locally
held certificate to be used. Other parameters, for example held certificate to be used. Other parameters, for example
cryptographic configuration such as cipher suites to use, must come cryptographic configuration such as cipher suites to use, must come
from configuration mechanisms not defined in this document. The from configuration mechanisms not defined in this document. The
securityName defined in the snmpTargetParamsSecurityName column will securityName defined in the snmpTargetParamsSecurityName column will
be used by the access control model to authorize any notifications be used by the access control model to authorize any notifications
that need to be sent. that need to be sent.
4. Elements of the Model 4. Elements of the Model
This section contains definitions required to realize the (D)TLS This section contains definitions required to realize the (D)TLS
Transport Model defined by this document. Transport Model defined by this document.
4.1. X.509 Certificates 4.1. X.509 Certificates
(D)TLS makes use of X.509 certificates for authentication of both (D)TLS can make use of X.509 certificates for authentication of both
sides of the transport. This section discusses the use of sides of the transport. This section discusses the use of X.509
certificates in the TLSTM. A brief overview of X.509 certificate certificates in the TLSTM. A brief overview of X.509 certificate
infrastructure can be found in Appendix B. infrastructure can be found in Appendix B.
While (D)TLS supports multiple authentication mechanisms, this While (D)TLS supports multiple authentication mechanisms, this
document only discusses X.509 certificate based authentication. document only discusses X.509 certificate based authentication.
Although other forms of authentication are possible they are outside Although other forms of authentication are possible they are outside
the scope of this specification. the scope of this specification. TLSTM implementations are REQUIRED
to support X.509 certificates.
4.1.1. Provisioning for the Certificate 4.1.1. Provisioning for the Certificate
Authentication using (D)TLS will require that SNMP entities are Authentication using (D)TLS will require that SNMP entities are
provisioned with certificates, which are signed by trusted provisioned with certificates, which are signed by trusted
certificate authorities. Furthermore, SNMP entities will most certificate authorities (possibly the certificate itself).
commonly need to be provisioned with root certificates which Furthermore, SNMP entities will most commonly need to be provisioned
represent the list of trusted certificate authorities that an SNMP with root certificates which represent the list of trusted
entity can use for certificate verification. SNMP entities SHOULD certificate authorities that an SNMP entity can use for certificate
also be provisioned with a X.509 certificate revocation mechanism verification. SNMP entities SHOULD also be provisioned with a X.509
which can be used to verify that a certificate has not been revoked. certificate revocation mechanism which can be used to verify that a
Trusted public keys from either CA certificates and/or self-signed certificate has not been revoked. Trusted public keys from either CA
certificates, must be installed through a trusted out of band certificates and/or self-signed certificates, MUST be installed
mechanism into the server and its authenticity MUST be verified through a trusted out of band mechanism into the server and its
before access is granted. authenticity MUST be verified before access is granted.
Having received a certificate from a connecting TLSTM client, the Having received a certificate from a connecting TLSTM client, the
authenticated tmSecurityName of the principal is derived up using the authenticated tmSecurityName of the principal is derived using the
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 Implementations MAY choose to discard any connections for which no
potential tlstmCertToTSNTable mapping exists before performing potential tlstmCertToTSNTable mapping exists before performing
certificate verification to avoid expending computational resources certificate verification to avoid expending computational resources
associated with certificate verification. associated with certificate verification.
The typical enterprise configuration will map a "subjectAltName" Enterprise configurations are encouraged to map a "subjectAltName"
component of the tbsCertificate to the TLSTM specific tmSecurityName. component of the X.509 certificate to the TLSTM specific
The authenticated identity can be obtained by the TLS Transport Model tmSecurityName. The authenticated identity can be obtained by the
by extracting the subjectAltName(s) from the peer's certificate. The TLS Transport Model by extracting the subjectAltName(s) from the
receiving application will then have an appropriate tmSecurityName peer's certificate. The receiving application will then have an
for use by other SNMPv3 components like an access control model. appropriate tmSecurityName for use by other SNMPv3 components like an
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.
This tmSecurityName may be later translated from a TLSTM specific This tmSecurityName may be later translated from a TLSTM specific
tmSecurityName to a SNMP engine securityName by the security model. tmSecurityName to a SNMP engine securityName by the security model.
A security model, like the TSM security model [RFC5591], may perform A security model, like the TSM security model [RFC5591], may perform
an identity mapping or a more complex mapping to derive the an identity mapping or a more complex mapping to derive the
securityName from the tmSecurityName offered by the TLS Transport securityName from the tmSecurityName offered by the TLS Transport
Model. Model.
skipping to change at page 16, line 42 skipping to change at page 16, line 49
As stated in Section 4.1.1 of [RFC4347], each DTLS record must fit As stated in Section 4.1.1 of [RFC4347], each DTLS record must fit
within a single DTLS datagram. The TLSTM SHOULD prohibit SNMP within a single DTLS datagram. The TLSTM SHOULD prohibit SNMP
messages from being sent that exceeds the maximum DTLS message size. messages from being sent that exceeds the maximum DTLS message size.
The TLSTM implementation SHOULD return an error when the DTLS message The TLSTM implementation SHOULD return an error when the DTLS message
size would be exceeded and the message won't be sent. size would be exceeded and the message won't be sent.
4.3. SNMP Services 4.3. SNMP Services
This section describes the services provided by the TLS Transport This section describes the services provided by the TLS Transport
Model with their inputs and outputs. The services are between the Model with their inputs and outputs. The services are between the
Transport Model and the dispatcher. Transport Model and the Dispatcher.
The services are described as primitives of an abstract service The services are described as primitives of an abstract service
interface (ASI) and the inputs and outputs are described as abstract interface (ASI) and the inputs and outputs are described as abstract
data elements as they are passed in these abstract service data elements as they are passed in these abstract service
primitives. primitives.
4.3.1. SNMP Services for an Outgoing Message 4.3.1. SNMP Services for an Outgoing Message
The dispatcher passes the information to the TLS Transport Model The Dispatcher passes the information to the TLS Transport Model
using the ASI defined in the transport subsystem: using the ASI defined in the transport subsystem:
statusInformation = statusInformation =
sendMessage( sendMessage(
IN destTransportDomain -- transport domain to be used IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length IN outgoingMessageLength -- its length
IN tmStateReference -- reference to transport state IN tmStateReference -- reference to transport state
) )
skipping to change at page 17, line 29 skipping to change at page 17, line 32
The abstract data elements returned from or passed as parameters into The abstract data elements returned from or passed as parameters into
the abstract service primitives are as follows: the abstract service primitives are as follows:
statusInformation: An indication of whether the passing of the statusInformation: An indication of whether the passing of the
message was successful. If not, it is an indication of the message was successful. If not, it is an indication of the
problem. problem.
destTransportDomain: The transport domain for the associated destTransportDomain: The transport domain for the associated
destTransportAddress. The Transport Model uses this parameter to destTransportAddress. The Transport Model uses this parameter to
determine the transport type of the associated determine the transport type of the associated
destTransportAddress. This parameter may also be used by the destTransportAddress. This document specifies the snmpTLSDomain,
transport subsystem to route the message to the appropriate the snmpDTLSUDPDomain and the snmpDTLSSCTPDomain" transport
Transport Model. This document specifies the snmpTLSDomain, the domains.
snmpDTLSUDPDomain and the snmpDTLSSCTPDomain" transport domains.
destTransportAddress: The transport address of the destination TLS destTransportAddress: The transport address of the destination TLS
Transport Model in a format specified by the SnmpTLSAddress Transport Model in a format specified by the SnmpTLSAddress
TEXTUAL-CONVENTION. TEXTUAL-CONVENTION.
outgoingMessage: The outgoing message to send to (D)TLS for outgoingMessage: The outgoing message to send to (D)TLS for
encapsulation. encapsulation.
outgoingMessageLength: The length of the outgoingMessage field. outgoingMessageLength: The length of the outgoingMessage field.
tmStateReference: A handle/reference to tmSecurityData to be used tmStateReference: A handle/reference to tmState to be used when
when securing outgoing messages. securing outgoing messages.
4.3.2. SNMP Services for an Incoming Message 4.3.2. SNMP Services for an Incoming Message
The TLS Transport Model processes the received message from the The TLS Transport Model processes the received message from the
network using the (D)TLS service and then passes it to the dispatcher network using the (D)TLS service and then passes it to the Dispatcher
using the following ASI: using the following ASI:
statusInformation = statusInformation =
receiveMessage( receiveMessage(
IN transportDomain -- origin transport domain IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address IN transportAddress -- origin transport address
IN incomingMessage -- the message received IN incomingMessage -- the message received
IN incomingMessageLength -- its length IN incomingMessageLength -- its length
IN tmStateReference -- reference to transport state IN tmStateReference -- reference to transport state
) )
skipping to change at page 18, line 48 skipping to change at page 19, line 7
When performing SNMP processing, there are two levels of state When performing SNMP processing, there are two levels of state
information that may need to be retained: the immediate state linking information that may need to be retained: the immediate state linking
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 TLSTM has no specific responsibilities regarding the cached The TLS Transport Model has specific responsibilities regarding the
information beyond those discussed in "Transport Subsystem for the cached information. See the Elements of Procedure in Section 5 for
Simple Network Management Protocol" [RFC5590]. detailed processing instructions on the use of the tmStateReference
fields by the TLS Transport Model
4.4.1.1. tmSecurityName
The tmSecurityName MUST be a human-readable name (in snmpAdminString
format) representing the identity that has been set according to the
procedures in Section 5. The tmSecurityName MUST be constant for all
traffic passing through an TLSTM session. Messages MUST NOT be sent
through an existing (D)TLS session that was established using a
different tmSecurityName.
On the (D)TLS server side of a connection the tmSecurityName is
derived using the procedures described in Section 5.3 and the TLSTM-
MIB's tlstmCertToTSNTable DESCRIPTION clause.
On the (D)TLS client side of a connection the tmSecurityName is
presented to the TLS Transport Model by the application (possibly
because of configuration specified in the SNMP-TARGET-MIB).
The securityName MAY be derived from the tmSecurityName by a Security
Model and MAY be used to configure notifications and access controls
in MIB modules. Transport Models SHOULD generate a predictable
tmSecurityName so operators will know what to use when configuring
MIB modules that use securityNames derived from tmSecurityNames.
4.4.1.2. tmSessionID
The tmSessionID MUST be recorded per message at the time of receipt.
When tmSameSecurity is set, the recorded tmSessionID can be used to
determine whether the (D)TLS session available for sending a
corresponding outgoing message is the same (D)TLS session as was used
when receiving the incoming message (e.g., a response to a request).
4.4.1.3. Session State
The per-session state that is referenced by tmStateReference may be
saved across multiple messages in a Local Configuration Datastore.
Additional session/connection state information might also be stored
in a Local Configuration Datastore.
5. Elements of Procedure 5. Elements of Procedure
Abstract service interfaces have been defined by [RFC3411] and Abstract service interfaces have been defined by [RFC3411] and
further augmented by [RFC5590] to describe the conceptual data flows further augmented by [RFC5590] to describe the conceptual data flows
between the various subsystems within an SNMP entity. The TLSTM uses between the various subsystems within an SNMP entity. The TLSTM uses
some of these conceptual data flows when communicating between some of these conceptual data flows when communicating between
subsystems. subsystems.
To simplify the elements of procedure, the release of state To simplify the elements of procedure, the release of state
skipping to change at page 19, line 45 skipping to change at page 20, line 45
describes the needed steps for de-multiplexing multiple DTLS describes the needed steps for de-multiplexing multiple DTLS
sessions, which is specifically needed for DTLS over UDP sessions. sessions, which is specifically needed for DTLS over UDP sessions.
Section 5.1.2 describes the steps specific to transport processing Section 5.1.2 describes the steps specific to transport processing
once the (D)TLS processing has been completed. It is assumed that once the (D)TLS processing has been completed. It is assumed that
TLS and DTLS/SCP protocol implementations already provide appropriate TLS and DTLS/SCP protocol implementations already provide appropriate
message demultiplexing and only the processing steps in Section 5.1.2 message demultiplexing and only the processing steps in Section 5.1.2
are needed. are needed.
5.1.1. DTLS Processing for Incoming Messages 5.1.1. DTLS Processing for Incoming Messages
DTLS is significantly different in terms of session handling than DTLS over UDP is significantly different in terms of session handling
when TLS or DTLS is run over session based streaming protocols like than when TLS or DTLS is run over session based streaming protocols
TCP or SCTP. Specifically, the DTLS protocol, when run over UDP, like TCP or SCTP. Specifically, the DTLS protocol, when run over
does not have a session identifier that allows implementations to UDP, does not have a session identifier that allows implementations
determine through what session a packet arrived. DTLS over SCTP and to determine through which session a packet arrived. It is always
TLS over TCP streams have built in session demultiplexing and thus critical, however, that implementations be able to derive a
the steps in this section are not necessary for those protocol tlstmSessionID from any session demultiplexing process. When
combinations. It is always critical, however, that implementations establishing a new session implementations MUST use a different UDP
be able to derive a tlsSnmpSessionID from any session demultiplexing source port number for each connection to a remote destination IP-
process. address/port-number combination to ensure the remote entity can
easily disambiguate between multiple sessions from a host to the same
port on a server.
A process for demultiplexing multiple DTLS sessions arriving over UDP A process for demultiplexing multiple DTLS sessions arriving over UDP
must be incorporated into the procedures for processing an incoming must be incorporated into the procedures for processing an incoming
message. The steps in this section describe one possible method to message. The steps in this section describe one possible method to
accomplish this, although any implementation-dependent method should accomplish this, although any implementation-dependent method should
be suitable as long as the results are deterministic. The important be suitable as long as the results are deterministic. The important
output results from the steps in this process are the output results from the steps in this process are the
transportDomain, the transportAddress, the wholeMessage, the transportDomain, the transportAddress, the wholeMessage, the
wholeMessageLength, and a unique implementation-dependent session wholeMessageLength, and a unique implementation-dependent session
identifier (tlsSnmpSessionID). identifier (tlstmSessionID).
This demultiplexing procedure assumes that upon session establishment This demultiplexing procedure assumes that upon session establishment
an entry in a local transport mapping table is created in the an entry in a local transport mapping table is created in the
Transport Model's Local Configuration Datastore (LCD). The transport Transport Model's Local Configuration Datastore (LCD). The transport
mapping table's entry should map a unique combination of the remote mapping table's entry should map a unique combination of the remote
address, remote port number, local address and local port number to address, remote port number, local address and local port number to
an implementation-dependent tlsSnmpSessionID. an implementation-dependent tlstmSessionID.
1) The TLS Transport Model examines the raw UDP message, in an 1) The TLS Transport Model examines the raw UDP message, in an
implementation-dependent manner. implementation-dependent manner.
2) The TLS Transport Model queries the LCD using the transport 2) The TLS Transport Model queries the LCD using the transport
parameters (source and destination addresses and ports) to parameters (source and destination addresses and ports) to
determine if a session already exists and its tlsSnmpSessionID. determine if a session already exists and its tlstmSessionID.
If a matching entry in the LCD does not exist then the message is If a matching entry in the LCD does not exist then the message is
passed to DTLS for processing without a corresponding passed to DTLS for processing without a corresponding
tlsSnmpSessionID. The incoming packet may result in a new tlstmSessionID. The incoming packet may result in a new session
session being established if the receiving entity is acting as a being established if the receiving entity is acting as a DTLS
DTLS server. If DTLS returns success then stop processing of server. If DTLS returns success then stop processing of this
this message. If DTLS returns an error then and the the message. If DTLS returns an error then increment the
tlstmSessionNoAvailableSessions counter and stop processing the snmpTlstmSessionNoSessions counter and stop processing the
message. message.
Note that an entry would already exist if the client and server's Note that an entry would already exist if the client and server's
session establishment procedures had been successfully completed session establishment procedures had been successfully completed
previously (as described both above and in Section 5.3) even if previously (as described both above and in Section 5.3) even if
no message had yet been sent through the newly established no message had yet been sent through the newly established
session. An entry may not exist, however, if a "rogue" message session. An entry may not exist, however, if a message not
was routed to the SNMP entity by mistake. An entry might also be intended the SNMP entity was routed to it by mistake. An entry
missing because of a "broken" session (see operational might also be missing because of a "broken" session (see
considerations). operational considerations).
3) Retrieve the tlsSnmpSessionID from the LCD. 3) Retrieve the tlstmSessionID from the LCD.
4) The UDP packet and the tlsSnmpSessionID 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) (D)TLS should return an incomingMessage and an
incomingMessageLength. These results and the tlsSnmpSessionID incomingMessageLength. These results and the tlstmSessionID are
are used below in the Section 5.1.2 to complete the processing of used below in the Section 5.1.2 to complete the processing of the
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
complete and singular. For example, multiple SNMP messages can be complete and single. For example, multiple SNMP messages can be
passed through a single DTLS message and partial SNMP messages may be passed through a single DTLS message and partial SNMP messages may be
received from a TLS stream. These steps describe the processing of a received from a TLS stream. These steps describe the processing of a
singular SNMP message after it has been delivered from the (D)TLS singular SNMP message after it has been delivered from the (D)TLS
stream. stream.
Create a tmStateReference cache for the subsequent reference and Create a tmStateReference cache for the subsequent reference and
assign the following values within it: assign the following values within it:
tmTransportDomain = snmpTLSTCPDomain, snmpDTLSUDPDomain or tmTransportDomain = snmpTLSTCPDomain, snmpDTLSUDPDomain or
snmpDTLSSCTPDomain as appropriate. snmpDTLSSCTPDomain as appropriate.
tmTransportAddress = The address the message originated from. tmTransportAddress = The address the message originated from.
tmSecurityLevel = The derived tmSecurityLevel for the session, as tmSecurityLevel = The derived tmSecurityLevel for the session, as
discussed in Section 3.1.2 and Section 5.3. discussed in Section 3.1.2 and Section 5.3.
tmSecurityName = The derived tmSecurityName for the session as tmSecurityName = The derived tmSecurityName for the session as
discussed in Section 5.3. This value MUST be constant during the discussed in Section 5.3. This value MUST be constant during the
lifetime of the (D)TLS session. lifetime of the (D)TLS session.
tmSessionID = The tlsSnmpSessionID, which MUST be a unique session tmSessionID = The tlstmSessionID, which MUST be a unique session
identifier for this (D)TLS connection. The contents and format of identifier for this (D)TLS connection. The contents and format of
this identifier are implementation-dependent as long as it is this identifier are implementation-dependent as long as it is
unique to the session. A session identifier MUST NOT be reused unique to the session. A session identifier MUST NOT be reused
until all references to it are no longer in use. The tmSessionID until all references to it are no longer in use. The tmSessionID
is equal to the tlsSnmpSessionID discussed in Section 5.1.1. is equal to the tlstmSessionID discussed in Section 5.1.1.
tmSessionID refers to the session identifier when stored in the tmSessionID refers to the session identifier when stored in the
tmStateReference and tlsSnmpSessionID refers to the session tmStateReference and tlstmSessionID refers to the session
identifier when stored in the LCD. They MUST always be equal when identifier when stored in the LCD. They MUST always be equal when
processing a given session's traffic. processing a given session's traffic.
The wholeMessage and the wholeMessageLength are assigned values from The wholeMessage and the wholeMessageLength are assigned values from
the incomingMessage and incomingMessageLength values from the (D)TLS the incomingMessage and incomingMessageLength values from the (D)TLS
processing. processing.
The TLS Transport Model passes the transportDomain, transportAddress, The TLS Transport Model passes the transportDomain, transportAddress,
wholeMessage, and wholeMessageLength to the dispatcher using the wholeMessage, and wholeMessageLength to the Dispatcher using the
receiveMessage ASI: receiveMessage ASI:
statusInformation = statusInformation =
receiveMessage( receiveMessage(
IN transportDomain -- snmpTLSTCPDomain, snmpDTLSUDPDomain, IN transportDomain -- snmpTLSTCPDomain, snmpDTLSUDPDomain,
-- or snmpDTLSSCTPDomain -- or snmpDTLSSCTPDomain
IN transportAddress -- address for the received message IN transportAddress -- address for the received message
IN wholeMessage -- the whole SNMP message from (D)TLS IN wholeMessage -- the whole SNMP message from (D)TLS
IN wholeMessageLength -- the length of the SNMP message IN wholeMessageLength -- the length of the SNMP message
IN tmStateReference -- transport info IN tmStateReference -- transport info
) )
5.2. Procedures for an Outgoing SNMP Message 5.2. Procedures for an Outgoing SNMP Message
The dispatcher sends a message to the TLS Transport Model using the The Dispatcher sends a message to the TLS Transport Model using the
following ASI: following ASI:
statusInformation = statusInformation =
sendMessage( sendMessage(
IN destTransportDomain -- transport domain to be used IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length IN outgoingMessageLength -- its length
IN tmStateReference -- transport info IN tmStateReference -- transport info
) )
This section describes the procedure followed by the TLS Transport This section describes the procedure followed by the TLS Transport
Model whenever it is requested through this ASI to send a message. Model whenever it is requested through this ASI to send a message.
1) Extract the tmSessionID, tmTransportAddress, tmSecurityName, 1) If tmStateReference does not refer to a cache containing values
tmRequestedSecurityLevel, and tmSameSecurity values from the for tmTransportDomain, tmTransportAddress, tmSecurityName,
tmStateReference. Note: The tmSessionID value may be undefined tmRequestedSecurityLevel, and tmSameSecurity, then increment the
if no session exists yet over which the message can be sent. snmpTlstmSessionInvalidCaches counter, discard the message, and
return the error indication in the statusInformation. Processing
of this message stops.
2) If tmSameSecurity is true and either tmSessionID is undefined or 2) Extract the tmSessionID, tmTransportDomain, tmTransportAddress,
tmSecurityName, tmRequestedSecurityLevel, and tmSameSecurity
values from the tmStateReference. Note: The tmSessionID value
may be undefined if no session exists yet over which the message
can be sent.
3) If tmSameSecurity is true and either tmSessionID is undefined or
refers to a session that is no longer open then increment the refers to a session that is no longer open then increment the
tlstmSessionNoAvailableSessions counter, discard the message and snmpTlstmSessionNoSessions counter, discard the message and
return the error indication in the statusInformation. Processing return the error indication in the statusInformation. Processing
of this message stops. of this message stops.
3) If tmSameSecurity is false and tmSessionID refers to a session 4) If tmSameSecurity is false and tmSessionID refers to a session
that is no longer available then an implementation SHOULD open a that is no longer available then an implementation SHOULD open a
new session using the openSession() ASI (described in greater new session using the openSession() ASI (described in greater
detail in step 4b). An implementation MAY choose to return an detail in step 4b). Instead of opening a new session an
error to the calling module and stop processing of the message. implementation MAY return a snmpTlstmSessionNoSessions error to
the calling module and stop processing of the message.
4) If tmSessionID is undefined, then use tmTransportAddress, 5) If tmSessionID is undefined, then use tmTransportDomain,
tmSecurityName and tmRequestedSecurityLevel to see if there is a tmTransportAddress, tmSecurityName and tmRequestedSecurityLevel
corresponding entry in the LCD suitable to send the message over. to see if there is a corresponding entry in the LCD suitable to
send the message over.
4a) If there is a corresponding LCD entry, then this session 4a) 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 4b) 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, increment the openSession(), then discard the message, discard the
tlstmSessionOpenErrors, return an error indication to the tmStateReferenc, increment the snmpTlstmSessionOpenErrors,
calling module and stop processing of the message. return an error indication to the calling module and stop
processing of the message.
5) 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
The TLS Transport Model provides the following primitive to establish The TLS Transport Model provides the following primitive to establish
a new (D)TLS session (previously discussed in Section 5.3): a new (D)TLS session:
statusInformation = -- errorIndication or success statusInformation = -- errorIndication or success
openSession( openSession(
IN tmStateReference -- transport information to be used IN tmStateReference -- transport information to be used
OUT tmStateReference -- transport information to be used OUT tmStateReference -- transport information to be used
IN maxMessageSize -- of the sending SNMP entity IN maxMessageSize -- of the sending SNMP entity
) )
The following describes the procedure to follow when establishing a The following describes the procedure to follow when establishing a
SNMP over (D)TLS session between SNMP engines for exchanging SNMP SNMP over (D)TLS session between SNMP engines for exchanging SNMP
messages. This process is followed by any SNMP engine establishing a messages. This process is followed by any SNMP engine establishing a
session for subsequent use. session for subsequent use.
This MAY be done automatically for SNMP messages which are not This MAY be done automatically for an SNMP application that initiates
Response or Report messages. a transaction, such as a command generator, a notification
originator, or a proxy forwarder.
1) The client selects the appropriate certificate and cipher_suites 1) The client selects the appropriate certificate and cipher_suites
for the key agreement based on the tmSecurityName and the for the key agreement based on the tmSecurityName and the
tmRequestedSecurityLevel for the session. For sessions being tmRequestedSecurityLevel for the session. For sessions being
established as a result of a SNMP-TARGET-MIB based operation, the established as a result of a SNMP-TARGET-MIB based operation, the
certificate will potentially have been identified via the certificate will potentially have been identified via the
tlstmParamsTable mapping and the cipher_suites will have to be tlstmParamsTable mapping and the cipher_suites will have to be
taken from system-wide or implementation-specific configuration. taken from system-wide or implementation-specific configuration.
Otherwise, the certificate and appropriate cipher_suites will Otherwise, the certificate and appropriate cipher_suites will
need to be passed to the openSession() ASI as supplemental need to be passed to the openSession() ASI as supplemental
information or configured through an implementation-dependent information or configured through an implementation-dependent
mechanism. It is also implementation-dependent and possibly mechanism. It is also implementation-dependent and possibly
policy-dependent how tmRequestedSecurityLevel will be used to policy-dependent how tmRequestedSecurityLevel will be used to
influence the security capabilities provided by the (D)TLS influence the security capabilities provided by the (D)TLS
session. However this is done, the security capabilities session. However this is done, the security capabilities
provided by (D)TLS MUST be at least as high as the level of provided by (D)TLS MUST be at least as high as the level of
security indicated by the tmRequestedSecurityLevel parameter. security indicated by the tmRequestedSecurityLevel parameter.
The actual security level of the session is reported in the The actual security level of the session is reported in the
tmStateReference cache as tmSecurityLevel. For (D)TLS to provide tmStateReference cache as tmSecurityLevel. For (D)TLS to provide
strong authentication, each principal acting as a Command strong authentication, each principal acting as a command
Generator SHOULD have its own certificate. generator SHOULD have its own certificate.
2) Using the destTransportDomain and destTransportAddress values, 2) Using the destTransportDomain and destTransportAddress values,
the client will initiate the (D)TLS handshake protocol to the client will initiate the (D)TLS handshake protocol to
establish session keys for message integrity and encryption. establish session keys for message integrity and encryption.
If the attempt to establish a session is unsuccessful, then If the attempt to establish a session is unsuccessful, then
tlstmSessionOpenErrors is incremented, an error indication is snmpTlstmSessionOpenErrors is incremented, an error indication is
returned, and processing stops. If the session failed to open returned, and processing stops. If the session failed to open
because the presented server certificate was unknown or invalid because the presented server certificate was unknown or invalid
then the tlstmSessionUnknownServerCertificate or then the snmpTlstmSessionUnknownServerCertificate or
tlstmSessionInvalidServerCertificates MUST be incremented and a snmpTlstmSessionInvalidServerCertificates MUST be incremented and
tlstmServerCertificateUnknown or tlstmServerInvalidCertificate a tlstmServerCertificateUnknown or tlstmServerInvalidCertificate
notification SHOULD be sent as appropriate. Reasons for server notification SHOULD be sent as appropriate. Reasons for server
certificate invalidation includes, but is not limited to, certificate invalidation includes, but is not limited to,
cryptographic validation failures and an unexpected presented cryptographic validation failures and an unexpected presented
certificate identity. certificate identity.
3) Once a (D)TLS secured session is established and both sides have 3) Once a (D)TLS secured session is established and both sides have
verified the authenticity of the peer's certificate (e.g. verified the authenticity of the peer's certificate (e.g.
[RFC5280]) then each side will determine and/or check the [RFC5280]) then each side will determine and/or check the
identity of the remote entity using the procedures described identity of the remote entity using the procedures described
below. below.
skipping to change at page 25, line 16 skipping to change at page 26, line 26
authenticated identity from the (D)TLS client's principal authenticated identity from the (D)TLS client's principal
certificate using configuration information from the certificate using configuration information from the
tlstmCertToTSNTable mapping table. The resulting derived tlstmCertToTSNTable mapping table. The resulting derived
tmSecurityName is recorded in the tmStateReference cache as tmSecurityName is recorded in the tmStateReference cache as
tmSecurityName. The details of the lookup process are fully tmSecurityName. The details of the lookup process are fully
described in the DESCRIPTION clause of the described in the DESCRIPTION clause of the
tlstmCertToTSNTable MIB object. If any verification fails in tlstmCertToTSNTable MIB object. If any verification fails in
any way (for example because of failures in cryptographic any way (for example because of failures in cryptographic
verification or because of the lack of an appropriate row in verification or because of the lack of an appropriate row in
the tlstmCertToTSNTable) then the session establishment MUST the tlstmCertToTSNTable) then the session establishment MUST
fail, the tlstmSessionInvalidClientCertificates object is fail, the 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
authenticated identity of the (D)TLS server's certificate is authenticated identity of the (D)TLS server's presented
the certificate. certificate is the expected certificate.
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 the if the presented identity matches the determine the if the presented identity matches the
expectations of the configuration. Path validation expectations of the configuration. Path validation
procedures (like those defined in [RFC5280]) MUST be procedures (like those defined in [RFC5280]) MUST be
followed. If a server identity name has been configured in followed. If a server identity name has been configured in
the tlstmAddrServerIdentity column then this reference the tlstmAddrServerIdentity column then this reference
identity must be compared against the presented identity (for identity must be compared against the presented identity (for
skipping to change at page 25, line 45 skipping to change at page 27, line 7
If the connection is being established for other reasons then If the connection is being established for other reasons then
configuration and procedures outside the scope of this configuration and procedures outside the scope of this
document should be followed. document should be followed.
(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 tlstmSessionInvalidServerCertificates object is fail, the snmpTlstmSessionInvalidServerCertificates object is
incremented and processing stops. incremented and processing stops.
4) The (D)TLS-specific session identifier is passed to the TLS 4) The (D)TLS-specific session identifier is set in the sessionID of
Transport Model and associated with the tmStateReference cache the tmStateReference passed to the TLS Transport Model to
entry to indicate that the session has been established indicate that the session has been established successfully and
successfully and to point to a specific (D)TLS session for future 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 the Server Name Indication extension defined in
Section 3.1 of [RFC4366]. Supporting this will allow, for example, Section 3.1 of [RFC4366]. Supporting this will allow, for example,
sending notifications to a specific principal at a given TCP, UDP or sending notifications to a specific principal at a given TCP, UDP or
SCTP port. 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 tmStateReference -- transport info IN tmSessionID -- session ID of the session to be closed
) )
The following describes the procedure to follow to close a session The following describes the procedure to follow to close a session
between a client and server. This process is followed by any SNMP between a client and server. This process is followed by any SNMP
engine closing the corresponding SNMP session. engine closing the corresponding SNMP session.
1) Look up the session in the cache and the LCD using the 1) Increment the snmpTlstmSessionCloses counter.
tmStateReference and its contents.
2) If there is no open session associated with the tmStateReference, 2) Look up the session using the tmSessionID.
then closeSession processing is completed.
3) Delete the entry from the cache and any other implementation- 3) If there is no open session associated with the tmSessionID, then
dependent information in the LCD. closeSession processing is completed.
4) Have (D)TLS close the specified session. This SHOULD include 4) Have (D)TLS close the specified session. This SHOULD include
sending a close_notify TLS Alert to inform the other side that sending a close_notify TLS Alert to inform the other side that
session cleanup may be performed. session cleanup may be performed.
6. MIB Module Overview 6. MIB Module Overview
This MIB module provides management of the TLS Transport Model. It This MIB module provides management of the TLS Transport Model. It
defines needed textual conventions, statistical counters, defines needed textual conventions, statistical counters,
notifications and configuration infrastructure necessary for session notifications and configuration infrastructure necessary for session
skipping to change at page 28, line 35 skipping to change at page 29, line 44
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 "200912080000Z" LAST-UPDATED "200912230000Z"
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 29, line 4 skipping to change at page 30, line 13
Juergen Schoenwaelder Juergen Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
Campus Ring 1 Campus Ring 1
28725 Bremen 28725 Bremen
Germany Germany
+49 421 200-3587 +49 421 200-3587
j.schoenwaelder@jacobs-university.de j.schoenwaelder@jacobs-university.de
Russ Mundy Russ Mundy
SPARTA, Inc. SPARTA, Inc.
7110 Samuel Morse Drive 7110 Samuel Morse Drive
Columbia, MD 21046 Columbia, MD 21046
USA USA
Co-editors: Co-editors:
Wes Hardaker Wes Hardaker
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 Copyright (c) 2009 IETF Trust and the persons identified as
identified as authors of the code. 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, are permitted provided that the without modification, is permitted pursuant to, and subject
following conditions are met: to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
- Redistributions of source code must retain the above copyright Relating to IETF Documents
notice, this list of conditions and the following disclaimer. (http://trustee.ietf.org/license-info).
- Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials
provided with the distribution.
- Neither the name of Internet Society, IETF or IETF Trust,
nor the names of specific contributors, may be used to endorse
or promote products derived from this software without
specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
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 "200912080000Z" REVISION "200912230000Z"
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 35, line 4 skipping to change at page 35, line 34
DESCRIPTION "Maps any of the following fields using the DESCRIPTION "Maps any of the following fields using the
corresponding mapping algorithms: corresponding mapping algorithms:
|------------+------------------------| |------------+------------------------|
| Type | Algorithm | | Type | Algorithm |
|------------+------------------------| |------------+------------------------|
| rfc822Name | tlstmCertSANRFC822Name | | rfc822Name | tlstmCertSANRFC822Name |
| dNSName | tlstmCertSANDNSName | | dNSName | tlstmCertSANDNSName |
| ipAddress | tlstmCertSANIpAddress | | ipAddress | tlstmCertSANIpAddress |
|------------+------------------------| |------------+------------------------|
The first matching subjectAltName value found in the The first matching subjectAltName value found in the
certificate any of the above types MUST be used when certificate any of the above types MUST be used when
deriving the tmSecurityName." deriving the tmSecurityName."
::= { tlstmCertToTSNMIdentities 5 } ::= { tlstmCertToTSNMIdentities 5 }
tlstmCertCommonName OBJECT-IDENTITY tlstmCertCommonName OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION "Maps a certificate's CommonName to a DESCRIPTION "Maps a certificate's CommonName to a
tmSecurityName by directly passing the value without tmSecurityName by directly passing the value without
any transformations." any transformations."
::= { tlstmCertToTSNMIdentities 6 } ::= { tlstmCertToTSNMIdentities 6 }
-- The snmpTlstmSession Group
tlstmSession OBJECT IDENTIFIER ::= { tlstmObjects 1 } snmpTlstmSession OBJECT IDENTIFIER ::= { tlstmObjects 1 }
tlstmSessionOpens OBJECT-TYPE snmpTlstmSessionOpens OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times an openSession() request has been "The number of times an openSession() request has been
executed as an (D)TLS client, whether it succeeded or failed." executed as an (D)TLS client, whether it succeeded or failed."
::= { tlstmSession 1 } ::= { snmpTlstmSession 1 }
tlstmSessionCloses OBJECT-TYPE snmpTlstmSessionCloses OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times a closeSession() request has been "The number of times a closeSession() request has been
executed as an (D)TLS client, whether it succeeded or failed." executed as an (D)TLS client, whether it succeeded or failed."
::= { tlstmSession 2 } ::= { snmpTlstmSession 2 }
tlstmSessionOpenErrors OBJECT-TYPE snmpTlstmSessionOpenErrors OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times an openSession() request failed to open a "The number of times an openSession() request failed to open a
session as a (D)TLS client, for any reason." session as a (D)TLS client, for any reason."
::= { tlstmSession 3 } ::= { snmpTlstmSession 3 }
tlstmSessionNoAvailableSessions OBJECT-TYPE snmpTlstmSessionNoSessions OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times an outgoing message was dropped because "The number of times an outgoing message was dropped because
the session associated with the passed tmStateReference was no the session associated with the passed tmStateReference was no
longer (or was never) available." longer (or was never) available."
::= { tlstmSession 4 } ::= { snmpTlstmSession 4 }
tlstmSessionInvalidClientCertificates OBJECT-TYPE snmpTlstmSessionInvalidClientCertificates OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times an incoming session was not established "The number of times an incoming session was not established
on an (D)TLS server because the presented client certificate was on an (D)TLS server because the presented client certificate was
invalid. Reasons for invalidation include, but are not invalid. Reasons for invalidation include, but are not
limited to, cryptographic validation failures or lack of a limited to, cryptographic validation failures or lack of a
suitable mapping row in the tlstmCertToTSNTable." suitable mapping row in the tlstmCertToTSNTable."
::= { tlstmSession 5 } ::= { snmpTlstmSession 5 }
tlstmSessionUnknownServerCertificate OBJECT-TYPE snmpTlstmSessionUnknownServerCertificate OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times an outgoing session was not established "The number of times an outgoing session was not established
on an (D)TLS client because the server certificate presented on an (D)TLS client because the server certificate presented
by a SNMP over (D)TLS server was invalid because no by a SNMP over (D)TLS server was invalid because no
configured fingerprint or CA was acceptable to validate it. configured fingerprint or CA was acceptable to validate it.
This may result because there was no entry in the This may result because there was no entry in the
tlstmAddrTable or because no path could be found to known tlstmAddrTable or because no path could be found to known
certificate authority." certificate authority."
::= { tlstmSession 6 } ::= { snmpTlstmSession 6 }
tlstmSessionInvalidServerCertificates OBJECT-TYPE snmpTlstmSessionInvalidServerCertificates OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times an outgoing session was not established "The number of times an outgoing session was not established
on an (D)TLS client because the server certificate presented on an (D)TLS client because the server certificate presented
by an SNMP over (D)TLS server could not be validated even if by an SNMP over (D)TLS server could not be validated even if
the fingerprint or expected validation path was known. I.E., the fingerprint or expected validation path was known. I.E.,
a cryptographic validation occurred during certificate a cryptographic validation occurred during certificate
validation processing. validation processing.
Reasons for invalidation include, but are not Reasons for invalidation include, but are not
limited to, cryptographic validation failures." limited to, cryptographic validation failures."
::= { tlstmSession 7 } ::= { snmpTlstmSession 7 }
snmpTlstmSessionInvalidCaches OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of outgoing messages dropped because the
tmStateReference referred to an invalid cache."
::= { snmpTlstmSession 8 }
tlstmTLSProtectionErrors OBJECT-TYPE tlstmTLSProtectionErrors OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times (D)TLS processing resulted in a message "The number of times (D)TLS processing resulted in a message
being discarded because it failed its integrity test, being discarded because it failed its integrity test,
decryption processing or other (D)TLS processing." decryption processing or other (D)TLS processing."
::= { tlstmSession 8 } ::= { snmpTlstmSession 9 }
-- Configuration Objects -- Configuration Objects
tlstmConfig OBJECT IDENTIFIER ::= { tlstmObjects 2 } tlstmConfig OBJECT IDENTIFIER ::= { tlstmObjects 2 }
-- Certificate mapping -- Certificate mapping
tlstmCertificateMapping OBJECT IDENTIFIER ::= { tlstmConfig 1 } tlstmCertificateMapping OBJECT IDENTIFIER ::= { tlstmConfig 1 }
tlstmCertToTSNCount OBJECT-TYPE tlstmCertToTSNCount OBJECT-TYPE
skipping to change at page 47, line 21 skipping to change at page 48, line 12
If the corresponding row in the targetAddrTable is deleted If the corresponding row in the targetAddrTable is deleted
then this row must be automatically removed." then this row must be automatically removed."
::= { tlstmAddrEntry 4 } ::= { tlstmAddrEntry 4 }
-- ************************************************ -- ************************************************
-- tlstmNotifications - Notifications Information -- tlstmNotifications - Notifications Information
-- ************************************************ -- ************************************************
tlstmServerCertificateUnknown NOTIFICATION-TYPE tlstmServerCertificateUnknown NOTIFICATION-TYPE
OBJECTS { tlstmSessionUnknownServerCertificate } OBJECTS { snmpTlstmSessionUnknownServerCertificate }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Notification that the server certificate presented by a SNMP "Notification that the server certificate presented by a SNMP
over (D)TLS server was invalid because no configured over (D)TLS server was invalid because no configured
fingerprint or CA was acceptable to validate it. This may fingerprint or CA was acceptable to validate it. This may
result because there was no entry in the tlstmAddrTable or result because there was no entry in the tlstmAddrTable or
because no path could be found to known certificate because no path could be found to known certificate
authority. authority.
To avoid notification loops, this notification MUST NOT be To avoid notification loops, this notification MUST NOT be
sent to servers that themselves have triggered the sent to servers that themselves have triggered the
notification." notification."
::= { tlstmNotifications 1 } ::= { tlstmNotifications 1 }
tlstmServerInvalidCertificate NOTIFICATION-TYPE tlstmServerInvalidCertificate NOTIFICATION-TYPE
OBJECTS { tlstmAddrServerFingerprint, OBJECTS { tlstmAddrServerFingerprint,
tlstmSessionInvalidServerCertificates} snmpTlstmSessionInvalidServerCertificates}
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Notification that the server certificate presented by an SNMP "Notification that the server certificate presented by an SNMP
over (D)TLS server could not be validated even if the over (D)TLS server could not be validated even if the
fingerprint or expected validation path was known. I.E., a fingerprint or expected validation path was known. I.E., a
cryptographic validation occurred during certificate cryptographic validation occurred during certificate
validation processing. validation processing.
To avoid notification loops, this notification MUST NOT be To avoid notification loops, this notification MUST NOT be
sent to servers that themselves have triggered the sent to servers that themselves have triggered the
skipping to change at page 48, line 34 skipping to change at page 49, line 25
tlstmIncomingGroup, tlstmIncomingGroup,
tlstmOutgoingGroup, tlstmOutgoingGroup,
tlstmNotificationGroup } tlstmNotificationGroup }
::= { tlstmCompliances 1 } ::= { tlstmCompliances 1 }
-- ************************************************ -- ************************************************
-- Units of conformance -- Units of conformance
-- ************************************************ -- ************************************************
tlstmStatsGroup OBJECT-GROUP tlstmStatsGroup OBJECT-GROUP
OBJECTS { OBJECTS {
tlstmSessionOpens, snmpTlstmSessionOpens,
tlstmSessionCloses, snmpTlstmSessionCloses,
tlstmSessionOpenErrors, snmpTlstmSessionOpenErrors,
tlstmSessionNoAvailableSessions, snmpTlstmSessionNoSessions,
tlstmSessionInvalidClientCertificates, snmpTlstmSessionInvalidClientCertificates,
tlstmSessionUnknownServerCertificate, snmpTlstmSessionUnknownServerCertificate,
tlstmSessionInvalidServerCertificates, snmpTlstmSessionInvalidServerCertificates,
snmpTlstmSessionInvalidCaches,
tlstmTLSProtectionErrors tlstmTLSProtectionErrors
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of objects for maintaining "A collection of objects for maintaining
statistical information of an SNMP engine which statistical information of an SNMP engine which
implements the SNMP TLS Transport Model." implements the SNMP TLS Transport Model."
::= { tlstmGroups 1 } ::= { tlstmGroups 1 }
tlstmIncomingGroup OBJECT-GROUP tlstmIncomingGroup OBJECT-GROUP
skipping to change at page 50, line 44 skipping to change at page 51, line 37
When an SNMP engine needs to establish an outgoing session for When an SNMP engine needs to establish an outgoing session for
notifications, the snmpTargetParamsTable includes an entry for the notifications, the snmpTargetParamsTable includes an entry for the
snmpTargetParamsSecurityName of the target. However, the receiving snmpTargetParamsSecurityName of the target. However, the receiving
SNMP engine (Server) does not know which (D)TLS certificate to offer SNMP engine (Server) does not know which (D)TLS certificate to offer
to the Client so that the tmSecurityName identity-authentication will to the Client so that the tmSecurityName identity-authentication will
be successful. be successful.
One solution is to maintain a one-to-one mapping between certificates One solution is to maintain a one-to-one mapping between certificates
and incoming ports for notification receivers. This can be handled and incoming ports for notification receivers. This can be handled
at the Notification Originator by configuring the snmpTargetAddrTable at the notification originator by configuring the snmpTargetAddrTable
(snmpTargetAddrTDomain and snmpTargetAddrTAddress) and requiring the (snmpTargetAddrTDomain and snmpTargetAddrTAddress) and requiring the
receiving SNMP engine to monitor multiple incoming static ports based receiving SNMP engine to monitor multiple incoming static ports based
on which principals are capable of receiving notifications. on which principals are capable of receiving notifications.
Implementations MAY also choose to designate a single Notification Implementations MAY also choose to designate a single Notification
Receiver Principal to receive all incoming notifications or select an Receiver Principal to receive all incoming notifications or select an
implementation specific method of selecting a server certificate to implementation specific method of selecting a server certificate to
present to clients. present to clients.
8.3. contextEngineID Discovery 8.3. contextEngineID Discovery
Most Command Responders have contextEngineIDs that are identical to Most command responders have contextEngineIDs that are identical to
the USM securityEngineID. USM provides a discovery service that the USM securityEngineID. USM provides a discovery service that
allows Command Generators to determine a securityEngineID and thus a allows command generators to determine a securityEngineID and thus a
default contextEngineID to use. Because the TLS Transport Model does default contextEngineID to use. Because the TLS Transport Model does
not make use of a securityEngineID, it may be difficult for Command not make use of a securityEngineID, it may be difficult for command
Generators to discover a suitable default contextEngineID. generators to discover a suitable default contextEngineID.
Implementations should consider offering another engineID discovery Implementations should consider offering another engineID discovery
mechanism to continue providing Command Generators with a suitable mechanism to continue providing Command Generators with a suitable
contextEngineID mechanism. A recommended discovery solution is contextEngineID mechanism. A recommended discovery solution is
documented in [RFC5343]. documented in [RFC5343].
8.4. Transport Considerations 8.4. Transport Considerations
This document defines how SNMP messages can be transmitted over the This document defines how SNMP messages can be transmitted over the
TLS and DTLS based protocols. Each of these protocols are TLS and DTLS based protocols. Each of these protocols are
additionally based on other transports (TCP, UDP and SCTP). These additionally based on other transports (TCP, UDP and SCTP). These
skipping to change at page 52, line 16 skipping to change at page 53, line 5
Implementations are responsible for providing a security certificate Implementations are responsible for providing a security certificate
installation and configuration mechanism. Implementations SHOULD installation and configuration mechanism. Implementations SHOULD
support certificate revocation lists. support certificate revocation lists.
(D)TLS provides for authentication of the identity of both the (D)TLS (D)TLS provides for authentication of the identity of both the (D)TLS
server and the (D)TLS client. Access to MIB objects for the server and the (D)TLS client. Access to MIB objects for the
authenticated principal MUST be enforced by an access control authenticated principal MUST be enforced by an access control
subsystem (e.g. the VACM). subsystem (e.g. the VACM).
Authentication of the Command Generator principal's identity is Authentication of the command generator principal's identity is
important for use with the SNMP access control subsystem to ensure important for use with the SNMP access control subsystem to ensure
that only authorized principals have access to potentially sensitive that only authorized principals have access to potentially sensitive
data. The authenticated identity of the Command Generator data. The authenticated identity of the command generator
principal's certificate is mapped to an SNMP model-independent principal's certificate is mapped to an SNMP model-independent
securityName for use with SNMP access control. securityName for use with SNMP access control.
The (D)TLS handshake only provides assurance that the certificate of The (D)TLS handshake only provides assurance that the certificate of
the authenticated identity has been signed by an configured accepted the authenticated identity has been signed by an configured accepted
Certificate Authority. (D)TLS has no way to further authorize or Certificate Authority. (D)TLS has no way to further authorize or
reject access based on the authenticated identity. An Access Control reject access based on the authenticated identity. An Access Control
Model (such as the VACM) provides access control and authorization of Model (such as the VACM) provides access control and authorization of
a Command Generator's requests to a Command Responder and a a command generator's requests to a command responder and a
Notification Responder's authorization to receive Notifications from notification responder's authorization to receive Notifications from
a Notification Originator. However to avoid man-in-the-middle a notification originator. However to avoid man-in-the-middle
attacks both ends of the (D)TLS based connection MUST check the attacks both ends of the (D)TLS based connection MUST check the
certificate presented by the other side against what was expected. certificate presented by the other side against what was expected.
For example, Command Generators must check that the Command Responder For example, command generators must check that the command responder
presented and authenticated itself with a X.509 certificate that was presented and authenticated itself with a X.509 certificate that was
expected. Not doing so would allow an impostor, at a minimum, to expected. Not doing so would allow an impostor, at a minimum, to
present false data, receive sensitive information and/or provide a present false data, receive sensitive information and/or provide a
false belief that configuration was actually received and acted upon. false belief that configuration was actually received and acted upon.
Authenticating and verifying the identity of the (D)TLS server and Authenticating and verifying the identity of the (D)TLS server and
the (D)TLS client for all operations ensures the authenticity of the the (D)TLS client for all operations ensures the authenticity of the
SNMP engine that provides MIB data. SNMP engine that provides MIB data.
The instructions found in the DESCRIPTION clause of the The instructions found in the DESCRIPTION clause of the
tlstmCertToTSNTable object must be followed exactly. It is also tlstmCertToTSNTable object must be followed exactly. It is also
skipping to change at page 53, line 8 skipping to change at page 53, line 46
9.2. Use with SNMPv1/SNMPv2c Messages 9.2. Use with SNMPv1/SNMPv2c Messages
The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP
74) always selects the SNMPv1 or SNMPv2c Security Models, 74) always selects the SNMPv1 or SNMPv2c Security Models,
respectively. Both of these and the User-based Security Model respectively. Both of these and the User-based Security Model
typically used with SNMPv3 derive the securityName and securityLevel typically used with SNMPv3 derive the securityName and securityLevel
from the SNMP message received, even when the message was received from the SNMP message received, even when the message was received
over a secure transport. Access control decisions are therefore made over a secure transport. Access control decisions are therefore made
based on the contents of the SNMP message, rather than using the based on the contents of the SNMP message, rather than using the
authenticated identity and securityLevel provided by the SSH authenticated identity and securityLevel provided by the TLS
Transport Model. Transport Model.
9.3. MIB Module Security 9.3. MIB Module Security
There are a number of management objects defined in this MIB module There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their network operations. These are the tables and objects and their
skipping to change at page 62, line 23 skipping to change at page 63, line 16
vacmSecurityName = "blueberry" vacmSecurityName = "blueberry"
vacmGroupName = "administrators" vacmGroupName = "administrators"
vacmSecurityToGroupStorageType = 3 (nonVolatile) vacmSecurityToGroupStorageType = 3 (nonVolatile)
vacmSecurityToGroupStatus = 4 (createAndGo) vacmSecurityToGroupStatus = 4 (createAndGo)
This example will assume that the "administrators" group has been This example will assume that the "administrators" group has been
given proper permissions via rows in the vacmAccessTable and given proper permissions via rows in the vacmAccessTable and
vacmViewTreeFamilyTable. vacmViewTreeFamilyTable.
Depending on whether this VACM configuration is for a Command Depending on whether this VACM configuration is for a Command
Responder or a Command Generator the security name "blueberry" will Responder or a command generator the security name "blueberry" will
come from a few different locations. come from a few different locations.
C.1. Configuring the Notification Generator C.1. Configuring the Notification Generator
For Notification Generators performing authorization checks, the For notification generators performing authorization checks, the
server's certificate must be verified against the expected server's certificate must be verified against the expected
certificate before proceeding to send the notification. The expected certificate before proceeding to send the notification. The expected
certificate from the server may be listed in the tlstmAddrTable or certificate from the server may be listed in the tlstmAddrTable or
may be determined through other X.509 path validation mechanisms. may be determined through other X.509 path validation mechanisms.
The securityName to use for VACM authorization checks is set by the The securityName to use for VACM authorization checks is set by the
SNMP-TARGET-MIB's snmpTargetParamsSecurityName column. SNMP-TARGET-MIB's snmpTargetParamsSecurityName column.
The certificate that the notification generator should present to the The certificate that the notification generator should present to the
server is taken from the tlstmParamsClientFingerprint column from the server is taken from the tlstmParamsClientFingerprint column from the
appropriate entry in the tlstmParamsTable table. appropriate entry in the tlstmParamsTable table.
C.2. Configuring the Command Responder C.2. Configuring the Command Responder
For Command Responder applications, the vacmSecurityName "blueberry" For command responder applications, the vacmSecurityName "blueberry"
value is a value that derived from an incoming (D)TLS session. The value is a value that derived from an incoming (D)TLS session. The
mapping from a recevied (D)TLS client certificate to a tmSecurityName mapping from a recevied (D)TLS client certificate to a tmSecurityName
is done with the tlstmCertToTSNTable. The certificates must be is done with the tlstmCertToTSNTable. The certificates must be
loaded into the device so that a tlstmCertToTSNEntry may refer to it. loaded into the device so that a tlstmCertToTSNEntry may refer to it.
As an example, consider the following entry which will provide a As an example, consider the following entry which will provide a
mapping from a client's public X.509's hash fingerprint directly to mapping from a client's public X.509's hash fingerprint directly to
the "blueberry" tmSecurityName: the "blueberry" tmSecurityName:
tlstmCertToTSNID = 1 (chosen by ordering preference) tlstmCertToTSNID = 1 (chosen by ordering preference)
tlstmCertToTSNFingerprint = HASH (appropriate fingerprint) tlstmCertToTSNFingerprint = HASH (appropriate fingerprint)
 End of changes. 128 change blocks. 
304 lines changed or deleted 344 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/