Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3thorsten.dahm@gmail.comNTTheas@shrubbery.netCisco Systems, Inc.170 West Tasman Dr.San JoseCA95134United States of Americadcmgash@cisco.comGoogle Inc.1600 Amphitheatre ParkwayMountain ViewCA94043United States of Americaandrej@ota.si
OPS
opsawgTACACS+ This document specifies the use of Transport Layer Security (TLS)
version 1.3 to secure the communication channel between a Terminal
Access Controller Access-Control System Plus (TACACS+) client and
server. TACACS+ is a protocol used for Authentication, Authorization,
and Accounting (AAA) in networked environments. The original TACACS+
protocol does not mandate the use of encryption or secure
transport. This specification defines a profile for using TLS 1.3 with
TACACS+, including guidance on authentication, connection
establishment, and operational considerations. The goal is to enhance
the confidentiality, integrity, and authenticity of TACACS+ traffic,
aligning the protocol with modern security best practices.This document updates RFC 8907.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Technical Definitions
. Requirements Language
. TACACS+ over TLS
. Separating TLS Connections
. TLS Connection
. TLS Authentication Options
. TLS Certificate-Based Authentication
. TLS Certificate Path Verification
. TLS Certificate Identification
. Cipher Suites Requirements
. TLS PSK Authentication
. TLS Resumption
. Obsolescence of TACACS+ Obfuscation
. Security Considerations
. TLS
. TLS Use
. TLS 0-RTT
. TLS Options
. Unreachable Certificate Authority (CA)
. TLS Server Name Indicator (SNI)
. Server Identity Wildcards
. TACACS+ Configuration
. Well-Known TCP/IP Port Number
. Operational Considerations
. Migration
. Maintaining Non-TLS TACACS+ Clients
. YANG Model for TACACS+ Clients
. IANA Considerations
. Acknowledgments
. References
. Normative References
. Informative References
Authors' Addresses
Introduction
"The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol"
provides device administration for routers, network access servers, and other networked computing
devices via one or more centralized TACACS+ servers.
The protocol provides authentication, authorization, and accounting services (AAA) for TACACS+ clients
within the device administration use case.
The content of the protocol is highly sensitive and requires
secure transport to safeguard a deployment. However, TACACS+ lacks
effective confidentiality, integrity, and authentication of the
connection and network traffic between the TACACS+ server and client.
The security mechanisms as described in are
extremely weak.
To address these deficiencies, this document updates the TACACS+ protocol to use
TLS 1.3
authentication and encryption , and obsoletes the use of TACACS+ obfuscation mechanisms. The maturity of TLS in version 1.3 and above makes it a suitable choice for the TACACS+ protocol.
Technical Definitions
The terms defined in
are fully applicable here and will not be repeated.
The following terms are also used in this document.
Obfuscation:
TACACS+ was originally intended to incorporate a mechanism for securing the body of its packets.
The algorithm is categorized as obfuscation in . The term
is used to ensure that the algorithm is not mistaken for encryption. It should not be considered secure.
Non-TLS connection:
This term refers to the connection defined in .
It is a connection without TLS, using the unsecure TACACS+
authentication and obfuscation (or the unobfuscated option for testing).
The use of well-known TCP/IP host port number 49 is specified as the default for non-TLS
connections.
TLS connection:
A TLS connection is a TCP/IP connection with TLS authentication and encryption used by TACACS+ for
transport. A TLS connection for TACACS+ is always between one TACACS+ client and one TACACS+ server.
TLS TACACS+ server:
This document describes a variant of the TACACS+ server, introduced in , which
utilizes TLS for transport, and makes some associated protocol optimizations. Both server variants respond to
TACACS+ traffic, but this document specifically defines a TACACS+ server (whether TLS or non-TLS) as being bound to a specific port number
on a particular IP address or hostname. This definition is important in the context of the configuration
of TACACS+ clients to ensure they direct their traffic to the correct TACACS+ servers.
Peer:
The peer of a TACACS+ client (or server) in the context of a TACACS+ connection, is a TACACS+ server (or
client). Together, the ends of a TACACS+ connection are referred to as peers.
Requirements Language
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.
TACACS+ over TLS
TACACS+ over TLS takes the protocol defined in , removes the option for obfuscation, and specifies that TLS 1.3 be used for transport ( elaborates on TLS version support). A new well-known default host port number is used.
The next sections provide further details and guidance.
TLS is introduced into TACACS+ to fulfill the following requirements:
Confidentiality and Integrity: The MD5 algorithm underlying the obfuscation mechanism specified in has been shown
to be insecure when used for encryption. This prevents TACACS+ from being used in a deployment compliant with . Securing the TACACS+ protocol with TLS is intended to provide confidentiality and
integrity without requiring the provision of a secured network.
Peer authentication: The authentication capabilities of TLS replace the shared secrets of obfuscation for mutual authentication.
This document adheres to the recommendations in .Separating TLS Connections
Peers implementing the TACACS+ protocol variant defined in this document MUST apply mutual
authentication and encrypt all data exchanged between them. Therefore, when a TCP connection is
established for the service, a TLS handshake begins immediately. Options that upgrade an initial non-TLS connection MUST NOT be used; see .
To ensure clear separation between TACACS+ traffic using TLS and that which does not (see ), servers supporting
TACACS+ over TLS MUST listen on a TCP/IP port distinct from that used by non-TLS TACACS+ servers. It is further RECOMMENDED
to deploy the TLS and non-TLS services on separate hosts, as discussed in .
Given the prevalence of default port usage in existing TACACS+ client
implementations, this specification assigns the well-known TCP port number
300 for TACACS+ over TLS (see ).
While the use of the designated port number is strongly encouraged, deployments with specific requirements MAY use alternative TCP port numbers.
In such cases, operators must carefully consider the operational implications described in .
TLS Connection
A TACACS+ client initiates a TLS connection by making a TCP connection to a configured TLS TACACS+ server on the
TACACS+ TLS port number.
Once the TCP connection is established, the client MUST immediately begin the TLS negotiation before
sending any TACACS+ protocol data.
A minimum of TLS 1.3 MUST be used for transport. It is expected that TACACS+, as described in this document, will
work
with future versions of TLS. Earlier versions of TLS MUST NOT be used.
Once the TLS connection has been successfully established, the exchange of TACACS+ data MUST proceed in
accordance with the procedures defined in . However, all TACACS+ messages SHALL be transmitted
as TLS application data. The TACACS+ obfuscation mechanism defined in MUST NOT be applied
when operating over TLS (). TLS TACACS+ connections are generally not long-lived. The connection
will be closed by either a peer if it encounters an error
or an inactivity timeout.For connections not operating in Single Connection Mode (as defined in
), the TCP session SHALL be closed upon
completion of the associated TACACS+ session. Connections operating in Single
Connection Mode MAY persist for a longer duration but are typically
subject to timeout and closure after a brief period of inactivity.
Consequently, support for transport-layer keepalive mechanisms is not
required.Why a connection is closed has no bearing on TLS resumption, unless
closed by a TLS error, in which case it is possible that the ticket has been invalidated.
TACACS+ clients and servers widely support IPv6 configuration in addition to IPv4. This document makes no changes to recommendations in this area.
TLS Authentication Options
Implementations MUST support certificate-based mutual authentication, to provide a core option for interoperability between deployments.
This authentication option is specified in .
In addition to certificate-based TLS authentication, implementations MAY support the following alternative authentication mechanisms:
Pre-Shared Keys (PSKs) (), also known as external PSKs in TLS 1.3.
Raw Public Keys (RPKs). The details
of RPKs are considered out of scope for this document. Refer to and for
implementation, deployment, and security considerations.
TLS Certificate-Based Authentication
TLS certificate authentication is the primary authentication option for TACACS+ over TLS.
This section covers certificate-based authentication only.Deploying TLS certificate-based authentication correctly will considerably improve the security of TACACS+
deployments. It is essential for implementers and operators to understand the implications of a TLS
certificate-based authentication solution, including the correct handling of certificates, Certificate Authorities (CAs), and all
elements of TLS configuration. For guidance, start with .Each peer MUST validate the certificate path of its remote peer, including revocation checking,
as
described in .
If the verification succeeds, the authentication is successful and the connection is permitted.
Policy may impose further constraints upon the peer, allowing or denying the connection based on
certificate fields or any other parameters exposed by the implementation.
Unless disabled by configuration, a peer MUST NOT permit connection of any peer that presents an
invalid TLS certificate.
TLS Certificate Path Verification
The implementation of certificate-based mutual authentication MUST support certificate path
validation as described in .
In some deployments, a peer may be isolated from a remote peer's CA.
Implementations for these deployments MUST support certificate chains
(aka bundles or chains of trust), where the entire chain of the remote peer's certificate is
stored
on the local peer.
TLS Cached Information Extension
SHOULD be implemented. This MAY be augmented with RPKs ,
though
revocation must be handled as it is not part of that specification.
Other approaches may be used for loading the intermediate certificates onto the client, but
they MUST
include support for revocation checking. For example,
details the Authority Information Access (AIA) extension to provide information about the
issuer
of the certificate in which the extension appears. It can be used to provide the address of
the
Online Certificate Status Protocol (OCSP) responder from where the revocation status of the
certificate (which includes the extension) can be checked.
TLS Certificate IdentificationFor the client-side validation of presented TLS TACACS+ server identities, implementations MUST follow the validation techniques defined in
.
Identifier types DNS-ID, IP-ID, or SRV-ID
are applicable for use with the TLS TACACS+ protocol; they are selected by operators depending upon
the
deployment design. TLS TACACS+ does not use URI-IDs for TLS TACACS+ server identity verification.Wildcards in TLS TACACS+ server identities simplify certificate management by allowing a single
certificate to secure multiple servers in a deployment. However, this introduces security risks,
as compromising the private key of a wildcard certificate impacts all servers using it.
To address these risks, the guidelines in MUST be followed,
and the wildcard SHOULD be confined to a subdomain dedicated solely to TACACS+ servers.
For the TLS TACACS+ server-side validation of client identities, implementations MUST support the
ability to
configure which fields of a certificate are used for client identification to verify that
the
client
is a valid
source for the received certificate and that it is permitted access
to TACACS+. Implementations MUST support either:
Network-address-based validation methods as described in or
Client Identity validation of a shared identity in the certificate subjectAltName. This is
applicable
in deployments where the client securely supports an identity which is shared with the
TLS TACACS+ server. Matching of dNSName and iPAddress MUST be supported. Other options defined
in MAY be supported.
This approach allows a client's network location to be reconfigured without issuing a new
client
certificate.
Implementations MUST support the TLS Server Name Indication (SNI) extension ().
TLS TACACS+ clients MUST support the ability to configure the TLS TACACS+ server's domain name, so that it may be
included
in
the
SNI "server_name" extension of the client hello (This is distinct from the IP Address or hostname configuration used for the TCP connection). Refer to
for security related operator considerations.
Certificate provisioning is out of scope of this document.Cipher Suites Requirements
Implementations MUST support the TLS 1.3 mandatory cipher suites ().
Readers should refer to . The cipher suites offered or accepted SHOULD be configurable so that operators can adapt.
TLS PSK Authentication
As an alternative to certificate-based authentication, implementations MAY support PSKs, also known as external PSKs in TLS 1.3 . These should not be confused with resumption PSKs.
The use of external PSKs is less well established than certificate-based authentication. It is
RECOMMENDED that systems follow the directions of and .
Where PSK authentication is implemented, PSK lengths of at least 16 octets MUST be supported.
PSK identity MUST follow recommendations of . Implementations MUST support PSK identities
of at least 16 octets.
Although this document removes the option of obfuscation (), it is still possible that the TLS and non-TLS
versions of TACACS+ exist in an organization, for example, during migration ().
In such cases, the shared secrets configured for TACACS+ obfuscation clients MUST NOT be the same as the PSKs configured for TLS clients.
TLS Resumption
TLS Resumption can minimize the number of round trips required during the handshake process.
If a TLS client holds a ticket previously extracted from a NewSessionTicket message from the TLS TACACS+ server, it can use the PSK identity tied to that ticket.
If the TLS TACACS+ server consents, the resumed session is acknowledged as authenticated and securely linked to
the initial session.
The client SHOULD use resumption when it holds a valid unused ticket from the TLS TACACS+ server,
as each ticket is intended for a single use only and will be refreshed during resumption. The TLS TACACS+ server can reject a resumption request,
but the TLS TACACS+ server SHOULD allow resumption if the ticket in question has not expired and has not been used before.
When a TLS TACACS+ server is presented with a resumption request from the TLS client, it MAY still choose to require a full handshake.
In this case, the negotiation proceeds as if the session was a new authentication,
and the resumption attempt is ignored. As described in , reuse of a ticket allows passive observers to correlate
different connections. TLS TACACS+ clients and servers SHOULD follow the client tracking preventions in .
When processing TLS resumption, certificates must be verified to check for revocation during the period since the last NewSessionTicket Message.
The resumption ticket_lifetime SHOULD be configurable, including a zero
seconds lifetime. Refer to for guidance on ticket lifetime.
Obsolescence of TACACS+ ObfuscationThe obfuscation mechanism documented in is weak.
The introduction of TLS authentication and encryption to TACACS+ replaces
this former mechanism, so obfuscation is hereby obsoleted.
This section describes how the TACACS+ client and servers MUST operate regarding the obfuscation
mechanism.
Peers MUST NOT use obfuscation with TLS.
A TACACS+ client initiating a TACACS+ TLS connection MUST set the TAC_PLUS_UNENCRYPTED_FLAG bit, thereby
asserting that obfuscation is not used for the session.
All subsequent packets MUST have the TAC_PLUS_UNENCRYPTED_FLAG bit set to 1.
A TLS TACACS+ server that receives a packet with the TAC_PLUS_UNENCRYPTED_FLAG bit not set to 1 over a TLS
connection MUST return an error of TAC_PLUS_AUTHEN_STATUS_ERROR, TAC_PLUS_AUTHOR_STATUS_ERROR, or
TAC_PLUS_ACCT_STATUS_ERROR as appropriate for the TACACS+ message type, with the
TAC_PLUS_UNENCRYPTED_FLAG bit set to 1, and terminate the session.
This behavior corresponds to that defined in
regarding data obfuscation for TAC_PLUS_UNENCRYPTED_FLAG or key mismatches.
A TACACS+ client that receives a packet with the TAC_PLUS_UNENCRYPTED_FLAG bit not set to 1 MUST
terminate the session, and SHOULD log this error.
Security ConsiderationsTLS
This document improves the confidentiality, integrity, and authentication of the connection and
network traffic between TACACS+ peers by adding TLS support.
Simply adding TLS support to the protocol does not guarantee the protection
of the TLS TACACS+ server and clients. It is essential for the operators and equipment vendors
to adhere to the latest best practices for ensuring the integrity of network devices
and selecting secure TLS key and encryption algorithms.
offers substantial guidance for implementing and deploying protocols that use TLS. Those implementing and deploying Secure TACACS+
must adhere to the recommendations relevant to TLS 1.3 outlined in
or its subsequent versions.
This document outlines additional restrictions permissible under .
For example, any recommendations referring to TLS 1.2, including the mandatory
support, are not relevant for Secure TACACS+, as TLS 1.3 or above is mandated.
This document concerns the use of TLS as transport for TACACS+ and does not make any changes to the core TACACS+
protocol, other than the direct implications of deprecating obfuscation. Operators MUST be cognizant of the security
implications of the TACACS+ protocol itself. Further documents are planned, for example, to address the security implications of password-based authentication and enhance the protocol to accommodate alternative schemes.
TLS Use
New TACACS+ production deployments SHOULD use TLS authentication and encryption. Also see .
TLS TACACS+ servers (as defined in ) MUST NOT allow non-TLS connections, because of the threat
of downgrade attacks or misconfiguration described in . Instead, separate non-TLS TACACS+ servers
SHOULD be set up to cater for these clients.
It is NOT RECOMMENDED that TLS TACACS+ servers and non-TLS TACACS+ servers be deployed
on the same host, for reasons discussed in . Non-TLS connections would be better served by deploying the
required non-TLS TACACS+ servers on separate hosts.
TACACS+ clients MUST NOT fail back to a non-TLS connection if a TLS connection fails. This prohibition includes during the migration of a deployment ().
TLS 0-RTT
TLS 1.3 resumption and PSK techniques make it possible to send early data, aka 0-RTT data, data
that is sent before the TLS handshake completes.
Replay of this data is a risk.
Given the sensitivity of TACACS+ data, clients MUST NOT send data until the full TLS handshake
completes; that is, clients MUST NOT send 0-RTT data and TLS TACACS+ servers MUST abruptly disconnect
clients that do.
TLS TACACS+ clients and servers MUST NOT include the "early_data" extension. See Sections and of
for security concerns.TLS OptionsRecommendations in
MUST be followed to determine which TLS versions and algorithms should be supported,
deprecated, obsoleted, or abandoned.
Also,
prescribes mandatory supported options.
Unreachable Certificate Authority (CA)
Operators should be cognizant of the potential of TLS TACACS+ server and/or client isolation from their
peer's CA by network failures.
Isolation from a public key certificate's CA will cause the verification of the certificate to
fail and thus TLS authentication of the peer to fail.
The approach mentioned in
can help address this and should be considered.
TLS Server Name Indicator (SNI)
Operators should be aware that the TLS SNI extension is part of the TLS client hello, which is sent in cleartext. It is,
therefore, subject to eavesdropping. Also see .
Server Identity Wildcards
The use of wildcards in TLS server identities creates a single point of failure:
a compromised private key of a wildcard certificate impacts all servers using it.
Their use MUST follow the recommendations of .
Operators MUST ensure that the wildcard is limited to a subdomain dedicated solely to TLS TACACS+ servers.
Further, operators MUST ensure that the TLS TACACS+ servers covered
by a wildcard certificate are impervious to redirection of
traffic to a different server (for example, due to on-path attacks or
DNS cache poisoning).
TACACS+ Configuration
Implementors must ensure that the configuration scheme introduced
for enabling TLS is straightforward and leaves no room for ambiguity regarding whether
TLS or non-TLS will be used between the TACACS+ client and the TACACS+ server.
This document recommends the use of a separate port number that TLS TACACS+ servers
will listen to. Where deployments have not overridden the defaults explicitly,
TACACS+ client implementations MUST use the correct port values:
49: for non-TLS connection TACACS+
300: for TLS connection TACACS+
Implementors may offer a single option for TACACS+ clients and servers to disable all
non-TLS TACACS+ operations. When enabled on a TACACS+ server, it will
not respond to any requests from non-TLS TACACS+ client connections. When enabled on
a TACACS+ client, it will not establish any non-TLS TACACS+ server connections.
Well-Known TCP/IP Port Number
A new port number is considered appropriate (rather than a mechanism that negotiates an
upgrade from an initial non-TLS TACACS+ connection) because it allows:
ease of blocking the unobfuscated or obfuscated connections by the TCP/IP port number,
passive Intrusion Detection Systems (IDSs) monitoring the unobfuscated to be unaffected by the
introduction of TLS,
avoidance of on-path attacks that can interfere with upgrade, and
prevention of the accidental exposure of sensitive information due to misconfiguration.
However, the coexistence of inferior authentication and obfuscation, whether a non-TLS connection or
deprecated parts that compose TLS, also presents an opportunity for downgrade attacks.
Causing failure of connections to the TLS-enabled service or the negotiation of shared algorithm
support are two such downgrade attacks.
The simplest mitigation exposure from non-TLS connection methods is to refuse non-TLS
connections at the host entirely, perhaps using separate hosts for non-TLS connections and TLS.
Another approach is mutual configuration that requires TLS.
TACACS+ clients and servers SHOULD support configuration that requires peers, globally and individually, to use
TLS.
Furthermore, peers SHOULD be configurable to limit offered or recognized TLS versions and algorithms
to those recommended by standards bodies and implementers.
Operational Considerations
Operational and deployment considerations are spread throughout the
document. While avoiding repetition, it is useful for the impatient
to direct particular attention to Sections and .
However, it is important that the entire is observed.
It is essential for operators to understand the implications of a TLS
certificate-based authentication solution, including the correct handling of certificates, CAs, and all
elements of TLS configuration. Refer to for guidance. Attention is drawn to the provisioning
of certificates to all peers, including TACACS+ TLS clients, to permit the mandatory mutual authentication.Migration mentions that for an optimal deployment of TLS TACACS+,
TLS should be universally applied throughout the deployment. However, during
the migration process from a non-TLS TACACS+ deployment, operators may need
to support both TLS and non-TLS TACACS+ servers. This migration phase allows
operators to gradually transition their deployments from an insecure state to
a more secure one, but it is important to note that it is vulnerable to
downgrade attacks. Therefore, the migration phase should be considered
insecure until it is fully completed. To mitigate this hazard:
The period where any client is configured with both TLS and non-TLS TACACS+ servers should be
minimized.
The operator must consider the security impact of supporting both TLS and non-TLS connections, as mentioned above.
Maintaining Non-TLS TACACS+ Clients
Some TACACS+ client devices in a deployment may not implement TLS.
These devices will require access to non-TLS TACACS+ servers.
Operators must follow the recommendation of
and deploy
separate non-TLS TACACS+ servers for these non-TLS clients from those used
for the TLS clients.
YANG Model for TACACS+ Clients specifies a YANG model for managing TACACS+ clients, including TLS support.
IANA Considerations
IANA has allocated the following new well-known system in the
"Service Name and Transport Protocol Port Number Registry" (see
). The
service name "tacacss" follows the common practice of appending an
"s" to the name given to the non-TLS well-known port name. See the
justification for the allocation in Section 5.3.
Service Name:
tacacss
Port Number:
300
Transport Protocol:
TCP
Description:
TLS Secure Login Host Protocol (TACACSS)
Assignee:
IESG
Contact:
IETF Chair
Reference:
RFC 9887
Considerations about service discovery are out of scope of
this document.Acknowledgments
The author(s) would like to thank , , , , , , ,
, and for their support, insightful
review, and/or comments. was also
used as a basis for the general approach to TLS. was used as a basis for TLS resumption
recommendations. Although still in draft form at the time of
writing, was used as
a model for PSK recommendations.
ReferencesNormative ReferencesDeprecating TLS 1.0 and TLS 1.1This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]Transport Layer Security (TLS) Transport Mapping for SyslogThis document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to syslog and how TLS can be used to counter such threats.Transport Layer Security (TLS) Extensions: Extension DefinitionsThis document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.Transport Layer Security (TLS) Cached Information ExtensionTransport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.The Terminal Access Controller Access-Control System Plus (TACACS+) ProtocolThis document describes the Terminal Access Controller Access-Control System Plus (TACACS+) protocol, which is widely deployed today to provide Device Administration for routers, network access servers, and other networked computing devices via one or more centralized servers.Service Identity in TLSMany application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions.This document obsoletes RFC 6125.Informative ReferencesSecurity Requirements for Cryptographic ModulesNational Institute of Standards and TechnologyNew Protocols Using TLS Must Require TLS 1.3Akamai TechnologiesTLS 1.3 use is widespread, it has had comprehensive security proofs, and it improves both security and privacy over TLS 1.2. Therefore, new protocols that use TLS must require TLS 1.3. As DTLS 1.3 is not widely available or deployed, this prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. This document updates RFC9325 and discusses post-quantum cryptography and the security and privacy improvements over TLS 1.2 as a rationale for that update.Work in ProgressStrong Security Requirements for Internet Engineering Task Force Standard ProtocolsUpdated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 AlgorithmsThis document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216.Guidance for External Pre-Shared Key (PSK) Usage in TLSThis document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used.Operational Considerations for Using TLS Pre-Shared Keys (TLS-PSKs) with RADIUSThis document provides implementation and operational considerations for using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS/TLS (RFC 6614) and RADIUS/DTLS (RFC 7360). The purpose of the document is to help smooth the operational transition from the use of RADIUS/UDP to RADIUS/TLS.A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)OrangeHuawei TechnologiesThis document defines a Terminal Access Controller Access-Control System Plus (TACACS+) client YANG module that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Specifically, this document defines a YANG module for TACACS+ over TLS 1.3. This document obsoletes RFC 9105.Work in ProgressAuthors' Addressesthorsten.dahm@gmail.comNTTheas@shrubbery.netCisco Systems, Inc.170 West Tasman Dr.San JoseCA95134United States of Americadcmgash@cisco.comGoogle Inc.1600 Amphitheatre ParkwayMountain ViewCA94043United States of Americaandrej@ota.si