[36120] in Kerberos
Re: pre-authentication attacks
daemon@ATHENA.MIT.EDU (Ben H)
Wed May 14 18:10:55 2014
MIME-Version: 1.0
In-Reply-To: <87y4y4yupf.fsf@windlord.stanford.edu>
Date: Wed, 14 May 2014 17:10:41 -0500
Message-ID: <CAAd7auaDRmRr6qvABXDKSLzEe0R=RG2w8dEbkg1Vzsy=vLSk7A@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
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@eyrie.org> wrote:
> Greg Hudson <ghudson@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@eyrie.org) <http://www.eyrie.org/~eagle/>
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
