Subject: Re: drasft-green--secsh-ecc-08 support for certificates

From: Douglas Stebila <[email-masked]>
Date: Fri, 19 Jun 2009 09:12:56 +1000

Hi Kevin,

Drafts up until -07 used the language
	string K_S, server's public host key and/or certificates
and then prompted by a comment from Jeffrey Hutzelman I changed it in  
-08 to what you indicated below, in a desire for more precision in the  
specification.

I sent him another email after your post below to enquire about  
changing it back, and here's part of the reply I received:

> The issue is that K_S must be the server's public host key, in the  
> format dictated by the negotiated host key algorithm.  Just randomly  
> replacing it with a certificate (or a key in a different format)  
> will cause interoperability problems.  If Kevin wants to use  
> certificates, he needs to define an SSH public key algorithm whose  
> public key format includes or permits certificates; currently no  
> such algorithms are in use (there are formats defined for keys  
> signed using OpenPGP, but I don't know how widely deployed they are,  
> and there are no formats defined for X.509 certs).

I'm willing to make a change in the draft to allow for the use of  
certificates, as it is the case that the key exchange method should  
transport the host public key / certificate in whatever format was  
decided for it.

I'd just like to have an idea in my mind of how an implementation  
might actually use certificates in an interoperable way in the context  
of ECDSA/SHA-2, which is presumably what you want when you say Suite B  
plans to require the use of certificates for both the client and the  
server.  My interpretation is that, when using an ecdsa-sha2-* method  
for the public key algorithm, an implementation must encode keys in  
the format specified in the draft, which is as a raw point according  
to Section 3.1 of the draft.  Do you intend for another public key  
algorithm to specify for the use of ECDSA/SHA-2 keys in X.509 or PGP  
or some other certificate format?  Is it desired that such a  
specification appear in this draft as well?  Or is there a reason that  
the existing framework of standards already covers it and I'm just not  
aware of it?

Douglas

On 2009-Jun-18, at 5:43 AM, Igoe, Kevin M. wrote:

> Douglas:
>
>  I need to verify a small detail on the SSH_MSG_KEX_ECDH_REPLY
> messages.
>
>  Suite B plans to be conservative and require the use of certificates
> for both the server (sent in the SSH_MSG_KEX_ECDH_REPLY) and client
> (sent in the SSH_MSG_USERAUTH_REQUEST).
>
> As described in section 7 of RFC 4252, SSH_MSG_USERAUTH_REQUEST  
> supports
> a "public key blob" for use in transporting the certificate:
>
> >      byte SSH_MSG_USERAUTH_REQUEST
> >      string user name in ISO-10646 UTF-8 encoding [RFC3629]
> >      string  service name in US-ASCII
> >      string  "publickey"
> >      boolean FALSE
> >      string  public key algorithm name
> >      string  public key blob
> >
> > Public key algorithms are defined in the transport layer
> > specification [SSH-TRANS]. The 'public key blob' may contain
> > certificates.
>
>
> Your SSH_MSG_KEX_ECDH_REPLY message contains the field
>
> >      byte     SSH_MSG_KEX_ECDH_REPLY
> >      string   K_S, server's public host key octet string
> >      string   Q_S, server's ephemeral public key octet string
> >      string   the signature on the exchange hash
> >      string   K_S, server's public host key octet string
>
>
> I've been assuming that the K_S string can, like the "public key
> Blob" string, contain a certificate.  Do you concur with that
> interpretaiion?

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Fri, 19 Jun 2009 08:35:33 -0400

We envisioned the server presenting a certificate of its choice (none
being one of their options).  If the the client doesn't like that cert
(untrusted authority, expired, unknown format), they can, if they wish,
terminate the attempt to establish a secure shell session.  How the
client chooses to handle a bad/missing cert is a policy decision left up
to the client (or their system adminstrator).

Perhaps we could handle this by the addition of a Cert_S string field at
the end of the SSH_MSG_KEX_ECDH_REPLY, say

      string   Cert_S, certificate for server's public host 

where Cert_S is allowed to have length 0 (i.e. Cert_S = 00 00 00 00)

FYI, a draft defining an X.509 based Suite B cetificate format
(draft-solinas-suiteb-cert-03) is in final call.

-----Original Message-----
From: Douglas Stebila [mailto:[email-masked]] 
Sent: Thursday, June 18, 2009 7:13 PM
To: Igoe, Kevin M.
Cc: [email-masked]
Subject: Re: drasft-green--secsh-ecc-08 support for certificates

Hi Kevin,

Drafts up until -07 used the language
	string K_S, server's public host key and/or certificates and
