IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Publickey subsystem draft posted
Hi,
Brent McClure wrote:
We've refreshed the individual draft of the "Secure Shell Public-Key Subsystem".
The new draft is available here:
http://www.ietf.org/internet-drafts/draft-galb-secsh-publickey-subsystem-01.txt
Following the various comments from the WG, I have the following
suggested text for the changes discussed. A lot of this is taken
directly from things people posted to the mailing list. I think I
caught all the suggested changes. Any errors are my fault. My comments
on the change appear above each patch hunk (I realise you're probably
not going to be able to apply the patch, since the text output is not
the source format, but this seemed the easiest way of presenting it all).
"will" doesn't seem especially RFCish...
@@ -207,7 +207,7 @@
Client implementations SHOULD reject this request; it is normally
only sent by the client.
- If want reply is TRUE, the server will respond with
+ If want reply is TRUE, the server MUST respond with
SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully
started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or
does not support the public-key subsystem.
As Joseph mentioned, length was omitted in the previous version.
Additionally, clarify what the length specifies.
@@ -228,23 +228,25 @@
2.2 Requests
- All public-key subsystem requests are sent request in the following
- form:
+ All public-key subsystem requests are sent in the following form:
+ uint32 length
string request-name
... request specific data follows
- The client MUST receive acknowledgement of each request prior to
- sending a new request.
+ The length field describes the length of the request-name field and
+ the request-specific data, but not of the length field itself. The
+ client MUST receive a response to each request prior to sending a
+ new request.
- All requests described in Section 3 are a description of the 'data'
- portion of the packet.
+ All requests described in Section 3 are a description of the
+ 'request-name' and 'data' portions of the packet.
2.3 Responses
- All public-key subsystem requests are sent request in the following
- form:
+ All public-key subsystem responses are sent in the following form:
+ uint32 length
string response-name
... response specific data follows
All the other drafts define a prefix of the form SSH_<something_ before
their defines. This seems like a sane practice.
@@ -268,12 +270,13 @@
The status code gives the status in a more machine-readable format
(suitable for localization), and can have the following values:
- SUCCESS 0
- ACCESS_DENIED 1
- STORAGE_EXCEEDED 2
- REQUEST_NOT_SUPPORTED 3
- KEY_NOT_FOUND 4
- KEY_NOT_SUPPORTED 5
+ SSH_PUBLICKEY_SUCCESS 0
+ SSH_PUBLICKEY_ACCESS_DENIED 1
+ SSH_PUBLICKEY_STORAGE_EXCEEDED 2
+ SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 3
+ SSH_PUBLICKEY_KEY_NOT_FOUND 4
+ SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5
+ SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6
@@ -282,7 +285,7 @@
Internet-Draft Secure Shell Public-Key Subsystem June 2003
- GENERAL_FAILURE 6
+ SSH_PUBLICKEY_GENERAL_FAILURE 7
Not sure if this is a useful clarification, but it seemed so.
@@ -355,7 +358,7 @@
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.
+ 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.
Both sides MUST wait to receive this version before continuing.
The big change. This is mostly Joseph's suggested text. I added
"agent", "env" and "subsystem" to the restrictions and moved
"port-forward" and "reverse-forward" to be attributes, to allow for
specification of allowed-host lists. Additionally integrated Nicolas'
suggestion regarding mandatory restrictions. Finally, added overwrite,
with behaviour as discussed.
@@ -364,16 +368,124 @@
If the client wishes to add a public key, the client sends:
string "add"
- string comment
string public-key algorithm name
string public-key blob
+ boolean overwrite
+ uint32 attribute-count
+ string attrib-name
+ string attrib-value
+ bool mandatory
+ repeated attribute-count times
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
- public-key authentications.
+ public-key authentications. If the overwrite field is false and the
+ specified key already exists, the server MUST return
+ SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the
+ 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 cannot be overwritten, the server MUST return
+ SSH_PUBLICKEY_ACCESS_DENIED.
+
+ Attribute names are defined following the same scheme laid out for
+ algorithm names in [SSH-ARCH] (section 5). If the server does not
+ implement a mandatory attribute, it MUST fail the add. For the
+ purposes of a mandatory attribute, storage of the attribute is not
+ sufficient, but requires that the server understand and implement
+ the intent of the attribute.
+
+ The following attributes are currently defined:
+
+ "comment"
+ The comment field contains user-specified text about the
+ public key. The server SHOULD make every effort to preserve
+ this value and return it with the key during a list operation.
+ The server MUST NOT attempt to interpret or act upon the content
+ of the comment field in any way.
+
+ The comment field is useful so the user can identify the key
+ without resorting to comparing its fingerprint.
+
+ This attribute SHOULD NOT be mandatory.
+
+ "comment-language"
+ If this attribute is specified, it MUST immediately follow a
+ "comment" attribute and specifies the language for that attribute
+ [RFC1766]. The client MAY specify more than comment if it
+ additionally specifies a different language for each of those
+ comments. The server SHOULD attempt to store each comment,
+ together with that comment's lanuage attribute.
+
+ This attribute SHOULD NOT be mandatory.
+
+ "command"
+ "command" bypasses the session channel "exec" and "shell" requests
+ by always executing the specified command (as if it had been
+ executed using an "exec" request).
+
+ This attribute SHOULD be mandatory. This attribute MUST NOT be
+ specified if the "subsystem" attribute is specified.
+
+ "subsystem"
+ "subsystem" specifies that the specified subsystem should be started
+ when this key is used (as if it had been started using a "subsystem"
+ request.
+
+ This attribute SHOULD be mandatory. This attribute MUST NOT be
+ specified if the "command" attribute is specified.
- The comment field contains user-specified text about the public key
- and MAY be empty.
+ "restrict"
+ The value of this attribute contains server functions that may
+ not be performed when this key is used. It is a comma seperated
+ list. Element names are specified in the same way as attribute
+ names, above. The following restrictions are currently defined:
+
+ Currently defined restrictions are:
+
+ "x11"
+ "shell"
+ "exec"
+ "agent"
+ "env"
+ "subsystem"
+
+ The "x11" restriction specifies that X11 forwarding may not be
+ performed when this key is in use. The "shell" restriction
+ specifies that session channel "shell" requests should be denied
+ when this key is in use. The "exec" restriction specifies that
+ session channel "exec" requests should be denied when this key
+ is in use. The "agent" restriction specifies that session channel
+ "auth-agent-req" requests should be denied when this key is in use.
+ The "env" restriction specifies that session channel "env" requests
+ should be denied when this key is in use. The "subsystem"
+ restriction specifies that subsystems may not be started when this
+ public key is in use (if the "subsystem" attribute is also
specified,
+ the subsystem specified in that attribute is exempted from this
+ restriction).
+
+ This attribute SHOULD be mandatory.
+
+ "port-forward"
+ "port-forward" specifies that no "direct-tcpip" requests should be
+ accepted, except to those 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 mandatory.
+
+ "reverse-forward"
+ "reverse-forward" specifies that no "tcpip-forward" requests should
+ be accepted, accept for the port numbers in the comma-separated
+ list supplied as a value to this attribute. If the value of this
+ attribute is empty, all "tcpip-forward" requests should be refused
+ when using this key.
+
+ This attribute SHOULD be mandatory.
+
+ In addition to the attributes and restrictions specified by the client,
+ the server MAY provide a method for administrators to compulsorily
enforce
+ certain attributes or restrictions.
3.3 Removing a public key
Integrate the attribute stuff into the list response. Further, remove
the "command" request, since it's no longer useful in light of the
additional "add" functionality. Finally, add a method of discovering
the server's supported restrictions. I'm convinced this will assist in
building a sane GUI for this stuff. The split that's present between
"attributes" and "restrictions" makes the response to this request a
little messy. I'm not sure whether it would be better to make the
"restrictions" be freestanding attributes, being that they're (as far as
I can tell) all boolean.
@@ -403,35 +515,47 @@
The server will respond with zero or more of the following responses:
string "publickey"
- string comment
string public-key algorithm name
string public-key blob
-
- The comment field contains user-specified text about the public key
- and MAY be empty.
+ uint32 attribute-count
+ string attrib-name
+ string attrib-value
+ repeated attribute-count times
Following the last "publickey" response, a status packet MUST be
sent.
An implementation MAY choose not to support this request.
-3.5 Associate public key with a mandatory command
+3.5 Listing server capabilities
- If the client wishes to associate a command with a specific public
- key, the client sends:
-
- string "command"
- string public-key algorithm name
- string public-key blob
- string command
+ If the client wishes to know which restrictions the server supports,
+ it sends:
- The request MUST fail if the public key does not already exist on the
- server.
+ string "listattributes"
- An implementation MAY choose not to support this request.
+ The server will respond with zero or more of the following responses:
+ string "attribute"
+ string attribute name
+ boolean compulsory
+
+ The server will then respond with zero or more of the following
+ responses:
+
+ string "restriction"
+ string restriction name
+ boolean compulsory
+
+ The server MAY include "restrict" in the list of attributes it supports.
+ The client SHOULD NOT require the server to do so in order to accept
+ that the server supports the list of restrictions returned by the
+ server.
+ Following the last "restriction" response, a status packet MUST be
+ sent.
+ An implementation MAY choose not to support this request.
If I should avoid wholesale editing of other people's documents in the
future, please let me know :-)
--
Jon Bright
Lead Programmer, Silicon Circus Ltd.
http://www.siliconcircus.com
Home |
Main Index |
Thread Index |
Old Index