Updates to the TLS
Transport Model for SNMP
Trevilon LLC
1060 Highway 107 South
Del Rio
TN
37727
US
+1 571 331 5670
kvaughn@trevilon.com
Operations and management
Internet Engineering Task Force
This document updates the TLS Transport Model (TLSTM), as defined in RFC 6353,
to reflect changes necessary to support Transport Layer Security Version 1.3
(TLS 1.3) and Datagram Transport Layer Security Version 1.3 (DTLS 1.3), which are jointly
known as "(D)TLS 1.3". This document is compatible with (D)TLS 1.2 and is
intended to be compatible with future versions of SNMP and (D)TLS.
This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353.
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 TLS Transport Models 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 BCP14 when, and only when, they
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 zero 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
stated 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. TLSTMv1.3 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 ciphersuites, 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 of the compliance requirements in apply.
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 .
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 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
References
Normative References
Informative References