TACACS+ Security, TLS, and SSH Public Keys

The TACACS+ Protocol provides device administration for routers, network access servers and other networked computing devices via one or more centralized servers. The protocol provides authentication, authorization and accounting services for TACACS+ clients. While the content of the protocol is highly sensitive, TACACS+ lacks modern and/or effective confidentiality, integrity, and authentication of the connection and network traffic between the server and client. The existing mechanisms of TACACS+ are extremely weak and the Security Considerations section of the TACACS+ Protocol adequately describes this. To address these deficiencies, this document updates the TACACS+ Protocol to use TLS 1.3 authentication and encryption, and deprecates the use of its former mechanisms. To support SSH authentication using public keys, highly desired by the operator community, this document introduces a method to support sending public keys to a TACACS+ client, allowing centralized management. To accomplish these goals and improve security and functionality when a network proxy is involved in a TACACS+ connection, new and uniform packet formats are introduced.

The Technical Definitions section of the TACACS+ Protocol is fully applicable here and will not be repeated, though may be augmented. The following terms are also used in this document.

An Attribute-Value Pair or AVP is another name a TACACS+ argument as defined in Sections 6.1 and 8.

An empty or zero-length value of an AVP as defined in Sections 8.1.

This is another term for a Connection as defined in TACACS+ Protocol. It is a Connection without TLS and therefore being plaintext or possibly using unsecure TACACS+ authentication and obfuscation.

This refers to a TACACS+ Server or Client.

A TLS Connection is a TCP/IP connection with TLS authentication and encryption used by TACACS+ for transport, similar to a Connection as defined in TACACS+ Protocol.

TACACS+ connections are TCP/IP connections initiated by the Client to the Server. The well-known TCP/IP port 49 on the Server is used for unencrypted and encrypted connections as defined in the TACACS+ Protocol. A connection may be used for only a single Session or the multiplexing of multiple Sessions in TACACS+ Single Connection Mode. TLS is introduced into TACACS+ to fulfill the following requirements:

Confidentiality and Integrity: The MD5 obfuscation specified in the original protocol definition is not fit for purpose, requiring that TACACS+ be deployed over a secured network. Securing TACACS+ protocol with TLS is intended to provide confidentiality and integrity without requiring the provision of a secured network.
Peer authentication: The use of shared keys to add and remove the MD5 obfuscation was intended to provide a form of Peer authentication for the TACACS+ protocol. This document deprecates the MD5 obfuscation, and specifies that the authentication capabilities of TLS are used to allow the Peers to authenticate each other.

All data exchanged by TACACS+ Peers MUST be encrypted, including the authentication of the Peers. Therefore, TLS Hello MUST be initiated by the client immediately upon the establishment of the TCP/IP connection. This document favors the predictable use of TLS security for a deployment, see (). TACACS+ TLS will therefore follow , where a different well-known system TCP/IP port is assigned by IANA, port [TBD] with the service name [TBDN], for TLS connections.

A TACACS+ Client initiates a TLS connection by making a TCP connection to a configured Server on the tacacss well-known port (). Once the TCP connection is established, the Client MUST immediately begin the TLS negotiation before sending any TACACS+ protocol data. Implementations MUST support TLS 1.3 and MAY permit TLS 1.3 session resumption. If resumption is supported, the resumption ticket_lifetime SHOULD be configurable, including a zero seconds lifetime. Once the TLS connection is established, the exchange of TACACS+ data proceeds as normal, except that it is transmitted over TLS as TLS application data and without TACACS+ obfuscation (see ) The connection persists until the Server or Client closes it. It might be closed due to an error or at the conclusion of the TACACS+ Session. If Single Connection Mode has been negotiated, it might remain open after a successful Session, until an error or a timeout occurs. Why it closed has no bearing on TLS resumption, unless closed by a TLS error, in which case the ticket might be invalidated.

