pre-authentication attacks

[Greg Hudson]

On 05/18/2014 12:57 PM, Simo Sorce wrote:
> On Wed, 2014-05-14 at 13:24 -0700, Russ Allbery wrote:
>> 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 FreeIPA project uses random salts since when we started, it seem all
> clients we know of cope just fine.

We have explored using random salts by default in MIT krb5 in the past.
http://k5wiki.kerberos.org/wiki/Projects/Random_Salt_Generation#Complications
describes the reasons why we didn't go ahead with it at that time.  They
aren't insurmountable, but they require additional resource investment.
 FreeIPA presumably works around all of these issues except for the
ktutil ktadd issue, which it can reasonably ignore.

In 1.10 (issue #6964) we added support for the "special" salt type as an
input salt type for kadmin cpw, supported_enctypes, etc..  (The
"special" type already existed but didn't work as an input.)  Currently
it generates a 16-byte ASCII salt containing 64 bits of entropy; there
isn't currently any way to adjust that.

> We do not change rounds, so I can't speak about changing that.

As far as I know, no KDC implementation has any support for changing the
number of PBKDF2 rounds, although clients generally have code to handle
it.  Note that in the absence of FAST or KKDCP or similar, an active
attacker could defeat this measure by altering the string-to-key
parameters in the preauth-required error as seen by the client.  (We do
not currently accept s2k parameters which reduce the number of rounds
from the default.)

An active attacker could also induce the client to use an enctype with a
faster or weaker string-to-key function.  Clients can defend against
this by removing all enctypes older than AES from default_tkt_enctypes,
e.g.:

    [libdefaults]
        default_tkt_enctypes = DEFAULT -des -des3 -rc4

but of course it would create interop issues if we simply changed our
hardcoded defaults.