then prompted by a comment from Jeffrey Hutzelman I changed it in
-08 to what you indicated below, in a desire for more precision in the
specification.

I sent him another email after your post below to enquire about changing
it back, and here's part of the reply I received:

> replacing it with a certificate (or a key in a different format) will 
> cause interoperability problems.  If Kevin wants to use certificates, 
> he needs to define an SSH public key algorithm whose public key format

> includes or permits certificates; currently no such algorithms are in 
> use (there are formats defined for keys signed using OpenPGP, but I 
> don't know how widely deployed they are, and there are no formats 
> defined for X.509 certs).

I'd just like to have an idea in my mind of how an implementation might
actually use certificates in an interoperable way in the context of
ECDSA/SHA-2, which is presumably what you want when you say Suite B
plans to require the use of certificates for both the client and the
server.  My interpretation is that, when using an ecdsa-sha2-* method
for the public key algorithm, an implementation must encode keys in the
format specified in the draft, which is as a raw point according to
Section 3.1 of the draft.  Do you intend for another public key
algorithm to specify for the use of ECDSA/SHA-2 keys in X.509 or PGP or
some other certificate format?  Is it desired that such a specification
appear in this draft as well?  Or is there a reason that the existing
framework of standards already covers it and I'm just not aware of it?

Douglas

On 2009-Jun-18, at 5:43 AM, Igoe, Kevin M. wrote:

> supports a "public key blob" for use in transporting the certificate:
>
> I've been assuming that the K_S string can, like the "public key Blob"

> string, contain a certificate.  Do you concur with that 
> interpretaiion?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 19 Jun 2009 17:28:58 -0400

>> Blob" string, contain a certificate.  Do you concur with that

I'm concerned you might be misinterpreting the language in the transport 
and userauth documents.  When the userauth document says "The 'public key 
block' may contain certificates", it doesn't mean that it is permissible to 
send a certificate instead of a public key.  What it means is that for some 
SSH public key algorithms, the specified public key format may include or 
permit use of a certificate.  Implementations of key-exchange methods and 
public-key userauth must send public keys in the format specified for the 
SSH public key algorithm in use; anything else is not in compliance with 
the protocol and will not interoperate.

In particular, if you "require the use of certificates...", then at least 
for the existing ssh-rsa and ssh-dsa public key algorithms, and for the 
ECDSA algorithm specified in the present draft, you are requiring 
noncompliance with the protocol specification.

Now, this could be worked around by defining new public key algorithms 
whose public key format allows the use of certificates.  Some work was done 
on this before the working group concluded, but it never went very far due 
to lack of sufficient interest to get it done.  Note that even if such new 
algorithms were to be defined, either by the IETF or by another party, they 
would likely not be as widely deployed as the current algorithms.

Perhaps more importantly, requiring the use of certificates means requiring 
a mode of operation that is inconsistent with the way people deploy and use 
SSH in real life.  Much use of SSH depends on the "leap of faith" model to 
avoid the need for pre-established PKI, and a standard which prohibited 
that mode of operation would make SSH considerably less useful for anyone 
required to comply.  I suggest considering these issues very carefully 
before introducing such a requirement.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Jun 2009 16:56:43 -0500

> would likely not be as widely deployed as the current algorithms.

+1

> before introducing such a requirement.

Oh come on Jeff!  This, from an author of RFC4462?

I think SSHv2 extensions to allow the use of PKIX certificates for host
and/or user authentication (and key transport!) would have their place.
So too would use of PKIX certificates via PKU2U (hmm, where are we on
that?) and the SSHv2 w/ GSS-API extensions (RFC4462).

In fact, there's plenty of user interest in using SSHv2 w/ certs.  In
practice, however, a combination of PKINIT, RFC4462 and the Kerberos V
GSS-API mechanism are good enough for a lot of the demand (i.e., PKIX
for user certs, not so much for host certs).

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 19 Jun 2009 18:25:51 -0400

--On Friday, June 19, 2009 04:56:43 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> In particular, if you "require the use of certificates...", then at
>> least  for the existing ssh-rsa and ssh-dsa public key algorithms, and
>> for the  ECDSA algorithm specified in the present draft, you are
>> requiring  noncompliance with the protocol specification.
>>
>> whose public key format allows the use of certificates.  Some work was
>> done  on this before the working group concluded, but it never went very
>> far due  to lack of sufficient interest to get it done.  Note that even
>> if such new  algorithms were to be defined, either by the IETF or by
>> another party, they  would likely not be as widely deployed as the
>> current algorithms.
>
> +1
>
>> Perhaps more importantly, requiring the use of certificates means
>> requiring  a mode of operation that is inconsistent with the way people
>> deploy and use  SSH in real life.  Much use of SSH depends on the "leap
>> of faith" model to  avoid the need for pre-established PKI, and a
>> standard which prohibited  that mode of operation would make SSH
>> considerably less useful for anyone  required to comply.  I suggest
>> considering these issues very carefully  before introducing such a
>> requirement.
>