Implementations MUST support the TLS 1.3 mandatory cipher suites (See RFC8446 Section 9.1). The cipher suites offered or accepted SHOULD be configurable so that operators can adapt. This document makes no cipher suite recommendations, but recommendations can be found in the TLS Cipher Suites section of the .

Implementations MUST support certificate-based TLS authentication and certificate revocation bi-directionally for authentication, identity verification and policy purposes. Certificate path verification as described in MUST be supported. If this 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 disconnect a Peer that offers an invalid TLS Certificate.

Implementations MUST support certificate Path verification as described in .

In addition to authentication of TLS certificates, implementations MUST support policy consideration of Peer-identifying certificate fields and policy used to verify that the Peer is a valid source for the received certificate and that it is permitted access to TACACS+. Implementations MUST support either: Network location based validation methods as described in or Device Identity based validation methods where the peer’s identity is used in the certificate subjectName. This is applicable in deployments where the device securely supports an identity which is shared with its peer. This approach allows a peer's network location to be reconfigured without issuing a new client certificate. Only the local server mapping needs to be updated.

Versions 1 and 2 of the TACACS+ Protocol, as defined in , specify the TACACS+ Authentication Packets for START, REPLY and CONTINUE which support the credential validation use case but does not accommodate any further arguments which may be used to give context to the request. One use-case where this shortcoming inhibits correct operation is for the TACACS+ proxy. Because the originating client is not encoded in the regular Authentication START Packet, TACACS+ Servers generally attempt to determine the client from the TCP connection. This is effective only for the first step: proxied TACACS+ servers can no longer securely enforce policy based upon the end client IP-Address. Further, advanced use cases (such as SSH key distribution) would otherwise rely on embedding structured information into the single data fields, obfuscating the content of the protocol. To support these use cases, and allow clients to add environment information to the request, the Extended Authentication Packets brings the Authentication phase of the protocol inline with the Authorization and Accounting Phase by incorporating extensible argument s. The server should expect Extended Authentication Packet Bodies if the minor version in the Packet Header is: 0x2

The action, priv_level, authen_type, authen_service, user_len, port_len, rem_addr_len, data_len, user, port, rem_addr and data fields are used exactly as defined in the Authentication START Packet Body in . The following fields contain the arguments that may be used to extend the authentication process. These are common to the Extended Authentication START, Extended Authentication REPLY, and Extended Authentication CONTINUE packet bodies; these fields represent the sole update from the previous START, REPLY and CONTINUE packet bodies. The new fields are as follows: arg_cnt This represents the number of arguments in the packet. arg_1_len ... arg_N_len, arg_1 ... arg_N Each argument is encoded in the packet as a single arg field (arg_1 ... arg_N) with a corresponding length field that indicates the length of each argument in bytes. The arguments are argument-value pairs. The argument and the value are in a single string and are separated by either a "=" (0X3D) or a "*" (0X2A). The equals sign indicates a mandatory argument. The asterisk indicates an optional one. For the rules regarding optional and mandatory arguments, refer to Multiple arguments with the same name are permitted within a packet, a common example is cmd-arg. The handling of repeated arguments is specific to the semantics of the argument and so are documented with that argument. Order is significant when processing arguments. The addition of arguments to the authentication packets is intended to permit the flexibility for the TACACS+ authentication phase that has been available previously for authorization and accounting. These fields are intended to be used as needed in deployment, they are used in this document in the enhancements for SSH, and to support the origin client to enhance TACACS+ Proxy: origin_client The IP-Address of the originating TACACS+ client. This is text encoded in line with the rest of the TACACS+ protocol, and may be IPv4 or IPv6. This argument is optional. IPv4 addresses are specified as octet numeric values separated by dots ('.'). IPv6 address text representation is defined in .

The TACACS+ server sends only one type of extended authentication packet to the client.

The status, flags, server_msg_len, data_len, server_msg, and data fields are used exactly as defined in the Authentication REPLY Packet Body in ]. The new arg_cnt, arg_1 ... arg_N, and arg_1_len .... arg_N_len fields are used as defined in The Extended Authentication START Packet Body.

This packet is sent from the client to the server following the receipt of an Extended REPLY packet.

The user_msg len, data_len, user_msg, and data fields are used exactly as defined in the Authentication REPLY Packet Body in . However, the status field replaces the flags field and has the following enumeration:

TAC_PLUS_AUTHEN_CONTINUE_STATUS_NONE := 00
TAC_PLUS_AUTHEN_CONTINUE_STATUS_PASS := 01
TAC_PLUS_AUTHEN_CONTINUE_STATUS_FAIL := 02
TAC_PLUS_AUTHEN_CONTINUE_STATUS_FRAGMENT := 03
TAC_PLUS_AUTHEN_CONTINUE_STATUS_ERROR := 04
TAC_PLUS_AUTHEN_CONTINUE_STATUS_ABORT := 05

TAC_PLUS_AUTHEN_CONTINUE_STATUS_NONE or TAC_PLUS_AUTHEN_CONTINUE_STATUS_ABORT MUST be used when the Extended Authentication Packets are used for the continuation of authentication flows documented in . The client may prematurely terminate a session by setting the TAC_PLUS_AUTHEN_CONTINUE_STATUS_ABORT or TAC_PLUS_AUTHEN_CONTINUE_STATUS_ERROR status in the CONTINUE message. The remainder are detailed in SSH. The new arg_cnt, arg_1 ... arg_N, and arg_1_len .... arg_N_len fields are used as defined in The Extended Authentication START Packet Body.

Most network equipment now support SSH for Command Line Interface (CLI) and NETCONF. Operators SHOULD use SSH public keys for authentication. Some devices support public keys in native configuration, but there is desire to centrally manage keys and SSH subsystem authorization.

The following new enumerated TACACS+ protocol values and well-known AVPs are needed to support SSH in the subsequent sections. These new values augment those in Sections 5.1 - 5.3, 6.1, and 8.2 as follows:

TAC_PLUS_AUTHEN_TYPE_SSHPK := 0x07: Extended Authentication START Packet authen_type for SSH pubkeys.
TAC_PLUS_AUTHEN_STATUS_GETSSHPKTYPE := 0x22: Extended Authentication REPLY Packet status to solicit SSH pubkey type.
TAC_PLUS_AUTHEN_STATUS_SSHPK := 0x23: Extended Authentication REPLY Packet status to provide SSH pubkeys.
TAC_PLUS_REPLY_FLAG_FRAGMENT := 0x02: Extended Authentication REPLY Packet flag indicating the REPLY is incomplete.
TAC_PLUS_AUTHEN_CONTINUE_STATUS_PASS := 0x01: Extended Authentication CONTINUE Packet flag indicating authentication success.
TAC_PLUS_AUTHEN_CONTINUE_STATUS_FAIL := 0x08: Extended Authentication CONTINUE Packet flag indicating authentication failure.
TAC_PLUS_AUTHEN_CONTINUE_STATUS_FRAGMENT := 0x03: Extended Authentication CONTINUE Packet flag requesting the next REPLY packet of an incomplete REPLY.
TAC_PLUS_AUTHEN_CONTINUE_STATUS_ERROR := 0x04: Extended Authentication CONTINUE Packet flag indicating authentication error.
AVP ssh_pubkey_type (String): Attribute to carry SSH public key type names.
AVP ssh_pubkey (String): Attribute to carry SSH public keys.
TAC_PLUS_AUTHEN_METH_SSHPK := 0x21: Authorization REQUEST Packet authen_method for SSH pubkey authentication.
AVP ssh_subsystem (String): Attribute to carry SSH subsystem name for authorization

To support central management of SSH public keys via TACACS+, the Authentication sequence of Section 5.4 is extended using Extended Authentication Packet sequences to deliver SSH public keys to devices for local verification. Besides new header values and flags and AVPs for Extended Authentication Packets, the SSH public key authentication process differs from other TACACS+ authentication types in that there may be more Authentication Reply and Authentication Continue Packets pairs than previously. The process follows:

The client begins an authentication session with an Extended Authentication START Packet. The START packet MUST include a non-zero-length username and the server MUST send an Authentication REPLY Packet with status TAC_PLUS_AUTHEN_STATUS_ERROR, if the client fails to do so.

The client MAY include one or more instances of the ssh_pubkey_type AVP, indicating the SSH public key types that it wants. The set of permissible values for this AVP are the SSH public algorithm names defined in the IANA SSH Protocol Parameters Registry, which are case-sensitive as specified and otherwise constrained by Section 4.6.1. Multiple values MUST be separated by a comma, therefore multiple ssh_pubkey_type AVPs MUST include commas for separation when the Peer concatenates them and the Peer MUST be prepared to ignore a leading or trailing comma in the concatenated value. The server MUST NOT reply with status TAC_PLUS_AUTHEN_STATUS_ERROR if it receives an algorithm name that it does not recognize. If the client marks a ssh_pubkey_type AVP as mandatory, the server MUST reply with at least one key of that type for the given user or reply with status TAC_PLUS_AUTHEN_STATUS_SSHNOPK with the relevant ssh_pubkey_type AVP.

The client MAY send an Empty Value for the algorithm name to request all types available for the given user.

The process ends and the client MUST start a new authentication session if it receives status SSHNOPK or ERROR.
If a ssh_pubkey_type AVP was not provided in the START packet, the server replies with the status code TAC_PLUS_AUTHEN_STATUS_GETSSHPKTYPE. The client MUST send a CONTINUE packet with one or more ssh_pubkey_type AVPs, else the server sends a REPLY packet with status TAC_PLUS_AUTHEN_STATUS_ERROR.
If the server has none of the requested ssh_pubkey_type(s) or any of the mandatory ssh_pubkey_types for the user or no pubkeys at all, the server MUST send a REPLY packet with status TAC_PLUS_AUTHEN_STATUS_SSHNOPK with the ssh_pubkey_type AVP(s) that it received.

The process ends and the client MUST start a new authentication session if it receives status SSHNOPK or ERROR.
The server sends REPLY packets with status TAC_PLUS_AUTHEN_STATUS_SSHPK and includes one or more ssh_pubkey optional AVPs, each containing one or more keys. The ssh_pubkey AVPs are formatted according to the rules of SSH Public Key File Format. As such, the client MUST be prepared to accept keys with Key File Markers. To address concatenation of multiple ssh_pubkey AVPs or multiple keys in a single AVP, the server MUST terminate each key file End Marker with a Line Termination sequence as specified in RFC4716 Section 3.1.

Since it is possible to have more ssh_pubkey AVPs than fit in a REPLY packet, the server SHOULD set the REPLY packet flag TAC_PLUS_REPLY_FLAG_FRAGMENT if two or more packets are required, indicating that the client SHOULD request the remainder.

