Merging GSSAPI kex?

[James Ralston]

On Thu, May 26, 2022 at 10:43 AM Demi Marie Obenour
<demiobenour at gmail.com> wrote:

> I was thinking about the recent problems with the GSSAPI kex patch,
> and I wonder if it would be best to merge GSSAPI kex into OpenSSH
> upstream.  My (admittedly dated) understanding is that the patch is
> of high quality, and that the concerns are instead about the GSSAPI
> implementation in use.  However, I believe this is a non-issue for
> most environments where GSSAPI kex would be useful: if someone can
> find an RCE in the GSSAPI implementation, there are bigger problems
> (like compromised domain controllers).
>
> To avoid increasing the attack surface when GSSAPI is not in use,
> I recommend having it off by default at both build-time and run-time.
> The OpenBSD version would of course ship with it disabled (no GSSAPI
> implementation in base), though there might be a package that
> ships with it enabled.  Most Linux distributions would ship with
> it included in the build, but not enabled via sshd.conf.  In this
> configuration, I would expect there to be no drawbacks other than a
> slightly increased binary size.  I also believe that the additional
> attack surface would be little greater than GSSAPI authentication,
> which OpenSSH already supports.

I agree with this, and will make the following observations:

1.  The GSSAPI kex patch has been well-vetted.

Red Hat, Fedora, and at least several other Linux distributions have
included the GSSAPI kex patch in their official OpenSSH packages for
nearly a decade.  (Red Hat Enterprise Linux 7, released on 2014-06-10,
was the first RHEL release to include it.)  In terms of both breadth
and duration, that is a significant attack surface.  In that time, to
my knowledge, there has been no security flaw discovered in OpenSSH
that was either enabled or worsened by the GSSAPI kex patch.

2.  The GSSAPI kex patch is increasingly useful.

Over the past decade, the rise of tools such as sssd have made it
increasingly easy to join Unix hosts to Active Directory and rely on
Microsoft Active Directory for users, groups, and authentication (1).
At our organization, we join all of our Linux hosts to AD, and rely
extensively on Kerberos authentication that is enabled by all Linux
hosts possessing a Kerberos keytab, including ssh GSSAPI kex
authentication.

My team of 4 people manages over 400 Linux hosts, all joined to AD.  I
have no interest in attempting to wrangle that many host ssh public
keys, and with GSSAPI kex, we do not have to.

3.  Not including the GSSAPI kex patch likely leads to worse overall
    real-world security.

One of the biggest Achilles’ heels of public/private key cryptography
is the secure dissemination of public keys.  To attempt to securely
collect and securely publish all hosts’ respective ssh public keys is
a daunting task, and at least my experience has been that most
organizations do not perform it well.  (There are always stale keys,
there are always some missing keys, et. al.)

If a user connects to a new host for the first time, and that host’s
public key is not yet available, the overwhelming temptation is to
assume that there is no MitM attacker and simply accept the presented
public key.  You can argue users *shouldn’t* do that, but the reality
is that they do, and we all know that they do.

Excluding the GSSAPI kex patch due to theoretical (and arguably
unrealized) concerns over its security fitness, when the effect of
excluding it is to increase the opportunities for users to just accept
new ssh public keys without vetting them, is akin to demanding that
the front door of a house be made of 6” galvanized steel instead of 4”
galvanized steel when the house’s back door is a screen door.  It is
the overall security of the system that matters, and the weakest link
in that overall security is almost always user behavior.  GSSAPI kex
avoids giving users opportunities to do the wrong thing, and that
practical effect trumps any theoretical security concerns.

4.  GSSAPI keys are rotated more frequently than ssh private keys.

Due to the challenge of ssh host public key distribution, I suspect
most sites do not attempt to regularly rotate (change) host ssh keys.
I am sure you could find organizations who operate long-standing hosts
that have been using the same ssh private keys for literally years.

In contrast, the design of Kerberos (mutual authentication, key
versioning) permits changing Kerberos keys as frequently as the
Kerberos TGT lifetime (typically 24 hours).  By default, unless
overridden, an AD-joined host that runs sssd changes its host key
every 30 days (the ad_maximum_machine_account_password_age in
sssd.conf(5)).  This drastically reduces the amount of time that a
potential attacker has to attempt brute-force cracking of the key, or
to impersonate the server (if the attacker were able to obtain the key
from the host keytab file).

So, in summary…

It was perfectly reasonable for the OpenSSH developers to express
security concerns about the GSSAPI kex patch when Simon first proposed
it.  But now we have ~10 years of data that tell us that (fortunately)
those fears were not realized.  These data are compelling that
including GSSAPI kex in OpenSSH will not weaken its overall security
posture—especially if GSSAPI kex is not enabled by default.

Moreover, GSSAPI kex neatly bypasses the thorny issue of secure a
priori distribution of host public ssh keys, the failings of which
enable arguably the biggest security weakness of ssh: users’ tendency
to trust a new host public ssh key without vetting it.  Closing that
practical security risk results in an overall more secure system.

Finally, thanks to modern tools like sssd, an increasing number of
organizations can leverage GSSAPI kex, because their Linux hosts are
joined to AD and have a keytab file.

So I will respectfully second Demi’s request to the OpenSSH
developers: please reconsider your position on integrating the
long-standing unofficial GSSAPI kex patch into the official OpenSSH
distribution.  OpenSSH is one of the most enormously useful tools in
any system administrator’s toolbox—and we are all indebted to you for
your effort over the years in maintaining and enhancing it.
Integrating the GSSAPI kex patch would only make it more useful to
system administrators everywhere.

Thank you for your consideration.

(1) https://sssd.io/