Subject: [Ietf-krb-wg] AD review of draft-ietf-krb-wg-camellia-cts

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Sep 2012 14:00:44 +0100

Hi all,

My AD review of this is below. Thanks for a nice
and nicely-short document!

The only thing that I'd like before I start IETF LC
is an answer on the IPR question at the top (or a
discussion about that if need be). All the other
stuff can be considered along with other IETF LC
comments.

Cheers,
S.

- The IPR declaration (#1304) is noted in the write-up
but not specifically associated with this draft, so
it wouldn't show up so easily for reviewers but I can
call that out specifically in the IETF LC message, but
there is another issue: that declaration refers for
example to things that are required for compliance
with a standard. However, the wg are proposing this
as informational, so it may be less clear to IETF
LC reviewers if the terms in the declaration apply
or not. Did the WG consider that difference when
deciding to go for informational?

(Note: In some cases, when we've told folks who made
declarations about this ambiguity they've been
happy to modify the language. I don't know if that
applies here or not and of course we cannot force
anyone to use specific language in their declarations,
but letting IPR holders know about it can help.)

- I think section 5 needs to say that the output of
CMAC is 128 bits regardless of key size. At present
that's only explicitly stated in the IANA considerations
and is implicit in the security considerations and
the samples. You could add something like "For this
specification, the CMAC Tlen is set to 128 bits,
that is, checksums are 128 bits long, regardless of
the key length."

- section 6 could do with a reference to the section of
whatever RFC says these are the parameters you need. I guess
that's [1], if so, the ordering is a little different here -
keeping the same order would have helped me a little to check
that nothing's missing.

   [1] http://tools.ietf.org/html/rfc3961#section-3

- section 6: 3961 says some things take UTF-8 as input
but you never mentioned UTF-8 here at all, do you need
to?

- Side note: while I'm not keen myself on ciphersuite
proliferation, when a wg wants it, as in this case, its not
my job to get in the way, especially when the wg have
specifically considered that aspect as you have here
in deciding that you want this as informational and
not standards-track. (I'm just saying this in case
someone says to me later: "but you said Camellia was
ok.";-)

nits:

- section 2: "The Camellia key space is dense" that's either
a non-trivial statement (in which case a reference would be
good) or else is trivial, in which case maybe just get rid of
it as it might confuse. (Even nittier nit: s/random octet
string/octet strings/)

- section 3 has an implicit pointer to section 4, where
KDF-FEEDBACK-CMAC is defined. Maybe add a pointer or swap the
order of sections 3 & 4.

- please say somewhere that "|" means catenation. (Personally
I prefer "||" but whatever.)

- section 6: are the en/de-cryption functions sufficiently
well specified that a coder can work from just this? I'm
guessing they are ok, but be nice to know if that's
happened.

- In cross-checking section 6 with 3961 section 3 I
wasn't sure that the "string-to-key parameter format"
that needs to be specified is clearly specified.
(Note: I just did a mechanical check that the
things called for by 3961 are present, I didn't
really dive into it fully.)

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

---

From: Greg Hudson <[email-masked]>
Date: Mon, 10 Sep 2012 12:24:14 -0400

Thanks for the comments, Stephen.

> deciding to go for informational?

I don't believe we specifically considered this issue, no.  In theory,
the same ambiguity could apply to a "proposed standard" or "draft
standard," perhaps with lower probability.  Is there anything you'd like
us to do about this before last call beside answer the specific question?

> CMAC is 128 bits regardless of key size.

Agreed--though I'm not sure how the key size enters into the picture.
The output length of CMAC is bounded by the cipher block size, and has
no relation to the key length.  I suggest adding "The output length
(Tlen) is 128 bits for both key sizes."

>    [1] http://tools.ietf.org/html/rfc3961#section-3

That's the correct reference.  I'd suggest changing the introductory
paragraph to begin with "The following parameters, required by RFC 3961
section 3, apply to...".  Similarly for section 7: "The following
parameters, required by RFC 3961 section 4, apply to...".

As for the order, this can be corrected by moving "Default string-to-key
parameters" after "Key-derivation function".

> but you never mentioned UTF-8 here at all, do you need

I don't think so.  Neither RFC 3962 nor the RFC 3961 simplified profile
mention UTF-8.

> it as it might confuse. (Even nittier nit: s/random octet

I'm echoing a statement from RFC 3962 section 3.  This statement means
that all bit values in the 128-bit key space are valid keys.  This is
true of all modern block ciphers, but is not true of DES or triple-DES
(which have historically been used by Kerberos).

> KDF-FEEDBACK-CMAC is defined. Maybe add a pointer or swap the

Swapping the order of sections 3 and 4 makes sense to me.

> I prefer "||" but whatever.)

I have no personal preference for | versus ||, but I think it's
important to remain consistent with RFC 3961.

I suggest adding, to the end of the first paragraph of section 3 (just
before the equations):

    In the following summary, | indicates concatenation.

> guessing they are ok, but be nice to know if that's

These are specified in the same level of detail as the specifications in
RFC 3961 section 5.3, which have proved to be sufficiently
well-specified for interoperability.

> really dive into it fully.)

I think it makes sense to add, just after "Key-derivation functions" and
before "Default string-to-key parameters":

    String-to-key parameter format: four octets indicating a 32-bit
    iteration count in big-endian order.  Implementations may limit
    the count as specified in RFC 3962 section 4.

I have prepared a revision of the draft with all of the edits I
mentioned, but will not submit it at this time, since we've passed WGLC
and I'm not certain of the editing restrictions at this point.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Sep 2012 17:42:55 +0100

Hi Greg,

> us to do about this before last call beside answer the specific question?

Nope, your answer above does it for me.

If someone wants to bring this ambiguity to the attention
of the IPR holding folks and if they would like to update
their text then that'd be lovely but our process doesn't
call for them to have to do that.

Otherwise, it turns out the easiest thing is for me (or
whoever wants to if someone else is in the mood) to post
a 3rd party IPR declaration just saying that the current
declaration (#1304) looks like its relevant to this draft
and then start IETF LC and the right pointers will exist.
(Yes, that's an irritating and clunky process, but I
asked the IESG and its what two other ADs suggested,
better ideas welcome;-)

All your answers below also look fine, so I'll do the
above and start IETF LC tomorrow unless the WG chairs
tell me they'd rather some other plan e.g. they might
prefer you issue the update now or not, or they might
want to wait a bit to see if another IPR declaration
is going to be done, but let's leave that call to the
chairs.

Cheers,
S

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 10 Sep 2012 15:04:32 -0400

> is going to be done, but let's leave that call to the

I don't expect another IPR declaration.  At the time this work was
started, declarations had been filed in relation to a number of other
protocols, but not for Kerberos.  The working group requested a
declaration relating to Kerberos, and one was filed.  This draft did not
yet exist in its present form and with its present filename, so it is
not surprising that declaration doesn't refer to it.  I'm certainly not
going to back to the authors now and ask that they do extra work to make
sure the draft filename is listed, when our process does not require
that.

Aside from that, I have no opinion on whether the update should be
submitted before or after going to IETF LC; I was going to defer to you
on that point.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Sep 2012 15:13:00 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

Greg, during the WG discussions, I made a statement with my OS
distributor hat on that I would not have trouble shipping an
implementation of this draft.  based on Stephen's catch that this may
not apply to an informational RFC, I'd like to withdraw that statement.
Instead, I have no comment on whether I could distribute software
implementing this draft at this time.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg