From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4312.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc4312.txt (limited to 'doc/rfc/rfc4312.txt') diff --git a/doc/rfc/rfc4312.txt b/doc/rfc/rfc4312.txt new file mode 100644 index 0000000..44c8d42 --- /dev/null +++ b/doc/rfc/rfc4312.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group A. Kato +Request for Comments: 4312 NTT Software Corporation +Category: Standards Track S. Moriai + Sony Computer Entertainment Inc. + M. Kanda + Nippon Telegraph and Telephone Corporation + December 2005 + + + The Camellia Cipher Algorithm and Its Use With IPsec + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes the use of the Camellia block cipher + algorithm in Cipher Block Chaining Mode, with an explicit + Initialization Vector, as a confidentiality mechanism within the + context of the IPsec Encapsulating Security Payload (ESP). + +1. Introduction + + This document describes the use of the Camellia block cipher + algorithm in Cipher Block Chaining Mode, with an explicit + Initialization Vector, as a confidentiality mechanism within the + context of the IPsec Encapsulating Security Payload (ESP). + + Camellia was selected as a recommended cryptographic primitive by the + EU NESSIE (New European Schemes for Signatures, Integrity and + Encryption) project [NESSIE] and was included in the list of + cryptographic techniques for Japanese e-Government systems that was + selected by the Japan CRYPTREC (Cryptography Research, Evaluation + Committees) [CRYPTREC]. Camellia has been submitted to several other + standardization bodies, such as ISO (ISO/IEC 18033) and the IETF + S/MIME Mail Security Working Group [Camellia-CMS]. + + + + + + +Kato, et al. Standards Track [Page 1] + +RFC 4312 Camellia Cipher December 2005 + + + Camellia supports 128-bit block size and 128-, 192-, and 256-bit key + lengths, i.e., the same interface specifications as the Advanced + Encryption Standard (AES) [AES]. + + Camellia is a symmetric cipher with a Feistel structure. Camillia + was developed jointly by NTT and Mitsubishi Electric Corporation in + 2000. It was designed to withstand all known cryptanalytic attacks, + and it has been scrutinized by worldwide cryptographic experts. + Camellia is suitable for implementation in software and hardware, + offering encryption speed in software and hardware implementations + that is comparable to AES. + + The Camellia homepage [Camellia-Web] contains a wealth of information + about camellia, including detailed specification, security analysis, + performance figures, reference implementation, test vectors, and + intellectual property information. + + The remainder of this document specifies the use of Camellia within + the context of IPsec ESP. For further information on how the various + pieces of ESP fit together to provide security services, please refer + to [ARCH], [ESP], and [ROAD]. + +1.1. Specification of Requirements + + The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that + appear in this document are to be interpreted as described in + [RFC-2119]. + +2. The Camellia Cipher Algorithm + + All symmetric block cipher algorithms share common characteristics + and variables, including mode, key size, weak keys, block size, and + rounds. The following sections contain descriptions of the relevant + characteristics of Camellia. + + The algorithm specification and object identifiers are described in + [Camellia-Desc]. + +2.1. Mode + + NIST has defined five modes of operation for AES and other FIPS- + approved ciphers [SP800-38a]: CBC (Cipher Block Chaining), ECB + (Electronic CodeBook), CFB (Cipher FeedBack), OFB (Output FeedBack), + and CTR (Counter). The CBC mode is well defined and well understood + for symmetric ciphers, and it is currently required for all other ESP + ciphers. This document specifies the use of the Camellia cipher in + CBC mode within ESP. This mode requires an Initialization Vector + + + +Kato, et al. Standards Track [Page 2] + +RFC 4312 Camellia Cipher December 2005 + + + (IV) size that is the same as the block size. Use of a randomly + generated IV prevents generation of identical cipher text from + packets that have identical data spanning the first block of the + cipher algorithm's block size. + + The CBC IV is XOR'd with the first plaintext block before it is + encrypted. Then, for successive blocks, the previous cipher text + block is XOR'd with the current plain text before it is encrypted. + More information on CBC mode can be obtained in [SP800-38a, + CRYPTO-S]. + +2.2. Key Size + + Camellia supports three key sizes: 128 bits, 192 bits, and 256 bits. + The default key size is 128 bits, and all implementations MUST + support this key size. Implementations MAY also support key sizes of + 192 bits and 256 bits. + + Camellia uses a different number of rounds for each of the defined + key sizes. When a 128-bit key is used, implementations MUST use 18 + rounds. When a 192-bit key is used, implementations MUST use 24 + rounds. When a 256-bit key is used, implementations MUST use 24 + rounds. + +2.3. Weak Keys + + At the time of writing this document, there are no known weak keys + for Camellia. + +2.4. Block Size and Padding + + Camellia uses a block size of sixteen octets (128 bits). + + Padding is required by the algorithms to maintain a 16-octet + (128-bit) block size. Padding MUST be added, as specified in [ESP], + such that the data to be encrypted (which includes the ESP Pad Length + and Next Header fields) is a multiple of 16 octets. + + Because of the algorithm-specific padding requirement, no additional + padding is required to ensure that the ciphertext terminates on a + 4-octet boundary. That is, maintaining a 16-octet block size + guarantees that the ESP Pad Length and Next Header fields will be + right-aligned within a 4-octet word). Additional padding MAY be + included, as specified in [ESP], as long as the 16-octet block size + is maintained. + + + + + + +Kato, et al. Standards Track [Page 3] + +RFC 4312 Camellia Cipher December 2005 + + +2.5. Performance + + Performance figures of Camellia are available at [Camellia-Web]. + This web site also includes performance comparison with the AES + cipher and other AES finalists. The NESSIE project [NESSIE] has + reported performance of Optimized Implementations independently. + +3. ESP Payload + + The ESP payload is made up of the IV followed by raw cipher-text. + Thus, the payload field, as defined in [ESP], is broken down + according to the following diagram: + + +---------------+---------------+---------------+---------------+ + | | + + Initialization Vector (16 octets) + + | | + +---------------+---------------+---------------+---------------+ + | | + ~ Encrypted Payload (variable length, a multiple of 16 octets) ~ + | | + +---------------------------------------------------------------+ + + The IV field MUST be the same size as the block size of the cipher + algorithm being used. The IV MUST be chosen at random, and MUST be + unpredictable. + + Including the IV in each datagram ensures that each received datagram + can be decrypted, even when some datagrams are dropped or re-ordered + in transit. + + To avoid CBC encryption of very similar plaintext blocks in different + packets, implementations MUST NOT use a counter or other low + Hamming-distance source for IVs. + +3.1. ESP Algorithmic Interactions + + Currently, there are no known issues regarding interactions between + the Camellia and other aspects of ESP, such as the use of certain + authentication schemes. + +3.2. Keying Material + + The minimum number of bits sent from the key exchange protocol to the + ESP algorithm must be greater than or equal to the key size. The + cipher's encryption and decryption key is taken from the first 128, + 192, or 256 bits of the keying material. + + + + +Kato, et al. Standards Track [Page 4] + +RFC 4312 Camellia Cipher December 2005 + + +4. Interaction with Internet Key Exchange [IKE] + + Camellia was designed to follow the same API as the AES cipher. + Therefore, this section defines only Phase 1 Identifier and Phase 2 + Identifier. Any other consideration related to interaction with IKE + is the same as that of the AES cipher. Details can be found in + [AES-IPSEC]. + +4.1. Phase 1 Identifier + + For Phase 1 negotiations, IANA has assigned an Encryption Algorithm + ID of 8 for CAMELLIA-CBC. + +4.2. Phase 2 Identifier + + For Phase 2 negotiations, IANA has assigned an ESP Transform + Identifier of 22 for ESP_CAMELLIA. + +5. Security Considerations + + Implementations are encouraged to use the largest key sizes they can, + taking into account performance considerations for their particular + hardware and software configuration. Note that encryption + necessarily affects both sides of a secure channel, so such + consideration must take into account not only the client side, but + also the server. However, a key size of 128 bits is considered + secure for the foreseeable future. + + No security problem has been found on Camellia [CRYPTREC][NESSIE]. + +6. IANA Considerations + + IANA has assigned Encryption Algorithm ID = 8 to CAMELLIA-CBC. + + IANA has assigned ESP Transform Identifier = 22 to ESP_CAMELLIA. + +7. Acknowledgements + + Portions of this text were unabashedly borrowed from [AES-IPSEC]. + This work was done when the first author worked for NTT. + + + + + + + + + + + +Kato, et al. Standards Track [Page 5] + +RFC 4312 Camellia Cipher December 2005 + + +8. References + +8.1. Normative References + + [Camellia-Desc] Matsui, M., Nakajima, J., and S. Moriai, "A + Description of the Camellia Encryption Algorithm", + RFC 3713, April 2004. + + [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + +8.2. Informative References + + [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard + (AES)," November 2001. + http://csrc.nist.gov/publications/fips/fips197/ + fips-197.{ps,pdf}. + + [AES-IPSEC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC + Cipher Algorithm and Its Use With IPsec," RFC 3602, + September 2003. + + [ARCH] Kent, S. and R. Atkinson, "Security Architecture for + the Internet Protocol", RFC 2401, November 1998. + + [Camellia-CMS] Moriai, S. and A. Kato, "Use of the Camellia + Encryption Algorithm in Cryptographic Message Syntax + (CMS)", RFC 3657, January 2004. + + [Camellia-Web] Camellia web site: + http://info.isl.ntt.co.jp/camellia/. + + [CRYPTO-S] Schneier, B., "Applied Cryptography Second Edition", + John Wiley & Sons, New York, NY, 1995, ISBN 0-471- + 12845-7. + + [CRYPTREC] Information-technology Promotion Agency (IPA), + Japan, CRYPTREC. + http://www.ipa.go.jp/security/enc/CRYPTREC/ index- + e.html. + + [IKE] Harkins, D. and D. Carrel, "The Internet Key + Exchange (IKE)", RFC 2409, November 1998. + + [SP800-38a] Dworkin, M., "Recommendation for Block Cipher Modes + of Operation - Methods and Techniques", NIST Special + Publication 800-38A, December 2001. + + + + +Kato, et al. Standards Track [Page 6] + +RFC 4312 Camellia Cipher December 2005 + + + [NESSIE] The NESSIE project (New European Schemes for + Signatures, Integrity and Encryption), + http://www.cosic.esat.kuleuven.ac.be/nessie/. + + [ROAD] Thayer, R., Doraswamy, N., and R. Glenn, "IP + Security Document Roadmap", RFC 2411, November 1998. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +Authors' Addresses + + Akihiro Kato + NTT Software Corporation + + Phone: +81-45-212-7934 + Fax: +81-45-212-7410 + EMail: akato@po.ntts.co.jp + + + Shiho Moriai + Sony Computer Entertainment Inc. + + Phone: +81-3-6438-7523 + Fax: +81-3-6438-8629 + EMail: camellia@isl.ntt.co.jp (Camellia team) + shiho@rd.scei.sony.co.jp (Shiho Moriai) + + + Masayuki Kanda + Nippon Telegraph and Telephone Corporation + + Phone: +81-46-859-2437 + Fax: +81-46-859-3365 + EMail: kanda@isl.ntt.co.jp + + + + + + + + + + + + + + + + +Kato, et al. Standards Track [Page 7] + +RFC 4312 Camellia Cipher December 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Kato, et al. Standards Track [Page 8] + -- cgit v1.2.3