| Internet-Draft | TACACS+ SSH Public Keys | August 2026 |
| Dahm, et al. | Expires 15 February 2027 | [Page] |
SSH [RFC4251] provides a robust and reliable mechanism to connect to network devices for administration. Conventionally, the public keys required to authenticate SSH sessions are provisioned directly on the network devices. This document adds an extension to Terminal Access Controller Access-Control System Plus (TACACS+) to eliminate the need for the direct provisioning of SSH public keys onto the Network Devices.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 15 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
SSH provides a robust and reliable mechanism to connect to Network Devices for administration. The common approach to provisioning the public keys required to authenticate SSH sessions is to upload them via some administration interface onto the network devices which are acting as SSH server. Once an SSH connection has been established, the Device Administration session is then often mediated (authorized and audited) through protocols such as Terminal Access Controller Access-Control System Plus (TACACS+) Protocol via one or more centralised servers.¶
This document describes an enhancement of the secured version of the TACACS+ protocol [RFC9887] to facilitate the download of the applicable public keys from a central TACACS+ server so that the TACACS+ Client can use it to complete SSH authentication. The intent is to shift the burden of distribution of SSH public keys from the network devices to the central TACACS+ server. Note that this model does NOT extend the SSH authentication flow out from the SSH server (the TACACS+ Client), to the TACACS+ server: The authentication remains completely in the SSH server (The TACACS+ Client). It is important to keep this in mind, as the phase of the AAA protocol that is used to download the public keys is actually the TACACS+ Authentication phase.¶
Specifically, this document adds a new authentication action value into TACACS+ authentication flow which allows the TACACS+ server to send the relevant SSH public keys to the device.¶
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.¶
The terms defined in Section 2 of [RFC9887] are fully applicable here and will not be repeated. The following terms are also used in this document.¶
This is the device that is running the SSH server and is configured as a TACACS+ Client.¶
The following mechanism describes the process. This enhancement of TACACS+ Protocol is only applicable to the TLS TACACS+ protocol.¶
A new enumerated value is added for use within the action field of the Authentication START Packet:¶
TAC_PLUS_AUTHEN_SEND_PUBLIC_KEYS := 0x05¶
A new enumerated value is added for use within the authen_type field of the Authentication START Packet:¶
TAC_PLUS_AUTHEN_TYPE_SSH := 0x07¶
A New enumerated value is added for use within the status section of the Authentication REPLY Packet:¶
TAC_PLUS_AUTHEN_STATUS_MORE := 0x22¶
During the SSH_MSG_USERAUTH_REQUEST phase of SSH authentication, the SSH server retrieves the set of public keys related to the user. These keys are used to determine if the public keys sent by the client in turn can be used to perform the actual login. This section describes the TACACS+ protocol process that the SSHServer/TACACS+Client uses to request the public keys associated with the user from the TACACS+ server.¶
The SSHServer/TACACS+Client MUST send an Authentication Start packet to the TACACS+ server with the following fields:¶
user = The username for which public keys are requested.¶
action = TAC_PLUS_AUTHEN_SEND_PUBLIC_KEYS¶
authen_type = TAC_PLUS_AUTHEN_TYPE_SSH¶
service = TAC_PLUS_AUTHEN_SVC_LOGIN¶
Upon receipt of the Authentication Start packet, the TACACS+ server extracts the username and determines the set of applicable public keys. The mechanism for key storage and retrieval is outside the scope of this document.¶
If public keys are not available, the server responds with status=TAC_PLUS_AUTHEN_STATUS_FAIL.¶
The TACACS+ server assembles the applicable public keys and encodes them into one or more data fields as defined in Section 3.4. The status of the response depends on whether the remaining keys can be fit into the data field of the reply packet that the server is preparing, or if additional packets will be required to transmit the remaining keys in their data fields.¶
If additional keys remain after this packet, the server MUST respond with:¶
If this is the final block of keys and at least one key was identified, the server MUST respond with:¶
The SSHServer/TACACS+Client receives the Authentication Reply packet and extracts the public keys from the data field. It then compares the public key presented by the SSH client with the public keys returned by the TACACS+ server. If a matching key is found, the SSH server continues the SSH public-key authentication procedure and verifies proof of possession of the corresponding private key.¶
If authentication is not successful and the status is TAC_PLUS_AUTHEN_STATUS_MORE, the SSHServer/TACACS+Client MAY send an Authentication CONTINUE packet with an empty data field to request the next block of keys. This cycle continues until authentication succeeds or the server indicates no further keys are available. When the TACACS+ server sends the final key(s), it MUST respond with status = TAC_PLUS_AUTHEN_STATUS_PASS.¶
Following successful authentication, subsequent authorization and accounting procedures proceed as if the SSH key had been provisioned locally by an administrator.¶
The Public Key is encoded in the data field of the Authentication Reply Packet as follows:¶
Key Text: Two options of public keys are supported: the SSH public key format defined in [RFC4716] and the OpenSSH public key format.¶
Encoding Format: Each key string MUST be encoded as base-64 ASCII text. The total length of the base64-encoding plus one delimiter byte MUST be less than the maximum size of the TACACS+ data field (64K). If the encoding exceeds this limit, it MUST be treated as if the key were not present.¶
Delimitation: A delimiter is placed into the data field after each base-64 encoded key (even if there is only one present in a data field). The delimiter is decimal 1 byte if the key is in [RFC4716] format or decimal 0 byte if Open SSH format is used. Base-64 encoding will never include these byte values.¶
Segmentation: The total payload is subject to the 64K size limitation of the TACACS+ data field. Keys MUST be encapsulated such that only complete key encoding strings (and separators) are contained within a single data field. If a key encoding cannot be accommodated within the remaining space of the current data field, the implementation MUST assign a new packet and utilize its data field to continue the sequence.¶
The resulting payload consists of one or more data fields, one per reply, each containing one or more ASCII Text keys delimited by byte (0 or 1).¶
Configuration for this feature on the SSHServer/TACACS+Client MUST include a setting for the maximum lifetime of stored public keys, which MUST default to 5 minutes.¶
Public SSH Keys downloaded using this mechanism MUST NOT be stored permanently.¶
This becomes an Appendix [REPLACE]¶
This template uses extracts from templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz. [REPLACE]¶
Thanks to all of the contributors. [REPLACE]¶