Network Working Group D. Black
Request for Comments: 5282 EMC
Updates: 4306 D. McGrew
Category: Standards Track August 2008
Network Working Group D. Black
Request for Comments: 5282 EMC
Updates: 4306 D. McGrew
Category: Standards Track August 2008
Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol
使用具有Internet密钥交换版本2（IKEv2）协议加密有效负载的认证加密算法
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）。本备忘录的分发不受限制。
Abstract
摘要
An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol.
认证加密算法将加密和完整性结合到单个操作中；此类算法也可称为加密密码的组合模式或组合模式算法。本文档描述了对Internet密钥交换版本2（IKEv2）协议的加密有效负载使用经过身份验证的加密算法。
The use of two specific authenticated encryption algorithms with the IKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload.
还描述了对IKEv2加密有效载荷使用两种特定的认证加密算法；这两种算法是Galois/计数器模式下的高级加密标准（AES）和CBC-MAC模式下的计数器中的AES（AES CCM）。其他文件可能会描述其他认证加密算法与IKEv2加密有效负载的使用。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Structure of this Document ......................................4
3. IKEv2 Encrypted Payload Data ....................................4
3.1. AES GCM and AES CCM Initialization Vector (IV) .............6
3.2. AES GCM and AES CCM Ciphertext (C) Construction ............6
4. AES GCM and AES CCM Nonce (N) Format ............................7
5. IKEv2 Associated Data (A) .......................................8
5.1. Associated Data (A) Construction ...........................8
5.2. Data Integrity Coverage ....................................8
6. AES GCM and AES CCM Encrypted Payload Expansion .................9
7. IKEv2 Conventions for AES GCM and AES CCM .......................9
7.1. Keying Material and Salt Values ............................9
7.2. IKEv2 Identifiers .........................................10
7.3. Key Length ................................................10
8. IKEv2 Algorithm Selection ......................................11
9. Test Vectors ...................................................11
10. RFC 5116 AEAD_* Algorithms ....................................11
10.1. AES GCM Algorithms with 8- and 12-octet ICVs .............12
10.1.1. AEAD_AES_128_GCM_8 ................................12
10.1.2. AEAD_AES_256_GCM_8 ................................12
10.1.3. AEAD_AES_128_GCM_12 ...............................12
10.1.4. AEAD_AES_256_GCM_12 ...............................12
10.2. AES CCM Algorithms with an 11-octet Nonce ................13
10.2.1. AEAD_AES_128_CCM_SHORT ............................13
10.2.2. AEAD_AES_256_CCM_SHORT ............................14
10.2.3. AEAD_AES_128_CCM_SHORT_8 ..........................14
10.2.4. AEAD_AES_256_CCM_SHORT_8 ..........................14
10.2.5. AEAD_AES_128_CCM_SHORT_12 .........................14
10.2.6. AEAD_AES_256_CCM_SHORT_12 .........................14
10.3. AEAD_* Algorithms and IKEv2 ..............................15
11. Security Considerations .......................................15
12. IANA Considerations ...........................................16
13. Acknowledgments ...............................................16
14. References ....................................................17
14.1. Normative References .....................................17
14.2. Informative References ...................................17
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Structure of this Document ......................................4
3. IKEv2 Encrypted Payload Data ....................................4
3.1. AES GCM and AES CCM Initialization Vector (IV) .............6
3.2. AES GCM and AES CCM Ciphertext (C) Construction ............6
4. AES GCM and AES CCM Nonce (N) Format ............................7
5. IKEv2 Associated Data (A) .......................................8
5.1. Associated Data (A) Construction ...........................8
5.2. Data Integrity Coverage ....................................8
6. AES GCM and AES CCM Encrypted Payload Expansion .................9
7. IKEv2 Conventions for AES GCM and AES CCM .......................9
7.1. Keying Material and Salt Values ............................9
7.2. IKEv2 Identifiers .........................................10
7.3. Key Length ................................................10
8. IKEv2 Algorithm Selection ......................................11
9. Test Vectors ...................................................11
10. RFC 5116 AEAD_* Algorithms ....................................11
10.1. AES GCM Algorithms with 8- and 12-octet ICVs .............12
10.1.1. AEAD_AES_128_GCM_8 ................................12
10.1.2. AEAD_AES_256_GCM_8 ................................12
10.1.3. AEAD_AES_128_GCM_12 ...............................12
10.1.4. AEAD_AES_256_GCM_12 ...............................12
10.2. AES CCM Algorithms with an 11-octet Nonce ................13
10.2.1. AEAD_AES_128_CCM_SHORT ............................13
10.2.2. AEAD_AES_256_CCM_SHORT ............................14
10.2.3. AEAD_AES_128_CCM_SHORT_8 ..........................14
10.2.4. AEAD_AES_256_CCM_SHORT_8 ..........................14
10.2.5. AEAD_AES_128_CCM_SHORT_12 .........................14
10.2.6. AEAD_AES_256_CCM_SHORT_12 .........................14
10.3. AEAD_* Algorithms and IKEv2 ..............................15
11. Security Considerations .......................................15
12. IANA Considerations ...........................................16
13. Acknowledgments ...............................................16
14. References ....................................................17
14.1. Normative References .....................................17
14.2. Informative References ...................................17
An authenticated encryption algorithm combines encryption and integrity into a single operation on plaintext data to produce ciphertext that includes an integrity check [RFC5116]. The integrity check may be an Integrity Check Value (ICV) that is logically distinct from the encrypted data, or the integrity check may be incorporated into the encrypted data that is produced. Authenticated encryption algorithms may also be referred to as combined modes of operation of a block cipher or as combined mode algorithms.
认证加密算法将加密和完整性结合到对明文数据的单一操作中，以生成包含完整性检查的密文[RFC5116]。完整性检查可以是逻辑上不同于加密数据的完整性检查值（ICV），或者可以将完整性检查合并到生成的加密数据中。经认证的加密算法也可称为分组密码的组合操作模式或组合模式算法。
An Authenticated Encryption with Associated Data (AEAD) algorithm also provides integrity protection for additional data that is associated with the plaintext, but which is left unencrypted. This document describes the use of AEAD algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol. The use of two specific AEAD algorithms with the IKEv2 Encrypted Payload is also described; the two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) [GCM] and AES in Counter with CBC-MAC Mode (AES CCM) [CCM].
通过身份验证的关联数据加密（AEAD）算法还为与明文关联但未加密的其他数据提供完整性保护。本文档描述了将AEAD算法与Internet密钥交换版本2（IKEv2）协议的加密有效负载一起使用。还描述了两种特定AEAD算法对IKEv2加密有效载荷的使用；这两种算法是Galois/计数器模式（AES GCM）[GCM]中的高级加密标准（AES）和CBC-MAC模式（AES CCM）[CCM]中的计数器中的AES。
Version 1 of the Internet Key Exchange protocol (IKEv1) [RFC2409] is based on the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]. The E (Encryption) bit in the ISAKMP header specifies that all payloads following the header are encrypted, but any data integrity verification of those payloads is handled by a separate Hash Payload or Signature Payload (see Sections 3.1, 3.11, and 3.12 of [RFC2408]). This separation of encryption from data integrity protection prevents the use of authenticated encryption with IKEv1, thus limiting initial specifications of AES combined mode usage for IPsec to the Encapsulating Security Payload (ESP) [RFC2406]. The current version of ESP is version 3, ESPv3 [RFC4303].
Internet密钥交换协议（IKEv1）[RFC2409]的版本1基于Internet安全关联和密钥管理协议（ISAKMP）[RFC2408]。ISAKMP报头中的E（加密）位指定对报头后的所有有效载荷进行加密，但这些有效载荷的任何数据完整性验证均由单独的哈希有效载荷或签名有效载荷处理（见[RFC2408]第3.1、3.11和3.12节）。这种加密与数据完整性保护的分离防止了对IKEv1使用经过身份验证的加密，从而将IPsec的AES组合模式使用的初始规范限制为封装安全有效负载（ESP）[RFC2406]。ESP的当前版本是版本3，ESPv3[RFC4303]。
Version 2 of the Internet Key Exchange Protocol (IKEv2) [RFC4306] employs an Encrypted Payload that is based on the design of ESP. The IKEv2 Encrypted Payload associates encryption and data integrity protection in a fashion that makes it possible to use AEAD algorithms.
互联网密钥交换协议（IKEv2）[RFC4306]第2版采用了基于ESP设计的加密有效载荷。IKEv2加密有效载荷将加密和数据完整性保护相关联，使使用AEAD算法成为可能。
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]中所述进行解释。
The symbols or variables that designate authenticated encryption and decryption operation inputs and outputs (K, N, P, A, and C) are
指定经过身份验证的加密和解密操作输入和输出（K、N、P、A和C）的符号或变量如下
defined in [RFC5116]. The SK_* symbols or variables that designate specific IKEv2 keys are defined in [RFC4306].
定义见[RFC5116]。[RFC4306]中定义了指定特定IKEv2键的SK_*符号或变量。
This document is based on the RFCs that describe the usage of AES GCM [RFC4106] and AES CCM [RFC4309] with ESP; hence, the introductory material and specification of the modes in those documents are not repeated here. The structure of this document follows the structure of those documents; many sections of this document indicate which sections of those two documents correspond, and call out any significant differences that implementers should be aware of. Significant portions of the text of this document have been adapted from those two documents.
本文件基于描述AES GCM[RFC4106]和AES CCM[RFC4309]与ESP结合使用的RFC；因此，这些文件中的介绍性材料和模式规范在此不再重复。本文件的结构遵循这些文件的结构；本文档的许多部分指出了这两个文档的哪些部分对应，并指出了实现者应该注意的任何重大差异。本文件的大部分文本都是根据这两份文件改编的。
This document is based on the authenticated encryption interfaces, notation, and terminology described in [RFC5116]. An important departure from [RFC4106] and [RFC4309] is that these two RFCs describe separate ciphertext and integrity check outputs of the encryption operation, whereas [RFC5116] specifies a single ciphertext (C) output that includes an integrity check. The latter more general approach encompasses authenticated encryption algorithms that produce a single, expanded ciphertext output into which the integrity check is incorporated, rather than producing separate ciphertext and integrity check outputs.
本文件基于[RFC5116]中描述的认证加密接口、符号和术语。[RFC4106]和[RFC4309]的一个重要区别是，这两个RFC描述了加密操作的单独密文和完整性检查输出，而[RFC5116]指定了包含完整性检查的单个密文（C）输出。后一种更通用的方法包括经过身份验证的加密算法，该算法生成一个单独的扩展密文输出，完整性检查被合并到该输出中，而不是生成单独的密文和完整性检查输出。
For AES GCM and AES CCM, the [RFC5116] ciphertext (C) output of authenticated encryption consists of the [RFC4106] or [RFC4309] ciphertext output concatenated with the [RFC4106] or [RFC4309] Integrity Check Value (ICV) output. This document does not modify the AES GCM or AES CCM authenticated encryption algorithms specified in [RFC4106] and [RFC4309].
对于AES GCM和AES CCM，认证加密的[RFC5116]密文（C）输出由[RFC4106]或[RFC4309]密文输出与[RFC4106]或[RFC4309]完整性检查值（ICV）输出串联而成。本文件不修改[RFC4106]和[RFC4309]中规定的AES GCM或AES CCM认证加密算法。
This section is based on [RFC5116] and Section 3.14 of [RFC4306].
本节以[RFC5116]和[RFC4306]第3.14节为基础。
For the use of authenticated encryption algorithms with the IKEv2 Encrypted Payload, this section updates Section 3.14 of [RFC4306] by replacing Figure 21 and the text that follows it (through the end of that section) with the contents of this section. In addition, Section 3.14 of [RFC4306] is also updated to allow the use of a single authenticated encryption algorithm instead of a block cipher and a separate integrity check algorithm. In contrast, Sections 3.1 and 3.2 of this document are specific to the AES GCM and AES CCM algorithms and hence do not update [RFC4306]. The updates to [RFC4306] made by this document have no effect when authenticated encryption algorithms are neither proposed nor used.
对于使用IKEv2加密有效载荷的认证加密算法，本节更新了[RFC4306]第3.14节，用本节内容替换图21及其后的文本（直到该节末尾）。此外，[RFC4306]第3.14节也进行了更新，以允许使用单一认证加密算法代替分组密码和单独的完整性检查算法。相反，本文件第3.1节和第3.2节专门针对AES GCM和AES CCM算法，因此不更新[RFC4306]。如果未提出或使用经过验证的加密算法，则本文件对[RFC4306]的更新无效。
The IKEv2 Encrypted Payload Data structure applies to all
authenticated encryption algorithms, and it is the same structure
that is used with ESP. When an authenticated encryption algorithm is
used, the IKEv2 Encrypted Payload is composed of the payload header
fields, followed by an Initialization Vector (IV) field and a
Ciphertext (C) field that includes an integrity check as shown in
Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initialization Vector !
! (length is specified by authenticated encryption algorithm) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ciphertext ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IKEv2 Encrypted Payload Data structure applies to all
authenticated encryption algorithms, and it is the same structure
that is used with ESP. When an authenticated encryption algorithm is
used, the IKEv2 Encrypted Payload is composed of the payload header
fields, followed by an Initialization Vector (IV) field and a
Ciphertext (C) field that includes an integrity check as shown in
Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initialization Vector !
! (length is specified by authenticated encryption algorithm) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ciphertext ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. IKEv2 Encrypted Payload Data for Authenticated Encryption
图1。IKEv2用于认证加密的加密有效负载数据
The Next Payload, C bit, and Payload Length fields are unchanged from [RFC4306].
下一个有效负载、C位和有效负载长度字段从[RFC4306]开始保持不变。
The contents of the Initialization Vector (IV) field are specified by the authenticated encryption algorithm; see Sections 3.1 and 4 (below) for AES GCM and AES CCM.
初始化向量（IV）字段的内容由认证加密算法指定；AES GCM和AES CCM见第3.1节和第4节（下文）。
The Ciphertext field is the output of an authenticated encryption operation (see Section 2.1 of [RFC5116]) on the following inputs:
密文字段是经过验证的加密操作（见[RFC5116]第2.1节）在以下输入上的输出：
o The secret key (K) is the cipher key obtained from the SK_ei or SK_er key, whichever is appropriate, see [RFC4306]. The authenticated encryption algorithm describes how to obtain the cipher key from SK_ei or SK_er; for AES GCM and AES CCM, see Section 7.1 (below).
o 密钥（K）是从SK_ei或SK_er密钥获得的密码密钥，以适当的为准，参见[RFC4306]。认证加密算法描述了如何从skuei或skuer获取密钥；有关AES GCM和AES CCM，请参见第7.1节（下文）。
o The nonce (N) is specified by the authenticated encryption algorithm; for AES GCM and AES CCM, see Section 4 (below). When decrypting an Encrypted Payload, a receiver constructs the nonce based on the IV in the Encrypted Payload, using rules that are specific to the authenticated encryption algorithm; see Sections 3.1 and 4 (below) for AES GCM and AES CCM.
o nonce（N）由认证加密算法指定；有关AES GCM和AES CCM，请参见第4节（下文）。当解密加密的有效载荷时，接收器使用特定于认证的加密算法的规则，基于加密的有效载荷中的IV构造nonce；AES GCM和AES CCM见第3.1节和第4节（下文）。
o The plaintext (P) consists of the concatenation of the IKE Payloads to be encrypted with the Padding (if any) and the Pad Length, as shown in Figure 2 (below). The plaintext structure in Figure 2 applies to all encryption algorithms used with the IKEv2 Encrypted Payload, and is unchanged from [RFC4306].
o 明文（P）由要用填充（如果有）和填充长度加密的IKE有效负载的串联组成，如图2（下面）所示。图2中的明文结构适用于与IKEv2加密负载一起使用的所有加密算法，与[RFC4306]相同。
o The associated data (A) is described in Section 5 (below).
o 相关数据（A）在第5节（下文）中描述。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IKE Payloads to be Encrypted ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! Padding (0-255 octets) !
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
! ! Pad Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IKE Payloads to be Encrypted ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! Padding (0-255 octets) !
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
! ! Pad Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. IKEv2 Encrypted Payload Plaintext (P)
图2。IKEv2加密有效负载明文（P）
The IKE Payloads are as specified in [RFC4306].
IKE有效载荷如[RFC4306]所述。
Padding MAY contain any value chosen by the sender.
填充可以包含发件人选择的任何值。
Pad Length is the number of octets in the Padding field. There are no alignment requirements on the length of the Padding field; the recipient MUST accept any amount of Padding up to 255 octets.
Pad Length是填充字段中的八位字节数。填充字段的长度没有对齐要求；收件人必须接受最多255个八位字节的任何填充量。
The ciphertext output of authenticated encryption algorithms, as defined by [RFC5116], incorporates data that allows checks on the integrity and authenticity of the ciphertext and associated data. Thus, there is no need for a separate Integrity Check Value (ICV) field in the IKEv2 Encrypted Payload Data structure.
[RFC5116]定义的认证加密算法的密文输出包含允许检查密文和相关数据完整性和真实性的数据。因此，在IKEv2加密有效负载数据结构中不需要单独的完整性检查值（ICV）字段。
This section is based on Section 3.1 of [RFC4106] and Section 3.1 of [RFC4309]. The Initialization Vector requirements are common to AES GCM and AES CCM, and are the same as the requirements for ESP.
本节以[RFC4106]第3.1节和[RFC4309]第3.1节为基础。初始化向量要求是AES GCM和AES CCM的共同要求，与ESP的要求相同。
The Initialization Vector (IV) 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 MAY 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).
初始化向量（IV）必须是八个八位字节。加密机必须以某种方式选择IV，以确保对给定密钥只使用一次相同的IV值。加密机可以以确保唯一性的任何方式生成IV。产生IV的常用方法包括为每个数据包增加一个计数器和线性反馈移位寄存器（LFSR）。
This section is based on Section 6 of [RFC4106] and Section 3.1 of [RFC4309] with generalizations to match the interfaces specified in [RFC5116]. The constructions for AES GCM and AES CCM are different, but in each case, the construction is the same as for ESP.
本节以[RFC4106]第6节和[RFC4309]第3.1节为基础，对[RFC5116]中规定的接口进行了概括。AES GCM和AES CCM的构造不同，但在每种情况下，构造都与ESP相同。
For AES GCM and AES CCM, the Ciphertext field consists of the output of the authenticated encryption algorithm. (Note that this field incorporates integrity check data.)
对于AES GCM和AES CCM，密文字段由经过身份验证的加密算法的输出组成。（请注意，此字段包含完整性检查数据。）
The AES GCM ICV consists solely of the AES GCM Authentication Tag. Implementations MUST support a full-length 16 octet ICV, MAY support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths.
AES GCM ICV仅由AES GCM认证标签组成。实施必须支持全长16个八位组ICV，可以支持8或12个八位组ICV，并且不得支持其他ICV长度。
AES CCM provides an encrypted ICV. Implementations MUST support ICV sizes of 8 octets and 16 octets. Implementations MAY also support 12 octet ICVs and MUST NOT support other ICV lengths.
AES CCM提供加密的ICV。实施必须支持8个八位字节和16个八位字节的ICV大小。实施还可能支持12个八位组ICV，且不得支持其他ICV长度。
Specific authenticated encryption algorithms MAY use different nonce formats, but they SHOULD use the default nonce format specified in this section.
特定的经过身份验证的加密算法可以使用不同的nonce格式，但它们应该使用本节中指定的默认nonce格式。
The default nonce format uses partially implicit nonces (see Section 3.2.1 of [RFC5116]) as follows:
默认的nonce格式使用部分隐式nonce（见[RFC5116]第3.2.1节），如下所示：
o The implicit portion of the nonce is the salt that is part of the IKEv2 Keying Material shared by the encryptor and decryptor (see Section 7.1); the salt is not included in the IKEv2 Encrypted Payload.
o nonce的隐式部分是salt，它是加密机和解密机共享的IKEv2密钥材料的一部分（参见第7.1节）；salt不包括在IKEv2加密负载中。
o The explicit portion of the nonce is the IV that is included in the IKEv2 Encrypted Payload.
o nonce的显式部分是包含在IKEv2加密负载中的IV。
When this default nonce format is used, both the encryptor and decryptor construct the nonce by concatenating the salt with the IV, in that order.
当使用此默认nonce格式时，加密程序和解密程序都通过按顺序将salt与IV连接起来来构造nonce。
For the use of AES GCM with the IKEv2 Encrypted Payload, this default nonce format MUST be used and a 12 octet nonce MUST be used. Note that this format matches the one specified in Section 4 of [RFC4106], providing compatibility between the use of AES GCM in IKEv2 and ESP. All of the requirements of Section 4 of [RFC4106] apply to the use of AES GCM with the IKEv2 Encrypted Payload.
对于将AES GCM与IKEv2加密负载一起使用，必须使用此默认的nonce格式，并且必须使用12个八位字节的nonce。请注意，该格式与[RFC4106]第4节中规定的格式相匹配，提供了在IKEv2和ESP中使用AES GCM之间的兼容性。[RFC4106]第4节中的所有要求均适用于在IKEv2加密有效负载中使用AES GCM。
For the use of AES CCM with the IKEv2 Encrypted Payload, this default nonce format MUST be used and an 11 octet nonce MUST be used. Note that this format matches the one specified in Section 4 of [RFC4309], providing compatibility between the use of AES CCM in IKEv2 and ESP. All of the requirements of Section 4 of [RFC4309] apply to the use of AES CCM with the IKEv2 Encrypted Payload.
对于将AES CCM与IKEv2加密有效负载一起使用，必须使用此默认nonce格式，并且必须使用11个八位字节的nonce。请注意，该格式与[RFC4309]第4节中规定的格式相匹配，提供了在IKEv2和ESP中使用AES CCM之间的兼容性。[RFC4309]第4节中的所有要求均适用于在IKEv2加密有效负载中使用AES CCM。
This section is based on Section 5 of [RFC4106] and Section 5 of [RFC4309], both of which refer to associated data as Additional Authenticated Data (AAD). The associated data construction described in this section applies to all authenticated encryption algorithms, but differs from the construction used with ESP because IKEv2 requires different data integrity coverage.
本节以[RFC4106]第5节和[RFC4309]第5节为基础，两者都将相关数据称为附加认证数据（AAD）。本节中描述的相关数据构造适用于所有经过身份验证的加密算法，但与ESP使用的构造不同，因为IKEv2需要不同的数据完整性覆盖率。
The associated data (A) MUST consist of the partial contents of the IKEv2 message, starting from the first octet of the Fixed IKE Header through the last octet of the Payload Header of the Encrypted Payload (i.e., the fourth octet of the Encrypted Payload), as shown in Figure 3. This includes any payloads that are between the Fixed IKE Header and the Encrypted Payload.
关联数据（A）必须由IKEv2消息的部分内容组成，从固定IKE头的第一个八位组开始，到加密有效负载的有效负载头的最后一个八位组（即，加密有效负载的第四个八位组），如图3所示。这包括固定IKE头和加密有效负载之间的任何有效负载。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IKEv2 Header ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Unencrypted IKE Payloads ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IKEv2 Header ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Unencrypted IKE Payloads ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. IKEv2 Encrypted Payload Associated Data (A) for Authenticated Encryption
图3。IKEv2用于认证加密的加密有效负载相关数据（A）
The Initialization Vector and Ciphertext fields shown in Figure 1 (above) MUST NOT be included in the associated data.
相关数据中不得包含图1（上图）所示的初始化向量和密文字段。
The data integrity coverage of the IKEv2 Encrypted Payload encompasses the entire IKEv2 message that contains the Encrypted Payload. When an authenticated encryption algorithm is used with the Encrypted Payload, this coverage is realized as follows:
IKEv2加密负载的数据完整性覆盖范围包括包含加密负载的整个IKEv2消息。当认证的加密算法与加密的有效负载一起使用时，该覆盖范围实现如下：
1. The associated data (A) covers the portion of the IKEv2 message starting from the first octet of the Fixed IKE Header through the last octet of the Payload Header of the Encrypted Payload (fourth octet of the Encrypted Payload). This includes any Payloads between the Fixed IKE Header and the Encrypted Payload. The Encrypted Payload is always the last payload in an IKEv2 message [RFC4306].
1. 关联数据（A）覆盖IKEv2消息的部分，该部分从固定IKE报头的第一个八位组开始，一直到加密有效载荷的有效载荷报头的最后一个八位组（加密有效载荷的第四个八位组）。这包括固定IKE头和加密有效负载之间的任何有效负载。加密的有效负载始终是IKEv2消息[RFC4306]中的最后一个有效负载。
2. The IV is an input to the authenticated encryption algorithm's integrity check. A successful integrity check at the receiver verifies that the correct IV was used, providing data integrity coverage for the IV.
2. IV是经过身份验证的加密算法完整性检查的输入。接收器处的成功完整性检查验证使用了正确的IV，从而为IV提供了数据完整性覆盖。
3. The plaintext (IKE Payloads, Padding and Pad Length) is covered by the authenticated encryption algorithm's integrity check.
3. 明文（IKE有效载荷、填充和填充长度）由经过身份验证的加密算法的完整性检查覆盖。
The expansion described in Section 7 of [RFC4106] and Section 6 of [RFC4309] applies to the use of the AES GCM and AES CCM combined modes with the IKEv2 Encrypted Payload. See Section 7 of [RFC4106] and Section 6 of [RFC4309].
[RFC4106]第7节和[RFC4309]第6节中描述的扩展适用于AES GCM和AES CCM组合模式与IKEv2加密有效负载的使用。参见[RFC4106]第7节和[RFC4309]第6节。
This section describes the conventions used to generate keying material and salt values for use with AES GCM and AES CCM using the IKEv2 [RFC4306] protocol. The identifiers and attributes needed to use AES GCM and AES CCM with the IKEv2 Encrypted Payload are also specified.
本节描述了用于生成键控材料和salt值的约定，以用于使用IKEv2[RFC4306]协议的AES GCM和AES CCM。还指定了将AES GCM和AES CCM与IKEv2加密负载一起使用所需的标识符和属性。
This section is based on Section 8.1 of [RFC4106] and Section 7.1 of [RFC4309]. The Keying Material and Salt Values for AES GCM and AES CCM are different, but have the same structure as the Keying Material and Salt Values used with ESP.
本节以[RFC4106]第8.1节和[RFC4309]第7.1节为基础。AES GCM和AES CCM的键控材料和盐值不同，但结构与ESP使用的键控材料和盐值相同。
IKEv2 makes use of a Pseudo-Random Function (PRF) to derive keying material. The PRF is used iteratively to derive keying material of arbitrary size, from which keying material for specific uses is extracted without regard to PRF output boundaries; see Section 2.14 of [RFC4306].
IKEv2利用伪随机函数（PRF）导出键控材料。重复使用PRF来导出任意大小的键控材料，从中提取用于特定用途的键控材料，而不考虑PRF输出边界；见[RFC4306]第2.14节。
This subsection describes how the key derivation specified in Section 2.14 of [RFC4306] is used to obtain keying material for AES GCM and AES CCM. When AES GCM or AES CCM is used with the IKEv2 Encrypted Payload, the SK_ai and SK_ar integrity protection keys are not used; each key MUST be treated as having a size of zero (0) octets. The size of each of the SK_ei and SK_er encryption keys includes additional salt bytes. The size and format of each of the SK_ei and SK_er encryption keys MUST be:
本小节描述了如何使用[RFC4306]第2.14节中规定的密钥派生来获取AES GCM和AES CCM的密钥材料。当AES GCM或AES CCM与IKEv2加密有效载荷一起使用时，不使用SK_ai和SK_ar完整性保护密钥；每个密钥必须被视为具有零（0）个八位字节的大小。每个SK_ei和SK_er加密密钥的大小包括额外的salt字节。SK_ei和SK_er加密密钥的大小和格式必须为：
o For AES GCM, each encryption key has the size and format of the "KEYMAT requested" material specified in Section 8.1 of [RFC4106] for the AES key size being used. For example, if the AES key size
o 对于AES GCM，每个加密密钥的大小和格式与[RFC4106]第8.1节中针对所用AES密钥大小规定的“KEYMAT requested”材料的大小和格式相同。例如，如果AES密钥大小
is 128 bits, each encryption key is 20 octets, consisting of a 16-octet AES cipher key followed by 4 octets of salt.
是128位，每个加密密钥是20个八位字节，由16个八位字节的AES密码密钥和4个八位字节的salt组成。
o For AES CCM, each key has the size and format of the "KEYMAT requested" material specified in Section 7.1 of [RFC4309] for the AES key size being used. For example, if the AES key size is 128 bits, each encryption key is 19 octets, consisting of a 16-octet AES cipher key followed by 3 octets of salt.
o 对于AES CCM，每个密钥具有[RFC4309]第7.1节中规定的AES密钥大小的“KEYMAT requested”材料的大小和格式。例如，如果AES密钥大小为128位，则每个加密密钥为19个八位字节，由16个八位字节的AES密码密钥和3个八位字节的salt组成。
This section is unique to the IKEv2 Encrypted Payload usage of AES GCM and AES CCM. It reuses the identifiers used to negotiate ESP usage of AES GCM and AES CCM.
本节仅适用于AES GCM和AES CCM的IKEv2加密有效负载使用。它重用用于协商AES GCM和AES CCM的ESP使用的标识符。
The following identifiers, previously allocated by IANA, are used to negotiate the use of AES GCM and AES CCM as the Encryption (ENCR) Transform for IKEv2 (i.e., for use with the IKEv2 Encrypted Payload):
先前由IANA分配的以下标识符用于协商将AES GCM和AES CCM用作IKEv2的加密（ENCR）转换（即用于IKEv2加密有效负载）：
14 for AES CCM with an 8-octet ICV;
15 for AES CCM with a 12-octet ICV;
16 for AES CCM with a 16-octet ICV;
14 for AES CCM with an 8-octet ICV;
15 for AES CCM with a 12-octet ICV;
16 for AES CCM with a 16-octet ICV;
18 for AES GCM with an 8-octet ICV; 19 for AES GCM with a 12-octet ICV; and 20 for AES GCM with a 16-octet ICV.
18例AES GCM，8-八位体ICV；19个AES GCM，带有12个八位组ICV；AES GCM和16个八位组ICV各20例。
A 16-octet ICV size SHOULD be used with IKEv2, as the higher level of security that it provides by comparison to smaller ICV sizes is appropriate to IKEv2's key exchange and related functionality.
IKEv2应使用16个八位组的ICV大小，因为与较小的ICV大小相比，它提供的更高安全级别适用于IKEv2的密钥交换和相关功能。
In general, the use of 12-octet ICVs (values 15 and 19) is NOT RECOMMENDED in order to reduce the number of options for ICV size. If an ICV size larger than 8 octets is appropriate, 16-octet ICVs SHOULD be used.
一般来说，不建议使用12个八位组ICV（值15和19），以减少ICV尺寸的选项数量。如果ICV大小大于8个八位字节是合适的，则应使用16个八位字节ICV。
This section is based on Section 8.4 of [RFC4106] and Section 7.4 of [RFC4309]. The Key Length requirements are common to AES GCM and AES CCM and are identical to the key length requirements for ESP.
本节以[RFC4106]第8.4节和[RFC4309]第7.4节为基础。密钥长度要求是AES GCM和AES CCM的共同要求，与ESP的密钥长度要求相同。
Because the AES supports three key lengths, the Key Length attribute MUST be specified when any of the identifiers for AES GCM or AES CCM, specified in Section 7.2 of this document, is used. The Key Length attribute MUST have a value of 128, 192, or 256. The use of the value 192 is NOT RECOMMENDED. If an AES key larger than 128 bits is
由于AES支持三种密钥长度，因此在使用本文件第7.2节中规定的AES GCM或AES CCM的任何标识符时，必须指定密钥长度属性。密钥长度属性的值必须为128、192或256。不建议使用值192。如果使用大于128位的AES密钥
appropriate, a 256-bit AES key SHOULD be used. This reduces the number of options for AES key length.
在适当情况下，应使用256位AES密钥。这减少了AES密钥长度选项的数量。
This section applies to the use of any authenticated encryption algorithm with the IKEv2 Encrypted Payload and is unique to that usage.
本节适用于任何经过身份验证的加密算法与IKEv2加密的有效负载的使用，并且是该用法所独有的。
IKEv2 (Section 3.3.3 of [RFC4306]) specifies that both an encryption algorithm and an integrity checking algorithm are required for an IKE SA (Security Association). This document updates [RFC4306] to require that when an authenticated encryption algorithm is selected as the encryption algorithm for any SA (IKE or ESP), an integrity algorithm MUST NOT be selected for that SA. This document further updates [RFC4306] to require that if all of the encryption algorithms in any proposal are authenticated encryption algorithms, then the proposal MUST NOT propose any integrity transforms.
IKEv2（RFC4306第3.3.3节）规定，IKE SA（安全关联）需要加密算法和完整性检查算法。本文件更新了[RFC4306]，要求当选择经过身份验证的加密算法作为任何SA（IKE或ESP）的加密算法时，不得为该SA选择完整性算法。本文件进一步更新了[RFC4306]，要求如果任何方案中的所有加密算法都是经过验证的加密算法，则该方案不得提出任何完整性转换。
See Section 9 of [RFC4106] and Section 8 of [RFC4309] for references that provide AES GCM and AES CCM test vectors.
有关提供AES GCM和AES CCM测试向量的参考资料，请参见[RFC4106]第9节和[RFC4309]第8节。
This section adds new algorithms to the AEAD_* algorithm framework defined in [RFC5116] to encompass the usage of AES GCM and AES CCM with IKEv2. An AEAD_* algorithm does not have any attributes or parameters; each AEAD_* algorithm identifier defined in this document completely specifies the AES key size and the ICV size to be used (e.g., AEAD_AES_128_GCM uses a 128-bit AES key and a 16-octet ICV).
本节将新算法添加到[RFC5116]中定义的AEAD_*算法框架中，以涵盖AES GCM和AES CCM与IKEv2的使用。AEAD_*算法没有任何属性或参数；本文档中定义的每个AEAD_u*算法标识符完全指定了AES密钥大小和要使用的ICV大小（例如，AEAD_AES_128_GCM使用128位AES密钥和16个八位ICV）。
AEAD_* algorithm coverage of the AES GCM and AES CCM authenticated encryption algorithms used with IKEv2 requires specification of eight additional AEAD_* algorithms beyond the four algorithms specified in [RFC5116]:
与IKEv2一起使用的AES GCM和AES CCM认证加密算法的AEAD算法覆盖范围要求在[RFC5116]中规定的四种算法之外指定八种额外的AEAD算法：
o Four AEAD_* algorithms are specified to allow 8- and 12-octet ICVs to be used with the AES GCM and AEAD_* algorithms specified in [RFC5116].
o 规定了四种AEAD_*算法，以允许8和12个八位组ICV与[RFC5116]中规定的AES GCM和AEAD_*算法一起使用。
o The version of AES CCM used with IPsec (see [RFC4309]) uses an 11-octet nonce instead of the 12-octet nonce used by the version of AES CCM specified in [RFC5116]. Six AEAD_* algorithms are specified for this short nonce version of AES CCM.
o 与IPsec一起使用的AES CCM版本（参见[RFC4309]）使用11个八位字节的nonce，而不是[RFC5116]中指定的AES CCM版本使用的12个八位字节的nonce。为AES CCM的这一短nonce版本指定了六种AEAD_*算法。
This document recommends against the use of 192-bit AES keys, and therefore does not specify AEAD_* algorithms for 192-bit AES keys.
本文档建议不要使用192位AES密钥，因此没有为192位AES密钥指定AEAD_*算法。
The following four AEAD_* algorithms are identical to the AEAD_* algorithms specified in [RFC5116], except that an 8-octet ICV is used instead of a 16-octet ICV.
以下四种AEAD_*算法与[RFC5116]中规定的AEAD_*算法相同，不同之处在于使用了8个八位组的ICV而不是16个八位组的ICV。
This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of [RFC5116]), except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used.
该算法与AEAD_AES_128_GCM（见[RFC5116]第5.1节）相同，只是标记长度t为8，并且使用长度为8个八位字节（64位）的认证标记。
An AEAD_AES_128_GCM_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
AEAD_AES_128_GCM_8密文正好比其相应的明文长8个八位字节。
This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of [RFC5116]), except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used.
该算法与AEAD_AES_256_GCM（见[RFC5116]第5.2节）相同，只是标记长度t为8，并且使用长度为8个八位字节（64位）的认证标记。
An AEAD_AES_256_GCM_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
AEAD_AES_256_GCM_8密文正好比其相应的明文长8个八位字节。
This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of [RFC5116]), except that the tag length, t, is 12, and an authentication tag with a length of 12 octets (64 bits) is used.
该算法与AEAD_AES_128_GCM（见[RFC5116]第5.1节）相同，只是标签长度t为12，并且使用长度为12个八位字节（64位）的认证标签。
An AEAD_AES_128_GCM_12 ciphertext is exactly 12 octets longer than its corresponding plaintext.
AEAD_AES_128_GCM_12密文比其相应的明文长12个八位字节。
This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of [RFC5116], except that the tag length, t, is 12 and an authentication tag with a length of 12 octets (64 bits) is used.
该算法与AEAD_AES_256_GCM（参见[RFC5116]第5.2节）相同，只是标签长度t为12，并且使用长度为12个八位字节（64位）的认证标签。
An AEAD_AES_256_GCM_12 ciphertext is exactly 12 octets longer than its corresponding plaintext.
AEAD_AES_256_GCM_12密文比相应的明文长12个八位字节。
The following four AEAD algorithms employ the AES CCM algorithms with an 11 octet nonce as specified in [RFC4309].
以下四种AEAD算法采用[RFC4309]中规定的具有11个八位字节的AES CCM算法。
The AEAD_AES_128_CCM_SHORT authenticated encryption algorithm is identical to the AEAD_AES_128_CCM algorithm (see Section 5.3 of [RFC5116]), except that it uses a nonce that is one octet shorter. AEAD_AES_128_CCM_SHORT works as specified in [CCM]. It uses AES-128 as the block cipher by providing the key, nonce, associated data, and plaintext to that mode of operation. The formatting and counter generation function are as specified in Appendix A of [CCM], and the values of the parameters identified in that appendix are as follows:
AEAD_AES_128_CCM_SHORT认证加密算法与AEAD_AES_128_CCM算法（见[RFC5116]第5.3节）相同，只是它使用的非同步时间短一个八位字节。AEAD_AES_128_CCM_短工程如[CCM]所述。它使用AES-128作为分组密码，为该操作模式提供密钥、nonce、关联数据和明文。格式化和计数器生成功能如[CCM]附录A所述，该附录中确定的参数值如下：
the nonce length n is 11,
当前长度n是11，
the tag length t is 16, and
标签长度t为16，且
the value of q is 3.
q的值是3。
An authentication tag with a length of 16 octets (128 bits) is used. The AEAD_AES_128_CCM_SHORT ciphertext consists of the ciphertext output of the CCM encryption operation concatenated with the authentication tag output of the CCM encryption operation. Test cases are provided in [CCM]. The input and output lengths are as follows:
使用长度为16个八位字节（128位）的身份验证标签。AEAD_AES_128_CCM_短密文由CCM加密操作的密文输出与CCM加密操作的认证标签输出串联而成。[CCM]中提供了测试用例。输入和输出长度如下所示：
K_LEN is 16 octets,
库伦是16个八位组，
P_MAX is 2^24 - 1 octets,
P_MAX是2^24-1个八位组，
A_MAX is 2^64 - 1 octets,
最大值为2^64-1个八位字节，
N_MIN and N_MAX are both 11 octets, and
N_MIN和N_MAX都是11个八位字节，并且
C_MAX is 2^24 + 15 octets.
C_MAX为2^24+15个八位字节。
An AEAD_AES_128_CCM_SHORT ciphertext is exactly 16 octets longer than its corresponding plaintext.
AEAD_AES_128_CCM_短密文比相应的明文长16个八位字节。
This algorithm is identical to AEAD_AES_128_CCM_SHORT, but with the following differences:
此算法与AEAD_AES_128_CCM_SHORT相同，但有以下区别：
K_LEN is 32 octets, instead of 16, and
K_LEN是32个八位字节，而不是16个，并且
AES-256 CCM is used instead of AES-128 CCM.
使用AES-256 CCM代替AES-128 CCM。
An AEAD_AES_256_CCM_SHORT ciphertext is exactly 16 octets longer than its corresponding plaintext.
AEAD_AES_256_CCM_短密文比其相应的明文长16个八位字节。
This algorithm is identical to AEAD_AES_128_CCM_SHORT, except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used.
该算法与AEAD_AES_128_CCM_SHORT相同，只是标记长度t为8，并且使用长度为8个八位字节（64位）的认证标记。
An AEAD_AES_128_CCM_SHORT_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
AEAD_AES_128_CCM_SHORT_8密文比其相应的明文长8个八位字节。
This algorithm is identical to AEAD_AES_256_CCM_SHORT, except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used.
该算法与AEAD_AES_256_CCM_SHORT相同，只是标记长度t为8，并且使用长度为8个八位字节（64位）的认证标记。
An AEAD_AES_256_CCM_SHORT_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
AEAD_AES_256_CCM_SHORT_8密文比其相应的明文长8个八位字节。
This algorithm is identical to AEAD_AES_128_CCM_SHORT, except that the tag length, t, is 12, and an authentication tag with a length of 12 octets (64 bits) is used.
该算法与AEAD_AES_128_CCM_SHORT相同，只是标记长度t为12，并且使用长度为12个八位字节（64位）的认证标记。
An AEAD_AES_128_CCM_SHORT_12 ciphertext is exactly 12 octets longer than its corresponding plaintext.
AEAD_AES_128_CCM_SHORT_12密文比其相应的明文长12个八位字节。
This algorithm is identical to AEAD_AES_256_CCM_SHORT, except that the tag length, t, is 12, and an authentication tag with a length of 8 octets (64 bits) is used.
该算法与AEAD_AES_256_CCM_SHORT相同，只是标记长度t为12，并且使用长度为8个八位字节（64位）的认证标记。
An AEAD_AES_256_CCM_SHORT_12 ciphertext is exactly 12 octets longer than its corresponding plaintext.
AEAD_AES_256_CCM_SHORT_12密文比其相应的明文长12个八位字节。
The following table lists the AES CCM and AES GCM AEAD_* algorithms that can be negotiated by IKEv2 and provides the IKEv2 Encryption (ENCR) Transform Identifier and Key Length Attribute combination that is used to negotiate each algorithm.
下表列出了可由IKEv2协商的AES CCM和AES GCM AEAD_*算法，并提供了用于协商每个算法的IKEv2加密（ENCR）转换标识符和密钥长度属性组合。
+--------------------------+------------------+-------------+
| AEAD algorithm | ENCR Identifier | Key Length |
+--------------------------+------------------+-------------+
| AEAD_AES_128_GCM | 20 | 128 |
| AEAD_AES_256_GCM | 20 | 256 |
| AEAD_AES_128_GCM_8 | 18 | 128 |
| AEAD_AES_256_GCM_8 | 18 | 256 |
| AEAD_AES_128_GCM_12 | 19 | 128 |
| AEAD_AES_256_GCM_12 | 19 | 256 |
| AEAD_AES_128_CCM_SHORT | 16 | 128 |
| AEAD_AES_256_CCM_SHORT | 16 | 256 |
| AEAD_AES_128_CCM_SHORT_8 | 14 | 128 |
| AEAD_AES_256_CCM_SHORT_8 | 14 | 256 |
| AEAD_AES_128_CCM_SHORT_12| 15 | 128 |
| AEAD_AES_256_CCM_SHORT_12| 15 | 256 |
+--------------------------+------------------+-------------+
+--------------------------+------------------+-------------+
| AEAD algorithm | ENCR Identifier | Key Length |
+--------------------------+------------------+-------------+
| AEAD_AES_128_GCM | 20 | 128 |
| AEAD_AES_256_GCM | 20 | 256 |
| AEAD_AES_128_GCM_8 | 18 | 128 |
| AEAD_AES_256_GCM_8 | 18 | 256 |
| AEAD_AES_128_GCM_12 | 19 | 128 |
| AEAD_AES_256_GCM_12 | 19 | 256 |
| AEAD_AES_128_CCM_SHORT | 16 | 128 |
| AEAD_AES_256_CCM_SHORT | 16 | 256 |
| AEAD_AES_128_CCM_SHORT_8 | 14 | 128 |
| AEAD_AES_256_CCM_SHORT_8 | 14 | 256 |
| AEAD_AES_128_CCM_SHORT_12| 15 | 128 |
| AEAD_AES_256_CCM_SHORT_12| 15 | 256 |
+--------------------------+------------------+-------------+
Each of the above AEAD_* algorithms is identical to the algorithm designated by the combination of the IKEv2 ENCR Identifier and Key Length Attribute shown on the same line of the table.
上述每个AEAD_*算法都与表的同一行上显示的IKEv2 ENCR标识符和密钥长度属性组合指定的算法相同。
For authenticated encryption security considerations, see the entirety of [RFC5116], not just its security considerations section; there are important security considerations that are discussed outside the security considerations section of that document.
有关认证加密安全注意事项，请参阅[RFC5116]的全部内容，而不仅仅是其安全注意事项部分；在该文件的“安全注意事项”部分之外讨论了一些重要的安全注意事项。
The security considerations for the use of AES GCM and AES CCM with ESP apply to the use of these algorithms with the IKEv2 Encrypted Payload, see Section 10 of [RFC4106] and Section 9 of [RFC4309]. Use of AES GCM and AES CCM with IKEv2 does not create additional security considerations beyond those for the use of AES GCM and AES CCM with ESP.
在ESP中使用AES GCM和AES CCM的安全注意事项适用于使用IKEv2加密有效载荷的这些算法，请参见[RFC4106]第10节和[RFC4309]第9节。在IKEv2中使用AES GCM和AES CCM不会产生额外的安全注意事项，除了在ESP中使用AES GCM和AES CCM。
For IKEv2 security considerations, see Section 5 of [RFC4306].
有关IKEv2安全注意事项，请参见[RFC4306]第5节。
The Encryption Transform identifiers specified in Section 7.2 have been previously assigned by IANA for use with ESP. This document extends their usage to IKEv2 for the Encrypted Payload. No IANA actions are required for this usage extension.
第7.2节中规定的加密转换标识符先前已由IANA分配用于ESP。本文件将其用于加密有效载荷的IKEv2。此使用扩展不需要IANA操作。
IANA has added the following entries to the Authenticated Encryption with Associated Data (AEAD) Parameters Registry:
IANA已将以下条目添加到具有关联数据的身份验证加密（AEAD）参数注册表中：
+--------------------------+----------------+--------------------+
| Name | Reference | Numeric Identifier |
+--------------------------+----------------+--------------------+
| AEAD_AES_128_GCM_8 | Section 10.1.1 | 5 |
| AEAD_AES_256_GCM_8 | Section 10.1.2 | 6 |
| AEAD_AES_128_GCM_12 | Section 10.1.3 | 7 |
| AEAD_AES_256_GCM_12 | Section 10.1.4 | 8 |
| AEAD_AES_128_CCM_SHORT | Section 10.2.1 | 9 |
| AEAD_AES_256_CCM_SHORT | Section 10.2.2 | 10 |
| AEAD_AES_128_CCM_SHORT_8 | Section 10.2.3 | 11 |
| AEAD_AES_256_CCM_SHORT_8 | Section 10.2.4 | 12 |
| AEAD_AES_128_CCM_SHORT_12| Section 10.2.5 | 13 |
| AEAD_AES_256_CCM_SHORT_12| Section 10.2.6 | 14 |
+--------------------------+----------------+--------------------+
+--------------------------+----------------+--------------------+
| Name | Reference | Numeric Identifier |
+--------------------------+----------------+--------------------+
| AEAD_AES_128_GCM_8 | Section 10.1.1 | 5 |
| AEAD_AES_256_GCM_8 | Section 10.1.2 | 6 |
| AEAD_AES_128_GCM_12 | Section 10.1.3 | 7 |
| AEAD_AES_256_GCM_12 | Section 10.1.4 | 8 |
| AEAD_AES_128_CCM_SHORT | Section 10.2.1 | 9 |
| AEAD_AES_256_CCM_SHORT | Section 10.2.2 | 10 |
| AEAD_AES_128_CCM_SHORT_8 | Section 10.2.3 | 11 |
| AEAD_AES_256_CCM_SHORT_8 | Section 10.2.4 | 12 |
| AEAD_AES_128_CCM_SHORT_12| Section 10.2.5 | 13 |
| AEAD_AES_256_CCM_SHORT_12| Section 10.2.6 | 14 |
+--------------------------+----------------+--------------------+
An IANA registration of an AEAD algorithm does not constitute an endorsement of that algorithm or its security.
AEAD算法的IANA注册不构成对该算法或其安全性的认可。
See Section 13 of [RFC4106] and Section 12 of [RFC4309] for AES GCM and AES CCM acknowledgments.
AES GCM和AES CCM确认请参见[RFC4106]第13节和[RFC4309]第12节。
Also, we thank Charlie Kaufman, Pasi Eronen, Tero Kivinen, Steve Kent, and Alfred Hoenes for their comprehensive reviews of this document.
此外，我们感谢Charlie Kaufman、Pasi Eronen、Tero Kivinen、Steve Kent和Alfred Hoenes对本文件的全面审查。
This document was originally prepared using 2-Word-v2.0.template.dot, created by Joe Touch.
本文档最初是使用Joe Touch创建的2-Word-v2.0.template.dot编写的。
[CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM Mode for Authentication and Confidentiality", U.S. National Institute of Standards and Technology, <http://csrc.nist.gov/publications/nistpubs/800-38C/ SP800-38C.pdf>, updated July 2007.
[CCM]Dworkin，M.，“NIST特别出版物800-38C：认证和保密的CCM模式”，美国国家标准与技术研究所<http://csrc.nist.gov/publications/nistpubs/800-38C/ SP800-38C.pdf>，2007年7月更新。
[GCM] Dworkin, M., "NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.", U.S. National Institute of Standards and Technology, November 2007, <http://csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>, November 2007.
[GCM]Dworkin，M.，“NIST特别出版物800-38D：分组密码操作模式建议：Galois/计数器模式（GCM）和GMAC”，，美国国家标准与技术研究所，2007年11月<http://csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>，2007年11月。
[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月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106]Viega，J.和D.McGrew，“在IPsec封装安全有效负载（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309]Housley，R.，“使用高级加密标准（AES）CCM模式和IPsec封装安全有效载荷（ESP）”，RFC 4309，2005年12月。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，2008年1月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
Author's Addresses
作者地址
David L. Black EMC Corporation 176 South Street Hopkinton, MA 10748
David L.Black EMC Corporation马萨诸塞州霍普金顿南街176号10748
Phone: +1 (508) 293-7953
EMail: black_david@emc.com
Phone: +1 (508) 293-7953
EMail: black_david@emc.com
David A. McGrew Cisco Systems, Inc. 510 McCarthy Blvd. Milpitas, CA 95035
David A.McGrew思科系统公司，位于麦卡锡大道510号。加利福尼亚州米尔皮塔斯95035
Phone: +1 (408) 525-8651
EMail: mcgrew@cisco.com
Phone: +1 (408) 525-8651
EMail: mcgrew@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.