draft-ietf-secsh-publickey-subsystem-08.txt   rfc4819.txt 
Secure Shell Working Group J. Galbraith Network Working Group J. Galbraith
Internet-Draft J. Van Dyke Request for Comments: 4819 J. Van Dyke
Intended status: Informational B. McClure Category: Standards Track VanDyke Software
Expires: April 8, 2007 VanDyke Software
J. Bright J. Bright
Silicon Circus Silicon Circus
October 5, 2006 Secure Shell Public Key Subsystem
Secure Shell Public-Key Subsystem
draft-ietf-secsh-publickey-subsystem-08.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 8, 2007. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Secure Shell defines a user 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.
A public key may also be associated with various restrictions, A public key may also be associated with various restrictions,
including a mandatory command or subsystem. including a mandatory command or subsystem.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Public-Key Subsystem Overview . . . . . . . . . . . . . . . . 6 3. Public Key Subsystem Overview . . . . . . . . . . . . . . . . 3
3.1. Opening the Public-Key Subsystem . . . . . . . . . . . . . 6 3.1. Opening the Public Key Subsystem . . . . . . . . . . . . . 4
3.2. Requests and Responses . . . . . . . . . . . . . . . . . . 7 3.2. Requests and Responses . . . . . . . . . . . . . . . . . . 5
3.3. The Status Message . . . . . . . . . . . . . . . . . . . . 7 3.3. The Status Message . . . . . . . . . . . . . . . . . . . . 5
3.3.1. Status Codes . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Status Codes . . . . . . . . . . . . . . . . . . . . . 5
3.4. The Version Packet . . . . . . . . . . . . . . . . . . . . 8 3.4. The Version Packet . . . . . . . . . . . . . . . . . . . . 6
4. Public-Key Subsystem Operations . . . . . . . . . . . . . . . 9 4. Public Key Subsystem Operations . . . . . . . . . . . . . . . 7
4.1. Adding a Public Key . . . . . . . . . . . . . . . . . . . 9 4.1. Adding a Public Key . . . . . . . . . . . . . . . . . . . 7
4.2. Removing a Public Key . . . . . . . . . . . . . . . . . . 12 4.2. Removing a Public Key . . . . . . . . . . . . . . . . . . 10
4.3. Listing Public Keys . . . . . . . . . . . . . . . . . . . 12 4.3. Listing Public Keys . . . . . . . . . . . . . . . . . . . 10
4.4. Listing Server Capabilities . . . . . . . . . . . . . . . 12 4.4. Listing Server Capabilities . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2.1. Conventions for Names . . . . . . . . . . . . . . . . 15 6.2.1. Conventions for Names . . . . . . . . . . . . . . . . 12
6.2.2. Future Assignments of Names . . . . . . . . . . . . . 16 6.2.2. Future Assignments of Names . . . . . . . . . . . . . 13
6.3. Public-Key Subystem Request Names . . . . . . . . . . . . 16 6.3. Public Key Subsystem Request Names . . . . . . . . . . . . 13
6.4. Public-Key Subsystem Response Names . . . . . . . . . . . 16 6.4. Public Key Subsystem Response Names . . . . . . . . . . . 13
6.5. Public-Key Subsystem Attribute Names . . . . . . . . . . . 16 6.5. Public Key Subsystem Attribute Names . . . . . . . . . . . 13
6.6. Public-Key subsystem Status Codes . . . . . . . . . . . . 17 6.6. Public Key Subsystem Status Codes . . . . . . . . . . . . 14
6.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 17 6.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 14
6.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 17 6.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 14
6.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 17 6.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
Secure Shell is a protocol for secure remote login and other secure Secure Shell (SSH) is a protocol for secure remote login and other
network services over an insecure network. Secure Shell defines a secure network services over an insecure network. Secure Shell
user authentication mechanism that is based on public keys, but does defines a user authentication mechanism that is based on public keys,
not define any mechanism for key distribution. Common practice is to but does not define any mechanism for key distribution. Common
authenticate once with password authentication and transfer the practice is to authenticate once with password authentication and
public key to the server. However, to date no two implementations transfer the public key to the server. However, to date no two
use the same mechanism to configure a public key for use. implementations 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 Public Key Infrastructure
for X.509 Certificates (PKIX) replacement.
The Secure Shell Public-Key subsystem has been designed to run on top The Secure Shell Public Key Subsystem has been designed to run on top
of the Secure Shell transport layer [2] and user authentication of the Secure Shell transport layer [2] and user authentication
protocols [3]. It provides a simple mechanism for the client to protocols [3]. It provides a simple mechanism for the client to
manage public keys on the server. manage public keys on the server.
This document should be read only after reading the Secure Shell This document should be read only after reading the Secure Shell
architecture [1] and Secure Shell connection [4] documents. architecture [1] and Secure Shell connection [4] documents.
This protocol is intended to be used from the Secure Shell Connection This protocol is intended to be used from the Secure Shell Connection
Protocol [4] as a subsystem, as described in the section "Starting a Protocol [4] as a subsystem, as described in the section "Starting a
Shell or a Command". The subsystem name used with this protocol is Shell or a Command". The subsystem name used with this protocol is
skipping to change at page 6, line 5 skipping to change at page 3, line 47
fashion before it can be used. If password authentication is used, fashion before it can be used. If password authentication is used,
servers SHOULD provide a configuration option to disable the use of servers SHOULD provide a configuration option to disable the use of
password authentication after the first public key is added. password authentication after the first public key is added.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [5]. document are to be interpreted as described in RFC2119 [5].
3. Public-Key Subsystem Overview 3. Public Key Subsystem Overview
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. The subsystem name is "publickey". public keys known by the server. The subsystem name is "publickey".
The public keys added, removed, and listed using this protocol are The public keys added, removed, and listed using this protocol are
specific and limited to those of the authenticated user. specific and limited to those of the authenticated user.
The operations to add, remove, and list the authenticated user's The operations to add, remove, and list the authenticated user's
public keys are performed as request packets sent to the server. The public keys are performed as request packets sent to the server. The
server sends response packets that indicate success or failure as server sends response packets that indicate success or failure as
well as provide specific response data. well as provide specific response data.
The format of public-key blobs are detailed in section 6.6, "Public The format of public key blobs are detailed in Section 6.6, "Public
Key Algorithms" of the SSH Transport Protocol document [2]. Key Algorithms" of the SSH Transport Protocol document [2].
3.1. Opening the Public-Key Subsystem 3.1. Opening the Public Key Subsystem
The public-key subsystem is started by a client sending an The Public Key Subsystem is started by a client sending an
SSH_MSG_CHANNEL_REQUEST over an existing session's channel. SSH_MSG_CHANNEL_REQUEST over an existing session's channel.
The details of how a session is opened are described in the SSH The details of how a session is opened are described in the SSH
Connection Protocol document [4] in the section "Opening a Session". Connection Protocol document [4] in the section "Opening a Session".
To open the public-key subsystem, the client sends: To open the Public Key Subsystem, the client sends:
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel uint32 recipient channel
string "subsystem" string "subsystem"
boolean want reply boolean want reply
string "publickey" string "publickey"
Client implementations SHOULD reject this request; it is normally Client implementations SHOULD reject this request; it is normally
sent only by the client. sent only by the client.
If want reply is TRUE, the server MUST respond with If want reply is TRUE, the server MUST respond with
SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully SSH_MSG_CHANNEL_SUCCESS if the Public Key Subsystem was successfully
started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or started, or SSH_MSG_CHANNEL_FAILURE if the server failed to start or
does not support the public-key subsystem. does not support the Public Key Subsystem.
The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user is The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user is
not allowed access to the public-key subsystem (for example, because not allowed access to the Public Key Subsystem (for example, because
the user authenticated with a restricted public key). the user authenticated with a restricted public key).
It is RECOMMENDED that clients request and check the reply for this It is RECOMMENDED that clients request and check the reply for this
request. request.
3.2. Requests and Responses 3.2. Requests and Responses
All public-key subsystem requests and responses are sent in the All Public Key Subsystem requests and responses are sent in the
following form: following form:
uint32 length uint32 length
string name string name
... request/response specific data follows ... request/response specific data follows
The length field describes the length of the name field and of the The length field describes the length of the name field and of the
request/response-specific data, but does not include the length of request/response-specific data, but does not include the length of
the length field itself. The client MUST receive acknowledgement of the length field itself. The client MUST receive acknowledgement of
each request prior to sending a new request. each request prior to sending a new request.
skipping to change at page 7, line 31 skipping to change at page 5, line 31
of the packet. of the packet.
3.3. The Status Message 3.3. The Status Message
A request is acknowledged by sending a status packet. If there is 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 in response to the request, the status packet is sent after all
data has been sent. data has been sent.
string "status" string "status"
uint32 status code uint32 status code
string description [RFC-3629] string description [7]
string language tag [RFC-3066] string language tag [6]
A status message MUST be sent for any unrecognized packets, and the A status message MUST be sent for any unrecognized packets, and the
request SHOULD NOT close the subsystem. request SHOULD NOT close the subsystem.
3.3.1. Status Codes 3.3.1. Status Codes
The status code gives the status in a more machine-readable format The status code gives the status in a more machine-readable format
(suitable for localization), and can have the following values: (suitable for localization), and can have the following values:
SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_SUCCESS 0
skipping to change at page 8, line 37 skipping to change at page 6, line 37
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.
Both sides MUST wait to receive this version before continuing. The Both sides MUST wait to receive this version before continuing. The
"version" packet MUST NOT be sent again after this initial exchange. "version" packet MUST NOT be sent again after this initial exchange.
The SSH_PUBLICKEY_VERSION_NOT_SUPPORTED status code must not be sent The SSH_PUBLICKEY_VERSION_NOT_SUPPORTED status code must not be sent
in response to any other request. in response to any other request.
Implementations MAY use the first 15 bytes of the version packet as a Implementations MAY use the first 15 bytes of the version packet as a
"magic cookie" to avoid processing spurious output from the user's "magic cookie" to avoid processing spurious output from the user's
shell (as described in section 6.5 of [4]). These bytes will always shell (as described in Section 6.5 of [4]). These bytes will always
be: be:
0x00 0x00 0x00 0x0F 0x00 0x00 0x00 0x07 0x76 0x65 0x72 0x73 0x69 0x6F 0x00 0x00 0x00 0x0F 0x00 0x00 0x00 0x07 0x76 0x65 0x72 0x73 0x69 0x6F
0x6E 0x6E
4. Public-Key Subsystem Operations 4. Public Key Subsystem Operations
The public-key subsystem currently defines four operations: add, The Public Key Subsystem currently defines four operations: add,
remove, list, and listattributes. remove, list, and listattributes.
4.1. Adding a Public Key 4.1. Adding a Public Key
If the client wishes to add a public key, the client sends: If the client wishes to add a public key, the client sends:
string "add" string "add"
string public-key algorithm name string public key algorithm name
string public-key blob string public key blob
boolean overwrite boolean overwrite
uint32 attribute-count uint32 attribute-count
string attrib-name string attrib-name
string attrib-value string attrib-value
bool critical bool critical
repeated attribute-count times repeated attribute-count times
The server MUST attempt to store the public key for the user in the 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 appropriate location so the public key can be used for subsequent
public-key authentications. If the overwrite field is false and the public key authentications. If the overwrite field is false and the
specified key already exists, the server MUST return specified key already exists, the server MUST return
SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the
client SHOULD provide an option to the user to overwrite the key. If client SHOULD provide an option to the user to overwrite the key. If
the overwrite field is true and the specified key already exists, but the overwrite field is true and the specified key already exists, but
cannot be overwritten, the server MUST return cannot be overwritten, the server MUST return
SSH_PUBLICKEY_ACCESS_DENIED. SSH_PUBLICKEY_ACCESS_DENIED.
Attribute names are defined following the same scheme laid out for Attribute names are defined following the same scheme laid out for
algorithm names in [1]. If the server does not implement a critical algorithm names in [1]. If the server does not implement a critical
attribute, it MUST fail the add, with the status code attribute, it MUST fail the add, with the status code
skipping to change at page 11, line 29 skipping to change at page 9, line 32
for this attribute. This attribute SHOULD be critical. for this attribute. This attribute SHOULD be critical.
"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-
networks, checking the IP address or performing a reverse DNS lookup. based networks, checking the IP address or performing a reverse DNS
For IP-based networks, it is anticipated that the "from" parameter lookup. For IP-based networks, it is anticipated that each element
will take the form of a specific IP address or hostname. of 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 11 skipping to change at page 10, line 14
In addition to the attributes specified by the client, the server MAY In addition to the attributes specified by the client, the server MAY
provide a method for administrators to enforce certain attributes provide a method for administrators to enforce certain attributes
compulsorily. compulsorily.
4.2. Removing a Public Key 4.2. Removing a Public Key
If the client wishes to remove a public key, the client sends: If the client wishes to remove a public key, the client sends:
string "remove" string "remove"
string public-key algorithm name string public key algorithm name
string public-key blob string public key blob
The server MUST attempt to remove the public key for the user from 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 the appropriate location, so that the public key cannot be used for
subsequent authentications. subsequent authentications.
4.3. Listing Public Keys 4.3. Listing Public Keys
If the client wishes to list the known public keys, the client sends: If the client wishes to list the known public keys, the client sends:
string "list" string "list"
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 There is no requirement that the responses be in any particular
order. Whilst some server implementations may send the responses in order. Whilst some server implementations may send the responses in
some order, client implementations should not rely on responses being some order, client implementations should not rely on responses being
in any order. in any order.
skipping to change at page 15, line 13 skipping to change at page 12, line 13
restrictions than were intended. restrictions than were intended.
6. IANA Considerations 6. IANA Considerations
This section contains conventions used in naming the namespaces, the This section contains conventions used in naming the namespaces, the
initial state of the registry, and instructions for future initial state of the registry, and instructions for future
assignments. assignments.
6.1. Registrations 6.1. Registrations
Consistent with Section 7 of [1], this document makes the following Consistent with Section 4.9.5 of [8], this document makes the
registration: following registration:
The subsystem name "publickey". The subsystem name "publickey".
6.2. Names 6.2. Names
In the following sections, the values for the namespaces are textual. In the following sections, the values for the namespaces are textual.
The conventions and instructions to the IANA for future assignments The conventions and instructions to the IANA for future assignments
are given in this section. The initial assignments are given in are given in this section. The initial assignments are given in
their respective sections. their respective sections.
6.2.1. Conventions for Names 6.2.1. Conventions for Names
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
sign ("@"), comma (","), or whitespace or control characters (ASCII at-sign ("@"), comma (","), or whitespace or control characters
codes 32 or less). Names are case-sensitive, and MUST NOT be longer (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be
than 64 characters. longer 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
preceding 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 [10] controlled by the person or organization defining
name. Names are case-sensitive, and MUST NOT be longer than 64 the 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 [9]
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 [9]. An example of a locally defined name
is "our-attribute@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 [11].
6.3. Public-Key Subystem Request Names 6.3. Public Key Subsystem Request Names
The following table lists the initial assignments of Public-Key The following table lists the initial assignments of Public Key
subsystem Request names. Subsystem Request names.
Request Name Request Name
------------- -------------
version version
add add
remove remove
list list
listattributes listattributes
6.4. Public-Key Subsystem Response Names 6.4. Public Key Subsystem Response Names
The following table lists the initial assignments of Public-Key The following table lists the initial assignments of Public Key
subsystem Response names. Subsystem Response names.
Response Name Response Name
-------------- --------------
version version
status status
publickey publickey
attribute attribute
6.5. Public-Key Subsystem 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 Public- keys. The following table lists the initial assignments of Public
Key subsystem Attribute 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. Public-Key subsystem 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 Public- The following table identifies the initial assignments of the Public
Key subsystem status 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 status codes in the range of 0 to 191 Requests for assignments of new status codes in the range of 0 to 191
MUST be done through the Standards Action method as described in MUST be done through the Standards Action method as described in
[10]. [11].
The IANA will not control the status code range of 192 through 255. The IANA will not control the status code range of 192 through 255.
This range will be left for private use. This range is 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.
[3] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [3] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006. Authentication Protocol", RFC 4252, January 2006.
[4] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection [4] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection
Protocol", RFC 4254, January 2006. Protocol", RFC 4254, January 2006.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[6] Alvestrand, H., "Tags for the Identification of Languages", [6] Phillips, A. and M. Davis, "Tags for Identifying Languages",
BCP 47, RFC 3066, January 2001. BCP 47, RFC 4646, September 2006.
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
7.2. Informative References 7.2. Informative References
[8] Crocker, D., "Standard for the format of ARPA Internet text [8] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol
Assigned Numbers", RFC 4250, January 2006.
[9] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982. messages", STD 11, RFC 822, August 1982.
[9] Mockapetris, P., "Domain names - concepts and facilities", [10] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
8. Acknowledgements
Brent McClure contributed to the writing of this document.
Authors' Addresses Authors' Addresses
Joseph Galbraith Joseph Galbraith
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: galb-list@vandyke.com EMail: galb@vandyke.com
Jeff P. Van Dyke Jeff P. Van Dyke
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: jpv@vandyke.com EMail: jpv@vandyke.com
Brent McClure
VanDyke Software
4848 Tramway Ridge Blvd
Suite 101
Albuquerque, NM 87111
US
Phone: +1 505 332 5700
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 21, line 45 skipping to change at page 17, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 58 change blocks. 
152 lines changed or deleted 130 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/