rfc9887.original   rfc9887.txt 
Operations and Management Area Working Group T. Dahm Internet Engineering Task Force (IETF) T. Dahm
Internet-Draft Request for Comments: 9887
Updates: 8907 (if approved) J. Heasley Updates: 8907 J. Heasley
Intended status: Standards Track NTT Category: Standards Track NTT
Expires: 10 January 2026 D.C. Medway Gash ISSN: 2070-1721 D.C. Medway Gash
Cisco Systems, Inc. Cisco Systems, Inc.
A. Ota A. Ota
Google Inc. Google Inc.
9 July 2025 October 2025
Terminal Access Controller Access-Control System Plus over TLS 1.3 Terminal Access Controller Access-Control System Plus (TACACS+)
(TACACS+ over TLS) over TLS 1.3
draft-ietf-opsawg-tacacs-tls13-24
Abstract Abstract
This document specifies the use of Transport Layer Security (TLS) This document specifies the use of Transport Layer Security (TLS)
version 1.3 to secure the communication channel between a Terminal version 1.3 to secure the communication channel between a Terminal
Access Controller Access-Control System Plus (TACACS+) client and Access Controller Access-Control System Plus (TACACS+) client and
server. TACACS+ is a protocol used for Authentication, server. TACACS+ is a protocol used for Authentication,
Authorization, and Accounting (AAA) in networked environments. The Authorization, and Accounting (AAA) in networked environments. The
original TACACS+ protocol, does not mandate the use of encryption or original TACACS+ protocol does not mandate the use of encryption or
secure transport. This specification defines a profile for using TLS secure transport. This specification defines a profile for using TLS
1.3 with TACACS+, including guidance on authentication, connection 1.3 with TACACS+, including guidance on authentication, connection
establishment, and operational considerations. The goal is to establishment, and operational considerations. The goal is to
enhance the confidentiality, integrity, and authenticity of TACACS+ enhance the confidentiality, integrity, and authenticity of TACACS+
traffic, aligning the protocol with modern security best practices. traffic, aligning the protocol with modern security best practices.
This document updates RFC 8907. This document updates RFC 8907.
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 10 January 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9887.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Technical Definitions . . . . . . . . . . . . . . . . . . . . 3 2. Technical Definitions
3. TACACS+ over TLS . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language
3.1. Separating TLS Connections . . . . . . . . . . . . . . . 5 3. TACACS+ over TLS
3.2. TLS Connection . . . . . . . . . . . . . . . . . . . . . 5 3.1. Separating TLS Connections
3.3. TLS Authentication Options . . . . . . . . . . . . . . . 6 3.2. TLS Connection
3.4. TLS Certificate-Based Authentication . . . . . . . . . . 6 3.3. TLS Authentication Options
3.4.1. TLS Certificate Path Verification . . . . . . . . . . 7 3.4. TLS Certificate-Based Authentication
3.4.2. TLS Certificate Identification . . . . . . . . . . . 8 3.4.1. TLS Certificate Path Verification
3.4.3. Cipher Suites Requirements . . . . . . . . . . . . . 9 3.4.2. TLS Certificate Identification
3.5. TLS PSK Authentication . . . . . . . . . . . . . . . . . 9 3.4.3. Cipher Suites Requirements
3.6. TLS Resumption . . . . . . . . . . . . . . . . . . . . . 9 3.5. TLS PSK Authentication
4. Obsolescence of TACACS+ Obfuscation . . . . . . . . . . . . . 10 3.6. TLS Resumption
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Obsolescence of TACACS+ Obfuscation
5.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations
5.1.1. TLS Use . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. TLS
5.1.2. TLS 0-RTT . . . . . . . . . . . . . . . . . . . . . . 12 5.1.1. TLS Use
5.1.3. TLS Options . . . . . . . . . . . . . . . . . . . . . 12 5.1.2. TLS 0-RTT
5.1.4. Unreachable Certification Authority (CA) . . . . . . 12 5.1.3. TLS Options
5.1.5. TLS Server Name Indicator (SNI) . . . . . . . . . . . 12 5.1.4. Unreachable Certification Authority (CA)
5.1.6. Server Identity Wildcards . . . . . . . . . . . . . . 12 5.1.5. TLS Server Name Indicator (SNI)
5.2. TACACS+ Configuration . . . . . . . . . . . . . . . . . . 13 5.1.6. Server Identity Wildcards
5.3. Well-Known TCP/IP Port Number . . . . . . . . . . . . . . 13 5.2. TACACS+ Configuration
6. Operational Considerations . . . . . . . . . . . . . . . . . 14 5.3. Well-Known TCP/IP Port Number
6.1. Migration . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Operational Considerations
6.2. Maintaining Non-TLS TACACS+ Clients . . . . . . . . . . . 15 6.1. Migration
6.3. YANG Model for TACACS+ Clients . . . . . . . . . . . . . 15 6.2. Maintaining Non-TLS TACACS+ Clients
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.3. YANG Model for TACACS+ Clients
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations
9. Normative References . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments
10. Informative References . . . . . . . . . . . . . . . . . . . 17 9. References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References
9.2. Informative References
Authors' Addresses
1. Introduction 1. Introduction
The Terminal Access Controller Access-Control System Plus (TACACS+) "The Terminal Access Controller Access-Control System Plus (TACACS+)
Protocol [RFC8907] provides device administration for routers, Protocol" [RFC8907] provides device administration for routers,
network access servers, and other networked computing devices via one network access servers, and other networked computing devices via one
or more centralized TACACS+ servers. The protocol provides or more centralized TACACS+ servers. The protocol provides
authentication, authorization and accounting services (AAA) for authentication, authorization, and accounting services (AAA) for
TACACS+ clients within the device administration use case. TACACS+ clients within the device administration use case.
While the content of the protocol is highly sensitive, TACACS+ lacks While the content of the protocol is highly sensitive, TACACS+ lacks
effective confidentiality, integrity, and authentication of the effective confidentiality, integrity, and authentication of the
connection and network traffic between the TACACS+ server and client, connection and network traffic between the TACACS+ server and client,
requiring secure transport to safeguard a deployment. The security requiring secure transport to safeguard a deployment. The security
mechanisms as described in Section 10 of [RFC8907] are extremely mechanisms as described in Section 10 of [RFC8907] are extremely
weak. weak.
To address these deficiencies, this document updates the TACACS+ To address these deficiencies, this document updates the TACACS+
protocol to use TLS 1.3 [RFC8446] authentication and encryption, and protocol to use TLS 1.3 authentication and encryption [RFC8446], and
obsoletes the use of TACACS+ obfuscation mechanisms (Section 10.5 of obsoletes the use of TACACS+ obfuscation mechanisms (Section 10.5 of
[RFC8907]). The maturity of TLS in version 1.3 and above makes it a [RFC8907]). The maturity of TLS in version 1.3 and above makes it a
suitable choice for the TACACS+ protocol. suitable choice for the TACACS+ protocol.
2. Technical Definitions 2. Technical Definitions
The terms defined in Section 3 of [RFC8907] are fully applicable here The terms defined in Section 3 of [RFC8907] are fully applicable here
and will not be repeated. The following terms are also used in this and will not be repeated. The following terms are also used in this
document. document.
Obfuscation: TACACS+ was originally intended to incorporate a Obfuscation: TACACS+ was originally intended to incorporate a
mechanism for securing the body of its packets. The algorithm is mechanism for securing the body of its packets. The algorithm is
categorized as Obfuscation in Section 10.5.2 of [RFC8907]. The term categorized as Obfuscation in Section 10.5.2 of [RFC8907]. The
is used to ensure that the algorithm is not mistaken for encryption. term is used to ensure that the algorithm is not mistaken for
It should not be considered secure. encryption. It should not be considered secure.
Non-TLS connection: This term refers to the connection defined in Non-TLS connection: This term refers to the connection defined in
[RFC8907]. It is a connection without TLS, using the unsecure [RFC8907]. It is a connection without TLS, using the unsecure
TACACS+ authentication and obfuscation (or the unobfuscated option TACACS+ authentication and obfuscation (or the unobfuscated option
for test). The use of well-known TCP/IP host port number 49 is for test). The use of well-known TCP/IP host port number 49 is
specified as the default for Non-TLS connections. specified as the default for non-TLS connections.
TLS connection: A TLS connection is a TCP/IP connection with TLS TLS connection: A TLS connection is a TCP/IP connection with TLS
authentication and encryption used by TACACS+ for transport. A TLS authentication and encryption used by TACACS+ for transport. A
connection for TACACS+ is always between one TACACS+ client and one TLS connection for TACACS+ is always between one TACACS+ client
TACACS+ server. and one TACACS+ server.
TLS TACACS+ server: This document describes a variant of the TACACS+ TLS TACACS+ server: This document describes a variant of the TACACS+
server, introduced in Section 3.2 of [RFC8907], which utilizes TLS server, introduced in Section 3.2 of [RFC8907], which utilizes TLS
for transport, and makes some associated protocol optimizations. for transport, and makes some associated protocol optimizations.
Both server variants respond to TACACS+ traffic, but this document Both server variants respond to TACACS+ traffic, but this document
specifically defines a TACACS+ server (whether TLS or Non-TLS) as specifically defines a TACACS+ server (whether TLS or non-TLS) as
being bound to specific port number on a particular IP address or being bound to a specific port number on a particular IP address
hostname. This definition is important in the context of the or hostname. This definition is important in the context of the
configuration of TACACS+ clients, to ensure they direct their traffic configuration of TACACS+ clients to ensure they direct their
to the correct TACACS+ servers. traffic to the correct TACACS+ servers.
Peer: The peer of a TACACS+ client (or server) in the context of a Peer: The peer of a TACACS+ client (or server) in the context of a
TACACS+ connection, is a TACACS+ server (or client). Together, the TACACS+ connection, is a TACACS+ server (or client). Together,
ends of a TACACS+ connection are referred to as peers. the ends of a TACACS+ connection are referred to as peers.
2.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. TACACS+ over TLS 3. TACACS+ over TLS
TACACS+ over TLS takes the protocol defined in [RFC8907], removes the TACACS+ over TLS takes the protocol defined in [RFC8907], removes the
option for MD5 obfuscation, and specifies that TLS 1.3 be used for option for MD5 obfuscation, and specifies that TLS 1.3 be used for
transport (Section 3.1 elaborates TLS version support). A new well- transport (Section 3.1 elaborates on TLS version support). A new
known default host port number is used. The next sections provide well-known default host port number is used. The next sections
further details and guidance. provide further details and guidance.
TLS is introduced into TACACS+ to fulfill the following requirements: TLS is introduced into TACACS+ to fulfill the following requirements:
1. Confidentiality and Integrity: The MD5 algorithm underlying the 1. Confidentiality and Integrity: The MD5 algorithm underlying the
obfuscation mechanism specified in [RFC8907] has been shown to be obfuscation mechanism specified in [RFC8907] has been shown to be
insecure [RFC6151] when used for encryption. This prevents insecure [RFC6151] when used for encryption. This prevents
TACACS+ being used in a [FIPS-140-3] - compliant deployment. TACACS+ from being used in a deployment compliant with
Securing TACACS+ protocol with TLS is intended to provide [FIPS-140-3]. Securing the TACACS+ protocol with TLS is intended
confidentiality and integrity without requiring the provision of to provide confidentiality and integrity without requiring the
a secured network. provision of a secured network.
2. Peer authentication: The authentication capabilities of TLS 2. Peer authentication: The authentication capabilities of TLS
replace the shared secrets of obfuscation for mutual replace the shared secrets of obfuscation for mutual
authentication. authentication.
This document adheres to the recommendations in This document adheres to the recommendations in [REQ-TLS13].
[I-D.ietf-uta-require-tls13].
3.1. Separating TLS Connections 3.1. Separating TLS Connections
Peers implementing the TACACS+ protocol variant defined in this Peers implementing the TACACS+ protocol variant defined in this
document MUST apply mutual authentication and encrypt all data document MUST apply mutual authentication and encrypt all data
exchanged between them. Therefore, when a TCP connection is exchanged between them. Therefore, when a TCP connection is
established for the service, a TLS handshake begins immediately. established for the service, a TLS handshake begins immediately.
Options which upgrade an initial Non-TLS connection, MUST NOT be Options that upgrade an initial non-TLS connection MUST NOT be used;
used, see Section 5.3. see Section 5.3.
To ensure clear separation between TACACS+ traffic using TLS and that To ensure clear separation between TACACS+ traffic using TLS and that
which does not (see Section 5.3), servers supporting TACACS+ over TLS which does not (see Section 5.3), servers supporting TACACS+ over TLS
MUST listen on a TCP/IP port distinct from that used by non-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 TACACS+ servers. It is further RECOMMENDED to deploy the TLS and
non-TLS services on separate hosts, as discussed in Section 5.1.1. non-TLS services on separate hosts, as discussed in Section 5.1.1.
Given the prevalence of default port usage in existing TACACS+ client Given the prevalence of default port usage in existing TACACS+ client
implementations, this specification assigns a well-known TCP port implementations, this specification assigns a well-known TCP port
number for TACACS+ over TLS: [TBD] (Section 7), with the associated number for TACACS+ over TLS: 300, with the associated service name
service name "tacacss" Section 7. This allows clients to "tacacss" (see Section 7). This allows clients to unambiguously
unambiguously distinguish between TLS and non-TLS connections, even distinguish between TLS and non-TLS connections, even in the absence
in the absence of an explicitly configured port number. of an explicitly configured port number.
While the use of the designated port number is strongly encouraged, While the use of the designated port number is strongly encouraged,
deployments with specific requirements MAY use alternative TCP port deployments with specific requirements MAY use alternative TCP port
numbers. In such cases, operators must carefully consider the numbers. In such cases, operators must carefully consider the
operational implications described in Section 5.3. operational implications described in Section 5.3.
3.2. TLS Connection 3.2. TLS Connection
A TACACS+ client initiates a TLS connection by making a TCP A TACACS+ client initiates a TLS connection by making a TCP
connection to a configured TLS TACACS+ server on the TACACS+ TLS port connection to a configured TLS TACACS+ server on the TACACS+ TLS port
number. Once the TCP connection is established, the client MUST number. Once the TCP connection is established, the client MUST
immediately begin the TLS negotiation before sending any TACACS+ immediately begin the TLS negotiation before sending any TACACS+
protocol data. protocol data.
Minimum TLS 1.3 [RFC8446] MUST be used for transport, it is expected A minimum of TLS 1.3 [RFC8446] MUST be used for transport. It is
that TACACS+ as described in this document will work with future expected that TACACS+, as described in this document, will work with
versions of TLS. Earlier versions of TLS MUST NOT be used. future versions of TLS. Earlier versions of TLS MUST NOT be used.
Once the TLS connection has been successfully established, the Once the TLS connection has been successfully established, the
exchange of TACACS+ data MUST proceed in accordance with the exchange of TACACS+ data MUST proceed in accordance with the
procedures defined in [RFC8907], However, all TACACS+ messages SHALL procedures defined in [RFC8907]. However, all TACACS+ messages SHALL
be transmitted as TLS application data. The TACACS+ obfuscation be transmitted as TLS application data. The TACACS+ obfuscation
mechanism defined in [RFC8907] MUST NOT be applied when operating mechanism defined in [RFC8907] MUST NOT be applied when operating
over TLS (Section 4). over TLS (Section 4).
The connection persists until the TLS TACACS+ peer closes it, either The connection persists until the TLS TACACS+ peer closes it, either
due to an error, or at the conclusion of the TACACS+ session, or, if due to an error, or at the conclusion of the TACACS+ session, or, if
Single Connection Mode (Section 4.3 of [RFC8907]) has been Single Connection Mode (Section 4.3 of [RFC8907]) has been
negotiated, when an inactivity timeout occurs. Why it closed has no negotiated, when an inactivity timeout occurs. Why it closed has no
bearing on TLS resumption, unless closed by a TLS error, in which bearing on TLS resumption, unless closed by a TLS error, in which
case it is possible that the ticket has been invalidated. case it is possible that the ticket has been invalidated.
TACACS+ connections are generally not long-lived. For connections TACACS+ connections are generally not long-lived. For connections
not operating in Single Connection Mode (as defined in Section 4.3 of not operating in Single Connection Mode (as defined in Section 4.3 of
[RFC8907]) the TCP session SHALL be closed upon completion of the [RFC8907]), the TCP session SHALL be closed upon completion of the
associated TACACS+ session. Connections operating in Single associated TACACS+ session. Connections operating in Single
Connection Mode MAY persist for a longer duration but are typically Connection Mode MAY persist for a longer duration but are typically
subject to timeout and closure after a brief period of inactivity. subject to timeout and closure after a brief period of inactivity.
Consequently, support for transport-layer keepalive mechanisms is not Consequently, support for transport-layer keepalive mechanisms is not
required. required.
TACACS+ clients and servers widely support IPv6 configuration in TACACS+ clients and servers widely support IPv6 configuration in
addition to IPv4. This document makes no changes to recommendations addition to IPv4. This document makes no changes to recommendations
in this area. in this area.
skipping to change at page 6, line 37 skipping to change at line 266
Implementations MUST support certificate-based mutual authentication, Implementations MUST support certificate-based mutual authentication,
to provide a core option for interoperability between deployments. to provide a core option for interoperability between deployments.
This authentication option is specified in Section 3.4. This authentication option is specified in Section 3.4.
In addition to certificate-based TLS authentication, implementations In addition to certificate-based TLS authentication, implementations
MAY support the following alternative authentication mechanisms: MAY support the following alternative authentication mechanisms:
* Pre-Shared Keys (PSKs) (Section 3.5), also known as external PSKs * Pre-Shared Keys (PSKs) (Section 3.5), also known as external PSKs
in TLS 1.3. in TLS 1.3.
* Raw Public Keys (RPKs). The details of RPK are considered out-of- * Raw Public Keys (RPKs). The details of RPKs are considered out of
scope for this document. Refer to [RFC7250] and Section 4.4.2 of scope for this document. Refer to [RFC7250] and Section 4.4.2 of
[RFC8446] for implementation, deployment, and security [RFC8446] for implementation, deployment, and security
considerations. considerations.
3.4. TLS Certificate-Based Authentication 3.4. TLS Certificate-Based Authentication
TLS certificate authentication is the primary authentication option TLS certificate authentication is the primary authentication option
for TACACS+ over TLS. This section covers certificate-based for TACACS+ over TLS. This section covers certificate-based
authentication only. authentication only.
skipping to change at page 7, line 33 skipping to change at line 305
of any peer that presents an invalid TLS certificate. of any peer that presents an invalid TLS certificate.
3.4.1. TLS Certificate Path Verification 3.4.1. TLS Certificate Path Verification
The implementation of certificate-based mutual authentication MUST The implementation of certificate-based mutual authentication MUST
support certificate path verification as described in Section 6 of support certificate path verification as described in Section 6 of
[RFC5280]. [RFC5280].
In some deployments, a peer may be isolated from a remote peer's CA. In some deployments, a peer may be isolated from a remote peer's CA.
Implementations for these deployments MUST support certificate chains Implementations for these deployments MUST support certificate chains
(a.k.a. bundles or chains of trust), where the entire chain of the (aka bundles or chains of trust), where the entire chain of the
remote's certificate is stored on the local peer. remote peer's certificate is stored on the local peer.
TLS Cached Information Extension [RFC7924] SHOULD be implemented. TLS Cached Information Extension [RFC7924] SHOULD be implemented.
This MAY be augmented with RPKs [RFC7250], though revocation must be This MAY be augmented with RPKs [RFC7250], though revocation must be
handled as it is not part of the standard. handled as it is not part of that specification.
Other approaches may be used for loading the intermediate Other approaches may be used for loading the intermediate
certificates onto the client, but MUST include support for revocation certificates onto the client, but they MUST include support for
checking. For example, [RFC5280] details the Authority Information revocation checking. For example, [RFC5280] details the Authority
Access (AIA) extension to provide information about the issuer of the Information Access (AIA) extension to provide information about the
certificate in which the extension appears. It can be used to issuer of the certificate in which the extension appears. It can be
provide the address of the Online Certificate Status Protocol (OCSP) used to provide the address of the Online Certificate Status Protocol
responder from where revocation status of the certificate (which (OCSP) responder from where the revocation status of the certificate
includes the extension) can be checked. (which includes the extension) can be checked.
3.4.2. TLS Certificate Identification 3.4.2. TLS Certificate Identification
For the client-side validation of presented TLS TACACS+ server For the client-side validation of presented TLS TACACS+ server
identities, implementations MUST follow [RFC9525] validation identities, implementations MUST follow the validation techniques
techniques. Identifier types DNS-ID, IP-ID, or SRV-ID are applicable defined in [RFC9525]. Identifier types DNS-ID, IP-ID, or SRV-ID are
for use with the TLS TACACS+ protocol, selected by operators applicable for use with the TLS TACACS+ protocol; they are selected
depending upon the deployment design. TLS TACACS+ does not use URI- by operators depending upon the deployment design. TLS TACACS+ does
IDs for TLS TACACS+ server identity verification. not use URI-IDs for TLS TACACS+ server identity verification.
Wildcards in TLS TACACS+ server identities simplify certificate Wildcards in TLS TACACS+ server identities simplify certificate
management by allowing a single certificate to secure multiple management by allowing a single certificate to secure multiple
servers in a deployment. However, this introduces security risks, as servers in a deployment. However, this introduces security risks, as
compromising the private key of a wildcard certificate impacts all compromising the private key of a wildcard certificate impacts all
servers using it. To address these risks, the guidelines in servers using it. To address these risks, the guidelines in
Section 6.3 of [RFC9525] MUST be followed, and the wildcard SHOULD be Section 6.3 of [RFC9525] MUST be followed, and the wildcard SHOULD be
confined to a subdomain dedicated solely to TACACS+ servers. confined to a subdomain dedicated solely to TACACS+ servers.
For the TLS TACACS+ server-side validation of client identities, For the TLS TACACS+ server-side validation of client identities,
implementations MUST support the ability to configure which fields of implementations MUST support the ability to configure which fields of
a certificate are used for client identification, to verify that the a certificate are used for client identification to verify that the
client is a valid source for the received certificate and that it is client is a valid source for the received certificate and that it is
permitted access to TACACS+. Implementations MUST support either: permitted access to TACACS+. Implementations MUST support either:
Network address based validation methods as described in Section 5.2 * Network-address-based validation methods as described in
of [RFC5425]. Section 5.2 of [RFC5425] or
or
Client Identity validation of a shared identity in the certificate * Client Identity validation of a shared identity in the certificate
subjectAltName. This is applicable in deployments where the client subjectAltName. This is applicable in deployments where the
securely supports an identity which is shared with the TLS TACACS+ client securely supports an identity which is shared with the TLS
server. Matching of dNSName and iPAddress MUST be supported. Other TACACS+ server. Matching of dNSName and iPAddress MUST be
options defined in Section 4.2.1.6 of [RFC5280] MAY be supported. supported. Other options defined in Section 4.2.1.6 of [RFC5280]
This approach allows a client's network location to be reconfigured MAY be supported. This approach allows a client's network
without issuing a new client certificate. location to be reconfigured without issuing a new client
certificate.
Implementations MUST support the TLS Server Name Indication extension Implementations MUST support the TLS Server Name Indication (SNI)
(SNI) (Section 3 of [RFC6066]). TLS TACACS+ clients MUST support the extension (Section 3 of [RFC6066]). TLS TACACS+ clients MUST support
ability to configure the TLS TACACS+ server's domain name, so that it the ability to configure the TLS TACACS+ server's domain name, so
may be included in the SNI "server_name" extension of the client that it may be included in the SNI "server_name" extension of the
hello (This is distinct from the IP Address or hostname configuration client hello (This is distinct from the IP Address or hostname
used for the TCP connection). Refer to Section 5.1.5 for security configuration used for the TCP connection). Refer to Section 5.1.5
related operator considerations. for security related operator considerations.
Certificate provisioning is out of scope of this document. Certificate provisioning is out of scope of this document.
3.4.3. Cipher Suites Requirements 3.4.3. Cipher Suites Requirements
Implementations MUST support the TLS 1.3 mandatory cipher suites Implementations MUST support the TLS 1.3 mandatory cipher suites
(Section 9.1 of [RFC8446]). Readers should refer to [BCP195]. The (Section 9.1 of [RFC8446]). Readers should refer to [BCP195]. The
cipher suites offered or accepted SHOULD be configurable so that cipher suites offered or accepted SHOULD be configurable so that
operators can adapt. operators can adapt.
3.5. TLS PSK Authentication 3.5. TLS PSK Authentication
As an alternative to certificate-based authentication, As an alternative to certificate-based authentication,
implementations MAY support PSKs, also known as External PSKs in TLS implementations MAY support PSKs, also known as external PSKs in TLS
1.3 [RFC8446]. These should not be confused with resumption PSKs. 1.3 [RFC8446]. These should not be confused with resumption PSKs.
The use of External PSKs is less well established than certificate- The use of external PSKs is less well established than certificate-
based authentication. It is RECOMMENDED that systems follow the based authentication. It is RECOMMENDED that systems follow the
directions of [RFC9257] and Section 4 of [RFC8446]. directions of [RFC9257] and Section 4 of [RFC8446].
Where PSK Authentication is implemented, PSK lengths of at least 16 Where PSK authentication is implemented, PSK lengths of at least 16
octets MUST be supported. octets MUST be supported.
PSK Identity MUST follow recommendations of Section 6.1 of [RFC9257]. PSK identity MUST follow recommendations of Section 6.1 of [RFC9257].
Implementations MUST support PSK identities of at least 16 octets. Implementations MUST support PSK identities of at least 16 octets.
Although this document removes the option of MD5 obfuscation Although this document removes the option of MD5 obfuscation
(Section 4), it is still possible that the TLS and Non-TLS versions (Section 4), it is still possible that the TLS and non-TLS versions
of TACACS+ may exist in an organization, for example, during of TACACS+ exist in an organization, for example, during migration
migration (Section 6.1). In such cases, the shared secrets (Section 6.1). In such cases, the shared secrets configured for
configured for TACACS+ obfuscation clients MUST NOT be the same as TACACS+ obfuscation clients MUST NOT be the same as the PSKs
the PSKs configured for TLS clients. configured for TLS clients.
3.6. TLS Resumption 3.6. TLS Resumption
The TLS Resumption protocol, detailed in [RFC8446], can minimize the The TLS Resumption protocol, detailed in [RFC8446], can minimize the
number of round trips required during the handshake process. If a number of round trips required during the handshake process. If a
TLS client holds a ticket previously extracted from a TLS client holds a ticket previously extracted from a
NewSessionTicket message from the TLS TACACS+ server, it can use the NewSessionTicket message from the TLS TACACS+ server, it can use the
PSK identity tied to that ticket. If the TLS TACACS+ server PSK identity tied to that ticket. If the TLS TACACS+ server
consents, the resumed session is acknowledged as authenticated and consents, the resumed session is acknowledged as authenticated and
securely linked to the initial session. securely linked to the initial session.
skipping to change at page 10, line 28 skipping to change at line 436
The resumption ticket_lifetime SHOULD be configurable, including a The resumption ticket_lifetime SHOULD be configurable, including a
zero seconds lifetime. Refer to Section 4.6.1 of [RFC8446] for zero seconds lifetime. Refer to Section 4.6.1 of [RFC8446] for
guidance on ticket lifetime. guidance on ticket lifetime.
4. Obsolescence of TACACS+ Obfuscation 4. Obsolescence of TACACS+ Obfuscation
[RFC8907] describes the obfuscation mechanism, documented in [RFC8907] describes the obfuscation mechanism, documented in
Section 5.2 of [RFC5425]. Such a method is weak. Section 5.2 of [RFC5425]. Such a method is weak.
The introduction of TLS authentication and encryption to TACACS+ The introduction of TLS authentication and encryption to TACACS+
replaces this former mechanism and so obfuscation is hereby replaces this former mechanism, so obfuscation is hereby obsoleted.
obsoleted. This section describes how the TACACS+ client and servers This section describes how the TACACS+ client and servers MUST
MUST operate regarding the obfuscation mechanism. operate regarding the obfuscation mechanism.
Peers MUST NOT use obfuscation with TLS. Peers MUST NOT use obfuscation with TLS.
A TACACS+ client initiating a TACACS+ TLS connection MUST set the A TACACS+ client initiating a TACACS+ TLS connection MUST set the
TAC_PLUS_UNENCRYPTED_FLAG bit, thereby asserting that obfuscation is TAC_PLUS_UNENCRYPTED_FLAG bit, thereby asserting that obfuscation is
not used for the session. All subsequent packets MUST have the not used for the session. All subsequent packets MUST have the
TAC_PLUS_UNENCRYPTED_FLAG bit set to 1. TAC_PLUS_UNENCRYPTED_FLAG bit set to 1.
A TLS TACACS+ server that receives a packet with the A TLS TACACS+ server that receives a packet with the
TAC_PLUS_UNENCRYPTED_FLAG bit not set to 1 over a TLS connection, TAC_PLUS_UNENCRYPTED_FLAG bit not set to 1 over a TLS connection MUST
MUST return an error of TAC_PLUS_AUTHEN_STATUS_ERROR, return an error of TAC_PLUS_AUTHEN_STATUS_ERROR,
TAC_PLUS_AUTHOR_STATUS_ERROR, or TAC_PLUS_ACCT_STATUS_ERROR as TAC_PLUS_AUTHOR_STATUS_ERROR, or TAC_PLUS_ACCT_STATUS_ERROR as
appropriate for the TACACS+ message type, with the appropriate for the TACACS+ message type, with the
TAC_PLUS_UNENCRYPTED_FLAG bit set to 1, and terminate the session. TAC_PLUS_UNENCRYPTED_FLAG bit set to 1, and terminate the session.
This behavior corresponds to that defined in Section 4.5 of [RFC8907] This behavior corresponds to that defined in Section 4.5 of [RFC8907]
Data Obfuscation for TAC_PLUS_UNENCRYPTED_FLAG or key mismatches. regarding Data Obfuscation for TAC_PLUS_UNENCRYPTED_FLAG or key
mismatches.
A TACACS+ client that receives a packet with the A TACACS+ client that receives a packet with the
TAC_PLUS_UNENCRYPTED_FLAG bit not set to 1 MUST terminate the TAC_PLUS_UNENCRYPTED_FLAG bit not set to 1 MUST terminate the
session, and SHOULD log this error. session, and SHOULD log this error.
5. Security Considerations 5. Security Considerations
5.1. TLS 5.1. TLS
This document improves the confidentiality, integrity, and This document improves the confidentiality, integrity, and
skipping to change at page 11, line 25 skipping to change at line 481
for the operators and equipment vendors to adhere to the latest best for the operators and equipment vendors to adhere to the latest best
practices for ensuring the integrity of network devices and selecting practices for ensuring the integrity of network devices and selecting
secure TLS key and encryption algorithms. secure TLS key and encryption algorithms.
[BCP195] offers substantial guidance for implementing protocols that [BCP195] offers substantial guidance for implementing protocols that
use TLS and their deployment. Those implementing and deploying use TLS and their deployment. Those implementing and deploying
Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3 Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3
outlined in [BCP195] or its subsequent versions. outlined in [BCP195] or its subsequent versions.
This document outlines additional restrictions permissible under This document outlines additional restrictions permissible under
[BCP195] For example, any recommendations referring to TLS 1.2, [BCP195]. For example, any recommendations referring to TLS 1.2,
including the mandatory support, are not relevant for Secure TACACS+ including the mandatory support, are not relevant for Secure TACACS+
as TLS 1.3 or above is mandated. as TLS 1.3 or above is mandated.
This document concerns the use of TLS as transport for TACACS+, and This document concerns the use of TLS as transport for TACACS+ and
does not make any changes to the core TACACS+ protocol, other than does not make any changes to the core TACACS+ protocol, other than
the direct implications of deprecating obfuscation. Operators MUST the direct implications of deprecating obfuscation. Operators MUST
be cognizant of the security implications of the TACACS+ protocol be cognizant of the security implications of the TACACS+ protocol
itself. Further documents are planned, for example, to address the itself. Further documents are planned, for example, to address the
security implications of password based authentication and enhance security implications of password-based authentication and enhance
the protocol to accommodate alternative schemes. the protocol to accommodate alternative schemes.
5.1.1. TLS Use 5.1.1. TLS Use
New TACACS+ production deployments SHOULD use TLS authentication and New TACACS+ production deployments SHOULD use TLS authentication and
encryption. Also see [RFC3365]. encryption. Also see [RFC3365].
TLS TACACS+ servers (as defined in Section 2) MUST NOT allow Non-TLS TLS TACACS+ servers (as defined in Section 2) MUST NOT allow non-TLS
connections, because of the threat of downgrade attacks or connections, because of the threat of downgrade attacks or
misconfiguration described in Section 5.3. Instead, separate Non-TLS misconfiguration described in Section 5.3. Instead, separate non-TLS
TACACS+ servers SHOULD be set up to cater for these clients. TACACS+ servers SHOULD be set up to cater for these clients.
It is NOT RECOMMENDED that TLS TACACS+ servers and Non-TLS TACACS+ It is NOT RECOMMENDED that TLS TACACS+ servers and non-TLS TACACS+
servers be deployed on the same host, for reasons discussed in servers be deployed on the same host, for reasons discussed in
Section 5.3. Non-TLS connections would be better served by deploying Section 5.3. Non-TLS connections would be better served by deploying
the required Non-TLS TACACS+ servers on separate hosts. the required non-TLS TACACS+ servers on separate hosts.
TACACS+ Clients MUST NOT fail back to a Non-TLS connection if a TLS TACACS+ clients MUST NOT fail back to a non-TLS connection if a TLS
connection fails. This prohibition includes during the migration of connection fails. This prohibition includes during the migration of
a deployment (Section 6.1). a deployment (Section 6.1).
5.1.2. TLS 0-RTT 5.1.2. TLS 0-RTT
TLS 1.3 resumption and PSK techniques make it possible to send Early 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 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 completes. Replay of this data is a risk. Given the sensitivity of
TACACS+ data, clients MUST NOT send data until the full TLS handshake 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+ completes; that is, clients MUST NOT send 0-RTT data and TLS TACACS+
servers MUST abruptly disconnect clients that do. servers MUST abruptly disconnect clients that do.
TLS TACACS+ clients and servers MUST NOT include the "early_data" TLS TACACS+ clients and servers MUST NOT include the "early_data"
extension. See sections 2.3 and 4.2.10 of [RFC8446] for security extension. See Sections 2.3 and 4.2.10 of [RFC8446] for security
concerns. concerns.
5.1.3. TLS Options 5.1.3. TLS Options
Recommendations in [BCP195] MUST be followed to determine which TLS Recommendations in [BCP195] MUST be followed to determine which TLS
versions and algorithms should be supported, deprecated, obsoleted, versions and algorithms should be supported, deprecated, obsoleted,
or abandoned. or abandoned.
Also, Section 9 of [RFC8446] prescribes mandatory supported options. Also, Section 9 of [RFC8446] prescribes mandatory supported options.
skipping to change at page 12, line 49 skipping to change at line 552
5.1.5. TLS Server Name Indicator (SNI) 5.1.5. TLS Server Name Indicator (SNI)
Operators should be aware that the TLS SNI extension is part of the Operators should be aware that the TLS SNI extension is part of the
TLS client hello, which is sent in cleartext. It is, therefore, TLS client hello, which is sent in cleartext. It is, therefore,
subject to eavesdropping. Also see Section 11.1 of [RFC6066]. subject to eavesdropping. Also see Section 11.1 of [RFC6066].
5.1.6. Server Identity Wildcards 5.1.6. Server Identity Wildcards
The use of wildcards in TLS server identities creates a single point The use of wildcards in TLS server identities creates a single point
of failure: a compromised private key of a wildcard certificate of failure: a compromised private key of a wildcard certificate
impacts all servers using it. Their use MUST follow recommendations impacts all servers using it. Their use MUST follow the
of Section 7.1 of [RFC9525]. Operators MUST ensure that the wildcard recommendations of Section 7.1 of [RFC9525]. Operators MUST ensure
is limited to a subdomain dedicated solely to TLS TACACS+ servers. that the wildcard is limited to a subdomain dedicated solely to TLS
Further, operators MUST ensure that the TLS TACACS+ servers covered TACACS+ servers. Further, operators MUST ensure that the TLS TACACS+
by a wildcard certificate MUST be impervious to redirection of servers covered by a wildcard certificate MUST be impervious to
traffic to a different server (for example, due to on-path attacks or redirection of traffic to a different server (for example, due to on-
DNS cache poisoning). path attacks or DNS cache poisoning).
5.2. TACACS+ Configuration 5.2. TACACS+ Configuration
Implementors must ensure that the configuration scheme introduced for Implementors must ensure that the configuration scheme introduced for
enabling TLS is straightforward and leaves no room for ambiguity enabling TLS is straightforward and leaves no room for ambiguity
regarding whether TLS or Non-TLS will be used between the TACACS+ regarding whether TLS or non-TLS will be used between the TACACS+
client and the TACACS+ server. client and the TACACS+ server.
This document recommends the use of a separate port number that TLS This document recommends the use of a separate port number that TLS
TACACS+ servers will listen to. Where deployments have not TACACS+ servers will listen to. Where deployments have not
overridden the defaults explicitly, TACACS+ client implementations overridden the defaults explicitly, TACACS+ client implementations
MUST use the correct values: MUST use the correct port values:
* for Non-TLS connection TACACS+: Port number 49. * 49: for non-TLS connection TACACS+
* for TLS connection TACACS+: (TBD). * 300: for TLS connection TACACS+
Implementors may offer a single option for TACACS+ clients and Implementors may offer a single option for TACACS+ clients and
servers to disable all Non-TLS TACACS+ operations. When enabled on a 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+ server, it will not respond to any requests from non-TLS
TACACS+ client connections. When enabled on a TACACS+ client, it TACACS+ client connections. When enabled on a TACACS+ client, it
will not establish any Non-TLS TACACS+ server connections. will not establish any non-TLS TACACS+ server connections.
5.3. Well-Known TCP/IP Port Number 5.3. Well-Known TCP/IP Port Number
A new port number is considered appropriate (rather than a mechanism A new port number is considered appropriate (rather than a mechanism
that negotiates an upgrade from an initial Non-TLS TACACS+ that negotiates an upgrade from an initial non-TLS TACACS+
Connection) because it allows: connection) because it allows:
* ease of blocking the unobfuscated or obfuscated connections by the * ease of blocking the unobfuscated or obfuscated connections by the
TCP/IP port number, TCP/IP port number,
* passive Intrusion Detection Systems (IDSs) monitoring the * passive Intrusion Detection Systems (IDSs) monitoring the
unobfuscated to be unaffected by the introduction of TLS, unobfuscated to be unaffected by the introduction of TLS,
* avoidance of on-path attacks that can interfere with upgrade, and * avoidance of on-path attacks that can interfere with upgrade, and
* prevention of the accidental exposure of sensitive information due * prevention of the accidental exposure of sensitive information due
to misconfiguration. to misconfiguration.
However, co-existence of inferior authentication and obfuscated, However, the coexistence of inferior authentication and obfuscation,
whether a Non-TLS connection or deprecated parts that compose TLS, whether a non-TLS connection or deprecated parts that compose TLS,
also presents opportunity for down-grade attacks. Causing failure of also presents an opportunity for downgrade attacks. Causing failure
connections to the TLS-enabled service or the negotiation of shared of connections to the TLS-enabled service or the negotiation of
algorithm support are two such down-grade attacks. shared algorithm support are two such downgrade attacks.
The simplest mitigation exposure from Non-TLS connection methods is The simplest mitigation exposure from non-TLS connection methods is
to refuse Non-TLS connections at the host entirely, perhaps using to refuse non-TLS connections at the host entirely, perhaps using
separate hosts for Non-TLS connections and TLS. separate hosts for non-TLS connections and TLS.
Another approach is mutual configuration that requires TLS. TACACS+ Another approach is mutual configuration that requires TLS. TACACS+
clients and servers SHOULD support configuration that requires peers, clients and servers SHOULD support configuration that requires peers,
globally and individually, use TLS. Furthermore, peers SHOULD be globally and individually, to use TLS. Furthermore, peers SHOULD be
configurable to limit offered or recognized TLS versions and configurable to limit offered or recognized TLS versions and
algorithms to those recommended by standards bodies and implementers. algorithms to those recommended by standards bodies and implementers.
6. Operational Considerations 6. Operational Considerations
Operational and deployment considerations are spread throughout the Operational and deployment considerations are spread throughout the
document. While avoiding repetition, it is useful for the impatient document. While avoiding repetition, it is useful for the impatient
to direct particular attention to Sections 5.2 and 5.1.5. However, to direct particular attention to Sections 5.2 and 5.1.5. However,
it is important that the entire Section 5 is observed. it is important that the entire Section 5 is observed.
It is essential for operators to understand the implications of a TLS It is essential for operators to understand the implications of a TLS
certificate-based authentication solution, including the correct certificate-based authentication solution, including the correct
handling of certificates, CAs, and all elements of TLS configuration. handling of certificates, CAs, and all elements of TLS configuration.
Refer to [BCP195] for guidance. Attention is drawn to the Refer to [BCP195] for guidance. Attention is drawn to the
provisioning of Certificates to all peers, including TACACS+ TLS provisioning of certificates to all peers, including TACACS+ TLS
clients, to permit the mandatory mutual authentication. clients, to permit the mandatory mutual authentication.
6.1. Migration 6.1. Migration
Section 5.2 mentions that for an optimal deployment of TLS TACACS+, Section 5.2 mentions that for an optimal deployment of TLS TACACS+,
TLS should be universally applied throughout the deployment. TLS should be universally applied throughout the deployment.
However, during the migration process from a Non-TLS TACACS+ However, during the migration process from a non-TLS TACACS+
deployment, operators may need to support both TLS and Non-TLS deployment, operators may need to support both TLS and non-TLS
TACACS+ servers. This migration phase allows operators to gradually TACACS+ servers. This migration phase allows operators to gradually
transition their deployments from an insecure state to a more secure transition their deployments from an insecure state to a more secure
one, but it is important to note that it is vulnerable to downgrade one, but it is important to note that it is vulnerable to downgrade
attacks. Therefore, the migration phase should be considered attacks. Therefore, the migration phase should be considered
insecure until it is fully completed. To mitigate this hazard: insecure until it is fully completed. To mitigate this hazard:
* The period where any client is configured with both TLS and Non- * The period where any client is configured with both TLS and non-
TLS TACACS+ servers should be minimized. TLS TACACS+ servers should be minimized.
* The operator must consider the impact of mixed TLS and Non-TLS on * The operator must consider the impact of mixed TLS and non-TLS on
security, as mentioned above. security, as mentioned above.
6.2. Maintaining Non-TLS TACACS+ Clients 6.2. Maintaining Non-TLS TACACS+ Clients
Some TACACS+ client devices in a deployment may not implement TLS. Some TACACS+ client devices in a deployment may not implement TLS.
These devices will require access to Non-TLS TACACS+ servers. These devices will require access to non-TLS TACACS+ servers.
Operators must follow the recommendation of Section 5.1.1 and deploy Operators must follow the recommendation of Section 5.1.1 and deploy
separate Non-TLS TACACS+ servers for these Non-TLS clients from those separate non-TLS TACACS+ servers for these non-TLS clients from those
used for the TLS clients. used for the TLS clients.
6.3. YANG Model for TACACS+ Clients 6.3. YANG Model for TACACS+ Clients
[ietf-opsawg-secure-tacacs-yang] specifies a YANG model for managing [TACACS-YANG] specifies a YANG model for managing TACACS+ clients,
TACACS+ clients, including TLS support. including TLS support.
7. IANA Considerations 7. IANA Considerations
IANA (has allocated) is requested to allocate a new well-known system IANA has allocated a new well-known system TCP/IP port number (300)
TCP/IP port number ([TBD]) for the service name "tacacss", described for the service name "tacacss", described as "TACACS+ over TLS". The
as "TACACS+ over TLS". The service name "tacacss" follows the common service name "tacacss" follows the common practice of appending an
practice of appending an "s" to the name given to the Non-TLS well- "s" to the name given to the non-TLS well-known port name. This
known port name. This allocation is justified in Section 5.3. allocation is justified in Section 5.3.
IANA (has added) is requested to add tacacss as a new entry to the
"Service name and Transport Protocol Port Number Registry" available
at https://www.iana.org/assignments/service-names-port-numbers/
Service Name: tacacss
Port Number: [TBD]
Transport Protocol: TCP
Description: TLS Secure Login Host Protocol (TACACSS)
Assignee: IESG
Contact: IETF Chair
Reference: [TBD] (This Document) IANA has added the following entry to the "Service Name and Transport
Protocol Port Number Registry" (see
<https://www.iana.org/assignments/service-names-port-numbers>).
RFC EDITOR: this port number should replace "[TBD]" within this Service Name: tacacss
document. 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 Considerations about service discovery are out of scope of this
document. document.
8. Acknowledgments 8. Acknowledgments
The author(s) would like to thank Russ Housley, Steven M. Bellovin, The author(s) would like to thank Russ Housley, Steven M. Bellovin,
Stephen Farrell, Alan DeKok, Warren Kumari, Tom Petch, Tirumal Reddy, Stephen Farrell, Alan DeKok, Warren Kumari, Tom Petch, Tirumal Reddy,
Valery Smyslov, and Mohamed Boucadair for their support, insightful Valery Smyslov, and Mohamed Boucadair for their support, insightful
review, and/or comments. [RFC5425] was also used as a basis for the review, and/or comments. [RFC5425] was also used as a basis for the
general approach to TLS. [RFC9190] was used as a basis for TLS general approach to TLS. [RFC9190] was used as a basis for TLS
Resumption Recommendations. Although still in draft form at the time resumption recommendations. Although still in draft form at the time
of writing, [I-D.ietf-radext-tls-psk] was used as a model for PSK of writing, [RFC9813] was used as a model for PSK recommendations.
Recommendations.
9. Normative References 9. References
9.1. Normative References
[BCP195] Best Current Practice 195, [BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>. <https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following: At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati, Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>. 2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 17, line 34 skipping to change at line 761
[RFC8907] Dahm, T., Ota, A., Medway Gash, D.C., Carrel, D., and L. [RFC8907] Dahm, T., Ota, A., Medway Gash, D.C., Carrel, D., and L.
Grant, "The Terminal Access Controller Access-Control Grant, "The Terminal Access Controller Access-Control
System Plus (TACACS+) Protocol", RFC 8907, System Plus (TACACS+) Protocol", RFC 8907,
DOI 10.17487/RFC8907, September 2020, DOI 10.17487/RFC8907, September 2020,
<https://www.rfc-editor.org/info/rfc8907>. <https://www.rfc-editor.org/info/rfc8907>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023, RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>. <https://www.rfc-editor.org/info/rfc9525>.
10. Informative References 9.2. Informative References
[FIPS-140-3] [FIPS-140-3]
National Institute of Standards and Technology, U.S. NIST, "Security Requirements for Cryptographic Modules",
Department of Commerce, "NIST Federal Information NIST FIPS 140-3, DOI 10.6028/NIST.FIPS.140-3, March 2019,
Processing Standards (FIPS) Publication 140-3", <https://nvlpubs.nist.gov/nistpubs/FIPS/
<https://csrc.nist.gov/pubs/fips/140-3/final>. NIST.FIPS.140-3.pdf>.
[I-D.ietf-radext-tls-psk]
DeKok, A., "Operational Considerations for RADIUS and TLS-
PSK", Work in Progress, Internet-Draft, draft-ietf-radext-
tls-psk-12, 21 January 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-
tls-psk-12>.
[I-D.ietf-uta-require-tls13] [REQ-TLS13]
Salz, R. and N. Aviram, "New Protocols Using TLS Must Salz, R. and N. Aviram, "New Protocols Using TLS Must
Require TLS 1.3", Work in Progress, Internet-Draft, draft- Require TLS 1.3", Work in Progress, Internet-Draft, draft-
ietf-uta-require-tls13-12, 14 April 2025, ietf-uta-require-tls13-12, 14 April 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-uta- <https://datatracker.ietf.org/doc/html/draft-ietf-uta-
require-tls13-12>. require-tls13-12>.
[ietf-opsawg-secure-tacacs-yang]
Boucadair, M., Ed., Wu, B., Zheng, G., and M. Wang, "A
YANG Data Model for Terminal Access Controller Access-
Control System Plus (TACACS+)",
<https://datatracker.ietf.org/doc/draft-ietf-opsawg-
secure-tacacs-yang/>.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet [RFC3365] Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", BCP 61, Engineering Task Force Standard Protocols", BCP 61,
RFC 3365, DOI 10.17487/RFC3365, August 2002, RFC 3365, DOI 10.17487/RFC3365, August 2002,
<https://www.rfc-editor.org/info/rfc3365>. <https://www.rfc-editor.org/info/rfc3365>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011, RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>. <https://www.rfc-editor.org/info/rfc6151>.
[RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the [RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
Extensible Authentication Protocol with TLS 1.3", Extensible Authentication Protocol with TLS 1.3",
RFC 9190, DOI 10.17487/RFC9190, February 2022, RFC 9190, DOI 10.17487/RFC9190, February 2022,
<https://www.rfc-editor.org/info/rfc9190>. <https://www.rfc-editor.org/info/rfc9190>.
[RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood, [RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood,
"Guidance for External Pre-Shared Key (PSK) Usage in TLS", "Guidance for External Pre-Shared Key (PSK) Usage in TLS",
RFC 9257, DOI 10.17487/RFC9257, July 2022, RFC 9257, DOI 10.17487/RFC9257, July 2022,
<https://www.rfc-editor.org/info/rfc9257>. <https://www.rfc-editor.org/info/rfc9257>.
[RFC9813] DeKok, A., "Operational Considerations for Using TLS Pre-
Shared Keys (TLS-PSKs) with RADIUS", BCP 243, RFC 9813,
DOI 10.17487/RFC9813, July 2025,
<https://www.rfc-editor.org/info/rfc9813>.
[TACACS-YANG]
Boucadair, M. and B. Wu, "A YANG Data Model for Terminal
Access Controller Access-Control System Plus (TACACS+)",
Work in Progress, Internet-Draft, draft-ietf-opsawg-
secure-tacacs-yang-13, 7 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
secure-tacacs-yang-13>.
Authors' Addresses Authors' Addresses
Thorsten Dahm Thorsten Dahm
Email: thorsten.dahm@gmail.com Email: thorsten.dahm@gmail.com
John Heasley John Heasley
NTT NTT
Email: heas@shrubbery.net Email: heas@shrubbery.net
Douglas C. Medway Gash Douglas C. Medway Gash
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
United States of America United States of America
Email: dcmgash@cisco.com Email: dcmgash@cisco.com
Andrej Ota Andrej Ota
Google Inc. Google Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
 End of changes. 84 change blocks. 
263 lines changed or deleted 257 lines changed or added

This html diff was produced by rfcdiff 1.48.