idnits 2.17.1 draft-kato-ipsec-ciph-camellia-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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 360. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 366), 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 == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 (March 2005) is 6975 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) == Missing Reference: 'MODES' is mentioned on line 131, but not defined == Unused Reference: 'IKE' is defined on line 299, 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 (~~), 7 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 March 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 March 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 The Camellia homepage, http://info.isl.ntt.co.jp/camellia/, 85 contains a wealth of information about camellia, including 86 detailed specification, security analysis, performance figures, 87 reference implementation, test vectors, and intellectual property 88 information. 90 The remainder of this document specifies the use of Camellia within 91 the context of IPsec ESP. For further information on how the various 92 pieces of ESP fit together to provide security services, please refer 93 to [ARCH], [ESP], and [ROAD]. 95 1.1. Specification of Requirements 97 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that 99 appear in this document are to be interpreted as described in 100 [RFC-2119]. 102 2. The Camellia Cipher Algorithm 104 All symmetric block cipher algorithms share common characteristics 105 and variables, including mode, key size, weak keys, block size, and 106 rounds. The following sections contain descriptions of the relevant 107 characteristics of Camellia. 109 The algorithm specification and object identifiers are described in 111 [Camellia-Desc]. 113 2.1. Mode 115 NIST has defined 5 modes of operation for AES and other FIPS-approved 116 ciphers [SP800-38a]: CBC (Cipher Block Chaining), ECB (Electronic 117 CodeBook), CFB (Cipher FeedBack), OFB (Output FeedBack) and CTR 118 (Counter). The CBC mode is well defined and well understood for 119 symmetric ciphers, and is currently required for all other ESP 120 ciphers. This document specifies the use of the Camellia cipher in 121 CBC mode within ESP. This mode requires an Initialization Vector 122 (IV) that is the same size as the block size. Use of a randomly 123 generated IV prevents generation of identical cipher text from 124 packets, which have identical data that spans the first block of the 125 cipher algorithm's block size. 127 The CBC IV is XOR'd with the first plaintext block before it is 128 encrypted. Then for successive blocks, the previous cipher text 129 block is XOR'd with the current plain text, before it is encrypted. 131 More information on CBC mode can be obtained in [MODES, CRYPTO-S]. 132 For the use of CBC mode in ESP with 64-bit ciphers, please see [CBC]. 134 2.2. Key Size 136 Camellia supports three key sizes: 128 bits, 192 bits, and 256 bits. 137 The default key size is 128 bits, and all implementations MUST 138 support this key size. Implementations MAY also support key sizes of 139 192 bits and 256 bits. 141 Camellia uses a different number of rounds for each of the defined 142 key sizes. When a 128-bit key is used, implementations MUST use 18 143 rounds. When a 192-bit key is used, implementations MUST use 24 144 rounds. When a 256-bit key is used, implementations MUST use 24 145 rounds. 147 2.3. Weak Keys 149 At the time of writing this document there are no known weak keys for 150 Camellia. 152 2.4. Block Size and Padding 154 Camellia uses a block size of sixteen octets (128 bits). 156 Padding is required by the algorithms to maintain a 16-octet 157 (128-bit) block size. Padding MUST be added, as specified in [ESP], 158 such that the data to be encrypted (which includes the ESP Pad Length 159 and Next Header fields) has a length that is a multiple of 16 octets. 161 Because of the algorithm specific padding requirement, no additional 162 padding is required to ensure that the ciphertext terminates on a 163 4-octet boundary (i.e. maintaining a 16-octet block size guarantees 164 that the ESP Pad Length and Next Header fields will be right aligned 165 within a 4-octet word). Additional padding MAY be included, as 166 specified in [ESP], as long as the 16-octet block size is maintained. 168 2.6. Performance 170 Performance figures of Camellia are available at 171 http://info.isl.ntt.co.jp/camellia/. It also includes performance 172 comparison with the AES cipher and other AES finalists. 173 [NESSIE] project has reported performance of Optimized 174 Implementations independently. 176 3. ESP Payload 178 The ESP payload is made up of the IV followed by raw cipher-text. 179 Thus the payload field, as defined in [ESP], is broken down according 180 to the following diagram: 182 +---------------+---------------+---------------+---------------+ 183 | | 184 + Initialization Vector (16 octets) + 185 | | 186 +---------------+---------------+---------------+---------------+ 187 | | 188 ~ Encrypted Payload (variable length, a multiple of 16 octets) ~ 189 | | 190 +---------------------------------------------------------------+ 192 The IV field MUST be the same size as the block size of the cipher 193 algorithm being used. The IV MUST be chosen at random, and MUST be 194 unpredictable. 196 Including the IV in each datagram ensures that decryption of each 197 received datagram can be performed, even when some datagrams are 198 dropped, or datagrams are re-ordered in transit. 200 To avoid CBC encryption of very similar plaintext blocks in different 201 packets, implementations MUST NOT use a counter or other low-Hamming 202 distance source for IVs. 204 3.1. ESP Algorithmic Interactions 206 Currently, there are no known issues regarding interactions between 207 the Camellia and other aspects of ESP, such as use of certain 208 authentication schemes. 210 3.2. Keying Material 212 The minimum number of bits sent from the key exchange protocol to the 213 ESP algorithm must be greater than or equal to the key size. 215 The cipher's encryption and decryption key is taken from the first 216 128, 192, or 256 bits of the keying material. 218 4. Interaction with IKE 219 Camellia was designed to follow the same API as the AES cipher. 220 Therefore, this section defines only Phase 1 Identifier and Phase 2 221 Identifier. Any other consideration related to interaction with IKE 222 is the same as that of the AES cipher. Details can be found in 223 [AES-IPSEC]. 225 4.1. Phase 1 Identifier 227 For Phase 1 negotiations, IANA has assigned an Encryption Algorithm 228 ID of (TBD1) for CAMELLIA-CBC. 230 4.2. Phase 2 Identifier 232 For Phase 2 negotiations, IANA has assigned an ESP Transform 233 Identifier of (TBD2) for ESP_CAMELLIA. 235 5. Security Considerations 237 Implementations are encouraged to use the largest key sizes they can 238 when taking into account performance considerations for their 239 particular hardware and software configuration. Note that encryption 240 necessarily affects both sides of a secure channel, so such 241 consideration must take into account not only the client side, but 242 the server as well. However, a key size of 128 bits is considered 243 secure for the foreseeable future. 245 No security problem has been found on Camellia [CRYPTREC][NESSIE]. 247 6. IANA Considerations 249 IANA has assigned Encryption Algorithm ID (TBD1) to CAMELLIA-CBC. 250 IANA has assigned ESP Transform Identifier (TBD2) to ESP_CAMELLIA. 252 7. Acknowledgments 254 Portions of this text were unabashedly borrowed from [AES-IPSEC]. 256 This work was done when the first author worked for NTT. 258 8. References 260 8.1. Normative References 262 [Camellia-Desc] 263 Matsui, M., Nakajima, J., Moriai, S., "A Description of 264 the Camellia Encryption Algorithm", RFC3713, April 2004. 266 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 267 Payload (ESP)", RFC 2406, November 1998. 269 [CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 270 Algorithms," RFC 2451, November 1998. 272 8.2 Informative References 274 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard 275 (AES)," November 2001. 276 http://csrc.nist.gov/publications/fips/fips197/ 277 fips-197.{ps,pdf}. 279 [AES-IPSEC] Frankel, S., S. Kelly, and R. Glenn, "The AES Cipher 280 Algorithm and Its Use With IPsec," RFC 3602, 281 September, 2003. 283 [ARCH] Kent, S. and R. Atkinson, "Security Architecture for 284 the Internet Protocol", RFC 2401, November 1998. 286 [Camellia-CMS] 287 Moriai, S. and Kato, A., "Use of the Camellia 288 Encryption Algorithm in CMS", January 2004, RFC3657. 290 [CRYPTO-S] Schneier, B., "Applied Cryptography Second Edition", 291 John Wiley & Sons, New York, NY, 1995, ISBN 292 0-471-12845-7. 294 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 295 CRYPTREC. 296 http://www.ipa.go.jp/security/enc/CRYPTREC/ 297 index-e.html. 299 [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange 300 (IKE)", RFC 2409, November 1998. 302 [SP800-38a] Dworkin, M., "Recommendation for Block Cipher Modes of 303 Operation - Methods and Techniques", NIST Special 304 Publication 800-38A, December 2001. 306 [NESSIE] The NESSIE project (New European Schemes for 307 Signatures, Integrity and Encryption), 308 http://www.cosic.esat.kuleuven.ac.be/nessie/. 310 [ROAD] Thayer, R., N. Doraswamy and R. Glenn, "IP Security 311 Document Roadmap", RFC 2411, November 1998. 313 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", RFC-2119, March 1997. 316 9. Authors' Addresses 318 Akihiro Kato 319 NTT Software Corporation 320 Phone: +81-45-212-7934 321 FAX: +81-45-212-7410 322 Email: akato@po.ntts.co.jp 324 Shiho Moriai 325 Sony Computer Entertainment Inc. 327 Phone: +81-3-6438-7523 328 FAX: +81-3-6438-8629 329 Email: camellia@isl.ntt.co.jp (Camellia team) 330 shiho "at" rd.scei.sony.co.jp (Shiho Moriai) 332 Masayuki Kanda 333 Nippon Telegraph and Telephone Corporation 334 Phone: +81-46-859-2437 335 FAX: +81-46-859-3365 336 Email: kanda@isl.ntt.co.jp 338 10. Intellectual Property Statement 340 The IETF takes no position regarding the validity or scope of any 341 Intellectual Property Rights or other rights that might be claimed to 342 pertain to the implementation or use of the technology described in 343 this document or the extent to which any license under such rights 344 might or might not be available; nor does it represent that it has 345 made any independent effort to identify any such rights. Information 346 on the procedures with respect to rights in RFC documents can be 347 found in BCP 78 and BCP 79. 349 Copies of IPR disclosures made to the IETF Secretariat and any 350 assurances of licenses to be made available, or the result of an 351 attempt made to obtain a general license or permission for the use of 352 such proprietary rights by implementers or users of this 353 specification can be obtained from the IETF on-line IPR repository at 354 http://www.ietf.org/ipr. 356 The IETF invites any interested party to bring to its attention any 357 copyrights, patents or patent applications, or other proprietary 358 rights that may cover technology that may be required to implement 359 this standard. Please address the information to the IETF at ietf- 360 ipr@ietf.org. 362 11. Full Copyright Statement 364 Copyright (C) The Internet Society (2005). This document is subject 365 to the rights, licenses and restrictions contained in BCP 78, and 366 except as set forth therein, the authors retain all their rights. 368 This document and the information contained herein are provided on 369 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 370 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 371 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 372 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 373 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 374 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.