Subject: [Ietf-krb-wg] Camellia-CTS for Kerberos

From: Ken Raeburn <[email-masked]>
Date: Sun, 9 May 2010 19:53:46 -0400

I apologize for not pulling together these comments earlier.  Overall, I think the specs (including the draft of the -02 version sent to me for comments) look pretty good, so far.  I have just some technical comments for your consideration, and a few minor editorial ones:

First, some (perhaps minor) alteration of the string-to-key function might be a good idea, so that AES and Camellia don't wind up using exactly the same key (as pointed out by Love).  One possible benefit to having both Camellia and AES implemented is that if one should be broken, you have another already implemented that you could fall back on; but if the break exposes the long-term keys, and AES and Camellia use the same long-term keys, switching doesn't help you.  I haven't though much about how it could be altered, but there are some obvious possibilities: Alter one of the PBKDF2 inputs, e.g., use "camellia128-cts-hmac-sha1-96:"+Kerberos-salt-string where PBKDF2 wants its "salt" parameter; this affects any pre-computed-dictionary attacks too since the attacker can't cache PBKDF2 output values to use for both AES and Camellia attacks.  Or, change the DK(tkey,"kerberos") part of string-to-key to use a different string, or add an additional DK call before the one using "kerb
 eros".  I kind of wish I'd had the foresight to do one of these for AES, but it really didn't occur to me until now.

I think you should consider raising the default iteration count for the string-to-key function.  As noted in the Security Considerations of RFC 3962, the default value given was intended to require a certain level of difficulty per attempt in a brute-force attack, based on commonly available hardware in 2004(?).  Now, several years later, CPUs are faster, and have multiple cores and more SIMD instructions; one compromised desktop system in a bot army can do more attempts per second now, and the bot armies are probably larger.  So perhaps it's time to raise the default iteration count to compensate.  Of course, this is just the default count to use when the string-to-key parameters aren't specified by the KDC.  An implementation can have a default iteration count that is different from this; that just means that it will normally have to send the string-to-key parameter block.  But I suspect most implementations will by default use the cryptosystem's default value.  (As an asid
 e: I wonder if an analysis has been done of CPU power available in major bot networks and how quickly they might be able to perform dictionary-based attacks against Kerberos AES/Camellia keys generated with various iteration counts.)  If you don't raise it, then I suggest a brief note in the "Security Considerations" section explaining why you kept the old value, and maybe mentioning that implementations might want use larger values (and thus have to send string-to-key parameters) by default; if you make it a strong recommendation, that belongs in the main text.

Moving to the SHA-2 functions, as Luke suggested, seems like a good idea, unless there's some pressing reason not to.  If used with PBKDF2, it would also have the effect of changing the string-to-key output to differ from AES, but you might still consider tweaking the algorithm to incorporate some per-cryptosystem variation.

None of these seem like show-stoppers; the document could still be published without changing these.

I haven't checked the RFC Editor guidelines lately, but I don't think my name belongs on the first page.  If I recall correctly, that's for the authors/editors of the *current* document, who are actually doing the work on behalf of the IETF working group.  Some bits of this document are based on text from RFC 3962, which I wrote, but I think a mention of this in an "Acknowledgements" section is adequate.  If the current authors didn't think up and write most of the text, perhaps describing the people actually editing the document as "editors" and spelling out all the details of contributions in "Acknowledgements" is the way to go, as I did in RFC 3961.

There are a few instances of spelling and grammatical errors; that's okay for now.  The RFC Editor can help polish up the final version, but as they may not understand some of the technical details well, the version to be submitted should be fixed up as much as possible, so the RFC Editor doesn't accidentally change something important.

The paragraph in section 3 should refer to Camellia, not AES.  Having a dense key space is a property of both cryptosystems, but the fact that Camellia has the property is what's of interest here.

Ken
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg