RFC 9887

Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3

📅 published December 2025, from ietf

Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3 ✨

okay bestie, this is RFC 9887 🎀 It's a Standards Track document from the IETF, ISSN 2070-1721, dated December 2025. The authors are T. Dahm, J. Heasley (NTT), D.C. Medway Gash (Cisco Systems, Inc.), and A. Ota (Google Inc.). It updates RFC 8907 and doesn't list anything it obsoletes 💅

Here's the whole vibe: it's about making TACACS+ (the AAA protocol for routers, access servers, and other devices) use TLS 1.3 so the traffic is encrypted and actually authenticated 🔐

Abstract 🌸

okay so this doc says it uses Transport Layer Security (TLS) version 1.3 to lock down the channel between a TACACS+ client and server 🔒 TACACS+ handles Authentication, Authorization, and Accounting (AAA) in networked setups, but the original protocol doesn't require encryption or a secure transport at all 😭 This spec gives a profile for running TLS 1.3 with TACACS+, covering authentication, connection setup, and operational stuff. The goal is better confidentiality, integrity, and authenticity, so the protocol lines up with modern security best practices ✨

This document updates RFC 8907.

Status of This Memo 📋

this is an Internet Standards Track document 🏆

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841.

Info about the current status, any errata, and how to send feedback is at https://www.rfc-editor.org/info/rfc9887.

the doc is © 2025 IETF Trust and the authors, all rights reserved 💜 It's subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as of the publication date, so read those carefully because they spell out your rights and restrictions 🧾 Code Components pulled out of this doc have to include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License says 🫶

Table of Contents 🗺️

1.  Introduction
2.  Technical Definitions
  2.1.  Requirements Language
3.  TACACS+ over TLS
  3.1.  Separating TLS Connections
  3.2.  TLS Connection
  3.3.  TLS Authentication Options
  3.4.  TLS Certificate-Based Authentication
    3.4.1.  TLS Certificate Path Verification
    3.4.2.  TLS Certificate Identification
    3.4.3.  Cipher Suites Requirements
  3.5.  TLS PSK Authentication
  3.6.  TLS Resumption
4.  Obsolescence of TACACS+ Obfuscation
5.  Security Considerations
  5.1.  TLS
    5.1.1.  TLS Use
    5.1.2.  TLS 0-RTT
    5.1.3.  TLS Options
    5.1.4.  Unreachable Certificate Authority (CA)
    5.1.5.  TLS Server Name Indicator (SNI)
    5.1.6.  Server Identity Wildcards
  5.2.  TACACS+ Configuration
  5.3.  Well-Known TCP/IP Port Number
6.  Operational Considerations
  6.1.  Migration
  6.2.  Maintaining Non-TLS TACACS+ Clients
  6.3.  YANG Model for TACACS+ Clients
7.  IANA Considerations
8.  Acknowledgments
9.  References
  9.1.  Normative References
  9.2.  Informative References
Authors' Addresses

1. Introduction 🦋

okay so "The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol" ([RFC8907]) is the protocol that handles device administration for routers, network access servers, and other networked devices through one or more centralized TACACS+ servers 🖥️ It gives AAA services to TACACS+ clients in the device administration use case.

the content is super sensitive, so it needs secure transport to keep a deployment safe 🚨 The problem is TACACS+ doesn't really have effective confidentiality, integrity, or authentication for the connection and network traffic between server and client 😬 The security mechanisms in Section 4.5 of [RFC8907] are extremely weak, bestie 💀

so this doc fixes that by updating TACACS+ to use TLS 1.3 authentication and encryption ([RFC8446]) and by obsoleting the TACACS+ obfuscation mechanisms 🔐 TLS 1.3 and up is mature enough to be a solid pick for TACACS+ ✨

2. Technical Definitions 🧠

the terms defined in Section 3 of [RFC8907] apply here too and won't be repeated. These extra terms are used in this doc 📖

Obfuscation: TACACS+ was originally meant to have a way to secure the body of its packets 📦 That algorithm is categorized as obfuscation in Section 10.5.2 of [RFC8907]. The word is used so nobody mistakes it for encryption. It should not be considered secure 🙅‍♀️

Non-TLS connection: this refers to the connection defined in [RFC8907] 🔓 It's a connection without TLS, using the insecure TACACS+ authentication and obfuscation (or the unobfuscated option for testing). Well-known TCP/IP host port number 49 is the default for non-TLS connections.

TLS connection: a TLS connection is a TCP/IP connection with TLS authentication and encryption, used by TACACS+ for transport 🔒 It's always between one TACACS+ client and one TACACS+ server 👯

