Camellia Encryption for Kerberos 5
draft-ietf-krb-wg-camellia-cts-02

I've cleared my Discuss after reading email from Ken Raeburn as designated expert.

However, Ken made a number of comments (captured below) that you may want to consider for a revised version...

> It might help to explicitly call out RFC3962 as the reference
> to use for the CTS description in section 6 where "CBC-CTS mode"
> is mentioned, as a couple different approaches have been discussed
> for handling the case where the plain text is a multiple of the
> block size.  (Do you swap the last cipher text blocks for
> consistency with the non-multiple case regardless of how full the
> last block is, or is the "stealing" only a fix for handling non-
> multiple cases and normal CBC should be used otherwise?  We went
> with always swapping, as done in RFC 2040 as well.)  My vague 
> recollection is that it wasn't always clear from the various
> descriptions of CTS that you could find on the net at the time 
> which way it should go, but I haven't looked into the matter in a
> long time.  It's probably best to discourage the reader from going
> and looking up CTS definitions from other, vague sources and 
> possibly drawing different conclusions; if we want them to do the
> same as we do for AES, just point them at the AES spec.  The only
> other link between CTS as used here and RFC 3962 is in the
> introduction where the AES encryption types are mentioned, which
> may not be a strong enough link.
>
> Just adding "[RFC3962]" after the first use of "CBC-CTS mode" there
> should be adequate.
>
> That's the only thing I'd bring up with my designated-expert hat on
> -- a minor issue of clarity and interoperability, and I could 
> possibly be convinced that it's clear enough already.
>
> But as long as I'm going over the document, a couple of very minor
> editorial points:
>
> Section 6 is called "Kerberos Algorithm Protocol Parameters" and 
> section 7 is called "Checksum Parameters", but both are for Kerberos,
> and the first is for an encryption algorithm specifically.  I'd
> suggest using something like "Encryption Algorithm Parameters"
> (dropping "protocol" too) and "Checksum Algorithm Parameters",
> perhaps with "Kerberos" on the front of both, or not...
>
> Appendix A has the "author" (singular) acknowledging people for
> reviews and feedback but no contributions of text, and in the
> Author's Address section, Greg is listed as "editor" and no other
> names are given.  Is Greg the only author, in which case he doesn't
> need to be describe as "editor"?  Should some people be acknowledged
> for text contributions too?

  The Gen-ART Review by Joel Halpern on 13-Sept-2012 makes two
  suggestions to improve the document:

  1.  The document seems to use "random2key" (in section 3) and
  "random-to-key" (in section 4) to represent the same thing,
  apparently meaning the "random-to-key" function of section 6.

  2.  Section 6 defines Ki in a different way than section 4.
  Section 4 apparently uses K0 and Ki to mean K(0) and K(i) for
  the iteration.  (And then in the next line uses K1, K2, ... Kn
  for these, without parens.) But section 6, Ki is for a specific
  value in the encrypt/decrypt functions.  The simple solution
  would seem to be to consistently use parenthesis in section 4.

From the secdir review:

As noted by Russ: is it random-to-key or random2key in s3/4?

In s4, please reference section 6 for random-to-key and RFC 3961 for k-truncate as well

In s3, what's the format for the string-to-key.

Encryption and decryption description in section 6 seems a little incomplete.  In particular the setting of newstate seems to be missing in the encryption.  In the decryption perhaps you should define how newIV is determined.