So do I, and I would very much like to see that work happen.  However, to 
date, there hasn't been enough interest in doing the work, from people with 
cycles to do it, for it to actually get done.  I hope no one misinterpreted 
me as saying that no one would be interested in having it; that is 
certainly not the case.

However, my concern is not about defining ways to use certificates with 
SSH, but about promulgating standards that require their use,

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Jun 2009 17:35:44 -0500

> >Oh come on Jeff!  This, from an author of RFC4462?

I had meant to add a smiley there...

> SSH, but about promulgating standards that require their use,

RFC4462 doesn't require the use of GSS-API mechanisms for authentication
either.  If the doc at hand does then you're right, that'd be bad, but
it's hard to believe that it does.

In fact, I just checked and: a) it does not even provide a way to send
certificates, b) much less does it require their use.

All the I-D says about certificates is:

...
      *Verify host key belongs to server.
...
   *It is recommended that the client verify that the host key sent is
   the server's host key (using certificates or a local database).  ...

The "using certificates or a local database" part is repeated once more.

You seem to have interpreted that as meaning that the cert should be
sent instead of just the key, but section 3.1 (Key Format) makes it
clear that that's not the case.

I take the above text to mean that the client should look for a
certificate whose subject public key matches the server's key.  but
that's not a trivial operation (since there's no usually no directories
that can be searched by subject public key).  Therefore I consider that
suggestion to be rather useless at best, ambiguous at worst.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Jun 2009 18:29:54 -0500

> >a "public key blob" for use in transporting the certificate:

I hadn't noticed this earlier.

There's no way to "require" the use of certificates for either the
server, nor the client host, nor the client user, in SSHv2 _today_ with
the existing SSHv2 algorithm names and specs.  To send a cert ina public
key blob slot would not interoperate.

The thing to do is to revive the SSHv2 w/ PKIX document(s) and progress
them.  That means adding new SSHv2 host and hostbased/pubkey user
authentication algorithm names that send certs (and OSCP responses,
...).  Alternatively push for completion of PKU2U and use that via SSHv2
w/ GSS-API key exchange and/or userauth.

Once those are done, requiring the use of certificates with SSHv2, using
those extensions, in any environment would be fine.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Jun 2009 18:00:05 -0500

Ah, seeing the rest of the thread and -07 I get your comments now.

I agree, this I-D a) must not provide a way to use ECC PKIX certs
without providing a way to use PKIX certs generally, and if past efforts
are any guide, that will take some effort, b) must not require use of
ECC certs (but if (a) is met the (b) is implied.

Sorry.

---

From: Douglas Stebila <[email-masked]>
Date: Sat, 20 Jun 2009 15:20:46 +1000

Based on the discussion on the mailing list over the last few days, it  
appears to me that, in the context of draft-green-secsh-ecc,  
certificates are presently not supported.  A future document on using  
X.509 or other certificates in SSH may appear, and this document  
should avoid hindering such a development, but that it is beyond the  
scope of this draft.

At this point, my intentions are to:

1) Have the language regarding K_S in ECDH and ECMQV to read as follows:
         string	K_S, server's public host key
to allow for compatibility with any public host key definition,  
including any future document that may use X.509 certificates.

2) Remove the possible ambiguity in the following text
>   *It is recommended that the client verify that the host key sent  
> is the server's host key (using certificates or a local database).
as noted by Nicolas Williams by changing it to read
	*It is recommended that the client verify that the host key sent is  
the server's host key (for example, using a local database).

On the issue of X.509 certificates in SSH, this does seem like a  
reasonable thing to have standardized.  Having looked at what I think  
is the X.509 in SSH draft
	http://tools.ietf.org/html/draft-ietf-secsh-x509-03
I am surprised that it did not progress, as it seems relatively  
complete.  If there is interest in seeing it revived and the original  
authors are unable/unwilling to carry on with the document, I am  
willing to do so.

Douglas

On 2009-Jun-19, at 10:35 PM, Igoe, Kevin M. wrote:

