idnits 2.17.1 draft-kato-ipsec-camellia-cmac96and128-05.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 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 21, 2009) is 5240 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 3713 (ref. '2') == Outdated reference: A later version (-11) exists of draft-ietf-ipsecme-ikev2bis-06 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Kato 3 Internet-Draft S. Kanno 4 Intended status: Standards Track NTT Software Corporation 5 Expires: June 24, 2010 M. Kanda 6 NTT 7 T. Iwata 8 Nagoya University 9 December 21, 2009 11 The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use 12 with IPsec 13 draft-kato-ipsec-camellia-cmac96and128-05 15 Abstract 17 This memo specifies two new algorithms for IPsec. One is the usage 18 of Cipher-based Message Authentication Code (CMAC) with the Camellia 19 block cipher as an authentication mechanism in the IPsec 20 Encapsulating Security Payload and Authentication Header protocols. 21 This algorithm is called Camellia-CMAC-96. The other algorithm is a 22 pseudo-random function (PRF) based on CMAC with the Camellia block 23 cipher for the Internet Key Exchange, version 2. This algorithm is 24 called Camellia-CMAC-PRF-128. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on June 24, 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 3. Camellia-CMAC . . . . . . . . . . . . . . . . . . . . . . . . 7 81 4. Camellia-CMAC-96 . . . . . . . . . . . . . . . . . . . . . . . 8 82 5. Camellia-CMAC-PRF-128 . . . . . . . . . . . . . . . . . . . . 9 83 6. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 6.1. Camellia-CMAC-96 . . . . . . . . . . . . . . . . . . . . . 11 85 6.2. Camellia-CMAC-PRF-128 . . . . . . . . . . . . . . . . . . 11 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 10.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 18 91 10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 The NIST specification [1] for the CMAC (Cipher-based Message 97 Authentication Code) mode of operation for a block cipher describes a 98 method to use the Advanced Encryption Standard (AES) as a Message 99 Authentication Code (MAC) that has a 128-bit output length. 101 The Camellia block cipher has the same external interface as the AES. 102 This memo specifies two new algorithms for IPsec that replace AES by 103 Camellia in already specified applications of CMAC for IPsec [8] and 104 [9]. One is the usage of CMAC mode with Camellia [2] as the 105 underlying block cipher as an authentication mechanism in the IPsec 106 Encapsulating Security Payload (ESP) [5] and Authentication Header 107 (AH) [4] protocols. This algorithm is called Camellia-CMAC-96. The 108 128-bit CMAC output is also useful as a long-lived Pseudo-Random 109 Function (PRF). Thus, the other algorithm is a PRF based on CMAC 110 with the Camellia block cipher for version 2 of the Internet Key 111 Exchange (IKEv2) [6] that supports fixed and variable key sizes for 112 the Key Derivation Function (KDF) and authentication, respectively. 113 This algorithm is called Camellia-CMAC-PRF-128. 115 The Camellia algorithm and its properties are described in [2]. This 116 document does not cover implementation details of CMAC. Those 117 details can be found in [1]. For further information on IKE, AH and 118 ESP, refer to [3], [4], [5], and [6]. 120 2. Definitions 122 CBC 123 Cipher Block Chaining mode of operation for a block cipher, 124 providing a block cipher for arbitrary message sizes. 126 MAC 127 Message Authentication Code. A bit string of a fixed 128 length, computed by the MAC generation algorithm, that is 129 used to establish the authority and, hence, the integrity 130 of a message. 132 CMAC 133 A MAC algorithm based on a symmetric key block cipher in 134 CBC mode, as specified in [1]. 136 Key (K) 137 128-bit (16-octet) key for the Camellia block cipher. 138 Denoted by K. 140 Variable-length Key (VK) 141 Variable-length key for Camellia-CMAC-PRF-128, denoted by 142 VK. 144 Message (M) 145 Message to be authenticated. Denoted by M. 147 Length (len) 148 The length of message M in octets. Denoted by len. The 149 minimum value is 0. The maximum value is not specified in 150 this document. 152 VKlen 153 The length of VK in octets. 155 truncate(T,l) 156 Truncate T (MAC) in most-significant-bit-first (MSB-first) 157 order to a length of l octets. 159 T 160 The output of Camellia-CMAC. 162 Camellia-CMAC 163 CMAC generation function based on the Camellia block cipher 164 with 128-bit key. 166 Camellia-CMAC-96 167 IPsec AH and ESP MAC generation function based on Camellia- 168 CMAC, which truncates the 128-bit CMAC output to its 96 169 most-significant bits. 171 Camellia-CMAC-PRF-128 172 IPsec AH and ESP PRF based on Camellia-CMAC, which removes 173 the 128-bit key length restriction. 175 SKEYSEED 176 Seed of shared key calculated from the nonces exchanged 177 during the IKE_SA_INIT exchange and the Diffie-Hellman 178 shared secret in the IKEv2 specification [6]. 180 3. Camellia-CMAC 182 The National Institute of Standards and Technology (NIST) has 183 specified the Cipher-based Message Authentication Code (CMAC) [1]. 184 CMAC is a keyed hash function that is based on a symmetric key block 185 cipher, such as the Advanced Encryption Standard [10]. The CMAC 186 algorithm provides a framework for inserting various block cipher 187 algorithms. 189 Camellia-CMAC uses the Camellia block cipher [2] as a building block 190 in CMAC [1]. To generate a MAC, Camellia-CMAC(K, M, len) takes a 191 secret key 'K', a message of variable length 'M', and the length of 192 the message in octets 'len' as inputs and returns a fixed-length bit 193 string. 195 In this specification, Camellia-CMAC is always used with 128-bit 196 length key. 198 4. Camellia-CMAC-96 200 For IPsec message authentication in AH and ESP, Camellia-CMAC is used 201 in its truncated form denoted as Camellia-CMAC-96 -- Camellia-CMAC 202 with its output truncated to 96 bits. Its output is a 96-bit MAC 203 that meets the default authenticator length as specified in [4]. The 204 result of truncation is taken in MSB-first order. 206 Figure 1 describes Camellia-CMAC-96 algorithm: 208 In step 1, Camellia-CMAC with key K is applied to the message M of 209 length len octets. 211 In step 2, the output of step 1 is truncated to its first 12 octets, 212 and the result (TT) is returned. 214 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 215 + Algorithm Camellia-CMAC-96 + 216 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 217 + + 218 + Input : K (128-bit Key) + 219 + : M (message to be authenticated) + 220 + : len (length of message in octets) + 221 + Output : Truncated T (truncated output to length 12 octets) + 222 + + 223 +-------------------------------------------------------------------+ 224 + + 225 + Step 1. T := Camellia-CMAC (K,M,len); + 226 + Step 2. TT := truncate (T, 12); + 227 + return TT; + 228 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 230 Figure 1: Algorithm Camellia-CMAC-96 232 5. Camellia-CMAC-PRF-128 234 The Camellia-CMAC-PRF-128 algorithm is identical to Camellia-CMAC 235 except that the 128-bit key length restriction is removed. 237 IKEv2 [6] uses PRFs for multiple purposes, most notably for 238 generating keying material and authentication of the IKE_SA. 240 When using Camellia-CMAC-PRF-128 as the PRF described in [6], 241 Camellia-CMAC-PRF-128 is considered to admit a variable key length in 242 all places, and the amount of keying material generated when new keys 243 are generated is 128 bits (i.e., preferred key length when generating 244 keying material of SK_d, SK_pi, and SK_pr is 128 bits). 246 When generating SKEYSEED the full of Ni and Nr are used as key for 247 the PRF. 249 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 250 + Camellia-CMAC-PRF-128 + 251 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 252 + + 253 + Input : VK (Variable-length key) + 254 + : M (Message, i.e., the input data of the PRF) + 255 + : VKlen (length of VK in octets) + 256 + : len (length of M in octets) + 257 + Output : PRV (128-bit Pseudo-Random Variable) + 258 + + 259 +-------------------------------------------------------------------+ 260 + Variable: K (128-bit key for Camellia-CMAC) + 261 + + 262 + Step 1. If VKlen is equal to 16 + 263 + Step 1a. then + 264 + K := VK; + 265 + Step 1b. else + 266 + K := Camellia-CMAC(0^128, VK, VKlen); + 267 + Step 2. PRV := Camellia-CMAC(K, M, len); + 268 + return PRV; + 269 + + 270 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 272 Figure 2: Algorithm Camellia-CMAC-PRF-128 274 In step 1, the 128-bit key, K, for Camellia-CMAC is derived as 275 follows: 277 o If the key VK is exactly 128 bits, then we use it as-is (step 1a). 279 o If it is longer or shorter than 128 bits, then we derive the key K 280 by applying the Camellia-CMAC algorithm using the 128-bit all-zero 281 string as the key and VK as the input message (step 1b). 283 In step 2, we apply the Camellia-CMAC algorithm using K as the key 284 and M as the input message. The output of this algorithm is 285 returned. 287 6. Test Cases 289 6.1. Camellia-CMAC-96 291 This section contains four test cases, which can be used to confirm 292 that an implementation has correctly implemented Camellia-CMAC-96. 294 ---------------- 295 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 297 Mlen = 0 298 M 299 T ba925782 aaa1f5d9 a00f8964 301 ---------------- 302 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 304 Mlen = 16 305 M 6bc1bee2 2e409f96 e93d7e11 7393172a 306 T 6d962854 a3b9fda5 6d7d45a9 308 ---------------- 309 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 311 Mlen = 40 312 M 6bc1bee2 2e409f96 e93d7e11 7393172a 313 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 314 30c81c46 a35ce411 315 T 5c18d119 ccd67661 44ac1866 317 ---------------- 318 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 320 Mlen = 64 321 M 6bc1bee2 2e409f96 e93d7e11 7393172a 322 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 323 30c81c46 a35ce411 e5fbc119 1a0a52ef 324 f69f2445 df4f9b17 ad2b417b e66c3710 325 T c2699a6e ba55ce9d 939a8a4e 327 6.2. Camellia-CMAC-PRF-128 329 This section contains twelve test cases, which can be used to confirm 330 that an implementation has correctly implemented Camellia-CMAC-PRF- 331 128. The first four test cases use 128 bit VK; the next four test 332 cases use 192 bit VK; and the last four test cases use 256 bit VK. 334 VKlen = 16 335 ---------------- 336 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 338 Mlen = 0 339 M 340 T ba925782 aaa1f5d9 a00f8964 8094fc71 342 ---------------- 343 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 345 Mlen = 16 346 M 6bc1bee2 2e409f96 e93d7e11 7393172a 347 T 6d962854 a3b9fda5 6d7d45a9 5ee17993 349 ---------------- 350 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 352 Mlen = 40 353 M 6bc1bee2 2e409f96 e93d7e11 7393172a 354 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 355 30c81c46 a35ce411 356 T 5c18d119 ccd67661 44ac1866 131d9f22 358 ---------------- 359 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 361 Mlen = 64 362 M 6bc1bee2 2e409f96 e93d7e11 7393172a 363 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 364 30c81c46 a35ce411 e5fbc119 1a0a52ef 365 f69f2445 df4f9b17 ad2b417b e66c3710 366 T c2699a6e ba55ce9d 939a8a4e 19466ee9 368 ------------------------------------------------------------ 369 VKlen = 24 370 ---------------- 371 VK 8e73b0f7 da0e6452 c810f32b 809079e5 372 62f8ead2 522c6b7b 374 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 376 Mlen = 0 377 M 378 T f4739892 c70bd23e 891f66c0 5fefbf27 380 ---------------- 381 VK 8e73b0f7 da0e6452 c810f32b 809079e5 382 62f8ead2 522c6b7b 384 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 386 Mlen = 16 387 M 6bc1bee2 2e409f96 e93d7e11 7393172a 388 T 60a33814 53babaed 1a11dfd3 d24c1410 390 ---------------- 391 VK 8e73b0f7 da0e6452 c810f32b 809079e5 392 62f8ead2 522c6b7b 394 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 396 Mlen = 40 397 M 6bc1bee2 2e409f96 e93d7e11 7393172a 398 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 399 30c81c46 a35ce411 400 T 42b9d47f 4f58bc29 85b6f82c 23b121cb 402 ---------------- 403 VK 8e73b0f7 da0e6452 c810f32b 809079e5 404 62f8ead2 522c6b7b 406 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 408 Mlen = 64 409 M 6bc1bee2 2e409f96 e93d7e11 7393172a 410 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 411 30c81c46 a35ce411 e5fbc119 1a0a52ef 412 f69f2445 df4f9b17 ad2b417b e66c3710 413 T d078729f dcae9abc ff1ea4d6 18ed4501 415 ------------------------------------------------------------ 416 VKlen = 32 417 ---------------- 418 VK 603deb10 15ca71be 2b73aef0 857d7781 419 1f352c07 3b6108d7 2d9810a3 0914dff4 421 K b5aeeae9 2c23bed7 167af194 2e831597 423 Mlen = 0 424 M 425 T c96d7d40 d4aaab78 ac906b91 c82bd690 426 ---------------- 427 VK 603deb10 15ca71be 2b73aef0 857d7781 428 1f352c07 3b6108d7 2d9810a3 0914dff4 430 K b5aeeae9 2c23bed7 167af194 2e831597 432 Mlen = 16 433 M 6bc1bee2 2e409f96 e93d7e11 7393172a 434 T 104de4b9 0da6baf1 fa73945b e614f032 436 ---------------- 437 VK 603deb10 15ca71be 2b73aef0 857d7781 438 1f352c07 3b6108d7 2d9810a3 0914dff4 440 K b5aeeae9 2c23bed7 167af194 2e831597 442 Mlen = 40 443 M 6bc1bee2 2e409f96 e93d7e11 7393172a 444 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 445 30c81c46 a35ce411 446 T 2d3684e9 1cb1b303 a7db8648 f25ee16c 448 ---------------- 449 VK 603deb10 15ca71be 2b73aef0 857d7781 450 1f352c07 3b6108d7 2d9810a3 0914dff4 452 K b5aeeae9 2c23bed7 167af194 2e831597 454 Mlen = 64 455 M 6bc1bee2 2e409f96 e93d7e11 7393172a 456 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 457 30c81c46 a35ce411 e5fbc119 1a0a52ef 458 f69f2445 df4f9b17 ad2b417b e66c3710 459 T d6b0f1b7 dda2b62a eca6d51d da63fdda 461 7. Security Considerations 463 The security provided by Camellia-CMAC-96 and Camellia-CMAC-PRF-128 464 is built on the strong cryptographic algorithm Camellia and CMAC. At 465 the time of this writing, there are no known practical cryptographic 466 attacks against Camellia or CMAC. 468 However, as is true with any cryptographic algorithm, part of its 469 strength lies in the secret key, K, and the correctness of the 470 implementation in all of the participating systems. If the secret 471 key is compromised or inappropriately shared, it guarantees neither 472 authentication nor message integrity at all. The secret key shall be 473 generated in a way that meets the pseudo randomness requirement of 474 RFC 4086 [7] and should be kept safe. If and only if 475 Camellia-CMAC-96 and Camellia-CMAC-PRF-128 are used properly it 476 provides the authentication and integrity that meet the best current 477 practice of message authentication. 479 8. IANA Considerations 481 The IANA has allocated value for IKEv2 Transform Type 3 482 (Integrity Algorithm) to the AUTH_CAMELLIA_CMAC_96 algorithm, and has 483 allocated a value of for IKEv2 Transform Type 2 (Pseudo-Random 484 Function) to the PRF_CAMELLIA128_CMAC algorithm. 486 9. Acknowledgements 488 We thank Tim Polk and Tero Kivinen for their initial review of this 489 document. Special thanks to Alfred Hoenes for several very detailed 490 reviews and suggestions. 492 10. References 494 10.1. Normative 496 [1] National Institute of Standards and Technology, "Recommendation 497 for Block Cipher Modes of Operation:The CMAC Mode for 498 Authentication", Special Publication 800-38B, May 2005. 500 [2] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the 501 Camellia Encryption Algorithm", RFC 3713, April 2004. 503 10.2. Informative 505 [3] Kent, S. and K. Seo, "Security Architecture for the Internet 506 Protocol", RFC 4301, December 2005. 508 [4] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 510 [5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 511 December 2005. 513 [6] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key 514 Exchange Protocol: IKEv2", draft-ietf-ipsecme-ikev2bis-06 (work 515 in progress), December 2009. 517 [7] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 518 Requirements for Security", BCP 106, RFC 4086, June 2005. 520 [8] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 521 Algorithm and Its Use with IPsec", RFC 4494, June 2006. 523 [9] Gustin, J. and A. Goyens, "A Uniform Resource Name (URN) 524 Namespace for SWIFT Financial Messaging", RFC 3615, 525 September 2003. 527 [10] National Institute of Standards and Technology, "Advanced 528 Encryption Standard (AES)", FIPS PUB 197, November 2001, 529 . 531 Authors' Addresses 533 Akihiro Kato 534 NTT Software Corporation 536 Phone: +81-45-212-9803 537 Fax: +81-45-212-9800 538 Email: kato.akihiro@po.ntts.co.jp 540 Satoru Kanno 541 NTT Software Corporation 543 Phone: +81-45-212-9803 544 Fax: +81-45-212-9800 545 Email: kanno.satoru@po.ntts.co.jp 547 Masayuki Kanda 548 NTT 550 Phone: +81-422-59-3456 551 Fax: +81-422-59-4015 552 Email: kanda.masayuki@lab.ntt.co.jp 554 Tetsu Iwata 555 Nagoya University 557 Email: iwata@cse.nagoya-u.ac.jp