Internet DRAFT - draft-galb-secsh-publickey-channel
draft-galb-secsh-publickey-channel
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.
