Re: Extension of the agent protocol for the PKCS#11 URI scheme

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Wed, 2010-12-08 at 13:58 +0100, Jan Pechanec wrote:
> 	Oracle's implementation of the X.509 part[1] 

You should be aware that the referenced document is an expired
internet-draft, and does not represent any part of the SSH protocol
specification.  It was one proposal for adding X.509 certificate support
to SSH, but did not end up being adopted.  In particular, you should be
aware that the public key algorithm names mentioned in that document
come from that portion of the namespace that is reserved for assignment
by IANA according to the "IETF Consensus" policy, and appear in no
registry.

You should take a look at draft-igoe-secsh-x509v3-06.txt, which is
currently in IESG review and is likely to come up again for discussion
shortly on this mailing list, due to some changes that have been
proposed.


That said...


> of the pubkey auth
> method in the SSH protocol works with a PKCS#11 URI scheme[2] and as
> with plain private keys in files, we allow individual keys to be added
> to the agent. For that, we need two new messages in the agent protocol:
> 
>         byte            SSH2_AGENTC_ADD_PKCS11_KEY or
>                         SSH2_AGENTC_ADD_PKCS11_KEY_CONSTRAINED
>         string          PKCS#11 URI
>         string          pin
>         string[]        key_constraints
> 
> 	we could reuse some existing messages, eg. put the URI into 
> reader_id in SSH_AGENTC_ADD_SMARTCARD_KEY used by OpenSSH but that would 
> be a hack. The way how OpenSSH works with keystores is different, all 
> available keys from a PKCS#11 provider are used, if I read the code 
> correctly.

IIRC, the existing smartcard support doesn't use PKCS#11 at all.  The
only implementation I've played with transmits both a reader ID (which
is really what PKCS#11 would consider a single slot) and a key ID, so in
fact only a single key is named.  In any case, I agree that reusing
those messages seems like a hack, and adding new messages may be more
appropriate.  I'd suggest doing something a bit more general, but I
think the community has mostly settled on PKCS#11 as being the primary
abstraction for this (which would be fine, if it didn't deal so poorly
with dynamic changes in the number of slots).


> 	the agent protocol OpenSSH, SunSSH as its derivative, and quite 
> a few other implementations use comes from the original ssh-1.x code. It 
> seems to me that authfd.h and PROTOCOL.agent in the OpenSSH tarball is 
> now the de facto place for others to read about the current state of the 
> protocol. I tried to contact the OpenSSH team about possible update of 
> the file but didn't get a reply.
> 
> 	we would like to notify you about our intention to take two new 
> agent protocol message numbers. While not a problem on a localhost, if 
> we (Oracle) clashed with other implementations we could run into 
> problems when using agent forwarding. For now, we use higher numbers to 
> avoid possible clash with other extensions:
> 
> #define SSH2_AGENTC_ADD_PKCS11_URI_KEY             62
> #define SSH2_AGENTC_ADD_PKCS11_URI_KEY_CONSTRAINED 63
> 
> 	please let us now if the numbers we use clash with any 
> implementation of yours or if you have any other concerns.


I think it's a (past) mistake to think of the agent protocol as being
something private, rather than something for which interoperability is
desirable and therefore for which standardization is appropriate.  I
imagine if someone wanted to write an I-D documenting the protocol and
setting up a registry for these values, that would be a good thing.  Not
that I'm volunteering, mind you.