Subject: comments on draft-raeburn-krb-rijndael-krb-05 security considerations

From: "Joel N. Weber II" <[email-masked]>
Date: Fri, 18 Jul 2003 13:09:25 -0400

[Yes, I know this is probably after some deadline by which I was
supposed to send comments.  ``Fortunately, the laws of physics prevent
crackers from carrying out an attack if they don't propose it before
the working group last call.'']

Security considerations of the rijndael spec has this text:

   An intruder spoofing the KDC reply, providing a low iteration count,
   and reading the client's reply from the network may be able to reduce
   the work needed in the brute-force attack outlined above.  Thus,
   implementations may wish to enforce lower bounds on the number of
   iterations that will be used.

However, if you're in a position to do that attack, an even more
effective attack is to simply ask the client to use an enctype that
uses a substantially faster string to key function, especially if a
lower bound on the AES iteration count is being enforced.  An attack
involving downgrading to a different enctype seems to not be discussed
at all.  (I'm also not sure that it's substantially fixable.  Yes,
limiting what enctypes the client will use in a config file would
work, but I suspect people may object to that approach.)

A much more minor issue is that this statement seems somewhat vague:

   Also, generating a 256-bit key from a pass phrase of any length may
   be deceptive, since the effective entropy in pass-phrase-derived key
   cannot be nearly that large.

In particular, does this imply that a passphrase can have 128 bits of
effective entropy?

(As far as I can tell, the amount of entropy truely present in
passphrases is not well understood, although people tend to have some
general sense of what is likely, and claims that cannot cite a
detailed analysis probably should not make it sound like they know
what they are claiming to be absolutely true.)

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 18 Jul 2003 10:40:17 -0700

> work, but I suspect people may object to that approach.)

1)  This problem is not particular to the AES I-D - Kebreros extensions
    likely will fix this problem without requiring any modification to
    the kcrypto/aes documents.

    Therefore this downgrade attack should be described in
    clarifications, not in the AES I-D.

2)  AES is the only REQUIRED enctype in clarifications and clients need
    not implement any other enctype or accept offers from KDCs to use
    any other enctype.

3)  Extensions for authentication of various plaintext in the Kerberos
    protocol are out of scope for clarifications.

    The problem is fixable, just not in clarifications.

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Fri, 18 Jul 2003 13:54:27 -0400

>     not implement any other enctype or accept offers from KDCs to use

Whether an attack works against an artificial system that only exists
in an IETF spec is not a terribly interesting question.  What is
interesting is whether real-world implementations can be attacked.
Attackers tend to be happy to violate abstraction barriers between
layers when doing so helps an attack to succeed.

I don't know of any implementations that support only AES, nor do I
know of anyone who has any plans to support only AES, nor do I expect
anyone to be able to ship something that by default doesn't accept
enctypes with faster string to key functions until long after
reasonable preauth gets deployed.

>     protocol are out of scope for clarifications.

How do you do this before the AS exchange is complete and without
leaking ciphertext that's usable for an offline dictionary attack?

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 18 Jul 2003 10:56:16 -0700

> layers when doing so helps an attack to succeed.

Noted.  The point was that there is a mitigation, the one you suggested.

> leaking ciphertext that's usable for an offline dictionary attack?

Here I have to refer you to the mail archives.  The extensions work will
likely start up soon and we will have the opportunity to fix this
problem and fix it well.

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 21 Jul 2003 12:36:44 -0400

> what they are claiming to be absolutely true.)

Given the way HMAC is used to generate the key, how much entropy from
the pass phrase can be carried forward?  Remember that part of the
HMAC spec says that if the key input is over a certain size, its hash
value is used instead.  To avoid chopping the pass phrase down to a
20-byte (160-bit) hash value, it has to be no longer than 64 bytes,
and given English word structure, grammar, and semantics, how much
entropy can you extract from that?  By the estimates you quote from
Schneier in another message, probably somewhere between 64 and 96
bits.

Longer pass phrases are better, but you still have the 160-bit cap.
So, yes, in theory, 128 bits of effective entropy may be achievable,
but 256 bits is not.

Perhaps it needs some more clarification, if the ADs send it back...

Ken

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 22 Jul 2003 12:55:10 -0400

> Perhaps it needs some more clarification, if the ADs send it back...

I think the text I quoted from the internet draft above, I took to
mean ``a key derived from any arbitrary passphrase using any arbitrary
string to key algorithm cannot possibly have more than 256 bits of
entropy'', and you intended it to refer to the specific string to key
algorithm that happens to be used with AES in Kerberos.  Maybe adding
``given the properties of the string to key function described here''
to the end of that sentence, or something, would make it slightly
clearer.  (This does seem like an exceedingly minor issue, though.)