Agent protocol

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

<Internet-Drafts%ietf.org@localhost> wrote:
> 	Title		: Secure Shell Authentication Agent Protocol
> 	Author(s)	: D. Moffat, T. Rinne, S. Lehtinen
> 	Filename	: draft-ietf-secsh-agent-01.txt

I have a couple of comments on the document as it stands, and a
proposal for an extension.

>   byte      SSH_AGENT_ADD_KEY
>   string    private key blob with empty passphrase
>   string    public key and/or certificates for it
>   string    description of the key
>   ... 0, 1 or several constraints follow

Absolutely vital missing information here: what is the format of the
private key blob? Unlike the public key blob, it hasn't been
standardised in any existing documents for any other reason.

I assume that the `public key and/or certificates' string is
guaranteed suitable for use in SSH_MSG_USERAUTH_REQUEST as the
`public key blob' string? Should this be made any clearer?

>    byte      SSH_AGENT_FAILURE
>    uint32    error code

Would it be too much trouble to allow an optional string after the
error code? I can easily imagine some agents wanting to convey a
human-readable message that contains more information than the small
list of codes provided. We've only just got over this problem in
SFTP; let's not have it all over again...

Also I'd like to propose a simple extension to the protocol. When I
implement this protocol in PuTTY's agent, I will want to add extra
features which are not contained in this protocol. I could just pick
an unused message number and hope nobody treads on it, but that's
nasty. So I propose an additional message number, say 300, which has
the format

    byte      SSH_AGENT_EXTENSION
    string    extension id
    ... extension-specific data follows ...

`extension id' will of course be allocated in the same way all other
SSH string ids are done: anything with an @ in it belongs to the
owner of the domain after the @. That way, I can safely invent
extensions to the agent protocol in a namespace I can be sure nobody
else will attempt to re-use for other purposes.

My vision of this message type is that it can be sent from client to
agent _or_ from agent to client, depending on the extension. An
agent should not be the first to send it, so a client can rely on
not seeing strange unexpected extension messages in response to its
requests; but if the client sends an extension message, the agent
might need to respond with other extension messages if no existing
response message is appropriate.

If the agent sees an extension message it doesn't understand, then
of course it should send back a complaint of some sort. Perhaps
SSH_AGENT_FAILURE / SSH_AGENT_ERROR_UNSUPPORTED_OP.

(One particular feature I want is to be able to add an _encrypted_
key to the agent, in such a way that the agent will list the public
half of it, and will interactively request the passphrase from the
user in response to the first attempt to actually use the key. This
is the advantage of having your agent be GUI-aware... But of course
this will be useless unless the encrypted blob is in PuTTY's own key
format, otherwise the ssh-add analogue will have to reformat it
which will involve decrypting and re-encrypting it.)

Cheers,
Simon
-- 
Simon Tatham         "Every person has a thinking part that wonders what
<anakin%pobox.com@localhost>    the part that isn't thinking isn't thinking about."