Summary

  • RFC 9887 defines TACACS+ over a minimum of TLS 1.3. The client begins TLS immediately after TCP establishment and sends TACACS+ only as TLS application data; a TLS failure does not authorize a non-TLS fallback.
  • Implementations must support certificate-based mutual authentication. Each peer validates the remote certificate path, including revocation checking. TLS PSKs and raw public keys are optional alternatives, and a TLS PSK must remain distinct from legacy TACACS+ obfuscation secrets.
  • TLS 0-RTT is forbidden for TACACS+ data because replay is a risk. Resumption tickets are single-use, and revocation must be checked again during resumption. The legacy obfuscation mechanism is obsolete for TLS operation; peers set the unencrypted flag because TLS supplies confidentiality and integrity.
  • A TLS TACACS+ server must reject non-TLS connections. RFC 9887 says the mixed TLS/non-TLS migration phase is insecure until completed and that its duration should be minimized. Non-TLS servers should be separated from TLS servers. IANA assigned TCP port 300 and the service name tacacss; alternate ports remain possible with explicit operational consideration.

The central distinction is between protocol behavior and migration architecture. “No fallback” is a client rule: a failed TLS attempt cannot silently become a non-TLS authentication attempt. It does not mean every device can be upgraded simultaneously. An organization may retain a separately addressed legacy service for equipment that cannot yet migrate, but that exception preserves an insecure path rather than making the overall deployment secure. Completion therefore means more than demonstrating that a TLS endpoint answers.

At the TLS endpoint, the observable sequence is immediate negotiation after TCP establishment, followed by TACACS+ records inside TLS application data. The baseline is mutual certificate authentication, with validation of the certificate path and revocation status on both sides. PSK or raw-public-key authentication can be used where supported by the protocol, while PSKs must not be confused with, or derived from, legacy obfuscation secrets. Resumption does not waive revocation checking, and a ticket cannot be treated as reusable. A client or server must not send TACACS+ through TLS 0-RTT.

TLS supplies confidentiality and integrity, so the TACACS+ obfuscation mechanism is obsoleted for TLS operation and peers set the unencrypted flag. This does not make a legacy server safe; it describes the representation inside the protected TLS exchange. The TLS server itself accepts no non-TLS connection. A separately operated non-TLS server is a migration accommodation, not a fallback endpoint.

The frozen evidence does not establish current vendor implementation coverage, production adoption of TCP port 300, observed migration duration or downgrade incidents, certificate-authority availability or revocation-check latency in deployed networks, or measured performance effects of TLS resumption. RFC 9887 also does not establish deployment prevalence, outcomes, vendor conformance, incident history, or current operator adoption.

Operator decision path

  1. Theo March analysis: inventory each device, its TACACS+ mode, address, trust material, certificate or PSK capability, and ability to use TCP 300 or an explicitly considered alternate port.
  2. If the device supports TLS 1.3 and the required authentication, move it to the TLS server. Verify mutual certificate and revocation checks, or verify the selected PSK/raw-public-key method and its separation from legacy secrets.
  3. If TLS negotiation fails, stop and investigate; do not enable client fallback. If the device cannot migrate, use only the separately controlled legacy service and record a Theo March analysis owner and expiry for that exception.
  4. Theo March analysis: when the exception ends, remove legacy reachability, firewall and route entries, and legacy credentials or secrets; then verify that the TLS server rejects non-TLS traffic. These completion controls are not additional RFC 9887 requirements.

Verification fixtures

Use a trace showing TCP establishment followed immediately by TLS 1.3 negotiation and no plaintext TACACS+ bytes. Test invalid and revoked peer certificates. Attempt TLS 0-RTT and confirm that TACACS+ data is not accepted in early data. Reuse a resumption ticket and confirm single-use handling plus a fresh revocation check. Present a legacy non-TLS connection to the TLS listener and confirm rejection; independently verify that a TLS failure produces an error rather than a connection to the legacy service. Inspect the exchange for the unencrypted flag and confirm that the legacy obfuscation secret is not used as the TLS PSK.

Sources