Encryption and Checksum Specifications for Kerberos 5
Note: This ballot was opened for revision 07 and is now closed.
(Russ Housley) Yes
(Harald Alvestrand) No Objection
(Steven Bellovin) No Objection
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ned Freed) No Objection
(Ted Hardie) No Objection
Comment (2004-01-06 for -)
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.
(Allison Mankin) (was Discuss) No Objection
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.
(Thomas Narten) (was Discuss) No Objection
(Jon Peterson) No Objection
(Bert Wijnen) No Objection
Comment (2004-01-08 for -)
Missing IPR statement/section