Re: [Curdle] [SSH] GSS key exchange methods

[Benjamin Kaduk <kaduk%MIT.EDU@localhost>]

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

> 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

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

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

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