Transport Layer Security Verion 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
Security
Internet Engineering Task Force
This document updates the TLS Transport Model (TLSTM), as defined in , 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 .
Introduction
This document updates the fingerprint algorithm defined by to support the ciphersuites used by Transport Layer Security Version
1.3 (TLS) and Datagram Transport Layer Security Version 1.3 (DTLS), which are jointly known
as "(D)TLS". The update also incorporates other less critical updates. 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.
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 User-Based Security Model (USM) is a
mandatory-to- implement Security Model in . The USM
derives the securityName and securityLevel from the SNMP message received, even when the
message was received over a secure transport. It is RECOMMENDED that
deployments that support the TLSTM disable the USM, if it has been implemented.
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 thereby breaking the
algorithm defined in . The update to the
SNMP-TLS-TM-MIB, as defined in , deprecates the
original fingerprint TEXTUAL-CONVENTION and replaces it with a new TEXTUAL-CONVENTION.
The change also required an update to several objects within the tables defined within
the SNMP-TLS-TM-MIB; further these objects are referernced by other (e.g., RowStatus)
objects in a manner that requires deprecating and replacing the tables in their entirety.
Thus, while the number of objects deprecated and replaced is significant the semantics of
the changes are minor.
References to the older objects within are
applicable to the replacement objects. The newer objects are identified with names similar
to those used in the original MIB but with a "13" inserted to reference TLS 1.3.
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. This document extends this statement such that TLSTM
clients and servers MUST NOT request, offer, or use SSL 3.0, (D)TLSv 1.0,
(D)TLS v1.1. See Appendix D.5 of for further details. For backward compatibility
issues with older TLS versions, see Appendix D of .
An implementation that supports these older protocols is not considered conformant to the
TLSTM while the older protocols are enabled.
SNMP Version
stated that using a non-transport-aware
Security Model with a secure Transport Model was not recommended. This document tightens
this statement such that TLSTM clients and servers MUST NOT request, offer,
or use SNMPv1 or SNMPv2c message processing described in , or the User-based Security Model of SNMPv3.
An implementation that supports these older protocols is not considered conformant to the
TLSTM while the older protocols are enabled.
Common Name
stated that the use of a certificate's
CommonName is deprecated and users were encouraged to use the subjectAltName. This
document tightens this statement such that TLSTM clients and servers MUST
NOT use the CommonName.
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 .
MIB Module Security
There are a number of management objects defined in this MIB module with a MAX-ACCESS
clause of read-write and/or read-create. Such objects might be considered sensitive or
vulnerable in some network environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on network operations.
These are the tables and objects and their sensitivity/vulnerability:
- The snmpTlstmParams13Table can be used to change the outgoing X.509 certificate used
to establish a TLS connection. Modifications to objects in this table need to be
adequately authenticated since modifying the values in this table will have profound
impacts to the security of outbound connections from the device. Since knowledge of
authorization rules and certificate usage mechanisms might be considered sensitive,
protection from disclosure of the SNMP traffic via encryption is automatically acheived
via TLS 1.3.
- The snmpTlstmAddr13Table can be used to change the expectations of the certificates
presented by a remote TLS server. Modifications to objects in this table need to be
adequately authenticated since modifying the values in this table will have profound
impacts to the security of outbound connections from the device. Since knowledge of
authorization rules and certificate usage mechanisms might be considered sensitive,
protection from disclosure of the SNMP traffic via encryption is automatically acheived
via TLS 1.3.
- The snmpTlstmCertToTSN13Table is used to specify the mapping of incoming X.509
certificates to tmSecurityNames, which eventually get mapped to an SNMPv3 securityName.
Modifications to objects in this table need to be adequately authenticated since
modifying the values in this table will have profound impacts to the security of
incoming connections to the device. Since knowledge of authorization rules and
certificate usage mechanisms might be considered sensitive, protection from disclosure
of the SNMP traffic via encryption is automatically acheived via TLS 1.3. When this
table contains a significant number of rows it might affect the system performance when
accepting new TLS connections.
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other
than not-accessible) might be considered sensitive or vulnerable in some network
environments. It is thus important to control even GET and/or NOTIFY access to these
objects and encrypt the values of these objects when sending them over the network via
SNMP. These are the tables and objects and their sensitivity/vulnerability:
- This MIB contains a collection of counters that monitor the TLS connections being
established with a device. Since knowledge of connection and certificate usage
mechanisms might be considered sensitive, protection from disclosure of the SNMP traffic
via encryption is automatically acheived via 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.
As defined in , TLSTM clients and servers
MUST NOT request, offer, or use SNMPv1 or SNMPv2c message processing
described in , or the User-based Security Model
of SNMPv3. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable
cryptographic security. It is then a customer/operator responsibility to ensure that the
SNMP entity giving access to an instance of this MIB module is properly configured to give
access to the objects only to those principals (users) that have legitimate rights to
indeed GET or SET (change/create/delete) them.
IANA Considerations
This document has no IANA actions beyond those performed as a part of .
Acknowledgements
Acknowledgements This document is based on . This document was reviewed by the
following people who helped provide useful comments: Michaela Vanderveen.
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".