idnits 2.17.1 draft-kato-ipsec-camellia-cmac96and128-01.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 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 657. 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 (November 14, 2007) is 5998 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: '8' is defined on line 545, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 562, 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) ** Obsolete normative reference: RFC 2411 (ref. '6') (Obsoleted by RFC 6071) ** Downref: Normative reference to an Informational RFC: RFC 3713 (ref. '7') -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '8') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4051 (ref. '10') (Obsoleted by RFC 6931) -- Obsolete informational reference (is this intentional?): RFC 4132 (ref. '12') (Obsoleted by RFC 5932) Summary: 4 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: May 17, 2008 Nippon Telegraph and Telephone 6 Corporation 7 T. Iwata 8 Nagoya University 9 November 14, 2007 11 The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use 12 with IPsec 13 draft-kato-ipsec-camellia-cmac96and128-01 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 May 17, 2008. 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4. Camellia-CMAC-96 . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Camellia-CMAC-PRF-128 . . . . . . . . . . . . . . . . . . . . 9 62 6. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 6.1. Camellia-CMAC-96 . . . . . . . . . . . . . . . . . . . . . 11 64 6.2. Camellia-CMAC-PRF-128 . . . . . . . . . . . . . . . . . . 11 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 10.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 18 70 10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 18 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 72 Intellectual Property and Copyright Statements . . . . . . . . . . 22 74 1. Introduction 76 This memo specifies two new alogorithms. One is the usage of CMAC 77 based on Camellia block cipher on the authentication mechanism of the 78 IPsec Encapsulating Security Payload (ESP) [4] and Authentication 79 Header protocols (AH) [3]. This algorithm is called 80 Camellia-CMAC-96. Latter is Pseudo-Random Function (PRF) based on 81 CMAC with Camellia block cipher for Internet Key Exchange (IKE) [5]. 82 This algoritm is called Camellia-CMAC-PRF-128. 84 Camellia is a symmetric cipher with a Feistel structure. Camillia 85 was developed jointly by NTT and Mitsubishi Electric Corporation in 86 2000. It was designed to withstand all known cryptanalytic attacks, 87 and it has been scrutinized by worldwide cryptographic experts. 88 Camellia is suitable for implementation in software and hardware, 89 offering encryption speed in software and hardware implementations 90 that is comparable to Advanced Encryption Standard (AES) [17]. 92 Camellia supports 128-bit block size and 128-, 192-, and 256-bit key 93 lengths, i.e., the same interface specifications as the AES. 94 Therefore developers can implement Camellia based alogorithms without 95 large amount of modification by replacing AES block of AES based 96 algorithms to Camellia block. 98 Camellia is adopted as IETF and several international standardization 99 organizations. Camellia is already adopted as IPSec [14], TLS [12], 100 S/MIME [9] and XML [10]. Camellia is adopted for the one of three 101 ISO/IEC international standard cipher [20] as 128bit block cipher 102 (Camellia AES and SEED). Camellia was selected as a recommended 103 cryptographic primitive by the EU NESSIE (New European Schemes for 104 Signatures, Integrity and Encryption) project [18] and was included 105 in the list of cryptographic techniques for Japanese e-Government 106 systems that was selected by the Japan CRYPTREC (Cryptography 107 Research Evaluation Committees) [19]. 109 Since optimized source code is provided by several open source 110 lisences [21], Camellia is also adopted by several open source 111 projects(Openssl, FreeBSD, Linux and Gran Paradiso). Additional API 112 for Network Security Services (NSS) and IPsec stack of Linux and Free 113 BSD are prepared or working progress for release. 115 The algorithm specification and object identifiers are described in 116 [7]. 118 The Camellia homepage [22] contains a wealth of information about 119 Camellia, including detailed specification, security analysis, 120 performance figures, reference implementation, optimized 121 implementetion, test vectors, and intellectual property information. 123 This doucment specifies the usage of CMAC with Camellia Block cipher 124 on the authentication mechanism of the IPsec Encapsulating Security 125 Payload [4] and Authentication Header [3] protocols. This new 126 algorithm is named Camellia-CMAC-96. 128 NIST CMAC specification document [1] describes a method to use the 129 Advanced Encryption Standard (AES) as a Message Authentication Code 130 (MAC) that has a 128-bit output length. The 128-bit output is useful 131 as a long-lived pseudo- random function (PRF). This document also 132 specifies a PRF based on CMAC with Camellia block cipher that 133 supports fixed and variable key sizes for IKEv2 [5] Key Derivation 134 Function (KDF) and authentication. This new alogrithm is named 135 Camellia-CMAC-PRF-128. For further information on IKE, AH and ESP, 136 refer to [5], [3], [4] and [6]. 138 This document does not cover implementation details of CMAC. Those 139 details can be found in [1]. 141 1.1. Terminology 143 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that 145 appear in this document are to be interpreted as described in [2]. 147 2. Definitions 149 CBC 150 Cipher Block Chaining mode of operation for message 151 authentication code. 153 MAC 154 Message Authentication Code. A bit string of a fixed 155 length, computed by the MAC generation algorithm, that is 156 used to establish the authority and, hence, the integrity 157 of a message. 159 CMAC 160 Cipher-based MAC based on a symmetric key block cipher. 162 Key (K) 163 128-bit (16-octet) key for Camellia cipher block. Denoted 164 by K. 166 Variable-length Key (VK) 167 Variable-length key for Camellia-CMAC-PRF-128, denoted by 168 VK. 170 Message (M) 171 Message to be authenticated. Denoted by M. 173 Length (len) 174 The length of message M in octets. Denoted by len. The 175 minimum value is 0. The maximum value is not specified in 176 this document. 178 VKlen 179 The length of VK in octets. 181 truncate(T,l) 182 Truncate T (MAC) in most-significant-bit-first (MSB-first) 183 order to a length of l octets. 185 T 186 The output of Camellia-CMAC. 188 Truncated T 189 The truncated output of Camellia-CMAC-128 in MSB-first 190 order. 192 Camellia-CMAC 193 CMAC generation function based on Camellia block cipher 194 with 128-bit key. 196 Camellia-CMAC-96 197 IPsec AH and ESP MAC generation function based on Camellia- 198 CMAC, which truncates the 96 most significant bits of the 199 128-bit output. 201 Camellia-CMAC-PRF-128 202 IPsec AH and ESP PRF based on Camellia-CMAC, which removes 203 128-bit key length restriction. 205 3. Camellia-CMAC 207 The National Institute of Standards and Technology (NIST) has 208 recently specified the Cipher-based Message Authentication Code 209 (CMAC). CMAC [1] is a keyed hash function that is based on a 210 symmetric key block cipher, such as the Advanced Encryption Standard 211 [17]. The CMAC algorithm provides a framework for inserting various 212 block cipher algorithm. 214 Camellia-CMAC uses the Camellia block cipher [7] as a building block 215 in CMAC [1]. To generate a MAC, Camelllia-CMAC takes a secret key, a 216 message of variable length, and the length of the message in octets 217 as inputs and returns a fixed-bit string. 219 4. Camellia-CMAC-96 221 For IPsec message authentication on AH and ESP, Camellia-CMAC-96 MAY 222 be used. Camellia-CMAC-96 is a Camellia-CMAC with 96-bit truncated 223 output in MSB-first order. The output is a 96-bit MAC that will meet 224 the default authenticator length as specified in [3]. The result of 225 truncation is taken in MSB-first order. 227 Figure 1 describes Camellia-CMAC-96 algorithm: 229 In step 1, Camellia-CMAC is applied to the message M in length len 230 with key K. 232 In step 2, the output block T is truncated to 12 octets in MSB-first 233 order, and Truncated T (TT) is returned. 235 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 236 + Algorithm Camellia-CMAC-96 + 237 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 238 + + 239 + Input : K (128-bit Key) + 240 + : M (message to be authenticated) + 241 + : len (length of message in octets) + 242 + Output : Truncated T (truncated output to length 12 octets) + 243 + + 244 +-------------------------------------------------------------------+ 245 + + 246 + Step 1. T := Camellia-CMAC (K,M,len); + 247 + Step 2. TT := truncate (T, 12); + 248 + return TT; + 249 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 251 Figure 1: Algorithm Camellia-CMAC-96 253 5. Camellia-CMAC-PRF-128 255 The Camellia-CMAC-PRF-128 algorithm is identical to Camellia-CMAC 256 except that the 128-bit key length restriction is removed. 258 IKEv2 [5] uses PRFs for multiple purposes, most notably for 259 generating keying material and authentication of the IKE_SA. The 260 IKEv2 specification differentiates between PRFs with fixed key sizes 261 and those with variable key sizes. 263 When using Camellia-CMAC-PRF-128 as the PRF described in IKEv2, 264 Camellia-CMAC-PRF-128 is considered to take fixed size (16 octets) 265 keys for generating keying material but it takes variable key sizes 266 for authentication. 268 That is, when generating keying material, "half the bits must come 269 from Ni and half from Nr, taking the first bits of each" as described 270 in IKEv2, section 2.14; but for authenticating with shared secrets 271 (IKEv2, section 2.16), the shared secret does not have to be 16 272 octets and the length may vary. 274 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 275 + Camellia-CMAC-PRF-128 + 276 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 277 + + 278 + Input : VK (Variable-length key) + 279 + : M (Message, i.e., the input data of the PRF) + 280 + : VKlen (length of VK in octets) + 281 + : len (length of M in octets) + 282 + Output : PRV (128-bit Pseudo-Random Variable) + 283 + + 284 +-------------------------------------------------------------------+ 285 + Variable: K (128-bit key for Camellia-CMAC) + 286 + + 287 + Step 1. If VKlen is equal to 16 + 288 + Step 1a. then + 289 + K := VK; + 290 + Step 1b. else + 291 + K := Camellia-CMAC(0^128, VK, VKlen); + 292 + Step 2. PRV := Camellia-CMAC(K, M, len); + 293 + return PRV; + 294 + + 295 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 297 Figure 2: Algorithm Camellia-CMAC-PRF-128 299 In step 1, the 128-bit key, K, for Camellia-CMAC is derived as 300 follows: 302 o If the key, VK, is exactly 128 bits, then we use it as-is. 304 o If it is longer or shorter than 128 bits, then we derive the key, 305 K, by applying the Camellia-CMAC algorithm using the 128-bit all- 306 zero string as the key and VK as the input message. This step is 307 described in step 1b. 309 In step 2, we apply the Camellia-CMAC algorithm using K as the key 310 and M as the input message. The output of this algorithm is 311 returned. 313 6. Test Vectors 315 6.1. Camellia-CMAC-96 317 This section contains four test vectors(TV), which can be used to 318 confirm that an implementation has correctly implemented Camellia- 319 CMAC-96. 321 ---------------- 322 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 324 Mlen = 0 325 M 326 T ba925782 aaa1f5d9 a00f8964 328 ---------------- 329 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 331 Mlen = 16 332 M 6bc1bee2 2e409f96 e93d7e11 7393172a 333 T 6d962854 a3b9fda5 6d7d45a9 335 ---------------- 336 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 338 Mlen = 40 339 M 6bc1bee2 2e409f96 e93d7e11 7393172a 340 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 341 30c81c46 a35ce411 342 T 5c18d119 ccd67661 44ac1866 344 ---------------- 345 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 347 Mlen = 64 348 M 6bc1bee2 2e409f96 e93d7e11 7393172a 349 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 350 30c81c46 a35ce411 e5fbc119 1a0a52ef 351 f69f2445 df4f9b17 ad2b417b e66c3710 352 T c2699a6e ba55ce9d 939a8a4e 354 6.2. Camellia-CMAC-PRF-128 356 This section contains twelve test vectors(TV), which can be used to 357 confirm that an implementation has correctly implemented Camellia- 358 CMAC-PRF-128. The first four test vectors use 128 bit VK; the next 359 four test vectors use 192 bit VK; and the last four test vectors use 360 256 bit VK. 362 VKlen = 16 363 ---------------- 364 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 366 Mlen = 0 367 M 368 T ba925782 aaa1f5d9 a00f8964 8094fc71 370 ---------------- 371 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 373 Mlen = 16 374 M 6bc1bee2 2e409f96 e93d7e11 7393172a 375 T 6d962854 a3b9fda5 6d7d45a9 5ee17993 377 ---------------- 378 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 380 Mlen = 40 381 M 6bc1bee2 2e409f96 e93d7e11 7393172a 382 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 383 30c81c46 a35ce411 384 T 5c18d119 ccd67661 44ac1866 131d9f22 386 ---------------- 387 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 389 Mlen = 64 390 M 6bc1bee2 2e409f96 e93d7e11 7393172a 391 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 392 30c81c46 a35ce411 e5fbc119 1a0a52ef 393 f69f2445 df4f9b17 ad2b417b e66c3710 394 T c2699a6e ba55ce9d 939a8a4e 19466ee9 396 ------------------------------------------------------------ 397 VKlen = 24 398 ---------------- 399 VK 8e73b0f7 da0e6452 c810f32b 809079e5 400 62f8ead2 522c6b7b 402 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 403 Mlen = 0 404 M 405 T f4739892 c70bd23e 891f66c0 5fefbf27 407 ---------------- 408 VK 8e73b0f7 da0e6452 c810f32b 809079e5 409 62f8ead2 522c6b7b 411 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 413 Mlen = 16 414 M 6bc1bee2 2e409f96 e93d7e11 7393172a 415 T 60a33814 53babaed 1a11dfd3 d24c1410 417 ---------------- 418 VK 8e73b0f7 da0e6452 c810f32b 809079e5 419 62f8ead2 522c6b7b 421 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 423 Mlen = 40 424 M 6bc1bee2 2e409f96 e93d7e11 7393172a 425 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 426 30c81c46 a35ce411 427 T 42b9d47f 4f58bc29 85b6f82c 23b121cb 429 ---------------- 430 VK 8e73b0f7 da0e6452 c810f32b 809079e5 431 62f8ead2 522c6b7b 433 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 435 Mlen = 64 436 M 6bc1bee2 2e409f96 e93d7e11 7393172a 437 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 438 30c81c46 a35ce411 e5fbc119 1a0a52ef 439 f69f2445 df4f9b17 ad2b417b e66c3710 440 T d078729f dcae9abc ff1ea4d6 18ed4501 442 ------------------------------------------------------------ 443 VKlen = 32 444 ---------------- 445 VK 603deb10 15ca71be 2b73aef0 857d7781 446 1f352c07 3b6108d7 2d9810a3 0914dff4 448 K b5aeeae9 2c23bed7 167af194 2e831597 450 Mlen = 0 451 M 452 T c96d7d40 d4aaab78 ac906b91 c82bd690 454 ---------------- 455 VK 603deb10 15ca71be 2b73aef0 857d7781 456 1f352c07 3b6108d7 2d9810a3 0914dff4 458 K b5aeeae9 2c23bed7 167af194 2e831597 460 Mlen = 16 461 M 6bc1bee2 2e409f96 e93d7e11 7393172a 462 T 104de4b9 0da6baf1 fa73945b e614f032 464 ---------------- 465 VK 603deb10 15ca71be 2b73aef0 857d7781 466 1f352c07 3b6108d7 2d9810a3 0914dff4 468 K b5aeeae9 2c23bed7 167af194 2e831597 470 Mlen = 40 471 M 6bc1bee2 2e409f96 e93d7e11 7393172a 472 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 473 30c81c46 a35ce411 474 T 2d3684e9 1cb1b303 a7db8648 f25ee16c 476 ---------------- 477 VK 603deb10 15ca71be 2b73aef0 857d7781 478 1f352c07 3b6108d7 2d9810a3 0914dff4 480 K b5aeeae9 2c23bed7 167af194 2e831597 482 Mlen = 64 483 M 6bc1bee2 2e409f96 e93d7e11 7393172a 484 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 485 30c81c46 a35ce411 e5fbc119 1a0a52ef 486 f69f2445 df4f9b17 ad2b417b e66c3710 487 T d6b0f1b7 dda2b62a eca6d51d da63fdda 489 7. Security Considerations 491 The security provided by Camellia-CMAC-96 Camellia-CMAC-PRF-128 is 492 built on the strong cryptographic algorithm Camellia and CMAC. At 493 the time of this writing, there are no known practical cryptographic 494 attacks against Camellia or CMAC. 496 However, as is true with any cryptographic algorithm, part of its 497 strength lies in the secret key, K, and the correctness of the 498 implementation in all of the participating systems. If the secret 499 key is compromised or inappropriately shared, it guarantees neither 500 authentication nor integrity of message at all. The secret key shall 501 be generated in a way that meets the pseudo randomness requirement of 502 RFC 4086 [11] and should be kept safe. If and only if 503 Camellia-CMAC-96 Camellia-CMAC-PRF-128 are used properly it provides 504 the authentication and integrity that meet the best current practice 505 of message authentication. 507 8. IANA Considerations 509 The IANA has allocated value for IKEv2 Transform Type 3 510 (Integrity Algorithm) to the AUTH_CAMELLIA_CMAC_96 algorithm, and has 511 allocated a value of for IKEv2 Transform Type 2 (Pseudo-Random 512 Function) to the PRF_CAMELLIA128_CMAC algorithm. 514 9. Acknowledgements 516 Portions of this text were borrowed from [15] and [16]. 518 10. References 520 10.1. Normative 522 [1] National Institute of Standards and Technology, "Recommendation 523 for Block Cipher Modes of Operation:The CMAC Mode for 524 Autentication", Special Publication 800-38B, May 2005. 526 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 527 Levels", BCP 14, RFC 2119, March 1997. 529 [3] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 531 [4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 532 December 2005. 534 [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 535 RFC 4306, December 2005. 537 [6] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document 538 Roadmap", RFC 2411, November 1998. 540 [7] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the 541 Camellia Encryption Algorithm", RFC 3713, April 2004. 543 10.2. Informative 545 [8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 546 RFC 2409, November 1998. 548 [9] Moriai, S. and A. Kato, "Use of the Camellia Encryption 549 Algorithm in Cryptographic Message Syntax (CMS)", RFC 3657, 550 January 2004. 552 [10] Eastlake, D., "Additional XML Security Uniform Resource 553 Identifiers (URIs)", RFC 4051, April 2005. 555 [11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 556 Requirements for Security", BCP 106, RFC 4086, June 2005. 558 [12] Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia 559 Cipher Suites to Transport Layer Security (TLS)", RFC 4132, 560 July 2005. 562 [13] Kent, S. and K. Seo, "Security Architecture for the Internet 563 Protocol", RFC 4301, December 2005. 565 [14] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher 566 Algorithm and Its Use With IPsec", RFC 4312, December 2005. 568 [15] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 569 Algorithm and Its Use with IPsec", RFC 4494, June 2006. 571 [16] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced 572 Encryption Standard-Cipher-based Message Authentication Code- 573 Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the 574 Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006. 576 [17] National Institute of Standards and Technology, "Advanced 577 Encryption Standard (AES)", FIPS PUB 197, November 2001, 578 . 580 [18] "The NESSIE project (New European Schemes for Signatures, 581 Integrity and Encryption)", 582 . 584 [19] Information-technology Promotion Agency (IPA), "Cryptography 585 Research and Evaluation Committees", 586 . 588 [20] International Organization for Standardization, "Information 589 technology - Security techniques - Encryption algorithms - Part 590 3: Block ciphers", ISO/IEC 18033-3, July 2005. 592 URIs 594 [21] 596 [22] 598 Authors' Addresses 600 Akihiro Kato 601 NTT Software Corporation 603 Phone: +81-45-212-7577 604 Fax: +81-45-212-9800 605 Email: akato@po.ntts.co.jp 607 Masayuki Kanda 608 Nippon Telegraph and Telephone Corporation 610 Phone: +81-422-59-3456 611 Fax: +81-422-59-4015 612 Email: kanda.masayuki@lab.ntt.co.jp 614 Tetsu Iwata 615 Nagoya University 617 Email: iwata@cse.nagoya-u.ac.jp 619 Full Copyright Statement 621 Copyright (C) The IETF Trust (2007). 623 This document is subject to the rights, licenses and restrictions 624 contained in BCP 78, and except as set forth therein, the authors 625 retain all their rights. 627 This document and the information contained herein are provided on an 628 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 629 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 630 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 631 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 632 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 633 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 635 Intellectual Property 637 The IETF takes no position regarding the validity or scope of any 638 Intellectual Property Rights or other rights that might be claimed to 639 pertain to the implementation or use of the technology described in 640 this document or the extent to which any license under such rights 641 might or might not be available; nor does it represent that it has 642 made any independent effort to identify any such rights. Information 643 on the procedures with respect to rights in RFC documents can be 644 found in BCP 78 and BCP 79. 646 Copies of IPR disclosures made to the IETF Secretariat and any 647 assurances of licenses to be made available, or the result of an 648 attempt made to obtain a general license or permission for the use of 649 such proprietary rights by implementers or users of this 650 specification can be obtained from the IETF on-line IPR repository at 651 http://www.ietf.org/ipr. 653 The IETF invites any interested party to bring to its attention any 654 copyrights, patents or patent applications, or other proprietary 655 rights that may cover technology that may be required to implement 656 this standard. Please address the information to the IETF at 657 ietf-ipr@ietf.org. 659 Acknowledgment 661 Funding for the RFC Editor function is provided by the IETF 662 Administrative Support Activity (IASA).