Re: gss userauth

[Sam Hartman <hartmans%mit.edu@localhost>]

>>>>> "Love" == Love Hörnquist Åstrand <lha%stacken.kth.se@localhost> writes:

    Love> So I would like to propose adding the following text (marked
    Love> with !) in 3.5 in draft-ietf-secsh-gsskeyex. I knowlingly
    Love> break backward compability because I think the problem is
    Love> important enough to (possibly) break backward compability.

Not surprisingly, I'd prefer not to break backward compatibility.

My reason is simple.  I don't really see this as a new vulnerability
so much as an apparent decision on the part of the WG to change the
threat model.


When we originally wrote this draft, we invisioned the GSSAPI userauth
mechanism would be used with some mechanisms that did not support
mutual authentication or integrity protection.

The mechanism does as good of a job as it can for such cases.  In such
cases, GSSAPI tokens are like one-time passwords.  We know that if an
attacker manages to tunnel them or otherwise get ahold of the token
before the token reaches the server (and the server's replay cache),
then the token can be used by the attacker.

It's reasonable for us to now decide that we want to expand the threat
model and to forbid use of GSSAPI mechanisms that support integrity.
It's also reasonable to allow mechanisms that do not support
integrity, but to use the integrity protection when it is available.
I'm happy with either of these decisions.

But people have deployed code based on our previous approach.  If they
believe that there threat model is acceptable--if they believe that
one-time-password style mechanisms are acceptable to them--then we
should at least provide them an upgrade path.

I don't actually have an opinion on whether we should allow GSSAPI
mechanisms without integrity.  I do strongly agree that we should move
to an environment where integrity protection is better.

--Sam