pre-authentication attacks

[Russ Allbery]

Ben H <bhendin at gmail.com> writes:

> I understand and agree with your first statements regarding the enctype.
> I was proposing a scenario where the environment was restricted to only
> AES types, so a client which only supported DES would not be allowed in
> any event.

Ah, yes, in that model, the distinction between whether the attacker can
request a particular enctype or can only use those from real clients
doesn't really matter.

> Assuming the server preferred AES, but accepted DES if requested, then
> clearly the pre-auth has the advantage.  Of course, even in a pre-auth
> scenario, couldn't I have a rogue client or modify the kerberos
> configuration (or run a second configuration) on a client that I have
> configured to support only a weak enctype?

Sure, but once you can compromise the Kerberos client, there's no point in
doing any sort of brute-force attack.  Just install a keystroke logger and
steal the password directly.

> My argument is mostly taking the vein that if this were compromised
> (switch password discovered, network tap, no ip-sec, compromise of a
> system on isolated network, etc.) that any principal's logon traffic
> which passed to the KDC is a possible target for a pre-auth attack.

This is true, but to get *all* the traffic you have to assume a network
tap on the KDC network.  Now, that may be a concern, but in most
enterprise situations a network tap near a client is far more likely than
a network tap near the KDC.  The latter requires compromising the core of
the data center network, whereas the latter is almost trivial if you have
any clients using wireless hotspots or the like.

> Of course I might not simply be able to request a TGT for
> admin at domain.com, but there is a good chance some administrator
> credentials will flow on a daily basis to the KDC, no?

At Stanford, lots and lots of Kerberos traffic comes from all over the
place, but administrative credentials come from far fewer places.  So
there are a lot of points of network traffic recording vulnerability for
any principal, but much fewer for admin credentials.  It's possible to do
a much better job than we do and always use VPN for admin actions, which
can reduce that window even further.

Of course, in the long run, we would want to always use FAST for admin
credentials, at which point it mostly doesn't matter.

> So while I may be trivializing these other protections, my experience
> tells me that often there are enough overlooked aspects of a network's
> security that gaining the advantage here is not as difficult as it might
> seem.  In the best of all possible worlds, enc timestamp pre-auth has a
> clear advantage - but in practice I am trying to determine what that
> advantage truly is.

I think you're right and we're largely on the same page.  Passive
man-in-the-middle is not a particularly onerous requirement, and security
measures that are vulnerable to passive man-in-the-middle are not
considered particularly strong.  I don't think that encrypted timestamp
pre-auth carries whole lot of security weight.

That said, you also get it for free with any Kerberos implementation, so
some of my response is just there to say that you should always turn on
pre-auth, since there's basically no reason not to and it does help some.
(And yet some sites don't.)

But what you really want is FAST, PKINIT, or (even better than either for
a lot of use cases) some sort of hypothetical PAKE pre-auth mechanism.

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>