< draft-ietf-isms-dtls-tm-10.txt   draft-ietf-isms-dtls-tm-11.txt >
ISMS W. Hardaker ISMS W. Hardaker
Internet-Draft Sparta, Inc. Internet-Draft Sparta, Inc.
Intended status: Standards Track April 14, 2010 Intended status: Standards Track May 4, 2010
Expires: October 16, 2010 Expires: November 5, 2010
Transport Layer Security (TLS) Transport Model for SNMP Transport Layer Security (TLS) Transport Model for the Simple Network
draft-ietf-isms-dtls-tm-10.txt Management Protocol (SNMP)
draft-ietf-isms-dtls-tm-11.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 1, line 48 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 October 16, 2010. This Internet-Draft will expire on November 5, 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 22 skipping to change at page 3, line 22
3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 12 3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 12
3.1.3. (D)TLS Connections . . . . . . . . . . . . . . . . . . 13 3.1.3. (D)TLS Connections . . . . . . . . . . . . . . . . . . 13
3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 14 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 14
3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14
4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 15 4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 15
4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 15 4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Provisioning for the Certificate . . . . . . . . . . . 15 4.1.1. Provisioning for the Certificate . . . . . . . . . . . 15
4.2. (D)TLS Usage . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. (D)TLS Usage . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 17 4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 18 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 . . . . . . . . 18
4.4. Cached Information and References . . . . . . . . . . . . 19 4.4. Cached Information and References . . . . . . . . . . . . 19
4.4.1. TLS Transport Model Cached Information . . . . . . . . 19 4.4.1. TLS Transport Model Cached Information . . . . . . . . 19
4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 20 4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 20
4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 20 4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 20
4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 20 4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 20
5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20
5.1. Procedures for an Incoming Message . . . . . . . . . . . . 21 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 21
5.1.1. DTLS over UDP Processing for Incoming Messages . . . . 21 5.1.1. DTLS over UDP Processing for Incoming Messages . . . . 21
5.1.2. Transport Processing for Incoming SNMP Messages . . . 23 5.1.2. Transport Processing for Incoming SNMP Messages . . . 23
5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 24 5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 24
5.3. Establishing or Accepting a Session . . . . . . . . . . . 25 5.3. Establishing or Accepting a Session . . . . . . . . . . . 26
5.3.1. Establishing a Session as a Client . . . . . . . . . . 26 5.3.1. Establishing a Session as a Client . . . . . . . . . . 26
5.3.2. Accepting a Session as a Server . . . . . . . . . . . 28 5.3.2. Accepting a Session as a Server . . . . . . . . . . . 28
5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 29 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 29
6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 29 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 29
6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 29 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 30
6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 29 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 30
6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 30 6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 30
6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 30 6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 30
6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 30 6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 30
6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 30 6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 30
6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 30 6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 31
7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 31 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 31
8. Operational Considerations . . . . . . . . . . . . . . . . . . 52 8. Operational Considerations . . . . . . . . . . . . . . . . . . 53
8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 52 8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.2. Notification Receiver Credential Selection . . . . . . . . 53 8.2. Notification Receiver Credential Selection . . . . . . . . 54
8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 53 8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 54
8.4. Transport Considerations . . . . . . . . . . . . . . . . . 54 8.4. Transport Considerations . . . . . . . . . . . . . . . . . 54
9. Security Considerations . . . . . . . . . . . . . . . . . . . 54 8.5. IPv6 and securityName mapping when used with TSM and
9.1. Certificates, Authentication, and Authorization . . . . . 54 VACM . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 55 9. Security Considerations . . . . . . . . . . . . . . . . . . . 55
9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 55 9.1. Certificates, Authentication, and Authorization . . . . . 55
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 56
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58 9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 57
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
12.1. Normative References . . . . . . . . . . . . . . . . . . . 58 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
12.2. Informative References . . . . . . . . . . . . . . . . . . 59 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Appendix A. Target and Notification Configuration Example . . . . 60 12.1. Normative References . . . . . . . . . . . . . . . . . . . 60
A.1. Configuring the Notification Originator . . . . . . . . . 61 12.2. Informative References . . . . . . . . . . . . . . . . . . 61
A.2. Configuring the Command Responder . . . . . . . . . . . . 62 Appendix A. Target and Notification Configuration Example . . . . 62
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 63 A.1. Configuring a Notification Originator . . . . . . . . . . 62
A.2. Configuring TLSTM to Utilize a Simple Derivation of
tmSecurityName . . . . . . . . . . . . . . . . . . . . . . 63
A.3. Configuring TLSTM to Utilize Table-Driven Certificate
Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 63
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
It is important to understand the modular SNMPv3 architecture as It is important to understand the modular SNMPv3 architecture as
defined by [RFC3411] and enhanced by the Transport Subsystem defined by [RFC3411] and enhanced by the Transport Subsystem
[RFC5590]. It is also important to understand the terminology of the [RFC5590]. It is also important to understand the terminology of the
SNMPv3 architecture in order to understand where the Transport Model SNMPv3 architecture in order to understand where the Transport Model
described in this document fits into the architecture and how it described in this document fits into the architecture and how it
interacts with the other architecture subsystems. For a detailed interacts with the other architecture subsystems. For a detailed
overview of the documents that describe the current Internet-Standard overview of the documents that describe the current Internet-Standard
skipping to change at page 5, line 51 skipping to change at page 5, line 51
accessed through the Simple Network Management Protocol (SNMP). accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58: module that is compliant to the SMIv2, which is described in STD 58:
[RFC2578], [RFC2579] and [RFC2580]. [RFC2578], [RFC2579] and [RFC2580].
The diagram shown below gives a conceptual overview of two SNMP The diagram shown below gives a conceptual overview of two SNMP
entities communicating using the TLS Transport Model (shown as "TLS entities communicating using the TLS Transport Model (shown as "TLS
TM"). One entity contains a command responder and notification TM"). One entity contains a command responder and notification
originator application, and the other a command generator and originator application, and the other a command generator and
notification responder application. It should be understood that notification receiver application. It should be understood that this
this particular mix of application types is an example only and other particular mix of application types is an example only and other
combinations are equally valid. Note: this diagram shows the combinations are equally valid. Note: this diagram shows the
Transport Security Model (TSM) being used as the security model which Transport Security Model (TSM) being used as the security model which
is defined in [RFC5591]. is defined in [RFC5591].
+---------------------------------------------------------------------+ +---------------------------------------------------------------------+
| Network | | Network |
+---------------------------------------------------------------------+ +---------------------------------------------------------------------+
^ | ^ | ^ | ^ |
|Notifications |Commands |Commands |Notifications |Notifications |Commands |Commands |Notifications
+---|---------------------|-------+ +--|---------------|--------------+ +---|---------------------|-------+ +--|---------------|--------------+
skipping to change at page 8, line 34 skipping to change at page 8, line 34
forwarder are used. See "SNMP Applications" [RFC3413] for further forwarder are used. See "SNMP Applications" [RFC3413] for further
information. 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 specification in this document, which
which includes support for both TLS and DTLS. includes support for both TLS and DTLS.
Throughout this document, the terms "client" and "server" are used to Throughout this document, the terms "client" and "server" are used to
refer to the two ends of the (D)TLS transport connection. The client refer to the two ends of the (D)TLS transport connection. The client
actively opens the (D)TLS connection, and the server passively actively opens the (D)TLS connection, and the server passively
listens for the incoming (D)TLS connection. An SNMP entity may act listens for the incoming (D)TLS connection. An SNMP entity may act
as a (D)TLS client or server or both, depending on the SNMP as a (D)TLS client or server or both, depending on the SNMP
applications supported. applications supported.
The User-Based Security Model (USM) [RFC3414] is a mandatory-to- The User-Based Security Model (USM) [RFC3414] is a mandatory-to-
implement Security Model in STD 62. While (D)TLS and USM frequently implement Security Model in STD 62. While (D)TLS and USM frequently
skipping to change at page 9, line 34 skipping to change at page 9, line 34
peer identity authentication and data integrity between two peer identity authentication and data integrity between two
communicating SNMP entities. The TLS and DTLS protocols provide a communicating SNMP entities. The TLS and DTLS protocols provide a
secure transport upon which the TLSTM is based. Please refer to secure transport upon which the TLSTM is based. Please refer to
[RFC5246] and [RFC4347] for complete descriptions of the protocols. [RFC5246] and [RFC4347] for complete descriptions of the protocols.
3. How the TLSTM fits into the Transport Subsystem 3. How the TLSTM fits into the Transport Subsystem
A transport model is a component of the Transport Subsystem. The TLS A transport model is a component of the Transport Subsystem. The TLS
Transport Model thus fits between the underlying (D)TLS transport Transport Model thus fits between the underlying (D)TLS transport
layer and the Message Dispatcher [RFC3411] component of the SNMP layer and the Message Dispatcher [RFC3411] component of the SNMP
engine and the Transport Subsystem. engine.
The TLS Transport Model will establish a session between itself and The TLS Transport Model will establish a session between itself and
the TLS Transport Model of another SNMP engine. The sending the TLS Transport Model of another SNMP engine. The sending
transport model passes unencrypted and unauthenticated messages from transport model passes unencrypted and unauthenticated messages from
the Dispatcher to (D)TLS to be encrypted and authenticated, and the the Dispatcher to (D)TLS to be encrypted and authenticated, and the
receiving transport model accepts decrypted and authenticated/ receiving transport model accepts decrypted and authenticated/
integrity-checked incoming messages from (D)TLS and passes them to integrity-checked incoming messages from (D)TLS and passes them to
the Dispatcher. the Dispatcher.
After a TLS Transport Model session is established, SNMP messages can After a TLS Transport Model session is established, SNMP messages can
skipping to change at page 12, line 16 skipping to change at page 12, line 16
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 used 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. A TLS Transport encryption of all traffic between SNMP engines. A TLS Transport
Model implementation SHOULD support message encryption to protect Model implementation MUST support message encryption to protect
sensitive data from eavesdropping attacks. sensitive data from eavesdropping attacks.
5. Denial of Service - the RFC 3411 architecture [RFC3411] states 5. Denial of Service - the RFC 3411 architecture [RFC3411] states
that denial of service (DoS) attacks need not be addressed by an that denial of service (DoS) attacks need not be addressed by an
SNMP security protocol. However, connectionless transports (like SNMP security protocol. However, connectionless transports (like
DTLS over UDP) are susceptible to a variety of denial of service DTLS over UDP) are susceptible to a variety of denial of service
attacks because they are more vulnerable to spoofed IP addresses. attacks because they are more vulnerable to spoofed IP addresses.
See Section 4.2 for details how the cookie mechanism is used. See Section 4.2 for details how the cookie mechanism is used.
Note, however, that this mechanism does not provide any defense Note, however, that this mechanism does not provide any defense
against denial of service attacks mounted from valid IP against denial of service attacks mounted from valid IP
skipping to change at page 13, line 20 skipping to change at page 13, line 20
If a suitable interface between the TLS Transport Model and the If a suitable interface between the TLS Transport Model and the
(D)TLS Handshake Protocol is implemented to allow the selection of (D)TLS Handshake Protocol is implemented to allow the selection of
security level dependent algorithms (for example a security level to security level dependent algorithms (for example a security level to
cipher_suites mapping table) then different security levels may be cipher_suites mapping table) then different security levels may be
utilized by the application. utilized by the application.
The authentication, integrity and privacy algorithms used by the The authentication, integrity and privacy algorithms used by the
(D)TLS Protocols may vary over time as the science of cryptography (D)TLS Protocols may vary over time as the science of cryptography
continues to evolve and the development of (D)TLS continues over continues to evolve and the development of (D)TLS continues over
time. Implementers are encouraged to plan for changes in operator time. Implementers are encouraged to plan for changes in operator
trust of particular algorithms. Implementations should offer trust of particular algorithms. Implementations SHOULD offer
configuration settings for mapping algorithms to SNMPv3 security configuration settings for mapping algorithms to SNMPv3 security
levels. levels.
3.1.3. (D)TLS Connections 3.1.3. (D)TLS Connections
(D)TLS connections are opened by the TLS Transport Model during the (D)TLS connections are opened by the TLS Transport Model during the
elements of procedure for an outgoing SNMP message. Since the sender elements of procedure for an outgoing SNMP message. Since the sender
of a message initiates the creation of a (D)TLS connection if needed, of a message initiates the creation of a (D)TLS connection if needed,
the (D)TLS connection will already exist for an incoming message. the (D)TLS connection will already exist for an incoming message.
skipping to change at page 14, line 7 skipping to change at page 14, line 7
address and port attributes since their lower layer protocols (TCP) address and port attributes since their lower layer protocols (TCP)
already provide adequate session framing. But they must still already provide adequate session framing. But they must still
provide a unique tlstmSessionID for referencing the session. provide a unique tlstmSessionID for referencing the session.
The tlstmSessionID identifier MUST NOT change during the entire The tlstmSessionID identifier MUST NOT change during the entire
duration of the session from the TLSTM's perspective, and MUST duration of the session from the TLSTM's perspective, and MUST
uniquely identify a single session. As an implementation hint: note uniquely identify a single session. As an implementation hint: note
that the (D)TLS internal SessionID does not meet these requirements, that the (D)TLS internal SessionID does not meet these requirements,
since it can change over the life of the connection as seen by the since it can change over the life of the connection as seen by the
TLSTM (for example, during renegotiation), and does not necessarily TLSTM (for example, during renegotiation), and does not necessarily
uniquely idenfify a TLSTM session (there can be multiple TLSTM uniquely identify a TLSTM session (there can be multiple TLSTM
sessions sharing the same D(TLS) internal SessionID). sessions sharing the same D(TLS) internal SessionID).
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,
skipping to change at page 15, line 6 skipping to change at page 15, line 6
securityName, securityModel, and securityLevel parameters, for securityName, securityModel, and securityLevel parameters, for
notification originator, 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 or snmpDTLSUDPDomain object and an set to the snmpTLSTCPDomain or snmpDTLSUDPDomain object and an
appropriate snmpTLSAddress value. When used with the SNMPv3 message appropriate snmpTLSAddress value. When used with the SNMPv3 message
processing model, the snmpTargetParamsMPModel column of the processing model, the snmpTargetParamsMPModel column of the
snmpTargetParamsTable should be set to a value of 3. 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 snmpTlstmParamsClientFingerprint parameter securityName value and the snmpTlstmParamsClientFingerprint parameter
of the snmpTlstmParamsTable should be set a value that refers to a of the snmpTlstmParamsTable SHOULD be set a value that refers to a
locally held certificate (and the corresponding private key) to be locally held certificate (and the corresponding private key) to be
used. Other parameters, for example cryptographic configuration such used. Other parameters, for example cryptographic configuration such
as which cipher suites to use, must come from configuration as which cipher suites to use, must come from configuration
mechanisms not defined in this document. mechanisms not defined in this document.
The securityName defined in the snmpTargetParamsSecurityName column The securityName defined in the snmpTargetParamsSecurityName column
will be used by the access control model to authorize any will be used by the access control model to authorize any
notifications that need to be sent. notifications that need to be sent.
4. Elements of the Model 4. Elements of the Model
skipping to change at page 15, line 36 skipping to change at page 15, line 36
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
certificates in the TLSTM. certificates in the TLSTM.
While (D)TLS supports multiple authentication mechanisms, this While (D)TLS supports multiple authentication mechanisms, this
document only discusses X.509 certificate based authentication; other document only discusses X.509 certificate based authentication; other
forms of authentication are are outside the scope of this forms of authentication are outside the scope of this specification.
specification. TLSTM implementations are REQUIRED to support X.509 TLSTM implementations are REQUIRED to support X.509 certificates.
certificates.
4.1.1. Provisioning for the Certificate 4.1.1. Provisioning for the Certificate
Authentication using (D)TLS will require that SNMP entities have Authentication using (D)TLS will require that SNMP entities have
certificates, either signed by trusted certification authorities, or certificates, either signed by trusted certification authorities, or
self-signed. Furthermore, SNMP entities will most commonly need to self-signed. Furthermore, SNMP entities will most commonly need to
be provisioned with root certificates which represent the list of be provisioned with root certificates which represent the list of
trusted certificate authorities that an SNMP entity can use for trusted certificate authorities that an SNMP entity can use for
certificate verification. SNMP entities SHOULD also be provisioned certificate verification. SNMP entities SHOULD also be provisioned
with a X.509 certificate revocation mechanism which can be used to with a X.509 certificate revocation mechanism which can be used to
skipping to change at page 16, line 23 skipping to change at page 16, line 22
a tmSecurityName, or a tmSecurityName, or
o Mapping a certificate's fingerprint value to a directly specified o Mapping a certificate's fingerprint value to a directly specified
tmSecurityName 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 snmpTlstmCertToTSNTable mapping connections for which no potential snmpTlstmCertToTSNTable mapping
exists before performing certificate verification to avoid expending exists 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" Deployments SHOULD map the "subjectAltName" component of X.509
component of the X.509 certificate to the TLSTM specific certificates to the TLSTM specific tmSecurityNames. The
tmSecurityName. The authenticated identity can be obtained by the authenticated identity can be obtained by the TLS Transport Model by
TLS Transport Model by extracting the subjectAltName(s) from the extracting the subjectAltName(s) from the peer's certificate. The
peer's certificate. The receiving application will then have an receiving application will then have an appropriate tmSecurityName
appropriate tmSecurityName for use by other SNMPv3 components like an for use by other SNMPv3 components like an access control model.
access control model.
An example of this type of mapping setup can be found in Appendix A. An example of this type of mapping setup can be found in Appendix A.
This tmSecurityName may be later translated from a TLSTM specific This tmSecurityName may be later translated from a TLSTM specific
tmSecurityName to a SNMP engine securityName by the security model. tmSecurityName to a SNMP engine securityName by the security model.
A security model, like the TSM security model [RFC5591], may perform A security model, like the TSM security model [RFC5591], may perform
an identity mapping or a more complex mapping to derive the an identity mapping or a more complex mapping to derive the
securityName from the tmSecurityName offered by the TLS Transport securityName from the tmSecurityName offered by the TLS Transport
Model. Model.
skipping to change at page 18, line 42 skipping to change at page 18, line 34
destTransportAddress. This document specifies the destTransportAddress. This document specifies the
snmpTLSTCPDomain and the snmpDTLSUDPDomain transport domains. snmpTLSTCPDomain and the snmpDTLSUDPDomain transport domains.
destTransportAddress: The transport address of the destination TLS destTransportAddress: The transport address of the destination TLS
Transport Model in a format specified by the SnmpTLSAddress Transport Model in a format specified by the SnmpTLSAddress
TEXTUAL-CONVENTION. TEXTUAL-CONVENTION.
outgoingMessage: The outgoing message to send to (D)TLS for outgoingMessage: The outgoing message to send to (D)TLS for
encapsulation and transmission. encapsulation and transmission.
outgoingMessageLength: The length of the outgoingMessage field. outgoingMessageLength: The length of the outgoingMessage.
tmStateReference: A reference to tmState to be used when securing tmStateReference: A reference used to pass model-specific and
outgoing messages. mechanism-specific parameters between the Transport Subsystem and
transport-aware Security Models.
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 19, line 30 skipping to change at page 19, line 30
transportDomain: The transport domain for the associated transportDomain: The transport domain for the associated
transportAddress. This document specifies the snmpTLSTCPDomain transportAddress. This document specifies the snmpTLSTCPDomain
and the snmpDTLSUDPDomain transport domains. and the snmpDTLSUDPDomain 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 the (D)TLS transport layer data has been removed. (D)TLS.
incomingMessageLength: The length of the incomingMessage field. incomingMessageLength: The length of the incomingMessage.
tmStateReference: A reference to tmSecurityData to be used by the tmStateReference: A reference used to pass model-specific and
security model. mechanism-specific parameters between the Transport Subsystem and
transport-aware Security Models.
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 10 skipping to change at page 20, line 10
The TLS Transport Model has specific responsibilities regarding the The TLS Transport Model has specific responsibilities regarding the
cached information. See the Elements of Procedure in Section 5 for cached information. See the Elements of Procedure in Section 5 for
detailed processing instructions on the use of the tmStateReference detailed processing instructions on the use of the tmStateReference
fields by the TLS Transport Model. fields by the TLS Transport Model.
4.4.1.1. tmSecurityName 4.4.1.1. tmSecurityName
The tmSecurityName MUST be a human-readable name (in snmpAdminString The tmSecurityName MUST be a human-readable name (in snmpAdminString
format) representing the identity that has been set according to the format) representing the identity that has been set according to the
procedures in Section 5. The tmSecurityName MUST be constant for all procedures in Section 5. The tmSecurityName MUST be constant for all
traffic passing through an TLSTM session. Messages MUST NOT be sent traffic passing through a single TLSTM session. Messages MUST NOT be
through an existing (D)TLS connection that was established using a sent through an existing (D)TLS connection that was established using
different tmSecurityName. a different tmSecurityName.
On the (D)TLS server side of a connection the tmSecurityName is On the (D)TLS server side of a connection the tmSecurityName is
derived using the procedures described in Section 5.3.2 and the SNMP- derived using the procedures described in Section 5.3.2 and the SNMP-
TLS-TM-MIB's snmpTlstmCertToTSNTable DESCRIPTION clause. TLS-TM-MIB's snmpTlstmCertToTSNTable DESCRIPTION clause.
On the (D)TLS client side of a connection the tmSecurityName is On the (D)TLS client side of a connection the tmSecurityName is
presented to the TLS Transport Model by the application (possibly presented to the TLS Transport Model by the application (possibly
because of configuration specified in the SNMP-TARGET-MIB). because of configuration specified in the SNMP-TARGET-MIB).
The securityName MAY be derived from the tmSecurityName by a Security The securityName MAY be derived from the tmSecurityName by a Security
skipping to change at page 22, line 20 skipping to change at page 22, line 20
implementation), the steps below describe one possible method to implementation), the steps below describe one possible method to
accomplish this. accomplish this.
The important output results from the steps in this process are the The important output results from the steps in this process are the
remote transport address, incomingMessage, incomingMessageLength, and remote transport address, incomingMessage, incomingMessageLength, and
the tlstmSessionID. the 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 Local Configuration Datastore
(LCD) (see [RFC3411] Section 3.4.2) using the transport
parameters (source and destination IP addresses and ports) to parameters (source and destination IP addresses and ports) to
determine if a session already exists. determine if a session already exists.
2a) If a matching entry in the LCD does not exist, then the UDP 2a) If a matching entry in the LCD does not exist, then the UDP
packet is passed to the DTLS implementation for processing. packet is passed to the DTLS implementation for processing.
If the DTLS implementation decides to continue with the If the DTLS implementation decides to continue with the
connection and allocate state for it, it returns a new DTLS connection and allocate state for it, it returns a new DTLS
connection handle (an implementation dependent detail). In connection handle (an implementation dependent detail). In
this case, TLSTM selects a new tlstmSessionId, and caches this case, TLSTM selects a new tlstmSessionId, and caches
this and the DTLS connection handle as a new entry in the this and the DTLS connection handle as a new entry in the
skipping to change at page 25, line 32 skipping to change at page 25, line 39
the calling module and stop processing of the message. the calling module and stop processing of the message.
5) If tmSessionID is undefined, then use tmTransportDomain, 5) If tmSessionID is undefined, then use tmTransportDomain,
tmTransportAddress, tmSecurityName and tmRequestedSecurityLevel tmTransportAddress, tmSecurityName and tmRequestedSecurityLevel
to see if there is a corresponding entry in the LCD suitable to to see if there is a corresponding entry in the LCD suitable to
send the message over. send the message over.
5a) If there is a corresponding LCD entry, then this session 5a) If there is a corresponding LCD entry, then this session
will be used to send the message. will be used to send the message.
5b) If there is not a corresponding LCD entry, then open a 5b) If there is no corresponding LCD entry, then open a session
session using the openSession() ASI (discussed further in using the openSession() ASI (discussed further in
Section 5.3.1). Implementations MAY wish to offer message Section 5.3.1). 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 (4 or 5), was one or the session resulting from a previous step (4 or 5),
skipping to change at page 27, line 52 skipping to change at page 28, line 14
command line argument. command line argument.
5) (D)TLS provides assurance that the authenticated identity has 5) (D)TLS provides assurance that the authenticated identity has
been signed by a trusted configured certification authority. If been signed by a trusted configured certification authority. If
verification of the server's certificate fails in any way (for verification of the server's certificate fails in any way (for
example because of failures in cryptographic verification or the example because of failures in cryptographic verification or the
presented identity did not match the expected named entity) then presented identity did not match the expected named entity) then
the session establishment MUST fail, the the session establishment MUST fail, the
snmpTlstmSessionInvalidServerCertificates object is incremented. snmpTlstmSessionInvalidServerCertificates object is incremented.
If the session can not be opened for any reason at all, including If the session can not be opened for any reason at all, including
cryptographic verification failures, then the cryptographic verification failures and snmpTlstmCertToTSNTable
snmpTlstmSessionOpenErrors counter is incremented and processing lookup failures, then the snmpTlstmSessionOpenErrors counter is
stops. incremented and processing stops.
6) The TLSTM-specific session identifier (tlstmSessionID) is set in 6) 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 connection for successfully and to point to a specific (D)TLS connection for
future use. The tlstmSessionID is also stored in the LCD for future use. The tlstmSessionID is also stored in the LCD for
later lookup during processing of incoming messages later lookup during processing of incoming messages
(Section 5.1.2). (Section 5.1.2).
5.3.2. Accepting a Session as a Server 5.3.2. Accepting a Session as a Server
skipping to change at page 29, line 27 skipping to change at page 29, line 36
engine closing the corresponding SNMP session. engine closing the corresponding SNMP session.
1) Increment either the snmpTlstmSessionClientCloses or the 1) Increment either the snmpTlstmSessionClientCloses or the
snmpTlstmSessionServerCloses counter as appropriate. snmpTlstmSessionServerCloses counter as appropriate.
2) Look up the session using the tmSessionID. 2) Look up the session using the tmSessionID.
3) If there is no open session associated with the tmSessionID, then 3) If there is no open session associated with the tmSessionID, then
closeSession processing is completed. closeSession processing is completed.
4) Have (D)TLS close the specified connection. This SHOULD include 4) Have (D)TLS close the specified connection. This MUST include
sending a close_notify TLS Alert to inform the other side that sending a close_notify TLS Alert to inform the other side that
session cleanup may be performed. session cleanup may be performed.
6. MIB Module Overview 6. MIB Module Overview
This MIB module provides management of the TLS Transport Model. It This MIB module provides management of the TLS Transport Model. It
defines needed textual conventions, statistical counters, defines needed textual conventions, statistical counters,
notifications and configuration infrastructure necessary for session notifications and configuration infrastructure necessary for session
establishment. Example usage of the configuration tables can be establishment. Example usage of the configuration tables can be
found in Appendix A. found in Appendix A.
skipping to change at page 30, line 4 skipping to change at page 30, line 16
Objects in this MIB module are arranged into subtrees. Each subtree Objects in this MIB module are arranged into subtrees. Each subtree
is organized as a set of related objects. The overall structure and is organized as a set of related objects. The overall structure and
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 A new TransportAddress format for describing (D)TLS connection o A new TransportAddress format for describing (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 SNMP-TLS-TM-MIB defines some counters that can provide network The SNMP-TLS-TM-MIB defines counters that provide network management
management stations with information about session usage and stations with information about session usage and potential errors
potential errors that a MIB-instrumented device may be experiencing. that a MIB-instrumented device may be experiencing.
6.4. Configuration Tables 6.4. Configuration Tables
The SNMP-TLS-TM-MIB defines configuration tables that an The SNMP-TLS-TM-MIB defines configuration tables that an
administrator can use for configuring a MIB-instrumented device for administrator can use for configuring a MIB-instrumented device for
sending and receiving SNMP messages over (D)TLS. In particular, sending and receiving SNMP messages over (D)TLS. In particular,
there are MIB tables that extend the SNMP-TARGET-MIB for configuring there are MIB tables that extend the SNMP-TARGET-MIB for configuring
(D)TLS certificate usage and a MIB table for mapping incoming (D)TLS (D)TLS certificate usage and a MIB table for mapping incoming (D)TLS
client certificates to SNMPv3 securityNames. client certificates to SNMPv3 securityNames.
skipping to change at page 31, line 28 skipping to change at page 31, line 39
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
; ;
snmpTlstmMIB MODULE-IDENTITY snmpTlstmMIB MODULE-IDENTITY
LAST-UPDATED "201004140000Z" LAST-UPDATED "201005040000Z"
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 32, line 4 skipping to change at page 32, line 16
Russ Mundy Russ Mundy
SPARTA, Inc. SPARTA, Inc.
7110 Samuel Morse Drive 7110 Samuel Morse Drive
Columbia, MD 21046 Columbia, MD 21046
USA USA
Editor: Editor:
Wes Hardaker Wes Hardaker
Sparta, Inc. Sparta, Inc.
P.O. Box 382 P.O. Box 382
Davis, CA 95617 Davis, CA 95617
USA USA
ietf@hardakers.net ietf@hardakers.net
" "
DESCRIPTION " DESCRIPTION "
The TLS Transport Model MIB The TLS Transport Model MIB
Copyright (c) 2010 IETF Trust and the persons identified as Copyright (c) 2010 IETF Trust and the persons identified as
the document authors. All rights reserved. the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info)." (http://trustee.ietf.org/license-info)."
REVISION "201004140000Z" REVISION "201005040000Z"
DESCRIPTION "This version of this MIB module is part of DESCRIPTION "This version of this MIB module is part of
RFC XXXX; see the RFC itself for full legal RFC XXXX; see the RFC itself for full legal
notices." 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 change the date to the -- for this document and change the date to the
-- current date and remove this note -- current date and remove this note
::= { mib-2 www } ::= { mib-2 www }
-- RFC Ed.: replace www with IANA-assigned number under the mib-2 -- RFC Ed.: replace www with IANA-assigned number under the mib-2
skipping to change at page 32, line 40 skipping to change at page 33, line 4
-- for this document and change the date to the -- for this document and change the date to the
-- current date and remove this note -- current date and remove this note
::= { mib-2 www } ::= { mib-2 www }
-- RFC Ed.: replace www with IANA-assigned number under the mib-2 -- RFC Ed.: replace www with IANA-assigned number under the mib-2
-- SNMP OID tree and remove this note -- SNMP OID tree and remove this note
-- ************************************************ -- ************************************************
-- subtrees of the SNMP-TLS-TM-MIB -- subtrees of the SNMP-TLS-TM-MIB
-- ************************************************ -- ************************************************
snmpTlstmNotifications OBJECT IDENTIFIER ::= { snmpTlstmMIB 0 } snmpTlstmNotifications OBJECT IDENTIFIER ::= { snmpTlstmMIB 0 }
snmpTlstmIdentities OBJECT IDENTIFIER ::= { snmpTlstmMIB 1 } snmpTlstmIdentities OBJECT IDENTIFIER ::= { snmpTlstmMIB 1 }
snmpTlstmObjects OBJECT IDENTIFIER ::= { snmpTlstmMIB 2 } snmpTlstmObjects OBJECT IDENTIFIER ::= { snmpTlstmMIB 2 }
snmpTlstmConformance OBJECT IDENTIFIER ::= { snmpTlstmMIB 3 } snmpTlstmConformance OBJECT IDENTIFIER ::= { snmpTlstmMIB 3 }
-- ************************************************ -- ************************************************
-- snmpTlstmObjects - Objects -- snmpTlstmObjects - Objects
-- ************************************************ -- ************************************************
snmpTLSTCPDomain OBJECT-IDENTITY snmpTLSTCPDomain OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The SNMP over TLS transport domain. The corresponding "The SNMP over TLS 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
snmpTLSTCPDomain is 'tls'. This prefix may be used by snmpTLSTCPDomain is 'tls'. 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."
REFERENCE
"RFC 2579: Textual Conventions for SMIv2"
::= { snmpDomains xx } ::= { snmpDomains xx }
-- RFC Ed.: replace xx with IANA-assigned number and -- RFC Ed.: replace xx with IANA-assigned number and
-- remove this note -- remove this note
-- RFC Ed.: replace 'tls' with the actual IANA assigned prefix string -- RFC Ed.: replace 'tls' with the actual IANA assigned prefix string
-- if 'tls' is not assigned to this document. -- if 'tls' is not assigned to this document.
snmpDTLSUDPDomain OBJECT-IDENTITY snmpDTLSUDPDomain OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The SNMP over DTLS/UDP transport domain. The corresponding "The SNMP over DTLS/UDP 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
snmpDTLSUDPDomain is 'dtls'. This prefix may be used by snmpDTLSUDPDomain is 'dtls'. 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."
REFERENCE
"RFC 2579: Textual Conventions for SMIv2"
::= { 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 'dtls' with the actual IANA assigned prefix string -- RFC Ed.: replace 'dtls' with the actual IANA assigned prefix string
-- if 'dtls' is not assigned to this document. -- if 'dtls' 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
in US-ASCII. in US-ASCII.
An IPv6 address must be a colon separated format, surrounded An IPv6 address must be a colon separated format (as described
by square brackets ('[', US-ASCII character 0x5B, and ']', in I-D.ietf-6man-text-addr-representation), surrounded by
square brackets ('[', US-ASCII character 0x5B, and ']',
US-ASCII character 0x5D), followed by a colon ':' (US-ASCII US-ASCII character 0x5D), followed by a colon ':' (US-ASCII
character 0x3A) and a decimal port number in US-ASCII. character 0x3A) and a decimal port number in US-ASCII.
A hostname is always in US-ASCII (as per RFC1033); A hostname is always in US-ASCII (as per RFC1033);
internationalized hostnames are encoded in US-ASCII as internationalized hostnames are encoded in US-ASCII as domain
specified in RFC 3490. The hostname is followed by a colon names after transformation via the ToASCII operation specified
':' (US-ASCII character 0x3A) and a decimal port number in in RFC 3490. The ToASCII operation MUST be performed with the
US-ASCII. The name SHOULD be fully qualified whenever UseSTD3ASCIIRules flag set. The hostname is followed by a
colon ':' (US-ASCII character 0x3A) and a decimal port number
in US-ASCII. The name SHOULD be fully qualified whenever
possible. possible.
Values of this textual convention may not be directly usable Values of this textual convention may not be directly usable
as transport-layer addressing information, and may require as transport-layer addressing information, and may require
run-time resolution. As such, applications that write them run-time resolution. As such, applications that write them
must be prepared for handling errors if such values are not must be prepared for handling errors if such values are not
supported, or cannot be resolved (if resolution occurs at the supported, or cannot be resolved (if resolution occurs at the
time of the management operation). time of the management operation).
The DESCRIPTION clause of TransportAddress objects that may The DESCRIPTION clause of TransportAddress objects that may
skipping to change at page 34, line 47 skipping to change at page 35, line 17
sub-identifiers specified in SMIv2 (STD 58). It is RECOMMENDED sub-identifiers specified in SMIv2 (STD 58). It is RECOMMENDED
that all MIB documents using this textual convention make that all MIB documents using this textual convention make
explicit any limitations on index component lengths that explicit any limitations on index component lengths that
management software must observe. This may be done either by management software must observe. This may be done either by
including SIZE constraints on the index components or by including SIZE constraints on the index components or by
specifying applicable constraints in the conceptual row specifying applicable constraints in the conceptual row
DESCRIPTION clause or in the surrounding documentation." DESCRIPTION clause or in the surrounding documentation."
REFERENCE REFERENCE
"RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE "RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE
RFC 3490: Internationalizing Domain Names in Applications RFC 3490: Internationalizing Domain Names in Applications
RFC 3986: Uniform Resource Identifier (URI): Generic Syntax I-D.ietf-6man-text-addr-representation:
RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 A Recommendation for IPv6 Address Text Representation
" "
SYNTAX OCTET STRING (SIZE (1..255)) SYNTAX OCTET STRING (SIZE (1..255))
Fingerprint ::= TEXTUAL-CONVENTION -- RFC Editor: if I-D.ietf-6man-text-addr-representation fails to get
-- published ahead of this draft, RFC3513 has been agreed to be a
-- sufficient replacement instead.
SnmpTLSFingerprint ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1x:254x" DISPLAY-HINT "1x:254x"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A Fingerprint value that can be used to uniquely reference "A fingerprint value that can be used to uniquely reference
other data of potentially arbitrary length. other data of potentially arbitrary length.
A Fingerprint value is composed of a 1-octet hashing algorithm A SnmpTLSFingerprint value is composed of a 1-octet hashing
identifier followed by the fingerprint value. The octet value algorithm identifier followed by the fingerprint value. The
encoded is taken from the IANA TLS HashAlgorithm Registry octet value encoded is taken from the IANA TLS HashAlgorithm
(RFC5246). The remaining octets are filled using the results Registry (RFC5246). The remaining octets are filled using the
of the hashing algorithm. results 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 SnmpTLSFingerprint value for use in tables where the
may be optional. MIB definitions or implementations may refuse fingerprint value may be optional. MIB definitions or
to accept a zero-length value as appropriate." implementations may refuse to accept a zero-length value as
REFERENCE appropriate." REFERENCE "RFC 5246: The Transport Layer
"RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 Security (TLS) Protocol Version 1.2
http://www.iana.org/assignments/tls-parameters/ http://www.iana.org/assignments/tls-parameters/ " SYNTAX OCTET
" STRING (SIZE (0..255))
SYNTAX OCTET STRING (SIZE (0..255))
-- Identities for use in the snmpTlstmCertToTSNTable -- Identities for use in the snmpTlstmCertToTSNTable
snmpTlstmCertToTSNMIdentities OBJECT IDENTIFIER snmpTlstmCertToTSNMIdentities OBJECT IDENTIFIER
::= { snmpTlstmIdentities 1 } ::= { snmpTlstmIdentities 1 }
snmpTlstmCertSpecified OBJECT-IDENTITY snmpTlstmCertSpecified 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 this certificate. The value of the tmSecurityName
skipping to change at page 36, line 40 skipping to change at page 37, line 14
snmpTsmConfigurationUsePrefix object for details) snmpTsmConfigurationUsePrefix object for details)
will result in securityName lengths that exceed will result in securityName lengths that exceed
what VACM can handle." what VACM can handle."
::= { snmpTlstmCertToTSNMIdentities 4 } ::= { snmpTlstmCertToTSNMIdentities 4 }
snmpTlstmCertSANAny OBJECT-IDENTITY snmpTlstmCertSANAny 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 | snmpTlstmCertSANRFC822Name | | rfc822Name | snmpTlstmCertSANRFC822Name |
| dNSName | snmpTlstmCertSANDNSName | | dNSName | snmpTlstmCertSANDNSName |
| iPAddress | snmpTlstmCertSANIpAddress | | iPAddress | snmpTlstmCertSANIpAddress |
|------------+------------------------| |------------+----------------------------|
The first matching subjectAltName value found in the The first matching subjectAltName value found in the
certificate of the above types MUST be used when certificate of the above types MUST be used when
deriving the tmSecurityName." deriving the tmSecurityName. The mapping algorithm
specified in the 'Algorithm' column MUST be used to
derive the tmSecurityName."
::= { snmpTlstmCertToTSNMIdentities 5 } ::= { snmpTlstmCertToTSNMIdentities 5 }
snmpTlstmCertCommonName OBJECT-IDENTITY snmpTlstmCertCommonName OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION "Maps a certificate's CommonName to a tmSecurityName DESCRIPTION "Maps a certificate's CommonName to a tmSecurityName
after converting it to a UTF-8 encoding." after converting it to a UTF-8 encoding."
::= { snmpTlstmCertToTSNMIdentities 6 } ::= { snmpTlstmCertToTSNMIdentities 6 }
-- The snmpTlstmSession Group -- The snmpTlstmSession Group
skipping to change at page 41, line 11 skipping to change at page 41, line 36
the row's data combined with the data presented in the the row's data combined with the data presented in the
certificate then additional rows MUST be searched looking for certificate then additional rows MUST be searched looking for
another potential match. If a resulting tmSecurityName mapped another potential match. If a resulting tmSecurityName mapped
from a given row is not compatible with the needed from a given row is not compatible with the needed
requirements of a tmSecurityName (e.g., VACM imposes a requirements of a tmSecurityName (e.g., VACM imposes a
32-octet-maximum length and the certificate derived 32-octet-maximum length and the certificate derived
securityName could be longer) then it must be considered an securityName could be longer) then it must be considered an
invalid match and additional rows MUST be searched looking for invalid match and additional rows MUST be searched looking for
another potential match. another potential match.
If no matching and valid row can be found, the connection MUST
be closed and SNMP messages MUST NOT be accepted over it.
Missing values of snmpTlstmCertToTSNID are acceptable and Missing values of snmpTlstmCertToTSNID 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. It is recommended that administrators skip index values
snmpTlstmCertToTSNID values of 10 and 20. to leave room for the insertion of future rows (E.G., use values
of 10 and 20 when creating initial rows).
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 certificate's subjectAltName to map directly to a
tmSecurityName via a 1:1 transformation. However, this table tmSecurityName via a 1:1 transformation. However, this table
is flexible to allow for situations where existing deployed is flexible to allow for situations where existing deployed
certificate infrastructures do not provide adequate certificate infrastructures do not provide adequate
subjectAltName values for use as tmSecurityNames. subjectAltName values for use as tmSecurityNames.
Certificates may also be mapped to tmSecurityNames using the Certificates may also be mapped to tmSecurityNames using the
skipping to change at page 41, line 47 skipping to change at page 42, line 28
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A row in the snmpTlstmCertToTSNTable that specifies a mapping "A row in the snmpTlstmCertToTSNTable that specifies a mapping
for an incoming (D)TLS certificate to a tmSecurityName to use for an incoming (D)TLS certificate to a tmSecurityName to use
for a connection." for a connection."
INDEX { snmpTlstmCertToTSNID } INDEX { snmpTlstmCertToTSNID }
::= { snmpTlstmCertToTSNTable 1 } ::= { snmpTlstmCertToTSNTable 1 }
SnmpTlstmCertToTSNEntry ::= SEQUENCE { SnmpTlstmCertToTSNEntry ::= SEQUENCE {
snmpTlstmCertToTSNID Unsigned32, snmpTlstmCertToTSNID Unsigned32,
snmpTlstmCertToTSNFingerprint Fingerprint, snmpTlstmCertToTSNFingerprint SnmpTLSFingerprint,
snmpTlstmCertToTSNMapType AutonomousType, snmpTlstmCertToTSNMapType AutonomousType,
snmpTlstmCertToTSNData OCTET STRING, snmpTlstmCertToTSNData OCTET STRING,
snmpTlstmCertToTSNStorageType StorageType, snmpTlstmCertToTSNStorageType StorageType,
snmpTlstmCertToTSNRowStatus RowStatus snmpTlstmCertToTSNRowStatus RowStatus
} }
snmpTlstmCertToTSNID OBJECT-TYPE snmpTlstmCertToTSNID 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. Lower "A unique, prioritized index for the given entry. Lower
numbers indicate a higher priority." numbers indicate a higher priority."
::= { snmpTlstmCertToTSNEntry 1 } ::= { snmpTlstmCertToTSNEntry 1 }
snmpTlstmCertToTSNFingerprint OBJECT-TYPE snmpTlstmCertToTSNFingerprint OBJECT-TYPE
SYNTAX Fingerprint (SIZE(1..255)) SYNTAX SnmpTLSFingerprint (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
is dictated by the snmpTlstmCertToTSNMapType column." is dictated by the snmpTlstmCertToTSNMapType column."
::= { snmpTlstmCertToTSNEntry 2 } ::= { snmpTlstmCertToTSNEntry 2 }
snmpTlstmCertToTSNMapType OBJECT-TYPE snmpTlstmCertToTSNMapType OBJECT-TYPE
skipping to change at page 42, line 44 skipping to change at page 43, line 24
be specified in the DESCRIPTION clause of the OBJECT-IDENTITY be specified in the DESCRIPTION clause of the OBJECT-IDENTITY
that describes the mapping. If a mapping succeeds it will that describes the mapping. If a mapping succeeds it will
return a tmSecurityName for use by the TLSTM model and return a tmSecurityName for use by the TLSTM model and
processing stops. processing stops.
If the resulting mapped value is not compatible with the If the resulting mapped value is not compatible with the
needed requirements of a tmSecurityName (e.g., VACM imposes a needed requirements of a tmSecurityName (e.g., VACM imposes a
32-octet-maximum length and the certificate derived 32-octet-maximum length and the certificate derived
securityName could be longer) then future rows MUST be securityName could be longer) then future rows MUST be
searched for additional snmpTlstmCertToTSNFingerprint matches searched for additional snmpTlstmCertToTSNFingerprint matches
to look for a mapping that succeeds." to look for a mapping that succeeds.
Suitable values for assigning to this object that are defined
within the SNMP-TLS-TM-MIB can be found in the
snmpTlstmCertToTSNMIdentities portion of the MIB tree."
DEFVAL { snmpTlstmCertSpecified } DEFVAL { snmpTlstmCertSpecified }
::= { snmpTlstmCertToTSNEntry 3 } ::= { snmpTlstmCertToTSNEntry 3 }
snmpTlstmCertToTSNData OBJECT-TYPE snmpTlstmCertToTSNData 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
"Auxiliary data used as optional configuration information for "Auxiliary data used as optional configuration information for
a given mapping specified by the snmpTlstmCertToTSNMapType a given mapping specified by the snmpTlstmCertToTSNMapType
skipping to change at page 43, line 37 skipping to change at page 44, line 22
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The status of this conceptual row. This object may be used "The status of this conceptual row. This object may be used
to create or remove rows from this table. to create or remove rows from this table.
To create a row in this table, an administrator must set this To create a row in this table, an administrator must set this
object to either createAndGo(4) or createAndWait(5). object to either createAndGo(4) or createAndWait(5).
Until instances of all corresponding columns are appropriately Until instances of all corresponding columns are appropriately
configured, the value of the corresponding instance of the configured, the value of the corresponding instance of the
snmpTlstmParamsRowStatus column is 'notReady'. snmpTlstmParamsRowStatus column is notReady(3).
In particular, a newly created row cannot be made active until In particular, a newly created row cannot be made active until
the corresponding snmpTlstmCertToTSNFingerprint, the corresponding snmpTlstmCertToTSNFingerprint,
snmpTlstmCertToTSNMapType, and snmpTlstmCertToTSNData columns snmpTlstmCertToTSNMapType, and snmpTlstmCertToTSNData columns
have been set. have been set.
The following objects may not be modified while the The following objects may not be modified while the
value of this object is active(1): value of this object is active(1):
- snmpTlstmCertToTSNFingerprint - snmpTlstmCertToTSNFingerprint
- snmpTlstmCertToTSNMapType - snmpTlstmCertToTSNMapType
skipping to change at page 45, line 9 skipping to change at page 45, line 42
infrastructure, is not a certificate and (D)TLS based infrastructure, is not a certificate and (D)TLS based
connection. The connection SHOULD NOT be established if the connection. The connection SHOULD NOT be established if the
certificate fingerprint stored in this entry does not point to certificate fingerprint stored in this entry does not point to
a valid locally held certificate or if it points to an a valid locally held certificate or if it points to an
unusable certificate (such as might happen when the unusable certificate (such as might happen when the
certificate's expiration date has been reached)." certificate's expiration date has been reached)."
INDEX { IMPLIED snmpTargetParamsName } INDEX { IMPLIED snmpTargetParamsName }
::= { snmpTlstmParamsTable 1 } ::= { snmpTlstmParamsTable 1 }
SnmpTlstmParamsEntry ::= SEQUENCE { SnmpTlstmParamsEntry ::= SEQUENCE {
snmpTlstmParamsClientFingerprint Fingerprint, snmpTlstmParamsClientFingerprint SnmpTLSFingerprint,
snmpTlstmParamsStorageType StorageType, snmpTlstmParamsStorageType StorageType,
snmpTlstmParamsRowStatus RowStatus snmpTlstmParamsRowStatus RowStatus
} }
snmpTlstmParamsClientFingerprint OBJECT-TYPE snmpTlstmParamsClientFingerprint OBJECT-TYPE
SYNTAX Fingerprint SYNTAX SnmpTLSFingerprint
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A cryptographic hash of a X.509 certificate. This object "This object stores the hash of the public portion of a
should store the hash of a locally held X.509 certificate that locally held X.509 certificate. The X.509 certificate, its
should be used (along with the corresponding private key) when public key, and the corresponding private key will be used
initiating a (D)TLS connection as a (D)TLS client." when initiating a (D)TLS connection as a (D)TLS client."
::= { snmpTlstmParamsEntry 1 } ::= { snmpTlstmParamsEntry 1 }
snmpTlstmParamsStorageType OBJECT-TYPE snmpTlstmParamsStorageType 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
having the value 'permanent' need not allow write-access to having the value 'permanent' need not allow write-access to
any columnar objects in the row." any columnar objects in the row."
skipping to change at page 45, line 49 skipping to change at page 46, line 34
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The status of this conceptual row. This object may be used "The status of this conceptual row. This object may be used
to create or remove rows from this table. to create or remove rows from this table.
To create a row in this table, an administrator must set this To create a row in this table, an administrator must set this
object to either createAndGo(4) or createAndWait(5). object to either createAndGo(4) or createAndWait(5).
Until instances of all corresponding columns are appropriately Until instances of all corresponding columns are appropriately
configured, the value of the corresponding instance of the configured, the value of the corresponding instance of the
snmpTlstmParamsRowStatus column is 'notReady'. snmpTlstmParamsRowStatus column is notReady(3).
In particular, a newly created row cannot be made active until In particular, a newly created row cannot be made active until
the corresponding snmpTlstmParamsClientFingerprint column has the corresponding snmpTlstmParamsClientFingerprint column has
been set. been set.
The snmpTlstmParamsClientFingerprint object may not be modified The snmpTlstmParamsClientFingerprint 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
snmpTlstmParamsRowStatus is active(1) will result in snmpTlstmParamsRowStatus is active(1) will result in
skipping to change at page 48, line 21 skipping to change at page 49, line 6
snmpTlstmAddrEntry exists for a given snmpTargetAddrEntry then snmpTlstmAddrEntry exists for a given snmpTargetAddrEntry then
the presented server certificate MUST match or the connection the presented server certificate MUST match or the connection
MUST NOT be established. If a row in this table does not MUST NOT be established. If a row in this table does not
exist to match a snmpTargetAddrEntry row then the connection exist to match a snmpTargetAddrEntry row then the connection
SHOULD still proceed if some other certificate validation path SHOULD still proceed if some other certificate validation path
algorithm (e.g. RFC5280) can be used." algorithm (e.g. RFC5280) can be used."
INDEX { IMPLIED snmpTargetAddrName } INDEX { IMPLIED snmpTargetAddrName }
::= { snmpTlstmAddrTable 1 } ::= { snmpTlstmAddrTable 1 }
SnmpTlstmAddrEntry ::= SEQUENCE { SnmpTlstmAddrEntry ::= SEQUENCE {
snmpTlstmAddrServerFingerprint Fingerprint, snmpTlstmAddrServerFingerprint SnmpTLSFingerprint,
snmpTlstmAddrServerIdentity SnmpAdminString, snmpTlstmAddrServerIdentity SnmpAdminString,
snmpTlstmAddrStorageType StorageType, snmpTlstmAddrStorageType StorageType,
snmpTlstmAddrRowStatus RowStatus snmpTlstmAddrRowStatus RowStatus
} }
snmpTlstmAddrServerFingerprint OBJECT-TYPE snmpTlstmAddrServerFingerprint OBJECT-TYPE
SYNTAX Fingerprint SYNTAX SnmpTLSFingerprint
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A cryptographic hash of a public X.509 certificate. This "A cryptographic hash of a public X.509 certificate. This
object should store the hash of the public X.509 certificate object should store the hash of the public X.509 certificate
that the remote server should present during the (D)TLS that the remote server should present during the (D)TLS
connection setup. The fingerprint of the presented connection setup. The fingerprint of the presented
certificate and this hash value MUST match exactly or the certificate and this hash value MUST match exactly or the
connection MUST NOT be established." connection MUST NOT be established."
DEFVAL { "" } DEFVAL { "" }
skipping to change at page 49, line 28 skipping to change at page 50, line 13
DESCRIPTION DESCRIPTION
"The status of this conceptual row. This object may be used "The status of this conceptual row. This object may be used
to create or remove rows from this table. to create or remove rows from this table.
To create a row in this table, an administrator must set this To create a row in this table, an administrator must set this
object to either createAndGo(4) or createAndWait(5). object to either createAndGo(4) or createAndWait(5).
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 snmpTlstmAddrRowStatus corresponding instance of the snmpTlstmAddrRowStatus
column is 'notReady'. column is notReady(3).
In particular, a newly created row cannot be made active until In particular, a newly created row cannot be made active until
the corresponding snmpTlstmAddrServerFingerprint column has been the corresponding snmpTlstmAddrServerFingerprint column has been
set. set.
Rows MUST NOT be active if the snmpTlstmAddrServerFingerprint Rows MUST NOT be active if the snmpTlstmAddrServerFingerprint
column is blank and the snmpTlstmAddrServerIdentity is set to column is blank and the snmpTlstmAddrServerIdentity is set to
'*' since this would insecurely accept any presented '*' since this would insecurely accept any presented
certificate. certificate.
skipping to change at page 50, line 28 skipping to change at page 51, line 13
::= { snmpTlstmNotifications 1 } ::= { snmpTlstmNotifications 1 }
snmpTlstmServerInvalidCertificate NOTIFICATION-TYPE snmpTlstmServerInvalidCertificate NOTIFICATION-TYPE
OBJECTS { snmpTlstmAddrServerFingerprint, OBJECTS { snmpTlstmAddrServerFingerprint,
snmpTlstmSessionInvalidServerCertificates} snmpTlstmSessionInvalidServerCertificates}
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Notification that the server certificate presented by an SNMP "Notification that the server certificate presented by an SNMP
over (D)TLS server could not be validated even if the over (D)TLS server could not be validated even if the
fingerprint or expected validation path was known. I.E., a fingerprint or expected validation path was known. I.E., a
cryptographic validation occurred during certificate cryptographic validation error occurred during certificate
validation processing. validation processing.
To avoid notification loops, this notification MUST NOT be To avoid notification loops, this notification MUST NOT be
sent to servers that themselves have triggered the sent to servers that themselves have triggered the
notification." notification."
::= { snmpTlstmNotifications 2 } ::= { snmpTlstmNotifications 2 }
-- ************************************************ -- ************************************************
-- snmpTlstmCompliances - Conformance Information -- snmpTlstmCompliances - Conformance Information
-- ************************************************ -- ************************************************
skipping to change at page 53, line 7 skipping to change at page 53, line 39
8.1. Sessions 8.1. Sessions
A session is discussed throughout this document as meaning a security A session is discussed throughout this document as meaning a security
association between two TLSTM instances. State information for the association between two TLSTM instances. State information for the
sessions are maintained in each TLSTM implementation and this sessions are maintained in each TLSTM implementation and this
information is created and destroyed as sessions are opened and information is created and destroyed as sessions are opened and
closed. A "broken" session (one side up and one side down) can closed. A "broken" session (one side up and one side down) can
result if one side of a session is brought down abruptly (i.e., result if one side of a session is brought down abruptly (i.e.,
reboot, power outage, etc.). Whenever possible, implementations reboot, power outage, etc.). Whenever possible, implementations
SHOULD provide graceful session termination through the use of SHOULD provide graceful session termination through the use of TLS
disconnect messages. Implementations SHOULD also have a system in disconnect messages. Implementations SHOULD also have a system in
place for detecting "broken" sessions through the use of heartbeats place for detecting "broken" sessions through the use of heartbeats
[I-D.seggelmann-tls-dtls-heartbeat] or other detection mechanisms. [I-D.seggelmann-tls-dtls-heartbeat] or other detection mechanisms.
Implementations SHOULD limit the lifetime of established sessions Implementations SHOULD limit the lifetime of established sessions
depending on the algorithms used for generation of the master session depending on the algorithms used for generation of the master session
secret, the privacy and integrity algorithms used to protect secret, the privacy and integrity algorithms used to protect
messages, the environment of the session, the amount of data messages, the environment of the session, the amount of data
transferred, and the sensitivity of the data. transferred, and the sensitivity of the data.
skipping to change at page 53, line 45 skipping to change at page 54, line 32
monitor multiple incoming static ports based on which principals are monitor multiple incoming static ports based on which principals are
capable of receiving notifications. capable of receiving notifications.
Implementations MAY also choose to designate a single Notification Implementations MAY also choose to designate a single Notification
Receiver Principal to receive all incoming notifications or select an Receiver Principal to receive all incoming notifications or select an
implementation specific method of selecting a server certificate to implementation specific method of selecting a server certificate to
present to clients. present to clients.
8.3. contextEngineID Discovery 8.3. contextEngineID Discovery
Most command responders have contextEngineIDs that are identical to SNMPv3 requires that an application know the identifier
the USM securityEngineID. USM provides a discovery service that (snmpEngineID) of the remote SNMP protocol engine in order to
allows command generators to determine a securityEngineID and thus a retrieve or manipulate objects maintained on the remote SNMP entity.
default contextEngineID to use. Because the TLS Transport Model does
not make use of a securityEngineID, it may be difficult for command [RFC5343] introduces a well-known localEngineID and a discovery
generators to discover a suitable default contextEngineID. mechanism that can be used to learn the snmpEngineID of a remote SNMP
Implementations should consider offering another engineID discovery protocol engine. Implementations are RECOMMENDED to support and use
mechanism to continue providing Command Generators with a suitable the contextEngineID discovery mechanism defined in [RFC5343].
contextEngineID mechanism. A recommended discovery solution is
documented in [RFC5343].
8.4. Transport Considerations 8.4. Transport Considerations
This document defines how SNMP messages can be transmitted over the This document defines how SNMP messages can be transmitted over the
TLS and DTLS based protocols. Each of these protocols are TLS and DTLS based protocols. Each of these protocols are
additionally based on other transports (TCP and UDP). These two base additionally based on other transports (TCP and UDP). These two base
protocols also have operational considerations that must be taken protocols also have operational considerations that must be taken
into consideration when selecting a (D)TLS based protocol to use such into consideration when selecting a (D)TLS based protocol to use such
as its performance in degraded or limited networks. It is beyond the as its performance in degraded or limited networks. It is beyond the
scope of this document to summarize the characteristics of these scope of this document to summarize the characteristics of these
transport mechanisms. Please refer to the base protocol documents transport mechanisms. Please refer to the base protocol documents
for details on messaging considerations with respect to MTU size, for details on messaging considerations with respect to MTU size,
fragmentation, performance in lossy-networks, etc. fragmentation, performance in lossy-networks, etc.
8.5. IPv6 and securityName mapping when used with TSM and VACM
It is possible to create a condition where it is impossible to map a
subjectAltName to a securityName when all of the following conditions
are true:
o The snmpTlstmCertToTSNMapType object of a snmpTlstmCertToTSNEntry
is set to the snmpTlstmCertSANIpAddress identity value.
o The X.509 certificate presented by the client contains a
subjectAltName with an IPv6 address in it.
o The security model in use is the Transport Security Model.
o The snmpTsmConfigurationUsePrefix object in the SNMP-TSM-MIB is
set to 'true'.
o The View-based Access Control Model is being used to authorize
requests.
If all of these conditions are true then the length of the generated
tmSecurityName will always be 32 octet characters and the
securityName generated by the TSM will be at least 36, which is
longer than the length allowed by the VACM.
Thus, the use of IPv6 subjectAltName to tmSecurityName mapping is NOT
RECOMMENDED when snmpTsmConfigurationUsePrefix is set to true.
9. Security Considerations 9. Security Considerations
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]. When run over a connectionless transport such as UDP, [RFC5246]. When run over a connectionless transport such as UDP,
DTLS is more vulnerable to denial of service attacks from spoofed IP DTLS is more vulnerable to denial of service attacks from spoofed IP
skipping to change at page 55, line 11 skipping to change at page 56, line 23
data. The authenticated identity of the command generator data. The authenticated identity of the command generator
principal's certificate is mapped to an SNMP model-independent principal's certificate is mapped to an SNMP model-independent
securityName for use with SNMP access control. securityName for use with SNMP access control.
The (D)TLS handshake only provides assurance that the certificate of The (D)TLS handshake only provides assurance that the certificate of
the authenticated identity has been signed by an configured accepted the authenticated identity has been signed by an configured accepted
certification authority. (D)TLS has no way to further authorize or certification authority. (D)TLS has no way to further authorize or
reject access based on the authenticated identity. An Access Control reject access based on the authenticated identity. An Access Control
Model (such as the VACM) provides access control and authorization of Model (such as the VACM) provides access control and authorization of
a command generator's requests to a command responder and a a command generator's requests to a command responder and a
notification responder's authorization to receive Notifications from notification receiver's authorization to receive Notifications from a
a notification originator. However to avoid man-in-the-middle notification originator. However to avoid man-in-the-middle attacks
attacks both ends of the (D)TLS based connection MUST check the both ends of the (D)TLS based connection MUST check the certificate
certificate presented by the other side against what was expected. presented by the other side against what was expected. For example,
For example, command generators must check that the command responder command generators must check that the command responder presented
presented and authenticated itself with a X.509 certificate that was and authenticated itself with a X.509 certificate that was expected.
expected. Not doing so would allow an impostor, at a minimum, to Not doing so would allow an impostor, at a minimum, to present false
present false data, receive sensitive information and/or provide a data, receive sensitive information and/or provide a false belief
false belief that configuration was actually received and acted upon. that configuration was actually received and acted upon.
Authenticating and verifying the identity of the (D)TLS server and Authenticating and verifying the identity of the (D)TLS server and
the (D)TLS client for all operations ensures the authenticity of the the (D)TLS client for all operations ensures the authenticity of the
SNMP engine that provides MIB data. SNMP engine that provides MIB data.
The instructions found in the DESCRIPTION clause of the The instructions found in the DESCRIPTION clause of the
snmpTlstmCertToTSNTable object must be followed exactly. It is also snmpTlstmCertToTSNTable object must be followed exactly. It is also
important that the rows of the table be searched in prioritized order important that the rows of the table be searched in prioritized order
starting with the row containing the lowest numbered starting with the row containing the lowest numbered
snmpTlstmCertToTSNID value. snmpTlstmCertToTSNID value.
9.2. Use with SNMPv1/SNMPv2c Messages 9.2. Use with SNMPv1/SNMPv2c Messages
The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP
74) always selects the SNMPv1 or SNMPv2c Security Models, 74) always selects the SNMPv1 or SNMPv2c Security Models,
respectively. Both of these and the User-based Security Model respectively. Both of these and the User-based Security Model
typically used with SNMPv3 derive the securityName and securityLevel typically used with SNMPv3 derive the securityName and securityLevel
from the SNMP message received, even when the message was received from the SNMP message received, even when the message was received
over a secure transport. Access control decisions are therefore made over a secure transport. Access control decisions are therefore made
based on the contents of the SNMP message, rather than using the based on the contents of the SNMP message, rather than using the
authenticated identity and securityLevel provided by the TLS authenticated identity and securityLevel provided by the TLS
Transport Model. Transport Model. It is RECOMMENDED that only SNMPv3 messages using
the Transport Security Model (TSM) or another secure-transport aware
security model be sent over the TLSTM transport.
Using a non-transport-aware Security Model with a secure Transport
Model is NOT RECOMMENDED. See [RFC5590] Section 7.1 for additional
details on the coexistence of security-aware transports and non-
transport-aware security models.
9.3. MIB Module Security 9.3. MIB Module Security
There are a number of management objects defined in this MIB module There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their network operations. These are the tables and objects and their
sensitivity/vulnerability: sensitivity/vulnerability:
skipping to change at page 56, line 32 skipping to change at page 57, line 49
recommended. recommended.
o The snmpTlstmCertToTSNTable is used to specify the mapping of o The snmpTlstmCertToTSNTable is used to specify the mapping of
incoming X.509 certificates to tmSecurityNames which eventually incoming X.509 certificates to tmSecurityNames which eventually
get mapped to a SNMPv3 securityName. Modification to objects in get mapped to a SNMPv3 securityName. Modification to objects in
this table need to be adequately authenticated since modification this table need to be adequately authenticated since modification
to values in this table will have profound impacts to the security to values in this table will have profound impacts to the security
of incoming connections to the device. Since knowledge of of incoming connections to the device. Since knowledge of
authorization rules and certificate usage mechanisms may be authorization rules and certificate usage mechanisms may be
considered sensitive, protection from disclosure of the SNMP considered sensitive, protection from disclosure of the SNMP
traffic via encryption is also highly recommended. traffic via encryption is also highly recommended. When this
table contains a significant number of rows it may affect the
system performance when accepting new (D)TLS connections.
Some of the readable objects in this MIB module (i.e., objects with a Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability: sensitivity/vulnerability:
o This MIB contains a collection of counters that monitor the (D)TLS o This MIB contains a collection of counters that monitor the (D)TLS
skipping to change at page 57, line 28 skipping to change at page 58, line 48
10. IANA Considerations 10. IANA Considerations
IANA is requested to assign: IANA is requested to assign:
1. Two TCP/UDP port numbers from the "Registered Ports" range of the 1. Two TCP/UDP port numbers from the "Registered Ports" range of the
Port Numbers registry, with the following keywords (where TBD1 Port Numbers registry, with the following keywords (where TBD1
and TBD2 correspond to the assigned port numbers): and TBD2 correspond to the assigned port numbers):
Keyword Decimal Description References Keyword Decimal Description References
------- ------- ----------- ---------- ------- ------- ----------- ----------
snmptls TBD1/tcp SNMPv3-TLS [RFC-isms-dtls-tm] snmptls TBD1/tcp SNMP-TLS [RFC-isms-dtls-tm]
snmpdtls TBD1/udp SNMPv3-DTLS [RFC-isms-dtls-tm] snmpdtls TBD1/udp SNMP-DTLS [RFC-isms-dtls-tm]
snmptls-trap TBD2/tcp SNMPv3-Trap-TLS [RFC-isms-dtls-tm] snmptls-trap TBD2/tcp SNMP-Trap-TLS [RFC-isms-dtls-tm]
snmpdtls-trap TBD2/udp SNMPv3-Trap-DTLS [RFC-isms-dtls-tm] snmpdtls-trap TBD2/udp SNMP-Trap-DTLS [RFC-isms-dtls-tm]
These are the default ports for receipt of SNMP command messages These are the default ports for receipt of SNMP command messages
(snmptls and snmpdtls) and SNMP notification messages (snmptls- (snmptls and snmpdtls) and SNMP notification messages (snmptls-
trap and snmpdtls-trap) over a TLS Transport Model as defined in trap and snmpdtls-trap) over a TLS Transport Model as defined in
this document. this document.
2. An SMI number under snmpDomains for the snmpTLSTCPDomain object 2. An SMI number under snmpDomains for the snmpTLSTCPDomain object
identifier, identifier,
3. An SMI number under snmpDomains for the snmpDTLSUDPDomain object 3. An SMI number under snmpDomains for the snmpDTLSUDPDomain object
identifier, identifier,
skipping to change at page 58, line 12 skipping to change at page 59, line 30
6. "dtls" as the corresponding prefix for the snmpDTLSUDPDomain in 6. "dtls" as the corresponding prefix for the snmpDTLSUDPDomain in
the SNMP Transport Model registry, the SNMP Transport Model registry,
RFC Editor's note: this section should be replaced with appropriate RFC Editor's note: this section should be replaced with appropriate
descriptive assignment text after IANA assignments are made and prior descriptive assignment text after IANA assignments are made and prior
to publication. to publication.
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 documented by David Harrington and Joseph Salowey in
[RFC5292]. [RFC5592].
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, Michael Peck, Tom David Harrington, Jeffrey Hutzelman, Alan Luchuk, Michael Peck, Tom
Petch, Randy Presuhn, Ray Purvis, Peter Saint-Andre, Joseph Salowey, Petch, Randy Presuhn, Ray Purvis, Peter Saint-Andre, Joseph Salowey,
Jurgen Schonwalder, Dave Shield, Robert Story. 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
skipping to change at page 58, line 29 skipping to change at page 60, line 4
Jurgen Schonwalder, Dave Shield, Robert Story. 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
12.1. Normative References 12.1. Normative References
[RFC1033] Lottor, M., "Domain administrators operations guide",
RFC 1033, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999. STD 58, RFC 2579, April 1999.
skipping to change at page 59, line 22 skipping to change at page 60, line 46
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, Management Protocol (SNMP)", STD 62, RFC 3415,
December 2002. December 2002.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the [RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, Simple Network Management Protocol (SNMP)", STD 62,
RFC 3418, December 2002. RFC 3418, December 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3 "Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework", of the Internet-standard Network Management Framework",
BCP 74, RFC 3584, August 2003. BCP 74, RFC 3584, August 2003.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem
for the Simple Network Management Protocol (SNMP)", for the Simple Network Management Protocol (SNMP)",
RFC 5590, June 2009. RFC 5590, June 2009.
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
for the Simple Network Management Protocol (SNMP)", for the Simple Network Management Protocol (SNMP)",
RFC 5591, June 2009. RFC 5591, June 2009.
[I-D.draft-ietf-6man-text-addr-representation]
Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation".
12.2. Informative References 12.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound
Route Filter for BGP-4", RFC 5292, August 2008.
[RFC5343] Schoenwaelder, J., "Simple Network Management Protocol [RFC5343] Schoenwaelder, J., "Simple Network Management Protocol
(SNMP) Context EngineID Discovery", RFC 5343, (SNMP) Context EngineID Discovery", RFC 5343,
September 2008. September 2008.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009.
[I-D.seggelmann-tls-dtls-heartbeat] [I-D.seggelmann-tls-dtls-heartbeat]
Seggelmann, R., Tuexen, M., and M. Williams, "Transport Seggelmann, R., Tuexen, M., and M. Williams, "Transport
Layer Security and Datagram Transport Layer Security Layer Security and Datagram Transport Layer Security
Heartbeat Extension". Heartbeat Extension".
Appendix A. Target and Notification Configuration Example Appendix A. Target and Notification Configuration Example
Configuring the SNMP-TARGET-MIB and NOTIFICATION-MIB along with The following sections describe example configuration for the SNMP-
access control settings for the SNMP-VIEW-BASED-ACM-MIB can be a TLS-TM-MIB, the SNMP-TARGET-MIB, the NOTIFICATION-MIB and the SNMP-
daunting task without an example to follow. The following section VIEW-BASED-ACM-MIB.
describes an example of what pieces must be in place to accomplish
this configuration.
The isAccessAllowed() ASI requires configuration to exist in the
following SNMP-VIEW-BASED-ACM-MIB tables:
vacmSecurityToGroupTable
vacmAccessTable
vacmViewTreeFamilyTable
The only table that needs to be discussed as particularly different
here is the vacmSecurityToGroupTable. This table is indexed by both
the SNMPv3 security model and the security name. The security model,
when TLSTM is in use, should be set to the value of 4, corresponding
to the TSM [RFC5591]. An example vacmSecurityToGroupTable row might
be filled out as follows (using a single SNMP SET request):
vacmSecurityModel = 4 (TSM)
vacmSecurityName = "blueberry"
vacmGroupName = "administrators"
vacmSecurityToGroupStorageType = 3 (nonVolatile)
vacmSecurityToGroupStatus = 4 (createAndGo)
This example will assume that the "administrators" group has been A.1. Configuring a Notification Originator
given proper permissions via rows in the vacmAccessTable and
vacmViewTreeFamilyTable.
Depending on whether this VACM configuration is for a Command The following row adds the "Joe Cool" user to the "administrators"
Responder or a command generator the security name "blueberry" will group:
come from a few different locations.
A.1. Configuring the Notification Originator vacmSecurityModel = 4 (TSM)
vacmSecurityName = "Joe Cool"
vacmGroupName = "administrators"
vacmSecurityToGroupStorageType = 3 (nonVolatile)
vacmSecurityToGroupStatus = 4 (createAndGo)
For notification originators performing authorization checks, the The following row configures the snmpTlstmAddrTable to use
server's certificate must be verified against the expected certificate path validation and to require the remote notification
certificate before proceeding to send the notification. The expected receiver to present a certificate for the "server.example.org"
certificate from the server may be listed in the snmpTlstmAddrTable identity.
or may be determined through other X.509 path validation mechanisms.
The securityName to use for VACM authorization checks is set by the
SNMP-TARGET-MIB's snmpTargetParamsSecurityName column.
The certificate that the notification originator should present to snmpTargetAddrName = "toNRAddr"
the server is taken from the snmpTlstmParamsClientFingerprint column snmpTlstmAddrServerFingerprint = ""
from the appropriate entry in the snmpTlstmParamsTable table. (Or snmpTlstmAddrServerIdentity = "server.example.org"
else a default certificate may be used if available.) snmpTlstmAddrStorageType = 3 (nonVolatile)
snmpTlstmAddrRowStatus = 4 (createAndGo)
To configure a notification originator to open a TLS over TCP The following row configures the snmpTargetAddrTable to send
connection to a notification receiver it must be configured so the notifications using TLS/TCP to the snmptls-trap port at 192.0.2.1:
server's presented certificate can be verified against the expected
certificate before proceeding to send the notification. This is done
by configuring the snmpTlstmAddrTable accordingly. For example, if
the verification is done via certification path validation (to a
trust anchor configured in implementation dependent manner), then the
table entries could look like:
snmpTargetAddrTable row: snmpTargetAddrName = "toNRAddr"
snmpTargetAddrName = "toNRAddr" snmpTargetAddrTDomain = snmpTLSTCPDomain
snmpTargetAddrTDomain = snmpTLSTCPDomain snmpTargetAddrTAddress = "192.0.2.1:XXXsnmptls-trap"
snmpTargetAddrTAddress = "192.0.2.1:XXXTLSTCPTRAPPORT" snmpTargetAddrTimeout = 1500
snmpTargetAddrTimeout = 1500 snmpTargetAddrRetryCount = 3
snmpTargetAddrRetryCount = 3 snmpTargetAddrTagList = "toNRTag"
snmpTargetAddrTagList = "toNRTag" snmpTargetAddrParams = "toNR" (MUST match above)
snmpTargetAddrParams = "toNR" (MUST match below) snmpTargetAddrStorageType = 3 (nonVolatile)
snmpTargetAddrStorageType = 3 (nonVolatile) snmpTargetAddrColumnStatus = 4 (createAndGo)
snmpTargetAddrColumnStatus = 4 (createAndGo)
snmpTargetParamsTable row: RFC Editor's note: replace the string "XXXsnmptls-trap" above with
snmpTargetParamsName = toNR the appropriately assigned "snmptls-trap" port.
snmpTargetParamsMPModel = SNMPv3
snmpTargetParamsSecurityModel = 4 (TransportSecurityModel)
snmpTargetParamsSecurityName = "blueberry"
snmpTargetParamsSecurityLevel = 3 (authPriv)
snmpTargetParamsStorageType = 3 (nonVolatile)
snmpTargetParamsRowStatus = 4 (createAndGo0
snmpTlstmAddrTable row: The following row configures the snmpTargetParamsTable to send the
snmpTargetAddrName = "toNRAddr" notifications to "Joe Cool", using authPriv SNMPv3 notifications
snmpTlstmAddrServerFingerprint = "" through the TransportSecurityModel [RFC5591]:
snmpTlstmAddrServerIdentity = "server.example.org"
snmpTlstmAddrStorageType = 3 (nonVolatile)
snmpTlstmAddrRowStatus = 4 (createAndGo)
Editor's note: replace the string "XXXTLSTCPTRAPPORT" above with the snmpTargetParamsName = toNR
appropriately assigned "snmptls-trap" port. snmpTargetParamsMPModel = SNMPv3
snmpTargetParamsSecurityModel = 4 (TransportSecurityModel)
snmpTargetParamsSecurityName = "Joe Cool"
snmpTargetParamsSecurityLevel = 3 (authPriv)
snmpTargetParamsStorageType = 3 (nonVolatile)
snmpTargetParamsRowStatus = 4 (createAndGo0
A.2. Configuring the Command Responder A.2. Configuring TLSTM to Utilize a Simple Derivation of tmSecurityName
For command responder applications, the vacmSecurityName "blueberry" The following row configures the snmpTlstmCertToTSNTable to map a
value is a value that derived from an incoming (D)TLS connection. validated client certificate, referenced by the client's public X.509
The mapping from a recevied (D)TLS client certificate to a hash fingerprint, to a tmSecurityName using the subjecwAltName
tmSecurityName is done with the snmpTlstmCertToTSNTable. The component of the certificate.
certificates must be loaded into the device so that a
snmpTlstmCertToTSNEntry may refer to it. As an example, consider the
following entry which will provide a mapping from a client's public
X.509's hash fingerprint directly to the "blueberry" tmSecurityName:
snmpTlstmCertToTSNID = 1 (chosen by ordering preference) snmpTlstmCertToTSNID = 1
snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint) (chosen by ordering preference)
snmpTlstmCertToTSNMapType = snmpTlstmCertSpecified snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint)
snmpTlstmCertToTSNSecurityName = "blueberry" snmpTlstmCertToTSNMapType = snmpTlstmCertSANAny
snmpTlstmCertToTSNStorageType = 3 (nonVolatile) snmpTlstmCertToTSNData = "" (not used)
snmpTlstmCertToTSNRowStatus = 4 (createAndGo) snmpTlstmCertToTSNStorageType = 3 (nonVolatile)
snmpTlstmCertToTSNRowStatus = 4 (createAndGo)
The above is an example of how to map a particular certificate to a This type of configuration should only be used when the naming
particular tmSecurityName. It is recommended, however, that users conventions of the (possibly multiple) certificate authorities are
make use of direct subjectAltName or CommonName mappings where well understood, so two different principals cannot inadvertently be
possible as it provides a more scalable approach to certificate identified by the same derived tmSecurityName..
management. This entry provides an example of using a subjectAltName
mapping:
snmpTlstmCertToTSNID = 1 (chosen by ordering preference) A.3. Configuring TLSTM to Utilize Table-Driven Certificate Mapping
snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint)
snmpTlstmCertToTSNMapType = snmpTlstmCertSANAny
snmpTlstmCertToTSNData = "" (not used)
snmpTlstmCertToTSNStorageType = 3 (nonVolatile)
snmpTlstmCertToTSNRowStatus = 4 (createAndGo)
The above entry indicates the subjectAltName field for certificates The following row configures the snmpTlstmCertToTSNTable to map a
created by an issuing certificate with a corresponding fingerprint validated client certificate, referenced by the client's public X.509
will be trusted to always produce common names that are directly one- hash fingerprint, to the directly specified tmSecurityName of "Joe
to-one mappable into tmSecurityNames. This type of configuration Cool".
should only be used when the certificate authorities naming
conventions are carefully controlled.
In the example, if the incoming (D)TLS client provided certificate snmpTlstmCertToTSNID = 1
contained a subjectAltName where the first listed subjectAltName in (chosen by ordering preference)
the extension is the rfc822Name of "blueberry@example.com", the snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint)
certificate was signed by a certificate matching the snmpTlstmCertToTSNMapType = snmpTlstmCertSpecified
snmpTlstmCertToTSNFingerprint value and the CA's certificate was snmpTlstmCertToTSNSecurityName = "Joe Cool"
properly installed on the device then the string snmpTlstmCertToTSNStorageType = 3 (nonVolatile)
"blueberry@example.com" would be used as the tmSecurityName for the snmpTlstmCertToTSNRowStatus = 4 (createAndGo)
session.
Author's Address Author's Address
Wes Hardaker Wes Hardaker
Sparta, Inc. Sparta, Inc.
P.O. Box 382 P.O. Box 382
Davis, CA 95617 Davis, CA 95617
USA USA
Phone: +1 530 792 1913 Phone: +1 530 792 1913
 End of changes. 97 change blocks. 
275 lines changed or deleted 297 lines changed or added

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