Updates to the TLS Transport Model for SNMP
updates
- rfc-6353 — Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)
Extracted elements (27)
0-RTT is disallowed for SNMP because there are no 'safe' SNMP messages that, if replayed, will be guaranteed to cause no harm at the server side: all incoming notifications or command responses are meant to be acted upon only once. RFC 8446 requires that a profile be written specifying which messages are 'safe to use' with 0-RTT, and within SNMP, no messages qualify.
A new 'SNMP-TLSTM HashAlgorithms' registry was created rather than reusing the 'TLS HashAlgorithm' registry because the TLS community does not plan to add new values to the TLS HashAlgorithm registry (to avoid incorrectly implying a new hash algorithm overcomes TLS 1.2 limitations), but TLSTM still needs to support new hash algorithm values as they are developed.
This document is compatible with (D)TLS 1.2 and is intended to be compatible with future versions of SNMP and (D)TLS. The updated SnmpTLSFingerprint textual convention reuses the existing RFC 6353 structure but references the new SNMP-TLSTM HashAlgorithms registry instead of the now-frozen TLS HashAlgorithm registry.
Using an IPv6 address for snmpTlstmCertSANIpAddress mapping while snmpTsmConfigurationUsePrefix is 'true' will result in securityName lengths that exceed what the View-based Access Control Model (VACM) can handle (VACM imposes a 32-octet maximum).
All compliance requirements from RFC 8446 Section 9 apply to SNMP TLSTM implementations because this document does not specify a TLS application profile; therefore mandatory cipher suites, extensions, and protocol invariants defined there are required.
If no matching and valid row can be found in the snmpTlstmCertToTSNTable, the connection MUST be closed and SNMP messages MUST NOT be accepted over it.
If the fingerprint in snmpTlstmAddrServerFingerprint does not match the server's presented certificate, the connection MUST be closed.
Implementations MUST support matching the expected host name against a dNSName in the subjectAltName extension and MUST support wildcards limited to the leftmost DNS label (e.g., *.example.com matches a.example.com but not example.com or a.b.example.com).
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.
Rows in snmpTlstmAddrTable MUST NOT be active if the snmpTlstmAddrServerFingerprint column is blank and snmpTlstmAddrServerIdentity is set to '*', since this would insecurely accept any presented certificate.
TLS 1.3 implementations for SNMP MUST NOT enable the 0-RTT mode of session resumption (either sending or accepting) and MUST NOT automatically resend 0-RTT data if it is rejected by the server.
TLSTM clients and servers MUST NOT request, offer, or use the 0-RTT mode of TLS 1.3.
TLSTM MUST only be used with (D)TLS versions 1.2 and later. RFC 8996 prohibits the use of (D)TLS versions prior to version 1.2.
To avoid notification loops, snmpTlstmServerCertificateUnknown and snmpTlstmServerInvalidCertificate notifications MUST NOT be sent to servers that themselves have triggered the notification.
Values 0 through 2 (none, md5, sha1) in the SNMP-TLSTM HashAlgorithms registry MUST NOT be used by implementations of this document but are listed for historical consistency.
Certificate-to-tmSecurityName mapping types defined in snmpTlstmCertToTSNMIdentities include: snmpTlstmCertSpecified (explicit value in data column), snmpTlstmCertSANRFC822Name (email SAN with lowercase domain), snmpTlstmCertSANDNSName (DNS SAN lowercased), snmpTlstmCertSANIpAddress (IP SAN as dotted quad or 32-char hex), snmpTlstmCertSANAny (first matching SAN), and snmpTlstmCertCommonName (deprecated CommonName).
SnmpTLSAddress is a textual convention (OCTET STRING SIZE 1..255) representing an IPv4 dotted-decimal address, an RFC 5952 IPv6 address in square brackets, or an ASCII hostname, each followed by a colon and decimal port number. Internationalized hostnames MUST be encoded as A-labels per RFC 5890.
SnmpTLSFingerprint is a textual convention composed of a one-octet hashing algorithm identifier (taken from the IANA 'SNMP-TLSTM HashAlgorithms' registry) followed by the fingerprint value. It is an OCTET STRING of SIZE 0..255, where zero-length is allowed for optional use in tables.
snmpTLSTCPDomain (snmpDomains 8) represents SNMP over TLS via TCP, with securityName prefix 'tls'. snmpDTLSUDPDomain (snmpDomains 9) represents SNMP over DTLS via UDP, with securityName prefix 'dtls'.
The SNMP-TLS-TM-MIB defines ten session statistics counters: snmpTlstmSessionOpens, snmpTlstmSessionClientCloses, snmpTlstmSessionOpenErrors, snmpTlstmSessionAccepts, snmpTlstmSessionServerCloses, snmpTlstmSessionNoSessions, snmpTlstmSessionInvalidClientCertificates, snmpTlstmSessionUnknownServerCertificate, snmpTlstmSessionInvalidServerCertificates, and snmpTlstmSessionInvalidCaches, all as Counter32.
The snmpTlstmAddrTable extends SNMP-TARGET-MIB's snmpTargetAddrTable with snmpTlstmAddrServerFingerprint and snmpTlstmAddrServerIdentity, used by a (D)TLS client to verify the correct server has been reached via fingerprint matching or hostname validation.
The snmpTlstmCertToTSNTable maps incoming (D)TLS client X.509 certificates to tmSecurityNames. Rows are evaluated in prioritized order by snmpTlstmCertToTSNID (lower = higher priority); a row matches if its fingerprint identifies the presented certificate or a trusted CA in the validation path.
The snmpTlstmParamsTable extends SNMP-TARGET-MIB's snmpTargetParamsTable with snmpTlstmParamsClientFingerprint, storing the hash of a locally held X.509 certificate used when initiating (D)TLS connections as a client.
IANA created a new registry 'SNMP-TLSTM HashAlgorithms' within the SMI Numbers group (OID 1.3.6.1.2.1.198.4). It has fields: Value (0-255), Description, Recommended, and References. Policy is Expert Review. Initial values mirror the TLS HashAlgorithm registry (none=0, md5=1, sha1=2, sha224=3, sha256=4, sha384=5, sha512=6, Reserved=7, Intrinsic=8).
0-RTT mode is prohibited because replay attacks against SNMP are particularly harmful: all incoming notifications and command responses are meant to be acted upon only once, and no SNMP messages qualify as 'safe to replay' under RFC 8446's application-profile requirement.
Implementations should consider the latest recommendations on the use of (D)TLS such as those documented in RFC 9325. Security considerations for TLS 1.3 are in RFC 8446 Section 10 and Appendix E; for DTLS 1.3 in RFC 9147 Section 11.
SNMP versions prior to SNMPv3 did not include adequate security. Even on a secured network (e.g., using IPsec), there is no access control over who can GET/SET objects in this MIB module. Only SNMPv3 with TSM or another secure-transport-aware security model should be used over TLSTM.