Advanced Encryption Standard (AES) Encryption for Kerberos 5
draft-raeburn-krb-rijndael-krb-07

[Ballot comment]
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.

[Ballot comment]
Was this a krb-wg document?  Since its title is not typical, it would be good
for the writeup to give assurance on the degree of consensus.

About the above - it's not possible to delete a comment (!) even after one reads
the writeup better!!!

[Ballot comment]
Was this a krb-wg document?  Since its title is not typical, it would be good
for the writeup to give assurance on the degree of consensus.

[Ballot comment]
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.

[Ballot comment]
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 KRB 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 bad 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.

[Ballot discuss]
I'm concerned about the way the document specifies the errata in 2040; the
text does not seem to match http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=2040&
The last erratum does not appear to exist in the RFC Editor's errataSearch.

The right, but no doubt painful answer, is probably to update 2040 so that the
errata are not needed.  Short of that, it seems like the right thing to do is to
make clear which set of errata are normative for this document and whether
they would be normative for any other use of 2040.

[Ballot discuss]
Section 2 mentions RFC 2119 as the source for key word definitions, but 2119 is not cited as a normative reference.  It should be if the intention is to use those key words.  However, I can't find any of the upper-case key words used in the document!  There are several uses of some of the words in lower case, though, so I'm not sure of how to interpret the conformance requirements.

[Ballot comment]
The "Comments should be sent to the author, or to the IETF Kerberos working group (ietf-krb-wg@anl.gov)." 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.

I requested confirmation that the test vectors in the document are correct on 08-Oct-2003.  I am still waiting.  Two reminders have been sent.  The most recent was sent today.