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).
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].
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].
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].
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].
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.
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.
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.
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:
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.
Currently, there are no known issues regarding interactions between the Camellia and other aspects of ESP, such as the use of certain authentication schemes.
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.
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].
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].
[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.
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.