summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4312.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4312.txt')
-rw-r--r--doc/rfc/rfc4312.txt451
1 files changed, 451 insertions, 0 deletions
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]
+