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 <[email protected]> wrote: > Greg Hudson <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
