
Camellia Encryption for Kerberos 5
drafthudsoncamelliacts00
Abstract
This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem suite. The new types use the Camellia block cipher in CBCmode with ciphertext stealing and the CMAC algorithm for integrity protection.
Status of this Memo
This InternetDraft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
InternetDrafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as InternetDrafts. The list of current InternetDrafts is at http://datatracker.ietf.org/drafts/current/.
InternetDrafts 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 InternetDrafts as reference material or to cite them other than as “work in progress.”
This InternetDraft will expire on May 23, 2011.
Copyright Notice
Copyright (c) 2010 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/licenseinfo) 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.
1. Introduction
The Camellia block cipher, described in [RFC3713] (Matsui, M., Nakajima, J., and S. Moriai, “A Description of the Camellia Encryption Algorithm,” April 2004.), has a 128bit block size and a 128bit, 192bit, or 256bit key size, similar to AES. This document specifies Kerberos encryption and checksum types for Camellia using 128bit or 256bit keys. The new types conform to the framework specified in [RFC3961] (Raeburn, K., “Encryption and Checksum Specifications for Kerberos 5,” February 2005.), 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] (Raeburn, K., “Encryption and Checksum Specifications for Kerberos 5,” February 2005.) section 5.1 key derivation function, the new types use a key derivation function from the family specified in [SP800‑108] (Chen, L., “Recommendation for Key Derivation Using Pseudorandom Functions,” October 2009.).
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] (Raeburn, K., “Advanced Encryption Standard (AES) Encryption for Kerberos 5,” February 2005.), 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
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] (Raeburn, K., “Advanced Encryption Standard (AES) Encryption for Kerberos 5,” February 2005.) section 4.
First, to ensure that different longterm 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 "camellia128ctscmac" or "camellia256ctscmac" (without the quotes).
Second, the final key derivation step uses the algorithm described in Section 4 (Key Derivation) instead of the key derivation algorithm used by the simplified profile.
Third, if no stringtokey parameters are specified, the default number of iterations is raised to 32768.
saltp = enctypename  0x00  salt tkey = random2key(PBKDF2HMACSHA1(passphrase, saltp, iter_count, keylength)) key = KDFFEEDBACKCMAC(tkey, "kerberos")
4. Key Derivation
We use a key derivation function from the family specified in [SP800‑108] (Chen, L., “Recommendation for Key Derivation Using Pseudorandom Functions,” October 2009.) section 5.2, "KDF in Feedback Mode". The PRF parameter of the key derivation function is CMAC with Camellia128 or Camellia256 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 bigendian order. The length of the output key in bits (denoted as k) is also represented as a fourbyte string in bigendian 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(i1)  i  constant  0x00  k) DR(key, constant) = ktruncate(K1  K2  ...  Kn) KDFFEEDBACKCMAC(key, constant) = randomtokey(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] (Dworkin, M., “Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication,” October 2009.), with Camellia128 or Camellia256 as the underlying block cipher.
6. Kerberos Algorithm Protocol Parameters
The following parameters apply to the encryption types camellia128ctscmac, which uses a 128bit protocol key, and camellia256ctscmac, which uses a 256bit protocol key.
Protocol key format: as defined in Section 2 (Protocol Key Representation).
Specific key structure: three protocol format keys: { Kc, Ke, Ki }.
Required checksum mechanism: as defined in Section 7 (Checksum Parameters).
Key generation seed length: the key size (128 or 256 bits).
Stringtokey function: as defined in Section 3 (Key Generation from Strings).
Default stringtokey parameters: 00 00 80 00.
Randomtokey function: identity function.
Keyderivation function: as indicated below, with usage represented as four octets in bigendian order.
Kc = KDFFEEDBACKCMAC(basekey, usage  0x99) Ke = KDFFEEDBACKCMAC(basekey, usage  0xAA) Ki = KDFFEEDBACKCMAC(basekey, usage  0x55)
Initial cipher state: all bits zero.
Encryption function: as follows, where E() is Camellia encryption in CBCCTS mode, with the nexttolast block used as the CBCstyle ivec, or the last block if there is only one.
conf = Random string of 128 bits (C, newstate.ivec) = E(Ke, conf  plaintext, oldstate.ivec) M = CMAC(Ki, conf  plaintext) ciphertext = C  M
Decryption function: as follows, where D() is Camellia decryption in CBCCTS mode, with the ivec treated as in E().
(C, M) = ciphertext (P, newIV) = D(Ke, C, oldstate.ivec) if (M != CMAC(Ki, P)) report error newstate.ivec = newIV
Pseudorandom function: as follows.
Kp = KDFFEEDBACKCMAC(protocolkey, "prf") PRF = CMAC(Kp, octetstring)
7. Checksum Parameters
The following parameters apply to the checksum types cmaccamellia128 and cmaccamellia256, which are the associated checksum for camellia128ctscmac and camellia256ctscmac respectively.
Associated cryptosystem: Camellia128 or Camellia256 as appropriate for the checksum type.
get_mic: CMAC(Kc, message).
verify_mic: get_mic and compare.
8. Assigned Numbers
Encryption types
Type name  etype value  key size 

