Network Working Group J. Galbraith INTERNET-DRAFT J. Van Dyke Expires May 2001 Van Dyke Technologies November 2000 Secure Shell Public Key Channel < draft-galb-secsh-publickey-channel-00.txt > Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a channel that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. The public key channel provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with a mandatory command. 1. Introduction SECSH is a protocol for secure remote login and other secure network services over an insecure network. SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. Common practice is to authenticate once with password authentication and transfer the public key to the server. However, to date no two implementations use the same mechanism to configure a public key for use. This document describes a channel that can be used to configure public keys in an implementation-independent fashion. This approach allows client software to take on the burden of this configuration. The public key channel protocol is designed for extreme simplicity in implementation. It is not intended as a PKIX replacement. The Secure Shell Public Key Channel has been designed to run on top of the SECSH transport layer [SSH-TRANS] and user authentication protocols [SSH-AUTH]. It provides a simple mechanism for the client to manage public keys on the server. This document should be read only after reading the SECSH architecture [SSH-ARCH] and SECSH connection [SSH-CONN] documents. The protocol requires that the user be able to authenticate in some fashion before it can be used. If password authentication is used, servers SHOULD provide a configuration option to disable the use of password authentication after the first public key is added. 2. Public Key Channel Overview The public key channel provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. The channel name is "publickey". The public keys added, removed, and listed using this channel are specific and limited to the authenticated user. All requests are sent as channel data and formatted using the SECSH packeting described in [SSH-TRANS]. The format of public key blobs are detailed in the SSH Transport Protocol document [SSH-TRANS]. 2.1 Opening a public key channel The SSH_MSG_CHANNEL_OPEN request is described in detail in the SECSH connection document [SSH-CONN]. Before any request packets can be sent, the channel must be opened. In order to open a public key channel, the client sends: byte SSH_MSG_CHANNEL_OPEN string "publickey" uint32 sender channel uint32 initial window size uint32 maximum packet size The server SHOULD fail the open if the user authenticated with a restricted public key that does not allow access to the "publickey" channel. The server responds with either SSH_MSG_CHANNEL_OPEN_FAILURE or SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as described in the SECSH connection document [SSH-CONN]. Client implementations SHOULD reject these messages; they are normally only sent by the client. 2.2 Requests All requests are sent as SSH_MSG_CHANNEL_DATA packets. A request is of the form: byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data The data is always of the form: string request-name ... request specific data follows Each request MUST be sent as a single packet of channel data. The client MUST receive acknowledgement of each request prior to sending a new request. A request is acknowledged by sending a status packet. If there is data in response to the request, the status packet is sent after all data has been sent. string "status" uint32 status code string description [RFC-2044] string language tag [RFC-1766] Status messages MUST be sent as a single packet of channel data. A status message MUST be sent for unrecognized packets and the request SHOULD NOT close the channel. 2.3 Status codes The status code gives the reason in a more machine-readable format (suitable for localization), and can have the following values: SUCCESS 0 ACCESS_DENIED 1 STORAGE_EXCEEDED 2 REQUEST_NOT_SUPPORTED 3 KEY_NOT_FOUND 4 KEY_NOT_SUPPORTED 5 GENERAL_FAILURE 6 3. "publickey" Channel Operations The "publickey" channel currently defines three operations: add, remove, and list. 3.1 Adding a public key If the client wishes to add a public key, the client sends: string "publickey-add" string comment string public key algorithm name string public key blob The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public key authentications. The comment field contains user-specified text about the public key and may be empty. 3.2 Removing a public key If the client wishes to remove a public key, the client sends: string "publickey-remove" string public key algorithm name string public key blob The server MUST attempt to remove the public key for the user from the appropriate location, so that the public key cannot be used for subsequent authentications. 3.3 Listing public keys If the client wishes to list the known public keys, the client sends: string "publickey-list" The server will respond with zero or more of the following responses: string "publickey" string comment string public key algorithm name string public key blob The comment field contains user-specified text about the public key and may be empty. Each "publickey" response MUST be sent as a single packet of channel data. Following the last "publickey" response, a status packet MUST be sent. An implementation MAY choose not to support this request. 3.4 Associate public key with a mandatory command If the client wishes to associate a command with a specific public key, the client sends: string "publickey-command" string public key algorithm name string public key blob string command The request MUST fail if the public key does not already exist on the server. An implementation MAY choose not to support this request. 4. References [SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet Draft, draft-secsh-architecture-05.txt [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet Draft, draft-secsh-transport-07.txt [SSH-USERAUTH] Ylonen, T., et al, "SSH Authentication Protocol", Internet Draft, draft-ietf-secsh-userauth-07.txt [SSH-CONNECT] Ylonen, T., et al, "SSH Connection Protocol", Internet Draft, draft-secsh-connect-07.txt [RFC-2279] Yergeau, F., "UTF-8, a Transformation Format of Unicode and ISO 10646", October 1996. 5. Author's addresses Joseph Galbraith Van Dyke Technologies, Inc. 4848 Tramway Ridge Dr. NE Suite 101 Albuquerque, NM 87111 USA E-mail: galb@vandyke.com Jeff P. Van Dyke Van Dyke Technologies, Inc. 4848 Tramway Ridge Dr. NE Suite 101 Albuquerque, NM 87111 USA E-mail: jpv@vandyke.com This draft expires May 2001.