Re: Publickey subsystem draft posted

[Simon Tatham <anakin%pobox.com@localhost>]

Brent McClure <mcclure%swcp.com@localhost> wrote:
> We've refreshed the individual draft of the "Secure Shell Public-Key
> Subsystem". 
> The new draft is available here:
[...]

OK, here are some comments. I'm in favour of a protocol of this type
existing, but I think this draft is going to need some work before
it's useful.

 - You don't mention any kind of packet structure within the
   subsystem channel, like SFTP has. Is this deliberate? It looks at
   the moment as if the individual components of any given request
   (e.g. string "add", string comment, string algorithm, string
   pubkey blob) are sent straight to the subsystem without any
   overall length field.

   If that's correct and not simply a documentation error, it
   _completely_ destroys extensibility: if a subsystem receives any
   request with a name it doesn't recognise, then it cannot know how
   much of the following data belongs to that request, so after
   returning REQUEST_NOT_SUPPORTED it _can't_ resume parsing at the
   next request boundary. Without this basic extensibility property,
   what was the point of having request types described in an
   extensible string namespace at all?

 - Speaking of extensibility, I strongly support Nicolas Williams's
   comment that there already exist SSH server implementations
   supporting a greater range of public key options and restrictions
   than your draft specifies. Surely at the very least there ought
   to be some sort of extension mechanism within the "add" request
   type?

 - The "command" request is seriously under-specified. It does not
   mention whether the key in question is expected to have been
   added using "add" previously, or is added by the "command"
   request itself.

    * If the former, this is a security hazard if naively
      implemented: the _only_ way to set up a restricted key is by
      issuing "add" and then "command", but between those two
      requests, there is a window of opportunity in which someone
      possessing the private key can gain unrestricted access to the
      target account. Since restricted keys are typically keys you
      don't fully trust not to fall into enemy hands, there should
      never be such a window of opportunity. Therefore, an
      implementation MUST delay actually making the changes until
      the subsystem channel is closed or a subsequent
      synchronisation message is sent; this should be clearly
      specified.

    * If the latter, this would make far more sense to me, except
      that the comment field present in the "add" request is missing
      in the "command" request.

   Since I've already proposed an extensibility field in the "add"
   request, I'm tempted to suggest that "command" is a complete
   misfeature and ought to be implemented in terms of that instead.

Cheers,
Simon
-- 
Simon Tatham         These are my opinions. There are many
<anakin%pobox.com@localhost>   like them but these ones are mine.