--- 1/draft-ietf-secsh-publickey-subsystem-07.txt 2006-10-06 22:12:34.000000000 +0200 +++ 2/draft-ietf-secsh-publickey-subsystem-08.txt 2006-10-06 22:12:34.000000000 +0200 @@ -1,21 +1,21 @@ Secure Shell Working Group J. Galbraith Internet-Draft J. Van Dyke Intended status: Informational B. McClure -Expires: March 5, 2007 VanDyke Software +Expires: April 8, 2007 VanDyke Software J. Bright Silicon Circus - September 1, 2006 + October 5, 2006 Secure Shell Public-Key Subsystem - draft-ietf-secsh-publickey-subsystem-07.txt + 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 @@ -26,29 +26,29 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 5, 2007. + This Internet-Draft will expire on April 8, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 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. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. @@ -70,39 +70,39 @@ 4.1. Adding a Public Key . . . . . . . . . . . . . . . . . . . 9 4.2. Removing a Public Key . . . . . . . . . . . . . . . . . . 12 4.3. Listing Public Keys . . . . . . . . . . . . . . . . . . . 12 4.4. Listing Server Capabilities . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.1. Conventions for Names . . . . . . . . . . . . . . . . 15 6.2.2. Future Assignments of Names . . . . . . . . . . . . . 16 - 6.3. Request Names . . . . . . . . . . . . . . . . . . . . . . 16 - 6.4. Response Names . . . . . . . . . . . . . . . . . . . . . . 16 - 6.5. Attribute Names . . . . . . . . . . . . . . . . . . . . . 16 - 6.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 17 + 6.3. Public-Key Subystem Request Names . . . . . . . . . . . . 16 + 6.4. Public-Key Subsystem Response Names . . . . . . . . . . . 16 + 6.5. Public-Key Subsystem Attribute Names . . . . . . . . . . . 16 + 6.6. Public-Key subsystem Status Codes . . . . . . . . . . . . 17 6.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 17 6.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 17 6.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 17 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 - Intellectual Property and Copyright Statements . . . . . . . . . . 20 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 + Intellectual Property and Copyright Statements . . . . . . . . . . 21 1. Introduction Secure Shell is a protocol for secure remote login and other secure - network services over an insecure network. Secure Shell defines an - authentication mechanism that is based on public keys, but does not - define any mechanism for key distribution. Common practice is to + network services over an insecure network. Secure Shell defines a + user authentication mechanism that is based on public keys, but does + not define any mechanism for key distribution. Common practice is to authenticate once with password authentication and transfer the public key to the server. However, to date no two implementations use the same mechanism to configure a public key for use. This document describes a subsystem that can be used to configure public keys in an implementation-independent fashion. This approach allows client software to take on the burden of this configuration. The public-key subsystem protocol is designed for extreme simplicity in implementation. It is not intended as a PKIX replacement. @@ -224,27 +224,29 @@ SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 If a request completed successfully, the server MUST send the status code SSH_PUBLICKEY_SUCCESS. The meaning of the failure codes is as implied by their names. 3.4. The Version Packet - Both sides MUST start by sending a version packet that indicates the - version of the protocol they are using. + Both sides MUST start a connection by sending a version packet that + indicates the version of the protocol they are using. string "version" 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 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 subsystem and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent. Note that, normally, status messages are only sent by the server (in response to requests from the client). This is the only occasion on which the client sends a status message. @@ -377,20 +379,22 @@ "from" "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 authorization purposes, the authorization attempt MUST be denied. The server SHOULD make a log entry regarding this. The server MAY provide a method for administrators to disallow the appearance of a host in this list. The server should use whatever method is appropriate for its platform to identify the host - e.g. for IP-based 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" specifies that no "direct-tcpip" requests should be accepted, except those to hosts specified in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "direct-tcpip" requests should be refused when using this key. This attribute SHOULD be critical. "reverse-forward" @@ -426,24 +430,29 @@ The server will respond with zero or more of the following responses: string "publickey" string public-key algorithm name string public-key blob uint32 attribute-count string attrib-name string attrib-value 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 sent. - An implementation MAY choose not to support this request. + Implementations SHOULD support this request. 4.4. Listing Server Capabilities If the client wishes to know which key attributes the server supports, it sends: string "listattributes" The server will respond with zero or more of the following responses: @@ -519,118 +528,120 @@ All names registered by the IANA in the following sections MUST be printable US-ASCII strings, and MUST NOT contain the characters at- sign ("@"), comma (","), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. 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. Names with the at-sign in them will have the format of "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 US-ASCII strings, and MUST NOT contain the comma character (","), or whitespace, or control characters (ASCII codes 32 or less). The part following the at-sign MUST be a valid, fully qualified Internet domain name [9] controlled by the person or organization defining 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 namespace. It has been noted that these names resemble STD 11 [8] email addresses. This is purely coincidental and actually has 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 Requests for assignments of new Names MUST be done through the IETF 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 ------------- version add remove list 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 -------------- version status publickey attribute -6.5. Attribute Names +6.5. Public-Key Subsystem Attribute Names Attributes are used to define properties or restrictions for public - keys. The following table lists the initial assignments of Attribute - names. + keys. The following table lists the initial assignments of Public- + Key subsystem Attribute names. Attribute Name --------------- comment comment-language command-override subsystem x11 shell exec agent env from port-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. 6.6.1. Conventions 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 reserved for use by local, private extensions. 6.6.2. Initial Assignments - The following table identifies the initial assignments of the status - code values. + The following table identifies the initial assignments of the Public- + Key subsystem status code values. Status code Value Reference ------------ ----- --------- SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 6.6.3. Future Assignments - Requests for assignments of new message numbers in the range of 0 to - 191 MUST be done through the Standards Action method as described in + 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 [10]. - The IANA will not control the message numbers range of 192 through - 255. This range will be left for private use. + The IANA will not control the status code range of 192 through 255. + This range will be left for private use. 7. References 7.1. Normative References [1] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [2] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. @@ -685,21 +696,21 @@ Email: jpv@vandyke.com Brent McClure VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 - Email: bdm@vandyke.com + Email: bdmccl@yahoo.com Jon Bright Silicon Circus 24 Jubilee Road Chichester, West Sussex PO19 7XB UK Phone: +49 172 524 0521 Email: jon@siliconcircus.com