From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6353.txt | 3643 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3643 insertions(+) create mode 100644 doc/rfc/rfc6353.txt (limited to 'doc/rfc/rfc6353.txt') diff --git a/doc/rfc/rfc6353.txt b/doc/rfc/rfc6353.txt new file mode 100644 index 0000000..4696ea6 --- /dev/null +++ b/doc/rfc/rfc6353.txt @@ -0,0 +1,3643 @@ + + + + + + +Internet Engineering Task Force (IETF) W. Hardaker +Request for Comments: 6353 SPARTA, Inc. +Obsoletes: 5953 July 2011 +Category: Standards Track +ISSN: 2070-1721 + + + Transport Layer Security (TLS) Transport Model for + the Simple Network Management Protocol (SNMP) + +Abstract + + This document describes a Transport Model for the Simple Network + Management Protocol (SNMP), that uses either the Transport Layer + Security protocol or the Datagram Transport Layer Security (DTLS) + protocol. The TLS and DTLS protocols provide authentication and + privacy services for SNMP applications. This document describes how + the TLS Transport Model (TLSTM) implements the needed features of an + SNMP Transport Subsystem to make this protection possible in an + interoperable way. + + This Transport Model is designed to meet the security and operational + needs of network administrators. It supports the sending of SNMP + messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of + TCP's improved support for larger packet sizes and the DTLS mode + provides potentially superior operation in environments where a + connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS + integrate well into existing public keying infrastructures. + + This document also defines a portion of the Management Information + Base (MIB) for use with network management protocols. In particular, + it defines objects for managing the TLS Transport Model for SNMP. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6353. + + + + + +Hardaker Standards Track [Page 1] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 + 1.2. Changes Since RFC 5953 . . . . . . . . . . . . . . . . . . 8 + 2. The Transport Layer Security Protocol . . . . . . . . . . . . 8 + 3. How the TLSTM Fits into the Transport Subsystem . . . . . . . 8 + 3.1. Security Capabilities of This Model . . . . . . . . . . . 11 + 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 12 + 3.1.3. (D)TLS Connections . . . . . . . . . . . . . . . . . . 13 + 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 14 + 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14 + 4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 15 + 4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 15 + 4.1.1. Provisioning for the Certificate . . . . . . . . . . . 15 + 4.2. (D)TLS Usage . . . . . . . . . . . . . . . . . . . . . . . 17 + 4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 18 + 4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 18 + 4.3.2. SNMP Services for an Incoming Message . . . . . . . . 19 + + + + +Hardaker Standards Track [Page 2] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + 4.4. Cached Information and References . . . . . . . . . . . . 20 + 4.4.1. TLS Transport Model Cached Information . . . . . . . . 20 + 4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 20 + 4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 21 + 4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 21 + 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 21 + 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 21 + 5.1.1. DTLS over UDP Processing for Incoming Messages . . . . 22 + 5.1.2. Transport Processing for Incoming SNMP Messages . . . 23 + 5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 25 + 5.3. Establishing or Accepting a Session . . . . . . . . . . . 26 + 5.3.1. Establishing a Session as a Client . . . . . . . . . . 26 + 5.3.2. Accepting a Session as a Server . . . . . . . . . . . 28 + 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 29 + 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 30 + 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 30 + 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 30 + 6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 30 + 6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 30 + 6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 31 + 6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 31 + 6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 31 + 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 31 + 8. Operational Considerations . . . . . . . . . . . . . . . . . . 54 + 8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 54 + 8.2. Notification Receiver Credential Selection . . . . . . . . 54 + 8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 55 + 8.4. Transport Considerations . . . . . . . . . . . . . . . . . 55 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 55 + 9.1. Certificates, Authentication, and Authorization . . . . . 55 + 9.2. (D)TLS Security Considerations . . . . . . . . . . . . . . 56 + 9.2.1. TLS Version Requirements . . . . . . . . . . . . . . . 56 + 9.2.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 57 + 9.3. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 57 + 9.4. MIB Module Security . . . . . . . . . . . . . . . . . . . 57 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 60 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 61 + Appendix A. Target and Notification Configuration Example . . . . 63 + A.1. Configuring a Notification Originator . . . . . . . . . . 63 + A.2. Configuring TLSTM to Utilize a Simple Derivation of + tmSecurityName . . . . . . . . . . . . . . . . . . . . . . 64 + A.3. Configuring TLSTM to Utilize Table-Driven Certificate + Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 64 + + + + + +Hardaker Standards Track [Page 3] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +1. Introduction + + It is important to understand the modular SNMPv3 architecture as + defined by [RFC3411] and enhanced by the Transport Subsystem + [RFC5590]. It is also important to understand the terminology of the + SNMPv3 architecture in order to understand where the Transport Model + described in this document fits into the architecture and how it + interacts with the other architecture subsystems. For a detailed + overview of the documents that describe the current Internet-Standard + Management Framework, please refer to Section 7 of [RFC3410]. + + This document describes a Transport Model that makes use of the + Transport Layer Security (TLS) [RFC5246] and the Datagram Transport + Layer Security (DTLS) Protocol [RFC4347], within a Transport + Subsystem [RFC5590]. DTLS is the datagram variant of the Transport + Layer Security (TLS) protocol [RFC5246]. The Transport Model in this + document is referred to as the Transport Layer Security Transport + Model (TLSTM). TLS and DTLS take advantage of the X.509 public + keying infrastructure [RFC5280]. While (D)TLS supports multiple + authentication mechanisms, this document only discusses X.509 + certificate-based authentication. Although other forms of + authentication are possible, they are outside the scope of this + specification. This transport model is designed to meet the security + and operational needs of network administrators, operating in both + environments where a connectionless (e.g., UDP) transport is + preferred and in environments where large quantities of data need to + be sent (e.g., over a TCP-based stream). Both TLS and DTLS integrate + well into existing public keying infrastructures. This document + supports sending of SNMP messages over TLS/TCP and DTLS/UDP. + + This document also defines a portion of the Management Information + Base (MIB) for use with network management protocols. In particular, + it defines objects for managing the TLS Transport Model for SNMP. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58: + [RFC2578], [RFC2579], and [RFC2580]. + + + + + + + + + + +Hardaker Standards Track [Page 4] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The diagram shown below gives a conceptual overview of two SNMP + entities communicating using the TLS Transport Model (shown as + "TLSTM"). One entity contains a command responder and notification + originator application, and the other a command generator and + notification receiver application. It should be understood that this + particular mix of application types is an example only and other + combinations are equally valid. + + Note: this diagram shows the Transport Security Model (TSM) being + used as the security model that is defined in [RFC5591]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hardaker Standards Track [Page 5] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + +---------------------------------------------------------------------+ + | Network | + +---------------------------------------------------------------------+ + ^ | ^ | + |Notifications |Commands |Commands |Notifications + +---|---------------------|-------+ +--|---------------|--------------+ + | | V | | | V | + | +------------+ +------------+ | | +-----------+ +----------+ | + | | (D)TLS | | (D)TLS | | | | (D)TLS | | (D)TLS | | + | | (Client) | | (Server) | | | | (Client) | | (Server) | | + | +------------+ +------------+ | | +-----------+ +----------+ | + | ^ ^ | | ^ ^ | + | | | | | | | | + | +-------------+ | | +--------------+ | + | +-----|------------+ | | +-----|------------+ | + | | V | | | | V | | + | | +--------+ | +-----+ | | | +--------+ | +-----+ | + | | | TLS TM |<--------->|Cache| | | | | TLS TM |<--------->|Cache| | + | | +--------+ | +-----+ | | | +--------+ | +-----+ | + | |Transport Subsys. | ^ | | |Transport Subsys. | ^ | + | +------------------+ | | | +------------------+ | | + | ^ | | | ^ | | + | | +--+ | | | +--+ | + | v | | | V | | + | +-----+ +--------+ +-------+ | | | +-----+ +--------+ +-------+ | | + | | | |Message | |Securi.| | | | | | |Message | |Securi.| | | + | |Disp.| |Proc. | |Subsys.| | | | |Disp.| |Proc. | |Subsys.| | | + | | | |Subsys. | | | | | | | | |Subsys. | | | | | + | | | | | | | | | | | | | | | | | | + | | | | +----+ | | +---+ | | | | | | | +----+ | | +---+ | | | + | | <--->|v3MP|<--> |TSM|<--+ | | | <--->|v3MP|<--->|TSM|<--+ | + | | | | +----+ | | +---+ | | | | | | +----+ | | +---+ | | + | | | | | | | | | | | | | | | | + | +-----+ +--------+ +-------+ | | +-----+ +--------+ +-------+ | + | ^ | | ^ | + | | | | | | + | +-+------------+ | | +-+----------+ | + | | | | | | | | + | v v | | v V | + | +-------------+ +-------------+ | | +-------------+ +-------------+ | + | | COMMAND | | NOTIFICAT. | | | | COMMAND | | NOTIFICAT. | | + | | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RECEIVER | | + | | application | | application | | | | application | | application | | + | +-------------+ +-------------+ | | +-------------+ +-------------+ | + | SNMP entity | | SNMP entity | + +---------------------------------+ +---------------------------------+ + + + + + +Hardaker Standards Track [Page 6] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +1.1. Conventions + + For consistency with SNMP-related specifications, this document + favors terminology as defined in STD 62, rather than favoring + terminology that is consistent with non-SNMP specifications. This is + consistent with the IESG decision to not require the SNMPv3 + terminology be modified to match the usage of other non-SNMP + specifications when SNMPv3 was advanced to a Full Standard. + + "Authentication" in this document typically refers to the English + meaning of "serving to prove the authenticity of" the message, not + data source authentication or peer identity authentication. + + The terms "manager" and "agent" are not used in this document + because, in the [RFC3411] architecture, all SNMP entities have the + capability of acting as manager, agent, or both depending on the SNMP + application types supported in the implementation. Where distinction + is required, the application names of command generator, command + responder, notification originator, notification receiver, and proxy + forwarder are used. See "SNMP Applications" [RFC3413] for further + information. + + Large portions of this document simultaneously refer to both TLS and + DTLS when discussing TLSTM components that function equally with + either protocol. "(D)TLS" is used in these places to indicate that + the statement applies to either or both protocols as appropriate. + When a distinction between the protocols is needed, they are referred + to independently through the use of "TLS" or "DTLS". The Transport + Model, however, is named "TLS Transport Model" and refers not to the + TLS or DTLS protocol but to the specification in this document, which + includes support for both TLS and DTLS. + + Throughout this document, the terms "client" and "server" are used to + refer to the two ends of the (D)TLS transport connection. The client + actively opens the (D)TLS connection, and the server passively + 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 + applications supported. + + The User-Based Security Model (USM) [RFC3414] is a mandatory-to- + implement Security Model in STD 62. While (D)TLS and USM frequently + refer to a user, the terminology preferred in RFC 3411 and in this + memo is "principal". A principal is the "who" on whose behalf + services are provided or processing takes place. A principal can be, + among other things, an individual acting in a particular role; a set + of individuals, with each acting in a particular role; an application + or a set of applications, or a combination of these within an + administrative domain. + + + +Hardaker Standards Track [Page 7] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + Throughout this document, the term "session" is used to refer to a + secure association between two TLS Transport Models that permits the + transmission of one or more SNMP messages within the lifetime of the + session. The (D)TLS protocols also have an internal notion of a + session and although these two concepts of a session are related, + when the term "session" is used this document is referring to the + TLSTM's specific session and not directly to the (D)TLS protocol's + session. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.2. Changes Since RFC 5953 + + This document obsoletes [RFC5953]. + + Since the publication of RFC 5953, a few editorial errata have been + noted. These errata are posted on the RFC Editor web site. These + errors have been corrected in this document. + + This document updates the references to RFC 3490 (IDNA 2003) to + [RFC5890] (IDNA 2008), because RFC 3490 was obsoleted by RFC 5890. + + References to RFC 1033 were replaced with references to [RFC1123]. + + Added informative reference to 5953. + + Updated MIB dates and revision date. + +2. The Transport Layer Security Protocol + + (D)TLS provides authentication, data message integrity, and privacy + at the transport layer (see [RFC4347]). + + The primary goals of the TLS Transport Model are to provide privacy, + peer identity authentication, and data integrity between two + communicating SNMP entities. The TLS and DTLS protocols provide a + secure transport upon which the TLSTM is based. Please refer to + [RFC5246] and [RFC4347] for complete descriptions of the protocols. + +3. How the TLSTM Fits into the Transport Subsystem + + A transport model is a component of the Transport Subsystem. The TLS + Transport Model thus fits between the underlying (D)TLS transport + layer and the Message Dispatcher [RFC3411] component of the SNMP + engine. + + + + +Hardaker Standards Track [Page 8] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The TLS Transport Model will establish a session between itself and + the TLS Transport Model of another SNMP engine. The sending + transport model passes unencrypted and unauthenticated messages from + the Dispatcher to (D)TLS to be encrypted and authenticated, and the + receiving transport model accepts decrypted and authenticated/ + integrity-checked incoming messages from (D)TLS and passes them to + the Dispatcher. + + After a TLS Transport Model session is established, SNMP messages can + conceptually be sent through the session from one SNMP message + Dispatcher to another SNMP Message Dispatcher. If multiple SNMP + messages are needed to be passed between two SNMP applications they + MAY be passed through the same session. A TLSTM implementation + engine MAY choose to close the session to conserve resources. + + The TLS Transport Model of an SNMP engine will perform the + translation between (D)TLS-specific security parameters and SNMP- + specific, model-independent parameters. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hardaker Standards Track [Page 9] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The diagram below depicts where the TLS Transport Model (shown as + "(D)TLS TM") fits into the architecture described in RFC 3411 and the + Transport Subsystem: + + +------------------------------+ + | Network | + +------------------------------+ + ^ ^ ^ + | | | + v v v + +-------------------------------------------------------------------+ + | +--------------------------------------------------+ | + | | Transport Subsystem | +--------+ | + | | +-----+ +-----+ +-------+ +-------+ | | | | + | | | UDP | | SSH | |(D)TLS | . . . | other |<--->| Cache | | + | | | | | TM | | TM | | | | | | | + | | +-----+ +-----+ +-------+ +-------+ | +--------+ | + | +--------------------------------------------------+ ^ | + | ^ | | + | | | | + | Dispatcher v | | + | +--------------+ +---------------------+ +----------------+ | | + | | Transport | | Message Processing | | Security | | | + | | Dispatch | | Subsystem | | Subsystem | | | + | | | | +------------+ | | +------------+ | | | + | | | | +->| v1MP |<--->| | USM | | | | + | | | | | +------------+ | | +------------+ | | | + | | | | | +------------+ | | +------------+ | | | + | | | | +->| v2cMP |<--->| | Transport | | | | + | | Message | | | +------------+ | | | Security |<--+ | + | | Dispatch <---->| +------------+ | | | Model | | | + | | | | +->| v3MP |<--->| +------------+ | | + | | | | | +------------+ | | +------------+ | | + | | PDU Dispatch | | | +------------+ | | | Other | | | + | +--------------+ | +->| otherMP |<--->| | Model(s) | | | + | ^ | +------------+ | | +------------+ | | + | | +---------------------+ +----------------+ | + | v | + | +-------+-------------------------+---------------+ | + | ^ ^ ^ | + | | | | | + | v v v | + + + + + + + + + +Hardaker Standards Track [Page 10] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + | +-------------+ +---------+ +--------------+ +-------------+ | + | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | + | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | + | | application | | | | applications | | application | | + | +-------------+ +---------+ +--------------+ +-------------+ | + | ^ ^ | + | | | | + | v v | + | +----------------------------------------------+ | + | | MIB instrumentation | SNMP entity | + +-------------------------------------------------------------------+ + +3.1. Security Capabilities of This Model + +3.1.1. Threats + + The TLS Transport Model provides protection against the threats + identified by the RFC 3411 architecture [RFC3411]: + + 1. Modification of Information - The modification threat is the + danger that an unauthorized entity may alter in-transit SNMP + messages generated on behalf of an authorized principal in such a + way as to effect unauthorized management operations, including + falsifying the value of an object. + + (D)TLS provides verification that the content of each received + message has not been modified during its transmission through the + network, data has not been altered or destroyed in an + unauthorized manner, and data sequences have not been altered to + an extent greater than can occur non-maliciously. + + 2. Masquerade - The masquerade threat is the danger that management + operations unauthorized for a given principal may be attempted by + assuming the identity of another principal that has the + appropriate authorizations. + + The TLSTM verifies the identity of the (D)TLS server through the + use of the (D)TLS protocol and X.509 certificates. A TLS + Transport Model implementation MUST support the authentication of + both the server and the client. + + 3. Message stream modification - The re-ordering, delay, or replay + of messages can and does occur through the natural operation of + many connectionless transport services. The message stream + modification threat is the danger that messages may be + maliciously re-ordered, delayed, or replayed to an extent that is + greater than can occur through the natural operation of + + + + +Hardaker Standards Track [Page 11] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + connectionless transport services, in order to effect + unauthorized management operations. + + (D)TLS provides replay protection with a Message Authentication + Code (MAC) that includes a sequence number. Since UDP provides + no sequencing ability, DTLS uses a sliding window protocol with + the sequence number used for replay protection (see [RFC4347]). + + 4. Disclosure - The disclosure threat is the danger of eavesdropping + on the exchanges between SNMP engines. + + (D)TLS provides protection against the disclosure of information + to unauthorized recipients or eavesdroppers by allowing for + encryption of all traffic between SNMP engines. A TLS Transport + Model implementation MUST support message encryption to protect + sensitive data from eavesdropping attacks. + + 5. Denial of Service - The RFC 3411 architecture [RFC3411] states + that denial-of-service (DoS) attacks need not be addressed by an + SNMP security protocol. However, connectionless transports (like + DTLS over UDP) are susceptible to a variety of DoS attacks + because they are more vulnerable to spoofed IP addresses. See + Section 4.2 for details on how the cookie mechanism is used. + Note, however, that this mechanism does not provide any defense + against DoS attacks mounted from valid IP addresses. + + See Section 9 for more detail on the security considerations + associated with the TLSTM and these security threats. + +3.1.2. Message Protection + + The RFC 3411 architecture recognizes three levels of security: + + o without authentication and without privacy (noAuthNoPriv) + + o with authentication but without privacy (authNoPriv) + + o with authentication and with privacy (authPriv) + + The TLS Transport Model determines from (D)TLS the identity of the + authenticated principal, the transport type, and the transport + address associated with an incoming message. The TLS Transport Model + provides the identity and destination type and address to (D)TLS for + outgoing messages. + + When an application requests a session for a message, it also + requests a security level for that session. The TLS Transport Model + MUST ensure that the (D)TLS connection provides security at least as + + + +Hardaker Standards Track [Page 12] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + high as the requested level of security. How the security level is + translated into the algorithms used to provide data integrity and + privacy is implementation dependent. However, the NULL integrity and + encryption algorithms MUST NOT be used to fulfill security level + requests for authentication or privacy. Implementations MAY choose + to force (D)TLS to only allow cipher_suites that provide both + authentication and privacy to guarantee this assertion. + + If a suitable interface between the TLS Transport Model and the + (D)TLS Handshake Protocol is implemented to allow the selection of + security-level-dependent algorithms (for example, a security level to + cipher_suites mapping table), then different security levels may be + utilized by the application. + + The authentication, integrity, and privacy algorithms used by the + (D)TLS Protocols may vary over time as the science of cryptography + continues to evolve and the development of (D)TLS continues over + time. Implementers are encouraged to plan for changes in operator + trust of particular algorithms. Implementations SHOULD offer + configuration settings for mapping algorithms to SNMPv3 security + levels. + +3.1.3. (D)TLS Connections + + (D)TLS connections are opened by the TLS Transport Model during the + elements of procedure for an outgoing SNMP message. Since the sender + of a message initiates the creation of a (D)TLS connection if needed, + the (D)TLS connection will already exist for an incoming message. + + Implementations MAY choose to instantiate (D)TLS connections in + anticipation of outgoing messages. This approach might be useful to + ensure that a (D)TLS connection to a given target can be established + before it becomes important to send a message over the (D)TLS + connection. Of course, there is no guarantee that a pre-established + session will still be valid when needed. + + DTLS connections, when used over UDP, are uniquely identified within + the TLS Transport Model by the combination of transportDomain, + transportAddress, tmSecurityName, and requestedSecurityLevel + associated with each session. Each unique combination of these + parameters MUST have a locally chosen unique tlstmSessionID for each + active session. For further information, see Section 5. TLS over + TCP sessions, on the other hand, do not require a unique pairing of + address and port attributes since their lower-layer protocols (TCP) + already provide adequate session framing. But they must still + provide a unique tlstmSessionID for referencing the session. + + + + + +Hardaker Standards Track [Page 13] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The tlstmSessionID MUST NOT change during the entire duration of the + session from the TLSTM's perspective, and MUST uniquely identify a + single session. As an implementation hint: note 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 TLSTM (for + example, during renegotiation), and does not necessarily uniquely + identify a TLSTM session (there can be multiple TLSTM sessions + sharing the same D(TLS) internal SessionID). + +3.2. Security Parameter Passing + + For the (D)TLS server-side, (D)TLS-specific security parameters + (i.e., cipher_suites, X.509 certificate fields, IP addresses, and + ports) are translated by the TLS Transport Model into security + parameters for the TLS Transport Model and security model (e.g., + tmSecurityLevel, tmSecurityName, transportDomain, transportAddress). + The transport-related and (D)TLS-security-related information, + including the authenticated identity, are stored in a cache + referenced by tmStateReference. + + For the (D)TLS client side, the TLS Transport Model takes input + provided by the Dispatcher in the sendMessage() Abstract Service + Interface (ASI) and input from the tmStateReference cache. The + (D)TLS Transport Model converts that information into suitable + security parameters for (D)TLS and establishes sessions as needed. + + The elements of procedure in Section 5 discuss these concepts in much + greater detail. + +3.3. Notifications and Proxy + + (D)TLS connections may be initiated by (D)TLS clients on behalf of + SNMP applications that initiate communications, such as command + generators, notification originators, proxy forwarders. Command + generators are frequently operated by a human, but notification + originators and proxy forwarders are usually unmanned automated + processes. The targets to whom notifications and proxied requests + should be sent are typically determined and configured by a network + administrator. + + The SNMP-TARGET-MIB module [RFC3413] contains objects for defining + management targets, including transportDomain, transportAddress, + securityName, securityModel, and securityLevel parameters, for + notification originator, proxy forwarder, and SNMP-controllable + command generator applications. Transport domains and transport + addresses are configured in the snmpTargetAddrTable, and the + securityModel, securityName, and securityLevel parameters are + configured in the snmpTargetParamsTable. This document defines a MIB + + + +Hardaker Standards Track [Page 14] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to + specify a (D)TLS client-side certificate to use for the connection. + + When configuring a (D)TLS target, the snmpTargetAddrTDomain and + snmpTargetAddrTAddress parameters in snmpTargetAddrTable SHOULD be + set to the snmpTLSTCPDomain or snmpDTLSUDPDomain object and an + appropriate snmpTLSAddress value. When used with the SNMPv3 message + processing model, the snmpTargetParamsMPModel column of the + snmpTargetParamsTable SHOULD be set to a value of 3. The + snmpTargetParamsSecurityName SHOULD be set to an appropriate + securityName value, and the snmpTlstmParamsClientFingerprint + parameter of the snmpTlstmParamsTable SHOULD be set to a value that + refers to a locally held certificate (and the corresponding private + key) to be used. Other parameters, for example, cryptographic + configuration such as which cipher_suites to use, must come from + configuration mechanisms not defined in this document. + + The securityName defined in the snmpTargetParamsSecurityName column + will be used by the access control model to authorize any + notifications that need to be sent. + +4. Elements of the Model + + This section contains definitions required to realize the (D)TLS + Transport Model defined by this document. + +4.1. X.509 Certificates + + (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 + certificates in the TLSTM. + + While (D)TLS supports multiple authentication mechanisms, this + document only discusses X.509-certificate-based authentication; other + forms of authentication are outside the scope of this specification. + TLSTM implementations are REQUIRED to support X.509 certificates. + +4.1.1. Provisioning for the Certificate + + Authentication using (D)TLS will require that SNMP entities have + certificates, either signed by trusted Certification Authorities + (CAs), or self signed. Furthermore, SNMP entities will most commonly + need to be provisioned with root certificates that represent the list + of trusted CAs that an SNMP entity can use for certificate + verification. SNMP entities SHOULD also be provisioned with an X.509 + certificate revocation mechanism which can be used to verify that a + certificate has not been revoked. Trusted public keys from either CA + certificates and/or self-signed certificates MUST be installed into + + + +Hardaker Standards Track [Page 15] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + the server through a trusted out-of-band mechanism and their + authenticity MUST be verified before access is granted. + + Having received a certificate from a connecting TLSTM client, the + authenticated tmSecurityName of the principal is derived using the + snmpTlstmCertToTSNTable. This table allows mapping of incoming + connections to tmSecurityNames through defined transformations. The + transformations defined in the SNMP-TLS-TM-MIB include: + + o Mapping a certificate's subjectAltName or CommonName components to + a tmSecurityName, or + + o Mapping a certificate's fingerprint value to a directly specified + tmSecurityName + + As an implementation hint: implementations may choose to discard any + connections for which no potential snmpTlstmCertToTSNTable mapping + exists before performing certificate verification to avoid expending + computational resources associated with certificate verification. + + Deployments SHOULD map the "subjectAltName" component of X.509 + certificates to the TLSTM specific tmSecurityNames. The + authenticated identity can be obtained by the TLS Transport Model by + extracting the subjectAltName(s) from the peer's certificate. The + receiving application will then have an appropriate tmSecurityName + for use by other SNMPv3 components like an access control model. + + An example of this type of mapping setup can be found in Appendix A. + + This tmSecurityName may be later translated from a TLSTM specific + tmSecurityName to an SNMP engine securityName by the security model. + A security model, like the TSM security model [RFC5591], may perform + an identity mapping or a more complex mapping to derive the + securityName from the tmSecurityName offered by the TLS Transport + Model. + + The standard View-Based Access Control Model (VACM) access control + model constrains securityNames to be 32 octets or less in length. A + TLSTM generated tmSecurityName, possibly in combination with a + messaging or security model that increases the length of the + securityName, might cause the securityName length to exceed 32 + octets. For example, a 32-octet tmSecurityName derived from an IPv6 + address, paired with a TSM prefix, will generate a 36-octet + securityName. Such a securityName will not be able to be used with + standard VACM or TARGET MIB modules. Operators should be careful to + select algorithms and subjectAltNames to avoid this situation. + + + + + +Hardaker Standards Track [Page 16] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + A pictorial view of the complete transformation process (using the + TSM security model for the example) is shown below: + + +-------------+ +-------+ +-----+ + | Certificate | | | | | + | Path | | TLSTM | tmSecurityName | TSM | + | Validation | --> | | ----------------->| | + +-------------+ +-------+ +-----+ + | + | securityName + V + +-------------+ + | application | + +-------------+ + +4.2. (D)TLS Usage + + (D)TLS MUST negotiate a cipher_suite that uses X.509 certificates for + authentication, and MUST authenticate both the client and the server. + The mandatory-to-implement cipher_suite is specified in the TLS + specification [RFC5246]. + + TLSTM verifies the certificates when the connection is opened (see + Section 5.3). For this reason, TLS renegotiation with different + certificates MUST NOT be done. That is, implementations MUST either + disable renegotiation completely (RECOMMENDED), or they MUST present + the same certificate during renegotiation (and MUST verify that the + other end presented the same certificate). + + For DTLS over UDP, each SNMP message MUST be placed in a single UDP + datagram; it MAY be split to multiple DTLS records. In other words, + if a single datagram contains multiple DTLS application_data records, + they are concatenated when received. The TLSTM implementation SHOULD + return an error if the SNMP message does not fit in the UDP datagram, + and thus cannot be sent. + + For DTLS over UDP, the DTLS server implementation MUST support DTLS + cookies ([RFC4347] already requires that clients support DTLS + cookies). Implementations are not required to perform the cookie + exchange for every DTLS handshake; however, enabling it by default is + RECOMMENDED. + + For DTLS, replay protection MUST be used. + + + + + + + + +Hardaker Standards Track [Page 17] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +4.3. SNMP Services + + This section describes the services provided by the TLS Transport + Model with their inputs and outputs. The services are between the + Transport Model and the Dispatcher. + + The services are described as primitives of an abstract service + interface (ASI) and the inputs and outputs are described as abstract + data elements as they are passed in these abstract service + primitives. + +4.3.1. SNMP Services for an Outgoing Message + + The Dispatcher passes the information to the TLS Transport Model + using the ASI defined in the Transport Subsystem: + + statusInformation = + sendMessage( + IN destTransportDomain -- transport domain to be used + IN destTransportAddress -- transport address to be used + IN outgoingMessage -- the message to send + IN outgoingMessageLength -- its length + IN tmStateReference -- reference to transport state + ) + + The abstract data elements returned from or passed as parameters into + the abstract service primitives are as follows: + + statusInformation: An indication of whether the sending of the + message was successful. If not, it is an indication of the + problem. + + destTransportDomain: The transport domain for the associated + destTransportAddress. The Transport Model uses this parameter to + determine the transport type of the associated + destTransportAddress. This document specifies the + snmpTLSTCPDomain and the snmpDTLSUDPDomain transport domains. + + destTransportAddress: The transport address of the destination TLS + Transport Model in a format specified by the SnmpTLSAddress + TEXTUAL-CONVENTION. + + outgoingMessage: The outgoing message to send to (D)TLS for + encapsulation and transmission. + + outgoingMessageLength: The length of the outgoingMessage. + + + + + +Hardaker Standards Track [Page 18] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + tmStateReference: A reference used to pass model-specific and + mechanism-specific parameters between the Transport Subsystem and + transport-aware Security Models. + +4.3.2. SNMP Services for an Incoming Message + + The TLS Transport Model processes the received message from the + network using the (D)TLS service and then passes it to the Dispatcher + using the following ASI: + + statusInformation = + receiveMessage( + IN transportDomain -- origin transport domain + IN transportAddress -- origin transport address + IN incomingMessage -- the message received + IN incomingMessageLength -- its length + IN tmStateReference -- reference to transport state + ) + + The abstract data elements returned from or passed as parameters into + the abstract service primitives are as follows: + + statusInformation: An indication of whether the passing of the + message was successful. If not, it is an indication of the + problem. + + transportDomain: The transport domain for the associated + transportAddress. This document specifies the snmpTLSTCPDomain + and the snmpDTLSUDPDomain transport domains. + + transportAddress: The transport address of the source of the + received message in a format specified by the SnmpTLSAddress + TEXTUAL-CONVENTION. + + incomingMessage: The whole SNMP message after being processed by + (D)TLS. + + incomingMessageLength: The length of the incomingMessage. + + tmStateReference: A reference used to pass model-specific and + mechanism-specific parameters between the Transport Subsystem and + transport-aware Security Models. + + + + + + + + + +Hardaker Standards Track [Page 19] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +4.4. Cached Information and References + + When performing SNMP processing, there are two levels of state + information that may need to be retained: the immediate state linking + a request-response pair, and potentially longer-term state relating + to transport and security. "Transport Subsystem for the Simple + Network Management Protocol (SNMP)" [RFC5590] defines general + requirements for caches and references. + +4.4.1. TLS Transport Model Cached Information + + The TLS Transport Model has specific responsibilities regarding the + cached information. See the Elements of Procedure in Section 5 for + detailed processing instructions on the use of the tmStateReference + fields by the TLS Transport Model. + +4.4.1.1. tmSecurityName + + The tmSecurityName MUST be a human-readable name (in snmpAdminString + format) representing the identity that has been set according to the + procedures in Section 5. The tmSecurityName MUST be constant for all + traffic passing through a single TLSTM session. Messages MUST NOT be + sent through an existing (D)TLS connection that was established using + a different tmSecurityName. + + On the (D)TLS server side of a connection, the tmSecurityName is + derived using the procedures described in Section 5.3.2 and the SNMP- + TLS-TM-MIB's snmpTlstmCertToTSNTable DESCRIPTION clause. + + On the (D)TLS client side of a connection, the tmSecurityName is + presented to the TLS Transport Model by the security model through + the tmStateReference. This tmSecurityName is typically a copy of or + is derived from the securityName that was passed by application + (possibly because of configuration specified in the SNMP-TARGET-MIB). + The Security Model likely derived the tmSecurityName from the + securityName presented to the Security Model by the application + (possibly because of configuration specified in the SNMP-TARGET-MIB). + + Transport-Model-aware security models derive tmSecurityName from a + securityName, possibly configured in MIB modules for notifications + and access controls. Transport Models SHOULD use predictable + tmSecurityNames so operators will know what to use when configuring + MIB modules that use securityNames derived from tmSecurityNames. The + TLSTM generates predictable tmSecurityNames based on the + configuration found in the SNMP-TLS-TM-MIB's snmpTlstmCertToTSNTable + and relies on the network operators to have configured this table + appropriately. + + + + +Hardaker Standards Track [Page 20] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +4.4.1.2. tmSessionID + + The tmSessionID MUST be recorded per message at the time of receipt. + When tmSameSecurity is set, the recorded tmSessionID can be used to + determine whether the (D)TLS connection available for sending a + corresponding outgoing message is the same (D)TLS connection as was + used when receiving the incoming message (e.g., a response to a + request). + +4.4.1.3. Session State + + The per-session state that is referenced by tmStateReference may be + saved across multiple messages in a Local Configuration Datastore. + Additional session/connection state information might also be stored + in a Local Configuration Datastore. + +5. Elements of Procedure + + Abstract service interfaces have been defined by [RFC3411] and + further augmented by [RFC5590] to describe the conceptual data flows + between the various subsystems within an SNMP entity. The TLSTM uses + some of these conceptual data flows when communicating between + subsystems. + + To simplify the elements of procedure, the release of state + information is not always explicitly specified. As a general rule, + if state information is available when a message gets discarded, the + message-state information should also be released. If state + information is available when a session is closed, the session state + information should also be released. Sensitive information, like + cryptographic keys, should be overwritten appropriately prior to + being released. + + An error indication in statusInformation will typically include the + Object Identifier (OID) and value for an incremented error counter. + This may be accompanied by the requested securityLevel and the + tmStateReference. Per-message context information is not accessible + to Transport Models, so for the returned counter OID and value, + contextEngine would be set to the local value of snmpEngineID and + contextName to the default context for error counters. + +5.1. Procedures for an Incoming Message + + This section describes the procedures followed by the (D)TLS + Transport Model when it receives a (D)TLS protected packet. The + required functionality is broken into two different sections. + + + + + +Hardaker Standards Track [Page 21] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + Section 5.1.1 describes the processing required for de-multiplexing + multiple DTLS connections, which is specifically needed for DTLS over + UDP sessions. It is assumed that TLS protocol implementations + already provide appropriate message demultiplexing. + + Section 5.1.2 describes the transport processing required once the + (D)TLS processing has been completed. This will be needed for all + (D)TLS-based connections. + +5.1.1. DTLS over UDP Processing for Incoming Messages + + Demultiplexing of incoming packets into separate DTLS sessions MUST + be implemented. For connection-oriented transport protocols, such as + TCP, the transport protocol takes care of demultiplexing incoming + packets to the right connection. For DTLS over UDP, this + demultiplexing will either need to be done within the DTLS + implementation, if supported, or by the TLSTM implementation. + + Like TCP, DTLS over UDP uses the four-tuple for identifying the connection + (and relevant DTLS connection state). This means that when + establishing a new session, implementations MUST use a different UDP + source port number for each active connection to a remote destination + IP-address/port-number combination to ensure the remote entity can + disambiguate between multiple connections. + + If demultiplexing received UDP datagrams to DTLS connection state is + done by the TLSTM implementation (instead of the DTLS + implementation), the steps below describe one possible method to + accomplish this. + + The important output results from the steps in this process are the + remote transport address, incomingMessage, incomingMessageLength, and + the tlstmSessionID. + + 1) The TLS Transport Model examines the raw UDP message, in an + implementation-dependent manner. + + 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 + determine if a session already exists. + + 2a) If a matching entry in the LCD does not exist, then the UDP + packet is passed to the DTLS implementation for processing. + If the DTLS implementation decides to continue with the + connection and allocate state for it, it returns a new DTLS + connection handle (an implementation dependent detail). In + + + +Hardaker Standards Track [Page 22] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + this case, TLSTM selects a new tlstmSessionId, and caches + this and the DTLS connection handle as a new entry in the + LCD (indexed by the transport parameters). If the DTLS + implementation returns an error or does not allocate + connection state (which can happen with the stateless cookie + exchange), processing stops. + + 2b) If a session does exist in the LCD, then its DTLS connection + handle (an implementation dependent detail) and its + tlstmSessionId is extracted from the LCD. The UDP packet + and the connection handle are passed to the DTLS + implementation. If the DTLS implementation returns success + but does not return an incomingMessage and an + incomingMessageLength, then processing stops (this is the + case when the UDP datagram contained DTLS handshake + messages, for example). If the DTLS implementation returns + an error, then processing stops. + + 3) Retrieve the incomingMessage and an incomingMessageLength from + DTLS. These results and the tlstmSessionID are used below in + Section 5.1.2 to complete the processing of the incoming message. + +5.1.2. Transport Processing for Incoming SNMP Messages + + The procedures in this section describe how the TLS Transport Model + should process messages that have already been properly extracted + from the (D)TLS stream. Note that care must be taken when processing + messages originating from either TLS or DTLS to ensure they're + complete and single. For example, multiple SNMP messages can be + passed through a single DTLS message and partial SNMP messages may be + received from a TLS stream. These steps describe the processing of a + singular SNMP message after it has been delivered from the (D)TLS + stream. + + 1) Determine the tlstmSessionID for the incoming message. The + tlstmSessionID MUST be a unique session identifier for this + (D)TLS connection. The contents and format of this identifier + are implementation dependent as long as it is unique to the + session. A session identifier MUST NOT be reused until all + references to it are no longer in use. The tmSessionID is equal + to the tlstmSessionID discussed in Section 5.1.1. tmSessionID + refers to the session identifier when stored in the + tmStateReference and tlstmSessionID refers to the session + identifier when stored in the LCD. They MUST always be equal + when processing a given session's traffic. + + + + + + +Hardaker Standards Track [Page 23] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + If this is the first message received through this session, and + the session does not have an assigned tlstmSessionID yet, then + the snmpTlstmSessionAccepts counter is incremented and a + tlstmSessionID for the session is created. This will only happen + on the server side of a connection because a client would have + already assigned a tlstmSessionID during the openSession() + invocation. Implementations may have performed the procedures + described in Section 5.3.2 prior to this point or they may + perform them now, but the procedures described in Section 5.3.2 + MUST be performed before continuing beyond this point. + + 2) Create a tmStateReference cache for the subsequent reference and + assign the following values within it: + + tmTransportDomain = snmpTLSTCPDomain or snmpDTLSUDPDomain as + appropriate. + + tmTransportAddress = The address from which the message + originated. + + tmSecurityLevel = The derived tmSecurityLevel for the session, + as discussed in Sections 3.1.2 and 5.3. + + tmSecurityName = The derived tmSecurityName for the session as + discussed in Section 5.3. This value MUST be constant during + the lifetime of the session. + + tmSessionID = The tlstmSessionID described in step 1 above. + + 3) The incomingMessage and incomingMessageLength are assigned values + from the (D)TLS processing. + + 4) The TLS Transport Model passes the transportDomain, + transportAddress, incomingMessage, and incomingMessageLength to + the Dispatcher using the receiveMessage ASI: + + statusInformation = + receiveMessage( + IN transportDomain -- snmpTLSTCPDomain or snmpDTLSUDPDomain, + IN transportAddress -- address for the received message + IN incomingMessage -- the whole SNMP message from (D)TLS + IN incomingMessageLength -- the length of the SNMP message + IN tmStateReference -- transport info + ) + + + + + + + +Hardaker Standards Track [Page 24] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +5.2. Procedures for an Outgoing SNMP Message + + The Dispatcher sends a message to the TLS Transport Model using the + following ASI: + + statusInformation = + sendMessage( + IN destTransportDomain -- transport domain to be used + IN destTransportAddress -- transport address to be used + IN outgoingMessage -- the message to send + IN outgoingMessageLength -- its length + IN tmStateReference -- transport info + ) + + This section describes the procedure followed by the TLS Transport + Model whenever it is requested through this ASI to send a message. + + 1) If tmStateReference does not refer to a cache containing values + for tmTransportDomain, tmTransportAddress, tmSecurityName, + tmRequestedSecurityLevel, and tmSameSecurity, then increment the + snmpTlstmSessionInvalidCaches counter, discard the message, and + return the error indication in the statusInformation. Processing + of this message stops. + + 2) Extract the tmSessionID, tmTransportDomain, tmTransportAddress, + tmSecurityName, tmRequestedSecurityLevel, and tmSameSecurity + values from the tmStateReference. Note: the tmSessionID value + may be undefined if no session exists yet over which the message + can be sent. + + 3) If tmSameSecurity is true and tmSessionID is either undefined or + refers to a session that is no longer open, then increment the + snmpTlstmSessionNoSessions counter, discard the message, and + return the error indication in the statusInformation. Processing + of this message stops. + + 4) If tmSameSecurity is false and tmSessionID refers to a session + that is no longer available, then an implementation SHOULD open a + new session, using the openSession() ASI (described in greater + detail in step 5b). Instead of opening a new session an + implementation MAY return an snmpTlstmSessionNoSessions error to + the calling module and stop the processing of the message. + + 5) If tmSessionID is undefined, then use tmTransportDomain, + tmTransportAddress, tmSecurityName, and tmRequestedSecurityLevel + to see if there is a corresponding entry in the LCD suitable to + send the message over. + + + + +Hardaker Standards Track [Page 25] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + 5a) If there is a corresponding LCD entry, then this session + will be used to send the message. + + 5b) If there is no corresponding LCD entry, then open a session + using the openSession() ASI (discussed further in + Section 5.3.1). Implementations MAY wish to offer message + buffering to prevent redundant openSession() calls for the + same cache entry. If an error is returned from + openSession(), then discard the message, discard the + tmStateReference, increment the snmpTlstmSessionOpenErrors, + return an error indication to the calling module, and stop + the processing of the message. + + 6) Using either the session indicated by the tmSessionID (if there + was one) or the session resulting from a previous step (4 or 5), + pass the outgoingMessage to (D)TLS for encapsulation and + transmission. + +5.3. Establishing or Accepting a Session + + Establishing a (D)TLS connection as either a client or a server + requires slightly different processing. The following two sections + describe the necessary processing steps. + +5.3.1. Establishing a Session as a Client + + The TLS Transport Model provides the following primitive for use by a + client to establish a new (D)TLS connection: + + statusInformation = -- errorIndication or success + openSession( + IN tmStateReference -- transport information to be used + OUT tmStateReference -- transport information to be used + IN maxMessageSize -- of the sending SNMP entity + ) + + The following describes the procedure to follow when establishing an + SNMP over a (D)TLS connection between SNMP engines for exchanging + SNMP messages. This process is followed by any SNMP client's engine + when establishing a session for subsequent use. + + This procedure MAY be done automatically for an SNMP application that + initiates a transaction, such as a command generator, a notification + originator, or a proxy forwarder. + + 1) The snmpTlstmSessionOpens counter is incremented. + + + + + +Hardaker Standards Track [Page 26] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + 2) The client selects the appropriate certificate and cipher_suites + for the key agreement based on the tmSecurityName and the + tmRequestedSecurityLevel for the session. For sessions being + established as a result of an SNMP-TARGET-MIB based operation, + the certificate will potentially have been identified via the + snmpTlstmParamsTable mapping and the cipher_suites will have to + be taken from a system-wide or implementation-specific + configuration. If no row in the snmpTlstmParamsTable exists, + then implementations MAY choose to establish the connection using + a default client certificate available to the application. + Otherwise, the certificate and appropriate cipher_suites will + need to be passed to the openSession() ASI as supplemental + information or configured through an implementation-dependent + mechanism. It is also implementation-dependent and possibly + policy-dependent how tmRequestedSecurityLevel will be used to + influence the security capabilities provided by the (D)TLS + connection. However this is done, the security capabilities + provided by (D)TLS MUST be at least as high as the level of + security indicated by the tmRequestedSecurityLevel parameter. + The actual security level of the session is reported in the + tmStateReference cache as tmSecurityLevel. For (D)TLS to provide + strong authentication, each principal acting as a command + generator SHOULD have its own certificate. + + 3) Using the destTransportDomain and destTransportAddress values, + the client will initiate the (D)TLS handshake protocol to + establish session keys for message integrity and encryption. + + If the attempt to establish a session is unsuccessful, then + snmpTlstmSessionOpenErrors is incremented, an error indication is + returned, and processing stops. If the session failed to open + because the presented server certificate was unknown or invalid, + then the snmpTlstmSessionUnknownServerCertificate or + snmpTlstmSessionInvalidServerCertificates MUST be incremented and + an snmpTlstmServerCertificateUnknown or + snmpTlstmServerInvalidCertificate notification SHOULD be sent as + appropriate. Reasons for server certificate invalidation + include, but are not limited to, cryptographic validation + failures and an unexpected presented certificate identity. + + 4) The (D)TLS client MUST then verify that the (D)TLS server's + presented certificate is the expected certificate. The (D)TLS + client MUST NOT transmit SNMP messages until the server + certificate has been authenticated, the client certificate has + been transmitted, and the TLS connection has been fully + established. + + + + + +Hardaker Standards Track [Page 27] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + If the connection is being established from a configuration based + on SNMP-TARGET-MIB configuration, then the snmpTlstmAddrTable + DESCRIPTION clause describes how the verification is done (using + either a certificate fingerprint, or an identity authenticated + via certification path validation). + + If the connection is being established for reasons other than + configuration found in the SNMP-TARGET-MIB, then configuration + and procedures outside the scope of this document should be + followed. Configuration mechanisms SHOULD be similar in nature + to those defined in the snmpTlstmAddrTable to ensure consistency + across management configuration systems. For example, a command- + line tool for generating SNMP GETs might support specifying + either the server's certificate fingerprint or the expected host + name as a command-line argument. + + 5) (D)TLS provides assurance that the authenticated identity has + been signed by a trusted configured Certification Authority. If + verification of the server's certificate fails in any way (for + example, because of failures in cryptographic verification or the + presented identity did not match the expected named entity), then + the session establishment MUST fail, and the + snmpTlstmSessionInvalidServerCertificates object is incremented. + If the session cannot be opened for any reason at all, including + cryptographic verification failures and snmpTlstmCertToTSNTable + lookup failures, then the snmpTlstmSessionOpenErrors counter is + incremented and processing stops. + + 6) The TLSTM-specific session identifier (tlstmSessionID) is set in + the tmSessionID of the tmStateReference passed to the TLS + Transport Model to indicate that the session has been established + successfully and to point to a specific (D)TLS connection for + future use. The tlstmSessionID is also stored in the LCD for + later lookup during processing of incoming messages + (Section 5.1.2). + +5.3.2. Accepting a Session as a Server + + A (D)TLS server should accept new session connections from any client + for which it is able to verify the client's credentials. This is + done by authenticating the client's presented certificate through a + certificate path validation process (e.g., [RFC5280]) or through + certificate fingerprint verification using fingerprints configured in + the snmpTlstmCertToTSNTable. Afterward, the server will determine + the identity of the remote entity using the following procedures. + + + + + + +Hardaker Standards Track [Page 28] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The (D)TLS server identifies the authenticated identity from the + (D)TLS client's principal certificate using configuration information + from the snmpTlstmCertToTSNTable mapping table. The (D)TLS server + MUST request and expect a certificate from the client and MUST NOT + accept SNMP messages over the (D)TLS connection until the client has + sent a certificate and it has been authenticated. The resulting + derived tmSecurityName is recorded in the tmStateReference cache as + tmSecurityName. The details of the lookup process are fully + described in the DESCRIPTION clause of the snmpTlstmCertToTSNTable + MIB object. If any verification fails in any way (for example, + because of failures in cryptographic verification or because of the + lack of an appropriate row in the snmpTlstmCertToTSNTable), then the + session establishment MUST fail, and the + snmpTlstmSessionInvalidClientCertificates object is incremented. If + the session cannot be opened for any reason at all, including + cryptographic verification failures, then the + snmpTlstmSessionOpenErrors counter is incremented and processing + stops. + + Servers that wish to support multiple principals at a particular port + SHOULD make use of a (D)TLS extension that allows server-side + principal selection like the Server Name Indication extension defined + in Section 3.1 of [RFC4366]. Supporting this will allow, for + example, sending notifications to a specific principal at a given TCP + or UDP port. + +5.4. Closing a Session + + The TLS Transport Model provides the following primitive to close a + session: + + statusInformation = + closeSession( + IN tmSessionID -- session ID of the session to be closed + ) + + The following describes the procedure to follow to close a session + between a client and server. This process is followed by any SNMP + engine closing the corresponding SNMP session. + + 1) Increment either the snmpTlstmSessionClientCloses or the + snmpTlstmSessionServerCloses counter as appropriate. + + 2) Look up the session using the tmSessionID. + + 3) If there is no open session associated with the tmSessionID, then + closeSession processing is completed. + + + + +Hardaker Standards Track [Page 29] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + 4) Have (D)TLS close the specified connection. This MUST include + sending a close_notify TLS Alert to inform the other side that + session cleanup may be performed. + +6. MIB Module Overview + + This MIB module provides management of the TLS Transport Model. It + defines needed textual conventions, statistical counters, + notifications, and configuration infrastructure necessary for session + establishment. Example usage of the configuration tables can be + found in Appendix A. + +6.1. Structure of the MIB Module + + Objects in this MIB module are arranged into subtrees. Each subtree + is organized as a set of related objects. The overall structure and + assignment of objects to their subtrees, and the intended purpose of + each subtree, is shown below. + +6.2. Textual Conventions + + Generic and Common Textual Conventions used in this module can be + found summarized at http://www.ops.ietf.org/mib-common-tcs.html. + + This module defines the following new Textual Conventions: + + o A new TransportAddress format for describing (D)TLS connection + addressing requirements. + + o A certificate fingerprint allowing MIB module objects to + generically refer to a stored X.509 certificate using a + cryptographic hash as a reference pointer. + +6.3. Statistical Counters + + The SNMP-TLS-TM-MIB defines counters that provide network management + stations with information about session usage and potential errors + that a device may be experiencing. + +6.4. Configuration Tables + + The SNMP-TLS-TM-MIB defines configuration tables that an + administrator can use for configuring a device for sending and + receiving SNMP messages over (D)TLS. In particular, 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 client + certificates to SNMPv3 tmSecurityNames. + + + + +Hardaker Standards Track [Page 30] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +6.4.1. Notifications + + The SNMP-TLS-TM-MIB defines notifications to alert management + stations when a (D)TLS connection fails because a server's presented + certificate did not meet an expected value + (snmpTlstmServerCertificateUnknown) or because cryptographic + validation failed (snmpTlstmServerInvalidCertificate). + +6.5. Relationship to Other MIB Modules + + Some management objects defined in other MIB modules are applicable + to an entity implementing the TLS Transport Model. In particular, it + is assumed that an entity implementing the SNMP-TLS-TM-MIB will + implement the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411], + the SNMP-TARGET-MIB [RFC3413], the SNMP-NOTIFICATION-MIB [RFC3413], + and the SNMP-VIEW-BASED-ACM-MIB [RFC3415]. + + The SNMP-TLS-TM-MIB module contained in this document is for managing + TLS Transport Model information. + +6.5.1. MIB Modules Required for IMPORTS + + The SNMP-TLS-TM-MIB module imports items from SNMPv2-SMI [RFC2578], + SNMPv2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMP-TARGET-MIB + [RFC3413], and SNMPv2-CONF [RFC2580]. + +7. MIB Module Definition + +SNMP-TLS-TM-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, + OBJECT-IDENTITY, mib-2, snmpDomains, + Counter32, Unsigned32, Gauge32, NOTIFICATION-TYPE + FROM SNMPv2-SMI -- RFC 2578 or any update thereof + TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType, + AutonomousType + FROM SNMPv2-TC -- RFC 2579 or any update thereof + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 or any update thereof + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 or any update thereof + snmpTargetParamsName, snmpTargetAddrName + FROM SNMP-TARGET-MIB -- RFC 3413 or any update thereof + ; + +snmpTlstmMIB MODULE-IDENTITY + LAST-UPDATED "201107190000Z" + + + +Hardaker Standards Track [Page 31] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + ORGANIZATION "ISMS Working Group" + CONTACT-INFO "WG-EMail: isms@lists.ietf.org + Subscribe: isms-request@lists.ietf.org + + Chairs: + Juergen Schoenwaelder + Jacobs University Bremen + Campus Ring 1 + 28725 Bremen + Germany + +49 421 200-3587 + j.schoenwaelder@jacobs-university.de + + Russ Mundy + SPARTA, Inc. + 7110 Samuel Morse Drive + Columbia, MD 21046 + USA + + Editor: + Wes Hardaker + SPARTA, Inc. + P.O. Box 382 + Davis, CA 95617 + USA + ietf@hardakers.net + " + + DESCRIPTION " + The TLS Transport Model MIB + + Copyright (c) 2010-2011 IETF Trust and the persons identified + as authors of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or + without modification, is permitted pursuant to, and subject + to the license terms contained in, the Simplified BSD License + set forth in Section 4.c of the IETF Trust's Legal Provisions + Relating to IETF Documents + (http://trustee.ietf.org/license-info)." + + REVISION "201107190000Z" + DESCRIPTION "This version of this MIB module is part of + RFC 6353; see the RFC itself for full legal + notices. The only change was to introduce + new wording to reflect require changes for + IDNA addresses in the SnmpTLSAddress TC." + + + + +Hardaker Standards Track [Page 32] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + REVISION "201005070000Z" + DESCRIPTION "This version of this MIB module is part of + RFC 5953; see the RFC itself for full legal + notices." + + ::= { mib-2 198 } + +-- ************************************************ +-- subtrees of the SNMP-TLS-TM-MIB +-- ************************************************ + +snmpTlstmNotifications OBJECT IDENTIFIER ::= { snmpTlstmMIB 0 } +snmpTlstmIdentities OBJECT IDENTIFIER ::= { snmpTlstmMIB 1 } +snmpTlstmObjects OBJECT IDENTIFIER ::= { snmpTlstmMIB 2 } +snmpTlstmConformance OBJECT IDENTIFIER ::= { snmpTlstmMIB 3 } + +-- ************************************************ +-- snmpTlstmObjects - Objects +-- ************************************************ + +snmpTLSTCPDomain OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The SNMP over TLS via TCP transport domain. The + corresponding transport address is of type SnmpTLSAddress. + + The securityName prefix to be associated with the + snmpTLSTCPDomain is 'tls'. This prefix may be used by + security models or other components to identify which secure + transport infrastructure authenticated a securityName." + REFERENCE + "RFC 2579: Textual Conventions for SMIv2" + ::= { snmpDomains 8 } + +snmpDTLSUDPDomain OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The SNMP over DTLS via UDP transport domain. The + corresponding transport address is of type SnmpTLSAddress. + + The securityName prefix to be associated with the + snmpDTLSUDPDomain is 'dtls'. This prefix may be used by + security models or other components to identify which secure + transport infrastructure authenticated a securityName." + REFERENCE + "RFC 2579: Textual Conventions for SMIv2" + ::= { snmpDomains 9 } + + + + +Hardaker Standards Track [Page 33] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +SnmpTLSAddress ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1a" + STATUS current + DESCRIPTION + "Represents an IPv4 address, an IPv6 address, or a + US-ASCII-encoded hostname and port number. + + An IPv4 address must be in dotted decimal format followed by a + colon ':' (US-ASCII character 0x3A) and a decimal port number + in US-ASCII. + + An IPv6 address must be a colon-separated format (as described + in RFC 5952), surrounded by square brackets ('[', US-ASCII + character 0x5B, and ']', US-ASCII character 0x5D), followed by + a colon ':' (US-ASCII character 0x3A) and a decimal port number + in US-ASCII. + + A hostname is always in US-ASCII (as per RFC 1123); + internationalized hostnames are encoded as A-labels as specified + in RFC 5890. 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. + + Values of this textual convention may not be directly usable + as transport-layer addressing information, and may require + run-time resolution. As such, applications that write them + must be prepared for handling errors if such values are not + supported, or cannot be resolved (if resolution occurs at the + time of the management operation). + + The DESCRIPTION clause of TransportAddress objects that may + have SnmpTLSAddress values must fully describe how (and + when) such names are to be resolved to IP addresses and vice + versa. + + This textual convention SHOULD NOT be used directly in object + definitions since it restricts addresses to a specific + format. However, if it is used, it MAY be used either on its + own or in conjunction with TransportAddressType or + TransportDomain as a pair. + + When this textual convention is used as a syntax of an index + object, there may be issues with the limit of 128 + sub-identifiers specified in SMIv2 (STD 58). It is RECOMMENDED + that all MIB documents using this textual convention make + explicit any limitations on index component lengths that + management software must observe. This may be done either by + + + +Hardaker Standards Track [Page 34] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + including SIZE constraints on the index components or by + specifying applicable constraints in the conceptual row + DESCRIPTION clause or in the surrounding documentation." + REFERENCE + "RFC 1123: Requirements for Internet Hosts - Application and + Support + RFC 5890: Internationalized Domain Names for Applications (IDNA): + Definitions and Document Framework + RFC 5952: A Recommendation for IPv6 Address Text Representation + " + SYNTAX OCTET STRING (SIZE (1..255)) + +SnmpTLSFingerprint ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1x:1x" + STATUS current + DESCRIPTION + "A fingerprint value that can be used to uniquely reference + other data of potentially arbitrary length. + + An SnmpTLSFingerprint value is composed of a 1-octet hashing + algorithm identifier followed by the fingerprint value. The + octet value encoded is taken from the IANA TLS HashAlgorithm + Registry (RFC 5246). The remaining octets are filled using the + results of the hashing algorithm. + + This TEXTUAL-CONVENTION allows for a zero-length (blank) + SnmpTLSFingerprint value for use in tables where the + fingerprint value may be optional. MIB definitions or + implementations may refuse to accept a zero-length value as + appropriate." + REFERENCE "RFC 5246: The Transport Layer + Security (TLS) Protocol Version 1.2 + http://www.iana.org/assignments/tls-parameters/ + " + SYNTAX OCTET STRING (SIZE (0..255)) + +-- Identities for use in the snmpTlstmCertToTSNTable + +snmpTlstmCertToTSNMIdentities OBJECT IDENTIFIER + ::= { snmpTlstmIdentities 1 } + +snmpTlstmCertSpecified OBJECT-IDENTITY + STATUS current + DESCRIPTION "Directly specifies the tmSecurityName to be used for + this certificate. The value of the tmSecurityName + to use is specified in the snmpTlstmCertToTSNData + column. The snmpTlstmCertToTSNData column must + contain a non-zero length SnmpAdminString compliant + + + +Hardaker Standards Track [Page 35] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + value or the mapping described in this row must be + considered a failure." + ::= { snmpTlstmCertToTSNMIdentities 1 } + +snmpTlstmCertSANRFC822Name OBJECT-IDENTITY + STATUS current + DESCRIPTION "Maps a subjectAltName's rfc822Name to a + tmSecurityName. The local part of the rfc822Name is + passed unaltered but the host-part of the name must + be passed in lowercase. This mapping results in a + 1:1 correspondence between equivalent subjectAltName + rfc822Name values and tmSecurityName values except + that the host-part of the name MUST be passed in + lowercase. + + Example rfc822Name Field: FooBar@Example.COM + is mapped to tmSecurityName: FooBar@example.com." + ::= { snmpTlstmCertToTSNMIdentities 2 } + +snmpTlstmCertSANDNSName OBJECT-IDENTITY + STATUS current + DESCRIPTION "Maps a subjectAltName's dNSName to a + tmSecurityName after first converting it to all + lowercase (RFC 5280 does not specify converting to + lowercase so this involves an extra step). This + mapping results in a 1:1 correspondence between + subjectAltName dNSName values and the tmSecurityName + values." + REFERENCE "RFC 5280 - Internet X.509 Public Key Infrastructure + Certificate and Certificate Revocation + List (CRL) Profile." + ::= { snmpTlstmCertToTSNMIdentities 3 } + +snmpTlstmCertSANIpAddress OBJECT-IDENTITY + STATUS current + DESCRIPTION "Maps a subjectAltName's iPAddress to a + tmSecurityName by transforming the binary encoded + address as follows: + + 1) for IPv4, the value is converted into a + decimal-dotted quad address (e.g., '192.0.2.1'). + + 2) for IPv6 addresses, the value is converted into a + 32-character all lowercase hexadecimal string + without any colon separators. + + + + + + +Hardaker Standards Track [Page 36] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + This mapping results in a 1:1 correspondence between + subjectAltName iPAddress values and the + tmSecurityName values. + + The resulting length of an encoded IPv6 address is + the maximum length supported by the View-Based + Access Control Model (VACM). Using both the + Transport Security Model's support for transport + prefixes (see the SNMP-TSM-MIB's + snmpTsmConfigurationUsePrefix object for details) + will result in securityName lengths that exceed what + VACM can handle." + ::= { snmpTlstmCertToTSNMIdentities 4 } + +snmpTlstmCertSANAny OBJECT-IDENTITY + STATUS current + DESCRIPTION "Maps any of the following fields using the + corresponding mapping algorithms: + + |------------+----------------------------| + | Type | Algorithm | + |------------+----------------------------| + | rfc822Name | snmpTlstmCertSANRFC822Name | + | dNSName | snmpTlstmCertSANDNSName | + | iPAddress | snmpTlstmCertSANIpAddress | + |------------+----------------------------| + + The first matching subjectAltName value found in the + certificate of the above types MUST be used when + deriving the tmSecurityName. The mapping algorithm + specified in the 'Algorithm' column MUST be used to + derive the tmSecurityName. + + This mapping results in a 1:1 correspondence between + subjectAltName values and tmSecurityName values. The + three sub-mapping algorithms produced by this + combined algorithm cannot produce conflicting + results between themselves." + ::= { snmpTlstmCertToTSNMIdentities 5 } + +snmpTlstmCertCommonName OBJECT-IDENTITY + STATUS current + + DESCRIPTION "Maps a certificate's CommonName to a tmSecurityName + after converting it to a UTF-8 encoding. The usage + of CommonNames is deprecated and users are + encouraged to use subjectAltName mapping methods + instead. This mapping results in a 1:1 + + + +Hardaker Standards Track [Page 37] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + correspondence between certificate CommonName values + and tmSecurityName values." + ::= { snmpTlstmCertToTSNMIdentities 6 } + +-- The snmpTlstmSession Group + +snmpTlstmSession OBJECT IDENTIFIER ::= { snmpTlstmObjects 1 } + +snmpTlstmSessionOpens OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times an openSession() request has been executed + as a (D)TLS client, regardless of whether it succeeded or + failed." + ::= { snmpTlstmSession 1 } + +snmpTlstmSessionClientCloses OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times a closeSession() request has been + executed as a (D)TLS client, regardless of whether it + succeeded or failed." + ::= { snmpTlstmSession 2 } + +snmpTlstmSessionOpenErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times an openSession() request failed to open a + session as a (D)TLS client, for any reason." + ::= { snmpTlstmSession 3 } + +snmpTlstmSessionAccepts OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times a (D)TLS server has accepted a new + connection from a client and has received at least one SNMP + message through it." + ::= { snmpTlstmSession 4 } + + + + + +Hardaker Standards Track [Page 38] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +snmpTlstmSessionServerCloses OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times a closeSession() request has been + executed as a (D)TLS server, regardless of whether it + succeeded or failed." + ::= { snmpTlstmSession 5 } + +snmpTlstmSessionNoSessions OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times an outgoing message was dropped because + the session associated with the passed tmStateReference was no + longer (or was never) available." + ::= { snmpTlstmSession 6 } + +snmpTlstmSessionInvalidClientCertificates OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times an incoming session was not established + on a (D)TLS server because the presented client certificate + was invalid. Reasons for invalidation include, but are not + limited to, cryptographic validation failures or lack of a + suitable mapping row in the snmpTlstmCertToTSNTable." + ::= { snmpTlstmSession 7 } + +snmpTlstmSessionUnknownServerCertificate OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times an outgoing session was not established + on a (D)TLS client because the server certificate presented + by an SNMP over (D)TLS server was invalid because no + configured fingerprint or Certification Authority (CA) was + acceptable to validate it. + This may result because there was no entry in the + snmpTlstmAddrTable or because no path could be found to a + known CA." + ::= { snmpTlstmSession 8 } + + + + + +Hardaker Standards Track [Page 39] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +snmpTlstmSessionInvalidServerCertificates OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times an outgoing session was not established + on a (D)TLS client because the server certificate presented + by an SNMP over (D)TLS server could not be validated even if + the fingerprint or expected validation path was known. That + is, a cryptographic validation error occurred during + certificate validation processing. + + Reasons for invalidation include, but are not + limited to, cryptographic validation failures." + ::= { snmpTlstmSession 9 } + +snmpTlstmSessionInvalidCaches OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of outgoing messages dropped because the + tmStateReference referred to an invalid cache." + ::= { snmpTlstmSession 10 } + +-- Configuration Objects + +snmpTlstmConfig OBJECT IDENTIFIER ::= { snmpTlstmObjects 2 } + +-- Certificate mapping + +snmpTlstmCertificateMapping OBJECT IDENTIFIER ::= { snmpTlstmConfig 1 } + +snmpTlstmCertToTSNCount OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of the number of entries in the + snmpTlstmCertToTSNTable." + ::= { snmpTlstmCertificateMapping 1 } + +snmpTlstmCertToTSNTableLastChanged OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + + + + + +Hardaker Standards Track [Page 40] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + DESCRIPTION + "The value of sysUpTime.0 when the snmpTlstmCertToTSNTable was + last modified through any means, or 0 if it has not been + modified since the command responder was started." + ::= { snmpTlstmCertificateMapping 2 } + +snmpTlstmCertToTSNTable OBJECT-TYPE + SYNTAX SEQUENCE OF SnmpTlstmCertToTSNEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table is used by a (D)TLS server to map the (D)TLS + client's presented X.509 certificate to a tmSecurityName. + + On an incoming (D)TLS/SNMP connection, the client's presented + certificate must either be validated based on an established + trust anchor, or it must directly match a fingerprint in this + table. This table does not provide any mechanisms for + configuring the trust anchors; the transfer of any needed + trusted certificates for path validation is expected to occur + through an out-of-band transfer. + + Once the certificate has been found acceptable (either by path + validation or directly matching a fingerprint in this table), + this table is consulted to determine the appropriate + tmSecurityName to identify with the remote connection. This + is done by considering each active row from this table in + prioritized order according to its snmpTlstmCertToTSNID value. + Each row's snmpTlstmCertToTSNFingerprint value determines + whether the row is a match for the incoming connection: + + 1) If the row's snmpTlstmCertToTSNFingerprint value + identifies the presented certificate, then consider the + row as a successful match. + + 2) If the row's snmpTlstmCertToTSNFingerprint value + identifies a locally held copy of a trusted CA + certificate and that CA certificate was used to + validate the path to the presented certificate, then + consider the row as a successful match. + + Once a matching row has been found, the + snmpTlstmCertToTSNMapType value can be used to determine how + the tmSecurityName to associate with the session should be + determined. See the snmpTlstmCertToTSNMapType column's + DESCRIPTION for details on determining the tmSecurityName + value. If it is impossible to determine a tmSecurityName from + the row's data combined with the data presented in the + + + +Hardaker Standards Track [Page 41] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + certificate, then additional rows MUST be searched looking for + another potential match. If a resulting tmSecurityName mapped + from a given row is not compatible with the needed + requirements of a tmSecurityName (e.g., VACM imposes a + 32-octet-maximum length and the certificate derived + securityName could be longer), then it must be considered an + invalid match and additional rows MUST be searched looking for + 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 + implementations should continue to the next highest numbered + row. It is recommended that administrators skip index values + to leave room for the insertion of future rows (for example, + use values of 10 and 20 when creating initial rows). + + Users are encouraged to make use of certificates with + subjectAltName fields that can be used as tmSecurityNames so + that a single root CA certificate can allow all child + certificate's subjectAltName to map directly to a + tmSecurityName via a 1:1 transformation. However, this table + is flexible to allow for situations where existing deployed + certificate infrastructures do not provide adequate + subjectAltName values for use as tmSecurityNames. + Certificates may also be mapped to tmSecurityNames using the + CommonName portion of the Subject field. However, the usage + of the CommonName field is deprecated and thus this usage is + NOT RECOMMENDED. Direct mapping from each individual + certificate fingerprint to a tmSecurityName is also possible + but requires one entry in the table per tmSecurityName and + requires more management operations to completely configure a + device." + ::= { snmpTlstmCertificateMapping 3 } + +snmpTlstmCertToTSNEntry OBJECT-TYPE + SYNTAX SnmpTlstmCertToTSNEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A row in the snmpTlstmCertToTSNTable that specifies a mapping + for an incoming (D)TLS certificate to a tmSecurityName to use + for a connection." + INDEX { snmpTlstmCertToTSNID } + ::= { snmpTlstmCertToTSNTable 1 } + + + + + +Hardaker Standards Track [Page 42] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +SnmpTlstmCertToTSNEntry ::= SEQUENCE { + snmpTlstmCertToTSNID Unsigned32, + snmpTlstmCertToTSNFingerprint SnmpTLSFingerprint, + snmpTlstmCertToTSNMapType AutonomousType, + snmpTlstmCertToTSNData OCTET STRING, + snmpTlstmCertToTSNStorageType StorageType, + snmpTlstmCertToTSNRowStatus RowStatus +} + +snmpTlstmCertToTSNID OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A unique, prioritized index for the given entry. Lower + numbers indicate a higher priority." + ::= { snmpTlstmCertToTSNEntry 1 } + +snmpTlstmCertToTSNFingerprint OBJECT-TYPE + SYNTAX SnmpTLSFingerprint (SIZE(1..255)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A cryptographic hash of an X.509 certificate. The results of + a successful matching fingerprint to either the trusted CA in + the certificate validation path or to the certificate itself + is dictated by the snmpTlstmCertToTSNMapType column." + ::= { snmpTlstmCertToTSNEntry 2 } + +snmpTlstmCertToTSNMapType OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Specifies the mapping type for deriving a tmSecurityName from + a certificate. Details for mapping of a particular type SHALL + be specified in the DESCRIPTION clause of the OBJECT-IDENTITY + that describes the mapping. If a mapping succeeds it will + return a tmSecurityName for use by the TLSTM model and + processing stops. + + If the resulting mapped value is not compatible with the + needed requirements of a tmSecurityName (e.g., VACM imposes a + 32-octet-maximum length and the certificate derived + securityName could be longer), then future rows MUST be + searched for additional snmpTlstmCertToTSNFingerprint matches + to look for a mapping that succeeds. + + + + +Hardaker Standards Track [Page 43] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + 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 } + ::= { snmpTlstmCertToTSNEntry 3 } + +snmpTlstmCertToTSNData OBJECT-TYPE + SYNTAX OCTET STRING (SIZE(0..1024)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Auxiliary data used as optional configuration information for + a given mapping specified by the snmpTlstmCertToTSNMapType + column. Only some mapping systems will make use of this + column. The value in this column MUST be ignored for any + mapping type that does not require data present in this + column." + DEFVAL { "" } + ::= { snmpTlstmCertToTSNEntry 4 } + +snmpTlstmCertToTSNStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for this conceptual row. Conceptual rows + having the value 'permanent' need not allow write-access to + any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { snmpTlstmCertToTSNEntry 5 } + +snmpTlstmCertToTSNRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The status of this conceptual row. This object may be used + to create or remove rows from this table. + + To create a row in this table, an administrator must set this + object to either createAndGo(4) or createAndWait(5). + + Until instances of all corresponding columns are appropriately + configured, the value of the corresponding instance of the + snmpTlstmParamsRowStatus column is notReady(3). + + In particular, a newly created row cannot be made active until + the corresponding snmpTlstmCertToTSNFingerprint, + + + +Hardaker Standards Track [Page 44] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + snmpTlstmCertToTSNMapType, and snmpTlstmCertToTSNData columns + have been set. + + The following objects may not be modified while the + value of this object is active(1): + - snmpTlstmCertToTSNFingerprint + - snmpTlstmCertToTSNMapType + - snmpTlstmCertToTSNData + An attempt to set these objects while the value of + snmpTlstmParamsRowStatus is active(1) will result in + an inconsistentValue error." + ::= { snmpTlstmCertToTSNEntry 6 } + +-- Maps tmSecurityNames to certificates for use by the SNMP-TARGET-MIB + +snmpTlstmParamsCount OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of the number of entries in the snmpTlstmParamsTable." + ::= { snmpTlstmCertificateMapping 4 } + +snmpTlstmParamsTableLastChanged OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime.0 when the snmpTlstmParamsTable + was last modified through any means, or 0 if it has not been + modified since the command responder was started." + ::= { snmpTlstmCertificateMapping 5 } + +snmpTlstmParamsTable OBJECT-TYPE + SYNTAX SEQUENCE OF SnmpTlstmParamsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table is used by a (D)TLS client when a (D)TLS + connection is being set up using an entry in the + SNMP-TARGET-MIB. It extends the SNMP-TARGET-MIB's + snmpTargetParamsTable with a fingerprint of a certificate to + use when establishing such a (D)TLS connection." + ::= { snmpTlstmCertificateMapping 6 } + +snmpTlstmParamsEntry OBJECT-TYPE + SYNTAX SnmpTlstmParamsEntry + MAX-ACCESS not-accessible + + + +Hardaker Standards Track [Page 45] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + STATUS current + DESCRIPTION + "A conceptual row containing a fingerprint hash of a locally + held certificate for a given snmpTargetParamsEntry. The + values in this row should be ignored if the connection that + needs to be established, as indicated by the SNMP-TARGET-MIB + infrastructure, is not a certificate and (D)TLS based + connection. The connection SHOULD NOT be established if the + certificate fingerprint stored in this entry does not point to + a valid locally held certificate or if it points to an + unusable certificate (such as might happen when the + certificate's expiration date has been reached)." + INDEX { IMPLIED snmpTargetParamsName } + ::= { snmpTlstmParamsTable 1 } + +SnmpTlstmParamsEntry ::= SEQUENCE { + snmpTlstmParamsClientFingerprint SnmpTLSFingerprint, + snmpTlstmParamsStorageType StorageType, + snmpTlstmParamsRowStatus RowStatus +} + +snmpTlstmParamsClientFingerprint OBJECT-TYPE + SYNTAX SnmpTLSFingerprint + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object stores the hash of the public portion of a + locally held X.509 certificate. The X.509 certificate, its + public key, and the corresponding private key will be used + when initiating a (D)TLS connection as a (D)TLS client." + ::= { snmpTlstmParamsEntry 1 } + +snmpTlstmParamsStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for this conceptual row. Conceptual rows + having the value 'permanent' need not allow write-access to + any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { snmpTlstmParamsEntry 2 } + +snmpTlstmParamsRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + + + +Hardaker Standards Track [Page 46] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + "The status of this conceptual row. This object may be used + to create or remove rows from this table. + + To create a row in this table, an administrator must set this + object to either createAndGo(4) or createAndWait(5). + + Until instances of all corresponding columns are appropriately + configured, the value of the corresponding instance of the + snmpTlstmParamsRowStatus column is notReady(3). + + In particular, a newly created row cannot be made active until + the corresponding snmpTlstmParamsClientFingerprint column has + been set. + + The snmpTlstmParamsClientFingerprint object may not be modified + while the value of this object is active(1). + + An attempt to set these objects while the value of + snmpTlstmParamsRowStatus is active(1) will result in + an inconsistentValue error." + ::= { snmpTlstmParamsEntry 3 } + +snmpTlstmAddrCount OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of the number of entries in the snmpTlstmAddrTable." + ::= { snmpTlstmCertificateMapping 7 } + +snmpTlstmAddrTableLastChanged OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime.0 when the snmpTlstmAddrTable + was last modified through any means, or 0 if it has not been + modified since the command responder was started." + ::= { snmpTlstmCertificateMapping 8 } + +snmpTlstmAddrTable OBJECT-TYPE + SYNTAX SEQUENCE OF SnmpTlstmAddrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table is used by a (D)TLS client when a (D)TLS + connection is being set up using an entry in the + SNMP-TARGET-MIB. It extends the SNMP-TARGET-MIB's + + + +Hardaker Standards Track [Page 47] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + snmpTargetAddrTable so that the client can verify that the + correct server has been reached. This verification can use + either a certificate fingerprint, or an identity + authenticated via certification path validation. + + If there is an active row in this table corresponding to the + entry in the SNMP-TARGET-MIB that was used to establish the + connection, and the row's snmpTlstmAddrServerFingerprint + column has non-empty value, then the server's presented + certificate is compared with the + snmpTlstmAddrServerFingerprint value (and the + snmpTlstmAddrServerIdentity column is ignored). If the + fingerprint matches, the verification has succeeded. If the + fingerprint does not match, then the connection MUST be + closed. + + If the server's presented certificate has passed + certification path validation [RFC5280] to a configured + trust anchor, and an active row exists with a zero-length + snmpTlstmAddrServerFingerprint value, then the + snmpTlstmAddrServerIdentity column contains the expected + host name. This expected host name is then compared against + the server's certificate as follows: + + - Implementations MUST support matching the expected host + name against a dNSName in the subjectAltName extension + field and MAY support checking the name against the + CommonName portion of the subject distinguished name. + + - The '*' (ASCII 0x2a) wildcard character is allowed in the + dNSName of the subjectAltName extension (and in common + name, if used to store the host name), but only as the + left-most (least significant) DNS label in that value. + This wildcard matches any left-most DNS label in the + server name. That is, the subject *.example.com matches + the server names a.example.com and b.example.com, but does + not match example.com or a.b.example.com. Implementations + MUST support wildcards in certificates as specified above, + but MAY provide a configuration option to disable them. + + - If the locally configured name is an internationalized + domain name, conforming implementations MUST convert it to + the ASCII Compatible Encoding (ACE) format for performing + comparisons, as specified in Section 7 of [RFC5280]. + + If the expected host name fails these conditions then the + connection MUST be closed. + + + + +Hardaker Standards Track [Page 48] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + If there is no row in this table corresponding to the entry + in the SNMP-TARGET-MIB and the server can be authorized by + another, implementation-dependent means, then the connection + MAY still proceed." + + ::= { snmpTlstmCertificateMapping 9 } + +snmpTlstmAddrEntry OBJECT-TYPE + SYNTAX SnmpTlstmAddrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row containing a copy of a certificate's + fingerprint for a given snmpTargetAddrEntry. The values in + this row should be ignored if the connection that needs to be + established, as indicated by the SNMP-TARGET-MIB + infrastructure, is not a (D)TLS based connection. If an + snmpTlstmAddrEntry exists for a given snmpTargetAddrEntry, then + the presented server certificate MUST match or the connection + MUST NOT be established. If a row in this table does not + exist to match an snmpTargetAddrEntry row, then the connection + SHOULD still proceed if some other certificate validation path + algorithm (e.g., RFC 5280) can be used." + INDEX { IMPLIED snmpTargetAddrName } + ::= { snmpTlstmAddrTable 1 } + +SnmpTlstmAddrEntry ::= SEQUENCE { + snmpTlstmAddrServerFingerprint SnmpTLSFingerprint, + snmpTlstmAddrServerIdentity SnmpAdminString, + snmpTlstmAddrStorageType StorageType, + snmpTlstmAddrRowStatus RowStatus +} + +snmpTlstmAddrServerFingerprint OBJECT-TYPE + SYNTAX SnmpTLSFingerprint + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A cryptographic hash of a public X.509 certificate. This + object should store the hash of the public X.509 certificate + that the remote server should present during the (D)TLS + connection setup. The fingerprint of the presented + certificate and this hash value MUST match exactly or the + connection MUST NOT be established." + DEFVAL { "" } + ::= { snmpTlstmAddrEntry 1 } + + + + + +Hardaker Standards Track [Page 49] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +snmpTlstmAddrServerIdentity OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The reference identity to check against the identity + presented by the remote system." + DEFVAL { "" } + ::= { snmpTlstmAddrEntry 2 } + +snmpTlstmAddrStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for this conceptual row. Conceptual rows + having the value 'permanent' need not allow write-access to + any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { snmpTlstmAddrEntry 3 } + + +snmpTlstmAddrRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The status of this conceptual row. This object may be used + to create or remove rows from this table. + + To create a row in this table, an administrator must set this + object to either createAndGo(4) or createAndWait(5). + + Until instances of all corresponding columns are + appropriately configured, the value of the + corresponding instance of the snmpTlstmAddrRowStatus + column is notReady(3). + + In particular, a newly created row cannot be made active until + the corresponding snmpTlstmAddrServerFingerprint column has been + set. + + Rows MUST NOT be active if the snmpTlstmAddrServerFingerprint + column is blank and the snmpTlstmAddrServerIdentity is set to + '*' since this would insecurely accept any presented + certificate. + + + + + +Hardaker Standards Track [Page 50] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The snmpTlstmAddrServerFingerprint object may not be modified + while the value of this object is active(1). + + An attempt to set these objects while the value of + snmpTlstmAddrRowStatus is active(1) will result in + an inconsistentValue error." + ::= { snmpTlstmAddrEntry 4 } + +-- ************************************************ +-- snmpTlstmNotifications - Notifications Information +-- ************************************************ + +snmpTlstmServerCertificateUnknown NOTIFICATION-TYPE + OBJECTS { snmpTlstmSessionUnknownServerCertificate } + STATUS current + DESCRIPTION + "Notification that the server certificate presented by an SNMP + over (D)TLS server was invalid because no configured + fingerprint or CA was acceptable to validate it. This may be + because there was no entry in the snmpTlstmAddrTable or + because no path could be found to known Certification + Authority. + + To avoid notification loops, this notification MUST NOT be + sent to servers that themselves have triggered the + notification." + ::= { snmpTlstmNotifications 1 } + +snmpTlstmServerInvalidCertificate NOTIFICATION-TYPE + OBJECTS { snmpTlstmAddrServerFingerprint, + snmpTlstmSessionInvalidServerCertificates} + STATUS current + DESCRIPTION + "Notification that the server certificate presented by an SNMP + over (D)TLS server could not be validated even if the + fingerprint or expected validation path was known. That is, a + cryptographic validation error occurred during certificate + validation processing. + + To avoid notification loops, this notification MUST NOT be + sent to servers that themselves have triggered the + notification." + ::= { snmpTlstmNotifications 2 } + +-- ************************************************ +-- snmpTlstmCompliances - Conformance Information +-- ************************************************ + + + + +Hardaker Standards Track [Page 51] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +snmpTlstmCompliances OBJECT IDENTIFIER ::= { snmpTlstmConformance 1 } + +snmpTlstmGroups OBJECT IDENTIFIER ::= { snmpTlstmConformance 2 } + +-- ************************************************ +-- Compliance statements +-- ************************************************ + +snmpTlstmCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP engines that support the + SNMP-TLS-TM-MIB" + MODULE + MANDATORY-GROUPS { snmpTlstmStatsGroup, + snmpTlstmIncomingGroup, + snmpTlstmOutgoingGroup, + snmpTlstmNotificationGroup } + ::= { snmpTlstmCompliances 1 } + +-- ************************************************ +-- Units of conformance +-- ************************************************ +snmpTlstmStatsGroup OBJECT-GROUP + OBJECTS { + snmpTlstmSessionOpens, + snmpTlstmSessionClientCloses, + snmpTlstmSessionOpenErrors, + snmpTlstmSessionAccepts, + snmpTlstmSessionServerCloses, + snmpTlstmSessionNoSessions, + snmpTlstmSessionInvalidClientCertificates, + snmpTlstmSessionUnknownServerCertificate, + snmpTlstmSessionInvalidServerCertificates, + snmpTlstmSessionInvalidCaches + } + STATUS current + DESCRIPTION + "A collection of objects for maintaining + statistical information of an SNMP engine that + implements the SNMP TLS Transport Model." + ::= { snmpTlstmGroups 1 } + +snmpTlstmIncomingGroup OBJECT-GROUP + OBJECTS { + snmpTlstmCertToTSNCount, + snmpTlstmCertToTSNTableLastChanged, + snmpTlstmCertToTSNFingerprint, + + + +Hardaker Standards Track [Page 52] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + snmpTlstmCertToTSNMapType, + snmpTlstmCertToTSNData, + snmpTlstmCertToTSNStorageType, + snmpTlstmCertToTSNRowStatus + } + STATUS current + DESCRIPTION + "A collection of objects for maintaining + incoming connection certificate mappings to + tmSecurityNames of an SNMP engine that implements the + SNMP TLS Transport Model." + ::= { snmpTlstmGroups 2 } + +snmpTlstmOutgoingGroup OBJECT-GROUP + OBJECTS { + snmpTlstmParamsCount, + snmpTlstmParamsTableLastChanged, + snmpTlstmParamsClientFingerprint, + snmpTlstmParamsStorageType, + snmpTlstmParamsRowStatus, + snmpTlstmAddrCount, + snmpTlstmAddrTableLastChanged, + snmpTlstmAddrServerFingerprint, + snmpTlstmAddrServerIdentity, + snmpTlstmAddrStorageType, + snmpTlstmAddrRowStatus + } + STATUS current + DESCRIPTION + "A collection of objects for maintaining + outgoing connection certificates to use when opening + connections as a result of SNMP-TARGET-MIB settings." + ::= { snmpTlstmGroups 3 } + +snmpTlstmNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + snmpTlstmServerCertificateUnknown, + snmpTlstmServerInvalidCertificate + } + STATUS current + DESCRIPTION + "Notifications" + ::= { snmpTlstmGroups 4 } + +END + + + + + + +Hardaker Standards Track [Page 53] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +8. Operational Considerations + + This section discusses various operational aspects of deploying + TLSTM. + +8.1. Sessions + + A session is discussed throughout this document as meaning a security + association between two TLSTM instances. State information for the + sessions are maintained in each TLSTM implementation and this + information is created and destroyed as sessions are opened and + 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., + reboot, power outage, etc.). Whenever possible, implementations + SHOULD provide graceful session termination through the use of TLS + disconnect messages. Implementations SHOULD also have a system in + place for detecting "broken" sessions through the use of heartbeats + [HEARTBEAT] or other detection mechanisms. + + Implementations SHOULD limit the lifetime of established sessions + depending on the algorithms used for generation of the master session + secret, the privacy and integrity algorithms used to protect + messages, the environment of the session, the amount of data + transferred, and the sensitivity of the data. + +8.2. Notification Receiver Credential Selection + + When an SNMP engine needs to establish an outgoing session for + notifications, the snmpTargetParamsTable includes an entry for the + snmpTargetParamsSecurityName of the target. Servers that wish to + support multiple principals at a particular port SHOULD make use of + the Server Name Indication extension defined in Section 3.1 of + [RFC4366]. Without the Server Name Indication the receiving SNMP + engine (server) will not know which (D)TLS certificate to offer to + the client so that the tmSecurityName identity-authentication will be + successful. + + Another solution is to maintain a one-to-one mapping between + certificates and incoming ports for notification receivers. This can + be handled at the notification originator by configuring the + snmpTargetAddrTable (snmpTargetAddrTDomain and + snmpTargetAddrTAddress) and requiring the receiving SNMP engine to + monitor multiple incoming static ports based on which principals are + capable of receiving notifications. + + Implementations MAY also choose to designate a single Notification + Receiver Principal to receive all incoming notifications or select an + + + + +Hardaker Standards Track [Page 54] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + implementation specific method of selecting a server certificate to + present to clients. + +8.3. contextEngineID Discovery + + SNMPv3 requires that an application know the identifier + (snmpEngineID) of the remote SNMP protocol engine in order to + retrieve or manipulate objects maintained on the remote SNMP entity. + + [RFC5343] introduces a well-known localEngineID and a discovery + mechanism that can be used to learn the snmpEngineID of a remote SNMP + protocol engine. Implementations are RECOMMENDED to support and use + the contextEngineID discovery mechanism defined in [RFC5343]. + +8.4. Transport Considerations + + This document defines how SNMP messages can be transmitted over the + TLS- and DTLS-based protocols. Each of these protocols is + additionally based on other transports (TCP and UDP). These two base + protocols also have operational considerations that must be taken + into consideration when selecting a (D)TLS-based protocol to use such + as its performance in degraded or limited networks. It is beyond the + scope of this document to summarize the characteristics of these + transport mechanisms. Please refer to the base protocol documents + for details on messaging considerations with respect to MTU size, + fragmentation, performance in lossy networks, etc. + +9. Security Considerations + + This document describes a transport model that permits SNMP to + utilize (D)TLS security services. The security threats and how the + (D)TLS transport model mitigates these threats are covered in detail + throughout this document. Security considerations for DTLS are + covered in [RFC4347] and security considerations for TLS are + described in Section 11 and Appendices D, E, and F of TLS 1.2 + [RFC5246]. When run over a connectionless transport such as UDP, + DTLS is more vulnerable to denial-of-service attacks from spoofed IP + addresses; see Section 4.2 for details how the cookie exchange is + used to address this issue. + +9.1. Certificates, Authentication, and Authorization + + Implementations are responsible for providing a security certificate + installation and configuration mechanism. Implementations SHOULD + support certificate revocation lists. + + (D)TLS provides for authentication of the identity of both the (D)TLS + server and the (D)TLS client. Access to MIB objects for the + + + +Hardaker Standards Track [Page 55] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + authenticated principal MUST be enforced by an access control + subsystem (e.g., the VACM). + + Authentication of the command generator principal's identity is + important for use with the SNMP access control subsystem to ensure + that only authorized principals have access to potentially sensitive + data. The authenticated identity of the command generator + principal's certificate is mapped to an SNMP model-independent + securityName for use with SNMP access control. + + The (D)TLS handshake only provides assurance that the certificate of + the authenticated identity has been signed by a configured accepted + Certification Authority. (D)TLS has no way to further authorize or + reject access based on the authenticated identity. An Access Control + Model (such as the VACM) provides access control and authorization of + a command generator's requests to a command responder and a + notification receiver's authorization to receive Notifications from a + notification originator. However, to avoid man-in-the-middle + attacks, both ends of the (D)TLS-based connection MUST check the + certificate presented by the other side against what was expected. + For example, command generators must check that the command responder + presented and authenticated itself with an X.509 certificate that was + expected. Not doing so would allow an impostor, at a minimum, to + present false data, receive sensitive information, and/or provide a + false belief that configuration was actually received and acted upon. + Authenticating and verifying the identity of the (D)TLS server and + the (D)TLS client for all operations ensures the authenticity of the + SNMP engine that provides MIB data. + + The instructions found in the DESCRIPTION clause of the + snmpTlstmCertToTSNTable object must be followed exactly. It is also + important that the rows of the table be searched in prioritized order + starting with the row containing the lowest numbered + snmpTlstmCertToTSNID value. + +9.2. (D)TLS Security Considerations + + This section discusses security considerations specific to the usage + of (D)TLS. + +9.2.1. TLS Version Requirements + + Implementations of TLS typically support multiple versions of the + Transport Layer Security protocol as well as the older Secure Sockets + Layer (SSL) protocol. Because of known security vulnerabilities, + TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0. + See Appendix E.2 of [RFC5246] for further details. + + + + +Hardaker Standards Track [Page 56] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +9.2.2. Perfect Forward Secrecy + + The use of Perfect Forward Secrecy is RECOMMENDED and can be provided + by (D)TLS with appropriately selected cipher_suites, as discussed in + Appendix F of [RFC5246]. + +9.3. Use with SNMPv1/SNMPv2c Messages + + The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP + 74) always selects the SNMPv1 or SNMPv2c Security Models, + respectively. Both of these and the User-based Security Model + typically used with SNMPv3 derive the securityName and securityLevel + from the SNMP message received, even when the message was received + over a secure transport. Access control decisions are therefore made + based on the contents of the SNMP message, rather than using the + authenticated identity and securityLevel provided by the TLS + 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.4. MIB Module Security + + 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 + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + o The snmpTlstmParamsTable can be used to change the outgoing X.509 + certificate used to establish a (D)TLS connection. Modifications + to objects in this table need to be adequately authenticated since + modifying the values in this table will have profound impacts to + the security of outbound connections from the device. Since + knowledge of authorization rules and certificate usage mechanisms + may be considered sensitive, protection from disclosure of the + SNMP traffic via encryption is also highly recommended. + + o The snmpTlstmAddrTable can be used to change the expectations of + the certificates presented by a remote (D)TLS server. + Modifications to objects in this table need to be adequately + authenticated since modifying the values in this table will have + + + +Hardaker Standards Track [Page 57] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + profound impacts to the security of outbound connections from the + device. Since knowledge of authorization rules and certificate + usage mechanisms may be considered sensitive, protection from + disclosure of the SNMP traffic via encryption is also highly + recommended. + + o The snmpTlstmCertToTSNTable is used to specify the mapping of + incoming X.509 certificates to tmSecurityNames, which eventually + get mapped to an SNMPv3 securityName. Modifications to objects in + this table need to be adequately authenticated since modifying the + values in this table will have profound impacts to the security of + incoming connections to the device. Since knowledge of + authorization rules and certificate usage mechanisms may be + considered sensitive, protection from disclosure of the SNMP + 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 + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + o This MIB contains a collection of counters that monitor the (D)TLS + connections being established with a device. Since knowledge of + connection and certificate usage mechanisms may be considered + sensitive, protection from disclosure of the SNMP traffic via + encryption is highly recommended. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example, by using IPsec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + It is RECOMMENDED that implementers consider the security features as + provided by the SNMPv3 framework (see [RFC3410], Section 8), + including full support for the SNMPv3 cryptographic mechanisms (for + authentication and privacy). + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + + + +Hardaker Standards Track [Page 58] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +10. IANA Considerations + + IANA has assigned: + + 1. Two TCP/UDP port numbers from the "Registered Ports" range of the + Port Numbers registry, with the following keywords: + + Keyword Decimal Description References + ------- ------- ----------- ---------- + snmptls 10161/tcp SNMP-TLS [RFC6353] + snmpdtls 10161/udp SNMP-DTLS [RFC6353] + snmptls-trap 10162/tcp SNMP-Trap-TLS [RFC6353] + snmpdtls-trap 10162/udp SNMP-Trap-DTLS [RFC6353] + + These are the default ports for receipt of SNMP command messages + (snmptls and snmpdtls) and SNMP notification messages (snmptls-trap + and snmpdtls-trap) over a TLS Transport Model as defined in this + document. + + 2. An SMI number (8) under snmpDomains for the snmpTLSTCPDomain + object identifier + + 3. An SMI number (9) under snmpDomains for the snmpDTLSUDPDomain + object identifier + + 4. An SMI number (198) under mib-2, for the MIB module in this + document + + 5. "tls" as the corresponding prefix for the snmpTLSTCPDomain in the + SNMP Transport Domains registry + + 6. "dtls" as the corresponding prefix for the snmpDTLSUDPDomain in + the SNMP Transport Domains registry + +11. Acknowledgements + + This document closely follows and copies the Secure Shell Transport + Model for SNMP documented by David Harrington and Joseph Salowey in + [RFC5592]. + + This document was reviewed by the following people who helped provide + useful comments (in alphabetical order): Andy Donati, Pasi Eronen, + David Harrington, Jeffrey Hutzelman, Alan Luchuk, Michael Peck, Tom + Petch, Randy Presuhn, Ray Purvis, Peter Saint-Andre, Joseph Salowey, + Juergen Schoenwaelder, Dave Shield, and Robert Story. + + + +Hardaker Standards Track [Page 59] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + This work was supported in part by the United States Department of + Defense. Large portions of this document are based on work by + General Dynamics C4 Systems and the following individuals: Brian + Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John + Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul, + Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip. + +12. References + +12.1. Normative References + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, October 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, + RFC 3411, December 2002. + + [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network + Management Protocol (SNMP) Applications", STD 62, + RFC 3413, December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based + Access Control Model (VACM) for the Simple Network + Management Protocol (SNMP)", STD 62, RFC 3415, + December 2002. + + + + + +Hardaker Standards Track [Page 60] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + [RFC3418] Presuhn, R., "Management Information Base (MIB) for the + Simple Network Management Protocol (SNMP)", STD 62, + RFC 3418, December 2002. + + [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, + "Coexistence between Version 1, Version 2, and Version 3 + of the Internet-standard Network Management Framework", + BCP 74, RFC 3584, August 2003. + + [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + 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 (TLS) Protocol Version 1.2", RFC 5246, + August 2008. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation + List (CRL) Profile", RFC 5280, May 2008. + + [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport + Subsystem for the Simple Network Management Protocol + (SNMP)", RFC 5590, June 2009. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security + Model for the Simple Network Management Protocol + (SNMP)", RFC 5591, June 2009. + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for + IPv6 Address Text Representation", RFC 5952, + August 2010. + +12.2. Informative References + + [HEARTBEAT] Seggelmann, R., Tuexen, M., and M. Williams, "Transport + Layer Security (TLS) and Datagram Transport Layer + Security (DTLS) Heartbeat Extension", Work in Progress, + July 2011. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + + + +Hardaker Standards Track [Page 61] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + [RFC5343] Schoenwaelder, J., "Simple Network Management Protocol + (SNMP) Context EngineID Discovery", RFC 5343, + 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. + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document + Framework", RFC 5890, August 2010. + + [RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol + (SNMP)", RFC 5953, August 2010. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hardaker Standards Track [Page 62] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +Appendix A. Target and Notification Configuration Example + + The following sections describe example configuration for the SNMP- + TLS-TM-MIB, the SNMP-TARGET-MIB, the NOTIFICATION-MIB, and the SNMP- + VIEW-BASED-ACM-MIB. + +A.1. Configuring a Notification Originator + + The following row adds the "Joe Cool" user to the "administrators" + group: + + vacmSecurityModel = 4 (TSM) + vacmSecurityName = "Joe Cool" + vacmGroupName = "administrators" + vacmSecurityToGroupStorageType = 3 (nonVolatile) + vacmSecurityToGroupStatus = 4 (createAndGo) + + The following row configures the snmpTlstmAddrTable to use + certificate path validation and to require the remote notification + receiver to present a certificate for the "server.example.org" + identity. + + snmpTargetAddrName = "toNRAddr" + snmpTlstmAddrServerFingerprint = "" + snmpTlstmAddrServerIdentity = "server.example.org" + snmpTlstmAddrStorageType = 3 (nonVolatile) + snmpTlstmAddrRowStatus = 4 (createAndGo) + + The following row configures the snmpTargetAddrTable to send + notifications using TLS/TCP to the snmptls-trap port at 192.0.2.1: + + snmpTargetAddrName = "toNRAddr" + snmpTargetAddrTDomain = snmpTLSTCPDomain + snmpTargetAddrTAddress = "192.0.2.1:10162" + snmpTargetAddrTimeout = 1500 + snmpTargetAddrRetryCount = 3 + snmpTargetAddrTagList = "toNRTag" + snmpTargetAddrParams = "toNR" (MUST match below) + snmpTargetAddrStorageType = 3 (nonVolatile) + snmpTargetAddrRowStatus = 4 (createAndGo) + + + + + + + + + + + +Hardaker Standards Track [Page 63] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The following row configures the snmpTargetParamsTable to send the + notifications to "Joe Cool", using authPriv SNMPv3 notifications + through the TransportSecurityModel [RFC5591]: + + snmpTargetParamsName = "toNR" (must match above) + snmpTargetParamsMPModel = 3 (SNMPv3) + snmpTargetParamsSecurityModel = 4 (TransportSecurityModel) + snmpTargetParamsSecurityName = "Joe Cool" + snmpTargetParamsSecurityLevel = 3 (authPriv) + snmpTargetParamsStorageType = 3 (nonVolatile) + snmpTargetParamsRowStatus = 4 (createAndGo) + +A.2. Configuring TLSTM to Utilize a Simple Derivation of tmSecurityName + + The following row configures the snmpTlstmCertToTSNTable to map a + validated client certificate, referenced by the client's public X.509 + hash fingerprint, to a tmSecurityName using the subjectAltName + component of the certificate. + + snmpTlstmCertToTSNID = 1 + (chosen by ordering preference) + snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint) + snmpTlstmCertToTSNMapType = snmpTlstmCertSANAny + snmpTlstmCertToTSNData = "" (not used) + snmpTlstmCertToTSNStorageType = 3 (nonVolatile) + snmpTlstmCertToTSNRowStatus = 4 (createAndGo) + + This type of configuration should only be used when the naming + conventions of the (possibly multiple) Certification Authorities are + well understood, so two different principals cannot inadvertently be + identified by the same derived tmSecurityName. + +A.3. Configuring TLSTM to Utilize Table-Driven Certificate Mapping + + The following row configures the snmpTlstmCertToTSNTable to map a + validated client certificate, referenced by the client's public X.509 + hash fingerprint, to the directly specified tmSecurityName of "Joe + Cool". + + snmpTlstmCertToTSNID = 2 + (chosen by ordering preference) + snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint) + snmpTlstmCertToTSNMapType = snmpTlstmCertSpecified + snmpTlstmCertToTSNSecurityName = "Joe Cool" + snmpTlstmCertToTSNStorageType = 3 (nonVolatile) + snmpTlstmCertToTSNRowStatus = 4 (createAndGo) + + + + + +Hardaker Standards Track [Page 64] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +Author's Address + + Wes Hardaker + SPARTA, Inc. + P.O. Box 382 + Davis, CA 95617 + USA + + Phone: +1 530 792 1913 + EMail: ietf@hardakers.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hardaker Standards Track [Page 65] + -- cgit v1.2.3