draft-ietf-secsh-publickey-subsystem-07.txt   draft-ietf-secsh-publickey-subsystem-08.txt 
Secure Shell Working Group J. Galbraith Secure Shell Working Group J. Galbraith
Internet-Draft J. Van Dyke Internet-Draft J. Van Dyke
Intended status: Informational B. McClure Intended status: Informational B. McClure
Expires: March 5, 2007 VanDyke Software Expires: April 8, 2007 VanDyke Software
J. Bright J. Bright
Silicon Circus Silicon Circus
September 1, 2006 October 5, 2006
Secure Shell Public-Key Subsystem Secure Shell Public-Key Subsystem
draft-ietf-secsh-publickey-subsystem-07.txt draft-ietf-secsh-publickey-subsystem-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 5, 2007. This Internet-Draft will expire on April 8, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Secure Shell defines an authentication mechanism that is based on Secure Shell defines a user authentication mechanism that is based on
public keys, but does not define any mechanism for key distribution. public keys, but does not define any mechanism for key distribution.
No common key management solution exists in current implementations. No common key management solution exists in current implementations.
This document describes a protocol that can be used to configure This document describes a protocol that can be used to configure
public keys in an implementation-independent fashion, allowing client public keys in an implementation-independent fashion, allowing client
software to take on the burden of this configuration. software to take on the burden of this configuration.
The public-key subsystem provides a server-independent mechanism for The public-key subsystem provides a server-independent mechanism for
clients to add public keys, remove public keys, and list the current clients to add public keys, remove public keys, and list the current
public keys known by the server. Rights to manage public keys are public keys known by the server. Rights to manage public keys are
specific and limited to the authenticated user. specific and limited to the authenticated user.
skipping to change at page 3, line 26 skipping to change at page 3, line 26
4.1. Adding a Public Key . . . . . . . . . . . . . . . . . . . 9 4.1. Adding a Public Key . . . . . . . . . . . . . . . . . . . 9
4.2. Removing a Public Key . . . . . . . . . . . . . . . . . . 12 4.2. Removing a Public Key . . . . . . . . . . . . . . . . . . 12
4.3. Listing Public Keys . . . . . . . . . . . . . . . . . . . 12 4.3. Listing Public Keys . . . . . . . . . . . . . . . . . . . 12
4.4. Listing Server Capabilities . . . . . . . . . . . . . . . 12 4.4. Listing Server Capabilities . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.1. Conventions for Names . . . . . . . . . . . . . . . . 15 6.2.1. Conventions for Names . . . . . . . . . . . . . . . . 15
6.2.2. Future Assignments of Names . . . . . . . . . . . . . 16 6.2.2. Future Assignments of Names . . . . . . . . . . . . . 16
6.3. Request Names . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Public-Key Subystem Request Names . . . . . . . . . . . . 16
6.4. Response Names . . . . . . . . . . . . . . . . . . . . . . 16 6.4. Public-Key Subsystem Response Names . . . . . . . . . . . 16
6.5. Attribute Names . . . . . . . . . . . . . . . . . . . . . 16 6.5. Public-Key Subsystem Attribute Names . . . . . . . . . . . 16
6.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Public-Key subsystem Status Codes . . . . . . . . . . . . 17
6.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 17 6.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 17
6.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 17 6.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 17
6.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 17 6.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
Secure Shell is a protocol for secure remote login and other secure Secure Shell is a protocol for secure remote login and other secure
network services over an insecure network. Secure Shell defines an network services over an insecure network. Secure Shell defines a
authentication mechanism that is based on public keys, but does not user authentication mechanism that is based on public keys, but does
define any mechanism for key distribution. Common practice is to not define any mechanism for key distribution. Common practice is to
authenticate once with password authentication and transfer the authenticate once with password authentication and transfer the
public key to the server. However, to date no two implementations public key to the server. However, to date no two implementations
use the same mechanism to configure a public key for use. use the same mechanism to configure a public key for use.
This document describes a subsystem that can be used to configure This document describes a subsystem that can be used to configure
public keys in an implementation-independent fashion. This approach public keys in an implementation-independent fashion. This approach
allows client software to take on the burden of this configuration. allows client software to take on the burden of this configuration.
The public-key subsystem protocol is designed for extreme simplicity The public-key subsystem protocol is designed for extreme simplicity
in implementation. It is not intended as a PKIX replacement. in implementation. It is not intended as a PKIX replacement.
skipping to change at page 8, line 10 skipping to change at page 8, line 10
SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6
SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_GENERAL_FAILURE 7
SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8
SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9
If a request completed successfully, the server MUST send the status If a request completed successfully, the server MUST send the status
code SSH_PUBLICKEY_SUCCESS. The meaning of the failure codes is as code SSH_PUBLICKEY_SUCCESS. The meaning of the failure codes is as
implied by their names. implied by their names.
3.4. The Version Packet 3.4. The Version Packet
Both sides MUST start by sending a version packet that indicates the Both sides MUST start a connection by sending a version packet that
version of the protocol they are using. indicates the version of the protocol they are using.
string "version" string "version"
uint32 protocol-version-number uint32 protocol-version-number
This document describes version 2 of the protocol. This document describes version 2 of the protocol. Version 1 was
used by an early draft of this document. The version number was
incremented after changes in the handling of status packets.
Both sides send the highest version that they implement. The lower Both sides send the highest version that they implement. The lower
of the version numbers is the version of the protocol to use. If of the version numbers is the version of the protocol to use. If
either side can't support the lower version, it should close the either side can't support the lower version, it should close the
subsystem and notify the other side by sending an subsystem and notify the other side by sending an
SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a
status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED
SHOULD be sent. Note that, normally, status messages are only sent SHOULD be sent. Note that, normally, status messages are only sent
by the server (in response to requests from the client). This is the by the server (in response to requests from the client). This is the
only occasion on which the client sends a status message. only occasion on which the client sends a status message.
skipping to change at page 11, line 31 skipping to change at page 11, line 31
"from" "from"
"from" specifies a comma-separated list of hosts from which the key "from" specifies a comma-separated list of hosts from which the key
may be used. If a host not in this list attempts to use this key for may be used. If a host not in this list attempts to use this key for
authorization purposes, the authorization attempt MUST be denied. authorization purposes, the authorization attempt MUST be denied.
The server SHOULD make a log entry regarding this. The server MAY The server SHOULD make a log entry regarding this. The server MAY
provide a method for administrators to disallow the appearance of a provide a method for administrators to disallow the appearance of a
host in this list. The server should use whatever method is host in this list. The server should use whatever method is
appropriate for its platform to identify the host - e.g. for IP-based appropriate for its platform to identify the host - e.g. for IP-based
networks, checking the IP address or performing a reverse DNS lookup. networks, checking the IP address or performing a reverse DNS lookup.
For IP-based networks, it is anticipated that the "from" parameter
will take the form of a specific IP address or hostname.
"port-forward" "port-forward"
"port-forward" specifies that no "direct-tcpip" requests should be "port-forward" specifies that no "direct-tcpip" requests should be
accepted, except those to hosts specified in the comma-separated list accepted, except those to hosts specified in the comma-separated list
supplied as a value to this attribute. If the value of this supplied as a value to this attribute. If the value of this
attribute is empty, all "direct-tcpip" requests should be refused attribute is empty, all "direct-tcpip" requests should be refused
when using this key. This attribute SHOULD be critical. when using this key. This attribute SHOULD be critical.
"reverse-forward" "reverse-forward"
skipping to change at page 12, line 33 skipping to change at page 12, line 34
The server will respond with zero or more of the following responses: The server will respond with zero or more of the following responses:
string "publickey" string "publickey"
string public-key algorithm name string public-key algorithm name
string public-key blob string public-key blob
uint32 attribute-count uint32 attribute-count
string attrib-name string attrib-name
string attrib-value string attrib-value
repeated attribute-count times repeated attribute-count times
There is no requirement that the responses be in any particular
order. Whilst some server implementations may send the responses in
some order, client implementations should not rely on responses being
in any order.
Following the last "publickey" response, a status packet MUST be Following the last "publickey" response, a status packet MUST be
sent. sent.
An implementation MAY choose not to support this request. Implementations SHOULD support this request.
4.4. Listing Server Capabilities 4.4. Listing Server Capabilities
If the client wishes to know which key attributes the server If the client wishes to know which key attributes the server
supports, it sends: supports, it sends:
string "listattributes" string "listattributes"
The server will respond with zero or more of the following responses: The server will respond with zero or more of the following responses:
skipping to change at page 15, line 37 skipping to change at page 15, line 37
All names registered by the IANA in the following sections MUST be All names registered by the IANA in the following sections MUST be
printable US-ASCII strings, and MUST NOT contain the characters at- printable US-ASCII strings, and MUST NOT contain the characters at-
sign ("@"), comma (","), or whitespace or control characters (ASCII sign ("@"), comma (","), or whitespace or control characters (ASCII
codes 32 or less). Names are case-sensitive, and MUST NOT be longer codes 32 or less). Names are case-sensitive, and MUST NOT be longer
than 64 characters. than 64 characters.
A provision is made here for locally extensible names. The IANA will A provision is made here for locally extensible names. The IANA will
not register, and will not control names with the at-sign in them. not register, and will not control names with the at-sign in them.
Names with the at-sign in them will have the format of Names with the at-sign in them will have the format of
"name@domainname" (without the double quotes) where the part "name@domainname" (without the double quotes) where the part
preceeding the at-sign is the name. The format of the part preceding preceding the at-sign is the name. The format of the part preceding
the at-sign is not specified, however these names MUST be printable the at-sign is not specified, however these names MUST be printable
US-ASCII strings, and MUST NOT contain the comma character (","), or US-ASCII strings, and MUST NOT contain the comma character (","), or
whitespace, or control characters (ASCII codes 32 or less). The part whitespace, or control characters (ASCII codes 32 or less). The part
following the at-sign MUST be a valid, fully qualified Internet following the at-sign MUST be a valid, fully qualified Internet
domain name [9] controlled by the person or organization defining the domain name [9] controlled by the person or organization defining the
name. Names are case-sensitive, and MUST NOT be longer than 64 name. Names are case-sensitive, and MUST NOT be longer than 64
characters. It is up to each domain how it manages its local characters. It is up to each domain how it manages its local
namespace. It has been noted that these names resemble STD 11 [8] namespace. It has been noted that these names resemble STD 11 [8]
email addresses. This is purely coincidental and actually has email addresses. This is purely coincidental and actually has
nothing to do with STD 11 [8]. An example of a locally defined name nothing to do with STD 11 [8]. An example of a locally defined name
is "ourcipher-cbc@example.com" (without the double quotes). is "our-attribute@example.com" (without the double quotes).
6.2.2. Future Assignments of Names 6.2.2. Future Assignments of Names
Requests for assignments of new Names MUST be done through the IETF Requests for assignments of new Names MUST be done through the IETF
Consensus method as described in [10]. Consensus method as described in [10].
6.3. Request Names 6.3. Public-Key Subystem Request Names
The following table lists the initial assignments of Request names. The following table lists the initial assignments of Public-Key
subsystem Request names.
Request Name Request Name
------------- -------------
version version
add add
remove remove
list list
listattributes listattributes
6.4. Response Names 6.4. Public-Key Subsystem Response Names
The following table lists the initial assignments of Response names. The following table lists the initial assignments of Public-Key
subsystem Response names.
Response Name Response Name
-------------- --------------
version version
status status
publickey publickey
attribute attribute
6.5. Attribute Names 6.5. Public-Key Subsystem Attribute Names
Attributes are used to define properties or restrictions for public Attributes are used to define properties or restrictions for public
keys. The following table lists the initial assignments of Attribute keys. The following table lists the initial assignments of Public-
names. Key subsystem Attribute names.
Attribute Name Attribute Name
--------------- ---------------
comment comment
comment-language comment-language
command-override command-override
subsystem subsystem
x11 x11
shell shell
exec exec
agent agent
env env
from from
port-forward port-forward
reverse-forward reverse-forward
6.6. Status Codes 6.6. Public-Key subsystem Status Codes
The status code is a byte value, describing the status of a request. The status code is a byte value, describing the status of a request.
6.6.1. Conventions 6.6.1. Conventions
Status responses have status codes in the range 0 to 255. These Status responses have status codes in the range 0 to 255. These
numbers are allocated as follows. Of these, the range 192 to 255 is numbers are allocated as follows. Of these, the range 192 to 255 is
reserved for use by local, private extensions. reserved for use by local, private extensions.
6.6.2. Initial Assignments 6.6.2. Initial Assignments
The following table identifies the initial assignments of the status The following table identifies the initial assignments of the Public-
code values. Key subsystem status code values.
Status code Value Reference Status code Value Reference
------------ ----- --------- ------------ ----- ---------
SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_SUCCESS 0
SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_ACCESS_DENIED 1
SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_STORAGE_EXCEEDED 2
SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3
SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_FOUND 4
SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5
SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6
SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_GENERAL_FAILURE 7
SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8
SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9
6.6.3. Future Assignments 6.6.3. Future Assignments
Requests for assignments of new message numbers in the range of 0 to Requests for assignments of new status codes in the range of 0 to 191
191 MUST be done through the Standards Action method as described in MUST be done through the Standards Action method as described in
[10]. [10].
The IANA will not control the message numbers range of 192 through The IANA will not control the status code range of 192 through 255.
255. This range will be left for private use. This range will be left for private use.
7. References 7. References
7.1. Normative References 7.1. Normative References
[1] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol [1] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol
Architecture", RFC 4251, January 2006. Architecture", RFC 4251, January 2006.
[2] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport [2] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport
Layer Protocol", RFC 4253, January 2006. Layer Protocol", RFC 4253, January 2006.
skipping to change at page 19, line 35 skipping to change at page 20, line 35
Email: jpv@vandyke.com Email: jpv@vandyke.com
Brent McClure Brent McClure
VanDyke Software VanDyke Software
4848 Tramway Ridge Blvd 4848 Tramway Ridge Blvd
Suite 101 Suite 101
Albuquerque, NM 87111 Albuquerque, NM 87111
US US
Phone: +1 505 332 5700 Phone: +1 505 332 5700
Email: bdm@vandyke.com Email: bdmccl@yahoo.com
Jon Bright Jon Bright
Silicon Circus Silicon Circus
24 Jubilee Road 24 Jubilee Road
Chichester, West Sussex PO19 7XB Chichester, West Sussex PO19 7XB
UK UK
Phone: +49 172 524 0521 Phone: +49 172 524 0521
Email: jon@siliconcircus.com Email: jon@siliconcircus.com
 End of changes. 26 change blocks. 
38 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/