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 5draft-ietf-krb-wg-camellia-cts-01
Abstract
This document specifies two encryption types and two corresponding
checksum types for the Kerberos cryptosystem framework defined in RFC3961. 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 http://datatracker.ietf.org/drafts/current/.
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
(http://trustee.ietf.org/license-info) 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 20121. 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
profile.
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
128 bits. A block counter is used with a length of 4 bytes,
represented in big-endian order. The length of the output key in
bits (denoted as k) is also represented as a four-byte string in big-
endian order. The label input to the KDF is the usage constant
supplied to the key derivation function, and the context is unused.
n = ceiling(k / 128)
K0 = zeros
Ki = CMAC(key, K(i-1) | i | constant | 0x00 | k)
DR(key, constant) = k-truncate(K1 | K2 | ... | Kn)
KDF-FEEDBACK-CMAC(key, constant) = random-to-key(DR(key, constant))
The constants used for key derivation are the same as those used in
the simplified profile.
5. CMAC Checksum Algorithm
For integrity protection and checksums, we use the CMAC function
defined in [SP800-38B], with Camellia-128 or Camellia-256 as the
underlying block cipher.
6. Kerberos Algorithm Protocol Parameters
The following parameters apply to the encryption types camellia128-
cts-cmac, which uses a 128-bit protocol key, and camellia256-cts-
cmac, which uses a 256-bit protocol key.
Protocol key format: as defined in Section 2.
Specific key structure: three protocol format keys: { Kc, Ke, Ki }.
Required checksum mechanism: as defined in Section 7.
Hudson Expires September 9, 2012 [Page 3]

Internet-Draft Camellia Encryption for Kerberos 5 March 2012
camellia128-cts-cmac and camellia256-cts-cmac respectively.
Associated cryptosystem: Camellia-128 or Camellia-256 as appropriate
for the checksum type.
get_mic: CMAC(Kc, message).
verify_mic: get_mic and compare.
8. Security Considerations
[CRYPTOENG] chapter 4 discusses weaknesses of the CBC cipher mode.
An attacker who can observe enough messages generated with the same
key to encounter a collision in ciphertext blocks could recover the
XOR of the plaintexts of the previous blocks. Observing such a
collision becomes likely as the number of blocks observed approaches
2^64. This consideration applies to all previously standardized
Kerberos encryption types and all uses of CBC encryption with 128-bit
block ciphers in other protocols. Kerberos deployments can mitigate
this concern by rolling over keys often enough to make observing 2^64
messages unlikely.
Because the new checksum types are deterministic, an attacker could
pre-compute checksums for a known plain-text message in 2^64 randomly
chosen protocol keys. The attacker could then observe checksums
legitimately computed in different keys until a collision with one of
the pre-computed keys is observed; this becomes likely after the
number of observed checksums approaches 2^64. Observing such a
collision allows the attacker to recover the protocol key. This
consideration applies to most previously standardized Kerberos
checksum types and most uses of 128-bit checksums in other protocols.
Kerberos deployments should not migrate to the Camellia encryption
types simply because they are newer, but should use them only if
business needs require the use of Camellia, or if a serious flaw is
discovered in AES which does not apply to Camellia.
The security considerations described in [RFC3962] section 8
regarding the string-to-key algorithm also apply to the Camellia
encryption types.
At the time of writing this document, there are no known weak keys
for Camellia, and no security problem has been found on Camellia (see
[NESSIE], [CRYPTREC], and [LNCS5867]).
Hudson Expires September 9, 2012 [Page 5]