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.
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:douglas%stebila.ca@localhost]
Sent: Thursday, June 18, 2009 7:13 PM
To: Igoe, Kevin M.
Cc: ietf-ssh%NetBSD.org@localhost
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?