Subject: Re: [Ietf-krb-wg] Assignments for Camellia-CCM enctypes

From: Ken Raeburn <[email-masked]>
Date: Thu, 16 Sep 2010 01:02:38 -0400

On Aug 19, 2010, at 12:01, Thomas Hardjono wrote:
> Ken,
> 
> Version -03 has just been uploaded.
> Please use this latest version.

I apologize; somehow I didn't see this email, but I'm looking at the draft now.

I'm not qualified to comment on Camellia itself, but in general, going forward with this seems like a good idea to me.  I'm not 100% happy with the IPR disclosure, but it's probably good enough.  I'd be happier if it nailed down the specific "IETF Kerberos standard" for which its requires *other* companies to license patents; otherwise it's kind of open-ended, if we do something really twisted in a future version of the standard that adds new patent requirements without first ensuring RAND licensing from the patent holder.

Some notes:

The tables in section 5 read like a CCM version of the "simplified profile" from RFC 3961.  This is a logical way to approach it, I think, since for example you could trivially define AES-CCM cryptosystems based on this.  However, there's little text outside the tables, and what there is says nothing about doing this; actually, it sounds like you're intending to *use* the simplified profile from 3961 (which assumes a CBC-like mode and uses HMAC), not define a similar one for using CCM.  I'd suggest separate sections defining the "simplified CCM profile" or whatever you want to call it, similar to (parts of?) section 5 of RFC 3961, and then define the Camellia-CCM cryptosystems using it, similar to section 6.3 of RFC 3961 and much of RFC 3962.  (In fact, looking back to last month's WG list traffic, with a structure like that, it *should* be almost trivial to add another section, or a separate document, defining AES-CCM cryptosystems for Kerberos, as Love suggested.  If it isn
 't that easy, it wasn't done right...)  And add some text describing this two-layered approach, like I did, only better. :-)

In Figure 2, it might be a little clearer if you make "camellia128-ccm-128" and "camellia256-ccm-128" not have line breaks.  Looking at that table, I was wondering if whitespace after "camellia" was implied by the break (since line breaks are usually done at whitespace or hyphens) and had to check the text elsewhere to find out.

The "encryption function" and "decryption function" specs in the tables both use "Flags", but I see no other occurrences of the word in the document to tell me what it means.  The "decryption function" part should also indicate the derivation of B0, for completeness.

If I understand correctly, setting q to 3 octets means we cannot encode messages of more than sixteen megabytes?  I don't think we have any existing cryptosystems that impose length limitations, and the ASN.1 encoding, for all practical purposes, does not.  (It may be unwise to use a cryptosystem and a single key for really large amounts of data, but I don't think we impose any actual prohibitions on it.  That may be a failing of ours, but I think it's mostly a separate matter.)  Nor does anything else I recall in the main Kerberos protocol impose length restrictions except for the KDC TCP exchange limiting message lengths to 2**31, nor indicate a way of handling application data (or authorization or preauth data?) larger than the cryptosystem will support in one message.  While this may or may not be an important *practical* change, I think it IS an important change, and needs to be addressed in more detail.

It's a bit of a tangent, but the recommendations for iteration counts to use with PBKDF2 in RFC 3962 are five years old, and recommended increasing the values over time.  Has anyone done timing tests with more modern hardware?  (An additional observation: Some reading I've been doing lately on the net suggests that Intel's Nehalem processors can do SHA-256 with SSE2 extensions on four messages in parallel with twice the throughput -- or more -- of your regular integer-based one-shot hash code on the same processor -- i.e., it probably takes almost twice as long but processes four times as much data.  And the vector units will probably be getting even better in the next couple of years or so.  While that's useless to the legitimate Kerberos user, a brute force attack or generation of a password-to-key dictionary would benefit from this sort of parallelism.)  Now, this is separate from the *protocol* default value, and it's fine to keep that the same as in RFC 3962, but it migh
 t be worth reiterating the "increase this over time" advice in the security considerations; even just a note along the lines of "the default in the wire protocol is 4096 but we recommend using a larger value, see RFC 3962 for discussion".  It's up to you.

IANA Considerations: This appears to be taken from RFC 3962, and is not correct for Camellia-CCM; there are no existing reserved values for Camellia.  And the "Assigned numbers" section would presumably cover the same material.  Just put in text telling IANA that we need numbers assigned before publication and show them where to fill in the numbers they give us.  They're not idiots, but they're not Kerberos experts either; make it simple and straightforward for them.

Obviously it's not complete without test vectors.  Though, sometimes they're put in an appendix instead of the main body.

Some of the references don't appear to be used anywhere.

I think that's all for now....

Ken
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 Sep 2010 16:17:08 -0400

Ken, can I get you to separate issues you see as blocking as the IANA
expert from issues you're making as individual comments.

For example it seems kind of odd for the IANA expert to block on whether
a new simplified profile is defined or on whether they just define a new
enctype without a profile.  Obviously, if a documented attempted
incorrectly to use a profile, that would be something where blocking
comments would be reasonable.

---

From: Luke Howard <[email-masked]>
Date: Fri, 17 Sep 2010 01:45:08 +0200

> HMAC), not define a similar one for using CCM.  I'd suggest separate sections defining the "simplified CCM profile" or whatever you want to

I initially proposed separate documents.

> In Figure 2, it might be a little clearer if you make "camellia128-ccm-128" and "camellia256-ccm-128" not have line breaks.  Looking at that table, I was wondering if whitespace after "camellia" wa…

Yes, this is confusing.

> The "encryption function" and "decryption function" specs in the tables both use "Flags", but I see no other occurrences of the word in the document to tell me what it means.  The "decryption funct…

Right, I wasn't clear enough to pull these in from the NIST doc.

-- Luke

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 17 Sep 2010 12:32:20 -0700

> I initially proposed separate documents.

I have no problem with separate documents per se.

I would rather not multiply the number of deployed enctypes in the wild unnecessarily, though.  I think I would recommend only Camellia-CCM be deployed unless/until an existing enctype is broken.  Then we can add one of the other combinations easily.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]