Subject: Re: draft-ietf-secsh-x509

From: Joseph Galbraith <[email-masked]>
Date: Thu, 24 Mar 2005 09:59:54 -0700

Heikki Nousiainen wrote:
> Hello Joseph, Oskari,
> 
> I was talking with Oskari today about the draft on X.509 certificates 
> and figured I might as well write my thoughts down on e-mail.

Thanks... I've cc'd the mailing list on this so we can get
more input.

> I recall there was an issue about signature schemes used in X.509 specs 
> on the IETF SecSh list a long time ago (alas, I can't find any of the 
> e-mails). IIRC, It was noted that locking a method for specific hash 
> scheme might be problematic as not all hardware tokens can do multiple 
> schemes. This issue is pretty much moot as virtually any token out there 
> does signatures over SHA1, which is used in the X.509 spec as well. 
> However, it might be a problem in future, if local policy, say NIST in 
> FIPS, would mandate use of SHA256 instead of SHA1. Now, x509v3-sign and 
> PKCS#7 can handle all kinds of imaginable signatures, but there's no way 
> of communicating capabilities or policy variables of either the client 
> or the server to the other end.
> 
> Consider the following: client has a token that can do SHA1 and SHA256, 
> server only allows SHA256 by local policy. Client first signs over SHA1, 
> which is refused by server. Client has no way of knowing what went 
> wrong, should it now re-try with SHA256 or skip that certificate?

Yes... I know this is a problem.

 > In the spirit of the rest of the protocol, I'd suggest naming the
 > methods along the lines 'x509-sign-dss-sha1' and
 > 'x509-sign-rsa-sha1-pkcs1.5' to remove that ambiguity.

Unfortunately, this doesn't help for userauth as the server
never sends a list of publickey algorithms it is willing
to accept for userauth.

And in the hostkey case, we just really can't solve
the problem adequately, and I've been kind of reluctant
to introduce the ugliness for a inadequate solution.

Consider a certificate chain that uses mixed algorithms;
the leaf certificate user DSA w/ SHA1, an intermediate
certificate doing RSA w/ MD5 and a root certificate doing
RSA w/ SHA256.

Such algorithm requirements can't be expressed in the
SSH protocol-- well, not reasonably anyway.

We could do something like make the algorithm name:

x509v3-sign-{algo-hash-method}-{algo-hash-method}-...-{algo-hash-method}

where the first {algo-hash-method} was for the leaf certificate,
and the last was for the root certificate.  But if I remember
correctly, the algorithm list in total must be less that
255 characters... so I can easily imagine us running short
of space here.

For hostkeys, I think the only solution is for admins to make
sure that their certificate chains are compatilble with the
servers and clients in use-- I don't think we can really
solve this problem (without a prohibitive amount of work.)

For the user auth request, I suppose we could define a new
message:

      byte      SSH_MSG_USERAUTH_SIGN_ALGORITHM_UNSUPPORTED
      string    hash[0..n]

where hash[0..n] is a list of algorithm oids of hashes which
can be used with the server.  The server MUST send this
message if the algorithms used in the pkcs7 signature are
not acceptable, regardless of whether the signature is
correct or incorrect.  The server SHOULD NOT count the
attempt as a authentication attempt.

I'm mildly against such a proposal, but I could live with it.
I'm not sure if it would need to be more complex; are there more
algorithms than the hash which need to be negotiated?

Thanks,

Joseph

---

From: Heikki Nousiainen <[email-masked]>
Date: Tue, 29 Mar 2005 10:19:38 +0300

> never sends a list of publickey algorithms it is willing

True, of course. I overlooked that everything goes under the publickey 
authentication.

What I missed as well, is that client can offer the certificate without 
signature to see whether the server accepts the certificate for 
authentication, and then proceed the actual requests with different 
signature schemes. An another option is to include multiple signatures 
within PKCS#7 blob.

I'm not sure whether this is doing certificate authentication the right 
way, but it probably works. Cons I can think of: extra roundtrips, 
hardware token having to do extra encryption passes and/or  having to 
enter pin or passphrase multiple times.

> to introduce the ugliness for a inadequate solution.

Kex already includes the list of host key algorithms, so the signature 
scheme [if key types were named more verbose] would be explicitly agreed 
upon by the client and the server. PKCS#7 fall-back could actually be 
counter-productive here: if client and server don't agree on a scheme, 
they wrap the bits into PKCS#7, cross fingers and hope for the best.

Host certificates carry a problem of their own: client and server have 
no way of knowing whether they share or trust a common CA until they are 
both committed to performing server authentication using certificates. I 
can't say I see a clean and easy way to change that with the current 
algorithm negotiation.

 > 255 characters... so I can easily imagine us running short

I don't think that information is really required, It's a unrecoverable 
error anyway. Besides, a holder of the certificate may not know such 
information about the certificate chain.

For userauth, it's easier just to offer the certificate.

> algorithms than the hash which need to be negotiated?

I think that's little bit backwards, and client can probably do fine 
without it.

I wonder if it would be worthwhile to separate certificate 
authentication from publickey authentication in userauth, though. In 
addition to supported signature schemes, the new authentication method 
could be drafted to include sending certificate chains, CRLs and 
whatever certificate related is needed. I'll see if I can come up with a 
sensible proposal to share with the working group.

I'd still consider naming the key types more verbose regardless of any 
of the issues above. If nothing else, it's a good precaution against 
possible compatibility issues.

Regards,
  Heikki Nousiainen