Ben H <[email protected]> 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 > [email protected], 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 ([email protected]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
