Another request for gss-keyex inclusion

[ghudson at MIT.EDU]

I would like to request additional consideration for inclusion of the
gss-keyex patch (https://bugzilla.mindrot.org/show_bug.cgi?id=1242)
into mainline OpenSSH.  I know this comes up every few months, and I
know that the current answer is "no" (as stated in November 2007), so
I'll get straight to the new information and possibly-new arguments.

1. I conducted a careful, line-by-line audit of the gss-keyex patch,
looking carefully at cases of pointer arithmetic, array operations,
integer arithmetic which could overflow, interactions between GSSAPI
support and the privsep architecture, anything which could lead to
improper authorization based on what happens during keyex, failures to
check return codes, and consistency between gss-keyex and the other DH
keyex implementations.

I didn't find anything exploitable.  I did find some minor issues
which Simon has corrected in the latest version of the patch.  With
those corrections, I believe the patch to be very solidly written and
to carry minimal risk beyond what is already present in the userauth
code.

2. The risk from the additional code is borne pretty much exclusively
by hosts whose administrators have consciously chosen to place their
security in the care of a GSSAPI implementation.  Any relevant
security holes in the GSSAPI library implementation are likely to be
exploitable by other paths--the existing userauth code, other
GSSAPI-enabled daemons, the system's PAM code, etc..

3. The risk of *not* having this functionality in a large GSSAPI-using
environment is that key exchange is, in most scenarios, vulnerable to
a man-in-the-middle attack.  This is because there are usually too
many hosts to manually manage the known-hosts files, and because hosts
are re-keyed often enough that any DH signature failure will typically
be chalked up to a reinstall.

4. I'm aware of OS packaging deployments of the patch in OSX, Solaris,
and Debian/Ubuntu, and site deployments of the patch at Google,
Stanford, MIT, Sun, Apple, NASA JPL, and DoD HPC.  I don't think that
necessarily speaks to the code-level security of the patch, but it
does speak to its protocol-level desirability.  We collected some
testimony from some of the above sites; here's a snippet from Google
which typifies what is attractive about gss-keyex support to the
people who deploy it:

> We have an extraordinarily dynamic environment which makes this patch
> particularly useful. It's so dynamic in fact that we have a script to
> make removing host keys from ~/.ssh/known_hosts easy and the default
> response to a host key mismatch was to remove the keys from your
> known_hosts (yes, this is horrible from a security point of view, but
> security just got in the way of usability too often due to the nature
> of the environment and given the likelihood of the key being replaced
> was high and the likelihood of it being compromised was low, it was a
> fair trade off at the time). As such, this patch provides a
> significant improvement in security for us (and is likely to do so for
> anyone who has a GSS-API based infrastructure).

Thank you for your consideration.  Regardless of your conclusion,
thank you very much for your work on an excellent tool which I use
every day.

Greg Hudson
MIT Kerberos Consortium