Re: draft-ietf-secsh-x509

[Heikki Nousiainen <Heikki.Nousiainen%F-Secure.com@localhost>]

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


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.

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


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.

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

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.

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


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