Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)
obsoletes
- rfc-5953 — Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)
updated by
also
- std-78
Extracted elements (30)
The (D)TLS internal SessionID is not used as the tlstmSessionID because it can change during renegotiation and does not necessarily uniquely identify a TLSTM session — multiple TLSTM sessions can share the same D(TLS) internal SessionID. A stable, unique TLSTM-level identifier is therefore required.
The subjectAltName certificate field is the preferred source for deriving tmSecurityNames; the CommonName mapping (snmpTlstmCertCommonName) is deprecated. Deployments SHOULD use subjectAltName because it provides structured, unambiguous identity information compared to the free-form CommonName field.
VACM constrains securityName to 32 octets. A TLSTM tmSecurityName derived from an IPv6 address (32 hex chars) combined with the TSM transport prefix yields a 36-octet securityName that exceeds VACM's limit. Operators must select algorithms and subjectAltNames carefully to avoid this incompatibility.
A TLS Transport Model implementation MUST support message encryption to protect sensitive data from eavesdropping. 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. Trusted public keys from CA certificates and/or self-signed certificates MUST be installed through a trusted out-of-band mechanism and their authenticity MUST be verified before access is granted.
(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, though 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, though implementations are not required to perform it for every handshake.
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. Session establishment MUST fail if certificate verification fails in any way.
The (D)TLS server MUST request and expect a certificate from the client and MUST NOT accept SNMP messages until the client certificate has been authenticated. If any verification fails, session establishment MUST fail and snmpTlstmSessionInvalidClientCertificates is incremented.
The tlstmSessionID MUST NOT change during the entire duration of the session and MUST uniquely identify a single session. A session identifier MUST NOT be reused until all references to it are no longer in use.
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.
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 that the peer also presented the same certificate.
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 DTLS/UDP connections, implementations MUST use a different UDP source port number for each active connection to a remote destination IP-address/port-number combination so the remote entity can disambiguate between multiple connections.
The snmpTLSTCPDomain (snmpDomains 8) and snmpDTLSUDPDomain (snmpDomains 9) are transport domain OIDs for SNMP over TLS/TCP and DTLS/UDP respectively. Their associated securityName prefixes are 'tls' and 'dtls', used by security models to identify which secure transport authenticated a principal.
The snmpTlstmCertToTSNTable maps incoming (D)TLS client certificates to SNMPv3 tmSecurityNames via defined transformations: directly specifying a tmSecurityName from a certificate fingerprint, or deriving it from subjectAltName fields (rfc822Name, dNSName, iPAddress) or CommonName.
The snmpTlstmParamsTable extends SNMP-TARGET-MIB's snmpTargetParamsTable to specify a (D)TLS client-side certificate fingerprint (snmpTlstmParamsClientFingerprint) to use when initiating outgoing connections.
The TLSTM session is uniquely identified by a tlstmSessionID. For DTLS/UDP, sessions are further uniquely identified by the combination of transportDomain, transportAddress, tmSecurityName, and requestedSecurityLevel. TLS/TCP sessions rely on TCP framing but still require a unique tlstmSessionID.
The tmStateReference cache holds per-session state including tmTransportDomain, tmTransportAddress, tmSecurityLevel, tmSecurityName, and tmSessionID. It is used to translate between (D)TLS-specific security parameters and SNMP model-independent parameters passed between the Transport Subsystem and security models.
The SNMP-TLS-TM-MIB module is registered at mib-2 198. It defines statistical counters, configuration tables (snmpTlstmParamsTable, snmpTlstmAddrTable, snmpTlstmCertToTSNTable), notifications (snmpTlstmServerCertificateUnknown, snmpTlstmServerInvalidCertificate), and transport domain OIDs snmpTLSTCPDomain and snmpDTLSUDPDomain.
Implementations MUST support TLS 1.1 as a minimum; TLS 1.2 (RFC 5246) is RECOMMENDED. Implementations SHOULD support cipher suites providing perfect forward secrecy (PFS) to limit damage from long-term key compromise. Configuration settings for mapping algorithms to SNMPv3 security levels SHOULD be offered.
SNMP entities SHOULD be provisioned with an X.509 certificate revocation mechanism to verify that certificates have not been revoked. Certificate path validation must be performed before granting access, and the snmpTlstmCertToTSNTable must have a matching row or session establishment must fail.
The snmpTlstmCertToTSNTable and snmpTlstmParamsTable contain sensitive configuration that controls which principals can access what SNMP operations. Unauthorized write access to these tables could enable session hijacking; implementations MUST apply strict access controls to these MIB objects.
Using TLSTM to carry SNMPv1 or SNMPv2c messages provides transport-level security, but those message formats include community strings in cleartext within the SNMP PDU. This is a known weakness and operators should be aware that TLSTM does not compensate for weaknesses inherent in older SNMP message formats.
Client session establishment: increment snmpTlstmSessionOpens → select certificate and cipher_suite → initiate (D)TLS handshake → verify server certificate → assign tlstmSessionID. Unknown/invalid server certificate triggers snmpTlstmSessionUnknownServerCertificate or snmpTlstmSessionInvalidServerCertificates increment and a corresponding notification.
Server session acceptance: receive client certificate → perform path validation or fingerprint lookup in snmpTlstmCertToTSNTable → derive tmSecurityName → increment snmpTlstmSessionAccepts. Failure in any verification step increments snmpTlstmSessionInvalidClientCertificates and snmpTlstmSessionOpenErrors, and the session MUST be rejected.
SnmpTLSAddress is an OCTET STRING (SIZE 1..255) encoding an IPv4 address in dotted-decimal:port format, an IPv6 address in [RFC 5952 colon-separated]:port format within square brackets, or a US-ASCII hostname:port. Internationalized hostnames are A-labels per RFC 5890.
SnmpTLSFingerprint is an OCTET STRING (SIZE 0..255) composed of a 1-octet hashing algorithm identifier taken from the IANA TLS HashAlgorithm Registry (RFC 5246) followed by the fingerprint value. A zero-length value is permitted for optional use in tables.