Re: Publickey subsystem draft posted

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Tue, Jul 22, 2003 at 12:16:37PM -0600, Joseph Galbraith wrote:
> What if the "add" command where changed as follows?
> 
> 	string "add"
> 	string public-key algorithm
> 	string public-key blob
> 	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.
> 
>   attrib-names without a '@' are reserved to the IETF.  Extensions
>   MAY be used by composing the '@' with a DNS name, for example,
>   'spiffy-extension%vandyke.com@localhost'
> 
>   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 defined by this draft.
> 
>   "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 comment field is useful so the user can identify the
> 	key without resorting to comparing it's fingerprint.

See Bill Sommerfeld's comment about I18N.  You ought to associate a
language tag with the comment.

>   "command"
> 	Command bypasses the session channel "exec" and "shell"
>         requests by always execution the specified command.
> 
> 	This attribute SHOULD be mandatory.

This attibute's values are generally going to be platform-specific.
There's no avoiding that, but it might be a good idea to have a way for
clients to find out about the server's platform and/or validate the
command.

>   "restrict"
> 	The value of this attribute contains server functions that
> 	may not be preformed when this key is used.  It is a comma
> 	seperated list.  Elements containing an '@' are reserved for
> 	implementation / site specific extension; all other elements
> 	are reserved for use by the IETF.

I think of "command" as a restriction, and all of these should be
treated the same way, perhaps with each having it's own attribute name.

> 	Currently defined restrictions are:
> 
> 		"x11"
> 		"shell"
> 		"exec"
> 		"port-forward"
> 		"reverse-forward"
> 
> 	This attribute SHOULD be mandatory.

Don't forget about subsystems.  And no, I don't think the "command"
restriction should be conflated with subsystem restrictions.

For the port forwarding restrictions there should probably be a list of
host:port restrictions associated.

There should probably be a list of host:ports which are allowed to use
this key to authenticate.

> The 'list' command would need to be updated to have
> a similar extension format.

Yes.

> What do you think?  What other extensions should we
> define here?  What other types ofrestrictions should
> be defined?

See above.

Cheers,

Nico
--