> We envisioned the server presenting a certificate of its choice  
> (none being one of their options).  If the the client doesn't like  
> that cert  (untrusted authority, expired, unknown format), they can,  
> if they wish, terminate the attempt to establish a secure shell  
> session.  How the client chooses to handle a bad/missing cert is a  
> policy decision left up to the client (or their system adminstrator).
>
> Perhaps we could handle this by the addition of a Cert_S string  
> field at the end of the SSH_MSG_KEX_ECDH_REPLY, say
>
> -08 to what you indicated below, in a desire for more precision in  
> the specification.
>
> will
> might actually use certificates in an interoperable way in the  
> context of ECDSA/SHA-2, which is presumably what you want when you  
> say Suite B plans to require the use of certificates for both the  
> client and the server.  My interpretation is that, when using an  
> ecdsa-sha2-* method for the public key algorithm, an implementation  
> must encode keys in the format specified in the draft, which is as a  
> raw point according to Section 3.1 of the draft.  Do you intend for  
> another public key algorithm to specify for the use of ECDSA/SHA-2  
> keys in X.509 or PGP or some other certificate format?  Is it  
> desired that such a specification appear in this draft as well?  Or  
> is there a reason that the existing framework of standards already  
> covers it and I'm just not aware of it?
>
> Douglas
>
> Blob"

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Mon, 22 Jun 2009 12:18:03 -0400

My primary customers (potential USG users of Suite B) have many
applications where their security requirements are best served by
integrating the use of certificates into secure shell.  It looks like I
have just "volunteered" to issue an informational RFC with some new
secsh public key algorithms. The new SSH public key algorithm names
would be something like

	x509-ecdsa-sha2-p256
	x509-ecdsa-sha2-p384

Naturally I will reuse as much of what is in place as possible.  

Transporting a certificate from the Server to the Client:

  I see two options:
  1) Defining SSH_MSG_KEX_X509_ECDH_* message formats, virtually 
     identical to the SSH_MSG_KEX_ECDH_* messages save for the addition 
     of a "string CERT_S" field to the KEX REPLY (might remove the K_S
field). 
     Sadly this means I'll also need new key excahnge algorithm names 
     (x509-ecdh-sha2-p256, x509-ecdh-sha2-p384) since the KEX, not the
host 
     algorithm, determines the format of the KEX messages. 

  2) Define x509-ecdsa* key formats so that the x509_ecc_key_blob has an
     x509 certificate field (see section 3.1 of
draft-green-secsh-ecc-08).

Transporting a certificate from the Client to the the Server:

  It appears to me that the public key blob field in the
SSH_MSG_USERAUTH_REQUEST 
  is capable of carrying an X509 certificate. (I believe the public key
algorithm 
  controls the format of the key blob, and the SSH_MSG_USERAUTH_REQUEST
has a
  "public key algorithm name" field.)

I'd appreciate any feedback before I go too far down this path.  (An
ounce of prevention etc.)

P.S. How the user or client is to deal with invalid, malformed or
expired certificates is a policy issue.  I intend to allow users to set
their own policies for handling these issues.

P.P.S. As I mentioned earlier, a draft defining an X.509 based Suite B
certificate format (draft-solinas-suiteb-cert-03) is in final call.

-----Original Message-----
From: Douglas Stebila [mailto:[email-masked]] 
Sent: Saturday, June 20, 2009 1:21 AM
To: Igoe, Kevin M.
Cc: [email-masked]
Subject: Re: drasft-green--secsh-ecc-08 support for certificates

Based on the discussion on the mailing list over the last few days, it
appears to me that, in the context of draft-green-secsh-ecc,
certificates are presently not supported.  A future document on using
X.509 or other certificates in SSH may appear, and this document should
avoid hindering such a development, but that it is beyond the scope of
this draft.

> the server's host key (using certificates or a local database).
as noted by Nicolas Williams by changing it to read
	*It is recommended that the client verify that the host key sent
is the server's host key (for example, using a local database).

On the issue of X.509 certificates in SSH, this does seem like a
reasonable thing to have standardized.  Having looked at what I think is
the X.509 in SSH draft
	http://tools.ietf.org/html/draft-ietf-secsh-x509-03
I am surprised that it did not progress, as it seems relatively
complete.  If there is interest in seeing it revived and the original
authors are unable/unwilling to carry on with the document, I am willing
to do so.

Douglas

On 2009-Jun-20, at 8:35 AM, Nicolas Williams wrote:

> that's not a trivial operation (since there's no usually no 
> directories that can be searched by subject public key).  Therefore I 
> consider that suggestion to be rather useless at best, ambiguous at 
> worst.

> (untrusted authority, expired, unknown format), they can, if they 
> wish, terminate the attempt to establish a secure shell session.  How 
> the client chooses to handle a bad/missing cert is a policy decision 
> left up to the client (or their system adminstrator).
>
> Perhaps we could handle this by the addition of a Cert_S string field 
> at the end of the SSH_MSG_KEX_ECDH_REPLY, say
>