Network Working Group M. Baugher
Request for Comments: 4046 Cisco
Category: Informational R. Canetti
IBM
L. Dondeti
Qualcomm
F. Lindholm
Ericsson
April 2005
Network Working Group M. Baugher
Request for Comments: 4046 Cisco
Category: Informational R. Canetti
IBM
L. Dondeti
Qualcomm
F. Lindholm
Ericsson
April 2005
Multicast Security (MSEC) Group Key Management Architecture
多播安全（MSEC）组密钥管理体系结构
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document defines the common architecture for Multicast Security (MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication.
本文档定义了多播安全（MSEC）密钥管理协议的通用体系结构，以支持各种应用程序、传输和网络层安全协议。它还定义了组安全关联（GSA），并描述了帮助建立GSA的密钥管理协议。本文档中描述的框架和指导原则允许对组密钥管理协议进行模块化和灵活的设计，以满足各种不同的应用需求。MSEC密钥管理协议可用于促进安全的一对多、多对多或一对一通信。
Table of Contents
目录
1. Introduction: Purpose of this Document ..........................2
2. Requirements of a Group Key Management Protocol .................4
3. Overall Design of Group Key Management Architecture .............6
3.1. Overview ...................................................6
3.2. Detailed Description of the GKM Architecture ...............8
3.3. Properties of the Design ..................................11
3.4. Group Key Management Block Diagram ........................11
4. Registration Protocol ..........................................13
4.1. Registration Protocol via Piggybacking or Protocol Reuse ..13
4.2. Properties of Alternative Registration Exchange Types .....14
1. Introduction: Purpose of this Document ..........................2
2. Requirements of a Group Key Management Protocol .................4
3. Overall Design of Group Key Management Architecture .............6
3.1. Overview ...................................................6
3.2. Detailed Description of the GKM Architecture ...............8
3.3. Properties of the Design ..................................11
3.4. Group Key Management Block Diagram ........................11
4. Registration Protocol ..........................................13
4.1. Registration Protocol via Piggybacking or Protocol Reuse ..13
4.2. Properties of Alternative Registration Exchange Types .....14
4.3. Infrastructure for Alternative Registration
Exchange Types ............................................15
4.4. De-registration Exchange ..................................16
5. Rekey Protocol .................................................16
5.1. Goals of the Rekey Protocol ...............................17
5.2. Rekey Message Transport and Protection ....................17
5.3. Reliable Transport of Rekey Messages ......................18
5.4. State-of-the-art on Reliable Multicast Infrastructure .....20
5.5. Implosion .................................................21
5.6. Incorporating Group Key Management Algorithms .............22
5.7. Stateless, Stateful, and Self-healing Rekeying
Algorithms ................................................22
5.8. Interoperability of a GKMA ................................23
6. Group Security Association .....................................24
6.1. Group Policy ..............................................24
6.2. Contents of the Rekey SA ..................................25
6.2.1. Rekey SA Policy ....................................26
6.2.2. Group Identity .....................................27
6.2.3. KEKs ...............................................27
6.2.4. Authentication Key .................................27
6.2.5. Replay Protection ..................................27
6.2.6. Security Parameter Index (SPI) .....................27
6.3. Contents of the Data SA ...................................27
6.3.1. Group Identity .....................................28
6.3.2. Source Identity ....................................28
6.3.3. Traffic Protection Keys ............................28
6.3.4. Data Authentication Keys ...........................28
6.3.5. Sequence Numbers ...................................28
6.3.6. Security Parameter Index (SPI) .....................28
6.3.7. Data SA Policy .....................................28
7. Scalability Considerations .....................................29
8. Security Considerations ........................................31
9. Acknowledgments ................................................32
10. Informative References ........................................33
4.3. Infrastructure for Alternative Registration
Exchange Types ............................................15
4.4. De-registration Exchange ..................................16
5. Rekey Protocol .................................................16
5.1. Goals of the Rekey Protocol ...............................17
5.2. Rekey Message Transport and Protection ....................17
5.3. Reliable Transport of Rekey Messages ......................18
5.4. State-of-the-art on Reliable Multicast Infrastructure .....20
5.5. Implosion .................................................21
5.6. Incorporating Group Key Management Algorithms .............22
5.7. Stateless, Stateful, and Self-healing Rekeying
Algorithms ................................................22
5.8. Interoperability of a GKMA ................................23
6. Group Security Association .....................................24
6.1. Group Policy ..............................................24
6.2. Contents of the Rekey SA ..................................25
6.2.1. Rekey SA Policy ....................................26
6.2.2. Group Identity .....................................27
6.2.3. KEKs ...............................................27
6.2.4. Authentication Key .................................27
6.2.5. Replay Protection ..................................27
6.2.6. Security Parameter Index (SPI) .....................27
6.3. Contents of the Data SA ...................................27
6.3.1. Group Identity .....................................28
6.3.2. Source Identity ....................................28
6.3.3. Traffic Protection Keys ............................28
6.3.4. Data Authentication Keys ...........................28
6.3.5. Sequence Numbers ...................................28
6.3.6. Security Parameter Index (SPI) .....................28
6.3.7. Data SA Policy .....................................28
7. Scalability Considerations .....................................29
8. Security Considerations ........................................31
9. Acknowledgments ................................................32
10. Informative References ........................................33
This document defines a common architecture for Multicast Security (MSEC) key management protocols to support a variety of application-, transport-, and network-layer security protocols. It also defines the group security association (GSA) and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication.
本文档定义了多播安全（MSEC）密钥管理协议的通用体系结构，以支持各种应用层、传输层和网络层安全协议。它还定义了组安全关联（GSA），并描述了有助于建立GSA的密钥管理协议。本文档中描述的框架和指导原则允许对组密钥管理协议进行模块化和灵活的设计，以满足各种不同的应用需求。MSEC密钥管理协议可用于促进安全的一对多、多对多或一对一通信。
Group and multicast applications in IP networks have diverse security requirements [TAXONOMY]. Their key management requirements, briefly reviewed in Section 2.0, include support for internetwork-, transport- and application-layer security protocols. Some applications achieve simpler operation by running key management messaging over a pre-established secure channel (e.g., TLS or IPsec). Other security protocols benefit from a key management protocol that can run over an already-deployed session initiation or management protocol (e.g., SIP or RTSP). Finally, some benefit from a lightweight key management protocol that requires few round trips. For all these reasons, application-, transport-, and IP-layer data security protocols (e.g., SRTP [RFC3711] and IPsec [RFC2401]) benefit from different group key management systems. This document defines a common architecture and design for all group key management (GKM) protocols.
IP网络中的组和多播应用程序具有不同的安全要求[分类法]。第2.0节简要回顾了它们的关键管理需求，包括对网络、传输和应用层安全协议的支持。一些应用程序通过在预先建立的安全通道（例如TLS或IPsec）上运行密钥管理消息传递来实现更简单的操作。其他安全协议受益于密钥管理协议，该协议可在已部署的会话启动或管理协议（例如SIP或RTSP）上运行。最后，轻量级密钥管理协议可以带来一些好处，它只需要很少的往返。由于所有这些原因，应用层、传输层和IP层数据安全协议（例如，SRTP[RFC3711]和IPsec[RFC2401]）受益于不同的组密钥管理系统。本文档定义了所有组密钥管理（GKM）协议的通用体系结构和设计。
This common architecture for group key management is called the MSEC group key management architecture. It is based on the group control or key server model developed in GKMP [RFC2094] and assumed by group key management algorithms such as LKH [RFC2627], OFT [OFT], and MARKS [MARKS]. There are other approaches that are not considered in this architecture, such as the highly distributed Cliques group key management protocol [CLIQUES] or broadcast key management schemes [FN93,Wool]. MSEC key management may in fact be complementary to other group key management designs, but the integration of MSEC group key management with Cliques, broadcast key management, or other group key systems is not considered in this document.
这种用于组密钥管理的通用体系结构称为MSEC组密钥管理体系结构。它基于GKP[RFC2094]中开发的组控制或密钥服务器模型，并由组密钥管理算法（如LKH[RFC2627]、OFT[OFT]和MARKS[MARKS]假设。该体系结构中没有考虑其他方法，例如高度分布式的集团密钥管理协议[Cliques]或广播密钥管理方案[FN93，Wool]。MSEC密钥管理实际上可能是对其他组密钥管理设计的补充，但本文件不考虑MSEC组密钥管理与集团、广播密钥管理或其他组密钥系统的集成。
Key management protocols are difficult to design and validate. The common architecture described in this document eases this burden by defining common abstractions and an overall design that can be specialized for different uses.
密钥管理协议很难设计和验证。本文档中描述的通用架构通过定义通用抽象和可专门用于不同用途的总体设计，减轻了这一负担。
This document builds on and extends the Group Key Management Building Block document of the IRTF SMuG research group [GKMBB] and is part of the MSEC document roadmap. The MSEC architecture [MSEC-Arch] defines a complete multicast or group security architecture, of which key management is a component.
本文件建立并扩展了IRTF SMuG研究小组[GKBB]的集团密钥管理构建块文件，是MSEC文件路线图的一部分。MSEC架构[MSEC Arch]定义了一个完整的多播或组安全架构，密钥管理是其中的一个组件。
The rest of this document is organized as follows. Section 2 discusses the security, performance and architectural requirements for a group key management protocol. Section 3 presents the overall architectural design principles. Section 4 describes the registration protocol in detail, and Section 5 does the same for rekey protocol. Section 6 considers the interface to the Group Security Association (GSA). Section 7 reviews the scalability issues for group key management protocols and Section 8 discusses security considerations.
本文件其余部分的组织如下。第2节讨论了组密钥管理协议的安全性、性能和体系结构要求。第3节介绍了总体建筑设计原则。第4节详细描述了注册协议，第5节对重新密钥协议也做了同样的描述。第6节考虑与集团安全协会（GSA）的接口。第7节回顾了组密钥管理协议的可伸缩性问题，第8节讨论了安全注意事项。
A group key management (GKM) protocol supports protected communication between members of a secure group. A secure group is a collection of principals, called members, who may be senders, receivers, or both receivers and senders to other members of the group. Group membership may vary over time. A group key management protocol helps to ensure that only members of a secure group can gain access to group data (by gaining access to group keys) and can authenticate group data. The goal of a group key management protocol is to provide legitimate group members with the up-to-date cryptographic state they need for secrecy and authentication.
组密钥管理（GKM）协议支持安全组成员之间的受保护通信。安全组是称为成员的主体的集合，这些主体可以是组中其他成员的发送者、接收者或接收者和发送者。团体成员资格可能随时间而变化。组密钥管理协议有助于确保只有安全组的成员才能访问组数据（通过访问组密钥）并对组数据进行身份验证。组密钥管理协议的目标是为合法组成员提供他们进行保密和身份验证所需的最新加密状态。
Multicast applications, such as video broadcast and multicast file transfer, typically have the following key management requirements (see also [TAXONOMY]). Note that the list is neither applicable to all applications nor exhaustive.
多播应用程序，如视频广播和多播文件传输，通常具有以下密钥管理要求（另请参见[分类]）。请注意，该列表既不适用于所有应用程序，也不详尽。
1. Group members receive security associations that include encryption keys, authentication/integrity keys, cryptographic policy that describes the keys, and attributes such as an index for referencing the security association (SA) or particular objects contained in the SA.
1. 组成员接收安全关联，其中包括加密密钥、身份验证/完整性密钥、描述密钥的加密策略，以及用于引用安全关联（SA）或SA中包含的特定对象的索引等属性。
2. In addition to the policy associated with group keys, the group owner or the Group Controller and Key Server (GCKS) may define and enforce group membership, key management, data security, and other policies that may or may not be communicated to the entire membership.
2. 除了与组密钥相关联的策略外，组所有者或组控制器和密钥服务器（GCKS）还可以定义和实施组成员资格、密钥管理、数据安全以及可能或可能不会传达给整个成员资格的其他策略。
3. Keys will have a pre-determined lifetime and may be periodically refreshed.
3. 密钥将具有预先确定的生存期，并且可以定期刷新。
4. Key material should be delivered securely to members of the group so that they are secret, integrity-protected and verifiably obtained from an authorized source.
4. 关键材料应安全交付给集团成员，以确保其保密、完整性得到保护，并可从授权来源获得。
5. The key management protocol should be secure against replay attacks and Denial of Service(DoS) attacks (see the Security Considerations section of this memo).
5. 密钥管理协议应能防止重播攻击和拒绝服务（DoS）攻击（请参阅本备忘录的安全注意事项部分）。
6. The protocol should facilitate addition and removal of group members. Members who are added may optionally be denied access to the key material used before they joined the group, and removed members should lose access to the key material following their departure.
6. 协议应便于添加和删除组成员。被添加的成员可能会被拒绝访问在加入组之前使用的关键材料，而被删除的成员在离开后将失去对关键材料的访问权限。
7. The protocol should support a scalable group rekey operation without unicast exchanges between members and a Group Controller and Key Server (GCKS), to avoid overwhelming a GCKS managing a large group.
7. 该协议应支持可扩展的组密钥重新分配操作，而无需在成员与组控制器和密钥服务器（GCKS）之间进行单播交换，以避免使管理大型组的GCKS不知所措。
8. The protocol should be compatible with the infrastructure and performance needs of the data security application, such as the IPsec security protocols AH and ESP, and/or application layer security protocols such as SRTP [RFC3711].
8. 该协议应与数据安全应用程序（如IPsec安全协议AH和ESP）和/或应用层安全协议（如SRTP[RFC3711]）的基础设施和性能需求兼容。
9. The key management protocol should offer a framework for replacing or renewing transforms, authorization infrastructure, and authentication systems.
9. 密钥管理协议应该为替换或更新转换、授权基础设施和身份验证系统提供一个框架。
10. The key management protocol should be secure against collusion among excluded members and non-members. Specifically, collusion must not result in attackers gaining any additional group secrets than each of them individually are privy to. In other words, combining the knowledge of the colluding entities must not result in revealing additional group secrets.
10. 密钥管理协议应能防止被排除成员和非成员之间的共谋。具体而言，共谋不得导致攻击者获得他们各自不知道的任何其他组机密。换句话说，结合共谋实体的知识不得导致泄露额外的集团机密。
11. The key management protocol should provide a mechanism to securely recover from a compromise of some or all of the key material.
11. 密钥管理协议应提供一种机制，用于从部分或全部密钥材料的泄露中安全恢复。
12. The key management protocol may need to address real-world deployment issues such as NAT-traversal and interfacing with legacy authentication mechanisms.
12. 密钥管理协议可能需要解决实际部署问题，例如NAT遍历和与遗留身份验证机制的接口。
In contrast to typical unicast key and SA negotiation protocols such as TLS and IKE, multicast group key management protocols provide SA and key download capability. This feature may be useful for point-to-point as well as multicast communication, so that a group key management protocol may be useful for unicast applications. Group key management protocols may be used for protecting multicast or unicast communications between members of a secure group. Secure sub-group communication is also plausible using the group SA.
与典型的单播密钥和SA协商协议（如TLS和IKE）不同，多播组密钥管理协议提供SA和密钥下载功能。该特性可用于点到点以及多播通信，因此组密钥管理协议可用于单播应用。组密钥管理协议可用于保护安全组成员之间的多播或单播通信。使用组SA进行安全子组通信也是可行的。
There are other requirements for small group operation with many all members as potential senders. In this case, the group setup time may need to be optimized to support a small, highly interactive group environment [RFC2627].
对于将许多所有成员作为潜在发送者的小团体操作，还有其他要求。在这种情况下，可能需要优化组设置时间，以支持小型、高度交互的组环境[RFC2627]。
The current key management architecture covers secure communication in large single-sender groups, such as source-specific multicast groups. Scalable operation to a range of group sizes is also a desirable feature, and a better group key management protocol will support large, single-sender groups as well as groups that have many
当前的密钥管理体系结构涵盖了大型单发送方组（如特定于源的多播组）中的安全通信。可扩展到一系列组大小的操作也是一个可取的特性，更好的组密钥管理协议将支持大型、单发送方组以及具有多个组的组
senders. It may be that no single key management protocol can satisfy the scalability requirements of all group-security applications.
寄件人。可能没有一个单一的密钥管理协议能够满足所有组安全应用程序的可伸缩性要求。
It is useful to emphasize two non-requirements: technical protection measures (TPM) [TPM] and broadcast key management. TPM are used for such things as copy protection by preventing the device user from getting easy access to the group keys. There is no reason why a group key management protocol cannot be used in an environment where the keys are kept in a tamper-resistant store, using various types of hardware or software to implement TPM. For simplicity, however, the MSEC key management architecture described in this document does not consider design for technical protection.
强调两个非需求是有用的：技术保护措施（TPM）[TPM]和广播密钥管理。TPM通过阻止设备用户轻松访问组密钥，用于复制保护等。没有理由不能在密钥保存在防篡改存储中的环境中使用组密钥管理协议，使用各种类型的硬件或软件来实现TPM。然而，为了简单起见，本文档中描述的MSEC密钥管理架构不考虑技术保护的设计。
The second non-requirement is broadcast key management when there is no back channel [FN93,JKKV94] or for a non-networked device such as a digital videodisc player. We assume IP network operation with two-way communication, however asymmetric, and authenticated key-exchange procedures that can be used for member registration. Broadcast applications may use a one-way Internet group key management protocol message and a one-way rekey message, as described below.
第二个非要求是当没有反向通道[FN93，JKKV94]或对于非网络设备（如数字视频光盘播放器）时的广播密钥管理。我们假设IP网络运行具有双向通信，但是不对称，并且可以用于成员注册的经过身份验证的密钥交换过程。广播应用程序可以使用单向因特网组密钥管理协议消息和单向重新密钥消息，如下所述。
The overall group key management architecture is based upon a group controller model [RFC2093,RFC2094,RFC2627,OFT,GSAKMP,RFC3547] with a single group owner as the root-of-trust. The group owner designates a group controller for member registration and GSA rekeying.
整个组密钥管理体系结构基于组控制器模型[RFC2093、RFC2094、RFC2627、OFT、GSAKMP、RFC3547]，其中单个组所有者作为信任根。组所有者指定一个组控制器用于成员注册和GSA密钥更新。
The main goal of a group key management protocol is to securely provide group members with an up-to-date security association (SA), which contains the needed information for securing group communication (i.e., the group data). We call this SA the Data SA. In order to obtain this goal, the group key management architecture defines the following protocols.
组密钥管理协议的主要目标是为组成员安全地提供最新的安全关联（SA），其中包含保护组通信所需的信息（即组数据）。我们称之为数据SA。为了实现这一目标，组密钥管理体系结构定义了以下协议。
(1) Registration Protocol
(1) 注册协议
This is a unicast protocol between the Group Controller and Key Server (GCKS) and a joining group member. In this protocol, the GCKS and joining member mutually authenticate each other. If the authentication succeeds and the GCKS finds that the joining member is authorized, then the GCKS supplies the joining member with the following information:
这是组控制器和密钥服务器（GCKS）与加入组成员之间的单播协议。在该协议中，GCK和加入成员相互认证。如果认证成功且GCKS发现加入成员已获得授权，则GCKS向加入成员提供以下信息：
(a) Sufficient information to initialize the Data SA within the joining member. This information is given only if the group security policy calls for initializing the Data SA at registration, instead of, or in addition to, as part of the rekey protocol.
(a) 足够的信息来初始化加入成员内的数据SA。仅当组安全策略要求在注册时初始化数据SA，而不是作为密钥更新协议的一部分，或者作为密钥更新协议的一部分，才会提供此信息。
(b) Sufficient information to initialize a Rekey SA within the joining member (see more details about this SA below). This information is given if the group security policy calls for a rekey protocol.
(b) 足够的信息来初始化加入成员内的重新密钥SA（请参阅下面有关此SA的更多详细信息）。如果组安全策略要求重新密钥协议，则会提供此信息。
The registration protocol must ensure that the transfer of information from GCKS to member is done in an authenticated and confidential manner over a security association. We call this SA the Registration SA. A complementary de-registration protocol serves to explicitly remove Registration SA state. Members may choose to delete Registration SA state.
注册协议必须确保通过安全协会以经认证和保密的方式将信息从GCKS传输给会员。我们称之为注册SA。一个补充的取消注册协议用于在一个状态下明确删除注册。成员可以选择删除在南非的注册。
(2) Rekey Protocol
(2) 密钥更新协议
A GCKS may periodically update or change the Data SA, by sending rekey information to the group members. Rekey messages may result from group membership changes, from changes in group security policy, from the creation of new traffic-protection keys (TPKs, see next section) for the particular group, or from key expiration. Rekey messages are protected by the Rekey SA, which is initialized in the registration protocol. They contain information for updating the Rekey SA and/or the Data SA and can be sent via multicast to group members or via unicast from the GCKS to a particular group member.
GCKS可以通过向组成员发送密钥更新信息，定期更新或更改数据SA。重新设置密钥消息可能来自组成员身份更改、组安全策略更改、为特定组创建新流量保护密钥（TPK，请参阅下一节）或密钥过期。重设密钥消息由重设密钥SA保护，该SA在注册协议中初始化。它们包含更新密钥SA和/或数据SA的信息，可通过多播发送给组成员，或通过单播从GCK发送给特定组成员。
Note that there are other means for managing (e.g., expiring or refreshing) the Data SA without interaction between the GCKS and the members. For example in MARKS [MARKS], the GCKS pre-determines TPKs for different periods in the lifetime of the secure group and distributes keys to members based on their membership periods. Alternative schemes such as the GCKS disbanding the secure group and starting a new group with a new Data SA are also possible, although this is typically limited to small groups.
请注意，还有其他方法用于管理（例如，过期或刷新）数据SA，而无需GCK和成员之间的交互。例如，在MARKS[MARKS]中，gck预先确定安全组生命周期中不同时期的tpk，并根据成员的成员期向成员分发密钥。也可以采用其他方案，如GCK解散安全组并使用新数据SA启动新组，尽管这通常仅限于小组。
Rekey messages are authenticated using one of the two following options:
使用以下两个选项之一对重设密钥消息进行身份验证：
(1) Using source authentication [TAXONOMY], that is, enabling each group member to verify that a rekey message originates with the GCKS and none other.
(1) 使用源身份验证[TAXONOMY]，也就是说，允许每个组成员验证重新密钥消息是否源自GCK而非其他。
(2) Using only group-based authentication with a symmetric key. Members can only be assured that the rekey messages originated within the group. Therefore, this is applicable only when all members of the group are trusted not to impersonate the GCKS. Group authentication for rekey messages is typically used when public-key cryptography is not suitable for the particular group.
(2) 仅使用具有对称密钥的基于组的身份验证。只能向成员保证，重新设置密钥的消息源于组内。因此，这仅在信任组的所有成员不模拟GCK时适用。当公钥加密不适用于特定组时，通常使用重密钥消息的组身份验证。
The rekey protocol ensures that all members receive the rekey information in a timely manner. In addition, the rekey protocol specifies mechanisms for the parties to contact the GCKS and re-synch if their keys expired and an updated key has not been received. The rekey protocol for large-scale groups offers mechanisms to avoid implosion problems and to ensure reliability in its delivery of keying material.
密钥更新协议确保所有成员及时收到密钥更新信息。此外，重新密钥协议规定了当双方的密钥过期且未收到更新密钥时，双方联系GCK并重新同步的机制。针对大型组的重新密钥协议提供了避免内爆问题的机制，并确保密钥材料交付的可靠性。
Although the Rekey SA is established by the registration protocol, it is updated using a rekey protocol. When a member leaves the group, it destroys its local copy of the GSA. Using a de-registration message may be an efficient way for a member to inform the GCKS that it has destroyed, or is about to destroy, the SAs. Such a message may prompt the GCKS to cryptographically remove the member from the group (i.e., to prevent the member from having access to future group communication). In large-scale multicast applications, however, de-registration can potentially cause implosion at the GCKS.
尽管通过注册协议建立了密钥更新SA，但它使用密钥更新协议进行更新。当成员离开组时，它将销毁其GSA的本地副本。使用注销消息可能是成员通知GCK其已销毁或即将销毁SAs的有效方式。此类消息可提示GCK以加密方式将该成员从组中移除（即，防止该成员访问未来的组通信）。然而，在大规模多播应用程序中，取消注册可能会导致GCK内爆。
Figure 1 depicts the overall design of a GKM protocol. Each group member, sender or receiver, uses the registration protocol to get authorized and authenticated access to a particular Group, its policies, and its keys. The two types of group keys are the key encryption keys (KEKs) and the traffic encryption keys (TEKs). For group authentication of rekey messages or data, key integrity or traffic integrity keys may be used, as well. We use the term protection keys to refer to both integrity and encryption keys. For example, the term traffic protection key (TPK) is used to denote the combination of a TEK and a traffic integrity key, or the key material used to generate them.
图1描述了GKM协议的总体设计。每个组成员（发送方或接收方）使用注册协议获得对特定组、其策略和密钥的授权和身份验证访问。这两种类型的组密钥是密钥加密密钥（KEK）和流量加密密钥（TEK）。对于密钥更新消息或数据的组认证，也可以使用密钥完整性或流量完整性密钥。我们使用术语保护密钥来指完整性密钥和加密密钥。例如，术语流量保护密钥（TPK）用于表示TEK和流量完整性密钥的组合，或用于生成它们的密钥材料。
The KEK may be a single key that protects the rekey message, typically containing a new Rekey SA (containing a KEK) and/or Data SA (containing a TPK/TEK). A Rekey SA may also contain a vector of keys that are part of a group key membership algorithm [RFC2627,OFT,TAXONOMY,SD1,SD2]. The data security protocol uses TPKs to protect streams, files, or other data sent and received by
KEK可以是保护密钥更新消息的单个密钥，通常包含新的密钥SA（包含KEK）和/或数据SA（包含TPK/TEK）。密钥更新SA还可以包含作为组密钥成员算法一部分的密钥向量[RFC2627，OFT，TAXONOMY，SD1，SD2]。数据安全协议使用TPK保护用户发送和接收的流、文件或其他数据
the data security protocol. Thus the registration protocol and/or the rekey protocol establish the KEK(s) and/or the TPKs.
数据安全协议。因此，注册协议和/或重新密钥协议建立KEK和/或tpk。
+------------------------------------------------------------------+
| +-----------------+ +-----------------+ |
| | POLICY | | AUTHORIZATION | |
| | INFRASTRUCTURE | | INFRASTRUCTURE | |
| +-----------------+ +-----------------+ |
| ^ ^ |
| | | |
| v v |
| +--------------------------------------------------------------+ |
| | | |
| | +--------------------+ | |
| | +------>| GCKS |<------+ | |
| | | +--------------------+ | | |
| | REGISTRATION or | REGISTRATION or | |
| | DE-REGISTRATION | DE-REGISTRATION | |
| | PROTOCOL | PROTOCOL | |
| | | | | | |
| | v REKEY v | |
| | +-----------------+ PROTOCOL +-----------------+ | |
| | | | (OPTIONAL) | | | |
| | | SENDER(S) |<-------+-------->| RECEIVER(S) | | |
| | | | | | | |
| | +-----------------+ +-----------------+ | |
| | | ^ | |
| | v | | |
| | +-------DATA SECURITY PROTOCOL-------+ | |
| | | |
| +--------------------------------------------------------------+ |
| |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| +-----------------+ +-----------------+ |
| | POLICY | | AUTHORIZATION | |
| | INFRASTRUCTURE | | INFRASTRUCTURE | |
| +-----------------+ +-----------------+ |
| ^ ^ |
| | | |
| v v |
| +--------------------------------------------------------------+ |
| | | |
| | +--------------------+ | |
| | +------>| GCKS |<------+ | |
| | | +--------------------+ | | |
| | REGISTRATION or | REGISTRATION or | |
| | DE-REGISTRATION | DE-REGISTRATION | |
| | PROTOCOL | PROTOCOL | |
| | | | | | |
| | v REKEY v | |
| | +-----------------+ PROTOCOL +-----------------+ | |
| | | | (OPTIONAL) | | | |
| | | SENDER(S) |<-------+-------->| RECEIVER(S) | | |
| | | | | | | |
| | +-----------------+ +-----------------+ | |
| | | ^ | |
| | v | | |
| | +-------DATA SECURITY PROTOCOL-------+ | |
| | | |
| +--------------------------------------------------------------+ |
| |
+------------------------------------------------------------------+
Figure 1: Group Security Association Model
图1：组安全关联模型
There are a few distinct outcomes to a successful registration Protocol exchange.
成功的注册协议交换有几个不同的结果。
o If the GCKS uses rekey messages, then the admitted member receives the Rekey SA. The Rekey SA contains the group's rekey policy (note that not all of the policy need to be revealed to members), and at least a group KEK. In addition, the GCKS sends a group key integrity key for integrity protection of rekey messages. If a group key management algorithm is used for efficient rekeying, the GCKS also sends one or more KEKs as specified by the key distribution policy of the group key management algorithm.
o 如果GCKS使用密钥更新消息，则被接纳的成员将收到密钥更新SA。重新登记SA包含集团的重新登记政策（请注意，并非所有政策都需要向成员披露），以及至少一个集团KEK。此外，GCKS还发送一个组密钥完整性密钥，用于重新密钥消息的完整性保护。如果使用组密钥管理算法进行有效的密钥更新，则GCKS还发送组密钥管理算法的密钥分配策略指定的一个或多个KEK。
o If rekey messages are not used for the Group, then the admitted member receives TPKs (as part of the Data Security SAs) that are passed to the member's Data Security Protocol (as IKE does for IPsec).
o 如果组未使用重设密钥消息，则被接纳的成员将接收传递给成员的数据安全协议的TPK（作为数据安全SA的一部分）（IKE对IPsec所做的）。
o The GCKS may pass one or more TPKs to the member even if rekey messages are used, for efficiency reasons and according to group policy.
o 出于效率原因并根据集团政策，即使使用了密钥更新消息，GCK也可以将一个或多个TPK传递给成员。
The GCKS creates the KEK and TPKs and downloads them to each member, as the KEK and TPKs are common to the entire group. The GCKS is a separate logical entity that performs member authentication and authorization according to the group policy that is set by the group owner. The GCKS may present a credential signed by the group owner to the group member, so that member can check the GCKS's authorization. The GCKS, which may be co-located with a member or be physically separate, runs the rekey protocol to push rekey messages containing refreshed KEKs, new TPKs, and/or refreshed TPKs to members. Note that some group key management algorithms refresh any of the KEKs (potentially), whereas others only refresh the group KEK.
GCK创建KEK和TPK，并将它们下载到每个成员，因为KEK和TPK对于整个组是通用的。GCKS是一个独立的逻辑实体，根据组所有者设置的组策略执行成员身份验证和授权。GCKS可以向组成员出示由组所有者签名的凭证，以便成员可以检查GCKS的授权。GCK可能与一个成员位于同一位置，也可能在物理上是独立的，它运行rekey协议，将包含刷新的KEK、新的TPK和/或刷新的TPK的rekey消息推送到成员。请注意，某些组密钥管理算法（可能）刷新任何KEK，而其他算法仅刷新组KEK。
Alternatively, the sender may forward rekey messages on behalf of the GCKS when it uses a credential mechanism that supports delegation. Thus, it is possible for the sender, or other members, to source keying material (TPKs encrypted in the Group KEK) as it sources multicast or unicast data. As mentioned above, the rekey message can be sent using unicast or multicast delivery. Upon receipt of a TPK (as part of a Data SA) via a rekey message or a registration protocol exchange, the member's group key management functional block will provide the new or updated security association (SA) to the data security protocol. This protects the data sent from sender to receiver.
或者，当发送方使用支持委派的凭证机制时，它可以代表GCK转发密钥更新消息。因此，发送方或其他成员可以在源多播或单播数据时源密钥材料（在组KEK中加密的tpk）。如上所述，可以使用单播或多播传递发送密钥更新消息。在通过密钥更新消息或注册协议交换接收到TPK（作为数据SA的一部分）后，成员的组密钥管理功能块将向数据安全协议提供新的或更新的安全关联（SA）。这样可以保护从发送方发送到接收方的数据。
The Data SA protects the data sent on the arc labeled DATA SECURITY PROTOCOL shown in Figure 1. A second SA, the Rekey SA, is optionally established by the key management protocol for rekey messages as shown in Figure 1 by the arc labeled REKEY PROTOCOL. The rekey message is optional because all keys, KEKs and TPKs, can be delivered by the registration protocol exchanges shown in Figure 1, and those keys may not need to be updated. The registration protocol is protected by a third, unicast, SA between the GCKS and each member. This is called the Registration SA. There may be no need for the Registration SA to remain in place after the completion of the registration protocol exchanges. The de-registration protocol may be used when explicit teardown of the SA is desirable (such as when a phone call or conference terminates). The three SAs compose the GSA. The only optional SA is the Rekey SA.
Data SA保护在图1所示的arc标记数据安全协议上发送的数据。第二个SA，即Rekey SA，可选择地由密钥管理协议为Rekey消息建立，如图1所示，由标有Rekey协议的arc建立。rekey消息是可选的，因为所有密钥KEK和TPK都可以通过图1所示的注册协议交换来传递，并且这些密钥可能不需要更新。注册协议由GCK和每个成员之间的第三个单播SA保护。这称为注册SA。注册协议交换完成后，注册SA可能无需保留。当需要显式地拆除SA时（例如当电话呼叫或会议终止时），可以使用取消注册协议。三个SA组成GSA。唯一可选的SA是重新设置SA。
Figure 1 shows two blocks that are external to the group key management protocol: The policy and authorization infrastructures are discussed in Section 6.1. The Multicast Security Architecture document further clarifies the SAs and their use as part of the complete architecture of a multicast security solution [MSEC-Arch].
图1显示了组密钥管理协议外部的两个模块：第6.1节讨论了策略和授权基础结构。多播安全体系结构文档进一步阐明了SAs及其作为多播安全解决方案完整体系结构的一部分的使用[MSEC Arch]。
The design of Section 3.2 achieves scalable operation by (1) allowing the de-coupling of authenticated key exchange in a registration protocol from a rekey protocol, (2) allowing the rekey protocol to use unicast push or multicast distribution of group and data keys as an option, (3) allowing all keys to be obtained by the unicast registration protocol, and (4) delegating the functionality of the GCKS among multiple entities, i.e., to permit distributed operation of the GCKS.
第3.2节的设计通过以下方式实现可扩展操作：（1）允许注册协议中的认证密钥交换与重密钥协议分离，（2）允许重密钥协议使用单播推送或组和数据密钥的多播分发作为选项，（3）允许通过单播注册协议获得所有密钥，以及（4）在多个实体之间委托gck的功能，即，允许gck的分布式操作。
High-capacity operation is obtained by (1) amortizing computationally-expensive asymmetric cryptography over multiple data keys used by data security protocols, (2) supporting multicast distribution of symmetric group and data keys, and (3) supporting key revocation algorithms such as LKH [RFC2627,OFT,SD1,SD2] that allow members to be added or removed at logarithmic rather than linear space/time complexity. The registration protocol may use asymmetric cryptography to authenticate joining members and optionally establish the group KEK. Asymmetric cryptography such as Diffie-Hellman key agreement and/or digital signatures are amortized over the life of the group KEK. A Data SA can be established without the use of asymmetric cryptography; the TPKs are simply encrypted in the symmetric KEK and sent unicast or multicast in the rekey protocol.
通过（1）对数据安全协议使用的多个数据密钥进行计算代价高昂的非对称加密，（2）支持对称组和数据密钥的多播分发，以及（3）支持密钥撤销算法，如LKH[RFC2627，OFT，SD1，SD2]来实现高容量操作允许以对数而不是线性空间/时间复杂性添加或删除成员。注册协议可以使用非对称加密来认证加入成员，并可选地建立组KEK。Diffie-Hellman密钥协议和/或数字签名等非对称加密在KEK组的生命周期内摊销。无需使用非对称密码就可以建立数据SA；TPK仅在对称KEK中加密，并在rekey协议中发送单播或多播。
The design of the registration and rekey protocols is flexible. The registration protocol establishes a Rekey SA or one or more Data SAs or both types of SAs. At least one of the SAs is present (otherwise, there is no purpose to the Registration SA). The Rekey SA may update the Rekey SA, or establish or update one or more Data SAs. Individual protocols or configurations may use this flexibility to obtain efficient operation.
注册和密钥更新协议的设计是灵活的。注册协议建立一个密钥重置SA或一个或多个数据SA或两种类型的SA。至少存在一个SA（否则，注册SA没有任何用途）。密钥更新SA可以更新密钥更新SA，或者建立或更新一个或多个数据SA。单个协议或配置可以使用这种灵活性来获得有效的操作。
In the block diagram of Figure 2, group key management protocols run between a GCKS and member principal to establish a Group Security Association (GSA). The GSA consists of a Data SA, an optional Rekey SA, and a Registration SA. The GCKS may use a delegated principal, such as the sender, which has a delegation credential signed by the GCKS. The Member of Figure 2 may be a sender or receiver of multicast or unicast data. There are two functional blocks in Figure
在图2的框图中，组密钥管理协议在GCKS和成员主体之间运行，以建立组安全关联（GSA）。GSA由一个数据SA、一个可选的密钥更新SA和一个注册SA组成。GCK可以使用委托主体，如发送方，其具有由GCK签署的委托凭证。图2的成员可以是多播或单播数据的发送者或接收者。图中有两个功能块
2 labeled GKM, and there are two arcs between them depicting the group key-management registration (reg) and rekey (rek) protocols. The message exchanges are in the GSA establishment protocols, which are the registration protocol and the rekey protocol described above.
2标记为GKM，它们之间有两条弧，描述了组密钥管理注册（reg）和重密钥（rek）协议。消息交换在GSA建立协议中，GSA建立协议是上述的注册协议和密钥更新协议。
Figure 2 shows that a complete group-key management functional specification includes much more than the message exchange. Some of these functional blocks and the arcs between them are peculiar to an operating system (OS) or vendor product, such as vendor specifications for products that support updates to the IPsec
图2显示了一个完整的组密钥管理功能规范所包含的远不止消息交换。其中一些功能块及其之间的弧是操作系统（OS）或供应商产品特有的，例如支持IPsec更新的产品的供应商规范
Security Association Database (SAD) and Security Policy Database (SPD) [RFC2367]. Various vendors also define the functions and interface of credential stores, CRED in Figure 2.
安全关联数据库（SAD）和安全策略数据库（SPD）[RFC2367]。各种供应商还定义了凭证存储的功能和接口，如图2所示。
+----------------------------------------------------------+
| |
| +-------------+ +------------+ |
| | CONTROL | | CONTROL | |
| +------^------+ +------|-----+ +--------+ |
| | | +-----| CRED | |
| | | | +--------+ |
| +----v----+ +----v--v-+ +--------+ |
| | <-----Reg-----> |<->| SAD | |
| | GKM -----Rek-----> GKM | +--------+ |
| | | | | +--------+ |
| | ------+ | |<->| SPD | |
| +---------+ | +-^-------+ +--------+ |
| +--------+ | | | | |
| | CRED |----->+ | | +-------------------+ |
| +--------+ | | +--------------------+ | |
| +--------+ | +-V-------+ +--------+ | | |
| | SAD <----->+ | |<->| SAD <-+ | |
| +--------+ | |SECURITY | +--------+ | |
| +--------+ | |PROTOCOL | +--------+ | |
| | SPD <----->+ | |<->| SPD <----+ |
| +--------+ +---------+ +--------+ |
| |
| (A) GCKS (B) MEMBER |
+----------------------------------------------------------+
+----------------------------------------------------------+
| |
| +-------------+ +------------+ |
| | CONTROL | | CONTROL | |
| +------^------+ +------|-----+ +--------+ |
| | | +-----| CRED | |
| | | | +--------+ |
| +----v----+ +----v--v-+ +--------+ |
| | <-----Reg-----> |<->| SAD | |
| | GKM -----Rek-----> GKM | +--------+ |
| | | | | +--------+ |
| | ------+ | |<->| SPD | |
| +---------+ | +-^-------+ +--------+ |
| +--------+ | | | | |
| | CRED |----->+ | | +-------------------+ |
| +--------+ | | +--------------------+ | |
| +--------+ | +-V-------+ +--------+ | | |
| | SAD <----->+ | |<->| SAD <-+ | |
| +--------+ | |SECURITY | +--------+ | |
| +--------+ | |PROTOCOL | +--------+ | |
| | SPD <----->+ | |<->| SPD <----+ |
| +--------+ +---------+ +--------+ |
| |
| (A) GCKS (B) MEMBER |
+----------------------------------------------------------+
Figure 2: Group Key Management Block in a Host
图2：主机中的组密钥管理块
The CONTROL function directs the GCKS to establish a group, admit a member, or remove a member, or it directs a member to join or leave a group. CONTROL includes authorization that is subject to group policy [GSPT] but its implementation is specific to the GCKS. For large scale multicast sessions, CONTROL could perform session
控制功能指示GCK建立组、接纳成员或移除成员，或指示成员加入或离开组。控制包括受集团政策[GSPT]约束的授权，但其实施特定于GCKS。对于大规模多播会话，控件可以执行会话
announcement functions to inform a potential group member that it may join a group or receive group data (e.g., a stream of file transfer protected by a data security protocol). Announcements notify group members to establish multicast SAs in advance of secure multicast data transmission. Session Description Protocol (SDP) is one form that the announcements might take [RFC2327]. The announcement function may be implemented in a session directory tool, an electronic program guide (EPG), or by other means. The Data Security or the announcement function directs group key management using an application programming interface (API), which is peculiar to the host OS in its specifics. A generic API for group key management is for further study, but this function is necessary to allow Group (KEK) and Data (TPKs) key establishment to be scalable to the particular application. A GCKS application program will use the API to initiate the procedures for establishing SAs on behalf of a Security Protocol in which members join secure groups and receive keys for streams, files, or other data.
公告功能用于通知潜在的组成员其可能加入组或接收组数据（例如，受数据安全协议保护的文件传输流）。通知通知组成员在安全多播数据传输之前建立多播SA。会话描述协议（SDP）是公告可能采用的一种形式[RFC2327]。公告功能可以通过会话目录工具、电子节目指南（EPG）或其他方式实现。数据安全性或公告功能使用应用程序编程接口（API）指导组密钥管理，这是主机操作系统特有的细节。用于组密钥管理的通用API用于进一步研究，但此功能对于允许组（KEK）和数据（TPKs）密钥建立可扩展到特定应用程序是必需的。GCKS应用程序将使用API启动代表安全协议建立SA的程序，在该协议中，成员加入安全组并接收流、文件或其他数据的密钥。
The goal of the exchanges is to establish a GSA through updates to the SAD of a key management implementation and particular Security Protocol. The Data Security Protocol ("SECURITY PROTOCOL") of Figure 2 may span internetwork and application layers or operate at the internetwork layer, such as AH and ESP.
交换的目标是通过更新密钥管理实现和特定安全协议的SAD来建立GSA。图2的数据安全协议（“安全协议”）可以跨越网络和应用层，或者在网络层上运行，例如AH和ESP。
The design of the registration protocol is flexible and can support different application scenarios. The chosen registration protocol solution reflects the specific requirements of specific scenarios. In principle, it is possible to base a registration protocol on any secure-channel protocol, such as IPsec and TLS, which is the case in tunneled GSAKMP [tGSAKMP]. GDOI [RFC3547] reuses IKE Phase 1 as the secure channel to download Rekey and/or Data SAs. Other protocols, such as MIKEY and GSAKMP, use authenticated Diffie-Hellman exchanges similar to IKE Phase 1, but they are specifically tailored for key download to achieve efficient operation. We discuss the design of a registration protocol in detail in the rest of this section.
注册协议的设计非常灵活，可以支持不同的应用场景。选择的注册协议解决方案反映了特定场景的特定需求。原则上，注册协议可以基于任何安全通道协议，如IPsec和TLS，隧道式GSAKMP[tGSAKMP]就是这种情况。GDOI[RFC3547]将IKE阶段1重新用作下载密钥和/或数据SA的安全通道。其他协议，如MIKEY和GSAKMP，使用经过验证的Diffie-Hellman交换，类似于IKE第1阶段，但它们专门针对密钥下载进行定制，以实现高效操作。我们将在本节的其余部分详细讨论注册协议的设计。
Some registration protocols need to tunnel through a data-signaling protocol to take advantage of already existing security functionality, and/or to optimize the total session setup time. For example, a telephone call has strict bounds for delay in setup time. It is not feasible to run security exchanges in parallel with call setup, since the latter often resolves the address. Call setup must complete before the caller knows the callee's address. In this case, it may be advantageous to tunnel the key exchange procedures inside
一些注册协议需要通过数据信令协议进行隧道传输，以利用现有的安全功能和/或优化总会话设置时间。例如，电话呼叫对设置时间的延迟有严格的限制。与呼叫设置并行运行安全交换是不可行的，因为后者通常解析地址。呼叫设置必须在呼叫方知道被呼叫方地址之前完成。在这种情况下，将密钥交换过程隧道到内部可能是有利的
call establishment [H.235,MIKEY], so that both can complete (or fail, see below) at the same time.
呼叫建立[H.235，MIKEY]，以便两者可以同时完成（或失败，见下文）。
The registration protocol has different requirements depending on the particular integration/tunneling approach. These requirements are not necessarily security requirements, but will have an impact on the chosen security solution. For example, the security association will certainly fail if the call setup fails in the case of IP telephony.
根据特定的集成/隧道方法，注册协议有不同的要求。这些需求不一定是安全需求，但会对所选的安全解决方案产生影响。例如，如果IP电话的呼叫设置失败，安全关联肯定会失败。
Conversely, the registration protocol imposes requirements on the protocol that tunnels it. In the case of IP telephony, the call setup usually will fail when the security association is not successfully established. In the case of video-on-demand, protocols such as RTSP that convey key management data will fail when a needed security association cannot be established.
相反，注册协议对传输它的协议施加了要求。在IP电话的情况下，当安全关联未成功建立时，呼叫设置通常会失败。在视频点播的情况下，当无法建立所需的安全关联时，传输密钥管理数据的协议（如RTSP）将失败。
Both GDOI and MIKEY use this approach, but in different ways. MIKEY can be tunneled in SIP and RTSP. It takes advantage of the session information contained in these protocols and the possibility to optimize the setup time for the registration procedure. SIP requires that a tunneled protocol must use at most one roundtrip (i.e., two messages). This is also a desirable requirement from RTSP.
GDOI和MIKEY都使用这种方法，但方式不同。MIKEY可以在SIP和RTSP中进行隧道传输。它利用这些协议中包含的会话信息以及优化注册过程的设置时间的可能性。SIP要求隧道协议必须最多使用一次往返（即两条消息）。这也是RTSP的理想要求。
The GDOI approach takes advantage of the already defined ISAKMP phase 1 exchange [RFC2409], and extends the phase 2 exchange for the registration. The advantage here is the reuse of a successfully deployed protocol and the code base, where the defined phase 2 exchange is protected by the SA created by phase 1. GDOI also inherits other functionality of the ISAKMP, and thus it is readily suitable for running IPsec protocols over IP multicast services.
GDOI方法利用了已经定义的ISAKMP第1阶段交换[RFC2409]，并扩展了注册的第2阶段交换。这里的优势是重用成功部署的协议和代码库，其中定义的阶段2交换由阶段1创建的SA保护。GDOI还继承了ISAKMP的其他功能，因此它非常适合在IP多播服务上运行IPsec协议。
The required design properties of a registration protocol have different trade-offs. A protocol that provides perfect forward secrecy and identity protection trades performance or efficiency for better security, while a protocol that completes in one or two messages may trade security functionality (e.g., identity protection) for efficiency.
注册协议所需的设计属性具有不同的权衡。提供完美的前向保密和身份保护的协议以性能或效率换取更好的安全性，而在一条或两条消息中完成的协议可能以安全功能（例如身份保护）换取效率。
Replay protection generally uses either a timestamp or a sequence number. The first requires synchronized clocks, while the latter requires retention of state. In a timestamp-based protocol, a replay cache is needed to store the authenticated messages (or the hashes of the messages) received within the allowable clock skew. The size of the replay cache depends on the number of authenticated messages received during the allowable clock skew. During a DoS attack, the replay cache might become overloaded. One solution is to over-
重播保护通常使用时间戳或序列号。前者需要同步时钟，而后者需要保留状态。在基于时间戳的协议中，需要重放缓存来存储在允许的时钟偏差内接收的经过身份验证的消息（或消息的哈希）。重播缓存的大小取决于在允许的时钟偏移期间接收的经过身份验证的消息的数量。在DoS攻击期间，重播缓存可能会过载。一个解决办法是结束-
provision the replay cache, but this may lead to a large replay cache. Another solution is to let the allowable clock skew be changed dynamically during runtime. During a suspected DoS attack, the allowable clock skew is decreased so that the replay cache becomes manageable.
设置replay缓存，但这可能会导致较大的replay缓存。另一个解决方案是让允许的时钟偏差在运行时动态更改。在可疑的DoS攻击期间，允许的时钟偏差会减小，以便重播缓存变得可管理。
A challenge-response mechanism (using Nonces) obviates the need for synchronized clocks for replay protection when the exchange uses three or more messages [MVV].
当交换使用三条或更多消息[MVV]时，质询-响应机制（使用nonce）消除了同步时钟用于重播保护的需要。
Additional security functions become possible as the number of allowable messages in the registration protocol increase. ISAKMP offers identity protection, for example, as part of a six-message exchange. With additional security features, however, comes added complexity: Identity protection, for example, not only requires additional messages, but may result in DoS vulnerabilities since authentication is performed in a late stage of the exchange after resources already have been devoted.
随着注册协议中允许的消息数量的增加，附加的安全功能成为可能。例如，ISAKMP提供身份保护，作为六条消息交换的一部分。然而，附加的安全特性增加了复杂性：例如，身份保护不仅需要额外的消息，而且可能会导致DoS漏洞，因为身份验证是在已投入资源的交换后期执行的。
In all cases, there are tradeoffs with the number of message exchanged, the desired security services, and the amount of infrastructure that is needed to support the group key management service. Whereas protocols that use two or even one-message setup have low latency and computation requirements, they may require more infrastructure such as secure time or offer less security such as the absence of identity protection. What tradeoffs are acceptable and what are not is very much dictated by the application and application environment.
在所有情况下，都需要权衡交换的消息数量、所需的安全服务以及支持组密钥管理服务所需的基础设施数量。虽然使用两个或甚至一个消息设置的协议具有较低的延迟和计算要求，但它们可能需要更多的基础设施（如安全时间），或者提供较少的安全性（如缺少身份保护）。哪些折衷是可以接受的，哪些不可以，在很大程度上取决于应用程序和应用程序环境。
The registration protocol may need external infrastructures to handle authentication and authorization, replay protection, protocol-run integrity, and possibly other security services such as secure synchronized clocks. For example, authentication and authorization may need a PKI deployment (with either authorization-based certificates or a separate management) or may be handled using AAA infrastructure. Replay protection using timestamps requires an external infrastructure or protocol for clock synchronization.
注册协议可能需要外部基础设施来处理身份验证和授权、重播保护、协议运行完整性，以及可能的其他安全服务，例如安全同步时钟。例如，身份验证和授权可能需要PKI部署（使用基于授权的证书或单独的管理），或者可以使用AAA基础设施进行处理。使用时间戳的重播保护需要外部基础结构或协议进行时钟同步。
However, external infrastructures may not always be needed; for example pre-shared keys are used for authentication and authorization. This may be the case if the subscription base is relatively small. In a conversational multimedia scenario (e.g., a VoIP call between two or more people), it may be the end user who handles the authorization by manually accepting/rejecting the incoming calls. In that case, infrastructure support may not be required.
然而，可能并不总是需要外部基础设施；例如，预共享密钥用于身份验证和授权。如果订阅基数相对较小，则可能会出现这种情况。在会话多媒体场景中（例如，两人或多人之间的VoIP呼叫），可能是最终用户通过手动接受/拒绝传入呼叫来处理授权。在这种情况下，可能不需要基础设施支持。
The session-establishment protocol (e.g., SIP, RTSP) that conveys a registration exchange often has a session-disestablishment protocol such as RTSP TEARDOWN [RFC2326] or SIP BYE [RFC3261]. The session-disestablishment exchange between endpoints offers an opportunity to signal the end of the GSA state at the endpoints. This exchange need only be a unidirectional notification by one side that the GSA is to be destroyed. For authentication of this notification, we may use a proof-of-possession of the group key(s) by one side to the other. Some applications benefit from acknowledgement in a mutual, two-message exchange signaling disestablishment of the GSA concomitant with disestablishment of the session, e.g., RTSP or SIP session. In this case, a two-way proof-of-possession might serve for mutual acknowledgement of the GSA disestablishment.
传送注册交换的会话建立协议（例如，SIP、RTSP）通常具有诸如RTSP TEARDOWN[RFC2326]或SIP BYE[rfc326]的会话解除建立协议。端点之间的会话解除建立交换提供了一个在端点发出GSA状态结束信号的机会。此交换只需是一方发出的GSA将被销毁的单向通知。对于此通知的身份验证，我们可以使用一方对另一方拥有组密钥的证明。一些应用程序受益于GSA的相互、两个消息交换信令解除建立以及会话解除建立中的确认，例如RTSP或SIP会话。在这种情况下，双向占有证明可能有助于相互承认GSA的撤销。
The group rekey protocol is for transport of keys and SAs between a GCKS and the members of a secure communications group. The GCKS sends rekey messages to update a Rekey SA, or initialize/update a Data SA or both. Rekey messages are protected by a Rekey SA. The GCKS may update the Rekey SA when group membership changes or when KEKs or TPKs expire. Recall that KEKs correspond to a Rekey SA and TPKs correspond to a Data SA.
组密钥更新协议用于在GCKS和安全通信组成员之间传输密钥和SA。GCKS发送重新密钥消息以更新重新密钥SA或初始化/更新数据SA或两者。重设密钥消息由重设密钥SA保护。当集团成员资格发生变化或KEK或TPK过期时，GCK可能会更新密钥SA。回想一下，KEK对应于密钥SA，TPK对应于数据SA。
The following are some desirable properties of the rekey protocol.
以下是重新密钥协议的一些理想属性。
o The rekey protocol ensures that all members receive the rekey information in a timely manner.
o 密钥更新协议确保所有成员及时收到密钥更新信息。
o The rekey protocol specifies mechanisms allowing the parties to contact the GCKS and re-sync when their keys expire and no updates have been received.
o 密钥更新协议指定了允许各方在密钥过期且未收到更新时联系GCK并重新同步的机制。
o The rekey protocol avoids implosion problems and ensures reliability in delivering Rekey information.
o 密钥更新协议避免了内爆问题，确保了密钥更新信息的可靠性。
We further note that the rekey protocol is primarily responsible for scalability of the group key management architecture. Hence, it is imperative that we provide the above listed properties in a scalable manner. Note that solutions exist in the literature (both IETF standards and research articles) for parts of the problem. For instance, the rekey protocol may use a scalable group key management algorithm (GKMA) to reduce the number of keys sent in a rekey message. Examples of a GKMA include LKH, OFT, Subset difference based schemes etc.
我们进一步注意到，rekey协议主要负责组密钥管理体系结构的可伸缩性。因此，我们必须以可扩展的方式提供上述属性。请注意，文献（IETF标准和研究文章）中存在部分问题的解决方案。例如，重新密钥协议可以使用可伸缩组密钥管理算法（GKMA）来减少在重新密钥消息中发送的密钥的数量。GKMA的示例包括LKH、OFT、基于子集差分的方案等。
The goals of the rekey protocol are:
重新密钥协议的目标是：
o to synchronize a GSA,
o 要同步GSA，
o to provide privacy and (symmetric or asymmetric) authentication, replay protection and DoS protection,
o 提供隐私和（对称或非对称）身份验证、重播保护和DoS保护，
o efficient rekeying after changes in group membership or when keys (KEKs) expire,
o 在组成员身份更改后或密钥（KEK）过期时高效地重新设置密钥，
o reliable delivery of rekey messages,
o 可靠地传递密钥更新消息，
o member recovery from an out-of-sync GSA,
o 从不同步的GSA恢复成员，
o high throughput and low latency, and
o 高吞吐量和低延迟，以及
o support IP Multicast or multi-unicast.
o 支持IP多播或多单播。
We identify several major issues in the design of a rekey protocol:
我们确定了重新密钥协议设计中的几个主要问题：
1. rekey message format,
1. 重新设置消息格式，
2. reliable transport of rekey messages,
2. 可靠传输密钥更新消息，
3. implosion,
3. 内爆，
4. recovery from out-of-sync GSA,
4. 从不同步的GSA恢复，
5. incorporating GKMAs in rekey messages, and
5. 将GKMAs合并到密钥消息中，以及
6. interoperability of GKMAs.
6. GKMAs的互操作性。
Note that interoperation of rekey protocol implementations is insufficient for a GCKS to successfully rekey a group. The GKMA must also interoperate, i.e., standard versions of the group key management algorithms such as LKH, OFT, or Subset Difference must be used.
请注意，重新设置密钥协议实现的互操作不足以使GCKS成功地重新设置组密钥。GKMA还必须具有互操作性，即必须使用标准版本的组密钥管理算法，如LKH、OFT或子集差异。
The rest of this section discusses these topics in detail.
本节其余部分将详细讨论这些主题。
Rekey messages contain Rekey and/or Data SAs along with KEKs and TPKs. These messages need to be confidential, authenticated, and protected against replay and DoS attacks. They are sent via multicast or multi-unicast from the GCKS to the members.
重设密钥消息包含重设密钥和/或数据SA以及KEK和TPK。这些消息需要保密、经过身份验证，并防止重播和DoS攻击。它们通过多播或多单播从GCK发送给成员。
Rekey messages are encrypted with the Group KEK for confidentiality. When used in conjunction with a GKMA, portions of the rekey message are first encrypted with the appropriate KEKs as specified by the GKMA. The GCKS authenticates rekey messages using either a MAC, computed using the group Authentication key, or a digital signature. In both cases, a sequence number is included in computation of the MAC or the signature to protect against replay attacks.
重新设置密钥的消息使用组KEK进行加密以确保机密性。当与GKMA结合使用时，根据GKMA的规定，首先使用适当的KEK对部分重新密钥消息进行加密。GCKS使用MAC（使用组身份验证密钥计算）或数字签名对重设密钥的消息进行身份验证。在这两种情况下，MAC或签名的计算中都包含一个序列号，以防止重播攻击。
When group authentication is provided with a symmetric key, rekey messages are vulnerable to attacks by other members of the group. Rekey messages are digitally signed when group members do not trust each other. When asymmetric authentication is used, members receiving rekey messages are vulnerable to DoS attacks. An external adversary may send a bogus rekey message, which a member cannot identify until after it performs an expensive digital signature operation. To protect against such an attack, a MAC may be sent as part of the rekey message. Members verify the signature only upon successful verification of the MAC.
当为组身份验证提供对称密钥时，重设密钥消息容易受到组中其他成员的攻击。当组成员彼此不信任时，将对重设密钥消息进行数字签名。使用非对称身份验证时，接收密钥更新消息的成员容易受到DoS攻击。外部对手可能会发送虚假的密钥更新消息，成员在执行昂贵的数字签名操作之前无法识别该消息。为了防止此类攻击，可以将MAC作为密钥更新消息的一部分发送。成员仅在成功验证MAC后验证签名。
Rekey messages contain group key updates corresponding to a single [RFC2627,OFT] or multiple membership changes [SD1,SD2,BatchRekey] and may contain group key initialization messages [OFT].
密钥更新消息包含与单个[RFC2627，OFT]或多个成员身份更改[SD1，SD2，BatchRekey]相对应的组密钥更新，并且可能包含组密钥初始化消息[OFT]。
The GCKS must ensure that all members have the current Data Security and Rekey SAs. Otherwise, authorized members may be inadvertently excluded from receiving group communications. Thus, the GCKS needs to use a rekey algorithm that is inherently reliable or employ a reliable transport mechanism to send rekey messages.
GCKS必须确保所有成员都具有当前的数据安全性并重新注册SA。否则，授权成员可能会无意中被排除在接收集团通信之外。因此，GCKS需要使用固有可靠的密钥更新算法，或采用可靠的传输机制来发送密钥更新消息。
There are two dimensions to the problem. Messages that update group keys may be lost in transit or may be missed by a host when it is offline. LKH and OFT group key management algorithms rely on past history of updates being received by the host. If the host goes offline, it will need to resynchronize its group-key state when it comes online; this may require a unicast exchange with the GCKS. The Subset Difference algorithm, however, conveys all the necessary state in its rekey messages and does not need members to be always online or keeping state. The Subset Difference algorithm does not require a back channel and can operate on a broadcast network. If a rekey message is lost in transmission, the Subset Difference algorithm cannot decrypt messages encrypted with the TPK sent via the lost rekey message. There are self-healing GKMAs proposed in the literature that allow a member to recover lost rekey messages, as long as rekey messages before and after the lost rekey message are received.
这个问题有两个方面。更新组密钥的消息可能在传输过程中丢失，或者主机脱机时可能会丢失。LKH和OFT组密钥管理算法依赖于主机接收到的更新的历史记录。如果主机脱机，则需要在联机时重新同步其组密钥状态；这可能需要与GCK进行单播交换。然而，子集差分算法在其密钥更新消息中传递所有必要的状态，并且不需要成员始终在线或保持状态。子集差分算法不需要反向信道，可以在广播网络上运行。如果重新密钥消息在传输过程中丢失，则子集差异算法无法解密通过丢失的重新密钥消息发送的TPK加密的消息。文献中提出的自愈GKMA允许成员恢复丢失的密钥更新消息，只要接收到丢失的密钥更新消息前后的密钥更新消息。
Rekey messages are typically short (for single membership change as well as for small groups), which makes it easy to design a reliable delivery protocol. On the other hand, the security requirements may add an additional dimension to address. There are some special cases in which membership changes are processed as a batch, reducing the frequency of rekey messages but increasing their size. Furthermore, among all the KEKs sent in a rekey message, as many as half the members need only a single KEK. We may take advantage of these properties in designing a rekey message(s) and a protocol for their reliable delivery.
密钥更新消息通常很短（对于单个成员更改以及小的组），这使得设计可靠的传递协议很容易。另一方面，安全要求可能会增加一个额外的维度来解决这个问题。在某些特殊情况下，成员资格更改将作为一个批处理，从而减少了重新设置密钥消息的频率，但增加了消息的大小。此外，在所有在重新密钥消息中发送的KEK中，多达一半的成员只需要一个KEK。我们可以利用这些特性来设计密钥更新消息和协议，以实现可靠的传递。
Three categories of solutions have been proposed:
提出了三类解决方案：
1. Repeatedly transmit the rekey message. In many cases rekey messages translate to only one or two IP packets.
1. 重复传输重新设置密钥的消息。在许多情况下，密钥更新消息只转换为一个或两个IP数据包。
2. Use an existing reliable multicast protocol/infrastructure.
2. 使用现有的可靠多播协议/基础结构。
3. Use FEC for encoding rekey packets (with NACKs as feedback) [BatchRekey].
3. 使用FEC对密钥包进行编码（NACK作为反馈）[BatchRekey]。
Note that for small messages, category 3 is essentially the same as category 1.
请注意，对于小消息，类别3基本上与类别1相同。
The group member might be out of synchrony with the GCKS if it receives a rekey message having a sequence number that is more than one greater than the last sequence number processed. This is one means by which the GCKS member detects that it has missed a rekey message. Alternatively, the data-security application, upon detecting that it is using an out-of-date key, may notify the group key management module. The action taken by the GCKS member is a matter of group policy. The GCKS member should log the condition and may contact the GCKS to rerun the re-registration protocol to obtain a fresh group key. The group policy needs to take into account boundary conditions, such as reordered rekey messages when rekeying is so frequent that two messages might get reordered in an IP network. The group key policy also needs to take into account the potential for denial of service attacks where an attacker delays or deletes a rekey message in order to force a subnetwork or subset of the members to simultaneously contact the GCKS.
如果组成员接收到序列号比最后处理的序列号大一个以上的重设密钥消息，则该组成员可能与GCKS不同步。这是GCKS成员检测到其错过重新密钥消息的一种方式。或者，数据安全应用程序在检测到它正在使用过期密钥时，可以通知组密钥管理模块。GCKS成员采取的行动与集团政策有关。GCKS成员应记录该情况，并可联系GCKS重新运行重新注册协议以获得新的组密钥。组策略需要考虑边界条件，例如，当重新设置密钥的频率非常高，以至于在IP网络中可能会对两条消息进行重新排序时，重新排序的重新设置密钥的消息。组密钥策略还需要考虑拒绝服务攻击的可能性，即攻击者延迟或删除重新密钥消息，以迫使子网络或成员子集同时联系GCK。
If a group member becomes out-of-synch with the GSA then it should re-register with the GCKS. However, in many cases there are other, simpler methods for re-synching with the group:
如果集团成员与GSA不同步，则应向GCKS重新注册。但是，在许多情况下，还有其他更简单的方法用于与组重新同步：
o The member can open a simple unprotected connection (e.g., TCP) with the GCKS and obtain the current (or several recent) rekey messages. Note that there is no need for authentication or
o 该成员可以打开与GCK的简单无保护连接（如TCP），并获取当前（或几条最近）的密钥更新消息。请注意，不需要进行身份验证或验证
encryption here, since the rekey message is already signed and is multicast in the clear. One may think that this opens the GCKS to DoS attacks by many bogus such requests. This, however, does not seem to worsen the situation; in fact, bombarding the GCKS with bogus resynch requests would be much more problematic.
这里进行加密，因为重新密钥消息已经签名，并且是明文多播的。有人可能会认为，这会导致GCKS受到许多虚假请求的DoS攻击。然而，这似乎并没有使局势恶化；事实上，用虚假的重新同步请求轰炸GCK会有更大的问题。
o The GCKS can post the rekey messages on some public site (e.g., a web site) and the out-of-synch member can obtain the rekey messages from that site.
o GCKS可以在某些公共站点（例如网站）上发布密钥更新消息，不同步成员可以从该站点获取密钥更新消息。
The GCKS may always provide all three ways of resynching (i.e., re-registration, simple TCP, and public posting). This way, the member may choose how to resynch; it also avoids adding yet another field to the policy token [GSPT]. Alternatively, a policy token may contain a field specifying one or more methods supported for resynchronization of a GSA.
GCK可能始终提供所有三种重新同步方式（即重新注册、简单TCP和公开发布）。这样，成员可以选择如何重新同步；它还避免了向策略令牌[GSPT]添加另一个字段。或者，策略令牌可以包含一个字段，指定GSA重新同步所支持的一个或多个方法。
The rekey message may be sent using reliable multicast. There are several types of reliable multicast protocols with different properties. However, there are no standards track reliable multicast protocols published at this time, although IETF consensus has been reached on two protocols that are intended to go into the standards track [NORM,RFC3450]. Thus, this document does not recommend a particular reliable multicast protocol or set of protocols for the purpose of reliable group rekeying. The suitability of NAK-based, ACK-based or other reliable multicast methods is determined by the application needs and operational environment. In the future, group key management protocols may choose to use particular standards-based approaches that meet the needs of the particular application. A secure announcement facility may be needed to signal the use of a reliable multicast protocol, which could be specified as part of group policy. The reliable multicast announcement and policy specification, however, can only follow the establishment of reliable multicast standards and are not considered further in this document.
可使用可靠多播发送密钥更新消息。有几种不同性质的可靠多播协议。然而，目前还没有发布标准跟踪可靠多播协议，尽管IETF已就两个协议达成共识，这两个协议旨在进入标准跟踪[NORM，RFC3450]。因此，本文档不建议使用特定的可靠多播协议或一组协议来实现可靠的组密钥更新。基于NAK、基于ACK或其他可靠多播方法的适用性取决于应用需求和操作环境。将来，组密钥管理协议可能会选择使用满足特定应用程序需求的基于特定标准的方法。可能需要一个安全的公告设施来发出使用可靠多播协议的信号，该协议可以指定为组策略的一部分。然而，可靠多播公告和策略规范只能遵循可靠多播标准的建立，本文档不作进一步考虑。
Today, the several MSEC group key management protocols support sequencing of the rekey messages through a sequence number, which is authenticated along with the rekey message. A sender of rekey messages may re-transmit multiple copies of the message provided that they have the same sequence number. Thus, re-sending the message is a rudimentary means of overcoming loss along the network path. A member who receives the rekey message will check the sequence number to detect duplicate and missing rekey messages. The member receiver will discard duplicate messages that it receives. Large rekey messages, such as those that contain LKH or OFT tree structures,
今天，几个MSEC组密钥管理协议支持通过序列号对密钥更新消息进行排序，该序列号与密钥更新消息一起进行身份验证。密钥更新消息的发送者可以重新传输消息的多个副本，只要它们具有相同的序列号。因此，重新发送消息是克服网络路径丢失的基本方法。接收到重新密钥消息的成员将检查序列号，以检测重复和丢失的重新密钥消息。成员接收方将丢弃其接收到的重复消息。大型重设密钥消息，例如包含LKH或OFT树结构的消息，
might benefit from transport-layer FEC in the future, when standards-based methods become available. It is unlikely that forward error correction (FEC) methods will benefit short rekey messages that fit within a single message. In this case, FEC degenerates to simple retransmission of the message.
将来，当基于标准的方法可用时，可能会受益于传输层FEC。前向纠错（FEC）方法不太可能有利于适合单个消息的短重设密钥消息。在这种情况下，FEC退化为消息的简单重传。
Implosion may occur due to one of two reasons. First, recall that one of the goals of the rekey protocol is to synchronize a GSA. When a rekey or Data SA expires, members may contact the GCKS for an update. If all, or even many, members contact the GCKS at about the same time, the GCKS might not be able to handle all those messages. We refer to this as an out-of-sync implosion.
内爆可能由以下两种原因之一引起。首先，回想一下rekey协议的目标之一是同步GSA。当更新密钥或数据SA到期时，会员可以联系GCKS进行更新。如果所有或甚至许多成员几乎同时联系GCK，GCK可能无法处理所有这些消息。我们称之为不同步内爆。
The second case is in the reliable delivery of rekey messages. Reliable multicast protocols use feedback (NACK or ACK) to determine which packets must be retransmitted. Packet losses may result in many members sending NACKs to the GCKS. We refer to this as feedback implosion.
第二种情况是重新密钥消息的可靠传递。可靠的多播协议使用反馈（NACK或ACK）来确定必须重新传输哪些数据包。数据包丢失可能导致许多成员向GCK发送NACK。我们称之为反馈内爆。
The implosion problem has been studied extensively in the context of reliable multicasting. The proposed feedback suppression and aggregation solutions might be useful in the GKM context as well. Members may wait a random time before sending an out-of-sync or feedback message. Meanwhile, members might receive the necessary key updates and therefore not send a feedback message. An alternative solution is to have the members contact one of several registration servers when they are out-of-sync. This requires GSA synchronization between the multiple registration servers.
在可靠多播的背景下，内爆问题得到了广泛的研究。建议的反馈抑制和聚合解决方案在GKM环境中也可能有用。成员可以在发送不同步或反馈消息之前随机等待一段时间。同时，成员可能会收到必要的密钥更新，因此不会发送反馈消息。另一种解决方案是让成员在不同步时联系多个注册服务器中的一个。这需要在多个注册服务器之间进行GSA同步。
Feedback aggregation and local recovery employed by some reliable multicast protocols are not easily adaptable to transport of rekey messages. Aggregation raises authentication issues. Local recovery is more complex because members need to establish SAs with the local repair server. Any member of the group or a subordinate GCKS may serve as a repair server, which can be responsible for resending rekey messages.
一些可靠的多播协议采用的反馈聚合和本地恢复不容易适应密钥更新消息的传输。聚合会引发身份验证问题。本地恢复更加复杂，因为成员需要使用本地修复服务器建立SAs。组中的任何成员或下属GCKS都可以充当修复服务器，负责重新发送密钥消息。
Members may use the group SA, more specifically the Rekey SA, to authenticate requests sent to the repair server. However, replay protection requires maintaining state at members as well as repair servers. Authentication of repair requests is meant to protect against DoS attacks. Note also that an out-of-sync member may use an expired Rekey SA to authenticate repair requests, which requires repair servers to accept messages protected by old SAs.
成员可以使用组SA（更具体地说是重新密钥SA）对发送到修复服务器的请求进行身份验证。但是，重播保护需要维护成员的状态以及修复服务器。修复请求的身份验证旨在防止DoS攻击。还请注意，不同步成员可能使用过期的密钥SA来验证修复请求，这要求修复服务器接受旧SA保护的消息。
Alternatively, a simple mechanism may be employed to achieve local repair efficiently. Each member receives a set of local repair server addresses as part of group operation policy information. When a member does not receive a rekey message, it can send a "Retransmit replay message(s) with sequence number n and higher" message to one of the local repair servers. The repair server can either ignore the request if it is busy or retransmit the requested rekey messages as received from the GCKS. The repair server, which is also another member may choose to serve only m requests in a given time period (i.e., rate limits responses) or per a given rekey message. Rate limiting the requests and responses protects the repair servers as well as other members of the group from DoS attacks.
或者，可以采用简单的机制来有效地实现局部修复。每个成员接收一组本地修复服务器地址，作为组操作策略信息的一部分。当成员未收到密钥更新消息时，它可以向其中一个本地修复服务器发送“序列号为n或更高的重发消息”。修复服务器可以在忙时忽略请求，也可以重新传输从GCKS接收到的请求重新密钥消息。修复服务器（也是另一个成员）可以选择在给定的时间段内（即速率限制响应）或根据给定的密钥更新消息仅服务m个请求。限制请求和响应的速率可保护修复服务器以及组中的其他成员免受DoS攻击。
Group key management algorithms make rekeying scalable. Large group rekeying without employing GKMAs is prohibitively expensive.
组密钥管理算法使密钥更新具有可扩展性。不使用GKMAs的大组密钥更新代价高昂。
Following are some considerations in selecting a GKMA:
以下是选择GKMA时的一些注意事项：
o Protection against collusion.
o 防止共谋。
Members (or non-members) should not be able to collaborate to deduce keys for which they are not privileged (following the GKMA key distribution rules).
成员（或非成员）不应能够协作推导他们没有特权的密钥（遵循GKMA密钥分发规则）。
o Forward access control
o 前向访问控制
The GKMA should ensure that departing members cannot get access to future group data.
GKMA应确保离职成员无法访问未来的集团数据。
o Backward access control
o 反向访问控制
The GKMA should ensure that joining members cannot decrypt past data.
GKMA应确保加入成员不能解密过去的数据。
We classify group key management algorithms into three categories: stateful, stateless, and self-healing.
我们将组密钥管理算法分为三类：有状态、无状态和自愈。
Stateful algorithms [RFC2627,OFT] use KEKs from past rekeying instances to encrypt (protect) KEKs corresponding to the current and future rekeying instances. The main disadvantage in these schemes is that if a member were offline or otherwise failed to receive KEKs from a past rekeying instance, it may no longer be able to synchronize its GSA even though it can receive KEKs from all future rekeying instances. The only solution is to contact the GCKS
有状态算法[RFC2627，OFT]使用来自过去密钥更新实例的KEK来加密（保护）与当前和未来密钥更新实例对应的KEK。这些方案的主要缺点是，如果一个成员离线或未能从过去的密钥更新实例接收KEK，那么它可能不再能够同步其GSA，即使它可以从所有未来的密钥更新实例接收KEK。唯一的解决办法是联系GCK
explicitly for resynchronization. Note that the KEKs for the first rekeying instance are protected by the Registration SA. Recall that communication in that phase is one to one, and therefore it is easy to ensure reliable delivery.
显式地用于重新同步。请注意，第一个密钥更新实例的KEK受注册SA的保护。回想一下，该阶段的沟通是一对一的，因此很容易确保可靠的交付。
Stateless GKMAs [SD1,SD2] encrypt rekey messages with KEKs sent during the registration protocol. Since rekey messages are independent of any past rekey messages (i.e., that are not protected by KEKs therein), a member may go offline but continue to decipher future communications. However, stateless GKMAs offer no mechanisms to recover past rekeying messages. Stateless rekeying may be relatively inefficient, particularly for immediate (not batch) rekeying in highly dynamic groups.
无状态GKMAs[SD1，SD2]使用注册协议期间发送的KEK对重新加密消息进行加密。由于重新密钥消息独立于任何过去的重新密钥消息（即，其中不受KEK保护的消息），成员可以脱机，但继续解密未来的通信。然而，无状态GKMA不提供任何机制来恢复过去的密钥更新消息。无状态密钥更新可能相对低效，特别是对于高度动态组中的即时（而非批处理）密钥更新。
In self-healing schemes [Self-Healing], a member can reconstruct a lost rekey message as long as it receives some past and some future rekey messages.
在自愈方案[自愈]中，成员只要接收到一些过去和将来的重新密钥消息，就可以重建丢失的重新密钥消息。
Most GKMA specifications do not specify packet formats, although many group key management algorithms need format specification for interoperability. There are several alternative ways to manage key trees and to number nodes within key trees. The following information is needed during initialization of a Rekey SA or included with each GKMA packet.
大多数GKMA规范没有指定数据包格式，尽管许多组密钥管理算法需要格式规范以实现互操作性。有几种替代方法可用于管理关键树和对关键树中的节点进行编号。在重新密钥SA的初始化期间需要以下信息，或包含在每个GKMA数据包中。
o GKMA name (e.g., LKH, OFT, Subset Difference)
o GKMA名称（如LKH、OFT、子集差异）
o GKMA version number (implementation specific). Version may imply several things such as the degree of a key tree, proprietary enhancements, and qualify another field such as a key ID.
o GKMA版本号（具体实施）。版本可能意味着一些事情，例如密钥树的级别、专有增强功能，以及限定另一个字段，例如密钥ID。
o Number of keys or largest ID
o 密钥数或最大ID
o Version-specific data
o 版本特定数据
o Per-key information:
o 每个关键信息：
- key ID, - key lifetime (creation/expiration data) , - encrypted key, and - encryption key's ID (optional).
- 密钥ID、-密钥生存期（创建/过期数据）、-加密密钥和-加密密钥的ID（可选）。
Key IDs may change in some implementations in which case one needs to send:
在某些实现中，密钥ID可能会更改，在这种情况下，需要发送：
o List of <old id, new id> pairs.
o <旧id，新id>对的列表。
The GKM architecture defines the interfaces between the registration, rekey, and data security protocols in terms of the Security Associations (SAs) of those protocols. By isolating these protocols behind a uniform interface, the architecture allows implementations to use protocols best suited to their needs. For example, a rekey protocol for a small group could use multiple unicast transmissions with symmetric authentication, while a rekey protocol for a large group could use IP Multicast with packet-level Forward Error Correction and source authentication.
GKM体系结构根据注册、密钥更新和数据安全协议的安全关联（SA）定义了这些协议之间的接口。通过在统一接口后面隔离这些协议，该体系结构允许实现使用最适合其需要的协议。例如，用于小组的密钥更新协议可以使用具有对称身份验证的多个单播传输，而用于大组的密钥更新协议可以使用具有分组级前向纠错和源身份验证的IP多播。
The group key management architecture provides an interface between the security protocols and the group SA (GSA). The GSA consists of three SAs: Registration SA, Rekey SA, and Data SA. The Rekey SA is optional. There are two cases in defining the relationships between the three SAs. In both cases, the Registration SA protects the registration protocol.
组密钥管理体系结构提供了安全协议和组SA（GSA）之间的接口。GSA由三个SA组成：注册SA、重新注册SA和数据SA。重置SA是可选的。定义三个SA之间的关系有两种情况。在这两种情况下，注册SA都保护注册协议。
Case 1: Group key management is done WITHOUT using a Rekey SA. The registration protocol initializes and updates one or more Data SAs (having TPKs to protect files or streams). Each Data SA corresponds to a single group, which may have more than one Data SA.
案例1：组密钥管理在不使用重新密钥SA的情况下完成。注册协议初始化和更新一个或多个数据SA（具有保护文件或流的TPK）。每个数据SA对应于单个组，该组可能有多个数据SA。
Case 2: Group key management is done WITH a Rekey SA to protect the rekey protocol. The registration protocol initializes the one or more Rekey SAs as well as zero or more Data SAs, upon successful completion. When a Data SA is not initialized in the registration protocol, initialization is done in the rekey protocol. The rekey protocol updates Rekey SA(s) AND establishes Data SA(s).
案例2：使用重新密钥SA进行组密钥管理，以保护重新密钥协议。注册协议在成功完成后初始化一个或多个重新密钥SA以及零个或多个数据SA。当数据SA未在注册协议中初始化时，将在密钥更新协议中进行初始化。密钥更新协议更新密钥SA并建立数据SA。
Group policy is described in detail in the Group Security Policy Token document [GSPT]. Group policy can be distributed through group announcements, key management protocols, and other out-of-band means (e.g., via a web page). The group key management protocol carries cryptographic policies of the SAs and the keys it establishes, as well as additional policies for the secure operation of the group.
组策略在组安全策略令牌文档[GSPT]中有详细描述。可以通过组公告、密钥管理协议和其他带外方式（例如，通过网页）分发组策略。组密钥管理协议包含SAs及其建立的密钥的加密策略，以及用于组安全操作的附加策略。
The acceptable cryptographic policies for the registration protocol, which may run over TLS [TLS], IPsec, or IKE, are not conveyed in the group key management protocol since they precede any of the key management exchanges. Thus, a security policy repository having some access protocol may need to be queried prior to establishing the key-management session, to determine the initial cryptographic policies for that establishment. This document assumes the existence of such a repository and protocol for GCKS and member policy queries. Thus group security policy will be represented in a policy repository and accessible using a policy protocol. Policy distribution may be a push or a pull operation.
注册协议的可接受加密策略（可能在TLS[TLS]、IPsec或IKE上运行）不会在组密钥管理协议中传输，因为它们先于任何密钥管理交换。因此，在建立密钥管理会话之前，可能需要查询具有某种访问协议的安全策略存储库，以确定该建立的初始加密策略。本文档假设存在这样一个用于GCK和成员策略查询的存储库和协议。因此，组安全策略将在策略存储库中表示，并使用策略协议进行访问。策略分发可以是推式操作或拉式操作。
The group key management architecture assumes that the following group policy information may be externally managed, e.g., by the content owner, group conference administrator or group owner:
组密钥管理体系结构假定以下组策略信息可以由外部管理，例如由内容所有者、组会议管理员或组所有者管理：
o the identity of the Group owner, the authentication method, and the delegation method for identifying a GCKS for the group;
o 组所有者的身份、身份验证方法和用于识别组的GCKS的委托方法；
o the group GCKS, authentication method, and delegation method for any subordinate GCKSs for the group;
o 集团的任何下属GCK的集团GCK、认证方法和授权方法；
o the group membership rules or list and authentication method.
o 组成员资格规则或列表和身份验证方法。
There are two additional policy-related requirements external to group key management.
集团密钥管理之外还有两项与策略相关的额外要求。
o There is an authentication and authorization infrastructure such as X.509 [RFC3280], SPKI [RFC2693], or a pre-shared key scheme, in accordance with the group policy for a particular group.
o 根据特定组的组策略，存在身份验证和授权基础设施，如X.509[RFC3280]、SPKI[RFC2693]或预共享密钥方案。
o There is an announcement mechanism for secure groups and events, which operates according to group policy for a particular group.
o 有一种用于安全组和事件的公告机制，它根据特定组的组策略进行操作。
Group policy determines how the registration and rekey protocols initialize or update Rekey and Data SAs. The following sections describe potential information sent by the GCKS for the Rekey and Data SAs. A member needs the information specified in the next sections to establish Rekey and Data SAs.
组策略确定注册和密钥更新协议如何初始化或更新密钥更新和数据SA。以下各节描述了GCK为Rekey和Data SA发送的潜在信息。成员需要在下一节中指定的信息来建立密钥和数据SA。
The Rekey SA protects the rekey protocol. It contains cryptographic policy, Group Identity, and Security Parameter Index (SPI) [RFC2401] to uniquely identify an SA, replay protection information, and key protection keys.
重新密钥SA保护重新密钥协议。它包含加密策略、组标识和安全参数索引（SPI）[RFC2401]，用于唯一标识SA、重播保护信息和密钥保护密钥。
o GROUP KEY MANAGEMENT ALGORITHM
o 组密钥管理算法
This represents the group key revocation algorithm that enforces forward and backward access control. Examples of key revocation algorithms include LKH, LKH+, OFT, OFC, and Subset Difference [RFC2627,OFT,TAXONOMY,SD1,SD2]. If the key revocation algorithm is NULL, the Rekey SA contains only one KEK, which serves as the group KEK. The rekey messages initialize or update Data SAs as usual. However, the Rekey SA itself can be updated (the group KEK can be rekeyed) when members join or the KEK is about to expire. Leave rekeying is done by re-initializing the Rekey SA through the rekey protocol.
这表示强制前向和后向访问控制的组密钥撤销算法。密钥撤销算法的示例包括LKH、LKH+、OFT、OFC和子集差异[RFC2627、OFT、分类法、SD1、SD2]。如果密钥撤销算法为NULL，则重新密钥SA仅包含一个KEK，作为组KEK。重新设置密钥消息会像往常一样初始化或更新数据SAs。但是，当成员加入或KEK即将过期时，可以更新重新设置SA密钥（组KEK可以重新设置密钥）。通过Rekey协议重新初始化Rekey SA，完成休假密钥更新。
o KEK ENCRYPTION ALGORITHM
o KEK加密算法
This specifies a standard encryption algorithm such as 3DES or AES, and also the KEK KEY LENGTH.
这指定了标准加密算法，如3DES或AES，以及KEK密钥长度。
o AUTHENTICATION ALGORITHM
o 认证算法
This algorithm uses digital signatures for GCKS authentication (since all shared secrets are known to some or all members of the group), or some symmetric secret in computing MACs for group authentication. Symmetric authentication provides weaker authentication in that any group member can impersonate a particular source. The AUTHENTICATION KEY LENGTH is also to be specified.
该算法使用数字签名进行GCKS身份验证（因为组中的一些或所有成员都知道所有共享机密），或者使用计算MAC中的一些对称机密进行组身份验证。对称身份验证提供较弱的身份验证，因为任何组成员都可以模拟特定的源。还应指定身份验证密钥长度。
o CONTROL GROUP ADDRESS
o 控制组地址
This address is used for multicast transmission of rekey messages. This information is sent over the control channel such as in an ANNOUNCEMENT protocol or call setup message. The degree to which the control group address is protected is a matter of group policy.
此地址用于重新密钥消息的多播传输。此信息通过控制通道发送，例如在公告协议或呼叫设置消息中。控制组地址的保护程度取决于组策略。
o REKEY SERVER ADDRESS
o 重新设置服务器地址
This address allows the registration server to be a different entity from the server used for rekeying, such as for future invocations of the registration and rekey protocols. If the registration server and the rekey server are two different entities, the registration server sends the rekey server's address as part of the Rekey SA.
此地址允许注册服务器成为与用于密钥更新的服务器不同的实体，例如用于将来调用注册和密钥更新协议。如果注册服务器和密钥更新服务器是两个不同的实体，则注册服务器将密钥更新服务器的地址作为密钥更新SA的一部分发送。
The group identity accompanies the SA (payload) information as an identifier if the specific group key management protocol allows multiple groups to be initialized in a single invocation of the registration protocol, or multiple groups to be updated in a single rekey message. It is often simpler to restrict each registration invocation to a single group, but such a restriction is unnecessary. It is always necessary to identify the group when establishing a Rekey SA, either implicitly through an SPI or explicitly as an SA parameter.
如果特定的组密钥管理协议允许在注册协议的一次调用中初始化多个组，或者在一次重新密钥消息中更新多个组，则组标识作为标识符伴随SA（有效负载）信息。将每个注册调用限制为单个组通常更简单，但这样的限制是不必要的。在通过SPI隐式地或显式地作为SA参数建立密钥重置SA时，始终需要标识组。
Corresponding to the key management algorithm, the Rekey SA contains one or more KEKs. The GCKS holds the key encrypting keys of the group, while the members receive keys following the specification of the key management algorithm. When there are multiple KEKs for a group (as in an LKH tree), each KEK needs to be associated with a Key ID, which is used to identify the key needed to decrypt it. Each KEK has a LIFETIME associated with it, after which the KEK expires.
与密钥管理算法相对应，重密钥SA包含一个或多个kek。GCKS持有组的密钥加密密钥，而成员则按照密钥管理算法的规范接收密钥。当一个组有多个KEK时（如在LKH树中），每个KEK都需要与一个密钥ID相关联，该ID用于标识解密密钥所需的密钥。每个KEK都有一个与之关联的生存期，在该生存期之后，KEK将过期。
The GCKS provides a symmetric or public key for authentication of its rekey messages. Symmetric key authentication is appropriate only when all group members can be trusted not to impersonate the GCKS. The architecture does not rule out methods for deriving symmetric authentication keys at the member [RFC2409] rather than pushing them from the GCKS.
GCKS为其密钥更新消息的身份验证提供对称密钥或公钥。只有当可以信任所有组成员不模拟GCK时，对称密钥身份验证才合适。该体系结构不排除在成员[RFC2409]处导出对称身份验证密钥的方法，而不是从GCK推送它们。
Rekey messages need to be protected from replay/reflection attacks. Sequence numbers are used for this purpose, and the Rekey SA (or protocol) contains this information.
需要保护重设密钥的消息免受重播/反射攻击。序列号用于此目的，重新密钥SA（或协议）包含此信息。
The tuple <Group identity, SPI> uniquely identifies a Rekey SA. The SPI changes each time the KEKs change.
tuple<Group identity，SPI>唯一地标识一个密钥重置SA。每次桶改变时，SPI都会改变。
The GCKS specifies the data security protocol used for secure transmission of data from sender(s) to receiving members. Examples of data security protocols include IPsec ESP [RFC2401] and SRTP [RFC3711]. While the contents of each of these protocols are out of
GCKS指定用于将数据从发送方安全传输到接收成员的数据安全协议。数据安全协议的示例包括IPsec ESP[RFC2401]和SRTP[RFC3711]。而这些协议中的每一个的内容都已过期
the scope of this document, we list the information sent by the registration protocol (or the rekey protocol) to initialize or update the Data SA.
在本文档的范围内，我们列出了注册协议（或密钥更新协议）发送的用于初始化或更新数据SA的信息。
The Group identity accompanies SA information when Data SAs are initialized or rekeyed for multiple groups in a single invocation of the registration protocol or in a single Rekey message.
在一次调用注册协议或在一次重新设置密钥消息中为多个组初始化或重新设置数据SA时，组标识伴随SA信息。
The SA includes source identity information when the group owner chooses to reveal source identity to authorized members only. A public channel such as the announcement protocol is only appropriate when there is no need to protect source or group identities.
当组所有者选择仅向授权成员透露源身份时，SA包括源身份信息。只有在不需要保护源或组标识时，才适合使用公告协议之类的公共通道。
Regardless of the data security protocol used, the GCKS supplies the TPKs, or information to derive TPKs for traffic protection.
无论使用何种数据安全协议，GCKS都会提供TPK，或用于派生TPK以进行流量保护的信息。
Depending on the data authentication method used by the data security protocol, group key management may pass one or more keys, functions (e.g., TESLA [TESLA-INFO,TESLA-SPEC]), or other parameters used for authenticating streams or files.
根据数据安全协议使用的数据认证方法，组密钥管理可传递一个或多个密钥、功能（例如，TESLA[TESLA-INFO，TESLA-SPEC]）或用于认证流或文件的其他参数。
The GCKS passes sequence numbers when needed by the data security protocol, for SA synchronization and replay protection.
GCKS在数据安全协议需要时传递序列号，用于SA同步和重播保护。
The GCKS may provide an identifier as part of the Data SA contents for data security protocols that use an SPI or similar mechanism to identify an SA or keys within an SA.
GCK可以为使用SPI或类似机制来识别SA或SA内的密钥的数据安全协议提供标识符作为数据SA内容的一部分。
The Data SA parameters are specific to the data security protocol but generally include encryption algorithm and parameters, the source authentication algorithm and parameters, the group authentication algorithm and parameters, and/or replay protection information.
数据SA参数特定于数据安全协议，但通常包括加密算法和参数、源身份验证算法和参数、组身份验证算法和参数和/或重播保护信息。
The area of group communications is quite diverse. In teleconferencing, a multipoint control unit (MCU) may be used to aggregate a number of teleconferencing members into a single session; MCUs may be hierarchically organized as well. A loosely coupled teleconferencing session [RFC3550] has no central controller but is fully distributed and end-to-end. Teleconferencing sessions tend to have at most dozens of participants. However, video broadcast that uses multicast communications and media-on-demand that uses unicast are large-scale groups numbering hundreds to millions of participants.
团体交流的领域相当多样化。在远程会议中，多点控制单元（MCU）可用于将多个远程会议成员聚合成单个会话；MCU也可以是分层组织的。松散耦合的电话会议会话[RFC3550]没有中央控制器，而是完全分布式和端到端的。电话会议往往最多有几十人参加。然而，使用多播通信的视频广播和使用单播的媒体点播都是规模庞大的群体，参与者数量从数亿到数百万。
As described in the Requirements section, Section 2, the group key management architecture supports multicast applications with a single sender. The architecture described in this paper supports large-scale operation through the following features.
如需求部分第2部分所述，组密钥管理体系结构支持具有单个发送方的多播应用程序。本文描述的体系结构通过以下特性支持大规模操作。
1. There is no need for a unicast exchange to provide data keys to a security protocol for members who have previously registered in the particular group; data keys can be pushed in the rekey protocol.
1. 不需要单播交换为先前在特定组中注册的成员提供安全协议的数据密钥；数据密钥可以在rekey协议中推送。
2. The registration and rekey protocols are separable to allow flexibility in how members receive group secrets. A group may use a smart-card based system in place of the registration protocol, for example, to allow the rekey protocol to be used with no back channel for broadcast applications such as television conditional access systems.
2. 注册和密钥更新协议是可分离的，以允许成员灵活地接收组机密。一个组可以使用基于智能卡的系统来代替注册协议，例如，允许在没有反向信道的情况下使用密钥更新协议，用于诸如电视条件接收系统之类的广播应用。
3. The registration and rekey protocols support new keys, algorithms, authentication mechanisms and authorization infrastructures in the architecture. When the authorization infrastructure supports delegation, as in X.509 and SPKI, the GCKS function can be distributed as shown in Figure 3 below.
3. 注册和重新密钥协议支持体系结构中的新密钥、算法、身份验证机制和授权基础设施。当授权基础设施支持委托时，如X.509和SPKI中所示，GCKS功能可以分布，如下图3所示。
The first feature in the list allows fast keying of data security protocols when the member already belongs to the group. While this is realistic for subscriber groups and customers of service providers who offer content events, it may be too restrictive for applications that allow member enrollment at the time of the event. The MSEC group key management architecture suggests hierarchically organized key distribution to handle potential mass simultaneous registration requests. The Figure 3 configuration may be needed when conventional clustering and load balancing solutions of a central GCKS site cannot meet customer requirements. Unlike conventional caching and content
列表中的第一个功能允许在成员已属于组时快速键入数据安全协议。虽然这对于提供内容活动的订户组和服务提供商的客户来说是现实的，但对于允许在活动时注册成员的应用程序来说，这可能限制太多。MSEC组密钥管理体系结构建议分层组织密钥分发，以处理潜在的大规模同时注册请求。当中央GCKS站点的传统集群和负载平衡解决方案无法满足客户需求时，可能需要图3配置。与传统的缓存和内容不同
distribution networks, however, the configuration shown in Figure 3 has additional security ramifications for physical security of a GCKS.
然而，图3所示的配电网配置对GCKS的物理安全具有额外的安全影响。
+----------------------------------------+
| +-------+ |
| | GCKS | |
| +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| +-------------+ |
| | | |
| v ... v |
| +-------+ +-------+ |
| | GCKS | | GCKS | |
| +-------+ +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| ... |
+----------------------------------------+
+----------------------------------------+
| +-------+ |
| | GCKS | |
| +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| +-------------+ |
| | | |
| v ... v |
| +-------+ +-------+ |
| | GCKS | | GCKS | |
| +-------+ +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| ... |
+----------------------------------------+
Figure 3: Hierarchically Organized Key Distribution
图3：分层组织的密钥分发
More analysis and work is needed on the protocol instantiations of the group key management architecture, to determine how effectively and securely the architecture can support large-scale multicast applications. In addition to being as secure as pairwise key management against man-in-the-middle, replay, and reflection attacks, group key management protocols have additional security needs. Unlike pairwise key management, group key management needs to be secure against attacks by group members who attempt to impersonate a GCKS or disrupt the operation of a GCKS, as well as by non-members.
需要对组密钥管理体系结构的协议实例进行更多的分析和工作，以确定该体系结构如何有效和安全地支持大规模多播应用。除了对中间人攻击、重播攻击和反射攻击进行成对密钥管理一样安全外，组密钥管理协议还具有额外的安全需求。与成对密钥管理不同，组密钥管理需要防止试图模拟GCKS或中断GCKS操作的组成员以及非成员的攻击。
Thus, secure groups need to converge to a common group key when members are attacking the group, joining and leaving the group, or being evicted from the group. Group key management protocols also need to be robust when DoS attacks or network partition leads to large numbers of synchronized requests. An instantiation of group key management, therefore, needs to consider how GCKS operation might be distributed across multiple GCKSs designated by the group owner to serve keys on behalf of a designated GCKS. GSAKMP [GSAKMP] protocol uses the policy token and allows designating some of the members as subordinate GCKSs to address this scalability issue.
因此，当成员攻击组、加入和离开组或被逐出组时，安全组需要收敛到公共组密钥。当DoS攻击或网络分区导致大量同步请求时，组密钥管理协议也需要健壮。因此，组密钥管理的实例化需要考虑GCKS操作如何分布在由组所有者指定的多个GCKSS上，以代表指定的GCKS服务密钥。GSAKMP[GSAKMP]协议使用策略令牌，并允许将一些成员指定为下级GCKSs，以解决此可伸缩性问题。
This memo describes MSEC key management architecture. This architecture will be instantiated in one or more group key management protocols, which must be protected against man-in-the-middle, connection hijacking, replay, or reflection of past messages, and denial of service attacks.
本备忘录描述了MSEC密钥管理体系结构。该体系结构将在一个或多个组密钥管理协议中实例化，这些协议必须受到保护，以防中间人、连接劫持、重播或反映过去的消息以及拒绝服务攻击。
Authenticated key exchange [STS,SKEME,RFC2408,RFC2412,RFC2409] techniques limit the effects of man-in-the-middle and connection hijacking attacks. Sequence numbers and low-computation message authentication techniques can be effective against replay and reflection attacks. Cookies [RFC2522], when properly implemented, provide an efficient means to reduce the effects of denial of service attacks.
认证密钥交换[STS、SKEME、RFC2408、RFC2412、RFC2409]技术限制中间人攻击和连接劫持攻击的影响。序列号和低计算量消息认证技术可以有效地抵御重放和反射攻击。Cookie[RFC2522]在正确实施时，提供了一种有效的方法来减少拒绝服务攻击的影响。
This memo does not address attacks against key management or security protocol implementations such as so-called type attacks that aim to disrupt an implementation by such means as buffer overflow. The focus of this memo is on securing the protocol, not on implementing the protocol.
本备忘录不涉及针对密钥管理或安全协议实现的攻击，如所谓的类型攻击，其目的是通过缓冲区溢出等方式破坏实现。本备忘录的重点是保护协议，而不是实施协议。
While classical techniques of authenticated key exchange can be applied to group key management, new problems arise with the sharing of secrets among a group of members: group secrets may be disclosed by a member of the group, and group senders may be impersonated by other members of the group. Key management messages from the GCKS should not be authenticated using shared symmetric secrets unless all members of the group can be trusted not to impersonate the GCKS or each other. Similarly, members who disclose group secrets undermine the security of the entire group. Group owners and GCKS administrators must be aware of these inherent limitations of group key management.
虽然认证密钥交换的经典技术可以应用于组密钥管理，但在一组成员之间共享秘密会出现新的问题：组秘密可能由组的一个成员披露，组发送者可能由组的其他成员模拟。不应使用共享对称机密对来自GCK的密钥管理消息进行身份验证，除非可以信任组中的所有成员不会模拟GCK或彼此。同样，泄露集团机密的成员会破坏整个集团的安全。组所有者和GCKS管理员必须了解组密钥管理的这些固有限制。
Another limitation of group key management is policy complexity. While peer-to-peer security policy is an intersection of the policy of the individual peers, a group owner sets group security policy
组密钥管理的另一个限制是策略的复杂性。虽然对等安全策略是单个对等方策略的交叉点，但组所有者设置组安全策略
externally in secure groups. This document assumes there is no negotiation of cryptographic or other security parameters in group key management. Group security policy, therefore, poses new risks to members who send and receive data from secure groups. Security administrators, GCKS operators, and users need to determine minimal acceptable levels of security (e.g., authentication and admission policy of the group, key lengths, cryptographic algorithms and protocols used) when joining secure groups.
在外部安全组中。本文档假设在组密钥管理中不存在加密或其他安全参数协商。因此，组安全策略给从安全组发送和接收数据的成员带来了新的风险。在加入安全组时，安全管理员、GCKS操作员和用户需要确定可接受的最低安全级别（例如，组的身份验证和许可策略、密钥长度、加密算法和使用的协议）。
Given the limitations and risks of group security, the security of the group key management registration protocol should be as good as the base protocols on which it is developed, such as IKE, IPsec, TLS, or SSL. The particular instantiations of this group key management architecture must ensure that the high standards for authenticated key exchange are preserved in their protocol specifications, which will be Internet standards-track documents that are subject to review, analysis, and testing.
考虑到组安全性的局限性和风险，组密钥管理注册协议的安全性应与开发它的基础协议（如IKE、IPsec、TLS或SSL）一样好。此组密钥管理体系结构的特定实例必须确保在其协议规范中保留经过身份验证的密钥交换的高标准，该协议规范将是互联网标准，跟踪需要审查、分析和测试的文档。
The second protocol, the group key management rekey protocol, is new and has unknown risks. The source-authentication risks described above are obviated by the use of public-key cryptography. The use of multicast delivery may raise additional security issues such as reliability, implosion, and denial-of-service attacks based upon the use of multicast. The rekey protocol specification needs to offer secure solutions to these problems. Each instantiation of the rekey protocol, such as the GSAKMP Rekey or the GDOI Groupkey-push operations, need to validate the security of their rekey specifications.
第二个协议，组密钥管理重密钥协议，是新的，具有未知的风险。通过使用公钥加密技术，可以避免上述源身份验证风险。使用多播传送可能会引发额外的安全问题，例如基于多播使用的可靠性、内爆和拒绝服务攻击。密钥更新协议规范需要为这些问题提供安全的解决方案。重新密钥协议的每个实例，如GSAKMP重新密钥或GDOI Groupkey推送操作，都需要验证其重新密钥规范的安全性。
Novelty and complexity are the biggest risks to group key management protocols. Much more analysis and experience are needed to ensure that the architecture described in this document can provide a well-articulated standard for security and risks of group key management.
新颖性和复杂性是组密钥管理协议的最大风险。需要更多的分析和经验，以确保本文档中描述的体系结构能够为集团密钥管理的安全性和风险提供清晰的标准。
The GKM Building Block [GKMBB] I-D by SMuG was a precursor to this document; thanks to Thomas Hardjono and Hugh Harney for their efforts. During the course of preparing this document, Andrea Colegrove, Brian Weis, George Gross, and several others in the MSEC WG and GSEC and SMuG research groups provided valuable comments that helped improve this document. The authors appreciate their contributions to this document.
SMuG的GKM构建块[GKBB]I-D是本文件的前身；感谢托马斯·哈乔诺和休·哈尼的努力。在编写本文件的过程中，MSEC工作组、GSEC和SMuG研究小组的Andrea Colegrove、Brian Weis、George Gross和其他几位成员提供了有助于改进本文件的宝贵意见。作者感谢他们对本文件的贡献。
[BatchRekey] Yang, Y. R., et al., "Reliable Group Rekeying: Design and Performance Analysis", Proc. ACM SIGCOMM, San Diego, CA, August 2001.
[BatchRekey]Yang，Y.R.，等，“可靠组更新：设计和性能分析”，Proc。ACM SIGCOMM，加利福尼亚州圣地亚哥，2001年8月。
[CLIQUES] Steiner, M., Tsudik, G., and M. Waidner, "CLIQUES: A New Approach to Group Key Agreement", IEEE ICDCS 97, May 1997
[集团]Steiner，M.，Tsudik，G.和M.Waidner，“集团：集团关键协议的新方法”，IEEE ICDCS 97，1997年5月
[FN93] Fiat, A. and M. Naor, "Broadcast Encryption, Advances in Cryptology", CRYPTO 93 Proceedings, Lecture Notes in Computer Science, Vol. 773, pp. 480-491, 1994.
[FN93]Fiat，A.和M.Naor，“广播加密，密码学进展”，加密93会议录，计算机科学讲稿，第773卷，第480-4911994页。
[GKMBB] Harney, H., M. Baugher, and T. Hardjono, "GKM Building Block: Group Security Association (GSA) Definition," Work in Progress, September 2000.
[GKMBB]Harney，H.，M.Baugher和T.Hardjono，“GKM构建块：集团安全协会（GSA）定义”，正在进行的工作，2000年9月。
[GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., and R. Fleischer, "Group Secure Association Key Management Protocol", Work in Progress, February 2003.
[GSAKMP]Harney，H.，Colegrove，A.，Harder，E.，Meth，U.，和R.Fleischer，“组安全关联密钥管理协议”，正在进行的工作，2003年2月。
[GSPT] Hardjono, T., Harney, H., McDaniel, P., Colegrove, A., and P. Dinsmore, "The MSEC Group Security Policy Token", Work in Progress, August 2003.
[GSPT]Hardjono，T.，Harney，H.，McDaniel，P.，Colegrove，A.，和P.Dinsmore，“MSEC集团安全策略令牌”，正在进行的工作，2003年8月。
[H.235] International Telecommunications Union, "Security and Encryption for H-Series (H.323 and other H.245-based) Multimedia Terminals", ITU-T Recommendation H.235 Version 3, Work in progress, 2001.
[H.235]国际电信联盟，“H系列（H.323和其他基于H.245的）多媒体终端的安全和加密”，ITU-T建议H.235第3版，正在进行的工作，2001年。
[JKKV94] Just, M., Kranakis, E., Krizanc, D., and P. van Oorschot, "On Key Distribution via True Broadcasting", Proc. 2nd ACM Conference on Computer and Communications Security, pp. 81-88, November 1994.
[JKKV94]Just，M.，Kranakis，E.，Krizanc，D.，和P.van Oorschot，“通过真实广播进行密钥分发”，Proc。第二届ACM计算机和通信安全会议，第81-88页，1994年11月。
[MARKS] Briscoe, B., "MARKS: Zero Side Effect Multicast Key Management Using Arbitrarily Revealed Key Sequences", Proc. First International Workshop on Networked Group Communication (NGC), Pisa, Italy, November 1999.
[MARKS]Briscoe，B.，“MARKS:使用任意公开密钥序列的零副作用多播密钥管理”，Proc。1999年11月在意大利比萨举行的第一次网络化群体通信国际讲习班。
[MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[MIKEY]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“MIKEY:多媒体互联网键控”，RFC 3830，2004年8月。
[MSEC-Arch] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[MSEC Arch]Hardjono，T.和B.Weis，“多播组安全架构”，RFC 3740，2004年3月。
[MVV] Menzes, A.J., van Oorschot, P.C., and S.A. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1996.
[MVV]Menzes，A.J.，van Oorschot，P.C.，和S.A.Vanstone，“应用密码学手册”，CRC出版社，1996年。
[NORM] Adamon, B., Bormann, C., Handley, M., and J. Macker, "Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November 2004.
[NORM]Adamon，B.，Bormann，C.，Handley，M.，和J.Macker，“面向否定确认（NACK）的可靠多播（NORM）协议”，RFC 39402004年11月。
[OFT] Balenson, D., McGrew, P.C., and A. Sherman, "Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization", IRTF Work in Progress, August 2000.
[OFT]Balenson，D.，McGrew，P.C.，和A.Sherman，“大型动态组的密钥管理：单向函数树和摊销初始化”，IRTF正在进行的工作，2000年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，“组密钥管理协议（GKP）体系结构”，RFC 2094，1997年7月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327]Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367]McDonald，D.，Metz，C.，和B.Phan，“PF_密钥管理API，版本2”，RFC 2367，1998年7月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]Orman，H.，“奥克利密钥确定协议”，RFC 2412，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月。
[RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999.
[RFC2693]Ellison，C.，Frantz，B.，Lampson，B.，Rivest，R.，Thomas，B.，和T.Ylonen，“SPKI证书理论”，RFC 26931999年9月。
[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月。
[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.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[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月。
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[RFC3450]Luby，M.，Gemmell，J.，Vicisano，L.，Rizzo，L.，和J.Crowcroft，“异步分层编码（ALC）协议实例化”，RFC 3450，2002年12月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[SD1] Naor, D., Naor, M., and J. Lotspiech, "Revocation and Tracing Schemes for Stateless Receiver", Advances in Cryptology - CRYPTO, Santa Barbara, CA: Springer-Verlag Inc., LNCS 2139, August 2001.
[SD1]Naor，D.，Naor，M.，和J.Lotspiech，“无状态接收器的撤销和跟踪方案”，密码学进展-加密，加利福尼亚州圣巴巴拉：Springer Verlag Inc.，LNCS 21392001年8月。
[SD2] Naor, M. and B. Pinkas, "Efficient Trace and Revoke Schemes", Proceedings of Financial Cryptography 2000, Anguilla, British West Indies, February 2000.
[SD2]Naor，M.和B.Pinkas，“有效追踪和撤销方案”，2000年金融加密会议录，英属西印度群岛安圭拉，2000年2月。
[Self-Healing] Staddon, J., et. al., "Self-healing Key Distribution with Revocation", Proc. 2002 IEEE Symposium on Security and Privacy, Oakland, CA, May 2002.
[自愈]Staddon，J.等人，“具有撤销功能的自愈密钥分发”，Proc。2002年IEEE安全和隐私研讨会，加利福尼亚州奥克兰，2002年5月。
[SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", ISOC Secure Networks and Distributed Systems Symposium, San Diego, 1996.
[SKEME]H.Krawczyk，“SKEME：一种通用的互联网安全密钥交换机制”，ISOC安全网络和分布式系统研讨会，圣地亚哥，1996年。
[STS] Diffie, P. van Oorschot, M., and J. Wiener, "Authentication and Authenticated Key Exchanges", Designs, Codes and Cryptography, 2, 107-125 (1992), Kluwer Academic Publishers.
[STS]Diffie，P.van Oorschot，M.和J.Wiener，“认证和认证密钥交换”，设计、代码和密码学，2107-125（1992），Kluwer学术出版社。
[TAXONOMY] Canetti, R., et. al., "Multicast Security: A Taxonomy and some Efficient Constructions", IEEE INFOCOM, 1999.
[TAXONOMY]Canetti，R.，et.al.，“多播安全：一种分类法和一些有效的构造”，IEEE INFOCOM，1999年。
[TESLA-INFO] Perrig, A., Canetti, R., Song, D., Tygar, D., and B. Briscoe, "TESLA: Multicast Source Authentication Transform Introduction", Work in Progress, December 2004.
[TESLA-INFO]Perrig，A.，Canetti，R.，Song，D.，Tygar，D.，和B.Briscoe，“特斯拉：多播源认证转换介绍”，正在进行的工作，2004年12月。
[TESLA-SPEC] Perrig, A., R. Canetti, and Whillock, "TESLA: Multicast Source Authentication Transform Specification", Work in Progress, April 2002.
[TESLA-SPEC]Perrig，A.，R.Canetti和Whillock，“TESLA：多播源认证转换规范”，正在进行的工作，2002年4月。
[tGSAKMP] Harney, H., et. al., "Tunneled Group Secure Association Key Management Protocol", Work in Progress, May 2003.
[tGSAKMP]Harney，H.等人，“隧道组安全关联密钥管理协议”，正在进行的工作，2003年5月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0," RFC 2246, January 1999.
[TLS]Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[TPM] Marks, D. and B. Turnbull, "Technical protection measures: The Intersection of Technology, Law, and Commercial Licenses", Workshop on Implementation Issues of the WIPO Copyright Treaty (WCT) and the WIPO Performances and Phonograms Treaty (WPPT), World Intellectual Property Organization, Geneva, December 6 and 7, 1999.
[TPM]Marks，D.和B.Turnbull，“技术保护措施：技术、法律和商业许可的交叉点”，《世界知识产权组织版权条约》（WCT）和《世界知识产权组织表演和录音制品条约》（WPPT）实施问题研讨会，世界知识产权组织，日内瓦，1999年12月6日和7日。
[Wool] Wool, A., "Key Management for Encrypted broadcast", 5th ACM Conference on Computer and Communications Security, San Francisco, CA, Nov. 1998.
[羊毛]羊毛，A，“加密管理的密钥管理”，第五ACM计算机与通信安全会议，旧金山，CA，1998月11日。
Authors' Addresses
作者地址
Mark Baugher Cisco Systems 5510 SW Orchid St. Portland, OR 97219, USA
Mark Baugher Cisco Systems美国波特兰西南兰花街5510号或97219号
Phone: +1 408-853-4418
EMail: mbaugher@cisco.com
Phone: +1 408-853-4418
EMail: mbaugher@cisco.com
Ran Canetti IBM Research 30 Saw Mill River Road Hawthorne, NY 10532, USA
Ran Canetti IBM Research 30 Saw Mill River Road Hawthorne，NY 10532，美国
Phone: +1 914-784-7076
EMail: canetti@watson.ibm.com
Phone: +1 914-784-7076
EMail: canetti@watson.ibm.com
Lakshminath R. Dondeti Qualcomm 5775 Morehouse Drive San Diego, CA 92121
Lakshminath R.Dondeti高通公司加利福尼亚州圣地亚哥莫尔豪斯大道5775号，邮编92121
Phone: +1 858 845 1267
EMail: ldondeti@qualcomm.com
Phone: +1 858 845 1267
EMail: ldondeti@qualcomm.com
Fredrik Lindholm Ericsson Research SE-16480 Stockholm, Sweden
Fredrik Lindholm Ericsson Research SE-16480瑞典斯德哥尔摩
Phone: +46 8 58531705
EMail: fredrik.lindholm@ericsson.com
Phone: +46 8 58531705
EMail: fredrik.lindholm@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。