rfc4309规范原文和机翻——aead ccm

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)

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.

本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。 本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。 本备忘录的分发不受限制。

Copyright Notice

Copyright © The Internet Society (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)，具有显式初始化向量 (IV)，作为 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

11. IANA Considerations …11

12. Acknowledgements …11

13. References …11
    13.1. Normative References …11
    13.2. Informative References …12

14. Introduction

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 的概述。 但是，有关 IPsec 的各个组件如何以及它们共同提供安全服务的方式的信息可在 [ARCH] 和 [ROAD] 中找到。

1.1. Conventions Used in This Document

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] 中的描述。

2. AES CCM Mode

CCM is a generic authenticate-and-encrypt block cipher mode [CCM]. In this specification, CCM is used with the AES [AES] block cipher.

AES CCM has two parameters：
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 M 表示完整性校验值（ICV）的大小。 CCM 定义了 4、6、8、10、12、14 和 16 个八位字节的值； 但是，为了保持一致并提供足够的安全性，只允许使用 4 的倍数且至少为 8 的值。 实现必须支持 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 L 以八位字节表示长度字段的大小。 CCM 定义了介于 2 个八位字节和 8 个八位字节之间的 L 值。 本规范仅支持 L = 4。实现必须支持 4 个八位字节的 L 值，它可以容纳完整的 Jumbogram [JUMBO]； 但是，长度包括所有加密数据，其中还包括 ESP Padding、Pad Length 和 Next Header 字段。

There are four inputs to CCM originator processing:
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 size is 128 bits, and implementations MUST support this key size. Implementations MAY also support key sizes of 192 bits and 256 bits.
单个密钥用于使用 CBC-MAC 计算 ICV 并使用计数器模式执行有效载荷加密。 AES 支持 128 位、192 位和 256 位的密钥大小。 默认密钥大小为 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 的大小取决于为参数 L 选择的值。它是 15-L 个八位字节。 实现必须支持 11 个八位字节的随机数。 nonce 的构造在第 4 节中描述。
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 数据包的有效载荷。 有效载荷不得超过 4,294,967,295 个八位字节，这是 Jumbogram [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.
CCM 为有效载荷之外的一些数据提供数据完整性和数据源身份验证。 CCM 不允许额外的认证数据 (AAD) 超过 18,446,744,073,709,551,615 个八位字节。 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 要求加密器为每个数据包生成一个唯一的值并将该值传达给解密器。 每个数据包的值是随机数的组成部分之一，它被称为初始化向量 (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 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 采用计数器模式进行加密。 与任何流密码一样，使用相同的密钥重复使用相同的 IV 值是灾难性的。 IV 冲突会立即泄漏有关两个数据包中明文的信息。 因此，将此 CCM 与静态配置的密钥一起使用是不合适的。 需要采取特殊措施来防止在电源循环中使用静态密钥重复使用 IV 值。 为了安全起见，实现必须使用带有 AES CCM 的新密钥。 互联网密钥交换 (IKE) [IKE] 协议或 IKEv2 [IKEv2] 可用于建立新密钥。

3. ESP Payload

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)                ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 1.  ESP Payload Encrypted with AES CCM

3.1. Initialization Vector (IV)

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 可确保解密器可以生成解密所需的密钥流，即使某些数据报丢失或重新排序。

3.2. Encrypted Payload
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 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].
AES CCM 模式不需要纯文本填充。 但是，ESP 确实需要填充到 32 位字对齐认证数据。 Padding、Pad Length 和 Next Header 字段必须在执行加密之前与明文连接，如 [ESP] 中所述。 当需要填充时，它必须按照 [ESP] 中指定的约定生成和检查。

3.3. Authentication Data

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 携带在 Authentication Data 字段中，无需进一步加密。 实现必须支持 8 个八位字节和 16 个八位字节的 ICV 大小。 实现也可以支持 ICV 12 八位字节。

4. Nonce Format

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 个八位字节。 1 个八位字节用于 CCM 标志，4 个八位字节用于块计数器，如 CCM L 参数所指定。 剩余的八位字节是随机数。 这些八位字节占据计数器块中的第二个到第十二个八位字节。 图 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                     |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2.  Nonce Format

The components of the nonce are as follows:
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.
Salt salt 字段是 24 位。 顾名思义，它包含一个不可预测的值。 它必须在安全关联的开始分配。 盐值不需要是秘密的，但它不能在安全关联开始之前是可预测的。
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

This construction provides more key stream for each packet than is needed to handle any IPv6 Jumbogram [JUMBO].
这种结构为每个数据包提供了比处理任何 IPv6 Jumbogram [JUMBO] 所需的更多的密钥流。

5. AAD Construction

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                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 3.  AAD Format with 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                             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 64-bit Extended Sequence Number               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 4.  AAD Format with 64-bit Extended Sequence Number

6. Packet Expansion

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加在payload的末尾，CCM参数M决定了ICV的大小。 实现必须支持 8 个八位字节和 16 个八位字节的 M 值，并且实现也可以支持 12 个八位字节的 M 值。

7. IKE Conventions

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.
本节描述了用于使用 Internet 密钥交换 (IKE) [IKE] 协议生成与 AES CCM 一起使用的密钥材料和盐值的约定。 还定义了协商使用 AES CCM 的安全关联所需的标识符和属性。

7.1. Keying Material and Salt Values

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 获取用于 nonce 的不可预测的盐值的约定。 请注意，此约定提供了一个秘密且不可预测的盐值。

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.
为每个 AES CCM 密钥请求的 KEYMAT 是 19 个八位字节。 前 16 个八位字节是 128 位 AES 密钥，其余三个八位字节用作计数器块中的盐值。
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.
为每个 AES CCM 密钥请求的 KEYMAT 是 27 个八位字节。 前 24 个八位字节是 192 位 AES 密钥，其余三个八位字节用作计数器块中的盐值。
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.
为每个 AES CCM 密钥请求的 KEYMAT 是 35 个八位字节。 前 32 个八位字节是 256 位 AES 密钥，其余三个八位字节用作计数器块中的盐值。

7.2. Phase 1 Identifier

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，需要一个单独的规范，并且需要分配一个加密算法标识符。

7.3. Phase 2 Identifier

For IKE Phase 2 negotiations, IANA has assigned three ESP Transform Identifiers for AES CCM with an explicit IV:
对于 IKE 阶段 2 协商，IANA 已为 AES CCM 分配了三个具有显式 IV 的 ESP 转换标识符：

  14 for AES CCM with an 8-octet ICV;
  14 用于 AES CCM，带有 8 个八位字节的 ICV
  15 for AES CCM with a 12-octet ICV; and
  15 用于具有 12 八位字节 ICV 的 AES CCM； 和
  16 for AES CCM with a 16-octet ICV.
  16 用于具有 16 八位字节 ICV 的 AES CCM。

7.4. Key Length Attribute

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] 中指定密钥长度属性。 Key Length 属性的值必须为 128、192 或 256

8. Test Vectors

Section 8 of [CCM] provides test vectors that will assist implementers with AES CCM mode.
[CCM] 的第 8 节提供了将帮助实现者使用 AES CCM 模式的测试向量。

9. Security Considerations

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)

  (Q1 XOR K1), (Q2 XOR K2), (Q3 XOR 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

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.
一旦攻击者获得了 XOR 在一起的两个明文，将它们分开就相对简单了。 因此，使用任何流密码（包括 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 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).
当使用 IKE 在两个对等实体之间建立新密钥时，将为两个流量流建立单独的密钥。 如果使用不同的机制来建立新的密钥，即只建立一个密钥来加密数据包的机制，那么对等方很可能会为某些数据包选择相同的 IV 值。 因此，为了避免计数器块冲突，允许使用相同密钥对具有相同对等方的数据包进行加密和解密的 ESP 实现必须确保两个对等方为安全关联 (SA) 分配不同的盐值。

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.
无论使用何种模式，在使用单个密钥加密 2^64 个块后，具有 128 位密钥的 AES 容易受到生日攻击。 由于具有扩展序列号的 ESP 允许在单个 SA 中最多包含 2^64 个数据包，因此使用一个密钥加密超过 2^64 个块的可能性确实存在。 实现应该在使用相同密钥加密 2^64 块之前生成一个新密钥，或者实现应该使用更长的 AES 密钥大小。 请注意，即使所有数据包都是最大长度的 Jumbogram，具有 32 位序列号的 ESP 也不会超过 2^64 个块。

10. Design Rationale

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. 显式 IV 的使用允许加法器、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 的三分之一，并且每个数据包的开销是恒定的。

11. IANA Considerations

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;
  14 用于具有 8 八位字节 ICV 的 AES CCM；
  15 for AES CCM with a 12-octet ICV; and
  15 用于具有 12 八位字节 ICV 的 AES CCM； 和
  16 for AES CCM with a 16-octet ICV.
  16 用于具有 16 八位字节 ICV 的 AES CCM。

12. Acknowledgements

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 模式。 我们开发了 CCM 模式作为 IEEE 802.11i 安全工作的一部分。 CCM 模式最吸引人的方面之一是它不受专利的阻碍。 我感谢支持开发无障碍认证加密模式的公司（按字母顺序）：

  Hifn
  Intersil
  MacFergus
  RSA Security

Also, I thank Tero Kivinen for his comprehensive review of this document.
此外，我感谢 Tero Kivinen 对本文档的全面审查。

13. References

This section provides normative and informative references.

13.1. Normative References

[AES] NIST, FIPS PUB 197, “Advanced Encryption Standard (AES),”
November 2001.

[DOI] Piper, D., “The Internet IP Security Domain of
Interpretation for ISAKMP”, RFC 2407, November 1998.

[ESP] Kent, S., “IP Encapsulating Security Payload (ESP)”, RFC
4303, December 2005.

[CCM] Whiting, D., Housley, R., and N. Ferguson, “Counter with
CBC-MAC (CCM)”, RFC 3610, September 2003.

[STDWORDS] Bradner, S., “Key words for use in RFCs to Indicate
Requirement Levels”, BCP 14, RFC 2119, March 1997.

13.2. Informative References

[ARCH] Kent, S. and K. Seo, “Security Architecture for the
Internet Protocol”, RFC 4301, December 2005.

[IKE] Harkins, D. and D. Carrel, “The Internet Key Exchange
(IKE)”, RFC 2409, November 1998.

[IKEv2] Kaufman, C., “Internet Key Exchange (IKEv2) Protocol”,
RFC 4306, December 2005.

[ROAD] Thayer, R., Doraswamy, N., and R. Glenn, “IP Security
Document Roadmap”, RFC 2411, November 1998.

[JUMBO] Borman, D., Deering, S., and R. Hinden, “IPv6
Jumbograms”, RFC 2675, August 1999.

Author’s Address

Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA

EMail: housley@vigilsec.com

Housley Standards Track [Page 12]

RFC 4309 Using AEC CCM Mode with IPsec ESP December 2005

Full Copyright Statement

Copyright © 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.

Housley Standards Track [Page 13]