Network Working Group D. McGrew
Request for Comments: 4543 Cisco Systems, Inc.
Category: Standards Track J. Viega
McAfee, Inc.
May 2006
Network Working Group D. McGrew
Request for Comments: 4543 Cisco Systems, Inc.
Category: Standards Track J. Viega
McAfee, Inc.
May 2006
The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
Galois消息认证码（GMAC）在IPsec-ESP和AH中的应用
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This memo describes the use of the Advanced Encryption Standard (AES) Galois Message Authentication Code (GMAC) as a mechanism to provide data origin authentication, but not confidentiality, within the IPsec Encapsulating Security Payload (ESP) and Authentication Header (AH). GMAC is based on the Galois/Counter Mode (GCM) of operation, and can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations.
本备忘录描述了使用高级加密标准（AES）Galois消息身份验证码（GMAC）作为一种机制，在IPsec封装安全负载（ESP）和身份验证头（AH）内提供数据源身份验证，但不提供机密性。GMAC基于Galois/计数器模式（GCM）的操作，可以在硬件中高效实现，速度为每秒10千兆位及以上，也非常适合软件实现。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. AES-GMAC ........................................................3
3. The Use of AES-GMAC in ESP ......................................3
3.1. Initialization Vector ......................................4
3.2. Nonce Format ...............................................4
3.3. AAD Construction ...........................................5
3.4. Integrity Check Value (ICV) ................................6
3.5. Differences with AES-GCM-ESP ...............................6
3.6. Packet Expansion ...........................................7
4. The Use of AES-GMAC in AH .......................................7
5. IKE Conventions .................................................8
5.1. Phase 1 Identifier .........................................8
5.2. Phase 2 Identifier .........................................8
5.3. Key Length Attribute .......................................9
5.4. Keying Material and Salt Values ............................9
6. Test Vectors ....................................................9
7. Security Considerations ........................................10
8. Design Rationale ...............................................11
9. IANA Considerations ............................................11
10. Acknowledgements ..............................................11
11. References ....................................................12
11.1. Normative References .....................................12
11.2. Informative References ...................................12
1. Introduction
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. AES-GMAC ........................................................3
3. The Use of AES-GMAC in ESP ......................................3
3.1. Initialization Vector ......................................4
3.2. Nonce Format ...............................................4
3.3. AAD Construction ...........................................5
3.4. Integrity Check Value (ICV) ................................6
3.5. Differences with AES-GCM-ESP ...............................6
3.6. Packet Expansion ...........................................7
4. The Use of AES-GMAC in AH .......................................7
5. IKE Conventions .................................................8
5.1. Phase 1 Identifier .........................................8
5.2. Phase 2 Identifier .........................................8
5.3. Key Length Attribute .......................................9
5.4. Keying Material and Salt Values ............................9
6. Test Vectors ....................................................9
7. Security Considerations ........................................10
8. Design Rationale ...............................................11
9. IANA Considerations ............................................11
10. Acknowledgements ..............................................11
11. References ....................................................12
11.1. Normative References .....................................12
11.2. Informative References ...................................12
1. Introduction
This document describes the use of AES-GMAC mode (AES-GMAC) as a mechanism for data origin authentication in ESP [RFC4303] and AH [RFC4302]. We refer to these methods as ENCR_NULL_AUTH_AES_GMAC and AUTH_AES_GMAC, respectively. ENCR_NULL_AUTH_AES_GMAC is a companion to the AES Galois/Counter Mode ESP [RFC4106], which provides authentication as well as confidentiality. ENCR_NULL_AUTH_AES_GMAC is intended for cases in which confidentiality is not desired. Like GCM, GMAC is efficient and secure, and is amenable to high-speed implementations in hardware. ENCR_NULL_AUTH_AES_GMAC and AUTH_AES_GMAC are designed so that the incremental cost of implementation, given an implementation is AES-GCM-ESP, is small.
本文档描述了AES-GMAC模式（AES-GMAC）在ESP[RFC4303]和AH[RFC4302]中作为数据源身份验证机制的使用。我们将这些方法分别称为ENCR_NULL_AUTH_AES_GMAC和AUTH_AES_GMAC。ENCR_NULL_AUTH_AES_GMAC是AES Galois/计数器模式ESP[RFC4106]的配套产品，它提供身份验证和机密性。ENCR_NULL_AUTH_AES_GMAC适用于不需要保密的情况。与GCM一样，GMAC高效、安全，并且易于在硬件中进行高速实现。ENCR_NULL_AUTH_AES_GMAC和AUTH_AES_GMAC的设计使得在AES-GCM-ESP实现的情况下，实现的增量成本很小。
This document does not cover implementation details of GCM or GMAC. Those details can be found in [GCM], along with test vectors.
本文件不包括GCM或GMAC的实施细节。这些细节可以在[GCM]中找到，以及测试向量。
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]中所述进行解释。
GMAC is a block cipher mode of operation providing data origin authentication. It is defined in terms of the GCM authenticated encryption operation as follows. The GCM authenticated encryption operation has four inputs: a secret key, an initialization vector (IV), a plaintext, and an input for additional authenticated data (AAD). It has two outputs, a ciphertext whose length is identical to the plaintext and an authentication tag. GMAC is the special case of GCM in which the plaintext has a length of zero. The (zero-length) ciphertext output is ignored, of course, so that the only output of the function is the Authentication Tag. In the following, we describe how the GMAC IV and AAD are formed from the ESP and AH fields, and how the ESP and AH packets are formed from the Authentication Tag.
GMAC是一种提供数据源身份验证的分组密码操作模式。它是根据GCM认证加密操作定义的，如下所示。GCM认证加密操作有四个输入：一个密钥、一个初始化向量（IV）、一个明文和一个用于附加认证数据（AAD）的输入。它有两个输出，一个长度与明文相同的密文和一个身份验证标签。GMAC是GCM的特例，其中明文的长度为零。当然，（零长度）密文输出被忽略，因此函数的唯一输出是身份验证标记。在下文中，我们将描述如何从ESP和AH字段形成GMAC IV和AAD，以及如何从认证标签形成ESP和AH数据包。
Below we refer to the AES-GMAC IV input as a nonce, in order to distinguish it from the IV fields in the packets. The same nonce and key combination MUST NOT be used more than once, since reusing a nonce/key combination destroys the security guarantees of AES-GMAC.
下面我们将AES-GMAC IV输入称为nonce，以便将其与数据包中的IV字段区分开来。同一个nonce和密钥组合不得多次使用，因为重用nonce/密钥组合会破坏AES-GMAC的安全保证。
Because of this restriction, it can be difficult to use this mode securely when using statically configured keys. For the sake of good security, implementations MUST use an automated key management system, such as the Internet Key Exchange (IKE) (either version two [RFC4306] or version one [RFC2409]), to ensure that this requirement is met.
由于此限制，在使用静态配置的密钥时，很难安全地使用此模式。为确保良好的安全性，实施必须使用自动密钥管理系统，如Internet密钥交换（IKE）（版本二[RFC4306]或版本一[RFC2409]），以确保满足此要求。
The AES-GMAC algorithm for ESP is defined as an ESP "combined mode" algorithm (see Section 3.2.3 of [RFC4303]), rather than an ESP integrity algorithm. It is called ENCR_NULL_AUTH_AES_GMAC to highlight the fact that it performs no encryption and provides no confidentiality.
ESP的AES-GMAC算法定义为ESP“组合模式”算法（见[RFC4303]第3.2.3节），而不是ESP完整性算法。它被称为ENCR_NULL_AUTH_AES_GMAC，以强调它不执行加密且不提供机密性这一事实。
Rationale: ESP makes no provision for integrity transforms to place an initialization vector within the Payload field; only encryption transforms are expected to use IVs. Defining GMAC as an encryption transform avoids this issue, and allows GMAC to benefit from the same pipelining as does GCM.
理由：ESP未提供完整性转换，以在有效载荷字段内放置初始化向量；只有加密转换才能使用IVs。将GMAC定义为加密转换可以避免这个问题，并允许GMAC从与GCM相同的管道中获益。
Like all ESP combined modes, it is registered in IKEv2 as an encryption transform, or "Type 1" transform. It MUST NOT be used in conjunction with any other ESP encryption transform (within a particular ESP encapsulation). If confidentiality is desired, then GCM ESP [RFC4106] SHOULD be used instead.
与所有ESP组合模式一样，它在IKEv2中注册为加密转换或“类型1”转换。它不得与任何其他ESP加密转换（在特定ESP封装内）结合使用。如果需要保密，则应使用GCM ESP[RFC4106]。
With ENCR_NULL_AUTH_AES_GMAC, an explicit Initialization Vector (IV) is included in the ESP Payload, at the outset of that field. The IV MUST be eight octets long. For a given key, the IV MUST NOT repeat. The most natural way to meet this requirement is to set the IV using a counter, but implementations are free to set the IV field in any way that guarantees uniqueness, such as a linear feedback shift register (LFSR). Note that the sender can use any IV generation method that meets the uniqueness requirement without coordinating with the receiver.
使用ENCR_NULL_AUTH_AES_GMAC，ESP有效负载中包含一个显式初始化向量（IV），位于该字段的开头。IV必须有八个八位字节长。对于给定的钥匙，IV不得重复。满足此要求的最自然的方法是使用计数器设置IV，但是实现可以自由地以任何保证唯一性的方式设置IV字段，例如线性反馈移位寄存器（LFSR）。请注意，发送方可以使用满足唯一性要求的任何IV生成方法，而无需与接收方协调。
The nonce passed to the AES-GMAC authentication algorithm has the following layout:
传递给AES-GMAC身份验证算法的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 1: Nonce Format
图1：Nonce格式
The components of the nonce are as follows:
nonce的组件如下所示：
Salt The salt field is a four-octet value that is assigned at the beginning of the security association, and then remains constant for the life of the security association. The salt SHOULD be unpredictable (i.e., chosen at random) before it is selected, but need not be secret. We describe how to set the salt for a Security Association established via the Internet Key Exchange in Section 5.4.
Salt Salt字段是在安全关联开始时指定的四个八位组的值，然后在安全关联的生命周期内保持不变。盐在被选择之前应该是不可预测的（即随机选择的），但不必是秘密的。我们在第5.4节中描述了如何为通过Internet密钥交换建立的安全关联设置salt。
Initialization Vector The IV field is described in Section 3.1.
第3.1节描述了IV字段的初始化向量。
Data integrity and data origin authentication are provided for the SPI, (Extended) Sequence Number, Authenticated Payload, Padding, Pad Length, and Next Header fields. This is done by including those fields in the AES-GMAC Additional Authenticated Data (AAD) field. Two formats of the AAD 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 2, and the format with 64-bit extended sequence numbers is shown in Figure 3.
为SPI、（扩展）序列号、已验证的有效负载、填充、焊盘长度和下一个标头字段提供数据完整性和数据源身份验证。这是通过将这些字段包括在AES-GMAC附加认证数据（AAD）字段中来实现的。定义了两种AAD格式：一种用于32位序列号，另一种用于64位扩展序列号。带有32位序列号的格式如图2所示，带有64位扩展序列号的格式如图3所示。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authenticated Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (0-255 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authenticated Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (0-255 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: AAD Format with 32-bit Sequence Number
图2: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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authenticated Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (0-255 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authenticated Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (0-255 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: AAD Format with 64-bit Extended Sequence Number
图3:64位扩展序列号的AAD格式
The use of 32-bit sequence numbers vs. 64-bit extended sequence numbers is determined by the security association (SA) management protocol that is used to create the SA. For IKEv2 [RFC4306] this is negotiated via Transform Type 5, and the default for ESP is to use 64-bit extended sequence numbers in the absence of negotiation (e.g., see Section 2.2.1 of [RFC4303]).
32位序列号与64位扩展序列号的使用由用于创建SA的安全关联（SA）管理协议决定。对于IKEv2[RFC4306]，这是通过转换类型5协商的，ESP的默认设置是在没有协商的情况下使用64位扩展序列号（例如，参见[RFC4303]第2.2.1节）。
The ICV consists solely of the AES-GMAC Authentication Tag. The Authentication Tag MUST NOT be truncated, so the length of the ICV is 16 octets.
ICV仅由AES-GMAC认证标签组成。身份验证标记不能被截断，因此ICV的长度为16个八位字节。
In this section, we highlight the differences between this specification and AES-GCM-ESP [RFC4106]. The essential difference is that in this document, the AAD consists of the SPI, Sequence Number, and ESP Payload, and the AES-GCM plaintext is zero-length, while in AES-GCM-ESP, the AAD consists only of the SPI and Sequence Number, and the AES-GCM plaintext consists of the ESP Payload. These differences are illustrated in Figure 4. This figure shows the case in which the Extended Sequence Number option is not used. When that option is exercised, the Sequence Number field in the figure would be replaced with the Extended Sequence Number.
在本节中，我们将重点介绍本规范与AES-GCM-ESP[RFC4106]之间的差异。本质区别在于，在本文件中，AAD由SPI、序列号和ESP有效载荷组成，AES-GCM明文长度为零，而在AES-GCM-ESP中，AAD仅由SPI和序列号组成，AES-GCM明文由ESP有效载荷组成。这些差异如图4所示。此图显示未使用扩展序列号选项的情况。当序列中的数字被扩展时，该数字将被替换为序列号。
Importantly, ENCR_NULL_AUTH_AES_GMAC is *not* equivalent to AES-GCM-ESP with encryption "turned off". However, the ICV computations performed in both cases are similar because of the structure of the GHASH function [GCM].
重要的是，ENCR_NULL_AUTH_AES_GMAC*不*等同于加密“关闭”的AES-GCM-ESP。然而，由于GHASH函数[GCM]的结构，在这两种情况下进行的ICV计算是相似的。
+-> +-----------------------+ <-+
AES-GCM-ESP | | SPI | |
AAD -------+ +-----------------------+ |
| | Sequence Number | |
+-> +-----------------------+ |
| Authentication | |
| IV | |
+->+-> +-----------------------+ +
AES-GCM-ESP | | | |
Plaintext -+ ~ ESP Payload ~ |
| | | |
| +-----------+-----+-----+ |
| | Padding | PL | NH | |
+----> +-----------+-----+-----+ <-+
|
ENCR_NULL_AUTH_AES_GMAC AAD --+
+-> +-----------------------+ <-+
AES-GCM-ESP | | SPI | |
AAD -------+ +-----------------------+ |
| | Sequence Number | |
+-> +-----------------------+ |
| Authentication | |
| IV | |
+->+-> +-----------------------+ +
AES-GCM-ESP | | | |
Plaintext -+ ~ ESP Payload ~ |
| | | |
| +-----------+-----+-----+ |
| | Padding | PL | NH | |
+----> +-----------+-----+-----+ <-+
|
ENCR_NULL_AUTH_AES_GMAC AAD --+
Figure 4: Differences between ENCR_NULL_AUTH_AES_GMAC and AES-GCM-ESP
图4:ENCR_NULL_AUTH_AES_GMAC和AES-GCM-ESP之间的差异
The IV adds an additional eight octets to the packet and the ICV adds an additional 16 octets. These are the only sources of packet expansion, other than the 10-13 bytes taken up by the ESP SPI, Sequence Number, Padding, Pad Length, and Next Header fields (if the minimal amount of padding is used).
IV向数据包添加了额外的8个八位字节，ICV向数据包添加了额外的16个八位字节。除了ESP SPI占用的10-13字节、序列号、填充、填充长度和下一个报头字段（如果使用最小填充量）之外，这些是数据包扩展的唯一来源。
In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV and the Authentication Tag, as shown in Figure 5. Unlike the usual AH case, the Authentication Data field contains both an input to the authentication algorithm (the IV) and the output of the authentication algorithm (the tag). No padding is required in the Authentication Data field, because its length is a multiple of 64 bits.
在AUTH_AES_GMAC中，AH认证数据字段由IV和认证标签组成，如图5所示。与通常的AH情况不同，身份验证数据字段包含身份验证算法的输入（IV）和身份验证算法的输出（标签）。身份验证数据字段中不需要填充，因为其长度是64位的倍数。
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 (IV) |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Check Value (ICV) (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (IV) |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Check Value (ICV) (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The AUTH_AES_GMAC Authentication Data Format
图5:AUTH_AES_GMAC认证数据格式
The IV is as described in Section 3.1. The Integrity Check Value (ICV) is as described in Section 3.4.
IV如第3.1节所述。完整性检查值（ICV）如第3.4节所述。
The GMAC Nonce input is formed as described in Section 3.2. The GMAC AAD input consists of the authenticated data as defined in Section 3.1 of [RFC4302]. These values are provided as to that algorithm, along with the secret key, and the resulting authentication tag given as output is used to form the ICV.
GMAC Nonce输入的形成如第3.2节所述。GMAC AAD输入由[RFC4302]第3.1节中定义的认证数据组成。这些值与密钥一起提供给该算法，并且作为输出给出的结果认证标签用于形成ICV。
This section describes the conventions used to generate keying material and salt values for use with ENCR_NULL_AUTH_AES_GMAC and AUTH_AES_GMAC using the Internet Key Exchange (IKE) versions one [RFC2409] and two [RFC4306].
本节描述了用于生成密钥材料和salt值的约定，以用于使用互联网密钥交换（IKE）版本一[RFC2409]和两[RFC4306]的ENCR_NULL_AUTH_AES_GMAC和AUTH_AES_GMAC。
This document does not specify the conventions for using AES-GMAC for IKE Phase 1 negotiations. For AES-GMAC to be used in this manner, a separate specification would be needed, and an Encryption Algorithm Identifier would need to be assigned. Implementations SHOULD use an IKE Phase 1 cipher that is at least as strong as AES-GMAC. The use of AES-CBC [RFC3602] with the same AES key size as used by ENCR_NULL_AUTH_AES_GMAC or AUTH_AES_GMAC is RECOMMENDED.
本文件未规定将AES-GMAC用于IKE第1阶段谈判的约定。要以这种方式使用AES-GMAC，需要单独的规范，并且需要分配加密算法标识符。实现应该使用至少与AES-GMAC一样强大的IKE第1阶段密码。建议使用AES-CBC[RFC3602]，其AES密钥大小与ENCR_NULL_AUTH_AES_GMAC或AUTH_AES_GMAC使用的相同。
For IKE Phase 2 negotiations, IANA has assigned identifiers as described in Section 9.
对于IKE第2阶段谈判，IANA已按照第9节所述分配标识符。
AES-GMAC can be used with any of the three AES key lengths. The way that the key length is indicated is different for AH and ESP.
AES-GMAC可与三种AES密钥长度中的任何一种一起使用。AH和ESP的键长指示方式不同。
For AH, each key length has its own separate integrity transform identifier and algorithm name (Section 9). The IKE Key Length attribute MUST NOT be used with these identifiers. This transform MUST NOT be used with ESP.
对于AH，每个密钥长度都有自己单独的完整性转换标识符和算法名称（第9节）。IKE Key Length属性不能与这些标识符一起使用。此转换不能与ESP一起使用。
For ESP, there is a single encryption transform identifier (which represents the combined transform) (Section 9). The IKE Key Length attribute MUST be used with each use of this identifier to indicate the key length. The Key Length attribute MUST have a value of 128, 192, or 256.
对于ESP，有一个加密转换标识符（表示组合转换）（第9节）。IKE Key Length属性必须与此标识符的每次使用一起使用，以指示密钥长度。密钥长度属性的值必须为128、192或256。
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 the KEYMAT for the ENCR_NULL_AUTH_AES_GMAC and AUTH_AES_GMAC MUST be four octets longer than is needed for the associated AES key. The keying material is used as follows:
ENCR_NULL_AUTH_AES_GMAC和AUTH_AES_GMAC的密钥表大小必须比关联AES密钥所需的长度长四个八位字节。键控材料的使用方式如下：
ENCR_NULL_AUTH_AES_GMAC with a 128-bit key and AUTH_AES_128_GMAC The KEYMAT requested for each AES-GMAC key is 20 octets. The first 16 octets are the 128-bit AES key, and the remaining four octets are used as the salt value in the nonce.
ENCR_NULL_AUTH_AES_GMAC带有128位密钥和AUTH_AES_128_GMAC每个AES-GMAC密钥请求的密钥为20个八位字节。前16个八位字节是128位AES密钥，其余四个八位字节用作nonce中的salt值。
ENCR_NULL_AUTH_AES_GMAC with a 192-bit key and AUTH_AES_192_GMAC The KEYMAT requested for each AES-GMAC key is 28 octets. The first 24 octets are the 192-bit AES key, and the remaining four octets are used as the salt value in the nonce.
ENCR_NULL_AUTH_AES_GMAC，带192位密钥和AUTH_AES_192_GMAC每个AES-GMAC密钥请求的密钥为28个八位字节。前24个八位字节是192位AES密钥，其余四个八位字节用作nonce中的salt值。
ENCR_NULL_AUTH_AES_GMAC with a 256-bit key and AUTH_AES_256_GMAC The KEYMAT requested for each AES-GMAC key is 36 octets. The first 32 octets are the 256-bit AES key, and the remaining four octets are used as the salt value in the nonce.
ENCR_NULL_AUTH_AES_GMAC，带256位密钥和AUTH_AES_256_GMAC每个AES-GMAC密钥请求的密钥为36个八位字节。前32个八位字节是256位AES密钥，其余四个八位字节用作nonce中的salt值。
Appendix B of [GCM] provides test vectors that will assist implementers with AES-GMAC.
[GCM]的附录B提供了将帮助AES-GMAC实施者的测试向量。
Since the authentication coverage is different between AES-GCM-ESP and this specification (see Figure 4), it is worth pointing out that both specifications are secure. In ENCR_NULL_AUTH_AES_GMAC, the IV is not included in either the plaintext or the additional authenticated data. This does not adversely affect security, because the IV field only provides an input to the GMAC IV, which is not required to be authenticated (see [GCM]). In AUTH_AES_GMAC, the IV is included in the additional authenticated data. This fact has no adverse effect on security; it follows from the property that GMAC is secure even against attacks in which the adversary can manipulate both the IV and the message. Even an adversary with these powerful capabilities cannot forge an authentication tag for any message (other than one that was submitted to the chosen-message oracle). Since such an adversary could easily choose messages that contain the IVs with which they correspond, there are no security problems with the inclusion of the IV in the AAD.
由于AES-GCM-ESP和本规范之间的身份验证覆盖范围不同（见图4），因此值得指出的是，这两种规范都是安全的。在ENCR_NULL_AUTH_AES_GMAC中，IV不包括在明文或附加认证数据中。这不会对安全性产生不利影响，因为IV字段只向GMAC IV提供输入，不需要进行身份验证（参见[GCM]）。在AUTH_AES_GMAC中，IV包含在附加的认证数据中。这一事实对安全没有不利影响；根据GMAC的特性，即使在攻击中对手可以同时操纵IV和消息，GMAC也是安全的。即使拥有这些强大功能的对手也无法伪造任何消息的身份验证标签（提交给选定消息oracle的消息除外）。因为这样的对手可以很容易地选择包含它们所对应的IV的消息，所以将IV包含在AAD中不存在安全问题。
GMAC is provably secure against adversaries that can adaptively choose plaintexts, ICVs and the AAD field, under standard cryptographic assumptions (roughly, that the output of the underlying cipher under a randomly chosen key is indistinguishable from a randomly selected output). Essentially, this means that, if used within its intended parameters, a break of GMAC implies a break of the underlying block cipher. The proof of security is available in [GCMP].
GMAC在标准密码假设下（大致上，随机选择的密钥下的基础密码输出与随机选择的输出不可区分），可证明对能够自适应选择明文、ICV和AAD字段的对手是安全的。本质上，这意味着，如果在其预期参数内使用，GMAC的中断意味着基础分组密码的中断。[GCMP]中提供了安全性证明。
The most important security consideration is that the IV never repeats for a given key. In part, this is handled by disallowing the use of AES-GMAC when using statically configured keys, as discussed in Section 2.
考虑到安全性，最重要的考虑决不会重复。在某种程度上，这是通过在使用静态配置密钥时不允许使用AES-GMAC来解决的，如第2节所述。
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 protect 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 or AH implementations that permit use of the same key for protecting packets with the same peer MUST ensure that the two peers assign different salt values to the security association (SA).
当IKE用于在两个对等实体之间建立新密钥时，将为两个业务流建立单独的密钥。如果使用不同的机制来建立新密钥，即仅建立单个密钥来保护数据包的机制，则对等方很可能会为某些数据包选择相同的IV值。因此，为了避免计数器块冲突，允许使用相同密钥保护同一对等方的数据包的ESP或AH实现必须确保两个对等方为安全关联（SA）分配不同的salt值。
The other consideration is that, as with any block cipher mode of operation, the security of all data protected under a given security association decreases slightly with each message.
另一个考虑因素是，与任何分组密码操作模式一样，在给定安全关联下受保护的所有数据的安全性随着每条消息的发送而略有降低。
To protect against this problem, implementations MUST generate a fresh key before processing 2^64 blocks of data with a given key. Note that it is impossible to reach this limit when using 32-bit Sequence Numbers.
为了防止此问题，实现必须在使用给定密钥处理2^64个数据块之前生成一个新密钥。请注意，使用32位序列号时不可能达到此限制。
Note that, for each message, GMAC calls the block cipher only once.
注意，对于每条消息，GMAC只调用一次分组密码。
This specification was designed to be as similar to AES-GCM-ESP [RFC4106] as possible. We re-use the design and implementation experience from that specification. We include all three AES key sizes since AES-GCM-ESP supports all of those sizes, and the larger key sizes provide future users with more high-security options.
本规范旨在尽可能类似于AES-GCM-ESP[RFC4106]。我们重复使用该规范中的设计和实现经验。我们包括所有三种AES密钥大小，因为AES-GCM-ESP支持所有这些大小，更大的密钥大小为未来用户提供了更高的安全性选项。
IANA has assigned the following IKEv2 parameters. For the use of AES GMAC in AH, the following integrity (type 3) transform identifiers have been assigned:
IANA已分配以下IKEv2参数。为了在AH中使用AES GMAC，已分配以下完整性（类型3）转换标识符：
"9" for AUTH_AES_128_GMAC
“9”用于认证AES 128\U GMAC
"10" for AUTH_AES_192_GMAC
“10”用于认证AES 192 GMAC
"11" for AUTH_AES_256_GMAC
用于认证AES 256 GMAC的“11”
For the use of AES-GMAC in ESP, the following encryption (type 1) transform identifier has been assigned:
为了在ESP中使用AES-GMAC，已分配以下加密（类型1）转换标识符：
"21" for ENCR_NULL_AUTH_AES_GMAC
“21”表示ENCR\u NULL\u AUTH\u AES\u GMAC
Our discussions with Fabio Maino and David Black significantly improved this specification, and Tero Kivinen provided us with useful comments. Steve Kent provided guidance on ESP interactions. This work is closely modeled after AES-GCM, which itself is closely modeled after Russ Housley's AES-CCM transform [RFC4309]. Additionally, the GCM mode of operation was originally conceived as an improvement to the CWC mode [CWC] in which Doug Whiting and Yoshi Kohno participated. We express our thanks to Fabio, David, Tero, Steve, Russ, Doug, and Yoshi.
我们与Fabio Maino和David Black的讨论显著改进了该规范，Tero Kivinen为我们提供了有用的意见。Steve Kent提供了ESP互动方面的指导。这项工作与AES-GCM密切相关，AES-GCM本身与Russ Housley的AES-CCM变换密切相关[RFC4309]。此外，GCM运行模式最初被认为是对Doug Whiting和Yoshi Kohno参与的《化学武器公约》模式的改进。我们向法比奥、大卫、泰罗、史蒂夫、罗斯、道格和约西表示感谢。
[GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of Operation (GCM)", Submission to NIST. http:// csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/ gcm-spec.pdf, January 2004.
[GCM]McGrew，D.和J.Viega，“伽罗瓦/计数器操作模式（GCM）”，提交给NIST。http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm-spec.pdf，2004年1月。
[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月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[CWC] Kohno, T., Viega, J., and D. Whiting, "CWC: A high-performance conventional authenticated encryption mode", Fast Software Encryption. http://eprint.iacr.org/2003/106.pdf, February 2004.
[CWC]Kohno，T.，Viega，J.，和D.Whiting，“CWC：一种高性能传统认证加密模式”，快速软件加密。http://eprint.iacr.org/2003/106.pdf，2004年2月。
[GCMP] McGrew, D. and J. Viega, "The Security and Performance of the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT '04, http://eprint.iacr.org/2004/193, December 2004.
[GCMP]McGrew，D.和J.Viega，“Galois/计数器模式（GCM）的安全性和性能”，INDOCRYPT'04会议录，http://eprint.iacr.org/2004/193，2004年12月。
[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月。
[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月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年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月。
Authors' Addresses
作者地址
David A. McGrew Cisco Systems, Inc. 510 McCarthy Blvd. Milpitas, CA 95035 US
David A.McGrew思科系统公司，位于麦卡锡大道510号。加利福尼亚州米尔皮塔斯95035美国
Phone: (408) 525 8651
EMail: mcgrew@cisco.com
URI: http://www.mindspring.com/~dmcgrew/dam.htm
Phone: (408) 525 8651
EMail: mcgrew@cisco.com
URI: http://www.mindspring.com/~dmcgrew/dam.htm
John Viega McAfee, Inc. 1145 Herndon Parkway, Suite 500 Herndon, VA 20170
约翰·维加·麦卡菲公司，地址：弗吉尼亚州赫恩登市赫恩登大道1145号500室，邮编：20170
EMail: viega@list.org
EMail: viega@list.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。