RE: drasft-green--secsh-ecc-08 support for certificates

["Igoe, Kevin M." <[e-mail]>]

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:[e-mail]] 
Sent: Saturday, June 20, 2009 1:21 AM
To: Igoe, Kevin M.
Cc: [e-mail]
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.

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-20, at 8:35 AM, Nicolas Williams wrote:

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

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
>
>       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
>       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:[e-mail]]
> Sent: Thursday, June 18, 2009 7:13 PM
> To: Igoe, Kevin M.
> Cc: [e-mail]
> 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:
>
> > 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?
>