pre-authentication attacks

[Ben H]

Thanks for the information, I will have to delve into some of it in more
detail (I don't yet have a good grasp on FAST) or necessarily understand
cryptography to the extent i fully grasp the expensive string-to-key
functions.

It seems however, that for the most part my assumption that in a closed
network (enterprise network, not across the Internet), assuming a potential
attacker has access to the traffic flowing to KDC, pre-authentication has
minimal advantages.  Brute-forcing the encrypted-timestamp may be only
marginally quicker than the integrity tag in the ciphertext (If I read Greg
correctly, I need to research this tag) .  But the preauthentication gives
the added protection of allowing the server to choose/enforce the
encryption type used.

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?

I ask this mostly as a high-level theory question now, understanding (also
at a high level) the other concepts and solutions discussed above.  I hope
to dig deep enough to fully understand these other implications, but want
to ensure I understand the original implementations first.




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

> Greg Hudson <ghudson at mit.edu> writes:
>
> > * The AES enctypes have an intentionally expensive string-to-key
> > function, making brute-force password attacks more expensive by a
> > significant but constant factor.
>
> The one caveat I'll add to this, though, is that "intentionally expensive"
> changes over time.  Current crypto best practices would use about 3x as
> many rounds as the AES enctype specifies as the default, and would use
> per-principal salt.
>
> The Kerberos protocol permits the server to tell the client both the salt
> and the rounds, so you could dynamically adjust the rounds and use
> per-principal salt within the protocol (or, even better, randomize the
> salt on every password change).  However, I don't know if anyone
> implements the tools required to manage this properly, or if typical
> clients would cope.
>
> > * The RC4 enctype doesn't use the salt, making brute-force password
> > attacks easier since a string-to-key table can be constructed which
> > applies to all principals.
>
> Also, the hash function is relatively trivial, so even without a rainbow
> table a brute force attack is much easier.
>
> > * FAST prevents brute-force password attacks as long as the attacker
> > does not know the armor ticket key.
>
> ...but of course the attacker can still attempt to brute-force the armor
> ticket key, which is why it's important for that key to be completely
> random to force the attacker to search the full key space, or to negotiate
> it using something like PKINIT.
>
> --
> Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>