GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4312

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4312.txt · Last modified: 2005/12/22 00:36 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki