Great - thanks - I agree with pretty much all of that. My questions was again more of a theoretical "what does it really provide?" and are those benefits worth any possible risk. I think that Greg's answer that enc time pre-auth is only slightly more negligible to brute force than without it and the advantages we discussed (although not always in place) helps me buy into pre-auth as a good thing overall as it does reduce the overall footprint.
I still need to research FAST which will be on my list after I finish review of the original RFCs again. On Thu, May 15, 2014 at 1:16 AM, Russ Allbery <[email protected]> wrote: > 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
