Camellia Encryption for Kerberos 5

The information below is for an old version of the document
Document Type Active Internet-Draft (krb-wg WG)
Author Greg Hudson 
Last updated 2012-09-27 (latest revision 2012-03-08)
Stream IETF
Intended RFC status Informational
Formats pdf htmlized (tools) htmlized bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd Jeffrey Hutzelman
Shepherd write-up Show (last changed 2012-03-09)
IESG IESG state Approved-announcement to be sent
Consensus Boilerplate Unknown
Telechat date
Responsible AD Stephen Farrell
IESG note The Document Shepherd for this document is Jeffrey Hutzelman (
Send notices to,
Kerberos Working Group                                    G. Hudson, Ed.
Internet-Draft                                   MIT Kerberos Consortium
Intended status: Informational                             March 8, 2012
Expires: September 9, 2012

                   Camellia Encryption for Kerberos 5


   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 9, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Hudson                  Expires September 9, 2012               [Page 1]
Internet-Draft     Camellia Encryption for Kerberos 5         March 2012

1.  Introduction

   The Camellia block cipher, described in [RFC3713], has a 128-bit
   block size and a 128-bit, 192-bit, or 256-bit key size, similar to
   AES.  This document specifies Kerberos encryption and checksum types
   for Camellia using 128-bit or 256-bit keys.  The new types conform to
   the framework specified in [RFC3961], but do not use the simplified

   Like the simplified profile, the new types use key derivation to
   produce keys for encryption, integrity protection, and checksum
   operations.  Instead of the [RFC3961] section 5.1 key derivation
   function, the new types use a key derivation function from the family
   specified in [SP800-108].

   The new types use the CMAC algorithm for integrity protection and
   checksum operations.  As a consequence, they do not rely on a hash
   algorithm except when generating keys from strings.

   Like the AES encryption types [RFC3962], the new encryption types use
   CBC mode with ciphertext stealing to avoid the need for padding.
   They also use the same PBKDF2 algorithm for key generation from
   strings, with a modification to the salt string to ensure that
   different keys are generated for Camellia and AES encryption types.

2.  Protocol Key Representation

   The Camellia key space is dense, so we use random octet strings
   directly as keys.  The first bit of the Camellia bit string is the
   high bit of the first byte of the random octet string.

3.  Key Generation from Strings

   We use a variation on the key generation algorithm specified in
   [RFC3962] section 4.

   First, to ensure that different long-term keys are used with Camellia
   and AES, we prepend the enctype name to the salt string, separated by
   a null byte.  The enctype name is "camellia128-cts-cmac" or
   "camellia256-cts-cmac" (without the quotes).

   Second, the final key derivation step uses the algorithm described in
   Section 4 instead of the key derivation algorithm used by the
   simplified profile.

   Third, if no string-to-key parameters are specified, the default

Hudson                  Expires September 9, 2012               [Page 2]
Internet-Draft     Camellia Encryption for Kerberos 5         March 2012

   number of iterations is raised to 32768.

   saltp = enctype-name | 0x00 | salt
   tkey = random2key(PBKDF2-HMAC-SHA1(passphrase, saltp,
                                      iter_count, keylength))
   key = KDF-FEEDBACK-CMAC(tkey, "kerberos")

4.  Key Derivation

   We use a key derivation function from the family specified in
   [SP800-108] section 5.2, "KDF in Feedback Mode".  The PRF parameter
   of the key derivation function is CMAC with Camellia-128 or Camellia-
   256 as the underlying block cipher; this PRF has an output size of
Show full document text