Encryption and Checksum Specifications for Kerberos 5
RFC 3961

Note: This ballot was opened for revision 07 and is now closed.

(Russ Housley; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Alex Zinin; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Allison Mankin; former steering group member) (was Discuss) No Objection

No Objection (2004-01-07)
No email
send info
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.

(Bert Wijnen; former steering group member) No Objection

No Objection (2004-01-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Missing IPR statement/section

(Bill Fenner; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Harald Alvestrand; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Jon Peterson; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Margaret Cullen; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ned Freed; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Steven Bellovin; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ted Hardie; former steering group member) No Objection

No Objection (2004-01-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Thomas Narten; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info