TLS TACACS+ server: this is a variant of the TACACS+ server, introduced in Section 3.2 of [RFC8907], that uses TLS for transport and has some protocol optimizations on top 🧚 Both server variants respond to TACACS+ traffic, but this doc specifically defines a TACACS+ server (TLS or non-TLS) as being bound to a specific port number on a particular IP address or hostname. This matters when you're configuring TACACS+ clients so they send traffic to the right servers 🎯

Peer: the peer of a TACACS+ client (or server), in the context of a TACACS+ connection, is a TACACS+ server (or client) 💞 Together, the two ends of a TACACS+ connection are called peers.

2.1. Requirements Language 📜

okay, the magic words. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔠 Lowercase versions are just regular words, bestie 💅

3. TACACS+ over TLS 🔐

TACACS+ over TLS takes the protocol from [RFC8907], drops the obfuscation option, and says TLS 1.3 has to be used for transport (Section 3.1 covers TLS version support) 🌈 It also gets a new well-known default host port number. The next sections have more details and guidance 📚

TLS gets added to TACACS+ to hit these requirements:

  1. Confidentiality and Integrity: the MD5 algorithm under the obfuscation mechanism in [RFC8907] has been shown to be insecure [RFC6151] when used for encryption 💔 That means TACACS+ can't be used in a deployment that's compliant with [FIPS-140-3]. Securing TACACS+ with TLS is meant to give confidentiality and integrity without needing a secured network 🛡️
  2. Peer authentication: TLS's authentication capabilities replace the shared secrets of obfuscation for mutual authentication 🤝

this doc follows the recommendations in [REQ-TLS13] 📝

3.1. Separating TLS Connections 🧩

okay so peers implementing the TACACS+ protocol variant in this document MUST apply mutual authentication and encrypt all data they exchange 🔒 That means once a TCP connection is set up for the service, a TLS handshake starts right away 🚀 Options that upgrade an initial non-TLS connection MUST NOT be used; see Section 5.3 🙅‍♀️

to keep TLS TACACS+ traffic clearly separate from the non-TLS kind (see Section 5.3), servers that support TACACS+ over TLS MUST listen on a TCP/IP port that's different from the one non-TLS TACACS+ servers use 🚧 It's also RECOMMENDED to run the TLS and non-TLS services on separate hosts, as covered in Section 5.1.1 🏠

since so many existing TACACS+ clients default to a certain port, this spec assigns well-known TCP port number 300 for TACACS+ over TLS (see Section 7) 🎀

using the designated port number is strongly encouraged 💜 deployments with specific needs MAY use other TCP port numbers, though. In that case, operators must carefully consider the operational implications described in Section 5.3 👀

3.2. TLS Connection 🦋

a TACACS+ client starts 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 up, the client MUST immediately begin the TLS negotiation before it sends any TACACS+ protocol data 🤳

a minimum of TLS 1.3 ([RFC8446]) MUST be used for transport 🔒 TACACS+ as described in this doc is expected to work with future versions of TLS too 🔮 Earlier versions of TLS MUST NOT be used 🙅‍♀️

once the TLS connection is successfully established, the TACACS+ data exchange MUST follow 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) 🚫

TLS TACACS+ connections are generally not long-lived ⏳ The connection will be closed by either peer if it runs into an error or an inactivity timeout 💤

for connections not running in Single Connection Mode (as defined in Section 4.3 of [RFC8907]), the TCP session SHALL be closed when the associated TACACS+ session finishes 🏁 Connections in Single Connection Mode MAY stick around longer, but they're typically subject to a timeout and closure after a short stretch of inactivity 😴 So support for transport-layer keepalive mechanisms is not required, which is a relief 🫠

why a connection gets closed has no bearing on TLS resumption, unless it was closed by a TLS error. In that case, the ticket may have been invalidated 🎟️

TACACS+ clients and servers widely support IPv6 configuration as well as IPv4 🌐 This document makes no changes to the recommendations in this area ✨

more parts are coming, bestie 💖 this is part 1 of 4 🎀

3.3. TLS Authentication Options 🔐

Okay bestie, so certificate-based mutual authentication is the core option, and implementations MUST support it so that deployments can actually work together. Section 3.4 has all the juicy details.

On top of certificate auth, implementations MAY also support these alternatives:

  • 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 out of scope for this doc, so don't go looking for them here 💅. Check out [RFC7250] and Section 4.4.2 of [RFC8446] for implementation, deployment, and security considerations.

3.4. TLS Certificate-Based Authentication 🎀

Certificate authentication is the main event for TACACS+ over TLS, no cap. This section only covers certificate-based auth.

