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?