Merging GSSAPI kex?

[Dmitry Belyavskiy]

On Thu, May 26, 2022 at 11:45 PM James Ralston <ralston at pobox.com> wrote:

> 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/
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

I strongly second this proposal and could invest some time if necessary as
the current maintainer of OpenSSH in Red Hat.
-- 
Dmitry Belyavskiy