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

[Douglas Stebila <[e-mail]>]

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