|
Hello Curdle, and the old SSH list:
I forward parts of a correspondence with Mike discussing the need to
address GSSAPI key exchange methods in the ssh-kex-sha2 draft:
- denis:
"RFC 4462 defines the following key exchange methods, which our SSH Client
and Server implement. I am aware also of other implementations by other vendors,
and we hear from users who use them:
The exchange methods parallel the DH key exchange methods, and are
currently:
gss-group1-sha1-*
gss-group14-sha1-*
gss-gex-sha1-*
The current version of the ssh-kex-sha2 draft mentions these, but only to
deprecate gss-gex-sha1-* and gss-group1-sha1-*. The draft allows
gss-group14-sha1-* as a MAY, but does not define any new versions of these
methods to parallel the new DH methods.
These key exchange methods serve a valuable role in environments where it
is possible to authenticate using Kerberos, which is in Unix realms and Windows
domains. The existing trust relationship between the client and the server can
be used in this case, and allows for host authentication without having to set
up or verify a host key on the client. This substantially improves security and
usability in these environments, since lack of proper host key verification
procedures is a big security risk, but their presence is a big pain point for
administration. These key exchange methods avoid that problem in environments
that already have an existing trust network to begin with."
- Mike:
"You make a really good point, I did leave out the GSS-API updates and only
deprecated the -sha1-* entries.
I suspect that the same reasons we defined groups 15, 16, 17, and 18 to use
sha512 would hold for gss-group* kex methods. so, adding:
Key Exchange Method
Name
Reference Note
gss-group14-sha256-*
This Draft MAY
gss-group15-sha512-*
This Draft MAY
gss-group16-sha512-*
This Draft MAY
gss-group17-sha512-*
This Draft MAY
gss-group18-sha512-*
This Draft MAY
would make sense."
-snip-
My proposal also included a suggestion to update the gss-gex- method. Since
it seems unlikely that the GSS methods will be implemented by
resource-constrained devices - in order to use this, a device would have to be
part of a Unix realm or a Windows domain - I suggested gss-gex-sha512-* to
provide a hash that meets the security level of any DH group.
Mike is currently unsure about updating gss-gex-. I don't feel strongly
about this, because the DH group exchange methods are a bit of a can of worms
(FIPS requires group validation that fails with deployed ephemeral groups). The
main priority is that GSS methods serve a unique function, and it would provide
value to maintain them.
For the same reasons we define the DH groups, I think it makes sense to
define the above groups. However, if I needed to pick only one, my priority
would be gss-group15-sha512. This is for the same reasons I prefer
diffie-hellman-group15-sha512. It meets all security recommendations, both in
terms of DH group size and hash size, and it is 2x faster than group 16, which
has performance characteristics that begin to close the gap between denial of
service and normal rate of connections on busy servers.
Does anyone else second these suggestions?
Defining this will not affect servers and clients that do not have a use
for key exchange and host authentication using Kerberos. Only folks who want to
use this will be affected.
I am aware of other implementations of these key exchange methods besides
ours, including patches for popular open source software. I’m not sure if PuTTY
implements them; I think it might just implement the user authentication method
gssapi-with-mic. For the people who do implement this, I’m not sure if they have
representation or awareness of this list.
denis
|