idnits 2.17.00 (12 Aug 2021) /tmp/idnits53606/draft-kato-ipsec-ciph-camellia-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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 363. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 369), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 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 (January 2005) is 6334 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: 'IKE' is defined on line 304, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3713 (ref. 'Camellia-Desc') ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'ARCH') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2411 (ref. 'ROAD') (Obsoleted by RFC 6071) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft A. Kato 3 January 2005 NTT Software Corporation 4 Expiration Date: June 2005 S. Moriai 5 Sony Computer Entertainment Inc. 6 M. Kanda 7 Nippon Telegraph and Telephone Corporation 8 January 2005 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 subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 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 document may not be modified, and derivative works of it may 39 not be created, except to publish it as an RFC and to translate it 40 into languages other than English. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). All Rights Reserved. 46 Abstract 48 This document describes the use of the Camellia block cipher 49 algorithm in Cipher Block Chaining Mode, with an explicit IV, as 50 a confidentiality mechanism within the context of the IPsec 51 Encapsulating Security Payload (ESP). 53 1. Introduction 55 Camellia was selected as a recommended cryptographic primitive by 56 the EU NESSIE (New European Schemes for Signatures, Integrity and 57 Encryption) project [NESSIE] and included in the list of 58 cryptographic techniques for Japanese e-Government systems, which 59 were selected by the Japan CRYPTREC (Cryptography Research, 60 Evaluation Committees) [CRYPTREC] . Camellia has been submitted to 61 other several standardization bodies such as ISO (ISO/IEC 18033) and 62 IETF S/MIME Mail Security Working Group [Camellia-CMS]. 64 Camellia supports 128-bit block size and 128-, 192-, and 256-bit key 65 lengths, i.e. the same interface specifications as the Advanced 66 Encryption Standard (AES) [AES]. 68 Camellia was jointly developed by NTT and Mitsubishi Electric 69 Corporation in 2000. It was carefully designed to withstand all 70 known cryptanalytic attacks and even to have a sufficiently large 71 security leeway. It has been scrutinized by worldwide 72 cryptographic experts. 74 Camellia was also designed to have suitability for both software 75 and hardware implementations and to cover all possible encryption 76 applications that range from low-cost smart cards to high-speed 77 network systems. Compared to the AES, Camellia offers at least 78 comparable encryption speed in software and hardware. Camellia has a 79 Feistel structure, which is different from AES. It is rich for the 80 IPsec community that has block cipher in which was well verified by 81 the cryptographic expert with another structure. In addition, a 82 distinguishing feature is its small hardware design. 84 Camellia perfectly meets one of the current IPsec market 85 requirements, where low power consumption is a mandatory 86 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 The Camellia homepage, http://info.isl.ntt.co.jp/camellia/, 94 contains a wealth of information about camellia, including 95 detailed specification, security analysis, performance figures, 96 reference implementation, test vectors, and intellectual property 97 information. 99 1.1. Specification of Requirements 101 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that 103 appear in this document are to be interpreted as described in 104 [RFC-2119]. 106 2. The Camellia Cipher Algorithm 108 All symmetric block cipher algorithms share common characteristics 109 and variables, including mode, key size, weak keys, block size, and 110 rounds. The following sections contain descriptions of the relevant 111 characteristics of Camellia. 113 The algorithm specification and object identifiers are described in 114 [Camellia-Desc]. 116 2.1. Mode 118 NIST has defined 5 modes of operation for AES and other FIPS-approved 119 ciphers [MODES]: CBC (Cipher Block Chaining), ECB (Electronic 120 CodeBook), CFB (Cipher FeedBack), OFB (Output FeedBack) and CTR 121 (Counter). The CBC mode is well defined and well understood for 122 symmetric ciphers, and is currently required for all other ESP 123 ciphers. This document specifies the use of the Camellia cipher in 124 CBC mode within ESP. This mode requires an Initialization Vector 125 (IV) that is the same size as the block size. Use of a randomly 126 generated IV prevents generation of identical cipher text from 127 packets, which have identical data that spans the first block of the 128 cipher algorithm's block size. 130 The IV is XOR'd with the first plaintext block before it is 131 encrypted. Then for successive blocks, the previous cipher text 132 block is XOR'd with the current plain text, before it is encrypted. 134 More information on CBC mode can be obtained in [MODES, CRYPTO-S]. 135 For the use of CBC mode in ESP with 64-bit ciphers, please see [CBC]. 137 2.2. Key Size 139 Camellia supports three key sizes: 128 bits, 192 bits, and 256 bits. 140 The default key size is 128 bits, and all implementations MUST 141 support this key size. Implementations MAY also support key sizes of 142 192 bits and 256 bits. 144 Camellia uses a different number of rounds for each of the defined 145 key sizes. When a 128-bit key is used, implementations MUST use 18 146 rounds. When a 192-bit key is used, implementations MUST use 24 147 rounds. When a 256-bit key is used, implementations MUST use 24 148 rounds. 150 2.3. Weak Keys 152 At the time of writing this document there are no known weak keys for 153 Camellia. 155 2.4. Block Size and Padding 157 Camellia uses a block size of sixteen octets (128 bits). 159 Padding is required by the algorithms to maintain a 16-octet 160 (128-bit) block size. Padding MUST be added, as specified in [ESP], 161 such that the data to be encrypted (which includes the ESP Pad Length 162 and Next Header fields) has a length that is a multiple of 16 octets. 164 Because of the algorithm specific padding requirement, no additional 165 padding is required to ensure that the ciphertext terminates on a 166 4-octet boundary (i.e. maintaining a 16-octet block size guarantees 167 that the ESP Pad Length and Next Header fields will be right aligned 168 within a 4-octet word). Additional padding MAY be included, as 169 specified in [ESP], as long as the 16-octet block size is maintained. 171 2.6. Performance 173 Performance figures of Camellia are available at 174 http://info.isl.ntt.co.jp/camellia/. It also includes performance 175 comparison with the AES cipher and other AES finalists. 176 [NESSIE] project has reported performance of Optimized 177 Implementations independently. 179 3. ESP Payload 181 The ESP payload is made up of the IV followed by raw cipher-text. 182 Thus the payload field, as defined in [ESP], is broken down according 183 to the following diagram: 185 +---------------+---------------+---------------+---------------+ 186 | | 187 + Initialization Vector (16 octets) + 188 | | 189 +---------------+---------------+---------------+---------------+ 190 | | 191 ~ Encrypted Payload (variable length, a multiple of 16 octets) ~ 192 | | 193 +---------------------------------------------------------------+ 195 The IV field MUST be the same size as the block size of the cipher 196 algorithm being used. The IV MUST be chosen at random, and MUST be 197 unpredictable. 199 Including the IV in each datagram ensures that decryption of each 200 received datagram can be performed, even when some datagrams are 201 dropped, or datagrams are re-ordered in transit. 203 To avoid CBC encryption of very similar plaintext blocks in different 204 packets, implementations MUST NOT use a counter or other low-Hamming 205 distance source for IVs. 207 3.1. ESP Algorithmic Interactions 209 Currently, there are no known issues regarding interactions between 210 the Camellia and other aspects of ESP, such as use of certain 211 authentication schemes. 213 3.2. Keying Material 215 The minimum number of bits sent from the key exchange protocol to the 216 ESP algorithm must be greater than or equal to the key size. 218 The cipher's encryption and decryption key is taken from the first 219 bits of the keying material, where represents the required 220 key size. 222 4. Interaction with IKE 224 Camellia was designed to follow the same API as the AES cipher. 225 Therefore, this section defines only Phase 1 Identifier and Phase 2 226 Identifier. Any other consideration related to interaction with IKE 227 is the same as that of the AES cipher. Details can be found in 228 [AES-IPSEC]. 230 4.1. Phase 1 Identifier 232 For Phase 1 negotiations, IANA has assigned an Encryption Algorithm 233 ID of (TBD1) for CAMELLIA-CBC. 235 4.2. Phase 2 Identifier 237 For Phase 2 negotiations, IANA has assigned an ESP Transform 238 Identifier of (TBD2) for ESP_CAMELLIA. 240 5. Security Considerations 242 Implementations are encouraged to use the largest key sizes they can 243 when taking into account performance considerations for their 244 particular hardware and software configuration. Note that encryption 245 necessarily affects both sides of a secure channel, so such 246 consideration must take into account not only the client side, but 247 the server as well. However, a key size of 128 bits is considered 248 secure for the foreseeable future. 250 No security problem has been found on Camellia [CRYPTREC][NESSIE]. 252 6. IANA Considerations 254 IANA has assigned Encryption Algorithm ID (TBD1) to CAMELLIA-CBC. 255 IANA has assigned ESP Transform Identifier (TBD2) to ESP_CAMELLIA. 257 7. Acknowledgments 259 Portions of this text were unabashedly borrowed from [AES-IPSEC]. 261 This work was done when the first author worked for NTT. 263 8. References 265 8.1. Normative References 267 [Camellia-Desc] 268 Matsui, M., Nakajima, J., Moriai, S., "A Description of 269 the Camellia Encryption Algorithm", RFC3713, April 2004. 271 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 272 Payload (ESP)", RFC 2406, November 1998. 274 [CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 275 Algorithms," RFC 2451, November 1998. 277 8.2 Informative References 279 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard 280 (AES)," November 2001. 281 http://csrc.nist.gov/publications/fips/fips197/ 282 fips-197.{ps,pdf}. 284 [AES-IPSEC] Frankel, S., S. Kelly, and R. Glenn, "The AES Cipher 285 Algorithm and Its Use With IPsec," RFC 3602, 286 September, 2003. 288 [ARCH] Kent, S. and R. Atkinson, "Security Architecture for 289 the Internet Protocol", RFC 2401, November 1998. 291 [Camellia-CMS] 292 Moriai, S. and Kato, A., "Use of the Camellia 293 Encryption Algorithm in CMS", January 2004, RFC3657. 295 [CRYPTO-S] Schneier, B., "Applied Cryptography Second Edition", 296 John Wiley & Sons, New York, NY, 1995, ISBN 297 0-471-12845-7. 299 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 300 CRYPTREC. 301 http://www.ipa.go.jp/security/enc/CRYPTREC/ 302 index-e.html. 304 [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange 305 (IKE)", RFC 2409, November 1998. 307 [MODES] Symmetric Key Block Cipher Modes of Operation, 308 http://www.nist.gov/modes/. 310 [NESSIE] The NESSIE project (New European Schemes for 311 Signatures, Integrity and Encryption), 312 http://www.cosic.esat.kuleuven.ac.be/nessie/. 314 [ROAD] Thayer, R., N. Doraswamy and R. Glenn, "IP Security 315 Document Roadmap", RFC 2411, November 1998. 317 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", RFC-2119, March 1997. 320 9. Authors' Addresses 322 Akihiro Kato 323 NTT Software Corporation 324 Phone: +81-45-212-7934 325 FAX: +81-45-212-7410 326 Email: akato@po.ntts.co.jp 328 Shiho Moriai 329 Sony Computer Entertainment Inc. 330 Phone: +81-3-6438-7523 331 FAX: +81-3-6438-8629 332 Email: camellia@isl.ntt.co.jp (Camellia team) 333 shiho "at" rd.scei.sony.co.jp (Shiho Moriai) 335 Masayuki Kanda 336 Nippon Telegraph and Telephone Corporation 337 Phone: +81-46-859-2437 338 FAX: +81-46-859-3365 339 Email: kanda@isl.ntt.co.jp 341 10. Intellectual Property Statement 343 The IETF takes no position regarding the validity or scope of any 344 Intellectual Property Rights or other rights that might be claimed to 345 pertain to the implementation or use of the technology described in 346 this document or the extent to which any license under such rights 347 might or might not be available; nor does it represent that it has 348 made any independent effort to identify any such rights. Information 349 on the procedures with respect to rights in RFC documents can be 350 found in BCP 78 and BCP 79. 352 Copies of IPR disclosures made to the IETF Secretariat and any 353 assurances of licenses to be made available, or the result of an 354 attempt made to obtain a general license or permission for the use of 355 such proprietary rights by implementers or users of this 356 specification can be obtained from the IETF on-line IPR repository at 357 http://www.ietf.org/ipr. 359 The IETF invites any interested party to bring to its attention any 360 copyrights, patents or patent applications, or other proprietary 361 rights that may cover technology that may be required to implement 362 this standard. Please address the information to the IETF at ietf- 363 ipr@ietf.org. 365 11. Full Copyright Statement 367 Copyright (C) The Internet Society (2005). This document is subject 368 to the rights, licenses and restrictions contained in BCP 78, and 369 except as set forth therein, the authors retain all their rights. 371 This document and the information contained herein are provided on 372 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 373 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 374 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 375 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 376 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 377 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.