| Internet-Draft | The Terminal Access Controller Access-Co | March 2024 |
| Dahm, et al. | Expires 21 September 2024 | [Page] |
The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol [RFC8907] provides device administration for routers, network access servers and other networked computing devices via one or more centralized servers. This document adds Transport Layer Security (TLS 1.3) support and obsoletes former inferior security mechanisms.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP14] when, and only when, they appear in all capitals, as shown here.¶
This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 September 2024.¶
Copyright (c) 2024 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 (https://trustee.ietf.org/license-info) 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.¶
The Terminal Access Controller Access-Control System Plus (TACACS+)+ Protocol [RFC8907] provides device administration for routers, network access servers and other networked computing devices via one or more centralized servers. The protocol provides authentication, authorization and accounting services (AAA) for TACACS+ clients within the device administration use case.¶
While the content of the protocol is highly sensitive, TACACS+ lacks modern and/or effective confidentiality, integrity, and authentication of the connection and network traffic between the server and client, requiring secure transport to safeguard the deployment. The existing TACACS+ mechanisms are extremely weak as described in section 10 of TACACS+ Protocol [RFC8907].¶
To address these deficiencies, this document updates the TACACS+ protocol to use TLS 1.3 [RFC8446] authentication and encryption, and obsoletes the use of its former mechanisms.¶
The terms defined in section 3 of TACACS+ Protocol [RFC8907] are fully applicable here and will not be repeated. The following terms are also used in this document.¶
Obfuscation is the inferior form of encryption used in TACACS+, labelled as such in [RFC8907], Section 10.5.2 to indicate that it is not encryption and is insufficient.¶
This is another term for a connection defined in the historic TACACS+ Protocol [RFC8907]. It is a connection without TLS and therefore being plaintext or possibly using unsecure TACACS+ authentication and obfuscation. The use of well-known TCP/IP server port 49 is specified as the default for Non-TLS connections. Non-TLS connections SHOULD NOT be used for new TACACS+ deployments.¶
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.¶
A TACACS+ server is an instance of the server as defined in [RFC8907], Section 3.2 that responds to TACACS+ traffic on a specific port in a host. This document distinguishes the TACACS+ server instance from the host itself. A host may have multiple TACACS+ servers installed, listening to different ports.¶
The peer of a TACACS+ client (or server) in the context of a TACACS+ connection, is the server (or client). Together, the ends of a TACACS+ connection are referred as the peers.¶
TACACS+ over TLS takes the protocol defined in TACACS+ Protocol [RFC8907], removes the option for MD5 obfuscation, and specifies the use of TLS (version 1.3 or later) for transport using a new well-known default server port. The next sections provide further details and guidance.¶
TLS is introduced into TACACS+ to fulfill the following requirements:¶
All data exchanged by TACACS+ peers MUST be encrypted, including the authentication of the peers. Therefore, when a TCP connection is established for the service, a TLS handshake begins immediately.¶
To ensure separation of TACACS+ traffic that uses TLS from that which does not (see Section 5.3), TACACS+ over TLS will follow [RFC7605]. This entails dedicating separate TCP/IP ports to each protocol type. Additionally, considering the widespread use of default settings in numerous existing TACACS+ configurations, the designated port for TLS TACACS+ will be defined as a well-known system TCP/IP port assigned by IANA, port [TBD] (Section 7) with the service name [TBDN] (Section 7).¶
Under exceptional circumstances, this document permits any other TCP port to be configured when required by deployment specifics, but the implications in Section 5.3 MUST still be considered by operators.¶
A TACACS+ client initiates a TLS connection by making a TCP connection to a server on the TACACS+ TLS well-known port ([TBD]) (Section 3.1). Once the TCP connection is established, the client MUST immediately begin the TLS negotiation before sending any TACACS+ protocol data.¶
Implementations MUST support TLS 1.3 [RFC8446] and MAY permit TLS 1.3 session resumption. If resumption is supported, the resumption ticket_lifetime SHOULD be configurable, including a zero seconds lifetime.¶
Once the TLS connection is established, the exchange of TACACS+ data proceeds as normal, except that it is transmitted over TLS as TLS application data and without TACACS+ obfuscation (see Section 4)¶
The connection persists until the server or client closes it. It might be closed due to an error or at the conclusion of the TACACS+ session. If Single Connection Mode has been negotiated, it might remain open after a successful session, until an error or an inactivity timeout occurs. Why it closed has no bearing on TLS resumption, unless closed by a TLS error, in which case the ticket might be invalidated.¶
Implementations MUST support the TLS 1.3 mandatory cipher suites (See TLS 1.3 [RFC8446] Section 9.1). The cipher suites offered or accepted SHOULD be configurable so that operators can adapt.¶
This document makes no cipher suite recommendations, but recommendations can be found in the TLS Cipher Suites section of the [RFC9325].¶
Implementations MUST support certificate-based TLS authentication and certificate revocation bi-directionally for authentication, identity verification and policy purposes. Certificate path verification as described in Section 3.2.2.1 MUST be supported.¶
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 disconnect any peer that presents an invalid TLS Certificate.¶
Implementations MAY support TLS authentication with Pre-Shared Keys (PSKs), also known as external PSKs in TLS 1.3, which are not resumption PSKs. PSKs are considered out-of-scope for this document.¶
Implementations MUST support certificate Path verification as described in [RFC5280].¶
Because a peer could be isolated from a remote peer's Certificate Authority (CA), implementations MUST support certificate chains (aka. bundles or chains of trust), where the entire chain of the remote's certificate is stored on the local peer.¶
In addition to authentication of TLS certificates, implementations MUST allow operators to specify which certificate fields are to be used for peer-identification, to verify that the peer is a valid source for the received certificate and that it is permitted access to TACACS+. Implementations MUST support either:¶
Network location based validation methods as described in [RFC5425], Section 5.2.¶
or¶
Device Identity based validation methods where the peer's identity is used in the certificate subjectName. This is applicable in deployments where the device securely supports an identity which is shared with its peer. This approach allows a peer's network location to be reconfigured without issuing a new client certificate. Only the local server mapping needs to be updated.¶
Implementations SHOULD support the TLS Server Name Indication extension ([RFC6066], Section 3). Policy can be applied to this attribute and it can be useful for load balancing or multiplexing at the server.¶
Certificate Provisioning is out of scope of this document.¶
The original draft of TACACS+ [RFC8907] described the obfuscation mechanism, documented in [RFC5425], Section 5.2. It is insufficient for modern purposes.¶
The introduction of TLS PSK, certificate peer authentication, and TLS encryption to TACACS+ replaces these former mechanisms and so obfuscation is hereby obsoleted. This section describes how the TACACS+ client and servers MUST operate with regards to 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 set.¶
A TACACS+ server that receives a packet with the TAC_PLUS_UNENCRYPTED_FLAG not set (cleared) 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 set, and terminate the session. This behavior corresponds to that defined in RFC8907 Section 4.5. Data Obfuscation [RFC8907] for TAC_PLUS_UNENCRYPTED_FLAG or key mismatches.¶
A TACACS+ client that receives a packet with the TAC_PLUS_UNENCRYPTED_FLAG not set (cleared), MUST terminate the session, and SHOULD log this error.¶
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 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.¶
[RFC9325]. offers substantial guidance for implementing protocols that use TLS and their deployment. Those implementing and deploying Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3 outlined in [RFC9325], or its subsequent versions.¶
This document outlines additional restrictions permissible under [RFC9325]. 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.¶
TLS encryption SHOULD be used in deployments where both the clients and servers support it. TACACS+ servers that have TLS support MUST NOT allow non-TLS connections from clients that do not support TLS, because of the threat of downgrade attacks, as described in Section 5.2. Instead, separate non-TLS TACACS+ servers can be set up to cater for these clients.¶
Further, TLS TACACS+ servers and non-TLS TACACS+ servers SHOULD NOT be deployed on the same host. Non-TLS connections would be better served by deploying the required Non-TLS TACACS+ servers on separate hosts.¶
It is NOT RECOMMENDED to deploy TACACS+ without TLS authentication and encryption, including TLS using the NULL algorithm, except for within test and debug environments. Also see [RFC3365].¶
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 servers MAY abruptly disconnect clients that do.¶
Implementors and operators SHOULD make use of the various RFCs to determine which TLS versions and algorithms should be supported, deprecated, obsoleted, or abandoned, in the absence of updates to this document.¶
Recommendations in [RFC9325] Section 4, or any RFCs which obsolete it, MUST be followed.¶
Other useful examples are the TLS specifications themselves (TLS 1.3 [RFC8446]), which prescribes mandatory support in Section 9, and TLS Recommendations [RFC7525].¶
Operators SHOULD be cognizant of the potential of 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. Operators SHOULD consider loading certificate chains on devices and servers to avoid this failure.¶
Certificate caching and Raw Public Keys [RFC7250] are other methods to help address this, but both are out of scope for this document. Certificate fingerprints are another option.¶
Operators SHOULD be aware that the TLS SNI extension is part of the TLS client hello, and is therefore subject to eavesdropping. Also see [RFC6066], Section 11.1.¶
If TLS Encrypted Client Hello becomes standardized and applicable to TLS 1.3, then it SHOULD be included in Secure TACACS+ implementation.¶
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 introduces a separate port that TLS enabled TACACS+ servers will listen to. Where deployments have not overridden the defaults explicitly, TACACS+ client implementations MUST use the correct values:¶
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.¶
A new port is considered appropriate and superior to a "STARTTLS" command or other negotiation method because it allows:¶
However, co-existence of inferior authentication and obfuscated, whether an Non-TLS connection or deprecated parts that compose TLS, also presents opportunity for down-grade attacks. Causing failure of connections to the TLS-enabled service or the negotiation of shared algorithm support are two such down-grade attacks.¶
The simplest way to address exposure from Non-TLS connection methods is to refuse Non-TLS connections at the server entirely, perhaps using separate servers for Non-TLS connections and TLS.¶
Another approach is mutual configuration that requires TLS. Clients and servers SHOULD support configuration that requires peers, globally and individually, 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 and deployment considerations are spread throughout the document. While avoiding repetition, it is useful for the impatient to direct particular attention to Section 5.2 and Section 5.1.5. However, it is important that the entire Section 5 is observed.¶
In section 5.2, it is mentioned 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:¶
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 Section 5.1.1 and deploy separate TACACS+ servers for these Non-TLS clients from those used for the TLS clients.¶
The authors request that, when this draft is accepted by the working group, the OPSAWG Chairs submit a request to IANA for an early allocation, per [RFC4020] and [RFC6335], of a new well-known system TCP/IP port number for the service name "tacacss" (referenced in this document also as "TACACS+ TLS well-known port ([TBD])"), described as "TACACS+ over TLS". The service name "tacacss" follows the common practice of appending an "s" to the name given to the non-TLS well-known port name. This allocation is justified in Section 5.3.¶
RFC EDITOR: this port number should replace "[TBD]" and the service name should replace "[TBDN]" within this document.¶
The author(s) would like to thank Russ Housley, Steven M. Bellovin, Stephen Farrell, Alan DeKok, Warren Kumari, Tom Petch and Mohamed Boucadair for their support, insightful review, and/or comments. [RFC5425] was also used as a basis for the approach to TLS.¶