[36118] in Kerberos

home help back first fref pref prev next nref lref last post

Re: pre-authentication attacks

daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed May 14 15:37:36 2014

Message-ID: <5373C5F2.1090001@mit.edu>
Date: Wed, 14 May 2014 15:37:22 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: Ben H <bhendin@gmail.com>, kerberos@mit.edu
In-Reply-To: <CAAd7auZrdp4Ax774EgO38vzjQ0OiU0twQ=j7EgrujgLeWZZPuQ@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

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.
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post