Network Working Group M. Baugher
Request for Comments: 3547 B. Weis
Category: Standards Track Cisco
T. Hardjono
Verisign
H. Harney
Sparta
July 2003
Network Working Group M. Baugher
Request for Comments: 3547 B. Weis
Category: Standards Track Cisco
T. Hardjono
Verisign
H. Harney
Sparta
July 2003
The Group Domain of Interpretation
解释的群体域
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members.
本文档介绍用于组密钥管理的ISAMKP解释域（DOI），以支持安全的组通信。GDOI管理组安全关联，这些关联由IPSEC和在IP或应用程序层上运行的潜在其他数据安全协议使用。这些安全关联保护一个或多个密钥加密密钥、流量加密密钥或组成员共享的数据。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. GDOI Applications. . . . . . . . . . . . . . . . . . . . 5
1.2. Extending GDOI . . . . . . . . . . . . . . . . . . . . . 5
2. GDOI Phase 1 protocol. . . . . . . . . . . . . . . . . . . . . 6
2.1. ISAKMP Phase 1 protocol. . . . . . . . . . . . . . . . . 6
2.1.1. DOI value. . . . . . . . . . . . . . . . . . . . 6
2.1.2. UDP port . . . . . . . . . . . . . . . . . . . . 6
3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 6
3.1. Authorization. . . . . . . . . . . . . . . . . . . . . . 7
3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Perfect Forward Secrecy. . . . . . . . . . . . . 9
3.2.2. ISAKMP Header Initialization . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. GDOI Applications. . . . . . . . . . . . . . . . . . . . 5
1.2. Extending GDOI . . . . . . . . . . . . . . . . . . . . . 5
2. GDOI Phase 1 protocol. . . . . . . . . . . . . . . . . . . . . 6
2.1. ISAKMP Phase 1 protocol. . . . . . . . . . . . . . . . . 6
2.1.1. DOI value. . . . . . . . . . . . . . . . . . . . 6
2.1.2. UDP port . . . . . . . . . . . . . . . . . . . . 6
3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 6
3.1. Authorization. . . . . . . . . . . . . . . . . . . . . . 7
3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Perfect Forward Secrecy. . . . . . . . . . . . . 9
3.2.2. ISAKMP Header Initialization . . . . . . . . . . 9
3.3. Initiator Operations . . . . . . . . . . . . . . . . . . 10
3.4. Receiver Operations. . . . . . . . . . . . . . . . . . . 11
4. GROUPKEY-PUSH Message. . . . . . . . . . . . . . . . . . . . . 11
4.1. Perfect Forward Secrecy (PFS). . . . . . . . . . . . . . 12
4.2. Forward and Backward Access Control. . . . . . . . . . . 12
4.2.1. Forward Access Control Requirements. . . . . . . 13
4.3. Delegation of Key Management . . . . . . . . . . . . . . 14
4.4. Use of signature keys. . . . . . . . . . . . . . . . . . 14
4.5. ISAKMP Header Initialization . . . . . . . . . . . . . . 14
4.6. Deletion of SAs. . . . . . . . . . . . . . . . . . . . . 14
4.7. GCKS Operations. . . . . . . . . . . . . . . . . . . . . 15
4.8. Group Member Operations. . . . . . . . . . . . . . . . . 16
5. Payloads and Defined Values. . . . . . . . . . . . . . . . . . 16
5.1. Identification Payload . . . . . . . . . . . . . . . . . 17
5.1.1. Identification Type Values . . . . . . . . . . . 18
5.2. Security Association Payload . . . . . . . . . . . . . . 18
5.2.1. Payloads following the SA payload. . . . . . . . 19
5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . 19
5.3.1. KEK Attributes . . . . . . . . . . . . . . . . . 22
5.3.2. KEK_MANAGEMENT_ALGORITHM . . . . . . . . . . . . 22
5.3.3. KEK_ALGORITHM. . . . . . . . . . . . . . . . . . 23
5.3.4. KEK_KEY_LENGTH . . . . . . . . . . . . . . . . . 23
5.3.5. KEK_KEY_LIFETIME . . . . . . . . . . . . . . . . 24
5.3.6. SIG_HASH_ALGORITHM . . . . . . . . . . . . . . . 24
5.3.7. SIG_ALGORITHM. . . . . . . . . . . . . . . . . . 24
5.3.8. SIG_KEY_LENGTH . . . . . . . . . . . . . . . . . 25
5.3.9. KE_OAKLEY_GROUP. . . . . . . . . . . . . . . . . 25
5.4. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . 25
5.4.1. PROTO_IPSEC_ESP. . . . . . . . . . . . . . . . . 26
5.4.2. Other Security Protocols . . . . . . . . . . . . 28
5.5. Key Download Payload . . . . . . . . . . . . . . . . . . 28
5.5.1. TEK Download Type. . . . . . . . . . . . . . . . 30
5.5.2. KEK Download Type. . . . . . . . . . . . . . . . 31
5.5.3. LKH Download Type. . . . . . . . . . . . . . . . 32
5.6. Sequence Number Payload. . . . . . . . . . . . . . . . . 35
5.7. Proof of Possession. . . . . . . . . . . . . . . . . . . 36
5.8. Nonce. . . . . . . . . . . . . . . . . . . . . . . . . . 36
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 36
6.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . 37
6.1.1. Authentication . . . . . . . . . . . . . . . . . 37
6.1.2. Confidentiality. . . . . . . . . . . . . . . . . 37
6.1.3. Man-in-the-Middle Attack Protection. . . . . . . 38
6.1.4. Replay/Reflection Attack Protection. . . . . . . 38
6.1.5. Denial of Service Protection . . . . . . . . . . 38
6.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . 38
6.2.1. Authentication . . . . . . . . . . . . . . . . . 38
6.2.2. Confidentiality. . . . . . . . . . . . . . . . . 39
6.2.3. Man-in-the-Middle Attack Protection. . . . . . . 39
3.3. Initiator Operations . . . . . . . . . . . . . . . . . . 10
3.4. Receiver Operations. . . . . . . . . . . . . . . . . . . 11
4. GROUPKEY-PUSH Message. . . . . . . . . . . . . . . . . . . . . 11
4.1. Perfect Forward Secrecy (PFS). . . . . . . . . . . . . . 12
4.2. Forward and Backward Access Control. . . . . . . . . . . 12
4.2.1. Forward Access Control Requirements. . . . . . . 13
4.3. Delegation of Key Management . . . . . . . . . . . . . . 14
4.4. Use of signature keys. . . . . . . . . . . . . . . . . . 14
4.5. ISAKMP Header Initialization . . . . . . . . . . . . . . 14
4.6. Deletion of SAs. . . . . . . . . . . . . . . . . . . . . 14
4.7. GCKS Operations. . . . . . . . . . . . . . . . . . . . . 15
4.8. Group Member Operations. . . . . . . . . . . . . . . . . 16
5. Payloads and Defined Values. . . . . . . . . . . . . . . . . . 16
5.1. Identification Payload . . . . . . . . . . . . . . . . . 17
5.1.1. Identification Type Values . . . . . . . . . . . 18
5.2. Security Association Payload . . . . . . . . . . . . . . 18
5.2.1. Payloads following the SA payload. . . . . . . . 19
5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . 19
5.3.1. KEK Attributes . . . . . . . . . . . . . . . . . 22
5.3.2. KEK_MANAGEMENT_ALGORITHM . . . . . . . . . . . . 22
5.3.3. KEK_ALGORITHM. . . . . . . . . . . . . . . . . . 23
5.3.4. KEK_KEY_LENGTH . . . . . . . . . . . . . . . . . 23
5.3.5. KEK_KEY_LIFETIME . . . . . . . . . . . . . . . . 24
5.3.6. SIG_HASH_ALGORITHM . . . . . . . . . . . . . . . 24
5.3.7. SIG_ALGORITHM. . . . . . . . . . . . . . . . . . 24
5.3.8. SIG_KEY_LENGTH . . . . . . . . . . . . . . . . . 25
5.3.9. KE_OAKLEY_GROUP. . . . . . . . . . . . . . . . . 25
5.4. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . 25
5.4.1. PROTO_IPSEC_ESP. . . . . . . . . . . . . . . . . 26
5.4.2. Other Security Protocols . . . . . . . . . . . . 28
5.5. Key Download Payload . . . . . . . . . . . . . . . . . . 28
5.5.1. TEK Download Type. . . . . . . . . . . . . . . . 30
5.5.2. KEK Download Type. . . . . . . . . . . . . . . . 31
5.5.3. LKH Download Type. . . . . . . . . . . . . . . . 32
5.6. Sequence Number Payload. . . . . . . . . . . . . . . . . 35
5.7. Proof of Possession. . . . . . . . . . . . . . . . . . . 36
5.8. Nonce. . . . . . . . . . . . . . . . . . . . . . . . . . 36
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 36
6.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . 37
6.1.1. Authentication . . . . . . . . . . . . . . . . . 37
6.1.2. Confidentiality. . . . . . . . . . . . . . . . . 37
6.1.3. Man-in-the-Middle Attack Protection. . . . . . . 38
6.1.4. Replay/Reflection Attack Protection. . . . . . . 38
6.1.5. Denial of Service Protection . . . . . . . . . . 38
6.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . 38
6.2.1. Authentication . . . . . . . . . . . . . . . . . 38
6.2.2. Confidentiality. . . . . . . . . . . . . . . . . 39
6.2.3. Man-in-the-Middle Attack Protection. . . . . . . 39
6.2.4. Replay/Reflection Attack Protection. . . . . . . 39
6.2.5. Denial of Service Protection . . . . . . . . . . 39
6.2.6. Authorization. . . . . . . . . . . . . . . . . . 40
6.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . 40
6.3.1. Authentication . . . . . . . . . . . . . . . . . 40
6.3.2. Confidentiality. . . . . . . . . . . . . . . . . 40
6.3.3. Man-in-the-Middle Attack Protection. . . . . . . 40
6.3.4. Replay/Reflection Attack Protection. . . . . . . 40
6.3.5. Denial of Service Protection . . . . . . . . . . 41
6.3.6. Forward Access Control . . . . . . . . . . . . . 41
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 41
7.1. ISAKMP DOI . . . . . . . . . . . . . . . . . . . . . . . 41
7.2. Payload Types. . . . . . . . . . . . . . . . . . . . . . 42
7.3. New Name spaces. . . . . . . . . . . . . . . . . . . . . 42
7.4. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 42
8. Intellectual Property Rights Statement . . . . . . . . . . . . 42
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.1. Normative References . . . . . . . . . . . . . . . . . . 43
10.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A: Alternate GDOI Phase 1 protocols . . . . . . . . . . . 46
A.1. IKEv2 Phase 1 protocol . . . . . . . . . . . . . . . . . 46
A.2. KINK Protocol. . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 48
6.2.4. Replay/Reflection Attack Protection. . . . . . . 39
6.2.5. Denial of Service Protection . . . . . . . . . . 39
6.2.6. Authorization. . . . . . . . . . . . . . . . . . 40
6.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . 40
6.3.1. Authentication . . . . . . . . . . . . . . . . . 40
6.3.2. Confidentiality. . . . . . . . . . . . . . . . . 40
6.3.3. Man-in-the-Middle Attack Protection. . . . . . . 40
6.3.4. Replay/Reflection Attack Protection. . . . . . . 40
6.3.5. Denial of Service Protection . . . . . . . . . . 41
6.3.6. Forward Access Control . . . . . . . . . . . . . 41
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 41
7.1. ISAKMP DOI . . . . . . . . . . . . . . . . . . . . . . . 41
7.2. Payload Types. . . . . . . . . . . . . . . . . . . . . . 42
7.3. New Name spaces. . . . . . . . . . . . . . . . . . . . . 42
7.4. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 42
8. Intellectual Property Rights Statement . . . . . . . . . . . . 42
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.1. Normative References . . . . . . . . . . . . . . . . . . 43
10.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A: Alternate GDOI Phase 1 protocols . . . . . . . . . . . 46
A.1. IKEv2 Phase 1 protocol . . . . . . . . . . . . . . . . . 46
A.2. KINK Protocol. . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 48
This document presents an ISAMKP Domain of Interpretation (DOI) for group key management called the "Group Domain of Interpretation" (GDOI). In this group key management model, the GDOI protocol is run between a group member and a "group controller/key server" (GCKS), which establishes security associations [Section 4.6.2 RFC2401] among authorized group members. ISAKMP defines two "phases" of negotiation [p.16 RFC2408]. The GDOI MUST be protected by a Phase 1 security association. This document incorporates the Phase 1 security association (SA) definition from the Internet DOI [RFC2407, RFC2409]. Other possible Phase 1 security association types are noted in Appendix A. The Phase 2 exchange is defined in this document, and proposes new payloads and exchanges according to the ISAKMP standard [p. 14 RFC2408].
本文档介绍了用于组密钥管理的ISAMKP解释域（DOI），称为“组解释域”（GDOI）。在该组密钥管理模型中，GDOI协议在组成员和“组控制器/密钥服务器”（GCKS）之间运行，该协议在授权组成员之间建立安全关联[第4.6.2节RFC2401]。ISAKMP定义了谈判的两个“阶段”[p.16 RFC2408]。GDOI必须受到阶段1安全关联的保护。本文档包含来自互联网DOI[RFC2407，RFC2409]的第1阶段安全关联（SA）定义。附录A中说明了其他可能的阶段1安全关联类型。本文件中定义了阶段2交换，并根据ISAKMP标准[p.14 RFC2408]提出了新的有效载荷和交换。
There are six new payloads:
有六个新的有效载荷：
1) GDOI SA 2) SA KEK (SAK) which follows the SA payload 3) SA TEK (SAT) which follows the SA payload
1) GDOI SA 2）SA KEK（SAK）跟随SA有效载荷3）SA TEK（SAT）跟随SA有效载荷
4) Key Download Array (KD) 5) Sequence number (SEQ) 6) Proof of Possession (POP)
4) 密钥下载阵列（KD）5）序列号（SEQ）6）持有证明（POP）
There are two new exchanges.
有两个新的交易所。
1) A Phase 2 exchange creates Re-key and Data-Security Protocol SAs.
1) 第2阶段交换创建密钥和数据安全协议SAs。
The new Phase 2 exchange, called "GROUPKEY-PULL," downloads keys for a group's "Re-key" SA and/or "Data-security" SA. The Re-key SA includes a key encrypting key, or KEK, common to the group; a Data-security SA includes a data encryption key, or TEK, used by a data-security protocol to encrypt or decrypt data traffic [Section 2.1 RFC2407]. The SA for the KEK or TEK includes authentication keys, encryption keys, cryptographic policy, and attributes. The GROUPKEY-PULL exchange uses "pull" behavior since the member initiates the retrieval of these SAs from a GCKS.
新的第2阶段交换称为“GROUPKEY-PULL”，它为组的“重新密钥”SA和/或“数据安全”SA下载密钥。重密钥SA包括组共用的密钥加密密钥或KEK；数据安全SA包括数据加密密钥或TEK，由数据安全协议用于加密或解密数据流量[第2.1节RFC2407]。KEK或TEK的SA包括身份验证密钥、加密密钥、加密策略和属性。GROUPKEY-PULL交换使用“PULL”行为，因为该成员从GCKS开始检索这些SA。
2) A datagram subsequently establishes additional Rekey and/or Data-Security Protocol SAs.
2) 数据报随后建立附加的密钥和/或数据安全协议SAs。
The GROUPKEY-PUSH datagram is "pushed" from the GCKS to the members to create or update a Re-key or Data-security SA. A Re-key SA protects GROUPKEY-PUSH messages. Thus, a GROUPKEY-PULL is necessary to establish at least one Re-key SA in order to protect subsequent GROUPKEY-PUSH messages. The GCKS encrypts the GROUPKEY-PUSH message using the KEK Re-key SA. GDOI accommodates the use of arrays of KEKs for group key management algorithms using the Logical Key Hierarchy (LKH) algorithm to efficiently add and remove group members [RFC2627]. Implementation of the LKH algorithm is OPTIONAL.
GROUPKEY-PUSH数据报从GCK“推送”到成员，以创建或更新重新密钥或数据安全SA。重新设置密钥SA可保护GROUPKEY-PUSH消息。因此，需要GROUPKEY-PULL来建立至少一个重新密钥SA，以保护后续GROUPKEY-PUSH消息。GCKS使用KEK Re key SA加密GROUPKEY-PUSH消息。GDOI允许将KEK数组用于组密钥管理算法，使用逻辑密钥层次（LKH）算法有效地添加和删除组成员[RFC2627]。LKH算法的实现是可选的。
Although the GROUPKEY-PUSH specified by this document can be used to refresh a Re-key SA, the most common use of GROUPKEY-PUSH is to establish a Data-security SA for a data security protocol. GDOI can accommodate future extensions to support a variety of data security protocols. This document only specifies data-security SAs for one security protocol, IPsec ESP. A separate RFC will specify support for other data security protocols such as a future secure Real-time Transport Protocol. A security protocol uses the TEK and "owns" the data-security SA in the same way that IPsec ESP uses the IKE Phase 2 keys and owns the Phase 2 SA; for GDOI, IPsec ESP uses the TEK.
尽管本文档指定的GROUPKEY-PUSH可用于刷新重新设置密钥的SA，但GROUPKEY-PUSH最常见的用途是为数据安全协议建立数据安全SA。GDOI可以适应未来的扩展，以支持各种数据安全协议。本文档仅为一个安全协议（IPsec ESP）指定数据安全SAs。单独的RFC将指定对其他数据安全协议（如未来安全实时传输协议）的支持。安全协议使用TEK并“拥有”数据安全SA，就像IPsec ESP使用IKE阶段2密钥并拥有阶段2 SA一样；对于GDOI，IPsec ESP使用TEK。
Thus, 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 key-encrypting keys, traffic-encrypting keys, or data shared by group members for multicast and groups security applications.
因此，GDOI是一个组安全关联管理协议：所有GDOI消息都用于创建、维护或删除组的安全关联。如上所述，这些安全关联为多播和组安全应用程序保护一个或多个密钥加密密钥、流量加密密钥或组成员共享的数据。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Secure multicast applications include video broadcast and multicast file transfer. In a business environment, many of these applications require network security and may use IPsec ESP to secure their data traffic. Section 5.4.1 specifies how GDOI carries the needed SA parameters for ESP. In this way, GDOI supports multicast ESP with group authentication of ESP packets using the shared, group key (authentication of unique sources of ESP packets is not possible).
安全多播应用包括视频广播和多播文件传输。在业务环境中，许多应用程序需要网络安全，并可能使用IPsec ESP来保护其数据流量。第5.4.1节规定了GDOI如何携带ESP所需的SA参数。通过这种方式，GDOI支持使用共享组密钥对ESP数据包进行组身份验证的多播ESP（不可能对ESP数据包的唯一来源进行身份验证）。
GDOI can also secure group applications that do not use multicast transport such as video-on-demand. For example, the GROUPKEY-PUSH message may establish a pair-wise IPsec ESP SA for a member of a subscription group without the need for key management exchanges and costly asymmetric cryptography.
GDOI还可以保护不使用多播传输（如视频点播）的组应用程序。例如，GROUPKEY-PUSH消息可以为订阅组的成员建立成对的IPsec ESP SA，而不需要密钥管理交换和昂贵的非对称加密。
Not all secure multicast or multimedia applications can use IPsec ESP. Many Real Time Transport Protocol applications, for example, require security above the IP layer to preserve RTP header compression efficiencies and transport-independence [RFC3550]. A future RTP security protocol may benefit from using GDOI to establish group SAs.
并非所有安全多播或多媒体应用程序都可以使用IPsec ESP。例如，许多实时传输协议应用程序需要IP层以上的安全性，以保持RTP报头压缩效率和传输独立性[RFC3550]。未来的RTP安全协议可能受益于使用GDOI建立组SA。
In order to add a new data security protocol, a new RFC MUST specify the data-security SA parameters conveyed by GDOI for that security protocol; these parameters are listed in section 5.4.2 of this document.
为了添加新的数据安全协议，新的RFC必须指定GDOI为该安全协议传输的数据安全SA参数；本文件第5.4.2节列出了这些参数。
Data security protocol SAs MUST protect group traffic. GDOI provides no restriction on whether that group traffic is transmitted as unicast or multicast packets. However, GDOI MUST NOT be used as a key management mechanism by a data security protocol when the packets protected by the data-security SA are intended to be private and never become part of group communications.
数据安全协议SAs必须保护组通信。GDOI对该组流量是作为单播还是多播数据包传输没有任何限制。然而，当数据安全SA保护的数据包是私有的且从未成为组通信的一部分时，GDOI不得被数据安全协议用作密钥管理机制。
GDOI is a "phase 2" protocol which MUST be protected by a "phase 1" protocol. The "phase 1" protocol can be any protocol which provides for the following protections:
GDOI是一个“第2阶段”协议，必须受到“第1阶段”协议的保护。“阶段1”协议可以是提供以下保护的任何协议：
o Peer Authentication o Confidentiality o Message Integrity
o 对等身份验证o机密性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.
以下各节描述了一个这样的“第一阶段”协议。附录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 6.1 describes how the ISAKMP Phase 1 protocols meet the requirements of a GDOI "phase 1" protocol.
第6.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值。
GDOI MUST NOT run on port 500 (the port commonly used for IKE). IANA has assigned port 848 for the use of GDOI.
GDOI不能在端口500（通常用于IKE的端口）上运行。IANA已将端口848分配给GDOI使用。
The goal of the GROUPKEY-PULL exchange is to establish a Re-key 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阵列。
There are two alternative means for authorizing the GROUPKEY-PULL message. First, the Phase 1 identity can be used to authorize the Phase 2 (GROUPKEY-PULL) request for a group key. Second, a new identity can be passed in the GROUPKEY-PULL request. The new identity could be specific to the group and use a certificate that is signed by the group owner to identify the holder as an authorized group member. The Proof-of-Possession payload validates that the holder possesses the secret key associated with the Phase 2 identity.
有两种方法可用于授权GROUPKEY-PULL消息。首先，阶段1标识可用于授权阶段2（GROUPKEY-PULL）请求组密钥。其次，可以在GROUPKEY-PULL请求中传递新标识。新身份可能特定于集团，并使用由集团所有人签署的证书将持有人标识为授权集团成员。占有证明有效载荷验证持有者拥有与阶段2身份相关联的密钥。
The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a which is the "key" in the keyed hash used in the GROUPKEY-PULL HASH payloads. When using the Phase 1 defined in this document, SKEYID_a is derived according to [RFC2409]. As with the IKE HASH payload generation [RFC 2409 section 5.5], each GROUPKEY-PULL message hashes a uniquely defined set of values. 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散列有效负载中使用的键控散列中的“键”。使用本文件中定义的阶段1时，根据[RFC2409]推导出SKEYID_a。与IKE散列有效负载生成一样[RFC 2409第5.5节]，每个GROUPKEY-PULL消息散列一组唯一定义的值。nonce排列散列并提供一些防止重放攻击的保护。重播保护对于保护GCK免受密钥管理服务器将吸引的攻击非常重要。
The GROUPKEY-PULL uses nonces to guarantee "liveliness", or against replay of a recent GROUPKEY-PULL message. The replay attack is only useful 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. 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 Responder MUST NOT compute the shared Diffie-Hellman number (if KE payloads were included) or install the new SAs until it receives a message with Nr included properly in the HASH payload.
GROUPKEY-PULL使用nonce来保证“生动性”，或者防止重播最近的GROUPKEY-PULL消息。重播攻击仅在当前阶段1的上下文中有用。如果基于前一阶段1重播GROUPKEY-PULL消息，则哈希计算将由于错误的SKEYID_a而失败。在评估nonce之前，消息将无法处理。为了让任何一个对等方获得重播保护的好处，它必须尽可能推迟处理，直到它收到协议中证明对等方是活动的消息为止。例如，响应者在收到散列负载中正确包含Nr的消息之前，不得计算共享Diffie-Hellman编号（如果包含KE有效负载）或安装新SAs。
Nonces require an additional message in the protocol exchange to ensure that the GCKS does not add a group member until it proves liveliness. The GROUPKEY-PULL member-initiator expects to find its nonce, Ni, in the HASH of a returned message. And the GROUPKEY-PULL GKCS responder expects to see its nonce, Nr, in the HASH of a returned message before providing group-keying material as in the following exchange.
nonce需要在协议交换中添加一条额外的消息，以确保GCKS在证明其活跃性之前不会添加组成员。GROUPKEY-PULL成员启动器希望在返回消息的哈希中找到其nonce Ni。GROUPKEY-PULL GKCS响应程序希望在提供组键控材料之前，在返回消息的散列中看到其nonce Nr，如下面的交换中所示。
Initiator (Member) Responder (GCKS)
------------------ ----------------
HDR*, HASH(1), Ni, ID -->
<-- HDR*, HASH(2), Nr, SA
HDR*, HASH(3) [,KE_I] -->
[,CERT] [,POP_I]
<-- HDR*, HASH(4),[KE_R,][SEQ,]
KD [,CERT] [,POP_R]
Initiator (Member) Responder (GCKS)
------------------ ----------------
HDR*, HASH(1), Ni, ID -->
<-- HDR*, HASH(2), Nr, SA
HDR*, HASH(3) [,KE_I] -->
[,CERT] [,POP_I]
<-- HDR*, HASH(4),[KE_R,][SEQ,]
KD [,CERT] [,POP_R]
Hashes are computed as follows:
散列计算如下：
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 [ | KE_I ] [ | CERT ]
[ | POP_I ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ | ]
KD [ | CERT ] [ | POP_R])
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 [ | KE_I ] [ | CERT ]
[ | POP_I ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ | ]
KD [ | CERT ] [ | POP_R])
POP payload is constructed as described in Section 5.7. * Protected by the Phase 1 SA, encryption occurs after HDR
POP有效载荷的构造如第5.7节所述。*受第1阶段SA保护，加密在HDR之后发生
HDR is an ISAKMP header payload that uses the Phase 1 cookies and a message identifier (M-ID) as in IKE [RFC2409]. Note that nonces are included in the first two exchanges, with the GCKS returning only the SA policy payload before liveliness is proven. The HASH payloads [RFC2409] prove that the peer has the Phase 1 secret (SKEYID_a) and the nonce for the exchange identified by message id, M-ID. Once liveliness is established, the last message completes the real processing of downloading the KD payload.
HDR是一个ISAKMP头有效载荷，它使用阶段1 cookie和消息标识符（M-ID），如IKE[RFC2409]中所述。请注意，前两个交换中包括nonce，GCK仅返回SA策略有效负载，然后才能验证其活跃性。散列有效载荷[RFC2409]证明对等方拥有第1阶段秘密（SKEYID_a）和由消息id M-id标识的用于交换的nonce。一旦建立活跃性，最后一条消息完成下载KD有效载荷的实际处理。
In addition to the Nonce and HASH payloads, the member-initiator identifies the group it wishes to join through the ISAKMP ID payload. The GCKS responder informs the member of the current value of the sequence number in the SEQ payload; the sequence number orders the GROUPKEY-PUSH datagrams (section 4); the member MUST check to see that the sequence number is greater than in the previous SEQ payload the member holds for the group (if it holds any) before installing any new SAs. The SEQ payload MUST be present if the SA payload contains an SA KEK attribute. The GCKS responder informs the member of the cryptographic policies of the group in the SA payload, which describes the DOI, KEK and/or TEK keying material, and authentication transforms. The SPIs are 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 Re-key SA, which is not negotiated but downloaded. The SA TEK attribute contains an SPI as defined in section 5.4 of this document. The second message downloads this SA payload. If a Re-key SA is defined in the SA payload, then KD will contain the KEK; if one or more Data-security
除了Nonce和HASH有效载荷外，成员启动器还通过ISAKMP ID有效载荷标识希望加入的组。GCKS应答器通知成员SEQ有效载荷中序列号的当前值；序列号对GROUPKEY-PUSH数据报进行排序（第4节）；在安装任何新的SAs之前，成员必须检查序列号是否大于该成员为该组持有的先前SEQ有效载荷（如果有）。如果SA有效负载包含SA KEK属性，则必须存在SEQ有效负载。GCKS响应者在SA有效载荷中通知组成员密码策略，该有效载荷描述了DOI、KEK和/或TEK密钥材料以及身份验证转换。SPI也由GCK确定，并在SA有效载荷链中下载（见第5.2节）。SA KEK属性包含重新设置SA密钥的ISAKMP cookie对，该对不是协商的，而是下载的。SA TEK属性包含本文件第5.4节中定义的SPI。第二条消息下载此SA有效负载。如果在SA有效载荷中定义了重设密钥SA，则KD将包含KEK；如果一个或多个数据安全
SAs are defined in the SA payload, KD will contain the TEKs. This is useful if there is an initial set of TEKs for the particular group and can obviate the need for future TEK GROUPKEY-PUSH messages (described in section 4).
SA在SA有效载荷中定义，KD将包含TEK。如果特定组有一组初始的TEK，这将非常有用，并且可以避免将来需要TEK组按键消息（如第4节所述）。
As described above, the member may establish an identity in the GROUPKEY-PULL exchange in an optional CERT payload that is separate from the Phase 1 identity. When the member passes a new CERT, a proof of possession (POP) payload accompanies it. The POP payload demonstrates that the member or GCKS has used the very secret that authenticates it. POP_I is an ISAKMP SIG payload containing a hash including the nonces Ni and Nr signed by the member, when the member passes a CERT, signed by the Group Owner to prove its authorization. POP_R contains the hash including the concatenated nonces Ni and Nr signed by the GCKS, when the GCKS passes a CERT, signed by the group owner, to prove its authority to provide keys for a particular group. The use of the nonce pair for the POP payload, transformed through a pseudo-random function (prf) and encrypted, is designed to withstand compromise of the Phase 1 key. Implementation of the CERT and POP payloads is OPTIONAL.
如上所述，成员可以在与阶段1身份分离的可选证书有效载荷中的GROUPKEY-PULL交换中建立身份。当成员通过一个新的证书时，一个持有证明（POP）有效载荷伴随着它。POP有效负载表明成员或GCKS使用了对其进行身份验证的机密。POP_I是一个ISAKMP SIG有效载荷，其中包含一个散列，其中包括当成员传递一个由组所有者签名以证明其授权的证书时，该成员签名的nonce Ni和Nr。POP_R包含哈希值，其中包括GCKS在传递由组所有者签名的证书以证明其为特定组提供密钥的权限时签名的串联nonce Ni和Nr。通过伪随机函数（prf）转换并加密的POP有效载荷的nonce对的使用被设计为能够承受第1阶段密钥的泄露。CERT和POP有效载荷的实现是可选的。
If PFS is desired and the optional KE payload is used in the exchange, then both sides compute a DH secret and use it to protect the new keying material contained in KD. The GCKS responder will xor the DH secret with the KD payload and send it to the member Initiator, which recovers the KD by repeating this operation as in the Oakley IEXTKEY procedure [RFC2412]. Implementation of the KE payload is OPTIONAL.
如果需要PFS，并且在交换中使用可选的KE有效载荷，则双方计算DH秘密并使用它来保护KD中包含的新密钥材料。GCKS响应程序将DH机密与KD有效负载异或，并将其发送给成员启动器，成员启动器通过重复Oakley IEXTKEY过程[RFC2412]中的此操作来恢复KD。KE有效负载的实现是可选的。
Cookies are used in the ISAKMP header as a weak form of denial of service protection. The GDOI GROUPKEY-PULL exchange uses cookies according to ISAKMP [RFC2408].
Cookie在ISAKMP标头中用作一种弱形式的拒绝服务保护。GDOI GROUPKEY-PULL交换根据ISAKMP[RFC2408]使用cookie。
Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).
下一个有效载荷标识ISAKMP或GDOI有效载荷（参见第5.0节）。
Major Version is 1 and Minor Version is 0 according to ISAKMP [RFC2408, Section 3.1].
根据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 [RFC2408, Section 3.1]
标志、消息ID和长度符合ISAKMP[RFC2408，第3.1节]
Before a group member (GDOI initiator) contacts the GCKS, it must determine the group identifier and acceptable Phase 1 policy via an out-of-band method such as SDP. Phase 1 is initiated using the GDOI DOI in the SA payload. Once Phase 1 is complete, the initiator state machine moves to the GDOI protocol.
在组成员（GDOI发起人）联系GCK之前，必须通过带外方法（如SDP）确定组标识符和可接受的阶段1策略。阶段1使用SA有效负载中的GDOI DOI启动。阶段1完成后，启动器状态机将移动到GDOI协议。
To construct the first GDOI message the initiator chooses Ni and creates a nonce payload, builds an identity payload including the group identifier, and generates HASH(1).
为了构造第一条GDOI消息，启动器选择Ni并创建一个nonce负载，构建一个包含组标识符的标识负载，并生成哈希（1）。
Upon receipt of the second GDOI message, the initiator validates HASH(2), extracts the nonce Nr, and interprets the SA payload. If the policy in the SA payload is acceptable (e.g., the security protocol and cryptographic protocols can be supported by the initiator), the initiator continues the protocol.
在收到第二条GDOI消息后，发起方验证散列（2），提取nonce Nr，并解释SA有效负载。如果SA有效负载中的策略是可接受的（例如，启动器可以支持安全协议和加密协议），则启动器继续协议。
If the group policy uses certificates for authorization, the initiator generates a hash including Ni and Nr and signs it. This becomes the contents of the POP payload. If necessary, a CERT payload is constructed which holds the public key corresponding to the private key used to sign the POP payload.
如果组策略使用证书进行授权，则发起程序将生成一个包含Ni和Nr的哈希，并对其进行签名。这将成为POP有效负载的内容。如有必要，将构造一个证书有效载荷，该有效载荷保存与用于签署POP有效载荷的私钥相对应的公钥。
The initiator constructs the third GDOI message by including the CERT and POP payloads (if needed) and creating HASH(3).
发起者通过包含CERT和POP有效载荷（如果需要）并创建散列（3）来构造第三条GDOI消息。
Upon receipt of the fourth GDOI message, the initiator validates HASH(4). If the responder sent CERT and POP_R payloads, the POP signature is validated.
在收到第四条GDOI消息后，启动器验证散列（4）。如果响应者发送了证书和POP\R有效载荷，POP签名将被验证。
If SEQ payload is present, the sequence number in the SEQ payload must be checked against any previously received sequence number for this group. If it is less than the previously received number, it should be considered stale and ignored. This could happen if two GROUPKEY-PULL messages happened in parallel, and the sequence number changed between the times the results of two GROUPKEY-PULL messages were returned from the GCKS.
如果存在SEQ payload，则必须对照之前收到的该组序列号检查SEQ payload中的序列号。如果它小于以前收到的编号，则应将其视为过时并忽略。如果两条GROUPKEY-PULL消息并行发生，并且在两条GROUPKEY-PULL消息的结果从GCK返回的时间之间序列号发生变化，则可能会发生这种情况。
The initiator interprets the KD key packets, matching the SPIs in the key packets to SPIs previously sent in the SA payloads identifying particular policy. For TEKs, once the keys and policy are matched, the initiator is ready to send or receive packets matching the TEK policy. (If policy and keys had been previously received for this TEK policy, the initiator may decide instead to ignore this TEK policy in case it is stale.) If this group has a KEK, the KEK policy and keys are marked as ready for use.
启动器解释KD密钥包，将密钥包中的SPI与SA有效负载中先前发送的SPI相匹配，以识别特定策略。对于TEK，一旦密钥和策略匹配，启动器就可以发送或接收与TEK策略匹配的数据包。（如果之前已收到此TEK策略的策略和密钥，则发起方可决定忽略此TEK策略，以防其过时。）如果此组具有KEK，则KEK策略和密钥将标记为可供使用。
The GCKS (responder) 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), extracts the Ni and group identifier in the ID payload. It verifies that its database contains the group information for the group identifier.
收到第一条GDOI消息后，GCKS验证哈希（1），提取ID有效负载中的Ni和组标识符。它验证其数据库是否包含组标识符的组信息。
The GCKS constructs the second GDOI message, including a nonce Nr, and the policy for the group in an SA payload, followed by SA TEK payloads for traffic SAs, and SA KEK policy (if the group controller will be sending Re-key messages to the group).
GCKS构造第二条GDOI消息，包括nonce Nr和SA有效负载中的组策略，然后是流量SA的SA TEK有效负载和SA KEK策略（如果组控制器将向组发送重新设置密钥的消息）。
Upon receipt of the third GDOI message the GCKS validates HASH(3). If the initiator sent CERT and POP_I payloads, the POP signature is validated.
收到第三条GDOI消息后，GCKS验证哈希（3）。如果发起人发送了证书和POP_I有效载荷，则POP签名将被验证。
The GCKS constructs the fourth GDOI message, including the SEQ payload (if the GCKS sends rekey messages), the KD payload containing keys corresponding to policy previously sent in the SA TEK and SA KEK payloads, and the CERT and POP payloads (if needed).
GCKS构造第四条GDOI消息，包括SEQ有效载荷（如果GCKS发送重新密钥消息）、KD有效载荷（包含与SA TEK和SA KEK有效载荷中先前发送的策略相对应的密钥）以及CERT和POP有效载荷（如果需要）。
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 Re-key SA KEK or KEK array, and/or creates a new Data-security SA.
GDOI使用组通信安全地发送控制信息。通常，这将使用GROUPKEY-PUSH消息的IP多播分发，但如果无法使用IP多播，也可以使用单播交付“推送”。GROUPKEY-PUSH消息替换重新设置密钥的SA KEK或KEK数组，和/或创建新的数据安全SA。
Member GCKS or Delegate
------ ----------------
Member GCKS or Delegate
------ ----------------
<---- HDR*, SEQ, SA, KD, [CERT,] SIG
<---- HDR*, SEQ, SA, KD, [CERT,] SIG
* Protected by the Re-key SA KEK; encryption occurs after HDR
* 受Re-key SA KEK保护；加密发生在HDR之后
HDR is defined below. The SEQ payload is defined in the Payloads section. The SA defines the policy (e.g., protection suite) and attributes (e.g., SPI) for a Re-key and/or Data-security SAs. The GCKS or delegate optionally provides a CERT payload for verification of the SIG. KD is the key download payload as described in the Payloads section.
HDR的定义如下。SEQ有效载荷在有效载荷部分中定义。SA为重设密钥和/或数据安全SA定义策略（如保护套件）和属性（如SPI）。GCKS或代表可选择提供证书有效载荷以验证SIG。KD是有效载荷部分中描述的关键下载有效载荷。
The SIG payload is a signature of a hash of the entire message before encryption (including the header and excluding the SIG payload itself), prefixed with the string "rekey". The prefixed string ensures that the signature of the Rekey datagram cannot be used for any other purpose in the GDOI protocol.
SIG有效载荷是加密前整个消息的散列签名（包括头部，不包括SIG有效载荷本身），前缀为字符串“rekey”。带前缀的字符串确保在GDOI协议中，密钥更新数据报的签名不能用于任何其他目的。
If the SA defines an LKH KEK array or single KEK, KD contains a KEK or KEK array for a new Re-key SA, which has a new cookie pair. When the KD payload carries a new SA KEK attribute (section 5.3), a Re-key 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. 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.5).
如果SA定义了一个LKH KEK数组或单个KEK，KD将包含一个KEK或KEK数组，用于具有新cookie对的新Re key SA。当KD有效载荷携带新的SA KEK属性（第5.3节）时，重新密钥SA将替换为具有相同组标识符（第3.2节消息1中指定的ID）的新SA，并递增相同序列计数器，该序列计数器在第3.2节消息4中初始化。如果SA定义了SA TEK有效载荷，则会通知会员机构已创建新的数据安全SA，并在KD中携带密钥材料（第5.5节）。
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阵列部分。
The GROUPKEY-PUSH message is protected by the group KEK though in all cases, the GROUPKEY-PUSH message carries new key downloads, among other information. A freshly generated secret must protect the key download for the GROUPKEY-PUSH message to have PFS. This issue is for further study.
GROUPKEY-PUSH消息受group KEK的保护，尽管在所有情况下，GROUPKEY-PUSH消息都包含新的密钥下载和其他信息。新生成的密钥必须保护密钥下载，才能使GROUPKEY-PUSH消息具有PFS。这个问题有待进一步研究。
Through GROUPKEY-PUSH, the GDOI supports algorithms such as LKH 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). An unrelated notion to PFS, "forward access control" and "backward access control" have been called "perfect forward security" and "perfect backward security" in the literature [RFC2627].
通过GROUPKEY-PUSH，GDOI支持LKH等算法，该算法具有拒绝从组中删除的成员访问新组密钥（前向访问控制）和添加到组中的成员访问旧组密钥（后向访问控制）的特性。一个与PFS无关的概念，“前向访问控制”和“后向访问控制”在文献[RFC2627]中被称为“完美前向安全”和“完美后向安全”。
Group management algorithms providing forward and backward access control other than LKH have been proposed in the literature, including OFT [OFT] and Subset Difference [NNL]. These algorithms could be used with GDOI, but are not specified as a part of this document.
文献中已经提出了除LKH之外提供前向和后向访问控制的组管理算法，包括OFT[OFT]和子集差分[NNL]。这些算法可与GDOI一起使用，但未作为本文档的一部分指定。
Support for group management algorithms is supported via the KEY_MANAGEMENT_ALGORITHM attribute which is sent in the SA_KEK payload. GDOI specifies one method by which LKH can be used for forward and backward access control. Other methods of using LKH, as well as other group management algorithms such as OFT or Subset Difference may be added to GDOI as part of a later document. Any such addition MUST be due to a Standards Action as defined in [RFC2434].
通过在SA_KEK有效负载中发送的KEY_management_ALGORITHM属性支持对组管理算法的支持。GDOI指定了一种方法，通过该方法LKH可以用于前向和后向访问控制。其他使用LKH的方法以及其他组管理算法（如OFT或子集差异）可以作为后续文档的一部分添加到GDOI中。任何此类添加必须是由于[RFC2434]中定义的标准行动。
When group membership is altered using a group management algorithm new SA_TEKs (and their associated keys) are usually also needed. New SAs and keys ensure that members who were denied access can no longer participate in the group.
当使用组管理算法更改组成员身份时，通常还需要新的SA_Tek（及其相关密钥）。新的SA和密钥确保被拒绝访问的成员不能再参与组。
If forward access control is a desired property of the group, new SA_TEKs and the associated key packets in the KD payload MUST NOT be included in a GROUPKEY-PUSH message which changes group membership. This is required because the SA_TEK policy and the associated key packets in the KD payload are not protected with the new KEK. A second GROUPKEY-PUSH message can deliver the new SA_TEKS and their associated keys because it will be protected with the new KEK, and thus will not be visible to the members who were denied access.
如果前向访问控制是组的期望属性，则KD有效负载中的新SA_Tek和相关密钥包不得包含在更改组成员资格的GROUPKEY-PUSH消息中。这是必需的，因为SA_-TEK策略和KD有效负载中的相关密钥数据包不受新KEK的保护。第二个GROUPKEY-PUSH消息可以传递新的SA_Tek及其相关密钥，因为它将受到新KEK的保护，因此被拒绝访问的成员将看不到它。
If forward access control policy for the group includes keeping group policy changes from members that are denied access to the group, then two sequential GROUPKEY-PUSH messages changing the group KEK MUST be sent by the GCKS. The first GROUPKEY-PUSH message creates a new KEK for the group. Group members, which are denied access, will not be able to access the new KEK, but will see the group policy since the GROUPKEY-PUSH message is protected under the current KEK. A subsequent GROUPKEY-PUSH message containing the changed group policy and again changing the KEK allows complete forward access control. A GROUPKEY-PUSH message MUST NOT change the policy without creating a new KEK.
如果组的前向访问控制策略包括保留被拒绝访问组的成员的组策略更改，则GCK必须发送两条更改组KEK的连续GROUPKEY-PUSH消息。第一条GROUPKEY-PUSH消息为组创建一个新的KEK。被拒绝访问的组成员将无法访问新的KEK，但将看到组策略，因为GROUPKEY-PUSH消息受当前KEK的保护。随后的GROUPKEY-PUSH消息包含更改的组策略，并且再次更改KEK，从而允许完全的前向访问控制。GROUPKEY-PUSH消息必须在不创建新KEK的情况下更改策略。
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消息中维护前向访问控制策略。
GDOI supports delegation of GROUPKEY-PUSH datagrams through the delegation capabilities of the PKI. However, GDOI does not explicitly specify how the GCKS identifies delegates, but leaves this to the PKI that is used by a particular GDOI implementation.
GDOI通过PKI的委托功能支持GROUPKEY-PUSH数据报的委托。但是，GDOI没有明确指定GCKS如何识别委托，而是将其留给特定GDOI实现所使用的PKI。
The GCKS SHOULD NOT use the same key to sign the SIG payload in the GROUPKEY-PUSH message as was used for authorization in the GROUPKEY-PULL POP payload. If the same key must be used, a different hash function SHOULD be used as a base for the POP payload than is used as a base for the SIG payload.
GCKS不应使用与GROUPKEY-PULL POP有效载荷中用于授权的密钥相同的密钥对GROUPKEY-PUSH消息中的SIG有效载荷进行签名。如果必须使用相同的密钥，则POP有效负载的基函数应与SIG有效负载的基函数不同。
Unlike ISAKMP or IKE, the cookie pair is completely determined by the GCKS. The cookie pair in the GDOI ISAKMP header identifies the Re-key SA to differentiate the secure groups managed by a GCKS. Thus, GDOI uses the cookie fields as an SPI.
与ISAKMP或IKE不同，cookie对完全由GCK决定。GDOI ISAKMP头中的cookie对标识重新密钥SA，以区分由GCKS管理的安全组。因此，GDOI将cookie字段用作SPI。
Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).
下一个有效载荷标识ISAKMP或GDOI有效载荷（参见第5.0节）。
Major Version is 1 and Minor Version is 0 according to ISAKMP [RFC2408, Section 3.1].
根据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 [RFC2008, Section 3.1]. All other bits MUST be set to zero.
标志必须根据[RFC2008，第3.1节]设置加密位。所有其他位必须设置为零。
Message ID MUST be set to zero.
消息ID必须设置为零。
Length is according to ISAKMP [RFC2408, Section 3.1]
长度根据ISAKMP[RFC2408，第3.1节]
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 [RFC2408, Section 3.15] 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.4 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. If a TEK SA and a KEK SA must be deleted, they must be sent in different Delete payloads.
o 协议Id字段包含本文件第5.4节中定义的TEK协议Id值。要删除KEK SA，必须将0的值用作协议id。请注意，在删除有效负载中只能定义一个协议id值。如果必须删除TEK SA和KEK SA，则必须以不同的删除有效载荷发送它们。
GCKS or its delegate 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 which is one greater than the previous rekey datagram.
为了开始重设密钥数据报，GCKS构建一个具有正确cookie对的ISAKMP HDR，以及一个包含比先前重设密钥数据报大一个序列号的SEQ有效载荷。
An SA payload is then added. This is identical in structure and meaning to a SA payload sent in a GROUPKEY-PULL exchange. If there are changes to the KEK (in the case of a static KEK) or in group membership (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（在静态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 KEK keys (or a KEK array) is included. TEK keys are sent for each SA_TEK attribute included in the SA payload.
然后添加KD有效负载。这在结构和意义上与在GROUPKEY-PULL交换中发送的KD有效负载相同。如果SA有效负载中包含SA_KEK属性，则会包含相应的KEK密钥（或KEK数组）。为SA有效负载中包含的每个SA_TEK属性发送TEK密钥。
A CERT payload is added if the initiator needs to provide its certificate.
如果启动器需要提供其证书，则会添加证书有效负载。
In the penultimate step, the initiator hashes the string "rekey" followed by the key management message already formed. The hash is signed, placed in a SIG payload and added to the datagram.
在倒数第二步中，发起者散列字符串“rekey”，后跟已经形成的密钥管理消息。散列被签名，放置在SIG有效负载中，并添加到数据报中。
Lastly, the payloads following the HDR are encrypted using the current KEK encryption key. 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 signature of the decrypted message is then validated, possibly using the CERT payload if it is included.
然后验证解密消息的签名，如果包含证书有效载荷，则可能使用证书有效载荷。
The sequence number in the SEQ payload is validated to ensure that it is greater than the previously received sequence number, and that it fits within a window of acceptable values.
验证SEQ有效负载中的序列号，以确保其大于先前接收的序列号，并且符合可接受值的窗口。
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 IPsec SAs being added to the system.
对SA和KD有效负载进行处理，从而将新的GDOI密钥SA（如果SA有效负载包括SA_KEK属性）和/或新的IPsec SA添加到系统中。
This document specifies use of several ISAKMP payloads, which are defined in accordance with RFC2408. The following payloads are extended or further specified.
本文件规定了根据RFC2408定义的多个ISAKMP有效载荷的使用。扩展或进一步指定了以下有效载荷。
Next Payload Type Value
----------------- -----
Security Association (SA) 1
Identification (ID) 5
Nonce (N) 10
Next Payload Type Value
----------------- -----
Security Association (SA) 1
Identification (ID) 5
Nonce (N) 10
Several new payload formats are required in the group security exchanges.
在组安全交换中需要几种新的有效负载格式。
Next Payload Type Value
----------------- -----
SA KEK Payload (SAK) 15
SA TEK Payload (SAT) 16
Key Download (KD) 17
Sequence Number (SEQ) 18
Proof of Possession (POP) 19
Next Payload Type Value
----------------- -----
SA KEK Payload (SAK) 15
SA TEK Payload (SAT) 16
Key Download (KD) 17
Sequence Number (SEQ) 18
Proof of Possession (POP) 19
The Identification Payload 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 IP multicast group, or may specify a more general identifier, such as one that represents a set of related multicast streams.
标识有效负载用于标识稍后将与组的安全关联关联的组标识。组标识可以映射到特定IP多播组，或者可以指定更通用的标识符，例如表示一组相关多播流的标识符。
The Identification 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! RESERVE2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! RESERVE2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Identification 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, this field will be zero (0).
o 下一个有效负载（1个八位字节）——消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为零（0）。
o RESERVED (1 octet) -- Unused, must be zero (0).
o 保留（1个八位组）--未使用，必须为零（0）。
o Payload Length (2 octets) -- Length, in octets, of the identification data, including the generic header.
o 有效负载长度（2个八位字节）——标识数据的长度，以八位字节为单位，包括通用报头。
o Identification Type (1 octet) -- Value describing the identity information found in the Identification Data field.
o 标识类型（1个八位字节）——描述标识数据字段中标识信息的值。
o RESERVED2 (2 octets) -- Unused, must be zero (0).
o RESERVED2（2个八位字节）——未使用，必须为零（0）。
o Identification Data (variable length) -- Value, as indicated by the Identification Type.
o 标识数据（可变长度）——由标识类型指示的值。
The following table lists the assigned values for the Identification Type field found in the Identification Payload.
下表列出了标识有效负载中标识类型字段的分配值。
ID Type Value
------- -----
RESERVED 0 - 10
ID_KEY_ID 11
RESERVED 12 - 127
Private Use 128 - 255
ID Type Value
------- -----
RESERVED 0 - 10
ID_KEY_ID 11
RESERVED 12 - 127
Private Use 128 - 255
In the context of a GDOI ID payload, ID_KEY_ID specifies a four (4)-octet group identifier.
在gdoiid有效负载的上下文中，ID_KEY_ID指定一个四（4）个八位组的组标识符。
The Security Association payload is defined in RFC 2408. For the GDOI, it is used by the GCKS to assert security attributes for both Re-key and Data-security SAs.
安全关联有效负载在RFC 2408中定义。对于GDOI，GCKS使用它为Re key和数据安全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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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 a SAK Payload or SAT Payload type, but the next non-Security Association type payload.
o 下一个有效负载（1个八位字节）——标识上面定义的GROUPKEY-PULL或GROUPKEY-PUSH消息的下一个有效负载。下一个有效负载不能是SAK有效负载或SAT有效负载类型，而是下一个非安全关联类型的有效负载。
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 (1 octet) -- Must be either a SAK Payload or a SAT Payload. See section 5.2.1 for a description of which circumstances are required for each payload type to be present.
o SA属性下一个有效负载（1个八位字节）——必须是SAK有效负载或SAT有效负载。请参见第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 Payloads, and zero or more SAT Payloads, where either one SAK or SAT payload MUST be present.
为集团使用的KEK和/或TEK定义特定安全关联属性的有效负载必须遵循SA有效负载。每个有效负载的数量取决于组策略。可能存在零或一个SAK有效载荷，以及零或多个SAT有效载荷，其中必须存在一个SAK或SAT有效载荷。
This latitude allows various group policies to be accommodated. For example if the group policy does not require the use of a Re-key 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 Re-key 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 Re-key SA message SA payload.
这种自由度允许适应各种集团政策。例如，如果集团策略不要求使用重新注册SA，则GCK不需要向集团成员发送SA KEK属性，因为所有SA更新都将使用注册SA执行。或者，组策略可能使用重新注册SA，但选择仅作为注册SA的一部分将KEK下载到组成员。因此，KEK策略（在SA KEK属性中）不需要作为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允许多个会话成为同一组的一部分，并允许多个流与会话（例如，视频、音频和文本）关联，但每个流都具有单独的安全关联策略。
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 ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! POP Algorithm ! POP Key Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ 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 ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! POP Algorithm ! POP Key Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ KEK Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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 SAT Payload or zero to indicate there is no SA TEK payload.
o 下一个有效负载（1个八位字节）——标识GROUPKEY-PULL或GROUPKEY-PUSH消息的下一个有效负载。此消息唯一有效的下一有效负载类型是SAT有效负载或零，表示没有SA TEK有效负载。
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) for the rekey datagram.
o 协议（1个八位组）--描述密钥更新数据报的IP协议ID（例如UDP/TCP）的值。
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 isakmpd-registry [ISAKMP-REG].
o SRC ID类型（1个八位字节）——描述在SRC标识数据字段中找到的标识信息的值。定义的值由IANA isakmpd注册表[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 should be ignored.
o SRC ID端口（2个八位字节）——指定与源ID关联的端口的值。值为零表示应忽略SRC ID端口字段。
o SRC ID Data Len (1 octet) -- Value specifying the length 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 isakmpd-registry [ISAKMP-REG].
o DST ID类型（1个八位字节）——描述在DST标识数据字段中找到的标识信息的值。定义的值由IANA isakmpd注册表[ISAKMP-REG]中的IPSEC标识类型部分指定。
o DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP).
o DST ID Prot（1个八位字节）——描述IP协议ID（例如UDP/TCP）的值。
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 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 must be 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 POP Algorithm (2 octets) -- The POP payload algorithm. Defined values are specified in the following table. If no POP algorithm is defined by the KEK policy this field must be zero.
o POP算法（2个八位字节）——POP有效负载算法。定义的值在下表中指定。如果KEK策略未定义POP算法，则此字段必须为零。
Algorithm Type Value
-------------- -----
RESERVED 0
POP_ALG_RSA 1
POP_ALG_DSS 2
POP_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255
Algorithm Type Value
-------------- -----
RESERVED 0
POP_ALG_RSA 1
POP_ALG_DSS 2
POP_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255
o POP Key Length (2 octets) -- Length of the POP payload key. If no POP algorithm is defined in the KEK policy, this field must be zero.
o POP密钥长度（2个八位字节）——POP有效负载密钥的长度。如果KEK策略中未定义POP算法，则此字段必须为零。
o KEK Attributes -- Contains KEK policy attributes associated with the group. The following sections describe the possible attributes. Any or all attributes may be optional, depending on the group policy.
o KEK属性--包含与组关联的KEK策略属性。以下各节描述了可能的属性。任何或所有属性都可能是可选的，具体取决于组策略。
The following attributes may be present in a SAK Payload. The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. 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).
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
KE_OAKLEY_GROUP 8 B
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
KE_OAKLEY_GROUP 8 B
The following attributes may only be included in a GROUPKEY-PULL message: KEK_MANAGEMENT_ALGORITHM, KE_OAKLEY_GROUP.
以下属性只能包含在GROUPKEY-PULL消息中：KEK_MANAGEMENT_ALGORITHM、KE_OAKLEY_GROUP。
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
RESERVED 2-127
Private Use 128-255
KEK Management Type Value
------------------- -----
RESERVED 0
LKH 1
RESERVED 2-127
Private Use 128-255
The KEK_ALGORITHM class specifies the encryption algorithm using with the KEK. Defined values are specified in the following table.
KEK_算法类指定与KEK一起使用的加密算法。定义的值在下表中指定。
Algorithm Type Value
-------------- -----
RESERVED 0
KEK_ALG_DES 1
KEK_ALG_3DES 2
KEK_ALG_AES 3
RESERVED 4-127
Private Use 128-255
Algorithm Type Value
-------------- -----
RESERVED 0
KEK_ALG_DES 1
KEK_ALG_3DES 2
KEK_ALG_AES 3
RESERVED 4-127
Private Use 128-255
A GDOI implementation MUST support the KEK_ALG_3DES algorithm attribute.
GDOI实现必须支持KEK_ALG_3DES算法属性。
If a KEK_MANAGEMENT_ALGORITHM is defined which defines 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 which are included as part of the management.
如果定义了定义多个密钥（例如，LKH）的KEK_管理算法，并且如果管理算法未指定这些密钥的算法，则KEK_算法属性定义的算法必须用于作为管理一部分的所有密钥。
This algorithm specifies DES using the Cipher Block Chaining (CBC) mode as described in [FIPS81].
该算法使用[FIPS81]中所述的密码块链接（CBC）模式指定DES。
This algorithm specifies 3DES using three independent keys as described in "Keying Option 1" in [FIPS46-3].
该算法使用[FIPS46-3]中“键控选项1”中所述的三个独立键指定3DE。
This algorithm specifies AES as described in [FIPS197]. The mode of operation for AES is Cipher Block Chaining (CBC) as recommended in [AES-MODES].
此算法指定AES，如[FIPS197]所述。AES的操作模式为[AES-MODES]中推荐的密码块链接（CBC）。
The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in bits).
KEK_KEY_LENGTH类指定KEK算法密钥长度（以位为单位）。
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 four (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 tables define the algorithms for SIG_HASH_ALGORITHM.
SIG_哈希算法指定SIG有效负载哈希算法。下表定义了SIG_哈希_算法的算法。
Algorithm Type Value
-------------- -----
RESERVED 0
SIG_HASH_MD5 1
SIG_HASH_SHA1 2
RESERVED 3-127
Private Use 128-255
Algorithm Type Value
-------------- -----
RESERVED 0
SIG_HASH_MD5 1
SIG_HASH_SHA1 2
RESERVED 3-127
Private Use 128-255
SIG_HASH_ALGORITHM is not required if the SIG_ALGORITHM is SIG_ALG_DSS or SIG_ALG_ECDSS, which imply SIG_HASH_SHA1.
如果SIG_算法是SIG_ALG_DSS或SIG_ALG_ECDSS，则不需要SIG_HASH_算法，这意味着SIG_HASH_SHA1。
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
RESERVED 4-127
Private Use 128-255
Algorithm Type Value
-------------- -----
RESERVED 0
SIG_ALG_RSA 1
SIG_ALG_DSS 2
SIG_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255
A GDOI implementation MUST support the following algorithm attribute: SIG_ALG_RSA.
GDOI实现必须支持以下算法属性：SIG_ALG_RSA。
This algorithm specifies the RSA digital signature algorithm as described in [RSA].
此算法指定[RSA]中所述的RSA数字签名算法。
This algorithm specifies the DSS digital signature algorithm as described in [FIPS186-2].
该算法规定了[FIPS186-2]中所述的DSS数字签名算法。
This algorithm specifies the Elliptic Curve digital signature algorithm as described in [FIPS186-2].
该算法规定了[FIPS186-2]中所述的椭圆曲线数字签名算法。
The SIG_KEY_LENGTH class specifies the length of the SIG payload key.
SIG_KEY_LENGTH类指定SIG有效负载密钥的长度。
The KE_OAKLEY_GROUP class defines the OAKLEY Group used to compute the PFS secret in the optional KE payload of the GDOI GROUPKEY-PULL exchange. This attribute uses the values assigned to Group Definitions in the IANA IPsec-registry [IPSEC-REG].
KE_OAKLEY_GROUP类定义用于计算GDOI GROUPKEY-PULL交换的可选KE有效负载中的PFS机密的OAKLEY组。此属性使用分配给IANA IPsec注册表[IPsec-REG]中的组定义的值。
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 ~
+-+-+-+-+-+-+-+-+ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
RESERVED 2-127
Private Use 128-255
Protocol ID Value
----------- -----
RESERVED 0
GDOI_PROTO_IPSEC_ESP 1
RESERVED 2-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 is as follows:
ESP的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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SAT Payload fields are defined as follows:
SAT有效载荷字段定义如下：
o Protocol (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP). A value of zero means that the Protocol field should be ignored.
o 协议（1个八位字节）——描述IP协议ID（例如UDP/TCP）的值。值为零表示应忽略协议字段。
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 isakmpd-registry [ISAKMP-REG].
o SRC ID类型（1个八位字节）——描述在SRC标识数据字段中找到的标识信息的值。定义的值由IANA isakmpd注册表[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 should be ignored.
o SRC ID端口（2个八位字节）——指定与源ID关联的端口的值。值为零表示应忽略SRC ID端口字段。
o SRC ID Data Len (1 octet) -- Value specifying the length 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 three bytes of zero for multiple-source multicast groups that use a common TEK for all senders.
o SRC标识数据（可变长度）——值，由SRC ID类型指示。对于所有发送方使用公共TEK的多个源多播组，将其设置为三个零字节。
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 isakmpd-registry [ISAKMP-REG].
o DST ID类型（1个八位字节）——描述在DST标识数据字段中找到的标识信息的值。定义的值由IANA isakmpd注册表[ISAKMP-REG]中的IPSEC标识类型部分指定。
o DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP). A value of zero means that the DST Id Prot field should be ignored.
o DST ID Prot（1个八位字节）——描述IP协议ID（例如UDP/TCP）的值。值为零表示应忽略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 should be ignored.
o DST ID端口（2个八位字节）——指定与源ID关联的端口的值。值为零表示应忽略DST ID端口字段。
o DST ID Data Len (1 octet) -- Value specifying the length 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 transform is to be used. The list of valid values is defined in the IPSEC ESP Transform Identifiers section of the IANA isakmpd-registry [ISAKMP-REG].
o 转换ID（1个八位字节）——指定要使用哪个ESP转换的值。有效值列表在IANA isakmpd注册表[ISAKMP-REG]的IPSEC ESP转换标识符部分中定义。
o SPI (4 octets) -- Security Parameter Index for ESP.
o SPI（4个八位字节）——ESP的安全参数索引。
o RFC 2407 Attributes -- ESP Attributes from RFC 2407 Section 4.5. The GDOI supports all IPSEC DOI SA Attributes for PROTO_IPSEC_ESP excluding the Group Description [RFC2407, section 4.5], which MUST NOT be sent by a GDOI implementation and is ignored by a GDOI implementation if received. All mandatory IPSEC DOI attributes are mandatory in GDOI PROTO_IPSEC_ESP. The Authentication Algorithm attribute of the IPSEC DOI is group authentication in GDOI.
o RFC 2407属性——RFC 2407第4.5节中的ESP属性。GDOI支持PROTO_IPSEC_ESP的所有IPSEC DOI SA属性，不包括组描述[RFC2407，第4.5节]，该组描述不能由GDOI实现发送，如果收到，GDOI实现将忽略。所有必需的IPSEC DOI属性在GDOI PROTO_IPSEC_ESP中都是必需的。IPSEC DOI的身份验证算法属性在GDOI中是组身份验证。
Besides ESP, 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外，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 The SPI Size o The method of SPI generation o The transforms, attributes and keys needed by the Security Protocol
o 特定安全协议的协议ID o SPI大小o SPI生成方法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 which 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有效负载定义的组的安全策略，对其应用多个安全属性。
When included as part of the Re-key SA with an optional KE payload, The Key Download Payload will be xor'ed with the new Diffie-Hellman shared secret. The xor operation will begin at the "Number of Key Packets" field.
当包含在带有可选KE负载的Re-key SA中时，密钥下载负载将与新的Diffie-Hellman共享秘密异或。异或操作将从“密钥包数”字段开始。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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 both TEK and Rekey arrays being passed in this data block.
o 密钥包数（2个八位字节）——包含在此数据块中传递的TEK和Rekey数组的总数。
o Key Packets 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
RESERVED 4-127
Private Use 128-255
Key Download Type Value
----------------- -----
RESERVED 0
TEK 1
KEK 2
LKH 3
RESERVED 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 an 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 [RFC2408] section 3.3. 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
TEK Class Value Type
--------- ----- ----
RESERVED 0
TEK_ALGORITHM_KEY 1 V
TEK_INTEGRITY_KEY 2 V
TEK_SOURCE_AUTH_KEY 3 V
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 Re-key SA. At least one TEK must be included in each Re-key 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。
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 bit). 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 member. SHA keys will consist of 160 bits, and MD5 keys will consist of 128 bits.
TEK_INTEGRITY_KEY类声明此SPI的完整性密钥包含为密钥包属性。SAT有效负载中指定了将使用此密钥的完整性算法。因此，GDOI假设对称加密和完整性密钥都被推送到成员。SHA密钥将由160位组成，MD5密钥将由128位组成。
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 [RFC2408] section 3.3. 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
KEK Class Value Type
--------- ----- ----
RESERVED 0
KEK_ALGORITHM_KEY 1 V
SIG_ALGORITHM_KEY 2 V
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 Initialization Vector (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 leaves 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 [RFC2408] section 3.3. 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
RESERVED 4-127
Private Use 128-255
KEK Class Value Type
--------- ----- ----
RESERVED 0
LKH_DOWNLOAD_ARRAY 1 V
LKH_UPDATE_ARRAY 2 V
SIG_ALGORITHM_KEY 3 V
RESERVED 4-127
Private Use 128-255
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 !
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The KEK_LKH attribute fields are defined as follows:
KEK_LKH属性字段定义如下：
o LKH version (1 octet) -- Contains the version of the LKH protocol which the data is formatted in. 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o LKH ID (2 octets) -- This is the position of this key in the binary tree structure used by LKH.
o LKH ID（2个八位字节）——这是该键在LKH使用的二叉树结构中的位置。
o Key Type (1 octet) -- This is the 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) -- This is the time value of 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个八位字节）——这是最初生成此密钥数据的时间值。时间值为零表示此键在任何时间之前无效。
o Key Expiration Date (4 octets) -- This is the time value of 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个八位字节）——这是该密钥不再有效使用时的时间值。时间值为零表示此密钥没有过期时间。
o Key Handle (4 octets) -- This is the randomly generated value to uniquely identify a key within an LKH ID.
o 密钥句柄（4个八位字节）——这是随机生成的值，用于唯一标识LKH ID中的密钥。
o Key Data (variable length) -- This is the actual encryption key data, which is dependent on the Key Type algorithm for its format. If the mode of operation for the algorithm requires an Initialization Vector (IV), an explicit IV MUST be included in the Key Data field before 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 Section 5.5.3.1
此属性用于更新组的键。它很可能包含在GROUPKEY-PUSH消息KD有效负载中，以对整个组重新设置密钥。该属性包括一个标题块，后跟一个或多个LKH键，如第5.5.3.1节所定义
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 !
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o LKH version (1 octet) -- Contains the version of the LKH protocol which the data is formatted in. 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.
o 保留（1个八位组）--未使用，设置为零。
o LKH ID (2 octets) -- This is the 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 RESERVED2（2个八位字节）——未使用，设置为零。
o Key Handle (4 octets) -- This is the value to uniquely identify the key within the LKH ID which was used to encrypt the first LKH key.
o 密钥句柄（4个八位字节）——这是用于唯一标识LKH ID中的密钥的值，该ID用于加密第一个LKH密钥。
The LKH Keys are as defined in Section 5.5.3.1. 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键的定义见第5.5.3.1节。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有效负载中指定。
The Sequence Number Payload (SEQ) provides an anti-replay protection for GROUPKEY-PUSH messages. Its use is similar to the Sequence Number field defined in the IPsec ESP protocol [RFC2406].
序列号有效负载（SEQ）为GROUPKEY-PUSH消息提供防重播保护。它的使用类似于IPsec ESP协议[RFC2406]中定义的序列号字段。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
o 有效负载长度（2个八位字节）——当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
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 SA payload. A group member must keep a sliding receive window. The window must be treated as in the ESP protocol [RFC2406] Section 3.4.3.
o 序列号（4个八位字节）——此字段包含组的单调递增计数器值。GCKS将其初始化为零，并在随后发送的每条消息中递增。因此，为给定密钥SA发送的第一个分组将具有序列号1。GDOI实现保留一个序列计数器作为Rekey SA的属性，并在收到GROUPKEY-PUSH消息时增加计数器。序列号的当前值必须作为注册SA有效载荷的一部分传输给组成员。组成员必须保持滑动接收窗口。该窗口必须按照ESP协议[RFC2406]第3.4.3节的规定处理。
The Proof of Possession Payload is used as part of group membership authorization during a GDOI exchange. The Proof of Possession Payload is identical to an ISAKMP SIG payload. However, the usage is entirely different.
在GDOI交换期间，占有证明有效负载用作组成员身份授权的一部分。持有证明有效载荷与ISAKMP SIG有效载荷相同。但是，用法完全不同。
The GCKS, GCKS delegate or member signs a hash of the following values: POP_HASH = hash("pop" | Ni | Nr) Where hash() is the hash function used with the signature.
GCKS、GCKS委托或成员对以下值的哈希进行签名：POP_hash=hash（“POP”| Ni | Nr），其中hash（）是用于签名的哈希函数。
The "pop" prefix ensures that the signature of the POP payload cannot be used for any other purpose in the GDOI protocol.
“pop”前缀确保pop有效负载的签名不能用于GDOI协议中的任何其他目的。
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 bytes.
Nonce有效负载的数据部分（即散列中包含的Ni_b和Nr_b）必须是8到128字节之间的值。
GDOI is a security association (SA) management protocol for groups of senders and receivers. Unlike a data security protocol, SA management includes a key establishment protocol to securely establish keys at communication endpoints. This protocol performs entity authentication of the GDOI member or Group Controller/Key Server (GCKS), it provides confidentiality of key management messages, and it provides source authentication of those messages. This protocol also uses best-known practices for defense against
GDOI是针对发送方和接收方组的安全关联（SA）管理协议。与数据安全协议不同，SA管理包括密钥建立协议，用于在通信端点安全地建立密钥。此协议执行GDOI成员或组控制器/密钥服务器（GCKS）的实体身份验证，它提供密钥管理消息的机密性，并提供这些消息的源身份验证。该协议还使用最著名的实践来防御
man-in-middle, connection hijacking, replay, reflection, and denial-of-service (DOS) attacks on unsecured networks [STS, RFC2522, SKEME]. GDOI assumes the network is not secure and may be under the complete control of an attacker.
中间人，对不安全网络的连接劫持、重播、反射和拒绝服务（DOS）攻击[STS，RFC2522，SKEME]。GDOI假设网络不安全，可能完全处于攻击者的控制之下。
GDOI assumes that the host computer is 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. The security of GDOI, therefore, is as good as the degree to which group members can be trusted to protect authenticators, encryption keys, decryption keys, and message authentication keys.
GDOI假设主机是安全的，即使网络是不安全的。GDOI最终在组成员之间建立密钥，必须信任组成员才能根据组策略以授权的方式使用这些密钥。因此，GDOI的安全性与组成员在保护身份验证器、加密密钥、解密密钥和消息身份验证密钥方面的可信程度一样好。
There are three phases of GDOI as described in this document: an ISAKMP Phase 1 protocol, a new exchange called GROUPKEY-PULL which is protected by the ISAKMP Phase 1 protocol, and a new message called GROUPKEY-PUSH. Each phase is considered separately below.
如本文档所述，GDOI分为三个阶段：ISAKMP第1阶段协议、受ISAKMP第1阶段协议保护的名为GROUPKEY-PULL的新交换以及名为GROUPKEY-PUSH的新消息。下面分别考虑每个阶段。
As described in this document, 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 [FS00], such as identity exposure, absence of unidirectional authentication, or stateful cookies [PK01]. GDOI could benefit, however, from improvements to its ancestor protocols just as it benefits from years of experience and work embodied in those protocols. To reap the benefits of future IKE improvements, however, GDOI would need to be revised in a future standards-track RFC, which is beyond the scope of this specification.
GDOI可能继承其祖先协议[FS00]的问题，例如身份暴露、缺少单向身份验证或有状态cookie[PK01]。然而，GDOI可以从对其祖先协议的改进中获益，就像它从这些协议中体现的多年经验和工作中获益一样。然而，为了从未来的IKE改进中获益，GDOI需要在未来的标准跟踪RFC中进行修订，这超出了本规范的范围。
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 send 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 denial of service 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 denial of service 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, but stateless cookies are a better defense against denial of service attacks.
拒绝服务攻击者向GDOI实体发送消息，使该实体执行不必要的消息身份验证操作。GDOI使用阶段1 cookie机制在加密哈希处理之前识别虚假消息。这是一种“弱”形式的拒绝服务保护，因为GDOI实体必须检查良好的Cookie，成熟的攻击者可以成功模仿这些Cookie。阶段1 cookie机制是有状态的，并为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已知的秘密。这可以防止中间人攻击和连接劫持攻击，因为攻击者无法在未被发现的情况下更改消息。
Nonces provide freshness of the GROUPKEY-PULL exchange. The group member and GCKS exchange nonce values first two messages. These nonces are included in subsequent HASH payload calculations. The Group member and GCKS MUST 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) until it receives the third message in the exchange with a valid HASH payload including its own nonce.
nonce提供了GROUPKEY-PULL交换的新鲜度。组成员和GCK交换前两条消息的nonce值。这些nonce包含在后续哈希有效负载计算中。在收到包含自身nonce的哈希之前，组成员和GCK不得执行任何计算开销大的任务。GCKS在收到交换中的第三条消息以及包含其自身nonce的有效哈希有效负载之前，不得更新组管理状态（例如，LKH密钥树）。
Implementations SHOULD keep a record of recently received GROUPKEY-PULL messages and reject messages that have already been processed. This enables an early discard of the replayed messages.
实现应保留最近收到的GROUPKEY-PULL消息的记录，并拒绝已处理的消息。这样可以提前放弃重播的消息。
A GROUPKEY-PULL message identifies its messages using a cookie pair from the Phase 1 exchange that precedes it. The cookies provide a weak form of denial of service protection as described above, in the sense that a GROUPKEY-PULL message with invalid cookies will be discarded.
GROUPKEY-PULL消息使用其前面的阶段1交换中的cookie对来标识其消息。Cookie提供了一种弱形式的拒绝服务保护，如上所述，即带有无效Cookie的GROUPKEY-PULL消息将被丢弃。
The replay protection mechanisms described above provide the basis for denial of service protection.
上述重播保护机制为拒绝服务保护提供了基础。
The CERT payload in a GROUPKEY-PULL exchange allows a group member or GCKS to submit a certificate containing authorization attributes to the peer as well as identifying a public/private key pair. The GROUPKEY-PULL POP payload enables authorization to be accomplished where the authorization infrastructure is different than the GROUPKEY-PULL authentication infrastructure by proving that it is in possession of the private key.
GROUPKEY-PULL交换中的证书有效载荷允许组成员或GCK向对等方提交包含授权属性的证书，并标识公钥/私钥对。GROUPKEY-PULL POP有效负载通过证明授权基础结构与GROUPKEY-PULL身份验证基础结构拥有私钥而实现授权。
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 provides an efficient rekey and group membership adjustment capability.
GROUPKEY-PUSH交换是允许GCKS向组成员发送SA和密钥的单一消息。这可能会发送给使用IP多播组的所有成员。这提供了有效的密钥更新和组成员资格调整功能。
The GROUPKEY-PULL exchange identifies 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 or its delegate. This digital signature provides source authentication for the message. Thus, GDOI protects the GCKS from impersonation in group environments.
GROUPKEY-PULL交换标识用于消息身份验证的公钥。GROUPKEY-PUSH消息使用GCKS或其代表持有的相应私钥进行数字签名。此数字签名为消息提供源身份验证。因此，GDOI保护GCK在组环境中不被模仿。
The GCKS encrypts the GROUPKEY-PUSH message with an encryption key that was established by the GROUPKEY-PULL exchange.
GCKS使用GROUPKEY-PULL交换建立的加密密钥对GROUPKEY-PUSH消息进行加密。
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 recognize a replayed message by comparing the sequence number to a sliding window, in the same manner as the ESP protocol uses sequence numbers.
GROUPKEY-PUSH消息包含一个单调递增的序列号，以防止重播和反射攻击。组成员将通过将序列号与滑动窗口进行比较来识别重播的消息，与ESP协议使用序列号的方式相同。
Implementations SHOULD keep a record of recently received GROUPKEY-PUSH messages and reject duplicate messages. 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 denial-of-service protection for the GROUPKEY-PUSH message.
cookie对标识GROUPKEY-PUSH消息的安全关联。因此，Cookie是GROUPKEY-PUSH消息的一种弱形式的拒绝服务保护。
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 denial of service 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.
用于消息身份验证的数字签名比消息身份验证代码具有更大的计算成本，并且可能会放大拒绝服务攻击对处理GROUPKEY-PUSH消息的GDOI成员的影响。需要防止GCKS模拟，这就证明了数字签名增加的成本是合理的：如果使用共享对称密钥进行GROUPKEY-PUSH消息身份验证，则不可能进行GCKS源身份验证，任何成员都可以进行GCKS模拟。
The potential of the digital signature amplifying a denial of service 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 replay window. Only if the sequence number is valid is the digital signature verified. Thus in order for a denial of service 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 denial of service attack.
数字签名放大拒绝服务攻击的可能性通过组成员采取的操作顺序得到缓解，其中首先执行的是成本最低的加密操作。组成员首先使用对称密码解密消息。如果是有效格式的消息，则根据重播窗口检查序列号。只有序列号有效，才能验证数字签名。因此，为了发起拒绝服务攻击，攻击者需要知道用于保密的对称加密密钥和有效序列号。一般来说，这意味着只有当前组成员才能有效地部署拒绝服务攻击。
If a group management algorithm (such as LKH) is used, forward access control may not be ensured in some cases. This can happen if some group members are denied access to the group in the same GROUPKEY-PUSH message as new policy and TEKs are delivered to the group. As discussed in Section 4.2.1, forward access control can be maintained by sending multiple GROUPKEY-PUSH messages, where the group membership changes are sent from the GCKS separate from the new policy and TEKs.
如果使用组管理算法（如LKH），则在某些情况下可能无法确保前向访问控制。如果在新策略和TEK交付给组时，在同一GROUPKEY-PUSH消息中拒绝某些组成员访问该组，则可能会发生这种情况。如第4.2.1节所述，可通过发送多个GROUPKEY-PUSH消息来维护前向访问控制，其中，组成员身份更改从GCK发送，与新策略和TEK分开。
An ISAKMP DOI number is needed to identify an SA payload as a GDOI SA payload. The IANA has assigned the value 2 to represent GDOI.
需要ISAKMP DOI号将SA有效负载标识为GDOI SA有效负载。IANA已指定值2表示GDOI。
The present document defines new ISAKMP Next Payload types. See Section 5.0 for the payloads defined in this document, including the Next Payload values defined by the IANA to identify these payloads.
本文档定义了新的ISAKMP Next有效负载类型。参见第5.0节，了解本文件中定义的有效载荷，包括IANA定义的下一个有效载荷值，以识别这些有效载荷。
The present document describes many new name spaces for use in the GDOI payloads. Those may be found in subsections under Section 5.0. A new GDOI registry has been created for these name spaces.
本文档描述了GDOI有效负载中使用的许多新名称空间。这些可在第5.0节的小节中找到。已经为这些名称空间创建了一个新的GDOI注册表。
Portions of name spaces marked "RESERVED" are reserved for IANA allocation. New values MUST be added due to a Standards Action as defined in [RFC2434].
标记为“保留”的名称空间部分保留用于IANA分配。由于[RFC2434]中定义的标准操作，必须添加新值。
Portions of name spaces marked "Private Use" may be allocated by implementations for their own purposes.
标记为“Private Use”的部分名称空间可以由实现分配，以用于它们自己的目的。
The IANA has assigned port 848 for use by GDOI.
IANA已分配848端口供GDOI使用。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
The authors thank Ran Canetti, Cathy Meadows, Andrea Colegrove, and Lakshminath Dondeti. Ran has advised the authors on secure group cryptography, which has led to changes in the exchanges and payload definitions. Cathy identified several problems in previous versions of this document, including a replay attack against the proof of possession exchange, as well as several man-in-the-middle attacks. Andrea contributed to the group policy section of this document. Lakshminath identified several protocol issues that needed further specification and helped to resolve them.
作者感谢兰·卡内蒂、凯西·梅多斯、安德里亚·科尔格罗夫和拉克希米纳·唐德蒂。Ran为作者提供了安全组加密方面的建议，这导致了交换和有效负载定义的变化。Cathy在该文档的早期版本中发现了几个问题，包括针对占有证据交换的重放攻击，以及几个中间人攻击。Andrea参与了本文件的集团政策部分。Lakshminath发现了几个需要进一步规范的协议问题，并帮助解决了这些问题。
[AES-MODES] "Recommendation for Block Cipher Modes of Operation", United States of American, National Institute of Science and Technology, NIST Special Publication 800-38A 2001 Edition, December 2001.
[AES-MODES]“分组密码操作模式建议”，美国国家科学技术研究院，NIST特别出版物800-38A 2001年版，2001年12月。
[FIPS46-3] "Data Encryption Standard (DES)", United States of American, 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 American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 81, December 1980.
[FIPS81]“DES操作模式”，美利坚合众国，国家科学技术研究所，联邦信息处理标准（FIPS）81，1980年12月。
[FIPS186-2] "Digital Signature Standard (DSS)", United States of American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 186-2, January 2000.
[FIPS186-2]“数字签名标准（DSS）”，美利坚合众国，国家科学技术研究所，联邦信息处理标准（FIPS）186-22000年1月。
[FIPS197] "Advanced Encryption Standard (AES)", United States of American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 197, November 2001.
[FIPS197]“高级加密标准（AES）”，美国国家科学技术研究所，联邦信息处理标准（FIPS）197，2001年11月。
[IPSEC-REG] http://www.iana.org/assignments/ipsec-registry
[IPSEC-REG] http://www.iana.org/assignments/ipsec-registry
[ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry
[ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2407] Piper, D., "The Internet IP Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP域”，RFC 2407，1998年11月。
[RFC2408] Maughan, D., Shertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Shertler，M.，Schneider，M.和J.Turner，“互联网安全协会和密钥管理协议”，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月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]Orman，H.，“奥克利密钥确定协议”，RFC 2412，1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522]Karn，P.和W.Simpson，“Photuris：会话密钥管理协议”，RFC 2522，1999年3月。
[RFC2627] Wallner, D., Harder, E. and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, September 1998.
[RFC2627]Wallner，D.，Harder，E.和R.Agee，“多播的密钥管理：问题和架构”，RFC 2627，1998年9月。
[RSA] RSA Laboratories, "PKCS #1 v2.0: RSA Encryption Standard", October 1998.
[RSA]RSA实验室，“PKCS#1 v2.0：RSA加密标准”，1998年10月。
[FS00] N. Ferguson and B. Schneier, "A Cryptographic Evaluation of IPsec, CounterPane", http://www.counterpane.com/ipsec.html.
[FS00]N.Ferguson和B.Schneier，“IPsec的加密评估，对策”，http://www.counterpane.com/ipsec.html.
[GKMARCH] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, "Group Key Management Architecture", Work in Progress.
[GKParch]M.Baugher，R.Canetti，L.Dondeti，F.Lindholm，“组密钥管理架构”，正在进行的工作。
[IKEv2] D. Harkins, et. al., "Proposal for the IKEv2 protocol", Work In Progress.
[IKEv2]D.Harkins等人，“IKEv2议定书提案”，正在进行的工作。
[KINK] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", Work in Progress.
[KINK]M.Thomas，J.Vilhuber，“密钥的Kerberized Internet协商（KINK）”，正在进行中。
[NNL] D. Naor, M. Naor and J. Lotspiech, "Revocation and Tracing Schemes for Stateless Receivers", Advances in Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001, pp. 41-62. A full version of the paper appears in http://www.wisdom.weizmann.ac.il/~naor/.
[NNL]D.Naor，M.Naor和J.Lotspiech，“无状态接收者的撤销和跟踪方案”，密码学进展，Crypto'01，Springer Verlag LNCS 21392001，第41-62页。该论文的完整版本出现在http://www.wisdom.weizmann.ac.il/~naor/。
[OFT] D. Mcgrew and A. Sherman, "Key Establishment in Large
Dynamic Groups Using One-Way Function Trees", Manuscript
submitted to IEEE Transactions on Software Engineering.
A full version of the paper
appears in http://download.nai.com/products/media/nai/
misc/oft052098.ps, 1998
[OFT] D. Mcgrew and A. Sherman, "Key Establishment in Large
Dynamic Groups Using One-Way Function Trees", Manuscript
submitted to IEEE Transactions on Software Engineering.
A full version of the paper
appears in http://download.nai.com/products/media/nai/
misc/oft052098.ps, 1998
[PK01] R.Perlman, C.Kaufman, "Analysis of the IPsec Key
Exchange Standard", WET-ICE conference, 2001.
http://sec.femto.org/wetice-2001/papers/radia-paper.pdf
[PK01] R.Perlman, C.Kaufman, "Analysis of the IPsec Key
Exchange Standard", WET-ICE conference, 2001.
http://sec.femto.org/wetice-2001/papers/radia-paper.pdf
[RFC2093] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification," RFC 2093, July 1997.
[RFC2093]Harney，H.和C.Muckenhirn，“组密钥管理协议（GKP）规范”，RFC 2093，1997年7月。
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture," RFC 2094, July 1997.
[RFC2094]Harney，H.和C.Muckenhirn，“组密钥管理协议（GKP）体系结构”，RFC 2094，1997年7月。
[RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367]McDonald，D.，Metz，C.和B.Phan，“PF_密钥管理API，版本2”，RFC 2367，1998年7月。
[RFC3550] Schulzrinne, H., Casner, S., Jacobson, V. and R. Frederick, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, June 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Jacobson，V.和R.Frederick，“RTP：实时应用的传输协议”，RFC 35502003年6月。
[SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", ISOC Secure Networks and Distributed Systems Symposium, San Diego, 1996.
[SKEME]H.Krawczyk，“SKEME：一种通用的互联网安全密钥交换机制”，ISOC安全网络和分布式系统研讨会，圣地亚哥，1996年。
[STS] Diffie, P. van Oorschot, M. J. Wiener, "Authentication and Authenticated Key Exchanges, Designs, Codes and Cryptography", 2, 107-125 (1992), Kluwer Academic Publishers.
[STS]Diffie，P.van Oorschot，M.J.Wiener，“认证和认证密钥交换，设计，代码和加密”，2，107-125（1992），Kluwer学术出版社。
Appendix A: Alternate GDOI Phase 1 protocols
附录A：替代GDOI第1阶段协议
This section describes a manner in which other protocols could be used as GDOI Phase 1 protocols in place of the ISAKMP Phase 1 protocol. However, they are not specified as a part of this document. A separate document MUST be written in order for another protocol to be used as a GDOI Phase 1 protocol.
本节描述了将其他协议用作GDOI第1阶段协议而不是ISAKMP第1阶段协议的方式。但是，它们并未作为本文件的一部分进行规定。为了将另一个协议用作GDOI第1阶段协议，必须编写单独的文档。
Other possible phase 1 protocols are also described in [GKMARCH].
[3]中还描述了其他可能的第1阶段协议。
Any GDOI phase 1 protocol MUST satisfy the requirements specified in Section 2 of this document.
任何GDOI第1阶段协议必须满足本文件第2节规定的要求。
Version 2 of the IKE protocol (IKEv2) is a work in progress [IKEv2]. That protocol seeks to simplify the IKE Phase 1 and Phase 2 protocols, and improve the security of the IKE protocol. An IKEv2 Phase 1 negotiates an IPSEC SA during phase 1, which was not possible in IKE. However, IKEv2 also defines a phase 2 protocol. The phase 2 protocol is protected by the Phase 1, similar in concept to how IKE Quick Mode is protected by the IKE Phase 1 protocols in [RFC2409].
IKE协议（IKEv2）的第2版正在进行中[IKEv2]。该协议旨在简化IKE第1阶段和第2阶段协议，并提高IKE协议的安全性。IKEv2阶段1在阶段1期间协商IPSEC SA，这在IKE中是不可能的。但是，IKEv2还定义了第2阶段协议。第2阶段协议由第1阶段保护，其概念类似于[RFC2409]中IKE快速模式如何由IKE第1阶段协议保护。
IKEv2 may not include a DOI value in the SA payload. However, since GDOI uses a unique port, choice of a phase 2 protocol in the SA payload using a GDOI value is not necessary. It is expected that an IKEv2 Phase 1 protocol definition could be run on the GDOI port. The SA payload in the protocol would be specific to GDOI, or omitted if not needed at all.
IKEv2可能不会在SA有效负载中包含DOI值。但是，由于GDOI使用唯一端口，因此不需要使用GDOI值在SA有效负载中选择阶段2协议。预计IKEv2第1阶段协议定义可以在GDOI端口上运行。协议中的SA有效负载将特定于GDOI，如果根本不需要，则可省略。
The GROUPKEY-PULL protocol would follow the IKEv2 Phase 1 protocol in the same manner as described in this document.
GROUPKEY-PULL协议将遵循IKEv2第1阶段协议，方式与本文档中描述的相同。
A work in progress [KINK] has defined a method of encapsulating an IKE Quick Mode [RFC2409] encapsulated in Kerberos KRB_AP_REQ and KRB_AP_REP payloads. KINK provides a low-latency, computationally inexpensive, easily managed, and cryptographically sound method of setting up IPSec security associations.
正在进行的工作[KINK]定义了一种封装IKE快速模式[RFC2409]的方法，该模式封装在Kerberos KRB_AP_REQ和KRB_AP_REP有效负载中。KINK提供了一种低延迟、计算成本低、易于管理且密码合理的方法来建立IPSec安全关联。
The KINK message format includes a GDOI field in the KINK header. The [KINK] document defines the DOI for the IPSEC DOI.
扭结消息格式在扭结头中包含一个GDOI字段。[KINK]文档定义了IPSEC DOI的DOI。
A new DOI for KINK could be defined which would encapsulate a GROUPKEY-PULL exchange in the Kerberos KRB_AP_REQ and KRB_AP_REP payloads. As such, GDOI would benefit from the computational efficiencies of KINK.
可以为KINK定义一个新的DOI，它将在Kerberos KRB_AP_REQ和KRB_AP_REP有效负载中封装一个GROUPKEY-PULL交换。因此，GDOI将受益于KINK的计算效率。
Authors' Addresses
作者地址
Mark Baugher Cisco Systems 5510 SW Orchid Street Portland, OR 97219, USA
美国波特兰兰花街西南5510号，邮编97219
Phone: (503) 245-4543 EMail: mbaugher@cisco.com
电话：（503）245-4543电子邮件：mbaugher@cisco.com
Thomas Hardjono VeriSign 401 Edgewater Place, Suite 280 Wakefield, MA 01880
马萨诸塞州韦克菲尔德市埃德沃特广场401号托马斯·哈德约诺·威瑞辛公寓280室01880
Phone: 781-245-6996 EMail: thardjono@verisign.com
电话：781-245-6996电子邮件：thardjono@verisign.com
Hugh Harney Sparta 9861 Broken Land Parkway Columbia, MD 21046
休·哈尼·斯巴达9861美国马里兰州哥伦比亚断地公园路21046号
Phone: (410) 381-9400 x203 EMail: hh@sparta.com
电话：（410）381-9400 x203电子邮件：hh@sparta.com
Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706, USA
Brian Weis Cisco Systems美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134-1706
Phone: (408) 526-4796 EMail: bew@cisco.com
电话：（408）526-4796电子邮件：bew@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。