idnits 2.17.00 (12 Aug 2021) /tmp/idnits36616/draft-hudson-krbwg-camellia-cts-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 11, 2011) is 4027 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3713 -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-38B' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-108' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRYPTOENG' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRYPTREC' -- Possible downref: Non-RFC (?) normative reference: ref. 'LNCS5867' -- Possible downref: Non-RFC (?) normative reference: ref. 'NESSIE' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). 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 Expires: November 12, 2011 May 11, 2011 6 Camellia Encryption for Kerberos 5 7 draft-hudson-krbwg-camellia-cts-02 9 Abstract 11 This document specifies two encryption types and two corresponding 12 checksum types for the Kerberos cryptosystem suite. The new types 13 use the Camellia block cipher in CBC-mode with ciphertext stealing 14 and the CMAC algorithm for integrity protection. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 12, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 1. Introduction 56 The Camellia block cipher, described in [RFC3713], has a 128-bit 57 block size and a 128-bit, 192-bit, or 256-bit key size, similar to 58 AES. This document specifies Kerberos encryption and checksum types 59 for Camellia using 128-bit or 256-bit keys. The new types conform to 60 the framework specified in [RFC3961], but do not use the simplified 61 profile. 63 Like the simplified profile, the new types use key derivation to 64 produce keys for encryption, integrity protection, and checksum 65 operations. Instead of the [RFC3961] section 5.1 key derivation 66 function, the new types use a key derivation function from the family 67 specified in [SP800-108]. 69 The new types use the CMAC algorithm for integrity protection and 70 checksum operations. As a consequence, they do not rely on a hash 71 algorithm except when generating keys from strings. 73 Like the AES encryption types [RFC3962], the new encryption types use 74 CBC mode with ciphertext stealing to avoid the need for padding. 75 They also use the same PBKDF2 algorithm for key generation from 76 strings, with a modification to the salt string to ensure that 77 different keys are generated for Camellia and AES encryption types. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. Protocol Key Representation 85 The Camellia key space is dense, so we use random octet strings 86 directly as keys. The first bit of the Camellia bit string is the 87 high bit of the first byte of the random octet string. 89 3. Key Generation from Strings 91 We use a variation on the key generation algorithm specified in 92 [RFC3962] section 4. 94 First, to ensure that different long-term keys are used with Camellia 95 and AES, we prepend the enctype name to the salt string, separated by 96 a null byte. The enctype name is "camellia128-cts-cmac" or 97 "camellia256-cts-cmac" (without the quotes). 99 Second, the final key derivation step uses the algorithm described in 100 Section 4 instead of the key derivation algorithm used by the 101 simplified profile. 103 Third, if no string-to-key parameters are specified, the default 104 number of iterations is raised to 32768. 106 saltp = enctype-name | 0x00 | salt 107 tkey = random2key(PBKDF2-HMAC-SHA1(passphrase, saltp, 108 iter_count, keylength)) 109 key = KDF-FEEDBACK-CMAC(tkey, "kerberos") 111 4. Key Derivation 113 We use a key derivation function from the family specified in 114 [SP800-108] section 5.2, "KDF in Feedback Mode". The PRF parameter 115 of the key derivation function is CMAC with Camellia-128 or Camellia- 116 256 as the underlying block cipher; this PRF has an output size of 117 128 bits. A block counter is used with a length of 4 bytes, 118 represented in big-endian order. The length of the output key in 119 bits (denoted as k) is also represented as a four-byte string in big- 120 endian order. The label input to the KDF is the usage constant 121 supplied to the key derivation function, and the context is unused. 123 n = ceiling(k / 128) 124 K0 = zeros 125 Ki = CMAC(key, K(i-1) | i | constant | 0x00 | k) 126 DR(key, constant) = k-truncate(K1 | K2 | ... | Kn) 127 KDF-FEEDBACK-CMAC(key, constant) = random-to-key(DR(key, constant)) 129 The constants used for key derivation are the same as those used in 130 the simplified profile. 132 5. CMAC Checksum Algorithm 134 For integrity protection and checksums, we use the CMAC function 135 defined in [SP800-38B], with Camellia-128 or Camellia-256 as the 136 underlying block cipher. 138 6. Kerberos Algorithm Protocol Parameters 140 The following parameters apply to the encryption types camellia128- 141 cts-cmac, which uses a 128-bit protocol key, and camellia256-cts- 142 cmac, which uses a 256-bit protocol key. 144 Protocol key format: as defined in Section 2. 146 Specific key structure: three protocol format keys: { Kc, Ke, Ki }. 148 Required checksum mechanism: as defined in Section 7. 150 Key generation seed length: the key size (128 or 256 bits). 152 String-to-key function: as defined in Section 3. 154 Default string-to-key parameters: 00 00 80 00. 156 Random-to-key function: identity function. 158 Key-derivation function: as indicated below, with usage represented 159 as four octets in big-endian order. 161 Kc = KDF-FEEDBACK-CMAC(base-key, usage | 0x99) 162 Ke = KDF-FEEDBACK-CMAC(base-key, usage | 0xAA) 163 Ki = KDF-FEEDBACK-CMAC(base-key, usage | 0x55) 165 Cipher state: a 128-bit CBC initialization vector. 167 Initial cipher state: all bits zero. 169 Encryption function: as follows, where E() is Camellia encryption in 170 CBC-CTS mode, with the next-to-last block used as the CBC-style ivec, 171 or the last block if there is only one. 173 conf = Random string of 128 bits 174 (C, newstate) = E(Ke, conf | plaintext, oldstate) 175 M = CMAC(Ki, conf | plaintext) 176 ciphertext = C | M 178 Decryption function: as follows, where D() is Camellia decryption in 179 CBC-CTS mode, with the ivec treated as in E(). 181 (C, M) = ciphertext 182 (P, newIV) = D(Ke, C, oldstate) 183 if (M != CMAC(Ki, P)) report error 184 newstate = newIV 185 Pseudo-random function: as follows. 187 Kp = KDF-FEEDBACK-CMAC(protocol-key, "prf") 188 PRF = CMAC(Kp, octet-string) 190 7. Checksum Parameters 192 The following parameters apply to the checksum types cmac-camellia128 193 and cmac-camellia256, which are the associated checksum for 194 camellia128-cts-cmac and camellia256-cts-cmac respectively. 196 Associated cryptosystem: Camellia-128 or Camellia-256 as appropriate 197 for the checksum type. 199 get_mic: CMAC(Kc, message). 201 verify_mic: get_mic and compare. 203 8. Assigned Numbers 205 Encryption types 207 +----------------------+-------------+----------+ 208 | Type name | etype value | key size | 209 +----------------------+-------------+----------+ 210 | camellia128-cts-cmac | TBD | 128 | 211 | camellia256-cts-cmac | TBD | 256 | 212 +----------------------+-------------+----------+ 214 Checksum types 216 +------------------+---------------+--------+ 217 | Type name | sumtype value | length | 218 +------------------+---------------+--------+ 219 | cmac-camellia128 | TBD | 128 | 220 | cmac-camellia256 | TBD | 128 | 221 +------------------+---------------+--------+ 223 9. Security Considerations 225 [CRYPTOENG] chapter 4 discusses weaknesses of the CBC cipher mode. 226 An attacker who can observe enough messages generated with the same 227 key to encounter a collision in ciphertext blocks could recover the 228 XOR of the plaintexts of the previous blocks. Observing such a 229 collision becomes likely as the number of blocks observed approaches 230 2^64. This consideration applies to all previously standardized 231 Kerberos encryption types and all uses of CBC encryption with 128-bit 232 block ciphers in other protocols. Kerberos deployments can mitigate 233 this concern by rolling over keys often enough to make observing 2^64 234 messages unlikely. 236 Because the new checksum types are deterministic, an attacker could 237 pre-compute checksums for a known plain-text message in 2^64 randomly 238 chosen protocol keys. The attacker could then observe checksums 239 legitimately computed in different keys until a collision with one of 240 the pre-computed keys is observed; this becomes likely after the 241 number of observed checksums approaches 2^64. Observing such a 242 collision allows the attacker to recover the protocol key. This 243 consideration applies to most previously standardized Kerberos 244 checksum types and most uses of 128-bit checksums in other protocols. 246 Kerberos deployments should not migrate to the Camellia encryption 247 types simply because they are newer, but should use them only if 248 business needs require the use of Camellia, or if a serious flaw is 249 discovered in AES which does not apply to Camellia. 251 The security considerations described in [RFC3962] section 8 252 regarding the string-to-key algorithm also apply to the Camellia 253 encryption types. 255 At the time of writing this document, there are no known weak keys 256 for Camellia, and no security problem has been found on Camellia (see 257 [NESSIE], [CRYPTREC], and [LNCS5867]). 259 10. IANA Considerations 261 Assign two Kerberos Encryption Type Numbers for camellia128-cts-cmac 262 and camellia256-cts-cmac. 264 Assign two Kerberos Checksum Type Numbers for cmac-camellia128 and 265 camellia256. 267 11. Test Vectors 269 Sample results for string-to-key conversion: 271 Iteration count = 1 272 Pass phrase = "password" 273 Salt = "ATHENA.MIT.EDUraeburn" 274 128-bit Camellia key: 275 57 D0 29 72 98 FF D9 D3 5D E5 A4 7F B4 BD E2 4B 277 256-bit Camellia key: 278 B9 D6 82 8B 20 56 B7 BE 65 6D 88 A1 23 B1 FA C6 279 82 14 AC 2B 72 7E CF 5F 69 AF E0 C4 DF 2A 6D 2C 281 Iteration count = 2 282 Pass phrase = "password" 283 Salt = "ATHENA.MIT.EDUraeburn" 284 128-bit Camellia key: 285 73 F1 B5 3A A0 F3 10 F9 3B 1D E8 CC AA 0C B1 52 286 256-bit Camellia key: 287 83 FC 58 66 E5 F8 F4 C6 F3 86 63 C6 5C 87 54 9F 288 34 2B C4 7E D3 94 DC 9D 3C D4 D1 63 AD E3 75 E3 290 Iteration count = 1200 291 Pass phrase = "password" 292 Salt = "ATHENA.MIT.EDUraeburn" 293 128-bit Camellia key: 294 8E 57 11 45 45 28 55 57 5F D9 16 E7 B0 44 87 AA 295 256-bit Camellia key: 296 77 F4 21 A6 F2 5E 13 83 95 E8 37 E5 D8 5D 38 5B 297 4C 1B FD 77 2E 11 2C D9 20 8C E7 2A 53 0B 15 E6 299 Iteration count = 5 300 Pass phrase = "password" 301 Salt=0x1234567878563412 302 128-bit Camellia key: 303 00 49 8F D9 16 BF C1 C2 B1 03 1C 17 08 01 B3 81 304 256-bit Camellia key: 305 11 08 3A 00 BD FE 6A 41 B2 F1 97 16 D6 20 2F 0A 306 FA 94 28 9A FE 8B 27 A0 49 BD 28 B1 D7 6C 38 9A 308 Iteration count = 1200 309 Pass phrase = (64 characters) 310 "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 311 Salt="pass phrase equals block size" 312 128-bit Camellia key: 313 8B F6 C3 EF 70 9B 98 1D BB 58 5D 08 68 43 BE 05 314 256-bit Camellia key: 315 11 9F E2 A1 CB 0B 1B E0 10 B9 06 7A 73 DB 63 ED 316 46 65 B4 E5 3A 98 D1 78 03 5D CF E8 43 A6 B9 B0 318 Iteration count = 1200 319 Pass phrase = (65 characters) 320 "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 321 Salt = "pass phrase exceeds block size" 322 128-bit Camellia key: 323 57 52 AC 8D 6A D1 CC FE 84 30 B3 12 87 1C 2F 74 324 256-bit Camellia key: 326 61 4D 5D FC 0B A6 D3 90 B4 12 B8 9A E4 D5 B0 88 327 B6 12 B3 16 51 09 94 67 9D DB 43 83 C7 12 6D DF 329 Iteration count = 50 330 Pass phrase = g-clef (0xf09d849e) 331 Salt = "EXAMPLE.COMpianist" 332 128-bit Camellia key: 333 CC 75 C7 FD 26 0F 1C 16 58 01 1F CC 0D 56 06 16 334 256-bit Camellia key: 335 16 3B 76 8C 6D B1 48 B4 EE C7 16 3D F5 AE D7 0E 336 20 6B 68 CE C0 78 BC 06 9E D6 8A 7E D3 6B 1E CC 338 Sample results for key derivation: 340 128-bit Camellia key: 341 57 D0 29 72 98 FF D9 D3 5D E5 A4 7F B4 BD E2 4B 342 Kc value for key usage 2 (constant = 0x0000000299): 343 D1 55 77 5A 20 9D 05 F0 2B 38 D4 2A 38 9E 5A 56 344 Ke value for key usage 2 (constant = 0x00000002AA): 345 64 DF 83 F8 5A 53 2F 17 57 7D 8C 37 03 57 96 AB 346 Ki value for key usage 2 (constant = 0x0000000255): 347 3E 4F BD F3 0F B8 25 9C 42 5C B6 C9 6F 1F 46 35 349 256-bit Camellia key: 350 B9 D6 82 8B 20 56 B7 BE 65 6D 88 A1 23 B1 FA C6 351 82 14 AC 2B 72 7E CF 5F 69 AF E0 C4 DF 2A 6D 2C 352 Kc value for key usage 2 (constant = 0x0000000299): 353 E4 67 F9 A9 55 2B C7 D3 15 5A 62 20 AF 9C 19 22 354 0E EE D4 FF 78 B0 D1 E6 A1 54 49 91 46 1A 9E 50 355 Ke value for key usage 2 (constant = 0x00000002AA): 356 41 2A EF C3 62 A7 28 5F C3 96 6C 6A 51 81 E7 60 357 5A E6 75 23 5B 6D 54 9F BF C9 AB 66 30 A4 C6 04 358 Ki value for key usage 2 (constant = 0x0000000255): 359 FA 62 4F A0 E5 23 99 3F A3 88 AE FD C6 7E 67 EB 360 CD 8C 08 E8 A0 24 6B 1D 73 B0 D1 DD 9F C5 82 B0 362 Sample encryptions (all using the default cipher state): 364 Plaintext: (empty) 365 128-bit Camellia key: 366 1D C4 6A 8D 76 3F 4F 93 74 2B CB A3 38 75 76 C3 367 Random confounder: 368 B6 98 22 A1 9A 6B 09 C0 EB C8 55 7D 1F 1B 6C 0A 369 Ciphertext: 370 C4 66 F1 87 10 69 92 1E DB 7C 6F DE 24 4A 52 DB 371 0B A1 0E DC 19 7B DB 80 06 65 8C A3 CC CE 6E B8 373 Plaintext: 1 374 Random confounder: 375 6F 2F C3 C2 A1 66 FD 88 98 96 7A 83 DE 95 96 D9 376 128-bit Camellia key: 377 50 27 BC 23 1D 0F 3A 9D 23 33 3F 1C A6 FD BE 7C 378 Ciphertext: 379 84 2D 21 FD 95 03 11 C0 DD 46 4A 3F 4B E8 D6 DA 380 88 A5 6D 55 9C 9B 47 D3 F9 A8 50 67 AF 66 15 59 381 B8 383 Plaintext: 9 bytesss 384 Random confounder: 385 A5 B4 A7 1E 07 7A EE F9 3C 87 63 C1 8F DB 1F 10 386 128-bit Camellia key: 387 A1 BB 61 E8 05 F9 BA 6D DE 8F DB DD C0 5C DE A0 388 Ciphertext: 389 61 9F F0 72 E3 62 86 FF 0A 28 DE B3 A3 52 EC 0D 390 0E DF 5C 51 60 D6 63 C9 01 75 8C CF 9D 1E D3 3D 391 71 DB 8F 23 AA BF 83 48 A0 393 Plaintext: 13 bytes byte 394 Random confounder: 395 19 FE E4 0D 81 0C 52 4B 5B 22 F0 18 74 C6 93 DA 396 128-bit Camellia key: 397 2C A2 7A 5F AF 55 32 24 45 06 43 4E 1C EF 66 76 398 Ciphertext: 399 B8 EC A3 16 7A E6 31 55 12 E5 9F 98 A7 C5 00 20 400 5E 5F 63 FF 3B B3 89 AF 1C 41 A2 1D 64 0D 86 15 401 C9 ED 3F BE B0 5A B6 AC B6 76 89 B5 EA 403 Plaintext: 30 bytes bytes bytes bytes byt 404 Random confounder: 405 CA 7A 7A B4 BE 19 2D AB D6 03 50 6D B1 9C 39 E2 406 128-bit Camellia key: 407 78 24 F8 C1 6F 83 FF 35 4C 6B F7 51 5B 97 3F 43 408 Ciphertext: 409 A2 6A 39 05 A4 FF D5 81 6B 7B 1E 27 38 0D 08 09 410 0C 8E C1 F3 04 49 6E 1A BD CD 2B DC D1 DF FC 66 411 09 89 E1 17 A7 13 DD BB 57 A4 14 6C 15 87 CB A4 412 35 66 65 59 1D 22 40 28 2F 58 42 B1 05 A5 414 Plaintext: (empty) 415 Random confounder: 416 3C BB D2 B4 59 17 94 10 67 F9 65 99 BB 98 92 6C 417 256-bit Camellia key: 418 B6 1C 86 CC 4E 5D 27 57 54 5A D4 23 39 9F B7 03 419 1E CA B9 13 CB B9 00 BD 7A 3C 6D D8 BF 92 01 5B 420 Ciphertext: 421 03 88 6D 03 31 0B 47 A6 D8 F0 6D 7B 94 D1 DD 83 422 7E CC E3 15 EF 65 2A FF 62 08 59 D9 4A 25 92 66 424 Plaintext: 1 425 Random confounder: 426 DE F4 87 FC EB E6 DE 63 46 D4 DA 45 21 BB A2 D2 427 256-bit Camellia key: 428 1B 97 FE 0A 19 0E 20 21 EB 30 75 3E 1B 6E 1E 77 429 B0 75 4B 1D 68 46 10 35 58 64 10 49 63 46 38 33 430 Ciphertext: 431 2C 9C 15 70 13 3C 99 BF 6A 34 BC 1B 02 12 00 2F 432 D1 94 33 87 49 DB 41 35 49 7A 34 7C FC D9 D1 8A 433 12 435 Plaintext: 9 bytesss 436 Random confounder: 437 AD 4F F9 04 D3 4E 55 53 84 B1 41 00 FC 46 5F 88 438 256-bit Camellia key: 439 32 16 4C 5B 43 4D 1D 15 38 E4 CF D9 BE 80 40 FE 440 8C 4A C7 AC C4 B9 3D 33 14 D2 13 36 68 14 7A 05 441 Ciphertext: 442 9C 6D E7 5F 81 2D E7 ED 0D 28 B2 96 35 57 A1 15 443 64 09 98 27 5B 0A F5 15 27 09 91 3F F5 2A 2A 9C 444 8E 63 B8 72 F9 2E 64 C8 39 446 Plaintext: 13 bytes byte 447 Random confounder: 448 CF 9B CA 6D F1 14 4E 0C 0A F9 B8 F3 4C 90 D5 14 449 256-bit Camellia key: 450 B0 38 B1 32 CD 8E 06 61 22 67 FA B7 17 00 66 D8 451 8A EC CB A0 B7 44 BF C6 0D C8 9B CA 18 2D 07 15 452 Ciphertext: 453 EE EC 85 A9 81 3C DC 53 67 72 AB 9B 42 DE FC 57 454 06 F7 26 E9 75 DD E0 5A 87 EB 54 06 EA 32 4C A1 455 85 C9 98 6B 42 AA BE 79 4B 84 82 1B EE 457 Plaintext: 30 bytes bytes bytes bytes byt 458 Random confounder: 459 64 4D EF 38 DA 35 00 72 75 87 8D 21 68 55 E2 28 460 256-bit Camellia key: 461 CC FC D3 49 BF 4C 66 77 E8 6E 4B 02 B8 EA B9 24 462 A5 46 AC 73 1C F9 BF 69 89 B9 96 E7 D6 BF BB A7 463 Ciphertext: 464 0E 44 68 09 85 85 5F 2D 1F 18 12 52 9C A8 3B FD 465 8E 34 9D E6 FD 9A DA 0B AA A0 48 D6 8E 26 5F EB 466 F3 4A D1 25 5A 34 49 99 AD 37 14 68 87 A6 C6 84 467 57 31 AC 7F 46 37 6A 05 04 CD 06 57 14 74 469 Sample checksums: 471 Plaintext: abcdefghijk 472 Checksum type: cmac-camellia128 473 128-bit Camellia key: 474 1D C4 6A 8D 76 3F 4F 93 74 2B CB A3 38 75 76 C3 475 Key usage: 7 476 Checksum: 477 11 78 E6 C5 C4 7A 8C 1A E0 C4 B9 C7 D4 EB 7B 6B 479 Plaintext: ABCDEFGHIJKLMNOPQRSTUVWXYZ 480 Checksum type: cmac-camellia128 481 128-bit Camellia key: 482 50 27 BC 23 1D 0F 3A 9D 23 33 3F 1C A6 FD BE 7C 483 Key usage: 8 484 Checksum: 485 D1 B3 4F 70 04 A7 31 F2 3A 0C 00 BF 6C 3F 75 3A 487 Plaintext: 123456789 488 Checksum type: cmac-camellia256 489 256-bit Camellia key: 490 B6 1C 86 CC 4E 5D 27 57 54 5A D4 23 39 9F B7 03 491 1E CA B9 13 CB B9 00 BD 7A 3C 6D D8 BF 92 01 5B 492 Key usage: 9 493 Checksum: 494 87 A1 2C FD 2B 96 21 48 10 F0 1C 82 6E 77 44 B1 496 Plaintext: !@#$%^&*()!@#$%^&*()!@#$%^&*() 497 Checksum type: cmac-camellia256 498 256-bit Camellia key: 499 32 16 4C 5B 43 4D 1D 15 38 E4 CF D9 BE 80 40 FE 500 8C 4A C7 AC C4 B9 3D 33 14 D2 13 36 68 14 7A 05 501 Key usage: 10 502 Checksum: 503 3F A0 B4 23 55 E5 2B 18 91 87 29 4A A2 52 AB 64 505 12. References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of 511 the Camellia Encryption Algorithm", RFC 3713, April 2004. 513 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 514 Kerberos 5", RFC 3961, February 2005. 516 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 517 Encryption for Kerberos 5", RFC 3962, February 2005. 519 [SP800-38B] 520 Dworkin, M., "Recommendation for Block Cipher Modes of 521 Operation: The CMAC Mode for Authentication", NIST Special 522 Publication 800-38B, October 2009. 524 [SP800-108] 525 Chen, L., "Recommendation for Key Derivation Using 526 Pseudorandom Functions", NIST Special Publication 800-108, 527 October 2009. 529 [CRYPTOENG] 530 Schneier, B., "Cryptography Engineering", March 2010. 532 [CRYPTREC] 533 Information-technology Promotion Agency (IPA), 534 "Cryptography Research and Evaluation Committees", 535 . 537 [LNCS5867] 538 Mala, H., Shakiba, M., and M. Dakhil-alian, "New Results 539 on Impossible Different Cryptanalysis of Reduced Round 540 Camellia-128", LNCS 5867, November 2009, 541 . 543 [NESSIE] The NESSIE Project, "New European Schemes for Signatures, 544 Integrity, and Encryption", 545 . 547 Appendix A. Document History (REMOVE BEFORE PUBLICATION) 549 0: Renamed to include krbwg in title. Clarified specification of 550 cipher state. Added security considerations text and references 551 about the Camellia cipher. 553 1: Minor edit. 555 Appendix B. Notes to RFC Editor 557 Change the "TBD" entries in Section 8 to the values assigned by IANA. 559 Remove the above document history section. 561 Remove this section. 563 Author's Address 565 Greg Hudson (editor) 566 MIT Kerberos Consortium 568 Email: ghudson@mit.edu