idnits 2.17.1 draft-kato-ipsec-camellia-cmac96and128-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (September 9, 2009) is 5336 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. '3') -- Obsolete informational reference (is this intentional?): RFC 2411 (ref. '4') (Obsoleted by RFC 6071) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 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: March 13, 2010 M. Kanda 6 NTT 7 T. Iwata 8 Nagoya University 9 September 9, 2009 11 The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use 12 with IPsec 13 draft-kato-ipsec-camellia-cmac96and128-04 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on March 13, 2010. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This memo specifies two new algorithms. One is the usage of Cipher- 61 based Message Authentication Code (CMAC) with Camellia block cipher 62 on the authentication mechanism of the IPsec Encapsulating Security 63 Payload and Authentication Header protocols. This algorithm is 64 called Camellia-CMAC-96. Latter is pseudo-random function based on 65 CMAC with Camellia block cipher for Internet Key Exchange. This 66 algorithm is called Camellia-CMAC-PRF-128. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Camellia-CMAC . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4. Camellia-CMAC-96 . . . . . . . . . . . . . . . . . . . . . . . 8 75 5. Camellia-CMAC-PRF-128 . . . . . . . . . . . . . . . . . . . . 9 76 6. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 6.1. Camellia-CMAC-96 . . . . . . . . . . . . . . . . . . . . . 11 78 6.2. Camellia-CMAC-PRF-128 . . . . . . . . . . . . . . . . . . 11 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 10.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 18 84 10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 This memo specifies two new algorithms. One is the usage of CMAC 90 based on Camellia block cipher on the authentication mechanism of the 91 IPsec Encapsulating Security Payload (ESP) [6] and Authentication 92 Header protocols (AH) [5]. This algorithm is called 93 Camellia-CMAC-96. Latter is Pseudo-Random Function (PRF) based on 94 CMAC with Camellia block cipher for Internet Key Exchange (IKEv2) 95 [7]. This algorithm is called Camellia-CMAC-PRF-128. 97 The algorithm specification and object identifiers are described in 98 [3]. 100 This document specifies the usage of CMAC with Camellia Block cipher 101 on the authentication mechanism of the IPsec Encapsulating Security 102 Payload [6] and Authentication Header [5] protocols. This new 103 algorithm is named Camellia-CMAC-96. 105 NIST CMAC specification document [1] describes a method to use the 106 Advanced Encryption Standard (AES) as a Message Authentication Code 107 (MAC) that has a 128-bit output length. The 128-bit output is useful 108 as a long-lived PRF. This document also specifies a PRF based on 109 CMAC with Camellia block cipher that supports fixed and variable key 110 sizes for IKEv2 [7] Key Derivation Function (KDF) and authentication. 111 This new algorithm is named Camellia-CMAC-PRF-128. For further 112 information on IKE, AH and ESP, refer to [7], [5], [6], and [4]. 114 This document does not cover implementation details of CMAC. Those 115 details can be found in [1]. 117 1.1. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [2]. 123 2. Definitions 125 CBC 126 Cipher Block Chaining mode of operation for message 127 authentication code. 129 MAC 130 Message Authentication Code. A bit string of a fixed 131 length, computed by the MAC generation algorithm, that is 132 used to establish the authority and, hence, the integrity 133 of a message. 135 CMAC 136 Cipher-based MAC based on a symmetric key block cipher. 138 Key (K) 139 128-bit (16-octet) key for Camellia cipher block. Denoted 140 by K. 142 Variable-length Key (VK) 143 Variable-length key for Camellia-CMAC-PRF-128, denoted by 144 VK. 146 Message (M) 147 Message to be authenticated. Denoted by M. 149 Length (len) 150 The length of message M in octets. Denoted by len. The 151 minimum value is 0. The maximum value is not specified in 152 this document. 154 VKlen 155 The length of VK in octets. 157 truncate(T,l) 158 Truncate T (MAC) in most-significant-bit-first (MSB-first) 159 order to a length of l octets. 161 T 162 The output of Camellia-CMAC. 164 Camellia-CMAC 165 CMAC generation function based on Camellia block cipher 166 with 128-bit key. 168 Camellia-CMAC-96 169 IPsec AH and ESP MAC generation function based on Camellia- 170 CMAC, which truncates the 96 most significant bits of the 171 128-bit output. 173 Camellia-CMAC-PRF-128 174 IPsec AH and ESP PRF based on Camellia-CMAC, which removes 175 128-bit key length restriction. 177 SKEYSEED Seed of shared key calculated from the nonces exchanged 178 during the IKE_SA_INIT exchange and the Diffie-Hellman 179 shared secret in IKEv2 specification. 181 3. Camellia-CMAC 183 The National Institute of Standards and Technology (NIST) has 184 recently specified the Cipher-based Message Authentication Code 185 (CMAC). CMAC [1] is a keyed hash function that is based on a 186 symmetric key block cipher, such as the Advanced Encryption Standard 187 [9]. The CMAC algorithm provides a framework for inserting various 188 block cipher algorithm. 190 Camellia-CMAC uses the Camellia block cipher [3] as a building block 191 in CMAC [1]. To generate a MAC, Camellia-CMAC(K, M, len) takes a 192 secret key 'K', a message of variable length 'M', and the length of 193 the message in octets 'len' as inputs and returns a fixed-bit 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 on AH and ESP, Camellia-CMAC-96 MAY 201 be used. Camellia-CMAC-96 is a Camellia-CMAC with 96-bit truncated 202 output in MSB-first order. The output is a 96-bit MAC that will meet 203 the default authenticator length as specified in [5]. The result of 204 truncation is taken in MSB-first order. 206 Figure 1 describes Camellia-CMAC-96 algorithm: 208 In step 1, Camellia-CMAC is applied to the message M in length len 209 with key K. 211 In step 2, the output block T is truncated to 12 octets in MSB-first 212 order, and Truncated T (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 [7] 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 IKEv2, 241 Camellia-CMAC-PRF-128 is considered to take variable key length in 242 all places, and the number of bits of keying material generated when 243 new keys are generated is 128 bits (i.e. preferred key length when 244 generating 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. 279 o If it is longer or shorter than 128 bits, then we derive the key, 280 K, by applying the Camellia-CMAC algorithm using the 128-bit all- 281 zero string as the key and VK as the input message. This step is 282 described in step 1b. 284 In step 2, we apply the Camellia-CMAC algorithm using K as the key 285 and M as the input message. The output of this algorithm is 286 returned. 288 6. Test Vectors 290 6.1. Camellia-CMAC-96 292 This section contains four test vectors(TV), which can be used to 293 confirm that an implementation has correctly implemented Camellia- 294 CMAC-96. 296 ---------------- 297 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 299 Mlen = 0 300 M 301 T ba925782 aaa1f5d9 a00f8964 303 ---------------- 304 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 306 Mlen = 16 307 M 6bc1bee2 2e409f96 e93d7e11 7393172a 308 T 6d962854 a3b9fda5 6d7d45a9 310 ---------------- 311 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 313 Mlen = 40 314 M 6bc1bee2 2e409f96 e93d7e11 7393172a 315 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 316 30c81c46 a35ce411 317 T 5c18d119 ccd67661 44ac1866 319 ---------------- 320 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 322 Mlen = 64 323 M 6bc1bee2 2e409f96 e93d7e11 7393172a 324 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 325 30c81c46 a35ce411 e5fbc119 1a0a52ef 326 f69f2445 df4f9b17 ad2b417b e66c3710 327 T c2699a6e ba55ce9d 939a8a4e 329 6.2. Camellia-CMAC-PRF-128 331 This section contains twelve test vectors(TV), which can be used to 332 confirm that an implementation has correctly implemented Camellia- 333 CMAC-PRF-128. The first four test vectors use 128 bit VK; the next 334 four test vectors use 192 bit VK; and the last four test vectors use 335 256 bit VK. 337 VKlen = 16 338 ---------------- 339 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 341 Mlen = 0 342 M 343 T ba925782 aaa1f5d9 a00f8964 8094fc71 345 ---------------- 346 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 348 Mlen = 16 349 M 6bc1bee2 2e409f96 e93d7e11 7393172a 350 T 6d962854 a3b9fda5 6d7d45a9 5ee17993 352 ---------------- 353 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 355 Mlen = 40 356 M 6bc1bee2 2e409f96 e93d7e11 7393172a 357 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 358 30c81c46 a35ce411 359 T 5c18d119 ccd67661 44ac1866 131d9f22 361 ---------------- 362 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 364 Mlen = 64 365 M 6bc1bee2 2e409f96 e93d7e11 7393172a 366 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 367 30c81c46 a35ce411 e5fbc119 1a0a52ef 368 f69f2445 df4f9b17 ad2b417b e66c3710 369 T c2699a6e ba55ce9d 939a8a4e 19466ee9 371 ------------------------------------------------------------ 372 VKlen = 24 373 ---------------- 374 VK 8e73b0f7 da0e6452 c810f32b 809079e5 375 62f8ead2 522c6b7b 377 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 378 Mlen = 0 379 M 380 T f4739892 c70bd23e 891f66c0 5fefbf27 382 ---------------- 383 VK 8e73b0f7 da0e6452 c810f32b 809079e5 384 62f8ead2 522c6b7b 386 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 388 Mlen = 16 389 M 6bc1bee2 2e409f96 e93d7e11 7393172a 390 T 60a33814 53babaed 1a11dfd3 d24c1410 392 ---------------- 393 VK 8e73b0f7 da0e6452 c810f32b 809079e5 394 62f8ead2 522c6b7b 396 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 398 Mlen = 40 399 M 6bc1bee2 2e409f96 e93d7e11 7393172a 400 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 401 30c81c46 a35ce411 402 T 42b9d47f 4f58bc29 85b6f82c 23b121cb 404 ---------------- 405 VK 8e73b0f7 da0e6452 c810f32b 809079e5 406 62f8ead2 522c6b7b 408 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 410 Mlen = 64 411 M 6bc1bee2 2e409f96 e93d7e11 7393172a 412 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 413 30c81c46 a35ce411 e5fbc119 1a0a52ef 414 f69f2445 df4f9b17 ad2b417b e66c3710 415 T d078729f dcae9abc ff1ea4d6 18ed4501 417 ------------------------------------------------------------ 418 VKlen = 32 419 ---------------- 420 VK 603deb10 15ca71be 2b73aef0 857d7781 421 1f352c07 3b6108d7 2d9810a3 0914dff4 423 K b5aeeae9 2c23bed7 167af194 2e831597 425 Mlen = 0 426 M 427 T c96d7d40 d4aaab78 ac906b91 c82bd690 429 ---------------- 430 VK 603deb10 15ca71be 2b73aef0 857d7781 431 1f352c07 3b6108d7 2d9810a3 0914dff4 433 K b5aeeae9 2c23bed7 167af194 2e831597 435 Mlen = 16 436 M 6bc1bee2 2e409f96 e93d7e11 7393172a 437 T 104de4b9 0da6baf1 fa73945b e614f032 439 ---------------- 440 VK 603deb10 15ca71be 2b73aef0 857d7781 441 1f352c07 3b6108d7 2d9810a3 0914dff4 443 K b5aeeae9 2c23bed7 167af194 2e831597 445 Mlen = 40 446 M 6bc1bee2 2e409f96 e93d7e11 7393172a 447 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 448 30c81c46 a35ce411 449 T 2d3684e9 1cb1b303 a7db8648 f25ee16c 451 ---------------- 452 VK 603deb10 15ca71be 2b73aef0 857d7781 453 1f352c07 3b6108d7 2d9810a3 0914dff4 455 K b5aeeae9 2c23bed7 167af194 2e831597 457 Mlen = 64 458 M 6bc1bee2 2e409f96 e93d7e11 7393172a 459 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 460 30c81c46 a35ce411 e5fbc119 1a0a52ef 461 f69f2445 df4f9b17 ad2b417b e66c3710 462 T d6b0f1b7 dda2b62a eca6d51d da63fdda 464 7. Security Considerations 466 The security provided by Camellia-CMAC-96 Camellia-CMAC-PRF-128 is 467 built on the strong cryptographic algorithm Camellia and CMAC. At 468 the time of this writing, there are no known practical cryptographic 469 attacks against Camellia or CMAC. 471 However, as is true with any cryptographic algorithm, part of its 472 strength lies in the secret key, K, and the correctness of the 473 implementation in all of the participating systems. If the secret 474 key is compromised or inappropriately shared, it guarantees neither 475 authentication nor integrity of message at all. The secret key shall 476 be generated in a way that meets the pseudo randomness requirement of 477 RFC 4086 [8] and should be kept safe. If and only if 478 Camellia-CMAC-96 Camellia-CMAC-PRF-128 are used properly it provides 479 the authentication and integrity that meet the best current practice 480 of message authentication. 482 8. IANA Considerations 484 The IANA has allocated value for IKEv2 Transform Type 3 485 (Integrity Algorithm) to the AUTH_CAMELLIA_CMAC_96 algorithm, and has 486 allocated a value of for IKEv2 Transform Type 2 (Pseudo-Random 487 Function) to the PRF_CAMELLIA128_CMAC algorithm. 489 9. Acknowledgements 491 We thank Tim Polk and Tero Kivinen for their initial review of this 492 document. 494 10. References 496 10.1. Normative 498 [1] National Institute of Standards and Technology, "Recommendation 499 for Block Cipher Modes of Operation:The CMAC Mode for 500 Authentication", Special Publication 800-38B, May 2005. 502 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 503 Levels", BCP 14, RFC 2119, March 1997. 505 [3] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the 506 Camellia Encryption Algorithm", RFC 3713, April 2004. 508 10.2. Informative 510 [4] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document 511 Roadmap", RFC 2411, November 1998. 513 [5] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 515 [6] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 516 December 2005. 518 [7] Kaufman, C., Hoffman, P., and P. Eronen, "Internet Key Exchange 519 Protocol: IKEv2", draft-hoffman-ikev2bis-03 (work in progress), 520 February 2008. 522 [8] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 523 Requirements for Security", BCP 106, RFC 4086, June 2005. 525 [9] National Institute of Standards and Technology, "Advanced 526 Encryption Standard (AES)", FIPS PUB 197, November 2001, 527 . 529 Authors' Addresses 531 Akihiro Kato 532 NTT Software Corporation 534 Phone: +81-45-212-7577 535 Fax: +81-45-212-9800 536 Email: kato.akihiro@po.ntts.co.jp 538 Satoru Kanno 539 NTT Software Corporation 541 Phone: +81-45-212-7577 542 Fax: +81-45-212-9800 543 Email: kanno.satoru@po.ntts.co.jp 545 Masayuki Kanda 546 NTT 548 Phone: +81-422-59-3456 549 Fax: +81-422-59-4015 550 Email: kanda.masayuki@lab.ntt.co.jp 552 Tetsu Iwata 553 Nagoya University 555 Email: iwata@cse.nagoya-u.ac.jp