3. TACACS+ over TLS

TACACS+ over TLS takes the protocol defined in [RFC8907], removes the option for obfuscation, and specifies that TLS 1.3 be used for transport. A new well-known default host port number is used. The next sections provide further details and guidance.

TLS is introduced into TACACS+ to fulfill the following requirements:

1. Confidentiality and Integrity: The MD5 algorithm underlying the obfuscation mechanism specified in [RFC8907] has been shown to be insecure [RFC6151] when used for encryption. This prevents TACACS+ from being used in a deployment compliant with [FIPS-140-3]. Securing the TACACS+ protocol with TLS is intended to provide confidentiality and integrity without requiring the provision of a secured network.

2. Peer authentication: The authentication capabilities of TLS replace the shared secrets of obfuscation for mutual authentication.

This document adheres to the recommendations in [REQ-TLS13].

3.1. Separating TLS Connections

Peers implementing the TACACS+ protocol variant defined in this document MUST apply mutual authentication and encrypt all data exchanged between them. Therefore, when a TCP connection is established for the service, a TLS handshake begins immediately. Options that upgrade an initial non-TLS connection MUST NOT be used; see Section 5.3.

To ensure clear separation between TACACS+ traffic using TLS and that 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 TACACS+ servers. It is further RECOMMENDED to deploy the TLS and non-TLS services on separate hosts, as discussed in Section 5.1.1.

Given the prevalence of default port usage in existing TACACS+ client implementations, this specification assigns the well-known TCP port number 300 for TACACS+ over TLS (see Section 7).

While the use of the designated port number is strongly encouraged, deployments with specific requirements MAY use alternative TCP port numbers. In such cases, operators must carefully consider the operational implications described in Section 5.3.

3.2. TLS Connection

A TACACS+ client initiates a TLS connection by making a TCP connection to a configured TLS TACACS+ server on the TACACS+ TLS port number. Once the TCP connection is established, the client MUST immediately begin the TLS negotiation before sending any TACACS+ protocol data.

A minimum of TLS 1.3 [RFC8446] MUST be used for transport. It is expected that TACACS+, as described in this document, will work with future versions of TLS. Earlier versions of TLS MUST NOT be used.

Once the TLS connection has been successfully established, the exchange of TACACS+ data MUST proceed in accordance with the procedures defined in [RFC8907]. However, all TACACS+ messages SHALL be transmitted as TLS application data. The TACACS+ obfuscation mechanism defined in [RFC8907] MUST NOT be applied when operating over TLS (Section 4).

Connection Lifecycle

TLS TACACS+ connections are generally not long-lived. The connection will be closed by either a peer if it encounters an error or an inactivity timeout.

• For connections not operating in Single Connection Mode (as defined in Section 4.3 of [RFC8907]), the TCP session SHALL be closed upon completion of the associated TACACS+ session.
• Connections operating in Single Connection Mode MAY persist for a longer duration but are typically subject to timeout and closure after a brief period of inactivity.
• Consequently, support for transport-layer keepalive mechanisms is not required.

Why a connection is closed has no bearing on TLS resumption, unless closed by a TLS error, in which case it is possible that the ticket has been invalidated.

TACACS+ clients and servers widely support IPv6 configuration in addition to IPv4. This document makes no changes to recommendations in this area.

3.3. TLS Authentication Options

Implementations MUST support certificate-based mutual authentication, to provide a core option for interoperability between deployments. This authentication option is specified in Section 3.4.

In addition to certificate-based TLS authentication, implementations MAY support the following alternative authentication mechanisms:

• Pre-Shared Keys (PSKs) (Section 3.5), also known as external PSKs in TLS 1.3.
• Raw Public Keys (RPKs). The details of RPKs are considered out of scope for this document. Refer to [RFC7250] and Section 4.4.2 of [RFC8446] for implementation, deployment, and security considerations.

3.4. TLS Certificate-Based Authentication

TLS certificate authentication is the primary authentication option for TACACS+ over TLS. This section covers certificate-based authentication only.

Deploying TLS certificate-based authentication correctly will considerably improve the security of TACACS+ deployments. It is essential for implementers and operators to understand the implications of a TLS certificate-based authentication solution, including the correct handling of certificates, Certificate Authorities (CAs), and all elements of TLS configuration. For guidance, start with [BCP195].

Each peer MUST validate the certificate path of its remote peer, including revocation checking, as described in Section 3.4.1.

If the verification succeeds, the authentication is successful and the connection is permitted. Policy may impose further constraints upon the peer, allowing or denying the connection based on certificate fields or any other parameters exposed by the implementation.

Unless disabled by configuration, a peer MUST NOT permit connection of any peer that presents an invalid TLS certificate.

3.4.1. TLS Certificate Path Verification

The implementation of certificate-based mutual authentication MUST support certificate path validation as described in Section 6 of [RFC5280].

In some deployments, a peer may be isolated from a remote peer's CA. Implementations for these deployments MUST support certificate chains (aka bundles or chains of trust), where the entire chain of the remote peer's certificate is stored on the local peer.

TLS Cached Information Extension [RFC7924] SHOULD be implemented. This MAY be augmented with RPKs [RFC7250], though revocation must be handled as it is not part of that specification.

3.4.2. TLS Certificate Identification

For the client-side validation of presented TLS TACACS+ server identities, implementations MUST follow the validation techniques defined in [RFC9525]. Identifier types DNS-ID, IP-ID, or SRV-ID are applicable for use with the TLS TACACS+ protocol; they are selected by operators depending upon the deployment design. TLS TACACS+ does not use URI-IDs for TLS TACACS+ server identity verification.

Wildcards in TLS TACACS+ server identities simplify certificate management by allowing a single certificate to secure multiple servers in a deployment. However, this introduces security risks, as compromising the private key of a wildcard certificate impacts all servers using it. To address these risks, the guidelines in Section 6.3 of [RFC9525] MUST be followed, and the wildcard SHOULD be confined to a subdomain dedicated solely to TACACS+ servers.

Implementations MUST support the TLS Server Name Indication (SNI) extension (Section 3 of [RFC6066]). TLS TACACS+ clients MUST support the ability to configure the TLS TACACS+ server's domain name, so that it may be included in the SNI "server_name" extension of the client hello.

3.4.3. Cipher Suites Requirements

Implementations MUST support the TLS 1.3 mandatory cipher suites (Section 9.1 of [RFC8446]). Readers should refer to [BCP195]. The cipher suites offered or accepted SHOULD be configurable so that operators can adapt.

3.5. TLS PSK Authentication

As an alternative to certificate-based authentication, implementations MAY support PSKs, also known as external PSKs in TLS 1.3 [RFC8446]. These should not be confused with resumption PSKs.

The use of external PSKs is less well established than certificate-based authentication. It is RECOMMENDED that systems follow the directions of [RFC9257] and Section 4 of [RFC8446].

Where PSK authentication is implemented, PSK lengths of at least 16 octets MUST be supported.

PSK identity MUST follow recommendations of Section 6.1 of [RFC9257]. Implementations MUST support PSK identities of at least 16 octets.

Although this document removes the option of obfuscation (Section 4), it is still possible that the TLS and non-TLS versions of TACACS+ exist in an organization, for example, during migration (Section 6.1). In such cases, the shared secrets configured for TACACS+ obfuscation clients MUST NOT be the same as the PSKs configured for TLS clients.

3.6. TLS Resumption

TLS Resumption [RFC8446] can minimize the number of round trips required during the handshake process. If a TLS client holds a ticket previously extracted from a NewSessionTicket message from the TLS TACACS+ server, it can use the PSK identity tied to that ticket.

The client SHOULD use resumption when it holds a valid unused ticket from the TLS TACACS+ server, as each ticket is intended for a single use only and will be refreshed during resumption. The TLS TACACS+ server can reject a resumption request, but the TLS TACACS+ server SHOULD allow resumption if the ticket in question has not expired and has not been used before.

When processing TLS resumption, certificates must be verified to check for revocation during the period since the last NewSessionTicket Message.

The resumption ticket_lifetime SHOULD be configurable, including a zero seconds lifetime. Refer to Section 4.6.1 of [RFC8446] for guidance on ticket lifetime.