Internet Engineering Task Force (IETF) S. Shen
Request for Comments: 5930 Huawei
Category: Informational Y. Mao
ISSN: 2070-1721 Hangzhou H3C Tech. Co., Ltd.
NSS. Murthy
Freescale Semiconductor
July 2010
Internet Engineering Task Force (IETF) S. Shen
Request for Comments: 5930 Huawei
Category: Informational Y. Mao
ISSN: 2070-1721 Hangzhou H3C Tech. Co., Ltd.
NSS. Murthy
Freescale Semiconductor
July 2010
Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol
使用Internet密钥交换版本02（IKEv2）协议的高级加密标准计数器模式（AES-CTR）
Abstract
摘要
This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange.
本文档描述了通过互联网密钥交换版本2（IKEv2）协议使用高级加密标准计数器模式（AES-CTR）和显式初始化向量，对IKEv2交换进行加密，该交换遵循IKE_SA_INIT交换。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5930.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5930.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. IKEv2 Encrypted Payload .........................................3
3. IKEv2 Conventions ...............................................4
4. Security Considerations .........................................4
5. IANA Considerations .............................................4
6. Acknowledgments .................................................4
7. References ......................................................5
7.1. Normative References .......................................5
7.2. Informative References .....................................5
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. IKEv2 Encrypted Payload .........................................3
3. IKEv2 Conventions ...............................................4
4. Security Considerations .........................................4
5. IANA Considerations .............................................4
6. Acknowledgments .................................................4
7. References ......................................................5
7.1. Normative References .......................................5
7.2. Informative References .....................................5
The Internet Key Exchange version 2 (IKEv2) protocol [RFC4306] is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). [RFC4307] defines the set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. [RFC4307] requires that an implementation "SHOULD" support Advanced Encryption Standard [AES] Counter Mode [MODES] (AES-CTR) as a Transform Type 1 algorithm (encryption).
Internet密钥交换版本2（IKEv2）协议[RFC4306]是IPsec的一个组件，用于执行相互身份验证以及建立和维护安全关联（SA）。[RFC4307]定义了作为IKEv2一部分必须实现的一组算法，以及应该实现的算法，因为它们可能在将来某个时候升级为必须实现的算法。[RFC4307]要求实现“应”支持高级加密标准[AES]计数器模式[MODES]（AES-CTR）作为转换类型1算法（加密）。
Although [RFC4307] specifies that the AES-CTR encryption algorithm feature SHOULD be supported by IKEv2, no existing document specifies how IKEv2 can support the feature. This document provides the specification and usage of AES-CTR Counter Mode by IKEv2.
尽管[RFC4307]规定IKEv2应支持AES-CTR加密算法功能，但没有现有文件规定IKEv2如何支持该功能。本文件提供了IKEv2的AES-CTR计数器模式的规范和用法。
Implementers need to carefully consider the use of AES-CTR over the mandatory-to-implement algorithms in [RFC4307], because the performance improvements of AES-CTR are minimal in the context of
实现者需要仔细考虑使用AES-CTR来强制执行[RCF4307]中的算法，因为AES-CTR的性能改进在上下文中是最小的。
IKEv2. Furthermore, these performance improvements may be offset by the Counter Mode specific risk of a minor, hard-to-detect implementation issue resulting in total security failure.
IKEv2。此外，这些性能改进可能会被计数器模式特定的风险所抵消，该风险是一个微小的、难以检测的实现问题，导致总体安全故障。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Section 3.14 of IKEv2 [RFC4306] explains the IKEv2 Encrypted Payload. The Encrypted Payload, denoted SK{...}, contains other IKEv2 payloads in encrypted form.
IKEv2[RFC4306]的第3.14节解释了IKEv2加密的有效负载。表示为SK{…}的加密有效负载包含加密形式的其他IKEv2有效负载。
The payload includes an Initialization Vector (IV) whose length is defined by the encryption algorithm negotiated. It also includes Integrity Checksum data. These two fields are not encrypted.
有效载荷包括初始化向量（IV），其长度由协商的加密算法定义。它还包括完整性校验和数据。这两个字段未加密。
The IV field MUST be 8 octets when the AES-CTR algorithm is used for IKEv2 encryption. The requirements for this IV are the same as what is specified for the Encapsulating Security Payload (ESP) in Section 3.1 of [RFC3686].
当AES-CTR算法用于IKEv2加密时，IV字段必须为8个八位字节。本IV的要求与[RFC3686]第3.1节中针对封装安全有效载荷（ESP）规定的要求相同。
IKEv2 requires Integrity Check Data for the Encrypted Payload as described in Section 3.14 of [RFC4306]. The choice of integrity algorithms in IKEv2 is defined in [RFC4307] or documents that update it in the future.
IKEv2需要[RFC4306]第3.14节所述的加密有效负载的完整性检查数据。IKEv2中完整性算法的选择在[RFC4307]或将来更新的文档中定义。
When AES-CTR is used in IKEv2, no padding is required. The Padding field of the Encrypted Payload SHOULD be empty, and the Pad Length field SHOULD be zero. However, according to [RFC4306], the recipient MUST accept any length that results in proper alignment. It should be noted that the ESP [RFC4303] Encrypted Payload requires alignment on a 4-byte boundary while the IKEv2 [RFC4306] Encrypted Payload does not have such a requirement.
在IKEv2中使用AES-CTR时，不需要填充。加密有效负载的Padding字段应为空，Pad Length字段应为零。然而，根据[RFC4306]，接收者必须接受导致正确对齐的任何长度。应该注意的是，ESP[RFC4303]加密的有效负载需要在4字节边界上对齐，而IKEv2[RFC4306]加密的有效负载没有这样的要求。
The Encrypted Payload is the XOR of the plaintext and key stream. The key stream is generated by inputting counter blocks into the AES algorithm. The AES counter block is 128 bits, including a 4-octet Nonce, 8-octet Initialization Vector, and 4-octet Block Counter, in that order. The Block Counter begins with the value of one and increments by one to generate the next portion of the key stream. The detailed requirements for the counter block are the same as those specified in Section 4 of [RFC3686].
加密的有效负载是明文和密钥流的异或。通过将计数器块输入AES算法生成密钥流。AES计数器块为128位，按该顺序包括4个八位字节的Nonce、8个八位字节的初始化向量和4个八位字节的块计数器。块计数器从值1开始，递增1以生成密钥流的下一部分。计数器块的详细要求与[RFC3686]第4节中规定的要求相同。
The use of AES-CTR for the IKE SA is negotiated in the same way as AES-CTR for ESP. The Transform ID (ENCR_AES_CTR) is the same; the key length transform attribute is used in the same way; and the keying material (consisting of the actual key and the nonce) is derived in the same way. See Section 5 of [RFC3686] for detailed descriptions.
IKE SA使用AES-CTR的协商方式与ESP使用AES-CTR的协商方式相同。转换ID（ENCR_AES_CTR）相同；密钥长度变换属性的使用方式相同；键控材质（由实际键和nonce组成）也是以同样的方式导出的。详细说明见[RFC3686]第5节。
Security considerations explained in Section 7 of [RFC3686] are entirely relevant to this document as well. The security considerations on fresh keys and integrity protection in Section 7 of [RFC3686] are totally applicable to using AES-CTR in IKEv2; see [RFC3686] for details. As static keys are never used in IKEv2 for IKE_SA and integrity protection is mandatory for IKE_SA, these issues are not applicable for AES-CTR in IKEv2 when protecting IKE_SA.
[RFC3686]第7节中解释的安全注意事项也与本文件完全相关。[RFC3686]第7节中关于新密钥和完整性保护的安全考虑完全适用于在IKEv2中使用AES-CTR；详见[RFC3686]。由于IKEv2中从未对IKE_SA使用静态密钥，且完整性保护对IKE_SA是强制性的，因此在保护IKE_SA时，这些问题不适用于IKEv2中的AES-CTR。
Additionally, since AES has a 128-bit block size, regardless of the mode employed, the ciphertext generated by AES encryption becomes distinguishable from random values after 2^64 blocks are encrypted with a single key. Since IKEv2 SA cannot carry that much data (because of the size limit of the message ID of the IKEv2 message and the requirements for the message ID in Section 4 of [RFC4306]), this issue is not a concern here.
此外，由于AES具有128位的块大小，无论采用何种模式，AES加密生成的密文在使用单个密钥加密2^64个块后可与随机值区分开来。由于IKEv2 SA无法承载如此多的数据（由于IKEv2消息的消息ID的大小限制以及[RFC4306]第4节中对消息ID的要求），因此此处不考虑此问题。
For generic attacks on AES, such as brute force or precalculations, the key-size requirements provide reasonable security [Recommendations].
对于AES的一般攻击，如暴力或预计算，密钥大小要求提供了合理的安全性[建议]。
IANA [IANA-Para] has assigned an Encryption Algorithm Transform ID for AES-CTR encryption with an explicit IV for IKEv2: 13 as the number, and ENCR_AES_CTR as the name. IANA has added a reference to this RFC in that entry.
IANA[IANA Para]为AES-CTR加密分配了一个加密算法转换ID，IKEv2的显式IV:13作为数字，ENCR_AES_CTR作为名称。IANA在该条目中添加了对该RFC的引用。
The authors thank Yaron Sheffer, Paul Hoffman, Tero Kivinen, and Alfred Hoenes for their direction and comments on this document.
作者感谢Yaron Sheffer、Paul Hoffman、Tero Kivinen和Alfred Hoenes对本文件的指导和评论。
This document specifies usage of AES-CTR with IKEv2, similar to usage of AES-CTR with ESP as specified in [RFC3686]. The reader is referred to [RFC3686] for the same descriptions and definitions. The authors thank Russ Housley for providing the document.
本文件规定了AES-CTR与IKEv2的用法，类似于[RFC3686]中规定的AES-CTR与ESP的用法。读者可参考[RFC3686]了解相同的描述和定义。作者感谢Russ Housley提供了该文件。
During the production and modification of this document, both Huawei and CNNIC supported one of the authors, Sean Shen. Both are appreciated as affiliations of the author.
在本文件的制作和修改过程中，华为和CNNIC均支持作者之一Sean Shen。两者都被视为作者的附属机构。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效负载（ESP）”，RFC 3686，2004年1月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[RFC4307]Schiller，J.“互联网密钥交换版本2（IKEv2）中使用的加密算法”，RFC 4307，2005年12月。
[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, <http://csrc.nist.gov/ publications/fips/fips197/fips-197.pdf>.
[AES]国家标准与技术研究所，“高级加密标准（AES）”，FIPS PUB 197，2001年11月<http://csrc.nist.gov/ 出版物/fips/fips197/fips-197.pdf>。
[IANA-Para] Internet Assigned Numbers Authority, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org>.
[IANA段落]互联网分配号码管理局，“互联网密钥交换版本2（IKEv2）参数”<http://www.iana.org>.
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation -- Methods and Techniques", NIST Special Publication 800-38A, December 2001, <http://csrc.nist.gov/publications/nistpubs/ 800-38a/sp800-38a.pdf>.
[模式]德沃金，M.“分组密码操作模式的建议——方法和技术”，NIST特别出版物800-38A，2001年12月<http://csrc.nist.gov/publications/nistpubs/ 800-38a/sp800-38a.pdf>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[Recommendations] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57, March 2007, <http:// csrc.nist.gov/publications/nistpubs/800-57/ sp800-57-Part1-revised2_Mar08-2007.pdf>.
[建议]Barker，E.，Barker，W.，Burr，W.，Polk，W.，和M.Smid，“关键管理建议-第1部分：总则（修订）”，NIST特别出版物800-57，2007年3月，<http://csrc.NIST.gov/publications/nistpubs/800-57/sp800-57-Part1-revied2\u Mar08-2007.pdf>。
Authors' Addresses
作者地址
Sean Shen Huawei 4, South 4th Street, Zhongguancun Beijing 100190 China
中国北京中关村南四街4号肖恩·申华为100190
EMail: shenshuo@cnnic.cn
EMail: shenshuo@cnnic.cn
Yu Mao Hangzhou H3C Tech. Co., Ltd. Oriental Electronic Bld., No. 2 Chuangye Road Shang-Di Information Industry Hai-Dian District Beijing 100085 China
中国北京市海淀区上地信息产业创业路2号东方电子大厦杭州宇茂华三科技有限公司100085
EMail: yumao9@gmail.com
EMail: yumao9@gmail.com
N S Srinivasa Murthy Freescale Semiconductor UMA PLAZA, NAGARJUNA CIRCLE, PUNJAGUTTA HYDERABAD 500082 INDIA
印度海得拉巴PUNJAGUTTA HYDERABAD NAGARJUNA CIRCLE S Srinivasa Murthy飞思卡尔半导体乌玛广场500082
EMail: ssmurthy.nittala@freescale.com
EMail: ssmurthy.nittala@freescale.com