pre-authentication attacks

[Tom Yu]

Ben H <bhendin at 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.