TACACS+ TLS 1.3

The TACACS+ Protocol 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 for TACACS+ clients. 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. The existing mechanisms of TACACS+ are extremely weak and the Security Considerations section of the TACACS+ Protocol adequately describes this. To address these deficiencies, this document updates the TACACS+ Protocol to use TLS 1.3 authentication and encryption, and obsoletes the use of its former mechanisms.

The Technical Definitions section of the TACACS+ Protocol is fully applicable here and will not be repeated. The following terms are also used in this document.

This is another term for a Connection as defined in TACACS+ Protocol. It is a Connection without TLS and therefore being plaintext or possibly using unsecure TACACS+ authentication and obfuscation.

A TLS Connection is a TCP/IP connection with TLS authentication and encryption used by TACACS+ for transport. The TLS Connection for TACACS+ is always between one Client and one Server as defined in TACACS+ Protocol.

In the context of a TLS Connection, the peer of a TACACS+ Client is the Server, and the peer is the TACACS+ Server is the Client. Together, the ends of a TLS Connection are referred as the peers.

Inferior form of encryption used in TACACS+, referred to as obfuscation in to indicate that it is not encryption and is utterly insufficient.

TACACS+ connections are TCP/IP connections initiated by the Client to the Server. The well-known TCP/IP port 49 on the Server is used for unobfuscated and obfuscated connections as defined in the TACACS+ Protocol. A connection might be used for only a single Session or the multiplexing of multiple Sessions in TACACS+ Single Connection Mode. TLS is introduced into TACACS+ to fulfill the following requirements:

Confidentiality and Integrity: The MD5 obfuscation specified in the original protocol definition is not fit for purpose, requiring that TACACS+ be deployed over a secured network. Securing TACACS+ protocol with TLS is intended to provide confidentiality and integrity without requiring the provision of a secured network.
Peer authentication: The use of shared keys to add and remove the MD5 obfuscation was intended to provide a form of Peer authentication for the TACACS+ protocol. This document obsoletes the MD5 obfuscation, and specifies that the authentication capabilities of TLS are used to allow the Peers to authenticate each other.

All data exchanged by TACACS+ Peers MUST be encrypted, including the authentication of the Peers. Therefore, TLS Hello MUST be initiated by the client immediately upon the establishment of the TCP/IP connection. This document favors the predictable use of TLS security for a deployment, see (). TACACS+ TLS will therefore follow , where a different well-known system TCP/IP port is assigned by IANA, port [TBD] with the service name [TBDN], for TLS connections. TACACS+ TLS could use any other TCP port by operator configuration, though should still be considered.

A TACACS+ Client initiates a TLS connection by making a TCP connection to a configured Server on the TACACS+ TLS well-known port ([TBD]) (). 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 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 ) 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 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 .

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 MUST be supported. If this 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 a Peer that offers an invalid TLS Certificate.

Implementations MUST support certificate Path verification as described in . 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 support policy consideration of Peer-identifying certificate fields and policy used 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 . 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 Inidication extension (). Policy can be applied to this attribute and it can be useful for load balancing or multiplexing at the server.

The original draft of TACACS+ described the Obfuscation mechanism, documented in . 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 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. This does not in itself protect the server nor clients; the operator and equipment vendors have a role. That role is to follow current best practices for maintaining the integrity of network devices and selection of TLS key and encryption algorithms.

No single and timely TLS recommendations document exists. Therefore, implementers and operators SHOULD refer to TLS RFCs to ensure the versions are current and which algorithms should be supported, deprecated, obsoleted, or abandoned, in the absence of updates to this document. Useful examples are the TLS specifications themselves (TLS 1.3), which prescribes mandatory support in Section 9, and TLS Recommendations .

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 possible. Given the sensitivity of TACACS+ data, a Client 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.

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 SHOULD NOT be shared among Clients or Servers to limit exposure of a compromised key and to ease key rotation. Also see and . PSKs are otherwise considered out-of-scope for this document.

This section outlines considerations which are specific to operators. It is important that operators ensure their deployments address the considerations in .

TLS encryption SHOULD be used in deployments when both the Clients and Servers support it. In order to prevent downgrade attacks, Servers SHOULD keep separate and disjoint lists of clients supporting TLS and Unsecure Connections. Unsecure Connections would be better served by separate Servers from the TLS Servers. 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 .

When Migrating from legacy service to TLS, any mixture of Unsecure Connected Servers and TLS-Protected Servers in the same redundant lists on clients SHOULD be minimised. After migration, the production deployment SHOULD NOT mix Legacy and TLS-Protected Servers within Server lists configured on clients.

All clients and servers in a deployment should be configured with consistent algorithm and cypher options to prevent harm from downgrade attacks. 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.

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 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 .

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 and , 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 . RFC EDITOR: this port number should replace "[TBD]" and the service name should replace "[TBDN]" within this document.

The authors concluded that a new port is considered superior to negotiation of TLS using "STARTTLS" command because:

it allows easy blocking the unobfuscated or obfuscated connections by the TCP/IP port number,
passive Intrusion Detection Systems (IDSs) monitoring the unobfuscated deployments will be unaffected by the introduction of TLS,
Man in the Middle (MitM) attacks that can interfere with STARTTLS will be avoided
helps prevent the accidental exposure of sensitive information due to misconfiguration.

The author(s) would like to thank Russ Housley, Steven M. Bellovin, Stephen Farrell, Alan DeKok, Warren Kumari, and Tom Petch for their support, insightful review, and/or comments. was also used as a basis for the approach to TLS.