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

From: Jan Pechanec <[email-masked]>
Date: Wed, 8 Dec 2010 13:58:43 +0100 (CET)

hi,

	Oracle's implementation of the X.509 part[1] 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.

	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.

	thank you, Jan.

[1] http://tools.ietf.org/id/draft-saarenmaa-ssh-x509-00.txt
[2] http://www.ietf.org/id/draft-pechanec-pkcs11uri-03.txt

--
Jan Pechanec
http://blogs.sun.com/janp

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 08 Dec 2010 11:45:28 -0500

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

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).

> 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.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Dec 2010 12:50:07 -0600

> think the community has mostly settled on PKCS#11 as being the primary

I agree as well that introducing new messages based on PKCS#11 is better
than abusing the existing SSH_AGENTC_ADD_SMARTCARD_KEY message.

> with dynamic changes in the number of slots).

A reasonably good solution is to pretend that there are many slots -- as
many as might ever be expected to exist.  But I agree, PKCS#11 is rather
limited here.

> that I'm volunteering, mind you.

That's why Jan posted this.  There are multiple implementors, and we all
like to make sure that our implementations interop.  But we lack both,
Standards-Track specifications and registries.  Therefore posting here
(and perhaps elsewhere?) seems like a reasonable way to pseudo-register
protocol elements.

Nico
--

---

From: der Mouse <[email-masked]>
Date: Wed, 8 Dec 2010 14:06:01 -0500 (EST)

> 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.

At least one such I-D has existed; the IETF apparently thew away their
copies(!), but
http://www.vandyke.com/technology/draft-ietf-secsh-agent.txt has what
looks like the latest version I know of.  It's somewhat broken -
perhaps most notably, it has an eight-bit field for which one of the
specified values is 301 - but it's about the best I know of.  It, or
perhaps some other version of that draft, is what I wrote my agent
implementation to.

I am not willing to jump through the IETF's stupid I-D hoops (and, yes,
I believe that's what they are), so I will not be resurrecting it as an
I-D.  I would cheerfully collaborate on the content if someone else
wants to undertake the hoop-jumping.  If not, I'll volunteer to host a
non-IETF document; under those circumstances, that's about as close to
a standard as we're likely to get.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Jan Pechanec <[email-masked]>
Date: Thu, 9 Dec 2010 13:00:59 +0100 (CET)

>by IANA according to the "IETF Consensus" policy, and appear in no

	hi, I'm aware of that. However, at least 4 different 
implementations support the original draft - VanDyke, Attachmate, Roumen 
Petrov's patch to OpenSSH, and Tectia (I think). We want to be 
compatible with such implementations.

>shortly on this mailing list, due to some changes that have been

	I know the draft and I hope it will become an RFC soon. As far 
as I know, no implementation supports it yet. It should not be difficult 
for us to add support for it in the future.

[...]

>with dynamic changes in the number of slots).

	the original smartcard code was replaced with PKCS#11 support in 
OpenSSH 5.4. I guess you had worked with the orignal code.

[...]

>that I'm volunteering, mind you.

	I agree. Before that happens, I think this alias is still the 
best communication channel for such things.

	thanks for comments, Jan.

---

From: Jan Pechanec <[email-masked]>
Date: Thu, 9 Dec 2010 13:04:19 +0100 (CET)

>perhaps some other version of that draft, is what I wrote my agent

	hi, I found the document when looking for the write-ups of the 
protocol and this one seems to be quite different from what OpenSSH and 
many other implementations support. The differences are subtle but there 
are quite a few of them. For example, check format of 
SSH_AGENTC_ADD_RSA_IDENTITY versus SSH_AGENT_ADD_KEY.

	J.

---

From: der Mouse <[email-masked]>
Date: Thu, 9 Dec 2010 09:38:36 -0500 (EST)

>> http://www.vandyke.com/technology/draft-ietf-secsh-agent.txt
> protocol and this one seems to be quite different from what OpenSSH
> and many other implementations support.  The differences are subtle
> but there are quite a few of them.  For example, check format of

I'd be interested to hear where I can find the documentation on this
protocol OpenSSH &c speak.  Are you talking about the stuff in
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.agent?rev=HEAD
or is this something else?  (I need to go through and figure out
exactly what moussh implements; I don't recall whether I bothered to
check whether the various bits of documentation I have agree with one
another or not.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Jan Pechanec <[email-masked]>
Date: Thu, 9 Dec 2010 16:03:36 +0100 (CET)

>check whether the various bits of documentation I have agree with one

	yes. I believe that PROTOCOL.agent file is the de facto place to 
read about the agent protocol that OpenSSH and others use. I haven't 
found it elsewhere. J.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 09 Dec 2010 10:49:41 -0500

> compatible with such implementations.

Fair enough.

> OpenSSH 5.4. I guess you had worked with the orignal code.

Indeed, I wasn't aware that such progress had been made.

-- Jeff