Network Working Group H. Harney
Request for Comments: 4535 U. Meth
Category: Standards Track A. Colegrove
SPARTA, Inc.
G. Gross
IdentAware
June 2006
Network Working Group H. Harney
Request for Comments: 4535 U. Meth
Category: Standards Track A. Colegrove
SPARTA, Inc.
G. Gross
IdentAware
June 2006
GSAKMP: Group Secure Association Key Management Protocol
GSAKMP：组安全关联密钥管理协议
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys.
本文档指定了组安全关联密钥管理协议（GSAKMP）。GSAKMP为在网络上创建和管理加密组提供了一个安全框架。它提供了传播组策略和验证用户的机制、在组建立和恢复期间执行访问控制决策的规则、从组成员的危害中恢复的能力、组安全功能的委派以及销毁组的能力。它还生成组密钥。
Table of Contents
目录
1. Introduction ....................................................7
1.1. GSAKMP Overview ............................................7
1.2. Document Organization ......................................9
2. Terminology .....................................................9
3. Security Considerations ........................................12
3.1. Security Assumptions ......................................12
3.2. Related Protocols .........................................13
3.2.1. ISAKMP .............................................13
3.2.2. FIPS Pub 196 .......................................13
3.2.3. LKH ................................................13
3.2.4. Diffie-Hellman .....................................14
3.3. Denial of Service (DoS) Attack ............................14
3.4. Rekey Availability ........................................14
3.5. Proof of Trust Hierarchy ..................................15
4. Architecture ...................................................15
4.1. Trust Model ...............................................15
4.1.1. Components .........................................15
4.1.2. GO .................................................16
4.1.3. GC/KS ..............................................16
4.1.4. Subordinate GC/KS ..................................17
4.1.5. GM .................................................17
4.1.6. Assumptions ........................................18
4.2. Rule-Based Security Policy ................................18
4.2.1. Access Control .....................................19
4.2.2. Authorizations for Security-Relevant Actions .......20
4.3. Distributed Operation .....................................20
4.4. Concept of Operation ......................................22
4.4.1. Assumptions ........................................22
4.4.2. Creation of a Policy Token .........................22
4.4.3. Creation of a Group ................................23
4.4.4. Discovery of GC/KS .................................24
4.4.5. GC/KS Registration Policy Enforcement ..............24
4.4.6. GM Registration Policy Enforcement .................24
4.4.7. Autonomous Distributed GSAKMP Operations ...........24
5. Group Life Cycle ...............................................27
5.1. Group Definition ..........................................27
5.2. Group Establishment .......................................27
5.2.1. Standard Group Establishment .......................28
5.2.1.1. Request to Join ...........................30
5.2.1.2. Key Download ..............................31
5.2.1.3. Request to Join Error .....................33
5.2.1.4. Key Download - Ack/Failure ................34
5.2.1.5. Lack of Ack ...............................35
5.2.2. Cookies: Group Establishment with Denial of
Service Protection .................................36
5.2.3. Group Establishment for Receive-Only Members .......39
1. Introduction ....................................................7
1.1. GSAKMP Overview ............................................7
1.2. Document Organization ......................................9
2. Terminology .....................................................9
3. Security Considerations ........................................12
3.1. Security Assumptions ......................................12
3.2. Related Protocols .........................................13
3.2.1. ISAKMP .............................................13
3.2.2. FIPS Pub 196 .......................................13
3.2.3. LKH ................................................13
3.2.4. Diffie-Hellman .....................................14
3.3. Denial of Service (DoS) Attack ............................14
3.4. Rekey Availability ........................................14
3.5. Proof of Trust Hierarchy ..................................15
4. Architecture ...................................................15
4.1. Trust Model ...............................................15
4.1.1. Components .........................................15
4.1.2. GO .................................................16
4.1.3. GC/KS ..............................................16
4.1.4. Subordinate GC/KS ..................................17
4.1.5. GM .................................................17
4.1.6. Assumptions ........................................18
4.2. Rule-Based Security Policy ................................18
4.2.1. Access Control .....................................19
4.2.2. Authorizations for Security-Relevant Actions .......20
4.3. Distributed Operation .....................................20
4.4. Concept of Operation ......................................22
4.4.1. Assumptions ........................................22
4.4.2. Creation of a Policy Token .........................22
4.4.3. Creation of a Group ................................23
4.4.4. Discovery of GC/KS .................................24
4.4.5. GC/KS Registration Policy Enforcement ..............24
4.4.6. GM Registration Policy Enforcement .................24
4.4.7. Autonomous Distributed GSAKMP Operations ...........24
5. Group Life Cycle ...............................................27
5.1. Group Definition ..........................................27
5.2. Group Establishment .......................................27
5.2.1. Standard Group Establishment .......................28
5.2.1.1. Request to Join ...........................30
5.2.1.2. Key Download ..............................31
5.2.1.3. Request to Join Error .....................33
5.2.1.4. Key Download - Ack/Failure ................34
5.2.1.5. Lack of Ack ...............................35
5.2.2. Cookies: Group Establishment with Denial of
Service Protection .................................36
5.2.3. Group Establishment for Receive-Only Members .......39
5.3. Group Maintenance .........................................39
5.3.1. Group Management ...................................39
5.3.1.1. Rekey Events ..............................39
5.3.1.2. Policy Updates ............................40
5.3.1.3. Group Destruction .........................40
5.3.2. Leaving a Group ....................................41
5.3.2.1. Eviction ..................................41
5.3.2.2. Voluntary Departure without Notice ........41
5.3.2.3. De-Registration ...........................41
5.3.2.3.1. Request to Depart ..............41
5.3.2.3.2. Departure_Response .............43
5.3.2.3.3. Departure_ACK ..................44
6. Security Suite .................................................45
6.1. Assumptions ...............................................45
6.2. Definition Suite 1 ........................................45
7. GSAKMP Payload Structure .......................................47
7.1. GSAKMP Header .............................................47
7.1.1. GSAKMP Header Structure ............................47
7.1.1.1. GroupID Structure .........................51
7.1.1.1.1. UTF-8 ..........................51
7.1.1.1.2. Octet String ...................52
7.1.1.1.3. IPv4 Group Identifier ..........52
7.1.1.1.4. IPv6 Group Identifier ..........53
7.1.2. GSAKMP Header Processing ...........................53
7.2. Generic Payload Header ....................................55
7.2.1. Generic Payload Header Structure ...................55
7.2.2. Generic Payload Header Processing ..................56
7.3. Policy Token Payload ......................................56
7.3.1. Policy Token Payload Structure .....................56
7.3.2. Policy Token Payload Processing ....................57
7.4. Key Download Payload ......................................58
7.4.1. Key Download Payload Structure .....................58
7.4.1.1. Key Datum Structure .......................61
7.4.1.2. Rekey Array Structure .....................63
7.4.2. Key Download Payload Processing ....................63
7.5. Rekey Event Payload .......................................64
7.5.1. Rekey Event Payload Structure ......................64
7.5.1.1. Rekey Event Header Structure .............66
7.5.1.2. Rekey Event Data Structure ...............67
7.5.1.2.1. Key Package Structure ..........68
7.5.2. Rekey Event Payload Processing .....................69
7.6. Identification Payload ....................................71
7.6.1. Identification Payload Structure ...................71
7.6.1.1. ID_U_NAME Structure .......................74
7.6.2. Identification Payload Processing ..................74
7.6.2.1. ID_U_NAME Processing ......................75
7.7. Certificate Payload .......................................75
7.7.1. Certificate Payload Structure ......................75
5.3. Group Maintenance .........................................39
5.3.1. Group Management ...................................39
5.3.1.1. Rekey Events ..............................39
5.3.1.2. Policy Updates ............................40
5.3.1.3. Group Destruction .........................40
5.3.2. Leaving a Group ....................................41
5.3.2.1. Eviction ..................................41
5.3.2.2. Voluntary Departure without Notice ........41
5.3.2.3. De-Registration ...........................41
5.3.2.3.1. Request to Depart ..............41
5.3.2.3.2. Departure_Response .............43
5.3.2.3.3. Departure_ACK ..................44
6. Security Suite .................................................45
6.1. Assumptions ...............................................45
6.2. Definition Suite 1 ........................................45
7. GSAKMP Payload Structure .......................................47
7.1. GSAKMP Header .............................................47
7.1.1. GSAKMP Header Structure ............................47
7.1.1.1. GroupID Structure .........................51
7.1.1.1.1. UTF-8 ..........................51
7.1.1.1.2. Octet String ...................52
7.1.1.1.3. IPv4 Group Identifier ..........52
7.1.1.1.4. IPv6 Group Identifier ..........53
7.1.2. GSAKMP Header Processing ...........................53
7.2. Generic Payload Header ....................................55
7.2.1. Generic Payload Header Structure ...................55
7.2.2. Generic Payload Header Processing ..................56
7.3. Policy Token Payload ......................................56
7.3.1. Policy Token Payload Structure .....................56
7.3.2. Policy Token Payload Processing ....................57
7.4. Key Download Payload ......................................58
7.4.1. Key Download Payload Structure .....................58
7.4.1.1. Key Datum Structure .......................61
7.4.1.2. Rekey Array Structure .....................63
7.4.2. Key Download Payload Processing ....................63
7.5. Rekey Event Payload .......................................64
7.5.1. Rekey Event Payload Structure ......................64
7.5.1.1. Rekey Event Header Structure .............66
7.5.1.2. Rekey Event Data Structure ...............67
7.5.1.2.1. Key Package Structure ..........68
7.5.2. Rekey Event Payload Processing .....................69
7.6. Identification Payload ....................................71
7.6.1. Identification Payload Structure ...................71
7.6.1.1. ID_U_NAME Structure .......................74
7.6.2. Identification Payload Processing ..................74
7.6.2.1. ID_U_NAME Processing ......................75
7.7. Certificate Payload .......................................75
7.7.1. Certificate Payload Structure ......................75
7.7.2. Certificate Payload Processing .....................77
7.8. Signature Payload .........................................78
7.8.1. Signature Payload Structure ........................78
7.8.2. Signature Payload Processing .......................80
7.9. Notification Payload ......................................81
7.9.1. Notification Payload Structure .....................81
7.9.1.1. Notification Data - Acknowledgement
(ACK) Payload Type ........................83
7.9.1.2. Notification Data -
Cookie_Required and Cookie Payload Type ...83
7.9.1.3. Notification Data - Mechanism
Choices Payload Type ......................84
7.9.1.4. Notification Data - IPv4 and IPv6
Value Payload Types .......................85
7.9.2. Notification Payload Processing ....................85
7.10. Vendor ID Payload ........................................86
7.10.1. Vendor ID Payload Structure .......................86
7.10.2. Vendor ID Payload Processing ......................87
7.11. Key Creation Payload .....................................88
7.11.1. Key Creation Payload Structure ....................88
7.11.2. Key Creation Payload Processing ...................89
7.12. Nonce Payload ............................................90
7.12.1. Nonce Payload Structure ...........................90
7.12.2. Nonce Payload Processing ..........................91
8. GSAKMP State Diagram ...........................................92
9. IANA Considerations ............................................95
9.1. IANA Port Number Assignment ...............................95
9.2. Initial IANA Registry Contents ............................95
10. Acknowledgements ..............................................96
11. References ....................................................97
11.1. Normative References .....................................97
11.2. Informative References ...................................98
Appendix A. LKH Information ......................................100
A.1. LKH Overview .............................................100
A.2. LKH and GSAKMP ...........................................101
A.3. LKH Examples .............................................102
A.3.1. LKH Key Download Example ..........................102
A.3.2. LKH Rekey Event Example ..........................103
7.7.2. Certificate Payload Processing .....................77
7.8. Signature Payload .........................................78
7.8.1. Signature Payload Structure ........................78
7.8.2. Signature Payload Processing .......................80
7.9. Notification Payload ......................................81
7.9.1. Notification Payload Structure .....................81
7.9.1.1. Notification Data - Acknowledgement
(ACK) Payload Type ........................83
7.9.1.2. Notification Data -
Cookie_Required and Cookie Payload Type ...83
7.9.1.3. Notification Data - Mechanism
Choices Payload Type ......................84
7.9.1.4. Notification Data - IPv4 and IPv6
Value Payload Types .......................85
7.9.2. Notification Payload Processing ....................85
7.10. Vendor ID Payload ........................................86
7.10.1. Vendor ID Payload Structure .......................86
7.10.2. Vendor ID Payload Processing ......................87
7.11. Key Creation Payload .....................................88
7.11.1. Key Creation Payload Structure ....................88
7.11.2. Key Creation Payload Processing ...................89
7.12. Nonce Payload ............................................90
7.12.1. Nonce Payload Structure ...........................90
7.12.2. Nonce Payload Processing ..........................91
8. GSAKMP State Diagram ...........................................92
9. IANA Considerations ............................................95
9.1. IANA Port Number Assignment ...............................95
9.2. Initial IANA Registry Contents ............................95
10. Acknowledgements ..............................................96
11. References ....................................................97
11.1. Normative References .....................................97
11.2. Informative References ...................................98
Appendix A. LKH Information ......................................100
A.1. LKH Overview .............................................100
A.2. LKH and GSAKMP ...........................................101
A.3. LKH Examples .............................................102
A.3.1. LKH Key Download Example ..........................102
A.3.2. LKH Rekey Event Example ..........................103
List of Figures
数字一览表
1 GSAKMP Ladder Diagram .........................................28
2 GSAKMP Ladder Diagram with Cookies ............................37
3 GSAKMP Header Format ..........................................47
4 GroupID UTF-8 Format ..........................................51
5 GroupID Octet String Format ...................................52
6 GroupID IPv4 Format ...........................................52
7 GroupID IPv6 Format ...........................................53
8 Generic Payload Header ........................................55
9 Policy Token Payload Format ...................................56
10 Key Download Payload Format ...................................58
11 Key Download Data Item Format .................................59
12 Key Datum Format ..............................................61
13 Rekey Array Structure Format ..................................63
14 Rekey Event Payload Format ....................................64
15 Rekey Event Header Format .....................................66
16 Rekey Event Data Format .......................................68
17 Key Package Format ............................................68
18 Identification Payload Format .................................72
19 Unencoded Name (ID-U-NAME) Format .............................74
20 Certificate Payload Format ....................................76
21 Signature Payload Format ......................................78
22 Notification Payload Format ...................................81
23 Notification Data - Acknowledge Payload Type Format ...........83
24 Notification Data - Mechanism Choices Payload Type Format......84
25 Vendor ID Payload Format ......................................86
26 Key Creation Payload Format ...................................88
27 Nonce Payload Format ..........................................90
28 GSAKMP State Diagram ..........................................92
29 LKH Tree .....................................................100
30 GSAKMP LKH Tree ..............................................101
1 GSAKMP Ladder Diagram .........................................28
2 GSAKMP Ladder Diagram with Cookies ............................37
3 GSAKMP Header Format ..........................................47
4 GroupID UTF-8 Format ..........................................51
5 GroupID Octet String Format ...................................52
6 GroupID IPv4 Format ...........................................52
7 GroupID IPv6 Format ...........................................53
8 Generic Payload Header ........................................55
9 Policy Token Payload Format ...................................56
10 Key Download Payload Format ...................................58
11 Key Download Data Item Format .................................59
12 Key Datum Format ..............................................61
13 Rekey Array Structure Format ..................................63
14 Rekey Event Payload Format ....................................64
15 Rekey Event Header Format .....................................66
16 Rekey Event Data Format .......................................68
17 Key Package Format ............................................68
18 Identification Payload Format .................................72
19 Unencoded Name (ID-U-NAME) Format .............................74
20 Certificate Payload Format ....................................76
21 Signature Payload Format ......................................78
22 Notification Payload Format ...................................81
23 Notification Data - Acknowledge Payload Type Format ...........83
24 Notification Data - Mechanism Choices Payload Type Format......84
25 Vendor ID Payload Format ......................................86
26 Key Creation Payload Format ...................................88
27 Nonce Payload Format ..........................................90
28 GSAKMP State Diagram ..........................................92
29 LKH Tree .....................................................100
30 GSAKMP LKH Tree ..............................................101
List of Tables
表格一览表
1 Request to Join (RTJ) Message Definition ......................30
2 Key Download (KeyDL) Message Definition .......................31
3 Request to Join Error (RTJ-Err) Message Definition ............33
4 Key Download - Ack/Failure (KeyDL-A/F) Message Definition .....34
5 Lack of Ack (LOA) Message Definition ..........................35
6 Cookie Download Message Definition ............................37
7 Rekey Event Message Definition ................................40
8 Request_to_Depart (RTD) Message Definition ....................42
9 Departure_Response (DR) Message Definition ....................43
10 Departure_ACK (DA) Message Definition .........................44
11 Group Identification Types ....................................48
12 Payload Types .................................................49
13 Exchange Types ................................................49
14 Policy Token Types ............................................57
15 Key Download Data Item Types ..................................60
16 Cryptographic Key Types .......................................62
17 Rekey Event Types .............................................66
18 Identification Classification .................................72
19 Identification Types ..........................................73
20 Certificate Payload Types .....................................77
21 Signature Types ...............................................79
22 Notification Types ............................................82
23 Acknowledgement Types .........................................83
24 Mechanism Types ...............................................84
25 Nonce Hash Types ..............................................85
26 Types Of Key Creation Information .............................89
27 Nonce Types ...................................................91
28 GSAKMP States .................................................93
29 State Transition Events .......................................94
1 Request to Join (RTJ) Message Definition ......................30
2 Key Download (KeyDL) Message Definition .......................31
3 Request to Join Error (RTJ-Err) Message Definition ............33
4 Key Download - Ack/Failure (KeyDL-A/F) Message Definition .....34
5 Lack of Ack (LOA) Message Definition ..........................35
6 Cookie Download Message Definition ............................37
7 Rekey Event Message Definition ................................40
8 Request_to_Depart (RTD) Message Definition ....................42
9 Departure_Response (DR) Message Definition ....................43
10 Departure_ACK (DA) Message Definition .........................44
11 Group Identification Types ....................................48
12 Payload Types .................................................49
13 Exchange Types ................................................49
14 Policy Token Types ............................................57
15 Key Download Data Item Types ..................................60
16 Cryptographic Key Types .......................................62
17 Rekey Event Types .............................................66
18 Identification Classification .................................72
19 Identification Types ..........................................73
20 Certificate Payload Types .....................................77
21 Signature Types ...............................................79
22 Notification Types ............................................82
23 Acknowledgement Types .........................................83
24 Mechanism Types ...............................................84
25 Nonce Hash Types ..............................................85
26 Types Of Key Creation Information .............................89
27 Nonce Types ...................................................91
28 GSAKMP States .................................................93
29 State Transition Events .......................................94
GSAKMP provides policy distribution, policy enforcement, key distribution, and key management for cryptographic groups. Cryptographic groups all share a common key (or set of keys) for data processing. These keys all support a system-level security policy so that the cryptographic group can be trusted to perform security-relevant services.
GSAKMP为加密组提供策略分发、策略实施、密钥分发和密钥管理。加密组都共享一个用于数据处理的公共密钥（或一组密钥）。这些密钥都支持系统级安全策略，因此可以信任加密组执行安全相关服务。
The ability of a group of entities to perform security services requires that a Group Secure Association (GSA) be established. A GSA ensures that there is a common "group-level" definition of security policy and enforcement of that policy. The distribution of cryptographic keys is a mechanism utilizing the group-level policy enforcements.
一组实体执行安全服务的能力要求建立一个组安全关联（GSA）。GSA确保对安全策略和该策略的实施有一个通用的“集团级”定义。加密密钥的分发是一种利用组级策略实施的机制。
Protecting group information requires the definition of a security policy and the enforcement of that policy by all participating parties. Controlling dissemination of cryptographic key is the primary mechanism to enforce the access control policy. It is the primary purpose of GSAKMP to generate and disseminate a group key in a secure fashion.
保护组信息需要定义安全策略并由所有参与方强制执行该策略。控制加密密钥的分发是实施访问控制策略的主要机制。GSAKMP的主要目的是以安全的方式生成和分发组密钥。
GSAKMP separates group security management functions and responsibilities into three major roles:1) Group Owner, 2) Group Controller Key Server, and 3) Group Member. The Group Owner is responsible for creating the security policy rules for a group and expressing these in the policy token. The Group Controller Key Server (GC/KS) is responsible for creating and maintaining the keys and enforcing the group policy by granting access to potential Group Members (GMs) in accordance with the policy token. To enforce a group's policy, the potential Group Members need to have knowledge of the access control policy for the group, an unambiguous identification of any party downloading keys to them, and verifiable chains of authority for key download. In other words, the Group Members need to know who potentially will be in the group and to verify that the key disseminator is authorized to act in that capacity.
GSAKMP将组安全管理职能和职责分为三个主要角色：1）组所有者、2）组控制器密钥服务器和3）组成员。组所有者负责为组创建安全策略规则，并在策略令牌中表示这些规则。组控制器密钥服务器（GC/KS）负责创建和维护密钥，并通过根据策略令牌授予潜在组成员（GMs）访问权限来实施组策略。为了实施组的策略，潜在组成员需要了解组的访问控制策略、下载密钥的任何一方的明确身份，以及密钥下载的可验证权限链。换句话说，小组成员需要知道谁可能会在小组中，并验证关键传播者是否有权以该身份行事。
In order to establish a Group Secure Association (GSA) to support these activities, the identity of each party in the process MUST be unambiguously asserted and authenticated. It MUST also be verified that each party is authorized, as defined by the policy token, to function in his role in the protocol (e.g., GM or GC/KS).
为了建立一个组安全关联（GSA）来支持这些活动，必须明确声明和验证过程中各方的身份。还必须验证，根据策略令牌的定义，各方被授权在协议中发挥其作用（例如，GM或GC/KS）。
The security features of the establishment protocol for the GSA include
GSA建立协议的安全特性包括
- Group policy identification
- 组策略标识
- Group policy dissemination
- 集团政策传播
- GM to GC/KS SA establishment to protect data
- 总经理向GC/KS SA部门提交数据保护报告
- Access control checking
- 访问控制检查
GSAKMP provides mechanisms for cryptographic group creation and management. Other protocols may be used in conjunction with GSAKMP to allow various applications to create functional groups according to their application-specific requirements. For example, in a small-scale video conference, the organizer might use a session invitation protocol like SIP [RFC3261] to transmit information about the time of the conference, the address of the session, and the formats to be used. For a large-scale video transmission, the organizer might use a multicast announcement protocol like SAP [RFC2974].
GSAKMP为加密组的创建和管理提供了机制。其他协议可与GSAKMP结合使用，以允许各种应用程序根据其特定于应用程序的需求创建功能组。例如，在小型视频会议中，组织者可以使用会话邀请协议（如SIP[rfc326]）来传输关于会议时间、会话地址和要使用的格式的信息。对于大规模视频传输，组织者可以使用类似SAP[RFC2974]的多播公告协议。
This document describes a useful default set of security algorithms and configurations, Security Suite 1. This suite allows an entire set of algorithms and settings to be described to prospective group members in a concise manner. Other security suites MAY be defined as needed and MAY be disseminated during the out-of-band announcement of a group.
本文档描述了一组有用的默认安全算法和配置，即安全套件1。该套件允许以简洁的方式向潜在的团队成员描述一整套算法和设置。其他安全套件可根据需要进行定义，并可在集团带外公告期间发布。
Distributed architectures support large-scale cryptographic groups. Secure distributed architectures require authorized delegation of GSA actions to network resources. The fully specified policy token is the mechanism to facilitate this authorization. Transmission of this policy token to all joining GMs allows GSAKMP to securely support distributed architectures and multiple data sources.
分布式体系结构支持大规模加密组。安全的分布式体系结构要求授权GSA操作到网络资源。完全指定的策略令牌是促进此授权的机制。将此策略令牌传输到所有加入的GMs允许GSAKMP安全地支持分布式体系结构和多个数据源。
Many-to-many group communications require multiple data sources. Multiple data sources are supported because the inclusion of a policy token and policy payloads allow group members to review the group access control and authorization parameters. This member review process gives each member (each potential source of data) the ability to determine if the group provides adequate protection for member data.
多对多组通信需要多个数据源。支持多个数据源，因为包含策略令牌和策略有效负载允许组成员查看组访问控制和授权参数。该成员审查流程使每个成员（每个潜在数据源）能够确定集团是否为成员数据提供了充分的保护。
The remainder of this document is organized as follows:Section 2 presents the terminology and concepts used to present the requirements of this protocol. Section 3 outlines the security considerations with respect to GSAKMP. Section 4 defines the architecture of GSAKMP. Section 5 describes the group management life cycle. Section 6 describes the Security Suite Definition. Section 7 presents the message types and formats used during each phase of the life cycle. Section 8 defines the state diagram for the protocol.
本文件的其余部分组织如下：第2节介绍了用于说明本协议要求的术语和概念。第3节概述了有关GSAKMP的安全注意事项。第4节定义了GSAKMP的体系结构。第5节描述了集团管理生命周期。第6节描述了安全套件的定义。第7节介绍了生命周期每个阶段使用的消息类型和格式。第8节定义了协议的状态图。
The following terminology is used throughout this document.
本文件中使用了以下术语。
Requirements Terminology: Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119].
要求术语：本文件中出现的关键词“必须”、“不得”、“必需”、“应该”、“不应该”和“可能”应按照[RFC2119]中所述进行解释。
Certificate: A data structure used to verifiably bind an identity to a cryptographic key (e.g., X.509v3).
证书：用于可验证地将身份绑定到加密密钥的数据结构（如X.509v3）。
Compromise Recovery: The act of recovering a secure operating state after detecting that a group member cannot be trusted. This can be accomplished by rekey.
折衷恢复：检测到组成员不可信后恢复安全操作状态的行为。这可以通过重新设置密钥来实现。
Cryptographic Group: A set of entities sharing or desiring to share a GSA.
加密组：共享或希望共享GSA的一组实体。
Group Controller Key Server (GC/KS): A group member with authority to perform critical protocol actions including creating and distributing keys and building and maintaining the rekey structures. As the group evolves, it MAY become desirable to have multiple controllers perform these functions.
组控制器密钥服务器（GC/KS）：有权执行关键协议操作的组成员，包括创建和分发密钥以及构建和维护密钥更新结构。随着团队的发展，可能需要多个控制器来执行这些功能。
Group Member (GM): A Group Member is any entity with access to the group keys. Regardless of how a member becomes a part of the group or how the group is structured, GMs will perform the following actions:
组成员（GM）：组成员是可以访问组密钥的任何实体。无论成员如何成为集团的一部分或集团的结构如何，GMs都将执行以下操作：
- Authenticate and validate the identities and the authorizations of entities performing security-relevant actions
- 验证和验证执行安全相关操作的实体的身份和授权
- Accept group keys from the GC/KS
- 从GC/KS接受组密钥
- Request group keys from the GC/KS
- 从GC/KS请求组密钥
- Enforce the cooperative group policies as stated in the group policy token
- 强制执行组策略令牌中所述的协作组策略
- Perform peer review of key management actions
- 对关键管理措施进行同行评审
- Manage local key
- 管理本地密钥
Group Owner (GO): A Group Owner is the entity authorized for generating and modifying an authenticatable policy token for the group, and notifying the GC/KS to start the group.
组所有者（GO）：组所有者是被授权为组生成和修改可验证策略令牌并通知GC/KS启动组的实体。
Group Policy: The Group Policy completely describes the protection mechanisms and security-relevant behaviors of the group. This policy MUST be commonly understood and enforced by the group for coherent secure operations.
组策略：组策略完全描述组的保护机制和安全相关行为。该政策必须得到集团的普遍理解和执行，以实现一致的安全运营。
Group Secure Association (GSA): A GSA is a logical association of users or hosts that share cryptographic key(s). This group may be established to support associations between applications or communication protocols.
组安全关联（GSA）：GSA是共享加密密钥的用户或主机的逻辑关联。可以建立该组以支持应用程序或通信协议之间的关联。
Group Traffic Protection Key (GTPK): The key or keys created for protecting the group data.
组流量保护密钥（GTPK）：为保护组数据而创建的一个或多个密钥。
Key Datum: A single key and its associated attributes for its usage.
关键点数据：单个关键点及其使用的相关属性。
Key Encryption Key (KEK): Key used in an encryption mechanism for wrapping another key.
密钥加密密钥（KEK）：加密机制中用于包装另一个密钥的密钥。
Key Handle: The identifier of a particular instance or version of a key.
密钥句柄：特定实例或密钥版本的标识符。
Key ID: The identifier for a key that MUST stay static throughout the life cycle of this key.
密钥ID：在该密钥的整个生命周期内必须保持静态的密钥的标识符。
Key Package: Type/Length/Data format containing a Key Datum.
密钥包：包含密钥数据的类型/长度/数据格式。
Logical Key Hierarchy (LKH) Array: The group of keys created to facilitate the LKH compromise recovery methodology.
逻辑密钥层次结构（LKH）阵列：为促进LKH折衷恢复方法而创建的密钥组。
Policy Token (PT): The policy token is a data structure used to disseminate group policy and the mechanisms to enforce it. The policy token is issued and signed by an authorized Group Owner. Each member of the group MUST verify the token, meet the group join policy, and enforce the policy of the group (e.g., encrypt application data with a specific algorithm). The group policy token will contain a variety of information including:
策略令牌（PT）：策略令牌是用于传播组策略及其实施机制的数据结构。策略令牌由授权的组所有者颁发和签名。组的每个成员都必须验证令牌，满足组加入策略，并实施组的策略（例如，使用特定算法加密应用程序数据）。组策略令牌将包含各种信息，包括：
- GSAKMP protocol version
- GSAKMP协议版本
- Key creation method
- 密钥创建方法
- Key dissemination policy
- 关键传播政策
- Access control policy
- 访问控制策略
- Group authorization policy
- 组授权策略
- Compromise recovery policy
- 折衷恢复政策
- Data protection mechanisms
- 数据保护机制
Rekey: The act of changing keys within a group as defined by policy.
重新设置密钥：在策略定义的组内更改密钥的行为。
Rekey Array: The construct that contains all the rekey information for a particular member.
重新设置密钥数组：包含特定成员的所有重新设置密钥信息的构造。
Rekey Key: The KEK used to encrypt keys for a subset of the group.
Rekey Key：用于加密组子集密钥的KEK。
Subordinate Group Controller Key Server (S-GC/KS): Any group member having the appropriate processing and trust characteristics, as defined in the group policy, that has the potential to act as a S-GC/KS. This will allow the group processing and communication requirements to be distributed equitably throughout the network (e.g., distribute group key). The optional use of GSAKMP with Subordinate Group Controller Key Servers will be documented in a separate paper.
从属组控制器密钥服务器（S-GC/KS）：具有适当处理和信任特征的任何组成员，如组策略中所定义，有可能充当S-GC/KS。这将允许在整个网络中公平分配组处理和通信需求（例如，分配组密钥）。GSAKMP与下属集团控制器密钥服务器的可选使用将在单独的文件中记录。
Wrapping KeyID: The Key ID of the key used to wrap a Key Package.
包装密钥ID：用于包装密钥包的密钥的密钥ID。
Wrapping Key Handle: The key handle of the key used to wrap the Key Package.
包裹密钥句柄：用于包裹密钥包的密钥的密钥句柄。
In addition to the specification of GSAKMP itself, the security of an implemented GSAKMP system is affected by supporting factors. These are discussed here.
除了GSAKMP本身的规范外，已实施GSAKMP系统的安全性还受到支持因素的影响。这里讨论这些问题。
The following assumptions are made as the basis for the security discussion:
以下假设作为安全讨论的基础：
1. GSAKMP assumes its supporting platform can provide the process and data separation services at the appropriate assurance level to support its groups.
1. GSAKMP假设其支持平台能够在适当的保证级别提供流程和数据分离服务，以支持其团队。
2. The key generation function of the cryptographic engine will only generate strong keys.
2. 加密引擎的密钥生成功能将只生成强密钥。
3. The security of this protocol is critically dependent on the randomness of the randomly chosen parameters. These should be generated by a strong random or properly seeded pseudo-random source [RFC4086].
3. 该协议的安全性主要取决于随机选择的参数的随机性。这些应该由强随机或正确播种的伪随机源生成[RFC4086]。
4. The security of a group can be affected by the accuracy of the system clock. Therefore, GSAKMP assumes that the system clock is close to correct time. If a GSAKMP host relies on a network time service to set its local clock, then that protocol must be secure against attackers. The maximum allowable clock skew across the group membership is policy configurable, with a default of 5 minutes.
4. 系统时钟的准确性会影响组的安全性。因此，GSAKMP假设系统时钟接近正确时间。如果GSAKMP主机依赖网络时间服务来设置其本地时钟，则该协议必须安全，不受攻击者攻击。组成员资格中允许的最大时钟偏差是策略可配置的，默认值为5分钟。
5. As described in the message processing section, the use of the nonce value used for freshness along with a signature is the mechanism used to foil replay attacks. In any use of nonces, a core requirement is unpredictability of the nonce, from an attacker's viewpoint. The utility of the nonce relies on the inability of an attacker either to reuse old nonces or to predict the nonce value.
5. 如消息处理部分所述，将用于新鲜度的nonce值与签名一起使用是用于抵御重播攻击的机制。在任何使用nonce的情况下，从攻击者的角度来看，核心需求是nonce的不可预测性。nonce的效用取决于攻击者无法重用旧nonce或预测nonce值。
6. GSAKMP does not provide identity protection.
6. GSAKMP不提供身份保护。
7. The group's multicast routing infrastructure is not secured by GSAKMP, and therefore it may be possible to create a multicast flooding denial of service attack using the multicast application's data stream. Either an insider (i.e., a rogue GM) or a non-member could direct the multicast routers to spray data at a victim system.
7. 该组的多播路由基础设施不受GSAKMP保护，因此可能会使用多播应用程序的数据流创建多播泛洪拒绝服务攻击。内部人员（即流氓GM）或非成员可以指示多播路由器向受害者系统喷洒数据。
8. The compromise of a S-GC/KS forces the re-registration of all GMs under its control. The GM recognizes this situation by finding the S-GC/KS's certificate on a CRL as supplied by a service such as LDAP.
8. S-GC/KS的妥协迫使其控制下的所有GMs重新注册。GM通过在由LDAP等服务提供的CRL上查找S-GC/KS证书来识别这种情况。
9. The compromise of the GO forces termination of the group. The GM recognizes this situation by finding the GO's certificate on a Certificate Revocation List (CRL) as supplied by a service such as LDAP.
9. 围棋的妥协迫使该团体终止。GM通过在LDAP等服务提供的证书吊销列表（CRL）上查找GO的证书来识别这种情况。
GSAKMP derives from two (2) existing protocols: ISAKMP [RFC2408] and FIPS Pub 196 [FIPS196]. In accordance with Security Suite 1, GSAKMP implementations MUST support the use of Diffie-Hellman key exchange [DH77] for two-party key creation and MAY use Logical Key Hierarchy (LKH) [RFC2627] for rekey capability. The GSAKMP design was also influenced by the following protocols: [HHMCD01], [RFC2093], [RFC2094], [BMS], and [RFC2412].
GSAKMP源自两（2）个现有协议：ISAKMP[RFC2408]和FIPS Pub 196[FIPS196]。根据安全套件1，GSAKMP实现必须支持使用Diffie-Hellman密钥交换[DH77]来创建双方密钥，并且可以使用逻辑密钥层次结构（LKH）[RFC2627]来重新密钥。GSAKMP设计还受到以下协议的影响：[HHMDC01]、[RFC2093]、[RFC2094]、[BMS]和[RFC2412]。
ISAKMP provides a flexible structure of chained payloads in support of authenticated key exchange and security association management for pairwise communications. GSAKMP builds upon these features to provide policy enforcement features in support of diverse group communications.
ISAKMP提供了一种灵活的链式有效负载结构，支持认证密钥交换和成对通信的安全关联管理。GSAKMP以这些功能为基础，提供策略实施功能，以支持不同的组通信。
FIPS Pub 196 provides a mutual authentication protocol.
FIPS Pub 196提供了一个相互认证协议。
When group policy dictates that a recovery of the group security is necessary after the discovery of the compromise of a GM, then GSAKMP relies upon a rekey capability (i.e., LKH) to enable group recovery after a compromise [RFC2627]. This is optional since in many instances it may be better to destroy the compromised group and rebuild a secure group.
当集团策略规定在发现GM泄露后有必要恢复集团安全性时，GSAKMP依赖于重新密钥功能（即LKH）在泄露后启用集团恢复[RFC2627]。这是可选的，因为在许多情况下，销毁受损组并重建安全组可能更好。
A Group may rely upon two-party key creation mechanisms, i.e., Diffie-Hellman, to protect sensitive data during download.
一个组可以依靠两方密钥创建机制，即Diffie-Hellman，在下载期间保护敏感数据。
The information in this section borrows heavily from [IKEv2], as this protocol has already worked through similar issues and GSAKMP is using the same security considerations for its purposes. This section will contain paraphrased sections of [IKEv2] modified for GSAKMP as appropriate.
本节中的信息大量借鉴了[IKEv2]，因为该协议已经解决了类似的问题，并且GSAKMP使用了相同的安全考虑。本节将包含为GSAKMP修改的[IKEv2]的释义部分（视情况而定）。
The strength of a key derived from a Diffie-Hellman exchange using specific p and g values depends on the inherent strength of the values, the size of the exponent used, and the entropy provided by the random number generator used. A strong random number generator combined with the recommendations from [RFC3526] on Diffie-Hellman exponent size is recommended as sufficient. An implementation should make note of this conservative estimate when establishing policy and negotiating security parameters.
使用特定p和g值从Diffie-Hellman交换中导出的密钥的强度取决于值的固有强度、所用指数的大小以及所用随机数生成器提供的熵。建议使用强随机数生成器，并结合[RFC3526]关于Diffie-Hellman指数大小的建议。在制定策略和协商安全参数时，实施应注意这一保守估计。
Note that these limitations are on the Diffie-Hellman values themselves. There is nothing in GSAKMP that prohibits using stronger values, nor is there anything that will dilute the strength obtained from stronger values. In fact, the extensible framework of GSAKMP encourages the definition of more Security Suites.
请注意，这些限制是针对Diffie-Hellman值本身的。GSAKMP中没有任何内容禁止使用更强的值，也没有任何内容会稀释从更强的值中获得的强度。事实上，GSAKMP的可扩展框架鼓励定义更多的安全套件。
It is assumed that the Diffie-Hellman exponents in this exchange are erased from memory after use. In particular, these exponents MUST NOT be derived from long-lived secrets such as the seed to a pseudo-random generator that is not erased after use.
假设此交换中的Diffie-Hellman指数在使用后从内存中删除。特别是，这些指数不能来源于长期存在的秘密，如伪随机发生器的种子，该种子在使用后不会被擦除。
This GSAKMP specification addresses the mitigation for a distributed IP spoofing attack (a subset of possible DoS attacks) in Section 5.2.2, "Cookies: Group Establishment with Denial of Service Protection".
本GSAKMP规范解决了第5.2.2节“Cookie:具有拒绝服务保护的组建立”中分布式IP欺骗攻击（可能的DoS攻击子集）的缓解问题。
In addition to GSAKMP's capability to do rekey operations, GSAKMP MUST also have the capability to make this rekey information highly available to GMs. The necessity of GMs receiving rekey messages requires the use of methods to increase the likelihood of receipt of rekey messages. These methods MAY include multiple transmissions of the rekey message, posting of the rekey message on a bulletin board, etc. Compliant GSAKMP implementations supporting the optional rekey capability MUST support retransmission of rekey messages.
除了GSAKMP进行重新密钥操作的能力外，GSAKMP还必须能够使GMs高度可用该重新密钥信息。GMs接收密钥更新消息的必要性要求使用方法增加接收密钥更新消息的可能性。这些方法可能包括多次传输密钥更新消息、在公告板上发布密钥更新消息等。支持可选密钥更新功能的兼容GSAKMP实现必须支持密钥更新消息的重新传输。
As defined by [HCM], security group policy MUST be defined in a verifiable manner. GSAKMP anchors its trust in the creator of the group, the GO.
根据[HCM]的定义，必须以可验证的方式定义安全组策略。GSAKMP对该组织的创造者GO表示信任。
The policy token explicitly defines all the parameters that create a secure verifiable infrastructure. The GSAKMP Policy Token is issued and signed by the GO. The GC/KS will verify it and grant access to GMs only if they meet the rules of the policy token. The new GMs will accept access only if 1) the token verifies, 2) the GC/KS is an authorized disseminator, and 3) the group mechanisms are acceptable for protecting the GMs data.
策略令牌明确定义了创建安全可验证基础结构的所有参数。GSAKMP策略令牌由GO颁发和签署。GC/KS将对其进行验证，并仅当GMs满足策略令牌的规则时才授予对GMs的访问权。只有在以下情况下，新的GMs才会接受访问：1）令牌验证；2）GC/KS是授权的传播者；3）组机制可用于保护GMs数据。
This architecture presents a trust model for GSAKMP and a concept of operations for establishing a trusted distributed infrastructure for group key and policy distribution.
该体系结构为GSAKMP提供了一个信任模型，并提出了为组密钥和策略分发建立可信分布式基础架构的操作概念。
GSAKMP conforms to the IETF MSEC architectural concepts as specified in the MSEC Architecture document [RFC3740]. GSAKMP uses the MSEC components to create a trust model for operations that implement the security principles of mutual suspicion and trusted policy creation authorities.
GSAKMP符合MSEC体系结构文件[RFC3740]中规定的IETF MSEC体系结构概念。GSAKMP使用MSEC组件为实现相互怀疑和可信策略创建权限的安全原则的操作创建信任模型。
The trust model contains four key components:
信任模型包含四个关键组件：
- Group Owner (GO),
- 集团所有者（GO），
- Group Controller Key Server (GC/KS),
- 组控制器密钥服务器（GC/KS），
- Subordinate GC/KS (S-GC/KS), and
- 下属GC/KS（S-GC/KS），以及
- Group Member (GM).
- 集团成员（总经理）。
The goal of the GSAKMP trust model is to derive trust from a common trusted policy creation authority for a group. All security-relevant decisions and actions implemented by GSAKMP are based on information that ultimately is traceable to and verified by the trusted policy creation authority. There are two trusted policy creation authorities for GSAKMP: the GO (policy creation authority) and the PKI root that allows us to verify the GO.
GSAKMP信任模型的目标是从组的公共受信任策略创建机构获得信任。GSAKMP执行的所有安全相关决策和操作都基于最终可追溯到可信策略创建机构并由其验证的信息。GSAKMP有两个受信任的策略创建机构：GO（策略创建机构）和允许我们验证GO的PKI根。
The GO is the policy creation authority for the group. The GO has a well-defined identity that is relevant to the group. That identity can be of a person or of a group-trusted component. All potential entities in the group have to recognize the GO as the individual with authority to specify policy for the group.
GO是该组的策略创建权限。GO具有与集团相关的明确身份。该标识可以是个人或组受信任组件的标识。集团内的所有潜在实体必须将GO视为有权为集团指定政策的个人。
The policy reflects the protection requirements of the data in a group. Ultimately, the data and the application environment drives the security policy for the group.
该策略反映了组中数据的保护要求。最终，数据和应用程序环境决定了集团的安全策略。
The GO has to determine the security rules and mechanisms that are appropriate for the data being protected by the group keys. All this information is captured in a policy token (PT). The GO creates the PT and signs it.
GO必须确定适用于受组密钥保护的数据的安全规则和机制。所有这些信息都捕获在策略令牌（PT）中。GO创建PT并对其进行签名。
The GC/KS is authorized to perform several functions: key creation, key distribution, rekey, and group membership management.
GC/KS被授权执行几个功能：密钥创建、密钥分发、重新密钥和组成员管理。
As the key creation authority, the GC/KS will create the set of keys for the group. These keys include the Group Traffic Protection Keys (GTPKs) and first-tier rekey keys. There may be second-tier rekey trees if a distributed rekey management structure is required for the group.
作为密钥创建机构，GC/KS将为组创建密钥集。这些密钥包括组流量保护密钥（GTPK）和第一层重密钥。如果组需要分布式密钥管理结构，则可能存在第二层密钥树。
As the key distribution (registration) authority, it has to notify the group of its location for registration services. The GC/KS will have to enforce key access control as part of the key distribution and registration processes.
作为密钥分发（注册）机构，它必须通知集团其注册服务的位置。作为密钥分发和注册过程的一部分，GC/KS必须实施密钥访问控制。
As the group rekey authority, it performs rekey in order to change the group's GTPK. Change of the GTPK limits the exposure of data encrypted with any single GTPK.
作为组密钥更新机构，它执行密钥更新以更改组的GTPK。GTPK的更改限制了使用任何单个GTPK加密的数据的公开。
Finally, as the group membership management authority, the GC/KS can manage the group membership (registration, eviction, de-registration, etc.). This may be done in part by using a key tree approach, such as Logical Key Hierarchies (LKH), as an optional approach.
最后，作为组成员管理机构，GC/KS可以管理组成员（注册、驱逐、注销等）。这可以部分地通过使用密钥树方法（如逻辑密钥层次结构（LKH））作为可选方法来实现。
A subordinate GC/KS is used to distribute the GC/KS functionality across multiple entities. The S-GC/KS will have all the authorities of the GC/KS except one: it will not create the GTPK. It is assumed here that the group will transmit data with a single GTPK at any one time. This GTPK comes from the GC/KS.
下级GC/KS用于在多个实体之间分发GC/KS功能。S-GC/KS将拥有GC/KS的所有权限，只有一个除外：它不会创建GTPK。此处假设该组将在任何时间使用单个GTPK传输数据。此GTPK来自GC/KS。
Note that relative to the GC/KS, the S-GC/KS is responsible for an additional security check: the S-GC/KS must register as a member with the GC/KS, and during that process it has to verify the authority of the GC/KS.
请注意，相对于GC/KS，S-GC/KS负责额外的安全检查：S-GC/KS必须注册为GC/KS的成员，并且在此过程中必须验证GC/KS的权限。
The GM has two jobs: to make sure all security-relevant actions are authorized and to use the group keys properly. During the registration process, the GM will verify that the PT is signed by a recognized GO. In addition, it will verify that the GC/KS or S-GC/KS engaged in the registration process is authorized, as specified in the PT. If rekey and new PTs are distributed to the group, the GM will verify that they are proper and all actions are authorized.
总经理有两项工作：确保所有与安全相关的行动都得到授权，并正确使用组密钥。在注册过程中，总经理将验证PT是否由认可的GO签署。此外，它将验证参与注册过程的GC/KS或S-GC/KS是否按照PT中的规定获得授权。如果向集团分发了更新的PTs和新的PTs，则GM将验证这些PTs是否正确，以及所有行动是否得到授权。
The GM is granted access to group data through receipt of the group keys This carries along with it a responsibility to protect the key from unauthorized disclosure.
GM通过接收组密钥被授予访问组数据的权限。同时，GM有责任保护密钥不被未经授权披露。
GSAKMP does not offer any enforcement mechanisms to control which GMs are multicast speakers at a given moment. This policy and its enforcement depend on the multicast application and its protocols. However, GSAKMP does allow a group to have one of three Group Security Association multicast speaker configurations:
GSAKMP不提供任何强制机制来控制在给定时刻哪些GMs是多播扬声器。此策略及其实施取决于多播应用程序及其协议。但是，GSAKMP允许组具有以下三种组安全关联多播扬声器配置之一：
- There is a single GM authorized to be the group's speaker. There is one multicast application SA allocated by the GO in support of that speaker. The PT initializes this multicast application SA and identifies the GM that has been authorized to be speaker. All GMs share a single TPK with that GM speaker. Sequence number checking for anti-replay protection is feasible and enabled by default. This is the default group configuration. GSAKMP implementations MUST support this configuration.
- 只有一位总经理被授权担任集团发言人。GO分配了一个多播应用程序SA以支持该演讲者。PT初始化该多播应用程序SA，并识别已被授权为演讲者的GM。所有通用汽车公司与该通用汽车公司扬声器共用一个TPK。反重放保护的序列号检查是可行的，默认情况下已启用。这是默认的组配置。GSAKMP实现必须支持此配置。
- The GO authorizes all of the GMs to be group speakers. The GO allocates one multicast application SA in support of these speakers. The PT initializes this multicast application SA and indicates that any GM can be a speaker. All of the GMs share a single GTPK and other SA state information. Consequently, some SA security features such as sequence number checking for anti-replay
- GO授权所有GMs作为团体发言人。GO分配一个多播应用程序SA以支持这些扬声器。PT初始化此多播应用程序SA，并指示任何GM都可以是扬声器。所有GMs共享一个GTPK和其他SA状态信息。因此，一些SA安全功能，如反重放的序列号检查
protection cannot be supported by this configuration. GSAKMP implementations MUST support this group configuration.
此配置不支持保护。GSAKMP实现必须支持此组配置。
- The GO authorizes a subset of the GMs to be group speakers (which may be the subset composed of all GMs). The GO allocates a distinct multicast application SA for each of these speakers. The PT identifies the authorized speakers and initializes each of their multicast application Security Associations. The speakers still share a common TPK across their SA, but each speaker has a separate SA state information instance at every peer GM. Consequently, this configuration supports SA security features, such as sequence number checking for anti-replay protection, or source authentication mechanisms that require per-speaker state at the receiver. The drawback of this configuration is that it does not scale to a large number of speakers. GSAKMP implementations MAY support this group configuration.
- GO授权GMs的一个子集为群组发言人（可以是由所有GMs组成的子集）。GO为每个扬声器分配不同的多播应用程序SA。PT识别授权发言人并初始化其每个多播应用程序安全关联。扬声器在其SA中仍然共享一个公共TPK，但每个扬声器在每个对等GM上都有一个单独的SA状态信息实例。因此，此配置支持SA安全功能，如反重播保护的序列号检查，或要求接收器处每个扬声器状态的源身份验证机制。这种配置的缺点是不能扩展到大量扬声器。GSAKMP实现可能支持此组配置。
The assumptions for this trust model are that:
该信任模型的假设如下：
- the GCKS is never compromised,
- GCKS从不妥协，
- the GO is never compromised,
- 围棋从不妥协，
- the PKI, subject to certificate validation, is trustworthy,
- 经过证书验证的PKI是可信的，
- The GO is capable of creating a security policy to meet the demands of the group,
- GO能够创建安全策略以满足集团的需求，
- the compromises of a group member will be detectable and reported to the GO in a trusted manner,
- 集团成员的妥协将被检测并以可信的方式报告给GO，
- the subsequent recovery from a compromise will deny inappropriate access to protected data to the compromised member,
- 随后从泄露中恢复将拒绝被泄露成员对受保护数据的不适当访问，
- no security-relevant actions depend on a precise network time,
- 没有任何与安全相关的操作依赖于精确的网络时间，
- there are confidentiality, integrity, multicast source authentication, and anti-replay protection mechanisms for all GSAKMP control messages.
- 所有GSAKMP控制消息都有保密性、完整性、多播源身份验证和反重播保护机制。
The trust model for GSAKMP revolves around the definition and enforcement of the security policy. In fact, the use of the key is only relevant, in a security sense, if it represents the successful enforcement of the group security policy.
GSAKMP的信任模型围绕安全策略的定义和实施展开。事实上，密钥的使用仅在代表成功实施组安全策略的情况下，在安全意义上才相关。
Group operations lend themselves to rule-based security policy. The need for distribution of data to many endpoints often leads to the defining of those authorized endpoints based on rules. For example, all IETF attendees at a given conference could be defined as a single group.
组操作适用于基于规则的安全策略。由于需要将数据分发到多个端点，通常需要根据规则定义这些授权端点。例如，给定会议上的所有IETF与会者可以定义为一个小组。
If the security policy rules are to be relevant, they must be coupled with validation mechanisms. The core principle here is that the level of trust one can afford a security policy is exactly equal to the level of trust one has in the validation mechanism used to prove that policy. For example, if all IETF attendees are allowed in, then they could register their identity from their certificate upon check-in to the meetings. That certificate is issued by a trusted policy creation authority (PKI root) that is authorized to identify someone as an IETF attendee. The GO could make admittance rules to the IETF group based on the identity certificates issued from trusted PKIs.
如果安全策略规则是相关的，那么它们必须与验证机制相结合。这里的核心原则是，一个安全策略所能承受的信任级别与一个用于证明该策略的验证机制中的信任级别完全相同。例如，如果所有IETF与会者都被允许进入，那么他们可以在登记参加会议时从他们的证书中注册他们的身份。该证书由受信任的策略创建机构（PKI根）颁发，该机构有权将某人标识为IETF参与者。GO可以根据可信PKI颁发的身份证书制定IETF组的准入规则。
In GSAKMP, every security policy rule is coupled with an explicit validation mechanism. For interoperability considerations, GSAKMP requires that its supporting PKI implementations MUST be compliant to RFC 3280.
在GSAKMP中，每个安全策略规则都与显式验证机制耦合。出于互操作性考虑，GSAKMP要求其支持的PKI实现必须符合RFC3280。
If a GM's public key certificate is revoked, then the entity that issues that revocation SHOULD signal the GO, so that the GO can expel that GM. The method that signals this event to the GO is not standardized by this specification.
如果GM的公钥证书被吊销，则发布该吊销的实体应向GO发出信号，以便GO可以驱逐该GM。向GO发出此事件信号的方法不符合本规范的标准。
A direct mapping of rule to validation mechanism allows the use of multiple rules and PKIs to create groups. This allows a GO to define a group security policy that spans multiple PKI domains, each with its own Certificate Authority public key certificate.
规则到验证机制的直接映射允许使用多个规则和PKI来创建组。这允许GO定义跨多个PKI域的组安全策略，每个域都有自己的证书颁发机构公钥证书。
The access control policy for the group keys is equivalent to the access control policy for the multicast application data the keys are protecting.
组密钥的访问控制策略相当于密钥所保护的多播应用程序数据的访问控制策略。
In a group, each data source is responsible for ensuring that the access to the source's data is appropriate. This implies that every data source should have knowledge of the access control policy for the group keys.
在一个组中，每个数据源负责确保对源数据的访问是适当的。这意味着每个数据源都应该了解组密钥的访问控制策略。
In the general case, GSAKMP offers a suite of security services to its applications and does not prescribe how they use those services.
在一般情况下，GSAKMP为其应用程序提供了一套安全服务，但没有规定它们如何使用这些服务。
GSAKMP supports the creation of GSAs with multiple data sources. It also supports architectures where the GC/KS is not itself a data source. In the multiple data source architectures GSAKMP requires that the access control policy is precisely defined and distributed to each data source. The reference for this data structure is the GSAKMP Policy Token [RFC4534].
GSAKMP支持使用多个数据源创建GSA。它还支持GC/KS本身不是数据源的体系结构。在多数据源体系结构中，GSAKMP要求精确定义访问控制策略并将其分发到每个数据源。此数据结构的参考是GSAKMP策略令牌[RFC4534]。
A critical aspect of the GSAKMP trust model is the authorization of security-relevant actions. These include download of group key, rekey, and PT creation and updates. These actions could be used to disrupt the secure group, and all entities in the group must verify that they were instigated by authorized entities within the group.
GSAKMP信任模型的一个关键方面是安全相关操作的授权。这些包括下载组密钥、重新密钥以及PT创建和更新。这些操作可用于中断安全组，组中的所有实体必须验证这些操作是由组内的授权实体发起的。
Scalability is a core feature of GSAKMP. GSAKMP's approach to scalable operations is the establishment of S-GC/KSes. This allows the GSAKMP systems to distribute the workload of setting up and managing very large groups.
可伸缩性是GSAKMP的核心特性。GSAKMP的可扩展操作方法是建立s-GC/KSE。这允许GSAKMP系统分配设置和管理非常大的组的工作量。
Another aspect of distributed S-GC/KS operations is the enabling of local management authorities. In very large groups, subordinate enclaves may be best suited to provide local management of the enclaves' group membership, due to a direct knowledge of the group members.
分布式S-GC/KS操作的另一个方面是启用本地管理机构。在非常大的集团中，由于直接了解集团成员，附属飞地可能最适合提供飞地集团成员的本地管理。
One of the critical issues involved with distributed operation is the discovery of the security infrastructure location and security suite. Many group applications that have dynamic interactions must "find" each other to operate. The discovery of the security infrastructure is just another piece of information that has to be known by the group in order to operate securely.
分布式操作涉及的关键问题之一是发现安全基础设施位置和安全套件。许多具有动态交互的组应用程序必须“找到”彼此才能运行。安全基础设施的发现只是集团必须了解的另一条信息，以确保安全运营。
There are several methods for infrastructure discovery:
基础架构发现有几种方法：
- Announcements
- 公告
- Anycast
- 选播
- Rendezvous points / Registration
- 集合点/登记
One method for distributing the security infrastructure location is to use announcements. The SAP is commonly used to announce the existence of a new multicast application or service. If an
分发安全基础设施位置的一种方法是使用公告。SAP通常用于宣布新的多播应用程序或服务的存在。如果
application uses SAP [RFC2974] to announce the existence of a service on a multicast channel, that service could be extended to include the security infrastructure location for a particular group.
应用程序使用SAP[RFC2974]宣布多播通道上存在一个服务，该服务可以扩展到包括特定组的安全基础设施位置。
Announcements can also be used by GSAKMP in one of two modes: expanding ring searches (ERSes) of security infrastructure and ERSes for infrastructure discovery. In either case, the GSAKMP would use a multicast broadcast that would slowly increase in its range by incremental multicast hops. The multicast source controls the packet's multicast range by explicitly setting its Time To Live count.
GSAKMP还可以通过以下两种模式之一使用公告：安全基础设施的扩展环搜索（ERSes）和基础设施发现的ERSes。在任何一种情况下，GSAKMP都将使用多播广播，该广播将通过增量多播跃点在其范围内缓慢增加。多播源通过显式设置数据包的生存时间计数来控制数据包的多播范围。
An expanding ring announcement operates by the GC/KS announcing its existence for a particular group. The number of hops this announcement would travel would be a locally configured number. The GMs would listen on a well-known multicast address for GC/KSes that provide service for groups of interest. If multiple GC/KSes are found that provide service, then the GM would pick the closest one (in terms of multicast hops). The GM would then send a GSAKMP Request to Join message (RTJ) to the announced GC/KS. If the announcement is found to be spurious, then that is reported to the appropriate management authorities. The ERA concept is slightly different from SAP in that it could occur over the data channel multicast address, instead of a special multicast address dedicated for the SAP service.
GC/KS发布扩展环公告，宣布特定组的存在。此公告将传播的跃点数将是本地配置的数。GMs将侦听为感兴趣的组提供服务的GC/KSE的已知多播地址。如果发现多个GC/KSE提供服务，则GM将选择最近的一个（就多播跳而言）。然后，GM将向宣布的GC/KS发送GSAKMP加入请求消息（RTJ）。如果发现该公告是虚假的，则应向相关管理当局报告。ERA的概念与SAP稍有不同，因为它可能发生在数据通道多播地址上，而不是专用于SAP服务的特殊多播地址上。
An expanding ring search operates in the reverse order of the ERA. In this case, the GM is the announcing entity. The (S-)GC/KSes listen for the requests for service, specifically the RTJ. The (S-)GC/KS responds to the RTJ. If the GM receives more than one response, it would either ignore the responses or send NACKs based on local configuration.
一个不断扩大的搜索环的运行顺序与时代相反。在这种情况下，通用汽车公司是宣布实体。GC/KSE侦听服务请求，特别是RTJ。（S-）GC/KS响应RTJ。如果GM收到多个响应，它将忽略响应或根据本地配置发送NACK。
Anycast is a service that is very similar to ERS. It also can be used to provide connection to the security infrastructure. In this case, the GM would send the RTJ to a well-known service request address. This anycast service would route the RTJ to an appropriate GC/KS. The anycast service would have security infrastructure and network connectivity knowledge to facilitate this connection.
Anycast是一项与ERS非常相似的服务。它还可用于提供与安全基础设施的连接。在这种情况下，GM会将RTJ发送到一个众所周知的服务请求地址。此选播服务将RTJ路由到适当的GC/KS。anycast的网络连接和安全知识将有助于此网络连接。
Registration points can be used to distribute many group-relevant data, including security infrastructure. Many group applications rely on well-known registration points to advertise the availability of groups. There is no reason that GSAKMP could not use the same approach for advertising the existence and location of the security infrastructure. This is a simple process if the application being supported already supports registration. The GSAKMP infrastructure can always provide a registration site if the existence of this
注册点可用于分发许多与组相关的数据，包括安全基础设施。许多组应用程序依赖于众所周知的注册点来宣传组的可用性。GSAKMP没有理由不使用相同的方法宣传安全基础设施的存在和位置。如果受支持的应用程序已经支持注册，那么这是一个简单的过程。GSAKMP基础设施始终可以提供注册站点（如果存在此站点）
security infrastructure discovery hub is needed. The registration of S-GC/KSes at this site could be an efficient way to allow GM registration.
需要安全基础设施发现中心。通过这种方式，通用汽车公司/通用汽车服务有限公司可以在通用汽车公司/通用汽车服务有限公司注册。
GSAKMP infrastructure discovery can use whatever mechanism suits a particular multicast application's requirements, including mechanisms that have not been discussed by this architecture. However, GSAKMP infrastructure discovery is not standardized by this version of the GSAKMP specification.
GSAKMP基础设施发现可以使用任何适合特定多播应用程序需求的机制，包括此体系结构未讨论的机制。但是，此版本的GSAKMP规范并未对GSAKMP基础设施发现进行标准化。
This concept of operation shows how the different roles in GSAKMP interact to set up a secure group. This particular concept of operation focuses on a secure group that utilizes the distributed key dissemination services of the S-GC/KS.
此操作概念显示了GSAKMP中的不同角色如何交互以建立安全组。此特定的操作概念侧重于利用S-GC/KS的分布式密钥分发服务的安全组。
The most basic assumption here is that there is one or more trustworthy PKIs for the group. That trusted PKI will be used to create and verify security policy rules.
这里最基本的假设是该组有一个或多个可信的PKI。该受信任的PKI将用于创建和验证安全策略规则。
There is a GO that all GMs recognize as having group policy creation authority. All GM must be securely pre-configured to know the GO public key.
所有GMs都承认有一个GO拥有集团策略创建权限。所有GM必须安全地预先配置，以了解GO公钥。
All GMs have access to the GO PKI information, both the trusted anchor public keys and the certificate path validation rules.
所有GMs都可以访问GO PKI信息，包括可信锚公钥和证书路径验证规则。
There is sufficient connectivity between the GSAKMP entities.
GSAKMP实体之间有足够的连接。
- The registration SA requires that GM can connect to the GC/KS or S-GC/KS using either TCP or UDP.
- 注册SA要求GM可以使用TCP或UDP连接到GC/KS或S-GC/KS。
- The Rekey SA requires that the data-layer multicast communication service be available. This can be multicast IP, overlay networks using TCP, or NAT tunnels.
- 密钥重置SA要求数据层多播通信服务可用。这可以是多播IP、使用TCP的覆盖网络或NAT隧道。
- GSAKMP can support many different data-layer secure applications, each with unique connectivity requirements.
- GSAKMP可以支持许多不同的数据层安全应用程序，每个应用程序都有独特的连接要求。
The GO creates and signs the policy token for a group. The policy token contains the rules for access control and authorizations for a particular group.
GO为组创建并签署策略令牌。策略令牌包含特定组的访问控制和授权规则。
The PT consists of the following information:
PT由以下信息组成：
- Identification: This allows an unambiguous identification of the PT and the group.
- 识别：这允许明确识别PT和组。
- Access Control Rules: These rules specify who can have access to the group keys.
- 访问控制规则：这些规则指定谁可以访问组密钥。
- Authorization Rules: These rules specify who can be a S-GC/KS.
- 授权规则：这些规则指定谁可以是S-GC/KS。
- Mechanisms: These rules specify the security mechanisms that will be used by the group. This is necessary to ensure there is no weak link in the group security profile. For example, for IPsec, this could include SPD/SAD configuration data.
- 机制：这些规则指定组将使用的安全机制。这是确保组安全配置文件中没有薄弱环节所必需的。例如，对于IPsec，这可能包括SPD/SAD配置数据。
- Source authentication of the PT to the GO: The PT is a CMS signed object, and this allows all GMs to verify the PT.
- PT到GO的源身份验证：PT是CMS签名对象，这允许所有GMs验证PT。
The PT is sent to a potential GC/KS. This can occur in several ways, and the method of transmittal is outside the scope of GSAKMP. The potential GC/KS will verify the GO signature on the PT to ensure that it comes from a trusted GO. Next, the GC/KS will verify that it is authorized to become the GC/KS, based on the authorization rules in the PT. Assuming that the GC/KS trusts the PT, is authorized to be a GC/KS, and is locally configured to become a GC/KS for a given group and the GO, then the GC/KS will create the keys necessary to start the group. The GC/KS will take whatever action is necessary (if any) to advertise its ability to distribute key for the group. The GC/KS will then listen for RTJs.
PT被发送到潜在的GC/KS。这可能以多种方式发生，传递方法不在GSAKMP的范围内。潜在GC/KS将验证PT上的GO签名，以确保其来自可信GO。接下来，GC/KS将根据PT中的授权规则验证其是否被授权成为GC/KS。假设GC/KS信任PT，被授权为GC/KS，并在本地配置为成为给定组和GO的GC/KS，则GC/KS将创建启动组所需的密钥。GC/KS将采取任何必要的措施（如有）宣传其为组分发密钥的能力。然后GC/KS将侦听RTJs。
The PT has a sequence number. Every time a PT is distributed to the group, the group members verify that the sequence number on the PT is increasing. The PT lifetime is not limited to a particular time interval, other than by the lifetimes imposed by some of its attributes (e.g., signature key lifetime). The current PT sequence number is downloaded to the GM in the "Key Download" message. Also, to avoid replay attacks, this sequence number is never reset to a lower value (i.e., rollover to zero) as long as the group identifier remains valid and in use. The GO MUST preserve this sequence number across re-boots.
PT有一个序列号。每次将PT分配给组时，组成员都会验证PT上的序列号是否在增加。PT生存期不限于特定的时间间隔，除了由其某些属性（例如，签名密钥生存期）施加的生存期之外。当前PT序列号在“钥匙下载”消息中下载到GM。此外，为了避免重播攻击，只要组标识符保持有效且正在使用，该序列号永远不会重置为较低的值（即，滚动到零）。GO必须在重新引导期间保留此序列号。
Potential GMs will receive notice of the new group via some mechanism: announcement, Anycast, or registration look-up. The GM will send an RTJ to the GC/KS.
潜在的总经理将通过某种机制收到新集团的通知：公告、选播或注册查询。GM将向GC/KS发送RTJ。
The GC/KS may or may not require cookies, depending on the DoS environment and the local configuration.
GC/KS可能需要也可能不需要cookie，这取决于DoS环境和本地配置。
Once the RTJ has been received, the GC/KS will verify that the GM is allowed to have access to the group keys. The GC/KS will then verify the signature on the RTJ to ensure it was sent by the claimed identity. If the checks succeed, the GC/KS will ready a Key Download message for the GM. If not, the GC/KS can notify the GM of a non-security-relevant problem.
收到RTJ后，GC/KS将验证是否允许GM访问组密钥。GC/KS随后将验证RTJ上的签名，以确保它是由声明的身份发送的。如果检查成功，GC/KS将为GM准备一条密钥下载消息。如果没有，GC/KS可以通知GM一个与安全无关的问题。
Upon receipt of the Key Download message, the GM will verify the signature on the message. Then the GM will retrieve the PT from the Key Download message and verify that the GO created and signed the PT. Once the PT is verified as valid, the GM will verify that the GC/KS is authorized to distribute key for this group. Then the GM will verify that the mechanisms used in the group are available and acceptable for protection of the GMs data (assuming the GM is a data source). The GM will then accept membership in this group.
在收到密钥下载消息后，GM将验证消息上的签名。然后，GM将从密钥下载消息中检索PT，并验证GO是否创建并签署了PT。一旦PT被验证为有效，GM将验证GC/KS是否有权为该组分配密钥。然后，GM将验证集团中使用的机制是否可用且可接受，以保护GMs数据（假设GM是一个数据源）。然后，总经理将接受该小组的成员资格。
The GM will then check to see if it is allowed to be a S-GC/KS for this group. If the GM is allowed to be a S-GC/KS AND the local GM configuration allows the GM to act as a S-GC/KS for this group, then the GM changes its operating state to S-GC/KS. The GO needs to assign the authority to become a S-GC/KS in a manner that supports the overall group integrity and operations.
然后，总经理将检查是否允许成为该组的S-GC/KS。如果允许GM为S-GC/KS，且本地GM配置允许GM作为该组的S-GC/KS，则GM将其运行状态更改为S-GC/KS。GO需要以支持整个集团完整性和运营的方式分配权限，以成为S-GC/KS。
In autonomous mode, each S-GC/KS operates a largely self-contained sub-group for which the Primary-GC/KS delegates the sub-group's membership management responsibility to the S-GC/KS. In general, the S-GC/KS locally handles each Group Member's registration and de-registration without any interaction with the Primary-GC/KS. Periodically, the Primary-GC/KS multicasts a Rekey Event message addressed only to its one or more S-GC/KS.
在自治模式下，每个S-GC/KS运行一个基本独立的子组，主GC/KS将子组的成员管理责任委托给S-GC/KS。通常，S-GC/KS在本地处理每个组成员的注册和注销，而不与主GC/KS进行任何交互。主GC/KS周期性地多播一条仅发往其一个或多个S-GC/KS的密钥更新事件消息。
After a S-GC/KS successfully processes a Rekey Event message from the Primary-GC/KS, the S-GC/KS transmits to its sub-group its own Rekey
在S-GC/KS成功处理来自主GC/KS的重新密钥事件消息后，S-GC/KS向其子组传输其自己的重新密钥
Event message containing a copy of the group's new GTPK and policy token. The S-GC/KS encrypts its Rekey Event message's sub-group key management information using Logical Key Hierarchy or a comparable rekey protocol. The S-GC/KS uses the rekey protocol to realize forward and backward secrecy, such that only the authorized sub-group members can decrypt and acquire access to the new GTPK and policy token. The frequency at which the Primary-GC/KS transmits a Rekey Event message is a policy token parameter.
包含组的新GTPK和策略令牌副本的事件消息。S-GC/KS使用逻辑密钥层次结构或类似的密钥更新协议对其密钥更新事件消息的子组密钥管理信息进行加密。S-GC/KS使用重新密钥协议实现前向和后向保密，这样只有授权的子组成员才能解密并获得对新GTPK和策略令牌的访问权。主GC/KS发送密钥更新事件消息的频率是策略令牌参数。
For the special case of a S-GC/KS detecting an expelled or compromised group member, a mechanism is defined to trigger an immediate group rekey rather than wait for the group's rekey period to elapse. See below for details.
对于S-GC/KS检测到被驱逐或受损的组成员的特殊情况，定义了一种机制来触发立即的组密钥更新，而不是等待组的密钥更新周期过去。详情见下文。
Each S-GC/KS will be registered by the GC/KS as a management node with responsibility for GTPK distribution, access control policy enforcement, LKH tree creation, and distribution of LKH key arrays. The S-GC/KS will be registered into the primary LKH tree as an endpoint. Each S-GC/KS will hold an entire LKH key array for the GC's LKH key tree.
GC/KS将每个S-GC/KS注册为管理节点，负责GTPK分发、访问控制策略实施、LKH树创建和LKH密钥阵列分发。S-GC/KS将作为端点注册到主LKH树中。每个S-GC/KS将为GC的LKH密钥树保存一个完整的LKH密钥数组。
For the purpose of clarity, the process of creating a distributed GSAKMP group will be explained in chronological order.
为了清晰起见，将按时间顺序解释创建分布式GSAKMP组的过程。
First, the Group Owner will create a policy token that authorizes a subset of the group's membership to assume the role of S-GC/KS.
首先，组所有者将创建一个策略令牌，该令牌授权组成员的一个子集担任s-GC/KS角色。
The GO needs to ensure that the S-GC/KS rules in the policy token will be stringent enough to ensure trust in the S-GC/KSes. This policy token is handed off to the primary GC.
GO需要确保策略令牌中的S-GC/KS规则足够严格，以确保对S-GC/KSE的信任。此策略令牌将传递给主GC。
The GC will create the GTPK and initial LKH key tree. The GC will then wait for a potential S-GC/KS to send a Request to Join (RTJ) message.
GC将创建GTPK和初始LKH密钥树。GC随后将等待潜在的S-GC/KS发送加入请求（RTJ）消息。
A potential S-GC/KS will eventually send an RTJ. The GC will enforce the access control policy as defined in the policy token. The S-GC/KS will accept the role of S-GC/KS and create its own LKH key tree for its sub-group membership.
潜在的S-GC/KS最终将发送RTJ。GC将强制执行策略令牌中定义的访问控制策略。S-GC/KS将接受S-GC/KS的角色，并为其子组成员身份创建自己的LKH密钥树。
The S-GC/KS will then offer registration services for the group. There are local management decisions that are optional to control the scope of group members that can be served by a S-GC/KS. These are truly local management issues that allow the administrators of an S-GC/KS to restrict service to potential GMs. These local controls do not affect the overall group security policy, as defined in the policy token.
S-GC/KS随后将为集团提供注册服务。有一些本地管理决策是可选的，用于控制S-GC/KS可以服务的组成员的范围。这些是真正的本地管理问题，允许S-GC/KS的管理员将服务限制为潜在的GMs。这些本地控制不会影响策略令牌中定义的整个组安全策略。
A potential Group Member will send an RTJ to the S-GC/KS. The S-GC/KS will enforce the entire access control policy as defined in the PT. The GM will receive an LKH key array that corresponds to the LKH tree of the S-GC/KS. The key tree generated by the S-GC/KS is independent of the key tree generated by the GC/KS; they share no common keys.
潜在的组成员将向S-GC/KS发送RTJ。S-GC/KS将执行PT中定义的整个访问控制策略。GM将接收与S-GC/KS的LKH树相对应的LKH密钥数组。S-GC/KS生成的密钥树独立于GC/KS生成的密钥树；他们没有共用钥匙。
The GM then has the keys it needs to receive group traffic and be subject to rekey from the S-GC/KS. For the sake of this discussion, let's assume the GM is to be expelled from the group membership.
然后，GM拥有接收组流量所需的密钥，并接受S-GC/KS的重新密钥。为了便于讨论，让我们假设总经理将被开除出小组成员。
The S-GC/KS will receive notification that the GM is to be expelled. This mechanism is outside the scope of this protocol.
S-GC/KS将收到GM将被开除的通知。此机制不在本协议的范围内。
Upon notification that a GM that holds a key array within its LKH tree is to be expelled, the S-GC/KS does two things. First, the S-GC/KS initiates a de-registration exchange with the GC/KS identifying the member to be expelled. (The S-GC/KS proxies a Group Member's de-registration informing the GC/KS that the Group Member has been expelled from the group.) Second, the S-GC/KS will wait for a rekey action by the GC/KS. The immediacy of the rekey action by the GC/KS is a management decision at the GC/KS. Security is best served by quick expulsion of untrusted members.
当通知在其LKH树中持有密钥数组的GM将被驱逐时，S-GC/KS会做两件事。首先，S-GC/KS启动与GC/KS的注销交换，确定要驱逐的成员。（S-GC/KS代理一个组成员的注销，通知GC/KS该组成员已被驱逐出该组。）其次，S-GC/KS将等待GC/KS的重新注册操作。GC/KS的重新密钥操作的即时性是GC/KS的管理决策。快速驱逐不受信任的成员最有利于安全。
Upon receipt of the de-registration notification from the S-GC/KS, the GC/KS will register the member to be expelled. The GC/KS will then follow group procedure for initiating a rekey action (outside the scope of this protocol). The GC/KS will communicate to the GO the expelled member's information (outside the scope of this protocol). With this information, the GO will create a new PT for the group with the expelled GM identity added to the excluded list in the group's access control rules. The GO provides this new PT to the GC/KS for distribution with the Rekey Event Message.
收到S-GC/KS发出的注销通知后，GC/KS将对将被开除的成员进行登记。然后，GC/KS将遵循集团程序启动重新密钥操作（不在本协议范围内）。GC/KS将向GO传达被驱逐成员的信息（不在本协议范围内）。有了这些信息，GO将为该组创建一个新的PT，并将被驱逐的GM身份添加到该组访问控制规则中的排除列表中。GO将此新PT提供给GC/KS，以便与Rekey事件消息一起分发。
The GC/KS will send out a rekey operation with a new PT. The S-GC/KS will receive the rekey and process it. At the same time, all other S-GC/KSes will receive the rekey and note the excluded GM identity. All S-GC/KSes will review local identities to ensure that the excluded GM is not a local member. If it is, then the S-GC/KS will create a rekey message. The S-GC/KSes must always create a rekey message, whether or not the expelled Group Member is a member of their subtrees.
GC/KS将发送一个带有新PT的重新密钥操作。S-GC/KS将接收重新密钥并对其进行处理。同时，所有其他S-GC/KSE将收到重新登记并记录排除的GM身份。所有S-GC/KSE将审查本地身份，以确保被排除的GM不是本地成员。如果是，则S-GC/KS将创建一条重新密钥消息。无论被驱逐的组成员是否为其子树的成员，S-GC/KSE必须始终创建一条重新密钥消息。
The S-GC/KS will then create a local rekey message. The S-GC/KS will send the wrapped Group TPK to all members of its local LKH tree, except the excluded member(s).
然后，S-GC/KS将创建本地密钥更新消息。S-GC/KS将向其本地LKH树的所有成员（排除的成员除外）发送包装组TPK。
The management of a cryptographic group follows a life cycle: group definition, group establishment, and security-relevant group maintenance. Group definition involves defining the parameters necessary to support a secure group, including its policy token. Group establishment is the process of granting access to new members. Security-relevant group maintenance messages include rekey, policy changes, member deletions, and group destruction. Each of these life cycle phases is discussed in the following sections.
加密组的管理遵循一个生命周期：组定义、组建立和与安全相关的组维护。组定义涉及定义支持安全组所需的参数，包括其策略令牌。集团成立是授予新成员访问权限的过程。与安全相关的组维护消息包括重新密钥、策略更改、成员删除和组销毁。以下各节将讨论每个生命周期阶段。
The use and processing of the optional Vendor ID payload for all messages can be found in Section 7.10.
所有消息的可选供应商ID有效负载的使用和处理见第7.10节。
A cryptographic group is established to support secure communications among a group of individuals. The activities necessary to create a policy token in support of a cryptographic group include:
建立密码组以支持一组个人之间的安全通信。创建策略令牌以支持加密组所需的活动包括：
- Determine Access Policy: identify the entities that are authorized to receive the group key.
- 确定访问策略：确定有权接收组密钥的实体。
- Determine Authorization Policy: identify which entities are authorized to perform security-relevant actions, including key dissemination, policy creation, and initiation of security-management actions.
- 确定授权策略：确定哪些实体被授权执行安全相关操作，包括密钥分发、策略创建和安全管理操作的启动。
- Determine Mechanisms: define the algorithms and protocols used by GSAKMP to secure the group.
- 确定机制：定义GSAKMP用于保护组的算法和协议。
- Create Group Policy Token: format the policies and mechanisms into a policy token, and apply the GO signature.
- 创建策略令牌和组策略令牌格式：创建策略令牌和应用策略令牌。
GSAKMP Group Establishment consists of three mandatory-to-implement messages: the Request to Join, the Key Download, and the Key Download Ack/Failure. The exchange may also include two OPTIONAL error messages: the Request to Join Error and the Lack_of_Ack messages. Operation using the mandatory messages only is referred to as "Terse Mode", while inclusion of the error messaging is referred to as "Verbose Mode". GSAKMP implementations MUST support Terse Mode and MAY support Verbose Mode. Group Establishment is discussed in Section 5.2.1.
GSAKMP组建立由三条强制消息组成：加入请求、密钥下载和密钥下载确认/失败。交换还可能包括两条可选错误消息：加入请求错误和缺少确认消息。仅使用强制消息的操作称为“简洁模式”，而包含错误消息称为“详细模式”。GSAKMP实现必须支持简洁模式，并且可能支持详细模式。第5.2.1节讨论了集团的建立。
A group is set in Terse or Verbose Mode by a policy token parameter. All (S-)GC/KSes in a Verbose Mode group MUST support Verbose Mode. GSAKMP allows Verbose Mode groups to have GMs that do not support Verbose Mode. Candidate GMs that do not support Verbose Mode and receive a RTJ-Error or Lack-of-Ack message must handle these messages gracefully. Additionally, a GM will not know ahead of time that it is interacting with the (S-)GC/KS in Verbose or Terse Mode until the policy token is received.
组由策略令牌参数以简洁或详细模式设置。详细模式组中的所有GC/KSE必须支持详细模式。GSAKMP允许详细模式组具有不支持详细模式的GMs。不支持详细模式并接收RTJ错误或缺少Ack消息的候选GMs必须优雅地处理这些消息。此外，在收到策略令牌之前，GM不会提前知道它正在以详细或简洁的模式与（S-）GC/KS交互。
For denial of service protection, a Cookie Exchange MAY precede the Group Establishment exchange. The Cookie Exchange is described in Section 5.2.2.
对于拒绝服务保护，Cookie交换可以在组建立交换之前进行。第5.2.2节描述了Cookie交换。
Regardless of mode, any error message sent between component members indicates the first error encountered while processing the message.
无论采用何种模式，组件成员之间发送的任何错误消息都表示处理消息时遇到的第一个错误。
After the out-of-band receipt of a policy token, a potential Group Controller Key Server (GC/KS) verifies the token and its eligibility to perform GC/KS functionality. It is then permitted to create any needed group keys and begin to establish the group.
在带外接收到策略令牌后，潜在的组控制器密钥服务器（GC/KS）将验证令牌及其执行GC/KS功能的资格。然后允许创建任何所需的组密钥并开始建立组。
The GSAKMP Ladder Diagram, Figure 1, illustrates the process of establishing a cryptographic group. The left side of the diagram represents the actions of the GC/KS. The right side of the diagram represents the actions of the GMs. The components of each message shown in the diagram are presented in Sections 5.2.1.1 through 5.2.1.5.
GSAKMP梯形图（图1）说明了建立加密组的过程。图的左侧表示GC/KS的操作。图的右侧表示GMs的操作。第5.2.1.1节至第5.2.1.5节介绍了图中所示每条信息的组成部分。
CONTROLLER Mandatory/ MESSAGE MEMBER
Optional
!<-M----------Request to Join-------------!
<Process> ! !
<RTJ> ! !
!--M----------Key Download--------------->!
! !<Process KeyDL>
!--O-------Request to Join Error--------->! or
! ! <Proc RTJ-Err>
!<-M----Key Download - Ack/Failure--------!
<Process >! !
<KeyDL-A/F>! !
!--O------Lack of Acknowledgement-------->!
! ! <Proc LOA>
!<=======SHARED KEYED GROUP SESSION======>!
CONTROLLER Mandatory/ MESSAGE MEMBER
Optional
!<-M----------Request to Join-------------!
<Process> ! !
<RTJ> ! !
!--M----------Key Download--------------->!
! !<Process KeyDL>
!--O-------Request to Join Error--------->! or
! ! <Proc RTJ-Err>
!<-M----Key Download - Ack/Failure--------!
<Process >! !
<KeyDL-A/F>! !
!--O------Lack of Acknowledgement-------->!
! ! <Proc LOA>
!<=======SHARED KEYED GROUP SESSION======>!
Figure 1: GSAKMP Ladder Diagram
图1:GSAKMP梯形图
The Request to Join message is sent from a potential GM to the GC/KS to request admission to the cryptographic group. The message contains key creation material, freshness data, an optional selection of mechanisms, and the signature of the GM.
加入请求消息从潜在的GM发送到GC/KS，以请求加入加密组。该消息包含密钥创建材料、新鲜度数据、可选机制选择和GM签名。
The Key Download message is sent from the GC/KS to the GM in response to an accepted Request to Join. This GC/KS-signed message contains the identifier of the GM, freshness data, key creation material, encrypted keys, and the encrypted policy token. The policy token is used to facilitate well-ordered group creation and MUST include the group's identification, group permissions, group join policy, group controller key server identity, group management information, and digital signature of the GO. This will allow the GM to determine whether group policy is compatible with local policy.
密钥下载消息从GC/KS发送至GM，以响应已接受的加入请求。此GC/KS签名消息包含GM的标识符、新鲜度数据、密钥创建材料、加密密钥和加密策略令牌。策略令牌用于促进有序的组创建，并且必须包括组的标识、组权限、组加入策略、组控制器密钥服务器标识、组管理信息和GO的数字签名。这将允许GM确定集团政策是否与本地政策兼容。
The Request to Join Error message is sent from the GC/KS to the GM in response to an unaccepted Request to Join. This message is not signed by the GC/KS for two reasons: 1) the GM, at this point, has no knowledge of who is authorized to act as a GC/KS, and so the signature would thus be meaningless to the GM, and 2) signing responses to denied join requests would provide a denial of service potential. The message contains an indication of the error condition. The possible values for this error condition are: Invalid-Payload-Type, Invalid-Version, Invalid-Group-ID, Invalid-Sequence-ID, Payload-Malformed, Invalid-ID-Information, Invalid-Certificate, Cert-Type-Unsupported, Invalid-Cert-Authority, Authentication-Failed, Certificate-Unavailable, Unauthorized-Request, Prohibited-by-Group-Policy, and Prohibited-by-Locally-Configured-Policy.
加入请求错误消息从GC/KS发送给GM，以响应未接受的加入请求。GC/KS没有对该消息进行签名有两个原因：1）此时GM不知道谁有权担任GC/KS，因此签名对GM来说没有意义，2）对拒绝的加入请求的签名响应将提供拒绝服务的可能性。该消息包含错误条件的指示。此错误条件的可能值为：无效负载类型、无效版本、无效组ID、无效序列ID、负载格式错误、无效ID信息、无效证书、证书类型不受支持、证书授权无效、身份验证失败、证书不可用、未经授权的请求、组策略禁止、，并且被本地配置的策略禁止。
The Key Download Ack/Failure message indicates Key Download receipt status at the GM. It is a GM-signed message containing freshness data and status.
密钥下载确认/失败消息表示GM处的密钥下载接收状态。这是一条GM签署的消息，包含新鲜度数据和状态。
The Lack_of_Ack message is sent from the GC/KS to the GM in response to an invalid or absent Key Download Ack/Failure message. The signed message contains freshness and status data and is used to warn the GM of impending eviction from the group if a valid Key Download Ack/Failure is not sent. Eviction means that the member will be excluded from the group after the next Rekey Event. The policy of when a particular group needs to rekey itself is stated in the policy token. Eviction is discussed further in Section 5.3.2.1.
缺少确认消息从GC/KS发送至GM，以响应无效或缺少密钥下载确认/失败消息。签名消息包含新鲜度和状态数据，用于在未发送有效密钥下载确认/失败时警告GM即将从组中退出。逐出意味着该成员将在下一次重新设置密钥事件后被排除在组之外。策略令牌中说明了特定组何时需要重新设置自身密钥的策略。第5.3.2.1节将进一步讨论驱逐问题。
For the following message structure sections, details about payload format and processing can be found in Section 7. Each message is identified by its exchange type in the header of the message. Nonces MUST be present in the messages unless synchronization time is available to the system.
对于以下消息结构部分，有关有效负载格式和处理的详细信息可在第7部分中找到。每条消息都由消息头中的交换类型标识。除非系统有可用的同步时间，否则消息中必须存在nonce。
The exchange type for Request to Join is eight (8).
请求加入的交换类型为八（8）。
The components of a Request to Join Message are shown in Table 1.
请求加入消息的组件如表1所示。
Table 1: Request to Join (RTJ) Message Definition
表1：请求加入（RTJ）消息定义
Message Name : Request to Join (RTJ) Dissection : {HDR-GrpID, Key Creation, Nonce_I, [VendorID], : [Notif_Mechanism_Choices], [Notif_Cookie], : [Notif_IPValue]} SigM, [Cert] Payload Types : GSAKMP Header, Key Creation, [Nonce], [Vendor ID], Signature, [Certificate], [Notifications]
消息名称：加入请求（RTJ）解析：{HDR GrpID，密钥创建，Nonce_I，[VendorID]，：[Notif_机制选择]，[Notif_Cookie]，：[Notif_IPValue]}SigM，[Cert]有效负载类型：GSAKMP头，密钥创建，[Nonce]，[Vendor ID]，[Signature，[Certificate]，[Notifications]
SigM : Signature of Group Member
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
SigM : Signature of Group Member
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
As shown by Figure 1, a potential GM MUST generate and send an RTJ message to request permission to join the group. At a minimum, the GM MUST be able to manually configure the destination for the RTJ. As defined in the dissection of the RTJ message, this message MUST contain a Key Creation payload for KEK determination. A Nonce payload MUST be included for freshness and the Nonce_I value MUST be saved for potential later use. The GC/KS will use this supplied nonce only if the policy token for this group defines the use of nonces versus synchronization time. An OPTIONAL Notification payload of type Mechanism Choices MAY be included to identify the mechanisms the GM wants to use. Absence of this payload will cause the GC/KS to select appropriate default policy-token-specified mechanisms for the Key Download.
如图1所示，潜在的GM必须生成并发送RTJ消息以请求加入该组的权限。至少，GM必须能够手动配置RTJ的目的地。如RTJ消息剖析中所定义，该消息必须包含KEK确定的密钥创建有效负载。必须包含一个Nonce有效负载以保持新鲜度，并且必须保存Nonce_I值以备将来使用。仅当此组的策略令牌定义了nonce的使用与同步时间时，GC/KS才会使用此提供的nonce。可包括机制选择类型的可选通知有效负载，以识别GM想要使用的机制。缺少此有效负载将导致GC/KS为密钥下载选择适当的默认策略令牌指定机制。
In response, the GC/KS accepts or denies the request based on local configuration. <Process RTJ> indicates the GC/KS actions that will determine if the RTJ will be acted upon. The following checks SHOULD be performed in the order presented.
作为响应，GC/KS根据本地配置接受或拒绝请求<Process RTJ>指示GC/KS操作，该操作将确定是否对RTJ进行操作。应按照提供的顺序执行以下检查。
In this procedure, the GC/KS MUST verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, then the identity of the sender is extracted from the Signature payload. This identity MUST be used to perform access control checks and find the GMs credentials (e.g., certificate) for message verification. It MUST also be used in the Key Download message. Then, the GC/KS will verify the signature on the message to ensure its authenticity. The
在此过程中，GC/KS必须验证消息头的格式是否正确，并通过检查GroupID的值来确认此消息适用于此组。如果报头检查通过，则从签名有效负载中提取发送者的身份。此标识必须用于执行访问控制检查并查找GMs凭据（例如证书）以进行消息验证。它还必须用于密钥下载消息中。然后，GC/KS将验证消息上的签名以确保其真实性。这个
GC/KS MUST use verified and trusted authentication material from a known root. If the message signature verifies, the GC/KS then confirms that all required payloads are present and properly formatted based upon the mechanisms announced and/or requested. If all checks pass, the GC/KS will create and send the Key Download message as described in Section 5.2.1.2.
GC/KS必须使用来自已知根目录的已验证和受信任的身份验证材料。如果消息签名得到验证，则GC/KS随后确认所有必需的有效载荷都存在，并且根据宣布和/或请求的机制正确格式化。如果所有检查都通过，GC/KS将创建并发送第5.2.1.2节所述的密钥下载消息。
If the GM receives no response to the RTJ within the GM's locally configured timeout value, the GM SHOULD resend the RTJ message up to three (3) times.
如果GM在其本地配置的超时值内未收到对RTJ的响应，则GM应最多重新发送RTJ消息三（3）次。
NOTE: At any one time, a GC/KS MUST process no more than one (1) valid RTJ message from a given GM per group until its pending registration protocol exchange concludes.
注意：在任何时候，GC/KS必须处理每个组中来自给定GM的不超过一（1）条有效RTJ消息，直到其挂起的注册协议交换结束。
If any error occurs during RTJ message processing, and the GC/KS is running in Terse Mode, the registration session MUST be terminated, and all saved state information MUST be cleared.
如果在RTJ消息处理过程中发生任何错误，并且GC/KS以简洁模式运行，则必须终止注册会话，并且必须清除所有保存的状态信息。
The OPTIONAL Notification payload of type Cookie is discussed in Section 5.2.2.
第5.2.2节讨论了Cookie类型的可选通知有效负载。
The OPTIONAL Notification payload of type IPValue may be used for the GM to convey a specific IP value to the GC/KS.
类型为IPValue的可选通知有效负载可用于GM向GC/KS传送特定IP值。
The exchange type for Key Download is nine (9).
密钥下载的交换类型为九（9）。
The components of a Key Download Message are shown in Table 2:
密钥下载消息的组件如表2所示：
Table 2: Key Download (KeyDL) Message Definition
表2：密钥下载（KeyDL）消息定义
Message Name : Key Download (KeyDL) Dissection : {HDR-GrpID, Member ID, [Nonce_R, Nonce_C], Key Creation, (Policy Token)*, (Key Download)*, [VendorID]} SigC, [Cert] Payload Types : GSAKMP Header, Identification, [Nonce], Key Creation, Policy Token, Key Download, [Vendor ID], Signature, [Certificate]
消息名称：密钥下载（KeyDL）解析：{HDR GrpID，成员ID，[Nonce_R，Nonce_C]，密钥创建，（策略令牌）*，（密钥下载）*，[VendorID]}SigC，[Cert]有效负载类型：GSAKMP头，标识，[Nonce]，密钥创建，策略令牌，密钥下载，[VendorID]，签名，[Certificate]
SigC : Signature of Group Controller Key Server
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
(data)* : Indicates encrypted information
SigC : Signature of Group Controller Key Server
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
(data)* : Indicates encrypted information
In response to a properly formed and verified RTJ message, the GC/KS creates and sends the KeyDL message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: GM identification, Key Creation material, encrypted policy token, encrypted key information, and signature information. If synchronized time is not available, the Nonce payloads MUST be included in the message for freshness.
为了响应格式正确且经过验证的RTJ消息，GC/KS创建并发送KeyDL消息。按照消息剖析中的定义，此消息必须包含有效负载以保存以下信息：GM标识、密钥创建材料、加密策略令牌、加密密钥信息和签名信息。如果同步时间不可用，则必须在消息中包含Nonce有效负载以获取新鲜度。
If present, the nonce values transmitted MUST be the GC/KS's generated Nonce_R value and the combined Nonce_C value that was generated by using the GC/KS's Nonce_R value and the Nonce_I value received from the GM in the RTJ.
如果存在，则传输的nonce值必须是GC/KS生成的nonce\R值以及通过使用GC/KS的nonce\R值和从RTJ中的GM接收的nonce\u I值生成的组合nonce\R值。
If two-party key determination is used, the key creation material supplied by the GM and/or the GC/KS will be used to generate the key. Generation of this key is dependent on the key exchange, as defined in Section 7.11, "Key Creation Payload". The policy token and key material are encrypted in the generated key.
如果使用双方密钥确定，则GM和/或GC/KS提供的密钥创建材料将用于生成密钥。该密钥的生成取决于密钥交换，如第7.11节“密钥创建有效载荷”中所定义。策略令牌和密钥材料在生成的密钥中加密。
The GM MUST be able to process the Key Download message. <Process KeyDL> indicates the GM actions that will determine how the Key Download message will be acted upon. The following checks SHOULD be performed in the order presented.
GM必须能够处理钥匙下载信息<Process KeyDL>表示GM将决定如何对密钥下载消息进行操作的操作。应按照提供的顺序执行以下检查。
In this procedure, the GM will verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GM MUST confirm that this message was intended for itself by comparing the Member ID in the Identification payload to its identity.
在此过程中，GM将通过检查GroupID的值来验证消息头的格式是否正确，并确认此消息适用于此组。如果报头检查通过，GM必须通过将识别有效载荷中的成员ID与其身份进行比较来确认该消息是针对其自身的。
After identification confirmation, the freshness values are checked. If using nonces, the GM MUST use its saved Nonce_I value, extract the received GC/KS Nonce_R value, compute the combined Nonce_C value, and compare it to the received Nonce_C value. If not using nonces, the GM MUST check the timestamp in the Signature payload to determine if the message is new.
确认标识后，检查新鲜度值。如果使用Nonce，GM必须使用其保存的Nonce_I值，提取接收的GC/KS Nonce_R值，计算组合的Nonce_C值，并将其与接收的Nonce_C值进行比较。如果不使用nonce，GM必须检查签名有效负载中的时间戳，以确定消息是否为新消息。
After freshness is confirmed, the signature MUST be verified to ensure its authenticity. The GM MUST use verified and trusted authentication material from a known root. If the message signature verifies, the key creation material is extracted from the Key Creation payload to generate the KEK. This KEK is then used to decrypt the policy token data. The signature on the policy token MUST be verified. Access control checks MUST be performed on both the GO and the GC/KS to determine both their authorities within this group. After all these checks pass, the KEK can then be used to
在确认新鲜度后，必须验证签名以确保其真实性。GM必须使用来自已知根目录的经验证和受信任的认证材料。如果消息签名验证，则从密钥创建有效负载中提取密钥创建材料以生成KEK。然后使用该KEK对策略令牌数据进行解密。必须验证策略令牌上的签名。必须对GO和GC/KS执行访问控制检查，以确定其在该组中的权限。在所有这些检查通过后，可以使用桶
decrypt and process the key material from the Key Download payload. If all is successful, the GM will create and send the Key Download - Ack/Failure message as described in Section 5.2.1.4.
解密并处理密钥下载负载中的密钥材料。如果全部成功，GM将创建并发送第5.2.1.4节所述的密钥下载-确认/失败消息。
The Policy Token and Key Download Payloads are sent encrypted in the KEK generated by the Key Creation Payload information using the mechanisms defined in the group announcement. This guarantees that the sensitive policy and key data for the group and potential rekey data for this individual cannot be read by anyone but the intended recipient.
策略令牌和密钥下载有效载荷在密钥创建有效载荷信息生成的KEK中使用组公告中定义的机制加密发送。这保证了集团的敏感政策和关键数据以及该个人的潜在密钥数据只能由预期接收者读取。
If any error occurs during KeyDL message processing, regardless of whether the GM is in Terse or Verbose Mode, the registration session MUST be terminated, the GM MUST send a Key Download - Ack/Failure message, and all saved state information MUST be cleared. If in Terse Mode, the Notification Payload will be of type NACK to indicate termination. If in Verbose Mode, the Notification Payload will contain the type of error encountered.
如果在KeyDL消息处理过程中发生任何错误，无论GM处于简练或详细模式，都必须终止注册会话，GM必须发送密钥下载-确认/失败消息，并且必须清除所有保存的状态信息。如果处于简洁模式，通知有效负载将为NACK类型，以指示终止。如果处于详细模式，通知负载将包含遇到的错误类型。
The exchange type for Request to Join Error is eleven (11).
请求加入错误的交换类型为十一（11）。
The components of the Request to Join Error Message are shown in Table 3:
请求加入错误消息的组件如表3所示：
Table 3: Request to Join Error (RTJ-Err) Message Definition
表3：请求加入错误（RTJ Err）消息定义
Message Name : Request to Join Error (RTJ-Err)
Dissection : {HDR-GrpID, [Nonce_I], Notification, [VendorID]}
Payload Types : GSAKMP Header, [Nonce] Notification, [Vendor ID]
Message Name : Request to Join Error (RTJ-Err)
Dissection : {HDR-GrpID, [Nonce_I], Notification, [VendorID]}
Payload Types : GSAKMP Header, [Nonce] Notification, [Vendor ID]
In response to an unacceptable RTJ, the GC/KS MAY send a Request to Join Error (RTJ-Err) message containing an appropriate Notification payload. Note that the RTJ-Err message is not a signed message for the following reasons: the lack of awareness on the GM's perspective of who is a valid GC/KS as well as the need to protect the GC/KS from signing messages and using valuable resources. Following the sending of an RTJ-Err, the GC/KS MUST terminate the session, and all saved state information MUST be cleared.
为了响应不可接受的RTJ，GC/KS可发送包含适当通知有效负载的加入请求错误（RTJ Err）消息。请注意，RTJ Err消息不是签名消息，原因如下：GM对谁是有效的GC/KS缺乏认识，以及需要保护GC/KS不签名消息和使用有价值的资源。发送RTJ Err后，GC/KS必须终止会话，并且必须清除所有保存的状态信息。
Upon receipt of an RTJ-Err message, the GM will validate the following: the GroupID in the header belongs to a group to which the GM has sent an RTJ, and, if present, the Nonce_I matches a Nonce_I sent in an RTJ to that group. If the above checks are successful, the GM MAY terminate the state associated with that GroupID and
收到RTJ Err消息后，GM将验证以下内容：标头中的GroupID属于GM已向其发送RTJ的组，如果存在，则Nonce_I与RTJ中发送给该组的Nonce_I匹配。如果上述检查成功，GM可终止与该GroupID关联的状态，并
nonce. The GM SHOULD be capable of receiving a valid KeyDownload message for that GroupID and nonce after receiving an RTJ-Err for a locally configured amount of time.
暂时的。在本地配置的时间内收到RTJ Err后，GM应该能够接收该GroupID和nonce的有效KeyDownload消息。
The exchange type for Key Download - Ack/Failure is four (4).
密钥下载-确认/失败的交换类型为四（4）。
The components of the Key Download - Ack/Failure Message are shown in Table 4:
密钥下载-确认/失败消息的组件如表4所示：
Table 4: Key Download - Ack/Failure (KeyDL-A/F) Message Definition
Table 4: Key Download - Ack/Failure (KeyDL-A/F) Message Definition
Message Name : Key Download - Ack/Failure (KeyDL-A/F)
Dissection : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM
Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor
ID], Signature
SigM : Signature of Group Member
{}SigX : Indicates fields used in Signature
Message Name : Key Download - Ack/Failure (KeyDL-A/F)
Dissection : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM
Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor
ID], Signature
SigM : Signature of Group Member
{}SigX : Indicates fields used in Signature
In response to a properly processed KeyDL message, the GM creates and sends the KeyDL-A/F message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: Notification payload of type Acknowledgement (ACK) and signature information. If synchronized time is not available, the Nonce payload MUST be present for freshness, and the nonce value transmitted MUST be the GM's generated Nonce_C value. If the GM does not receive a KeyDL message within a locally configured amount of time, the GM MAY send a new RTJ. If the GM receives a valid LOA (see Section 5.2.1.5) message from the GC/KS before receipt of a KeyDL message, the GM SHOULD send a KeyDL-A/F message of type NACK followed by a new RTJ.
为了响应正确处理的KeyDL消息，GM创建并发送KeyDL-a/F消息。如消息剖析中所定义的，此消息必须包含有效负载以保存以下信息：确认类型的通知有效负载（ACK）和签名信息。如果同步时间不可用，则必须存在Nonce有效负载以保持新鲜度，并且传输的Nonce值必须是GM生成的Nonce_C值。如果GM在本地配置的时间内未收到KeyDL消息，则GM可发送新的RTJ。如果GM在收到KeyDL消息之前收到GC/KS发出的有效LOA（见第5.2.1.5节）消息，GM应发送NACK类型的KeyDL-a/F消息，然后发送新的RTJ。
The GC/KS MUST be able to process the KeyDL-A/F message. <Process KeyDL-A/F> indicates the GC/KS actions that will determine how the KeyDL-A/F message will be acted upon. The following checks SHOULD be performed in the order presented.
GC/KS必须能够处理KeyDL-A/F消息<Process KeyDL-A/F>指示GC/KS操作，该操作将确定如何对KeyDL-A/F消息进行操作。应按照提供的顺序执行以下检查。
In this procedure, the GC/KS will verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GC/KS MUST check the message for freshness. If using nonces, the GC/KS MUST use its saved Nonce_C value and compare it for equality with the received Nonce_C value. If not using nonces, the GC/KS MUST check the timestamp in the Signature payload to determine if the message is new. After freshness is confirmed, the signature MUST be verified to ensure its authenticity. The GC/KS MUST use verified and trusted authentication material from a known root. If the message
在此过程中，GC/KS将验证消息头的格式是否正确，并通过检查GroupID的值来确认此消息是针对该组的。如果标头检查通过，GC/KS必须检查消息的新鲜度。如果使用Nonce，则GC/KS必须使用其保存的Nonce_C值，并将其与接收到的Nonce_C值进行相等性比较。如果不使用nonce，GC/KS必须检查签名有效负载中的时间戳，以确定消息是否为新消息。在确认新鲜度后，必须验证签名以确保其真实性。GC/KS必须使用来自已知根目录的已验证和受信任的身份验证材料。如果消息
signature verifies, the GC/KS processes the Notification payload. If the notification type is of type ACK, then the registration has completed successfully, and both parties SHOULD remove state information associated with this GM's registration.
签名验证后，GC/KS处理通知有效负载。如果通知类型为ACK类型，则注册已成功完成，双方应删除与此GM注册相关的状态信息。
If the GC/KS does not receive a KeyDL-A/F message of proper form or is unable to correctly process the KeyDL-A/F message, the Notification payload type is any value except ACK; or if no KeyDL-A/F message is received within the locally configured timeout, the GC/KS MUST evict this GM from the group in the next policy-defined Rekey Event. The GC/KS MAY send the OPTIONAL Lack_of_Ack message if running in Verbose Mode as defined in Section 5.2.1.5.
如果GC/KS没有收到正确形式的KeyDL-a/F消息或无法正确处理KeyDL-a/F消息，则通知有效负载类型为ACK以外的任何值；或者，如果在本地配置的超时时间内未收到KeyDL-A/F消息，则GC/KS必须在下一个策略定义的Rekey事件中将此GM从组中逐出。如果在第5.2.1.5节定义的详细模式下运行，GC/KS可能会发送可选的缺少确认消息。
The exchange type for Lack of Ack is twelve (12).
缺少Ack的交换类型为十二（12）。
The components of a Lack of Ack Message are shown in Table 5:
缺少确认消息的组件如表5所示：
Table 5: Lack of Ack (LOA) Message Definition
表5：缺少Ack（LOA）消息定义
Message Name : Lack of Ack (LOA) Dissection : {HDR-GrpID, Member ID, [Nonce_R, Nonce_C], Notification, [VendorID]} SigC, [Cert] Payload Types : GSAKMP Header, Identification, [Nonce], Notification, [Vendor ID], Signature, [Certificate]
消息名称：缺少Ack（LOA）解析：{HDR GrpID，成员ID，[Nonce_R，Nonce_C]，通知，[VendorID]}SigC，[Cert]有效负载类型：GSAKMP头，标识，[Nonce]，通知，[VendorID]，签名，[Certificate]
SigC : Signature of Group Controller Key Server
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
SigC : Signature of Group Controller Key Server
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
If the GC/KS's local timeout value expires prior to receiving a KeyDL-A/F from the GM, the GC/KS MAY create and send a LOA message to the GM. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: GM identification, Notification of error, and signature information.
如果GC/KS的本地超时值在从GM接收KeyDL-a/F之前过期，则GC/KS可创建LOA消息并将其发送给GM。如消息剖析中所定义，此消息必须包含有效载荷以保存以下信息：GM标识、错误通知和签名信息。
If synchronized time is not available, the Nonce payloads MUST be present for freshness, and the nonce values transmitted MUST be the GC/KS's generated Nonce_R value and the combined Nonce_C value which was generated by using the GC/KS's Nonce_R value and the Nonce_I value received from the GM in the RTJ. These values were already generated during the Key Download message phase.
如果同步时间不可用，则必须存在用于新鲜度的Nonce有效负载，并且传输的Nonce值必须是GC/KS生成的Nonce_R值以及通过使用GC/KS的Nonce_R值和从RTJ中的GM接收的Nonce_I值生成的组合Nonce_C值。这些值已在密钥下载消息阶段生成。
The GM MAY be able to process the LOA message based upon local configuration. <Process LOA> indicates the GM actions that will determine how the LOA message will be acted upon. The following checks SHOULD be performed in the order presented.
GM可能能够根据本地配置处理LOA消息<Process LOA>表示GM将决定如何对LOA消息采取行动的行动。应按照提供的顺序执行以下检查。
In this procedure, the GM MUST verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GM MUST confirm that this message was intended for itself by comparing the Member ID in the Identification payload to its identity. After identification confirmation, the freshness values are checked. If using nonces, the GM MUST use its save Nonce_I value, extract the received GC/KS Nonce_R value, compute the combined Nonce_C value, and compare it to the received Nonce_C value. If not using nonces, the GM MUST check the timestamp in the Signature payload to determine if the message is new. After freshness is confirmed, access control checks MUST be performed on the GC/KS to determine its authority within this group. Then signature MUST be verified to ensure its authenticity, The GM MUST use verified and trusted authentication material from a known root.
在此过程中，GM必须验证消息头的格式是否正确，并通过检查GroupID的值确认此消息适用于此组。如果报头检查通过，GM必须通过将识别有效载荷中的成员ID与其身份进行比较来确认该消息是针对其自身的。确认标识后，检查新鲜度值。如果使用Nonce，GM必须使用其save Nonce_I值，提取接收到的GC/KS Nonce_R值，计算组合的Nonce_C值，并将其与接收到的Nonce_C值进行比较。如果不使用nonce，GM必须检查签名有效负载中的时间戳，以确定消息是否为新消息。确认新鲜度后，必须对GC/KS进行访问控制检查，以确定其在此组中的权限。然后必须对签名进行验证以确保其真实性，GM必须使用已知根目录中经过验证和信任的认证材料。
If the checks succeed, the GM SHOULD resend a KeyDL-A/F for that session.
如果检查成功，GM应为该会话重新发送KeyDL-a/F。
This section defines an OPTIONAL capability that MAY be implemented into GSAKMP when using IP-based groups. The information in this section borrows heavily from [IKEv2] as this protocol has already worked through this issue and GSAKMP is copying this concept. This section will contain paraphrased sections of [IKEv2] modified for GSAKMP to define the purpose of Cookies.
本节定义了在使用基于IP的组时可在GSAKMP中实现的可选功能。本节中的信息大量借鉴[IKEv2]，因为该协议已经解决了这个问题，GSAKMP正在复制这个概念。本节将包含[IKEv2]中为GSAKMP修改的释义部分，以定义Cookie的用途。
An optional Cookie mode is being defined for the GSAKMP to help against DoS attacks.
正在为GSAKMP定义可选的Cookie模式，以帮助抵御DoS攻击。
The term "cookies" originates with Karn and Simpson [RFC2522] in Photuris, an early proposal for key management with IPSec. The ISAKMP fixed message header includes two eight-octet fields titled "cookies". Instead of placing this cookie data in the header, in GSAKMP this data is moved into a Notification payload.
“cookies”一词起源于Photuris中的Karn和Simpson[RFC2522]，这是一个关于IPSec密钥管理的早期建议。ISAKMP固定消息头包含两个名为“cookies”的八位字节字段。在GSAKMP中，该数据被移动到通知负载中，而不是将该cookie数据放在头中。
An expected attack against GSAKMP is state and CPU exhaustion, where the target GC/KS is flooded with Request to Join requests from forged IP addresses. This attack can be made less effective if a GC/KS implementation uses minimal CPU and commits no state to the communication until it knows the initiator potential GM can receive packets at the address from which it claims to be sending them. To
对GSAKMP的预期攻击是状态和CPU耗尽，目标GC/KS中充斥着来自伪造IP地址的加入请求。如果GC/KS实现使用最少的CPU，并且在知道潜在的发起方GM可以在其声称发送数据包的地址接收数据包之前，不向通信提交任何状态，则此攻击的有效性可能会降低。到
accomplish this, the GC/KS (when operating in Cookie mode) SHOULD reject initial Request to Join messages unless they contain a Notification payload of type "cookie". It SHOULD instead send a Cookie Download message as a response to the RTJ and include a cookie in a notify payload of type Cookie_Required. Potential GMs who receive such responses MUST retry the Request to Join message with the responder-GC/KS-supplied cookie in its notification payload of type Cookie, as defined by the optional Notification payload of the Request to Join Msg in Section 5.2.1.1. This initial exchange will then be as shown in Figure 2 with the components of the new message Cookie Download shown in Table 6. The exchange type for Cookie Download is ten (10).
为此，GC/KS（在Cookie模式下操作时）应拒绝加入消息的初始请求，除非它们包含“Cookie”类型的通知负载。相反，它应该发送一个Cookie下载消息作为对RTJ的响应，并在类型为Cookie_Required的通知负载中包含一个Cookie。收到此类响应的潜在GMs必须在其cookie类型的通知有效负载中使用响应者GC/KS提供的cookie重试加入请求消息，如第5.2.1.1节中加入请求消息的可选通知有效负载所定义。这个初始交换如图2所示，新消息Cookie下载的组件如表6所示。Cookie下载的交换类型为十（10）。
CONTROLLER MESSAGE MEMBER
in Cookie Mode
!<--Request to Join without Cookie Info---!
<Gen Cookie>! !
<Response >! !
!----------Cookie Download--------------->!
! ! <Process CD>
!<----Request to Join with Cookie Info----!
<Process> ! !
<RTJ > ! !
!-------------Key Download--------------->!
! ! <Proc KeyDL>
!<-----Key Download - Ack/Failure--------!
<Process >! !
<KeyDL-A/F>! !
!<=======SHARED KEYED GROUP SESSION======>!
CONTROLLER MESSAGE MEMBER
in Cookie Mode
!<--Request to Join without Cookie Info---!
<Gen Cookie>! !
<Response >! !
!----------Cookie Download--------------->!
! ! <Process CD>
!<----Request to Join with Cookie Info----!
<Process> ! !
<RTJ > ! !
!-------------Key Download--------------->!
! ! <Proc KeyDL>
!<-----Key Download - Ack/Failure--------!
<Process >! !
<KeyDL-A/F>! !
!<=======SHARED KEYED GROUP SESSION======>!
Figure 2: GSAKMP Ladder Diagram with Cookies
图2：带有Cookies的GSAKMP梯形图
Table 6: Cookie Download Message Definition
表6:Cookie下载消息定义
Message Name : Cookie Download
Dissection : {HDR-GrpID, Notif_COOKIE_REQUIRED, [VendorID]}
Payload Types : GSAKMP Header, Notification, [Vendor ID]
Message Name : Cookie Download
Dissection : {HDR-GrpID, Notif_COOKIE_REQUIRED, [VendorID]}
Payload Types : GSAKMP Header, Notification, [Vendor ID]
The first two messages do not affect any GM or GC/KS state except for communicating the cookie.
前两条消息不影响任何GM或GC/KS状态，但与cookie通信除外。
A GSAKMP implementation SHOULD implement its GC/KS cookie generation in such a way as not to require any saved state to recognize its valid cookie when the second Request to Join message arrives. The exact algorithms and syntax they use to generate cookies does not affect interoperability and hence is not specified here.
GSAKMP实现应该以这样的方式实现其GC/KS cookie生成，即当第二个加入请求消息到达时，不需要任何保存的状态来识别其有效cookie。它们用于生成cookie的确切算法和语法不会影响互操作性，因此此处未指定。
The following is an example of how an endpoint could use cookies to implement limited DoS protection.
以下是端点如何使用cookie实现有限的DoS保护的示例。
A good way to do this is to set the cookie to be:
执行此操作的一个好方法是将cookie设置为：
Cookie = <SecretVersionNumber> | Hash(Ni | IPi | <secret>)
Cookie = <SecretVersionNumber> | Hash(Ni | IPi | <secret>)
where <secret> is a randomly generated secret known only to the responder GC/KS and periodically changed, Ni is the nonce value taken from the initiator potential GM, and IPi is the asserted IP address of the candidate GM. The IP address is either the IP header's source IP address or else the IP address contained in the optional Notification "IPvalue" payload (if it is present). <SecretVersionNumber> should be changed whenever <secret> is regenerated. The cookie can be recomputed when the "Request to Join with Cookie Info" arrives and compared to the cookie in the received message. If it matches, the responder GC/KS knows that all values have been computed since the last change to <secret> and that IPi MUST be the same as the source address it saw the first time. Incorporating Ni into the hash assures that an attacker who sees only the Cookie_Download message cannot successfully forge a "Request to Join with Cookie Info" message. This Ni value MUST be the same Ni value from the original "Request to Join" message for the calculation to be successful.
其中，<secret>是只对响应者GC/KS已知并定期更改的随机生成的秘密，Ni是从启动器潜在GM获取的nonce值，IPi是候选GM的断言IP地址。IP地址是IP报头的源IP地址或可选通知中包含的IP地址“IPvalue”有效负载（如果存在）。<SecretVersionNumber>应在重新生成<secret>时更改。当“请求加入cookie信息”时，可以重新计算cookie“到达并与接收到的消息中的cookie进行比较。如果匹配，响应程序GC/KS知道自上次更改为<secret>以来已计算了所有值，并且IPi必须与第一次看到的源地址相同。将Ni合并到哈希中可确保仅看到Cookie_下载消息的攻击者无法成功伪造“请求加入Cookie信息”消息。此Ni值必须与原始“加入请求”消息中的Ni值相同，计算才能成功。
If a new value for <secret> is chosen while connections are in the process of being initialized, a "Request to Join with Cookie Info" might be returned with a <SecretVersionNumber> other than the current one. The responder GC/KS in that case MAY reject the message by sending another response with a new cookie, or it MAY keep the old value of <secret> around for a short time and accept cookies computed from either one. The responder GC/KS SHOULD NOT accept cookies indefinitely after <secret> is changed, since that would defeat part of the denial of service protection. The responder GC/KS SHOULD change the value of <secret> frequently, especially if under attack.
如果在初始化连接的过程中为<secret>选择了一个新值，则可能会返回一个<SecretVersionNumber>而不是当前值的“使用Cookie信息加入的请求”。在这种情况下，响应者GC/KS可以通过发送另一个带有新cookie的响应来拒绝消息，或者它可以在短时间内保留<secret>的旧值，并接受从其中任何一个计算出的cookie。响应者GC/KS不应在<secret>更改后无限期地接受cookie，因为这将破坏部分拒绝服务保护。响应者GC/KS应经常更改<secret>的值，尤其是在受到攻击时。
An alternative example for Cookie value generation in a NAT environment is to substitute the IPi value with the IPValue received in the Notification payload in the RTJ message. This scenario is indicated by the presence of the Notification payload of type IPValue. With this substitution, a calculation similar to that described above can be used.
NAT环境中生成Cookie值的另一个示例是用RTJ消息中通知有效负载中接收的IPi值替换IPi值。此场景由IPValue类型的通知有效负载的存在表示。通过这种替代，可以使用与上述类似的计算。
This section describes an OPTIONAL capability that may be implemented in a structured system where the authorized (S-)GC/KS is known in advance through out-of-band means and where synchronized time is available.
本节描述了可在结构化系统中实施的可选功能，其中授权（S-）GC/KS通过带外方式预先已知，且同步时间可用。
Unlike Standard Group Establishment, in the Receive-Only system, the GMs and (S-)GC/KSes operate in Terse Mode and exchange one message only: the Key Download. Potential new GMs do not send an RTJ. (S-)GC/KSes do not expect Key Download - ACK/Failure messages and do not remove GMs for lack or receipt of the message.
与标准组建立不同，在仅接收系统中，GMs和（S-）GC/KSE以简洁模式运行，只交换一条消息：密钥下载。潜在的新GMs不发送RTJ。（S-）GC/KSE不希望收到密钥下载确认/失败消息，也不会因为缺少或收到消息而删除GMs。
Operation is as follows: upon notification via an authorized out-of-band event, the (S-)GC/KS forms and sends a Key Download message to the new member with the Nonce payloads ABSENT. The GM verifies
操作如下：通过授权带外事件发出通知后，（S-）GC/KS形成密钥下载消息，并向新成员发送一条密钥下载消息，其中不存在Nonce有效负载。总经理核实
- the ID payload identifies that GM
- ID有效载荷识别GM
- the timestamp in the message is fresh
- 消息中的时间戳是新的
- the message is signed by an authorized (S-)GC/KS
- 该消息由授权的（S-）GC/KS签名
- the signature on the message verifies
- 消息上的签名验证
When using a Diffie-Hellman Key Creation Type for receive-only members, a static-ephemeral model is assumed: the Key Creation payload in the Key Download message contains the (S-)GC/KS's public component. The member's public component is assumed to be obtained through secure out-of-band means.
当对仅接收成员使用Diffie-Hellman密钥创建类型时，假定静态临时模型：密钥下载消息中的密钥创建有效负载包含（S-）GC/KS的公共组件。假定成员的公共组件通过安全带外方式获得。
The Group Maintenance phase includes member joins and leaves, group rekey activities, policy updates, and group destruction. These activities are presented in the following sections.
组维护阶段包括成员加入和离开、组密钥更新活动、策略更新和组销毁。以下各节介绍了这些活动。
A Rekey Event is any action, including a compromise report or key expiration, that requires the creation of a new group key and/or rekey information.
重设密钥事件是指需要创建新组密钥和/或重设密钥信息的任何操作，包括泄露报告或密钥过期。
Once an event has been identified (as defined in the group security policy token), the GC/KS MUST create and provide a signed message containing the GTPK and rekey information to the group.
一旦识别出事件（如组安全策略令牌中所定义），GC/K必须创建并向组提供包含GTPK和密钥信息的签名消息。
Each GM who receives this message MUST verify the signature on the message to ensure its authenticity. If the message signature does not verify, the message MUST be discarded. Upon verification, the GM will find the appropriate rekey download packet and decrypt the information with a stored rekey key(s). If a new Policy Token is distributed with the message, it MUST be encrypted in the old GTPK.
收到此消息的每个GM必须验证消息上的签名，以确保其真实性。如果消息签名未验证，则必须丢弃该消息。在验证后，GM将找到适当的重新密钥下载包，并使用存储的重新密钥解密信息。如果新策略令牌与消息一起分发，则必须在旧GTPK中对其进行加密。
The exchange type for Rekey Event is five (5).
重设密钥事件的交换类型为五（5）。
The components of a Rekey Event message are shown in Table 7:
Rekey事件消息的组件如表7所示：
Table 7: Rekey Event Message Definition
表7：重新设置事件消息定义
Message Name : Rekey Event Dissection : {HDR-GrpID, ([Policy Token])*, Rekey Array, [VendorID]}SigC, [Cert] Payload Types : GSAKMP Header, [Policy Token], Rekey Event, [Vendor ID], Signature, [Certificate],
消息名称：重设密钥事件解析：{HDR GrpID，（[Policy Token]）*，重设密钥数组，[VendorID]}SigC，[Cert]有效负载类型：GSAKMP头，[Policy Token]，重设密钥事件，[Vendor ID]，签名，[Certificate]，
SigC : Signature of Group Controller Key Server
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
(data)* : Indicates encrypted information
[] : Indicate an optional data item
SigC : Signature of Group Controller Key Server
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
(data)* : Indicates encrypted information
[] : Indicate an optional data item
New policy tokens are sent via the Rekey Event message. These policy updates may be coupled with an existing rekey event or may be sent in a message with the Rekey Event Type of the Rekey Event Payload set to None(0) (see Section 7.5.1).
通过重新设置密钥事件消息发送新策略令牌。这些策略更新可与现有的重新密钥事件耦合，或可在重新密钥事件有效载荷的重新密钥事件类型设置为无（0）的消息中发送（见第7.5.1节）。
A policy token MUST NOT be processed if the processing of the Rekey Event message carrying it fails. Policy token processing is type dependent and is beyond the scope of this document.
如果处理携带策略令牌的密钥更新事件消息失败，则不得处理策略令牌。策略令牌处理依赖于类型，超出了本文档的范围。
Group destruction is also accomplished via the Rekey Event message. In a Rekey Event message for group destruction, the Sequence ID is set to 0xFFFFFFFF. Upon receipt of this authenticated Rekey Event message, group components MUST terminate processing of information associated with the indicated group.
组销毁也通过重新设置密钥事件消息完成。在组销毁的重设密钥事件消息中，序列ID设置为0xFFFFFF。在收到此经过身份验证的密钥更新事件消息后，组组件必须终止处理与所示组关联的信息。
There are several conditions under which a member will leave a group: eviction, voluntary departure without notice, and voluntary departure with notice (de-registration). Each of these is discussed in this section.
成员离开团体的条件有以下几种：驱逐、未经通知自愿离开和通知自愿离开（注销登记）。本节将讨论其中的每一项。
At some point in the group's lifetime, it may be desirable to evict one or more members from a group. From a key management viewpoint, this involves revoking access to the group's protected data by "disabling" the departing members' keys. This is accomplished with a Rekey Event, which is discussed in more detail in Section 5.3.1.1. If future access to the group is also to be denied, the members MUST be added to a denied access control list, and the policy token's authorization rules MUST be appropriately updated so that they will exclude the expelled GM(s). After receipt of a new PT, GMs SHOULD evaluate the trustworthiness of any recent application data originating from the expelled GM(s).
在团队生命周期的某个时刻，可能需要从团队中驱逐一个或多个成员。从密钥管理的角度来看，这涉及通过“禁用”离开成员的密钥来撤销对组受保护数据的访问。这是通过一次重新钥匙事件完成的，第5.3.1.1节将对此进行更详细的讨论。如果将来对组的访问也将被拒绝，则必须将成员添加到拒绝访问控制列表中，并且必须适当更新策略令牌的授权规则，以便将被驱逐的GM排除在外。收到新的PT后，GM应评估来自被开除GM的任何最新申请数据的可信度。
If a member wishes to leave a group for which membership imposes no cost or responsibility to that member, then the member MAY merely delete local copies of group keys and cease group activities.
如果成员希望离开其成员资格不向其施加任何费用或责任的组，则该成员仅可删除组密钥的本地副本并停止组活动。
If the membership in the group does impose cost or responsibility to the departing member, then the member SHOULD de-register from the group when that member wishes to leave. De-registration consists of a three-message exchange between the GM and the member's GC/KS: the Request_to_Depart, Departure_Response, and the Departure_Ack. Compliant GSAKMP implementations for GMs SHOULD support the de-registration messages. Compliant GSAKMP implementations for GC/KSes MUST support the de-registration messages.
如果集团中的成员确实对离任成员施加了成本或责任，则该成员应在该成员希望离任时从集团中注销。取消注册包括总经理和会员GC/KS之间的三条消息交换：请求离开、离开响应和离开确认。GMs的兼容GSAKMP实施应支持注销消息。GC/KSE的兼容GSAKMP实现必须支持注销消息。
The Exchange Type for a Request_to_Depart Message is thirteen (13). The components of a Request_to_Depart Message are shown in Table 8.
请求离开消息的交换类型为十三（13）。表8显示了请求到离开消息的组件。
Any GM desiring to initiate the de-registration process MUST generate and send an RTD message to notify the GC/KS of its intent. As defined in the dissection of the RTD message, this message MUST contain payloads to hold the following information: the GC/KS identification and Notification of the desire to leave the group.
任何希望启动注销流程的GM必须生成并发送RTD消息，通知GC/KS其意图。如RTD消息剖析中所定义，该消息必须包含有效载荷，以保存以下信息：GC/KS标识和离开集团的意愿通知。
When synchronization time is not available to the system as defined by the Policy Token, a Nonce payload MUST be included for freshness, and the Nonce_I value MUST be saved for later use. This message MUST then be signed by the GM.
当策略令牌定义的同步时间不适用于系统时，必须包含一个Nonce有效负载以保持新鲜度，并且必须保存Nonce_I值以供以后使用。该信息必须由总经理签字。
Table 8: Request_to_Depart (RTD) Message Definition
表8：请求离开（RTD）消息定义
Message Name : Request_to_Depart (RTD) Dissection : {HDR-GrpID, GC/KS_ID, [Nonce_I], Notif_Leave_Group, [VendorID]} SigM, [Cert] Payload Types : GSAKMP Header, Identification, [Nonce], Notification, [Vendor ID], Signature, [Certificate]
消息名称：请求离开（RTD）解析：{HDR GrpID，GC/KS_ID，[Nonce_I]，Notif_离开组，[VendorID]}SigM，[Cert]有效负载类型：GSAKMP头，标识，[Nonce]，通知，[VENDER ID]，签名，[Certificate]
SigM : Signature of Group Member
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
SigM : Signature of Group Member
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
Upon receipt of the RTD message, the GC/KS MUST verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, then the identifier value in Identification payload is compared to its own, the GC/KS's identity, to confirm that the GM intended to converse with this GC/KS, the GC/KS who registered this member into the group. Then the identity of the sender is extracted from the Signature payload. This identity MUST be used to confirm that this GM is a member of the group serviced by this GC/KS. Then the GC/KS will confirm from the Notification payload that the GM is requesting to leave the group. Then the GC/KS will verify the signature on the message to ensure its authenticity. The GC/KS MUST use verified and trusted authentication material from a known root. If all checks pass and the message is successfully processed, then the GC/KS MUST form a Departure_Response message as defined in Section 5.3.2.3.2.
收到RTD消息后，GC/KS必须验证消息头的格式是否正确，并通过检查GroupID的值确认此消息适用于此组。如果报头检查通过，则将标识有效负载中的标识符值与其自身的GC/KS标识进行比较，以确认GM打算与该GC/KS（将该成员注册到组中的GC/KS）对话。然后从签名有效载荷中提取发送者的身份。此标识必须用于确认此GM是此GC/KS服务的组的成员。然后，GC/KS将从通知有效负载中确认GM正在请求离开该组。然后GC/KS将验证消息上的签名以确保其真实性。GC/KS必须使用来自已知根目录的已验证和受信任的身份验证材料。如果所有检查均通过且消息已成功处理，则GC/KS必须形成第5.3.2.3.2节中定义的离开响应消息。
If the processing of the message fails, the de-registration session MUST be terminated, and all state associated with this session is removed. If the GC/KS is operating in Terse Mode, then no error message is sent to the GM. If the GC/KS is operating in Verbose Mode, then the GC/KS sends a Departure_Response Message with a Notification Payload of type Request_to_Depart_Error.
如果消息处理失败，则必须终止取消注册会话，并删除与此会话关联的所有状态。如果GC/KS在简洁模式下运行，则不会向GM发送任何错误消息。如果GC/KS在详细模式下运行，则GC/KS会发送一条离开响应消息，其通知负载类型为Request_to_DEVICE_error。
The Exchange Type for a Departure_Response Message is fourteen (14). The components of a Departure_Response Message are shown in Table 9.
离港应答报文的交换类型为十四（14）。表9显示了离港响应信息的组成部分。
In response to a properly formed and verified RTD message, the GC/KS MUST create and send the DR message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: GM identification, Notification for acceptance of departure, and signature information. If synchronization time is not available, the Nonce payloads MUST be included in the message for freshness.
为响应格式正确且经过验证的RTD消息，GC/KS必须创建并发送DR消息。根据报文剖析中的定义，该报文必须包含有效载荷，以保存以下信息：GM标识、离境接受通知和签名信息。如果同步时间不可用，则必须在消息中包含Nonce有效负载以获取新鲜度。
Table 9: Departure_Response (DR) Message Definition
表9：离港应答（DR）报文定义
Message Name : Departure_Response (DR) Dissection : {HDR-GrpID, Member_ID, [Nonce_R, Nonce_C], Notification, [VendorID]} SigC, [Cert] Payload Types : GSAKMP Header, Identification, [Nonce], Notification, [Vendor ID], Signature, [Certificate]
消息名称：出发响应（DR）解析：{HDR GrpID，成员ID，[Nonce\U R，Nonce\U C]，通知，[VendorID]}SigC，[Cert]有效负载类型：GSAKMP头，标识，[Nonce]，通知，[VENDER ID]，签名，[Certificate]
SigC : Signature of Group Member
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
SigC : Signature of Group Member
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
If present, the nonce values transmitted MUST be the GC/KS's generated Nonce_R value and the combined Nonce_C value that was generated by using the GC/KS's Nonce_R value and the Nonce_I value received from the GM in the RTD. This Nonce_C value MUST be saved relative to this departing GM's ID.
如果存在，则传输的nonce值必须是GC/KS生成的nonce\R值以及使用GC/KS的nonce\R值和RTD中从GM接收的nonce\u I值生成的组合nonce\R值。必须相对于该离开GM的ID保存此Nonce_C值。
The GM MUST be able to process the Departure_Response message. The following checks SHOULD be performed in the order presented.
总经理必须能够处理离开响应信息。应按照提供的顺序执行以下检查。
The GM MUST verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GM MUST confirm that this message was intended for itself by comparing the Member ID in the Identification payload to its identity. After identification confirmation, the freshness values are checked. If using nonces, the GM MUST use its saved Nonce_I value, extract the received GC/KS Nonce_R value, compute the combined Nonce_C value, and compare it for equality with the received Nonce_C value. If not using nonces, the GM MUST check the timestamp in the signature payload to determine if the message is new. After freshness is confirmed, confirmation of the identity of the signer of the DR message is the GMs authorized
GM必须验证消息头的格式是否正确，并通过检查GroupID的值确认此消息适用于此组。如果报头检查通过，GM必须通过将识别有效载荷中的成员ID与其身份进行比较来确认该消息是针对其自身的。确认标识后，检查新鲜度值。如果使用Nonce，GM必须使用其保存的Nonce_I值，提取接收的GC/KS Nonce_R值，计算组合的Nonce_C值，并将其与接收的Nonce_C值进行相等比较。如果不使用nonce，GM必须检查签名有效负载中的时间戳，以确定消息是否为新消息。在确认新鲜度后，由GMs授权确认DR消息签名者的身份
GC/KS is performed. Then, the signature MUST be verified to ensure its authenticity. The GM MUST use verified and trusted authentication material from a known root. If the message signature verifies, then the GM MUST verify that the Notification is of Type Departure_Accepted or Request_to_Depart_Error.
执行GC/KS。然后，必须验证签名以确保其真实性。GM必须使用来自已知根目录的经验证和受信任的认证材料。如果消息签名验证，则GM必须验证通知类型是否为“已接受离开”或“请求离开”错误。
If the processing is successful, and the Notification payload is of type Departure_Accepted, the member MUST form the Departure_ACK message as defined in Section 5.3.2.3.3. If the processing is successful, and the Notification payload is of type Request_to_Depart_Error, the member MUST remove all state associated with the de-registration session. If the member still desires to De-Register from the group, the member MUST restart the de-registration process.
如果处理成功，且通知有效载荷类型为“已接受离开”，则成员必须形成第5.3.2.3.3节中定义的离开确认消息。如果处理成功，且通知有效负载的类型为Request_to_Deeption_Error，则成员必须删除与取消注册会话关联的所有状态。如果该成员仍希望从组中注销，则该成员必须重新启动注销过程。
If the processing of the message fails, the de-registration session MUST be terminated, and all state associated with this session is removed. If the GM is operating in Terse Mode, then a Departure_Ack Message with Notification Payload of type NACK is sent to the GC/KS. If the GM is operating in Verbose Mode, then the GM sends a Departure_Ack Message with a Notification Payload of the appropriate failure type.
如果消息处理失败，则必须终止取消注册会话，并删除与此会话关联的所有状态。如果GM在简洁模式下运行，则向GC/KS发送带有NACK类型通知有效载荷的离开确认消息。如果GM在详细模式下运行，则GM发送一条带有适当故障类型的通知有效载荷的离开确认消息。
The Exchange Type for a Departure_ACK Message is fifteen (15). The components of the Departure_ACK Message are shown in Table 10:
出发确认信息的交换类型为十五（15）。出发确认信息的组成如表10所示：
Table 10: Departure_ACK (DA) Message Definition
表10：出发确认（DA）报文定义
Message Name : Departure_ACK (DA)
Dissection : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM
Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor
ID], Signature
SigM : Signature of Group Member
{}SigX : Indicates fields used in Signature
Message Name : Departure_ACK (DA)
Dissection : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM
Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor
ID], Signature
SigM : Signature of Group Member
{}SigX : Indicates fields used in Signature
In response to a properly processed Departure_Response message, the GM MUST create and send the Departure_ACK message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: Notification payload of type Acknowledgement (ACK) and signature information. If synchronization time is not available, the Nonce payload MUST be present for freshness, and the nonce value transmitted MUST be the GM's generated Nonce_C value.
为响应正确处理的离港确认信息，总经理必须创建并发送离港确认信息。如消息剖析中所定义的，此消息必须包含有效负载以保存以下信息：确认类型的通知有效负载（ACK）和签名信息。如果同步时间不可用，则必须存在Nonce有效负载以保持新鲜度，并且传输的Nonce值必须是GM生成的Nonce_C值。
Upon receipt of the Departure_ACK, the GC/KS MUST perform the following checks. These checks SHOULD be performed in the order presented.
收到离境确认后，GC/KS必须进行以下检查。这些检查应按照提供的顺序进行。
In this procedure, the GC/KS MUST verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GC/KS MUST check the message for freshness. If using nonces, the GC/KS MUST use its saved Nonce_C value and compare it to the received Nonce_C value. If not using nonces, the GC/KS MUST check the timestamp in the signature payload to determine if the message is new. After freshness is confirmed, the signature MUST be verified to ensure its authenticity. The GC/KS MUST use verified and trusted authentication material from a known root. If the message signature verifies, the GC/KS processes the Notification payload. If the notification type is of type ACK, this is considered a successful processing of this message.
在此过程中，GC/KS必须验证消息头的格式是否正确，并通过检查GroupID的值来确认此消息适用于此组。如果标头检查通过，GC/KS必须检查消息的新鲜度。如果使用Nonce，GC/KS必须使用其保存的Nonce_C值，并将其与接收到的Nonce_C值进行比较。如果不使用nonce，GC/KS必须检查签名有效负载中的时间戳，以确定消息是否为新消息。在确认新鲜度后，必须验证签名以确保其真实性。GC/KS必须使用来自已知根目录的已验证和受信任的身份验证材料。如果消息签名得到验证，GC/KS将处理通知有效负载。如果通知类型为ACK类型，则认为此消息处理成功。
If the processing of the message is successful, the GC/KS MUST remove the member from the group. This MAY involve initiating a Rekey Event for the group.
如果消息处理成功，GC/KS必须从组中删除该成员。这可能涉及启动组的重新密钥事件。
If the processing of the message fails or if no Departure_Ack is received, the GC/KS MAY issue a LOA message.
如果消息处理失败或未收到离开确认，GC/KS可发出LOA消息。
The Security Definition Suite 1 MUST be supported. Other security suite definitions MAY be defined in other Internet specifications.
必须支持安全定义套件1。其他安全套件定义可在其他Internet规范中定义。
All potential GMs will have enough information available to them to use the correct Security Suite to join the group. This can be accomplished by a well-known default suite, 'Security Suite 1', or by announcing/posting another suite.
所有潜在的GMs都将拥有足够的可用信息，以使用正确的安全套件加入该组。这可以通过一个众所周知的默认套件“安全套件1”或通过宣布/发布另一个套件来实现。
GSAKMP implementations MUST support the following suite of algorithms and configurations. The following definition of Suite 1 borrows heavily from IKE's Oakley group 2 definition and Oakley itself.
GSAKMP实现必须支持以下一套算法和配置。以下对套件1的定义大量借鉴了IKE的Oakley group 2定义和Oakley本身。
The GSAKMP Suite 1 definition gives all the algorithm and cryptographic definitions required to process group establishment messages. It is important to note that GSAKMP does not negotiate
GSAKMP套件1定义提供了处理组建立消息所需的所有算法和加密定义。值得注意的是，GSAKMP不进行谈判
these cryptographic mechanisms. This definition is set by the Group Owner via the Policy Token (passed during the GSAKMP exchange for member verification purposes).
这些加密机制。此定义由组所有者通过策略令牌设置（在GSAKMP交换期间传递，用于成员验证）。
The GSAKMP Suite 1 definition is:
GSAKMP套件1的定义是：
Key download and Policy Token encryption algorithm definition: Algorithm: AES Mode: CBC Key Length: 128 bits
密钥下载和策略令牌加密算法定义：算法：AES模式：CBC密钥长度：128位
Policy Token digital signature algorithm is: DSS-ASN1-DER Hash algorithm is: SHA-1
策略令牌数字签名算法为：DSS-ASN1-DER哈希算法为：SHA-1
Nonce Hash algorithm is: SHA-1
Nonce散列算法是：SHA-1
The Key Creation definition is: Algorithm type is Diffie Hellman MODP group definition g: 2 p: "FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1" "29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD" "EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245" "E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED" "EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381" "FFFFFFFF FFFFFFFF"
关键创建定义为：算法类型为Diffie Hellman MODP组定义g:2 p:“FFFFFFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1”“29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD”“EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245”“E485B57625E7EC6 F442E9 A637ED6 0BFF56CB067ED”“EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381”“FFFFFFFFFF”
NOTE: The p and g values come from IKE [RFC2409], Section 6.2, "Second Oakley Group", and p is 1024 bits long.
注：p和g值来自IKE[RFC2409]，第6.2节，“第二个Oakley组”，p为1024位长。
The GSAKMP message digital signature algorithm is: DSS-SHA1-ASN1-DER
GSAKMP消息数字签名算法为：DSS-SHA1-ASN1-DER
The digital signature ID type is: ID-DN-STRING
数字签名ID类型为：ID-DN-STRING
A GSAKMP Message is composed of a GSAKMP Header (Section 7.1) followed by at least one GSAKMP Payload. All GSAKMP Payloads are composed of the Generic Payload Header (Section 7.2) followed by the specific payload data. The message is chained by a preceding payload defining its succeeding payload. Payloads are not required to be in the exact order shown in the message dissection in Section 5, provided that all required payloads are present. Unless it is explicitly stated in a dissection that multiple payloads of a single type may be present, no more than one payload of each type allowed by the message may appear. The final payload in a message will point to no succeeding payload.
GSAKMP消息由GSAKMP头（第7.1节）和至少一个GSAKMP有效负载组成。所有GSAKMP有效载荷由通用有效载荷标题（第7.2节）和特定有效载荷数据组成。消息由定义其后续有效负载的前一有效负载链接。如果存在所有要求的有效载荷，则不要求有效载荷按照第5节消息分解中所示的准确顺序。除非在剖析中明确说明可能存在单一类型的多个有效载荷，否则消息允许的每种类型的有效载荷不得超过一个。消息中的最终有效负载将指向无后续有效负载。
All fields of type integer in the Header and Payload structure that are larger than one octet MUST be converted into Network Byte Order prior to data transmission.
在数据传输之前，必须将报头和有效负载结构中大于一个八位字节的整数类型的所有字段转换为网络字节顺序。
Padding of fields MUST NOT be done as this leads to processing errors.
不得填充字段，因为这会导致处理错误。
When a message contains a Vendor ID payload, the processing of the payloads of that message is modified as defined in Section 7.10.
当消息包含供应商ID有效载荷时，该消息的有效载荷处理将按照第7.10节中的定义进行修改。
The GSAKMP Header fields are shown in Figure 3 and defined as:
GSAKMP头字段如图3所示，定义如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! GroupID Type ! GroupID Length! Group ID Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Next Payload ! Version ! Exchange Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sequence ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! GroupID Type ! GroupID Length! Group ID Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Next Payload ! Version ! Exchange Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sequence ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: GSAKMP Header Format
图3:GSAKMP头格式
Group Identification Type (1 octet) - Table 11 presents the group identification types. This field is treated as an unsigned value.
组标识类型（1个八位字节）-表11给出了组标识类型。此字段被视为无符号值。
Table 11: Group Identification Types
表11：组标识类型
Grp ID Type Value Description
_____________________________________________________________________
Grp ID Type Value Description
_____________________________________________________________________
Reserved 0 UTF-8 1 Format defined in Section 7.1.1.1.1. Octet String 2 This type MUST be implemented. Format defined in Section 7.1.1.1.2. IPv4 3 Format defined in Section 7.1.1.1.3. IPv6 4 Format defined in Section 7.1.1.1.4. Reserved to IANA 5 - 192 Private Use 193 - 255
第7.1.1.1.1节中定义的保留0 UTF-8 1格式。必须实现此类型的八位字节字符串2。第7.1.1.1.2节中定义的格式。第7.1.1.1.3节中定义的IPv4 3格式。第7.1.1.1.4节中定义的IPv6 4格式。保留给IANA 5-192私人使用193-255
Group Identification Length (1 octet) - Length of the Group Identification Value field in octets. This value MUST NOT be zero (0). This field is treated as an unsigned value.
组标识长度（1个八位字节）-组标识值字段的长度（以八位字节为单位）。此值不能为零（0）。此字段被视为无符号值。
Group Identification Value (variable length) - Indicates the name/title of the group. All GroupID types should provide unique naming across groups. GroupID types SHOULD provide this capability by including a random element generated by the creator (owner) of the group of at least eight (8) octets, providing extremely low probability of collision in group names. The GroupID value is static throughout the life of the group.
组标识值（可变长度）-表示组的名称/标题。所有GroupID类型都应跨组提供唯一的命名。GroupID类型应通过包含由至少八（8）个八位字节组成的组的创建者（所有者）生成的随机元素来提供此功能，从而在组名中提供极低的冲突概率。GroupID值在组的整个生命周期内是静态的。
Next Payload (1 octet) - Indicates the type of the next payload in the message. The format for each payload is defined in the following sections. Table 12 presents the payload types. This field is treated as an unsigned value.
下一个有效负载（1个八位字节）-指示消息中下一个有效负载的类型。每个有效负载的格式在以下部分中定义。表12给出了有效载荷类型。此字段被视为无符号值。
Table 12: Payload Types
表12：有效载荷类型
Next_Payload_Type Value
___________________________________
Next_Payload_Type Value
___________________________________
None 0 Policy Token 1 Key Download Packet 2 Rekey Event 3 Identification 4 Reserved 5 Certificate 6 Reserved 7 Signature 8 Notification 9 Vendor ID 10 Key Creation 11 Nonce 12 Reserved to IANA 13 - 192 Private Use 193 - 255
无0策略令牌1密钥下载数据包2重新密钥事件3标识4保留5证书6保留7签名8通知9供应商ID 10密钥创建11临时12保留给IANA 13-192专用193-255
Version (1 octet) - Indicates the version of the GSAKMP protocol in use. The current value is one (1). This field is treated as an unsigned value.
版本（1个八位字节）-表示正在使用的GSAKMP协议的版本。当前值为一（1）。此字段被视为无符号值。
Exchange Type (1 octet) - Indicates the type of exchange (also known as the message type). Table 13 presents the exchange type values. This field is treated as an unsigned value.
交换类型（1个八位字节）-表示交换的类型（也称为消息类型）。表13给出了交换类型值。此字段被视为无符号值。
Table 13: Exchange Types
表13：交易所类型
Exchange_Type Value
________________________________________
Exchange_Type Value
________________________________________
Reserved 0 - 3 Key Download Ack/Failure 4 Rekey Event 5 Reserved 6 - 7 Request to Join 8 Key Download 9 Cookie Download 10 Request to Join Error 11 Lack of Ack 12 Request to Depart 13 Departure Response 14 Departure Ack 15 Reserved to IANA 16 - 192 Private Use 193 - 255
保留0-3密钥下载确认/失败4重新密钥事件5保留6-7加入请求8密钥下载9 Cookie下载10加入请求错误11缺少确认12请求离开13离开响应14离开确认15保留给IANA 16-192私人使用193-255
Sequence ID (4 octets) - The Sequence ID is used for replay protection of group management messages. If the message is not a group management message, this value MUST be set to zero (0). The first value used by a (S-)GC/KS MUST be one (1). For each distinct group management message that this (S-)GC/KS transmits, this value MUST be incremented by one (1). Receivers of this group management message MUST confirm that the value received is greater than the value of the sequence ID received with the last group management message from this (S-)GC/KS. Group Components (e.g., GMs, S-GC/KSes) MUST terminate processing upon receipt of an authenticated group management message containing a Sequence ID of 0xFFFFFFFF. This field is treated as an unsigned integer in network byte order.
序列ID（4个八位字节）-序列ID用于组管理消息的重播保护。如果消息不是组管理消息，则此值必须设置为零（0）。（S-）GC/KS使用的第一个值必须是一（1）。对于此（S-）GC/KS传输的每个不同的组管理消息，此值必须增加一（1）。此组管理消息的接收者必须确认接收到的值大于使用来自此（S-）GC/KS的最后一条组管理消息接收到的序列ID的值。组组件（例如，GMs、S-GC/KSE）必须在收到包含序列ID 0xFFFF的经过身份验证的组管理消息后终止处理。此字段按网络字节顺序视为无符号整数。
Length (4 octets) - Length of total message (header + payloads) in octets. This field is treated as an unsigned integer in network byte order.
长度（4个八位字节）-以八位字节为单位的总消息长度（报头+有效负载）。此字段按网络字节顺序视为无符号整数。
This section defines the formats for the defined GroupID types.
本节定义定义的GroupID类型的格式。
The format for type UTF-8 [RFC3629] is shown in Figure 4.
UTF-8型[RFC3629]的格式如图4所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Random Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! UTF-8 String ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Random Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! UTF-8 String ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: GroupID UTF-8 Format
图4:GroupID UTF-8格式
Random Value (16 octets) - For the UTF-8 GroupID type, the Random Value is represented as a string of exactly 16 hexadecimal digits converted from its octet values in network-byte order. The leading zero hexadecimal digits and the trailing zero hexadecimal digits are always included in the string, rather than being truncated.
随机值（16个八位字节）-对于UTF-8 GroupID类型，随机值表示为一个由16位十六进制数字组成的字符串，这些数字按网络字节顺序从八位字节值转换而来。字符串中始终包含前导零位十六进制数字和尾随零位十六进制数字，而不是截断。
UTF-8 String (variable length) - This field contains the human readable portion of the GroupID in UTF-8 format. Its length is calculated as the (GroupID Length - 16) for the Random Value field. The minimum length for this field is one (1) octet.
UTF-8字符串（可变长度）-此字段包含UTF-8格式的GroupID的可读部分。其长度计算为随机值字段的（GroupID长度-16）。此字段的最小长度为一（1）个八位字节。
The format for type Octet String is shown in Figure 5.
类型八位字符串的格式如图5所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Random Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Octet String ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Random Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Octet String ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: GroupID Octet String Format
图5:GroupID八位字节字符串格式
Random Value (8 octets) - The 8-octet unsigned random value in network byte order format.
随机值（8个八位字节）-网络字节顺序格式的8个八位无符号随机值。
Octet String (variable length) - This field contains the Octet String portion of the GroupID. Its length is calculated as the (GroupID Length - 8) for the Random Value field. The minimum length for this field is one (1) octet.
八位字节字符串（可变长度）-此字段包含GroupID的八位字节字符串部分。其长度计算为随机值字段的（GroupID长度-8）。此字段的最小长度为一（1）个八位字节。
The format for type IPv4 Group Identifier is shown in Figure 6.
IPv4组标识符类型的格式如图6所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Random Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IPv4 Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Random Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IPv4 Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: GroupID IPv4 Format
图6:GroupID IPv4格式
Random Value (8 octets) - The 8-octet unsigned random value in network byte order format.
随机值（8个八位字节）-网络字节顺序格式的8个八位无符号随机值。
IPv4 Value (4 octets) - The IPv4 value in network byte order format. This value MAY contain the multicast address of the group.
IPv4值（4个八位字节）-网络字节顺序格式的IPv4值。此值可能包含组的多播地址。
The format for type IPv6 Group Identifier is shown in Figure 7.
IPv6组标识符类型的格式如图7所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Random Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IPv6 Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Random Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IPv6 Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: GroupID IPv6 Format
图7:GroupID IPv6格式
Random Value (8 octets) - The 8-octet unsigned random value in network byte order format.
随机值（8个八位字节）-网络字节顺序格式的8个八位无符号随机值。
IPv6 Value (16 octets) - The IPv6 value in network byte order format. This value MAY contain the multicast address of the group.
IPv6值（16个八位字节）-网络字节顺序格式的IPv6值。此值可能包含组的多播地址。
When processing the GSAKMP Header, the following fields MUST be checked for correct values:
处理GSAKMP标头时，必须检查以下字段的值是否正确：
1. Group ID Type - The Group ID Type value MUST be checked to be a valid group identification payload type as defined by Table 11. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
1. 组ID类型-必须检查组ID类型值是否为表11定义的有效组标识有效负载类型。如果该值无效，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
2. GroupID - The GroupID of the received message MUST be checked against the valid GroupIDs of the Group Component. If no match is found, then an error is logged; in addition, if in Verbose Mode, an appropriate message containing notification value Invalid-Group-ID will be sent.
2. GroupID-必须对照组组件的有效GroupID检查所接收消息的GroupID。如果未找到匹配项，则记录错误；此外，如果处于详细模式，将发送一条包含通知值Invalid Group ID的适当消息。
3. Next Payload - The Next Payload value MUST be checked to be a valid payload type as defined by Table 12. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Payload-Type will be sent.
3. 下一个有效负载-必须检查下一个有效负载值是否为表12定义的有效负载类型。如果该值无效，则会记录错误。如果处于详细模式，将发送包含通知值无效有效负载类型的适当消息。
4. Version - The GSAKMP version number MUST be checked that its value is one (1). For other values, see below for processing. The GSAKMP version number MUST be checked that it is consistent with the group's policy as specified in its Policy Token. If the version is not supported or authorized, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Version will be sent.
4. 版本-必须检查GSAKMP版本号的值是否为一（1）。有关其他值，请参见下面的处理。必须检查GSAKMP版本号是否与其策略令牌中指定的组策略一致。如果不支持或授权该版本，则会记录错误。如果处于详细模式，将发送包含通知值Invalid Version的适当消息。
5. Exchange Type - The Exchange Type MUST be checked to be a valid exchange type as defined by Table 13 and MUST be of the type expected to be received by the GSAKMP state machine. If the exchange type is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Exchange-Type will be sent.
5. 交换类型-交换类型必须被检查为表13定义的有效交换类型，并且必须是GSAKMP状态机预期接收的类型。如果交换类型无效，则会记录错误。如果处于详细模式，将发送一条包含通知值Invalid Exchange Type的适当消息。
6. Sequence ID - The Sequence ID value MUST be checked for correctness. For negotiation messages, this value MUST be zero (0). For group management messages, this value MUST be greater than the last sequence ID received from this (S-)GC/KS. Receipt of incorrect Sequence ID on group management messages MUST NOT cause a reply message to be generated. Upon receipt of incorrect Sequence ID on non-group management messages, an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Sequence-ID will be sent.
6. 序列ID-必须检查序列ID值的正确性。对于协商消息，此值必须为零（0）。对于组管理消息，此值必须大于从该（S-）GC/KS接收的最后一个序列ID。必须在收到不正确的消息序列管理消息时生成不正确的消息ID组。在非组管理消息上收到错误的序列ID后，将记录错误。如果处于详细模式，将发送包含通知值Invalid Sequence ID的适当消息。
The length fields in the GSAKMP Header (Group ID Length and Length) are used to help process the message. If any field is found to be incorrect, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
GSAKMP头中的长度字段（组ID长度和长度）用于帮助处理消息。如果发现任何字段不正确，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
In order to allow a GSAKMP version one (v1) implementation to interoperate with future versions of the protocol, some ideas will be discussed here to this effect.
为了允许GSAKMP版本1（v1）实现与协议的未来版本进行互操作，这里将讨论一些实现这一点的想法。
A (S-)GC/KS that is operating in a multi-versioned group as defined by the Policy Token can take many approaches on how to interact with the GMs in this group for a rekey message.
在策略令牌定义的多版本组中运行的（S-）GC/KS可以采取多种方法来与该组中的GMs进行交互以获得密钥更新消息。
One possible solution is for the (S-)GC/KS to send out multiple rekey messages, one per version level that it supports. Then each GM would only process the message that has the version at which it is operating.
每个版本支持多条消息，每个版本支持多条消息。然后，每个GM只处理包含其运行版本的消息。
An alternative approach that all GM v1 implementations MUST support is the embedding of a v1 message inside a version two (v2) message. If a GM running at v1 receives a GSAKMP message that has a version value greater than one (1), the GM will attempt to process the information immediately after the Group Header as a Group Header for v1 of the protocol. If this is in fact a v1 Group Header, then the remainder of this v1 message will be processed in place. After processing this v1 embedded message, the data following the v1 message should be the payload as identified by the Next Payload field in the original header of the message and will be ignored by the v1 member. However, if the payload following the initial header is not a v1 Group Header, then the GM will gracefully handle the unrecognized message.
所有GM v1实现都必须支持的另一种方法是在版本2（v2）消息中嵌入v1消息。如果在v1运行的GM接收到版本值大于一（1）的GSAKMP消息，则GM将尝试在组头之后立即将该信息作为协议v1的组头进行处理。如果这实际上是一个v1组头，那么该v1消息的其余部分将就地处理。处理此v1嵌入消息后，v1消息后面的数据应为消息原始标头中下一个有效负载字段标识的有效负载，v1成员将忽略该数据。但是，如果初始报头后面的有效负载不是v1组报头，则GM将优雅地处理未识别的消息。
Each GSAKMP payload defined in the following sections begins with a generic header, shown in Figure 8, that provides a payload "chaining" capability and clearly defines the boundaries of a payload. The Generic Payload Header fields are defined as follows:
以下各节中定义的每个GSAKMP有效负载都以一个通用头开始，如图8所示，该头提供了有效负载“链接”功能，并明确定义了有效负载的边界。通用有效负载标头字段定义如下：
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Generic Payload Header
图8：通用有效负载头
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 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段提供“链接”功能。表12确定了有效载荷类型。此字段被视为无符号值。
RESERVED (1 octet) - Unused, set to 0.
保留（1个八位组）-未使用，设置为0。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。此字段被视为网络字节顺序格式的无符号整数。
When processing the Generic Payload Header, the following fields MUST be checked for correct values:
处理通用有效负载标头时，必须检查以下字段的值是否正确：
1. Next Payload - The Next Payload value MUST be checked to be a valid payload type as defined by Table 12. If the payload type is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Payload-Type will be sent.
1. 下一个有效负载-必须检查下一个有效负载值是否为表12定义的有效负载类型。如果有效负载类型无效，则会记录错误。如果处于详细模式，将发送包含通知值无效有效负载类型的适当消息。
2. RESERVED - This field MUST contain the value zero (0). If the value of this field is not zero (0), then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. 保留-此字段必须包含值零（0）。如果此字段的值不是零（0），则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
The length field in the Generic Payload Header is used to process the remainder of the payload. If this field is found to be incorrect, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
通用有效负载标头中的长度字段用于处理剩余的有效负载。如果发现此字段不正确，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
The Policy Token Payload contains authenticatable group-specific information that describes the group security-relevant behaviors, access control parameters, and security mechanisms. Figure 9 shows the format of the payload.
策略令牌负载包含可验证的组特定信息，这些信息描述了与组安全相关的行为、访问控制参数和安全机制。图9显示了有效负载的格式。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy Token Type ! Policy Token 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy Token Type ! Policy Token Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Policy Token Payload Format
图9：策略令牌有效负载格式
The Policy Token Payload fields are defined as follows:
策略令牌有效负载字段定义如下：
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 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段提供“链接”功能。表12确定了有效载荷类型。此字段被视为无符号值。
RESERVED (1 octet) - Unused, set to 0.
保留（1个八位组）-未使用，设置为0。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。此字段被视为网络字节顺序格式的无符号整数。
Policy Token Type (2 octets) - Specifies the type of Policy Token being used. Table 14 identifies the types of policy tokens. This field is treated as an unsigned integer in network byte order format.
策略令牌类型（2个八位字节）-指定正在使用的策略令牌的类型。表14确定了策略令牌的类型。此字段被视为网络字节顺序格式的无符号整数。
Table 14: Policy Token Types
表14：策略令牌类型
Policy_Token_Type Value Definition/Defined In
____________________________________________________________________
Policy_Token_Type Value Definition/Defined In
____________________________________________________________________
Reserved 0 GSAKMP_ASN.1_PT_V1 1 All implementations of GSAKMP MUST support this PT format. Format specified in [RFC4534]. Reserved to IANA 2 - 49152 Private Use 49153 - 65535
保留0 GSAKMP_ASN.1_PT_V1 1所有GSAKMP实现必须支持此PT格式。[RFC4534]中指定的格式。保留给IANA 2-49152私人使用49153-65535
Policy Token Data (variable length) - Contains Policy Token information. The values for this field are token specific, and the format is specified by the PT Type field.
策略令牌数据（可变长度）-包含策略令牌信息。此字段的值特定于令牌，格式由PT Type字段指定。
If this payload is encrypted, only the Policy Token Data field is encrypted.
如果此有效负载已加密，则仅加密策略令牌数据字段。
The payload type for the Policy Token Payload is one (1).
策略令牌有效负载的有效负载类型为一（1）。
When processing the Policy Token Payload, the following fields MUST be checked for correct values:
处理策略令牌负载时，必须检查以下字段的值是否正确：
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 下一有效载荷、保留有效载荷、有效载荷长度-这些字段按照第7.2.2节“通用有效载荷标头处理”中的定义进行处理。
2. Policy Token Type - The Policy Token Type value MUST be checked to be a valid policy token type as defined by Table 14. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. 策略令牌类型-必须检查策略令牌类型值是否为表14定义的有效策略令牌类型。如果该值无效，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
3. Policy Token Data - This Policy Token Data MUST be processed according to the Policy Token Type specified. The type will define the format of the data.
3. 策略令牌数据-必须根据指定的策略令牌类型处理此策略令牌数据。该类型将定义数据的格式。
Refer to the terminology section for the different terms relating to keys used within this section.
有关本节中使用的钥匙的不同术语，请参阅术语部分。
The Key Download Payload contains group keys (e.g., group keys, initial rekey keys, etc.). These key download payloads can have several security attributes applied to them based upon the security policy of the group. Figure 10 shows the format of the payload.
密钥下载有效负载包含组密钥（例如，组密钥、初始重密钥等）。根据组的安全策略，这些密钥下载有效负载可以应用多个安全属性。图10显示了有效负载的格式。
The security policy of the group dictates that the key download payload MUST be encrypted with a key encryption key (KEK). The encryption mechanism used is specified in the Policy Token. The group members MUST create the KEK using the key creation method identified in the Key Creation Payload.
组的安全策略规定密钥下载有效负载必须使用密钥加密密钥（KEK）进行加密。使用的加密机制在策略令牌中指定。组成员必须使用密钥创建负载中标识的密钥创建方法创建KEK。
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 Items ! Key Download Data Items ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Items ! Key Download Data Items ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Key Download Payload Format
图10：密钥下载有效负载格式
The Key Download Payload fields are defined as follows:
密钥下载有效负载字段定义如下：
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 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段提供“链接”功能。表12确定了有效载荷类型。此字段被视为无符号值。
RESERVED (1 octet) - Unused, set to 0.
保留（1个八位组）-未使用，设置为0。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。此字段被视为网络字节顺序格式的无符号整数。
Number of Items (2 octets) - Contains the total number of group traffic protection keys and Rekey Arrays being passed in this data block. This field is treated as an unsigned integer in network byte order format.
项数（2个八位字节）-包含在此数据块中传递的组流量保护密钥和重密钥数组的总数。此字段被视为网络字节顺序格式的无符号整数。
Key Download Data Items (variable length) - Contains Key Download information. The Key Download Data is a sequence of Type/Length/Data of the Number of Items. The format for each item is defined in Figure 11.
密钥下载数据项（可变长度）-包含密钥下载信息。关键下载数据是项目数量的类型/长度/数据序列。每个项目的格式如图11所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KDD Item Type ! Key Download Data Item Length! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Data for Key Download Data Item (Key Datum/Rekey Array) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KDD Item Type ! Key Download Data Item Length! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Data for Key Download Data Item (Key Datum/Rekey Array) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Key Download Data Item Format
图11：关键下载数据项格式
For each Key Download Data Item, the data format is as follows:
对于每个关键下载数据项，数据格式如下：
Key Download Data (KDD) Item Type (1 octet) - Identifier for the type of data contained in this Key Download Data Item. See Table 15 for the possible values of this field. This field is treated as an unsigned value.
密钥下载数据（KDD）项类型（1个八位字节）-此密钥下载数据项中包含的数据类型的标识符。该字段的可能值见表15。此字段被视为无符号值。
Key Download Data Item Length (2 octets) - Length in octets of the Data for the Key Download Data Item following this field. This field is treated as an unsigned integer in network byte order format.
密钥下载数据项长度（2个八位字节）-此字段后面的密钥下载数据项的数据长度（以八位字节为单位）。此字段被视为网络字节顺序格式的无符号整数。
Data for Key Download Data Item (variable length) - Contains Keys and related information. The format of this field is specific depending on the value of the Key Download Data Item Type field. For KDD Item Type of GTPK, this field will contain a Key Datum as defined in Section 7.4.1.1. For KDD Item Type Rekey - LKH, this field will contain a Rekey Array as defined in Section 7.4.1.2.
密钥下载数据项的数据（可变长度）-包含密钥和相关信息。此字段的格式取决于密钥下载数据项类型字段的值。对于GTPK的KDD项目类型，该字段将包含第7.4.1.1节中定义的关键数据。对于KDD项目类型Rekey-LKH，该字段将包含第7.4.1.2节中定义的Rekey数组。
Table 15: Key Download Data Item Types
表15：关键下载数据项类型
Key Download Data Value Definition
Item Type
_________________________________________________________________
Key Download Data Value Definition
Item Type
_________________________________________________________________
GTPK 0 This type MUST be implemented. This type identifies that the data contains group traffic protection key information. Rekey - LKH 1 Optional Reserved to IANA 2 - 192 Private Use 193 - 255
GTPK 0必须实现此类型。此类型标识数据包含组流量保护密钥信息。重新密钥-LKH 1可选保留给IANA 2-192专用193-255
The encryption of this payload only covers the data subsequent to the Generic Payload header (Number of Items and Key Download Data Items fields).
此有效负载的加密仅覆盖通用有效负载头（项目数和密钥下载数据项字段）之后的数据。
The payload type for the Key Download Packet is two (2).
密钥下载包的有效负载类型为2。
A Key Datum contains all the information for a key. Figure 12 shows the format for this structure.
钥匙数据包含钥匙的所有信息。图12显示了此结构的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Type ! Key ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Key Handle ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Key Creation Date ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! Key Expiration Date ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Type ! Key ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Key Handle ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Key Creation Date ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! Key Expiration Date ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Key Datum Format
图12：关键基准格式
Key Type (2 octets) - This is the cryptographic algorithm for which this key data is to be used. This value is specified in the Policy Token. See Table 16 for the possible values of this field. This field is treated as an unsigned value.
密钥类型（2个八位字节）-这是使用此密钥数据的加密算法。此值在策略令牌中指定。有关此字段的可能值，请参见表16。此字段被视为无符号值。
Table 16: Cryptographic Key Types
表16：加密密钥类型
Cryptographic_Key_Types Value Description/Defined In
____________________________________________________________________
Cryptographic_Key_Types Value Description/Defined In
____________________________________________________________________
Reserved 0 - 2 3DES_CBC64_192 3 See [RFC2451]. Reserved 4 - 11 AES_CBC_128 12 This type MUST be supported. See [IKEv2]. AES_CTR 13 See [IKEv2]. Reserved to IANA 14 - 49152 Private Use 49153 - 65535
保留的0-2个数据集\u CBC64\u 192 3请参见[RFC2451]。保留4-11 AES_CBC_128 12必须支持此类型。见[IKEv2]。AES_CTR 13见[IKEv2]。保留给IANA 14-49152私人使用49153-65535
Key ID (4 octets) - This is the permanent ID of all versions of the key. This value MAY be defined by the Policy Token. This field is treated as an octet string.
密钥ID（4个八位字节）-这是所有版本密钥的永久ID。此值可由策略令牌定义。此字段被视为八位字节字符串。
Key Handle (4 octets) - This is the value to uniquely identify a version (particular instance) of a key. This field is treated as an octet string.
密钥句柄（4个八位字节）-这是唯一标识密钥版本（特定实例）的值。此字段被视为八位字节字符串。
Key Creation Date (15 octets) - This is the time value of when this key data was originally generated. This field contains the timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999), MM is the numerical value of the month (01 - 12), DD is the day of the month (01 - 31), HH is the hour of the day (00 - 23), MM is the minute within the hour (00 - 59), SS is the seconds within the minute (00 - 59), and the letter Z indicates that this is Zulu time. This format is loosely based on [RFC3161].
密钥创建日期（15个八位字节）-这是最初生成此密钥数据的时间值。此字段包含UTF-8格式的时间戳YYYYMMDDHMMSSZ，其中YYYY是年（0000-9999），MM是月的数值（01-12），DD是月的日（01-31），HH是一天中的小时（00-23），MM是小时内的分钟（00-59），SS是分钟内的秒（00-59），字母Z表示这是祖鲁时间。此格式大致基于[RFC3161]。
Key Expiration Date (15 octets) - This is the time value of when this key is no longer valid for use. This field contains the timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999), MM is the numerical value of the month (01 - 12), DD is the day of the month (01 - 31), HH is the hour of the day (00 - 23), MM is the minute within the hour (00 - 59), SS is the seconds within the minute (00 - 59), and the letter Z indicates that this is Zulu time. This format is loosely based on [RFC3161].
密钥过期日期（15个八位字节）-这是该密钥不再有效时的时间值。此字段包含UTF-8格式的时间戳YYYYMMDDHMMSSZ，其中YYYY是年（0000-9999），MM是月的数值（01-12），DD是月的日（01-31），HH是一天中的小时（00-23），MM是小时内的分钟（00-59），SS是分钟内的秒（00-59），字母Z表示这是祖鲁时间。此格式大致基于[RFC3161]。
Key Data (variable length) - This is the actual key data, which is dependent on the Key Type algorithm for its format.
密钥数据（可变长度）-这是实际的密钥数据，其格式取决于密钥类型算法。
NOTE: The combination of the Key ID and the Key Handle MUST be unique within the group. This combination will be used to uniquely identify a key.
注意：密钥ID和密钥句柄的组合在组中必须是唯一的。此组合将用于唯一标识密钥。
A Rekey Array contains the information for the set of KEKs that is associated with a Group Member. Figure 13 shows the format for this structure.
重设密钥数组包含与组成员关联的KEK集的信息。图13显示了此结构的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Rekey Version#! Member ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Number of KEK Keys ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Datum(s) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Rekey Version#! Member ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Number of KEK Keys ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Datum(s) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Rekey Array Structure Format
图13：重新设置数组结构格式
Rekey Version (1 octet) - Contains the version of the Rekey protocol in which the data is formatted. For Key Download Data Item Type of Rekey - LKH, refer to Section A.2 for a description of this value. This field is treated as an unsigned value.
密钥更新版本（1个八位字节）-包含格式化数据的密钥更新协议版本。关于Rekey-LKH的密钥下载数据项类型，请参阅第A.2节以了解该值的说明。此字段被视为无符号值。
Member ID (4 octets) - This is the Member ID of the Rekey sequence contained in this Rekey Array. This field is treated as an octet string. For Key Download Data Item Type of Rekey - LKH, refer to Section A.2 for a description of this value.
成员ID（4个八位字节）-这是此重密钥数组中包含的重密钥序列的成员ID。此字段被视为八位字节字符串。关于Rekey-LKH的密钥下载数据项类型，请参阅第A.2节以了解该值的说明。
Number of KEK Keys (2 octets) - This value is the number of distinct KEK keys in this sequence. This value is treated as an unsigned integer in network byte order format.
KEK键的数量（2个八位字节）-此值是此序列中不同KEK键的数量。此值被视为网络字节顺序格式的无符号整数。
Key Datum(s) (variable length) - The sequence of KEKs in Key Datum format. The format for each Key Datum in this sequence is defined in section 7.4.1.1.
关键基准（可变长度）-关键基准格式中的KEK序列。第7.4.1.1节定义了该序列中每个关键基准的格式。
Key ID (for Key ID within the Rekey) - LKH space, refer to Section A.2 for a description of this value.
密钥ID（对于重新密钥内的密钥ID）-LKH空间，有关该值的说明，请参阅第A.2节。
Prior to processing its data, the payload contents MUST be decrypted.
在处理其数据之前，必须对有效负载内容进行解密。
When processing the Key Download Payload, the following fields MUST be checked for correct values:
处理密钥下载有效负载时，必须检查以下字段的值是否正确：
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 下一有效载荷、保留有效载荷、有效载荷长度-这些字段按照第7.2.2节“通用有效载荷标头处理”中的定义进行处理。
2. KDD Item Type - All KDD Item Type fields MUST be checked to be a valid Key Download Data Item type as defined by Table 15. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. KDD项目类型-必须检查所有KDD项目类型字段是否为表15定义的有效密钥下载数据项目类型。如果该值无效，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
3. Key Type - All Key Type fields MUST be checked to be a valid encryption type as defined by Table 16. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Key-Information will be sent.
3. 密钥类型-必须检查所有密钥类型字段是否为表16定义的有效加密类型。如果该值无效，则会记录错误。如果处于详细模式，将发送包含通知值无效密钥信息的适当消息。
4. Key Expiration Date - All Key Expiration Date fields MUST be checked confirm that their values represent a future and not a past time value. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Key-Information will be sent.
4. 密钥过期日期-必须检查所有密钥过期日期字段，以确认其值代表未来而不是过去的时间值。如果该值无效，则会记录错误。如果处于详细模式，将发送包含通知值无效密钥信息的适当消息。
The length and counter fields in the payload are used to help process the payload. If any field is found to be incorrect, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
有效负载中的长度和计数器字段用于帮助处理有效负载。如果发现任何字段不正确，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
Refer to the terminology section for the different terms relating to keys used within this section.
有关本节中使用的钥匙的不同术语，请参阅术语部分。
The Rekey Event Payload MAY contain multiple keys encrypted in Wrapping KEKs. Figure 14 shows the format of the payload. If the data to be contained within a Rekey Event Payload is too large for the payload, the sequence can be split across multiple Rekey Event Payloads at a Rekey Event Data boundary.
重设密钥事件有效负载可能包含在包装KEK中加密的多个密钥。图14显示了有效负载的格式。如果要包含在重新密钥事件有效载荷中的数据对于有效载荷来说太大，则可以在重新密钥事件数据边界处跨多个重新密钥事件有效载荷分割序列。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! RekeyEvnt Type! Rekey Event Header ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Rekey Event Data(s) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! RekeyEvnt Type! Rekey Event Header ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Rekey Event Data(s) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Rekey Event Payload Format
图14：重新设置事件有效负载格式
The Rekey Event Payload fields are defined as follows:
重新设置密钥事件有效负载字段定义如下：
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 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段提供“链接”功能。表12确定了有效载荷类型。此字段被视为无符号值。
RESERVED (1 octet) - Unused, set to 0.
保留（1个八位组）-未使用，设置为0。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。此字段被视为网络字节顺序格式的无符号整数。
Rekey Event Type (1 octet) - Specifies the type of Rekey Event being used. Table 17 presents the types of Rekey events. This field is treated as an unsigned value.
重设密钥事件类型（1个八位字节）-指定正在使用的重设密钥事件的类型。表17显示了重设密钥事件的类型。此字段被视为无符号值。
Rekey Event Header (variable length) - This is the header information for the Rekey Event. The format for this is defined in Section 7.5.1.1, "Rekey Event Header Structure".
重新设置密钥事件标头（可变长度）-这是重新设置密钥事件的标头信息。其格式在第7.5.1.1节“重新设置事件标题结构”中定义。
Rekey Event Data(s) (variable length) - This is the rekey information for the Rekey Event. The format for this is defined in Section 7.5.1.2, "Rekey Event Data Structure".
重置事件数据（可变长度）-这是重置事件的重置信息。第7.5.1.2节“更新事件数据结构”中定义了该格式。
The Rekey Event payload type is three (3).
重设密钥事件有效负载类型为三（3）。
Table 17: Rekey Event Types
表17：重新设置事件类型
Rekey_Event_Type Value Definition/Defined In
_____________________________________________________________________
Rekey_Event_Type Value Definition/Defined In
_____________________________________________________________________
None 0 This type MUST be implemented. In this case, the size of the Rekey Event Data field will be zero bytes long. The purpose of a Rekey Event Payload with type None is when it is necessary to send out a new token with no rekey information. GSAKMP rekey msg requires a Rekey Event Payload, and in this instance it would have rekey data of type None. GSAKMP_LKH 1 The rekey data will be of type LKH formatted according to GSAKMP. The format for this field is defined in Section 7.5.1.2. Reserved to IANA 2 - 192 Private Use 193 - 255
无0必须实现此类型。在这种情况下，重设密钥事件数据字段的大小将为零字节长。类型为None的重设密钥事件有效负载的用途是在需要发送没有重设密钥信息的新令牌时。GSAKMP rekey msg需要一个rekey事件负载，在本例中，它将具有None类型的rekey数据。GSAKMP_LKH 1根据GSAKMP格式化的密钥数据类型为LKH。第7.5.1.2节定义了该字段的格式。保留给IANA 2-192私人使用193-255
The format for the Rekey Event Header is shown in Figure 15.
Rekey事件头的格式如图15所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Group ID Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group ID Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Time/Date Stamp ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! RekeyEnt Type ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Algorithm Ver ! # of Rekey Event Data(s) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Group ID Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group ID Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Time/Date Stamp ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! RekeyEnt Type ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Algorithm Ver ! # of Rekey Event Data(s) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Rekey Event Header Format
图15：重新设置事件头格式
Group Identification Value (variable length) - Indicates the name/title of the group to be rekeyed. This is the same format, length, and value as the Group Identification Value in Section 7.1, "GSAKMP Header".
组标识值（可变长度）-表示要重新键入的组的名称/标题。这与第7.1节“GSAKMP标头”中的组标识值的格式、长度和值相同。
Time/Date Stamp (15 octets) - This is the time value when the Rekey Event Data was generated. This field contains the timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999), MM is the numerical value of the month (01 - 12), DD is the day of the month (01 - 31), HH is the hour of the day (00 - 23), MM is the minute within the hour (00 - 59), SS is the seconds within the minute (00 - 59), and the letter Z indicates that this is Zulu time. This format is loosely based on [RFC3161].
时间/日期戳（15个八位字节）-这是生成密钥更新事件数据时的时间值。此字段包含UTF-8格式的时间戳YYYYMMDDHMMSSZ，其中YYYY是年（0000-9999），MM是月的数值（01-12），DD是月的日（01-31），HH是一天中的小时（00-23），MM是小时内的分钟（00-59），SS是分钟内的秒（00-59），字母Z表示这是祖鲁时间。此格式大致基于[RFC3161]。
Rekey Event Type (1 octet) - This is the Rekey algorithm being used for this group. The values for this field can be found in Table 17. This field is treated as an unsigned value.
重设密钥事件类型（1个八位字节）-这是用于此组的重设密钥算法。该字段的值见表17。此字段被视为无符号值。
Algorithm Version (1 octet) - Indicates the version of the Rekey Type being used. For Rekey Event Type of GSAKMP_LKH, refer to Section A.2 for a description of this value. This field is treated as an unsigned value.
算法版本（1个八位字节）-表示正在使用的密钥更新类型的版本。有关GSAKMP_LKH的重新设定事件类型，请参阅第A.2节了解该值的说明。此字段被视为无符号值。
# of Rekey Event Data(s) (2 octets) - The number of Rekey Event Data(s) contained in the Rekey Data. This value is treated as an unsigned integer in network byte order.
#重设密钥事件数据的数量（2个八位字节）-重设密钥数据中包含的重设密钥事件数据的数量。此值被视为网络字节顺序的无符号整数。
As defined in the Rekey Event Header, # of Rekey Data(s) field, multiple pieces of information are sent in a Rekey Event Data. Each end user, will be interested in only one Rekey Event Data among all of the information sent. Each Rekey Event Data will contain all the Key Packages that a user requires. For each Rekey Event Data, the data following the Wrapping fields is encrypted with the key identified in the Wrapping Header. Figure 16 shows the format of each Rekey Event Data.
如重新设置密钥事件标题“重新设置密钥数据”字段中所定义，在重新设置密钥事件数据中发送多条信息。在发送的所有信息中，每个最终用户只对一个密钥更新事件数据感兴趣。每个重设密钥事件数据将包含用户所需的所有密钥包。对于每个重设密钥事件数据，包装字段后面的数据将使用包装标头中标识的密钥进行加密。图16显示了每个重设密钥事件数据的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Packet Length ! Wrapping KeyID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Wrapping Key Handle ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! # of Key Packages !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Packages(s) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Packet Length ! Wrapping KeyID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Wrapping Key Handle ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! # of Key Packages !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Packages(s) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Rekey Event Data Format
图16：重新设置事件数据格式
Packet Length (2 octets) - Length in octets of the Rekey Event Data, which consists of the # of Key Packages and the Key Packages(s). This value is treated as an unsigned integer in network byte order.
数据包长度（2个八位字节）-密钥事件数据的八位字节长度，包括密钥包和密钥包的长度。此值被视为网络字节顺序的无符号整数。
Wrapping KeyID (4 octets) - This is the Key ID of the KEK that is being used for encryption/decryption of the new (rekeyed) keys. For Rekey Event Type of Rekey - LKH, refer to Section A.2 for a description of this value.
包装密钥ID（4个八位字节）-这是用于加密/解密新（重新设置密钥）密钥的KEK密钥ID。关于Rekey-LKH的Rekey事件类型，有关该值的说明，请参阅第A.2节。
Wrapping Key Handle (4 octets) - This is a Key Handle of the KEK that is being used for encryption/decryption of the new (rekeyed) keys. Refer to Section 7.4.1.1 for the values of this field.
包装密钥句柄（4个八位字节）-这是KEK的密钥句柄，用于加密/解密新（重新设置密钥的）密钥。有关该字段的值，请参阅第7.4.1.1节。
# of Key Packages (2 octets) - The number of key packages contained in this Rekey Event Data. This value is treated as an unsigned integer in network byte order.
#密钥包数（2个八位字节）-此密钥更新事件数据中包含的密钥包数。此值被视为网络字节顺序的无符号整数。
Key Package(s) (variable length) - The type/length/value format of a Key Datum. The format for this is defined in Section 7.5.1.2.1.
密钥包（可变长度）-密钥数据的类型/长度/值格式。第7.5.1.2.1节中定义了该格式。
Each Key Package contains all the information about the key. Figure 17 shows the format for a Key Package.
每个密钥包都包含有关密钥的所有信息。图17显示了密钥包的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KeyPkg Type ! Key Package Length ! Key Datum ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KeyPkg Type ! Key Package Length ! Key Datum ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Key Package Format
图17：关键包格式
Key Package Type (1 octet) - The type of key in this key package. Legal values for this field are defined in Table 15, Key Download Data Types. This field is treated as an unsigned value.
密钥包类型（1个八位字节）-此密钥包中的密钥类型。该字段的合法值在表15“密钥下载数据类型”中定义。此字段被视为无符号值。
Key Package Length (2 octets) - The length of the Key Datum. This field is treated as an unsigned integer in network byte order format.
密钥包长度（2个八位字节）-密钥数据的长度。此字段被视为网络字节顺序格式的无符号整数。
Key Datum (variable length) - The actual data of the key. The format for this field is defined in Section 7.4.1.1, "Key Datum Structure".
键基准（可变长度）-键的实际数据。该字段的格式见第7.4.1.1节“关键基准结构”。
When processing the Rekey Event Payload, the following fields MUST be checked for correct values:
处理重设密钥事件有效负载时，必须检查以下字段的值是否正确：
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 下一有效载荷、保留有效载荷、有效载荷长度-这些字段按照第7.2.2节“通用有效载荷标头处理”中的定义进行处理。
2. Rekey Event Type field within "Rekey Event" payload header - The Rekey Event Type MUST be checked to be a valid rekey event type as defined by Table 17. If the Rekey Event Type is not valid, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
2. “Rekey Event”有效负载标头内的Rekey Event Type字段-必须检查Rekey Event Type是否为表17定义的有效Rekey Event Type。如果重新设置密钥事件类型无效，则无论采用何种模式（例如简练或详细），都会记录错误。没有为接收组管理消息生成响应错误消息。
3. Group ID Value - The Group ID value of the Rekey Event Header received message MUST be checked against the GroupID of the Group Component. If no match is found, the payload is discarded, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
3. 组ID值-必须对照组组件的组ID检查接收到的Rekey事件头消息的组ID值。如果未找到匹配项，则丢弃有效负载，然后无论采用何种模式（例如简练或详细），都会记录错误。没有为接收组管理消息生成响应错误消息。
4. Date/Time Stamp - The Date/Time Stamp value of the Rekey Event Header MAY be checked to determine if the Rekey Event generation time is recent relative to network delay and processing times. If the TimeStamp is judged not to be recent, an error is logged. No response error message is generated for receipt of a Group Management Message.
4. 日期/时间戳-可以检查密钥更新事件头的日期/时间戳值，以确定密钥更新事件生成时间是否是相对于网络延迟和处理时间最近的。如果判断时间戳不是最近的，则记录错误。没有为接收组管理消息生成响应错误消息。
5. Rekey Event Type field within the "Rekey Event Header" - The Rekey Event Type of the Rekey Event Header received message MUST be checked to be a valid rekey event type, as defined by Table 17, and the same value of the Rekey Event Type earlier in this payload. If the Rekey Event Type is not valid or not equal to the previous value of the Rekey Event Type, then regardless of
5. “Rekey Event Header”中的Rekey Event Type字段-必须检查Rekey Event Header接收消息的Rekey Event Type是否为有效的Rekey Event Type，如表17所定义，并且与此有效负载中之前的Rekey Event Type值相同。如果重新设置密钥事件类型无效或不等于重新设置密钥事件类型的上一个值，则不管
mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
模式（例如，简洁或详细）记录错误。没有为接收组管理消息生成响应错误消息。
6. Algorithm Version - The Rekey Algorithm Version number MUST be checked to ensure that the version indicated is supported. If it is not supported, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
6. 算法版本-必须检查密钥更新算法版本号，以确保支持指定的版本。如果不支持，则无论采用何种模式（例如简练或详细），都会记录错误。没有为接收组管理消息生成响应错误消息。
The length and counter fields are used to help process the message. If any field is found to be incorrect, then termination processing MUST be initiated.
长度和计数器字段用于帮助处理消息。如果发现任何字段不正确，则必须启动终止处理。
A GM MUST process all the Rekey Event Datas as based on the rekey method used there is a potential that multiple Rekey Event Datas are for this GM. The Rekey Event Datas are processed in order until all Rekey Event Datas are consumed.
GM必须根据使用的重新钥匙方法处理所有重新钥匙事件数据。此GM可能有多个重新钥匙事件数据。重新钥匙事件数据按顺序处理，直到所有重新钥匙事件数据被消耗。
1. Wrapping KeyID - The Wrapping KeyID MUST be checked against the list of stored KEKs that this GM holds. If a match is found, then continue processing this Rekey Event Data. Otherwise, skip to the next Rekey Event Data.
1. 包装密钥ID-包装密钥ID必须与此GM持有的存储密钥列表进行核对。如果找到匹配项，则继续处理此重设密钥事件数据。否则，跳到下一个重新设置事件数据。
2. Wrapping Handle - If a matching Wrapping KeyID was found, then the Wrapping Handle MUST be checked against the handle of the KEK for which the KeyID was a match. If the handles match, then the GM will process the Key Packages associated with this Rekey Event Data. Otherwise, skip to the next Rekey Event Data.
2. 包装句柄-如果找到匹配的包装密钥ID，则必须对照密钥ID匹配的KEK的句柄检查包装句柄。如果句柄匹配，则GM将处理与此重设密钥事件数据关联的密钥包。否则，跳到下一个重新设置事件数据。
If a GM has found a matching Wrapping KeyID and Wrapping Handle, the GM decrypts the remaining data in this Rekey Event Data according to policy using the KEK defined by the Wrapping KeyID and Handle. After decrypting the data, the GM extracts the # of Key Packages field to help process the subsequent Key Packages. The Key Packages are processed as follows:
如果GM已找到匹配的换行密钥ID和换行句柄，则GM将使用换行密钥ID和句柄定义的KEK，根据策略解密此重新设置密钥事件数据中的剩余数据。解密数据后，GM提取#of Key Packages字段以帮助处理后续的密钥包。关键包的处理如下所示：
1. Key Package Type - The Key Package Type MUST be checked to be a valid key package type as defined by Table 15. If the Key Package Type is not valid, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
1. 密钥包类型-必须检查密钥包类型是否为表15定义的有效密钥包类型。如果密钥包类型无效，则无论采用何种模式（例如简练或详细），都会记录错误。没有为接收组管理消息生成响应错误消息。
2. Key Package Length - The Key Package Length is used to process the subsequent Key Datum information.
2. 密钥包长度-密钥包长度用于处理后续密钥数据信息。
3. Key Type - The Key Type MUST be checked to be a valid key type as defined by Table 16. If the Key Package Type is not valid, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
3. 密钥类型-必须检查密钥类型是否为表16中定义的有效密钥类型。如果密钥包类型无效，则无论采用何种模式（例如简练或详细），都会记录错误。没有为接收组管理消息生成响应错误消息。
4. Key ID - The Key ID MUST be checked against the set of Key IDs that this user maintains for this Key Type. If no match is found, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
4. 密钥ID-必须对照此用户为此密钥类型维护的密钥ID集检查密钥ID。如果未找到匹配项，则无论采用何种模式（例如简练或详细），都会记录错误。没有为接收组管理消息生成响应错误消息。
5. Key Handle - The Key Handle is extracted as is and is used to be the new Key Handle for the Key currently associated with the Key Package's Key ID.
5. 密钥句柄-密钥句柄按原样提取，并用作当前与密钥包密钥ID关联的密钥的新密钥句柄。
6. Key Creation Date - The Key Creation Date MUST be checked that it is subsequent to the Key Creation Date for the currently held key. If this date is prior to the currently held key, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
6. 密钥创建日期-必须检查密钥创建日期是否在当前持有密钥的密钥创建日期之后。如果当前记录的是Verbose或terbose模式，则不管该日期是在哪种模式下。没有为接收组管理消息生成响应错误消息。
7. Key Expiration Date - The Key Expiration Date MUST be checked that it is subsequent to the Key Creation Date just received and that the time rules conform with policy. If the expiration date is not subsequent to the creation date or does not conform with policy, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
7. 密钥过期日期-必须检查密钥过期日期是否在刚收到的密钥创建日期之后，以及时间规则是否符合策略。如果过期日期不在创建日期之后或不符合策略，则无论采用何种模式（例如，简洁或详细），都会记录错误。没有为接收组管理消息生成响应错误消息。
8. Key Data - The Key Data is extracted based on the length information in the key package.
8. 密钥数据-根据密钥包中的长度信息提取密钥数据。
If there were no errors when processing the Key Package, the key represented by the KeyID will have all of its data updated based upon the received information.
如果在处理密钥包时没有错误，则由KeyID表示的密钥将根据接收到的信息更新其所有数据。
The Identification Payload contains entity-specific data used to exchange identification information. This information is used to verify the identities of members. Figure 18 shows the format of the Identification Payload.
标识有效负载包含用于交换标识信息的实体特定数据。此信息用于验证成员的身份。图18显示了标识有效负载的格式。
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 Classif ! ID Type ! 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 Classif ! ID Type ! Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Identification Payload Format
图18：识别有效载荷格式
The Identification Payload fields are defined as follows:
标识有效载荷字段定义如下：
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 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段提供“链接”功能。表12确定了有效载荷类型。此字段被视为无符号值。
RESERVED (1 octet) - Unused, set to 0.
保留（1个八位组）-未使用，设置为0。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。此字段被视为网络字节顺序格式的无符号整数。
Identification (ID) Classification (1 octet) - Classifies the ownership of the Identification Data. Table 18 identifies possible values for this field. This field is treated as an unsigned value.
标识（ID）分类（1个八位字节）-对标识数据的所有权进行分类。表18确定了该字段的可能值。此字段被视为无符号值。
Table 18: Identification Classification
表18：识别分类
ID_Classification Value
_______________________________
ID_Classification Value
_______________________________
Sender 0 Receiver 1 Third Party 2 Reserved to IANA 3 - 192 Private Use 193 - 255
发送方0接收方1第三方2保留给IANA 3-192私人使用193-255
Identification (ID) Type (1 octet) - Specifies the type of Identification being used. Table 19 identifies possible values for this type. This field is treated as an unsigned value. All defined types are OPTIONAL unless otherwise stated.
标识（ID）类型（1个八位字节）-指定正在使用的标识类型。表19确定了该类型的可能值。此字段被视为无符号值。除非另有说明，否则所有定义的类型都是可选的。
Identification Data (variable length) - Contains identity information. The values for this field are group specific, and the format is specified by the ID Type field. The format for this field is stated in conjunction with the type in Table 19.
标识数据（可变长度）-包含标识信息。此字段的值是特定于组的，格式由ID类型字段指定。该字段的格式与表19中的类型一起说明。
The payload type for the Identification Payload is four (4).
识别有效负载的有效负载类型为四（4）。
Table 19: Identification Types
表19：识别类型
ID_Type Value PKIX Cert Description
Field Defined In
_____________________________________________________________________
ID_Type Value PKIX Cert Description
Field Defined In
_____________________________________________________________________
Reserved 0
ID_IPV4_ADDR 1 SubjAltName See [IKEv2]
iPAddress Section 3.5.
ID_FQDN 2 SubjAltName See [IKEv2]
dNSName Section 3.5.
ID_RFC822_ADDR 3 SubjAltName See [IKEv2]
rfc822Name Section 3.5.
Reserved 4
ID_IPV6_ADDR 5 SubjAltName See [IKEv2]
iPAddress Section 3.5.
Reserved 6 - 8
ID_DER_ASN1_DN 9 Entire Subject, See [IKEv2]
bitwise Compare Section 3.5.
Reserved 10
ID_KEY_ID 11 N/A See [IKEv2]
Reserved 12 - 29 Section 3.5.
Unencoded Name 30 Subject The format for
(ID_U_NAME) this type is
defined in
Section 7.6.1.1.
ID_DN_STRING 31 Subject See [RFC4514].
This type MUST
be implemented.
Reserved to IANA 32 - 192
Private Use 193 - 255
Reserved 0
ID_IPV4_ADDR 1 SubjAltName See [IKEv2]
iPAddress Section 3.5.
ID_FQDN 2 SubjAltName See [IKEv2]
dNSName Section 3.5.
ID_RFC822_ADDR 3 SubjAltName See [IKEv2]
rfc822Name Section 3.5.
Reserved 4
ID_IPV6_ADDR 5 SubjAltName See [IKEv2]
iPAddress Section 3.5.
Reserved 6 - 8
ID_DER_ASN1_DN 9 Entire Subject, See [IKEv2]
bitwise Compare Section 3.5.
Reserved 10
ID_KEY_ID 11 N/A See [IKEv2]
Reserved 12 - 29 Section 3.5.
Unencoded Name 30 Subject The format for
(ID_U_NAME) this type is
defined in
Section 7.6.1.1.
ID_DN_STRING 31 Subject See [RFC4514].
This type MUST
be implemented.
Reserved to IANA 32 - 192
Private Use 193 - 255
The format for type Unencoded Name (ID_U_NAME) is shown in Figure 19.
类型Unencoded Name（ID____名称）的格式如图19所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! DN 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! DN Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Unencoded Name (ID-U-NAME) Format
图19：未编码名称（ID-U-Name）格式
Serial Number (20 octets) - The certificate serial number. This field is treated as an unsigned integer in network byte order format.
序列号（20个八位字节）-证书序列号。此字段被视为网络字节顺序格式的无符号整数。
Length (4 octets) - Length in octets of the DN Data field. This field is treated as an unsigned integer in network byte order format.
长度（4个八位字节）-DN数据字段的八位字节长度。此字段被视为网络字节顺序格式的无符号整数。
DN Data (variable length) - The actual UTF-8 DN value (Subject field) using the slash (/) character for field delimiters (e.g., "/C=US/ST=MD/L=Somewhere/O=ACME, Inc./OU=DIV1/CN=user1/ Email=user1@acme.com" without the surrounding quotes).
DN数据（可变长度）-使用斜杠（/）字符作为字段分隔符的实际UTF-8 DN值（主题字段）（例如“/C=US/ST=MD/L=某处/O=ACME，Inc./OU=DIV1/CN=user1/Email=user1@acme.com“没有周围的引号）。
When processing the Identification Payload, the following fields MUST be checked for correct values:
处理识别有效负载时，必须检查以下字段的值是否正确：
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 下一有效载荷、保留有效载荷、有效载荷长度-这些字段按照第7.2.2节“通用有效载荷标头处理”中的定义进行处理。
2. Identification Classification - The Identification Classification value MUST be checked to be a valid identification classification type as defined by Table 18. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. 标识分类-必须检查标识分类值是否为表18中定义的有效标识分类类型。如果该值无效，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
3. Identification Type - The Identification Type value MUST be checked to be a valid identification type as defined by Table 19. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
3. 标识类型-必须检查标识类型值是否为表19中定义的有效标识类型。如果该值无效，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
4. Identification Data - This Identification Data MUST be processed according to the identification type specified. The type will define the format of the data. If the identification data is being used to find a match and no match is found, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-ID-Information will be sent.
4. 识别数据-必须根据指定的识别类型处理该识别数据。该类型将定义数据的格式。如果识别数据用于查找匹配项，但未找到匹配项，则会记录错误。如果处于详细模式，将发送包含通知值无效ID信息的适当消息。
When processing the Identification Data of type ID_U_NAME, the following fields MUST be checked for correct values:
在处理ID\U\U NAME类型的标识数据时，必须检查以下字段的值是否正确：
1. Serial Number - The serial number MUST be a greater than or equal to one (1) to be a valid serial number from a conforming CA [RFC3280]. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
1. 序列号-序列号必须大于或等于一（1）才能成为合格CA的有效序列号[RFC3280]。如果该值无效，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
2. DN Data - The DN data is processed as a UTF-8 string.
2. DN数据-DN数据作为UTF-8字符串处理。
3. The CA MUST be a valid trusted policy creation authority as defined by the Policy Token.
3. CA必须是策略令牌定义的有效受信任策略创建机构。
These 2 pieces of information, Serial Number and DN Data, in conjunction, will then be used for party identification. These values are also used to help identify the certificate when necessary.
这两条信息、序列号和DN数据将一起用于识别参与方。必要时，这些值也可用于帮助识别证书。
The Certificate Payload provides a means to transport certificates or other certificate-related information via GSAKMP and can appear in any GSAKMP message. Certificate payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g., LDAP [RFC4523]) is not available to distribute certificates. Multiple
证书有效负载提供了通过GSAKMP传输证书或其他证书相关信息的方法，并且可以出现在任何GSAKMP消息中。当适当的目录服务（例如LDAP[RFC4523]）不可用于分发证书时，应将证书有效载荷包括在exchange中。倍数
certificate payloads MAY be sent to enable verification of certificate chains. Conversely, zero (0) certificate payloads may be sent, and the receiving GSAKMP MUST rely on some other mechanism to retrieve certificates for verification purposes. Figure 20 shows the format of the Certificate Payload.
可以发送证书有效载荷，以便能够验证证书链。相反，可能会发送零（0）个证书有效负载，并且接收的GSAKMP必须依赖于某些其他机制来检索证书以进行验证。图20显示了证书有效负载的格式。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Type ! Certificate 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Type ! Certificate Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Certificate Payload Format
图20：证书有效负载格式
The Certificate Payload fields are defined as follows:
证书有效负载字段定义如下：
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 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段提供“链接”功能。表12确定了有效载荷类型。此字段被视为无符号值。
RESERVED (1 octet) - Unused, set to 0.
保留（1个八位组）-未使用，设置为0。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。此字段被视为网络字节顺序格式的无符号整数。
Certificate Type (2 octets) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field. Table 20 presents the types of certificate payloads. This field is treated as an unsigned integer in network byte order format.
证书类型（2个八位字节）-此字段表示证书类型或证书数据字段中包含的证书相关信息。表20显示了证书有效载荷的类型。此字段被视为网络字节顺序格式的无符号整数。
Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Type/Encoding field.
证书数据（可变长度）-证书数据的实际编码。证书类型由证书类型/编码字段指示。
The payload type for the Certificate Payload is six (6).
证书有效负载的有效负载类型为六（6）。
Table 20: Certificate Payload Types
表20：证书有效负载类型
Certificate_Type Value Description/
Defined In
_____________________________________________________________________
Certificate_Type Value Description/
Defined In
_____________________________________________________________________
None 0
Reserved 1 - 3
X.509v3 Certificate 4 This type MUST be
-- Signature implemented.
-- DER Encoding Contains a DER
encoded X.509
certificate.
Reserved 5 - 6
Certificate Revocation List 7 Contains a BER
(CRL) encoded X.509 CRL.
Reserved 8 - 9
X.509 Certificate 10 See [IKEv2], Sec 3.6.
-- Attribute
Raw RSA Key 11 See [IKEv2], Sec 3.6.
Hash and URL of X.509 12 See [IKEv2], Sec 3.6.
Certificate
Hash and URL of X.509 13 See [IKEv2], Sec 3.6.
bundle
Reserved to IANA 14 -- 49152
Private Use 49153 -- 65535
None 0
Reserved 1 - 3
X.509v3 Certificate 4 This type MUST be
-- Signature implemented.
-- DER Encoding Contains a DER
encoded X.509
certificate.
Reserved 5 - 6
Certificate Revocation List 7 Contains a BER
(CRL) encoded X.509 CRL.
Reserved 8 - 9
X.509 Certificate 10 See [IKEv2], Sec 3.6.
-- Attribute
Raw RSA Key 11 See [IKEv2], Sec 3.6.
Hash and URL of X.509 12 See [IKEv2], Sec 3.6.
Certificate
Hash and URL of X.509 13 See [IKEv2], Sec 3.6.
bundle
Reserved to IANA 14 -- 49152
Private Use 49153 -- 65535
When processing the Certificate Payload, the following fields MUST be checked for correct values:
处理证书有效负载时，必须检查以下字段的值是否正确：
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 下一有效载荷、保留有效载荷、有效载荷长度-这些字段按照第7.2.2节“通用有效载荷标头处理”中的定义进行处理。
2. Certificate Type - The Certificate Type value MUST be checked to be a valid certificate type as defined by Table 20. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Cert-Type-Unsupported will be sent.
2. 证书类型-必须检查证书类型值是否为表20定义的有效证书类型。如果该值无效，则会记录错误。如果处于详细模式，将发送包含通知值Cert Type Unsupported的适当消息。
3. Certificate Data - This Certificate Data MUST be processed according to the certificate type specified. The type will define the format of the data. Receipt of a certificate of the trusted policy creation authority in a Certificate payload causes
3. 证书数据-必须根据指定的证书类型处理此证书数据。该类型将定义数据的格式。在证书有效负载中接收受信任策略创建机构的证书
the payload to be discarded. This received certificate MUST NOT be used to verify the message. The certificate of the trusted policy creation authority MUST be retrieved by other means.
要丢弃的有效载荷。此收到的证书不得用于验证消息。必须通过其他方式检索受信任策略创建机构的证书。
The Signature Payload contains data generated by the digital signature function. The digital signature, as defined by the dissection of each message, covers the message from the GSAKMP Message Header through the Signature Payload, up to but not including the Signature Data Length. Figure 21 shows the format of the Signature Payload.
签名有效载荷包含由数字签名函数生成的数据。通过对每条消息的剖析定义的数字签名，涵盖了从GSAKMP消息头到签名有效载荷的消息，不超过但不包括签名数据长度。图21显示了签名有效负载的格式。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signature Type ! Sig ID Type ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Signature Timestamp ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Signer ID Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signer ID Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signature Length ! Signature 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signature Type ! Sig ID Type ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Signature Timestamp ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Signer ID Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signer ID Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signature Length ! Signature Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Signature Payload Format
图21：签名有效负载格式
The Signature Payload fields are defined as follows:
签名有效负载字段定义如下：
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 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段提供“链接”功能。表12确定了有效载荷类型。此字段被视为无符号值。
RESERVED (1 octet) - Unused, set to 0.
保留（1个八位组）-未使用，设置为0。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。此字段被视为网络字节顺序格式的无符号整数。
Signature Type (2 octets) - Indicates the type of signature. Table 21 presents the allowable signature types. This field is treated as an unsigned integer in network byte order format.
签名类型（2个八位字节）-表示签名的类型。表21给出了允许的签名类型。此字段被视为网络字节顺序格式的无符号整数。
Table 21: Signature Types
表21：签名类型
Signature Type Value Description/
Defined In
_____________________________________________________________________
Signature Type Value Description/
Defined In
_____________________________________________________________________
DSS/SHA1 with ASN.1/DER encoding 0 This type MUST (DSS-SHA1-ASN1-DER) be supported. RSA1024-MD5 1 See [RFC3447]. ECDSA-P384-SHA3 2 See [FIPS186-2]. Reserved to IANA 3 - 41952 Private Use 41953 - 65536
ASN.1/DER编码为0的DSS/SHA1必须支持此类型（DSS-SHA1-ASN1-DER）。RSA1024-MD5 1参见[RFC3447]。ECDSA-P384-SHA3 2参见[FIPS186-2]。保留给IANA 3-41952私人使用41953-65536
Signature ID Type (1 octet) - Indicates the format for the Signature ID Data. These values are the same as those defined for the Identification Payload Identification types, which can be found in Table 19. This field is treated as an unsigned value.
签名ID类型（1个八位字节）-表示签名ID数据的格式。这些值与表19中为识别有效载荷识别类型定义的值相同。此字段被视为无符号值。
Signature Timestamp (15 octets) - This is the time value when the digital signature was applied. This field contains the timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999), MM is the numerical value of the month (01 - 12), DD is the day of the month (01 - 31), HH is the hour of the day (00 - 23), MM is the minute within the hour (00 - 59), SS is the seconds within the minute (00 - 59), and the letter Z indicates that this is Zulu time. This format is loosely based on [RFC3161].
签名时间戳（15个八位字节）-这是应用数字签名时的时间值。此字段包含UTF-8格式的时间戳YYYYMMDDHMMSSZ，其中YYYY是年（0000-9999），MM是月的数值（01-12），DD是月的日（01-31），HH是一天中的小时（00-23），MM是小时内的分钟（00-59），SS是分钟内的秒（00-59），字母Z表示这是祖鲁时间。此格式大致基于[RFC3161]。
Signer ID Length (2 octets) - Length in octets of the Signer's ID. This field is treated as an unsigned integer in network byte order format.
签名者ID长度（2个八位字节）-签名者ID的八位字节长度。此字段被视为网络字节顺序格式的无符号整数。
Signer ID Data (variable length) - Data identifying the Signer's ID (e.g., DN). The format for this field is based on the Signature ID Type field and is shown where that type is defined. The contents of this field MUST be checked against the Policy Token to determine the authority and access of the Signer within the context of the group.
签名者ID数据（可变长度）-标识签名者ID（例如DN）的数据。此字段的格式基于签名ID类型字段，并显示在定义该类型的位置。必须对照策略令牌检查此字段的内容，以确定签名者在组上下文中的权限和访问权限。
Signature Length (2 octets) - Length in octets of the Signature Data. This field is treated as an unsigned integer in network byte order format.
签名长度（2个八位字节）-签名数据的八位字节长度。此字段被视为网络字节顺序格式的无符号整数。
Signature Data (variable length) - Data that results from applying the digital signature function to the GSAKMP message and/or payload.
签名数据（可变长度）-将数字签名功能应用于GSAKMP消息和/或有效负载后产生的数据。
The payload type for the Signature Payload is eight (8).
签名有效负载的有效负载类型为八（8）。
When processing the Signature Payload, the following fields MUST be checked for correct values:
处理签名有效负载时，必须检查以下字段的值是否正确：
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 下一有效载荷、保留有效载荷、有效载荷长度-这些字段按照第7.2.2节“通用有效载荷标头处理”中的定义进行处理。
2. Signature Type - The Signature Type value MUST be checked to be a valid signature type as defined by Table 21. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. 签名类型-必须检查签名类型值是否为表21定义的有效签名类型。如果该值无效，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
3. Signature ID Type - The Signature ID Type value MUST be checked to be a valid signature ID type as defined by Table 19. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
3. 签名ID类型-必须检查签名ID类型值是否为表19中定义的有效签名ID类型。如果该值无效，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
4. Signature Timestamp - This field MAY be checked to determine if the transaction signing time is fresh relative to expected network delays. Such a check is appropriate for systems in which archived sequences of events are desired.
4. 签名时间戳-可检查此字段以确定事务签名时间相对于预期网络延迟是否新鲜。这种检查适用于需要归档事件序列的系统。
NOTE: The maximum acceptable age of a signature timestamp relative to the local system clock is a locally configured parameter that can be tuned by its GSAKMP management interface.
注：签名时间戳相对于本地系统时钟的最大可接受年限是一个本地配置的参数，可通过其GSAKMP管理接口进行调整。
5. Signature ID Data - This field will be used to identify the sending party. This information MUST then be used to confirm that the correct party sent this information. This field is also used to retrieve the appropriate public key of the certificate to verify the message.
5. 签名ID数据-此字段将用于标识发送方。然后，必须使用此信息确认发送此信息的是正确的一方。此字段还用于检索证书的适当公钥以验证消息。
6. Signature Data - This value MUST be compared to the recomputed signature to verify the message. Information on how to verify certificates used to ascertain the validity of the signature can be found in [RFC3280]. Only after the certificate identified by the Signature ID Data is verified can the signature be computed to compare to the signature data for signature verification. A potential error that can occur during signature verification is Authentication-Failed. Potential errors that can occur while processing certificates for signature verification are: Invalid-Certificate, Invalid-Cert-Authority, Cert-Type-Unsupported, and Certificate-Unavailable.
6. 签名数据-必须将此值与重新计算的签名进行比较，以验证消息。有关如何验证用于确定签名有效性的证书的信息，请参见[RFC3280]。只有在验证由签名ID数据标识的证书之后，才能计算签名以与签名数据进行比较，以进行签名验证。签名验证期间可能发生的一个潜在错误是身份验证失败。处理证书进行签名验证时可能出现的潜在错误有：无效证书、无效证书颁发机构、不支持证书类型和证书不可用。
The length fields in the Signature Payload are used to process the remainder of the payload. If any field is found to be incorrect, then termination processing MUST be initiated.
签名有效负载中的长度字段用于处理剩余的有效负载。如果发现任何字段不正确，则必须启动终止处理。
The Notification Payload can contain both GSAKMP and group-specific data and is used to transmit informational data, such as error conditions, to a GSAKMP peer. It is possible to send multiple independent Notification payloads in a single GSAKMP message. Figure 22 shows the format of the Notification Payload.
通知有效负载可以包含GSAKMP和组特定数据，并用于将信息数据（如错误条件）传输到GSAKMP对等方。可以在单个GSAKMP消息中发送多个独立的通知有效负载。图22显示了通知有效负载的格式。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Notification Type ! Notification 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Notification Type ! Notification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Notification Payload Format
图22：通知有效负载格式
The Notification Payload fields are defined as follows:
通知有效负载字段定义如下：
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 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段提供“链接”功能。表12确定了有效载荷类型。此字段被视为无符号值。
RESERVED (1 octet) - Unused, set to 0.
保留（1个八位组）-未使用，设置为0。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。此字段被视为网络字节顺序格式的无符号整数。
Notification Type (2 octets) - Specifies the type of notification message. Table 22 presents the Notify Payload Types. This field is treated as an unsigned integer in network byte order format.
通知类型（2个八位字节）-指定通知消息的类型。表22显示了Notify有效负载类型。此字段被视为网络字节顺序格式的无符号整数。
Notification Data (variable length) - Informational or error data transmitted in addition to the Notify Payload Type. Values for this field are Domain of Interpretation (DOI) specific.
通知数据（可变长度）-除通知有效负载类型外发送的信息或错误数据。此字段的值特定于解释域（DOI）。
The payload type for the Notification Payload is nine (9).
通知有效负载的有效负载类型为九（9）。
Table 22: Notification Types
表22：通知类型
Notification Type Value
__________________________________________________________
Notification Type Value
__________________________________________________________
None 0 Invalid-Payload-Type 1 Reserved 2 - 3 Invalid-Version 4 Invalid-Group-ID 5 Invalid-Sequence-ID 6 Payload-Malformed 7 Invalid-Key-Information 8 Invalid-ID-Information 9 Reserved 10 - 11 Cert-Type-Unsupported 12 Invalid-Cert-Authority 13 Authentication-Failed 14 Reserved 15 - 16 Certificate-Unavailable 17 Reserved 18 Unauthorized-Request 19 Reserved 20 - 22 Acknowledgement 23 Reserved 24 - 25 Nack 26 Cookie-Required 27 Cookie 28 Mechanism Choices 29 Leave Group 30 Departure Accepted 31 Request to Depart Error 32 Invalid Exchange Type 33 IPv4 Value 34
无0无效有效负载类型1保留2-3无效版本4无效组ID 5无效序列ID 6有效负载格式错误7无效密钥信息8无效ID信息9保留10-11证书类型不受支持12无效证书颁发机构13身份验证失败14保留15-16证书不可用17保留18未经授权的请求19保留20-22确认23保留24-25 Nack 26 Cookie所需27 Cookie 28机制选择29离开组30离开已接受31离开请求错误32无效交换类型33 IPv4值34
IPv6 Value 35 Prohibited by Group Policy 36 Prohibited by Locally Configured Policy 37 Reserved to IANA 38 - 49152 Private Use 49153 -- 65535
IPv6值35被组策略禁止36被本地配置的策略禁止37保留给IANA 38-49152专用49153-65535
The data portion of the Notification payload of type ACK either serves as confirmation of correct receipt of the Key Download message or, when needed, provides other receipt information when included in a signed message. Figure 23 shows the format of the Notification Data - Acknowledge Payload Type.
ACK类型的通知有效载荷的数据部分用作确认密钥下载消息的正确接收，或者在需要时，当包含在签名消息中时提供其他接收信息。图23显示了通知数据的格式-确认有效负载类型。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Ack Type ! Acknowledgement 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Ack Type ! Acknowledgement Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Notification Data - Acknowledge Payload Type Format
图23：通知数据-确认有效负载类型格式
The Notification Data - Acknowledgement Payload Type data fields are defined as follows:
通知数据-确认有效负载类型数据字段定义如下：
Ack Type (1 octet) - Specifies the type of acknowledgement. Table 23 presents the Notify Acknowledgement Payload Types. This field is treated as an unsigned value.
确认类型（1个八位字节）-指定确认的类型。表23显示了通知确认有效负载类型。此字段被视为无符号值。
Table 23: Acknowledgement Types
表23：确认类型
ACK_Type Value Definition
_____________________________________________________
ACK_Type Value Definition
_____________________________________________________
Simple 0 Data portion null. Reserved to IANA 1 - 192 Private Use 193 - 255
简单0数据部分为空。保留给IANA 1-192私人使用193-255
The data portion of the Notification payload of types Cookie_Required and Cookie contain the Cookie value. The value for this field will have been computed by the responder GC/KS and sent to the GM. The GM will take the value received and copy it into the Notification payload Notification Data field of type Cookie that is transmitted in the "Request to Join with Cookie Info" back to the GC/KS. The cookie value MUST NOT be modified.
Cookie_Required和Cookie类型的通知负载的数据部分包含Cookie值。此字段的值将由响应者GC/KS计算并发送给GM。GM将获取收到的值并将其复制到Cookie类型的通知有效负载通知数据字段中，该字段在“请求加入Cookie信息”中传输回GC/KS。不得修改cookie值。
The format for this is already described in the discussion on cookies in Section 5.2.2.
第5.2.2节中关于cookie的讨论中已经描述了该格式。
The data portion of the Notification payload of type Mechanism Choices contains the mechanisms the GM is requesting to use for the negotiation with the GC/KS. This information will be supplied by the GM in a RTJ message. Figure 24 shows the format of the Notification Data - Mechanism Choices Payload Type. Multiple type|length|data choices are strung together in one notification payload to allow a user to transmit all relevant information within one Notification Payload. The length of the payload will control the parsing of the Notification Data Mechanism Choices field.
机制选择类型的通知有效负载的数据部分包含GM请求用于与GC/KS协商的机制。该信息将由GM在RTJ信息中提供。图24显示了通知数据-机制选择负载类型的格式。多个类型|长度|数据选择串在一个通知负载中，以允许用户在一个通知负载中传输所有相关信息。有效负载的长度将控制Notification Data Mechanism Choices字段的解析。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Mech Type ! Mechanism Choice 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Mech Type ! Mechanism Choice Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..
Figure 24: Notification Data - Mechanism Choices Payload Type Format
图24：通知数据-机制选择有效负载类型格式
The Notification Data - Mechanism Choices Payload Type data fields are defined as follows:
通知数据-机制选择有效负载类型数据字段定义如下：
Mechanism Type (1 octet) - Specifies the type of mechanism. Table 24 presents the Notify Mechanism Choices Mechanism Types. This field is treated as an unsigned value.
机构类型（1个八位字节）-指定机构的类型。表24显示了通知机制选择机制类型。此字段被视为无符号值。
Table 24: Mechanism Types
表24：机构类型
Mechanism_Type Value Mechanism Choice
Data Value Table Reference
___________________________________________________________________
Mechanism_Type Value Mechanism Choice
Data Value Table Reference
___________________________________________________________________
Key Creation Algorithm 0 Table 26 Encryption Algorithm 1 Table 16 Nonce Hash Algorithm 2 Table 25 Reserved to IANA 3 - 192 Private Use 193 - 255
密钥创建算法0表26加密算法1表16 Nonce哈希算法2表25保留给IANA 3-192专用193-255
Mechanism Choice Data (2 octets) - The data value for the mechanism type being selected. The values are specific to each Mechanism Type defined. All tables necessary to define the values that are not defined elsewhere (in this specification or others) are defined here. This field is treated as an unsigned integer in network byte order format.
机构选择数据（2个八位字节）-所选机构类型的数据值。这些值特定于定义的每个机构类型。此处定义了定义其他地方（本规范或其他规范中）未定义的值所需的所有表格。此字段被视为网络字节顺序格式的无符号整数。
Table 25: Nonce Hash Types
表25：Nonce散列类型
Nonce_Hash_Type Value Description
__________________________________________________________________
Nonce_Hash_Type Value Description
__________________________________________________________________
Reserved 0 SHA-1 1 This type MUST be supported. Reserved to IANA 2 - 49152 Private Use 49153 - 65535
保留0-1必须支持此类型。保留给IANA 2-49152私人使用49153-65535
The data portion of the Notification payload of type IPv4 and IPv6 value contains the appropriate IP value in network byte order. This value will be set by the creator of the message for consumption by the receiver of the message.
IPv4和IPv6值类型的通知有效负载的数据部分按网络字节顺序包含相应的IP值。该值将由消息创建者设置，以供消息接收者使用。
When processing the Notification Payload, the following fields MUST be checked for correct values:
处理通知有效负载时，必须检查以下字段的值是否正确：
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 下一有效载荷、保留有效载荷、有效载荷长度-这些字段按照第7.2.2节“通用有效载荷标头处理”中的定义进行处理。
2. Notification Type - The Notification type value MUST be checked to be a notification type as defined by Table 22. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. 通知类型-必须检查通知类型值是否为表22定义的通知类型。如果该值无效，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
3. Notification Data - This Notification Data MUST be processed according to the notification type specified. The type will define the format of the data. When processing this data, any type field MUST be checked against the appropriate table for correct values. If the contents of the Notification Data are not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
3. 通知数据-必须根据指定的通知类型处理此通知数据。该类型将定义数据的格式。处理此数据时，必须对照相应的表检查任何类型字段的正确值。如果通知数据的内容无效，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
The Vendor ID Payload contains a vendor-defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backwards compatibility. Figure 25 shows the format of the payload.
供应商ID有效负载包含供应商定义的常量。供应商使用该常量来识别和识别其实现的远程实例。这种机制允许供应商在保持向后兼容性的同时试验新功能。图25显示了有效负载的格式。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Vendor ID (VID) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Vendor ID (VID) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Vendor ID Payload Format
图25：供应商ID有效负载格式
A Vendor ID payload MAY announce that the sender is capable of accepting certain extensions to the protocol, or it MAY simply identify the implementation as an aid in debugging. A Vendor ID payload MUST NOT change the interpretation of any information defined in this specification. Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to send any Vendor ID payload at all.
供应商ID有效负载可以宣布发送方能够接受协议的某些扩展，或者它可以简单地将实现标识为调试的辅助。供应商ID有效载荷不得改变本规范中定义的任何信息的解释。可以发送多个供应商ID有效载荷。根本不需要实现来发送任何供应商ID有效负载。
A Vendor ID payload may be sent as part of any message. Receipt of a familiar Vendor ID payload allows an implementation to make use of Private Use numbers described throughout this specification -- private payloads, private exchanges, private notifications, etc. This implies that all the processing rules defined for all the payloads are now modified to recognize all values defined by this Vendor ID for all fields of all payloads. Unfamiliar Vendor IDs MUST be ignored.
供应商ID有效负载可以作为任何消息的一部分发送。接收熟悉的供应商ID有效载荷允许实现使用本规范中描述的专用编号——专用有效载荷、专用交换、专用通知、，等等。这意味着现在修改为所有有效载荷定义的所有处理规则，以识别此供应商ID为所有有效载荷的所有字段定义的所有值。必须忽略不熟悉的供应商ID。
Writers of Internet-Drafts who wish to extend this protocol MUST define a Vendor ID payload to announce the ability to implement the extension in the Internet-Draft. It is expected that Internet-Drafts that gain acceptance and are standardized will be given assigned values out of the Reserved to IANA range, and the requirement to use a Vendor ID payload will go away.
希望扩展此协议的Internet草案编写者必须定义供应商ID有效负载，以宣布在Internet草案中实现扩展的能力。预计获得认可和标准化的互联网草案将被赋予超出IANA保留范围的赋值，使用供应商ID有效载荷的要求将消失。
The Vendor ID payload fields are defined as follows:
供应商ID有效负载字段定义如下：
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 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段提供“链接”功能。表12确定了有效载荷类型。此字段被视为无符号值。
RESERVED (1 octet) - Unused, set to 0.
保留（1个八位组）-未使用，设置为0。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。此字段被视为网络字节顺序格式的无符号整数。
Vendor ID (variable length) - The Vendor ID value. The minimum length for this field is four (4) octets. It is the responsibility of the person choosing the Vendor ID to assure its uniqueness in spite of the absence of any central registry for IDs. Good practice is to include a company name, a person name, or similar type data. A message digest of a long unique string is preferable to the long unique string itself.
供应商ID（可变长度）-供应商ID值。该字段的最小长度为四（4）个八位字节。选择供应商ID的人员有责任确保其唯一性，尽管没有ID的中央注册。良好的做法是包含公司名称、人名或类似类型的数据。长唯一字符串的消息摘要比长唯一字符串本身更可取。
The payload type for the Vendor ID Payload is ten (10).
供应商ID有效负载的有效负载类型为十（10）。
When processing the Vendor ID Payload, the following fields MUST be checked for correct values:
处理供应商ID有效负载时，必须检查以下字段的值是否正确：
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 下一有效载荷、保留有效载荷、有效载荷长度-这些字段按照第7.2.2节“通用有效载荷标头处理”中的定义进行处理。
2. Vendor ID - The Vendor ID Data MUST be processed to determine if the Vendor ID value is recognized by the implementation. If the Vendor ID value is not recognized, then regardless of mode (e.g., Terse or Verbose) this information is logged. Processing of the message MUST continue regardless of recognition of this value.
2. 供应商ID—必须处理供应商ID数据，以确定实现是否识别供应商ID值。如果无法识别供应商ID值，则无论采用何种模式（例如简练或详细），都会记录此信息。无论是否识别此值，都必须继续处理消息。
It is recommended that implementations that want to use Vendor-ID-specific information attempt to process the Vendor ID payloads of an incoming message prior to the remainder of the message processing. This will allow the implementation to recognize that when processing other payloads it can use the larger set of values for payload fields (Private Use values, etc.) as defined by the recognized Vendor IDs.
建议希望使用供应商ID特定信息的实现尝试在消息处理的其余部分之前处理传入消息的供应商ID有效负载。这将允许实现认识到，在处理其他有效负载时，它可以使用由已识别的供应商ID定义的有效负载字段（专用值等）的更大值集。
The Key Creation Payload contains information used to create key encryption keys. The security attributes for this payload are provided in the Policy Token. Figure 26 shows the format of the payload.
密钥创建有效负载包含用于创建密钥加密密钥的信息。此有效负载的安全属性在策略令牌中提供。图26显示了有效负载的格式。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Creation Type ! Key Creation 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Creation Type ! Key Creation Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Key Creation Payload Format
图26：密钥创建有效负载格式
The Key Creation Payload fields are defined as follows:
密钥创建有效负载字段定义如下：
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 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段提供“链接”功能。表12确定了有效载荷类型。此字段被视为无符号值。
RESERVED (1 octet) - Unused, set to 0.
保留（1个八位组）-未使用，设置为0。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。此字段被视为网络字节顺序格式的无符号整数。
Key Creation Type (2 octets) - Specifies the type of Key Creation being used. Table 26 identifies the types of key creation information. This field is treated as an unsigned integer in network byte order format.
密钥创建类型（2个八位字节）-指定正在使用的密钥创建类型。表26确定了密钥创建信息的类型。此字段被视为网络字节顺序格式的无符号整数。
Key Creation Data (variable length) - Contains Key Creation information. The values for this field are group specific, and the format is specified by the key creation type field.
密钥创建数据（可变长度）-包含密钥创建信息。此字段的值特定于组，格式由“键创建类型”字段指定。
The payload type for the Key Creation Packet is eleven (11).
密钥创建数据包的有效负载类型为十一（11）。
Table 26: Types of Key Creation Information
表26：密钥创建信息的类型
Key Creation Type Value Definition/Defined In
_____________________________________________________________________
Key Creation Type Value Definition/Defined In
_____________________________________________________________________
Reserved 0 - 1 Diffie-Hellman 2 This type MUST be supported. 1024-bit MODP Group Defined in [IKEv2] B.2. Truncated If the output of the process is longer than needed for the defined mechanism, use the first X low order bits and truncate the remainder. Reserved 3 - 13 Diffie-Hellman 14 Defined in [RFC3526]. 2048-bit MODP Group If the output of the process Truncated is longer than needed for the defined mechanism, use the first X low order bits and truncate the remainder. Reserved to IANA 15 - 49152 Private Use 49153 - 65535
保留的0-1 Diffie Hellman 2必须支持此类型。[IKEv2]B.2中定义的1024位MODP组。截断如果进程的输出长于所定义机制所需的长度，则使用前X个低阶位并截断剩余的位。[RFC3526]中定义的保留3-13 Diffie-Hellman 14。2048位MODP组如果被截断的进程的输出比定义的机制所需的长，则使用前X个低阶位并截断剩余的。保留给IANA 15-49152私人使用49153-65535
The specifics of the Key Creation Payload are defined in Section 7.11.
第7.11节中定义了密钥创建有效载荷的细节。
When processing the Key Creation Payload, the following fields MUST be checked for correct values:
处理密钥创建有效负载时，必须检查以下字段的值是否正确：
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 下一有效载荷、保留有效载荷、有效载荷长度-这些字段按照第7.2.2节“通用有效载荷标头处理”中的定义进行处理。
2. Key Creation Type - The Key Creation Type value MUST be checked to be a valid key creation type as defined by Table 26. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. 密钥创建类型-必须检查密钥创建类型值是否为表26定义的有效密钥创建类型。如果该值无效，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
3. Key Creation Data - This Key Creation Data MUST be processed according to the key creation type specified to generate the KEK to protect the information to be sent in the appropriate message. The type will define the format of the data.
3. 密钥创建数据-必须根据指定的密钥创建类型来处理该密钥创建数据，以生成KEK，从而保护要在适当消息中发送的信息。该类型将定义数据的格式。
Implementations that want to derive other keys from the initial Key Creation keying material (for example, DH Secret keying material) MUST define a Key Creation Type other than one of those shown in Table 26. The new Key Creation Type must specify that derivation's algorithm, for which the KEK MAY be one of the keys derived.
想要从初始密钥创建密钥材料（例如，DH Secret keying material）派生其他密钥的实现必须定义一种密钥创建类型，而不是表26所示的类型。新的密钥创建类型必须指定派生的算法，KEK可能是派生的密钥之一。
The Nonce Payload contains random data used to guarantee freshness during an exchange and protect against replay attacks. Figure 27 shows the format of the Nonce Payload.
Nonce有效负载包含用于保证交换期间的新鲜度和防止重播攻击的随机数据。图27显示了Nonce有效负载的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Nonce Type ! Nonce 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Nonce Type ! Nonce Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Nonce Payload Format
图27：Nonce有效负载格式
The Nonce Payload fields are defined as follows:
Nonce有效负载字段定义如下：
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 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段提供“链接”功能。表12确定了有效载荷类型。此字段被视为无符号值。
RESERVED (1 octet) - Unused, set to 0.
保留（1个八位组）-未使用，设置为0。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。此字段被视为网络字节顺序格式的无符号整数。
Nonce Type (1 octet) - Specifies the type of nonce being used. Table 27 identifies the types of nonces. This field is treated as an unsigned value.
Nonce Type（1个八位字节）-指定正在使用的Nonce的类型。表27确定了nonce的类型。此字段被视为无符号值。
Table 27: Nonce Types
表27：临时类型
Nonce_Type Value Definition
_____________________________________________________________________
Nonce_Type Value Definition
_____________________________________________________________________
None 0 Initiator (Nonce_I) 1 Responder (Nonce_R) 2 Combined (Nonce_C) 3 Hash (Append (Initiator_Value,Responder_Value)) The hash type comes from the Policy (e.g., Security Suite Definition of Policy Token). Reserved to IANA 4 - 192 Private Use 192 - 255
None 0启动器（Nonce_I）1响应程序（Nonce_R）2组合（Nonce_C）3哈希（Append（Initiator_值，Responder_值））哈希类型来自策略（例如，策略令牌的安全套件定义）。保留给IANA 4-192专用192-255
Nonce Data (variable length) - Contains the nonce information. The values for this field are group specific, and the format is specified by the Nonce Type field. If no group-specific information is provided, the minimum length for this field is 4 bytes.
Nonce数据（可变长度）-包含Nonce信息。此字段的值是特定于组的，格式由Nonce Type字段指定。如果未提供组特定信息，则此字段的最小长度为4字节。
The payload type for the Nonce Payload is twelve (12).
当前有效载荷的有效载荷类型为十二（12）。
When processing the Nonce Payload, the following fields MUST be checked for correct values:
处理当前有效负载时，必须检查以下字段的值是否正确：
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 下一有效载荷、保留有效载荷、有效载荷长度-这些字段按照第7.2.2节“通用有效载荷标头处理”中的定义进行处理。
2. Nonce Type - The Nonce Type value MUST be checked to be a valid nonce type as defined by Table 27. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. Nonce类型-必须检查Nonce类型值是否为表27定义的有效Nonce类型。如果该值无效，则会记录错误。如果处于详细模式，将发送一条包含通知值Payload Malformed的适当消息。
3. Nonce Data - This is the nonce data and it must be checked according to its content. The size of this field is defined in Section 7.12, "Nonce Payload". Refer to Section 5.2, "Group Establishment", for interpretation of this field.
3. Nonce数据-这是Nonce数据，必须根据其内容进行检查。该字段的大小在第7.12节“非有效载荷”中定义。有关该领域的解释，请参阅第5.2节“集团成立”。
Figure 28 presents the states encountered in the use of this protocol. Table 28 defines the states. Table 29 defines the transitions.
图28显示了在使用本协议时遇到的状态。表28界定了各州。表29定义了转换。
!-----------------> ( )
! !-------------> ( Idle ) <------------------!
! ! ( ) !
! ! ! ! !
! ! ! ! !
! ! (1a) (1) !
! ! ! ! !
! ! ! ! !
! ! V V !
! !---(5a)--- (Wait for ) (Wait for ) ----(5)-----!
! (Group ) (GC/KS Event) <---
! (Membership) ^ ! \ \
! ! ! ! \ \
! ! ! ! \--(2)---\
! (2a) (4)(3)
! ! ! !
! ! ! !
! V ! V
!-------(4a)--- (Wait for ) (Wait for )
(Group ) (Response )
(Membership) (from Key )
/--> (Event ) (Download )
/ /
/ /
/--(3a)---/
!-----------------> ( )
! !-------------> ( Idle ) <------------------!
! ! ( ) !
! ! ! ! !
! ! ! ! !
! ! (1a) (1) !
! ! ! ! !
! ! ! ! !
! ! V V !
! !---(5a)--- (Wait for ) (Wait for ) ----(5)-----!
! (Group ) (GC/KS Event) <---
! (Membership) ^ ! \ \
! ! ! ! \ \
! ! ! ! \--(2)---\
! (2a) (4)(3)
! ! ! !
! ! ! !
! V ! V
!-------(4a)--- (Wait for ) (Wait for )
(Group ) (Response )
(Membership) (from Key )
/--> (Event ) (Download )
/ /
/ /
/--(3a)---/
Figure 28: GSAKMP State Diagram
图28:GSAKMP状态图
Table 28: GSAKMP States
______________________________________________________________________
Table 28: GSAKMP States
______________________________________________________________________
Idle : GSAKMP Application waiting for input
______________________________________________________________________
Idle : GSAKMP Application waiting for input
______________________________________________________________________
Wait for GC/KS Event : GC/KS up and running, waiting for events
______________________________________________________________________
Wait for GC/KS Event : GC/KS up and running, waiting for events
______________________________________________________________________
Wait for Response : GC/KS has sent Key Download,
from Key Download : waiting for response from GM
______________________________________________________________________
Wait for Response : GC/KS has sent Key Download,
from Key Download : waiting for response from GM
______________________________________________________________________
Wait for Group : GM in process of joining group
Membership :
______________________________________________________________________
Wait for Group : GM in process of joining group
Membership :
______________________________________________________________________
Wait for Group : GM has group key, waiting for
Membership Event : group management messages.
______________________________________________________________________
Wait for Group : GM has group key, waiting for
Membership Event : group management messages.
______________________________________________________________________
Table 29: State Transition Events
____________________________________________________________________
Table 29: State Transition Events
____________________________________________________________________
Transition 1 : Create group command
______________:_____________________________________________________
:
Transition 2 : Receive bad RTJ
: Receive valid command to change group membership
: Send Compromise message x times
: Member Deregistration
______________:_____________________________________________________
:
Transition 3 : Receive valid RTJ
______________:_____________________________________________________
:
Transition 4 : Timeout
: Receive Ack
: Receive Nack
______________:_____________________________________________________
:
Transition 5 : Delete group command
______________:_____________________________________________________
:
Transition 1a : Join group command
______________:_____________________________________________________
:
Transition 2a : Send Ack
______________:_____________________________________________________
:
Transition 3a : Receipt of group management messages
______________:_____________________________________________________
:
Transition 4a : Delete group command
: Deregistration command
______________:_____________________________________________________
:
Transition 5a : Time out
: Msg failure
: errors
:
____________________________________________________________________
Transition 1 : Create group command
______________:_____________________________________________________
:
Transition 2 : Receive bad RTJ
: Receive valid command to change group membership
: Send Compromise message x times
: Member Deregistration
______________:_____________________________________________________
:
Transition 3 : Receive valid RTJ
______________:_____________________________________________________
:
Transition 4 : Timeout
: Receive Ack
: Receive Nack
______________:_____________________________________________________
:
Transition 5 : Delete group command
______________:_____________________________________________________
:
Transition 1a : Join group command
______________:_____________________________________________________
:
Transition 2a : Send Ack
______________:_____________________________________________________
:
Transition 3a : Receipt of group management messages
______________:_____________________________________________________
:
Transition 4a : Delete group command
: Deregistration command
______________:_____________________________________________________
:
Transition 5a : Time out
: Msg failure
: errors
:
____________________________________________________________________
IANA has provided GSAKMP port number 3761 in both the UDP and TCP spaces. All implementations MUST use this port assignment in the appropriate manner.
IANA在UDP和TCP空间中都提供了GSAKMP端口号3761。所有实现都必须以适当的方式使用此端口分配。
The following registry entries have been created:
已创建以下注册表项：
GSAKMP Group Identification Types (Section 7.1.1) GSAKMP Payload Types (Section 7.1.1) GSAKMP Exchange Types (Section 7.1.1) GSAKMP Policy Token Types (Section 7.3.1) GSAKMP Key Download Data Item Types (Section 7.4.1) GSAKMP Cryptographic Key Types (Section 7.4.1.1) GSAKMP Rekey Event Types (Section 7.5.1) GSAKMP Identification Classification (Section 7.6.1) GSAKMP Identification Types (Section 7.6.1) GSAKMP Certificate Types (Section 7.7.1) GSAKMP Signature Types (Section 7.8.1) GSAKMP Notification Types (Section 7.9.1) GSAKMP Acknowledgement Types (Section 7.9.1.1) GSAKMP Mechanism Types (Section 7.9.1.3) GSAKMP Nonce Hash Types (Section 7.9.1.3) GSAKMP Key Creation Types (Section 7.11.1) GSAKMP Nonce Types (Section 7.12.1)
GSAKMP组标识类型（第7.1.1节）GSAKMP有效负载类型（第7.1.1节）GSAKMP交换类型（第7.1.1节）GSAKMP策略令牌类型（第7.3.1节）GSAKMP密钥下载数据项类型（第7.4.1节）GSAKMP加密密钥类型（第7.4.1.1节）GSAKMP重新密钥事件类型（第7.5.1节）GSAKMP标识分类（第7.6.1节）GSAKMP标识类型（第7.6.1节）GSAKMP证书类型（第7.7.1节）GSAKMP签名类型（第7.8.1节）GSAKMP通知类型（第7.9.1节）GSAKMP确认类型（第7.9.1.1节）GSAKMP机制类型（第7.9.1.3节）GSAKMP Nonce散列类型（第7.9.1.3节）GSAKMP密钥创建类型（第7.11.1节）GSAKMP当前类型（第7.12.1节）
Changes and additions to the following registries are by IETF Standards Action:
IETF标准行动将对以下注册表进行更改和添加：
GSAKMP Group Identification Types GSAKMP Payload Types GSAKMP Exchange Types GSAKMP Policy Token Types GSAKMP Key Download Data Item Types GSAKMP Rekey Event Types GSAKMP Identification Classification GSAKMP Notification Types GSAKMP Acknowledgement Types GSAKMP Mechanism Types GSAKMP Nonce Types
GSAKMP组标识类型GSAKMP有效负载类型GSAKMP交换类型GSAKMP策略令牌类型GSAKMP密钥下载数据项类型GSAKMP重新密钥事件类型GSAKMP标识分类GSAKMP通知类型GSAKMP确认类型GSAKMP机制类型GSAKMP Nonce类型
Changes and additions to the following registries are by Expert Review:
以下登记册的更改和增补由专家审查：
GSAKMP Cryptographic Key Types GSAKMP Identification Types GSAKMP Certificate Types GSAKMP Signature Types GSAKMP Nonce Hash Types GSAKMP Key Creation Types
GSAKMP加密密钥类型GSAKMP标识类型GSAKMP证书类型GSAKMP签名类型GSAKMP Nonce散列类型GSAKMP密钥创建类型
This document is the collaborative effort of many individuals. If there were no limit to the number of authors that could appear on an RFC, the following, in alphabetical order, would have been listed: Haitham S. Cruickshank of University of Surrey, Sunil Iyengar of University Of Surrey Gavin Kenny of LogicaCMG, Patrick McDaniel of AT&T Labs Research, and Angela Schuett of NSA.
本文件是许多个人共同努力的成果。如果对RFC上出现的作者的数量没有限制，以下按字母顺序列出：塞瑞大学的HithAM S.CurksHANK、塞瑞大学的Suni-Iyangar、Logic ACMG的加文肯尼、AT&T实验室研究的Patrick McDaniel和NSA的Angela Schuett。
The following individuals deserve recognition and thanks for their contributions, which have greatly improved this protocol: Eric Harder is an author to the Tunneled-GSAKMP, whose concepts are found in GSAKMP as well. Rod Fleischer, also a Tunneled-GSAKMP author, and Peter Lough were both instrumental in coding a prototype of the GSAKMP software and helped define many areas of the protocol that were vague at best. Andrew McFarland and Gregory Bergren provided critical analysis of early versions of the specification. Ran Canetti analyzed the security of the protocol and provided denial of service suggestions leading to optional "cookie protection".
以下个人的贡献值得认可和感谢，这些贡献极大地改进了本协议：Eric Harder是Tunneled GSAKMP的作者，其概念也可以在GSAKMP中找到。罗德·弗莱舍（Rod Fleischer），也是一位隧道式GSAKMP的作者，和彼得·洛夫（Peter Lough）都在编写GSAKMP软件原型方面发挥了重要作用，并帮助定义了协议中许多充其量含糊不清的领域。Andrew McFarland和Gregory Bergren对规范的早期版本进行了批判性分析。Ran Canetti分析了协议的安全性，并提供了拒绝服务建议，从而实现可选的“cookie保护”。
[DH77] Diffie, W., and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, June 1977.
[DH77]Diffie，W.和M.Hellman，“密码学的新方向”，IEEE信息论交易，1977年6月。
[FIPS186-2] NIST, "Digital Signature Standard", FIPS PUB 186-2, National Institute of Standards and Technology, U.S. Department of Commerce, January 2000.
[FIPS186-2]NIST，“数字签名标准”，FIPS PUB 186-2，美国商务部国家标准与技术研究所，2000年1月。
[FIPS196] "Entity Authentication Using Public Key Cryptography," Federal Information Processing Standards Publication 196, NIST, February 1997.
[FIPS196]“使用公钥加密的实体认证”，联邦信息处理标准出版物196，NIST，1997年2月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[RFC2627]Wallner，D.，Harder，E.，和R.Agee，“多播的密钥管理：问题和架构”，RFC 2627，1999年6月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
2002年4月，福特公司发布了《公共基础设施许可证》和《公共基础设施许可证撤销许可证》（RFC.3280），并于2002年4月发布。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514]Zeilenga，K.，Ed.“轻量级目录访问协议（LDAP）：可分辨名称的字符串表示”，RFC4514，2006年6月。
[RFC4534] Colegrove, A. and H. Harney, "Group Security Policy Token v1", RFC 4534, June 2006.
[RFC4534]Colegrove，A.和H.Harney，“集团安全策略令牌v1”，RFC 4534，2006年6月。
[BMS] Balenson, D., McGrew, D., and A. Sherman, "Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization", Work in Progress, February 1999.
[BMS]Balenson，D.，McGrew，D.，和A.Sherman，“大型动态组的密钥管理：单向函数树和摊销初始化”，正在进行的工作，1999年2月。
[HCM] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy in Secure Groups", Proceedings of Network and Distributed Systems Security 2001 Internet Society, San Diego, CA, February 2001.
[HCM]H.Harney，A.Colegrove，P.McDaniel，“安全团体的政策原则”，2001年网络和分布式系统安全会议录，加利福尼亚州圣地亚哥，2001年2月。
[HHMCD01] Hardjono, T., Harney, H., McDaniel, P., Colegrove, A., and P. Dinsmore, "Group Security Policy Token: Definition and Payloads", Work in Progress, August 2003.
[HHMDC01]Hardjono，T.，Harney，H.，McDaniel，P.，Colegrove，A.，和P.Dinsmore，“集团安全策略令牌：定义和有效负载”，正在进行的工作，2003年8月。
[RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC2093]Harney，H.和C.Muckenhirn，“组密钥管理协议（GKPP）规范”，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，“组密钥管理协议（GKPP）体系结构”，RFC 2094，1997年7月。
[RFC2408] Maughan D., Schertler M., Schneider M., and Turner J., "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, Proposed Standard, November 1998
[RFC2408]Maughan D.，Schertler M.，Schneider M.，和Turner J.，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，提议的标准，1998年11月
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[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月。
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, June 2006.
[RFC4523]Zeilenga，K.，“X.509证书的轻型目录访问协议（LDAP）模式定义”，RFC4523，2006年6月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[RFC3161]Adams，C.，Cain，P.，Pinkas，D.，和R.Zuccherato，“互联网X.509公钥基础设施时间戳协议（TSP）”，RFC3161，2001年8月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740]Hardjono，T.和B.Weis，“多播组安全架构”，RFC 3740，2004年3月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
This appendix will give an overview of LKH, define the values for fields within GSAKMP messages that are specific to LKH, and give an example of a Rekey Event Message using the LKH scheme.
本附录将概述LKH，定义特定于LKH的GSAKMP消息中的字段值，并给出使用LKH方案的密钥更新事件消息示例。
LKH provides a topology for handling key distribution for a group rekey. It rekeys a group based upon a tree structure and subgroup keys. In the LKH tree shown in Figure 29, members are represented by the leaf nodes on the tree, while intermediate tree nodes represent abstract key groups. A member will possess multiple keys: the group traffic protection key (GTPK), subgroup keys for every node on its path to the root of the tree, and a personal key. For example, the member labeled as #3 will have the GTPK, Key A, Key D, and Key 3.
LKH提供了一种拓扑结构，用于处理组密钥的密钥分发。它根据树结构和子组密钥为组重新设置密钥。在图29所示的LKH树中，成员由树上的叶节点表示，而中间树节点表示抽象密钥组。成员将拥有多个密钥：组流量保护密钥（GTPK）、指向树根的路径上每个节点的子组密钥以及个人密钥。例如，标记为#3的成员将具有GTPK、键A、键D和键3。
root
/ \
/ \
A B
/ \ / \
/ \ / \
C D E F
/ \ / \ / \ / \
/ \ / \ / \ / \
1 2 3 4 5 6 7 8
root
/ \
/ \
A B
/ \ / \
/ \ / \
C D E F
/ \ / \ / \ / \
/ \ / \ / \ / \
1 2 3 4 5 6 7 8
Figure 29: LKH Tree
图29:LKH树
This keying topology provides for a rapid rekey to all but a compromised member of the group. If Member 3 were compromised, the new GTPK (GTPK') would need to be distributed to the group under a key not possessed by Member 3. Additionally, new Keys A and D (Key A' and Key D') would also need to be securely distributed to the other members of those subtrees. Encrypting the GTPK' with Key B would securely distribute that key to Members 5, 6, 7, and 8. Key C can be used to encrypt both the GTPK' and Key A' for Members 1 and 2. Member 3's nearest neighbor, Member 4, can obtain GTPK', Key D', and Key A' encrypted under its personal key, Key 4. At the end of this process, the group is securely rekeyed with Member 3 fully excluded.
此密钥拓扑提供了对组中除受损成员以外的所有成员的快速重新密钥。如果成员3被泄露，新的GTPK（GTPK'）将需要以成员3不拥有的密钥分发给组。此外，还需要将新密钥A和D（密钥A'和密钥D'）安全地分发给这些子树的其他成员。使用密钥B加密GTPK'将安全地将该密钥分发给成员5、6、7和8。密钥C可用于加密成员1和2的GTPK'和密钥A'。成员3的最近邻居成员4可以获得在其个人密钥密钥4下加密的GTPK'，密钥D'和密钥A'。在该过程结束时，安全地重新键入组，成员3被完全排除。
When using LKH with GSAKMP, the following issues require attention:
将LKH与GSAKMP一起使用时，需要注意以下问题：
1. Rekey Version # - The Rekey Version # in the Rekey Array of the Key Download Payload MUST contain the value one (1).
1. 密钥下载有效负载的密钥数组中的密钥版本必须包含值1（1）。
2. Algorithm Version - The Algorithm Version in the Rekey Event Payload MUST contain the value one (1).
2. 算法版本-密钥更新事件有效负载中的算法版本必须包含值1（1）。
3. Degree of Tree - The LKH tree used can be of any degree; it need not be binary.
3. 树的阶数-使用的LKH树可以是任意阶数；它不必是二进制的。
4. Node Identification - Each node in the tree is treated as a KEK. A KEK is just a special key. As the rule stated for all keys in GSAKMP, the set of the KeyID and the KeyHandle MUST be unique. A suggestion on how to do this will be given in this section.
4. 节点标识-树中的每个节点都被视为KEK。桶只是一把特殊的钥匙。正如GSAKMP中所有密钥的规则所述，KeyID和KeyHandle的集合必须是唯一的。本节将给出如何实现这一点的建议。
5. Wrapping KeyID and Handle - This is the KeyID and Handle of the LKH node used to wrap/encrypt the data in a Rekey Event Data.
5. 包装KeyID和句柄-这是LKH节点的KeyID和句柄，用于包装/加密重密钥事件数据中的数据。
For the following discussion, refer to Figure 30.
关于以下讨论，请参考图30。
Key: o: a node in the LKH tree N: this line contains the KeyID node number L: this line contains the MemberID number for all leaves ONLY
Key:o:LKH树中的节点N：此行包含KeyID节点号L：此行仅包含所有叶的MemberID号
LEVEL
----
root o
N: / 1 \
/ \
1 o o
N: / 2 \ / 3 \
/ \ / \
2 o o o o
N: /4\ /5\ /6\ /7\
/ \ / \ / \ / \
3 o o o o o o o o
N: 8 9 10 11 12 13 14 15
L: 1 2 3 4 5 6 7 8
LEVEL
----
root o
N: / 1 \
/ \
1 o o
N: / 2 \ / 3 \
/ \ / \
2 o o o o
N: /4\ /5\ /6\ /7\
/ \ / \ / \ / \
3 o o o o o o o o
N: 8 9 10 11 12 13 14 15
L: 1 2 3 4 5 6 7 8
Figure 30: GSAKMP LKH Tree
图30:GSAKMP LKH树
To guarantee uniqueness of KeyID, the Rekey Controller SHOULD build a virtual tree and label the KeyID of each node, doing a breadth-first search of a fully populated tree regardless of whether or not the tree is actually full. For simplicity of this example, the root of the tree was given KeyID value of one (1). These KeyID values will be static throughout the life of this tree. Additionally, the rekey arrays distributed to GMs requires a MemberID value associated with them to be distributed with the KeyDownload Payload. These MemberID values MUST be unique. Therefore, the set associated with each leaf node (the nodes from that leaf back to the root) are given a MemberID. In this example, the leftmost leaf node is given MemberID value of one (1). These 2 sets of values, the KeyIDs (represented on lines N) and the MemberIDs (represented on line L), will give sufficient information in the KeyDownload and RekeyEvent Payloads to disseminate information. The KeyHandle associated with these keys is regenerated each time the key is replaced in the tree due to compromise.
为了保证KeyID的唯一性，Rekey控制器应该构建一个虚拟树并标记每个节点的KeyID，对完全填充的树进行广度优先搜索，而不管树是否实际已满。为了简化本例，树的根的KeyID值为1。这些KeyID值在该树的整个生命周期内都是静态的。此外，分发给GMs的密钥更新阵列需要与之关联的MemberID值与密钥下载负载一起分发。这些MemberID值必须是唯一的。因此，与每个叶节点（从该叶返回到根的节点）关联的集合被赋予一个MemberID。在本例中，最左边的叶节点的MemberID值为1。这两组值，即KeyID（在第N行中表示）和MemberID（在第L行中表示），将在KeyDownload和RekeyEvent有效负载中提供足够的信息，以传播信息。与这些密钥相关联的KeyHandle将在每次由于泄露而在树中替换密钥时重新生成。
Definition of values: 0xLLLL - length value 0xHHHHHHH# - handle value YYYYMMDDHHMMSSZ - time value
值的定义：0xLLLL-长度值0xHHHHHHHH#-句柄值YYYYMMDDHHMMSSZ-时间值
This section will give an example of the data for the Key Download payload. The GM will be given MemberID 1 and its associated keys. The data shown will be subsequent to the Generic Payload Header.
本节将给出密钥下载有效负载的数据示例。GM将获得MemberID 1及其相关密钥。显示的数据将在通用有效负载标题之后。
| GTPK | MemberID 1 | KeyID 2 | KeyID 4 | KeyID 8
|GTPK |成员ID 1 |密钥ID 2 |密钥ID 4 |密钥ID 8
Number of Items - 0x0002
Item #1:
Key Download Data Item Type - 0x00 (GTPK)
Key Download Data Item Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - KEY1
Key Handle - 0xHHHHHHH0
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Item #2:
Key Download Data Item Type - 0x01 (Rekey - LKH)
Key Download Data Item Length - 0xLLLL
Rekey Version Number - 0x01
Member ID - 0x00000001
Number of Items - 0x0002
Item #1:
Key Download Data Item Type - 0x00 (GTPK)
Key Download Data Item Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - KEY1
Key Handle - 0xHHHHHHH0
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Item #2:
Key Download Data Item Type - 0x01 (Rekey - LKH)
Key Download Data Item Length - 0xLLLL
Rekey Version Number - 0x01
Member ID - 0x00000001
Number of KEK Keys - 0x0003
KEK #1:
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000002
Key Handle - 0xHHHHHHH2
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
KEK #2:
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000004
Key Handle - 0xHHHHHHH4
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
KEK #3:
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000008
Key Handle - 0xHHHHHHH8
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Number of KEK Keys - 0x0003
KEK #1:
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000002
Key Handle - 0xHHHHHHH2
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
KEK #2:
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000004
Key Handle - 0xHHHHHHH4
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
KEK #3:
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000008
Key Handle - 0xHHHHHHH8
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
This section will give an example of the data for the Rekey Event payload. The GM with MemberID 6 will be keyed out of the group. The data shown will be subsequent to the Generic Payload Header.
本节将给出重设密钥事件有效负载的数据示例。成员ID为6的GM将被键入组外。显示的数据将在通用有效负载标题之后。
| Rekey Event Type | GroupID | Date/Time | Rekey Type | Algorithm Ver | # of Packets | { (GTPK)2, (GTPK, 3', 6')12, (GTPK, 3')7 }
|重新设置事件类型| GroupID |日期/时间|重新设置类型|算法版本|数据包{（GTPK）2，（GTPK，3'，6'）12，（GTPK，3'）7}
This data shows that three packets are being transmitted. Read each packet as:
该数据显示正在传输三个数据包。将每个数据包读为：
a) GTPK wrapped in LKH KeyID 2 b) GTPK, LKH KeyIDs 3' & 6', all wrapped in LKH KeyID 12 c) GTPK and LKH KeyID 3', all wrapped in LKH KeyID 7
a) GTPK包裹在LKH密钥ID 2中b）GTPK，LKH密钥ID 3'和6'，均包裹在LKH密钥ID 12c）GTPK和LKH密钥ID 3'，均包裹在LKH密钥ID 7中
NOTE: Although in this example multiple keys are encrypted under one key, alternative pairings are legal (e.g., (GTPK)2, (GTPK)3', (3')6', (3')7', (6')12).
注意：尽管在本例中，多个密钥在一个密钥下加密，但可选配对是合法的（例如，（GTPK）2，（GTPK）3’，（3’）6’，（3’）7’，（6’）12）。
We will show the format for all header data and packet (b).
我们将显示所有报头数据和数据包（b）的格式。
Rekey Event Type - 0x01 (GSAKMP`LKH)
GroupID - 0xAABBCCDD
0x12345678
Time/Date Stamp - YYYYMMDDHHMMSSZ
Rekey Event Type - 0x01 (GSAKMP`LKH)
Algorithm Vers - 0x01
# of RkyEvt Pkts - 0x0003
For Packet (b):
Packet Length - 0xLLLL
Wrapping KeyID - 0x000C
Wrapping Key Handle - 0xHHHHHHHD
# of Key Packages - 0x0003
Key Package 1:
Key Pkg Type - 0x00 (GTPK)
Pack Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - KEY1
Key Handle - 0xHHHHHHH0
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Key Package 2:
Key Pkg Type - 0x01 (Rekey - LKH)
Pack Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000003
Key Handle - 0xHHHHHHH3
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Key Package 3:
Key Pkg Type - 0x01 (Rekey - LKH)
Pack Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000006
Key Handle - 0xHHHHHHH6
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Rekey Event Type - 0x01 (GSAKMP`LKH)
GroupID - 0xAABBCCDD
0x12345678
Time/Date Stamp - YYYYMMDDHHMMSSZ
Rekey Event Type - 0x01 (GSAKMP`LKH)
Algorithm Vers - 0x01
# of RkyEvt Pkts - 0x0003
For Packet (b):
Packet Length - 0xLLLL
Wrapping KeyID - 0x000C
Wrapping Key Handle - 0xHHHHHHHD
# of Key Packages - 0x0003
Key Package 1:
Key Pkg Type - 0x00 (GTPK)
Pack Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - KEY1
Key Handle - 0xHHHHHHH0
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Key Package 2:
Key Pkg Type - 0x01 (Rekey - LKH)
Pack Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000003
Key Handle - 0xHHHHHHH3
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Key Package 3:
Key Pkg Type - 0x01 (Rekey - LKH)
Pack Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000006
Key Handle - 0xHHHHHHH6
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Authors' Addresses
作者地址
Hugh Harney (point-of-contact) SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
Hugh Harney（联络点）斯巴达公司，地址：马里兰州哥伦比亚塞缪尔莫尔斯大道7110号，邮编：21046
Phone: (443) 430-8032 Fax: (443) 430-8181 EMail: hh@sparta.com
电话：（443）430-8032传真：（443）430-8181电子邮件：hh@sparta.com
Uri Meth SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
Uri Meth SPARTA，Inc.美国马里兰州哥伦比亚塞缪尔莫尔斯大道7110号，邮编：21046
Phone: (443) 430-8058 Fax: (443) 430-8207 EMail: umeth@sparta.com
电话：（443）430-8058传真：（443）430-8207电子邮件：umeth@sparta.com
Andrea Colegrove SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
马里兰州哥伦比亚塞缪尔·莫尔斯大道7110号安德里亚·科尔格罗夫斯巴达公司，邮编：21046
Phone: (443) 430-8014 Fax: (443) 430-8163 EMail: acc@sparta.com
电话：（443）430-8014传真：（443）430-8163电子邮件：acc@sparta.com
George Gross IdentAware Security 82 Old Mountain Road Lebanon, NJ 08833
乔治格罗斯，新泽西州黎巴嫩老山路82号，邮编08833
Phone: (908) 268-1629 EMail: gmgross@identaware.com
电话：（908）268-1629电子邮件：gmgross@identaware.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。