Skip to main content

4. Obsolescence of TACACS+ Obfuscation

The obfuscation mechanism documented in Section 4.5 of [RFC8907] is weak.

The introduction of TLS authentication and encryption to TACACS+ replaces this former mechanism, so obfuscation is hereby obsoleted. This section describes how the TACACS+ client and servers MUST operate regarding 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 bit set to 1.

A TLS TACACS+ server that receives a packet with the TAC_PLUS_UNENCRYPTED_FLAG bit not set to 1 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 bit set to 1, and terminate the session.

A TACACS+ client that receives a packet with the TAC_PLUS_UNENCRYPTED_FLAG bit not set to 1 MUST terminate the session, and SHOULD log this error.

5. Security Considerations

5.1. TLS​

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 TLS TACACS+ 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.

[BCP195] offers substantial guidance for implementing and deploying protocols that use TLS. Those implementing and deploying Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3 outlined in [BCP195] or its subsequent versions.

5.1.1. TLS Use​

New TACACS+ production deployments SHOULD use TLS authentication and encryption.

TLS TACACS+ servers (as defined in Section 2) MUST NOT allow non-TLS connections, because of the threat of downgrade attacks or misconfiguration described in Section 5.3. Instead, separate non-TLS TACACS+ servers SHOULD be set up to cater for these clients.

It is NOT RECOMMENDED that TLS TACACS+ servers and non-TLS TACACS+ servers be deployed on the same host, for reasons discussed in Section 5.3. Non-TLS connections would be better served by deploying the required non-TLS TACACS+ servers on separate hosts.

TACACS+ clients MUST NOT fail back to a non-TLS connection if a TLS connection fails. This prohibition includes during the migration of a deployment (Section 6.1).

5.1.2. TLS 0-RTT​

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 TLS TACACS+ servers MUST abruptly disconnect clients that do.

TLS TACACS+ clients and servers MUST NOT include the "early_data" extension. See Sections 2.3 and 4.2.10 of [RFC8446] for security concerns.

5.1.3. TLS Options​

Recommendations in [BCP195] MUST be followed to determine which TLS versions and algorithms should be supported, deprecated, obsoleted, or abandoned.

Also, Section 9 of [RFC8446] prescribes mandatory supported options.

5.1.4. Unreachable Certificate Authority (CA)​

Operators should be cognizant of the potential of TLS TACACS+ 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. The approach mentioned in Section 3.4.1 can help address this and should be considered.

5.1.5. TLS Server Name Indicator (SNI)​

Operators should be aware that the TLS SNI extension is part of the TLS client hello, which is sent in cleartext. It is, therefore, subject to eavesdropping. Also see Section 11.1 of [RFC6066].

5.1.6. Server Identity Wildcards​

The use of wildcards in TLS server identities creates a single point of failure: a compromised private key of a wildcard certificate impacts all servers using it. Their use MUST follow the recommendations of Section 7.1 of [RFC9525]. Operators MUST ensure that the wildcard is limited to a subdomain dedicated solely to TLS TACACS+ servers.

5.2. TACACS+ Configuration​

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 recommends the use of a separate port number that TLS TACACS+ servers will listen to. Where deployments have not overridden the defaults explicitly, TACACS+ client implementations MUST use the correct port values:

  • Port 49: for non-TLS connection TACACS+
  • Port 300: for TLS connection TACACS+

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 common misconfiguration is to enable TLS on the server but misconfigure the client to use the non-TLS port, or vice versa. To prevent this, clear configuration practices SHOULD include:

  • Explicit TLS/non-TLS mode indicators in configuration files
  • Validation warnings when port numbers don't match the configured mode
  • Separate configuration sections for TLS and non-TLS servers

5.3. Well-Known TCP/IP Port Number​

A new port number is considered appropriate (rather than a mechanism that negotiates an upgrade from an initial non-TLS TACACS+ connection) because it allows:

  • ease of blocking the unobfuscated or obfuscated connections by the TCP/IP port number,
  • passive Intrusion Detection Systems (IDSs) monitoring the unobfuscated to be unaffected by the introduction of TLS,
  • avoidance of on-path attacks that can interfere with upgrade, and
  • prevention of the accidental exposure of sensitive information due to misconfiguration.

6. Operational Considerations

6.1. Migration​

In order to facilitate a smooth transition from legacy TACACS+ deployments to TLS-secured TACACS+, organizations need to plan their migration carefully. The most common migration strategies are:

Parallel Operation: Operators can deploy new TLS TACACS+ servers alongside existing non-TLS servers. This allows for gradual client migration without service disruption. However, as noted in Section 5.1.1, it is NOT RECOMMENDED to run both TLS and non-TLS services on the same host.

