idnits 2.17.1 draft-ietf-ipsec-ciph-camellia-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 53 has weird spacing: '...imitive by...' == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 199, but not defined == Unused Reference: 'DOI' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'IKE' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'RFC-2026' is defined on line 304, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** Obsolete normative reference: RFC 2401 (ref. 'ARCH') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. 'Camellia' == Outdated reference: A later version (-03) exists of draft-nakajima-camellia-02 ** Downref: Normative reference to an Informational draft: draft-nakajima-camellia (ref. 'Camellia-ID') == Outdated reference: A later version (-06) exists of draft-ietf-tls-camellia-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'CRYPTO-S' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRYPTREC' ** Obsolete normative reference: RFC 2407 (ref. 'DOI') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' -- Possible downref: Non-RFC (?) normative reference: ref. 'NESSIE' ** Obsolete normative reference: RFC 2411 (ref. 'ROAD') (Obsoleted by RFC 6071) Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft IPsec Working Group 3 October 2003 S. Moriai 4 Expiration Date: March 2004 Sony Computer Entertainment Inc. 5 S. Okazaki 6 NTT Multimedia Communications Laboratories, Inc. 7 A. Kato 8 NTT Software Corp. 10 The Camellia Cipher Algorithm and Its Use With IPsec 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsolete by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Drafts Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This document is a submission to the IETF Internet Protocol Security 33 (IPSEC) Working Group. Comments are solicited and should be addressed 34 to the working group mailing list (ipsec@lists.tislabs.com) or to the 35 editors. 37 Distribution of this memo is unlimited. 39 Abstract 41 This document describes the use of the Camellia block cipher 42 algorithm in Cipher Block Chaining Mode, with an explicit IV, as 43 a confidentiality mechanism within the context of the IPsec 44 Encapsulating Security Payload (ESP). 46 1. Introduction 48 This document describes the use of the Camellia block cipher 49 algorithm in Cipher Block Chaining Mode, with an explicit IV, as a 50 confidentiality mechanism within the context of the IPsec 51 Encapsulating Security Payload (ESP). 53 Camellia was selected as a recommended cryptographic primitive by 54 the EU NESSIE (New European Schemes for Signatures, Integrity and 55 Encryption) project [NESSIE] and included in the list of 56 cryptographic techniques for Japanese e-Government systems which were 57 selected by the Japan CRYPTREC (Cryptography Research and Evaluation 58 Committees) [CRYPTREC]. Camellia has been submitted to other several 59 standardization bodies such as ISO (ISO/IEC 18033) , IETF Transport 60 Layer Security working group [Camellia-TLS] and S/MIME Mail Security 61 [Camellia-SMIME] and it is under consideration. 63 Camellia supports 128-bit block size and 128-, 192-, and 256-bit key 64 lengths, i.e. the same interface specifications as the Advanced 65 Encryption Standard (AES) [AES]. 67 Camellia was jointly developed by NTT and Mitsubishi Electric 68 Corporation in 2000. It was carefully designed to withstand all known 69 cryptanalytic attacks and even to have a sufficiently large security 70 leeway for use of the next 10-20 years. It has been scrutinized by 71 worldwide cryptographic experts. 73 Camellia was also designed to have suitability for both software and 74 hardware implementations and to cover all possible encryption 75 applications that range from low-cost smart cards to high-speed 76 network systems. Compared to the AES, Camellia offers at least 77 comparable encryption speed in software and hardware. An optimized 78 implementation of Camellia in assembly language can encrypt on a 79 Pentium III (1.13GHz) at the rate of 471 Mbits per second. In 80 addition, a distinguishing feature is its small hardware design. The 81 current smallest hardware implementation, which includes encryption, 82 decryption, and the key schedule for 128-bit keys, occupies only 83 8.12K gates using a 0.18um CMOS ASIC library [Camellia]. This is in 84 the smallest class among all existing 128-bit block ciphers. It 85 perfectly meets one of the current IPsec market requirements, where 86 low power consumption is a mandatory condition. 88 The remainder of this document specifies the use of Camellia within 89 the context of IPsec ESP. For further information on how the various 90 pieces of ESP fit together to provide security services, please refer 91 to [ARCH], [ESP], and [ROAD]. 93 1.1 Specification of Requirements 95 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that 97 appear in this document are to be interpreted as described in 98 [RFC-2119]. 100 2. The Camellia Cipher Algorithm 102 All symmetric block cipher algorithms share common characteristics 103 and variables, including mode, key size, weak keys, block size, and 104 rounds. The following sections contain descriptions of the relevant 105 characteristics of Camellia. 107 The algorithm specification and object identifiers are described in 108 [Camellia-ID]. The Camellia homepage, 109 http://info.isl.ntt.co.jp/camellia/, contains a wealth of information 110 about camellia, including detailed specification, security analysis, 111 performance figures, reference implementation, test vectors, and 112 intellectual property information. 114 2.1 Mode 116 NIST has defined 5 modes of operation for AES and other FIPS-approved 117 ciphers [MODES]: CBC (Cipher Block Chaining), ECB (Electronic 118 CodeBook), CFB (Cipher FeedBack), OFB (Output FeedBack) and CTR 119 (Counter). The CBC mode is well-defined and well-understood for 120 symmetric ciphers, and is currently required for all other ESP 121 ciphers. This document specifies the use of the Camellia cipher in 122 CBC mode within ESP. This mode requires an Initialization Vector (IV) 123 that is the same size as the block size. Use of a randomly generated 124 IV prevents generation of identical ciphertext from packets which 125 have identical data that spans the first block of the cipher 126 algorithm's block size. 128 The IV is XOR'd with the first plaintext block before it is 129 encrypted. Then for successive blocks, the previous ciphertext block 130 is XOR'd with the current plaintext, before it is encrypted. 132 More information on CBC mode can be obtained in [MODES, CRYPTO-S]. 133 For the use of CBC mode in ESP with 64-bit ciphers, please see [CBC]. 135 2.2 Key Size 137 Camellia supports three key sizes: 128 bits, 192 bits, and 256 bits. 138 The default key size is 128 bits, and all implementations MUST 139 support this key size. Implementations MAY also support key sizes of 140 192 bits and 256 bits. 142 Camellia uses a different number of rounds for each of the defined 143 key sizes. When a 128-bit key is used, implementations MUST use 18 144 rounds. When a 192-bit key is used, implementations MUST use 24 145 rounds. When a 256-bit key is used, implementations MUST use 24 146 rounds. 148 2.3 Weak Keys 150 At the time of writing this document there are no known weak keys for 151 Camellia. 153 2.4 Block Size and Padding 155 Camellia uses a block size of sixteen octets (128 bits). 157 Padding is required by the algorithms to maintain a 16-octet 158 (128-bit) blocksize. Padding MUST be added, as specified in [ESP], 159 such that the data to be encrypted (which includes the ESP Pad Length 160 and Next Header fields) has a length that is a multiple of 16 octets. 162 Because of the algorithm specific padding requirement, no additional 163 padding is required to ensure that the ciphertext terminates on a 164 4-octet boundary (i.e. maintaining a 16-octet blocksize guarantees 165 that the ESP Pad Length and Next Header fields will be right aligned 166 within a 4-octet word). Additional padding MAY be included, as 167 specified in [ESP], as long as the 16-octet blocksize is maintained. 169 2.6 Performance 171 Performance figures of Camellia are available at 172 http://info.isl.ntt.co.jp/camellia/. It also includes performance 173 comparison with the AES cipher and other AES finalists. 174 [NESSIE] project has reported performance of Optimized Implementations 175 independently. 177 3. ESP Payload 179 Camellia was designed to follow the same API as the AES cipher. 180 Therefore, any consideration related to ESP payload is the same as 181 that of the AES cipher. Details can be found in [AES-IPSEC]. 183 4. Interaction with IKE 185 Camellia was designed to follow the same API as the AES cipher. 186 Therefore, this section defines only Phase 1 Identifier and Phase 2 187 Identifier. Any other consideration related to interaction with IKE 188 is the same as that of the AES cipher. Details can be found in 189 [AES-IPSEC]. 191 4.1 Phase 1 Identifier 193 For Phase 1 negotiations, IANA has assigned an Encryption Algorithm 194 ID of (TBD) for CAMELLIA-CBC. 196 4.2 Phase 2 Identifier 198 For Phase 2 negotiations, IANA has assigned an ESP Transform 199 Identifier of [TBD] for ESP_CAMELLIA. 201 5. Security Considerations 203 Implementations are encouraged to use the largest key sizes they can 204 when taking into account performance considerations for their 205 particular hardware and software configuration. Note that encryption 206 necessarily impacts both sides of a secure channel, so such 207 consideration must take into account not only the client side, but 208 the server as well. However, a key size of 128 bits is considered 209 secure for the foreseeable future. 211 No security problem has been found on Camellia [CRYPTREC][NESSIE]. 213 6. Intellectual Property Statement 215 The IETF takes no position regarding the validity or scope of any 216 intellectual property or other rights that might be claimed to 217 pertain to the implementation or use of the technology described 218 in this document or the extent to which any license under such 219 rights might or might not be available; neither does it represent 220 that it has made any effort to identify any such rights. 221 Information on the IETF's procedures with respect to rights in 222 standards-track and standards-related documentation can be found 223 in BCP-11. Copies of claims of rights made available for 224 publication and any assurances of licenses to be made available, 225 or the result of an attempt made to obtain a general license or 226 permission for the use of such proprietary rights by implementors 227 or users of this specification can be obtained from the IETF 228 Secretariat. 230 The IETF invites any interested party to bring to its attention 231 any copyrights, patents or patent applications, or other 232 proprietary rights which may cover technology that may be required 233 to practice this standard. Please address the information to the 234 IETF Executive Director. 236 The IETF has been notified of intellectual property rights 237 claimed in regard to some or all of the specification contained in 238 this document. For more information consult the online list of 239 claimed rights. 241 7. References 243 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard 244 (AES)," November 2001. 245 http://csrc.nist.gov/publications/fips/fips197/ 246 fips-197.{ps,pdf}. 248 [AES-IPSEC] Frankel, S., S. Kelly, and R. Glenn, "The AES Cipher 249 Algorithm and Its Use With IPsec," RFC 3602, 250 September, 2003. 252 [ARCH] Kent, S. and R. Atkinson, "Security Architecture for 253 the Internet Protocol", RFC 2401, November 1998. 255 [Camellia] Aoki, K, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 256 J. Nakajima, and T. Tokita, "Camellia: A 128-Bit Block 257 Cipher Suitable for Multiple Platforms,'' September, 258 2001, http://info.isl.ntt.co.jp/camellia/CRYPTREC/ 259 2001/01eeval.pdf. 261 [Camellia-ID] 262 Nakajima, J. and S. Moriai, "A Description of the 263 Camellia Encryption Algorithm," draft-nakajima- 264 camellia-02.txt, July, 2001. 266 [Camellia-TLS] 267 Moriai, S., "Addition of the Camellia Encryption 268 Algorithm to TLS," draft-ietf-tls-camellia-03.txt, 269 June, 2003. 271 [Camellia-SMIME] 272 Moriai, S. and Kato, A., "Use of the Camellia 273 Encryption Algorithm in CMS", 274 draft-ietf-smime-camellia-05.txt, August 2003. 276 [CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 277 Algorithms," RFC 2451, November 1998. 279 [CRYPTO-S] Schneier, B., "Applied Cryptography Second Edition", 280 John Wiley & Sons, New York, NY, 1995, ISBN 281 0-471-12845-7. 283 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 284 CRYPTREC. 285 http://www.ipa.go.jp/security/enc/CRYPTREC/ 286 index-e.html. 288 [DOI] Piper, D., "The Internet IP Security Domain of 289 Interpretation for ISAKMP," RFC 2407, November 1998. 291 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 292 Payload (ESP)", RFC 2406, November 1998. 294 [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange 295 (IKE)", RFC 2409, November 1998. 297 [MODES] Symmetric Key Block Cipher Modes of Operation, 298 http://www.nist.gov/modes/. 300 [NESSIE] The NESSIE project (New European Schemes for 301 Signatures, Integrity and Encryption), 302 http://www.cosic.esat.kuleuven.ac.be/nessie/. 304 [RFC-2026] Bradner, S., "The Internet Standards Process -- 305 Revision 3", RFC2026, October 1996. 307 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", RFC-2119, March 1997. 310 [ROAD] Thayer, R., N. Doraswamy and R. Glenn, "IP Security 311 Document Roadmap", RFC 2411, November 1998. 313 8. Authors' Addresses 315 Shiho Moriai 316 Sony Computer Entertainment Inc. 317 Phone: +81-3-6438-7523 318 FAX: +81-3-6438-8629 319 Email: camellia@isl.ntt.co.jp (Camellia team) 320 shiho@rd.scei.sony.co.jp (Shiho Moriai) 322 Satomi Okazaki 323 NTT Multimedia Communications Laboratories, Inc. 324 250 Cambridge Avenue, Suite 300 325 Palo Alto, CA 94306, USA 326 Phone: +1-650-833-3631 327 FAX: +1-650-326-1878 328 Email: satomi@nttmcl.com 330 Akihiro Kato 331 NTT Software Corporation 332 Phone: +81-45-212-7404 333 FAX: +81-45-212-7410 334 Email: akato@po.ntts.co.jp 336 9. Full Copyright Statement 338 Copyright (C) The Internet Society (1998). All Rights Reserved. 340 This document and translations of it may be copied and furnished to 341 others, and derivative works that comment on or otherwise explain it 342 or assist in its implementation may be prepared, copied, published 343 and distributed, in whole or in part, without restriction of any 344 kind, provided that the above copyright notice and this paragraph 345 are included on all such copies and derivative works. However, this 346 document itself may not be modified in any way, such as by removing 347 the copyright notice or references to the Internet Society or other 348 Internet organizations, except as needed for the purpose of 349 developing Internet standards in which case the procedures for 350 copyrights de fined in the Internet Standards process must be 351 followed, or as re quired to translate it into languages other than 352 English. 354 The limited permissions granted above are perpetual and will not be 355 revoked by the Internet Society or its successors or assigns. 357 This document and the information contained herein is provided on an 358 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 359 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 360 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 361 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 362 MERCHANT ABILITY OR FITNESS FOR A PARTICULAR PURPOSE.