Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)
obsoleted by
- rfc-6353 — Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (31)
DTLS was included alongside TLS to serve environments where connectionless UDP transport is preferred (e.g., where existing SNMP infrastructure uses UDP). TLS/TCP is better suited for large data transfers due to TCP's support for larger packet sizes.
The TLSTM defines its own tlstmSessionID rather than reusing the (D)TLS internal SessionID because the (D)TLS internal ID can change during renegotiation and may be shared across multiple TLSTM sessions, making it unsuitable as a stable, unique TLSTM session reference.
The use of CommonName for tmSecurityName mapping (snmpTlstmCertCommonName) is deprecated in favor of subjectAltName mappings. This follows RFC 5280's preference for subjectAltName and avoids ambiguity inherent in CommonName fields.
Servers supporting multiple principals at a single port SHOULD use the TLS Server Name Indication extension (RFC 4366 Section 3.1) to allow server-side principal selection, enabling notifications to a specific principal at a given TCP or UDP port.
The standard VACM access control model constrains securityNames to 32 octets or less. A tmSecurityName derived from an IPv6 subjectAltName iPAddress (32 hex chars) combined with a TSM transport prefix produces a 36-octet securityName that cannot be used with standard VACM or TARGET MIB modules.
A TLS Transport Model implementation MUST support message encryption. The NULL integrity and encryption algorithms MUST NOT be used to fulfill security level requests for authentication or privacy.
A TLS Transport Model implementation MUST support the authentication of both the server and the client using X.509 certificates. TLSTM implementations are REQUIRED to support X.509 certificates; other forms of authentication are outside the scope of this specification.
(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 (RFC 5246).
For DTLS over UDP, each SNMP message MUST be placed in a single UDP datagram (it MAY be split into multiple DTLS records). The TLSTM implementation SHOULD return an error if the SNMP message does not fit in the UDP datagram.
For DTLS over UDP, the DTLS server implementation MUST support DTLS cookies; enabling the cookie exchange by default is RECOMMENDED. For DTLS, replay protection MUST be used.
The (D)TLS client MUST verify the server's presented certificate and 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.
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. Any verification failure MUST cause session establishment to fail.
The tlstmSessionID MUST NOT change during the entire duration of the session and MUST uniquely identify a single session. The (D)TLS internal SessionID does not meet these requirements, as it can change during renegotiation.
The tmSecurityName MUST be a human-readable name in snmpAdminString format and MUST be constant for all traffic passing through a single TLSTM session. Messages MUST NOT be sent through an existing (D)TLS connection established using a different tmSecurityName.
TLS renegotiation with different certificates MUST NOT be done. Implementations MUST either disable renegotiation completely (RECOMMENDED) or present the same certificate during renegotiation and verify the peer also presented the same certificate.
Trusted public keys from CA certificates and/or self-signed certificates MUST be installed into the server through a trusted out-of-band mechanism and their authenticity MUST be verified before access is granted.
When closing a session, (D)TLS MUST send a close_notify TLS Alert to inform the other side that session cleanup may be performed.
When establishing a new DTLS 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.
SnmpTLSFingerprint is a textual convention composed of a 1-octet hashing algorithm identifier (from the IANA TLS HashAlgorithm Registry per RFC 5246) followed by the fingerprint value. A zero-length value is permitted for use in optional-fingerprint contexts.
The snmpTlstmCertToTSNTable maps incoming (D)TLS client certificates to tmSecurityNames via defined transformations: mapping subjectAltName (rfc822Name, dNSName, iPAddress) or CommonName to a tmSecurityName, or mapping a certificate fingerprint to a directly specified tmSecurityName.
tlstmSessionID is a locally chosen unique session identifier stored in the LCD and tmStateReference. For DTLS/UDP, it is indexed by the combination of transportDomain, transportAddress, tmSecurityName, and requestedSecurityLevel. It must not reuse identifiers while still referenced.
tmSecurityName is a per-session cached value derived from the peer's X.509 certificate using the snmpTlstmCertToTSNTable. On the server side it is derived from the client certificate; on the client side it is provided by the security model via tmStateReference.
The SNMP-TLS-TM-MIB defines six certificate-to-tmSecurityName mapping algorithm identities under snmpTlstmCertToTSNMIdentities: snmpTlstmCertSpecified, snmpTlstmCertSANRFC822Name, snmpTlstmCertSANDNSName, snmpTlstmCertSANIpAddress, snmpTlstmCertSANAny, and snmpTlstmCertCommonName.
The SNMP-TLS-TM-MIB is assigned OID mib-2 198. It defines snmpTLSTCPDomain (snmpDomains 8) for SNMP over TLS/TCP and snmpDTLSUDPDomain (snmpDomains 9) for SNMP over DTLS/UDP as new transport domain object identities.
Access to writable MIB objects in the SNMP-TLS-TM-MIB (e.g., snmpTlstmCertToTSNTable, snmpTlstmAddrTable, snmpTlstmParamsTable) must be carefully controlled, as misconfiguration can allow unauthorized principals to be authenticated or valid sessions to be rejected.
Implementations MUST use TLS version 1.0 or higher (section 9.2.1 references RFC 5246 TLS 1.2 as the specification). The NULL integrity and encryption algorithms MUST NOT be used; cipher suites providing both authentication and privacy are recommended to satisfy all security level requests.
Perfect Forward Secrecy (PFS): implementations SHOULD use cipher suites that provide PFS (e.g., DHE or ECDHE key exchange) so that compromise of long-term keys does not compromise past session traffic.
Use of TLSTM with SNMPv1 or SNMPv2c messages is strongly discouraged; those message formats lack per-message security and community strings are sent in cleartext, undermining the security provided by the TLS transport layer.
Session close: (1) increment snmpTlstmSessionClientCloses or snmpTlstmSessionServerCloses, (2) look up session by tmSessionID, (3) if no open session, stop, (4) have (D)TLS close the connection including sending close_notify.
Session establishment as client: (1) increment snmpTlstmSessionOpens, (2) select certificate and cipher_suites, (3) initiate (D)TLS handshake, (4) verify server certificate, (5) fail and increment snmpTlstmSessionInvalidServerCertificates on any verification failure, (6) set tlstmSessionID on success.
SnmpTLSAddress is an OCTET STRING (SIZE 1..255) encoding an IPv4 dotted-decimal address, an IPv6 colon-separated address in square brackets, or a US-ASCII hostname, each followed by a colon and a decimal port number. Internationalized hostnames are encoded via the ToASCII operation with UseSTD3ASCIIRules.