Internet Engineering Task Force (IETF) B. Weis
Request for Comments: 8263 Cisco Systems
Category: Standards Track U. Mangla
ISSN: 2070-1721 Juniper Networks Inc.
T. Karl
Deutsche Telekom
N. Maheshwari
November 2017
Internet Engineering Task Force (IETF) B. Weis
Request for Comments: 8263 Cisco Systems
Category: Standards Track U. Mangla
ISSN: 2070-1721 Juniper Networks Inc.
T. Karl
Deutsche Telekom
N. Maheshwari
November 2017
Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message
组解释域（GDOI）组密钥推送确认消息
Abstract
摘要
The Group Domain of Interpretation (GDOI) includes the ability of a Group Controller/Key Server (GCKS) to provide a set of current Group Member (GM) devices with additional security associations (e.g., to rekey expiring security associations). This memo adds the ability of a GCKS to request that the GM devices return an acknowledgement of receipt of its rekey message and specifies the acknowledgement method.
组解释域（GDOI）包括组控制器/密钥服务器（GCKS）提供一组具有附加安全关联的当前组成员（GM）设备的能力（例如，为即将到期的安全关联重新设置密钥）。此备忘录增加了GCKS请求GM设备返回其重新输入消息接收确认的能力，并指定了确认方法。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8263.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8263.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Acronyms and Abbreviations .................................4
2. Acknowledgement Message Request .................................5
2.1. REKEY_ACK_KEK_SHA256 Type ..................................5
2.2. REKEY_ACK_LKH_SHA256 Type ..................................6
2.3. REKEY_ACK_KEK_SHA512 Type ..................................6
2.4. REKEY_ACK_LKH_SHA512 Type ..................................6
3. GROUPKEY-PUSH Acknowledgement Message ...........................6
3.1. HDR ........................................................7
3.2. HASH .......................................................8
3.3. SEQ ........................................................9
3.4. ID .........................................................9
4. Group Member Operations .........................................9
5. GCKS Operations ................................................10
6. Management Considerations ......................................10
7. Security Considerations ........................................12
7.1. Protection of the GROUPKEY-PUSH ACK .......................12
7.2. Transmitting a GROUPKEY-PUSH ACK ..........................13
7.3. Receiving a GROUPKEY-PUSH ACK .............................13
8. IANA Considerations ............................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................16
Acknowledgements ..................................................17
Authors' Addresses ................................................17
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Acronyms and Abbreviations .................................4
2. Acknowledgement Message Request .................................5
2.1. REKEY_ACK_KEK_SHA256 Type ..................................5
2.2. REKEY_ACK_LKH_SHA256 Type ..................................6
2.3. REKEY_ACK_KEK_SHA512 Type ..................................6
2.4. REKEY_ACK_LKH_SHA512 Type ..................................6
3. GROUPKEY-PUSH Acknowledgement Message ...........................6
3.1. HDR ........................................................7
3.2. HASH .......................................................8
3.3. SEQ ........................................................9
3.4. ID .........................................................9
4. Group Member Operations .........................................9
5. GCKS Operations ................................................10
6. Management Considerations ......................................10
7. Security Considerations ........................................12
7.1. Protection of the GROUPKEY-PUSH ACK .......................12
7.2. Transmitting a GROUPKEY-PUSH ACK ..........................13
7.3. Receiving a GROUPKEY-PUSH ACK .............................13
8. IANA Considerations ............................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................16
Acknowledgements ..................................................17
Authors' Addresses ................................................17
The Group Domain of Interpretation (GDOI) [RFC6407] is a group key management method by which a Group Controller/Key Server (GCKS) distributes security associations (i.e., cryptographic policy and keying material) to a set of Group Member (GM) devices. The GDOI meets the requirements set forth in [RFC4046] ("Multicast Security (MSEC) Group Key Management Architecture"), including a Registration Protocol and a Rekey Protocol. The GDOI describes the Rekey Protocol as a GROUPKEY-PUSH message.
组解释域（GDOI）[RFC6407]是一种组密钥管理方法，通过该方法，组控制器/密钥服务器（GCKS）将安全关联（即加密策略和密钥材料）分发给一组组组成员（GM）设备。GDOI符合[RFC4046]（“多播安全（MSEC）组密钥管理体系结构”）中规定的要求，包括注册协议和重密钥协议。GDOI将Rekey协议描述为GROUPKEY-PUSH消息。
A GDOI GCKS uses a GROUPKEY-PUSH message (Section 4 of [RFC6407]) to alert GMs to updates in policy for the group, including new policy and keying material, replacement policy and keying material, and indications of deleted policy and keying material. Usually, the GCKS does not require a notification that the GM actually received the policy. However, in some cases it is beneficial for a GCKS to be told by each receiving GM that it received the rekey message and, by implication, has reacted to the policy contained within. For example, a GCKS policy can use the acknowledgements to determine which GMs are receiving the current group policy and which GMs are no longer participating in the group.
GDOI GCKS使用GROUPKEY-PUSH消息（[RFC6407]第4节）提醒GMs集团的策略更新，包括新策略和密钥材料、替换策略和密钥材料，以及已删除策略和密钥材料的指示。通常，GCKS不要求GM实际收到保单的通知。然而，在某些情况下，由每个接收GM告知GCKS其已收到重新密钥消息，并暗示已对其中包含的政策作出反应，这对GCKS是有益的。例如，GCKS策略可以使用确认来确定哪些GMs正在接收当前的组策略，哪些GMs不再参与组。
This memo introduces a method by which a GM returns an Acknowledgement Message to the GCKS. Initially, a GCKS requests that a GM acknowledge GROUPKEY-PUSH messages as part of a distributed group policy. Then, as shown in Figure 1, when the GCKS delivers a GROUPKEY-PUSH message, each GM that honors the GCKS request returns a GROUPKEY-PUSH Acknowledgement Message. The rest of this memo describes this method in detail.
本备忘录介绍了GM向GCKS返回确认信息的方法。最初，GCKS请求GM确认GROUPKEY-PUSH消息，作为分布式组策略的一部分。然后，如图1所示，当GCKS发送一条GROUPKEY-PUSH消息时，每个接受GCKS请求的GM返回一条GROUPKEY-PUSH确认消息。本备忘录的其余部分详细描述了该方法。
GCKS GM1 GM2
| | |
| +---------->| |
| GROUPKEY-PUSH | | |
|-----------------+ | |
| | | |
| +-------------------->|
| | |
|<----------------------------| |
| GROUPKEY-PUSH ACK | |
| | |
|<--------------------------------------|
| GROUPKEY-PUSH ACK | |
GCKS GM1 GM2
| | |
| +---------->| |
| GROUPKEY-PUSH | | |
|-----------------+ | |
| | | |
| +-------------------->|
| | |
|<----------------------------| |
| GROUPKEY-PUSH ACK | |
| | |
|<--------------------------------------|
| GROUPKEY-PUSH ACK | |
Figure 1: GROUPKEY-PUSH Rekey Event
图1:GROUPKEY-PUSH重新按键事件
Implementation of the GROUPKEY-PUSH Acknowledgement Message is OPTIONAL.
GROUPKEY-PUSH确认消息的实现是可选的。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The following acronyms and abbreviations are used throughout this document.
本文件中使用了以下首字母缩略词和缩写词。
ACK Acknowledgement Message
确认消息
D Delete
D删除
GCKS Group Controller/Key Server
GCKS组控制器/密钥服务器
GDOI Group Domain of Interpretation
GDOI组解释域
GM Group Member
总经理小组成员
HDR Header
HDR报头
HMAC Hashed Message Authentication Code
HMAC哈希消息身份验证码
IV Initialization Vector
IV初始化向量
KD Key Download
KD密钥下载
KDF Key Derivation Function
KDF密钥派生函数
KEK Key Encryption Key
KEK密钥加密密钥
LKH Logical Key Hierarchy
逻辑密钥层次结构
MSEC Multicast Security
MSEC组播安全
PRF Pseudorandom Function
伪随机函数
SA Security Association
南非安全协会
SEQ Sequence Number
序列号
SIG Signature
签名
SPI Security Parameter Index
安全参数索引
When a GM is ready to join a group, it contacts the GCKS with a GROUPKEY-PULL Registration Protocol. When the GCKS has authenticated and verified that the GM is an authorized member of the group, it downloads several sets of policy in a Security Association (SA) payload. If the group includes the use of a GROUPKEY-PUSH Rekey Protocol, the SA payload includes an SA Key Encryption Key (KEK) payload (Section 5.3 of [RFC6407]). When necessary, the GROUPKEY-PUSH Rekey Protocol also contains an SA payload that includes the SA KEK policy. The SA KEK policy indicates how the GM will be receiving and handling the GROUPKEY-PUSH Rekey Protocol.
当GM准备加入一个组时，它会使用GROUPKEY-PULL注册协议联系GCK。当GCKS验证并验证GM是组的授权成员时，它将在安全关联（SA）有效负载中下载多组策略。如果该组包括使用GROUPKEY-PUSH-Rekey协议，SA有效载荷包括SA密钥加密密钥（KEK）有效载荷（RFC6407第5.3节）。必要时，GROUPKEY-PUSH-Rekey协议还包含一个SA有效负载，其中包括SA KEK策略。SA KEK策略表明GM将如何接收和处理GROUPKEY-PUSH重新密钥协议。
When the GCKS policy includes the use of the GROUPKEY-PUSH Acknowledgement Message, the GCKS reports this policy to the GM within the SA KEK policy. The GCKS includes a new KEK attribute with the name KEK_ACK_REQUESTED (9), which indicates that the GM is requested to return a GROUPKEY-PUSH Acknowledgement Message.
当GCKS策略包括使用GROUPKEY-PUSH确认消息时，GCKS会在SA KEK策略中向GM报告此策略。GCKS包括一个名为KEK_ACK_REQUESTED（9）的新KEK属性，该属性表示请求GM返回GROUPKEY-PUSH确认消息。
As part of the SA KEK policy, the GCKS specifies information on the keying material that is used to protect the GROUPKEY-PUSH Rekey Protocol (e.g., the presence of a KEK management algorithm). Parts of this information are used by a GM to derive the ack_key (defined in Section 3.2), which protects the GROUPKEY-PUSH Acknowledgement Message. There are different types of Rekey Acknowledgement Messages; they share an identical message format but differ in the keying material used.
作为SA KEK策略的一部分，GCKS指定了用于保护GROUPKEY-PUSH重新密钥协议的密钥材料信息（例如，存在KEK管理算法）。GM使用该信息的一部分来推导ack_密钥（定义见第3.2节），该密钥保护GROUPKEY-PUSH确认消息。存在不同类型的重新密钥确认消息；它们共享相同的消息格式，但使用的键控材料不同。
The following values of the KEK_ACK_REQUESTED attribute are defined in this memo.
本备忘录中定义了KEK_ACK_REQUESTED属性的以下值。
This type of Rekey ACK is used when the KEK Download Type (Section 5.6.2 of [RFC6407]) is part of the group policy. The prf (defined in Section 3.2) is PRF-HMAC-SHA-256 [RFC4868]. The base_key (also defined in Section 3.2) is the KEK_ALGORITHM_KEY used to decrypt the GROUPKEY-PUSH message. Note that for some algorithms the KEK_ALGORITHM_KEY will include an explicit Initialization Vector (IV) before the actual key (Section 5.6.2.1 of [RFC6407]), but it is not used in the definition of the base_key.
当KEK下载类型（RFC6407第5.6.2节）是集团政策的一部分时，使用这种类型的密钥确认。prf（定义见第3.2节）为prf-HMAC-SHA-256[RFC4868]。基本密钥（也在第3.2节中定义）是用于解密GROUPKEY-PUSH消息的KEK算法密钥。请注意，对于某些算法，KEK_算法_密钥将在实际密钥（RFC6407第5.6.2.1节）之前包含一个显式初始化向量（IV），但它不用于基本_密钥的定义。
This type of Rekey ACK can be used when the KEK_MANAGEMENT_ALGORITHM KEK attribute with a value representing the Logical Key Hierarchy (LKH) is part of the group policy (Section 5.3.1.1 of [RFC6407]). The prf is PRF-HMAC-SHA-256. The base_key is the Key Data field value taken from the first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute (see Section 5.6.3.1 of [RFC6407]). This is a secret symmetric key that the GCKS shares with the GM. Note that for some algorithms the LKH Key structure will include an explicit IV before the actual key (Section 5.6.3.1 of [RFC6407]), but it is not used in the definition of the base_key.
当具有表示逻辑密钥层次结构（LKH）的值的KEK_管理_算法KEK属性是组策略的一部分时（RFC6407第5.3.1.1节），可以使用这种类型的密钥确认。prf为prf-HMAC-SHA-256。基本密钥是取自LKH\U下载数组属性中第一个LKH密钥结构的密钥数据字段值（见[RFC6407]第5.6.3.1节）。这是GCKS与GM共享的秘密对称密钥。请注意，对于某些算法，LKH密钥结构将在实际密钥之前包含一个显式IV（RFC6407第5.6.3.1节），但未在基本密钥的定义中使用。
This type of Rekey ACK is identical to the REKEY_ACK_KEK_SHA256 Type, except that the prf is PRF-HMAC-SHA-512 (defined in [RFC4868]).
除了prf为prf-HMAC-SHA-512（在[RFC4868]中定义）外，该类型的重新密钥确认与重新密钥确认SHA256类型相同。
This type of Rekey ACK is identical to the REKEY_ACK_LKH_SHA256 Type, except that the prf is PRF-HMAC-SHA-512 (defined in [RFC4868]).
除了prf为prf-HMAC-SHA-512（在[RFC4868]中定义）之外，该类型的密钥应答与密钥应答的密钥应答相同。
The GROUPKEY-PUSH message defined in [RFC6407] is reproduced in Figure 2. The SA and Key Download (KD) payloads contain the actual policy and keying material being distributed to the GM. The Sequence Number (SEQ) payload contains a sequence number that is used by the GM for replay protection. This sequence number defines a unique rekey message delivered to that GM. One or more Delete (D) payloads optionally specify the deletion of the existing group policy. The Signature (SIG) payload includes a signature of a hash of the entire GROUPKEY-PUSH message (excepting the SIG payload octets) before it has been encrypted.
图2中重现了[RFC6407]中定义的GROUPKEY-PUSH消息。SA和密钥下载（KD）有效载荷包含分发给GM的实际策略和密钥材料。序列号（SEQ）有效载荷包含GM用于重播保护的序列号。此序列号定义了传递给该GM的唯一密钥更新消息。一个或多个删除（D）有效载荷可选择指定删除现有组策略。签名（SIG）有效载荷包括加密前整个GROUPKEY-PUSH消息（SIG有效载荷八位字节除外）的哈希签名。
GM GCKS
-- ----
<---- HDR*, SEQ, [D,] SA, KD, SIG
GM GCKS
-- ----
<---- HDR*, SEQ, [D,] SA, KD, SIG
* Protected by the Rekey SA KEK; encryption occurs after HDR
* 受Rekey SA KEK保护；加密发生在HDR之后
Figure 2: GROUPKEY-PUSH Message (from RFC 6407)
图2:GROUPKEY-PUSH消息（来自RFC6407）
When the GM has received a KEK_ACK_REQUESTED attribute in an SA KEK and it chooses to respond, it returns the value of the Sequence Number taken from the GROUPKEY-PUSH message to the GCKS along with its identity. This tuple alerts the GCKS that the GM has received the GROUPKEY-PUSH message and implemented the policy contained therein. The GROUPKEY-PUSH Acknowledgement Message is shown in Figure 3.
当GM在SA KEK中收到KEK_ACK_REQUESTED属性并选择响应时，它将从GROUPKEY-PUSH消息中获取的序列号值及其标识返回给GCK。此元组提醒GCK GM已收到GROUPKEY-PUSH消息并实施其中包含的策略。GROUPKEY-PUSH确认消息如图3所示。
GM GCKS
-- ----
HDR, HASH, SEQ, ID ---->
GM GCKS
-- ----
HDR, HASH, SEQ, ID ---->
Figure 3: GROUPKEY-PUSH Acknowledgement Message
图3:GROUPKEY-PUSH确认消息
The IP header for the GROUPKEY-PUSH Acknowledgement Message is constructed as if it were a reply to the GROUPKEY-PUSH message. That is, the source address of the GROUPKEY-PUSH message becomes the destination address of the GROUPKEY-PUSH Acknowledgement Message, and the GM includes its own IP address as the source address of the GROUPKEY-PUSH Acknowledgement Message. The source port in the GROUPKEY-PUSH message UDP header becomes the destination port of the GROUPKEY-PUSH Acknowledgement Message UDP header, and the destination port of the GROUPKEY-PUSH message UDP header becomes the source port of the GROUPKEY-PUSH Acknowledgement Message UDP header.
GROUPKEY-PUSH确认消息的IP报头被构造为对GROUPKEY-PUSH消息的回复。也就是说，GROUPKEY-PUSH消息的源地址成为GROUPKEY-PUSH确认消息的目的地址，并且GM包括其自己的IP地址作为GROUPKEY-PUSH确认消息的源地址。GROUPKEY-PUSH消息UDP头中的源端口成为GROUPKEY-PUSH确认消息UDP头的目标端口，GROUPKEY-PUSH消息UDP头的目标端口成为GROUPKEY-PUSH确认消息UDP头的源端口。
The following sections describe the payloads in the GROUPKEY-PUSH Acknowledgement Message.
以下各节描述GROUPKEY-PUSH确认消息中的有效负载。
The message begins with a header as defined for the GDOI GROUPKEY-PUSH message in Section 4.2 of [RFC6407]. The fields in the HDR MUST be initialized as follows. The cookies of a GROUPKEY-PUSH message act as a Security Parameter Index (SPI) and are copied to the Acknowledgement Message. "Next Payload" identifies a "Hash (HASH)" payload (value 8) [ISAKMP-NP]. Major Version is 1 and Minor Version is 0. The Exchange Type has value 35 for the GDOI GROUPKEY-PUSH Acknowledgement Message. Flags are set to 0. Message ID MUST be set to 0. Length is according to Section 4.2 of [RFC6407].
消息以[RFC6407]第4.2节中为GDOI GROUPKEY-PUSH消息定义的头开始。HDR中的字段必须按如下方式初始化。GROUPKEY-PUSH消息的cookies充当安全参数索引（SPI），并复制到确认消息中。“下一个有效负载”标识“哈希（Hash）”有效负载（值8）[ISAKMP-NP]。主要版本为1，次要版本为0。对于GDOI GROUPKEY-PUSH确认消息，交换类型的值为35。标志设置为0。消息ID必须设置为0。长度符合[RFC6407]第4.2节的规定。
The HASH payload is the same one used in the GDOI GROUPKEY-PULL exchange defined in Section 3.2 of [RFC6407]. The hash data in the HASH payload is created as follows:
哈希有效载荷与[RFC6407]第3.2节中定义的GDOI GROUPKEY-PULL交换中使用的相同。哈希有效负载中的哈希数据创建如下：
HASH = prf(ack_key, SEQ | ID)
哈希=prf（确认键，序号ID）
where:
哪里：
o "prf" is specific to the KEK_ACK_REQUESTED value and is described as part of that description.
o “prf”特定于KEK_确认_请求的值，并作为该描述的一部分进行描述。
o "|" indicates concatenation.
o “|”表示串联。
o "SEQ" and "ID" represent the bytes comprising the Sequence Number and Identification payloads.
o “SEQ”和“ID”表示包含序列号和标识有效载荷的字节。
The ack_key is computed from a Key Derivation Function (KDF) that conforms to KDF in feedback mode as defined in NIST SP800-108 [SP800-108], where the length of the derived keying material is the same as the output of the prf, there is no IV, and the optional counter is not used. Note: When the derived ack_key is smaller than the prf block size (i.e., 512 bits for PRF-HMAC-SHA-256), it is zero-filled to the right, as specified in Section 2.1.2 of [RFC4868].
ack_密钥由密钥派生函数（KDF）计算得出，该函数符合NIST SP800-108[SP800-108]中定义的反馈模式下的KDF，其中派生密钥材料的长度与prf的输出相同，没有IV，并且不使用可选计数器。注：当导出的ack_密钥小于prf块大小（即，prf-HMAC-SHA-256为512位）时，按照[RFC4868]第2.1.2节的规定，其右侧为零填充。
ack_key = prf(base_key, "GROUPKEY-PUSH ACK" | SPI | L)
ack|U key=prf（基本|U key，“组键-推送ack”| SPI | L）
where:
哪里：
o "prf" is specific to the KEK_ACK_REQUESTED value and is described as part of that description.
o “prf”特定于KEK_确认_请求的值，并作为该描述的一部分进行描述。
o "base_key" is specific to the KEK_ACK_REQUESTED value and is described as part of that description. If the base_key is smaller than the prf block size (i.e., 512 bits for PRF-HMAC-SHA-256), then it is zero-filled to the right, as specified in Section 2.1.2 of [RFC4868].
o “基本密钥”特定于KEK_ACK_请求的值，并作为该描述的一部分进行描述。如果基本密钥小于prf块大小（即，prf-HMAC-SHA-256为512位），则按照[RFC4868]第2.1.2节的规定，其右侧为零填充。
o "|" indicates concatenation.
o “|”表示串联。
o "GROUPKEY-PUSH ACK" is a label encoded as a null-terminated ASCII string.
o “GROUPKEY-PUSH-ACK”是编码为以空结尾的ASCII字符串的标签。
o "SPI" (per [RFC6407]) is the Initiator Cookie followed by the Responder Cookie taken from the GROUPKEY-PUSH message HDR, which describes the context of the key usage.
o “SPI”（per[RFC6407]）是发起方Cookie，后跟从GROUPKEY-PUSH消息HDR中获取的响应方Cookie，该消息描述密钥使用的上下文。
o "L" is a length field matching the number of bits in the ack_key. L MUST match the length of the base_key (i.e., 512 bits for PRF-HMAC-SHA-256). The value L is represented as two octets in network byte order (that is, most significant byte first).
o “L”是与ack_键中的位数匹配的长度字段。L必须匹配基本密钥的长度（即，PRF-HMAC-SHA-256为512位）。值L以网络字节顺序表示为两个八位字节（即，最高有效字节排在第一位）。
The Sequence Number payload is defined in Section 5.7 of [RFC6407]. The value in the GROUPKEY-PUSH SEQ payload is copied to the GROUPKEY-PUSH ACK SEQ payload.
序列号有效载荷在[RFC6407]第5.7节中定义。GROUPKEY-PUSH-SEQ有效载荷中的值被复制到GROUPKEY-PUSH-ACK-SEQ有效载荷。
The Identification payload is used as defined in Section 5.1 of [RFC6407]. The ID payload contains an ID Type of ID_IPV4_ADDR, ID_IPV6_ADDR, or ID_OID as defined in [RFC8052] for GDOI exchanges. The Protocol ID and Port fields MUST be set to 0. The address provided in the ID payload represents the IP address of the GM and MUST match the source IP address used for the most recent GROUPKEY-PULL exchange.
按照[RFC6407]第5.1节的规定使用识别有效载荷。ID有效负载包含一个ID类型，即[RFC8052]中为GDOI交换定义的ID_IPV4_ADDR、ID_IPV6_ADDR或ID_OID。协议ID和端口字段必须设置为0。ID有效负载中提供的地址表示GM的IP地址，并且必须与用于最新GROUPKEY-PULL交换的源IP地址匹配。
When a GM receives an SA KEK payload (in a GROUPKEY-PULL exchange or GROUPKEY-PUSH message) including a KEK_ACK_REQUESTED attribute, it records in its group state some indication that it is expected to return a GROUPKEY-PUSH ACK. A GM recognizing the attribute MUST honor the KEK_ACK_REQUESTED attribute by returning Acknowledgements, because it can be expected that the GCKS is likely to take some policy-specific action regarding unresponsive GMs, including ceasing to deliver GROUPKEY-PUSH messages to it.
当GM接收到SA KEK有效载荷（在GROUPKEY-PULL交换或GROUPKEY-PUSH消息中）包括KEK_ACK_REQUESTED属性时，它会在其组状态中记录预期返回GROUPKEY-PUSH ACK的一些指示。识别该属性的GM必须通过返回确认来遵守KEK_ACK_REQUESTED属性，因为可以预期GCK可能会针对无响应的GM采取一些特定于策略的措施，包括停止向其发送GROUPKEY-PUSH消息。
If a GM cannot respond with the requested type of Acknowledgement, it continues with protocol exchange and participates in the group. In any case, if a GM stops receiving GROUPKEY-PUSH messages from a GCKS, it will re-register before existing SAs expire, so omitting the sending of Acknowledgements should not be critical.
如果GM无法响应请求的确认类型，它将继续协议交换并参与组。在任何情况下，如果GM停止接收来自GCKS的GROUPKEY-PUSH消息，它将在现有SAs过期之前重新注册，因此忽略发送确认不应是关键。
When a GM receives a GROUPKEY-PUSH message that contains a KEK_ACK_REQUESTED attribute in the SA KEK payload, it processes the message according to RFC 6407. When it concludes successful processing of the message, it formulates the GROUPKEY-PUSH ACKs as described in Section 3 and delivers the message to the GCKS from which the GROUPKEY-PUSH message was received. A GROUPKEY-PUSH ACK is sent even if the GROUPKEY-PUSH message contains a Delete payload for the KEK used to protect the GROUPKEY-PUSH message.
当GM接收到在SA KEK有效载荷中包含KEK_ACK_请求属性的GROUPKEY-PUSH消息时，它将根据RFC 6407处理该消息。当完成消息的成功处理时，它按照第3节中的描述制定GROUPKEY-PUSH确认，并将消息发送给接收GROUPKEY-PUSH消息的GCK。即使GROUPKEY-PUSH消息包含用于保护GROUPKEY-PUSH消息的KEK的删除有效负载，也会发送GROUPKEY-PUSH确认。
When a GCKS policy includes requesting a GROUPKEY-PUSH ACK from GMs, it includes the KEK_ACK_REQUESTED attribute in the SA KEK payload. It does this each time the SA KEK is delivered, in both GROUPKEY-PULL exchanges and GROUPKEY-PUSH messages. The value of the KEK_ACK_REQUESTED attribute will depend upon the type of SA KEK policy, as described in Section 2.
当GCKS策略包括从GMs请求GROUPKEY-PUSH ACK时，它在SA KEK有效负载中包括KEK_ACK_REQUESTED属性。每次在GROUPKEY-PULL交换和GROUPKEY-PUSH消息中交付SA KEK时，它都会执行此操作。KEK_ACK_REQUESTED属性的值将取决于SA KEK策略的类型，如第2节所述。
When a GCKS receives a GROUPKEY-PUSH ACK (identified by an Exchange Type of GROUPKEY-PUSH-ACK), it first verifies that the group policy includes receiving GROUPKEY-PUSH ACKs. If not, the message is discarded. GCKS implementations SHOULD keep a record (e.g., a hash value) of recently received GROUPKEY-PUSH Acknowledgement Messages and reject duplicate messages prior to performing cryptographic operations. This enables an early discard of the replayed messages.
当GCKS收到GROUPKEY-PUSH-ACK（由交换类型GROUPKEY-PUSH-ACK标识）时，它首先验证组策略是否包括接收GROUPKEY-PUSH-ACK。否则，将丢弃该消息。GCKS实现应保留最近收到的GROUPKEY-PUSH确认消息的记录（例如哈希值），并在执行加密操作之前拒绝重复消息。这样可以提前放弃重播的消息。
If the message is expected, the GCKS validates the format of the message and verifies that the HASH has been properly constructed as described in Section 3.2. If validation fails, the message is discarded. The GCKS extracts the sequence number and identity of the GM from the SEQ and ID payloads, respectively, and records the fact that the GM received the GROUPKEY-PUSH message represented by its sequence number.
如果消息是预期的，GCKS将验证消息的格式，并验证哈希是否已按照第3.2节所述正确构造。如果验证失败，消息将被丢弃。GCKS分别从SEQ和ID有效载荷中提取GM的序列号和标识，并记录GM收到由其序列号表示的GROUPKEY-PUSH消息的事实。
The GCKS manages group policy as well as determining which GM devices are presently "live" members of the group (i.e., members either sending or receiving messages). Group policy includes a strategy to ensure that rekey messages with current group policy reach all live GMs. This is discussed briefly in Section 5.3 of [RFC4046]. The GROUPKEY-PUSH Acknowledgement Message specified in this memo provides the GCKS with an additional method to assess if a GM is live and has received the current group policy. But it is possible for a rekey message or GROUPKEY-PUSH Acknowledgement Message to be discarded in the network, resulting in a live GM appearing to be unresponsive. Also, a GM might not be able to respond with a GROUPKEY-PUSH ACK, so the GCKS should use caution in using a lack of an Acknowledgement Message as the only factor in determining whether a GM is live. In particular, a GCKS SHOULD NOT consider a GM to have left the group until it has received at least one ACK from the GM.
GCKS管理组策略，并确定哪些GM设备目前是组的“活动”成员（即发送或接收消息的成员）。组策略包括一种策略，以确保使用当前组策略的密钥更新消息到达所有活动GMs。[RFC4046]第5.3节对此进行了简要讨论。本备忘录中指定的GROUPKEY-PUSH确认消息为GCKS提供了一种额外的方法，用于评估GM是否处于活动状态并已收到当前的集团政策。但是，在网络中可能会丢弃重新密钥消息或GROUPKEY-PUSH确认消息，从而导致live GM看起来没有响应。此外，GM可能无法使用GROUPKEY-PUSH ACK进行响应，因此GCK应谨慎使用缺少确认消息作为确定GM是否有效的唯一因素。特别是，GCKS不应该考虑GM已经离开该组，直到它从GM接收到至少一个ACK。
Some management considerations for determining how a GM handles Acknowledgement Messages are as follows:
确定GM如何处理确认消息的一些管理注意事项如下：
o A GM MUST respond with Acknowledgement Messages when requested, as a GCKS can subsequently determine when a GM unexpectedly becomes unresponsive.
o GM必须在收到请求时回复确认消息，因为GCKS随后可以确定GM何时意外失去响应。
o A GM receiving a GROUPKEY-PUSH message as a multicast message MAY introduce jitter to the timing of its Acknowledgement Message to help the GCKS better manage replies from GMs. A GM MUST NOT delay sending an Acknowledgement Message for more than 5 seconds. a GCKS SHOULD NOT declare an Acknowledgement Message as missing until it has waited at least 10 seconds. Implementations SHOULD make these timers configurable.
o 作为多播消息接收GROUPKEY-PUSH消息的GM可能会对其确认消息的定时引入抖动，以帮助gck更好地管理来自GMs的回复。GM发送确认信息的延迟时间不得超过5秒。GCKS在等待至少10秒之前不应将确认消息声明为丢失。实现应该使这些计时器可配置。
Some management considerations for determining how the GCKS handles Acknowledgement Messages are as follows:
确定GCKS如何处理确认消息的一些管理注意事项如下：
o Non-receipt of an Acknowledgement Message is an indication that a GM is unable to respond. A GCKS SHOULD wait at least several seconds before determining non-receipt, as GMs could add jitter to the response time before sending an Acknowledgement Message.
o 未收到确认信息表示GM无法响应。GCKS在确定未接收之前应至少等待几秒钟，因为GMs可能会在发送确认消息之前增加响应时间的抖动。
o If the GCKS is aware that GMs are expected to respond, then non-receipt of an Acknowledgement Message SHOULD trigger a logging event. The GCKS MAY be configured with such additional policy actions as transmitting the GROUPKEY-PUSH message several times in a short period of time (as suggested in [RFC4046]), thereby mitigating loss of either the GROUPKEY-PUSH message or an Acknowledgement Message. Another policy action could be to alert GCKS administrators of GMs that do not return several consecutive Acknowledgement Messages or even removing unresponsive GMs from the group. However, a GCKS with a policy of removing GMs from the group needs to be aware that a GM that has not responded will not receive a newer group policy until it initiates contact with the GCKS again.
o 如果GCKS知道GMs将响应，则未收到确认消息应触发日志事件。GCK可配置有这样的附加策略动作，如在短时间内多次发送GROUPKEY-PUSH消息（如[RFC4046]中所建议），从而减轻GROUPKEY-PUSH消息或确认消息的丢失。另一个策略操作可能是提醒GCKS管理员GMs不会返回多个连续的确认消息，甚至不会从组中删除无响应的GMs。但是，具有从集团中删除GM的政策的GCKS需要知道，未响应的GM在再次与GCKS联系之前不会收到新的集团政策。
o When a GROUPKEY-PUSH message includes a Delete payload for the KEK used to protect the GROUPKEY-PUSH message, the GCKS SHOULD NOT itself delete the KEK until it has given GMs the opportunity to acknowledge receipt of the GROUPKEY-PUSH message. This could be several seconds, as GMs could add jitter to the response time before sending an Acknowledgement Message.
o 当GROUPKEY-PUSH消息包含用于保护GROUPKEY-PUSH消息的KEK的删除有效负载时，GCKS不应自行删除KEK，直到它给GMs机会确认收到GROUPKEY-PUSH消息。这可能需要几秒钟，因为GMs可能会在发送确认消息之前增加响应时间的抖动。
o A GCKS SHOULD log failure events, such as receiving Acknowledgement Messages for a group in which the GCKS has not requested Acknowledgements, receiving malformed Acknowledgements, and Acknowledgements that fail validation.
o GCKS应记录失败事件，例如接收GCKS未请求确认的组的确认消息、接收格式错误的确认以及验证失败的确认。
There are three areas of security considerations to consider: the protection of the GROUPKEY-PUSH ACK, whether the GM should transmit a GROUPKEY-PUSH ACK, and whether a GCKS should accept a GROUPKEY-PUSH ACK. These are addressed in the following subsections.
有三个安全方面需要考虑：GROUPKEY-PUSH ACK的保护、GM是否应发送GROUPKEY-PUSH ACK，以及GCKS是否应接受GROUPKEY-PUSH ACK。这些问题将在以下小节中讨论。
The construction of the HASH defined in this memo uses PRF-HMAC-SHA-256 or PRF-HMAC-SHA-512. The strengths of PRF-HMAC-SHA-256 and PRF-HMAC-SHA-512 were unquestioned at the time this memo was developed. When a HASH construction using a different prf becomes necessary, a new KEK_ACK_REQUESTED value will be defined in a new specification.
本备忘录中定义的哈希的构造使用PRF-HMAC-SHA-256或PRF-HMAC-SHA-512。在制定本备忘录时，PRF-HMAC-SHA-256和PRF-HMAC-SHA-512的强度是毋庸置疑的。当需要使用不同prf的哈希构造时，将在新规范中定义新的KEK_ACK_请求值。
The GROUPKEY-PUSH ACK is an Internet Security Association and Key Management Protocol (ISAKMP) message as discussed in [RFC2408]. (Note: RFC 2408 has been obsoleted by RFC 7296, but only RFC 2408 applies in this context.) Message authentication and protection against man-in-the-middle attacks are provided by the inclusion of a HASH payload that includes the output of an HMAC computation over the bytes of the message.
GROUPKEY-PUSH-ACK是互联网安全关联和密钥管理协议（ISAKMP）消息，如[RFC2408]中所述。（注意：RFC 7296已经淘汰了RFC 2408，但只有RFC 2408适用于此上下文。）消息身份验证和防止中间人攻击的保护是通过包含散列负载来提供的，该负载包括消息字节上HMAC计算的输出。
Because the KEK is a group secret, when the value of REKEY_ACK_KEK is specified, impersonation of a victim GM by another authorized GM is possible. However, security considerations regarding such an impersonation are limited to a false claim that a victim GM has received a GROUPKEY-PUSH when the victim GM has in fact not received it (e.g., because an active attacker has discarded the GROUPKEY-PUSH). If a GCKS policy includes sending retransmissions of the GROUPKEY-PUSH message to that victim GM, then the victim GM might not receive replacement SAs. However, this does not introduce any additional threats over a use case where the GROUPKEY-PUSH ACK is not deployed and GROUPKEY-PUSH messages are withheld from a victim GM by an active attacker. These threats can be mitigated by using a value of REKEY_ACK_LKH, due to the use of a secret pairwise key shared between the GCKS and an individual GM.
因为KEK是一个组秘密，所以当指定了REKEY_ACK_KEK的值时，另一个授权的GM可以模拟受害者GM。但是，有关此类模拟的安全考虑仅限于虚假声明，即受害者GM已收到GROUPKEY-PUSH，而受害者GM实际上并未收到它（例如，因为活动攻击者已放弃GROUPKEY-PUSH）。如果GCKS策略包括向受害GM发送GROUPKEY-PUSH消息的重新传输，则受害GM可能不会收到替换SA。但是，在未部署GROUPKEY-PUSH ACK且GROUPKEY-PUSH消息被主动攻击者从受害者GM扣留的用例中，这不会引入任何额外的威胁。这些威胁可以通过使用REKEY_ACK_LKH值来缓解，这是由于使用了GCK和单个GM之间共享的秘密成对密钥。
Confidentiality is not provided for the GROUPKEY-PUSH ACK. The contents of the message, including the hash value, the sequence number from the GROUPKEY-PUSH message to which it is acknowledging receipt, and the identity of the GM, can be observed by a passive attacker. Observation of a hash value or set of hash values will not compromise the hash key. The identity of the GM is also available to the passive attacker as the source IP address of the packet. Note that the sequence number in the GROUPKEY-PUSH ACK does reveal the sequence number (previously not available to the attacker) that was
GROUPKEY-PUSH-ACK不提供机密性。被动攻击者可以观察到消息的内容，包括哈希值、确认收到的GROUPKEY-PUSH消息的序列号以及GM的身份。观察哈希值或一组哈希值不会影响哈希键。被动攻击者还可以使用GM的身份作为数据包的源IP地址。请注意，GROUPKEY-PUSH-ACK中的序列号确实显示了被攻击的序列号（攻击者以前不可用）
included in the GROUPKEY-PUSH message. However, the attacker is assumed to not be in possession of the key used to encrypt the message and thus cannot create a spoofed GROUPKEY-PUSH message. Therefore, the attacker does not derive any direct value from learning the sequence number.
包含在GROUPKEY-PUSH消息中。但是，假定攻击者不拥有用于加密消息的密钥，因此无法创建伪造的GROUPKEY-PUSH消息。因此，攻击者不会从学习序列号中获得任何直接值。
A GM transmits an ACK only when the policy of the most recently received SA KEK includes a request by the GCKS for ACKs, and the ACK is only returned after processing the GROUPKEY-PUSH message according to Section 4.4 of [RFC6407]. In other words, the form of the GROUPKEY-PUSH message will have been validated, replay protection completed, and the digital signature verified as being genuine. Therefore, the threat of a GM responding to a spoofed or resent GROUPKEY-PUSH message, and the possibility of the GM being used to propagate a Distributed Denial of Service (DDoS) attack on a GCKS, are mitigated. For more information, see the security considerations for a GROUPKEY-PUSH message as described in Section 7.3 of [RFC6407].
GM仅在最近收到的SA KEK的策略包括GCKS对ACK的请求时发送ACK，并且仅在根据[RFC6407]第4.4节处理GROUPKEY-PUSH消息后返回ACK。换句话说，GROUPKEY-PUSH消息的形式将得到验证，重播保护完成，数字签名验证为真实。因此，GM响应伪造或重新发送的GROUPKEY-PUSH消息的威胁，以及GM被用于在GCKS上传播分布式拒绝服务（DDoS）攻击的可能性都得到了缓解。有关更多信息，请参阅[RFC6407]第7.3节中描述的GROUPKEY-PUSH消息的安全注意事项。
A GCKS receiving ACKs will follow the validation steps described in Section 5 before interpreting the contents of the message. The GCKS will then be sure to operate only on messages that have been sent by an authorized GM.
接收ACK的GCKS在解释报文内容之前，将遵循第5节所述的验证步骤。然后，GCKS将确保仅对授权GM发送的消息进行操作。
A GCKS SHOULD be prepared to receive GROUPKEY-PUSH ACKs from each GM to which it was sent. That is, it needs to ensure that it has sufficient resources (e.g., receive queue size) so that it does not unnecessarily drop ACKs. A GCKS should be aware that a large number of replayed or invalid GROUPKEY-PUSH messages could be addressed to it. However, this is no worse a threat than if it received a large number of other types of replayed or invalid GDOI or other messages containing a HASH payload.
GCKS应准备好从发送给它的每个GM接收GROUPKEY-PUSH确认。也就是说，它需要确保有足够的资源（例如，接收队列大小），以便不会不必要地丢弃ack。GCKS应该知道，大量重播或无效的GROUPKEY-PUSH消息可能会发送给它。然而，与收到大量其他类型的重播或无效GDOI或包含哈希有效负载的其他消息相比，这种威胁并不更严重。
How a GCKS processes the sequence number and identity included in an ACK is a matter of local policy and is outside the scope of this memo.
GCKS如何处理ACK中包含的序列号和标识是当地政策的问题，不在本备忘录的范围内。
The following additions have been made to the "Group Domain of Interpretation (GDOI) Payloads" [GDOI-REG] registry.
在“集团解释域（GDOI）有效载荷”[GDOI-REG]注册表中添加了以下内容。
A new attribute has been added to the "SA KEK Payload Values - KEK Attributes" registry. The ID Class name is KEK_ACK_REQUESTED with a value of 9 and is a Basic attribute.
“SA KEK有效负载值-KEK属性”注册表中添加了一个新属性。ID类名为KEK_ACK_REQUESTED，值为9，是一个基本属性。
A new registry defining values for KEK_ACK_REQUESTED, "SA KEK Payload Values - KEK_ACK_REQUESTED", has been added; the initial registrations are shown in the following table. The terms "Reserved", "Unassigned", and "Private Use" are to be applied as defined in [RFC8126]. The registration procedure is Specification Required.
添加了一个新的注册表，该注册表定义了KEK_ACK_请求的值，“SAKEK有效负载值-KEK_ACK_请求”；初始注册如下表所示。术语“保留”、“未分配”和“专用”应按照[RFC8126]中的定义应用。注册程序是必需的。
Value Type
------- --------------------
0 Reserved
1 REKEY_ACK_KEK_SHA256
2 REKEY_ACK_LKH_SHA256
3 REKEY_ACK_KEK_SHA512
4 REKEY_ACK_LKH_SHA512
5-128 Unassigned
129-255 Private Use
Value Type
------- --------------------
0 Reserved
1 REKEY_ACK_KEK_SHA256
2 REKEY_ACK_LKH_SHA256
3 REKEY_ACK_KEK_SHA512
4 REKEY_ACK_LKH_SHA512
5-128 Unassigned
129-255 Private Use
A new registry describing ISAKMP Exchange Types for the GDOI, "GDOI DOI Exchange Types", has been added under the "Group Domain of Interpretation (GDOI) Payloads" registry [GDOI-REG]. This new registry defines DOI Specific Use values [ISAKMP-EXCH], which are Exchange Type values used with the ISAKMP GDOI DOI. The registration procedure is Specification Required. The terms "Known Unregistered Use" and "Unassigned" are to be applied as defined in [RFC8126].
在“集团解释域（GDOI）有效载荷”注册表[GDOI-REG]下添加了一个描述GDOI的ISAKMP交换类型的新注册表“GDOI DOI交换类型”。此新注册表定义了特定于DOI的使用值[ISAKMP-EXCH]，这些值是与ISAKMP GDOI DOI一起使用的交换类型值。注册程序是必需的。术语“已知未注册使用”和“未分配”应按照[RFC8126]中的定义应用。
Value Phase Reference
---------------------- ------ ---------
GROUPKEY-PULL 32 RFC 6407
GROUPKEY-PUSH 33 RFC 6407
Known Unregistered Use 34
GROUPKEY-PUSH-ACK 35 RFC 8263
Unassigned 36-239
Value Phase Reference
---------------------- ------ ---------
GROUPKEY-PULL 32 RFC 6407
GROUPKEY-PUSH 33 RFC 6407
Known Unregistered Use 34
GROUPKEY-PUSH-ACK 35 RFC 8263
Unassigned 36-239
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.
[RFC4868]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，DOI 10.17487/RFC4868，2007年5月<https://www.rfc-editor.org/info/rfc4868>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[RFC6407]Weis，B.，Rowles，S.，和T.Hardjono，“解释的集团领域”，RFC 6407，DOI 10.17487/RFC6407，2011年10月<https://www.rfc-editor.org/info/rfc6407>.
[RFC8052] Weis, B., Seewald, M., and H. Falk, "Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services", RFC 8052, DOI 10.17487/RFC8052, June 2017, <https://www.rfc-editor.org/info/rfc8052>.
[RFC8052]Weis，B.，Seewald，M.，和H.Falk，“IEC 62351安全服务的集团解释域（GDOI）协议支持”，RFC 8052，DOI 10.17487/RFC8052，2017年6月<https://www.rfc-editor.org/info/rfc8052>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[GDOI-REG] Internet Assigned Numbers Authority, "Group Domain of Interpretation (GDOI) Payload Type Values", IANA Registry, September 2017, <https://www.iana.org/assignments/ gdoi-payloads/>.
[GDOI-REG]互联网分配号码管理局，“集团解释域（GDOI）有效载荷类型值”，IANA注册，2017年9月<https://www.iana.org/assignments/ gdoi有效载荷/>。
[ISAKMP-EXCH] Internet Assigned Numbers Authority, "Internet Key Exchange (IKE) Attributes Exchange Type Values", IANA Registry, May 2013, <https://www.iana.org/assignments/ipsec-registry/>.
[ISAKMP-EXCH]互联网分配号码管理局，“互联网密钥交换（IKE）属性交换类型值”，IANA注册表，2013年5月<https://www.iana.org/assignments/ipsec-registry/>.
[ISAKMP-NP] Internet Assigned Numbers Authority, "Internet Key Exchange (IKE) Attributes Next Protocol Types", IANA Registry, May 2013, <https://www.iana.org/assignments/ipsec-registry/>.
[ISAKMP-NP]互联网分配号码管理局，“互联网密钥交换（IKE）属性下一个协议类型”，IANA注册表，2013年5月<https://www.iana.org/assignments/ipsec-registry/>.
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998, <https://www.rfc-editor.org/info/rfc2408>.
[RFC2408]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，DOI 10.17487/RFC2408，1998年11月<https://www.rfc-editor.org/info/rfc2408>.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, <https://www.rfc-editor.org/info/rfc4046>.
[RFC4046]Baugher，M.，Canetti，R.，Dondeti，L.，和F.Lindholm，“多播安全（MSEC）组密钥管理体系结构”，RFC 4046，DOI 10.17487/RFC4046，2005年4月<https://www.rfc-editor.org/info/rfc4046>.
[SP800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions (Revised)", National Institute of Science and Technology, NIST Special Publication 800-108, DOI 10.6028/NIST.SP.800-108, October 2009, <http://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-108.pdf>.
[SP800-108]Chen，L.“使用伪随机函数进行密钥推导的建议（修订版）”，国家科学技术研究院，NIST特别出版物800-108，DOI 10.6028/NIST.SP.800-108，2009年10月<http://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-108.pdf>。
Acknowledgements
致谢
Mike Hamada, Adrian Farrel, and Yaron Sheffer provided many useful technical and editorial comments and suggestions for improvement.
Mike Hamada、Adrian Farrel和Yaron Sheffer提供了许多有用的技术和编辑评论以及改进建议。
Authors' Addresses
作者地址
Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 United States of America
Brian Weis Cisco Systems美国加利福尼亚州圣何塞塔斯曼大道西170号95134-1706
Phone: +1-408-526-4796
Email: bew@cisco.com
Phone: +1-408-526-4796
Email: bew@cisco.com
Umesh Mangla Juniper Networks Inc. 1133 Innovation Way Sunnyvale, California 94089 United States of America
Umesh Mangla Juniper Networks Inc.美国加利福尼亚州桑尼维尔市创新路1133号，邮编94089
Phone: +1-408-936-1022
Email: umangla@juniper.net
Phone: +1-408-936-1022
Email: umangla@juniper.net
Thomas Karl Deutsche Telekom Landgrabenweg 151 Bonn 53227 Germany
Thomas Karl Deutsche Telekom Landgrabenweg 151波恩53227德国
Phone: +49-228-18138122
Email: thomas.karl@telekom.de
Phone: +49-228-18138122
Email: thomas.karl@telekom.de
Nilesh Maheshwari
尼莱什·马赫什瓦里
Email: nileshm@gmail.com
Email: nileshm@gmail.com