idnits 2.17.1 draft-kato-ipsec-camellia-cmac96and128-02.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 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 641. 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, 2008) is 5905 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) == Outdated reference: A later version (-03) exists of draft-hoffman-ikev2bis-02 -- Obsolete informational reference (is this intentional?): RFC 4051 (ref. '9') (Obsoleted by RFC 6931) -- Obsolete informational reference (is this intentional?): RFC 4132 (ref. '11') (Obsoleted by RFC 5932) Summary: 2 errors (**), 0 flaws (~~), 3 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 28, 2008 Nippon Telegraph and Telephone 6 Corporation 7 T. Iwata 8 Nagoya University 9 February 25, 2008 11 The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use 12 with IPsec 13 draft-kato-ipsec-camellia-cmac96and128-02 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 28, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This memo specifies two new algorithms. 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 algorithm is 50 called Camellia-CMAC-96. Latter is pseudo-random function based on 51 CMAC with Camellia block cipher for Internet Key Exchange. This 52 algorithm 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 algorithms. One is the usage of CMAC 77 based on Camellia block cipher on the authentication mechanism of the 78 IPsec Encapsulating Security Payload (ESP) [7] and Authentication 79 Header protocols (AH) [6]. 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 (IKEv2) 82 [8]. This algorithm is called Camellia-CMAC-PRF-128. 84 Camellia is a symmetric cipher with a Feistel structure. Camellia 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) [13]. 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 algorithms 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 [12], TLS [11], 100 S/MIME [5] and XML [9]. Camellia is adopted for the one of three 101 ISO/IEC international standard cipher [16] 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 [14] 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) [15]. 109 Since optimized source code is provided by several open source 110 lisences [17], Camellia is also adopted by several open source 111 projects (Openssl, FreeBSD, Linux and Gran Paradiso). 113 The algorithm specification and object identifiers are described in 114 [3]. 116 The Camellia homepage [18] contains a wealth of information about 117 Camellia, including detailed specification, security analysis, 118 performance figures, reference implementation, optimized 119 implementation, test vectors, and intellectual property information. 121 This document specifies the usage of CMAC with Camellia Block cipher 122 on the authentication mechanism of the IPsec Encapsulating Security 123 Payload [7] and Authentication Header [6] protocols. This new 124 algorithm is named Camellia-CMAC-96. 126 NIST CMAC specification document [1] describes a method to use the 127 Advanced Encryption Standard (AES) as a Message Authentication Code 128 (MAC) that has a 128-bit output length. The 128-bit output is useful 129 as a long-lived PRF. This document also specifies a PRF based on 130 CMAC with Camellia block cipher that supports fixed and variable key 131 sizes for IKEv2 [8] Key Derivation Function (KDF) and authentication. 132 This new algorithm is named Camellia-CMAC-PRF-128. For further 133 information on IKE, AH and ESP, refer to [8], [6], [7] and [4]. 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 cipher block. Denoted 161 by K. 163 Variable-length Key (VK) 164 Variable-length key for Camellia-CMAC-PRF-128, denoted by 165 VK. 167 Message (M) 168 Message to be authenticated. Denoted by M. 170 Length (len) 171 The length of message M in octets. Denoted by len. The 172 minimum value is 0. The maximum value is not specified in 173 this document. 175 VKlen 176 The length of VK in octets. 178 truncate(T,l) 179 Truncate T (MAC) in most-significant-bit-first (MSB-first) 180 order to a length of l octets. 182 T 183 The output of Camellia-CMAC. 185 Camellia-CMAC 186 CMAC generation function based on Camellia block cipher 187 with 128-bit key. 189 Camellia-CMAC-96 190 IPsec AH and ESP MAC generation function based on Camellia- 191 CMAC, which truncates the 96 most significant bits of the 192 128-bit output. 194 Camellia-CMAC-PRF-128 195 IPsec AH and ESP PRF based on Camellia-CMAC, which removes 196 128-bit key length restriction. 198 SKEYSEED Seed of shared key calculated from the nonces exchanged 199 during the IKE_SA_INIT exchange and the Diffie-Hellman 200 shared secret in IKEv2 specification. 202 3. Camellia-CMAC 204 The National Institute of Standards and Technology (NIST) has 205 recently specified the Cipher-based Message Authentication Code 206 (CMAC). CMAC [1] is a keyed hash function that is based on a 207 symmetric key block cipher, such as the Advanced Encryption Standard 208 [13]. The CMAC algorithm provides a framework for inserting various 209 block cipher algorithm. 211 Camellia-CMAC uses the Camellia block cipher [3] as a building block 212 in CMAC [1]. To generate a MAC, Camellia-CMAC(K, M, len) takes a 213 secret key 'K', a message of variable length 'M', and the length of 214 the message in octets 'len' as inputs and returns a fixed-bit string. 216 In this specification, Camellia-CMAC is always used with 128-bit 217 length key. 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 [6]. 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 [8] uses PRFs for multiple purposes, most notably for 259 generating keying material and authentication of the IKE_SA. 261 When using Camellia-CMAC-PRF-128 as the PRF described in IKEv2, 262 Camellia-CMAC-PRF-128 is considered to take variable key length in 263 all places, and the number of bits of keying material generated when 264 new keys are generated is 128 bits (i.e. preferred key length when 265 generating keying material of SK_d, SK_pi, and SK_pr is 128 bits). 267 When generating SKEYSEED the full of Ni and Nr are used as key for 268 the PRF. 270 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 271 + Camellia-CMAC-PRF-128 + 272 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 273 + + 274 + Input : VK (Variable-length key) + 275 + : M (Message, i.e., the input data of the PRF) + 276 + : VKlen (length of VK in octets) + 277 + : len (length of M in octets) + 278 + Output : PRV (128-bit Pseudo-Random Variable) + 279 + + 280 +-------------------------------------------------------------------+ 281 + Variable: K (128-bit key for Camellia-CMAC) + 282 + + 283 + Step 1. If VKlen is equal to 16 + 284 + Step 1a. then + 285 + K := VK; + 286 + Step 1b. else + 287 + K := Camellia-CMAC(0^128, VK, VKlen); + 288 + Step 2. PRV := Camellia-CMAC(K, M, len); + 289 + return PRV; + 290 + + 291 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 293 Figure 2: Algorithm Camellia-CMAC-PRF-128 295 In step 1, the 128-bit key, K, for Camellia-CMAC is derived as 296 follows: 298 o If the key, VK, is exactly 128 bits, then we use it as-is. 300 o If it is longer or shorter than 128 bits, then we derive the key, 301 K, by applying the Camellia-CMAC algorithm using the 128-bit all- 302 zero string as the key and VK as the input message. This step is 303 described in step 1b. 305 In step 2, we apply the Camellia-CMAC algorithm using K as the key 306 and M as the input message. The output of this algorithm is 307 returned. 309 6. Test Vectors 311 6.1. Camellia-CMAC-96 313 This section contains four test vectors(TV), which can be used to 314 confirm that an implementation has correctly implemented Camellia- 315 CMAC-96. 317 ---------------- 318 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 320 Mlen = 0 321 M 322 T ba925782 aaa1f5d9 a00f8964 324 ---------------- 325 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 327 Mlen = 16 328 M 6bc1bee2 2e409f96 e93d7e11 7393172a 329 T 6d962854 a3b9fda5 6d7d45a9 331 ---------------- 332 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 334 Mlen = 40 335 M 6bc1bee2 2e409f96 e93d7e11 7393172a 336 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 337 30c81c46 a35ce411 338 T 5c18d119 ccd67661 44ac1866 340 ---------------- 341 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 343 Mlen = 64 344 M 6bc1bee2 2e409f96 e93d7e11 7393172a 345 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 346 30c81c46 a35ce411 e5fbc119 1a0a52ef 347 f69f2445 df4f9b17 ad2b417b e66c3710 348 T c2699a6e ba55ce9d 939a8a4e 350 6.2. Camellia-CMAC-PRF-128 352 This section contains twelve test vectors(TV), which can be used to 353 confirm that an implementation has correctly implemented Camellia- 354 CMAC-PRF-128. The first four test vectors use 128 bit VK; the next 355 four test vectors use 192 bit VK; and the last four test vectors use 356 256 bit VK. 358 VKlen = 16 359 ---------------- 360 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 362 Mlen = 0 363 M 364 T ba925782 aaa1f5d9 a00f8964 8094fc71 366 ---------------- 367 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 369 Mlen = 16 370 M 6bc1bee2 2e409f96 e93d7e11 7393172a 371 T 6d962854 a3b9fda5 6d7d45a9 5ee17993 373 ---------------- 374 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 376 Mlen = 40 377 M 6bc1bee2 2e409f96 e93d7e11 7393172a 378 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 379 30c81c46 a35ce411 380 T 5c18d119 ccd67661 44ac1866 131d9f22 382 ---------------- 383 VK 2b7e1516 28aed2a6 abf71588 09cf4f3c 385 Mlen = 64 386 M 6bc1bee2 2e409f96 e93d7e11 7393172a 387 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 388 30c81c46 a35ce411 e5fbc119 1a0a52ef 389 f69f2445 df4f9b17 ad2b417b e66c3710 390 T c2699a6e ba55ce9d 939a8a4e 19466ee9 392 ------------------------------------------------------------ 393 VKlen = 24 394 ---------------- 395 VK 8e73b0f7 da0e6452 c810f32b 809079e5 396 62f8ead2 522c6b7b 398 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 399 Mlen = 0 400 M 401 T f4739892 c70bd23e 891f66c0 5fefbf27 403 ---------------- 404 VK 8e73b0f7 da0e6452 c810f32b 809079e5 405 62f8ead2 522c6b7b 407 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 409 Mlen = 16 410 M 6bc1bee2 2e409f96 e93d7e11 7393172a 411 T 60a33814 53babaed 1a11dfd3 d24c1410 413 ---------------- 414 VK 8e73b0f7 da0e6452 c810f32b 809079e5 415 62f8ead2 522c6b7b 417 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 419 Mlen = 40 420 M 6bc1bee2 2e409f96 e93d7e11 7393172a 421 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 422 30c81c46 a35ce411 423 T 42b9d47f 4f58bc29 85b6f82c 23b121cb 425 ---------------- 426 VK 8e73b0f7 da0e6452 c810f32b 809079e5 427 62f8ead2 522c6b7b 429 K abddaa68 e8b9f0af 2fb4db53 41cf1d91 431 Mlen = 64 432 M 6bc1bee2 2e409f96 e93d7e11 7393172a 433 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 434 30c81c46 a35ce411 e5fbc119 1a0a52ef 435 f69f2445 df4f9b17 ad2b417b e66c3710 436 T d078729f dcae9abc ff1ea4d6 18ed4501 438 ------------------------------------------------------------ 439 VKlen = 32 440 ---------------- 441 VK 603deb10 15ca71be 2b73aef0 857d7781 442 1f352c07 3b6108d7 2d9810a3 0914dff4 444 K b5aeeae9 2c23bed7 167af194 2e831597 446 Mlen = 0 447 M 448 T c96d7d40 d4aaab78 ac906b91 c82bd690 450 ---------------- 451 VK 603deb10 15ca71be 2b73aef0 857d7781 452 1f352c07 3b6108d7 2d9810a3 0914dff4 454 K b5aeeae9 2c23bed7 167af194 2e831597 456 Mlen = 16 457 M 6bc1bee2 2e409f96 e93d7e11 7393172a 458 T 104de4b9 0da6baf1 fa73945b e614f032 460 ---------------- 461 VK 603deb10 15ca71be 2b73aef0 857d7781 462 1f352c07 3b6108d7 2d9810a3 0914dff4 464 K b5aeeae9 2c23bed7 167af194 2e831597 466 Mlen = 40 467 M 6bc1bee2 2e409f96 e93d7e11 7393172a 468 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 469 30c81c46 a35ce411 470 T 2d3684e9 1cb1b303 a7db8648 f25ee16c 472 ---------------- 473 VK 603deb10 15ca71be 2b73aef0 857d7781 474 1f352c07 3b6108d7 2d9810a3 0914dff4 476 K b5aeeae9 2c23bed7 167af194 2e831597 478 Mlen = 64 479 M 6bc1bee2 2e409f96 e93d7e11 7393172a 480 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 481 30c81c46 a35ce411 e5fbc119 1a0a52ef 482 f69f2445 df4f9b17 ad2b417b e66c3710 483 T d6b0f1b7 dda2b62a eca6d51d da63fdda 485 7. Security Considerations 487 The security provided by Camellia-CMAC-96 Camellia-CMAC-PRF-128 is 488 built on the strong cryptographic algorithm Camellia and CMAC. At 489 the time of this writing, there are no known practical cryptographic 490 attacks against Camellia or CMAC. 492 However, as is true with any cryptographic algorithm, part of its 493 strength lies in the secret key, K, and the correctness of the 494 implementation in all of the participating systems. If the secret 495 key is compromised or inappropriately shared, it guarantees neither 496 authentication nor integrity of message at all. The secret key shall 497 be generated in a way that meets the pseudo randomness requirement of 498 RFC 4086 [10] and should be kept safe. If and only if 499 Camellia-CMAC-96 Camellia-CMAC-PRF-128 are used properly it provides 500 the authentication and integrity that meet the best current practice 501 of message authentication. 503 8. IANA Considerations 505 The IANA has allocated value for IKEv2 Transform Type 3 506 (Integrity Algorithm) to the AUTH_CAMELLIA_CMAC_96 algorithm, and has 507 allocated a value of for IKEv2 Transform Type 2 (Pseudo-Random 508 Function) to the PRF_CAMELLIA128_CMAC algorithm. 510 9. Acknowledgements 512 We thank Tim Polk and Tero Kivinen for their initial review of this 513 document. 515 10. References 517 10.1. Normative 519 [1] National Institute of Standards and Technology, "Recommendation 520 for Block Cipher Modes of Operation:The CMAC Mode for 521 Authentication", Special Publication 800-38B, May 2005. 523 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 524 Levels", BCP 14, RFC 2119, March 1997. 526 [3] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the 527 Camellia Encryption Algorithm", RFC 3713, April 2004. 529 10.2. Informative 531 [4] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document 532 Roadmap", RFC 2411, November 1998. 534 [5] Moriai, S. and A. Kato, "Use of the Camellia Encryption 535 Algorithm in Cryptographic Message Syntax (CMS)", RFC 3657, 536 January 2004. 538 [6] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 540 [7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 541 December 2005. 543 [8] Kaufman, C., Hoffman, P., and P. Eronen, "Internet Key Exchange 544 Protocol: IKEv2", draft-hoffman-ikev2bis-02 (work in progress), 545 November 2007. 547 [9] Eastlake, D., "Additional XML Security Uniform Resource 548 Identifiers (URIs)", RFC 4051, April 2005. 550 [10] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 551 Requirements for Security", BCP 106, RFC 4086, June 2005. 553 [11] Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia 554 Cipher Suites to Transport Layer Security (TLS)", RFC 4132, 555 July 2005. 557 [12] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher 558 Algorithm and Its Use With IPsec", RFC 4312, December 2005. 560 [13] National Institute of Standards and Technology, "Advanced 561 Encryption Standard (AES)", FIPS PUB 197, November 2001, 562 . 564 [14] "The NESSIE project (New European Schemes for Signatures, 565 Integrity and Encryption)", 566 . 568 [15] Information-technology Promotion Agency (IPA), "Cryptography 569 Research and Evaluation Committees", 570 . 572 [16] International Organization for Standardization, "Information 573 technology - Security techniques - Encryption algorithms - Part 574 3: Block ciphers", ISO/IEC 18033-3, July 2005. 576 URIs 578 [17] 580 [18] 582 Authors' Addresses 584 Akihiro Kato 585 NTT Software Corporation 587 Phone: +81-45-212-7577 588 Fax: +81-45-212-9800 589 Email: akato@po.ntts.co.jp 591 Masayuki Kanda 592 Nippon Telegraph and Telephone Corporation 594 Phone: +81-422-59-3456 595 Fax: +81-422-59-4015 596 Email: kanda.masayuki@lab.ntt.co.jp 598 Tetsu Iwata 599 Nagoya University 601 Email: iwata@cse.nagoya-u.ac.jp 603 Full Copyright Statement 605 Copyright (C) The IETF Trust (2008). 607 This document is subject to the rights, licenses and restrictions 608 contained in BCP 78, and except as set forth therein, the authors 609 retain all their rights. 611 This document and the information contained herein are provided on an 612 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 613 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 614 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 615 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 616 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 617 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 619 Intellectual Property 621 The IETF takes no position regarding the validity or scope of any 622 Intellectual Property Rights or other rights that might be claimed to 623 pertain to the implementation or use of the technology described in 624 this document or the extent to which any license under such rights 625 might or might not be available; nor does it represent that it has 626 made any independent effort to identify any such rights. Information 627 on the procedures with respect to rights in RFC documents can be 628 found in BCP 78 and BCP 79. 630 Copies of IPR disclosures made to the IETF Secretariat and any 631 assurances of licenses to be made available, or the result of an 632 attempt made to obtain a general license or permission for the use of 633 such proprietary rights by implementers or users of this 634 specification can be obtained from the IETF on-line IPR repository at 635 http://www.ietf.org/ipr. 637 The IETF invites any interested party to bring to its attention any 638 copyrights, patents or patent applications, or other proprietary 639 rights that may cover technology that may be required to implement 640 this standard. Please address the information to the IETF at 641 ietf-ipr@ietf.org. 643 Acknowledgment 645 Funding for the RFC Editor function is provided by the IETF 646 Administrative Support Activity (IASA).