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
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
Camellia密码算法及其在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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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).
本文档描述了在密码块链接模式下使用Camellia分组密码算法，并带有明确的初始化向量，作为IPsec封装安全负载（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分组密码算法，并带有明确的初始化向量，作为IPsec封装安全负载（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].
Camellia被欧盟NESSIE（新欧洲签名、完整性和加密方案）项目[NESSIE]选为推荐的加密原语，并被日本CRYPTREC（密码学研究、评估委员会）[CRYPTREC]选定为日本电子政务系统的加密技术清单. Camellia已提交给其他几个标准化机构，如ISO（ISO/IEC 18033）和IETF S/MIME邮件安全工作组[Camellia CMS]。
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支持128位块大小和128、192和256位密钥长度，即与高级加密标准（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.
Camellia是一种具有Feistel结构的对称密码。卡米利亚于2000年由NTT和三菱电机公司联合开发。它被设计来抵抗所有已知的密码分析攻击，并且已经被全世界的密码专家仔细检查过。Camellia适合在软件和硬件中实现，在软件和硬件实现中提供与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.
Camellia主页[Camellia Web]包含大量关于Camellia的信息，包括详细的规范、安全性分析、性能数据、参考实现、测试向量和知识产权信息。
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].
本文档的其余部分指定了在IPsec ESP的上下文中使用Camellia。有关ESP的各个部分如何组合在一起以提供安全服务的更多信息，请参阅[ARCH]、[ESP]和[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].
本文件中出现的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[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].
算法规范和对象标识符在[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
NIST为AES和其他FIPS批准的密码[SP800-38a]定义了五种操作模式：CBC（密码块链接）、ECB（电子码本）、CFB（密码反馈）、OFB（输出反馈）和CTR（计数器）。对称密码的CBC模式定义良好，且易于理解，目前所有其他ESP密码都需要CBC模式。本文件规定了在ESP中CBC模式下使用Camellia密码。该模式需要初始化向量
(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.
（四） 与块大小相同的大小。使用随机生成的IV可防止从具有跨越密码算法块大小的第一个块的相同数据的数据包生成相同的密码文本。
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].
CBC IV在加密前与第一个明文块异或。然后，对于连续块，前一个密文块在加密之前与当前纯文本异或。有关CBC模式的更多信息，请参见[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支持三种密钥大小：128位、192位和256位。默认密钥大小为128位，所有实现都必须支持此密钥大小。实现还可以支持192位和256位的密钥大小。
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对每个定义的关键帧大小使用不同的轮数。使用128位密钥时，实现必须使用18轮。当使用192位密钥时，实现必须使用24轮。使用256位密钥时，实现必须使用24轮。
At the time of writing this document, there are no known weak keys for Camellia.
在编写本文档时，没有已知的Camellia的弱键。
Camellia uses a block size of sixteen octets (128 bits).
Camellia使用16个八位字节（128位）的块大小。
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.
算法需要填充以保持16个八位组（128位）的块大小。必须按照[ESP]中的规定添加填充，以便要加密的数据（包括ESP填充长度和下一个标头字段）是16个八位字节的倍数。
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.
由于特定于算法的填充要求，不需要额外的填充来确保密文终止于4-八位字节边界。也就是说，保持16个八位字节的块大小可以保证ESP Pad长度和Next Header字段在4个八位字节的字内右对齐）。如[ESP]所述，只要保持16个八位组的块大小，就可以包括额外的填充。
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.
Camellia的性能数据可在[Camellia Web]上获得。该网站还包括与AES密码和其他AES入围者的性能比较。NESSIE项目[NESSIE]独立报告了优化实施的性能。
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:
ESP有效载荷由IV和原始密码文本组成。因此，[ESP]中定义的有效载荷字段根据下图进行分解：
+---------------+---------------+---------------+---------------+
| |
+ Initialization Vector (16 octets) +
| |
+---------------+---------------+---------------+---------------+
| |
~ Encrypted Payload (variable length, a multiple of 16 octets) ~
| |
+---------------------------------------------------------------+
+---------------+---------------+---------------+---------------+
| |
+ 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.
IV字段的大小必须与所用密码算法的块大小相同。静脉注射必须是随机选择的，而且必须是不可预测的。
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.
在每个数据报中包含IV可以确保每个接收到的数据报都可以被解密，即使某些数据报在传输过程中被丢弃或重新排序。
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.
为了避免对不同数据包中非常相似的明文块进行CBC加密，实现过程中不得使用计数器或其他用于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.
目前，关于Camellia和ESP的其他方面之间的交互，例如某些身份验证方案的使用，还没有已知的问题。
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.
从密钥交换协议发送到ESP算法的最小位数必须大于或等于密钥大小。密码的加密和解密密钥取自密钥材料的前128、192或256位。
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].
Camellia的设计遵循与AES密码相同的API。因此，本节仅定义阶段1标识符和阶段2标识符。与IKE交互相关的任何其他考虑事项与AES密码相同。有关详细信息，请参见[AES-IPSEC]。
For Phase 1 negotiations, IANA has assigned an Encryption Algorithm ID of 8 for CAMELLIA-CBC.
对于第1阶段协商，IANA为CAMELLIA-CBC分配了一个加密算法ID 8。
For Phase 2 negotiations, IANA has assigned an ESP Transform Identifier of 22 for ESP_CAMELLIA.
对于第2阶段谈判，IANA为ESP_CAMELLIA分配了22的ESP转换标识符。
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.
我们鼓励实现使用尽可能大的密钥大小，同时考虑其特定硬件和软件配置的性能考虑。请注意，加密必然会影响安全通道的两侧，因此这种考虑不仅要考虑客户端，还要考虑服务器。然而，128位的密钥大小在可预见的将来被认为是安全的。
No security problem has been found on Camellia [CRYPTREC][NESSIE].
在Camellia[CRYPTREC][NESSIE]上未发现任何安全问题。
IANA has assigned Encryption Algorithm ID = 8 to CAMELLIA-CBC.
IANA已将加密算法ID=8分配给CAMELLIA-CBC。
IANA has assigned ESP Transform Identifier = 22 to ESP_CAMELLIA.
IANA已将ESP转换标识符=22分配给ESP_CAMELLIA。
Portions of this text were unabashedly borrowed from [AES-IPSEC]. This work was done when the first author worked for NTT.
本文的部分内容是毫不掩饰地从[AES-IPSEC]借用的。这项工作是在第一作者为NTT工作时完成的。
[Camellia-Desc] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the Camellia Encryption Algorithm", RFC 3713, April 2004.
[Camellia Desc]Matsui，M.，Nakajima，J.，和S.Moraii，“茶花加密算法的描述”，RFC 3713，2004年4月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]Kent，S.，“IP封装安全有效负载（ESP）”，RFC 4303，2005年12月。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)," November 2001. http://csrc.nist.gov/publications/fips/fips197/ fips-197.{ps,pdf}.
[AES]NIST，FIPS PUB 197，“高级加密标准（AES）”，2001年11月。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.
[AES-IPSEC]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPSEC中的使用”，RFC 3602，2003年9月。
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[ARCH]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[Camellia-CMS] Moriai, S. and A. Kato, "Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3657, January 2004.
[Camellia CMS]Moraii，S.和A.Kato，“加密消息语法（CMS）中Camellia加密算法的使用”，RFC 3657，2004年1月。
[Camellia-Web] Camellia web site: http://info.isl.ntt.co.jp/camellia/.
[Camellia Web]Camellia网站：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.
[CRYPTO-S]Schneier，B.，“应用密码学第二版”，约翰·威利父子出版社，纽约，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.
[CRYPTREC]信息技术促进机构（IPA），日本，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.
[IKE]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[SP800-38a] Dworkin, M., "Recommendation for Block Cipher Modes of Operation - Methods and Techniques", NIST Special Publication 800-38A, December 2001.
[SP800-38a]德沃金，M.“分组密码操作模式的建议-方法和技术”，NIST特别出版物800-38a，2001年12月。
[NESSIE] The NESSIE project (New European Schemes for Signatures, Integrity and Encryption), http://www.cosic.esat.kuleuven.ac.be/nessie/.
[NESSIE]NESSIE项目（新的欧洲签名、完整性和加密方案），http://www.cosic.esat.kuleuven.ac.be/nessie/.
[ROAD] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[ROAD]Thayer，R.，Doraswamy，N.，和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Authors' Addresses
作者地址
Akihiro Kato NTT Software Corporation
加藤昭宏NTT软件公司
Phone: +81-45-212-7934
Fax: +81-45-212-7410
EMail: akato@po.ntts.co.jp
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)
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
Phone: +81-46-859-2437
Fax: +81-46-859-3365
EMail: kanda@isl.ntt.co.jp
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。