An AVP SHALL NOT span multiple fragments; each must be contained entirely in the fragment in which it begins.
If the TAC_PLUS_REPLY_FLAG_FRAGMENT flag is set, the client MAY reply with the same CONTINUE packet as before with the TAC_PLUS_AUTHEN_CONTINUE_STATUS_FRAGMENT flag set. The server replies with the next REPLY fragment as before, clearing the TAC_PLUS_REPLY_FLAG_FRAGMENT flag of the last REPLY fragment. This repeats until the last REPLY fragment is received, the client aborts the authentication process, or an error occurs. The client MUST NOT set TAC_PLUS_AUTHEN_CONTINUE_STATUS_FRAGMENT if the REPLY packet did not have the TAC_PLUS_REPLY_FLAG_FRAGMENT flag set and the server MUST reply with TAC_PLUS_AUTHEN_STATUS_ERROR if it does so.
Once the client has all of the pubkeys, it performs the ssh pubkey authentication with its ssh client. The client MUST then reply to the server with the status of that authentication by sending a CONTINUE packet with one of the following new or existing CONTINUE flags: TAC_PLUS_CONTINUE_FLAG_ABORT, TAC_PLUS_AUTHEN_CONTINUE_STATUS_PASS, TAC_PLUS_AUTHEN_CONTINUE_STATUS_FAIL, or TAC_PLUS_AUTHEN_CONTINUE_STATUS_ERROR.
The client MUST give the server the final consent, by waiting for a REPLY packet with one of the status: TAC_PLUS_AUTHEN_STATUS_PASS, TAC_PLUS_AUTHEN_STATUS_FAIL, or TAC_PLUS_AUTHEN_STATUS_ERROR, thus ending the authentication session.

To support central management of SSH and SSH subsystem authorization and accounting via TACACS+, this document adds a new authen_method to RFC8907 Section 6.1 Authorization REQUEST and a well-known AVP to Section 8.2 Authorization Arguments. The new authen_method TAC_PLUS_AUTHEN_METH_SSHPUBKEY indicates that the user was authenticated with a SSH public key. The well-known ssh_subsystem AVP defines the SSH subsystem for which the authorization is requested and MUST be present any time the authorization is for a SSH connection. The set of permissible values for this AVP are the SSH Subsystem Names defined in the IANA SSH Connection Protocol Subsystem Names Registry, which are case-sensitive as specified and otherwise constrained by Section 4.6.1. The client MAY send an Empty Value for the subsystem name to indicate no subsystem, also known as a shell or CLI. The server MUST NOT reply with status TAC_PLUS_AUTHOR_STATUS_ERROR if it receives a subsystem name whose syntax is valid but whose value is not recognized. Subsystems might need additional data for authorization or accounting that will be particular to that subsystem and are therefore out of scope for this document. These new authen_methods and AVPs apply equally to accounting.

The original draft of TACACS+ described an encryption mechanism built into the protocol. This is insufficient for modern purposes and the document TACACS+ Protocol reclassified the mechanism as one capable only of obfuscation. The introduction of TLS PSK and certificate Peer authentication and TLS encryption to TACACS+ obsolesces these former mechanisms and so are hereby deprecated. This section describes how the TACACS+ client and servers MUST operate with regards to the obfuscation mechanism. The TACACS+ server or client receiving TACACS+ Packets MUST process the packet as if TAC_PLUS_UNENCRYPTED_FLAG was set. The actual value of TAC_PLUS_UNENCRYPTED_FLAG flag in the TACACS+ header MUST be ignored. Peers SHOULD set the TAC_PLUS_UNENCRYPTED_FLAG flag in the Packet Header of packets on TLS Connections, indicating that the data obfuscation is not used.

This section deprecates features from the TACACS+ Protocol. MS-CHAPv1: has been replaced by MS-CHAPv2 in most deployments, the intent of this deprecation is to complete the transition. MD4 is still required to support MS-CHAPv2 so cannot be deprecated at this point It should be noted that the use of MD4 is purely to allow compatible MS-CHAPv2 operation and not for security; the TLS transport is intended to provide that function. TAC_PLUS_AUTHEN_SENDAUTH: the sendauth mechanism can not be supported, as it permits the leak of sensitive information.

This document improves the confidentiality, integrity, and authentication of the connection and network traffic between TACACS+ Peers by adding TLS support. This does not in itself protect the server nor clients; the operator and equipment vendors have a role. That role is to diligently follow current best practices for maintaining the integrity of network devices and selection of TLS key and encryption algorithms.

TLS encryption SHOULD be used in deployments when both the Clients and Servers support it. Servers that support TLS encryption MAY be configured to allow Unsecure Connections when TLS encryption is not supported by the Client, but this is NOT RECOMMENDED because of the threat of downgrade attacks, as described in . Unsecure Connections would be better served by separate Servers from the TLS Servers. It is NOT RECOMMENDED to deploy TACACS+ without TLS authentication and encryption, including TLS using the NULL algorithm, except for within test and debug environments. Also see .

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 possible. Given the sensitivity of TACACS+ data, a Client MUST NOT send data until the full TLS handshake completes; that is, Clients MUST NOT send 0-RTT data and Servers MAY abruptly disconnect Clients that do.

Implementations MAY support TLS authentication with Pre-Shared Keys (PSKs), also known as external PSKs in TLS 1.3, which are not resumption PSKs. PSKs SHOULD NOT be shared among Clients or Servers to limit exposure of a compromised key and to ease key rotation. Also see and . PSKs are otherwise considered out-of-scope for this document.

Unfortunately, no single and timely TLS recommendations document exists. Therefore, implementers and operators SHOULD make use of the various RFCs to determine which TLS versions and algorithms should be supported, deprecated, or abandoned, in the absence of updates to this document. Useful examples are the TLS specifications themselves (TLS 1.3), which prescribes mandatory support in Section 9, and TLS Recommendations .

Operators SHOULD be cognizant of the potential of Server and/or Client isolation from their Peer's Certificate Authority (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. Certificate caching and Raw Public Keys are methods to address this, but both are out of scope for this document. Certificate fingerprints are another option.

A new port is considered appropriate and superior to a "STARTTLS" command or other negotiation method because it allows:

ease of blocking the unencrypted or inferiorly encrypted connections by the TCP/IP port number,
passive Intrusion Detection Systems (IDSs) monitoring the unencrypted version to be unaffected by the introduction of TLS,
avoidance of Man in the Middle (MitM) attacks that can interfere with STARTTLS,
and helps prevent the accidental exposure of sensitive information due to misconfiguration.

However, co-existence of inferior authentication and encryption, whether an Unsecure Connection or deprecated parts that compose TLS, also presents opportunity for down-grade attacks. Causing failure of connections to the TLS-enabled service or the negotiation of shared algorithm support are two such down-grade attacks. The simplest way to address the exposure from Unsecure Connection methods is to refuse Unsecure Connections at the server entirely, perhaps using separate servers for Unsecure Connections and TLS. Another approach is mutual configuration that requires TLS. Clients and Servers SHOULD support configuration that requires Peers, globally and individually, use TLS. Furthermore, Peers SHOULD be configurable to limit offered or recognized TLS versions and algorithms to those recommended by standards bodies and implementers. Servers and Clients could also maintain a cache of Peers that have engaged in TACACS+ TLS connections and demand TLS from that point forward. However, this has potential to be a Denial of Service (DoS) vector, whereby an attacker causes a server to believe that a client that does not support TLS has successfully connected with TLS.

A Client MUST NOT cache SSH public keys received from a Server for future SSH client authentication. Doing so would deny the Server the opportunity to deny authentication for other reasons than key validity or to revoke a key. The Server has no method to revoke a key, except by not offering the key in future authentication sessions.

The authors request that, when this draft is accepted by the working group, the OPSAWG Chairs submit a request to IANA for an early allocation, per and , of a new well-known system TCP/IP port number for the service name "tacacss", described as "TACACS+ over TLS". The service name "tacacss" follows the common practice of appending an "s" to the name given of the non-TLS well-known port. This allocation is justified in . RFC EDITOR: this port number should replace "[TBD]" and the service name should replace "[TBDN]" within this document.

The author(s) would like to thank Russ Housley, Steven M. Bellovin, Stephen Farrell, Alan DeKok, Warren Kumari, and Tom Petch for their support, insightful review, and/or comments. was also used as a basis for the approach to TLS.