pre-authentication attacks

[Ben H]

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 <eagle at eyrie.org> wrote:

> 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/>
>