draft-ietf-secsh-publickey-subsystem-03.txt   draft-ietf-secsh-publickey-subsystem-04.txt 
Secure Shell Working Group J. Galbraith Secure Shell Working Group J. Galbraith
Internet-Draft J. Van Dyke Internet-Draft J. Van Dyke
Expires: February 25, 2006 B. McClure Expires: March 17, 2006 B. McClure
VanDyke Software VanDyke Software
J. Bright J. Bright
Silicon Circus Silicon Circus
August 24, 2005 September 13, 2005
Secure Shell Public-Key Subsystem Secure Shell Public-Key Subsystem
draft-ietf-secsh-publickey-subsystem-03.txt draft-ietf-secsh-publickey-subsystem-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 25, 2006. This Internet-Draft will expire on March 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
SECSH defines an authentication mechanism that is based on public SECSH defines an authentication mechanism that is based on public
keys, but does not define any mechanism for key distribution. No keys, but does not define any mechanism for key distribution. No
common key management solution exists in current implementations. common key management solution exists in current implementations.
skipping to change at page 5, line 20 skipping to change at page 5, line 20
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 the The length field describes the length of the name field and 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.
The version packet, as well as all requests and responses described The version packet, as well as all requests and responses described
in Section 3 are a description of the 'name' field and the data part in Section 3, are a description of the 'name' field and the data part
of the packet. of the packet.
2.3. The Status Message 2.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
skipping to change at page 6, line 25 skipping to change at page 6, line 25
The version of the protocol described by this document is version 2. The version of the protocol described by this document is version 2.
Both sides send the highest version that they implement. The lower Both sides send the highest version that they implement. The lower
of the version numbers is the version of the protocol to use. If of the version numbers is the version of the protocol to use. If
either side can't support the lower version, it should close the either side can't support the lower version, it should close the
subsystem and notify the other side by sending an subsystem and notify the other side by sending an
SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a
status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED
SHOULD be sent. Note that normally, status messages are only sent by 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 the server (in response to requests from the client). This is the
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.
3. Public-Key Subsystem Operations 3. 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.
skipping to change at page 7, line 32 skipping to change at page 7, line 32
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 mandatory algorithm names in [1]. If the server does not implement a mandatory
attribute, it MUST fail the add, with the status code attribute, it MUST fail the add, with the status code
SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a
mandatory attribute, storage of the attribute is not sufficient, but mandatory attribute, mere storage of the attribute is not sufficient
requires that the server understand and implement the intent of the -- rather, the server must understand and implement the intent of the
attribute. attribute.
The following attributes are currently defined: The following attributes are currently defined:
"comment" "comment"
The value of the comment attribute contains user-specified text about The value of the comment attribute contains user-specified text about
the public key. The server SHOULD make every effort to preserve this the public key. The server SHOULD make every effort to preserve this
value and return it with the key during any subsequent list value and return it with the key during any subsequent list
operation. The server MUST NOT attempt to interpret or act upon the operation. The server MUST NOT attempt to interpret or act upon the
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/