Transport Layer Security Version 1.3 (TLS 1.3)
Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3)
Trevilon LLC
6606 FM 1488 RD
Suite 148-503
Magnolia
TX
77354
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 support Transport Layer Security Version 1.3 (TLS) and Datagram Transport Layer Security Version 1.3
(DTLS), which are jointly known as
"(D)TLS". This document may be applicable to 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 Version
1.3 (TLS) or Datagram Transport Layer Security Version 1.3 (DTLS), which are jointly known
as "(D)TLS".
The update also incorporates the update, which prohibits the use of TLS versions prior to TLS 1.2.
Although the title and text of this document specifically reference 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", "(D)TLS", “SNMP”, and “TLSTM” mean “TLS
1.3”, “DTLS 1.3”, “TLS 1.3 and/or DTLS 1.3”, “SMNPv3”, and “TLSTM 1.3”, respectively.
These version numbers are only used when the text needs to emphasize version numbers, such
as within the title. When this document refers to any other version of these protocols, it
always explicitly states the version intended.
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 SNMPv3 terminology be modified to match the usage of other non-SNMP
specifications when SNMPv3 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.
While TLS frequently refers to a user, the terminology preferred in and in this memo is "principal". A principal is the
"who" on whose behalf services are provided or processing takes place. A principal can be,
among other things, an individual acting in a particular role; a set of individuals, with
each acting in a particular role; an application or a set of applications, or a
combination of these within an administrative domain.
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 .
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 1.3 cipher
suite still includes a hashing algorithm but new hashing algorithms (e.g., for use in TLS 1.3)
will not be assigned values in the IANA TLS HashAlgorithm Registry, as defined in RFC 5246.
This document updates the definition of SnmpTLSFingerprint to clarify that the one-octet
identifier in the fingerprint algorithm uses a registry that is consistent with the IANA TLS HashAlgorithm
Registry for its initial values but one that can be extended to support new hashing algorithms that
might be used for TLS versions after version 1.2. This change allows the reuse of the existing
fingerprint TEXTUAL-CONVENTION and minimizes the impact to RFC 6353.
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. This is consistent with what was
prescribed in RFC6353, where a TLS Transport Model is expected to provide for outgoing
connections with a security level at least that of the requested security level.
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.
Zero Round Trip Time Resumption (0-RTT)
TLS 1.3 implementations for SNMPv3 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” SNMPv3 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 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
This document requires the establishment of a new TLSTM HashAlgorithm Table, which is
referenced in the above MIB as being located at "http://www.iana.org/assignments/tlstm-parameters/".
The initial
values for this table MUST be identical to the contents of the TLS HashAlgorithm Registry
(RFC 5246).
Acknowledgements
Acknowledgements This document is based on . This document was reviewed by the
following people who helped provide useful comments: Michaela Vanderveen, Joe Clarke, Jürgen Schönwälder, and Tom Petch
References
Normative References
Informative References
Target and Notification Configuration Example
The following sections describe example configuration for the SNMP- TLS-TM-MIB, the
SNMP-TARGET-MIB, the NOTIFICATION-MIB, and the SNMP- VIEW-BASED-ACM-MIB.
Configuring a Notification Originator
The following row adds the "Joe Cool" user to the "administrators" group:
The following row configures the snmpTlstmAddr13Table to use certificate path validation
and to require the remote notification receiver to present a certificate for the
"server.example.org" identity.
The following row configures the snmpTargetAddrTable to send notifications using TLS/TCP
to the snmptls-trap port at 192.0.2.1:
The following row configures the snmpTargetParamsTable to send the notifications to "Joe
Cool", using authPriv SNMPv3 notifications through the TransportSecurityModel []:
Configuring TLSTM to Utilize a Simple Derivation of tmSecurityName
The following row configures the snmpTlstmCertToTSN13Table to map a validated client
certificate, referenced by the client's public X.509 hash fingerprint, to a tmSecurityName
using the subjectAltName component of the certificate.
This type of configuration should only be used when the naming conventions of the
(possibly multiple) Certification Authorities are well understood, so two different
principals cannot inadvertently be identified by the same derived tmSecurityName.
Configuring TLSTM to Utilize Table-Driven Certificate Mapping
The following row configures the snmpTlstmCertToTSN13Table to map a validated client
certificate, referenced by the client's public X.509 hash fingerprint, to the directly
specified tmSecurityName of "Joe Cool".