Re: Revised Publickey subsystem draft

["Brent McClure" <mcclure%swcp.com@localhost>]

> a) Does anyone have some suggested text for a security
considerations
> section?  That the protocol assumes it's running over a secure
transport
> layer would seem to be fairly standard, for starters.

What about this for a first pass on Security Considerations. 
Note, this text is inspired by and almost identical to similar 
statements in SFTP's security considerations:

  This protocol assumes that it is run over a secure channel and that
  the endpoints of the channel have been authenticated.  Thus, this
  protocol assumes that it is externally protected from network-level
  attacks.

  This protocol provides a mechanism that allows client authentication
  data to be uploaded and manipulated. It is the responsibility of the 
  server implementation to enforce any access controls that may be 
  required to limit the access allowed for any particular user (the 
  user being authenticated externally to this protocol, typically 
  using the SSH User Authentication Protocol [8].

I was wondering also if something needs to be said about users
applying/erasing "command" attributes in such a way that the publickey
subsystem might be used by a user to override some restrictions on
that user's account that an administrator thought were securely in place.
eg. Once authenticated with a key that always execs some restricted command
shell, the user then uploads a key that has no such restictions. I'm not 
really sure if this is how this "command" feature is used by admins
on servers that support it, but if it were the case then perhaps
some language about implementations needing to allow configuration
to disable access to this subsystem for such users. OTOH, maybe the 
second paragraph above covers that.

--Brent