Advanced Encryption Standard (AES) Encryption for Kerberos 5
Note: This ballot was opened for revision 07 and is now closed.
(Russ Housley) Yes
(Steven Bellovin) No Objection
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) (was Discuss) No Objection
In Section 4, the draft says: For environments where slower hardware is the norm, implementations may wish to limit the number of iterations to prevent a spoofed response from consuming lots of client-side CPU time; It would be valuable to tie back into Kerberos spec here, as "spoofed response" appears here without reference to what part of the Kerberos exchange is at issue. In the Security Considerations, the draft says: A better way to deal with the brute-force attack is through preauthentication mechanisms that provide better protection of the user's long-term key. Use of such mechanisms is out of scope for this document. If a site does wish to use this means of protection against a brute- force attack, the iteration count should be chosen based on the facilities expected to be available to an attacker, and the amount of work the attacker should be required to perform to acquire the key or password. Would it not need to be "chosen based on the facilities available to both attacker and legitimate user"? If the attackers are presumed to have much greater facilities than the legitimate end user, relatively frequent password and salt changes may be needed to compensate, but it is still possible to take the legitimate user's facilities into account.
(Scott Hollenbeck) (was Discuss) No Objection
The "Comments should be sent to the author, or to the IETF Kerberos working group (email@example.com)." text at the end of the abstract should be removed. The second-to-last paragraph in section 4 uses "NOT" in a way that makes it look like a 2119 key word. It isn't, though, so it would be better used in lower case text.
(David Kessens) No Objection
(Allison Mankin) No Objection
Comment (2004-07-08 for -** No value found for 'p.get_dochistory.rev' **)
I see this document is blocking its ref KRYPTO in the rfc-editor queue - hopefully the rfc-ed will resolve the ref quickly, even though the ref has an xx in place of 06. There's a nice dependendency that will resolve out of this doc.