Subject: RE: AES and SHA-1 timing

From: "Paul Leach" <[email-masked]>
Date: Wed, 16 Apr 2003 11:45:41 -0700

>
> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Wednesday, April 16, 2003 11:03 AM
> To: Paul Leach
> Cc: Marcus Watts; [email-masked]
>
> It's a reference to the need for new pre-auth types which
> have better mechanisms for protecting weak passwords than
> PA-ENC-TIMESTAMP.

Got it; thanks.

I believe that anything that does better than the encrypted timestamp will
have to be public key crypto based -- and they won't run all that swiftly
on the ancient hardware and PDAs either. Further, all the ones I know
about either require public key infrastructure, are subject to MITM
attacks, or are covered by intellectual property restrictions. Are there
others that I don't know about, that can avoid these issues?

Otherwise, I think that the only thing that could be deployable "this
summer" (Ken's target timeframe) is an improved PA-ENC-TIMESTAMP based
approach that makes cracking harder by making it slower (and,
unfortunatly, also makes ordinary logon slower).

Futher, even if these alternative approaches were available, that doesn't
mean we should leave the PA-ENC-TIMESTAMP approach weak. If the other
approaches were available, its computational cost would be irrelevant: it
would presumably just fall out of use.

Paul

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Apr 2003 12:55:11 -0700

> others that I don't know about, that can avoid these issues?

Several possiblities have been discussed here and elsewhere.  One
involves using a second ticket (say, one where the user principal is a
host-based principal name belonging to the client) to secure the
encrypted timestamp.  Another involves a realm public key used to
encrypt the encrypted timestamp, and which requires distribution of
realm public keys.  PKINIT is also an option.  Doug Engert suggested
that we consider building a new pre-auth on fortified key negotiation
(FKN - I'm looking into this).  Sam Hartman, IIRC, wants to do a
pre-auth which is only subject to a MITM dictionary attack which the
client can detect.

I think a pre-auth based on FKN could be designed such that possible
MITM and other active attackers can be detected heuristically with the
mitigation being acceleration of password aging schedules (by the
client, when only the client can detect the attacker, or by the KDC when
the KDC can detect the attacker).

> unfortunatly, also makes ordinary logon slower).

Well, yes.  Not much else could be done by "this summer."

> would presumably just fall out of use.

Granted.  I would not ask that we drop PA-ENC-TIMESTAMP or do nothing in
the AES string2key to make AES PA-ENC-TIMESTAMP stronger.  Quite the
contrary.  However, I think it's clear that in the medium and longer
terms we need a different pre-auth type, one that better protects weak
passwords.

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 16 Apr 2003 16:06:00 -0400

> others that I don't know about, that can avoid these issues?

There is at least one approach using a non-password-derived Kerberos
key stored on the client system, which I *think* is free of IP
problems.  Use a session key or long-term key for the device to
provide additional protection of the AS exchange.  (Either via double
encryption, or creating an operation for combining keys that similarly
provides the combined protection of the two keys.)  Even if the
device's key is compromised, it reduces only to the current offline
attack.

> unfortunatly, also makes ordinary logon slower).

Even without the linear multiplier, I don't think it's any worse than
the string-to-key schemes for DES and 3DES that we're using now.  The
AES encryption step may be faster than the others (I haven't checked
with MIT's implementation), but doing several iterations in PBKDF2
could probably fix that, if we cared.  And by several, I don't mean
hundreds or thousands.  So I don't think this would be an issue for
MIT.

> would presumably just fall out of use.

I've assumed that at least some of the other approaches will probably
start with "generate the long term key, and then use it like this...."
So the expense for generating the long-term key would still be an
issue, unless we're going to throw away all the string-to-key stuff
and roll our own for each preauth scheme.  When we start using strong
preauth schemes, yes, PA-ENC-TIMESTAMP should just go away, unless the
KDC says it's required, and even then, the client can be configured to
refuse to do it (in case the KDC is spoofed).

One thing we've completely failed to specify is what information a
preauthentication scheme should consider available to it, and what
changes it can make in the KDC exchanges besides adding preauth data
and changing the key.  Without some guidance there, preauth schemes
will probably do lots of random things, and it'll be nearly impossible
to implement a plug-in architecture for preauth systems because the
core Kerberos protocol code will have to know about all the little
tweaks to the Kerberos messages.

Ken