Subject: AES draft...

From: Ken Raeburn <[email-masked]>
Date: Wed, 30 Apr 2003 19:58:11 -0400

Okay, it looks like the main issue for the AES draft is the iteration
count for PBKDF2 when the KDC chooses not to send you the s2k-params
data for AES in an ETYPE-INFO2 message.

I phrased that carefully.  It's not a number we're insisting you
assume when doing optimistic PA-ENC-TIMESTAMP preauthentication
without having heard from the KDC.  (More generally, if you're doing
such optimistic preauth, we're not saying anywhere that you should use
the default s2k-params value.)  It's not a number we're recommending
for everyone who can't give a really good reason for picking another
number.  It's not a number we're saying adds difficulty X for an
attacker.

(Perhaps I need to add something to the draft to clarify just what the
"default" means?)

That said, I get the impression that everyone wants to use that number
as their normal configurations, at least initially.

I'd be tempted to say that we should just always require that the KDC
provide the number, except that the way the crypto framework is
constructed, we need to handle the no-s2k-params case in some useful
way.  (Or do we?  That's been my assumption.  Perhaps we can define
the "default" case as an error.  I don't really like that approach
though.)

There seems to be "rough consensus" (I think everyone who's expressed
an opinion other than Paul, with the silent majority being, well,
silent) that the current value of 45056 is too large to use in the
normal case for a lot of currently-used hardware, and that the added
work for an attacker will quickly be compensated for by Moore's Law,
SIMD architectures, multiple machines, etc.

However, we haven't really discussed other possible values.  I threw
out 4096 as another possibility, which would reduce all the CPU times
we've been discussing by a factor of 11.

We could also consider a small number like 16, basically indicating we
aren't trying at all to address the offline attack issue *in that
case*, and in the Security Considerations section suggest use of a
higher number by client and server if they care about the dictionary
attack and aren't using a good preauth scheme.

As I noted above, whatever number we indicate in the draft, any
implementation would be free to default to other numbers when storing
users' keys, or computing optimistic preauth data.  It also sounds
likely that MIT and Microsoft (assuming Paul's views are shared by the
whole Kerberos team) may go with different "normal" iteration counts.

Having to use a "normal" iteration count that is not the "default" for
the no-s2k-params case would probably delay MIT's next release a bit,
and I've heard that the Heimdal KDC isn't going to support specified
iteration counts soon either.  I don't know how tough such a
divergence would be for Microsoft.

Naturally, I'm biased by that, so keep that in mind while I make a
concrete proposal of changing the default to 4096 and letting
Microsoft consider using another, higher value for their clients and
KDCs.

Comments?

The draft does permit implementations to put bounds on the iteration
counts permissible, but there is no particular range described as
"must support".  In some ways, I think that's a much more interesting
issue than the no-s2k-params case.  An attacker on the net could spoof
KDC replies saying PA-ENC-TIMESTAMP is needed and some tiny number of
iterations is needed.  The user fails to get logged in, probably, but
the attacker has simplified his offline attack.

I don't think we should be proposing any requirements on this right
now, but it would probably be a good idea for interoperability testing
for implementations to be able to use the no-s2k-params "default"
iteration count, even if it's not the default configuration for the
software.

The other comment I've gotten on the draft is that putting a label
like "PBKDF2-HMAC-SHA1" in with the test vectors might make searching
the web a little easier for someone not looking for Kerberos, but
looking for PKBDF2 test vectors using a SHA1 HMAC.  (Some search
engines can be asked for terms occurring near each other in the
searched documents, not just spread out.)

Ken