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/