Subject: Re: Certificate authentication

From: [email-masked] (Peter Gutmann)
Date: Sat, 17 Jan 2004 14:57:44 +1300

"Glen Matthews" <[email-masked] writes:

>sorry for the dumb question (if it is dumb) but I can't see any drafts
>dealing with certificate authentication in ssh. ssh.com seems to support
>this, and I see a patch for openssh by Roumen Petrov - but is there any
>position from the wg on this?

I looked at this a while back and the group consensus is that no two people
can agree on how to handle it :-).  I went through the list archives
collecting all the comments on this, it starts around July'01 with:

  For x.509 certificates using rsa keys, SSH Communications 3.0 appears to be
  using PKCS #1 with MD5.

That doesn't describe the format, merely what's inside the RSA bignum... and
the debate then fizzled out again.  There's another post from August '01:

  I would suggest we include the following text in section documenting
  "x509v3-sign-rsa":

  The "x509v3-sign-rsa" key format has the following specific encoding:

     string    "x509v3-sign-rsa"
     byte[n]   x.509v3 compatible der encoded certificate data

  The resulting signature is encoded as follows:

     string    "x509v3-sign-rsa"
     string    rsa_signature_blob

  Variants to this go in the other x.509 sections as appropriate.

  In addition, I would suggest that we note that signatures made with x509v3-
  sign-rsa keys MUST use the SHA-1 hash, and be done using PKCS1.

but then later he says:

  So, we decided to change x.509v3 certificates to use pkcs7 signatures,
  because otherwise, there is no way to know what hashing algorithm was used.

  There are currently two such algorithms defined:

        x509v3-sign-rsa      RECOMMENDED  sign    X.509 certificates (RSA key)
        x509v3-sign-dss      RECOMMENDED  sign    X.509 certificates (DSS key)

      The "x509v3-*" key format has the following generic encoding:

        string    "x509v3-*"
        string    x.509v3 compatible der encoded certificate data

      The resulting signature is encoded as follows:

        string    "pkcs7"
        string    PKCS-7 signature, DER encoded

      The "x509v3-sign-rsa" method indicates that the key
      (or one of the keys in the certificate) is an RSA-key.

      The "x509v3-sign-dss".  As above, but indicates that the key (or
      one of the keys in the certificate) is a DSS-key.

which never appeard in the RFC.  There's a  followup in Jan'02 asking why it's
not present yet, and several other ones indicating that no two people can
agree on how to do this, including the [editorial comment deleted] suggestion
to use:

   The certificate formats based on ssh-rsa extend the public key
   format to include certificate data:

     string    "ssh-rsa-x509v3" / "ssh-rsa-spki" / "ssh-rsa-pgp"
     mpint     e
     mpint     n
     string    certificate

which practically guarantees that one or more implementations will use the e
and n from outside the cert (particularly ones only pretending to do X.509),
completely voiding the purpose of having the cert in the first place.  Even
ssh.com don't seem to know what to do:

  moreover, implementations supporting x509 (e.g. ssh.com) currently send

        string  "DER-encoded cert"

  without even sending the key type.

   Certificates and public keys are encoded as follows:

     string   certificate or public key format identifier
     byte[n]  key/certificate data

  so, i'm confused by the draft and the implementations.

Markus Friedl then comments that:

  This is obviously wrong,

Bill Sommerfeld finally sums it up with:

  i do not want to hold up the core drafts waiting for folks to figure out how
  to use x.509 with ssh.

and Damien Miller followed up with the observation that:

  The current spec is too vague to implement.

There were further comments more recently which indicated that interest in
doing X.509 with SSH was sufficiently low that no-one cared too much about
this issue anyway.

Peter.

---

From: Damien Miller <[email-masked]>
Date: Mon, 19 Jan 2004 13:06:43 +1100

>      string    "ssh-rsa-x509v3" / "ssh-rsa-spki" / "ssh-rsa-pgp"

IIRC it was I that suggested this encoding and then promptly retracted
it after a good night's sleep. I had hoped that this bit of embassasment
would lay undisturbed in the list archives. Anyway:

- I think that the certificate hostkeys or userauth should be specified
in separate drafts.

- I'd prefer that no more changes be made to the current drafts so as
not to (yet again) delay them.

- If changes absolutely have to be made, then I would prefer the current
wording around certificate encoding to be converted to references to
external specifications.

- I don't think that the current wording should just be deleted, as at
least one implementation (ssh.com, and possibly people who are using
patched OpenSSH) does use host-key certificates with the specified
encoding name.

-d

---

From: Roumen Petrov <[email-masked]>
Date: Tue, 27 Jan 2004 08:11:50 +0200

Peter Gutmann wrote:
> [SNIP]

In [SSH-USERAUTH] section 3.3 definition is public key blob. X.509 equivalent is exactly "DER-encoded cert".
Wenn a packet contain X.509 certificates and we would like to compute signature we MUST use ASN.1 DER encoding.

>      byte[n]  key/certificate data

Might definition in [SSH-TRANS] is confusing. Where is public key blob ?

Is "public key blob" == string(format identifier)+byte[n](key data)
or might "public key blob" == byte[n](key data) ?

Of course we know that "public key blob"[SSH-USERAUTH] == "key format"[SSH-TRANS]

>   so, i'm confused by the draft and the implementations.

In case of X.509 certificates "key format" should be ASN.1 DER encoded only,
i.e. without format identifier since X.509 cert. contain all necessary information.

> [SNIP]

About signatures: this is the true/real question.
In case of x509v3-sign-rsa we can use MD5 or SHA-1 hash.
In my implementation we can select preffered rsa hash. Client and server accept authentication packets with both hashes.
Since SHA-1 is preferred in [PKIXPROF] might is good [SSH-TRANS] document to contain lines:
   After 31 December 2004 all SSH implementation MUST use SHA-1 hash to compute x509v3-sign-rsa resulting signature.
   Until that date, conforming SSH may be assumed MD5 and SHA-1 hash based resulting signature as different.

What sort of signature to use in case of x509v3-sign-dss: same as described in [SSH-TRANS] for "ssh-dss" or to
use ASN.1 encoding for dsa-sig(r,s) as is defined in [PKIXALGS] and as is in some SecSH implementations ?

References:
[SSH-TRANS]     Ylonen, T., "SSH Transport Layer Protocol", I-D
                 draft-ietf-transport-17.txt, Oct 2003.

[SSH-USERAUTH]  Ylonen, T., "SSH Authentication Protocol", I-D
                 draft-ietf-userauth-18.txt, Oct 2003.

[PKIXPROF]      Housley, R., Polk, T, Ford, W. and Solo, D., "Internet
                 X.509 Public Key Infrastructure Certificate and
                 Certificate Revocation List (CRL) Profile", RFC 3280,
                 April 2002.

[PKIXALGS]      Bassham, L., Polk, W. and R. Housley, "Algorithms and
                 Identifiers for the Internet X.509 Public Key
                 Infrastructure Certificate and Certificate Revocation
                 Lists (CRL) Profile", RFC 3279, April 2002.

Roumen

---

From: Roumen Petrov <[email-masked]>
Date: Tue, 27 Jan 2004 08:12:51 +0200

> - I think that the certificate hostkeys or userauth should be specified

[SSH-USERAUTH] document should be changed too.

---

From: "Brent McClure" <[email-masked]>
Date: Thu, 29 Jan 2004 17:10:49 -0700

Could I get some clarification about the "compulsory" flag in the
publickey subsystem draft?
http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickey-subsystem-00.txt

The draft talks about how a client can send a "listattributes" request
and the server will respond with zero or more of these responses:

     string    "attribute"
     string    attribute name
     boolean   compulsory

Here is the draft's description of compulsory:

   The "compulsory" field indicates whether this attribute will be
   compulsorily applied to any added keys (irrespective of whether the
   attribute has been specified by the client) due to administrative
   settings on the server.  If the server does not support
   administrative settings of this nature, it MUST return false in the
   compulsory field.

What was the rationale for the compulsory flag? I want to make sure
I understand what we're supposed to do with this flag.

thanks, Brent