Updates to the TLS Transport Model for SNMP

Introduction This document updates and clarifies how the rules of apply when using Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) versions later than 1.2. This document jointly refers to these two protocols as "(D)TLS". The update also incorporates the update, which prohibits the use of TLS versions prior to TLS 1.2. Although the text of this document specifically references SNMPv3 and (D)TLS 1.3, this document may be applicable to future versions of these protocols and is backwards compatible with (D)TLS 1.2.

Conventions Within this document the terms "TLS", "DTLS", and "(D)TLS" apply to all versions of the indicated protocols. The term "SNMP" means "SMNPv3" unless a specific version number is indicated. Specific version numbers are used when the text needs to emphasize version numbers. For consistency with SNMP-related specifications, this document favors terminology as defined in , rather than favoring terminology that is consistent with non-SNMP specifications. This is consistent with the IESG decision to not require the SNMP terminology be modified to match the usage of other non-SNMP specifications when SNMP 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 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 necessary, the application names of command generator, command responder, notification originator, notification receiver, and proxy forwarder are used. See "SNMP Applications" for further information. Throughout this document, the terms "client" and "server" are used to refer to the two ends of the TLS transport connection. The client actively opens the TLS connection, and the server passively listens for the incoming TLS connection. An SNMP entity MAY act as a TLS client or server or both, depending on the SNMP applications supported. Throughout this document, the term "session" is used to refer to a secure association between two instances of the TLS Transport Model (TLSTM) that permits the transmission of one or more SNMP messages within the lifetime of the session. The TLS protocol also has 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 TLS protocol's session. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Changes from RFC 6353 This document updates . The changes from are defined in the following clauses.

TLSTM Fingerprint defines a fingerprint algorithm that references the one-octet TLS 1.2 hash algorithm identifier. TLS 1.3 replaced the one-octet hash algorithm identifier with a two-octet TLS 1.3 cipher suite identifier. The TLS community does not plan to ever add additional values to the TLS 1.2 hash algorithm registry because some might incorrectly infer that using a new hash algorithm with TLS 1.2 would overcome the limitations of TLS 1.2. However, there is still a need within TLSTM to support new values as they are developed. This document updates the definition of SnmpTLSFingerprint to clarify that the one-octet identifier in the fingerprint algorithm uses the IANA SNMP-TLSTM HashAlgorithm Registry; this registry is consistent with the IANA TLS HashAlgorithm Registry for its initial values but can be extended as needed to support new hashing algorithms without implying that the new values can be used by TLS version 1.2. This change allows the reuse of the existing fingerprint TEXTUAL-CONVENTION and minimizes the impact to . The initial values for the SNMP-TLSTM HashAlgorithm Registry are defined below: SNMP-TLSTM Hash Algorithms

Value	Description	Recommended	Reference
0	none	N	[RFC5246]
1	md5	N	[RFC5246]
2	sha1	N	[RFC5246]
3	sha224	Y	[RFC5246]
4	sha256	Y	[RFC5246]
5	sha384	Y	[RFC5246]
6	sha512	Y	[RFC5246]
7	reserved		[RFC8447]
8	intrinsic	N	[RFC8422]
9-223	reserved		[RFC8447]
224-255	private		[RFC5246]

Values 0 through 2 MUST NOT be used by implementations of this document but are listed for historical consistency.

Security Level The architecture recognizes three levels of security:

without authentication and without privacy (noAuthNoPriv)
with authentication but without privacy (authNoPriv)
with authentication and with privacy (authPriv)

With (D)TLS 1.3, authentication and privacy are always provided. Hence, all exchanges conforming to the rules of this document will include authentication and privacy, regardless of the security level requested.

TLS Version states that TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0. prohibits the use of (D)TLS versions prior to version 1.2. TLSTM MUST only be used with (D)TLS version 1.2 and later.

Additional Rules for TLS 1.3 This document specifies additional rules and clarifications for the use of TLS 1.3. These rules may additionally apply to future versions of TLS.

Zero Round Trip Time Resumption (0-RTT) 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. The reason 0-RTT is disallowed is that there are no "safe" messages that if replayed will be guaranteed to cause no harm at a server side: all incoming notification or command responses are meant to be acted upon only once. See Security considerations section for further details. TLS TM clients and servers MUST NOT request, offer, or use the 0-RTT mode of TLS 1.3. removed the renegotiation supported in TLS 1.2 ; for session resumption, it introduced a zero-RTT (0-RTT) mode, saving a round-trip at connection setup at the cost of increased risk of replay attacks (it is possible for servers to guard against this attack by keeping track of all the messages received). requires a profile be written for any application that wants to use 0-RTT, specifying which messages are "safe to use" on this mode. The reason 0-RTT is disallowed here is that there are no "safe" SNMP messages that if replayed will be sure to cause no harm at a server side: all incoming notification or command responses have consequences and are to be acted upon only once. Renegotiation of sessions is not supported as it is not supported by TLS 1.3.

TLS cipher suites, extensions and protocol invariants section 9 requires that, in the absence of application profiles, certain cipher suites, TLS extensions, and TLS protocol invariants are mandatory to implement. This document does not specify an application profile, hence all the compliance requirements in apply.

MIB Module Definition This module makes references to , , , , , , , , , , , , and

Security Considerations This document updates a transport model that permits SNMP to utilize (D)TLS security services. The security threats and how the TLS transport model mitigates these threats are covered throughout this document and in . Security considerations for TLS are described in Section 10 and Appendix E of TLS 1.3 . Security considerations for DTLS are described in Section 11 of DTLS 1.3 . SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPsec), 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 only SNMPv3 messages using the Transport Security Model (TSM) or another secure-transport aware security model be sent over the TLSTM transport.

IANA Considerations IANA is asked to create a new registry called the SNMP-TLSTM HashAlgorithm Registry in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) Group and to update the proposed URL reference in the above MIB (listed as "https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml" under SnmpTLSFingerprint), if needed, to accurately reflect its location. The registry should have the following fields: value, description, recommended, and reference. The range of values is zero to 255, with initial assignments shown in Section 2.1. The "recommended" column indicates "Y" for hashing algorithms that are deemed to be acceptable for current use and "N" for hashing algorithms that reflect historical meanings that are not recommended (e.g., because they do not provide sufficient security for modern systems). A blank field indicates that no recommendation is made (e.g., because the value is reserved or left for private use). The policy for updates is Expert Review. The expert should consult the Security Area, e.g. via the mailing list of the TLS WG (the initial values of this registry are taken from an existing TLS Registry so the TLS WG would seem the best fit for this). While future additions to the IANA TLS HashAlgorithm Registry are not expected, any future addition to the IANA TLS HashAlgorithm Registry MUST be consistent with the values assigned in the IANA SNMP-TLSTM HashAlgorithm Registry.

Acknowledgements This document is based on . This document was reviewed by the following people who helped provide useful comments: Michaela Vanderveen, Joe Clarke, Jurgen Schonwalder, and Tom Petch.