idnits 2.17.1 draft-kato-ipsec-camellia-cmac96and128-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 507. 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 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2007) is 6270 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) == Unused Reference: '9' is defined on line 395, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 412, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 4306 (ref. '5') (Obsoleted by RFC 5996) ** Downref: Normative reference to an Informational RFC: RFC 4493 (ref. '6') ** Obsolete normative reference: RFC 2411 (ref. '7') (Obsoleted by RFC 6071) ** Downref: Normative reference to an Informational RFC: RFC 3713 (ref. '8') -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '9') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4051 (ref. '11') (Obsoleted by RFC 6931) -- Obsolete informational reference (is this intentional?): RFC 4132 (ref. '13') (Obsoleted by RFC 5932) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Kato 3 Internet-Draft NTT Software Corporation 4 Intended status: Standards Track M. Kanda 5 Expires: August 29, 2007 Nippon Telegraph and Telephone 6 Corporation 7 T. Iwata 8 Nagoya University 9 February 25, 2007 11 The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use 12 with IPsec 13 draft-kato-ipsec-camellia-cmac96and128-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 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 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 29, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This memo specifies two new alogorithms. One is the usage of Cipher- 47 based Message Authentication Code (CMAC) with Camellia block cipher 48 on the authentication mechanism of the IPsec Encapsulating Security 49 Payload and Authentication Header protocols. This algoritm is called 50 Camellia-CMAC-96. Latter is a pseudo-random function based on CMAC 51 with Camellia block cipher for Internet Key Exchange. This algoritm 52 is called Camellia-CMAC-PRF-128. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Camellia-CMAC and Camellia128-CMAC . . . . . . . . . . . . . . 7 60 4. Camellia-CMAC-96 . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Camellia-CMAC-PRF-128 . . . . . . . . . . . . . . . . . . . . 9 62 6. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 10.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 15 68 10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 15 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 70 Intellectual Property and Copyright Statements . . . . . . . . . . 19 72 1. Introduction 74 This memo specifies two new alogorithms. One is the usage of CMAC 75 based on Camellia block cipher on the authentication mechanism of the 76 IPsec Encapsulating Security Payload (ESP) [4] and Authentication 77 Header protocols (AH) [3]. This algorithm is called 78 Camellia-CMAC-96. Latter is a Pseudo-Random Function (PRF) based on 79 CMAC with Camellia block cipher for Internet Key Exchange (IKE) [5]. 80 This algoritm is called Camellia-CMAC-PRF-128. 82 Camellia is a symmetric cipher with a Feistel structure. Camellia 83 was developed jointly by NTT and Mitsubishi Electric Corporation in 84 2000. It was designed to withstand all known cryptanalytic attacks, 85 and it has been scrutinized by worldwide cryptographic experts. 86 Camellia is suitable for implementation in software and hardware, 87 offering encryption speed in software and hardware implementations 88 that is comparable to Advanced Encryption Standard (AES) [18]. 90 Camellia supports 128-bit block size and 128-, 192-, and 256-bit key 91 lengths, i.e., the same interface specifications as the AES. 92 Therefore it is easy to implement Camellia-CMAC by replacing AES 93 block of AES-CMAC to Camellia. 95 Camellia is adopted as IETF and several international standardization 96 organizations. Camellia is already adopted as IPSec [15], TLS [13], 97 S/MIME [10] and XML [11]. Camellia is adopted for the one of three 98 ISO/IEC international standard cipher [21] as 128-bit block cipher 99 (Camellia AES and SEED). Camellia was selected as a recommended 100 cryptographic primitive by the EU NESSIE (New European Schemes for 101 Signatures, Integrity and Encryption) project [19] and was included 102 in the list of cryptographic techniques for Japanese e-Government 103 systems that was selected by the Japan CRYPTREC (Cryptography 104 Research and Evaluation Committees) [20]. 106 Since optimized source code is provided by several open source 107 lisences [22], Camellia is also adopted by several open source 108 projects. Camellia is already adopted by Openssl. Additional API 109 for Network Security Services (NSS) and IPsec stack of Linux and Free 110 BSD are prepared or working progress for release. 112 The algorithm specification and object identifiers are described in 113 [8]. 115 The Camellia homepage [23] contains a wealth of information about 116 Camellia, including detailed specification, security analysis, 117 performance figures, reference implementation, optimized 118 implementetion, test vectors, and intellectual property information. 120 This document specifies the usage of CMAC with Camellia Block cipher 121 on the authentication mechanism of the IPsec Encapsulating Security 122 Payload [4] and Authentication Header [3] protocols. This new 123 algorithm is named Camellia-CMAC-96. 125 NIST CMAC specification document [1] describes a method to use the 126 Advanced Encryption Standard (AES) as a Message Authentication Code 127 (MAC) that has a 128-bit output length. The 128-bit output is useful 128 as a long-lived pseudo-random function (PRF). This document also 129 specifies a PRF based on CMAC with Camellia block cipher that 130 supports fixed and variable key sizes for IKEv2 [5] Key Derivation 131 Function (KDF) and authentication. This new alogrithm is named 132 Camellia-CMAC-PRF-128. For further information on IKE, AH and ESP, 133 refer to [5], [3], [4] and [7]. 135 This document does not cover implementation details of CMAC. Those 136 details can be found in [1]. 138 1.1. Terminology 140 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that 142 appear in this document are to be interpreted as described in [2]. 144 2. Definitions 146 CBC 147 Cipher Block Chaining mode of operation for message 148 authentication code. 150 MAC 151 Message Authentication Code. A bit string of a fixed 152 length, computed by the MAC generation algorithm, that is 153 used to establish the authority and, hence, the integrity 154 of a message. 156 CMAC 157 Cipher-based MAC based on a symmetric key block cipher. 159 Key (K) 160 128-bit (16-octet) key for Camellia. Denoted by K. 162 Variable-length Key (VK) 163 Variable-length key for Camellia-CMAC-PRF-128, denoted by 164 VK. 166 Message (M) 167 Message to be authenticated. Denoted by M. 169 Length (len) 170 The length of message M in octets. Denoted by len. The 171 minimum value is 0. The maximum value is not specified in 172 this document. 174 VKlen 175 The length of VK in octets. 177 truncate(T,l) 178 Truncate T (MAC) in most-significant-bit-first (MSB-first) 179 order to a length of l octets. 181 T 182 The output of Camellia128-CMAC. 184 Truncated T 185 The truncated output of Camellia128-CMAC in MSB-first 186 order. 188 Camellia128-CMAC 189 The CMAC generation function based on Camellia block cipher 190 with 128-bit key. 192 Camellia-CMAC-96 193 IPsec AH and ESP MAC generation function based on 194 Camellia128-CMAC, which truncates the 96 most significant 195 bits of the 128-bit output. 197 Camellia-CMAC-PRF-128 198 IPsec AH and ESP PRF based on Camellia128-CMAC, which 199 removes 128-bit key length restriction. 201 3. Camellia-CMAC and Camellia128-CMAC 203 The National Institute of Standards and Technology (NIST) specified 204 the Cipher-based Message Authentication Code (CMAC) [1]. CMAC is a 205 keyed hash function that is based on a symmetric key block cipher, 206 such as the Advanced Encryption Standard [18]. The CMAC algorithm 207 provides a framework for inserting various block cipher algorithm. 209 Camellia-CMAC uses the Camellia block cipher [8] as a building block 210 in CMAC [1]. To generate a MAC, Camellia-CMAC takes a secret key, a 211 message of variable length, and the length of the message in octets 212 as inputs and returns a fixed-bit string. 214 Camellia-CMAC provides stronger assurance of data integrity than a 215 checksum or an error detecting code, as well as AES-CMAC. The output 216 of Camellia-CMAC can validate the input message. Validating the 217 message provides assurance of the integrity and authenticity over the 218 message from the source. 220 Hereafter, we define Camellia128-CMAC as special case of Camellia- 221 CMAC that allows only a 128-bit secret key. Therefore, Camellia128- 222 CMAC takes a secret key, a message of variable length, and the length 223 of the message in octets as inputs. Camellia128-CMAC is the 224 identical algorithm which is replacing AES-128 in Figure 2.3 of [6] 225 to Camellia with 128-bit key. 227 4. Camellia-CMAC-96 229 For IPsec message authentication on AH and ESP, Camellia-CMAC-96 MAY 230 be used. Camellia-CMAC-96 is a Camellia128-CMAC, defined in 231 Section 3, with 96-bit truncated output in MSB-first order. The 232 output is a 96-bit MAC that will meet the default authenticator 233 length as specified in [3]. The result of truncation is taken in 234 MSB-first order. 236 Figure 1 describes Camellia-CMAC-96 algorithm: 238 In step 1, Camellia128-CMAC is applied to the message M in length len 239 with key K. 241 In step 2, the output block T is truncated to 12 octets in MSB-first 242 order, and Truncated T (TT) is returned. 244 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 245 + Algorithm Camellia-CMAC-96 + 246 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 247 + + 248 + Input : K (128-bit Key) + 249 + : M (message to be authenticated) + 250 + : len (length of message in octets) + 251 + Output : Truncated T (truncated output to length 12 octets) + 252 + + 253 +-------------------------------------------------------------------+ 254 + + 255 + Step 1. T := Camellia128-CMAC (K,M,len); + 256 + Step 2. TT := truncate (T, 12); + 257 + return TT; + 258 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 260 Figure 1: Algorithm Camellia-CMAC-96 262 5. Camellia-CMAC-PRF-128 264 The Camellia-CMAC-PRF-128 algorithm is identical to Camellia128-CMAC, 265 defined in Section 3, except that the 128-bit key length restriction 266 is removed. 268 IKEv2 [5] uses PRFs for multiple purposes, most notably for 269 generating keying material and authentication of the IKE_SA. The 270 IKEv2 specification differentiates between PRFs with fixed key sizes 271 and those with variable key sizes. 273 When using Camellia-CMAC-PRF-128 as the PRF described in IKEv2, 274 Camellia-CMAC-PRF-128 is considered to take fixed size (16 octets) 275 keys for generating keying material but it takes variable key sizes 276 for authentication. 278 That is, when generating keying material, "half the bits must come 279 from Ni and half from Nr, taking the first bits of each" as described 280 in IKEv2, section 2.14; but for authenticating with shared secrets 281 (IKEv2, section 2.16), the shared secret does not have to be 16 282 octets and the length may vary. 284 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 285 + Camellia-CMAC-PRF-128 + 286 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 287 + + 288 + Input : VK (Variable-length key) + 289 + : M (Message, i.e., the input data of the PRF) + 290 + : VKlen (length of VK in octets) + 291 + : len (length of M in octets) + 292 + Output : PRV (128-bit Pseudo-Random Variable) + 293 + + 294 +-------------------------------------------------------------------+ 295 + Variable: K (128-bit key for Camellia128-CMAC) + 296 + + 297 + Step 1. If VKlen is equal to 16 + 298 + Step 1a. then + 299 + K := VK; + 300 + Step 1b. else + 301 + K := Camellia128-CMAC(0^128, VK, VKlen); + 302 + Step 2. PRV := Camellia128-CMAC(K, M, len); + 303 + return PRV; + 304 + + 305 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 307 Figure 2: Algorithm Camellia-CMAC-PRF-128 309 In step 1, the 128-bit key, K, for Camellia128-CMAC is derived as 310 follows: 312 o If the key, VK, is exactly 128 bits, then we use it as-is. 314 o If it is longer or shorter than 128 bits, then we derive the key, 315 K, by applying the Camellia128-CMAC algorithm using the 128-bit 316 all-zero string as the key and VK as the input message. This step 317 is described in step 1b. 319 In step 2, we apply the Camellia128-CMAC algorithm using K as the key 320 and M as the input message. The output of this algorithm is 321 returned. 323 6. Test Vectors 325 TBD. 327 7. Security Considerations 329 The security provided by Camellia-CMAC-96 and Camellia-CMAC-PRF-128 330 is built on the strong cryptographic algorithm Camellia and CMAC. At 331 the time of this writing, there are no known practical cryptographic 332 attacks against Camellia and CMAC. 334 However, as is true with any cryptographic algorithm, part of its 335 strength lies in the secret key, K and VK, and the correctness of the 336 implementation in all of the participating systems. If the secret 337 key is compromised or inappropriately shared, it guarantees neither 338 authentication nor integrity of message at all. The secret key shall 339 be independently and randomly generated in a way that meets the 340 pseudo randomness requirement of RFC 4086 [12] and should be kept 341 safe. 343 For Camellia-CMAC-PRF-128, if the variable-length secret key, VK, is 344 longer than 128 bits and it is shortened to meet the 128-bit key 345 size, then some entropy might be lost. However, as long as VK is 346 longer than 128 bits, then the new key, K, preserves sufficient 347 entropy, i.e., the entropy of K is about 128 bits. 349 Therefore, we recommend the use of VK that is longer than or equal to 350 128 bits and periodically refreshed, and we discourage the use of VK 351 that is shorter than or equal to 64 bits, because of the small 352 entropy. 354 8. IANA Considerations 356 The IANA has allocated value for IKEv2 Transform Type 3 357 (Integrity Algorithm) to the AUTH_CAMELLIA_CMAC_96 algorithm, and has 358 allocated a value of for IKEv2 Transform Type 2 (Pseudo-Random 359 Function) to the PRF_CAMELLIA128_CMAC algorithm. 361 9. Acknowledgements 363 Portions of this text were borrowed from [16] and [17]. 365 10. References 367 10.1. Normative 369 [1] National Institute of Standards and Technology, "Recommendation 370 for Block Cipher Modes of Operation:The CMAC Mode for 371 Autentication", Special Publication 800-38B, May 2005. 373 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 374 Levels", BCP 14, RFC 2119, March 1997. 376 [3] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 378 [4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 379 December 2005. 381 [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 382 RFC 4306, December 2005. 384 [6] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC 385 Algorithm", RFC 4493, June 2006. 387 [7] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document 388 Roadmap", RFC 2411, November 1998. 390 [8] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the 391 Camellia Encryption Algorithm", RFC 3713, April 2004. 393 10.2. Informative 395 [9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 396 RFC 2409, November 1998. 398 [10] Moriai, S. and A. Kato, "Use of the Camellia Encryption 399 Algorithm in Cryptographic Message Syntax (CMS)", RFC 3657, 400 January 2004. 402 [11] Eastlake, D., "Additional XML Security Uniform Resource 403 Identifiers (URIs)", RFC 4051, April 2005. 405 [12] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 406 Requirements for Security", BCP 106, RFC 4086, June 2005. 408 [13] Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia 409 Cipher Suites to Transport Layer Security (TLS)", RFC 4132, 410 July 2005. 412 [14] Kent, S. and K. Seo, "Security Architecture for the Internet 413 Protocol", RFC 4301, December 2005. 415 [15] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher 416 Algorithm and Its Use With IPsec", RFC 4312, December 2005. 418 [16] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 419 Algorithm and Its Use with IPsec", RFC 4494, June 2006. 421 [17] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced 422 Encryption Standard-Cipher-based Message Authentication Code- 423 Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the 424 Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006. 426 [18] National Institute of Standards and Technology, "Advanced 427 Encryption Standard (AES)", FIPS PUB 197, November 2001, 428 . 430 [19] "The NESSIE project (New European Schemes for Signatures, 431 Integrity and Encryption)", 432 . 434 [20] Information-technology Promotion Agency (IPA), "Cryptography 435 Research and Evaluation Committees", 436 . 438 [21] International Organization for Standardization, "Information 439 technology - Security techniques - Encryption algorithms - Part 440 3: Block ciphers", ISO/IEC 18033-3, July 2005. 442 URIs 444 [22] 446 [23] 448 Authors' Addresses 450 Akihiro Kato 451 NTT Software Corporation 453 Phone: +81-45-212-7614 454 Fax: +81-45-212-7528 455 Email: akato@po.ntts.co.jp 457 Masayuki Kanda 458 Nippon Telegraph and Telephone Corporation 460 Phone: +81-46-859-2437 461 Fax: +81-46-859-3365 462 Email: kanda@isl.ntt.co.jp 464 Tetsu Iwata 465 Nagoya University 467 Email: iwata@cse.nagoya-u.ac.jp 469 Full Copyright Statement 471 Copyright (C) The IETF Trust (2007). 473 This document is subject to the rights, licenses and restrictions 474 contained in BCP 78, and except as set forth therein, the authors 475 retain all their rights. 477 This document and the information contained herein are provided on an 478 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 479 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 480 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 481 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 482 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 483 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 485 Intellectual Property 487 The IETF takes no position regarding the validity or scope of any 488 Intellectual Property Rights or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; nor does it represent that it has 492 made any independent effort to identify any such rights. Information 493 on the procedures with respect to rights in RFC documents can be 494 found in BCP 78 and BCP 79. 496 Copies of IPR disclosures made to the IETF Secretariat and any 497 assurances of licenses to be made available, or the result of an 498 attempt made to obtain a general license or permission for the use of 499 such proprietary rights by implementers or users of this 500 specification can be obtained from the IETF on-line IPR repository at 501 http://www.ietf.org/ipr. 503 The IETF invites any interested party to bring to its attention any 504 copyrights, patents or patent applications, or other proprietary 505 rights that may cover technology that may be required to implement 506 this standard. Please address the information to the IETF at 507 ietf-ipr@ietf.org. 509 Acknowledgment 511 Funding for the RFC Editor function is provided by the IETF 512 Administrative Support Activity (IASA).