[36117] in Kerberos
Re: pre-authentication attacks
daemon@ATHENA.MIT.EDU (Tom Yu)
Wed May 14 15:37:14 2014
From: Tom Yu <tlyu@mit.edu>
To: Ben H <bhendin@gmail.com>
Date: Wed, 14 May 2014 15:36:59 -0400
In-Reply-To: <CAAd7auZrdp4Ax774EgO38vzjQ0OiU0twQ=j7EgrujgLeWZZPuQ@mail.gmail.com>
(Ben H.'s message of "Wed, 14 May 2014 14:17:55 -0500")
Message-ID: <ldvbnv0jgo4.fsf@sarnath.mit.edu>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Ben H <bhendin@gmail.com> writes:
> I was reading up a bit on the history of pre-authentication after hearing a
> speaker I generally put all faith into mention something about pre-auth
> which I didn't think was accurate (namely that's its use was to help
> determine available encryption types...something which I can find no
> evidence of).
The ETYPE-INFO and ETYPE-INFO2 "preauth" types are hints from the KDC to
the client as to what enctypes to use for further preauth or for
decrypting the AS-REP. They happen to take advantage of the protocol
"hole" provided by the preauth elements in the protocol, but they do not
exemplify the intended use of preauth.
> In any event, my understanding is that pre-auth is used to prevent an
> entity from requesting a TGT without credentials and therefore not being
> able to brute force the encryption.
I think the intention was to prevent just anyone on the entire Internet
from requesting ciphertext use for a dictionary attack unless they could
first demonstrate knowledge of the key.
> However, there are tools out there which are able to also perform
> brute-force attacks against the pre-auth timestamp. In order to do this
> however, it would require the ability to listen on the wire between a
> client and a KDC. Something that may be trivial in certain circumstances
> (compromising a single application box could provide a sniff of all users
> authenticating to the KDC).
>
> That being said, assuming that all traffic to the KDC is encrypted,
> pre-authentication would seem to be superior as I can't request a ticket
> without credentials from an insecure location. If however, we assume that
> all traffic between a client and a KDC may be compromised, is
> pre-authentication superior?
I believe you're thinking primarily of encrypted-timestamp preauth. It
adds some protection from attackers who are not network-omniscient, but
not very much when an attacker can capture all traffic entering and
leaving the KDC. There are stronger preauth protections than
encrypted-timestamp, e.g., FAST (RFC 6113), that can replace or
strengthen the use of password-derived keys, and we are considering
adding more.
> We don't even need to make repeated attempts for a pre-auth required, we
> simply need to listen on the wire for when user's authenticate.
> Isn't a known entity like a UTC timestamp eaiser to brute force against
> than the encrypted TGT?
The encryption schemes used for encrypted-timestamp (and in much of
Kerberos) are authenticated encryption, so it is easy to verify that the
correct key was guessed.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
