pre-authentication attacks

[Ben H]

Russ,

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.
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?

Regarding your second statements - I'm not sure I fully grasp your
meanings.  I am certainly not doubting that there are advantages to the
pre-auth.  The point you make about unused accounts is a good one.
If an enterprise is secured enough to prevent the passive man-in-the-middle
attacks then the advantage is clear.  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.  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?

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 believe we are probably on the same page here, but if you feel I am still
missing your point (and you care to make it again), please elaborate.


On Wed, May 14, 2014 at 5:16 PM, Russ Allbery <eagle at eyrie.org> wrote:

> Ben H <bhendin at gmail.com> writes:
>
> > But the preauthentication gives the added protection of allowing the
> > server to choose/enforce the encryption type used.
>
> I don't believe this is the case.  Whether or not pre-authentication is
> enabled, the server always has the ability to choose or enforce the
> encryption type used.
>
> The difference in the pre-authentication case is that the *attacker*
> cannot choose a weak enctype that the server is willing to accept by
> claiming that the attacker is a client that only supports weak enctypes.
> Instead, the attacker has to work from network capture information from a
> real client, and real clients will always attempt to negotiate the
> strongest encryption type they support.
>
> > That being said, if say AES were the only allowable encryption type used
> > on such a network, the advantages here would be significantly less
> > substantial and if we assumed easy access to the network, and standard
> > encrypted-timestamp preauth, then the advantages of this pre-auth are
> > negligible at best to no pre-auth at all?
>
> Pre-authentication essentially requires the attacker to be capable of
> being a passive man-in-the-middle in order to launch an off-line
> brute-force attack.  If there is no security risk benefit in shifting the
> attacker profile from "anyone who can connect to the KDC" to "passive
> man-in-the-middle," then yes, encrypted timestamp pre-authentication isn't
> really doing anything for you.
>
> That being said, I am rather dubious that you can construct a reasonable
> scenario where that change has no benefit.  A typical enterprise closed
> network use case is *not* such a scenario.  With encrypted timestamp, the
> attacker can still only attack clients for which it has network capture
> data, which means that unused accounts are not vulnerable to off-line
> brute-force, and any limitation on the attacker's ability to see all
> network traffic (and, in practice, there will be many limitations for most
> likely attacker scenarios) will give you more security by reducing the
> principal space the attacker can launch off-line attacks against.
>
> --
> Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>
>