Phased Migration: A recommended approach includes:

  1. Assessment Phase: Identify all TACACS+ clients and servers in the environment
  2. Pilot Phase: Deploy TLS TACACS+ servers on port 300 in a test environment
  3. Initial Deployment: Configure a subset of clients to use the new TLS servers
  4. Gradual Rollout: Incrementally migrate additional clients
  5. Monitoring Period: Ensure stable operation before proceeding
  6. Completion: Decommission non-TLS infrastructure once all clients are migrated

During migration, TACACS+ clients MUST NOT be configured to fall back to non-TLS connections if a TLS connection fails (Section 5.1.1). This prohibition is essential to prevent downgrade attacks.

Operators should maintain detailed logs during migration to identify any clients still attempting non-TLS connections.

6.2. Maintaining Non-TLS TACACS+ Clients​

Some legacy devices may not support TLS and cannot be upgraded. For these devices, operators have several options:

  1. Separate Non-TLS Infrastructure: Deploy dedicated non-TLS TACACS+ servers on separate hosts (RECOMMENDED). These servers should be isolated in a more restricted network segment if possible.

  2. Gradual Hardware Refresh: Plan to replace or upgrade legacy devices as part of normal refresh cycles.

  3. Compensating Controls: If legacy devices must remain, implement additional network-level security controls such as dedicated VLANs, enhanced monitoring, or encrypted tunnels at the network layer.

Non-TLS TACACS+ servers SHOULD be clearly documented and monitored. Organizations should have a target date for complete TLS migration.

6.3. YANG Model for TACACS+ Clients​

A YANG data model for configuring TACACS+ clients, including TLS-specific parameters, would be beneficial for network automation and consistent configuration management across heterogeneous network devices.

Such a model could include:

  • Server addresses and port numbers
  • TLS configuration parameters (certificate paths, cipher suites, etc.)
  • Fallback behavior and timeout settings
  • Authentication priorities

The development of a standardized YANG model is outside the scope of this document but is encouraged as future work. Organizations implementing TACACS+ over TLS in YANG-based management systems should consider developing vendor-neutral models.

7. IANA Considerations

IANA has assigned TCP port number 300 with the service name "tacacss" for TACACS+ over TLS:

Service Name: tacacss
Transport Protocol: TCP
Port Number: 300
Description: TACACS+ over TLS
Reference: RFC 9887

8. Acknowledgments

The authors would like to acknowledge the contributions and feedback from the IETF Operations and Management Area Working Group (OPSAWG) participants. Special thanks to those who provided valuable input during the development of this specification, including reviews, suggestions, and implementation experience that helped shape this document.

The work to enhance TACACS+ security through TLS was driven by the operational community's need for better protection of device administration traffic. The authors appreciate the collaborative effort that made this specification possible.

9. References

9.1. Normative References​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

    • https://www.rfc-editor.org/info/rfc2119

  • [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

    • https://www.rfc-editor.org/info/rfc8174

  • [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018.

    • https://www.rfc-editor.org/info/rfc8446

  • [RFC8907] Dahm, T., Ota, A., Medway Gash, D., and L. Grant, "The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol", RFC 8907, DOI 10.17487/RFC8907, September 2020.

    • https://www.rfc-editor.org/info/rfc8907

  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008.

    • https://www.rfc-editor.org/info/rfc5280

  • [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023.

    • https://www.rfc-editor.org/info/rfc9525

  • [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011.

    • https://www.rfc-editor.org/info/rfc6066

9.2. Informative References​

  • [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011.

    • https://www.rfc-editor.org/info/rfc6151

  • [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014.

    • https://www.rfc-editor.org/info/rfc7250

  • [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016.

    • https://www.rfc-editor.org/info/rfc7924

  • [RFC9257] Housley, R., "Guidance for External Pre-Shared Key (PSK) Usage in TLS", RFC 9257, DOI 10.17487/RFC9257, July 2022.

    • https://www.rfc-editor.org/info/rfc9257

  • [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015.

    • https://www.rfc-editor.org/info/rfc7525

  • [FIPS-140-3] National Institute of Standards and Technology, "Security Requirements for Cryptographic Modules", FIPS PUB 140-3, March 2019.

    • https://csrc.nist.gov/publications/detail/fips/140/3/final

  • [REQ-TLS13] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", RFC 8996, DOI 10.17487/RFC8996, March 2021.

    • https://www.rfc-editor.org/info/rfc8996

Authors' Addresses​

Thorsten Dahm
Email: [email protected]

John Heasley
NTT
Email: [email protected]

Douglas C. Medway Gash
Cisco Systems, Inc.
Email: [email protected]

Andrej Ota
Google Inc.
Email: [email protected]

Last updated on