camellia128ctscmac  TBD  128 
camellia256ctscmac  TBD  256 
Checksum types
Type name  sumtype value  length 

cmaccamellia128  TBD  128 
cmaccamellia256  TBD  128 
9. Security Considerations
[CRYPTOENG] (Schneier, B., “Cryptography Engineering,” March 2010.) 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 128bit 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 precompute checksums for a known plaintext 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 precomputed 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 128bit checksums in other protocols.
The Camellia cipher has not received as much scrutiny as AES. 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] (Raeburn, K., “Advanced Encryption Standard (AES) Encryption for Kerberos 5,” February 2005.) section 8 regarding the stringtokey algorithm also apply to the Camellia encryption types.
10. Test Vectors
Sample results for stringtokey conversion:
Iteration count = 1 Pass phrase = "password" Salt = "ATHENA.MIT.EDUraeburn" 128bit Camellia key: 57 D0 29 72 98 FF D9 D3 5D E5 A4 7F B4 BD E2 4B 256bit Camellia key: B9 D6 82 8B 20 56 B7 BE 65 6D 88 A1 23 B1 FA C6 82 14 AC 2B 72 7E CF 5F 69 AF E0 C4 DF 2A 6D 2C Iteration count = 2 Pass phrase = "password" Salt = "ATHENA.MIT.EDUraeburn" 128bit Camellia key: 73 F1 B5 3A A0 F3 10 F9 3B 1D E8 CC AA 0C B1 52 256bit Camellia key: 83 FC 58 66 E5 F8 F4 C6 F3 86 63 C6 5C 87 54 9F 34 2B C4 7E D3 94 DC 9D 3C D4 D1 63 AD E3 75 E3 Iteration count = 1200 Pass phrase = "password" Salt = "ATHENA.MIT.EDUraeburn" 128bit Camellia key: 8E 57 11 45 45 28 55 57 5F D9 16 E7 B0 44 87 AA 256bit Camellia key: 77 F4 21 A6 F2 5E 13 83 95 E8 37 E5 D8 5D 38 5B 4C 1B FD 77 2E 11 2C D9 20 8C E7 2A 53 0B 15 E6 Iteration count = 5 Pass phrase = "password" Salt=0x1234567878563412 128bit Camellia key: 00 49 8F D9 16 BF C1 C2 B1 03 1C 17 08 01 B3 81 256bit Camellia key: 11 08 3A 00 BD FE 6A 41 B2 F1 97 16 D6 20 2F 0A FA 94 28 9A FE 8B 27 A0 49 BD 28 B1 D7 6C 38 9A Iteration count = 1200 Pass phrase = (64 characters) "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" Salt="pass phrase equals block size" 128bit Camellia key: 8B F6 C3 EF 70 9B 98 1D BB 58 5D 08 68 43 BE 05 256bit Camellia key: 11 9F E2 A1 CB 0B 1B E0 10 B9 06 7A 73 DB 63 ED 46 65 B4 E5 3A 98 D1 78 03 5D CF E8 43 A6 B9 B0 Iteration count = 1200 Pass phrase = (65 characters) "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" Salt = "pass phrase exceeds block size" 128bit Camellia key: 57 52 AC 8D 6A D1 CC FE 84 30 B3 12 87 1C 2F 74 256bit Camellia key: 61 4D 5D FC 0B A6 D3 90 B4 12 B8 9A E4 D5 B0 88 B6 12 B3 16 51 09 94 67 9D DB 43 83 C7 12 6D DF Iteration count = 50 Pass phrase = gclef (0xf09d849e) Salt = "EXAMPLE.COMpianist" 128bit Camellia key: CC 75 C7 FD 26 0F 1C 16 58 01 1F CC 0D 56 06 16 256bit Camellia key: 16 3B 76 8C 6D B1 48 B4 EE C7 16 3D F5 AE D7 0E 20 6B 68 CE C0 78 BC 06 9E D6 8A 7E D3 6B 1E CC
Sample results for key derivation:
128bit Camellia key: 57 D0 29 72 98 FF D9 D3 5D E5 A4 7F B4 BD E2 4B Kc value for key usage 2 (constant = 0x0000000299): D1 55 77 5A 20 9D 05 F0 2B 38 D4 2A 38 9E 5A 56 Ke value for key usage 2 (constant = 0x00000002AA): 64 DF 83 F8 5A 53 2F 17 57 7D 8C 37 03 57 96 AB Ki value for key usage 2 (constant = 0x0000000255): 3E 4F BD F3 0F B8 25 9C 42 5C B6 C9 6F 1F 46 35 256bit Camellia key: B9 D6 82 8B 20 56 B7 BE 65 6D 88 A1 23 B1 FA C6 82 14 AC 2B 72 7E CF 5F 69 AF E0 C4 DF 2A 6D 2C Kc value for key usage 2 (constant = 0x0000000299): E4 67 F9 A9 55 2B C7 D3 15 5A 62 20 AF 9C 19 22 0E EE D4 FF 78 B0 D1 E6 A1 54 49 91 46 1A 9E 50 Ke value for key usage 2 (constant = 0x00000002AA): 41 2A EF C3 62 A7 28 5F C3 96 6C 6A 51 81 E7 60 5A E6 75 23 5B 6D 54 9F BF C9 AB 66 30 A4 C6 04 Ki value for key usage 2 (constant = 0x0000000255): FA 62 4F A0 E5 23 99 3F A3 88 AE FD C6 7E 67 EB CD 8C 08 E8 A0 24 6B 1D 73 B0 D1 DD 9F C5 82 B0
Sample encryptions (all using the default cipher state):
Plaintext: (empty) 128bit Camellia key: 1D C4 6A 8D 76 3F 4F 93 74 2B CB A3 38 75 76 C3 Random confounder: B6 98 22 A1 9A 6B 09 C0 EB C8 55 7D 1F 1B 6C 0A Ciphertext: C4 66 F1 87 10 69 92 1E DB 7C 6F DE 24 4A 52 DB 0B A1 0E DC 19 7B DB 80 06 65 8C A3 CC CE 6E B8 Plaintext: 1 Random confounder: 6F 2F C3 C2 A1 66 FD 88 98 96 7A 83 DE 95 96 D9 128bit Camellia key: 50 27 BC 23 1D 0F 3A 9D 23 33 3F 1C A6 FD BE 7C Ciphertext: 84 2D 21 FD 95 03 11 C0 DD 46 4A 3F 4B E8 D6 DA 88 A5 6D 55 9C 9B 47 D3 F9 A8 50 67 AF 66 15 59 B8 Plaintext: 9 bytesss Random confounder: A5 B4 A7 1E 07 7A EE F9 3C 87 63 C1 8F DB 1F 10 128bit Camellia key: A1 BB 61 E8 05 F9 BA 6D DE 8F DB DD C0 5C DE A0 Ciphertext: 61 9F F0 72 E3 62 86 FF 0A 28 DE B3 A3 52 EC 0D 0E DF 5C 51 60 D6 63 C9 01 75 8C CF 9D 1E D3 3D 71 DB 8F 23 AA BF 83 48 A0 Plaintext: 13 bytes byte Random confounder: 19 FE E4 0D 81 0C 52 4B 5B 22 F0 18 74 C6 93 DA 128bit Camellia key: 2C A2 7A 5F AF 55 32 24 45 06 43 4E 1C EF 66 76 Ciphertext: B8 EC A3 16 7A E6 31 55 12 E5 9F 98 A7 C5 00 20 5E 5F 63 FF 3B B3 89 AF 1C 41 A2 1D 64 0D 86 15 C9 ED 3F BE B0 5A B6 AC B6 76 89 B5 EA Plaintext: 30 bytes bytes bytes bytes byt Random confounder: CA 7A 7A B4 BE 19 2D AB D6 03 50 6D B1 9C 39 E2 128bit Camellia key: 78 24 F8 C1 6F 83 FF 35 4C 6B F7 51 5B 97 3F 43 Ciphertext: A2 6A 39 05 A4 FF D5 81 6B 7B 1E 27 38 0D 08 09 0C 8E C1 F3 04 49 6E 1A BD CD 2B DC D1 DF FC 66 09 89 E1 17 A7 13 DD BB 57 A4 14 6C 15 87 CB A4 35 66 65 59 1D 22 40 28 2F 58 42 B1 05 A5 Plaintext: (empty) Random confounder: 3C BB D2 B4 59 17 94 10 67 F9 65 99 BB 98 92 6C 256bit Camellia key: B6 1C 86 CC 4E 5D 27 57 54 5A D4 23 39 9F B7 03 1E CA B9 13 CB B9 00 BD 7A 3C 6D D8 BF 92 01 5B Ciphertext: 03 88 6D 03 31 0B 47 A6 D8 F0 6D 7B 94 D1 DD 83 7E CC E3 15 EF 65 2A FF 62 08 59 D9 4A 25 92 66 Plaintext: 1 Random confounder: DE F4 87 FC EB E6 DE 63 46 D4 DA 45 21 BB A2 D2 256bit Camellia key: 1B 97 FE 0A 19 0E 20 21 EB 30 75 3E 1B 6E 1E 77 B0 75 4B 1D 68 46 10 35 58 64 10 49 63 46 38 33 Ciphertext: 2C 9C 15 70 13 3C 99 BF 6A 34 BC 1B 02 12 00 2F D1 94 33 87 49 DB 41 35 49 7A 34 7C FC D9 D1 8A 12 Plaintext: 9 bytesss Random confounder: AD 4F F9 04 D3 4E 55 53 84 B1 41 00 FC 46 5F 88 256bit Camellia key: 32 16 4C 5B 43 4D 1D 15 38 E4 CF D9 BE 80 40 FE 8C 4A C7 AC C4 B9 3D 33 14 D2 13 36 68 14 7A 05 Ciphertext: 9C 6D E7 5F 81 2D E7 ED 0D 28 B2 96 35 57 A1 15 64 09 98 27 5B 0A F5 15 27 09 91 3F F5 2A 2A 9C 8E 63 B8 72 F9 2E 64 C8 39 Plaintext: 13 bytes byte Random confounder: CF 9B CA 6D F1 14 4E 0C 0A F9 B8 F3 4C 90 D5 14 256bit Camellia key: B0 38 B1 32 CD 8E 06 61 22 67 FA B7 17 00 66 D8 8A EC CB A0 B7 44 BF C6 0D C8 9B CA 18 2D 07 15 Ciphertext: EE EC 85 A9 81 3C DC 53 67 72 AB 9B 42 DE FC 57 06 F7 26 E9 75 DD E0 5A 87 EB 54 06 EA 32 4C A1 85 C9 98 6B 42 AA BE 79 4B 84 82 1B EE Plaintext: 30 bytes bytes bytes bytes byt Random confounder: 64 4D EF 38 DA 35 00 72 75 87 8D 21 68 55 E2 28 256bit Camellia key: CC FC D3 49 BF 4C 66 77 E8 6E 4B 02 B8 EA B9 24 A5 46 AC 73 1C F9 BF 69 89 B9 96 E7 D6 BF BB A7 Ciphertext: 0E 44 68 09 85 85 5F 2D 1F 18 12 52 9C A8 3B FD 8E 34 9D E6 FD 9A DA 0B AA A0 48 D6 8E 26 5F EB F3 4A D1 25 5A 34 49 99 AD 37 14 68 87 A6 C6 84 57 31 AC 7F 46 37 6A 05 04 CD 06 57 14 74
Sample checksums:
Plaintext: abcdefghijk Checksum type: cmaccamellia128 128bit Camellia key: 1D C4 6A 8D 76 3F 4F 93 74 2B CB A3 38 75 76 C3 Key usage: 7 Checksum: 11 78 E6 C5 C4 7A 8C 1A E0 C4 B9 C7 D4 EB 7B 6B Plaintext: ABCDEFGHIJKLMNOPQRSTUVWXYZ Checksum type: cmaccamellia128 128bit Camellia key: 50 27 BC 23 1D 0F 3A 9D 23 33 3F 1C A6 FD BE 7C Key usage: 8 Checksum: D1 B3 4F 70 04 A7 31 F2 3A 0C 00 BF 6C 3F 75 3A Plaintext: 123456789 Checksum type: cmaccamellia256 256bit Camellia key: B6 1C 86 CC 4E 5D 27 57 54 5A D4 23 39 9F B7 03 1E CA B9 13 CB B9 00 BD 7A 3C 6D D8 BF 92 01 5B Key usage: 9 Checksum: 87 A1 2C FD 2B 96 21 48 10 F0 1C 82 6E 77 44 B1 Plaintext: !@#$%^&*()!@#$%^&*()!@#$%^&*() Checksum type: cmaccamellia256 256bit Camellia key: 32 16 4C 5B 43 4D 1D 15 38 E4 CF D9 BE 80 40 FE 8C 4A C7 AC C4 B9 3D 33 14 D2 13 36 68 14 7A 05 Key usage: 10 Checksum: 3F A0 B4 23 55 E5 2B 18 91 87 29 4A A2 52 AB 64
11. References
[RFC2119]  Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). 
[RFC3713]  Matsui, M., Nakajima, J., and S. Moriai, “A Description of the Camellia Encryption Algorithm,” RFC 3713, April 2004 (TXT). 
[RFC3961]  Raeburn, K., “Encryption and Checksum Specifications for Kerberos 5,” RFC 3961, February 2005 (TXT). 
[RFC3962]  Raeburn, K., “Advanced Encryption Standard (AES) Encryption for Kerberos 5,” RFC 3962, February 2005 (TXT). 
[SP80038B]  Dworkin, M., “Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication,” NIST Special Publication 80038B, October 2009. 
[SP800108]  Chen, L., “Recommendation for Key Derivation Using Pseudorandom Functions,” NIST Special Publication 800108, October 2009. 
[CRYPTOENG]  Schneier, B., “Cryptography Engineering,” March 2010. 
Author's Address
Greg Hudson (editor)  
MIT Kerberos Consortium  
Email:  ghudson@mit.edu 