]>

thorsten.dahm@gmail.com

NTT

heas@shrubbery.net

Cisco Systems, Inc.

170 West Tasman Dr. San Jose CA 95134 United States of America dcmgash@cisco.com

andrej@ota.si

Operations and Management (ops) Operations and Management Area Working Group TACACS+ SSH Public Key SSH 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.

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

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Technical Definitions The terms defined in Section 2 of are fully applicable here and will not be repeated. The following terms are also used in this document.

SSHServer/TACACS+Client This is the device that is running the SSH server and is configured as a TACACS+ Client.

SSH Public Key Distribution The following mechanism describes the process. This enhancement of TACACS+ Protocol is only applicable to the TLS TACACS+ protocol.

Authentication START Packet A new enumerated value is added for use within the action field of the Authentication START Packet: A new enumerated value is added for use within the authen_type field of the Authentication START Packet:

Authentication REPLY Packet A New enumerated value is added for use within the status section of the Authentication REPLY Packet:

SSH Key download process 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 . 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:

• status = TAC_PLUS_AUTHEN_STATUS_MORE
• data = the next block of keys.

If this is the final block of keys and at least one key was identified, the server MUST respond with:

• status = TAC_PLUS_AUTHEN_STATUS_PASS
• data = the final block of keys.

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.

Encoding of SSH Public Key in Authentication Reply Packet 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 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 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).

Security Considerations 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.

Operational Considerations Public SSH Keys downloaded using this mechanism MUST NOT be stored permanently.

IANA Considerations TBD

References Normative References Informative References

Appendix 1 [REPLACE/DELETE] This becomes an Appendix [REPLACE]

Acknowledgements This template uses extracts from templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz. [REPLACE]

Contributors Thanks to all of the contributors. [REPLACE]