openssh unix dev - May 2017 - Host certificates signed with ed25519 fails with old clients

Hello all,
recently Fedora infrastructure deployed OpenSSH RSA certificates signed 
with ed25519 CA on server with GIT repositories and we encounter 
problems when connecting from old clients (openssh-5.3p1 + certificates) 
as described in the following bug [1].

There is a known workaround (using only the raw key) and after reading 
some more code around the key exchange and certificates specification, I 
don't see a simple way how to prevent it
  * the client does not know what CA key will be used
  * the server can not select raw RSA (different than would be selected 
by client)

The question is, can/should be the ED25519 keys be used for CA? The 
specification (The line 196 [2]) does not list them or is outdated.  If 
it is a bug, can this be fixed? If it is intended, how to prevent using 
ED25519 keys as CA?

Also reading through the gssgex code I noticed duplicate conditions on 
lines 168 and 172 [3]. Can this be fixed too?

Any more ideas to the current problem?

Attached patches to the minor issues, but not resolving the original 
problem.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1450609
[2] 
https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.certkeys#L196
[3] https://github.com/openssh/openssh-portable/blob/master/kexgexc.c#L172

Thanks,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-certkeys.patch
Type: text/x-patch
Size: 1277 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170516/8785d199/attachment.bin>

On Tue, 16 May 2017, Jakub Jelen wrote:
> Hello all,
> recently Fedora infrastructure deployed OpenSSH RSA certificates signed
with
> ed25519 CA on server with GIT repositories and we encounter problems when
> connecting from old clients (openssh-5.3p1 + certificates) as described in
the
> following bug [1].
Yeah, the certificate fallback on the client only works if the client
can parse the certificate and the contained signature key. 5.3p1 knew nothing
about Ed25519 keys, so that's not gonna happen.
> There is a known workaround (using only the raw key) and after reading some
> more code around the key exchange and certificates specification, I
don't see
> a simple way how to prevent it
>  * the client does not know what CA key will be used
>  * the server can not select raw RSA (different than would be selected by
> client)
The server can specify HostKeyAlgorithms, but that only covers the type of
the certificates offered and not the CA keys used for signatures that are
embedded in them. There's at present no way to vary HostKeyAlgorithms or
the set of hostkeys themselves for old clients.
> The question is, can/should be the ED25519 keys be used for CA? The
> specification (The line 196 [2]) does not list them or is outdated.
> If it is a bug, can this be fixed? If it is intended, how to prevent
> using ED25519 keys as CA?
It's definitely intended that Ed25519 keys are allowed as CA keys and
I've updated PROTOCOL.certkeys to reflect this.
> Also reading through the gssgex code I noticed duplicate conditions on
lines
> 168 and 172 [3]. Can this be fixed too?
Fixed; thanks.
> Any more ideas to the current problem?
Not really, and note that a similar problem might happen with certificates
signed with an RSA key using SHA256/512 signatures (possible since
57464e393 by specifying a key type to ssh-keygen).

I've toyed with the idea of adding a "Match banner" capability to
sshd_config. It's a pretty hacky idea, but it would allow things like
overriding HostkeyAlgorithms for old OpenSSH for example.

-d