pre-authentication attacks

[Greg Hudson]

On 05/14/2014 03:17 PM, Ben H wrote:
> 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?
> 
> 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?

A Kerberos EncryptedData message contains an integrity tag in the RFC
3961 cipherext, so one can brute-force an EncKDCRepPart just about as
easily as a PA-ENC-TIMESTAMP.  The encrypted timestamp is a little
shorter, but that shouldn't change the constant factor much since the
attacker also has to do string-to-key for each candidate password.

Here's a summary of Kerberos offline password attack properties:

* Without preauth_required (or without disallow_svr), an attacker can
simply request a ciphertext encrypted in the long-term key and conduct a
brute-force attack against the EncKDCRepPart.

* With preauth_required and disallow_svr, an attacker must be able to
observe traffic from a legitimate client to be able to conduct a
brute-force attack.  The attacker also doesn't get to choose the enctype
of the long-term key used, unless the attacker can also modify the
etype-info2 padata in the preauth_required reply as seen by the client.

* 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 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.

* FAST prevents brute-force password attacks as long as the attacker
does not know the armor ticket key.  It is not as easy to deploy FAST as
we would like.

* PKINIT prevents brute-force password attacks by not using a
password-derived long-term key.

* Microsoft has a Kerberos-over-HTTPS standard called MS-KKDCP which we
will be implementing in MIT krb5 1.13.  This will allow Kerberos traffic
to be encrypted, with the KDC authenticated by a standard web server TLS
certificate, at the expense of a lower load ceiling on the proxy server.