Deploying TLS certificate-based auth correctly will seriously glow up the security of TACACS+ deployments ✨. Implementers and operators need to understand what it all implies: how certificates are handled, Certificate Authorities (CAs), and every single piece of TLS configuration. For the full starting point, go read [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 can add extra constraints on the peer, allowing or denying the connection based on certificate fields or any other parameters the implementation exposes 🧐.

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

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 might be cut off 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.

Other approaches may be used for loading the intermediate certificates onto the client, but they MUST include support for revocation checking. For example, [RFC5280] details the Authority Information Access (AIA) extension, which gives info about the issuer of the certificate it appears in. It can be used to provide the address of the Online Certificate Status Protocol (OCSP) responder, where the revocation status of the certificate (which includes the extension) can be checked 🔍.

3.4.2. TLS Certificate Identification 🪪

For the client-side validation of TLS TACACS+ server identities, implementations MUST follow the validation techniques defined in [RFC9525]. The identifier types DNS-ID, IP-ID, or SRV-ID all work with TLS TACACS+, and operators pick whichever fits their design. TLS TACACS+ does not use URI-IDs for server identity verification.

Wildcards in TLS TACACS+ server identities are super convenient because one certificate can secure multiple servers in a deployment. BUT, it's a risk: if the private key of a wildcard certificate gets compromised, every server using it is impacted 😬. 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.

For the TLS TACACS+ server-side validation of client identities, implementations MUST support the ability to configure which fields of a certificate are used for client identification. That's how they check that the client is a valid source for the received certificate and that it is permitted access to TACACS+. Implementations MUST support either:

  • Network-address-based validation methods as described in Section 5.2 of [RFC5425], or
  • Client Identity validation of a shared identity in the certificate subjectAltName. This is for deployments where the client securely supports an identity that's shared with the TLS TACACS+ server. Matching of dNSName and iPAddress MUST be supported. Other options defined in Section 4.2.1.6 of [RFC5280] MAY be supported. The nice part is that a client's network location can be reconfigured without issuing a new client certificate 🙌.

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 it can be included in the SNI "server_name" extension of the client hello. (This is distinct from the IP Address or hostname configuration used for the TCP connection.) Refer to Section 5.1.5 for security-related operator considerations.

Certificate provisioning is out of scope of this document 🤷‍♀️.

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, bestie 🙅‍♀️.

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 the 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), the TLS and non-TLS versions of TACACS+ might still both live in an organization, for example, during migration (Section 6.1). In those cases, the shared secrets configured for TACACS+ obfuscation clients MUST NOT be the same as the PSKs configured for TLS clients. Keep them separate, iykyk 🫶.

3.6. TLS Resumption ⏩

TLS Resumption [RFC8446] can minimize the number of round trips required during the handshake, which is giving efficiency 💨. 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. If the TLS TACACS+ server consents, the resumed session is acknowledged as authenticated and securely linked to the initial session.

The client SHOULD use resumption when it holds a valid unused ticket from the TLS TACACS+ server, since 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 a TLS TACACS+ server gets a resumption request from the TLS client, it MAY still choose to require a full handshake. In that case, the negotiation proceeds as if the session was a new authentication, and the resumption attempt is ignored. As described in Appendix C.4 of [RFC8446], reusing a ticket lets passive observers correlate different connections, which is a privacy moment 👀. TLS TACACS+ clients and servers SHOULD follow the client tracking preventions in Appendix C.4 of [RFC8446].

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

4. Obsolescence of TACACS+ Obfuscation 🫥

The obfuscation mechanism documented in Section 4.5 of [RFC8907] is weak. Not it, sis 💀.

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. This behavior corresponds to that defined in Section 4.5 of [RFC8907] regarding data obfuscation for TAC_PLUS_UNENCRYPTED_FLAG or key mismatches.

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. Main character glow-up 🌟.

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. No shortcuts, bestie 🫠.

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

This document outlines additional restrictions permissible under [BCP195]. For example, any recommendations referring to TLS 1.2, including the mandatory support, are not relevant for Secure TACACS+, as TLS 1.3 or above is mandated. TLS 1.2 is so last season 🙅‍♀️.

This document concerns the use of TLS as transport for TACACS+ and does not make any changes to the core TACACS+ protocol, other than the direct implications of deprecating obfuscation. Operators MUST be cognizant of the security implications of the TACACS+ protocol itself. Further documents are planned, for example, to address the security implications of password-based authentication and enhance the protocol to accommodate alternative schemes 📚.

5.1.1. TLS Use ✨

