Internet Engineering Task Force (IETF) B. Weis
Request for Comments: 6407 S. Rowles
Obsoletes: 3547 Cisco Systems
Category: Standards Track T. Hardjono
ISSN: 2070-1721 MIT
October 2011
Internet Engineering Task Force (IETF) B. Weis
Request for Comments: 6407 S. Rowles
Obsoletes: 3547 Cisco Systems
Category: Standards Track T. Hardjono
ISSN: 2070-1721 MIT
October 2011
The Group Domain of Interpretation
解释的群体域
Abstract
摘要
This document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. This document replaces RFC 3547.
本文件描述了RFC 3547中规定的集团解释域（GDOI）协议。GDOI提供组密钥管理，以根据RFC 4046中指定的体系结构支持安全的组通信。GDOI管理组安全关联，这些关联由IPsec和潜在的其他数据安全协议使用。本文件取代RFC 3547。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6407.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6407.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 7
2. GDOI Phase 1 Protocol . . . . . . . . . . . . . . . . . . . . 8
2.1. DOI value . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. UDP port . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 9
3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Group Member Operations . . . . . . . . . . . . . . . . . 12
3.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 13
3.5. Counter-Modes of Operation . . . . . . . . . . . . . . . . 14
4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 16
4.1. Use of Signature Keys . . . . . . . . . . . . . . . . . . 17
4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 17
4.3. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 17
4.4. Group Member Operations . . . . . . . . . . . . . . . . . 18
5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 19
5.1. Identification Payload . . . . . . . . . . . . . . . . . . 20
5.2. Security Association Payload . . . . . . . . . . . . . . . 20
5.3. SA KEK Payload . . . . . . . . . . . . . . . . . . . . . . 21
5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 27
5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 30
5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 34
5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 44
5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 45
6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7. Security Considerations . . . . . . . . . . . . . . . . . . . 47
7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 47
7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 48
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 7
2. GDOI Phase 1 Protocol . . . . . . . . . . . . . . . . . . . . 8
2.1. DOI value . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. UDP port . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 9
3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Group Member Operations . . . . . . . . . . . . . . . . . 12
3.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 13
3.5. Counter-Modes of Operation . . . . . . . . . . . . . . . . 14
4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 16
4.1. Use of Signature Keys . . . . . . . . . . . . . . . . . . 17
4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 17
4.3. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 17
4.4. Group Member Operations . . . . . . . . . . . . . . . . . 18
5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 19
5.1. Identification Payload . . . . . . . . . . . . . . . . . . 20
5.2. Security Association Payload . . . . . . . . . . . . . . . 20
5.3. SA KEK Payload . . . . . . . . . . . . . . . . . . . . . . 21
5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 27
5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 30
5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 34
5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 44
5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 45
6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7. Security Considerations . . . . . . . . . . . . . . . . . . . 47
7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 47
7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 48
7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 50
7.4. Forward and Backward Access Control . . . . . . . . . . . 51
7.5. Derivation of Keying Material . . . . . . . . . . . . . . 53
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
8.1. Additions to Current Registries . . . . . . . . . . . . . 53
8.2. New Registries . . . . . . . . . . . . . . . . . . . . . . 54
8.3. Cleanup of Existing Registries . . . . . . . . . . . . . . 55
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
10.1. Normative References . . . . . . . . . . . . . . . . . . . 57
10.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. GDOI Applications . . . . . . . . . . . . . . . . . . 62
Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 62
7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 50
7.4. Forward and Backward Access Control . . . . . . . . . . . 51
7.5. Derivation of Keying Material . . . . . . . . . . . . . . 53
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
8.1. Additions to Current Registries . . . . . . . . . . . . . 53
8.2. New Registries . . . . . . . . . . . . . . . . . . . . . . 54
8.3. Cleanup of Existing Registries . . . . . . . . . . . . . . 55
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
10.1. Normative References . . . . . . . . . . . . . . . . . . . 57
10.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. GDOI Applications . . . . . . . . . . . . . . . . . . 62
Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 62
Secure group and multicast applications require a method by which each group member shares common security policy and keying material. This document describes the Group Domain of Interpretation (GDOI), which is an Internet Security Association and Key Management Protocol (ISAMKP) [RFC2408] Domain of Interpretation (DOI), a group key management system. The GDOI distributes security associations (SAs) for IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security Payload (ESP) [RFC4303] protocols and potentially other data security protocols used in group applications. The GDOI uses the group key management model defined in [RFC4046], and described more generally by "The Multicast Group Security Architecture" [RFC3740].
安全组和多播应用程序要求每个组成员共享公共安全策略和密钥材料的方法。本文档描述了组解释域（GDOI），它是一个互联网安全关联和密钥管理协议（ISAMKP）[RFC2408]解释域（DOI），一个组密钥管理系统。GDOI为IPsec身份验证头（AH）[RFC4302]和封装安全有效负载（ESP）[RFC4303]协议以及组应用程序中可能使用的其他数据安全协议分发安全关联（SA）。GDOI使用[RFC4046]中定义的组密钥管理模型，并由“多播组安全体系结构”[RFC3740]更一般地描述。
In this group key management model, the GDOI protocol participants are a Group Controller/Key Server (GCKS) and a group member (GM). A group member contacts ("registers with") a GCKS to join the group. During the registration, mutual authentication and authorization are achieved, after which the GCKS distributes current group policy and keying material to the group member over an authenticated and encrypted session. The GCKS may also initiate contact ("rekeys") with group members to provide updates to group policy.
在这个组密钥管理模型中，GDOI协议的参与者是一个组控制器/密钥服务器（GCKS）和一个组成员（GM）。集团成员与GCKS联系（“注册”）加入集团。在注册过程中，实现相互身份验证和授权，然后GCKS通过经过身份验证和加密的会话将当前组策略和密钥材料分发给组成员。GCK还可以启动与集团成员的联系（“重新登记”），以提供集团政策的更新。
ISAKMP defines two "phases" of negotiation (Section 2.3 of [RFC2408]). A Phase 1 security association provides mutual authentication and authorization, and a security association that is used by the protocol participants to execute a Phase 2 exchange. This document incorporates (i.e., uses but does not redefine) the Phase 1 security association definition from the Internet DOI [RFC2407], [RFC2409]. Although RFCs 2407, 2408, and 2409 were obsoleted by [RFC4306] (and subsequently [RFC5996]), they are used by this document because the protocol definitions remain relevant for ISAKMP protocols other than IKEv2.
ISAKMP定义了谈判的两个“阶段”（RFC2408第2.3节）。阶段1安全关联提供相互身份验证和授权，以及协议参与者用于执行阶段2交换的安全关联。本文件包含（即使用但不重新定义）互联网DOI[RFC2407]，[RFC2409]中的第1阶段安全关联定义。尽管[RFC4306]（以及随后的[RFC5996]）已淘汰了RFC 2407、2408和2409，但本文件仍使用它们，因为协议定义与IKEv2以外的ISAKMP协议相关。
The GDOI includes two new Phase 2 ISAKMP exchanges (protocols), as well as necessary new payload definitions to the ISAKMP standard (Section 2.1 of [RFC2408]). These two new protocols are:
GDOI包括两个新的第2阶段ISAKMP交换（协议），以及ISAKMP标准（RFC2408第2.1节）中必要的新有效负载定义。这两个新协议是：
1. The GROUPKEY-PULL registration protocol exchange. This exchange uses "pull" behavior since the member initiates the retrieval of these SAs from a GCKS. It is protected by an ISAKMP Phase 1 protocol, as described above. At the culmination of a GROUPKEY-PULL exchange, an authorized group member has received and installed a set of SAs that represent group policy, and it is ready to participate in secure group communications.
1. GROUPKEY-PULL注册协议交换。此交换使用“拉”行为，因为成员从GCKS开始检索这些SA。如上所述，它受ISAKMP第1阶段协议的保护。在GROUPKEY-PULL交换达到高潮时，授权的组成员已接收并安装了一组表示组策略的SA，并且已准备好参与安全的组通信。
2. The GROUPKEY-PUSH rekey protocol exchange. The rekey protocol is a datagram initiated ("pushed") by the GCKS, usually delivered to group members using a IP multicast address. The rekey protocol is an ISAKMP protocol, where cryptographic policy and keying material ("Rekey SA") are included in the group policy distributed by the GCKS in the GROUPKEY-PULL exchange. At the culmination of a GROUPKEY-PUSH exchange, the key server has sent group policy to all authorized group members, allowing receiving group members to participate in secure group communications. If a group management method is included in group policy (as described in Section 7.4), at the conclusion of the GROUPKEY-PUSH exchange, some members of the group may have been de-authorized and no longer able to participate in the secure group communications.
2. GROUPKEY-PUSH重新密钥协议交换。密钥更新协议是由GCKS发起（“推送”）的数据报，通常使用IP多播地址发送给组成员。rekey协议是一种ISAKMP协议，其中加密策略和密钥材料（“rekey SA”）包含在由GCK在GROUPKEY-PULL交换中分发的组策略中。在GROUPKEY-PUSH交换达到高潮时，密钥服务器已向所有授权的组成员发送组策略，允许接收组成员参与安全的组通信。如果组策略中包含组管理方法（如第7.4节所述），则在GROUPKEY-PUSH交换结束时，组中的一些成员可能已被取消授权，不再能够参与安全组通信。
+--------------------------------------------------------------+
| |
| +--------------------+ |
| +------>| GDOI GCKS |<------+ |
| | +--------------------+ | |
| | | | |
| GROUPKEY-PULL | GROUPKEY-PULL |
| PROTOCOL | PROTOCOL |
| | | | |
| v GROUPKEY-PUSH v |
| +-----------------+ PROTOCOL +-----------------+ |
| | | | | | |
| | GDOI GM(s) |<-------+-------->| GDOI GM(S) | |
| | | | | |
| +-----------------+ +-----------------+ |
| | ^ |
| v | |
| +-Data Security Protocol (e.g., ESP)-+ |
| |
+--------------------------------------------------------------+
+--------------------------------------------------------------+
| |
| +--------------------+ |
| +------>| GDOI GCKS |<------+ |
| | +--------------------+ | |
| | | | |
| GROUPKEY-PULL | GROUPKEY-PULL |
| PROTOCOL | PROTOCOL |
| | | | |
| v GROUPKEY-PUSH v |
| +-----------------+ PROTOCOL +-----------------+ |
| | | | | | |
| | GDOI GM(s) |<-------+-------->| GDOI GM(S) | |
| | | | | |
| +-----------------+ +-----------------+ |
| | ^ |
| v | |
| +-Data Security Protocol (e.g., ESP)-+ |
| |
+--------------------------------------------------------------+
Figure 1. Group Key Management Model
图1。组密钥管理模型
Although the GROUPKEY-PUSH protocol specified by this document can be used to refresh the Rekey SA protecting the GROUPKEY-PUSH protocol, the most common use of GROUPKEY-PUSH is to establish keying material and policy for a data security protocol.
尽管本文档中指定的GROUPKEY-PUSH协议可用于刷新保护GROUPKEY-PUSH协议的重新密钥SA，但GROUPKEY-PUSH最常见的用途是为数据安全协议建立密钥材料和策略。
GDOI defines several payload types used to distribute policy and keying material within the GROUPKEY-PULL and GROUPKEY-PUSH protocols: Security Association (SA), SA KEK, SA TEK, Group Associated Policy (GAP), Sequence Number (SEQ), and Key Download (KD). Format and usage of these payloads are defined in later sections of this memo.
GDOI定义了用于在GROUPKEY-PULL和GROUPKEY-PUSH协议中分发策略和密钥材料的几种有效负载类型：安全关联（SA）、SA KEK、SA TEK、组关联策略（GAP）、序列号（SEQ）和密钥下载（KD）。这些有效载荷的格式和用法在本备忘录后面的章节中定义。
In summary, GDOI is a group security association management protocol: all GDOI messages are used to create, maintain, or delete security associations for a group. As described above, these security associations protect one or more data security protocol SAs, a Rekey SA, and/or other data shared by group members for multicast and groups security applications.
总之，GDOI是一个组安全关联管理协议：所有GDOI消息都用于创建、维护或删除组的安全关联。如上所述，这些安全关联为多播和组安全应用程序保护一个或多个数据安全协议SA、密钥更新SA和/或组成员共享的其他数据。
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 following key terms are used throughout this document.
本文件中使用了以下关键术语。
Data-Security SA The security policy distributed by a GDOI GCKS describing traffic that is expected to be protected by group members. This document described the distribution of IPsec AH and ESP Data-Security SAs.
数据安全SA由GDOI GCKS分发的安全策略，描述预期由组成员保护的通信量。本文档描述了IPsec AH和ESP数据安全SAs的分发。
Group Controller/Key Server A device that defines group policy and distributes keys for that policy [RFC3740].
组控制器/密钥服务器定义组策略并为该策略分发密钥的设备[RFC3740]。
Group Member. An authorized member of a secure group, sending and/or receiving IP packets related to the group.
小组成员。安全组的授权成员，发送和/或接收与该组相关的IP数据包。
GROUPKEY-PULL. A protocol used by a GDOI group member to request group policy and keying material.
组键拉动。GDOI组成员用于请求组策略和密钥材料的协议。
GROUPKEY-PUSH. A protocol used by a GDOI GCKS to distribute updates of group policy and keying material to authorized group members.
组键推送。GDOI GCKS使用的一种协议，用于将组策略和密钥材料的更新分发给授权的组成员。
Key Encrypting Key. The symmetric cipher key used to protect the GROUPKEY-PUSH message.
密钥加密密钥。用于保护GROUPKEY-PUSH消息的对称密码密钥。
Logical Key Hierarchy. A group management method defined in Section 5.4 of [RFC2627].
逻辑密钥层次结构。[RFC2627]第5.4节中定义的集团管理方法。
Rekey SA. The security policy protecting a GROUPKEY-PUSH protocol.
雷克萨。保护GROUPKEY-PUSH协议的安全策略。
SA Attribute Payload A payload that follows the Security Association payload and that describes group security attributes associated with the security association. SA Attribute payloads include the SAK, SAT, and GAP payloads.
SA属性有效负载遵循安全关联有效负载并描述与安全关联关联的组安全属性的有效负载。SA属性有效载荷包括SAK、SAT和GAP有效载荷。
Security Parameter Index An arbitrary value that is used by a receiver to identify a security association such as an IPsec ESP Security Association or a Rekey SA.
安全参数索引接收方用于标识安全关联（如IPsec ESP安全关联或密钥重置SA）的任意值。
Traffic Encryption Key. The symmetric cipher key used to protect a data security protocol (e.g., IPsec ESP).
流量加密密钥。用于保护数据安全协议（如IPsec ESP）的对称密码密钥。
The following acronyms and abbreviations are used throughout this document.
本文件中使用了以下首字母缩略词和缩写词。
AH IP Authentication Header
AH IP认证头
ATD Activation Time Delay
ATD激活延时
DOI Domain of Interpretation
DOI解释领域
DTD Deactivation Time Delay
DTD失活延时
ESP IP Encapsulating Security Payload
封装安全有效负载的ESP-IP
GCKS Group Controller/Key Server
GCKS组控制器/密钥服务器
GDOI Group Domain of Interpretation
GDOI组解释域
GAP Group Associated Policy Payload
间隙组关联策略有效负载
GM Group Member
总经理小组成员
GSPD Group Security Policy Database
GSPD组安全策略数据库
IV Initialization Vector
IV初始化向量
KD Key Download Payload
KD密钥下载有效负载
KEK Key Encryption Key
KEK密钥加密密钥
LKH Logical Key Hierarchy
逻辑密钥层次结构
SA Security Association
南非安全协会
SAK SA KEK Payload
萨克萨克有效载荷
SEQ Sequence Number Payload
序列号有效载荷
SAT SA TEK Payload
SAT SA TEK有效载荷
SID Sender-ID
SID发送者ID
SPI Security Parameter Index
安全参数索引
SSIV Sender-Specific IV
SSIV发送方特定IV
TEK Traffic Encryption Key
TEK流量加密密钥
TLV Type/Length/Value
TLV类型/长度/值
TV Type/Value
电视类型/价值
The GDOI GROUPKEY-PULL exchange is a Phase 2 protocol that MUST be protected by a Phase 1 protocol. The Phase 1 protocol can be any protocol that provides for the following protections:
GDOI GROUPKEY-PULL交换是阶段2协议，必须由阶段1协议保护。阶段1协议可以是提供以下保护的任何协议：
o Peer Authentication
o 对等身份验证
o Confidentiality
o 保密性
o Message Integrity
o 消息完整性
The following sections describe one such Phase 1 protocol. Other protocols which may be potential Phase 1 protocols are described in Appendix A. However, the use of the protocols listed there are not considered part of this document.
以下各节描述了一个这样的第1阶段协议。附录A中描述了可能是第1阶段协议的其他协议。但是，此处列出的协议的使用不属于本文件的一部分。
This document defines how the ISAKMP Phase 1 exchanges as defined in [RFC2409] can be used a Phase 1 protocol for GDOI. The following sections define characteristics of the ISAKMP Phase 1 protocols that are unique for these exchanges when used for GDOI.
本文件定义了[RFC2409]中定义的ISAKMP第1阶段交换如何用于GDOI的第1阶段协议。以下各节定义了ISAKMP第1阶段协议的特征，这些协议在用于GDOI时对这些交换机是唯一的。
Section 7.1 describes how the ISAKMP Phase 1 protocols meet the requirements of a GDOI Phase 1 protocol.
第7.1节描述了ISAKMP第1阶段协议如何满足GDOI第1阶段协议的要求。
The Phase 1 SA payload has a DOI value. That value MUST be the GDOI DOI value as defined later in this document.
阶段1 SA有效负载具有DOI值。该值必须是本文档后面定义的GDOI DOI值。
IANA has assigned port 848 for the use of GDOI; this allows for an implementation to use separate ISAKMP implementations to service GDOI and the Internet Key Exchange Protocol (IKE) [RFC5996]. A GCKS SHOULD listen on this port for GROUPKEY-PULL exchanges, and the GCKS MAY use this port to distribute GROUPKEY-PUSH messages. An ISAKMP Phase 1 exchange implementation supporting NAT traversal [RFC3947] MAY move to port 4500 to process the GROUPKEY-PULL exchange.
IANA已将848端口分配给GDOI使用；这允许实现使用单独的ISAKMP实现来服务GDOI和Internet密钥交换协议（IKE）[RFC5996]。GCK应在此端口上侦听GROUPKEY-PULL交换，GCK可使用此端口分发GROUPKEY-PUSH消息。支持NAT遍历[RFC3947]的ISAKMP第1阶段交换实现可以移动到端口4500以处理GROUPKEY-PULL交换。
The goal of the GROUPKEY-PULL exchange is to establish a Rekey and/or Data-Security SAs at the member for a particular group. A Phase 1 SA protects the GROUPKEY-PULL; there MAY be multiple GROUPKEY-PULL exchanges for a given Phase 1 SA. The GROUPKEY-PULL exchange downloads the data security keys (TEKs) and/or group key encrypting key (KEK) or KEK array under the protection of the Phase 1 SA.
GROUPKEY-PULL交换的目标是在特定组的成员处建立重新密钥和/或数据安全SA。第1阶段SA保护GROUPKEY-PULL；对于给定的第1阶段SA，可能有多个GROUPKEY-PULL交换。GROUPKEY-PULL exchange在第1阶段SA的保护下下载数据安全密钥（TEK）和/或组密钥加密密钥（KEK）或KEK阵列。
It is important that a group member explicitly trust entities that it expects to act as a GCKS for a particular group. When no authorization is performed, it is possible for a rogue GDOI participant to perpetrate a man-in-the-middle attack between a group member and a GCKS [MP04]. A group member MUST specifically list each authorized GCKS in its Group Peer Authorization Database (GPAD) [RFC5374]. A group member MUST ensure that the Phase 1 identity of the GCKS is an authorized GCKS.
重要的是，组成员明确信任它希望充当特定组的GCK的实体。当未执行授权时，流氓GDOI参与者有可能在组成员和GCKS之间实施中间人攻击[MP04]。集团成员必须在其集团对等授权数据库（GPAD）[RFC5374]中明确列出每个授权GCK。集团成员必须确保GCK的第1阶段身份是经授权的GCK。
It is important that a GCKS explicitly authorize group members before providing them with group policy and keying material. A GCKS implementation SHOULD have a method of authorizing group members (e.g., by maintaining an authorization list). When the GCKS performs authorization, it MUST use the Phase 1 identity to authorize the GROUPKEY-PULL request for group policy and keying material.
重要的是，GCKS在向组成员提供组策略和密钥材料之前，应明确授权组成员。GCKS实施应具有授权组成员的方法（例如，通过维护授权列表）。当GCKS执行授权时，它必须使用阶段1标识对组策略和密钥材料的GROUPKEY-PULL请求进行授权。
The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a, which is the "key" in the keyed hash used in the ISAKMP HASH payloads [RFC2408] included in GROUPKEY-PULL messages. When using the Phase 1 defined in this document, SKEYID_a is derived according to [RFC2409]. Each GROUPKEY-PULL message hashes a uniquely defined set of values (described below) and includes the result in the HASH payload. Nonces permute the HASH and provide some protection against replay attacks. Replay protection is important to protect the GCKS from attacks that a key management server will attract.
GROUPKEY-PULL是第2阶段交换。阶段1计算SKEYID_a，它是GROUPKEY-PULL消息中包含的ISAKMP哈希有效载荷[RFC2408]中使用的密钥散列中的“密钥”。使用本文件中定义的阶段1时，根据[RFC2409]推导出SKEYID_a。每个GROUPKEY-PULL消息散列一组唯一定义的值（如下所述），并将结果包含在散列负载中。nonce排列散列并提供一些防止重放攻击的保护。重播保护对于保护GCK免受密钥管理服务器将吸引的攻击非常重要。
The GROUPKEY-PULL uses nonces to guarantee "liveness" as well as against replay of a recent GROUPKEY-PULL message. The replay attack is only possible in the context of the current Phase 1. If a GROUPKEY-PULL message is replayed based on a previous Phase 1, the HASH calculation will fail due to a wrong SKEYID_a. The message will fail processing before the nonce is ever evaluated.
GROUPKEY-PULL使用nonce来保证“活跃性”，并防止重播最近的GROUPKEY-PULL消息。重播攻击仅在当前阶段1的上下文中可能发生。如果基于前一阶段1重播GROUPKEY-PULL消息，则哈希计算将由于错误的SKEYID_a而失败。在评估nonce之前，消息将无法处理。
In order for either peer to get the benefit of the replay protection, it must postpone as much processing as possible until it receives the message in the protocol that proves the peer is live. For example, the GCKS MUST NOT adjust its internal state (e.g., keeping a record of the GM) until it receives a message with Nr included properly in the HASH payload. This requirement ensures that replays of GDOI messages will not cause the GCKS to change the state of the group until it has confirmation that the initiating group member is live.
为了让任何一个对等方获得重播保护的好处，它必须尽可能推迟处理，直到它收到协议中证明对等方是活动的消息为止。例如，GCKS在收到散列负载中正确包含Nr的消息之前，不得调整其内部状态（例如，保留GM的记录）。此要求确保在确认发起组成员处于活动状态之前，GDOI消息的重播不会导致GCK更改组的状态。
Group Member GCKS
------------ ----
(1) HDR*, HASH(1), Ni, ID -->
(2) <-- HDR*, HASH(2), Nr, SA
(3) HDR*, HASH(3) [,GAP] -->
(4) <-- HDR*, HASH(4), [SEQ,] KD
Group Member GCKS
------------ ----
(1) HDR*, HASH(1), Ni, ID -->
(2) <-- HDR*, HASH(2), Nr, SA
(3) HDR*, HASH(3) [,GAP] -->
(4) <-- HDR*, HASH(4), [SEQ,] KD
* Protected by the Phase 1 SA; encryption occurs after HDR
* 受第一阶段SA保护；加密发生在HDR之后
Figure 2. GROUPKEY-PULL Exchange
图2。分组键拉交换
Figure 2 demonstrates the four messages that are part of a GROUPKEY-PULL exchange. HDR is an ISAKMP header payload that uses the Phase 1 cookies and a message identifier (M-ID) as in ISAKMP. Following each HDR is a set of payloads conveying requests (messages 1 and 3 originated by the group member), or group policy and/or keying material (messages 2 and 4 originated by the GCKS).
图2演示了作为GROUPKEY-PULL交换一部分的四条消息。HDR是一个ISAKMP头有效负载，它使用阶段1 cookie和消息标识符（M-ID），如在ISAKMP中一样。在每个HDR之后是一组有效载荷，用于传递请求（由组成员发起的消息1和3）或组策略和/或密钥材料（由GCKS发起的消息2和4）。
Hashes are computed in the manner described within [RFC2409]. The HASH computation for each message is unique; it is shown in Figure 2 and below as HASH(n) where (n) represents the GROUPKEY-PULL message number. Each HASH calculation is a pseudo-random function ("prf") over the message ID (M-ID) from the ISAKMP header concatenated with the entire message that follows the hash including all payload headers, but excluding any padding added for encryption. The GM expects to find its nonce, Ni, in the HASH of a returned message, and the GCKS expects to see its nonce, Nr, in the HASH of a returned message. HASH(2), HASH(3), and HASH(4) also include nonce values previously passed in the protocol (i.e., Ni or Nr minus the payload header). The nonce passed in Ni is represented as Ni_b, and the nonce passed in Nr is represented as Nr_b. The HASH payloads prove that the peer has the Phase 1 secret (SKEYID_a) and the nonce for the exchange identified by message ID, M-ID.
散列按照[RFC2409]中描述的方式计算。每个消息的哈希计算是唯一的；它在图2和下图中显示为散列（n），其中（n）表示GROUPKEY-PULL消息编号。每个哈希计算都是来自ISAKMP头的消息ID（M-ID）上的伪随机函数（“prf”），该消息ID与哈希后的整个消息连接，包括所有有效负载头，但不包括为加密添加的任何填充。GM希望在返回消息的哈希中找到其nonce Ni，GCKS希望在返回消息的哈希中找到其nonce Nr。散列（2）、散列（3）和散列（4）还包括先前在协议中传递的nonce值（即Ni或Nr减去有效负载报头）。传入Ni的nonce表示为Ni_b，传入Nr的nonce表示为Nr_b。散列有效载荷证明对等方具有第1阶段秘密（SKEYID_a）和由消息ID M-ID标识的交换的nonce。
HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | GAP ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | SEQ ] | KD)
HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | GAP ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | SEQ ] | KD)
In addition to the Nonce and HASH payloads, the GM identifies the group it wishes to join through the ISAKMP ID payload.
除了Nonce和HASH有效载荷外，GM还通过ISAKMP ID有效载荷识别希望加入的组。
The GCKS informs the member of the cryptographic policies of the group in the SA payload, which describes the DOI, KEK, and/or TEK keying material, authentication transforms, and other group policy. Each SPI is also determined by the GCKS and downloaded in the SA payload chain (see Section 5.2). The SA KEK attribute contains the ISAKMP cookie pair for the Rekey SA, which is not negotiated but downloaded. Each SA TEK attribute contains a SPI as defined in Section 5.5 of this document.
GCKS通知SA有效负载中的组成员密码策略，该有效负载描述了DOI、KEK和/或TEK密钥材料、身份验证转换和其他组策略。每个SPI也由GCKS确定，并在SA有效载荷链中下载（见第5.2节）。SA KEK属性包含Rekey SA的ISAKMP cookie对，该对不是协商的，而是下载的。每个SA TEK属性包含本文件第5.5节中定义的SPI。
After receiving and parsing the SA payload, the GM responds with an acknowledgement message proving its liveness. It optionally includes a GAP payload requesting resources.
在接收和解析SA有效负载后，GM会用确认消息进行响应，以证明其活动性。它可选地包括请求资源的间隙有效负载。
The GCKS informs the GM of the value of the sequence number in the SEQ payload. This sequence number provides anti-replay state associated with a KEK, and its knowledge ensures that the GM will not accept GROUPKEY-PUSH messages sent prior to the GM joining the group. The SEQ payload has no other use and is omitted from the GROUPKEY-PULL exchange when a KEK attribute is not included in the SA payload. When a SEQ payload is included in the GROUPKEY-PULL exchange, it includes the most recently used sequence number for the group. At the conclusion of a GROUPKEY-PULL exchange, the initiating group member MUST NOT accept any rekey message with both the KEK attribute SPI value and a sequence number less than or equal to the one received during the GROUPKEY-PULL exchange. When the first group member initiates a GROUPKEY-PULL exchange, the GCKS provides a Sequence Number of zero, since no GROUPKEY-PUSH messages have yet been sent. Note the sequence number increments only with GROUPKEY-PUSH messages. The GROUPKEY-PULL exchange distributes the current sequence number to the group member. The sequence number resets to a value of one with the usage of a new KEK attribute. Thus, the first packet sent for a given Rekey SA will have a Sequence Number of 1. The sequence number increments with each successive rekey.
GCKS通知GM SEQ有效载荷中的序列号值。此序列号提供与KEK相关联的防重播状态，其知识确保GM不会接受在GM加入组之前发送的GROUPKEY-PUSH消息。SEQ有效负载没有其他用途，当SA有效负载中不包括KEK属性时，它将从GROUPKEY-PULL交换中省略。当GROUPKEY-PULL交换中包括SEQ有效负载时，它包括该组最近使用的序列号。在GROUPKEY-PULL交换结束时，发起组成员不得接受KEK属性SPI值和序列号小于或等于GROUPKEY-PULL交换期间接收到的序列号的任何重新密钥消息。当第一个组成员启动GROUPKEY-PULL交换时，GCKS提供一个零的序列号，因为还没有发送GROUPKEY-PUSH消息。请注意，序列号仅在GROUPKEY-PUSH消息中递增。GROUPKEY-PULL交换将当前序列号分配给组成员。使用新的KEK属性，序列号将重置为值1。因此，为给定密钥SA发送的第一个分组将具有序列号1。序列号随着每次连续的重键而递增。
The GCKS always returns a KD payload containing keying material to the GM. If a Rekey SA is defined in the SA payload, then KD will contain the KEK; if one or more Data-Security SAs are defined in the SA payload, KD will contain the TEKs.
GCKS始终将包含键控材料的KD有效载荷返回给GM。如果SA有效载荷中定义了重新键控SA，则KD将包含KEK；如果SA有效负载中定义了一个或多个数据安全SA，KD将包含TEK。
Cookies are used in the ISAKMP header to identify a particular GDOI session. The GDOI GROUPKEY-PULL exchange uses cookies according to ISAKMP [RFC2408].
在ISAKMP头中使用cookie来标识特定的GDOI会话。GDOI GROUPKEY-PULL交换根据ISAKMP[RFC2408]使用cookie。
Next Payload identifies an ISAKMP or GDOI payload (see Section 5).
下一个有效载荷标识ISAKMP或GDOI有效载荷（参见第5节）。
Major Version is 1 and Minor Version is 0 according to ISAKMP (Section 3.1 of [RFC2408]).
根据ISAKMP（RFC2408第3.1节），主要版本为1，次要版本为0。
The Exchange Type has value 32 for the GDOI GROUPKEY-PULL exchange.
对于GDOI GROUPKEY-PULL交换，交换类型的值为32。
Flags, Message ID, and Length are according to ISAKMP (Section 3.1 of [RFC2408]). The Commit flag is not useful because there is no synchronization between the GROUPKEY-PULL exchange and the data traffic protected by the policy distributed by the GROUPKEY-PULL exchange.
标志、消息ID和长度符合ISAKMP（RFC2408第3.1节）的要求。Commit标志没有用处，因为GROUPKEY-PULL交换和由GROUPKEY-PULL交换分发的策略保护的数据通信之间没有同步。
Before a GM contacts the GCKS, it needs to determine the group identifier and acceptable Phase 1 policy via an out-of-band method. Phase 1 is initiated using the GDOI DOI in the SA payload. Once Phase 1 is complete, the GM state machine moves to the GDOI protocol.
在GM联系GCKS之前，需要通过带外方法确定集团标识符和可接受的阶段1政策。阶段1使用SA有效负载中的GDOI DOI启动。一旦阶段1完成，GM状态机将转移到GDOI协议。
To construct the first GDOI message, the GM chooses Ni, creates a nonce payload, builds an identity payload including the group identifier, and generates HASH(1).
为了构造第一条GDOI消息，GM选择Ni，创建一个nonce负载，构建一个包含组标识符的标识负载，并生成散列（1）。
Upon receipt of the second GDOI message, the GM validates HASH(2), extracts the nonce Nr, and interprets the SA payload (including its SA Attribute payloads) . The SA payload contains policy describing the security protocol and cryptographic protocols used by the group. This policy describes the Rekey SA (if present), Data-Security SAs, and other group policy. If the policy in the SA payload is acceptable to the GM, it continues the protocol. Otherwise, the GM SHOULD tear down the Phase 1 session after notifying the GCKS with an ISAKMP Informational Exchange containing a Delete payload.
在接收到第二条GDOI消息后，GM验证散列（2），提取nonce Nr，并解释SA有效载荷（包括其SA属性有效载荷）。SA有效负载包含描述组使用的安全协议和加密协议的策略。此策略描述了重置SA（如果存在）、数据安全SA和其他组策略。如果SA有效负载中的策略为GM所接受，则继续协议。否则，GM应在使用包含删除有效负载的ISAKMP信息交换通知GCK后中断阶段1会话。
When constructing the third GDOI message, it first reviews each Data-Security SA given to it. If any describe the use of a counter mode cipher, the GM determines whether it requires more than one Sender-ID (SID) (see Section 3.5). If so, it requests the required number of Sender-IDs for its exclusive use within the counter mode nonce as described in Section 5.4 of this document. The GM then completes construction of the third GDOI message by creating HASH(3).
在构造第三条GDOI消息时，它首先检查提供给它的每个数据安全SA。如果有任何描述计数器模式密码的使用，GM将确定其是否需要一个以上的发送者ID（SID）（参见第3.5节）。如果是这样，它将请求所需数量的发送方ID，以便在本文件第5.4节所述的计数器模式nonce中独家使用。然后，GM通过创建散列（3）完成第三条GDOI消息的构造。
Upon receipt of the fourth GDOI message, the GM validates HASH(4).
在收到第四条GDOI消息后，GM验证散列（4）。
If the SEQ payload is present, the sequence number included in the SEQ payload asserts the lowest acceptable sequence number present in a future GROUPKEY-PUSH message. But if the KEK associated with this sequence number had been previously installed, due to the
如果存在SEQ有效负载，则SEQ有效负载中包含的序列号将断言未来GROUPKEY-PUSH消息中存在的最低可接受序列号。但如果与此序列号相关的KEK之前已安装，则由于
asynchronous processing of GROUPKEY-PULL and GROUPKEY-PUSH messages, this sequence number may be lower than the sequence number contained in the most recently received GROUPKEY-PUSH message. In this case, the sequence number value in the SEQ payload MUST be considered stale and ignored.
GROUPKEY-PULL和GROUPKEY-PUSH消息的异步处理，此序列号可能低于最近收到的GROUPKEY-PUSH消息中包含的序列号。在这种情况下，SEQ有效负载中的序列号值必须被视为过时并被忽略。
The GM interprets the KD key packets, where each key packet includes the keying material for SAs distributed in the SA payload. Keying material is matched by comparing the SPI in each key packet to SPI values previously sent in the SA payloads. Once TEKs and policy are matched, the GM provides them to the data security subsystem, and it is ready to send or receive packets matching the TEK policy. If this group has a KEK, the KEK policy and keys are marked as ready for use, and the GM knows to expect a sequence number not less than the one distributed in the SEQ payload. The GM is now ready to receive GROUPKEY-PUSH messages.
GM解释KD密钥包，其中每个密钥包包括SA有效负载中分配的SA密钥材料。通过将每个密钥包中的SPI与SA有效载荷中先前发送的SPI值进行比较，匹配密钥材料。一旦TEK和策略匹配，GM将它们提供给数据安全子系统，并且它准备发送或接收与TEK策略匹配的数据包。如果该组具有KEK，则KEK策略和密钥被标记为可供使用，并且GM知道预期序列号不小于SEQ有效载荷中分配的序列号。GM现在已准备好接收GROUPKEY-PUSH消息。
If the KD payload included an LKH array of keys, the GM takes the last key in the array as the group KEK. The array is then stored without further processing.
如果KD有效载荷包含一个密钥LKH数组，GM将该数组中的最后一个密钥作为组KEK。然后存储阵列，无需进一步处理。
The GCKS passively listens for incoming requests from group members. The Phase 1 authenticates the group member and sets up the secure session with them.
GCKS被动侦听来自组成员的传入请求。阶段1验证组成员并与他们建立安全会话。
Upon receipt of the first GDOI message, the GCKS validates HASH(1) and extracts the Ni and group identifier in the ID payload. It verifies that its database contains the group information for the group identifier and that the GM is authorized to participate in the group.
收到第一条GDOI消息后，GCKS验证哈希（1）并提取ID有效负载中的Ni和组标识符。它验证其数据库是否包含组标识符的组信息，以及GM是否有权参与该组。
The GCKS constructs the second GDOI message, including a nonce Nr, and the policy for the group in an SA payload, followed by SA Attribute payloads (i.e, SA KEK, GAP, and/or SA TEK payloads) according to the GCKS policy. (See Section 5.2.1 for details on how the GCKS chooses which payloads to send.)
GCKS根据GCKS策略为SA有效负载中的组构造第二条GDOI消息，包括nonce Nr和策略，然后是SA属性有效负载（即SA KEK、GAP和/或SA TEK有效负载）。（有关GCKS如何选择发送哪些有效载荷的详细信息，请参见第5.2.1节。）
Upon receipt of the third GDOI message, the GCKS validates HASH(3). If the message includes a GAP payload, it caches the requests included in that payload for the use of constructing the fourth GDOI message.
收到第三条GDOI消息后，GCKS验证哈希（3）。如果消息包括间隙有效负载，则它缓存该有效负载中包括的请求，以用于构造第四条GDOI消息。
The GCKS constructs the fourth GDOI message, including the SEQ payload (if the GCKS sends rekey messages), and the KD payload containing keys corresponding to policy previously sent in the SA TEK and SA KEK payloads. If a group management algorithm is defined as
GCKS构造第四条GDOI消息，包括SEQ有效载荷（如果GCKS发送rekey消息）和KD有效载荷，KD有效载荷包含与先前在SA TEK和SA KEK有效载荷中发送的策略相对应的密钥。如果组管理算法定义为
part of group policy, the GCKS will first insert the group member into the group management structure (e.g., a leaf in the LKH tree), and then create an LKH array of keys and include it in the KD payload. The first key in the array is associated with the group member leaf node, followed by each LKH node above it in the tree, culminating with the root node (which is also the KEK). If one or more Data-Security SAs distributed in the SA payload included a counter mode of operation, the GCKS includes at least one SID value in the KD payload, and possibly more depending on a request received in the third GDOI message.
作为组策略的一部分，GCKS将首先将组成员插入组管理结构（例如，LKH树中的叶子），然后创建密钥LKH数组并将其包含在KD有效负载中。数组中的第一个键与组成员叶节点相关联，然后是树中它上面的每个LKH节点，最后是根节点（也是KEK）。如果在SA有效载荷中分布的一个或多个数据安全SA包括计数器操作模式，则GCKS在KD有效载荷中包括至少一个SID值，并且可能更多，这取决于在第三GDOI消息中接收的请求。
Several new counter-based modes of operation have been specified for ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], AES-GMAC [RFC4543]) and AH (e.g., AES-GMAC [RFC4543]). These counter-based modes require that no two senders in the group ever send a packet with the same Initialization Vector (IV) using the same cipher key and mode. This requirement is met in GDOI when the following requirements are met:
已为ESP（例如AES-CTR[RFC3686]、AES-GCM[RFC4106]、AES-CCM[RFC4309]、AES-GMAC[RFC4543]）和AH（例如AES-GMAC[RFC4543]）指定了几种新的基于计数器的操作模式。这些基于计数器的模式要求组中没有两个发送方使用相同的密钥和模式发送具有相同初始化向量（IV）的数据包。当满足以下要求时，GDOI满足此要求：
o The GCKS distributes a unique key for each Data-Security SA.
o GCKS为每个数据安全SA分配一个唯一密钥。
o The GCKS uses the method described in [RFC6054], which assigns each sender a portion of the IV space by provisioning each sender with one or more unique SID values.
o GCKS使用[RFC6054]中所述的方法，该方法通过为每个发送方提供一个或多个唯一SID值，为每个发送方分配一部分IV空间。
When at least one Data-Security SA included in the group policy includes a counter-mode, the GCKS automatically allocates and distributes one SID to each group member acting in the role of sender on the Data-Security SA. The SID value is used exclusively by the group member to which it was allocated. The group member uses the same SID for each Data-Security SA specifying the use of a counter-based mode of operation. A GCKS MUST distribute unique keys for each Data-Security SA including a counter-based mode of operation in order to maintain a unique key and nonce usage.
当组策略中包含的至少一个数据安全SA包括计数器模式时，GCKS会自动将一个SID分配给充当数据安全SA上发送者角色的每个组成员。SID值仅由分配给它的组成员使用。组成员对每个数据安全SA使用相同的SID，指定使用基于计数器的操作模式。GCKS必须为每个数据安全SA分配唯一的密钥，包括基于计数器的操作模式，以保持唯一的密钥和nonce使用。
When a group member receives a Data-Security SA in a SA TEK payload for which it is a sender, it can choose to request one or more SID values. Requesting a value of 1 is not necessary since the GCKS will automatically allocate exactly one to the sending group member. A group member MUST request as many SIDs matching the number of encryption modules in which it will be installing the TEKs in the outbound direction. Alternatively, a group member MAY request more than one SID and use them serially. This could be useful when it is anticipated that the group member will exhaust their range of Data-Security SA nonces using a single SID too quickly (e.g., before the time-based policy in the TEK expires).
当一个组成员在其作为发送方的SA TEK有效负载中接收到数据安全SA时，它可以选择请求一个或多个SID值。请求值1不是必需的，因为GCKS将自动为发送组成员分配一个值。组成员必须请求尽可能多的SID，以匹配其将在出站方向安装TEK的加密模块的数量。或者，组成员可以请求多个SID并连续使用它们。当预期组成员将使用单个SID过快（例如，在TEK中基于时间的策略到期之前）耗尽其数据安全暂时性范围时，这可能非常有用。
When group policy includes a counter-based mode of operation, a GCKS SHOULD use the following method to allocate SID values, which ensures that each SID will be allocated to just one group member.
当组策略包括基于计数器的操作模式时，GCKS应使用以下方法分配SID值，以确保每个SID仅分配给一个组成员。
1. A GCKS maintains a SID-counter, which records which SIDs have been allocated. SIDs are allocated sequentially, with the first SID allocated to be zero.
1. GCKS维护一个SID计数器，记录已分配的SID。SID按顺序分配，第一个SID分配为零。
2. Each time a SID is allocated, the current value of the counter is saved and allocated to the group member. The SID-counter is then incremented in preparation for the next allocation.
2. 每次分配SID时，都会保存计数器的当前值并将其分配给组成员。然后增加SID计数器，为下一次分配做准备。
3. When the GCKS distributes a Data-Security SA specifying a counter-based mode of operation, and a group member is a sender, a group member may request a count of SIDs in a GAP payload. When the GCKS receives this request, it increments the SID-counter once for each requested SID, and distributes each SID value to the group member.
3. 当GCKS分发指定基于计数器的操作模式的数据安全SA，并且组成员是发送方时，组成员可以请求GAP有效负载中的SID计数。当GCKS收到此请求时，它会为每个请求的SID递增SID计数器一次，并将每个SID值分配给组成员。
4. A GCKS allocates new SID values for each GROUPKEY-PULL exchange originated by a sender, regardless of whether a group member had previously contacted the GCKS. In this way, the GCKS does not have a requirement of maintaining a record of which SID values it had previously allocated to each group member. More importantly, since the GCKS cannot reliably detect whether the group member had sent data on the current group Data-Security SAs, it does not know which Data-Security counter-mode nonce values a group member has used. By distributing new SID values, the key server ensures that each time a conforming group member installs a Data-Security SA it will use a unique set of counter-based mode nonces.
4. GCKS为发件人发起的每个GROUPKEY-PULL交换分配新的SID值，而不管组成员以前是否联系过GCKS。通过这种方式，GCKS不需要维护其先前分配给每个组成员的SID值的记录。更重要的是，由于GCKS无法可靠地检测组成员是否已在当前组数据安全SAs上发送数据，因此它不知道组成员使用了哪些数据安全计数器模式nonce值。通过分发新的SID值，密钥服务器确保每次一致性组成员安装数据安全SA时，它将使用一组唯一的基于计数器的模式nonce。
5. When the SID-counter maintained by the GCKS reaches its final SID value, no more SID values can be distributed. Before distributing any new SID values, the GCKS MUST delete the Data-Security SAs for the group, followed by creation of new Data-Security SAs, and resetting the SID-counter to its initial value.
5. 当GCKS维护的SID计数器达到其最终SID值时，无法再分配SID值。在分发任何新的SID值之前，GCK必须删除组的数据安全SA，然后创建新的数据安全SA，并将SID计数器重置为其初始值。
6. The GCKS SHOULD send a GROUPKEY-PUSH message deleting all Data-Security SAs and the Rekey SA for the group. This will result in the group members initiating a new GROUPKEY-PULL exchange, in which they will receive both new SID values and new Data-Security SAs. The new SID values can safely be used because they are only used with the new Data-Security SAs. Note that deletion of the Rekey SA is necessary to ensure that group members receiving a GROUPKEY-PUSH exchange before the re-register do not inadvertently use their old SIDs with the new Data-Security SAs.
6. GCKS应发送GROUPKEY-PUSH消息，删除该组的所有数据安全SA和重新密钥SA。这将导致组成员启动新的GROUPKEY-PULL交换，在该交换中，他们将接收新的SID值和新的数据安全SA。可以安全地使用新的SID值，因为它们仅与新的数据安全SAs一起使用。请注意，删除重新注册SA是必要的，以确保在重新注册之前接收GROUPKEY-PUSH交换的组成员不会无意中将其旧SID用于新的数据安全SA。
Using the method above, at no time can two group members use the same IV values with the same Data-Security SA key.
使用上述方法，两个组成员在任何时候都不能使用相同的数据安全SA密钥使用相同的IV值。
GDOI sends control information securely using group communications. Typically, this will be using IP multicast distribution of a GROUPKEY-PUSH message, but it can also be "pushed" using unicast delivery if IP multicast is not possible. The GROUPKEY-PUSH message replaces a Rekey SA KEK or KEK array, and/or it creates a new Data-Security SA.
GDOI使用组通信安全地发送控制信息。通常，这将使用GROUPKEY-PUSH消息的IP多播分发，但如果无法使用IP多播，也可以使用单播交付“推送”。GROUPKEY-PUSH消息将替换Rekey SA KEK或KEK数组，和/或创建新的数据安全SA。
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 3. GROUPKEY-PUSH Message
图3。组键推送消息
HDR is defined below. The SEQ payload is defined in Section 5 ("Payloads"). One or more D (Delete) payloads (further described in Section 5.9) optionally specify the deletion of existing group policy. The SA defines the group policy for replacement Rekey SA and/or Data-Security SAs as described in Section 5, with the KD providing keying material for those SAs.
HDR的定义如下。SEQ有效载荷在第5节（“有效载荷”）中定义。一个或多个D（删除）有效载荷（在第5.9节中进一步描述）可选地指定删除现有组策略。SA定义了第5节所述的更换密钥SA和/或数据安全SA的集团政策，KD为这些SA提供密钥材料。
The SIG payload includes a signature of a hash of the entire GROUPKEY-PUSH message (excepting the SIG payload octets) before it has been encrypted. The HASH is taken over the string 'rekey', the GROUPKEY-PUSH HDR, followed by all payloads preceding the SIG payload. The prefixed string ensures that the signature of the Rekey datagram cannot be used for any other purpose in the GDOI protocol. The SIG payload is created using the signature of the above hash, with the receiver verifying the signature using a public key retrieved in a previous GDOI exchange. The current KEK (also previously distributed in a GROUPKEY-PULL exchange or GROUPKEY-PUSH message) encrypts all the payloads following the GROUPKEY-PUSH HDR. Note: The rationale for this order of operations is given in Section 7.3.5.
SIG有效负载包括加密前整个GROUPKEY-PUSH消息（SIG有效负载八位字节除外）的哈希签名。哈希值接管字符串'rekey'，GROUPKEY-PUSH HDR，然后是SIG有效负载之前的所有有效负载。带前缀的字符串确保在GDOI协议中，密钥更新数据报的签名不能用于任何其他目的。SIG有效载荷是使用上述散列的签名创建的，接收方使用在先前GDOI交换中检索的公钥验证签名。当前KEK（以前也在GROUPKEY-PULL交换或GROUPKEY-PUSH消息中分发）加密GROUPKEY-PUSH HDR之后的所有有效负载。注：第7.3.5节给出了该操作顺序的基本原理。
If the SA defines the use of a single KEK or an LKH KEK array, KD MUST contain a corresponding KEK or KEK array for a new Rekey SA, which has a new cookie pair. When the KD payload carries a new SA KEK attribute (Section 5.3), a Rekey SA is replaced with a new SA having the same group identifier (ID specified in message 1 of Section 3.2) and incrementing the same sequence counter, which is initialized in message 4 of Section 3.2. Note the first packet for
如果SA定义了单个KEK或LKH KEK数组的使用，KD必须包含新密钥SA的相应KEK或KEK数组，新密钥SA具有新的cookie对。当KD有效载荷携带新的SA KEK属性（第5.3节）时，将用具有相同组标识符（第3.2节消息1中指定的ID）并递增相同序列计数器（在第3.2节消息4中初始化）的新SA替换密钥SA。注意第一个数据包
the given Rekey SA encrypted with the new KEK attribute will have a Sequence number of 1. If the SA defines an SA TEK payload, this informs the member that a new Data-Security SA has been created, with keying material carried in KD (Section 5.6).
使用新KEK属性加密的给定密钥SA的序列号为1。如果SA定义了SA TEK有效载荷，则通知会员机构已创建新的数据安全SA，密钥材料在KD中携带（第5.6节）。
If the SA defines a large LKH KEK array (e.g., during group initialization and batched rekeying), parts of the array MAY be sent in different unique GROUPKEY-PUSH datagrams. However, each of the GROUPKEY-PUSH datagrams MUST be a fully formed GROUPKEY-PUSH datagram. This results in each datagram containing a sequence number and the policy in the SA payload, which corresponds to the KEK array portion sent in the KD payload.
如果SA定义了一个大型LKH KEK数组（例如，在组初始化和批处理密钥更新期间），则可以在不同的唯一GROUPKEY-PUSH数据报中发送该数组的部分。但是，每个GROUPKEY-PUSH数据报必须是完全格式的GROUPKEY-PUSH数据报。这导致每个数据报包含SA有效负载中的序列号和策略，对应于KD有效负载中发送的KEK阵列部分。
A signing key should not be used in more than one context (e.g., used for host authentication and also for message authentication). Thus, the GCKS SHOULD NOT use the same key to sign the SIG payload in the GROUPKEY-PUSH message as was used for authentication in the GROUPKEY-PULL exchange.
签名密钥不应在多个上下文中使用（例如，用于主机身份验证和消息身份验证）。因此，GCK在GROUPKEY-PUSH消息中不应使用与在GROUPKEY-PULL交换中用于身份验证相同的密钥对SIG有效负载进行签名。
Unlike ISAKMP, the cookie pair is completely determined by the GCKS. The cookie pair in the GDOI ISAKMP header identifies the Rekey SA to differentiate the secure groups managed by a GCKS. Thus, GDOI uses the cookie fields as an SPI.
与ISAKMP不同，cookie对完全由GCK决定。GDOI ISAKMP标头中的cookie对标识重新密钥SA，以区分由GCKS管理的安全组。因此，GDOI将cookie字段用作SPI。
Next Payload identifies an ISAKMP or GDOI payload (see Section 5).
下一个有效载荷标识ISAKMP或GDOI有效载荷（参见第5节）。
Major Version is 1 and Minor Version is 0 according to ISAKMP (Section 3.1 of [RFC2408]).
根据ISAKMP（RFC2408第3.1节），主要版本为1，次要版本为0。
The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message.
对于GDOI GROUPKEY-PUSH消息，交换类型的值为33。
Flags MUST have the Encryption bit set according to Section 3.1 of [RFC2408]. All other bits MUST be set to zero.
标志必须根据[RFC2408]第3.1节设置加密位。所有其他位必须设置为零。
Message ID MUST be set to zero.
消息ID必须设置为零。
Length is according to ISAKMP (Section 3.1 of [RFC2408]).
长度根据ISAKMP（RFC2408第3.1节）确定。
GCKS may initiate a Rekey message for one of several reasons, e.g., the group membership has changed or keys are due to expire.
GCKS可能会出于以下原因之一启动密钥更新消息，例如，组成员身份已更改或密钥即将过期。
To begin the rekey datagram, the GCKS builds an ISAKMP HDR with the correct cookie pair, and a SEQ payload that includes a sequence number that is 1 greater than the previous rekey datagram. If the message is using the new KEK attribute for the first time, the SEQ is reset to 1 in this message.
为了开始重新密钥数据报，GCKS构建一个具有正确cookie对的ISAKMP HDR，以及一个包含比先前重新密钥数据报大1的序列号的SEQ有效载荷。如果消息首次使用新的KEK属性，则此消息中的SEQ将重置为1。
An SA payload is then added. This is identical in structure and meaning to an SA payload sent in a GROUPKEY-PULL exchange. If there are changes to the KEK (including due to group members being excluded, in the case of LKH), an SA_KEK attribute is added to the SA. If there are one or more new TEKs, then SA_TEK attributes are added to describe that policy.
然后添加SA有效负载。这在结构和意义上与在GROUPKEY-PULL交换中发送的SA有效负载相同。如果对KEK进行了更改（包括在LKH的情况下，由于排除了组成员），则会向SA添加一个SA_KEK属性。如果有一个或多个新的TEK，则添加SA_TEK属性来描述该策略。
A KD payload is then added. This is identical in structure and meaning to a KD payload sent in a GROUPKEY-PULL exchange. If an SA_KEK attribute was included in the SA payload, then corresponding KEKs (or a KEK update array) are included. A KEK update array is created by first determining which group members have been excluded, generating new keys as necessary, and then distributing LKH update arrays sufficient to provide the new KEK to remaining group members (see Section 5.4.1 of [RFC2627] for details). TEKs are also sent for each SA_TEK attribute included in the SA payload.
然后添加KD有效负载。这在结构和意义上与在GROUPKEY-PULL交换中发送的KD有效负载相同。如果SA有效负载中包含SA_KEK属性，则会包含相应的KEK（或KEK更新数组）。通过首先确定哪些组成员已被排除，根据需要生成新密钥，然后分发足以向其余组成员提供新KEK的LKH更新数组来创建KEK更新数组（有关详细信息，请参见[RFC2627]第5.4.1节）。还为SA有效负载中包含的每个SA_TEK属性发送TEK。
In the penultimate step, the GCKS creates the SIG payload and adds it to the datagram.
在倒数第二步中，GCKS创建SIG有效载荷并将其添加到数据报中。
Lastly, the payloads following the HDR are encrypted using the current KEK. The datagram can now be sent.
最后，HDR之后的有效负载使用当前KEK进行加密。现在可以发送数据报了。
A group member receiving the GROUPKEY-PUSH datagram matches the cookie pair in the ISAKMP HDR to an existing SA. The message is decrypted, and the form of the datagram is validated. This weeds out obvious ill-formed messages (which may be sent as part of a denial-of-service attack on the group).
接收GROUPKEY-PUSH数据报的组成员将ISAKMP HDR中的cookie对与现有SA匹配。对消息进行解密，并验证数据报的形式。这将清除明显的格式错误的消息（可能作为对组的拒绝服务攻击的一部分发送）。
The sequence number in the SEQ payload is validated to ensure that it is greater than the previously received sequence number. The SIG payload is then validated. If the signature fails, the message is discarded.
验证SEQ有效负载中的序列号，以确保其大于先前接收的序列号。然后验证SIG有效载荷。如果签名失败，消息将被丢弃。
The SA and KD payloads are processed, which results in a new GDOI Rekey SA (if the SA payload included an SA_KEK attribute) and/or new Data-Security SAs being added to the system. If the KD payload includes an LKH update array, the group member compares the LKH ID in each key update packet to the LKH IDs that it holds. If it finds a
对SA和KD有效载荷进行处理，从而将新的GDOI密钥SA（如果SA有效载荷包括SA_KEK属性）和/或新的数据安全SA添加到系统中。如果KD有效载荷包括LKH更新数组，则组成员将每个密钥更新数据包中的LKH ID与其持有的LKH ID进行比较。如果它发现
match, it decrypts the key using the key prior to it in the key array and stores the new key in the LKH key array that it holds. The final decryption yields the new group KEK.
匹配时，它使用密钥数组中它之前的密钥解密密钥，并将新密钥存储在它所持有的LKH密钥数组中。最终解密产生新的组KEK。
If the SA payload includes one or more Data-Security SAs including a counter-mode of operation and if the receiving group member is a sender for that SA, the group member uses its current SID value with the Data-Security SAs to create counter-mode nonces. If it is a sender and does not hold a current SID value, it MUST NOT install the Data-Security SAs. It MAY initiate a GROUPKEY-PULL exchange to the GCKS in order to obtain a SID value (along with current group policy).
如果SA有效负载包括一个或多个数据安全SA，包括计数器操作模式，并且如果接收组成员是该SA的发送方，则该组成员将其当前SID值用于数据安全SA以创建计数器模式nonce。如果它是一个发送方并且不持有当前SID值，则它不得安装数据安全SAs。它可以启动到GCK的GROUPKEY-PULL交换，以获得SID值（以及当前组策略）。
This document specifies use of several ISAKMP payloads, which are defined in accordance with [RFC2408]. The following payloads are used as defined in [RFC2408].
本文件规定了几种ISAKMP有效载荷的使用，这些载荷是根据[RFC2408]定义的。按照[RFC2408]中的定义使用以下有效载荷。
Next Payload Type Value
----------------- -----
Hash Payload (HASH) 8
Signature (SIG) 9
Next Payload Type Value
----------------- -----
Hash Payload (HASH) 8
Signature (SIG) 9
The following payloads are extended or further specified.
扩展或进一步指定了以下有效载荷。
Next Payload Type Value
----------------- -----
Security Association (SA) 1
Identification (ID) 5
Nonce (N) 10
Delete (D) 12
Next Payload Type Value
----------------- -----
Security Association (SA) 1
Identification (ID) 5
Nonce (N) 10
Delete (D) 12
Several payload formats specific to the group security exchanges are required.
需要几种特定于组安全交换的有效负载格式。
Next Payload Type Value
----------------- -----
SA KEK (SAK) 15
SA TEK (SAT) 16
Key Download (KD) 17
Sequence Number (SEQ) 18
Group Associated Policy (GAP) 22
Next Payload Type Value
----------------- -----
SA KEK (SAK) 15
SA TEK (SAT) 16
Key Download (KD) 17
Sequence Number (SEQ) 18
Group Associated Policy (GAP) 22
All multi-octet fields in GDOI payloads representing integers are laid out in big endian order (also known as "most significant byte first" or "network byte order").
GDOI有效负载中表示整数的所有多个八位字节字段均按大端顺序排列（也称为“最高有效字节优先”或“网络字节顺序”）。
All payloads including an ISAKMP Generic Payload Header create a Payload Length field that includes the length of the generic payload header (Section 3.2 of [RFC2408]).
包括ISAKMP通用有效载荷头的所有有效载荷创建一个有效载荷长度字段，该字段包括通用有效载荷头的长度（RFC2408第3.2节）。
The Identification payload is defined in [RFC2408]. For the GDOI, it is used to identify a group identity that will later be associated with security associations for the group. A group identity may map to a specific IPv4 or IPv6 multicast address, or may specify a more general identifier, such as one that represents a set of related multicast streams.
识别有效载荷在[RFC2408]中定义。对于GDOI，它用于标识稍后将与组的安全关联关联的组标识。组标识可以映射到特定的IPv4或IPv6多播地址，或者可以指定更通用的标识符，例如表示一组相关多播流的标识符。
When used with the GDOI, the DOI-Specific ID Data field MUST be set to 0.
与GDOI一起使用时，DOI特定ID数据字段必须设置为0。
When used with the GDOI, the ID_KEY_ID ID Type MUST be supported by a conforming implementation and MUST specify a 4-octet group identifier as its value. Implementations MAY also support other ID Types.
当与GDOI一起使用时，ID_KEY_ID ID类型必须得到一致性实现的支持，并且必须指定一个4-octet组标识符作为其值。实现还可能支持其他ID类型。
The Security Association payload is defined in [RFC2408]. For the GDOI, it is used by the GCKS to assert security attributes for both Rekey and Data-Security SAs.
安全关联有效负载在[RFC2408]中定义。对于GDOI，GCKS使用它为密钥更新和数据安全SA断言安全属性。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! DOI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SA Attribute Next Payload ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! DOI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SA Attribute Next Payload ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 4. Security Association Payload
图4。安全关联有效负载
The Security Association payload fields are defined as follows:
安全关联有效负载字段定义如下：
o Next Payload (1 octet) -- Identifies the next payload for the GROUPKEY-PULL or the GROUPKEY-PUSH message as defined above. The next payload MUST NOT be an SA Attribute payload; it MUST be the next payload following the Security Association type payload.
o 下一个有效负载（1个八位字节）——标识上面定义的GROUPKEY-PULL或GROUPKEY-PUSH消息的下一个有效负载。下一个有效负载不能是SA属性有效负载；它必须是安全关联类型有效负载之后的下一个有效负载。
o RESERVED (1 octet) -- MUST be zero.
o 保留（1个八位字节）--必须为零。
o Payload Length (2 octets) -- Is the octet length of the current payload including the generic header and all TEK and KEK payloads.
o 有效负载长度（2个八位字节）——是当前有效负载的八位字节长度，包括通用头和所有TEK和KEK有效负载。
o DOI (4 octets) -- Is the GDOI, which is value 2.
o DOI（4个八位字节）——是GDOI，值为2。
o Situation (4 octets) -- MUST be zero.
o 情况（4个八位字节）——必须为零。
o SA Attribute Next Payload (2 octets) -- MUST be the code for an SA Attribute payload type. See Section 5.2.1 for a description of which circumstances are required for each payload type to be present.
o SA属性下一个有效负载（2个八位字节）——必须是SA属性有效负载类型的代码。请参见第5.2.1节，了解每种有效载荷类型需要哪些情况。
o RESERVED (2 octets) -- MUST be zero.
o 保留（2个八位字节）--必须为零。
Payloads that define specific security association attributes for the KEK and/or TEKs used by the group MUST follow the SA payload. How many of each payload is dependent upon the group policy. There may be zero or one SAK payload, zero or one GAP payload, and zero or more SAT payloads, where either one SAK or SAT payload MUST be present. When present, the order of the SA Attribute payloads MUST be: SAK, GAP, and SATs.
为集团使用的KEK和/或TEK定义特定安全关联属性的有效负载必须遵循SA有效负载。每个有效负载的数量取决于组策略。可能存在零或一个SAK有效载荷、零或一个间隙有效载荷以及零或多个SAT有效载荷，其中必须存在一个SAK或SAT有效载荷。存在时，SA属性有效载荷的顺序必须为：SAK、GAP和SAT。
This latitude regarding SA Attribute payloads allows various group policies to be accommodated. For example, if the group policy does not require the use of a Rekey SA, the GCKS would not need to send an SA KEK attribute to the group member since all SA updates would be performed using the Registration SA. Alternatively, group policy might use a Rekey SA but choose to download a KEK to the group member only as part of the Registration SA. Therefore, the KEK policy (in the SA KEK attribute) would not be necessary as part of the Rekey SA message SA payload.
有关SA属性有效负载的这个纬度允许容纳各种组策略。例如，如果集团策略不要求使用重新注册SA，则GCK不需要向集团成员发送SA KEK属性，因为所有SA更新都将使用注册SA执行。或者，组策略可能使用重新注册SA，但选择仅作为注册SA的一部分将KEK下载给组成员。因此，KEK策略（在SA KEK属性中）不需要作为重新设置SA消息SA有效负载的一部分。
Specifying multiple SATs allows multiple sessions to be part of the same group and multiple streams to be associated with a session (e.g., video, audio, and text) but each with individual security association policy.
指定多个SAT允许多个会话成为同一组的一部分，并允许多个流与会话（例如，视频、音频和文本）关联，但每个流都具有单独的安全关联策略。
A GAP payload allows for the distribution of group-wide policy, such as instructions as to when to activate and deactivate SAs.
GAP有效负载允许在集团范围内分发策略，例如关于何时激活和停用SAs的说明。
The SA KEK (SAK) payload contains security attributes for the KEK method for a group and parameters specific to the GROUPKEY-PULL operation. The source and destination identities describe the identities used for the GROUPKEY-PULL datagram.
SA KEK（SAK）有效负载包含组的KEK方法的安全属性和特定于GROUPKEY-PULL操作的参数。源标识和目标标识描述用于GROUPKEY-PULL数据报的标识。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! !
~ SPI ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ KEK Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! !
~ SPI ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ KEK Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 5. SA KEK Payload
图5。萨科克有效载荷
The SAK payload fields are defined as follows:
SAK有效载荷字段定义如下：
o Next Payload (1 octet) -- Identifies the next payload for the GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next payload types for this message are a GAP payload, SAT payload, or zero to indicate that no SA Attribute payloads follow.
o 下一个有效负载（1个八位字节）——标识GROUPKEY-PULL或GROUPKEY-PUSH消息的下一个有效负载。此消息唯一有效的next有效负载类型是GAP有效负载、SAT有效负载或零，表示没有SA属性有效负载跟随。
o RESERVED (1 octet) -- MUST be zero.
o 保留（1个八位字节）--必须为零。
o Payload Length (2 octets) -- Length of this payload, including the KEK attributes.
o 有效负载长度（2个八位字节）——此有效负载的长度，包括KEK属性。
o Protocol (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP) [PROT-REG] for the GROUPKEY-PUSH datagram.
o 协议（1个八位字节）——描述GROUPKEY-PUSH数据报的IP协议ID（例如UDP/TCP）[PROT-REG]的值。
o SRC ID Type (1 octet) -- Value describing the identity information found in the SRC Identification Data field. Defined values are specified by the IPsec Identification Type section in the IANA ISAKMP registry [ISAKMP-REG].
o SRC ID类型（1个八位字节）——描述在SRC标识数据字段中找到的标识信息的值。定义的值由IANA ISAKMP注册表[ISAKMP-REG]中的IPsec标识类型部分指定。
o SRC ID Port (2 octets) -- Value specifying a port associated with the source ID. A value of zero means that the SRC ID Port field MUST be ignored.
o SRC ID端口（2个八位字节）——指定与源ID关联的端口的值。值为零表示必须忽略SRC ID端口字段。
o SRC ID Data Len (1 octet) -- Value specifying the length (in octets) of the SRC Identification Data field.
o SRC ID Data Len（1个八位字节）——指定SRC标识数据字段长度（以八位字节为单位）的值。
o SRC Identification Data (variable length) -- Value, as indicated by the SRC ID Type.
o SRC标识数据（可变长度）——值，由SRC ID类型指示。
o DST ID Type (1 octet) -- Value describing the identity information found in the DST Identification Data field. Defined values are specified by the IPsec Identification Type section in the IANA ISAKMP registry [ISAKMP-REG].
o DST ID类型（1个八位字节）——描述在DST标识数据字段中找到的标识信息的值。定义的值由IANA ISAKMP注册表[ISAKMP-REG]中的IPsec标识类型部分指定。
o DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP) [PROT-REG].
o DST ID Prot（1个八位字节）——描述IP协议ID（例如UDP/TCP）的值[Prot-REG]。
o DST ID Port (2 octets) -- Value specifying a port associated with the source ID.
o DST ID端口（2个八位字节）——指定与源ID关联的端口的值。
o DST ID Data Len (1 octet) -- Value specifying the length (in octets) of the DST Identification Data field.
o DST ID数据长度（1个八位字节）——指定DST标识数据字段长度（以八位字节为单位）的值。
o DST Identification Data (variable length) -- Value, as indicated by the DST ID Type.
o DST标识数据（可变长度）——由DST ID类型指示的值。
o SPI (16 octets) -- Security Parameter Index for the KEK. The SPI is the ISAKMP Header cookie pair where the first 8 octets become the "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR, and the second 8 octets become the "Responder Cookie" in the same HDR. As described above, these cookies are assigned by the GCKS.
o SPI（16个八位字节）——KEK的安全参数索引。SPI是ISAKMP头cookie对，其中前8个八位字节成为GROUPKEY-PUSH消息ISAKMP HDR的“启动器cookie”字段，后8个八位字节成为同一HDR中的“响应者cookie”。如上所述，这些cookie由GCK分配。
o RESERVED2 (4 octets) -- MUST be zero. These octets represent fields previously defined but no longer used by GDOI.
o RESERVED2（4个八位字节）——必须为零。这些八位字节表示先前定义但GDOI不再使用的字段。
o KEK Attributes -- Contains KEK policy attributes associated with the group. The following attributes may be present in a SAK payload. The attributes must follow the format defined in ISAKMP (Section 3.3 of [RFC2408]). In the table, attributes that are defined as TV are marked as Basic (B); attributes that are defined as TLV are marked as Variable (V).
o KEK属性--包含与组关联的KEK策略属性。SAK有效负载中可能存在以下属性。属性必须遵循ISAKMP（RFC2408第3.3节）中定义的格式。在表中，定义为TV的属性标记为基本（B）；定义为TLV的属性标记为变量（V）。
ID Class Value Type
-------- ----- ----
RESERVED 0
KEK_MANAGEMENT_ALGORITHM 1 B
KEK_ALGORITHM 2 B
KEK_KEY_LENGTH 3 B
KEK_KEY_LIFETIME 4 V
SIG_HASH_ALGORITHM 5 B
SIG_ALGORITHM 6 B
SIG_KEY_LENGTH 7 B
RESERVED 8 B
Unassigned 9-127
Private Use 128-255
Unassigned 256-32767
ID Class Value Type
-------- ----- ----
RESERVED 0
KEK_MANAGEMENT_ALGORITHM 1 B
KEK_ALGORITHM 2 B
KEK_KEY_LENGTH 3 B
KEK_KEY_LIFETIME 4 V
SIG_HASH_ALGORITHM 5 B
SIG_ALGORITHM 6 B
SIG_KEY_LENGTH 7 B
RESERVED 8 B
Unassigned 9-127
Private Use 128-255
Unassigned 256-32767
The KEK_ALGORITHM and SIG_ALGORITHM attributes MUST be included; others are OPTIONAL and are included depending on group policy. The KEK_MANAGEMENT_ALGORITHM attribute MUST NOT be included in a GROUPKEY-PULL message, and MUST be ignored if present.
必须包括KEK_算法和SIG_算法属性；其他是可选的，根据组策略包括在内。“KEK_管理_算法”属性不能包含在GROUPKEY-PULL消息中，如果存在，则必须忽略该属性。
The KEK_MANAGEMENT_ALGORITHM class specifies the group KEK management algorithm used to provide forward or backward access control (i.e., used to exclude group members). Defined values are specified in the following table.
KEK_MANAGEMENT_ALGORITHM类指定用于提供前向或后向访问控制（即，用于排除组成员）的组KEK管理算法。定义的值在下表中指定。
KEK Management Type Value
------------------- -----
Reserved 0
LKH 1
Unassigned 2-127
Private Use 128-255
Unassigned 256-65535
KEK Management Type Value
------------------- -----
Reserved 0
LKH 1
Unassigned 2-127
Private Use 128-255
Unassigned 256-65535
This type indicates the group management method described in Section 5.4 of [RFC2627]. A general discussion of LKH operations can also be found in Section 6.3 of "Multicast and Group Security" [HD03]
该类型表示[RFC2627]第5.4节所述的集团管理方法。关于LKH操作的一般性讨论也可以在“多播和组安全”的第6.3节[HD03]中找到
The KEK_ALGORITHM class specifies the encryption algorithm in which the KEK is used to provide confidentiality for the GROUPKEY-PUSH message. Defined values are specified in the following table. A GDOI implementation MUST abort if it encounters an attribute or capability that it does not understand.
KEK_算法类指定加密算法，其中KEK用于为GROUPKEY-PUSH消息提供机密性。定义的值在下表中指定。如果GDOI实现遇到无法理解的属性或功能，则必须中止。
Algorithm Type Value
-------------- -----
RESERVED 0
KEK_ALG_DES 1
KEK_ALG_3DES 2
KEK_ALG_AES 3
Unassigned 4-127
Private Use 128-255
Unassigned 256-32767
Algorithm Type Value
-------------- -----
RESERVED 0
KEK_ALG_DES 1
KEK_ALG_3DES 2
KEK_ALG_AES 3
Unassigned 4-127
Private Use 128-255
Unassigned 256-32767
If a KEK_MANAGEMENT_ALGORITHM is defined that specifies multiple keys (e.g., LKH), and if the management algorithm does not specify the algorithm for those keys, then the algorithm defined by the KEK_ALGORITHM attribute MUST be used for all keys that are included as part of the management.
如果定义的KEK_管理_算法指定了多个密钥（例如，LKH），并且如果管理算法未指定这些密钥的算法，则KEK_算法属性定义的算法必须用于作为管理一部分包含的所有密钥。
This type specifies DES using the Cipher Block Chaining (CBC) mode as described in [FIPS81].
此类型使用[FIPS81]中所述的密码块链接（CBC）模式指定DES。
This type specifies 3DES using three independent keys as described in "Keying Option 1" in [FIPS46-3].
该类型使用[FIPS46-3]中“键控选项1”中所述的三个独立键指定3DE。
This type specifies AES as described in [FIPS197]. The mode of operation for AES is CBC as defined in [SP.800-38A].
此类型指定[FIPS197]中所述的AES。AES的操作模式为[SP.800-38A]中定义的CBC。
The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in bits). The Group Controller/Key Server (GCKS) adds the KEK_KEY_LENGTH attribute to the SA payload when distributing KEK policy to group members. The group member verifies whether or not it has the capability of using a cipher key of that size. If the cipher definition includes a fixed key length (e.g., KEK_ALG_3DES), the group member can make its decision solely using the KEK_ALGORITHM attribute and does not need the KEK_KEY_LENGTH attribute. Sending the KEK_KEY_LENGTH attribute in the SA payload is OPTIONAL if the KEK cipher has a fixed key length. Also, note that the KEK_KEY_LEN includes only the actual length of the cipher key (the IV length is not included in this attribute).
KEK_KEY_LENGTH类指定KEK算法密钥长度（以位为单位）。在向组成员分发KEK策略时，组控制器/密钥服务器（GCKS）将KEK_密钥长度属性添加到SA有效负载。组成员验证是否能够使用该大小的密钥。如果密码定义包含固定的密钥长度（例如，KEK_ALG_3DES），则组成员可以仅使用KEK_算法属性做出决策，而不需要KEK_密钥长度属性。如果KEK密码具有固定的密钥长度，则在SA有效负载中发送KEK_密钥长度属性是可选的。另外，请注意KEK_KEY_LEN仅包括密码密钥的实际长度（IV长度不包括在此属性中）。
The KEK_KEY_LIFETIME class specifies the maximum time for which the KEK is valid. The GCKS may refresh the KEK at any time before the end of the valid period. The value is a 4-octet number defining a valid time period in seconds.
KEK_KEY_life类指定KEK有效的最长时间。GCK可在有效期结束前的任何时间刷新KEK。该值是定义有效时间段（以秒为单位）的4个八位数字。
SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. The following table defines the algorithms for SIG_HASH_ALGORITHM.
SIG_哈希算法指定SIG有效负载哈希算法。下表定义了SIG_哈希_算法的算法。
Algorithm Type Value
-------------- -----
Reserved 0
SIG_HASH_MD5 1
SIG_HASH_SHA1 2
SIG_HASH_SHA256 3
SIG_HASH_SHA384 4
SIG_HASH_SHA512 5
Unassigned 6-127
Private Use 128-255
Unassigned 256-65535
Algorithm Type Value
-------------- -----
Reserved 0
SIG_HASH_MD5 1
SIG_HASH_SHA1 2
SIG_HASH_SHA256 3
SIG_HASH_SHA384 4
SIG_HASH_SHA512 5
Unassigned 6-127
Private Use 128-255
Unassigned 256-65535
The SHA hash algorithms are defined in the Secure Hash Standard [FIPS180-3.2008].
安全哈希标准[FIPS180-3.2008]中定义了SHA哈希算法。
If the SIG_ALGORITHM is SIG_ALG_ECDSA-256, SIG_ALG_ECDSA-384, or SIG_ALG_ECDSA-521, the hash algorithm is implicit in the definition, and SIG_HASH_ALGORITHM is OPTIONAL in a SAK payload.
如果SIG_算法是SIG_ALG_ECDSA-256、SIG_ALG_ECDSA-384或SIG_ALG_ECDSA-521，则散列算法在定义中是隐式的，并且SIG_散列_算法在SAK负载中是可选的。
The SIG_ALGORITHM class specifies the SIG payload signature algorithm. Defined values are specified in the following table.
SIG_算法类指定SIG有效负载签名算法。定义的值在下表中指定。
Algorithm Type Value
-------------- -----
Reserved 0
SIG_ALG_RSA 1
SIG_ALG_DSS 2
SIG_ALG_ECDSS 3
SIG_ALG_ECDSA-256 4
SIG_ALG_ECDSA-384 5
SIG_ALG_ECDSA-521 6
Unassigned 7-127
Private Use 128-255
Unassigned 256-65535
Algorithm Type Value
-------------- -----
Reserved 0
SIG_ALG_RSA 1
SIG_ALG_DSS 2
SIG_ALG_ECDSS 3
SIG_ALG_ECDSA-256 4
SIG_ALG_ECDSA-384 5
SIG_ALG_ECDSA-521 6
Unassigned 7-127
Private Use 128-255
Unassigned 256-65535
This algorithm specifies the RSA digital signature algorithm using the EMSA-PKCS1-v1_5 encoding method, as described in [RFC3447].
该算法使用[RFC3447]中所述的EMSA-PKCS1-v1_5编码方法指定RSA数字签名算法。
This algorithm specifies the DSS digital signature algorithm as described in Section 4 of [FIPS186-3].
该算法规定了[FIPS186-3]第4节所述的DSS数字签名算法。
This algorithm specifies the Elliptic Curve Digital Signature Algorithm as described in Section 5 of [FIPS186-3]. This definition is deprecated in favor of the SIG_ALG_ECDSA family of algorithms.
该算法规定了[FIPS186-3]第5节所述的椭圆曲线数字签名算法。该定义被弃用，取而代之的是SIG_ALG_ECDSA系列算法。
This algorithm specifies the 256-bit Random ECP Group, as described in [RFC5903]. The format of the signature in the SIG payload MUST be as specified in [RFC4754].
此算法指定256位随机ECP组，如[RFC5903]中所述。SIG有效载荷中的签名格式必须符合[RFC4754]中的规定。
This algorithm specifies the 384-bit Random ECP Group, as described in [RFC5903]. The format of the signature in the SIG payload MUST be as specified in [RFC4754].
此算法指定384位随机ECP组，如[RFC5903]中所述。SIG有效载荷中的签名格式必须符合[RFC4754]中的规定。
This algorithm specifies the 521-bit Random ECP Group, as described in [RFC5903]. The format of the signature in the SIG payload MUST be as specified in [RFC4754].
该算法指定521位随机ECP组，如[RFC5903]所述。SIG有效载荷中的签名格式必须符合[RFC4754]中的规定。
The SIG_KEY_LENGTH class specifies the length of the SIG payload key in bits.
SIG_KEY_LENGTH类以位为单位指定SIG有效负载密钥的长度。
A GCKS may have group-specific policy that is not distributed in an SA TEK or SA KEK. Some of this policy is relevant to all group members, and some is sender-specific policy for a particular group member. The former can be distributed in either a GROUPKEY-PULL or GROUPKEY-PUSH exchange, whereas the latter MUST only be sent in a GROUPKEY-PULL exchange. Additionally, a group member sometimes has the need to make policy requests for resources of the GCKS in a
GCK可能具有未在SA TEK或SA KEK中分发的特定于组的策略。此策略中的一些与所有组成员相关，另一些是特定组成员的特定发件人策略。前者可以在GROUPKEY-PULL或GROUPKEY-PUSH交换中分发，后者只能在GROUPKEY-PULL交换中发送。此外，集团成员有时需要对集团中的GCK资源提出策略请求
GROUPKEY-PULL exchange. GDOI distributes this associated group policy and the policy requests in the Group Associated Policy (GAP) payload.
GROUPKEY-PULL交换。GDOI在组关联策略（GAP）负载中分发此关联的组策略和策略请求。
The GAP payload can be distributed by the GCKS as part of the SA payload. It follows any SA KEK payload and is placed before any SA TEK payloads. In the case that group policy does not include an SA KEK, the SA Attribute Next Payload field in the SA payload MAY indicate the GAP payload.
GAP有效载荷可由GCKS作为SA有效载荷的一部分进行分配。它跟随任何SA KEK有效载荷，并置于任何SA TEK有效载荷之前。在组策略不包括SA KEK的情况下，SA有效载荷中的SA属性Next Payload字段可指示间隙有效载荷。
The GAP payload can be optionally included by a group member in message 3 of the GROUPKEY-PULL exchange in order to make policy requests.
组成员可以选择在GROUPKEY-PULL交换的消息3中包括GAP有效负载，以便进行策略请求。
The GAP payload is defined as follows:
间隙有效载荷定义如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Group Associated Policy Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Group Associated Policy Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 6. GAP Payload
图6。间隙有效载荷
The GAP payload fields are defined as follows:
间隙有效载荷字段定义如下：
o Next Payload (1 octet) -- Identifies the next payload present in the GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next payload type for this message is an SA TEK or zero to indicate there are no more security association attributes.
o 下一个有效负载（1个八位字节）——标识GROUPKEY-PULL或GROUPKEY-PUSH消息中存在的下一个有效负载。此消息唯一有效的下一个有效负载类型是SA TEK或零，表示没有更多的安全关联属性。
o RESERVED (1 octet) -- MUST be zero.
o 保留（1个八位字节）--必须为零。
o Payload Length (2 octets) -- Length of this payload, including the GAP header and Attributes.
o 有效负载长度（2个八位字节）——此有效负载的长度，包括间隙标头和属性。
o Group Associated Policy Attributes (variable) -- Contains attributes following the format defined in Section 3.3 of [RFC2408]. In the table, attributes that are defined as TV are marked as Basic (B); attributes that are defined as TLV are marked as Variable (V).
o 组关联策略属性（变量）——包含符合[RFC2408]第3.3节定义格式的属性。在表中，定义为TV的属性标记为基本（B）；定义为TLV的属性标记为变量（V）。
Attribute Type Value Type
-------------- ----- ----
RESERVED 0
ACTIVATION_TIME_DELAY 1 B
DEACTIVATION_TIME_DELAY 2 B
SENDER_ID_REQUEST 3 B
Unassigned 4-127
Private Use 128-255
Unassigned 256-32767
Attribute Type Value Type
-------------- ----- ----
RESERVED 0
ACTIVATION_TIME_DELAY 1 B
DEACTIVATION_TIME_DELAY 2 B
SENDER_ID_REQUEST 3 B
Unassigned 4-127
Private Use 128-255
Unassigned 256-32767
Several group associated policy attributes are defined in this memo. A GDOI implementation MUST abort if it encounters an attribute or capability that it does not understand. The values for these attributes are included in the IANA Considerations section of this memo.
此备忘录中定义了多个与组关联的策略属性。如果GDOI实现遇到无法理解的属性或功能，则必须中止。这些属性的值包含在本备忘录的IANA注意事项部分中。
Section 4.2.1 of [RFC5374] specifies a key rollover method that requires two values be given it from the group key management protocol. The ACTIVATION_TIME_DELAY attribute allows a GCKS to set the Activation Time Delay (ATD) for SAs generated from TEKs. The ATD defines how long after receiving new SAs that they are to be activated by the GM. The ATD value is in seconds.
[RFC5374]第4.2.1节规定了一种密钥翻转方法，该方法要求从组密钥管理协议中为其提供两个值。激活时间延迟属性允许GCKS为TEKs生成的SA设置激活时间延迟（ATD）。ATD定义了GM在收到新SAs后激活它们的时间。ATD值以秒为单位。
The DEACTIVATION_TIME_DELAY allows the GCKS to set the Deactivation Time Delay (DTD) for previously distributed SAs. The DTD defines how long after receiving new SAs that it SHOULD deactivate SAs that are destroyed by the rekey event. The value is in seconds.
停用时间延迟允许GCK为先前分发的SAs设置停用时间延迟（DTD）。DTD定义了在接收到新SA后多长时间内，它应该停用被重新密钥事件破坏的SA。该值以秒为单位。
The values of ATD and DTD are independent. However, the most effective policy will have the DTD value be the larger value, as this allows new SAs to be activated before older SAs are deactivated. Such a policy ensures that protected group traffic will always flow without interruption.
ATD和DTD的值是独立的。但是，最有效的策略将使DTD值为较大的值，因为这允许在停用旧SA之前激活新SA。这样的策略可确保受保护的组流量始终不会中断。
The SENDER_ID_REQUEST attribute is used by a group member to request SIDs during the GROUPKEY-PULL message, and includes a count of how many SID values it desires.
在GROUPKEY-PULL消息期间，组成员使用SENDER_ID_REQUEST属性请求SID，并包括它需要多少SID值的计数。
The SA TEK (SAT) payload contains security attributes for a single TEK associated with a group.
SA TEK（SAT）有效负载包含与组关联的单个TEK的安全属性。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol-ID ! TEK Protocol-Specific Payload ~
+-+-+-+-+-+-+-+-+ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol-ID ! TEK Protocol-Specific Payload ~
+-+-+-+-+-+-+-+-+ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 7. SA TEK Payload
图7。萨特克有效载荷
The SAT payload fields are defined as follows:
SAT有效载荷字段定义如下：
o Next Payload (1 octet) -- Identifies the next payload for the GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next payload types for this message are another SAT payload or zero to indicate there are no more security association attributes.
o 下一个有效负载（1个八位字节）——标识GROUPKEY-PULL或GROUPKEY-PUSH消息的下一个有效负载。此消息唯一有效的下一个有效负载类型是另一个SAT负载或零，表示没有更多的安全关联属性。
o RESERVED (1 octet) -- MUST be zero.
o 保留（1个八位字节）--必须为零。
o Payload Length (2 octets) -- Length of this payload, including the TEK Protocol-Specific Payload.
o 有效负载长度（2个八位字节）——此有效负载的长度，包括TEK协议特定的有效负载。
o Protocol-ID (1 octet) -- Value specifying the Security Protocol. The following table defines values for the Security Protocol.
o 协议ID（1个八位字节）——指定安全协议的值。下表定义了安全协议的值。
Protocol ID Value
----------- -----
RESERVED 0
GDOI_PROTO_IPSEC_ESP 1
GDOI_PROTO_IPSEC_AH 2
Unassigned 3-127
Private Use 128-255
Protocol ID Value
----------- -----
RESERVED 0
GDOI_PROTO_IPSEC_ESP 1
GDOI_PROTO_IPSEC_AH 2
Unassigned 3-127
Private Use 128-255
o TEK Protocol-Specific Payload (variable) -- Payload which describes the attributes specific for the Protocol-ID.
o TEK协议特定有效负载（变量）——描述协议ID特定属性的有效负载。
The TEK Protocol-Specific payload for ESP and AH is as follows:
ESP和AH的TEK协议特定有效载荷如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Transform ID ! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI ! RFC 2407 SA Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Transform ID ! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI ! RFC 2407 SA Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 8. ESP/AH TEK Payload
图8。ESP/AH-TEK有效载荷
The SAT payload fields are defined as follows:
SAT有效载荷字段定义如下：
o Protocol (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP) [PROT-REG]. A value of zero means that the Protocol field MUST be ignored.
o 协议（1个八位字节）——描述IP协议ID（例如UDP/TCP）[PROT-REG]的值。值为零表示必须忽略协议字段。
o SRC ID Type (1 octet) -- Value describing the identity information found in the SRC Identification Data field. Defined values are specified by the IPsec Identification Type section in the IANA ISAKMP registry [ISAKMP-REG].
o SRC ID类型（1个八位字节）——描述在SRC标识数据字段中找到的标识信息的值。定义的值由IANA ISAKMP注册表[ISAKMP-REG]中的IPsec标识类型部分指定。
o SRC ID Port (2 octets) -- Value specifying a port associated with the source ID. A value of zero means that the SRC ID Port field MUST be ignored.
o SRC ID端口（2个八位字节）——指定与源ID关联的端口的值。值为零表示必须忽略SRC ID端口字段。
o SRC ID Data Len (1 octet) -- Value specifying the length (in octets) of the SRC Identification Data field.
o SRC ID Data Len（1个八位字节）——指定SRC标识数据字段长度（以八位字节为单位）的值。
o SRC Identification Data (variable length) -- Value, as indicated by the SRC ID Type. Set to 3 octets or zero for multiple-source multicast groups that use a common TEK for all senders.
o SRC标识数据（可变长度）——值，由SRC ID类型指示。对于所有发送方使用公共TEK的多个源多播组，设置为3个八位字节或零。
o DST ID Type (1 octet) -- Value describing the identity information found in the DST Identification Data field. Defined values are specified by the IPsec Identification Type section in the IANA ISAKMP registry [ISAKMP-REG].
o DST ID类型（1个八位字节）——描述在DST标识数据字段中找到的标识信息的值。定义的值由IANA ISAKMP注册表[ISAKMP-REG]中的IPsec标识类型部分指定。
o DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP) [PROT-REG]. A value of zero means that the DST ID Prot field MUST be ignored.
o DST ID Prot（1个八位字节）——描述IP协议ID（例如UDP/TCP）的值[Prot-REG]。值为零表示必须忽略DST ID Prot字段。
o DST ID Port (2 octets) -- Value specifying a port associated with the source ID. A value of zero means that the DST ID Port field MUST be ignored.
o DST ID端口（2个八位字节）——指定与源ID关联的端口的值。值为零表示必须忽略DST ID端口字段。
o DST ID Data Len (1 octet) -- Value specifying the length (in octets) of the DST Identification Data field.
o DST ID数据长度（1个八位字节）——指定DST标识数据字段长度（以八位字节为单位）的值。
o DST Identification Data (variable length) -- Value, as indicated by the DST ID Type.
o DST标识数据（可变长度）——由DST ID类型指示的值。
o Transform ID (1 octet) -- Value specifying which ESP or AH transform is to be used. The list of valid values is defined in the IPsec ESP or IPsec AH Transform Identifiers section of the IANA ISAKMP registry [ISAKMP-REG].
o 转换ID（1个八位字节）——指定要使用哪个ESP或AH转换的值。有效值列表在IANA ISAKMP注册表[ISAKMP-REG]的IPsec ESP或IPsec AH转换标识符部分中定义。
o SPI (4 octets) -- Security Parameter Index for ESP.
o SPI（4个八位字节）——ESP的安全参数索引。
o RFC 2407 Attributes -- ESP and AH Attributes from Section 4.5 of [RFC2407]. The GDOI supports all IPsec DOI SA Attributes for GDOI_PROTO_IPSEC_ESP and GDOI_PROTO_IPSEC_AH, excluding the Group Description (Section 4.5 of [RFC2407]), which MUST NOT be sent by a GDOI implementation and is ignored by a GDOI implementation if received. The following attributes MUST be supported by an implementation supporting ESP and AH: SA Life Type, SA Life Duration, and Encapsulation Mode. An implementation supporting ESP MUST also support the Authentication Algorithm attribute if the ESP transform includes authentication. The Authentication Algorithm attribute of the IPsec DOI is group authentication in GDOI.
o RFC 2407属性——来自[RFC2407]第4.5节的ESP和AH属性。GDOI支持GDOI_PROTO_IPsec_ESP和GDOI_PROTO_IPsec_AH的所有IPsec DOI SA属性，不包括组描述（RFC2407的第4.5节），该组描述不能由GDOI实现发送，并且在收到时被GDOI实现忽略。支持ESP和AH的实现必须支持以下属性：SA生命类型、SA生命周期和封装模式。如果ESP转换包含身份验证，则支持ESP的实现还必须支持“身份验证算法”属性。IPsec DOI的身份验证算法属性是GDOI中的组身份验证。
"Multicast Extensions to the Security Architecture for the Internet Protocol" (RFC 5374) introduces new requirements for a group key management system distributing IPsec policy. It also defines new attributes as part of the Group Security Policy Database (GSPD). These attributes describe policy that a group key management system must convey to a group member in order to support those extensions. The GDOI SA TEK payload distributes IPsec policy using IPsec security association attributes defined in [ISAKMP-REG]. This section defines how GDOI can convey the new attributes as IPsec Security Association Attributes.
“Internet协议安全体系结构的多播扩展”（RFC 5374）对分发IPsec策略的组密钥管理系统提出了新的要求。它还将新属性定义为组安全策略数据库（GSPD）的一部分。这些属性描述了组密钥管理系统必须向组成员传达的策略，以支持这些扩展。GDOI SA TEK有效负载使用[ISAKMP-REG]中定义的IPsec安全关联属性分发IPsec策略。本节定义GDOI如何将新属性作为IPsec安全关联属性传递。
Applications use the extensions in [RFC5374] to copy the IP addresses into the outer IP header when encapsulating an IP packet as an IPsec tunnel mode packet. This allows an IP multicast packet to continue to be routed as a IP multicast packet. This attribute also provides the necessary policy so that the GDOI group member can appropriately set up the GSPD. The following table defines values for the Address Preservation attribute.
当将IP数据包封装为IPsec隧道模式数据包时，应用程序使用[RFC5374]中的扩展将IP地址复制到外部IP报头中。这允许IP多播数据包继续作为IP多播数据包路由。此属性还提供必要的策略，以便GDOI组成员可以适当地设置GSPD。下表定义了地址保留属性的值。
Address Preservation Type Value
------------------------- -----
Reserved 0
None 1
Source-Only 2
Destination-Only 3
Source-and-Destination 4
Unassigned 5-61439
Private Use 61440-65535
Address Preservation Type Value
------------------------- -----
Reserved 0
None 1
Source-Only 2
Destination-Only 3
Source-and-Destination 4
Unassigned 5-61439
Private Use 61440-65535
Depending on group policy, several address preservation methods are possible: no address preservation ("None"), preservation of the original source address ("Source-Only"), preservation of the original destination address ("Destination-Only"), or both addresses ("Source-and-Destination"). If this attribute is not included in a GDOI SA TEK payload provided by a GCKS, then Source-and-Destination address preservation has been defined for the SA TEK.
根据集团政策，有几种地址保存方法是可能的：无地址保存（“无”）、原始源地址保存（“仅源”）、原始目的地址保存（“仅目的地”）或两种地址保存（“源和目的地”）。如果此属性未包含在GCKS提供的GDOI SA TEK有效负载中，则已为SA TEK定义了源地址和目标地址保留。
Depending on group policy, an IPsec SA created from an SA TEK payload is defined to be in the sending and/or receiving direction. The following table defines values for the SA Direction attribute.
根据组策略，从SA TEK有效负载创建的IPsec SA定义为处于发送和/或接收方向。下表定义了SA方向属性的值。
Name Value
---- -----
Reserved 0
Sender-Only 1
Receiver-Only 2
Symmetric 3
Unassigned 4-61439
Private Use 61440-65535
Name Value
---- -----
Reserved 0
Sender-Only 1
Receiver-Only 2
Symmetric 3
Unassigned 4-61439
Private Use 61440-65535
SA TEK policy used by multiple senders MUST be installed in both the sending and receiving direction ("Symmetric"), whereas SA TEK for a single sender SHOULD be installed in the receiving direction by receivers ("Receiver-Only") and in the sending direction by the sender ("Sender-Only").
多个发送方使用的SA TEK策略必须安装在发送和接收方向（“对称”），而单个发送方的SA TEK策略应由接收方安装在接收方向（“仅接收方”）上，由发送方安装在发送方向上（“仅发送方”）。
An SA TEK payload that does not include the SA Direction attribute is treated as a Symmetric IPsec SA. Note that Symmetric is the only value that can be meaningfully described for an SA TEK distributed in a GROUPKEY-PUSH message. Alternatively, Receiver-Only could be distributed, but group senders would need to be configured to not receive GROUPKEY-PUSH messages in order to retain their role.
不包括SA方向属性的SA TEK有效负载被视为对称IPsec SA。请注意，对于在GROUPKEY-PUSH消息中分发的SA TEK，Symmetric是唯一可以有意义地描述的值。或者，只能分发接收方，但需要将组发送方配置为不接收GROUPKEY-PUSH消息，以保留其角色。
Besides ESP and AH, GDOI should serve to establish SAs for secure groups needed by other Security Protocols that operate at the transport, application, and internetwork layers. These other Security Protocols, however, are in the process of being developed or do not yet exist.
除了ESP和AH之外，GDOI还应该为在传输层、应用层和互联网层运行的其他安全协议所需的安全组建立SA。然而，这些其他安全协议正在开发中或尚不存在。
The following information needs to be provided for a Security Protocol to the GDOI.
需要为GDOI的安全协议提供以下信息。
o The Protocol-ID for the particular Security Protocol
o 特定安全协议的协议ID
o The SPI Size
o SPI大小
o The method of SPI generation
o SPI生成方法
o The transforms, attributes, and keys needed by the Security Protocol
o 安全协议所需的转换、属性和密钥
All Security Protocols MUST provide the information in the bulleted list above to guide the GDOI specification for that protocol. Definitions for the support of those Security Protocols in GDOI will be specified in separate documents.
所有安全协议必须提供上述项目符号列表中的信息，以指导该协议的GDOI规范。GDOI中支持这些安全协议的定义将在单独的文件中指定。
A Security Protocol MAY protect traffic at any level of the network stack. However, in all cases, applications of the Security Protocol MUST protect traffic that MAY be shared by more than two entities.
安全协议可以在网络堆栈的任何级别保护通信量。然而，在所有情况下，安全协议的应用程序必须保护可能由两个以上实体共享的通信量。
The Key Download payload contains group keys for the group specified in the SA payload. These Key Download payloads can have several security attributes applied to them based upon the security policy of the group as defined by the associated SA payload.
密钥下载有效负载包含SA有效负载中指定的组的组密钥。这些密钥下载有效负载可以基于由关联SA有效负载定义的组的安全策略，对其应用多个安全属性。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Number of Key Packets ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packets ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Number of Key Packets ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packets ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 9. Key Download Payload
图9。密钥下载有效载荷
The Key Download payload fields are defined as follows:
密钥下载有效负载字段定义如下：
o Next Payload (1 octet) -- Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be zero.
o 下一个有效负载（1个八位字节）——消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为零。
o RESERVED (1 octet) -- Unused; set to zero.
o 保留（1个八位组）——未使用；设置为零。
o Payload Length (2 octets) -- Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节）——当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
o Number of Key Packets (2 octets) -- Contains the total number of key packets being passed in this data block.
o 密钥包数（2个八位字节）——包含在此数据块中传递的密钥包总数。
o Key Packets (variable) -- Several types of key packets are defined. Each key packet has the following format.
o 密钥包（变量）——定义了几种类型的密钥包。每个密钥包具有以下格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! KD Type ! RESERVED ! KD Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI Size ! SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packet Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! KD Type ! RESERVED ! KD Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI Size ! SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packet Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 10. Key Packet
图10。密钥包
o Key Download (KD) Type (1 octet) -- Identifier for the Key Data field of this key packet.
o 密钥下载（KD）类型（1个八位字节）——此密钥包的密钥数据字段的标识符。
Key Download Type Value
----------------- -----
Reserved 0
TEK 1
KEK 2
LKH 3
SID 4
Unassigned 4-127
Private Use 128-255
Key Download Type Value
----------------- -----
Reserved 0
TEK 1
KEK 2
LKH 3
SID 4
Unassigned 4-127
Private Use 128-255
"KEK" is a single key, whereas LKH is an array of key-encrypting keys.
“KEK”是单个密钥，而LKH是密钥加密密钥的数组。
o Reserved (1 octet) -- Unused; set to zero.
o 保留（1个八位组）——未使用；设置为零。
o Key Download Length (2 octets) -- Length in octets of the Key Packet data, including the Key Packet header.
o 密钥下载长度（2个八位字节）——密钥包数据的八位字节长度，包括密钥包头。
o SPI Size (1 octet) -- Value specifying the length in octets of the SPI as defined by the Protocol-ID.
o SPI大小（1个八位字节）——指定协议ID定义的SPI长度（以八位字节为单位）的值。
o SPI (variable length) -- Security Parameter Index, which matches a SPI previously sent in a SAK or SAT payload.
o SPI（可变长度）——安全参数索引，它与先前在SAK或SAT有效负载中发送的SPI相匹配。
o Key Packet Attributes (variable length) -- Contains key information. The format of this field is specific to the value of the KD Type field. The following sections describe the format of each KD Type.
o 密钥包属性（可变长度）——包含密钥信息。此字段的格式特定于KD类型字段的值。以下各节描述了每种KD类型的格式。
The following attributes may be present in a TEK Download Type. Exactly one attribute matching each type sent in the SAT payload MUST be present. The attributes must follow the format defined in ISAKMP (Section 3.3 of [RFC2408]). In the table, attributes defined as TV are marked as Basic (B); attributes defined as TLV are marked as Variable (V).
TEK下载类型中可能存在以下属性。必须存在与SAT有效负载中发送的每种类型匹配的一个属性。属性必须遵循ISAKMP（RFC2408第3.3节）中定义的格式。在表中，定义为TV的属性标记为基本（B）；定义为TLV的属性标记为变量（V）。
TEK Class Value Type
--------- ----- ----
RESERVED 0
TEK_ALGORITHM_KEY 1 V
TEK_INTEGRITY_KEY 2 V
TEK_SOURCE_AUTH_KEY 3 V
Unassigned 4-127
Private Use 128-255
Unassigned 256-32767
TEK Class Value Type
--------- ----- ----
RESERVED 0
TEK_ALGORITHM_KEY 1 V
TEK_INTEGRITY_KEY 2 V
TEK_SOURCE_AUTH_KEY 3 V
Unassigned 4-127
Private Use 128-255
Unassigned 256-32767
If no TEK key packets are included in a Registration KD payload, the group member can expect to receive the TEK as part of a Rekey SA. At least one TEK must be included in each Rekey KD payload. Multiple TEKs may be included if multiple streams associated with the SA are to be rekeyed.
如果注册KD有效负载中不包括TEK密钥数据包，则组成员可以期望作为重新密钥SA的一部分接收TEK。每个重新密钥KD有效载荷中必须至少包含一个TEK。如果要对与SA相关联的多个流进行密钥更新，则可以包括多个tek。
When an algorithm specification specifies the format of the keying material, the value transported in the KD payload for that key is passed according to that specification. The keying material may contain information besides a key. For example, "The Use of Galois/ Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)" [RFC4106] defines a salt value as part of KEYMAT.
当算法规范指定键控材料的格式时，根据该规范传递该键在KD有效负载中传输的值。键控材料可能包含除键外的信息。例如，“在IPsec封装安全有效负载（ESP）中使用Galois/计数器模式（GCM）”[RFC4106]将salt值定义为KEYMAT的一部分。
The TEK_ALGORITHM_KEY class declares that the encryption key for this SPI is contained as the Key Packet Attribute. The encryption algorithm that will use this key was specified in the SAT payload.
TEK_ALGORITHM_KEY类声明此SPI的加密密钥包含为密钥包属性。SAT有效负载中指定了将使用此密钥的加密算法。
In the case that the algorithm requires multiple keys (e.g., 3DES), all keys will be included in one attribute.
如果算法需要多个关键点（例如3DE），则所有关键点都将包含在一个属性中。
DES keys will consist of 64 bits (the 56 key bits with parity bits). Triple DES keys will be specified as a single 192-bit attribute (including parity bits) in the order that the keys are to be used for encryption (e.g., DES_KEY1, DES_KEY2, DES_KEY3).
DES密钥将由64位组成（56个密钥位和奇偶校验位）。三重DES密钥将按照密钥用于加密的顺序指定为单个192位属性（包括奇偶校验位）（例如，DES_密钥1、DES_密钥2、DES_密钥3）。
The TEK_INTEGRITY_KEY class declares that the integrity key for this SPI is contained as the Key Packet Attribute. The integrity algorithm that will use this key was specified in the SAT payload. Thus, GDOI assumes that both the symmetric encryption and integrity keys are pushed to the GM. HMAC-SHA1 keys will consist of 160 bits [RFC2404], and HMAC-MD5 keys will consist of 128 bits [RFC2403]. HMAC-SHA2 and AES-GMAC keys will have a key length equal to the output length of the hash functions [RFC4868] [RFC4543].
TEK_INTEGRITY_KEY类声明此SPI的完整性密钥包含为密钥包属性。SAT有效负载中指定了将使用此密钥的完整性算法。因此，GDOI假设对称加密和完整性密钥都被推送到GM。HMAC-SHA1密钥将由160位[RFC2404]组成，HMAC-MD5密钥将由128位[RFC2403]组成。HMAC-SHA2和AES-GMAC密钥的密钥长度将等于散列函数[RFC4868][RFC4543]的输出长度。
The TEK_SOURCE_AUTH_KEY class declares that the source authentication key for this SPI is contained in the Key Packet Attribute. The source authentication algorithm that will use this key was specified in the SAT payload.
TEK_SOURCE_AUTH_KEY类声明此SPI的源身份验证密钥包含在密钥包属性中。SAT有效负载中指定了将使用此密钥的源身份验证算法。
The following attributes may be present in a KEK Download Type. Exactly one attribute matching each type sent in the SAK payload MUST be present. The attributes MUST follow the format defined in ISAKMP (Section 3.3 of [RFC2408]). In the table, attributes defined as TV are marked as Basic (B); attributes defined as TLV are marked as Variable (V).
KEK下载类型中可能存在以下属性。必须存在与SAK有效负载中发送的每种类型匹配的一个属性。属性必须遵循ISAKMP（RFC2408第3.3节）中定义的格式。在表中，定义为TV的属性标记为基本（B）；定义为TLV的属性标记为变量（V）。
KEK Class Value Type
--------- ----- ----
RESERVED 0
KEK_ALGORITHM_KEY 1 V
SIG_ALGORITHM_KEY 2 V
Unassigned 3-127
Private Use 128-255
Unassigned 256-32767
KEK Class Value Type
--------- ----- ----
RESERVED 0
KEK_ALGORITHM_KEY 1 V
SIG_ALGORITHM_KEY 2 V
Unassigned 3-127
Private Use 128-255
Unassigned 256-32767
If the KEK key packet is included, there MUST be only one present in the KD payload.
如果包含KEK密钥数据包，KD有效负载中必须只有一个。
The KEK_ALGORITHM_KEY class declares the encryption key for this SPI is contained in the Key Packet Attribute. The encryption algorithm that will use this key was specified in the SAK payload.
KEK_算法_密钥类声明此SPI的加密密钥包含在密钥包属性中。将使用此密钥的加密算法已在SAK有效负载中指定。
If the mode of operation for the algorithm requires an IV, an explicit IV MUST be included in the KEK_ALGORITHM_KEY before the actual key.
如果算法的操作模式需要IV，则在实际密钥之前，KEK_算法_密钥中必须包含显式IV。
The SIG_ALGORITHM_KEY class declares that the public key for this SPI is contained in the Key Packet Attribute, which may be useful when no public key infrastructure is available. The signature algorithm that will use this key was specified in the SAK payload.
SIG_ALGORITHM_KEY类声明此SPI的公钥包含在KEY Packet属性中，这在没有可用的公钥基础结构时可能很有用。将使用此密钥的签名算法在SAK有效负载中指定。
The LKH key packet is comprised of attributes representing different nodes in the LKH key tree.
LKH密钥分组由表示LKH密钥树中不同节点的属性组成。
The following attributes are used to pass an LKH KEK array in the KD payload. The attributes MUST follow the format defined in ISAKMP (Section 3.3 of [RFC2408]). In the table, attributes defined as TV are marked as Basic (B); attributes defined as TLV are marked as Variable (V).
以下属性用于传递KD有效负载中的LKH KEK数组。属性必须遵循ISAKMP（RFC2408第3.3节）中定义的格式。在表中，定义为TV的属性标记为基本（B）；定义为TLV的属性标记为变量（V）。
KEK Class Value Type
--------- ----- ----
RESERVED 0
LKH_DOWNLOAD_ARRAY 1 V
LKH_UPDATE_ARRAY 2 V
SIG_ALGORITHM_KEY 3 V
Unassigned 4-127
Private Use 128-255
Unassigned 256-32767
KEK Class Value Type
--------- ----- ----
RESERVED 0
LKH_DOWNLOAD_ARRAY 1 V
LKH_UPDATE_ARRAY 2 V
SIG_ALGORITHM_KEY 3 V
Unassigned 4-127
Private Use 128-255
Unassigned 256-32767
If an LKH key packet is included in the KD payload, there MUST be only one present.
如果KD有效负载中包含LKH密钥数据包，则必须仅存在一个密钥数据包。
This attribute is used to download a set of keys to a group member. It MUST NOT be included in a GROUPKEY-PUSH message KD payload if the GROUPKEY-PUSH is sent to more than the group member. If an LKH_DOWNLOAD_ARRAY attribute is included in a KD payload, there MUST be only one present.
此属性用于将一组密钥下载到组成员。如果GROUPKEY-PUSH发送给多个组成员，则它不得包含在GROUPKEY-PUSH消息KD有效负载中。如果KD有效负载中包含LKH_DOWNLOAD_数组属性，则必须仅存在一个。
This attribute consists of a header block, followed by one or more LKH keys.
该属性由一个头块和一个或多个LKH键组成。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Version ! # of LKH Keys ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Keys !
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Version ! # of LKH Keys ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Keys !
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11. LKH Download Array
图11。LKH下载阵列
The KEK_LKH attribute fields are defined as follows:
KEK_LKH属性字段定义如下：
o LKH version (1 octet) -- Version of the LKH data format. Must be one.
o LKH版本（1个八位字节）——LKH数据格式的版本。一定是一个。
o Number of LKH Keys (2 octets) -- This value is the number of distinct LKH keys in this sequence.
o LKH键的数量（2个八位字节）——此值是此序列中不同LKH键的数量。
o RESERVED (1 octet) -- Unused; set to zero. Each LKH Key is defined as follows:
o 保留（1个八位组）——未使用；设置为零。每个LKH键定义如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH ID ! Key Type ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Creation Date !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Expiration Date !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Handle !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Key Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH ID ! Key Type ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Creation Date !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Expiration Date !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Handle !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Key Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12. LKH Key
图12。LKH键
o LKH ID (2 octets) -- Identity of the LKH node. A GCKS is free to choose the ID in an implementation-specific manner (e.g., the position of this key in a binary tree structure used by LKH).
o LKH ID（2个八位字节）——LKH节点的标识。GCKS可以以特定于实现的方式自由选择ID（例如，LKH使用的二叉树结构中该键的位置）。
o Key Type (1 octet) -- Encryption algorithm for which this key data is to be used. This value is specified in Section 5.3.3.
o 密钥类型（1个八位字节）--使用此密钥数据的加密算法。第5.3.3节规定了该值。
o RESERVED (1 octet) -- Unused; set to zero.
o 保留（1个八位组）——未使用；设置为零。
o Key Creation Date (4 octets) -- Unsigned time value defining a valid time period in seconds representing the number of seconds since 0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal Time (UTC), without including leap seconds. [RFC5905]. This is the time when this key data was originally generated. A time value of zero indicates that there is no time before which this key is not valid.
o 密钥创建日期（4个八位字节）--无符号时间值定义有效时间段（以秒为单位），表示自1970年1月1日协调世界时（UTC）0小时0分0秒起的秒数，不包括闰秒。[RFC5905]。这是最初生成此关键数据的时间。时间值为零表示此键在任何时间之前无效。
o Key Expiration Date (4 octets) -- Unsigned time value defining a valid time period in seconds representing the number of seconds since 0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal Time (UTC), without including leap seconds. [RFC5905]. This is the time when this key is no longer valid for use. A time value of zero indicates that this key does not have an expiration time.
o 密钥过期日期（4个八位字节）--无符号时间值定义有效时间段（以秒为单位），表示自1970年1月1日协调世界时（UTC）0小时、0分钟、0秒起的秒数，不包括闰秒。[RFC5905]。此时此密钥不再有效。时间值为零表示此密钥没有过期时间。
o Key Handle (4 octets) -- Value assigned by the GCKS to uniquely identify a key within an LKH ID. Each new key distributed by the GCKS for this node will have a key handle identity distinct from previous or successive key handles specified for this node.
o 密钥句柄（4个八位字节）——GCKS分配的值，用于唯一标识LKH ID内的密钥。GCKS为此节点分配的每个新密钥将具有一个不同于为该节点指定的先前或后续密钥句柄的密钥句柄标识。
o Key Data (variable length) -- Key data, which is dependent on the Key Type algorithm for its format. If the mode of operation for the algorithm requires an IV, an explicit IV MUST be included in the Key Data field prepended to the actual key.
o 密钥数据（可变长度）——密钥数据，其格式取决于密钥类型算法。如果算法的操作模式需要IV，则必须在实际密钥前面的密钥数据字段中包含显式IV。
The Key Creation Date and Key Expiration Dates MAY be zero. This is necessary in the case where time synchronization within the group is not possible.
密钥创建日期和密钥过期日期可以为零。在无法在组内进行时间同步的情况下，这是必要的。
The first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute contains the Leaf identifier and key for the group member. The rest of the LKH Key structures contain keys along the path of the key tree in order from the leaf, culminating in the group KEK.
LKH_DOWNLOAD_数组属性中的第一个LKH密钥结构包含组成员的叶标识符和密钥。其余的LKH密钥结构包含沿着密钥树路径的密钥，从叶子开始依次排列，最后到达组KEK。
This attribute is used to update the keys for a group. It is most likely to be included in a GROUPKEY-PUSH message KD payload to rekey the entire group. This attribute consists of a header block, followed by one or more LKH keys, as defined in the previous section.
此属性用于更新组的键。它很可能包含在GROUPKEY-PUSH消息KD有效负载中，以对整个组重新设置密钥。该属性由一个标题块组成，后面跟着一个或多个LKH键，如前一节中所定义。
There may be any number of UPDATE_ARRAY attributes included in a KD payload.
KD有效负载中可能包含任意数量的UPDATE_数组属性。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Version ! # of LKH Keys ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH ID ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Handle !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Keys !
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Version ! # of LKH Keys ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH ID ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Handle !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Keys !
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13. LKH Update Array
图13。LKH更新数组
o LKH version (1 octet) -- Version of the LKH data format. Must be one.
o LKH版本（1个八位字节）——LKH数据格式的版本。一定是一个。
o Number of LKH Keys (2 octets) -- Number of distinct LKH keys in this sequence.
o LKH键数（2个八位字节）——此序列中不同的LKH键数。
o RESERVED (1 octet) -- Unused; set to zero.
o 保留（1个八位组）——未使用；设置为零。
o LKH ID (2 octets) -- Node identifier associated with the key used to encrypt the first LKH Key.
o LKH ID（2个八位字节）——与用于加密第一个LKH密钥的密钥相关联的节点标识符。
o RESERVED2 (2 octets) -- Unused; set to zero.
o 保留2（2个八位字节）——未使用；设置为零。
o Key Handle (4 octets) -- Value assigned by the GCKS to uniquely identify the key within the LKH ID used to encrypt the first LKH Key.
o 密钥句柄（4个八位字节）——GCK分配的值，用于唯一标识用于加密第一个LKH密钥的LKH ID内的密钥。
The LKH Keys are as defined in the previous section. The LKH Key structures contain keys along the path of the key tree in order from the LKH ID found in the LKH_UPDATE_ARRAY header, culminating in the group KEK. The Key Data field of each LKH Key is encrypted with the LKH key preceding it in the LKH_UPDATE_ARRAY attribute. The first LKH Key is encrypted under the key defined by the LKH ID and Key Handle found in the LKH_UPDATE_ARRAY header.
LKH键如前一节所述。LKH密钥结构包含沿着密钥树路径的密钥，顺序从LKH_UPDATE_数组头中找到的LKH ID开始，最后到达组KEK。每个LKH密钥的密钥数据字段使用LKH_UPDATE_数组属性中其前面的LKH密钥进行加密。第一个LKH密钥根据LKH ID和LKH_UPDATE_数组头中的密钥句柄定义的密钥进行加密。
The SIG_ALGORITHM_KEY class declares that the public key for this SPI is contained in the Key Packet Attribute, which may be useful when no public key infrastructure is available. The signature algorithm that will use this key was specified in the SAK payload.
SIG_ALGORITHM_KEY类声明此SPI的公钥包含在KEY Packet属性中，这在没有可用的公钥基础结构时可能很有用。将使用此密钥的签名算法在SAK有效负载中指定。
This attribute is used to download one or more Sender-ID (SID) values for the exclusive use of a group member.
此属性用于下载一个或多个发件人ID（SID）值以供组成员独占使用。
The SID Download Type does not require an SPI. When the KD Type is SID, the SPI Size field MUST be zero, and the SPI field is omitted.
SID下载类型不需要SPI。当KD类型为SID时，SPI大小字段必须为零，并且省略SPI字段。
SID Class Value Type
--------- ----- ----
RESERVED 0
NUMBER_OF_SID_BITS 1 B
SID_VALUE 2 V
Unassigned 3-128
Private Use 129-255
Unassigned 256-32767
SID Class Value Type
--------- ----- ----
RESERVED 0
NUMBER_OF_SID_BITS 1 B
SID_VALUE 2 V
Unassigned 3-128
Private Use 129-255
Unassigned 256-32767
Because a SID value is intended for a single group member, the SID Download type MUST NOT be distributed in a GROUPKEY-PUSH message distributed to multiple group members.
由于SID值适用于单个组成员，因此SID下载类型不得在分发给多个组成员的GROUPKEY-PUSH消息中分发。
The NUMBER_OF_SID_BITS class declares how many bits of the cipher nonce in which to represent a SID value. This value is applied to each SID value distributed in the SID Download.
类的NUMBER\u OF_SID\u BITS声明表示SID值的密码nonce的位数。此值应用于SID下载中分发的每个SID值。
The SID_VALUE class declares a single SID value for the exclusive use of the group member. Multiple SID_VALUE attributes MAY be included in a SID Download.
SID_VALUE类声明一个SID值供组成员独占使用。SID下载中可能包含多个SID_值属性。
The SID_VALUE attribute value distributed to the group member MUST be used by that group member as the SID field portion of the IV for all Data-Security SAs including a counter-based mode of operation distributed by the GCKS as a part of this group.
分配给该组成员的SID_值属性值必须由该组成员用作所有数据安全SA的IV的SID字段部分，包括GCKS作为该组一部分分配的基于计数器的操作模式。
When the Sender-Specific IV (SSIV) field for any Data-Security SA is exhausted, the group member MUST no longer act as a sender on that SA using its active SID. The group member SHOULD re-register, at which time the GCKS will issue a new SID to the group member, along with either the same Data-Security SAs or replacement ones. The new SID replaces the existing SID used by this group member and also resets the SSIV value to its starting value. A group member MAY re-register prior to the actual exhaustion of the SSIV field to avoid dropping data packets due to the exhaustion of available SSIV values combined with a particular SID value.
当任何数据安全SA的特定于发件人的IV（SSIV）字段用尽时，组成员不得再使用其活动SID在该SA上充当发件人。该组成员应重新注册，此时GCKS将向该组成员发出新的SID，以及相同的数据安全SA或替换SA。新SID将替换此组成员使用的现有SID，并将SSIV值重置为其起始值。组成员可以在实际耗尽SSIV字段之前重新注册，以避免由于耗尽可用SSIV值和特定SID值而丢弃数据包。
GROUPKEY-PUSH message may include Data-Security SAs that are distributed to the group member for the first time. A SID previously issued to the receiving group member is used with counter-based mode of operation Data-Security SAs on which the group member acts as a sender. Because this Data-Security SA has not previously been used for transmission, the SSIV field should be set to its starting value.
GROUPKEY-PUSH消息可能包括首次分发给组成员的数据安全SA。先前发给接收组成员的SID与基于计数器的操作模式数据安全SAs一起使用，该组成员作为发送方。由于此数据安全SA以前未用于传输，因此SSIV字段应设置为其起始值。
If any KD payload includes keying material that is associated with a counter-mode of operation, a SID Download Type KD payload containing at least one SID_VALUE attribute MUST be included.
如果任何KD有效载荷包括与计数器操作模式相关联的键控材料，则必须包括包含至少一个SID_值属性的SID下载类型KD有效载荷。
The GCKS MUST NOT send the SID Download Type KD payload as part of a GROUPKEY-PUSH message because distributing the same sender-specific policy to more than one group member will reduce the security of the group.
GCKS不得将SID下载类型KD有效负载作为GROUPKEY-PUSH消息的一部分发送，因为将同一发件人特定策略分发给多个组成员会降低组的安全性。
The Sequence Number (SEQ) Payload provides an anti-replay protection for GROUPKEY-PUSH messages. Its use is similar to the Sequence Number field defined in the IPsec ESP protocol [RFC4303].
序列号（SEQ）有效负载为GROUPKEY-PUSH消息提供防重播保护。它的使用类似于IPsec ESP协议[RFC4303]中定义的序列号字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sequence Number !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sequence Number !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14. Sequence Number Payload
图14。序列号有效载荷
The Sequence Number Payload fields are defined as follows:
序列号有效载荷字段定义如下：
o Next Payload (1 octet) -- Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be zero.
o 下一个有效负载（1个八位字节）——消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为零。
o RESERVED (1 octet) -- Unused; set to zero.
o 保留（1个八位组）——未使用；设置为零。
o Payload Length (2 octets) -- Length in octets of the current payload, including the generic payload header. MUST be a value of 8.
o 有效负载长度（2个八位字节）——当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。值必须为8。
o Sequence Number (4 octets) -- This field contains a monotonically increasing counter value for the group. It is initialized to zero by the GCKS and incremented in each subsequently transmitted message. Thus, the first packet sent for a given Rekey SA will have a Sequence Number of 1. The GDOI implementation keeps a sequence counter as an attribute for the Rekey SA and increments the counter upon receipt of a GROUPKEY-PUSH message. The current value of the sequence number MUST be transmitted to group members as a part of the Registration SA payload.
o 序列号（4个八位字节）——此字段包含组的单调递增计数器值。GCKS将其初始化为零，并在随后发送的每条消息中递增。因此，为给定密钥SA发送的第一个分组将具有序列号1。GDOI实现保留一个序列计数器作为Rekey SA的属性，并在收到GROUPKEY-PUSH消息时增加计数器。序列号的当前值必须作为注册SA有效载荷的一部分传输给组成员。
The data portion of the Nonce payload (i.e., Ni_b and Nr_b included in the HASHs) MUST be a value between 8 and 128 octets.
Nonce有效负载的数据部分（即散列中包含的Ni_b和Nr_b）必须是8到128个八位字节之间的值。
There are times the GCKS may want to signal to receivers to delete SAs, for example, at the end of a broadcast. Deletion of keys may be accomplished by sending an ISAKMP Delete payload (Section 3.15 of [RFC2408]) as part of a GDOI GROUPKEY-PUSH message.
有时，GCK可能希望向接收机发送信号，以删除SAs，例如，在广播结束时。可以通过发送ISAKMP删除有效载荷（RFC2408第3.15节）作为GDOI GROUPKEY-PUSH消息的一部分来完成密钥的删除。
One or more Delete payloads MAY be placed following the SEQ payload in a GROUPKEY-PUSH message. If a GCKS has no further SAs to send to group members, the SA and KD payloads MUST be omitted from the message.
在GROUPKEY-PUSH消息中，可以将一个或多个删除有效载荷放置在SEQ有效载荷之后。如果GCKS没有更多SA发送给组成员，则必须从消息中忽略SA和KD有效载荷。
The following fields of the Delete payload are further defined as follows:
删除有效负载的以下字段进一步定义如下：
o The Domain of Interpretation field contains the GDOI DOI.
o 解释域字段包含GDOI DOI。
o The Protocol-ID field contains TEK protocol ID values defined in Section 5.5 of this document. To delete a KEK SA, the value of zero MUST be used as the protocol ID. Note that only one protocol ID value can be defined in a Delete payload. Thus, if a TEK SA and a KEK SA are to be deleted, their SPI values MUST be sent in different Delete payloads.
o 协议ID字段包含本文件第5.5节中定义的TEK协议ID值。要删除KEK SA，必须将0的值用作协议ID。请注意，在删除有效负载中只能定义一个协议ID值。因此，如果要删除TEK SA和KEK SA，则必须在不同的删除有效负载中发送它们的SPI值。
There may be circumstances where the GCKS may want to start over with a clean slate. If the administrator is no longer confident in the integrity of the group, the GCKS can signal deletion of all policy of a particular TEK protocol by sending a TEK with an SPI value equal to zero in the delete payload. For example, if the GCKS wishes to remove all the KEKs and all the TEKs in the group, the GCKS SHOULD send a delete payload with an SPI of zero and a Protocol-ID of a TEK Protocol-ID value, followed by another delete payload with an SPI value of zero and Protocol-ID of zero, indicating that the KEK SA should be deleted.
在某些情况下，GCK可能希望重新开始。如果管理员对组的完整性不再有信心，则GCKS可以通过发送删除有效负载中SPI值等于零的TEK来发出删除特定TEK协议的所有策略的信号。例如，如果GCKS希望删除组中的所有KEK和所有TEK，则GCKS应发送SPI为零、协议ID为TEK协议ID值的删除有效负载，然后发送SPI值为零、协议ID为零的另一个删除有效负载，指示应删除KEK SA。
For GDOI implementations to interoperate, they must support one or more security algorithms in common. This section specifies the security algorithm implementation requirements for standards-conformant GDOI implementations. In all cases, the choices are intended to maintain at least 112 bits of security [SP.800-131].
为了使GDOI实现能够互操作，它们必须共同支持一个或多个安全算法。本节规定了符合标准的GDOI实现的安全算法实现要求。在所有情况下，这些选择都旨在保持至少112位的安全性[SP.800-131]。
Algorithms not referenced in this section MAY be used.
可使用本节未提及的算法。
These tables list the algorithm selections for values related to the
KEK.
Requirement KEK Management Algorithm
----------- ---------------------
SHOULD LKH
These tables list the algorithm selections for values related to the
KEK.
Requirement KEK Management Algorithm
----------- ---------------------
SHOULD LKH
Requirement KEK Algorithm (notes)
----------- ---------------------
MUST KEK_ALG_AES with 128-bit keys
SHOULD NOT KEK_ALG_DES (1)
Requirement KEK Algorithm (notes)
----------- ---------------------
MUST KEK_ALG_AES with 128-bit keys
SHOULD NOT KEK_ALG_DES (1)
Requirement KEK Signature Hash Algorithm (notes)
----------- ------------------------------------
MUST SIG_HASH_SHA256
SHOULD SIG_HASH_SHA1 (2)
SHOULD NOT SIG_HASH_MD5 (3)
Requirement KEK Signature Hash Algorithm (notes)
----------- ------------------------------------
MUST SIG_HASH_SHA256
SHOULD SIG_HASH_SHA1 (2)
SHOULD NOT SIG_HASH_MD5 (3)
Requirement KEK Signature Algorithm (notes)
----------- -------------------------------
MUST SIG_ALG_RSA with 2048-bit keys
Requirement KEK Signature Algorithm (notes)
----------- -------------------------------
MUST SIG_ALG_RSA with 2048-bit keys
Notes:
笔记：
(1) DES, with its small key size and corresponding security strength, is of questionable security for general use
(1) DES密钥大小小，安全性强，一般使用安全性有问题
(2) The use of SIG_HASH_SHA1 as a signature hash algorithm used with GROUPKEY-PUSH messages remains safe at the time of this writing, and it is a widely deployed signature hash algorithm.
(2) 在撰写本文时，使用SIG_HASH_SHA1作为用于GROUPKEY-PUSH消息的签名哈希算法仍然是安全的，它是一种广泛部署的签名哈希算法。
(3) Although a real weakness with second preimage resistance with MD5 has not been found at the time of this writing, the security strength of MD5 has been shown to be rapidly declining over time, and its use should be understood and carefully weighed.
(3) 尽管在撰写本文时还没有发现MD5的第二个前像抵抗的真正弱点，但MD5的安全强度已被证明随着时间的推移而迅速下降，应该理解并仔细权衡它的使用。
The following table lists the requirements for Security Protocol support for an implementation.
下表列出了实现的安全协议支持要求。
Requirement KEK Management Algorithm
----------- ---------------------
MUST GDOI_PROTO_IPSEC_ESP
Requirement KEK Management Algorithm
----------- ---------------------
MUST GDOI_PROTO_IPSEC_ESP
GDOI is a security association (SA) management protocol for groups of senders and receivers. This protocol performs authentication of communicating protocol participants (Group Member, Group Controller/ Key Server). It provides confidentiality of key management messages, and it provides source authentication of those messages. GDOI includes defenses against man-in-middle, connection hijacking, replay, reflection, and denial-of-service (DoS) attacks on unsecured networks. GDOI assumes the network is not secure and may be under the complete control of an attacker.
GDOI是针对发送方和接收方组的安全关联（SA）管理协议。此协议执行通信协议参与者（组成员、组控制器/密钥服务器）的身份验证。它提供密钥管理消息的机密性，并提供这些消息的源身份验证。GDOI包括对中间人、连接劫持、重播、反射和对不安全网络的拒绝服务（DoS）攻击的防御。GDOI假设网络不安全，可能完全处于攻击者的控制之下。
GDOI assumes that the group members and GCKS are secure even though the network is insecure. GDOI ultimately establishes keys among members of a group, which MUST be trusted to use those keys in an authorized manner according to group policy. A GDOI entity compromised by an attacker may reveal the secrets necessary to eavesdrop on group traffic and/or take the identity of a group sender, so host security measures mitigating unauthorized access are of the utmost importance. The latter threat could be mitigated by using source origin authentication in the Data-Security SAs (e.g., the use of RSA signatures [RFC4359] or TESLA [RFC4082]). The choice of Data-Security SAs is a matter of group policy and is not within the scope of this memo.
GDOI假设组成员和GCK是安全的，即使网络不安全。GDOI最终在组成员之间建立密钥，必须信任组成员才能根据组策略以授权的方式使用这些密钥。被攻击者破坏的GDOI实体可能会泄露窃听组流量和/或获取组发送方身份所需的秘密，因此，主机安全措施对于减少未经授权的访问至关重要。后一种威胁可以通过在数据安全SAs中使用源站身份验证来缓解（例如，使用RSA签名[RFC4359]或特斯拉[RFC4082]）。选择数据安全SAs是集团政策的问题，不在本备忘录的范围内。
There are three phases of GDOI as described in this document: an ISAKMP Phase 1 protocol, the GROUPKEY-PULL exchange protected by the ISAKMP Phase 1 protocol, and the GROUPKEY-PUSH message. Each phase is considered separately below.
本文档中描述的GDOI分为三个阶段：ISAKMP第1阶段协议、受ISAKMP第1阶段协议保护的GROUPKEY-PULL交换和GROUPKEY-PUSH消息。下面分别考虑每个阶段。
GDOI uses the Phase 1 exchanges defined in [RFC2409] to protect the GROUPKEY-PULL exchange. Therefore, all security properties and considerations of those exchanges (as noted in [RFC2409]) are relevant for GDOI.
GDOI使用[RFC2409]中定义的第1阶段交换来保护GROUPKEY-PULL交换。因此，这些交易所的所有安全属性和考虑事项（如[RFC2409]中所述）与GDOI相关。
GDOI may inherit the problems of its ancestor protocols, such as identity exposure, absence of unidirectional authentication, or stateful cookies [PK01].
GDOI可能继承其祖先协议的问题，如身份暴露、缺少单向身份验证或有状态cookie[PK01]。
Authentication is provided via the mechanisms defined in [RFC2409], namely pre-shared keys or public key encryption.
通过[RFC2409]中定义的机制提供身份验证，即预共享密钥或公钥加密。
Confidentiality is achieved in Phase 1 through a Diffie-Hellman exchange that provides keying material and through negotiation of encryption transforms.
在第1阶段，通过提供密钥材料的Diffie-Hellman交换和加密转换的协商实现机密性。
The Phase 1 protocol will be protecting encryption and integrity keys sent in the GROUPKEY-PULL protocol. The strength of the encryption used for Phase 1 SHOULD exceed that of the keys sent in the GROUPKEY-PULL protocol.
第1阶段协议将保护GROUPKEY-PULL协议中发送的加密和完整性密钥。第1阶段使用的加密强度应超过GROUPKEY-PULL协议中发送的密钥强度。
A successful man-in-the-middle or connection-hijacking attack foils entity authentication of one or more of the communicating entities during key establishment. GDOI relies on Phase 1 authentication to defeat man-in-the-middle attacks.
成功的中间人攻击或连接劫持攻击会在密钥建立期间挫败一个或多个通信实体的实体身份验证。GDOI依靠第1阶段身份验证来击败中间人攻击。
In a replay/reflection attack, an attacker captures messages between GDOI entities and subsequently forwards them to a GDOI entity. Replay and reflection attacks seek to gain information from a subsequent GDOI message response or seek to disrupt the operation of a GDOI member or GCKS entity. GDOI relies on the Phase 1 nonce mechanism in combination with a hash-based message authentication code to protect against the replay or reflection of previous key management messages.
在重播/反射攻击中，攻击者捕获GDOI实体之间的消息，然后将其转发给GDOI实体。重播和反射攻击试图从随后的GDOI消息响应中获取信息，或试图中断GDOI成员或GCKS实体的操作。GDOI依赖于第1阶段的nonce机制以及基于散列的消息身份验证代码，以防止重播或反射以前的密钥管理消息。
A DoS attacker sends messages to a GDOI entity to cause that entity to perform unneeded message authentication operations. GDOI uses the Phase 1 cookie mechanism to identify spurious messages prior to cryptographic hash processing. This is a "weak" form of DoS protection in that the GDOI entity must check for good cookies, which can be successfully imitated by a sophisticated attacker. The Phase 1 cookie mechanism is stateful and commits memory resources for cookies.
DoS攻击者向GDOI实体发送消息，使该实体执行不必要的消息身份验证操作。GDOI使用阶段1 cookie机制在加密哈希处理之前识别虚假消息。这是一种“弱”形式的DoS保护，因为GDOI实体必须检查良好的Cookie，成熟的攻击者可以成功模仿这些Cookie。阶段1 cookie机制是有状态的，并为cookie提交内存资源。
The GROUPKEY-PULL exchange allows a group member to request SAs and keys from a GCKS. It runs as a Phase 2 protocol under protection of the Phase 1 security association.
GROUPKEY-PULL交换允许组成员向GCKS请求SA和密钥。它作为第2阶段协议在第1阶段安全关联的保护下运行。
Peer authentication is not required in the GROUPKEY-PULL protocol. It is running in the context of the Phase 1 protocol, which has previously authenticated the identity of the peer.
GROUPKEY-PULL协议中不需要对等身份验证。它在第1阶段协议的上下文中运行，该协议先前已验证了对等方的身份。
Message authentication is provided by HASH payloads in each message, where the HASH is defined to be over SKEYID_a (derived in the Phase 1 exchange), the ISAKMP Message-ID, and all payloads in the message. Because only the two endpoints of the exchange know the SKEYID_a value, this provides confidence that the peer sent the message.
消息身份验证由每条消息中的散列有效负载提供，其中散列被定义为通过SKEYID_a（在阶段1交换中派生）、ISAKMP消息ID和消息中的所有有效负载。因为只有交换的两个端点知道SKEYID_a值，所以这提供了对等方发送消息的信心。
Confidentiality is provided by the Phase 1 security association, after the manner described in [RFC2409].
第1阶段安全协会按照[RFC2409]中描述的方式提供保密性。
Message authentication (described above) includes a secret known only to the group member and GCKS when constructing a HASH payload. This prevents man-in-the-middle and connection-hijacking attacks because an attacker would not be able to change the message undetected.
消息认证（如上所述）包括在构造散列负载时仅对组成员和gck已知的秘密。这可以防止中间人攻击和连接劫持攻击，因为攻击者无法在未被发现的情况下更改消息。
A GROUPKEY-PULL message identifies its messages using a cookie pair from the Phase 1 exchange that precedes it. A GROUPKEY-PULL message with invalid cookies will be discarded. Therefore, GDOI messages that are not associated with a current GDOI session will be discarded without further processing.
GROUPKEY-PULL消息使用其前面的阶段1交换中的cookie对来标识其消息。将丢弃包含无效Cookie的GROUPKEY-PULL消息。因此，不与当前GDOI会话关联的GDOI消息将被丢弃，而无需进一步处理。
Replayed GDOI messages that are associated with a current GDOI session will be decrypted and authenticated. The M-ID in the HDR identifies a session. Replayed packets will be processed according to the state machine of that session. Packets not matching that state machine will be discarded without processing.
与当前GDOI会话关联的重播GDOI消息将被解密和验证。HDR中的M-ID标识会话。重播的数据包将根据该会话的状态机进行处理。与该状态机不匹配的数据包将被丢弃而不进行处理。
GCKS implementations SHOULD keep a record of recently received GROUPKEY-PULL messages (e.g., a hash of the packet) and reject messages that have already been processed. This provides DoS and replay protection of previously sent messages. An implementation MAY choose to rate-limit the receipt of GDOI messages in order to mitigate overloading its computational resources.
GCKS实施应记录最近收到的GROUPKEY-PULL消息（例如，数据包的散列）和已处理的拒绝消息。这为以前发送的邮件提供DoS和重播保护。实现可以选择对GDOI消息的接收进行速率限制，以减轻其计算资源的过载。
The GCKS SHOULD NOT perform any computationally expensive tasks before receiving a HASH with its own nonce included. The GCKS MUST NOT update the group management state (e.g., LKH key tree, SID-counter) until it receives the third message in the exchange with a valid HASH payload including its own nonce.
GCK在收到包含自身nonce的哈希之前，不应执行任何计算开销大的任务。GCKS在收到交换中的第三条消息以及包含其自身nonce的有效哈希有效负载之前，不得更新组管理状态（例如，LKH密钥树、SID计数器）。
A GCKS implementation SHOULD maintain an authorization list of authorized group members. A group member MUST specifically list each authorized GCKS in its Group Peer Authorization Database (GPAD) [RFC5374].
GCKS实施应维护授权组成员的授权列表。集团成员必须在其集团对等授权数据库（GPAD）[RFC5374]中明确列出每个授权GCK。
The GROUPKEY-PUSH exchange is a single message that allows a GCKS to send SAs and keys to group members. This is likely to be sent to all members using an IP multicast group. This message provides an efficient rekey and group membership adjustment capability.
GROUPKEY-PUSH交换是允许GCKS向组成员发送SA和密钥的单一消息。这可能会发送给使用IP多播组的所有成员。此消息提供了有效的密钥更新和组成员资格调整功能。
The GROUPKEY-PULL exchange distributes a public key that is used for message authentication. The GROUPKEY-PUSH message is digitally signed using the corresponding private key held by the GCKS. This digital signature provides source authentication for the message. Thus, GDOI protects the GCKS from impersonation in group environments.
GROUPKEY-PULL exchange分发用于消息身份验证的公钥。GROUPKEY-PUSH消息使用GCKS持有的相应私钥进行数字签名。此数字签名为消息提供源身份验证。因此，GDOI保护GCK在组环境中不被模仿。
The GCKS encrypts the GROUPKEY-PUSH message with an encryption key that was distributed in the GROUPKEY-PULL exchange or a previous GROUPKEY-PUSH exchange. The encryption key may be a simple KEK or the result of a group management method (e.g., LKH) calculation.
GCKS使用在GROUPKEY-PULL交换或以前的GROUPKEY-PUSH交换中分发的加密密钥加密GROUPKEY-PUSH消息。加密密钥可以是简单的KEK或组管理方法（例如，LKH）计算的结果。
This combination of confidentiality and message authentication services protects the GROUPKEY-PUSH message from man-in-middle and connection-hijacking attacks.
这种保密性和消息身份验证服务的组合可保护GROUPKEY-PUSH消息免受中间人攻击和连接劫持攻击。
The GROUPKEY-PUSH message includes a monotonically increasing sequence number to protect against replay and reflection attacks. A group member will discard sequence numbers associated with the
GROUPKEY-PUSH消息包含一个单调递增的序列号，以防止重播和反射攻击。组成员将丢弃与组关联的序列号
current KEK SPI that have the same or lower value as the most recently received replay number.
与最近接收的重播号码具有相同或更低值的当前KEK SPI。
Implementations SHOULD keep a record (e.g., a hash value) of recently received GROUPKEY-PUSH messages and reject duplicate messages prior to performing cryptographic operations. This enables an early discard of the replayed messages.
实现应保留最近接收的GROUPKEY-PUSH消息的记录（例如哈希值），并在执行加密操作之前拒绝重复消息。这样可以提前放弃重播的消息。
A cookie pair identifies the security association for the GROUPKEY-PUSH message. The cookies thus serve as a weak form of DoS protection for the GROUPKEY-PUSH message.
cookie对标识GROUPKEY-PUSH消息的安全关联。因此，Cookie是GROUPKEY-PUSH消息的弱DoS保护形式。
The digital signature used for message authentication has a much greater computational cost than a message authentication code and could amplify the effects of a DoS attack on GDOI members who process GROUPKEY-PUSH messages. The added cost of digital signatures is justified by the need to prevent GCKS impersonation: If a shared symmetric key were used for GROUPKEY-PUSH message authentication, then GCKS source authentication would be impossible, and any member would be capable of GCKS impersonation.
用于消息身份验证的数字签名比消息身份验证代码具有更大的计算成本，并且可能会放大DoS攻击对处理GROUPKEY-PUSH消息的GDOI成员的影响。由于需要防止GCKS模拟，数字签名的额外成本是合理的：如果使用共享对称密钥进行GROUPKEY-PUSH消息身份验证，则不可能进行GCKS源身份验证，并且任何成员都可以进行GCKS模拟。
The potential of the digital signature amplifying a DoS attack is mitigated by the order of operations a group member takes, where the least expensive cryptographic operation is performed first. The group member first decrypts the message using a symmetric cipher. If it is a validly formed message, then the sequence number is checked against the most recently received sequence number. Only when the sequence number is valid (i.e., it is a larger value than previously received) is the digital signature verified and the message further processed. Thus, in order for a DoS attack to be mounted, an attacker would need to know both the symmetric encryption key used for confidentiality and a valid sequence number. Generally speaking, this means only current group members can effectively deploy a DoS attack.
数字签名放大DoS攻击的可能性通过组成员采取的操作顺序得到缓解，其中首先执行最便宜的加密操作。组成员首先使用对称密码解密消息。如果是有效格式的消息，则根据最近收到的序列号检查序列号。只有当序列号有效时（即，它的值大于先前接收的值），才能验证数字签名并进一步处理消息。因此，为了装载DoS攻击，攻击者需要知道用于保密的对称加密密钥和有效序列号。一般来说，这意味着只有当前组成员才能有效地部署DoS攻击。
Through GROUPKEY-PUSH, the GDOI supports group management methods such as LKH (Section 5.4 of [RFC2627]) that have the property of denying access to a new group key by a member removed from the group (forward access control) and to an old group key by a member added to the group (backward access control). The concepts "forward access control" and "backward access control" have also been described as "perfect forward security" and "perfect backward security", respectively, in the literature [RFC2627].
通过GROUPKEY-PUSH，GDOI支持LKH（RFC2627第5.4节）等组管理方法，该方法具有拒绝从组中删除的成员访问新组密钥（前向访问控制）和添加到组中的成员访问旧组密钥（后向访问控制）的特性。在文献[RFC2627]中，“前向访问控制”和“后向访问控制”的概念也分别被描述为“完美前向安全”和“完美后向安全”。
Group management algorithms providing forward and backward access control other than LKH have been proposed in the literature, including one-way function trees [OFT] and Subset Difference [NNL]. These algorithms could be used with GDOI, but are not specified as a part of this document.
文献中已经提出了除LKH之外提供前向和后向访问控制的组管理算法，包括单向函数树[OFT]和子集差分[NNL]。这些算法可与GDOI一起使用，但未作为本文档的一部分指定。
When group membership is altered using a group management algorithm, new Data-Security SAs are usually also needed. New SAs ensure that members who were denied access can no longer participate in the group.
当使用组管理算法更改组成员身份时，通常还需要新的数据安全SA。新SA确保被拒绝访问的成员不能再参与组。
If forward access control is a desired property of the group, new Data-Security SAs MUST NOT be included in a GROUPKEY-PUSH message that changes group membership. This is required because the new Data-Security SAs are not protected with the new KEK. Instead, two sequential GROUPKEY-PUSH messages must be sent by the GCKS; the first changing the KEK, and the second (protected with the new KEK) distributing the new Data-Security SAs.
如果前向访问控制是组的所需属性，则更改组成员资格的GROUPKEY-PUSH消息中不得包含新的数据安全SA。这是必需的，因为新的数据安全SA不受新KEK的保护。相反，GCK必须发送两条连续的GROUPKEY-PUSH消息；第一个更改KEK，第二个（受新KEK保护）分发新的数据安全SAs。
Note that in the above sequence, although the new KEK can effectively deny access to the group to some group members, they will be able to view the new KEK policy. If forward access control policy for the group includes keeping the KEK policy secret as well as the KEK itself secret, then two GROUPKEY-PUSH messages changing the KEK must occur before the new Data-Security SAs are transmitted.
请注意，在上述序列中，尽管新的KEK可以有效地拒绝某些组成员访问该组，但他们将能够查看新的KEK策略。如果组的前向访问控制策略包括保留KEK策略机密以及KEK本身机密，则在传输新的数据安全SAs之前，必须发生两条更改KEK的GROUPKEY-PUSH消息。
If other methods of using LKH or other group management algorithms are added to GDOI, those methods MAY remove the above restrictions requiring multiple GROUPKEY-PUSH messages, providing those methods specify how forward access control policy is maintained within a single GROUPKEY-PUSH message.
如果将使用LKH或其他组管理算法的其他方法添加到GDOI中，则这些方法可以删除需要多个GROUPKEY-PUSH消息的上述限制，前提是这些方法指定如何在单个GROUPKEY-PUSH消息中维护前向访问控制策略。
If backward access control is a desired property of the group, a new member MUST NOT be given Data-Security SAs that were used prior to its joining the group. This can be accomplished if the GCKS provides only the Rekey SA to the new member in a GROUPKEY-PULL exchange, followed by a GROUPKEY-PUSH message that both deletes current Data-Security SAs and provides new replacement Data-Security SAs. The new group member will effectively join the group at such time as the existing members begin sending on the Data-Security SAs.
如果向后访问控制是组的所需属性，则不得为新成员提供加入组之前使用的数据安全SA。如果GCKS在GROUPKEY-PULL交换中仅向新成员提供重新密钥SA，然后发送GROUPKEY-PUSH消息，删除当前数据安全SA并提供新的替换数据安全SA，则可以实现这一点。新组成员将在现有成员开始通过数据安全SAs发送数据时有效加入组。
If there is a possibility that the new group member has stored GROUPKEY-PUSH messages delivered prior to joining the group, then the above procedure is not sufficient. In this case, to achieve backward
如果新的组成员可能存储了在加入组之前传递的GROUPKEY-PUSH消息，则上述过程是不够的。在这种情况下，要实现向后
access control, the GCKS needs to return a new Rekey SA to the group member in a GROUPKEY-PULL exchange rather than the existing one. The GCKS would subsequently deliver two GROUPKEY-PUSH messages. The first, intended for existing group members, distributes the new Rekey SA to existing members. The GCKS would then deliver the second GROUPKEY-PUSH message using the new Rekey SA that both deletes current Data-Security SAs and provides new replacement Data-Security SAs. Both preexisting and new members would process the second GROUPKEY-PUSH message, and all would be able to communicate using the new Data-Security SAs.
访问控制，GCKS需要在GROUPKEY-PULL交换中向组成员返回新的密钥SA，而不是现有的密钥SA。GCK随后将发送两条GROUPKEY-PUSH消息。第一种是针对现有集团成员的，将新的重新注册SA分发给现有成员。然后，GCKS将使用新的Rekey SA传递第二个GROUPKEY-PUSH消息，该SA将删除当前的数据安全SA并提供新的替换数据安全SA。现有成员和新成员都将处理第二条GROUPKEY-PUSH消息，所有成员都将能够使用新的数据安全SAs进行通信。
A GCKS distributes keying material associated with Data-Security SAs and the Rekey SA. Because these security associations are used by a set of group members, this keying material is not related to any pair-wise connection, and there is no requirement in "The Multicast Group Security Architecture" [RFC3740] for group members to permute group keying material. Because the GCKS is solely responsible for the generation of the keying material, the GCKS MUST derive the keying material using a strong random number generator. Because there are no interoperability concerns with key generation, no method is prescribed in GDOI.
GCKS分发与数据安全SA和重新密钥SA相关的密钥材料。由于这些安全关联由一组组组成员使用，因此该密钥材料与任何成对连接无关，并且“多播组安全体系结构”[RFC3740]中不要求组成员排列组密钥材料。由于GCKS仅负责生成键控材料，因此GCKS必须使用强随机数生成器导出键控材料。由于密钥生成没有互操作性问题，因此GDOI中没有规定任何方法。
The GDOI KEK Attribute named SIG_HASH_ALGORITHM [GDOI-REG] has been assigned several new Algorithm Type values from the RESERVED space to represent the SHA-256, SHA-384, and SHA-512 hash algorithms as defined in [FIPS180-3.2008]. The new algorithm names are SIG_HASH_SHA256, SIG_HASH_SHA384, and SIG_HASH_SHA512, respectively, and have the values of 3, 4, and 5, respectively.
名为SIG_HASH_ALGORITHM[GDOI-REG]的GDOI KEK属性已从保留空间中分配了几个新的算法类型值，以表示[FIPS180-3.2008]中定义的SHA-256、SHA-384和SHA-512哈希算法。新算法名称分别为SIG_HASH_SHA256、SIG_HASH_SHA384和SIG_HASH_SHA512，其值分别为3、4和5。
The GDOI KEK Attribute named SIG_ALGORITHM [GDOI-REG] has been assigned several new Algorithm Type values from the RESERVED space to represent the SIG_ALG_ECDSA-256, SIG_ALG_ECDSA-384, and SIG_ALG_ECDSA-521 signature algorithms. The Algorithm Types values are 4, 5, and 6, respectively.
名为SIG_ALGORITHM[GDOI-REG]的GDOI KEK属性已从保留空间中分配了几个新的算法类型值，以表示SIG_ALG_ECDSA-256、SIG_ALG_ECDSA-384和SIG_ALG_ECDSA-521签名算法。算法类型值分别为4、5和6。
A new GDOI SA TEK type Protocol-ID type [GDOI-REG] has been assigned from the RESERVED space. The new algorithm ID is called GDOI_PROTO_IPSEC_AH, refers to the IPsec AH encapsulation, and has a value of 2.
已从保留空间分配了新的GDOI SA TEK类型协议ID类型[GDOI-REG]。新算法ID称为GDOI_PROTO_IPSEC_AH，指的是IPSEC AH封装，其值为2。
A new Next Payload Type [ISAKMP-REG] has been assigned. The new type is called "SA Group Associated Policy (GAP)" and has a value of 22.
已分配新的下一个有效负载类型[ISAKMP-REG]。新类型称为“SA组关联策略（GAP）”，其值为22。
A new Key Download Type Section 5.6 has been assigned. The new type is called "SID" and has a value of 4.
已分配第5.6节中的新密钥下载类型。新类型称为“SID”，其值为4。
A new registry identifying the possible values of GAP Payload Policy Attributes (of the form described in Section 3.3 of [RFC2408]) has been created in the GDOI Payloads registry [GDOI-REG]. This memo defines the following values for this registry:
在GDOI有效负载注册表[GDOI-REG]中创建了一个新的注册表，用于标识GAP有效负载策略属性的可能值（采用[RFC2408]第3.3节中所述的形式）。此备忘录定义了此注册表的以下值：
Attribute Type Value Type
---- ----- ----
RESERVED 0
ACTIVATION_TIME_DELAY 1 B
DEACTIVATION_TIME_DELAY 2 B
SENDER_ID_REQUEST 3 B
Unassigned 4-127
Private Use 128-255
Unassigned 256-32767
Attribute Type Value Type
---- ----- ----
RESERVED 0
ACTIVATION_TIME_DELAY 1 B
DEACTIVATION_TIME_DELAY 2 B
SENDER_ID_REQUEST 3 B
Unassigned 4-127
Private Use 128-255
Unassigned 256-32767
The registration procedure is Standards Action. The terms Standards Action and Private Use are to be applied as defined in [RFC5226].
注册程序是标准行动。按照[RFC5226]中的定义，应用术语“标准行动”和“私人使用”。
A new IPsec Security Association Attribute [ISAKMP-REG] defining the preservation of IP addresses has been registered. The attribute class is called "Address Preservation", and it is a Basic type. The following rules apply to define the values of the attribute:
已注册定义IP地址保留的新IPsec安全关联属性[ISAKMP-REG]。属性类称为“地址保留”，它是一种基本类型。以下规则适用于定义属性的值：
Name Value
---- -----
Reserved 0
None 1
Source-Only 2
Destination-Only 3
Source-and-Destination 4
Unassigned 5-61439
Private Use 61440-65535
Name Value
---- -----
Reserved 0
None 1
Source-Only 2
Destination-Only 3
Source-and-Destination 4
Unassigned 5-61439
Private Use 61440-65535
The registration procedure is Standards Action. The terms Standards Action and Private Use are to be applied as defined in [RFC5226].
注册程序是标准行动。按照[RFC5226]中的定义，应用术语“标准行动”和“私人使用”。
A new IPsec Security Association Attribute [ISAKMP-REG] defining the SA direction has been created. The attribute class is called "SA Direction", and it is a Basic type. The following rules apply to define the values of the attribute:
已创建定义SA方向的新IPsec安全关联属性[ISAKMP-REG]。属性类称为“SA方向”，它是一种基本类型。以下规则适用于定义属性的值：
Name Value
---- -----
Reserved 0
Sender-Only 1
Receiver-Only 2
Symmetric 3
Unassigned 4-61439
Private Use 61440-65535
Name Value
---- -----
Reserved 0
Sender-Only 1
Receiver-Only 2
Symmetric 3
Unassigned 4-61439
Private Use 61440-65535
The registration procedure is Standards Action. terms Standards Action and Private Use are to be applied as defined in [RFC5226].
注册程序是标准行动。按照[RFC5226]中的定义，应用术语标准行动和私人使用。
When the SID "Key Download Type" (described in the previous section) has a set of attributes, the attributes must follow the format defined in ISAKMP (Section 3.3 of [RFC2408]). In the table, attributes defined as TV are marked as Basic (B); attributes defined as TLV are marked as Variable (V).
当SID“密钥下载类型”（如前一节所述）具有一组属性时，这些属性必须遵循ISAKMP（RFC2408第3.3节）中定义的格式。在表中，定义为TV的属性标记为基本（B）；定义为TLV的属性标记为变量（V）。
SID Class Value Type
--------- ----- ----
RESERVED 0
NUMBER_OF_SID_BITS 1 B
SID_VALUE 2 V
Unassigned 3-128
Private Use 129-255
Unassigned 256-32767
SID Class Value Type
--------- ----- ----
RESERVED 0
NUMBER_OF_SID_BITS 1 B
SID_VALUE 2 V
Unassigned 3-128
Private Use 129-255
Unassigned 256-32767
The registration procedure is Standards Action. terms Standards Action and Private Use are to be applied as defined in [RFC5226].
注册程序是标准行动。按照[RFC5226]中的定义，应用术语标准行动和私人使用。
Several existing GDOI Payloads registries do not use the terms in RFC 5226 and/or do not describe the entire range of possible values. The following sections correct these registries. The terms Standards Action, Unassigned, and Private Use are to be applied as defined in [RFC5226].
几个现有的GDOI有效载荷注册中心未使用RFC 5226中的术语和/或未描述可能值的整个范围。以下各节更正了这些注册表。按照[RFC5226]中的定义，应用术语“标准行动”、“未分配”和“私人使用”。
The registration procedure is Standards Action. Values 4-27 are designated Unassigned. Values 256-32767 have been added and are designated Unassigned.
注册程序是标准行动。值4-27指定为未指定。已添加值256-32767，并指定为未分配值。
The registration procedure is Standards Action. Values 9-127 have been added and are designated Unassigned. Values 128-255 have been added and are designated Private Use. Values 256-32767 have been added and are designated Unassigned.
注册程序是标准行动。已添加值9-127，并指定为未指定值。已添加值128-255，并指定为专用。已添加值256-32767，并指定为未分配值。
The registration procedure is Standards Action. Values 2-127 are designated Unassigned. Values 128-255 have been added and designated Private Use. Values 256-65535 have been added and are designated Unassigned.
注册程序是标准行动。值2-127被指定为未赋值。已添加值128-255并指定为专用。已添加值256-65535，并指定为未分配值。
The registration procedure is Standards Action. Values 4-127 are designated Unassigned. Values 256-65535 have been added and are designated Unassigned.
注册程序是标准行动。值4-127被指定为未赋值。已添加值256-65535，并指定为未分配值。
The registration procedure is Standards Action. Values 6-127 are designated Unassigned. Values 256-65535 have been added and are designated Unassigned.
注册程序是标准行动。值6-127被指定为未赋值。已添加值256-65535，并指定为未分配值。
The registration procedure is Standards Action. Values 7-127 are designated Unassigned. Values 256-65535 have been added and are designated Unassigned.
注册程序是标准行动。值7-127被指定为未赋值。已添加值256-65535，并指定为未分配值。
The registration procedure is Standards Action. Values 3-127 are designated Unassigned.
注册程序是标准行动。值3-127指定为未指定。
The registration procedure is Standards Action. Values 5-127 are designated Unassigned.
注册程序是标准行动。值5-127被指定为未赋值。
The registration procedure is Standards Action. Values 4-127 have been added and are designated Unassigned. Values 128-255 have been added and are designated Private Use. Values 256-32767 have been added and are designated Unassigned.
注册程序是标准行动。已添加值4-127，并指定为未指定值。已添加值128-255，并指定为专用。已添加值256-32767，并指定为未分配值。
The registration procedure is Standards Action. Values 3-127 are designated Unassigned. Values 128-255 have been added and are designated Private Use. Values 256-32767 have been added and are designated Unassigned.
注册程序是标准行动。值3-127指定为未指定。已添加值128-255，并指定为专用。已添加值256-32767，并指定为未分配值。
The registration procedure is Standards Action. Values 4-127 are designated Unassigned. Values 256-32767 have been added and are designated Unassigned.
注册程序是标准行动。值4-127被指定为未赋值。已添加值256-32767，并指定为未分配值。
This memo replaces RFC 3547, and the authors wish to thank Mark Baugher and Hugh Harney for their extensive contributions that led to this newer specification of GDOI.
本备忘录取代RFC3547，作者希望感谢Mark Baugher和Hugh Harney的广泛贡献，他们的贡献导致了GDOI的新规范。
The authors are grateful to Catherine Meadows for her careful review and suggestions for mitigating the man-in-the-middle attack she had previously identified. Yoav Nir, Vincent Roca, Sean Turner, and Elwyn Davies provided many useful technical and editorial comments and suggestions for improvement.
作者感谢Catherine Meadows的仔细审查和建议，以减轻她先前确定的中间人攻击。Yoav Nir、Vincent Roca、Sean Turner和Elwyn Davies提供了许多有用的技术和编辑评论以及改进建议。
[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月。
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[RFC2403]Madson，C.和R.Glenn，“HMAC-MD5-96在ESP和AH中的使用”，RFC 2403，1998年11月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Schneider，M.和M.Schertler，“互联网安全协会和密钥管理协议（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月。
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[RFC2627]Wallner，D.，Harder，E.，和R.Agee，“多播的密钥管理：问题和架构”，RFC 2627，1999年6月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[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月。
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007.
[RFC4754]Fu，D.和J.Solinas，“使用椭圆曲线数字签名算法（ECDSA）的IKE和IKEv2认证”，RFC 4754，2007年1月。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC4868]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，2007年5月。
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
[RFC5374]Weis，B.，Gross，G.和D.Ignjatic，“互联网协议安全架构的多播扩展”，RFC 5374，2008年11月。
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010.
[RFC5903]Fu，D.和J.Solinas，“IKE和IKEv2的模素数的椭圆曲线群（ECP群）”，RFC 5903，2010年6月。
[RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic", RFC 6054, November 2010.
[RFC6054]McGrew，D.和B.Weis，“使用具有封装安全有效负载（ESP）和身份验证头（AH）的计数器模式来保护组流量”，RFC 60542010年11月。
[FIPS180-3.2008] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-3, October 2008, <http:// csrc.nist.gov/publications/fips/fips180-3/ fips180-3_final.pdf>.
[FIPS180-3.2008]国家标准与技术研究所，“安全哈希标准”，FIPS PUB 180-3，2008年10月，<http://csrc.nist.gov/publications/FIPS/FIPS180-3/FIPS180-3_final.pdf>。
[FIPS186-3] "Digital Signature Standard (DSS)", United States of America, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 186-2, June 2009.
[FIPS186-3]“数字签名标准（DSS）”，美国国家科学技术研究所，联邦信息处理标准（FIPS）186-21909年6月。
[FIPS197] "Advanced Encryption Standard (AES)", United States of America, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 197, November 2001.
[FIPS197]“高级加密标准（AES）”，美国国家科学技术研究所，联邦信息处理标准（FIPS）197，2001年11月。
[FIPS46-3] "Data Encryption Standard (DES)", United States of America, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 46-3, October 1999.
[FIPS46-3]“数据加密标准（DES）”，美国国家科学技术研究所，联邦信息处理标准（FIPS）46-3，1999年10月。
[FIPS81] "DES Modes of Operation", United States of America, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 81, December 1980.
[FIPS81]“DES操作模式”，美利坚合众国，国家科学技术研究所，联邦信息处理标准（FIPS）81，1980年12月。
[GDOI-REG] Internet Assigned Numbers Authority, "Group Domain of Interpretation (GDOI) Payload Type Values", IANA Registry, December 2004, <http://www.iana.org/assignments/gdoi-payloads>.
[GDOI-REG]互联网分配号码管理局，“集团解释域（GDOI）有效载荷类型值”，IANA注册，2004年12月<http://www.iana.org/assignments/gdoi-payloads>.
[HD03] Hardjono, T. and L. Dondeti, "Multicast and Group Security", Artech House Computer Security Series, ISBN 1-58053-342-6, 2003.
[HD03]Hardjono，T.和L.Dondeti，“多播和组安全”，Artech House计算机安全系列，ISBN 1-58053-342-62003。
[ISAKMP-REG] "'Magic Numbers' for ISAKMP Protocol", <http://www.iana.org/assignments/isakmp-registry>.
[ISAKMP-REG]“‘魔法数字’用于ISAKMP协议”<http://www.iana.org/assignments/isakmp-registry>.
[MP04] Meadows, C. and D. Pavlovic, "Deriving, Attacking, and Defending the GDOI Protocol", European Symposium on Research in Computer Security (ESORICS) 2004, pp. 53-72, September 2004.
[MP04]Meadows，C.和D.Pavlovic，“推导、攻击和捍卫GDOI协议”，2004年欧洲计算机安全研究研讨会（ESORICS），第53-72页，2004年9月。
[NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and Tracing Schemes for Stateless Receivers", Advances in Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001, pp. 41-62, 2001, <http://www.iacr.org/archive/crypto2001/21390040.pdf>.
[NNL]Naor，D.，Noal，M.，和J.Lotspiech，“无状态接收者的撤销和跟踪方案”，密码学进展，Crypto'01，Springer Verlag LNCS 21392001，第41-622001页<http://www.iacr.org/archive/crypto2001/21390040.pdf>.
[OFT] Sherman, A. and D. McGrew, "Key Establishment in Large Dynamic Groups Using One-Way Function Trees", IEEE Transactions on Software Engineering, Vol. 29, Issue 5, pp. 444-458, May 2003, <http://ieeexplore.ieee.org/search/ freesrchabstract.jsp?tp=&arnumber=1199073>.
[OFT]Sherman，A.和D.McGrew，“使用单向函数树在大型动态组中建立密钥”，IEEE软件工程学报，第29卷，第5期，第444-458页，2003年5月<http://ieeexplore.ieee.org/search/ jsp？tp=&arnumber=1199073>。
[PK01] Perlman, R. and C. Kaufman, "Analysis of the IPsec Key Exchange Standard", Enabling Technologies: Infrastructure for Collaborative Enterprises, WET ICE 2001, Proceedings. Tenth IEEE International Workshops on IEEE Transactions on Software Engineering, pp. 150-156, June 2001, <http://ieeexplore.ieee.org/search/ freesrchabstract.jsp?tp=&arnumber=953405>.
[PK01]Perlman，R.和C.Kaufman，“IPsec密钥交换标准的分析”，使能技术：协作企业的基础设施，湿冰2001，论文集。第十届IEEE软件工程国际研讨会，第150-156页，2001年6月<http://ieeexplore.ieee.org/search/ jsp？tp=&arnumber=953405>。
[PROT-REG] "Assigned Internet Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers/>.
[PROT-REG]“指定的互联网协议编号”<http://www.iana.org/assignments/protocol-numbers/>.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效负载（ESP）”，RFC 3686，2004年1月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740]Hardjono，T.和B.Weis，“多播组安全架构”，RFC 3740，2004年3月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005.
[RFC4046]Baugher，M.，Canetti，R.，Dondeti，L.，和F.Lindholm，“多播安全（MSEC）组密钥管理体系结构”，RFC 4046，2005年4月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082]Perrig，A.，Song，D.，Canetti，R.，Tygar，J.，和B.Briscoe，“定时高效流丢失容忍认证（TESLA）：多播源认证转换介绍”，RFC 40822005年6月。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年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月。
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
[RFC4359]Weis，B.“在封装安全有效载荷（ESP）和身份验证头（AH）中使用RSA/SHA-1签名”，RFC 4359，2006年1月。
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
[RFC4543]McGrew，D.和J.Viega，“Galois消息认证码（GMAC）在IPsec ESP和AH中的使用”，RFC 4543，2006年5月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[SP.800-131] Barker, E. and A. Roginsky, "Recommendation for the Transitioning of Cryptographic Algorithms and Key Lengths", United States of America, National Institute of Science and Technology, DRAFT NIST Special Publication 800-131, June 2010.
[SP.800-131]Barker，E.和A.Roginsky，“密码算法和密钥长度转换建议”，美利坚合众国，国家科学技术研究院，NIST特别出版物草案800-131，2010年6月。
[SP.800-38A] Dworkin, M., "Recommendation for Block Cipher Modes of Operation", United States of America, National Institute of Science and Technology, NIST Special Publication 800-38A 2001 Edition, December 2001.
[SP.800-38A]Dworkin，M.，“分组密码操作模式的建议”，美国国家科学技术研究院，NIST特别出版物800-38A 2001年版，2001年12月。
GDOI can be used to distribute keys for several secure multicast applications, where different applications have different key management requirements. This section outlines two examples of ways that GDOI can be used. Other examples can be found in Section 10 of [HD03].
GDOI可用于为多个安全多播应用程序分发密钥，其中不同的应用程序具有不同的密钥管理要求。本节概述了使用GDOI的两个示例。其他示例见[HD03]第10节。
A simple application is secure delivery of periodic multicast content over an organization's IP network, perhaps a multicast video broadcast. Assuming the content delivery time frame is bounded and the group membership is not expected to change over time, there is no need for group policy to include a GROUPKEY-PUSH exchange, and there is no need for the GCKS to distribute a Rekey SA. Thus, the GDOI GCKS may only need to distribute a single set of Data-Security SAs to protect the time-bounded broadcast.
一个简单的应用是通过组织的IP网络（可能是多播视频广播）安全地定期交付多播内容。假设内容交付时间范围是有限制的，并且组成员资格预计不会随时间而改变，则组策略不需要包括GROUPKEY-PUSH交换，GCK也不需要分发Rekey SA。因此，GDOI GCK可能只需要分发一组数据安全SA来保护有时间限制的广播。
In contrast, a persistent IP multicast application (e.g., stock-ticker delivery service) may have many group members, where the group membership changes over time. A periodic change of Data-Security SAs may be desirable, and the potential for change in group membership requires the use of a group management method enabling de-authorization of group members. The GDOI GCKS will distribute the current set of Data-Security SAs and a Rekey SA to registering group members. It will then use regularly scheduled GROUPKEY-PUSH exchanges to deliver the new SAs for the group. Additionally, the group membership on the GCKS may be frequently adjusted, which will result in a GROUPKEY-PUSH exchange that delivers new Rekey SAs protected by a group management method. Each GROUPKEY-PUSH may include Data-Security SAs and/or a Rekey SA.
相反，持久性IP多播应用程序（例如，股票行情交付服务）可能有许多组成员，其中组成员随时间而变化。可能需要定期更改数据安全SA，并且可能更改组成员资格需要使用组管理方法来取消组成员的授权。GDOI GCKS将向注册的组成员分发当前的一组数据安全SA和一个密钥更新SA。然后，它将使用定期安排的GROUPKEY-PUSH交换为该组交付新的SA。此外，GCK上的组成员资格可能会经常调整，这将导致GROUPKEY-PUSH交换，该交换提供受组管理方法保护的新的密钥SA。每个GROUPKEY-PUSH可包括数据安全SA和/或重新密钥SA。
In each example, the relevant policy is defined on the GCKS and relayed to group members using the GROUPKEY-PULL and/or GROUPKEY-PUSH protocols. Specific policy choices configured by the GCKS administrator depend on each application.
在每个示例中，相关策略在GCK上定义，并使用GROUPKEY-PULL和/或GROUPKEY-PUSH协议转发给组成员。GCKS管理员配置的特定策略选择取决于每个应用程序。
The following significant changes have been made from RFC 3547.
RFC 3547做出了以下重大变更。
o The Proof of Possession (POP) payload was removed from the GROUPKEY-PULL exchange. It provided an alternate form of authorization, but its use was underspecified. Furthermore, Meadows and Pavlovic [MP04] discussed a man-in-the-middle attack on the POP authorization method, which would require changes to its semantics. No known implementation of RFC 3547 supported the
o 已从GROUPKEY-PULL交换中删除占有证明（POP）有效负载。它提供了另一种授权形式，但它的使用没有明确规定。此外，Meadows和Pavlovic[MP04]讨论了对POP授权方法的中间人攻击，这需要更改其语义。没有已知的RFC 3547实现支持
POP payload, so it was removed. Removal of the POP payload obviated the need for the CERT payload in that exchange, and it was removed as well.
弹起有效载荷，所以它被移除了。POP有效载荷的移除消除了该交换中对CERT有效载荷的需要，并且它也被移除。
o The Key Exchange payloads (KE_I, KE_R) were removed from the GROUPKEY-PULL exchange. However, the specification for computing keying material for the additional encryption function in RFC 3547 is faulty. Furthermore, it has been observed that because the GDOI registration message uses strong ciphers and provides authenticated encryption, additional encryption of the keying material in a GDOI registration message provides negligible value. Therefore, the use of KE payloads is deprecated in this memo.
o 密钥交换有效载荷（keu I，keu R）已从GROUPKEY-PULL交换中移除。然而，RFC3547中用于计算附加加密功能的密钥材料的规范是错误的。此外，已经观察到，由于GDOI注册消息使用强密码并提供经认证的加密，因此GDOI注册消息中的密钥材料的附加加密提供的值可以忽略不计。因此，本备忘录不推荐使用KE有效载荷。
o The Certificate Payload (CERT) was removed from the GROUPKEY-PUSH exchange. The use of this payload was underspecified. In all known use cases, the public key used to verify the GROUPKEY-PUSH payload is distributed directly from the key server as part of the GROUPKEY-PULL exchange.
o 证书有效负载（CERT）已从GROUPKEY-PUSH exchange中删除。该有效载荷的使用未指定。在所有已知的用例中，用于验证GROUPKEY-PUSH有效负载的公钥作为GROUPKEY-PULL交换的一部分直接从密钥服务器分发。
o Supported cryptographic algorithms were changed to meet current guidance. Implementations are required to support AES with 128-bit keys to encrypt the rekey message and support SHA-256 for cryptographic signatures. The use of DES is deprecated.
o 支持的加密算法已更改，以满足当前的指导。实现需要支持具有128位密钥的AES来加密重密钥消息，并支持用于加密签名的SHA-256。不推荐使用DES。
o New protocol support for AH.
o 对AH的新协议支持。
o New protocol definitions were added to conform to the most recent "Security Architecture for the Internet Protocol" [RFC4301] and the "Multicast Extensions to the Security Architecture for the Internet Protocol" [RFC5374]. This includes addition of the GAP payload.
o 添加了新的协议定义，以符合最新的“互联网协议安全架构”[RFC4301]和“互联网协议安全架构的多播扩展”[RFC5374]。这包括增加间隙有效载荷。
o New protocol definitions and semantics were added to support "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic" [RFC6054].
o 添加了新的协议定义和语义，以支持“使用带有封装安全负载（ESP）和身份验证头（AH）的计数器模式来保护组流量”[RFC6054]。
o Specification to IANA was added to better clarify the use of the GDOI Payloads registry.
o 添加IANA规范是为了更好地阐明GDOI有效载荷注册中心的使用。
Authors' Addresses
作者地址
Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA
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
Sheela Rowles Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA
美国加利福尼亚州圣何塞塔斯曼大道西170号希拉·罗尔斯思科系统公司95134-1706
Phone: +1-408-527-7677
EMail: sheela@cisco.com
Phone: +1-408-527-7677
EMail: sheela@cisco.com
Thomas Hardjono MIT 77 Massachusetts Ave. Cambridge, Massachusetts 02139 USA
美国马萨诸塞州剑桥市马萨诸塞大道77号麻省理工学院托马斯·哈德乔诺邮编02139
Phone: +1-781-729-9559
EMail: hardjono@mit.edu
Phone: +1-781-729-9559
EMail: hardjono@mit.edu