draft-ietf-isms-dtls-tm-05.txt   draft-ietf-isms-dtls-tm-06.txt 
ISMS W. Hardaker ISMS W. Hardaker
Internet-Draft Sparta, Inc. Internet-Draft Sparta, Inc.
Intended status: Standards Track January 8, 2010 Intended status: Standards Track January 27, 2010
Expires: July 12, 2010 Expires: July 31, 2010
Transport Layer Security (TLS) Transport Model for SNMP Transport Layer Security (TLS) Transport Model for SNMP
draft-ietf-isms-dtls-tm-05.txt draft-ietf-isms-dtls-tm-06.txt
Abstract Abstract
This document describes a Transport Model for the Simple Network This document describes a Transport Model for the Simple Network
Management Protocol (SNMP), that uses either the Transport Layer Management Protocol (SNMP), that uses either the Transport Layer
Security protocol or the Datagram Transport Layer Security (DTLS) Security protocol or the Datagram Transport Layer Security (DTLS)
protocol. The TLS and DTLS protocols provide authentication and protocol. The TLS and DTLS protocols provide authentication and
privacy services for SNMP applications. This document describes how privacy services for SNMP applications. This document describes how
the TLS Transport Model (TLSTM) implements the needed features of a the TLS Transport Model (TLSTM) implements the needed features of a
SNMP Transport Subsystem to make this protection possible in an SNMP Transport Subsystem to make this protection possible in an
skipping to change at page 2, line 9 skipping to change at page 2, line 9
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 12, 2010. This Internet-Draft will expire on July 31, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
3. How the TLSTM fits into the Transport Subsystem . . . . . . . 9 3. How the TLSTM fits into the Transport Subsystem . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . 15 4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . 18 4.3.2. SNMP Services for an Incoming Message . . . . . . . . 17
4.4. Cached Information and References . . . . . . . . . . . . 18 4.4. Cached Information and References . . . . . . . . . . . . 18
4.4.1. TLS Transport Model Cached Information . . . . . . . . 19 4.4.1. TLS Transport Model Cached Information . . . . . . . . 18
4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 19 4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 19
4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 19 4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 19
4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 19 4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 19
5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19
5.1. Procedures for an Incoming Message . . . . . . . . . . . . 20 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 20
5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 20 5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 20
5.1.2. Transport Processing for Incoming SNMP Messages . . . 22 5.1.2. Transport Processing for Incoming SNMP Messages . . . 22
5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 23 5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 23
5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 24 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 24
5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 27 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 27
6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 28 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 27
6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28
6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 28 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 28
6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 28 6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 28
6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 28 6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 28
6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 29 6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 28
6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29 6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29
6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29 6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29
7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29
8. Operational Considerations . . . . . . . . . . . . . . . . . . 50 8. Operational Considerations . . . . . . . . . . . . . . . . . . 50
8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.2. Notification Receiver Credential Selection . . . . . . . . 51 8.2. Notification Receiver Credential Selection . . . . . . . . 51
8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 52 8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 52
8.4. Transport Considerations . . . . . . . . . . . . . . . . . 52 8.4. Transport Considerations . . . . . . . . . . . . . . . . . 52
9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 9. Security Considerations . . . . . . . . . . . . . . . . . . . 52
9.1. Certificates, Authentication, and Authorization . . . . . 52 9.1. Certificates, Authentication, and Authorization . . . . . 52
skipping to change at page 4, line 14 skipping to change at page 4, line 14
9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 54 9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 54
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
12.1. Normative References . . . . . . . . . . . . . . . . . . . 57 12.1. Normative References . . . . . . . . . . . . . . . . . . . 57
12.2. Informative References . . . . . . . . . . . . . . . . . . 58 12.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 59 Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 59
A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 59 A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 59
A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 60 A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 60
Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 61 Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 61
Appendix C. Target and Notificaton Configuration Example . . . . 62 Appendix C. Target and Notification Configuration Example . . . . 62
C.1. Configuring the Notification Generator . . . . . . . . . . 63 C.1. Configuring the Notification Originator . . . . . . . . . 63
C.2. Configuring the Command Responder . . . . . . . . . . . . 63 C.2. Configuring the Command Responder . . . . . . . . . . . . 63
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
It is important to understand the modular SNMPv3 architecture as It is important to understand the modular SNMPv3 architecture as
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
skipping to change at page 6, line 8 skipping to change at page 6, line 8
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. Note: this diagram shows the Transport Security Model equally valid. Note: this diagram shows the Transport Security Model
(TSM) being used as the security model which is defined in [RFC5591]. (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 | +-------+ | | | V | +--------+ |
| | +------+ +----+ | | | | | +------+ +----+ | | | | | +--------+ | | | | | | +--------+ | | | |
| | | TLS | <---------->| Cache | | | | | TLS | <---->| Cache | | | | | TLS TM |---------->| Cache | | | | | TLS TM | <---->| Cache | |
| | | 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- | | |
| | | |Subsystem | |sys. | | | | | | |system| |sys. | | | | | | |Subsystem | |sys. | | | | | | |system| |sys. | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | |+---+| | | | | | | | |+---+| | | | | | | | |+---+| | | | | | | | |+---+| | |
| | | | +-----+ | || || | | | | | |+----+| || || | | | | | | +-----+ | || || | | | | | |+----+| || || | |
| | <--->|v3MP |<-->||TSM|<-+ | | | <-->|v3MP|<->|TSM|<-+ | | | <--->|v3MP |<--->|TSM|<-+ | | | <-->|v3MP|<->|TSM|<-+ |
| | | | +-----+ | || || | | | | |+----+| || || | | | | | +-----+ | || || | | | | |+----+| || || |
| +-------+ | | |+---+| | | +-----+ | | |+---+| | | +-------+ | | |+---+| | | +-----+ | | |+---+| |
| ^ | | | | | | ^ | | | | | | ^ | | | | | | ^ | | | | |
| | +----------+ +-----+ | | | +------+ +-----+ | | | +----------+ +-----+ | | | +------+ +-----+ |
| +-+------------+ | | +-+------------+ | | +-+------------+ | | +-+----------+ |
| ^ ^ | | ^ ^ | | ^ ^ | | | ^ |
| | | | | | | | | | | | | | | |
| v v | | V V | | v v | | v V |
| +-------------+ +--------------+ | | +-----------+ +--------------+ | | +-------------+ +--------------+ | | +-----------+ +--------------+ |
| | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | |
| | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RECEIVER | | | | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RECEIVER | |
| | application | | application | | | |application| | application | | | | application | | application | | | |application| | application | |
| +-------------+ +--------------+ | | +-----------+ +--------------+ | | +-------------+ +--------------+ | | +-----------+ +--------------+ |
| SNMP entity | | SNMP entity | | SNMP entity | | SNMP entity |
+----------------------------------+ +--------------------------------+ +----------------------------------+ +--------------------------------+
1.1. Conventions 1.1. Conventions
skipping to change at page 7, line 25 skipping to change at page 7, line 25
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 "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 The terms "manager" and "agent" are not used in this document
because, in the RFC 3411 architecture, all SNMP entities have the because, in the [RFC3411] architecture, all SNMP entities have the
capability of acting as manager, agent, or both depending on the SNMP capability of acting as manager, agent, or both depending on the SNMP
application types supported in the implementation. Where distinction application types supported in the implementation. Where distinction
is required, the application names of command generator, command is required, the application names of command generator, command
responder, notification originator, notification receiver, and proxy responder, notification originator, notification receiver, and proxy
forwarder are used. See "SNMP Applications" [RFC3413] for further forwarder are used. See "SNMP Applications" [RFC3413] for further
information. information.
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 [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.
skipping to change at page 11, line 27 skipping to change at page 11, line 15
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 used 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.
(D)TLS provides protection against the disclosure of information (D)TLS provides protection against the disclosure of information
to unauthorized recipients or eavesdroppers by allowing for to unauthorized recipients or eavesdroppers by allowing for
encryption of all traffic between SNMP engines. The TLS encryption of all traffic between SNMP engines. The TLS
Transport Model SHOULD support the message encryption to protect Transport Model SHOULD support the message encryption to protect
sensitive data from eavesdropping attacks. sensitive data from eavesdropping attacks.
skipping to change at page 12, line 31 skipping to change at page 12, line 21
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, the transport type and the transport address authenticated principal, the transport type and the transport address
associated with an incoming message. The TLS Transport Model associated with an incoming message. The TLS Transport Model
provides the identity and destination type and address to (D)TLS for provides the identity and destination type and address to (D)TLS for
outgoing messages. outgoing messages.
When an application requests a session for a message, through the When an application requests a session for a message it also requests
cache, the application requests a security level for that session. a security level for that session. The TLS Transport Model MUST
The TLS Transport Model MUST ensure that the (D)TLS session provides ensure that the (D)TLS session provides security at least as high as
security at least as high as the requested level of security. How the requested level of security. How the security level is
the security level is translated into the algorithms used to provide translated into the algorithms used to provide data integrity and
data integrity and privacy is implementation-dependent. However, the privacy is implementation-dependent. However, the NULL integrity and
NULL integrity and encryption algorithms MUST NOT be used to fulfill encryption algorithms MUST NOT be used to fulfill security level
security level requests for authentication or privacy. requests for authentication or privacy. Implementations MAY choose
Implementations MAY choose to force (D)TLS to only allow to force (D)TLS to only allow cipher_suites that provide both
cipher_suites that provide both authentication and privacy to authentication and privacy to guarantee this assertion.
guarantee this assertion.
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
skipping to change at page 13, line 50 skipping to change at page 13, line 39
duration of the session from the TLSTM's perspective even if the TLS duration of the session from the TLSTM's perspective even if the TLS
internal session identifier does change. internal session identifier does change.
3.2. Security Parameter Passing 3.2. Security Parameter Passing
For the (D)TLS server-side, (D)TLS-specific security parameters For the (D)TLS server-side, (D)TLS-specific security parameters
(i.e., cipher_suites, X.509 certificate fields, IP address and port) (i.e., cipher_suites, X.509 certificate fields, IP address and port)
are translated by the TLS Transport Model into security parameters are translated by the TLS Transport Model into security parameters
for the TLS Transport Model and security model (e.g., for the TLS Transport Model and security model (e.g.,
tmSecurityLevel, tmSecurityName, transportDomain, transportAddress). tmSecurityLevel, tmSecurityName, transportDomain, transportAddress).
The transport- related and (D)TLS-security-related information, The transport-related and (D)TLS-security-related information,
including the authenticated identity, are stored in a cache including the authenticated identity, are stored in a cache
referenced by tmStateReference. referenced by tmStateReference.
For the (D)TLS client-side, the TLS Transport Model takes input For the (D)TLS client-side, the TLS Transport Model takes input
provided by the Dispatcher in the sendMessage() Abstract Service provided by the Dispatcher in the sendMessage() Abstract Service
Interface (ASI) and input from the tmStateReference cache. The Interface (ASI) and input from the tmStateReference cache. The
(D)TLS Transport Model converts that information into suitable (D)TLS Transport Model converts that information into suitable
security parameters for (D)TLS and establishes sessions as needed. security parameters for (D)TLS and establishes sessions as needed.
The elements of procedure in Section 5 discuss these concepts in much The elements of procedure in Section 5 discuss these concepts in much
skipping to change at page 14, line 29 skipping to change at page 14, line 19
generators, notification originators, proxy forwarders. Command generators, notification originators, proxy forwarders. Command
generators are frequently operated by a human, but notification generators are frequently operated by a human, but notification
originators and proxy forwarders are usually unmanned automated originators and proxy forwarders are usually unmanned automated
processes. The targets to whom notifications and proxied requests processes. The targets to whom notifications and proxied requests
should be sent is typically determined and configured by a network should be sent is typically determined and configured by a network
administrator. 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 originator, 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. When used with the object and an appropriate snmpTLSAddress value. When used with the
SNMPv3 message processing model, the snmpTargetParamsMPModel column SNMPv3 message processing model, the snmpTargetParamsMPModel column
of the snmpTargetParamsTable should be set to a value of 3. The of the snmpTargetParamsTable should be set to a value of 3. 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 which cipher suites to use, must
from configuration mechanisms not defined in this document. The come from configuration mechanisms not defined in this document.
securityName defined in the snmpTargetParamsSecurityName column will
be used by the access control model to authorize any notifications The securityName defined in the snmpTargetParamsSecurityName column
that need to be sent. will be used by the access control model to authorize any
notifications 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 can make 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 X.509 sides of the transport. This section discusses the use of X.509
skipping to change at page 15, line 34 skipping to change at page 15, line 29
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 (possibly the certificate itself). certificate authorities (possibly the certificate itself).
Furthermore, SNMP entities will most commonly need to be provisioned Furthermore, SNMP entities will most commonly need to be provisioned
with root certificates which represent the list of trusted with root certificates which represent the list of trusted
certificate authorities that an SNMP entity can use for certificate certificate authorities that an SNMP entity can use for certificate
verification. SNMP entities SHOULD also be provisioned with a X.509 verification. SNMP entities SHOULD also be provisioned with a X.509
certificate revocation mechanism which can be used to verify that a certificate revocation mechanism which can be used to verify that a
certificate has not been revoked. Trusted public keys from either CA certificate has not been revoked. Trusted public keys from either CA
certificates and/or self-signed certificates, MUST be installed certificates and/or self-signed certificates, MUST be installed into
through a trusted out of band mechanism into the server and its the server through a trusted out of band mechanism and their
authenticity MUST be verified 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 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
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, or
o Mapping a certificate's fingerprint value to a directly specified
tmSecurityName
As an implementation hint: implementations may choose to discard any As an implementation hint: implementations may choose to discard any
connections for which no potential tlstmCertToTSNTable mapping exists connections for which no potential tlstmCertToTSNTable mapping exists
before performing certificate verification to avoid expending before performing certificate verification to avoid expending
computational resources associated with certificate verification. computational resources associated with certificate verification.
Enterprise configurations are encouraged to map a "subjectAltName" Enterprise configurations are encouraged to map a "subjectAltName"
component of the X.509 certificate to the TLSTM specific component of the X.509 certificate to the TLSTM specific
tmSecurityName. The authenticated identity can be obtained by the tmSecurityName. The authenticated identity can be obtained by the
TLS Transport Model by extracting the subjectAltName(s) from the TLS Transport Model by extracting the subjectAltName(s) from the
skipping to change at page 16, line 26 skipping to change at page 16, line 21
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.
A pictorial view of the complete transformation process (using the A pictorial view of the complete transformation process (using the
TSM security model for the example) is shown below: TSM security model for the example) is shown below:
+-------------+ +-------+ +----------------+ +-----+ +-------------+ +-------+ +-----+
| Certificate | | | | | | | | Certificate | | | | |
| Path | | TLSTM | | tmSecurityName | | TSM | | Path | | TLSTM | tmpSecurityName | TSM |
| Validation | --> | | --> | | --> | | | Validation | --> | | ----------------->| |
+-------------+ +-------+ +----------------+ +-----+ +-------------+ +-------+ +-----+
| |
V | securityName
+-------------+ +--------------+ V
| application | <-- | securityName | +-------------+
+-------------+ +--------------+ | application |
+-------------+
4.2. Messages 4.2. Messages
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
skipping to change at page 17, line 25 skipping to change at page 17, line 22
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
) )
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 sending 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 document specifies the snmpTLSDomain, destTransportAddress. This document specifies the snmpTLSDomain,
the snmpDTLSUDPDomain and the snmpDTLSSCTPDomain" transport the snmpDTLSUDPDomain and the snmpDTLSSCTPDomain transport
domains. 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 and transmission.
outgoingMessageLength: The length of the outgoingMessage field. outgoingMessageLength: The length of the outgoingMessage field.
tmStateReference: A handle/reference to tmState to be used when tmStateReference: A reference to tmState to be used when securing
securing outgoing messages. 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
skipping to change at page 18, line 29 skipping to change at page 18, line 23
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.
transportDomain: The transport domain for the associated transportDomain: The transport domain for the associated
transportAddress. This document specifies the snmpTLSDomain, the transportAddress. This document specifies the snmpTLSDomain, the
snmpDTLSUDPDomain and the snmpDTLSSCTPDomain" transport domains. snmpDTLSUDPDomain and the snmpDTLSSCTPDomain transport domains.
transportAddress: The transport address of the source of the transportAddress: The transport address of the source of the
received message in a format specified by the SnmpTLSAddress received message in a format specified by the SnmpTLSAddress
TEXTUAL-CONVENTION. TEXTUAL-CONVENTION.
incomingMessage: The whole SNMP message after being processed by incomingMessage: The whole SNMP message after being processed by
(D)TLS and removed of the (D)TLS transport layer data. (D)TLS and the (D)TLS transport layer data has been removed.
incomingMessageLength: The length of the incomingMessage field. incomingMessageLength: The length of the incomingMessage field.
tmStateReference: A handle/reference to tmSecurityData to be used by tmStateReference: A reference to tmSecurityData to be used by the
the security model. security model.
4.4. Cached Information and References 4.4. Cached Information and References
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.
skipping to change at page 20, line 19 skipping to change at page 20, line 9
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
information is not always explicitly specified. As a general rule, information is not always explicitly specified. As a general rule,
if state information is available when a message gets discarded, the if state information is available when a message gets discarded, the
message-state information should also be released. If state message-state information should also be released. If state
information is available when a session is closed, the session state information is available when a session is closed, the session state
information should also be released. Sensitive information, like information should also be released. Sensitive information, like
cryptographic keys, should be overwritten appropriately first prior cryptographic keys, should be overwritten appropriately prior to
to being released. being released.
An error indication in statusInformation will typically include the An error indication in statusInformation will typically include the
Object Identifier (OID) and value for an incremented error counter. Object Identifier (OID) and value for an incremented error counter.
This may be accompanied by the requested securityLevel and the This may be accompanied by the requested securityLevel and the
tmStateReference. Per-message context information is not accessible tmStateReference. Per-message context information is not accessible
to Transport Models, so for the returned counter OID and value, to Transport Models, so for the returned counter OID and value,
contextEngine would be set to the local value of snmpEngineID and contextEngine would be set to the local value of snmpEngineID and
contextName to the default context for error counters. contextName to the default context for error counters.
5.1. Procedures for an Incoming Message 5.1. Procedures for an Incoming Message
This section describes the procedures followed by the (D)TLS This section describes the procedures followed by the (D)TLS
Transport Model when it receives a (D)TLS protected packet. The Transport Model when it receives a (D)TLS protected packet. The
steps are broken into two different sections. Section 5.1.1 required functionality is broken into two different sections.
describes the needed steps for de-multiplexing multiple DTLS
sessions, which is specifically needed for DTLS over UDP sessions. Section 5.1.1 describes the processing required for de-multiplexing
Section 5.1.2 describes the steps specific to transport processing multiple DTLS sessions, which is specifically needed for DTLS over
once the (D)TLS processing has been completed. It is assumed that UDP sessions. It is assumed that TLS and DTLS/SCP protocol
TLS and DTLS/SCP protocol implementations already provide appropriate implementations already provide appropriate message demultiplexing.
message demultiplexing and only the processing steps in Section 5.1.2
are needed. Section 5.1.2describes the transport processing required once the
(D)TLS processing has been completed. This will be needed for all
(D)TLS-based sessions.
5.1.1. DTLS Processing for Incoming Messages 5.1.1. DTLS Processing for Incoming Messages
DTLS over UDP is significantly different in terms of session handling DTLS over UDP is significantly different in terms of session handling
than when TLS or DTLS is run over session based streaming protocols than when TLS or DTLS is run over session based streaming protocols
like TCP or SCTP. Specifically, the DTLS protocol, when run over like TCP or SCTP. Specifically, the DTLS protocol, when run over
UDP, does not have a session identifier that allows implementations UDP, does not have a session identifier that allows implementations
to determine through which session a packet arrived. It is always to determine through which session a packet arrived. It is critical,
critical, however, that implementations be able to derive a however, that implementations are always able to derive a
tlstmSessionID from any session demultiplexing process. When tlstmSessionID from any session demultiplexing process. When
establishing a new session implementations MUST use a different UDP establishing a new session implementations MUST use a different UDP
source port number for each connection to a remote destination IP- source port number for each active connection to a remote destination
address/port-number combination to ensure the remote entity can IP-address/port-number combination to ensure the remote entity can
easily disambiguate between multiple sessions from a host to the same easily disambiguate between multiple sessions from a host to the same
port on a server. 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
skipping to change at page 21, line 31 skipping to change at page 21, line 24
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 tlstmSessionID. 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 tlstmSessionID. determine if a session already exists.
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
tlstmSessionID. The incoming packet may result in a new session tlstmSessionID. The incoming packet may result in a new session
being established if the receiving entity is acting as a DTLS being established if the receiving entity is acting as a DTLS
server. If DTLS returns success then stop processing of this server. If DTLS returns success then stop processing of this
message. If DTLS returns an error then increment the message. If DTLS returns an error then increment the
snmpTlstmSessionNoSessions counter and stop processing the snmpTlstmSessionNoSessions counter and stop processing the
message. message.
skipping to change at page 22, line 16 skipping to change at page 22, line 7
4) The UDP packet and the tlstmSessionID are passed to DTLS for 4) The UDP packet and the tlstmSessionID are passed to DTLS for
integrity checking and decryption. integrity checking and decryption.
If the message fails integrity checks or other (D)TLS security If the message fails integrity checks or other (D)TLS security
processing then increment the tlstmDTLSProtectionErrors counter, processing then increment the tlstmDTLSProtectionErrors counter,
discard and stop processing the message. discard and stop processing the message.
5) DTLS should return an incomingMessage and an 5) DTLS should return an incomingMessage and an
incomingMessageLength. These results and the tlstmSessionID are incomingMessageLength. These results and the tlstmSessionID are
used below in the Section 5.1.2 to complete the processing of the used below in Section 5.1.2 to complete the processing of the
incoming message. incoming message.
5.1.2. Transport Processing for Incoming SNMP Messages 5.1.2. Transport Processing for Incoming SNMP Messages
The procedures in this section describe how the TLS Transport Model The procedures in this section describe how the TLS Transport Model
should process messages that have already been properly extracted should process messages that have already been properly extracted
from the (D)TLS stream. Note that care must be taken when processing from the (D)TLS stream. Note that care must be taken when processing
messages originating from either TLS or DTLS to ensure they're messages originating from either TLS or DTLS to ensure they're
complete and single. 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 1) 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,
discussed in Section 3.1.2 and Section 5.3. as 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
lifetime of the (D)TLS session. the lifetime of the (D)TLS session.
tmSessionID = The tlstmSessionID, 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
this identifier are implementation-dependent as long as it is format of this identifier are implementation-dependent as long
unique to the session. A session identifier MUST NOT be reused as it is unique to the session. A session identifier MUST NOT
until all references to it are no longer in use. The tmSessionID be reused until all references to it are no longer in use.
is equal to the tlstmSessionID discussed in Section 5.1.1. The tmSessionID is equal to the tlstmSessionID discussed in
tmSessionID refers to the session identifier when stored in the Section 5.1.1. tmSessionID refers to the session identifier
tmStateReference and tlstmSessionID refers to the session when stored in the tmStateReference and tlstmSessionID refers
identifier when stored in the LCD. They MUST always be equal when to the session identifier when stored in the LCD. They MUST
processing a given session's traffic. always be equal when processing a given session's traffic.
The wholeMessage and the wholeMessageLength are assigned values from 2) The incomingMessage and incomingMessageLength are assigned values
the incomingMessage and incomingMessageLength values from the (D)TLS from the (D)TLS processing.
processing.
The TLS Transport Model passes the transportDomain, transportAddress, 3) The TLS Transport Model passes the transportDomain,
wholeMessage, and wholeMessageLength to the Dispatcher using the transportAddress, incomingMessage, and incomingMessageLength to
receiveMessage ASI: the Dispatcher using the 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 incomingMessage -- the whole SNMP message from (D)TLS
IN wholeMessageLength -- the length of the SNMP message IN incomingMessageLength -- 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(
skipping to change at page 24, line 43 skipping to change at page 24, line 32
session using the openSession() ASI (discussed further in session using the openSession() ASI (discussed further in
Section 5.3). Implementations MAY wish to offer message Section 5.3). Implementations MAY wish to offer message
buffering to prevent redundant openSession() calls for the buffering to prevent redundant openSession() calls for the
same cache entry. If an error is returned from same cache entry. If an error is returned from
openSession(), then discard the message, discard the openSession(), then discard the message, discard the
tmStateReference, increment the snmpTlstmSessionOpenErrors, tmStateReference, increment the snmpTlstmSessionOpenErrors,
return an error indication to the calling module and stop return an error indication to the calling module and stop
processing of the message. processing of the message.
6) Using either the session indicated by the tmSessionID if there 6) Using either the session indicated by the tmSessionID if there
was one or the session resulting from a previous step (3 or 4), was one or the session resulting from a previous step (4 or 5),
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: a new (D)TLS session:
statusInformation = -- errorIndication or success statusInformation = -- errorIndication or success
openSession( openSession(
skipping to change at page 26, line 43 skipping to change at page 26, line 33
b) The (D)TLS client side of the connection MUST verify that the b) The (D)TLS client side of the connection MUST verify that the
(D)TLS server's presented certificate is the expected (D)TLS server's presented certificate is the expected
certificate. The (D)TLS client MUST NOT transmit SNMP certificate. The (D)TLS client MUST NOT transmit SNMP
messages until the server certificate has been authenticated messages until the server certificate has been authenticated
and the client certificate has been transmitted. and the client certificate has been transmitted.
If the connection is being established from configuration If the connection is being established from configuration
based on SNMP-TARGET-MIB configuration then the procedures in based on SNMP-TARGET-MIB configuration then the procedures in
the tlstmAddrTable DESCRIPTION clause should be followed to the tlstmAddrTable DESCRIPTION clause should be followed to
determine if the presented identity matches the expectations determine if the presented identity matches the expectations
of the configuration. Path validation procedures (like those of the configuration. Validation procedures (like the path
defined in [RFC5280]) MUST be followed. If a server identity validation procedures defined in [RFC5280] or through the use
name has been configured in the tlstmAddrServerIdentity of fingerprints as defined by the tlstmAddrServerIdentity
column then this reference identity must be compared against column) MUST be followed. If a server identity name has been
the presented identity (for example using procedures configured in the tlstmAddrServerIdentity column then this
described in [I-D.saintandre-tls-server-id-check]). reference identity must be compared against the presented
identity (for example using procedures described in
[I-D.saintandre-tls-server-id-check]).
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 snmpTlstmSessionInvalidServerCertificates object is fail, the snmpTlstmSessionInvalidServerCertificates object is
incremented and processing stops. incremented and processing stops.
4) The TLSTM-specific session identifier (tlstmSessionID) is set in 4) The TLSTM-specific session identifier (tlstmSessionID) is set in
the tmSessionID of the tmStateReference passed to the TLS the tmSessionID of the tmStateReference passed to the TLS
Transport Model to indicate that the session has been established Transport Model to indicate that the session has been established
successfully and to point to a specific (D)TLS session for future successfully and to point to a specific (D)TLS session for future
use. use. The tlstmSessionID is also stored in the LCD for later
lookup during processing of incoming messages (Section 5.1.2).
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 a (D)TLS extension that allows server-side SHOULD make use of a (D)TLS extension that allows server-side
principal selection like the Server Name Indication extension defined principal selection like the Server Name Indication extension defined
in Section 3.1 of [RFC4366]. Supporting this will allow, for in Section 3.1 of [RFC4366]. Supporting this will allow, for
example, sending notifications to a specific principal at a given example, sending notifications to a specific principal at a given
TCP, UDP or SCTP port. TCP, UDP or SCTP port.
5.4. Closing a Session 5.4. Closing a Session
skipping to change at page 28, line 31 skipping to change at page 28, line 21
assignment of objects to their subtrees, and the intended purpose of assignment of objects to their subtrees, and the intended purpose of
each subtree, is shown below. each subtree, is shown below.
6.2. Textual Conventions 6.2. Textual Conventions
Generic and Common Textual Conventions used in this module can be Generic and Common Textual Conventions used in this module can be
found summarized at http://www.ops.ietf.org/mib-common-tcs.html found summarized at http://www.ops.ietf.org/mib-common-tcs.html
This module defines the following new Textual Conventions: This module defines the following new Textual Conventions:
o New TransportDomain and TransportAddress formats for describing o A new TransportAddress format for describing (D)TLS connection
(D)TLS connection addressing requirements. addressing requirements.
o A certificate fingerprint allowing MIB module objects to o A certificate fingerprint allowing MIB module objects to
generically refer to a stored X.509 certificate using a generically refer to a stored X.509 certificate using a
cryptographic hash as a reference pointer. cryptographic hash as a reference pointer.
6.3. Statistical Counters 6.3. Statistical Counters
The TLSTM-MIB defines some counters that can provide network managers The TLSTM-MIB defines some counters that can provide network managers
with information about (D)TLS session usage and potential errors that with information about (D)TLS session usage and potential errors that
a MIB-instrumented device may be experiencing. a MIB-instrumented device may be experiencing.
skipping to change at page 30, line 6 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 "201001080000Z" LAST-UPDATED "201001270000Z"
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 31, line 4 skipping to change at page 30, line 44
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this MIB module is part of RFC XXXX; This version of this MIB module is part of RFC XXXX;
see the RFC itself for full legal notices." see the RFC itself for full legal notices."
-- NOTE to RFC editor: replace XXXX with actual RFC number -- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document and remove this note -- for this document and remove this note
REVISION "201001080000Z"
REVISION "201001270000Z"
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 32, line 16 skipping to change at page 32, line 9
snmpDTLSUDPDomain is 'dudp'. This prefix may be used by snmpDTLSUDPDomain is 'dudp'. This prefix may be used by
security models or other components to identify which secure security models or other components to identify which secure
transport infrastructure authenticated a securityName." transport infrastructure authenticated a securityName."
::= { snmpDomains yy } ::= { snmpDomains yy }
-- RFC Ed.: replace yy with IANA-assigned number and -- RFC Ed.: replace yy with IANA-assigned number and
-- remove this note -- remove this note
-- RFC Ed.: replace 'dudp' with the actual IANA assigned prefix string -- RFC Ed.: replace 'dudp' with the actual IANA assigned prefix string
-- if 'dudp' is not assigned to this document.
snmpDTLSSCTPDomain OBJECT-IDENTITY snmpDTLSSCTPDomain OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The SNMP over DTLS/SCTP transport domain. The corresponding "The SNMP over DTLS/SCTP transport domain. The corresponding
transport address is of type SnmpTLSAddress. transport address is of type SnmpTLSAddress.
The securityName prefix to be associated with the The securityName prefix to be associated with the
snmpDTLSSCTPDomain is 'dsct'. This prefix may be used by snmpDTLSSCTPDomain is 'dsct'. This prefix may be used by
security models or other components to identify which secure security models or other components to identify which secure
transport infrastructure authenticated a securityName." transport infrastructure authenticated a securityName."
::= { snmpDomains zz } ::= { snmpDomains zz }
-- RFC Ed.: replace zz with IANA-assigned number and -- RFC Ed.: replace zz with IANA-assigned number and
-- remove this note -- remove this note
-- RFC Ed.: replace 'dsct' with the actual IANA assigned prefix string -- RFC Ed.: replace 'dsct' with the actual IANA assigned prefix string
-- if 'dsct' is not assigned to this document.
SnmpTLSAddress ::= TEXTUAL-CONVENTION SnmpTLSAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a" DISPLAY-HINT "1a"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents a IPv4 address, an IPv6 address or an US-ASCII "Represents a IPv4 address, an IPv6 address or an US-ASCII
encoded hostname and port number. encoded hostname and port number.
An IPv4 address must be in dotted decimal format followed by a An IPv4 address must be in dotted decimal format followed by a
colon ':' (US-ASCII character 0x3A) and a decimal port number colon ':' (US-ASCII character 0x3A) and a decimal port number
skipping to change at page 34, line 19 skipping to change at page 34, line 11
encoded is taken from the IANA TLS HashAlgorithm Registry encoded is taken from the IANA TLS HashAlgorithm Registry
(RFC5246). The remaining octets are filled using the results (RFC5246). The remaining octets are filled using the results
of the hashing algorithm. of the hashing algorithm.
This TEXTUAL-CONVENTION allows for a zero-length (blank) This TEXTUAL-CONVENTION allows for a zero-length (blank)
Fingerprint value for use in tables where the fingerprint value Fingerprint value for use in tables where the fingerprint value
may be optional. MIB definitions or implementations may refuse may be optional. MIB definitions or implementations may refuse
to accept a zero-length value as appropriate." to accept a zero-length value as appropriate."
REFERENCE REFERENCE
"RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 "RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
http://www.iana.org/assignments/tls-parameters/
" "
SYNTAX OCTET STRING (SIZE (0..255)) SYNTAX OCTET STRING (SIZE (0..255))
-- Identities for use in the tlstmCertToTSNTable
tlstmCertToTSNMIdentities OBJECT IDENTIFIER ::= { tlstmIdentities 1 } tlstmCertToTSNMIdentities OBJECT IDENTIFIER ::= { tlstmIdentities 1 }
tlstmCertSpecified OBJECT-IDENTITY tlstmCertSpecified OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION "Directly specifies the tmSecurityName to be used for DESCRIPTION "Directly specifies the tmSecurityName to be used for
this certificate. The value of the tmSecurityName to this certificate. The value of the tmSecurityName
use is specified in the tlstmCertToTSNData column. to use is specified in the tlstmCertToTSNData
The column must contain a SnmpAdminString compliant column. The tlstmCertToTSNData column must contain
value or contains a zero length string then the a non-zero length SnmpAdminString compliant value or
mapping will be considered a failure." the mapping described in this row must be considered
a failure."
::= { tlstmCertToTSNMIdentities 1 } ::= { tlstmCertToTSNMIdentities 1 }
tlstmCertSANRFC822Name OBJECT-IDENTITY tlstmCertSANRFC822Name OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION "Maps a subjectAltName's rfc822Name to a DESCRIPTION "Maps a subjectAltName's rfc822Name to a
tmSecurityName. The local part of the rfc822Name is tmSecurityName. The local part of the rfc822Name is
passed unaltered but the host-part of the name must passed unaltered but the host-part of the name must
be passed in lower case. be passed in lower case.
Example rfc822Name Field: FooBar@Example.COM Example rfc822Name Field: FooBar@Example.COM
is mapped to tmSecurityName: FooBar@exmaple.com" is mapped to tmSecurityName: FooBar@example.com"
::= { tlstmCertToTSNMIdentities 2 } ::= { tlstmCertToTSNMIdentities 2 }
tlstmCertSANDNSName OBJECT-IDENTITY tlstmCertSANDNSName OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION "Maps a subjectAltName's dNSName to a DESCRIPTION "Maps a subjectAltName's dNSName to a
tmSecurityName by directly passing the value without tmSecurityName by directly passing the value without
any transformations." any transformations."
::= { tlstmCertToTSNMIdentities 3 } ::= { tlstmCertToTSNMIdentities 3 }
tlstmCertSANIpAddress OBJECT-IDENTITY tlstmCertSANIpAddress OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION "Maps a subjectAltName's ipAddress to a DESCRIPTION "Maps a subjectAltName's iPAddress to a
tmSecurityName by transforming the binary encoded tmSecurityName by transforming the binary encoded
address as follows: address as follows:
1) for IPv4 the value is converted into a decimal 1) for IPv4 the value is converted into a decimal
dotted quad address (e.g. '192.0.2.1') dotted quad address (e.g. '192.0.2.1')
2) for IPv6 addresses the value is converted into a 2) for IPv6 addresses the value is converted into a
32-character hexadecimal string without any colon 32-character hexadecimal string without any colon
separators. separators.
skipping to change at page 35, line 40 skipping to change at page 35, line 32
tlstmCertSANAny OBJECT-IDENTITY tlstmCertSANAny OBJECT-IDENTITY
STATUS current STATUS current
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 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 }
skipping to change at page 37, line 22 skipping to change at page 37, line 13
snmpTlstmSessionUnknownServerCertificate 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 a known
certificate authority." certificate authority."
::= { snmpTlstmSession 6 } ::= { snmpTlstmSession 6 }
snmpTlstmSessionInvalidServerCertificates 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 error 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."
::= { snmpTlstmSession 7 } ::= { snmpTlstmSession 7 }
snmpTlstmSessionInvalidCaches OBJECT-TYPE snmpTlstmSessionInvalidCaches OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of outgoing messages dropped because the "The number of outgoing messages dropped because the
tmStateReference referred to an invalid cache." tmStateReference referred to an invalid cache."
::= { snmpTlstmSession 8 } ::= { snmpTlstmSession 8 }
tlstmTLSProtectionErrors OBJECT-TYPE snmpTlstmTLSProtectionErrors 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."
::= { snmpTlstmSession 9 } ::= { snmpTlstmSession 9 }
-- Configuration Objects -- Configuration Objects
skipping to change at page 38, line 44 skipping to change at page 38, line 36
"The value of sysUpTime.0 when the tlstmCertToTSNTable "The value of sysUpTime.0 when the tlstmCertToTSNTable
was last modified through any means, or 0 if it has not been was last modified through any means, or 0 if it has not been
modified since the command responder was started." modified since the command responder was started."
::= { tlstmCertificateMapping 2 } ::= { tlstmCertificateMapping 2 }
tlstmCertToTSNTable OBJECT-TYPE tlstmCertToTSNTable OBJECT-TYPE
SYNTAX SEQUENCE OF TlstmCertToTSNEntry SYNTAX SEQUENCE OF TlstmCertToTSNEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A table listing the X.509 certificates known to the entity "A table listing the fingerprints of X.509 certificates known
and the associated method for determining the SNMPv3 security to the entity and the associated method for determining the
name from a certificate. SNMPv3 security name from a certificate.
On an incoming (D)TLS/SNMP connection the client's presented On an incoming (D)TLS/SNMP connection the client's presented
certificate must be examined and validated based on an certificate must be examined and validated based on an
established trusted path from a CA certificate or self-signed established trusted path from a CA certificate or self-signed
public certificate (e.g. RFC5280). This table provides a public certificate (e.g. RFC5280). This table provides a
mapping from a validated certificate to a tmSecurityName. mapping from a validated certificate to a tmSecurityName.
This table does not provide any mechanisms for uploading This table does not provide any mechanisms for uploading
trusted certificates; the transfer of any needed trusted trusted certificates; the transfer of any needed trusted
certificates for path validation is expected to occur through certificates for path validation is expected to occur through
an out-of-band transfer. an out-of-band transfer.
skipping to change at page 39, line 25 skipping to change at page 39, line 15
order according to its tlstmCertToTSNID value. Each row's order according to its tlstmCertToTSNID value. Each row's
tlstmCertToTSNFingerprint value determines whether the row is a tlstmCertToTSNFingerprint value determines whether the row is a
match for the incoming connection: match for the incoming connection:
1) If the row's tlstmCertToTSNFingerprint value identifies 1) If the row's tlstmCertToTSNFingerprint value identifies
the presented certificate then consider the row as a the presented certificate then consider the row as a
successful match. successful match.
2) If the row's tlstmCertToTSNFingerprint value identifies 2) If the row's tlstmCertToTSNFingerprint value identifies
a locally held copy of a trusted CA certificate and a locally held copy of a trusted CA certificate and
that CA certificated was used to validate the path to that CA certificate was used to validate the path to
the presented certificate then consider the row as a the presented certificate then consider the row as a
successful match. successful match.
Once a matching row has been found, the tlstmCertToTSNMapType Once a matching row has been found, the tlstmCertToTSNMapType
value can be used to determine how the tmSecurityName to value can be used to determine how the tmSecurityName to
associate with the session should be determined. See the associate with the session should be determined. See the
tlstmCertToTSNMapType column's DESCRIPTION for details on tlstmCertToTSNMapType column's DESCRIPTION for details on
determining the tmSecurityName value. If it is impossible to determining the tmSecurityName value. If it is impossible to
determine a tmSecurityName from the row's data combined with the determine a tmSecurityName from the row's data combined with the
data presented in the certificate then additional rows MUST be data presented in the certificate then additional rows MUST be
skipping to change at page 40, line 4 skipping to change at page 39, line 42
another potential match. another potential match.
Missing values of tlstmCertToTSNID are acceptable and Missing values of tlstmCertToTSNID are acceptable and
implementations should continue to the next highest numbered implementations should continue to the next highest numbered
row. E.G., the table may legally contain only two rows with row. E.G., the table may legally contain only two rows with
tlstmCertToTSNID values of 10 and 20. tlstmCertToTSNID values of 10 and 20.
Users are encouraged to make use of certificates with Users are encouraged to make use of certificates with
subjectAltName fields that can be used as tmSecurityNames so subjectAltName fields that can be used as tmSecurityNames so
that a single root CA certificate can allow all child that a single root CA certificate can allow all child
certificate's subjectAltName to map directly to a tmSecurityName certificate's subjectAltName to map directly to a
via a 1:1 transformation. However, this table is flexible to tmSecurityName via a 1:1 transformation. However, this table
allow for situations where existing deployed certificate is flexible to allow for situations where existing deployed
infrastructures do not provide adequate subjectAltName values certificate infrastructures do not provide adequate
for use as tmSecurityNames. Certificates may also be subjectAltName values for use as tmSecurityNames.
mapped to tmSecurityNames using the CommonName portion of the Certificates may also be mapped to tmSecurityNames using the
Subject field but usage of the CommonName field is deprecated. CommonName portion of the Subject field. However, the usage
Direct mapping from each individual certificate fingerprint to of the CommonName field is deprecated and thus this usage is
a tmSecurityName is also possible but requires one entry in the NOT RECOMMENDED. Direct mapping from each individual
table per tmSecurityName and requires more management operations certificate fingerprint to a tmSecurityName is also possible
to completely configure a device." but requires one entry in the table per tmSecurityName and
requires more management operations to completely configure a
device."
::= { tlstmCertificateMapping 3 } ::= { tlstmCertificateMapping 3 }
tlstmCertToTSNEntry OBJECT-TYPE tlstmCertToTSNEntry OBJECT-TYPE
SYNTAX TlstmCertToTSNEntry SYNTAX TlstmCertToTSNEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A row in the tlstmCertToTSNTable that specifies a mapping for "A row in the tlstmCertToTSNTable that specifies a mapping for
an incoming (D)TLS certificate to a tmSecurityName to use for a an incoming (D)TLS certificate to a tmSecurityName to use for a
connection." connection."
skipping to change at page 40, line 42 skipping to change at page 40, line 34
tlstmCertToTSNData OCTET STRING, tlstmCertToTSNData OCTET STRING,
tlstmCertToTSNStorageType StorageType, tlstmCertToTSNStorageType StorageType,
tlstmCertToTSNRowStatus RowStatus tlstmCertToTSNRowStatus RowStatus
} }
tlstmCertToTSNID OBJECT-TYPE tlstmCertToTSNID OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295) SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A unique, prioritized index for the given entry." "A unique, prioritized index for the given entry. Lower
numbers indicate a higher priority."
::= { tlstmCertToTSNEntry 1 } ::= { tlstmCertToTSNEntry 1 }
tlstmCertToTSNFingerprint OBJECT-TYPE tlstmCertToTSNFingerprint OBJECT-TYPE
SYNTAX Fingerprint (SIZE(1..255)) SYNTAX Fingerprint (SIZE(1..255))
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A cryptographic hash of a X.509 certificate. The results of "A cryptographic hash of a X.509 certificate. The results of
a successful matching fingerprint to either the trusted CA in a successful matching fingerprint to either the trusted CA in
the certificate validation path or to the certificate itself the certificate validation path or to the certificate itself
skipping to change at page 41, line 34 skipping to change at page 41, line 27
searched for additional tlstmCertToTSNFingerprint matches to searched for additional tlstmCertToTSNFingerprint matches to
look for a mapping that succeeds." look for a mapping that succeeds."
DEFVAL { tlstmCertSpecified } DEFVAL { tlstmCertSpecified }
::= { tlstmCertToTSNEntry 3 } ::= { tlstmCertToTSNEntry 3 }
tlstmCertToTSNData OBJECT-TYPE tlstmCertToTSNData OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..1024)) SYNTAX OCTET STRING (SIZE(0..1024))
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Axillary data used as optional configuration information for "Auxiliary data used as optional configuration information for
a given mapping specified by the tlstmCertToTSNMapType column. a given mapping specified by the tlstmCertToTSNMapType column.
Only some mapping systems will make use of this column. The Only some mapping systems will make use of this column. The
value in this column MUST be ignored for any mapping type that value in this column MUST be ignored for any mapping type that
does not require data present in this column." does not require data present in this column."
DEFVAL { "" } DEFVAL { "" }
::= { tlstmCertToTSNEntry 4 } ::= { tlstmCertToTSNEntry 4 }
tlstmCertToTSNStorageType OBJECT-TYPE tlstmCertToTSNStorageType OBJECT-TYPE
SYNTAX StorageType SYNTAX StorageType
MAX-ACCESS read-create MAX-ACCESS read-create
skipping to change at page 43, line 4 skipping to change at page 42, line 46
::= { tlstmCertificateMapping 4 } ::= { tlstmCertificateMapping 4 }
tlstmParamsTableLastChanged OBJECT-TYPE tlstmParamsTableLastChanged OBJECT-TYPE
SYNTAX TimeStamp SYNTAX TimeStamp
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of sysUpTime.0 when the tlstmParamsTable "The value of sysUpTime.0 when the tlstmParamsTable
was last modified through any means, or 0 if it has not been was last modified through any means, or 0 if it has not been
modified since the command responder was started." modified since the command responder was started."
::= { tlstmCertificateMapping 5 } ::= { tlstmCertificateMapping 5 }
tlstmParamsTable OBJECT-TYPE tlstmParamsTable OBJECT-TYPE
SYNTAX SEQUENCE OF TlstmParamsEntry SYNTAX SEQUENCE OF TlstmParamsEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This table extends the SNMP-TARGET-MIB's "This table is used by a (D)TLS client when a (D)TLS session is
snmpTargetParamsTable with an additional (D)TLS client-side being set up using an entry in the SNMP-TARGET-MIB. It
certificate fingerprint identifier to use when establishing extends the SNMP-TARGET-MIB's snmpTargetParamsTable with a
new (D)TLS connections." fingerprint of a certificate to use when establishing such a
(D)TLS connection."
::= { tlstmCertificateMapping 6 } ::= { tlstmCertificateMapping 6 }
tlstmParamsEntry OBJECT-TYPE tlstmParamsEntry OBJECT-TYPE
SYNTAX TlstmParamsEntry SYNTAX TlstmParamsEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A conceptual row containing a fingerprint hash of a locally "A conceptual row containing a fingerprint hash of a locally
held certificate for a given snmpTargetParamsEntry. The held certificate for a given snmpTargetParamsEntry. The
values in this row should be ignored if the connection that values in this row should be ignored if the connection that
skipping to change at page 44, line 43 skipping to change at page 44, line 37
been set. been set.
The tlstmParamsClientFingerprint object may not be modified The tlstmParamsClientFingerprint object may not be modified
while the value of this object is active(1). while the value of this object is active(1).
An attempt to set these objects while the value of An attempt to set these objects while the value of
tlstmParamsRowStatus is active(1) will result in tlstmParamsRowStatus is active(1) will result in
an inconsistentValue error." an inconsistentValue error."
::= { tlstmParamsEntry 3 } ::= { tlstmParamsEntry 3 }
tlstmAddrCount OBJECT-TYPE tlstmAddrCount OBJECT-TYPE
SYNTAX Unsigned32 SYNTAX Unsigned32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A count of the number of entries in the tlstmAddrTable" "A count of the number of entries in the tlstmAddrTable"
::= { tlstmCertificateMapping 7 } ::= { tlstmCertificateMapping 7 }
tlstmAddrTableLastChanged OBJECT-TYPE tlstmAddrTableLastChanged OBJECT-TYPE
SYNTAX TimeStamp SYNTAX TimeStamp
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of sysUpTime.0 when the tlstmAddrTable "The value of sysUpTime.0 when the tlstmAddrTable
was last modified through any means, or 0 if it has not been was last modified through any means, or 0 if it has not been
modified since the command responder was started." modified since the command responder was started."
skipping to change at page 45, line 22 skipping to change at page 45, line 13
"The value of sysUpTime.0 when the tlstmAddrTable "The value of sysUpTime.0 when the tlstmAddrTable
was last modified through any means, or 0 if it has not been was last modified through any means, or 0 if it has not been
modified since the command responder was started." modified since the command responder was started."
::= { tlstmCertificateMapping 8 } ::= { tlstmCertificateMapping 8 }
tlstmAddrTable OBJECT-TYPE tlstmAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF TlstmAddrEntry SYNTAX SEQUENCE OF TlstmAddrEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This table extends the SNMP-TARGET-MIB's snmpTargetAddrTable "This table is used by a (D)TLS client when a (D)TLS session
with an expected (D)TLS server-side certificate identifier to is being set up using an entry in the SNMP-TARGET-MIB. It
expect when establishing a new (D)TLS connections. If a extends the SNMP-TARGET-MIB's snmpTargetAddrTable so that the
matching row in this table exists and the row is active then client can validate the certificate that the server presents.
the fingerprint identifier from the tlstmAddrServerFingerprint
columnshould be compared against the fingerprint of the
certificate being presented by the server. If the fingerprint
of the certificate presented by the server does not match the
tlstmAddrServerFingerprint column's value then the connection
MUST NOT be established.
If a matching row exists with a zero-length If there is a row in this table corresponding to the entry in
tlstmAddrServerFingerprint value and the certificate can still the SNMP-TARGET-MIB that was used to establish the session
be validated through another certificate validation path (and that row is active), then the fingerprint of the server's
(e.g. RFC5280) then the server's presented identity should be presented certificate is compared with the value of the
checked against the value of the tlstmAddrServerIdentity tlstmAddrServerFingerprint column. If fingerprint does not
column. If the server's identity does not match the reference match, then the connection MUST NOT be established.
identity found in the tlstmAddrServerIdentity column then the
connection MUST NOT be established. A tlstmAddrServerIdentity
may contain a '*' to match any server's identity or may
contain a '*.' prefix to match any server identity from a
given domain (e.g. '*.example.com').
If no matching row exists in this table then the connection If the row exists with a zero-length
SHOULD still proceed if another certificate validation path tlstmAddrServerFingerprint value and the certificate can be
algorithm (e.g. RFC5280) can be followed to a configured trust validated through another certificate validation path (such as
anchor." the path validation procedures defined in [RFC5280]) then the
server's presented identity should be checked against the
value of the tlstmAddrServerIdentity column. If the server's
identity does not match the reference identity found in the
tlstmAddrServerIdentity column then the connection MUST NOT be
established.
A tlstmAddrServerIdentity may contain a single ASCII '*'
character (ASCII code 0x2a) to match any server's identity if
the tlstmAddrServerFingerprint column is not blank. A row
MUST NOT contain both a blank tlstmAddrServerFingerprint
column and a '*' in the tlstmAddrServerIdentity column since
this would insecurely accept any presented certificate.
If there is no row in this table corresponding to an entry in
the SNMP-TARGET-MIB and another certificate validation path
algorithm (such as the path validation procedures defined in
[RFC5280]) can be used, then the connection SHOULD still
proceed."
::= { tlstmCertificateMapping 9 } ::= { tlstmCertificateMapping 9 }
tlstmAddrEntry OBJECT-TYPE tlstmAddrEntry OBJECT-TYPE
SYNTAX TlstmAddrEntry SYNTAX TlstmAddrEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A conceptual row containing a copy of a certificate's "A conceptual row containing a copy of a certificate's
fingerprint for a given snmpTargetAddrEntry. The values in fingerprint for a given snmpTargetAddrEntry. The values in
this row should be ignored if the connection that needs to be this row should be ignored if the connection that needs to be
established, as indicated by the SNMP-TARGET-MIB established, as indicated by the SNMP-TARGET-MIB
infrastructure, is not a (D)TLS based connection. If an infrastructure, is not a (D)TLS based connection. If an
tlstmAddrEntry exists for a given snmpTargetAddrEntry then the tlstmAddrEntry exists for a given snmpTargetAddrEntry then the
presented server certificate MUST match or the connection MUST presented server certificate MUST match or the connection MUST
NOT be established. If a row in this table does not exist to NOT be established. If a row in this table does not exist to
match a snmpTargetAddrEntry row then the connection SHOULD match a snmpTargetAddrEntry row then the connection SHOULD
still proceed if some other certificate validation path still proceed if some other certificate validation path
algorithm (e.g. RFC5280) can be followed to a configured trust algorithm (e.g. RFC5280) can be used."
anchor."
INDEX { IMPLIED snmpTargetAddrName } INDEX { IMPLIED snmpTargetAddrName }
::= { tlstmAddrTable 1 } ::= { tlstmAddrTable 1 }
TlstmAddrEntry ::= SEQUENCE { TlstmAddrEntry ::= SEQUENCE {
tlstmAddrServerFingerprint Fingerprint, tlstmAddrServerFingerprint Fingerprint,
tlstmAddrServerIdentity SnmpAdminString, tlstmAddrServerIdentity SnmpAdminString,
tlstmAddrStorageType StorageType, tlstmAddrStorageType StorageType,
tlstmAddrRowStatus RowStatus tlstmAddrRowStatus RowStatus
} }
skipping to change at page 46, line 51 skipping to change at page 46, line 49
::= { tlstmAddrEntry 1 } ::= { tlstmAddrEntry 1 }
tlstmAddrServerIdentity OBJECT-TYPE tlstmAddrServerIdentity OBJECT-TYPE
SYNTAX SnmpAdminString SYNTAX SnmpAdminString
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The reference identity to check against the identity "The reference identity to check against the identity
presented by the remote system. A single ASCII '*' character presented by the remote system. A single ASCII '*' character
(ASCII code 0x2a) may be used as a wildcard string and will (ASCII code 0x2a) may be used as a wildcard string and will
match any presented server identity. A '*.' prefix may also match any presented server identity."
be used to match any identity within a given domain
(e.g. '*.example.com' will match both 'foo.example.com' and
'bar.example.com')."
REFERENCE "draft-saintandre-tls-server-id-check" REFERENCE "draft-saintandre-tls-server-id-check"
DEFVAL { "*" } DEFVAL { "*" }
::= { tlstmAddrEntry 2 } ::= { tlstmAddrEntry 2 }
tlstmAddrStorageType OBJECT-TYPE tlstmAddrStorageType OBJECT-TYPE
SYNTAX StorageType SYNTAX StorageType
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The storage type for this conceptual row. Conceptual rows "The storage type for this conceptual row. Conceptual rows
skipping to change at page 47, line 43 skipping to change at page 47, line 38
Until instances of all corresponding columns are Until instances of all corresponding columns are
appropriately configured, the value of the appropriately configured, the value of the
corresponding instance of the tlstmAddrRowStatus corresponding instance of the tlstmAddrRowStatus
column is 'notReady'. column is 'notReady'.
In particular, a newly created row cannot be made active until In particular, a newly created row cannot be made active until
the corresponding tlstmAddrServerFingerprint column has been the corresponding tlstmAddrServerFingerprint column has been
set. set.
Rows MUST NOT be active if the tlstmAddrServerFingerprint
column is blank and the tlstmAddrServerIdentity is set to '*'
since this would insecurely accept any presented certificate.
The tlstmAddrServerFingerprint object may not be modified The tlstmAddrServerFingerprint object may not be modified
while the value of this object is active(1). while the value of this object is active(1).
An attempt to set these objects while the value of An attempt to set these objects while the value of
tlstmAddrRowStatus is active(1) will result in tlstmAddrRowStatus is active(1) will result in
an inconsistentValue error." an inconsistentValue error."
::= { tlstmAddrEntry 4 } ::= { tlstmAddrEntry 4 }
-- ************************************************ -- ************************************************
-- tlstmNotifications - Notifications Information -- tlstmNotifications - Notifications Information
-- ************************************************ -- ************************************************
tlstmServerCertificateUnknown NOTIFICATION-TYPE tlstmServerCertificateUnknown NOTIFICATION-TYPE
OBJECTS { snmpTlstmSessionUnknownServerCertificate } OBJECTS { snmpTlstmSessionUnknownServerCertificate }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"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 be 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,
skipping to change at page 49, line 31 skipping to change at page 49, line 31
tlstmStatsGroup OBJECT-GROUP tlstmStatsGroup OBJECT-GROUP
OBJECTS { OBJECTS {
snmpTlstmSessionOpens, snmpTlstmSessionOpens,
snmpTlstmSessionCloses, snmpTlstmSessionCloses,
snmpTlstmSessionOpenErrors, snmpTlstmSessionOpenErrors,
snmpTlstmSessionNoSessions, snmpTlstmSessionNoSessions,
snmpTlstmSessionInvalidClientCertificates, snmpTlstmSessionInvalidClientCertificates,
snmpTlstmSessionUnknownServerCertificate, snmpTlstmSessionUnknownServerCertificate,
snmpTlstmSessionInvalidServerCertificates, snmpTlstmSessionInvalidServerCertificates,
snmpTlstmSessionInvalidCaches, snmpTlstmSessionInvalidCaches,
tlstmTLSProtectionErrors snmpTlstmTLSProtectionErrors
} }
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
OBJECTS { OBJECTS {
skipping to change at page 52, line 43 skipping to change at page 52, line 43
This document describes a transport model that permits SNMP to This document describes a transport model that permits SNMP to
utilize (D)TLS security services. The security threats and how the utilize (D)TLS security services. The security threats and how the
(D)TLS transport model mitigates these threats are covered in detail (D)TLS transport model mitigates these threats are covered in detail
throughout this document. Security considerations for DTLS are throughout this document. Security considerations for DTLS are
covered in [RFC4347] and security considerations for TLS are covered in [RFC4347] and security considerations for TLS are
described in Section 11 and Appendices D, E, and F of TLS 1.2 described in Section 11 and Appendices D, E, and F of TLS 1.2
[RFC5246]. DTLS adds to the security considerations of TLS only [RFC5246]. DTLS adds to the security considerations of TLS only
because it is more vulnerable to denial of service attacks. A random because it is more vulnerable to denial of service attacks. A random
cookie exchange was added to the handshake to prevent anonymous cookie exchange was added to the handshake to prevent anonymous
denial of service attacks. RFC 4347 recommends that the cookie denial of service attacks. RFC 4347 recommends that the cookie
exchange is utilized for all handshakes and therefore this exchange is utilized for all handshakes. It is also RECOMMENDED by
specification also RECOMMENDEDs that implementers also support this this specification that users enable this cookie exchange.
cookie exchange.
9.1. Certificates, Authentication, and Authorization 9.1. Certificates, Authentication, and Authorization
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
skipping to change at page 57, line 10 skipping to change at page 57, line 10
11. Acknowledgements 11. Acknowledgements
This document closely follows and copies the Secure Shell Transport This document closely follows and copies the Secure Shell Transport
Model for SNMP defined by David Harrington and Joseph Salowey in Model for SNMP defined by David Harrington and Joseph Salowey in
[RFC5292]. [RFC5292].
This document was reviewed by the following people who helped provide This document was reviewed by the following people who helped provide
useful comments (in alphabetical order): Andy Donati, Pasi Eronen, useful comments (in alphabetical order): Andy Donati, Pasi Eronen,
David Harrington, Jeffrey Hutzelman, Alan Luchuk, Tom Petch, Randy David Harrington, Jeffrey Hutzelman, Alan Luchuk, Tom Petch, Randy
Presuhn, Ray Purvis, Joseph Salowey, Jurgen Schonwalder, Dave Shield. Presuhn, Ray Purvis, Joseph Salowey, Jurgen Schonwalder, Dave Shield,
Robert Story.
This work was supported in part by the United States Department of This work was supported in part by the United States Department of
Defense. Large portions of this document are based on work by Defense. Large portions of this document are based on work by
General Dynamics C4 Systems and the following individuals: Brian General Dynamics C4 Systems and the following individuals: Brian
Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John
Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul, Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul,
Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip. Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip.
12. References 12. References
skipping to change at page 62, line 34 skipping to change at page 62, line 34
The basic X.509 authentication procedure is as follows: A system is The basic X.509 authentication procedure is as follows: A system is
initialized with a number of root certificates that contain the initialized with a number of root certificates that contain the
public keys of a number of trusted CAs. When a system receives a public keys of a number of trusted CAs. When a system receives a
X.509 certificate, signed by one of those CAs, the certificate has to X.509 certificate, signed by one of those CAs, the certificate has to
be verified. It first checks the signatureValue field by using the be verified. It first checks the signatureValue field by using the
public key of the corresponding trusted CA. Then it compares the public key of the corresponding trusted CA. Then it compares the
digest of the received certificate with a digest of the digest of the received certificate with a digest of the
tbsCertificate field. If they match, then the subject in the tbsCertificate field. If they match, then the subject in the
tbsCertificate field is authenticated. tbsCertificate field is authenticated.
Appendix C. Target and Notificaton Configuration Example Appendix C. Target and Notification Configuration Example
Configuring the SNMP-TARGET-MIB and NOTIFICATION-MIB along with Configuring the SNMP-TARGET-MIB and NOTIFICATION-MIB along with
access control settings for the SNMP-VIEW-BASED-ACM-MIB can be a access control settings for the SNMP-VIEW-BASED-ACM-MIB can be a
daunting task without an example to follow. The following section daunting task without an example to follow. The following section
describes an example of what pieces must be in place to accomplish describes an example of what pieces must be in place to accomplish
this configuration. this configuration.
The isAccessAllowed() ASI requires configuration to exist in the The isAccessAllowed() ASI requires configuration to exist in the
following SNMP-VIEW-BASED-ACM-MIB tables: following SNMP-VIEW-BASED-ACM-MIB tables:
skipping to change at page 63, line 22 skipping to change at page 63, line 22
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 Originator
For notification generators performing authorization checks, the For notification originators 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 originator should present to
server is taken from the tlstmParamsClientFingerprint column from the the server is taken from the tlstmParamsClientFingerprint column from
appropriate entry in the tlstmParamsTable table. the 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
 End of changes. 91 change blocks. 
226 lines changed or deleted 231 lines changed or added

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