idnits 2.17.1 draft-ietf-krb-wg-camellia-cts-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2012) is 4431 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 254, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kerberos Working Group G. Hudson, Ed. 3 Internet-Draft MIT Kerberos Consortium 4 Intended status: Informational March 8, 2012 5 Expires: September 9, 2012 7 Camellia Encryption for Kerberos 5 8 draft-ietf-krb-wg-camellia-cts-01 10 Abstract 12 This document specifies two encryption types and two corresponding 13 checksum types for the Kerberos cryptosystem framework defined in RFC 14 3961. The new types use the Camellia block cipher in CBC-mode with 15 ciphertext stealing and the CMAC algorithm for integrity protection. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 9, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 The Camellia block cipher, described in [RFC3713], has a 128-bit 52 block size and a 128-bit, 192-bit, or 256-bit key size, similar to 53 AES. This document specifies Kerberos encryption and checksum types 54 for Camellia using 128-bit or 256-bit keys. The new types conform to 55 the framework specified in [RFC3961], but do not use the simplified 56 profile. 58 Like the simplified profile, the new types use key derivation to 59 produce keys for encryption, integrity protection, and checksum 60 operations. Instead of the [RFC3961] section 5.1 key derivation 61 function, the new types use a key derivation function from the family 62 specified in [SP800-108]. 64 The new types use the CMAC algorithm for integrity protection and 65 checksum operations. As a consequence, they do not rely on a hash 66 algorithm except when generating keys from strings. 68 Like the AES encryption types [RFC3962], the new encryption types use 69 CBC mode with ciphertext stealing to avoid the need for padding. 70 They also use the same PBKDF2 algorithm for key generation from 71 strings, with a modification to the salt string to ensure that 72 different keys are generated for Camellia and AES encryption types. 74 2. Protocol Key Representation 76 The Camellia key space is dense, so we use random octet strings 77 directly as keys. The first bit of the Camellia bit string is the 78 high bit of the first byte of the random octet string. 80 3. Key Generation from Strings 82 We use a variation on the key generation algorithm specified in 83 [RFC3962] section 4. 85 First, to ensure that different long-term keys are used with Camellia 86 and AES, we prepend the enctype name to the salt string, separated by 87 a null byte. The enctype name is "camellia128-cts-cmac" or 88 "camellia256-cts-cmac" (without the quotes). 90 Second, the final key derivation step uses the algorithm described in 91 Section 4 instead of the key derivation algorithm used by the 92 simplified profile. 94 Third, if no string-to-key parameters are specified, the default 95 number of iterations is raised to 32768. 97 saltp = enctype-name | 0x00 | salt 98 tkey = random2key(PBKDF2-HMAC-SHA1(passphrase, saltp, 99 iter_count, keylength)) 100 key = KDF-FEEDBACK-CMAC(tkey, "kerberos") 102 4. Key Derivation 104 We use a key derivation function from the family specified in 105 [SP800-108] section 5.2, "KDF in Feedback Mode". The PRF parameter 106 of the key derivation function is CMAC with Camellia-128 or Camellia- 107 256 as the underlying block cipher; this PRF has an output size of 108 128 bits. A block counter is used with a length of 4 bytes, 109 represented in big-endian order. The length of the output key in 110 bits (denoted as k) is also represented as a four-byte string in big- 111 endian order. The label input to the KDF is the usage constant 112 supplied to the key derivation function, and the context is unused. 114 n = ceiling(k / 128) 115 K0 = zeros 116 Ki = CMAC(key, K(i-1) | i | constant | 0x00 | k) 117 DR(key, constant) = k-truncate(K1 | K2 | ... | Kn) 118 KDF-FEEDBACK-CMAC(key, constant) = random-to-key(DR(key, constant)) 120 The constants used for key derivation are the same as those used in 121 the simplified profile. 123 5. CMAC Checksum Algorithm 125 For integrity protection and checksums, we use the CMAC function 126 defined in [SP800-38B], with Camellia-128 or Camellia-256 as the 127 underlying block cipher. 129 6. Kerberos Algorithm Protocol Parameters 131 The following parameters apply to the encryption types camellia128- 132 cts-cmac, which uses a 128-bit protocol key, and camellia256-cts- 133 cmac, which uses a 256-bit protocol key. 135 Protocol key format: as defined in Section 2. 137 Specific key structure: three protocol format keys: { Kc, Ke, Ki }. 139 Required checksum mechanism: as defined in Section 7. 141 Key generation seed length: the key size (128 or 256 bits). 143 String-to-key function: as defined in Section 3. 145 Default string-to-key parameters: 00 00 80 00. 147 Random-to-key function: identity function. 149 Key-derivation function: as indicated below, with usage represented 150 as four octets in big-endian order. 152 Kc = KDF-FEEDBACK-CMAC(base-key, usage | 0x99) 153 Ke = KDF-FEEDBACK-CMAC(base-key, usage | 0xAA) 154 Ki = KDF-FEEDBACK-CMAC(base-key, usage | 0x55) 156 Cipher state: a 128-bit CBC initialization vector. 158 Initial cipher state: all bits zero. 160 Encryption function: as follows, where E() is Camellia encryption in 161 CBC-CTS mode, with the next-to-last block used as the CBC-style ivec, 162 or the last block if there is only one. 164 conf = Random string of 128 bits 165 (C, newstate) = E(Ke, conf | plaintext, oldstate) 166 M = CMAC(Ki, conf | plaintext) 167 ciphertext = C | M 169 Decryption function: as follows, where D() is Camellia decryption in 170 CBC-CTS mode, with the ivec treated as in E(). To separate the 171 ciphertext into C and M components, use the final final 16 bytes for 172 M and all of the preceding bytes for C. 174 (C, M) = ciphertext 175 (P, newIV) = D(Ke, C, oldstate) 176 if (M != CMAC(Ki, P)) report error 177 newstate = newIV 179 Pseudo-random function: as follows. 181 Kp = KDF-FEEDBACK-CMAC(protocol-key, "prf") 182 PRF = CMAC(Kp, octet-string) 184 7. Checksum Parameters 186 The following parameters apply to the checksum types cmac-camellia128 187 and cmac-camellia256, which are the associated checksum for 188 camellia128-cts-cmac and camellia256-cts-cmac respectively. 190 Associated cryptosystem: Camellia-128 or Camellia-256 as appropriate 191 for the checksum type. 193 get_mic: CMAC(Kc, message). 195 verify_mic: get_mic and compare. 197 8. Security Considerations 199 [CRYPTOENG] chapter 4 discusses weaknesses of the CBC cipher mode. 200 An attacker who can observe enough messages generated with the same 201 key to encounter a collision in ciphertext blocks could recover the 202 XOR of the plaintexts of the previous blocks. Observing such a 203 collision becomes likely as the number of blocks observed approaches 204 2^64. This consideration applies to all previously standardized 205 Kerberos encryption types and all uses of CBC encryption with 128-bit 206 block ciphers in other protocols. Kerberos deployments can mitigate 207 this concern by rolling over keys often enough to make observing 2^64 208 messages unlikely. 210 Because the new checksum types are deterministic, an attacker could 211 pre-compute checksums for a known plain-text message in 2^64 randomly 212 chosen protocol keys. The attacker could then observe checksums 213 legitimately computed in different keys until a collision with one of 214 the pre-computed keys is observed; this becomes likely after the 215 number of observed checksums approaches 2^64. Observing such a 216 collision allows the attacker to recover the protocol key. This 217 consideration applies to most previously standardized Kerberos 218 checksum types and most uses of 128-bit checksums in other protocols. 220 Kerberos deployments should not migrate to the Camellia encryption 221 types simply because they are newer, but should use them only if 222 business needs require the use of Camellia, or if a serious flaw is 223 discovered in AES which does not apply to Camellia. 225 The security considerations described in [RFC3962] section 8 226 regarding the string-to-key algorithm also apply to the Camellia 227 encryption types. 229 At the time of writing this document, there are no known weak keys 230 for Camellia, and no security problem has been found on Camellia (see 231 [NESSIE], [CRYPTREC], and [LNCS5867]). 233 9. IANA Considerations 235 IANA has assigned the following numbers from the Encryption Type 236 Numbers and Checksum Type Numbers registries defined in [RFC3961] 237 section 11. 239 Encryption types 241 +-------+----------------------+-----------+ 242 | etype | encryption type | Reference | 243 +-------+----------------------+-----------+ 244 | TBD1 | camellia128-cts-cmac | [RFCXXXX] | 245 | TBD2 | camellia256-cts-cmac | [RFCXXXX] | 246 +-------+----------------------+-----------+ 248 Checksum types 250 +---------------+------------------+---------------+-----------+ 251 | sumtype value | Checksum type | checksum size | Reference | 252 +---------------+------------------+---------------+-----------+ 253 | TBD3 | cmac-camellia128 | 16 | [RFCXXXX] | 254 | TBD4 | cmac-camellia256 | 16 | [RFCXXXX] | 255 +---------------+------------------+---------------+-----------+ 257 [TO BE REMOVED: These registries are at: http://www.iana.org/ 258 assignments/kerberos-parameters/kerberos-parameters.xml] 260 10. Test Vectors 262 Sample results for string-to-key conversion: 264 Iteration count = 1 265 Pass phrase = "password" 266 Salt = "ATHENA.MIT.EDUraeburn" 267 128-bit Camellia key: 268 57 D0 29 72 98 FF D9 D3 5D E5 A4 7F B4 BD E2 4B 269 256-bit Camellia key: 270 B9 D6 82 8B 20 56 B7 BE 65 6D 88 A1 23 B1 FA C6 271 82 14 AC 2B 72 7E CF 5F 69 AF E0 C4 DF 2A 6D 2C 273 Iteration count = 2 274 Pass phrase = "password" 275 Salt = "ATHENA.MIT.EDUraeburn" 276 128-bit Camellia key: 277 73 F1 B5 3A A0 F3 10 F9 3B 1D E8 CC AA 0C B1 52 278 256-bit Camellia key: 279 83 FC 58 66 E5 F8 F4 C6 F3 86 63 C6 5C 87 54 9F 280 34 2B C4 7E D3 94 DC 9D 3C D4 D1 63 AD E3 75 E3 282 Iteration count = 1200 283 Pass phrase = "password" 284 Salt = "ATHENA.MIT.EDUraeburn" 285 128-bit Camellia key: 286 8E 57 11 45 45 28 55 57 5F D9 16 E7 B0 44 87 AA 287 256-bit Camellia key: 288 77 F4 21 A6 F2 5E 13 83 95 E8 37 E5 D8 5D 38 5B 289 4C 1B FD 77 2E 11 2C D9 20 8C E7 2A 53 0B 15 E6 291 Iteration count = 5 292 Pass phrase = "password" 293 Salt=0x1234567878563412 294 128-bit Camellia key: 295 00 49 8F D9 16 BF C1 C2 B1 03 1C 17 08 01 B3 81 296 256-bit Camellia key: 297 11 08 3A 00 BD FE 6A 41 B2 F1 97 16 D6 20 2F 0A 298 FA 94 28 9A FE 8B 27 A0 49 BD 28 B1 D7 6C 38 9A 300 Iteration count = 1200 301 Pass phrase = (64 characters) 302 "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 303 Salt="pass phrase equals block size" 304 128-bit Camellia key: 305 8B F6 C3 EF 70 9B 98 1D BB 58 5D 08 68 43 BE 05 306 256-bit Camellia key: 307 11 9F E2 A1 CB 0B 1B E0 10 B9 06 7A 73 DB 63 ED 308 46 65 B4 E5 3A 98 D1 78 03 5D CF E8 43 A6 B9 B0 310 Iteration count = 1200 311 Pass phrase = (65 characters) 312 "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 313 Salt = "pass phrase exceeds block size" 314 128-bit Camellia key: 315 57 52 AC 8D 6A D1 CC FE 84 30 B3 12 87 1C 2F 74 316 256-bit Camellia key: 317 61 4D 5D FC 0B A6 D3 90 B4 12 B8 9A E4 D5 B0 88 318 B6 12 B3 16 51 09 94 67 9D DB 43 83 C7 12 6D DF 320 Iteration count = 50 321 Pass phrase = g-clef (0xf09d849e) 322 Salt = "EXAMPLE.COMpianist" 323 128-bit Camellia key: 324 CC 75 C7 FD 26 0F 1C 16 58 01 1F CC 0D 56 06 16 325 256-bit Camellia key: 326 16 3B 76 8C 6D B1 48 B4 EE C7 16 3D F5 AE D7 0E 327 20 6B 68 CE C0 78 BC 06 9E D6 8A 7E D3 6B 1E CC 329 Sample results for key derivation: 331 128-bit Camellia key: 332 57 D0 29 72 98 FF D9 D3 5D E5 A4 7F B4 BD E2 4B 333 Kc value for key usage 2 (constant = 0x0000000299): 334 D1 55 77 5A 20 9D 05 F0 2B 38 D4 2A 38 9E 5A 56 335 Ke value for key usage 2 (constant = 0x00000002AA): 336 64 DF 83 F8 5A 53 2F 17 57 7D 8C 37 03 57 96 AB 337 Ki value for key usage 2 (constant = 0x0000000255): 338 3E 4F BD F3 0F B8 25 9C 42 5C B6 C9 6F 1F 46 35 340 256-bit Camellia key: 341 B9 D6 82 8B 20 56 B7 BE 65 6D 88 A1 23 B1 FA C6 342 82 14 AC 2B 72 7E CF 5F 69 AF E0 C4 DF 2A 6D 2C 343 Kc value for key usage 2 (constant = 0x0000000299): 344 E4 67 F9 A9 55 2B C7 D3 15 5A 62 20 AF 9C 19 22 345 0E EE D4 FF 78 B0 D1 E6 A1 54 49 91 46 1A 9E 50 346 Ke value for key usage 2 (constant = 0x00000002AA): 347 41 2A EF C3 62 A7 28 5F C3 96 6C 6A 51 81 E7 60 348 5A E6 75 23 5B 6D 54 9F BF C9 AB 66 30 A4 C6 04 349 Ki value for key usage 2 (constant = 0x0000000255): 350 FA 62 4F A0 E5 23 99 3F A3 88 AE FD C6 7E 67 EB 351 CD 8C 08 E8 A0 24 6B 1D 73 B0 D1 DD 9F C5 82 B0 353 Sample encryptions (all using the default cipher state): 355 Plaintext: (empty) 356 128-bit Camellia key: 357 1D C4 6A 8D 76 3F 4F 93 74 2B CB A3 38 75 76 C3 358 Random confounder: 359 B6 98 22 A1 9A 6B 09 C0 EB C8 55 7D 1F 1B 6C 0A 360 Ciphertext: 361 C4 66 F1 87 10 69 92 1E DB 7C 6F DE 24 4A 52 DB 362 0B A1 0E DC 19 7B DB 80 06 65 8C A3 CC CE 6E B8 364 Plaintext: 1 365 Random confounder: 366 6F 2F C3 C2 A1 66 FD 88 98 96 7A 83 DE 95 96 D9 367 128-bit Camellia key: 368 50 27 BC 23 1D 0F 3A 9D 23 33 3F 1C A6 FD BE 7C 369 Ciphertext: 370 84 2D 21 FD 95 03 11 C0 DD 46 4A 3F 4B E8 D6 DA 371 88 A5 6D 55 9C 9B 47 D3 F9 A8 50 67 AF 66 15 59 372 B8 374 Plaintext: 9 bytesss 375 Random confounder: 376 A5 B4 A7 1E 07 7A EE F9 3C 87 63 C1 8F DB 1F 10 378 128-bit Camellia key: 379 A1 BB 61 E8 05 F9 BA 6D DE 8F DB DD C0 5C DE A0 380 Ciphertext: 381 61 9F F0 72 E3 62 86 FF 0A 28 DE B3 A3 52 EC 0D 382 0E DF 5C 51 60 D6 63 C9 01 75 8C CF 9D 1E D3 3D 383 71 DB 8F 23 AA BF 83 48 A0 385 Plaintext: 13 bytes byte 386 Random confounder: 387 19 FE E4 0D 81 0C 52 4B 5B 22 F0 18 74 C6 93 DA 388 128-bit Camellia key: 389 2C A2 7A 5F AF 55 32 24 45 06 43 4E 1C EF 66 76 390 Ciphertext: 391 B8 EC A3 16 7A E6 31 55 12 E5 9F 98 A7 C5 00 20 392 5E 5F 63 FF 3B B3 89 AF 1C 41 A2 1D 64 0D 86 15 393 C9 ED 3F BE B0 5A B6 AC B6 76 89 B5 EA 395 Plaintext: 30 bytes bytes bytes bytes byt 396 Random confounder: 397 CA 7A 7A B4 BE 19 2D AB D6 03 50 6D B1 9C 39 E2 398 128-bit Camellia key: 399 78 24 F8 C1 6F 83 FF 35 4C 6B F7 51 5B 97 3F 43 400 Ciphertext: 401 A2 6A 39 05 A4 FF D5 81 6B 7B 1E 27 38 0D 08 09 402 0C 8E C1 F3 04 49 6E 1A BD CD 2B DC D1 DF FC 66 403 09 89 E1 17 A7 13 DD BB 57 A4 14 6C 15 87 CB A4 404 35 66 65 59 1D 22 40 28 2F 58 42 B1 05 A5 406 Plaintext: (empty) 407 Random confounder: 408 3C BB D2 B4 59 17 94 10 67 F9 65 99 BB 98 92 6C 409 256-bit Camellia key: 410 B6 1C 86 CC 4E 5D 27 57 54 5A D4 23 39 9F B7 03 411 1E CA B9 13 CB B9 00 BD 7A 3C 6D D8 BF 92 01 5B 412 Ciphertext: 413 03 88 6D 03 31 0B 47 A6 D8 F0 6D 7B 94 D1 DD 83 414 7E CC E3 15 EF 65 2A FF 62 08 59 D9 4A 25 92 66 416 Plaintext: 1 417 Random confounder: 418 DE F4 87 FC EB E6 DE 63 46 D4 DA 45 21 BB A2 D2 419 256-bit Camellia key: 420 1B 97 FE 0A 19 0E 20 21 EB 30 75 3E 1B 6E 1E 77 421 B0 75 4B 1D 68 46 10 35 58 64 10 49 63 46 38 33 422 Ciphertext: 423 2C 9C 15 70 13 3C 99 BF 6A 34 BC 1B 02 12 00 2F 424 D1 94 33 87 49 DB 41 35 49 7A 34 7C FC D9 D1 8A 425 12 427 Plaintext: 9 bytesss 428 Random confounder: 429 AD 4F F9 04 D3 4E 55 53 84 B1 41 00 FC 46 5F 88 430 256-bit Camellia key: 431 32 16 4C 5B 43 4D 1D 15 38 E4 CF D9 BE 80 40 FE 432 8C 4A C7 AC C4 B9 3D 33 14 D2 13 36 68 14 7A 05 433 Ciphertext: 434 9C 6D E7 5F 81 2D E7 ED 0D 28 B2 96 35 57 A1 15 435 64 09 98 27 5B 0A F5 15 27 09 91 3F F5 2A 2A 9C 436 8E 63 B8 72 F9 2E 64 C8 39 438 Plaintext: 13 bytes byte 439 Random confounder: 440 CF 9B CA 6D F1 14 4E 0C 0A F9 B8 F3 4C 90 D5 14 441 256-bit Camellia key: 442 B0 38 B1 32 CD 8E 06 61 22 67 FA B7 17 00 66 D8 443 8A EC CB A0 B7 44 BF C6 0D C8 9B CA 18 2D 07 15 444 Ciphertext: 445 EE EC 85 A9 81 3C DC 53 67 72 AB 9B 42 DE FC 57 446 06 F7 26 E9 75 DD E0 5A 87 EB 54 06 EA 32 4C A1 447 85 C9 98 6B 42 AA BE 79 4B 84 82 1B EE 449 Plaintext: 30 bytes bytes bytes bytes byt 450 Random confounder: 451 64 4D EF 38 DA 35 00 72 75 87 8D 21 68 55 E2 28 452 256-bit Camellia key: 453 CC FC D3 49 BF 4C 66 77 E8 6E 4B 02 B8 EA B9 24 454 A5 46 AC 73 1C F9 BF 69 89 B9 96 E7 D6 BF BB A7 455 Ciphertext: 456 0E 44 68 09 85 85 5F 2D 1F 18 12 52 9C A8 3B FD 457 8E 34 9D E6 FD 9A DA 0B AA A0 48 D6 8E 26 5F EB 458 F3 4A D1 25 5A 34 49 99 AD 37 14 68 87 A6 C6 84 459 57 31 AC 7F 46 37 6A 05 04 CD 06 57 14 74 461 Sample checksums: 463 Plaintext: abcdefghijk 464 Checksum type: cmac-camellia128 465 128-bit Camellia key: 466 1D C4 6A 8D 76 3F 4F 93 74 2B CB A3 38 75 76 C3 467 Key usage: 7 468 Checksum: 469 11 78 E6 C5 C4 7A 8C 1A E0 C4 B9 C7 D4 EB 7B 6B 471 Plaintext: ABCDEFGHIJKLMNOPQRSTUVWXYZ 472 Checksum type: cmac-camellia128 473 128-bit Camellia key: 474 50 27 BC 23 1D 0F 3A 9D 23 33 3F 1C A6 FD BE 7C 475 Key usage: 8 476 Checksum: 477 D1 B3 4F 70 04 A7 31 F2 3A 0C 00 BF 6C 3F 75 3A 479 Plaintext: 123456789 480 Checksum type: cmac-camellia256 481 256-bit Camellia key: 482 B6 1C 86 CC 4E 5D 27 57 54 5A D4 23 39 9F B7 03 483 1E CA B9 13 CB B9 00 BD 7A 3C 6D D8 BF 92 01 5B 484 Key usage: 9 485 Checksum: 486 87 A1 2C FD 2B 96 21 48 10 F0 1C 82 6E 77 44 B1 488 Plaintext: !@#$%^&*()!@#$%^&*()!@#$%^&*() 489 Checksum type: cmac-camellia256 490 256-bit Camellia key: 491 32 16 4C 5B 43 4D 1D 15 38 E4 CF D9 BE 80 40 FE 492 8C 4A C7 AC C4 B9 3D 33 14 D2 13 36 68 14 7A 05 493 Key usage: 10 494 Checksum: 495 3F A0 B4 23 55 E5 2B 18 91 87 29 4A A2 52 AB 64 497 11. References 499 11.1. Normative References 501 [RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of 502 the Camellia Encryption Algorithm", RFC 3713, April 2004. 504 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 505 Kerberos 5", RFC 3961, February 2005. 507 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 508 Encryption for Kerberos 5", RFC 3962, February 2005. 510 [SP800-38B] 511 Dworkin, M., "Recommendation for Block Cipher Modes of 512 Operation: The CMAC Mode for Authentication", NIST Special 513 Publication 800-38B, October 2009. 515 [SP800-108] 516 Chen, L., "Recommendation for Key Derivation Using 517 Pseudorandom Functions", NIST Special Publication 800-108, 518 October 2009. 520 11.2. Non-normative References 522 [CRYPTOENG] 523 Schneier, B., "Cryptography Engineering", March 2010. 525 [CRYPTREC] 526 Information-technology Promotion Agency (IPA), 527 "Cryptography Research and Evaluation Committees", 528 . 530 [LNCS5867] 531 Mala, H., Shakiba, M., and M. Dakhil-alian, "New Results 532 on Impossible Different Cryptanalysis of Reduced Round 533 Camellia-128", LNCS 5867, November 2009, 534 . 536 [NESSIE] The NESSIE Project, "New European Schemes for Signatures, 537 Integrity, and Encryption", 538 . 540 Appendix A. Acknowledgements 542 The author would like to thank Ken Raeburn, Satoru Kanno, Jeffrey 543 Hutzelman, Nico Williams, Sam Hartman, and Tom Yu for their help in 544 reviewing and providing feedback on this document. 546 Author's Address 548 Greg Hudson (editor) 549 MIT Kerberos Consortium 551 Email: ghudson@mit.edu