Encryption and Checksum Specifications for Kerberos 5
draft-ietf-krb-wg-crypto-07

The IMPLEMENTATION NOTE under the definition of initial cipher 
state talks about "This new specification"  preventing applications from
setting the DES CBC initial cipher state themselves.  It's hard to tell if the
author means the present document, which doesn't specify processing
to that level, or kerberos-clarifications, which also doesn't seem to
do so.  If the author wants to use the present spec to direct new rules
for handling algorithms, that seems fine, but the language needs to
be more directive.

This spec doesn't have draft-ietf-krb-wg-kerberos-clarifications in its
references, unless I've missed something.

Missing IPR statement/section

Section 6.2 says:

   The DES specifications [DESI81] identify four 'weak' and twelve
   'semi-weak' keys; those keys shall not be used for encrypting
   messages for use in Kerberos. 

Is this a SHALL NOT equivalent statement?

That same section says:

   One common extension is to support the "AFS string-to-key" algorithm,
   which is not defined here, if the type value above is one (1).

Is there an available reference for the "AFS string-to-key" algorithm?

In general, I find the string-to-key text a little light.  In the terminology
section it is given as:

         string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)
         This function generates a key from two UTF-8 strings and an
         opaque octet string.  One of the strings is normally the
         principal's pass phrase, but is in general merely a secret
         string.  

While this seems to be fine in principle, I wonder if there might not be
an early step "somestring-to-utf8string" for cases where the overall
system was not provided the initial string in UTF-8.  I am not suggesting
that this document should cover that ground, but it does seem like
explicit recognition of that step might reinforce the idea that string-to-key
starts from a UTF-8 string *not* from a locale-specific encoding.
See also 6.3.1, which might be taken to imply that all passwords are UTF-8.

In Section A.4, The draft has this example:

  salt:   "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
    passwd: eszett
    key:    16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0


Assuming that the salt given actually intends to represent UTF-8 characters
outside the ASCII range (rather than the literal text "c-acute" and so forth),
I would suggest using the U+XXXX method of referencing the input characters.
That would result in a line like:
salt:   "ATHENA.MIT.EDUJuri"+"U+0161" + "i" + "U+0107"

rendering the whole thing U+XXXX format would also be possible, if a bit tedious.