Network Working Group T. Hardjono
Request for Comments: 3740 Verisign
Category: Informational B. Weis
Cisco
March 2004
Network Working Group T. Hardjono
Request for Comments: 3740 Verisign
Category: Informational B. Weis
Cisco
March 2004
The Multicast Group Security Architecture
组播组安全体系结构
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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast Security Reference Framework, and proceeds to identify the security services that may be part of a secure multicast solution.
本文档提供了用于保护大型多播组数据包的多播安全体系结构的概述和基本原理。本文档首先介绍一个多播安全参考框架，然后确定可能是安全多播解决方案一部分的安全服务。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Summary of Contents of Document. . . . . . . . . . . . . 3
1.3. Audience . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
2. Architectural Design: The Multicast Security Reference
Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Reference Framework. . . . . . . . . . . . . . . . . 4
2.2. Elements of the Centralized Reference Framework. . . . . 5
2.2.1. Group Controller and Key Server. . . . . . . . . 6
2.2.2. Sender and Receiver. . . . . . . . . . . . . . . 7
2.2.3. Policy Server. . . . . . . . . . . . . . . . . . 7
2.3. Elements of the Distributed Reference Framework. . . . . 8
3. Functional Areas . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 9
3.2. Group Key Management . . . . . . . . . . . . . . . . . . 10
3.3. Multicast Security Policies. . . . . . . . . . . . . . . 11
4. Group Security Associations (GSA). . . . . . . . . . . . . . . 12
4.1. The Security Association . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Summary of Contents of Document. . . . . . . . . . . . . 3
1.3. Audience . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
2. Architectural Design: The Multicast Security Reference
Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Reference Framework. . . . . . . . . . . . . . . . . 4
2.2. Elements of the Centralized Reference Framework. . . . . 5
2.2.1. Group Controller and Key Server. . . . . . . . . 6
2.2.2. Sender and Receiver. . . . . . . . . . . . . . . 7
2.2.3. Policy Server. . . . . . . . . . . . . . . . . . 7
2.3. Elements of the Distributed Reference Framework. . . . . 8
3. Functional Areas . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 9
3.2. Group Key Management . . . . . . . . . . . . . . . . . . 10
3.3. Multicast Security Policies. . . . . . . . . . . . . . . 11
4. Group Security Associations (GSA). . . . . . . . . . . . . . . 12
4.1. The Security Association . . . . . . . . . . . . . . . . 12
4.2. Structure of a GSA: Introduction . . . . . . . . . . . . 13
4.3. Structure of a GSA: Reasoning. . . . . . . . . . . . . . 14
4.4. Definition of GSA. . . . . . . . . . . . . . . . . . . . 15
4.5. Typical Compositions of a GSA. . . . . . . . . . . . . . 17
5. Security Services. . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Multicast Data Confidentiality . . . . . . . . . . . . . 18
5.2. Multicast Source Authentication and Data Integrity . . . 18
5.3. Multicast Group Authentication . . . . . . . . . . . . . 19
5.4. Multicast Group Membership Management. . . . . . . . . . 19
5.5. Multicast Key Management . . . . . . . . . . . . . . . . 20
5.6. Multicast Policy Management. . . . . . . . . . . . . . . 21
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
6.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 22
6.2. Group Key Management . . . . . . . . . . . . . . . . . . 22
6.3. Multicast Security Policies. . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 23
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
4.2. Structure of a GSA: Introduction . . . . . . . . . . . . 13
4.3. Structure of a GSA: Reasoning. . . . . . . . . . . . . . 14
4.4. Definition of GSA. . . . . . . . . . . . . . . . . . . . 15
4.5. Typical Compositions of a GSA. . . . . . . . . . . . . . 17
5. Security Services. . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Multicast Data Confidentiality . . . . . . . . . . . . . 18
5.2. Multicast Source Authentication and Data Integrity . . . 18
5.3. Multicast Group Authentication . . . . . . . . . . . . . 19
5.4. Multicast Group Membership Management. . . . . . . . . . 19
5.5. Multicast Key Management . . . . . . . . . . . . . . . . 20
5.6. Multicast Policy Management. . . . . . . . . . . . . . . 21
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
6.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 22
6.2. Group Key Management . . . . . . . . . . . . . . . . . . 22
6.3. Multicast Security Policies. . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 23
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
Securing IP multicast group communication is a complex task that involves many aspects. Consequently, a secure IP multicast protocol suite must have a number of functional areas that address different aspects of the solution. This document describes those functional areas and how they are related.
保护IP多播组通信是一项涉及多个方面的复杂任务。因此，安全的IP多播协议套件必须具有多个功能区域，以解决解决方案的不同方面。本文档描述了这些功能领域以及它们之间的关系。
This architecture is concerned with the securing of large multicast groups. Whereas it can also be used for smaller groups, it is not necessarily the most efficient means. Other architectures (e.g., the Cliques architecture [STW]) can be more efficient for small ad-hoc group communication.
该体系结构涉及大型多播组的安全。虽然它也可以用于较小的群体，但它不一定是最有效的手段。其他体系结构（例如，集团体系结构[STW]）可以更有效地用于小型特设组通信。
This architecture is "end to end", and does not require multicast routing protocols (e.g., PIM [RFC2362]) to participate in this architecture. Inappropriate routing may cause denial of service to application layer groups conforming to this architecture. However the routing cannot affect the authenticity or secrecy of group data or management packets. The multicast routing protocols could themselves use this architecture to protect their own multicast and group packets. However, this would be independent of any secure application layer group.
这种架构是“端到端”的，不需要多播路由协议（例如PIM[RFC2362]）来参与这种架构。不适当的路由可能会导致拒绝服务到符合此体系结构的应用层组。但是，路由不能影响组数据或管理数据包的真实性或保密性。组播路由协议本身可以使用这种架构来保护自己的组播和分组数据包。但是，这将独立于任何安全应用程序层组。
This architecture does not require IP multicast admission control protocols (e.g., IGMP [RFC3376], MLD [RFC3019]) to be a part of secure multicast groups. As such, a "join" or "leave" operation for a secure group is independent of a "join" or "leave" of an IP multicast group. For example, the process of joining a secure group requires being authenticated and authorized by a security device, while the process of joining an IP multicast group entails contacting a multicast-aware router. Admission control protocols could themselves use this architecture to protect their own multicast packets. However, this would be independent of any secure application layer group.
该体系结构不要求IP多播接纳控制协议（例如，IGMP[RFC3376]，MLD[RFC3019]）成为安全多播组的一部分。因此，安全组的“加入”或“离开”操作独立于IP多播组的“加入”或“离开”。例如，加入安全组的过程需要由安全设备进行身份验证和授权，而加入IP多播组的过程需要联系多播感知路由器。接纳控制协议本身可以使用这种架构来保护自己的多播数据包。但是，这将独立于任何安全应用程序层组。
This architecture does not explicitly describe how secure multicast groups deal with Network Address Translation (NAT) [RFC2663]. Multicast routing protocols generally require the source and destination addresses and ports of an IP multicast packet to remain unchanged. This allows consistent multicast distribution trees to be created throughout the network. If NAT is used in a network, then the connectivity of senders and receivers may be adversely affected. This situation is neither improved or degraded as a result of deploying this architecture.
该体系结构没有明确描述安全多播组如何处理网络地址转换（NAT）[RFC2663]。多播路由协议通常要求IP多播数据包的源地址、目标地址和端口保持不变。这允许在整个网络中创建一致的多播分发树。如果网络中使用NAT，则发送方和接收方的连接可能会受到不利影响。部署此体系结构不会改善或降低这种情况。
This architecture does not require the use of reliable mechanisms, for either data or management protocols. The use of reliable multicast routing techniques (e.g., FEC [RFC3453]) enhance the availability of secure multicast groups. However the authenticity or secrecy of group data or management packets is not affected by the omission of that capability from a deployment.
这种体系结构不需要对数据或管理协议使用可靠的机制。使用可靠的多播路由技术（例如，FEC[RFC3453]）可以提高安全多播组的可用性。但是，组数据或管理数据包的真实性或保密性不受部署中省略该功能的影响。
This document provides an architectural overview that outlines the security services required to secure large multicast groups. It provides a Reference Framework for organizing the various elements within the architecture, and explains the elements of the Reference Framework.
本文档提供了架构概述，概述了保护大型多播组所需的安全服务。它提供了一个参考框架，用于组织体系结构中的各种元素，并解释了参考框架的元素。
The Reference Framework organizes the elements of the architecture along three Functional Areas pertaining to security. These elements cover the treatment of data when it is to be sent to a group, the management of keying material used to protect the data, and the policies governing a group.
参考框架沿着与安全性相关的三个功能区域组织架构的元素。这些要素包括将数据发送到组时对数据的处理、用于保护数据的键控材料的管理以及管理组的策略。
Another important item in this document is the definition and explanation of Group Security Associations (GSA), which is the multicast counterpart of the unicast Security Association (SA). The GSA is specific to multicast security, and is the foundation of the work on group key management.
本文档中的另一个重要项目是组安全关联（GSA）的定义和解释，它是单播安全关联（SA）的多播对应物。GSA是特定于组播安全的，是组密钥管理工作的基础。
This document is addressed to the technical community, implementers of IP multicast security technology, and others interested in gaining a general background understanding of multicast security. This document assumes that the reader is familiar with the Internet Protocol, the IPsec suite of protocols (e.g., [RFC2401]), related networking technology, and general security terms and concepts.
本文档面向技术社区、IP多播安全技术的实现者以及其他有兴趣了解多播安全的一般背景知识的人。本文档假设读者熟悉互联网协议、IPsec协议套件（例如，[RFC2401]）、相关网络技术以及一般安全术语和概念。
The following key terms are used throughout this document.
本文件中使用了以下关键术语。
1-to-N
1对N
A group which has one sender and many receivers.
有一个发送者和多个接收者的组。
Group Security Association (GSA)
集团安全协会（GSA）
A bundling of Security Associations (SAs) that together define how a group communicates securely. The GSA may include a registration protocol SA, a rekey protocol SA, and one or more data security protocol SAs.
安全关联（SA）的捆绑，共同定义组如何安全通信。GSA可以包括注册协议SA、密钥更新协议SA和一个或多个数据安全协议SA。
M-to-N
M-to-N
A group which has many senders and many receivers, where M and N are not necessarily the same value.
具有多个发送方和多个接收方的组，其中M和N不一定是相同的值。
Security Association (SA)
保安协会（SA）
A set of policy and cryptographic keys that provide security services to network traffic that matches that policy.
一组策略和加密密钥，为与该策略匹配的网络流量提供安全服务。
This section considers the complex issues of multicast security in the context of a Reference Framework. This Reference Framework is used to classify functional areas, functional elements, and interfaces. Two designs of the Reference Framework are shown: a centralized design, and a distributed design that extends the centralized design for very large groups.
本节将在参考框架的上下文中考虑多播安全的复杂问题。该参考框架用于对功能区域、功能元素和接口进行分类。本文展示了参考框架的两种设计：一种是集中式设计，另一种是分布式设计，将集中式设计扩展到非常大的组。
The Reference Framework is based on three broad functional areas (as shown in Figure 1). The Reference Framework incorporates the main entities and functions relating to multicast security, and depicts
参考框架基于三个广泛的功能领域（如图1所示）。参考框架包含了与多播安全相关的主要实体和功能，并描述了
the inter-relations among them. It also expresses multicast security from the perspective of multicast group types (1-to-N and M-to-N), and classes of protocols (the exchanged messages) needed to secure multicast packets.
它们之间的相互关系。它还从多播组类型（1-to-N和M-to-N）和保护多播数据包所需的协议类（交换的消息）的角度来表示多播安全性。
The aim of the Reference Framework is to provide some general context around the functional areas, and the relationships between the functional areas. Note that some issues span more than one functional area. In fact, the framework encourages the precise identification and formulation of issues that involve more than one functional area or those which are difficult to express in terms of a single functional area. An example of such a case is the expression of policies concerning group keys, which involves both the functional areas of group key management and multicast policies.
参考框架的目的是围绕功能领域以及功能领域之间的关系提供一些一般背景。请注意，有些问题跨越多个功能领域。事实上，该框架鼓励准确确定和提出涉及一个以上职能领域或难以用单一职能领域表达的问题。这种情况的一个例子是关于组密钥的策略的表达，它涉及组密钥管理和多播策略的功能领域。
When considering the Reference Framework diagrams, it is important to realize that the singular "boxes" in the framework do not necessarily imply a corresponding singular entity implementing a given function. Rather, a box in the framework should be interpreted loosely as pertaining to a given function related to a functional area. Whether that function is in reality implemented as one or more physical entities is dependent on the particular solution. As an example, the box labeled "Key Server" must be interpreted in broad terms as referring to the functions of key management.
在考虑参考框架图时，重要的是要认识到框架中的单数“框”并不一定意味着实现给定功能的对应单数实体。相反，框架中的一个框应该被松散地解释为与某个功能区域相关的给定功能相关。该功能实际上是否实现为一个或多个物理实体取决于特定的解决方案。例如，标签为“密钥服务器”的框必须广义地解释为指密钥管理的功能。
Similarly, the Reference Framework acknowledges that some implementations may in fact merge a number of the "boxes" into a single physical entity. This could be true even across functional areas. For example, an entity in a group could act as both a Group Controller and a Sender to a group.
类似地，参考框架承认，一些实现实际上可能将多个“框”合并到单个物理实体中。即使是跨职能领域的情况也可能如此。例如，组中的实体可以同时充当组控制器和组的发送者。
The protocols to be standardized are depicted in the Reference Framework diagrams by the arrows that connect the various boxes. See more details in Section 4, below.
要标准化的协议在参考框架图中通过连接各个框的箭头进行描述。详见下文第4节。
The Reference Framework diagram of Figure 1 contains boxes and arrows. The boxes are the functional entities and the arrows are the interfaces between them. Standard protocols are needed for the interfaces, which support the multicast services between the functional entities.
图1的参考框架图包含方框和箭头。框是功能实体，箭头是它们之间的接口。接口需要标准协议，支持功能实体之间的多播服务。
In some cases, a system implementing the multicast security architecture may not need to implement protocols to account for every interface. Rather, those interfaces may be satisfied through the use of manual configuration, or even omitted if they are not necessary for the application.
在某些情况下，实现多播安全体系结构的系统可能不需要实现协议来说明每个接口。相反，可以通过使用手动配置来满足这些接口，如果应用程序不需要这些接口，甚至可以省略这些接口。
There are three sets of functional entities. Each is discussed below.
有三组功能实体。下文将对每一种情况进行讨论。
+--------------------------------------+
| |
| |
| FUNCTIONAL |
| AREAS |
| |
| +------+ |
| Multicast |Policy| |
| Security |Server| |
| Policies +------+ |
| ^ |
| | |
| | |
| v |
| +------+ |
| Group |Group | |
| Key |Ctrl/ |<---------+ |
| Management |Key | | |
| |Server| V |
| +------+ +--------+ |
| ^ | | |
| | |Receiver| |
| | | | |
| v +--------+ |
| +------+ ^ |
| | | | |
| Multicast |Sender|----------+ |
| Data | | |
| Handling | | |
| +------+ |
| |
+--------------------------------------+
+--------------------------------------+
| |
| |
| FUNCTIONAL |
| AREAS |
| |
| +------+ |
| Multicast |Policy| |
| Security |Server| |
| Policies +------+ |
| ^ |
| | |
| | |
| v |
| +------+ |
| Group |Group | |
| Key |Ctrl/ |<---------+ |
| Management |Key | | |
| |Server| V |
| +------+ +--------+ |
| ^ | | |
| | |Receiver| |
| | | | |
| v +--------+ |
| +------+ ^ |
| | | | |
| Multicast |Sender|----------+ |
| Data | | |
| Handling | | |
| +------+ |
| |
+--------------------------------------+
Figure 1: Centralized Multicast Security Reference Framework
图1：集中式多播安全参考框架
The Group Controller and Key Server (GCKS) represent both the entity and functions relating to the issuance and management of cryptographic keys used by a multicast group. The GCKS also conducts user-authentication and authorization checks on the candidate members of the multicast group.
组控制器和密钥服务器（GCKS）代表与多播组使用的加密密钥的发布和管理相关的实体和功能。GCKS还对多播组的候选成员进行用户身份验证和授权检查。
The Key Server (KS) and the Group Controller (GC) have somewhat different functionality and may in principle be regarded as separate entities. Currently the framework regards the two entities as one "box" in order to simplify the design, and in order not to mandate standardization of the protocol between the KS and the GC. It is stressed that the KS and GC need not be co-located. Furthermore, future designs may choose to standardize the protocol between the GC and the KS, without altering other components.
密钥服务器（KS）和组控制器（GC）具有一些不同的功能，并且原则上可以被视为单独的实体。目前，该框架将两个实体视为一个“盒子”，以简化设计，并且不强制KS和GC之间的协议标准化。需要强调的是，KS和GC无需位于同一地点。此外，未来的设计可能会选择标准化GC和KS之间的协议，而不改变其他组件。
The Sender is an entity that sends data to the multicast group. In a 1-to-N multicast group only a single sender is authorized to transmit data to the group. In an M-to-N multicast group, two or more group members are authorized to be senders. In some groups all members are authorized as senders.
发送方是向多播组发送数据的实体。在1对N多播组中，只有一个发送方被授权向该组传输数据。在M-to-N多播组中，两个或多个组成员被授权为发送者。在某些组中，所有成员都被授权为发件人。
Both Sender and Receiver must interact with the GCKS entity for the purpose of key management. This includes user and/or device authentication, user and/or device authorization, the obtaining of keying material in accordance with some key management policies for the group, obtaining new keys during key-updates, and obtaining other messages relating to the management of keying material and security parameters.
出于密钥管理的目的，发送方和接收方必须与GCKS实体进行交互。这包括用户和/或设备认证、用户和/或设备授权、根据组的一些密钥管理策略获取密钥材料、在密钥更新期间获取新密钥以及获取与密钥材料和安全参数管理相关的其他消息。
Senders and Receivers may receive much of their policy from the GCKS entities. The event of joining a multicast group is typically coupled with the Sender/Receiver obtaining keying material from a GCKS entity. This does not preclude the direct interaction between the Sender/Receiver and the Policy Server.
发送方和接收方可能会从GCKS实体接收其大部分策略。加入多播组的事件通常与从GCKS实体获取密钥材料的发送方/接收方耦合。这并不排除发送方/接收方与策略服务器之间的直接交互。
The Policy Server represents both the entity and functions used to create and manage security policies specific to a multicast group. The Policy Server interacts with the GCKS entity in order to install and manage the security policies related to the membership of a given multicast group and those related to keying material for a multicast group.
策略服务器表示用于创建和管理特定于多播组的安全策略的实体和函数。策略服务器与GCKS实体交互，以便安装和管理与给定多播组的成员资格相关的安全策略以及与多播组的密钥材料相关的安全策略。
The interactions between the Policy Server and other entities in the Reference Framework is dependent to a large extent on the security circumstances being addressed by a given policy.
策略服务器与参考框架中其他实体之间的交互在很大程度上取决于给定策略所处理的安全环境。
The need for solutions to be scalable to large groups across wide geographic regions of the Internet requires the elements of the framework to also function as a distributed system. Figure 2 shows how distributed designs supporting large group scalability fit into the Reference Framework.
解决方案需要可扩展到互联网广泛地理区域的大型群体，这就要求框架的元素也能作为分布式系统发挥作用。图2显示了支持大组可伸缩性的分布式设计如何适应参考框架。
+-----------------------------------------------------------------+
| |
| |
| FUNCTIONAL |
| AREAS |
| +------+ +------+ |
| Multicast |Policy|<-------------------------------->|Policy| |
| Security |Server| |Server| |
| Policies +------+ +------+ |
| ^ ^ |
| | | |
| | | |
| v v |
| +------+ +------+ |
| Group |Group |<-------------------------------> |Group | |
| Key |Ctrl/ |<---------+ |Ctlr/ | |
| Management |Key | | |Key | |
| |Server| V |Server| |
| +------+ +--------+ +------+ |
| ^ | | ^ |
| | |Receiver| | |
| | | | | |
| v +--------+ | |
| +------+ ^ V |
| | | | +--------+ |
| Multicast |Sender|----------+ | | |
| Data | |-------------------------------->|Receiver| |
| Handling | | | | |
| +------+ +--------+ |
+-----------------------------------------------------------------+
+-----------------------------------------------------------------+
| |
| |
| FUNCTIONAL |
| AREAS |
| +------+ +------+ |
| Multicast |Policy|<-------------------------------->|Policy| |
| Security |Server| |Server| |
| Policies +------+ +------+ |
| ^ ^ |
| | | |
| | | |
| v v |
| +------+ +------+ |
| Group |Group |<-------------------------------> |Group | |
| Key |Ctrl/ |<---------+ |Ctlr/ | |
| Management |Key | | |Key | |
| |Server| V |Server| |
| +------+ +--------+ +------+ |
| ^ | | ^ |
| | |Receiver| | |
| | | | | |
| v +--------+ | |
| +------+ ^ V |
| | | | +--------+ |
| Multicast |Sender|----------+ | | |
| Data | |-------------------------------->|Receiver| |
| Handling | | | | |
| +------+ +--------+ |
+-----------------------------------------------------------------+
Figure 2: Distributed Multicast Security Reference Framework
图2：分布式多播安全参考框架
In a distributed design the GCKS entity interacts with other GCKS entities to achieve scalability in the key management related services. GCKS entities will require a means of authenticating their peer GCKS entities, a means of authorization, and a means of interacting securely to pass keys and policy.
在分布式设计中，GCKS实体与其他GCKS实体交互，以实现密钥管理相关服务的可伸缩性。GCKS实体将需要一种对其对等GCKS实体进行身份验证的方法、一种授权方法以及一种安全交互以传递密钥和策略的方法。
Similarly, Policy Servers must interact with each other securely to allow the communication and enforcement of policies across the Internet.
同样，策略服务器必须彼此安全地交互，以允许在Internet上进行策略通信和执行。
Two Receiver boxes are displayed corresponding to the situation where both the Sender and Receiver employ the same GCKS entity (centralized architecture) and where the Sender and Receiver employ different GCKS entities (distributed architecture). In the distributed design, all Receivers must obtain identical keys and policy. Each member of a multicast group may interact with a primary GCKS entity (e.g., the "nearest" GCKS entity, measured in terms of a well-defined and consistent metric). Similarly, a GCKS entity may interact with one or more Policy Servers, also arranged in a distributed architecture.
显示两个接收者框，对应于发送者和接收者采用相同的GCKS实体（集中式体系结构）和发送者和接收者采用不同的GCKS实体（分布式体系结构）的情况。在分布式设计中，所有接收器必须获得相同的密钥和策略。多播组的每个成员都可以与主GCKS实体（例如，“最近的”GCKS实体，根据定义良好且一致的度量进行度量）交互。类似地，GCKS实体可以与一个或多个策略服务器交互，策略服务器也布置在分布式体系结构中。
The Reference Framework identifies three functional areas. They are:
参考框架确定了三个功能领域。他们是：
- Multicast data handling. This area covers the security-related treatments of multicast data by the sender and the receiver. This functional area is further discussed in Section 3.1.
- 多播数据处理。此区域涵盖发送方和接收方对多播数据的安全相关处理。第3.1节将进一步讨论该功能领域。
- Group Key Management. This area is concerned with the secure distribution and refreshment of keying material. This functional area is further discussed in Section 3.2.
- 组密钥管理。该区域涉及密钥材料的安全分发和更新。第3.2节将进一步讨论该功能领域。
- Multicast Security Policies. This area covers aspects of policy in the context of multicast security, taking into consideration the fact that policies may be expressed in different ways: that they may exist at different levels in a given multicast security architecture, and that they may be interpreted differently according to the context in which they are specified and implemented. This functional area is further discussed in Section 3.3.
- 多播安全策略。本领域涵盖多播安全上下文中的策略方面，考虑到策略可能以不同的方式表达：它们可能存在于给定多播安全体系结构的不同级别，并且，根据其具体规定和实施的环境，可以对其进行不同的解释。第3.3节将进一步讨论该功能领域。
In a secure multicast group, the data typically needs to be:
在安全多播组中，数据通常需要：
1. Encrypted using the group key, mainly for access control and possibly also for confidentiality. 2. Authenticated, for verifying the source and integrity of the data. Authentication takes two flavors: a. Source authentication and data integrity. This functionality guarantees that the data originated with the claimed source and was not modified en route (either by a group member or an external attacker).
1. 使用组密钥加密，主要用于访问控制，也可能用于保密。2.已验证，用于验证数据的来源和完整性。身份验证有两种风格：a。源身份验证和数据完整性。此功能可确保数据来源于声明的源，并且在传输过程中未被修改（由组成员或外部攻击者）。
b. Group authentication. This type of authentication only guarantees that the data was generated (or last modified) by some group member. It does not guarantee data integrity unless all group members are trusted.
b. 组身份验证。这种类型的身份验证只保证数据是由某个组成员生成（或上次修改）的。除非所有组成员都受信任，否则不能保证数据完整性。
While multicast encryption and group authentication are fairly standard and similar to encrypting and authenticating a point-to-point communication, source authentication for multicast is considerably more involved. Consequently, off-the-shelf solutions (e.g., taken from IPsec [RFC2406]) may be sufficient for encryption and group authentication. For source authentication, however, special-purpose transformations are necessary. See [CCPRRS] for further elaboration on the concerns regarding the data transforms.
虽然多播加密和组身份验证是相当标准的，并且类似于对点到点通信进行加密和身份验证，但多播的源身份验证涉及的问题要多得多。因此，现成的解决方案（例如，取自IPsec[RFC2406]）可能足以用于加密和组身份验证。但是，对于源身份验证，需要进行特殊用途的转换。请参阅[CCPRRS]以进一步了解有关数据转换的问题。
Multicast data encrypted and/or authenticated by a sender should be handled the same way by both centralized and distributed receivers, (as shown in Figure 2).
由发送方加密和/或认证的多播数据应由集中式和分布式接收方以相同的方式处理（如图2所示）。
The "Multicast Encapsulating Security Payload" [BCCR] provides the definition for Multicast ESP for data traffic. The "Multicast Source Authentication Transform Specification" [PCW] defines the use of the TESLA algorithm for source authentication in multicast.
“多播封装安全有效负载”[BCCR]为数据流量的多播ESP提供了定义。“多播源认证转换规范”[PCW]定义了在多播中使用特斯拉算法进行源认证。
The term "keying material" refers to the cryptographic keys belonging to a group, the state associated with the keys, and the other security parameters related to the keys. Hence, the management of the cryptographic keys belonging to a group necessarily requires the management of their associated state and parameters. A number of solutions for specific issues must be addressed. These may include the following:
术语“密钥材料”是指属于组的加密密钥、与密钥相关联的状态以及与密钥相关联的其他安全参数。因此，属于组的加密密钥的管理必然需要对其关联状态和参数进行管理。必须解决一些具体问题的解决办法。这些措施可能包括：
- Methods for member identification and authentication. - Methods to verify the membership to groups. - Methods to establish a secure channel between a GCKS entity and the member, for the purpose of delivery of shorter-term keying material pertaining to a group. - Methods to establish a long-term secure channel between one GCKS entity and another, for the purpose of distributing shorter-term keying material pertaining to a group. - Methods to effect the changing of keys and keying material. - Methods to detect and signal failures and perceived compromises to keys and keying material.
- 成员身份识别和认证方法。-验证组成员身份的方法。-在GCKS实体和成员之间建立安全通道的方法，用于交付与组有关的短期密钥材料。-在一个GCKS实体和另一个GCKS实体之间建立长期安全通道的方法，用于分发与组有关的短期密钥材料。-更改键和键控材料的方法。-检测和发出故障信号的方法以及对钥匙和钥匙材料的感知损害。
The requirements related to the management of keying material must be seen in the context of the policies that prevail within the given circumstance.
与键控材料管理相关的要求必须在给定情况下盛行的政策背景下考虑。
Core to the area of key management is Security Association (SA) Management, which will be discussed further below.
密钥管理领域的核心是安全协会（SA）管理，下面将进一步讨论。
A "Group Key Management Architecture" document [BCDL] further defines the key management architecture for multicast security. It builds on the Group Security Association (GSA) concept, and further defines the roles of the Key Server and Group Controller.
“组密钥管理体系结构”文档[BCDL]进一步定义了多播安全的密钥管理体系结构。它建立在组安全关联（GSA）概念的基础上，并进一步定义了密钥服务器和组控制器的角色。
"The Group Domain of Interpretation" [RFC3547], "GSAKMP" [GSAKMP], and "MIKEY" [ACLNM] are three instances of protocols implementing the group key management function.
“组解释域”[RFC3547]、“GSAKMP”[GSAKMP]和“MIKEY”[ACLNM]是实现组密钥管理功能的协议的三个实例。
Multicast Security Policies must provide the rules for operation for the other elements of the Reference Framework. Security Policies may be distributed in an ad-hoc fashion in some instances. However, better coordination and higher levels of assurance are achieved if a Policy Controller distributes Security Policies policy to the group.
多播安全策略必须为参考框架的其他元素提供操作规则。在某些情况下，安全策略可能以特别方式分发。但是，如果策略控制器向组分发安全策略，则可以实现更好的协调和更高级别的保证。
Multicast security policies must represent, or contain, more information than a traditional peer-to-peer policy. In addition to representing the security mechanisms for the group communication, the policy must also represent the rules for the governance of the secure group. For example, policy would specify the authorization level necessary in order for an entity to join a group. More advanced operations would include the conditions when a group member must be forcibly removed from the group, and what to do if the group members need to resynchronize because of lost key management messages.
多播安全策略必须表示或包含比传统对等策略更多的信息。除了表示组通信的安全机制外，策略还必须表示安全组的治理规则。例如，策略将指定实体加入组所需的授权级别。更高级的操作包括必须从组中强制删除组成员时的条件，以及如果组成员由于丢失密钥管理消息而需要重新同步时该怎么办。
The application of policy at the Group Controller element and the member (sender and receiver) elements must be described. While there is already a basis for security policy management in the IETF, multicast security policy management extends the concepts developed for unicast communication in the areas of:
必须说明组控制器元素和成员（发送方和接收方）元素上策略的应用。虽然IETF中已经有了安全策略管理的基础，但多播安全策略管理在以下领域扩展了为单播通信开发的概念：
- Policy creation, - High-level policy translation, and - Policy representation.
- 策略创建、高级策略转换和策略表示。
Examples of work in multicast security policies include the Dynamic Cryptographic Context Management project [Din], Group Key Management Protocol [Har1, Har2], and Antigone [McD].
多播安全策略方面的工作示例包括动态加密上下文管理项目[Din]、组密钥管理协议[Har1，Har2]和Antigone[McD]。
Policy creation for secure multicast has several more dimensions than the single administrator specified policy assumed in the existing unicast policy frameworks. Secure multicast groups are usually large and by their very nature extend over several administrative domains,
安全多播的策略创建比现有单播策略框架中假定的单个管理员指定的策略具有更多的维度。安全多播组通常比较大，其本质是扩展到多个管理域，
if not spanning a different domain for each user. There are several methods that need to be considered in the creation of a single, coherent group security policy. They include a top-down specification of the group policy from the group initiator and negotiation of the policy between the group members (or prospective members). Negotiation can be as simple as a strict intersection of the policies of the members or extremely complicated using weighted voting systems.
如果没有为每个用户跨越不同的域。在创建单一、一致的组安全策略时，需要考虑几种方法。它们包括来自组发起人的组策略自上而下的规范，以及组成员（或潜在成员）之间的策略协商。谈判可以是成员国政策的严格交叉，也可以是使用加权投票系统进行的极其复杂的谈判。
The translation of policy rules from one data model to another is much more difficult in a multicast group environment. This is especially true when group membership spans multiple administrative domains. Policies specified at a high level with a Policy Management tool must be translated into more precise rules that the available security policy mechanisms can both understand and implement. When dealing with multicast communication and its multiple participants, it is essential that the individual translation performed for each participant result in the use of a mechanism that is interoperable with the results of all of the other translations. Typically, the translation from high-level policy to specific policy objects must result in the same objects in order to achieve communication between all of the group members. The requirement that policy translation results in the same objects places constraints on the use and representations in the high-level policies.
在多播组环境中，将策略规则从一个数据模型转换到另一个数据模型要困难得多。当组成员身份跨越多个管理域时尤其如此。必须将使用策略管理工具在较高级别指定的策略转换为可用安全策略机制可以理解和实现的更精确的规则。在处理多播通信及其多个参与者时，为每个参与者执行的单个翻译必须使用一种与所有其他翻译结果可互操作的机制。通常，从高级策略到特定策略对象的转换必须产生相同的对象，以实现所有组成员之间的通信。策略转换导致相同对象的要求对高级策略中的使用和表示施加了限制。
It is also important that policy negotiation and translation be performed as an integral part of joining a group. Adding a member to a group is meaningless if they will not be able to participate in the group communications.
政策谈判和翻译作为加入集团的一个组成部分也很重要。如果一个成员不能参与组通信，那么将其添加到组中是没有意义的。
A security association is a commonly used term in cryptographic systems (e.g., [RFC2401, RFC2406bis, RFC2409]). This document uses the term to mean any set of policy and cryptographic keys that provide security services for the network traffic matching that policy. A Security Association usually contains the following attributes:
安全关联是密码系统（例如，[RFC2401、RFC2406bis、RFC2409]）中常用的术语。本文档使用该术语表示为与该策略匹配的网络流量提供安全服务的任何策略和加密密钥集。安全关联通常包含以下属性：
- selectors, such as source and destination transport addresses. - properties, such as an security parameter index (SPI) or cookie pair, and identities. - cryptographic policy, such as the algorithms, modes, key lifetimes, and key lengths used for authentication or confidentiality. - keys, such as authentication, encryption and signing keys.
- 选择器，例如源和目标传输地址。-属性，例如安全参数索引（SPI）或cookie对，以及标识。-加密策略，例如用于身份验证或机密性的算法、模式、密钥生存期和密钥长度。-密钥，例如身份验证、加密和签名密钥。
Group key management uses a different set of abstractions than point-to-point key management systems (such as IKE [RFC2409]). Notwithstanding, the abstractions used in the Group Key Management functional area may be built from the point-to-point key management abstractions.
组密钥管理使用与点对点密钥管理系统（如IKE[RFC2409]）不同的抽象集。尽管如此，在组密钥管理功能区域中使用的抽象可以从点到点密钥管理抽象构建。
Security associations (SAs) for group key management are more complex, and are usually more numerous, than for point-to-point key management algorithms. The latter establishes a key management SA to protect application SAs (usually one or two, depending on the protocol). However, group key management may require up to three or more SAs. These SAs are described in later sections.
用于组密钥管理的安全关联（SA）比用于点到点密钥管理算法的安全关联（SA）更复杂，并且通常数量更多。后者建立密钥管理SA以保护应用程序SA（通常一个或两个，取决于协议）。但是，组密钥管理可能需要最多三个或更多SA。这些SA将在后面的章节中介绍。
A GSA contains all of the SA attributes identified in the previous section, as well some additional attributes pertaining to the group. As shown in Figure 3, the GSA builds on the SA in two distinct ways.
GSA包含上一节中确定的所有SA属性，以及与组相关的一些附加属性。如图3所示，GSA以两种不同的方式构建在SA上。
- First, the GSA is a superset of an SA (Figure 3(a)). A GSA has group policy attributes. For example, the kind of signed credentials needed for group membership, whether group members will be given new keys when a member is added (called "backward re-key" below), or whether group members will be given new keys when a member is removed from the group ("forward re-key"). A GSA also includes an SA as an attribute of itself.
- 首先，GSA是SA的超集（图3（a））。GSA具有组策略属性。例如，组成员资格所需的签名凭据的类型，添加成员时是否为组成员提供新密钥（下文称为“向后重新密钥”），或从组中删除成员时是否为组成员提供新密钥（“向前重新密钥”）。GSA还包括SA作为其自身属性。
- Second, the GSA is an aggregation of SAs (Figure 3(b)). A GSA is comprised of multiple SAs, and these SAs may be used for several independent purposes.
- 其次，GSA是SA的集合（图3（b））。GSA由多个SA组成，这些SA可用于多个独立目的。
+---------------+ +-------------------+
| GSA | | GSA |
| | | +-----+ +-----+ |
| | | | SA1 | | SA2 | |
| +----+ | | +-----+ +-----+ |
| | SA | | | +-----+ |
| +----+ | | | SA3 | |
| | | +-----+ |
+---------------+ +-------------------+
+---------------+ +-------------------+
| GSA | | GSA |
| | | +-----+ +-----+ |
| | | | SA1 | | SA2 | |
| +----+ | | +-----+ +-----+ |
| | SA | | | +-----+ |
| +----+ | | | SA3 | |
| | | +-----+ |
+---------------+ +-------------------+
(a) superset (b) aggregation
(a) 超集（b）聚合
Figure 3: Relationship of GSA to SA
图3:GSA与SA的关系
Figure 4 shows three categories of SAs that can be aggregated into a GSA.
图4显示了可以聚合到GSA中的三类SA。
+------------------------------------------------------------+
| |
| +------------------+ |
| | GCKS | |
| | | |
| | REG REG | |
| | / REKEY \ | |
| +---/-----|----\---+ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| +----------/------+ | +------\----------+ |
| | REG | | | REG | |
| | REKEY-----+----REKEY | |
| | Sender | | Receiver | |
| | DATA----------DATA | |
| +-----------------+ +-----------------+ |
| |
| |
+------------------------------------------------------------+
+------------------------------------------------------------+
| |
| +------------------+ |
| | GCKS | |
| | | |
| | REG REG | |
| | / REKEY \ | |
| +---/-----|----\---+ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| +----------/------+ | +------\----------+ |
| | REG | | | REG | |
| | REKEY-----+----REKEY | |
| | Sender | | Receiver | |
| | DATA----------DATA | |
| +-----------------+ +-----------------+ |
| |
| |
+------------------------------------------------------------+
Figure 4: GSA Structure and 3 categories of SAs
图4:GSA结构和3类SAs
The three categories of SAs are:
SA的三个类别是：
- Registration SA (REG): A separate unicast SA between the GCKS and each group member, regardless of whether the group member is a sender or a receiver or acting in both roles.
- 注册SA（REG）：GCK和每个组成员之间的单独单播SA，无论该组成员是发送者还是接收者，或同时担任这两个角色。
- Re-key SA (REKEY): A single multicast SA between the GCKS and all of the group members.
- 重设SA密钥（重设密钥）：GCK和所有组成员之间的单个多播SA。
- Data Security SA (DATA): A multicast SA between each multicast source speaker and the group's receivers. There may be as many data SAs as there are multicast sources allowed by the group's policy.
- 数据安全SA（Data）：每个多播源说话人和组的接收器之间的多播SA。组策略允许的多播源的数量可能与数据SA的数量相同。
Each of these SAs are defined in more detail in the next section.
在下一节中将对每个SA进行更详细的定义。
The three categories of SAs correspond to three different kinds of communications commonly required for group communications. This section describes the SAs depicted in Figure 4 in detail.
三类SA对应于组通信通常需要的三种不同类型的通信。本节详细描述了图4所示的SAs。
- Registration SA (REG): An SA is required for (bi-directional) unicast communications between the GCKS and a group member (be it a Sender or Receiver). This SA is established only between the GCKS and a Member. The GCKS entity is charged with access control to the group keys, with policy distribution to members (or prospective members), and with group key dissemination to Sender and Receiver members. This use of a (unicast) SA as a starting point for key management is common in a number of group key management environments [RFC3547, GSAKMP, CCPRRS, RFC2627, BMS].
- 注册SA（REG）：GCK和组成员（无论是发送方还是接收方）之间的（双向）单播通信需要SA。此SA仅在GCK和成员之间建立。GCKS实体负责对组密钥的访问控制、向成员（或潜在成员）分发策略以及向发送方和接收方成员分发组密钥。使用（单播）SA作为密钥管理的起点在许多组密钥管理环境中很常见[RFC3547、GSAKMP、CCPRRS、RFC2627、BMS]。
The Registration SA is initiated by the member to pull GSA information from the GCKS. This is how the member requests to join the secure group, or has its GSA keys re-initialized after being disconnected from the group (e.g., when its host computer has been turned off during re-key operations). The GSA information pulled down from the GCKS is related to the other two SAs defined as part of the GSA.
注册SA由会员发起，以从GCK获取GSA信息。这是成员请求加入安全组的方式，或者在与组断开连接后（例如，在重新设置密钥操作期间其主机已关闭）重新初始化其GSA密钥的方式。从GCKS下拉的GSA信息与定义为GSA一部分的其他两个SA相关。
Note that this (unicast) SA is used to protect the other elements of the GSA. As such, the Registration SA is crucial and is inseparable from the other two SAs in the definition of a GSA.
请注意，此（单播）SA用于保护GSA的其他元素。因此，注册SA至关重要，在GSA的定义中与其他两个SA不可分割。
However, the requirement of a registration SA does not imply the need of a registration protocol to create that Registration SA. The registration SA could instead be setup through some manual means, such as distributed on a smart card. Thus, what is important is that a Registration SA exists, and is used to protect the other SAs.
但是，注册SA的要求并不意味着需要注册协议来创建该注册SA。注册SA可以通过一些手动方式设置，例如在智能卡上分发。因此，重要的是注册SA存在，并用于保护其他SA。
From the perspective of one given GCKS, there are as many unique registration SAs as there are members (Senders and/or Receivers) in the group. This may constitute a scalability concern for some applications. A registration SA may be established on-demand with a short lifetime, whereas re-key and data security SAs are established at least for the life of the sessions that they support.
从一个给定GCK的角度来看，组中的成员（发送者和/或接收者）数量与唯一注册SA数量相同。对于某些应用程序来说，这可能是一个可伸缩性问题。注册SA可以在短生命周期内按需建立，而重新密钥和数据安全SA至少在其支持的会话的生命周期内建立。
Conversely the registration SA could be left in place for the duration of the group lifetime, if scalability is not an issue. Such a long term registration SA would be useful for re-synchronization or deregistration purposes.
相反，如果可伸缩性不是问题，则注册SA可以在组生存期内保持不变。这样的长期注册SA将有助于重新同步或注销。
- Re-key SA (REKEY): In some cases, a GCKS needs the ability to "push" new SAs as part of the GSA. These new SAs must be sent to all group members. In other cases, the GCKS needs the ability to quickly revoke access to one or more group members. Both of these needs are satisfied with the Re-key SA.
- 为SA重新设置密钥（重新设置密钥）：在某些情况下，GCKS需要能够“推送”新SA作为GSA的一部分。必须将这些新SA发送给所有组成员。在其他情况下，GCKS需要能够快速撤销对一个或多个组成员的访问权限。这两种需求都通过重新设置SA密钥得到了满足。
This Re-key SA is a unidirectional multicast transmission of key management messages from the GCKS to all group members. As such, this SA is known by the GCKS and by all members of the group.
该重密钥SA是从GCK到所有组成员的密钥管理消息的单向多播传输。因此，GCK和集团所有成员都知道该SA。
This SA is not negotiated, since all the group members must share it. Thus, the GCKS must be the authentic source and act as the sole point of contact for the group members to obtain this SA.
此SA未经协商，因为所有集团成员都必须共享。因此，GCK必须是真实来源，并作为集团成员获取本SA的唯一联络点。
A rekey SA is not absolutely required to be part of a GSA. For example, the lifetime of some groups may be short enough such that a rekey is not necessary. Conversely, the policy for the group could specify multiple rekey SAs of different types. For example, if the GC and KS are separate entities, the GC may deliver rekey messages that adjust the group membership, and the KS may deliver rekey messages with new DATA SAs.
重新注册的SA不一定是GSA的一部分。例如，某些组的生存期可能足够短，因此不需要重新设置密钥。相反，组的策略可以指定不同类型的多个重新设置密钥SA。例如，如果GC和KS是单独的实体，则GC可以发送调整组成员资格的密钥更新消息，KS可以发送具有新数据SA的密钥更新消息。
- Data Security SA (DATA): The Data Security SA protects data between member senders and member receivers.
- 数据安全SA（Data）：数据安全SA保护成员发送方和成员接收方之间的数据。
One or more SAs are required for the multicast transmission of data-messages from the Sender to other group members. This SA is known by the GCKS and by all members of the group.
从发送方到其他组成员的数据消息的多播传输需要一个或多个SA。GCK和集团所有成员都知道该SA。
Regardless of the number of instances of this third category of SA, this SA is not negotiated. Rather, all group members obtain it from the GCKS. The GCKS itself does not use this category of SA.
无论第三类SA的实例数量如何，都不会协商此SA。相反，所有小组成员都从GCK获得该信息。GCKS本身不使用此类SA。
From the perspective of the Receivers, there is at least one data security SA for the member sender (one or more) in the group. If the group has more than one data security SA, the data security protocol must have a means of differentiating the SAs (e.g., with a SPI).
从接收者的角度来看，组中的成员发送者（一个或多个）至少有一个数据安全SA。如果集团有多个数据安全SA，则数据安全协议必须具有区分SA的方法（例如，使用SPI）。
There are a number of possibilities with respect to the number of data security SAs:
关于数据安全SA的数量，存在多种可能性：
1. Each sender in the group could be assigned a unique data security SA, thereby resulting in each receiver having to maintain as many data security SAs as there are senders in the group. In this case, each sender may be verified using source origin authentication techniques.
1. 可以为组中的每个发送方分配唯一的数据安全SA，从而导致每个接收方必须维护与组中发送方数量相同的数据安全SA。在这种情况下，可以使用源认证技术来验证每个发送方。
2. The entire group deploys a single data security SA for all senders. Receivers would then be able to maintain only one data security SA.
2. 整个组为所有发件人部署一个数据安全SA。然后，接收器将只能维护一个数据安全SA。
3. A combination of 1. and 2.
3. 1的组合。二,。
Depending on the multicast group policy, many compositions of a GSA are possible. For illustrative purposes, this section describes a few possible compositions.
根据多播组策略，GSA的许多组合是可能的。为了便于说明，本节描述了几种可能的组合。
- A group of memory-constrained members may require only a REG SA, and a single DATA SA. - A "pay-per-session" application, where all of the SA information needed for the session may be distributed over a REG SA. Re-key and re-initialization of DATA SAs may not be necessary, so there is no REKEY SA. - A subscription group, where keying material is changed as membership changes. A REG SA is needed to distribute other SAs; a REKEY SA is needed to re-initialize a DATA SA at the time membership changes.
- 一组内存受限的成员可能只需要一个REG SA和一个数据SA。-“按会话付费”应用程序，其中会话所需的所有SA信息可通过REG SA分发。可能不需要重新设置数据SA的密钥和重新初始化，因此不需要重新设置SA的密钥。-订阅组，其中键控材质随成员资格的更改而更改。需要REG SA来分发其他SA；在成员资格更改时，需要重新设置SA密钥以重新初始化数据SA。
This section identifies security services for designated interfaces of Figure 2. Distinct security services are assigned to specific interfaces. For example, multicast source authentication, data authentication, and confidentiality occur on the multicast data interface between Senders and Receivers in Figure 2. Authentication and confidentiality services may also be needed between the Key Server and group members (i.e., the Senders and Receivers of Figure 2), but the services that are needed for multicast key management may be unicast as well as multicast. A security service in the Multicast Security Reference Framework therefore identifies a specific function along one or more Figure 2 interfaces.
本节确定了图2指定接口的安全服务。不同的安全服务被分配给特定的接口。例如，多播源身份验证、数据身份验证和机密性发生在图2中发送方和接收方之间的多播数据接口上。密钥服务器和组成员（即图2的发送方和接收方）之间也可能需要身份验证和保密服务，但多播密钥管理所需的服务可能是单播的，也可能是多播的。因此，多播安全参考框架中的安全服务沿着一个或多个图2接口标识特定功能。
This paper does not attempt to analyze the trust relationships, detailed functional requirements, performance requirements, suitable algorithms, and protocol specifications for IP multicast and application-layer multicast security. Instead, that work will occur as the security services are further defined and realized in algorithms and protocols.
本文不试图分析IP多播和应用层多播安全的信任关系、详细的功能需求、性能需求、合适的算法和协议规范。相反，随着安全服务在算法和协议中的进一步定义和实现，这项工作将发生。
This security service handles the encryption of multicast data at the Sender's end and the decryption at the Receiver's end. This security service may also apply the keying material that is provided by Multicast Key Management in accordance with Multicast Policy Management, but it is independent of both.
此安全服务处理发送方端的多播数据加密和接收方端的解密。该安全服务还可以根据多播策略管理应用由多播密钥管理提供的密钥材料，但它独立于两者。
An important part of the Multicast Data Confidentiality security service is in the identification of and motivation for specific ciphers that should be used for multicast data. Obviously, not all ciphers will be suitable for IP multicast and application-layer multicast traffic. Since this traffic will usually be connectionless UDP flows, stream ciphers may be unsuitable, though hybrid stream/block ciphers may have advantages over some block ciphers.
多播数据保密安全服务的一个重要部分是识别和激励应用于多播数据的特定密码。显然，并非所有密码都适用于IP多播和应用层多播流量。由于此流量通常是无连接的UDP流，因此流密码可能不合适，尽管混合流/块密码可能比某些块密码有优势。
Regarding application-layer multicast, some consideration is needed to consider the effects of sending encrypted data in a multicast environment lacking admission-control, where practically any application program can join a multicast event independently of its participation in a multicast security protocol. Thus, this security service is also concerned with the effects of multicast confidentiality services (intended and otherwise) on application programs. Effects to both Senders and Receivers are considered.
关于应用层组播，需要考虑在没有准入控制的多播环境中发送加密数据的影响，实际上，任何应用程序可以独立于其参与多播安全协议而加入多播事件。因此，该安全服务还涉及多播保密服务（有意或无意）对应用程序的影响。考虑了对发送方和接收方的影响。
In Figure 2, the Multicast Data Confidentiality security service is placed in Multicast Data Handling Area along the interface between Senders and Receivers. The algorithms and protocols that are realized from work on this security service may be applied to other interfaces and areas of Figure 2 when multicast data confidentiality is needed.
在图2中，多播数据机密性安全服务沿着发送方和接收方之间的接口放置在多播数据处理区域中。当需要多播数据保密性时，在该安全服务上实现的算法和协议可应用于图2的其他接口和区域。
This security service handles source authentication and integrity verification of multicast data. It includes the transforms to be made both at the Sender's end and at the Receiver's end. It assumes that the appropriate signature and verification keys are provided via Multicast Key Management in accordance with Multicast Policy Management as described below. This is one of the harder areas of multicast security due to the connectionless and real-time
此安全服务处理多播数据的源身份验证和完整性验证。它包括在发送方端和接收方端进行的转换。它假设根据如下所述的多播策略管理，通过多播密钥管理提供适当的签名和验证密钥。由于无连接性和实时性，这是多播安全的难点之一
requirements of many IP multicast applications. There are classes of application-layer multicast security, however, where offline source and data authentication will suffice. As discussed previously, not all multicast applications require real-time authentication and data-packet integrity. A robust solution to multicast source and data authentication, however, is necessary for a complete solution to multicast security.
许多IP多播应用的需求。然而，有一些应用层多播安全级别，离线源和数据身份验证就足够了。如前所述，并非所有多播应用程序都需要实时身份验证和数据包完整性。然而，一个可靠的多播源和数据认证解决方案对于一个完整的多播安全解决方案是必要的。
In Figure 2, the Multicast Source and Data Authentication security service is placed in Multicast Data Handling Area along the interface between Senders and Receivers. The algorithms and protocols that are produced for this functional area may have applicability to security services in other functional area that use multicast services such as Group Key Management.
在图2中，多播源和数据认证安全服务沿着发送方和接收方之间的接口放置在多播数据处理区域中。为该功能区域产生的算法和协议可适用于使用多播服务（例如组密钥管理）的其他功能区域中的安全服务。
This security service provides a limited amount of authenticity of the transmitted data: It only guarantees that the data originated with (or was last modified by) one of the group members. It does not guarantee authenticity of the data in case that other group members are not trusted.
此安全服务提供有限数量的传输数据的真实性：它仅保证数据源自（或上次由）组成员之一。在其他组成员不受信任的情况下，它不能保证数据的真实性。
The advantage of group authentication is that it is guaranteed via relatively simple and efficient cryptographic transforms. Therefore, when source authentication is not paramount, group authentication becomes useful. In addition, performing group authentication is useful even when source authentication is later performed: it provides a simple-to-verify weak integrity check that is useful as a measure against denial-of-service attacks.
组身份验证的优点是通过相对简单和高效的密码转换来保证。因此，当源身份验证不是最重要的时，组身份验证变得非常有用。此外，即使在以后执行源身份验证时，执行组身份验证也很有用：它提供了一个简单的弱完整性验证检查，可用于抵御拒绝服务攻击。
The Multicast Group Authentication security service is placed in the Multicast Data Handling Area along the interface between Senders and Receivers.
多播组身份验证安全服务位于发送方和接收方之间接口的多播数据处理区域中。
This security service describes the functionality of registration of members with the Group Controller, and de-registration of members from the Group Controller. These are security functions, which are independent from IP multicast group "join" and "leave" operations that the member may need to perform as a part of group admission control protocols (i.e., IGMP [RFC3376], MLD [RFC3019]).
此安全服务描述向组控制器注册成员以及从组控制器注销成员的功能。这些是安全功能，独立于IP多播组“加入”和“离开”操作，成员可能需要作为组准入控制协议的一部分执行这些操作（即IGMP[RFC3376]，MLD[RFC3019]）。
Registration includes member authentication, notification and negotiation of security parameters, and logging of information according to the policies of the group controller and the would-be
注册包括成员身份验证、通知和协商安全参数，以及根据集团控制器和潜在客户的策略记录信息
member. (Typically, an out-of-band advertisement of group information would occur before the registration takes place. The registration process will typically be invoked by the would-be member.)
成员（通常，组信息的带外广告会在注册之前出现。注册过程通常由潜在成员调用。）
De-registration may occur either at the initiative of the member or at the initiative of the group controller. It would result in logging of the de-registration event by the group controller and an invocation of the appropriate mechanism for terminating the membership of the de-registering member (see Section 5.5).
取消注册可由成员或集团控制人主动进行。这将导致集团控制器记录注销事件，并调用相应机制终止注销成员的成员资格（见第5.5节）。
This security service also describes the functionality of the communication related to group membership among different GCKS servers in a distributed group design.
此安全服务还描述了分布式组设计中不同GCKS服务器之间与组成员身份相关的通信功能。
In Figure 2, the Multicast Group Membership security service is placed in the Group Key Management Area and has interfaces to Senders and Receivers.
在图2中，多播组成员身份安全服务位于组密钥管理区域中，并具有与发送方和接收方的接口。
This security service describes the functionality of distributing and updating the cryptographic keying material throughout the life of the group. Components of this security service may include:
此安全服务描述在组的整个生命周期内分发和更新加密密钥材料的功能。此安全服务的组件可能包括：
- GCKS to group member (Sender or Receiver) notification regarding current keying material (e.g., group encryption and authentication keys, auxiliary keys used for group management, keys for source authentication, etc.). - Updating of current keying material, depending on circumstances and policies. - Termination of groups in a secure manner, including the secure group itself and the associated keying material.
- GCK向集团成员（发送方或接收方）发出关于当前密钥材料的通知（例如，集团加密和身份验证密钥、用于集团管理的辅助密钥、用于源身份验证的密钥等）——根据情况和政策，更新当前键入材料。-以安全方式终止组，包括安全组本身和相关密钥材料。
Among the responsibilities of this security service is the secure management of keys between Key Servers and group members, the addressing issues for the multicast distribution of keying material, and the scalability or other performance requirements for multicast key management [RFC2627, BMS]. Key Servers and group members may take advantage of a common Public Key Infrastructure (PKI) for increased scalability of authentication and authorization.
该安全服务的职责包括密钥服务器和组成员之间密钥的安全管理、密钥材料的多播分发的解决问题以及多播密钥管理的可扩展性或其他性能要求[RFC2627，BMS]。密钥服务器和组成员可以利用公共公钥基础设施（PKI）来提高身份验证和授权的可扩展性。
To allow for an interoperable and secure IP multicast security protocol, this security service may need to specify host abstractions such as a group security association database (GSAD) and a group security policy database (GSPD) for IP multicast security. The degree of overlap between IP multicast and application-layer multicast key management needs to be considered. Thus, this security service takes into account the key management requirements for IP
为了允许互操作和安全的IP多播安全协议，此安全服务可能需要指定主机抽象，例如用于IP多播安全的组安全关联数据库（GSAD）和组安全策略数据库（GSPD）。需要考虑IP多播和应用层多播密钥管理之间的重叠程度。因此，此安全服务考虑了IP的密钥管理要求
multicast, the key management requirements for application-layer multicast, and to what degree specific realizations of a Multicast Key Management security service can satisfy both. ISAKMP, moreover, has been designed to be extensible to multicast key management for both IP multicast and application-layer multicast security [RFC2408]. Thus, multicast key management protocols may use the existing ISAKMP standard's Phase 1 and Phase 2 protocols, possibly with needed extensions (such as GDOI [RFC3547] or application-layer multicast security).
多播，应用层多播的密钥管理要求，以及多播密钥管理安全服务的特定实现在多大程度上可以满足这两个要求。此外，ISAKMP被设计为可扩展到IP多播和应用层多播安全的多播密钥管理[RFC2408]。因此，多播密钥管理协议可以使用现有ISAKMP标准的第1阶段和第2阶段协议，可能具有所需的扩展（例如GDOI[RFC3547]或应用层多播安全性）。
This security service also describes the functionality of the communication related to key management among different GCKS servers in a distributed group design.
此安全服务还描述了与分布式组设计中不同GCKS服务器之间的密钥管理相关的通信功能。
Multicast Key Management appears in both the centralized and distributed designs as shown in Figure 2 and is placed in the Group Key Management Area.
多播密钥管理出现在集中式和分布式设计中，如图2所示，并位于组密钥管理区域。
This security service handles all matters related to multicast group policy including membership policy and multicast key management policy. Indeed, one of the first tasks in further defining this security service is identifying the different areas of multicast policy. Multicast Policy Management includes the design of the policy server for multicast security, the particular policy definitions that will be used for IP multicast and application-layer multicast security, and the communication protocols between the Policy Server and the Key Server. This security service may be realized using a standard policy infrastructure such as a Policy Decision Point (PDP) and Policy Enforcement Point (PEP) architecture [RFC2748]. Thus, it may not be necessary to re-invent a separate architecture for multicast security policy. At minimum, however, this security service will be realized in a set of policy definitions, such as multicast security conditions and actions.
此安全服务处理与多播组策略相关的所有事项，包括成员身份策略和多播密钥管理策略。实际上，进一步定义此安全服务的首要任务之一是识别多播策略的不同区域。多播策略管理包括多播安全策略服务器的设计，用于IP多播和应用层多播安全的特定策略定义，以及策略服务器和密钥服务器之间的通信协议。该安全服务可以使用标准的策略基础设施实现，如策略决策点（PDP）和策略实施点（PEP）体系结构[RFC2748]。因此，可能没有必要为多播安全策略重新创建单独的体系结构。但是，该安全服务至少将在一组策略定义中实现，例如多播安全条件和操作。
The Multicast Policy Management security service describes the functionality of the communication between an instance of a GCKS to an instance of the Policy Server. The information transmitted may include policies concerning groups, memberships, keying material definition and their permissible uses, and other information. This security service also describes communication between and among Policy Servers. Group members are not expected to directly participate in this security service. However, this option is not ruled out.
多播策略管理安全服务描述GCKS实例与策略服务器实例之间通信的功能。传输的信息可能包括有关团体、成员资格、密钥材料定义及其允许用途的政策以及其他信息。此安全服务还描述策略服务器之间的通信。组成员不应直接参与此安全服务。然而，这一选择并不排除。
This document describes an architectural framework for protecting multicast and group traffic with cryptographic protocols. Three functional areas are identified within the framework. Each functional area has unique security considerations, and these are discussed below.
本文档描述了使用加密协议保护多播和组通信的体系结构框架。框架内确定了三个功能领域。每个功能区域都有独特的安全注意事项，下面将讨论这些事项。
This architectural framework is end-to-end, and does not rely upon the network that connects group controllers and group members. It also does not attempt to resolve security issues in the unicast or multicast routing infrastructures, or in multicast admission control protocols. As such, denial of service, message deletion, and other active attacks against the unicast or multicast routing infrastructures are not addressed by this framework. Section 1.1 describes the relationship of the network infrastructure to the multicast group security architecture.
此体系结构框架是端到端的，不依赖于连接组控制器和组成员的网络。它也不试图解决单播或多播路由基础设施或多播接纳控制协议中的安全问题。因此，拒绝服务、消息删除和其他针对单播或多播路由基础设施的主动攻击不在该框架中解决。第1.1节描述了网络基础设施与多播组安全体系结构的关系。
Cryptographic protocols protecting multicast data are responsible for providing confidentiality and group authentication. They should also be able to provide source authentication to uniquely identify senders to the group. Replay protection of multicast data is also desirable, but may not always be possible. This is due to the complexity of maintaining replay protection state for multiple senders. Section 3.1 elaborates on the security requirements for this area.
保护多播数据的加密协议负责提供机密性和组身份验证。他们还应该能够提供源身份验证，以唯一地标识组的发件人。多播数据的重播保护也是可取的，但并非总是可能的。这是因为维护多个发送方的重播保护状态非常复杂。第3.1节详细说明了该区域的安全要求。
Group key management protocols provide cryptographic keys and policy to group members. They are responsible for authenticating and authorizing group members before revealing those keys, and for providing confidentiality and authentication of those keys during transit. They are also responsible for providing a means for rekeying the group, in the case that the policy specifies a lifetime for the keys. They also are responsible for revocation of group membership, once one or more group members have had their authorization to be a group member revoked. Section 3.2 describes the security requirements of this area in more detail.
组密钥管理协议向组成员提供加密密钥和策略。他们负责在泄露这些密钥之前对组成员进行身份验证和授权，并负责在传输过程中对这些密钥进行保密和身份验证。在策略指定密钥的生存期的情况下，他们还负责提供重新设置组密钥的方法。一旦一个或多个集团成员的集团成员授权被撤销，他们还负责撤销集团成员资格。第3.2节更详细地描述了该区域的安全要求。
Cryptographic protocols providing multicast security policies are responsible for distributing that policy such that the integrity of the policy is maintained. If the policy itself is confidential, they also are responsible for authenticating group controllers and group members, and providing confidentiality of the policy during transit.
提供多播安全策略的加密协议负责分发该策略，以保持策略的完整性。如果策略本身是机密的，他们还负责验证组控制器和组成员，并在传输过程中提供策略的机密性。
Much of the text in this document was derived from two research papers. The framework for this document came from a paper co-authored by Thomas Hardjono, Ran Canetti, Mark Baugher, and Pete Dinsmore. Description of the GSA came from a document co-authored by Hugh Harney, Mark Baugher, and Thomas Hardjono. George Gross suggested a number of improvements that were included in later versions of this document.
本文中的大部分文本来自两篇研究论文。本文件的框架来自托马斯·哈德乔诺、兰·卡内蒂、马克·鲍格尔和皮特·丁斯莫尔合著的一篇论文。对GSA的描述来自休·哈尼、马克·鲍格尔和托马斯·哈德乔诺合著的一份文件。George Gross提出了一些改进建议，这些改进已包含在本文档的后续版本中。
[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., Shertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Shertler，M.，Schneider，M.和J.Turner，“互联网安全协会和密钥管理协议”，RFC 2408，1998年11月。
[ACLNM] J. Arkko, et. al., "MIKEY: Multimedia Internet KEYing", Work in Progress, December 2003.
[ACLNM]J.Arkko等人，“MIKEY：多媒体互联网键控”，正在进行的工作，2003年12月。
[BCCR] M. Baugher, R. Canetti, P. Cheng, P. Rohatgi, "MESP: A Multicast Framework for the IPsec ESP", Work in Progress, October 2002.
[BCCR]M.Baugher，R.Canetti，P.Cheng，P.Rohatgi，“MESP：IPsec ESP的多播框架”，正在进行的工作，2002年10月。
[BCDL] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, "Group Key Management Architecture", Work in Progress, September 2003.
[BCDL]M.Baugher，R.Canetti，L.Dondeti，F.Lindholm，“组密钥管理体系结构”，正在进行的工作，2003年9月。
[BMS] D. Balenson, D. McGrew, A. Sherman, Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization, http://www.securemulticast.org/draft-balenson-groupkeymgmt-oft-00.txt, Work in Progress, February 1999.
[BMS]D.Balenson，D.McGrew，A.Sherman，大型动态组的密钥管理：单向函数树和摊销初始化，http://www.securemulticast.org/draft-balenson-groupkeymgmt-oft-00.txt，在建工程，1999年2月。
[CCPRRS] Canetti, R., Cheng P. C., Pendarakis D., Rao, J., Rohatgi P., Saha D., "An IPSec-based Host Architecture for Secure Internet Multicast", http://www.isoc.org/isoc/conferences/ndss/2000/ proceedings/028.pdf, NDSS 2000.
[CCPRRS]Canetti，R.，Cheng P.C.，Pendarakis D.，Rao，J.，Rohatgi P.，Saha D.，“基于IPSec的安全互联网多播主机体系结构”，http://www.isoc.org/isoc/conferences/ndss/2000/ 会议记录/028.pdf，NDSS 2000。
[Din] Dinsmore, P., Balenson, D., Heyman, M., Kruus, P., Scace, C., and Sherman, A., "Policy-Based Security Management for Large Dynamic Groups: An Overview of the DCCM Project," DARPA Information Survivability Conference and Exposition, http://download.nai.com/products/media/nai/doc/discex-110199.doc.
[Din]Dinsmore，P.，Balenson，D.，Heyman，M.，Kruus，P.，Scace，C.，和Sherman，A.，“大型动态组基于策略的安全管理：DCCM项目概述”，DARPA信息生存性会议和博览会，http://download.nai.com/products/media/nai/doc/discex-110199.doc.
[GSAKMP] H. Harney, et. al., "GSAKMP", Work in Progress, October 2003.
[GSAKMP]H.Harney等人，“GSAKMP”，正在进行的工作，2003年10月。
[Har1] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[Har1]Harney，H.和C.Muckenhirn，“组密钥管理协议（GKPP）规范”，RFC 2093，1997年7月。
[Har2] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
[Har2]Harney，H.和C.Muckenhirn，“组密钥管理协议（GKPP）体系结构”，RFC 2094，1997年7月。
[McD] McDaniel, P., Honeyman, P., and Prakash, A., "Antigone: A Flexible Framework for Secure Group Communication," Proceedings of the Eight USENIX Security Symposium, pp 99-113, August, 1999.
[McD]McDaniel，P.，Honeyman，P.，和Prakash，A.，“安提戈涅：安全组通信的灵活框架”，八个USENIX安全研讨会论文集，第99-113页，1999年8月。
[PCW] Perrig, A., Canetti, R. and B. Whillock, TESLA: Multicast Source Authentication Transform Specification", Work in Progress, October 2002.
[PCW]Perrig，A.，Canetti，R.和B.Whillock，特斯拉：多播源认证转换规范”，正在进行的工作，2002年10月。
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[RFC2362]Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Liu，C.，Sharma，P.和L.Wei，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2406bis] Kent, S., "IP Encapsulating Security Payload (ESP)", Work in Progress, March 2003.
[RFC2406bis]Kent，S.，“IP封装安全有效负载（ESP）”，正在进行的工作，2003年3月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2627] Wallner, D., Harder, E. and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, September 1998.
[RFC2627]Wallner，D.，Harder，E.和R.Agee，“多播的密钥管理：问题和架构”，RFC 2627，1998年9月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzong, S., Rajan, R. and A. Sastry, "COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[RFC2748]Durham，D.，Ed.，Boyle，J.，Cohen，R.，Herzong，S.，Rajan，R.和A.Sastry，“COPS（公共开放政策服务）协议”，RFC 27482000年1月。
[RFC3019] Haberman, B. and R. Worzella, "IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol", RFC 3019, January 2001.
[RFC3019]Haberman，B.和R.Worzella，“多播侦听器发现协议的IP版本6管理信息库”，RFC 3019，2001年1月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, M., Handley, M. and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453]Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，M.，Handley，M.和J.Crowcroft，“在可靠多播中使用前向纠错（FEC）”，RFC 3453，2002年12月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The Group Domain of Interpretation", RFC 3547, December 2002.
[RFC3547]Baugher，M.，Weis，B.，Hardjono，T.和H.Harney，“解释的集团领域”，RFC 3547，2002年12月。
[STW] M., Steiner, Tsudik, G., Waidner, M., CLIQUES: A New Approach to Group key Agreement, IEEE ICDCS'98 , May 1998.
[STW]M.，Steiner，Tsudik，G.，Waidner，M.，集团：集团密钥协议的新方法，IEEE ICDC'98，1998年5月。
Thomas Hardjono VeriSign 487 E. Middlefield Rd. Mountain View, CA 94043, USA
Thomas Hardjono VeriSign美国加利福尼亚州山景城米德尔菲尔德东路487号，邮编94043
Phone:(650) 426-3204 EMail: thardjono@verisign.com
电话：（650）426-3204电子邮件：thardjono@verisign.com
Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706, USA
Brian Weis Cisco Systems美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134-1706
Phone: (408) 526-4796 EMail: bew@cisco.com
电话：（408）526-4796电子邮件：bew@cisco.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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编辑功能的资金目前由互联网协会提供。