[36126] in Kerberos
Re: pre-authentication attacks
daemon@ATHENA.MIT.EDU (Ben H)
Thu May 15 10:20:48 2014
MIME-Version: 1.0
In-Reply-To: <87ha4r1s8g.fsf@windlord.stanford.edu>
Date: Thu, 15 May 2014 09:20:27 -0500
Message-ID: <CAAd7auY+j++CcF+6dxoYrna_4PJ77vJ_8onQbJ-s2bTEPSTNEQ@mail.gmail.com>
From: Ben H <bhendin@gmail.com>
To: Russ Allbery <eagle@eyrie.org>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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@eyrie.org> wrote:
> Ben H <bhendin@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@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@eyrie.org) <http://www.eyrie.org/~eagle/>
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