okay so, new TACACS+ production deployments SHOULD use TLS authentication and encryption 🔐 Also see [RFC3365] 💖

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 get 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, which is data sent before the TLS handshake completes. Replay of this data is a risk 💀 Given how sensitive TACACS+ data is, clients MUST NOT send data until the full TLS handshake completes. Put differently, 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. Further, operators MUST ensure that the TLS TACACS+ servers covered by a wildcard certificate are impervious to redirection of traffic to a different server (for example, due to on-path attacks or DNS cache poisoning) 🚨

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:

  • 49: for non-TLS connection TACACS+
  • 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 🔒

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 🛡️

However, the coexistence of inferior authentication and obfuscation, whether a non-TLS connection or deprecated parts that compose TLS, also presents an opportunity for downgrade attacks 😱 Causing failure of connections to the TLS-enabled service, or the negotiation of shared algorithm support, are two such downgrade attacks.

The simplest mitigation for exposure from non-TLS connection methods is to refuse non-TLS connections at the host entirely, perhaps using separate hosts for non-TLS connections and TLS 🧹

Another approach is mutual configuration that requires TLS. TACACS+ clients and servers SHOULD support configuration that requires peers, globally and individually, to use TLS. Furthermore, peers SHOULD be configurable to limit offered or recognized TLS versions and algorithms to those recommended by standards bodies and implementers 🌈

6. Operational Considerations 🧭

Operational and deployment considerations are spread throughout the document. While avoiding repetition, it is useful for the impatient to direct particular attention to Sections 5.2 and 5.1.5. However, it is important that the entire Section 5 is observed 🫶

It is essential for operators to understand the implications of a TLS certificate-based authentication solution, including the correct handling of certificates, CAs, and all elements of TLS configuration. Refer to [BCP195] for guidance. Attention is drawn to the provisioning of certificates to all peers, including TACACS+ TLS clients, to permit the mandatory mutual authentication 🎀

6.1. Migration 🦋

Section 5.2 mentions that for an optimal deployment of TLS TACACS+, TLS should be universally applied throughout the deployment. However, during the migration process from a non-TLS TACACS+ deployment, operators may need to support both TLS and non-TLS TACACS+ servers. This migration phase lets operators gradually transition their deployments from an insecure state to a more secure one, but it is important to note that it is vulnerable to downgrade attacks. Therefore, the migration phase should be considered insecure until it is fully completed. To mitigate this hazard:

  • The period where any client is configured with both TLS and non-TLS TACACS+ servers should be minimized.
  • The operator must consider the security impact of supporting both TLS and non-TLS connections, as mentioned above.

6.2. Maintaining Non-TLS TACACS+ Clients 🧸

Some TACACS+ client devices in a deployment may not implement TLS. These devices will require access to non-TLS TACACS+ servers. Operators must follow the recommendation of Section 5.1.1 and deploy separate non-TLS TACACS+ servers for these non-TLS clients from those used for the TLS clients 🧃

6.3. YANG Model for TACACS+ Clients 🌷

[TACACS-YANG] specifies a YANG model for managing TACACS+ clients, including TLS support 💜

7. IANA Considerations 📇

IANA has allocated the following new well-known system in the "Service Name and Transport Protocol Port Number Registry" (see https://www.iana.org/assignments/service-names-port-numbers). The service name "tacacss" follows the common practice of appending an "s" to the name given to the non-TLS well-known port name. See the justification for the allocation in Section 5.3 ✨

Service Name:  tacacss
Port Number:  300
Transport Protocol:  TCP
Description:  TLS Secure Login Host Protocol (TACACSS)
Assignee:  IESG
Contact:  IETF Chair
Reference:  RFC 9887

Considerations about service discovery are out of scope of this document 🙅‍♀️

8. Acknowledgments 💌

The author(s) would like to thank Russ Housley, Steven M. Bellovin, Stephen Farrell, Alan DeKok, Warren Kumari, Tom Petch, Tirumal Reddy, Valery Smyslov, and Mohamed Boucadair for their support, insightful review, and/or comments 🥰 [RFC5425] was also used as a basis for the general approach to TLS. [RFC9190] was used as a basis for TLS resumption recommendations. Although still in draft form at the time of writing, [RFC9813] was used as a model for PSK recommendations 🙌

9. References 📚

9.1. Normative References

okay so these are the refs the spec leans on hardest, so bookmark them 🔖💅

9.2. Informative References

these ones are the extra reading for the curious 🦋 they give background and context, so go wild 🌸

Authors' Addresses 🧚

the squad behind the spec, with their contact deets 💌

Thorsten Dahm
Email: thorsten.dahm@gmail.com


John Heasley
NTT
Email: heas@shrubbery.net


Douglas C. Medway Gash
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America
Email: dcmgash@cisco.com


Andrej Ota
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: andrej@ota.si
📦 where this page comes from