Subject: [SSH] GSS key exchange methods

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Sat, 10 Sep 2016 00:35:55 -0600

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:

https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-04

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

https://tools.ietf.org/html/rfc4462

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 10 Sep 2016 13:48:10 -0400 (EDT)

On Sat, 10 Sep 2016, denis bider (Bitvise) wrote:

> I forward parts of a correspondence with Mike discussing the need to address
> GSSAPI key exchange methods in the ssh-kex-sha2 draft:
>  
> "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 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

[Obligatory note that the GSS-API is truly *generic*, in that I know of
sites that use a GSS mechanism that backends to X.509 certificates instead
of Kerberos.  I'm willing to ignore the GSS NTLM variants, though :) ]

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

It is quite useful in those environments, yes, but is not risk-free.  The
most glaring risk is when GSS is using Kerberos, Kerberos is using DNS
lookups (without DNSSEC) to expand the hostname in the host-based service
principal, and both GSSAPIKeyExchange and GSSAPIDelegateCredentials are in
use (to use the openssh spellings).  In this case, an attacker that can
spoof DNS responses to point the user at an attacker-controlled machine
that has valid Kerberos credentials, can obtain a valid TGT of that user,
granting near-full privilege to act as that user!  For this reason, we
disable GSSAPIKeyExchange in environments where users are likely to use
GSSAPIDelegateCredentials, as the risk is too large.

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

Sure; I'd like to see them.

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

I believe the PuTTY patches were maintained out of tree for a while but
did eventually make it in.  I'll add a few more CCs that are or used to be
in the business of maintaining patches for GSS SSH support.

-Ben