Camellia Encryption for Kerberos 5
RFC 6803

[Ballot comment]
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.

[Ballot comment]
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?

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

However, Ken made a number of comments (capturedbelow)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?

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

However, Ken made a number of comments (capturedbelow)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?

[Ballot discuss]
A small process-related Discuss that the responsible AD should be able
to resolve without action from the authors.

The IANA allocation policy for the two registries is "Standards Action
or Expert Review". Since this is an Informational RFC, can you confirm
that the expert review has been carried out? The shepherd write-up is
silent on the issue.

[Ballot comment]

  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.

IANA has reviewed draft-ietf-krb-wg-camellia-cts-01 and has the following comments:

IANA understands that, upon approval of this document, there are two IANA
actions which must be completed.

First, in the Encryption Type subregistry of the Kerberos Parameters registry
located at:

http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xml

two new Encryption Types are to be registered as follows:

etype: [ TBD ]
encryption type: camellia128-cts-cmac
Reference: [ RFC-to-be ]

etype: [ TBD ]
encryption type: camellia256-cts-cmac
Reference: [ RFC-to-be ]

Second, in the Kerberos Checksum Type Numbers subregistry of the Kerberos
Parameters registry located at:

http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xml

two new Kerberos Checksum Type Numbers are to be registered as follows:

sumtype value: [ TBD ]
Checksum type: cmac-camellia128
checksum size: 16
Reference: [ RFC-to-be ]

sumtype value: [ TBD ]
Checksum type: cmac-camellia128
checksum size: 16
Reference: [ RFC-to-be ]

IANA understands these to be the only actions required to be completed
upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <ietf-krb-wg@lists.anl.gov>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-krb-wg-camellia-cts-01.txt> (Camellia Encryption for Kerberos 5) to Informational RFC


The IESG has received a request from the Kerberos WG (krb-wg) to consider
the following document:
- 'Camellia Encryption for Kerberos 5'
  <draft-ietf-krb-wg-camellia-cts-01.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-09-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies two encryption types and two corresponding
  checksum types for the Kerberos cryptosystem framework defined in RFC
  3961.  The new types use the Camellia block cipher in CBC-mode with
  ciphertext stealing and the CMAC algorithm for integrity protection.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-krb-wg-camellia-cts/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-krb-wg-camellia-cts/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1880/

This is a request to the IESG to approve publication of "Camellia
Encryption for Kerberos 5", draft-ietf-krb-wg-camellia-cts-01.txt
as an Informational RFC.  This document is a product of the Kerberos
working group.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  We are requesting publication as an Informational RFC. 

  The authors have requested publication on the standards track; however,
  there is no consensus within the working group to do so at this time.
  There is a possibility that a consensus may emerge in the future to
  adopt one or both of the enctypes defined in this document as mandatory
  to implement for Kerberos; if that happens, we will likely request that
  the document be reclassified as a Proposed Standard.  However, no such
  consensus exists at this time.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document specifies two encryption types and two corresponding
  checksum types for the Kerberos cryptosystem framework defined in RFC
  3961.  The new types use the Camellia block cipher in CBC-mode with
  ciphertext stealing and the CMAC algorithm for integrity protection.


Working Group Summary

  This document represents the consensus of the Kerberos Working Group.


Document Quality

  At least one major Kerberos implementor plans to include support for
  the encryption and checksum types described in this document.


Personnel

  The Document Shepherd for this document is Jeffrey Hutzelman.
  The responsible Area Director is Stephen Farrell.



(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I have reviewed this document, and any issues raised have been
  resolved to my satisfaction.  I believe the document is now ready
  for IETF-wide review and publication as an RFC.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

  This document is the result of an effort which involved
  both individuals with extensive experience with the Kerberos
  cryptographic framework and those who have been involved in
  specifying support for Camellia in other IETF protocols.
  It has been extensively reviewed and discussed within the
  working group, and all technical issues raised have been
  resolved.  I have no concerns about the level of review
  this document has received.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  I don't believe any particular external review is needed for this
  document.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  I have no particular concerns with this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  All authors have confirmed that any required IPR disclosures have
  been filed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  I have no particular concerns about this document.  NTT
  and Mitsubishi Electric have filed a joint IPR statement
  #1304, related to use of Camellia in Kerberos.  Similar
  disclosures had been filed previously related to IPsec,
  TLS, S/MIME, and OpenPGP.  This issue has been discussed
  briefly within the working group, and there were no
  objections to proceeding with this work once the IPR
  disclosure was filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  There is consensus within the working group to publish this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  There have been no expressions of discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  This document has been run through the idnits tool, and was reviewed
  manually for compliance with requirements not checked by the automatic
  tool.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal review criteria apply to this document.

(13) Have all references within this document been identified as
either normative or informative?

  References have been split appropriately.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  There are no normative references to other documents that are not
  ready for advancement.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  This document contains a normative reference to RFC3713,
  and informational document which describes the Camellia
  cipher.  We don't see a problem with this, even if the
  document is published on the standards track, as this is
  consistent with current practice within the IETF relating
  to descriptions of cryptographic algorithms.

  This document also contains normative references to two
  NIST special publications.  While these are not IETF
  documents, we feel they are suitably stable to be used as
  normative references by a protocol specification.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document does not change the status of any existing RFCs.
  As noted in the abstract and introduction, this document does specify
  new encryption and checksum types to be used within the framework
  defined by RFC3961.  However, it does not make any changes to the
  framework itself, and so does not update RFC3961.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This document defines new Kerberos encryption and checksum
  types, which require assignment of numbers in IANA-managed
  namespaces.  The IANA considerations section correctly
  identifies the required registrations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  This document creates no registries requiring Expert Review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No part of this document is written in a formal language
  requiring such verification.

No consensus to publish on standards track; proceeding as Informational.
This still needs verification of the test vectors, if we can get that in a timely manner.