Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3
updates
- rfc-8907 — The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol
Extracted elements (31)
A new well-known port (300) was chosen instead of an upgrade mechanism from non-TLS connections because it enables easy firewall blocking of unobfuscated traffic by port number, avoids on-path attacks that can interfere with upgrade negotiations, allows passive IDSs to remain unaffected, and prevents accidental sensitive data exposure from misconfiguration.
The TACACS+ obfuscation mechanism is obsoleted because the underlying MD5 algorithm has been shown insecure for encryption (RFC 6151), preventing FIPS-140-3 compliant deployments. TLS 1.3 replaces obfuscation for both confidentiality/integrity and peer authentication (replacing shared secrets).
During migration from non-TLS TACACS+, operators may need to support both TLS and non-TLS servers simultaneously. This migration phase is considered insecure until fully completed; the period where any client is configured with both server types should be minimized.
TACACS+ client devices that do not implement TLS require access to separate non-TLS TACACS+ servers. TLS TACACS+ servers MUST NOT serve non-TLS clients; operators must deploy dedicated non-TLS servers for legacy devices.
A minimum of TLS 1.3 MUST be used for transport; earlier versions of TLS MUST NOT be used. It is expected that TACACS+ over TLS will work with future TLS versions.
A TACACS+ client initiating a TLS connection MUST set the TAC_PLUS_UNENCRYPTED_FLAG bit, and all subsequent packets MUST have this bit set to 1. A TLS TACACS+ server receiving a packet without this flag set MUST return an appropriate error and terminate the session.
Certificate path validation MUST follow RFC 5280 Section 6. Implementations MUST support certificate chains for isolated deployments, and any approach used MUST include support for revocation checking.
Client-side validation of TLS TACACS+ server identities MUST follow RFC 9525. Applicable identifier types are DNS-ID, IP-ID, or SRV-ID; URI-IDs MUST NOT be used for TACACS+ server identity verification.
Clients MUST NOT send 0-RTT data; TLS TACACS+ servers MUST abruptly disconnect clients that do. TLS TACACS+ clients and servers MUST NOT include the 'early_data' extension, due to replay attack risk given the sensitivity of TACACS+ data.
Implementations MUST support certificate-based mutual TLS authentication as the core interoperability option. Each peer MUST validate the certificate path of its remote peer, including revocation checking.
Implementations MUST support the TLS 1.3 mandatory cipher suites (RFC 8446 Section 9.1). The cipher suites offered or accepted SHOULD be configurable so that operators can adapt.
Implementations MUST support the TLS SNI extension (RFC 6066 Section 3). TLS TACACS+ clients MUST support configuring the server's domain name for inclusion in the SNI 'server_name' extension of the client hello.
Once TLS is established, the TACACS+ obfuscation mechanism defined in RFC 8907 MUST NOT be applied. Peers MUST NOT use obfuscation with TLS.
Peers implementing TACACS+ over TLS MUST apply mutual authentication and encrypt all data exchanged. When a TCP connection is established, a TLS handshake begins immediately; options that upgrade an initial non-TLS connection MUST NOT be used.
Server-side validation of client identities MUST support either network-address-based validation (per RFC 5425 Section 5.2) or Client Identity validation of a shared identity in the certificate subjectAltName, with mandatory support for matching dNSName and iPAddress.
Shared secrets configured for TACACS+ obfuscation clients MUST NOT be the same as the PSKs configured for TLS clients, even when both coexist during migration.
TACACS+ client implementations MUST use port 49 for non-TLS connections and port 300 for TLS connections where defaults have not been explicitly overridden.
TLS TACACS+ servers MUST listen on a TCP/IP port distinct from that used by non-TLS TACACS+ servers. The well-known TCP port number 300 is assigned for TACACS+ over TLS; deployments with specific requirements MAY use alternative port numbers.
TLS TACACS+ servers MUST NOT allow non-TLS connections to prevent downgrade attacks or misconfiguration. TACACS+ clients MUST NOT fall back to a non-TLS connection if a TLS connection fails, including during migration.
Where PSK authentication is implemented, PSK lengths of at least 16 octets MUST be supported, and PSK identities of at least 16 octets MUST be supported. PSK identity MUST follow recommendations of RFC 9257 Section 6.1.
Wildcard use in TLS server identities MUST follow RFC 9525 Section 7.1. Operators MUST ensure the wildcard is limited to a subdomain dedicated solely to TLS TACACS+ servers, and that those servers are impervious to traffic redirection.
A TLS connection for TACACS+ is a TCP/IP connection with TLS authentication and encryption, always between one TACACS+ client and one TACACS+ server. Once established, TACACS+ data exchanges proceed per RFC 8907 but all messages are transmitted as TLS application data.
The TAC_PLUS_UNENCRYPTED_FLAG bit signals that obfuscation is not used for the session. On TLS connections, this flag must always be set to 1; a TLS TACACS+ server that receives it unset returns TAC_PLUS_AUTHEN_STATUS_ERROR, TAC_PLUS_AUTHOR_STATUS_ERROR, or TAC_PLUS_ACCT_STATUS_ERROR as appropriate and terminates the session.
Three TLS authentication options are defined: certificate-based mutual authentication (mandatory for all implementations), Pre-Shared Keys (PSKs) as an optional alternative, and Raw Public Keys (RPKs) whose details are out of scope but referenced via RFC 7250.
TLS resumption is supported using PSK identity tied to a NewSessionTicket; clients SHOULD use resumption when holding a valid unused ticket (each ticket is for single use only). Certificates must be verified for revocation since the last NewSessionTicket during resumption.
IANA has allocated TCP port 300 with service name 'tacacss' in the Service Name and Transport Protocol Port Number Registry for TLS Secure Login Host Protocol (TACACSS). This follows the common practice of appending 's' to the non-TLS well-known port name.
A wildcard TLS certificate creates a single point of failure: a compromised private key affects all servers using it. Wildcards MUST be confined to a subdomain dedicated solely to TACACS+ servers and those servers must be protected against traffic redirection attacks.
Network isolation from a peer's CA will cause certificate verification to fail, preventing TLS authentication. Implementations MUST support certificate chains stored locally to address this; operators should plan for CA reachability.
The coexistence of TLS and non-TLS TACACS+ creates downgrade attack opportunities via connection failure to TLS service or negotiation of weak algorithms. The recommended mitigation is refusing all non-TLS connections at the host level, using separate hosts for TLS and non-TLS services.
The TLS SNI extension is sent in cleartext as part of the TLS client hello and is subject to eavesdropping. Operators must be aware of this exposure when designing deployments.
TLS 0-RTT data MUST NOT be sent because replay attacks are a risk and TACACS+ data is highly sensitive. Both the 'early_data' extension and any early data transmission are prohibited; servers must abruptly disconnect violating clients.