Network Working Group R. Housley
Request for Comments: 4309 Vigil Security
Category: Standards Track December 2005
Network Working Group R. Housley
Request for Comments: 4309 Vigil Security
Category: Standards Track December 2005
Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
使用具有IPsec封装安全有效负载（ESP）的高级加密标准（AES）CCM模式
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 Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) Mode, with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity.
本文档描述了在CBC-MAC（CCM）模式下使用高级加密标准（AES）作为IPsec封装安全有效负载（ESP）机制，以提供机密性、数据源身份验证和无连接完整性。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. AES CCM Mode ....................................................2
3. ESP Payload .....................................................4
3.1. Initialization Vector (IV) .................................4
3.2. Encrypted Payload ..........................................4
3.3. Authentication Data ........................................5
4. Nonce Format ....................................................5
5. AAD Construction ................................................6
6. Packet Expansion ................................................7
7. IKE Conventions .................................................7
7.1. Keying Material and Salt Values ............................7
7.2. Phase 1 Identifier .........................................8
7.3. Phase 2 Identifier .........................................8
7.4. Key Length Attribute .......................................8
8. Test Vectors ....................................................8
9. Security Considerations .........................................8
10. Design Rationale ...............................................9
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. AES CCM Mode ....................................................2
3. ESP Payload .....................................................4
3.1. Initialization Vector (IV) .................................4
3.2. Encrypted Payload ..........................................4
3.3. Authentication Data ........................................5
4. Nonce Format ....................................................5
5. AAD Construction ................................................6
6. Packet Expansion ................................................7
7. IKE Conventions .................................................7
7.1. Keying Material and Salt Values ............................7
7.2. Phase 1 Identifier .........................................8
7.3. Phase 2 Identifier .........................................8
7.4. Key Length Attribute .......................................8
8. Test Vectors ....................................................8
9. Security Considerations .........................................8
10. Design Rationale ...............................................9
11. IANA Considerations ...........................................11
12. Acknowledgements ..............................................11
13. References ....................................................11
13.1. Normative References .....................................11
13.2. Informative References ...................................12
11. IANA Considerations ...........................................11
12. Acknowledgements ..............................................11
13. References ....................................................11
13.1. Normative References .....................................11
13.2. Informative References ...................................12
The Advanced Encryption Standard (AES) [AES] is a block cipher, and it can be used in many different modes. This document describes the use of AES in CCM (Counter with CBC-MAC) mode (AES CCM), with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) [ESP] mechanism to provide confidentiality, data origin authentication, and connectionless integrity.
高级加密标准（AES）[AES]是一种分组密码，可用于多种不同的模式。本文档描述了在CCM（带CBC-MAC的计数器）模式（AES CCM）中使用AES（带显式初始化向量（IV））作为IPsec封装安全有效负载（ESP）[ESP]机制，以提供机密性、数据源身份验证和无连接完整性。
This document does not provide an overview of IPsec. However, information about how the various components of IPsec and the way in which they collectively provide security services is available in [ARCH] and [ROAD].
本文档不提供IPsec概述。但是，[ARCH]和[ROAD]中提供了有关IPsec各个组件如何以及它们共同提供安全服务的方式的信息。
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 [STDWORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[STDWORDS]中的说明进行解释。
CCM is a generic authenticate-and-encrypt block cipher mode [CCM]. In this specification, CCM is used with the AES [AES] block cipher.
CCM是一种通用的身份验证和加密分组密码模式[CCM]。在本规范中，CCM与AES[AES]分组密码一起使用。
AES CCM has two parameters:
AES CCM有两个参数：
M M indicates the size of the integrity check value (ICV). CCM defines values of 4, 6, 8, 10, 12, 14, and 16 octets; However, to maintain alignment and provide adequate security, only the values that are a multiple of four and are at least eight are permitted. Implementations MUST support M values of 8 octets and 16 octets, and implementations MAY support an M value of 12 octets.
M表示完整性检查值（ICV）的大小。CCM定义了4、6、8、10、12、14和16个八位字节的值；但是，为了保持对齐并提供足够的安全性，只允许使用四的倍数且至少为八的值。实现必须支持8个八位字节和16个八位字节的M值，并且实现可以支持12个八位字节的M值。
L L indicates the size of the length field in octets. CCM defines values of L between 2 octets and 8 octets. This specification only supports L = 4. Implementations MUST support an L value of 4 octets, which accommodates a full Jumbogram [JUMBO]; however, the length includes all of the encrypted data, which also includes the ESP Padding, Pad Length, and Next Header fields.
L表示长度字段的大小（以八位字节为单位）。CCM定义2个八位字节和8个八位字节之间的L值。本规范仅支持L=4。实现必须支持4个八位字节的L值，这可以容纳一个完整的巨型程序[JUMBO]；但是，长度包括所有加密数据，其中还包括ESP Padding、Pad length和Next Header字段。
There are four inputs to CCM originator processing:
CCM发起人处理有四个输入：
key A single key is used to calculate the ICV using CBC-MAC and to perform payload encryption using counter mode. AES supports key sizes of 128 bits, 192 bits, and 256 bits. The default key
密钥单个密钥用于使用CBC-MAC计算ICV，并使用计数器模式执行有效负载加密。AES支持128位、192位和256位的密钥大小。默认键
size is 128 bits, and implementations MUST support this key size. Implementations MAY also support key sizes of 192 bits and 256 bits.
大小为128位，实现必须支持此密钥大小。实现还可以支持192位和256位的密钥大小。
nonce The size of the nonce depends on the value selected for the parameter L. It is 15-L octets. Implementations MUST support a nonce of 11 octets. The construction of the nonce is described in Section 4.
nonce nonce的大小取决于为参数L选择的值。它是15-L八位字节。实现必须支持11个八位字节的nonce。第4节描述了nonce的构造。
payload The payload of the ESP packet. The payload MUST NOT be longer than 4,294,967,295 octets, which is the maximum size of a Jumbogram [JUMBO]; however, the ESP Padding, Pad Length, and Next Header fields are also part of the payload.
有效载荷ESP数据包的有效载荷。有效载荷不得超过4294967295个八位字节，这是一个巨型程序[JUMBO]的最大大小；但是，ESP Padding、Pad Length和Next Header字段也是有效负载的一部分。
AAD CCM provides data integrity and data origin authentication for some data outside the payload. CCM does not allow additional authenticated data (AAD) to be longer than 18,446,744,073,709,551,615 octets. The ICV is computed from the ESP header, Payload, and ESP trailer fields, which is significantly smaller than the CCM-imposed limit. The construction of the AAD described in Section 5.
AAD CCM为有效负载之外的某些数据提供数据完整性和数据源身份验证。CCM不允许附加认证数据（AAD）的长度超过18446744073709551615个八位字节。ICV根据ESP标题、有效载荷和ESP拖车字段计算，该字段明显小于CCM施加的限制。第5节中描述的AAD施工。
AES CCM requires the encryptor to generate a unique per-packet value and to communicate this value to the decryptor. This per-packet value is one of the component parts of the nonce, and it is referred to as the initialization vector (IV). The same IV and key combination MUST NOT be used more than once. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs).
AES CCM要求加密程序生成唯一的每个数据包值，并将该值传送给解密程序。该每个分组的值是nonce的组成部分之一，它被称为初始化向量（IV）。同一IV和钥匙组合不得使用多次。加密机可以以确保唯一性的任何方式生成IV。产生IV的常用方法包括为每个数据包增加一个计数器和线性反馈移位寄存器（LFSR）。
AES CCM employs counter mode for encryption. As with any stream cipher, reuse of the same IV value with the same key is catastrophic. An IV collision immediately leaks information about the plaintext in both packets. For this reason, it is inappropriate to use this CCM with statically configured keys. Extraordinary measures would be needed to prevent reuse of an IV value with the static key across
AES CCM采用计数器模式进行加密。与任何流密码一样，使用相同密钥重复使用相同的IV值是灾难性的。IV冲突会立即泄漏两个数据包中的明文信息。因此，将此CCM与静态配置的密钥一起使用是不合适的。需要采取特殊措施，防止使用静态键重复使用IV值
power cycles. To be safe, implementations MUST use fresh keys with AES CCM. The Internet Key Exchange (IKE) [IKE] protocol or IKEv2 [IKEv2] can be used to establish fresh keys.
电力循环。为了安全起见，实现必须使用AES CCM的新密钥。因特网密钥交换（IKE）[IKE]协议或IKEv2[IKEv2]可用于建立新密钥。
The ESP payload is composed of the IV followed by the ciphertext. The payload field, as defined in [ESP], is structured as shown in Figure 1.
ESP有效载荷由IV和密文组成。[ESP]中定义的有效负载字段的结构如图1所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Encrypted Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Encrypted Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. ESP Payload Encrypted with AES CCM
图1。使用AES CCM加密的ESP有效负载
The AES CCM IV field MUST be eight octets. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is used only once for a given key. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs).
AES CCM IV字段必须为八个八位字节。加密机必须以某种方式选择IV，以确保对给定密钥只使用一次相同的IV值。加密机可以以确保唯一性的任何方式生成IV。产生IV的常用方法包括为每个数据包增加一个计数器和线性反馈移位寄存器（LFSR）。
Including the IV in each packet ensures that the decryptor can generate the key stream needed for decryption, even when some datagrams are lost or reordered.
在每个数据包中包含IV可确保解密器能够生成解密所需的密钥流，即使某些数据报丢失或重新排序。
The encrypted payload contains the ciphertext.
加密的有效负载包含密文。
AES CCM mode does not require plaintext padding. However, ESP does require padding to 32-bit word-align the authentication data. The Padding, Pad Length, and Next Header fields MUST be concatenated
AES CCM模式不需要纯文本填充。但是，ESP确实需要填充以32位字对齐身份验证数据。Padding、Pad Length和Next Header字段必须连接在一起
with the plaintext before performing encryption, as described in [ESP]. When padding is required, it MUST be generated and checked in accordance with the conventions specified in [ESP].
如[ESP]中所述，在执行加密之前使用明文。当需要填充时，必须根据[ESP]中规定的约定生成和检查填充。
AES CCM provides an encrypted ICV. The ICV provided by CCM is carried in the Authentication Data fields without further encryption. Implementations MUST support ICV sizes of 8 octets and 16 octets. Implementations MAY also support ICV 12 octets.
AES CCM提供加密的ICV。CCM提供的ICV在认证数据字段中携带，无需进一步加密。实施必须支持8个八位字节和16个八位字节的ICV大小。实现也可能支持ICV 12八位字节。
Each packet conveys the IV that is necessary to construct the sequence of counter blocks used by counter mode to generate the key stream. The AES counter block is 16 octets. One octet is used for the CCM Flags, and 4 octets are used for the block counter, as specified by the CCM L parameter. The remaining octets are the nonce. These octets occupy the second through the twelfth octets in the counter block. Figure 2 shows the format of the nonce.
每个分组传送构造计数器模式用于生成密钥流的计数器块序列所需的IV。AES计数器块为16个八位字节。根据CCM L参数的规定，一个八位字节用于CCM标志，四个八位字节用于块计数器。其余的八位字节是nonce。这些八位字节占据计数器块中的第二到第十二个八位字节。图2显示了nonce的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Nonce Format
图2。Nonce格式
The components of the nonce are as follows:
nonce的组件如下所示：
Salt The salt field is 24 bits. As the name implies, it contains an unpredictable value. It MUST be assigned at the beginning of the security association. The salt value need not be secret, but it MUST NOT be predictable prior to the beginning of the security association.
盐田是24位的。顾名思义，它包含一个不可预测的值。必须在安全关联开始时分配它。salt值不必是秘密的，但在安全关联开始之前，它不能是可预测的。
Initialization Vector The IV field is 64 bits. As described in Section 3.1, the IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is used only once for a given key.
初始化向量IV字段为64位。如第3.1节所述，加密机必须选择IV，以确保同一IV值对给定密钥仅使用一次。
This construction permits each packet to consist of up to:
这种结构允许每个包由以下部分组成：
2^32 blocks = 4,294,967,296 blocks = 68,719,476,736 octets
2^32块=4294967296块=68719476736个八位字节
This construction provides more key stream for each packet than is needed to handle any IPv6 Jumbogram [JUMBO].
这种构造为每个数据包提供了比处理任何IPv6巨型程序[JUMBO]所需的更多的密钥流。
The data integrity and data origin authentication for the Security Parameters Index (SPI) and (Extended) Sequence Number fields is provided without encrypting them. Two formats are defined: one for 32-bit sequence numbers and one for 64-bit extended sequence numbers. The format with 32-bit sequence numbers is shown in Figure 3, and the format with 64-bit extended sequence numbers is shown in Figure 4.
安全参数索引（SPI）和（扩展）序列号字段的数据完整性和数据源身份验证在不加密的情况下提供。定义了两种格式：一种用于32位序列号，另一种用于64位扩展序列号。带有32位序列号的格式如图3所示，带有64位扩展序列号的格式如图4所示。
Sequence Numbers are conveyed canonical network byte order. Extended Sequence Numbers are conveyed canonical network byte order, placing the high-order 32 bits first and the low-order 32 bits second. Canonical network byte order is fully described in RFC 791, Appendix B.
序列号以标准网络字节顺序传输。扩展序列号以标准网络字节顺序传输，将高阶32位放在第一位，低阶32位放在第二位。规范的网络字节顺序在RFC 791附录B中有完整的描述。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. AAD Format with 32-bit Sequence Number
图3。具有32位序列号的AAD格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit Extended Sequence Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit Extended Sequence Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. AAD Format with 64-bit Extended Sequence Number
图4。具有64位扩展序列号的AAD格式
The initialization vector (IV) and the integrity check value (ICV) are the only sources of packet expansion. The IV always adds 8 octets to the front of the payload. The ICV is added at the end of the payload, and the CCM parameter M determines the size of the ICV. Implementations MUST support M values of 8 octets and 16 octets, and implementations MAY also support an M value of 12 octets.
初始化向量（IV）和完整性检查值（ICV）是数据包扩展的唯一来源。IV总是在有效载荷的前端添加8个八位字节。ICV添加到有效载荷的末端，CCM参数M确定ICV的大小。实现必须支持8个八位字节和16个八位字节的M值，并且实现还可以支持12个八位字节的M值。
This section describes the conventions used to generate keying material and salt values for use with AES CCM using the Internet Key Exchange (IKE) [IKE] protocol. The identifiers and attributes needed to negotiate a security association that uses AES CCM are also defined.
本节描述了用于生成密钥材料和salt值的约定，用于使用互联网密钥交换（IKE）[IKE]协议的AES CCM。还定义了协商使用AES CCM的安全关联所需的标识符和属性。
As previously described, implementations MUST use fresh keys with AES CCM. IKE can be used to establish fresh keys. This section describes the conventions for obtaining the unpredictable salt value for use in the nonce from IKE. Note that this convention provides a salt value that is secret as well as unpredictable.
如前所述，实现必须使用AES CCM的新密钥。IKE可用于建立新密钥。本节描述了从IKE获取不可预测的salt值以便在当前使用的约定。请注意，此约定提供了一个秘密且不可预测的salt值。
IKE makes use of a pseudo-random function (PRF) to derive keying material. The PRF is used iteratively to derive keying material of arbitrary size, called KEYMAT. Keying material is extracted from the output string without regard to boundaries.
IKE利用伪随机函数（PRF）来推导键控材料。PRF被迭代地用于派生任意大小的键控材质，称为KEYMAT。从输出字符串中提取关键帧材质，而不考虑边界。
The size of KEYMAT MUST be three octets longer than is needed for the associated AES key. The keying material is used as follows:
KEYMAT的大小必须比相关AES密钥所需的长度长三个八位字节。键控材料的使用方式如下：
AES CCM with a 128-bit key The KEYMAT requested for each AES CCM key is 19 octets. The first 16 octets are the 128-bit AES key, and the remaining three octets are used as the salt value in the counter block.
具有128位密钥的AES CCM为每个AES CCM密钥请求的密钥为19个八位字节。前16个八位字节是128位AES密钥，其余三个八位字节用作计数器块中的salt值。
AES CCM with a 192-bit key The KEYMAT requested for each AES CCM key is 27 octets. The first 24 octets are the 192-bit AES key, and the remaining three octets are used as the salt value in the counter block.
具有192位密钥的AES CCM为每个AES CCM密钥请求的密钥为27个八位字节。前24个八位字节是192位AES密钥，其余三个八位字节用作计数器块中的salt值。
AES CCM with a 256-bit key The KEYMAT requested for each AES CCM key is 35 octets. The first 32 octets are the 256-bit AES key, and the remaining three octets are used as the salt value in the counter block.
具有256位密钥的AES CCM为每个AES CCM密钥请求的键盘为35个八位字节。前32个八位字节是256位AES密钥，其余三个八位字节用作计数器块中的salt值。
This document does not specify the conventions for using AES CCM for IKE Phase 1 negotiations. For AES CCM to be used in this manner, a separate specification is needed, and an Encryption Algorithm Identifier needs to be assigned.
本文件未规定将AES CCM用于IKE第1阶段协商的约定。为了以这种方式使用AES CCM，需要单独的规范，并且需要分配加密算法标识符。
For IKE Phase 2 negotiations, IANA has assigned three ESP Transform Identifiers for AES CCM with an explicit IV:
对于IKE第2阶段协商，IANA为AES CCM分配了三个ESP转换标识符，并带有显式IV：
14 for AES CCM with an 8-octet ICV; 15 for AES CCM with a 12-octet ICV; and 16 for AES CCM with a 16-octet ICV.
14用于8-八位组ICV的AES CCM；15用于AES CCM，带有12个八位组ICV；16个用于AES CCM，带有16个八位组ICV。
Because the AES supports three key lengths, the Key Length attribute MUST be specified in the IKE Phase 2 exchange [DOI]. The Key Length attribute MUST have a value of 128, 192, or 256.
由于AES支持三种密钥长度，因此必须在IKE阶段2交换[DOI]中指定密钥长度属性。密钥长度属性的值必须为128、192或256。
Section 8 of [CCM] provides test vectors that will assist implementers with AES CCM mode.
[CCM]第8节提供了测试向量，这些测试向量将帮助实施者使用AES CCM模式。
AES CCM employs counter (CTR) mode for confidentiality. If a counter value is ever used for more that one packet with the same key, then the same key stream will be used to encrypt both packets, and the confidentiality guarantees are voided.
AES CCM采用计数器（CTR）模式进行保密。如果计数器值用于多个具有相同密钥的数据包，则将使用相同的密钥流对两个数据包进行加密，并且机密性保证无效。
What happens if the encryptor XORs the same key stream with two different packet plaintexts? Suppose two packets are defined by two plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3, then both are encrypted with key stream K1, K2, K3. The two corresponding ciphertexts are:
如果加密程序使用两个不同的数据包明文对同一密钥流进行异或运算，会发生什么情况？假设两个数据包由两个明文字节序列P1、P2、P3和Q1、Q2、Q3定义，然后使用密钥流K1、K2、K3对这两个数据包进行加密。两个相应的密文是：
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
（P1异或K1），（P2异或K2），（P3异或K3）
(Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3)
（Q1异或K1）、（Q2异或K2）、（Q3异或K3）
If both of these two ciphertext streams are exposed to an attacker, then a catastrophic failure of confidentiality results, because:
如果这两个密文流都暴露给攻击者，则会导致灾难性的保密失败，因为：
(P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1
(P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2
(P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3
(P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1
(P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2
(P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3
Once the attacker obtains the two plaintexts XORed together, it is relatively straightforward to separate them. Thus, using any stream cipher, including AES CTR, to encrypt two plaintexts under the same key stream leaks the plaintext.
一旦攻击者获得两个异或在一起的明文，就可以相对直接地将它们分开。因此，使用任何流密码（包括AES CTR）对同一密钥流下的两个明文进行加密都会泄漏明文。
Therefore, AES CCM should not be used with statically configured keys. Extraordinary measures would be needed to prevent the reuse of a counter block value with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES CCM. The IKE [IKE] protocol can be used to establish fresh keys.
因此，AES CCM不应与静态配置的密钥一起使用。需要采取特殊措施，防止在整个电源循环中使用静态键重复使用计数器块值。为了安全起见，实现必须使用AES CCM的新密钥。IKE[IKE]协议可用于建立新密钥。
When IKE is used to establish fresh keys between two peer entities, separate keys are established for the two traffic flows. If a different mechanism is used to establish fresh keys, one that
当IKE用于在两个对等实体之间建立新密钥时，将为两个业务流建立单独的密钥。如果使用不同的机制建立新密钥，则
establishes only a single key to encrypt packets, then there is a high probability that the peers will select the same IV values for some packets. Thus, to avoid counter block collisions, ESP implementations that permit use of the same key for encrypting and decrypting packets with the same peer MUST ensure that the two peers assign different salt values to the security association (SA).
仅建立一个密钥来加密数据包，则对等方很可能会为某些数据包选择相同的IV值。因此，为了避免计数器块冲突，允许使用同一密钥对同一对等方的数据包进行加密和解密的ESP实现必须确保两个对等方为安全关联（SA）分配不同的salt值。
Regardless of the mode used, AES with a 128-bit key is vulnerable to the birthday attack after 2^64 blocks are encrypted with a single key. Since ESP with Extended Sequence Numbers allows for up to 2^64 packets in a single SA, there is real potential for more than 2^64 blocks to be encrypted with one key. Implementations SHOULD generate a fresh key before 2^64 blocks are encrypted with the same key, or implementations SHOULD make use of the longer AES key sizes. Note that ESP with 32-bit Sequence Numbers will not exceed 2^64 blocks even if all of the packets are maximum-length Jumbograms.
无论使用何种模式，使用128位密钥的AES在使用单个密钥加密2^64个块后容易受到生日攻击。由于具有扩展序列号的ESP在单个SA中最多允许2^64个数据包，因此使用一个密钥加密超过2^64个数据块的可能性很大。在使用相同密钥加密2^64个块之前，实现应该生成一个新密钥，或者实现应该使用更长的AES密钥大小。请注意，具有32位序列号的ESP不会超过2^64个块，即使所有数据包都是最大长度的巨型程序。
In the development of this specification, the use of the ESP sequence number field instead of an explicit IV field was considered. This section documents the rationale for the selection of an explicit IV. This selection is not a cryptographic security issue, as either approach will prevent counter block collisions.
在制定本规范时，考虑使用ESP序列号字段代替显式IV字段。本节记录了选择显式IV的基本原理。此选择不是密码安全问题，因为任何一种方法都将防止计数器块冲突。
The use of the explicit IV does not dictate the manner that the encryptor uses to assign the per-packet value in the counter block. This is desirable for several reasons.
显式IV的使用并不规定加密程序在计数器块中分配每个数据包值的方式。出于几个原因，这是可取的。
1. Only the encryptor can ensure that the value is not used for more than one packet, so there is no advantage to selecting a mechanism that allows the decryptor to determine whether counter block values collide. Damage from the collision is done, whether the decryptor detects it or not.
1. 只有加密程序才能确保该值不会用于多个数据包，因此选择允许解密程序确定计数器块值是否冲突的机制没有好处。无论解密器是否检测到碰撞，都会造成损坏。
2. The use of explicit IVs allows adders, LFSRs, and any other technique that meets the time budget of the encryptor, so long as the technique results in a unique value for each packet. Adders are simple and straightforward to implement, but due to carries, they do not execute in constant time. LFSRs offer an alternative that executes in constant time.
2. 使用显式IVs允许使用加法器、LFSR和满足加密机时间预算的任何其他技术，只要该技术为每个数据包产生唯一值。加法器的实现简单而直接，但由于进位的原因，它们不能在恒定的时间内执行。LFSR提供了一种以恒定时间执行的替代方案。
3. Complexity is in control of the implementer. Furthermore, the decision made by the implementer of the encryptor does not make the decryptor more (or less) complex.
3. 复杂性由实现者控制。此外，加密机的实现者所做的决定不会使解密机变得更复杂（或更少）。
4. The assignment of the per-packet counter block value needs to be inside the assurance boundary. Some implementations assign the sequence number inside the assurance boundary, but others do not. A sequence number collision does not have the dire consequences, but, as described in Section 6, a collision in counter block values has disastrous consequences.
4. 每包计数器块值的分配需要在保证边界内。一些实现在保证边界内分配序列号，但其他实现不分配序列号。序列号冲突不会产生可怕的后果，但如第6节所述，计数器块值冲突会产生灾难性后果。
5. Using the sequence number as the IV is possible in those architectures where the sequence number assignment is performed within the assurance boundary. In this situation, the sequence number and the IV field will contain the same value.
5. 在保证边界内执行序列号分配的架构中，可以将序列号用作IV。在这种情况下，序列号和IV字段将包含相同的值。
6. By decoupling the IV and the sequence number, architectures where the sequence number assignment is performed outside the assurance boundary are accommodated.
6. 通过解耦IV和序列号，可适应在保证边界外执行序列号分配的架构。
The use of an explicit IV field directly follows from the decoupling of the sequence number and the per-packet counter block value. The additional overhead (64 bits for the IV field) is acceptable. This overhead is significantly less overhead associated with Cipher Block Chaining (CBC) mode. As normally employed, CBC requires a full block for the IV and, on average, half of a block for padding. AES CCM confidentiality processing with an explicit IV has about one-third of the overhead as AES CBC, and the overhead is constant for each packet.
显式IV字段的使用直接遵循序列号和每包计数器块值的解耦。额外的开销（IV字段为64位）是可以接受的。这种开销大大减少了与密码块链接（CBC）模式相关的开销。与通常使用的一样，CBC需要一个完整的块用于IV，平均需要半个块用于填充。使用显式IV的AES CCM机密性处理的开销约为AES CBC的三分之一，并且每个数据包的开销是恒定的。
IANA has assigned three ESP transform numbers for use with AES CCM with an explicit IV:
IANA分配了三个ESP转换编号，用于带有显式IV的AES CCM：
14 for AES CCM with an 8-octet ICV; 15 for AES CCM with a 12-octet ICV; and 16 for AES CCM with a 16-octet ICV.
14用于8-八位组ICV的AES CCM；15用于AES CCM，带有12个八位组ICV；16个用于AES CCM，带有16个八位组ICV。
Doug Whiting and Niels Ferguson worked with me to develop CCM mode. We developed CCM mode as part of the IEEE 802.11i security effort. One of the most attractive aspects of CCM mode is that it is unencumbered by patents. I acknowledge the companies that supported the development of an unencumbered authenticated encryption mode (in alphabetical order):
Doug Whiting和Niels Ferguson与我合作开发CCM模式。作为IEEE 802.11i安全工作的一部分，我们开发了CCM模式。CCM模式最吸引人的一个方面是它不受专利的限制。我感谢支持开发无障碍认证加密模式（按字母顺序）的公司：
Hifn Intersil MacFergus RSA Security
Hifn Intersil MacFergus RSA安全
Also, I thank Tero Kivinen for his comprehensive review of this document.
此外，我感谢Tero Kivinen对本文件的全面审查。
This section provides normative and informative references.
本节提供了规范性和信息性参考。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)," November 2001.
[AES]NIST，FIPS PUB 197，“高级加密标准（AES）”，2001年11月。
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[DOI]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]Kent，S.，“IP封装安全有效负载（ESP）”，RFC 4303，2005年12月。
[CCM] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[CCM]Whiting，D.，Housley，R.，和N.Ferguson，“与CBC-MAC（CCM）对抗”，RFC 36102003年9月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[ARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[ARCH]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[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月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[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月。
[JUMBO] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[JUMBO]Borman，D.，Deering，S.和R.Hinden，“IPv6巨型程序”，RFC 26751999年8月。
Author's Address
作者地址
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com
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编辑功能的资金目前由互联网协会提供。