Secure Shell Public Key Subsystem
draft-ietf-secsh-publickey-subsystem-08

[Ballot comment]
I was imaging an ssh client that supported this and it seems that it would end up having some "send public key" to other side. However, does that automatically add a key to the authorized list? The text that this draft has around things like setting the command-overide implies to me that the act of adding a key actually adds the keys to the authorization list as well. Now if this is the case what soft of "verification" should the client require? Do you need the password again? In a typical client, if the I get the sys admin to log in from my computer to the server and walk look the other direction for 30 seconds, can I add my private keys to the server and be able to log on any time?

Anyways, I think the draft should say more about what the authorization assumptions are around adding or removing keys and give advice to client implementers about security concerns on whey they should allow keys to a be added.

[Ballot comment]
The document is completely missing any reference to the operational considerations of deploying a secure shell public-key subsystem. I would have expected a short section to be included describing what is the deployment strategy, what subsystems are effected and need to be upgraded, if there any default settings or operations at installation, if there is any expected impact on the behavior of the network or other applications, and if any means of monitoring or management are needed or recommended.

IANA Last Call Comments:

As described in the IANA Considerations section of this
document, upon approval of this document IANA understands it
must take two actions:

First, in the registry located at:

http://www.iana.org/assignments/ssh-parameters

in the subregistry marked:

"Connection Protocol Subsystem Names"

IANA will register the subsystem name "publickey"

Second, in the registry located at:

http://www.iana.org/assignments/ssh-parameters

IANA will create three new subregistries. They are
"Request Names," "Response Names," and "Attribute Names."
In each case, requests for new assignments in these
subregistries will be done through IETF consensus.
The initial values for the new subregistries are as follows:

Request Name
-------------
version
add
remove
list
listattributes

Response Name
--------------
version
status
publickey
attribute

Attribute Name
---------------
comment
comment-language
command-override
subsystem
x11
shell
exec
agent
env
from
port-forward
reverse-forward

IANA understands that these are the only actions required upon
publication of the document.

[Ballot comment]
This comment: A question on results ordering and a note on language tagging and selecting language.

Is there any requirement for server ordering of public keys in response to a 'list'?  it might be worth saying the list is unordered so that clients don't come to depend on some accidental ordering.

Language tagging: First, a note on the experience of another group that attempted to define text properties with language tagging -- WebDAV.  We discovered that servers never implemented storing multiple properties, one per language (although it may be that the spec wasn't clear on this point).  But worse, servers didn't even preserve the language information because no client bothered to provide it and so it was usually missed in testing. It remains an interoperability hole (though not a problem as nobody uses it) 8 years later.

I'm not even sure what lesson to draw from this property language tagging experience.  Possibly clients should be required to provide language tags -- this at least forces servers to do the right thing, and most clients can at least pull up a user's system language default value.  Certainly I'd conclude that if single-value language tagging is so seldom used, multiple-value-by-language-tag is even less likely to be used.


Finally, I notice that although the language packet allows the description language to be tagged, there's no way for the client to request that status descriptions be in their own language.  Is the status description intended for display?  Would it be poor form instead for a client to use the status code to look up an appropriate locally-stored description of the status code and discard the description provided by the server which might be in an inappropriate language?

[Ballot comment]
Section 3.1., paragraph 8:
>    It is RECOMMENDED that clients request and check the reply for this
>    request.

  What would that check entail?


Section 3.4., paragraph 1:
>    Both sides MUST start by sending a version packet that indicates the
>    version of the protocol they are using.

  Section 3.1 already talked about starting the public-key subsystem;
  what is started here?


Section 4.3., paragraph 4:
>        uint32    attribute-count
>          string    attrib-name
>          string    attrib-value

  Any reason why "critical" isn't reported? (See 4.1.)


Section 6.2.1., paragraph 2:
>    "name@domainname" (without the double quotes) where the part
>    preceeding the at-sign is the name.  The format of the part preceding

  Nit: s/preceeding/preceding/