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
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.
このアーキテクチャは、安全なマルチキャストグループの一部である（例えば、IGMP [RFC3376] MLD [RFC3019]）を、IPマルチキャストアドミッション制御プロトコルを必要としません。このように、「結合」または「結合」とは無関係である安全なグループのための操作を「残す」又は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.
リファレンスフレームワークは、セキュリティに関係する3つの機能領域に沿って建築の要素を整理します。それはグループ、データを保護するために使用される材料をキーイングの管理、およびグループを管理するポリシーに送信するときに、これらの要素は、データの治療をカバーしています。
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.
この文書に記載されているもう一つの重要な項目は、ユニキャストセキュリティアソシエーション（SA）のマルチキャスト対応です。グループセキュリティアソシエーション（GSA）の定義と説明です。 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.
1つの送信者と多くの受信機を持つグループ。
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、および1つまたは複数のデータ・セキュリティ・プロトコルSAを含んでもよいです。
M-to-N
M対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)
せくりｔｙ あっそしあちおん （さ）
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.
このセクションでは、リファレンスフレームワークのコンテキストでマルチキャストセキュリティの複雑な問題を検討します。このリファレンスフレームワークは、機能領域、機能要素、およびインターフェイスを分類するために使用されます。リファレンスフレームワークの2つの設計を示している：集中管理、設計、および非常に大規模なグループのための集中設計を拡張分散設計を。
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 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.
リファレンスフレームワークは、3つの広範な機能領域（図1に示すように）に基づいています。リファレンスフレームワークは、マルチキャスト、セキュリティに関連する主要なエンティティと機能を内蔵し、それらの間の相互関係を示しています。それはまた、マルチキャストグループタイプ（1対NおよびM対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.
リファレンスフレームワーク図を考えるとき、枠組みの中で特異な「箱」は、必ずしも特定の機能を実現する対応する特異実体を意味するものではありませんことを認識することが重要です。むしろ、フレームワーク内のボックスは、機能領域に関連する所定の機能に関連するように緩く解釈されるべきです。その関数が実際に1つ以上の物理エンティティとして実装されているかどうかは、特定のソリューションに依存しています。例として、「キーサーバ」というボックスは、鍵管理の機能を指すものとして広い意味で解釈されなければなりません。
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.
機能エンティティの3つのセットがあります。それぞれについて、以下で議論されます。
+--------------------------------------+
| |
| |
| 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）は多少異なる機能を持っており、原則的に別々のエンティティとみなすことができます。現在、フレームワークは、設計を簡素化するために、1つ「ボックス」として、2つのエンティティについて、そして順番に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対Nマルチキャストグループでは、2つ以上のグループメンバーは、送信者が許可されています。いくつかのグループでは、すべてのメンバーは、送信者として認定されています。
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.
参考Frameworkでのポリシーサーバと他のエンティティ間の相互作用は、特定の政策によって対処されているセキュリティの状況に大きく依存しています。
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 | | | | |
| +------+ +--------+ |
+-----------------------------------------------------------------+
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.
同様に、ポリシーサーバは、インターネットを介して、ポリシーのコミュニケーションと執行を許可するようにしっかりと相互に作用しなければなりません。
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.
2つの受信ボックスは送信者と受信者の両方が同じGCKSエンティティ（集中型アーキテクチャ）を採用し、ここで、送信者と受信者異なるGCKSエンティティ（分散アーキテクチャ）を使用状況に対応して表示されます。分散型設計では、すべてのレシーバは、同一のキーとポリシーを取得する必要があります。マルチキャストグループの各メンバーは、一次GCKSエンティティと対話することができる（例えば、明確に定義され、一貫性メトリックの点で測定された「最も近い」GCKSエンティティ）。同様に、GCKSエンティティは、分散アーキテクチャに配置された1台のまたは複数のポリシーサーバと対話することができます。
The Reference Framework identifies three functional areas. They are:
リファレンスフレームワークは、3つの機能領域を特定します。彼らです：
- 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.データのソースとの整合性を検証するために、認証されました。認証は2種類を取ります。ソース認証とデータの整合性。この機能は、データが記載ソースに由来し、途中（グループメンバーまたは外部の攻撃者のいずれかによって）変更されなかったことを保証します。
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]マルチキャストソース認証用TESLAアルゴリズムの使用を規定します。
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エンティティと部材との間に安全なチャネルを確立します。 - メソッドは、グループに属する短期の鍵素材を配布する目的で、1つの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]グループ鍵管理機能を実現するプロトコルの3つのインスタンスです。
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].
マルチキャストセキュリティポリシーでの作業の例としては、ダイナミック暗号コンテキスト管理プロジェクト[ディン]、グループ鍵管理プロトコル[HAR1、HAR2]、およびアンティゴネ[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.
1つのデータモデルから別のポリシールールの翻訳は、マルチキャストグループ環境ではるかに困難です。グループメンバーシップは、複数の管理ドメインにまたがるとき、これは特にそうです。ポリシー管理ツールでハイレベルで指定されたポリシーは、利用可能なセキュリティポリシーメカニズムの両方を理解し、実装することができ、より正確なルールに翻訳されなければなりません。マルチキャスト通信とその複数の参加者を扱う際には、個々の翻訳は他の翻訳のすべての結果と相互運用可能であるメカニズムの使用における各参加者の結果に対して行うことが不可欠です。典型的には、特定のポリシー・オブジェクトへの高レベルのポリシーからの翻訳は、グループメンバーのすべてとの間の通信を達成するために、同じ目的をもたらす必要があります。同じオブジェクトのポリシー翻訳結果は、高レベルのポリシーでの使用や表現に制約を課す要件。
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）又はクッキー対などの特性、およびアイデンティティ。 - そのような認証または機密保持のために使用されるアルゴリズム、モード、鍵寿命、及びキーの長さなどの暗号化ポリシー、。 - そのような認証、暗号化と署名キーなどのキー、。
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）は、より複雑であり、通常はポイント・ツー・ポイントの鍵管理アルゴリズムのためよりも、より多数です。後者は、（プロトコルに応じて、通常、1または2個の）アプリケーションSAを保護するために鍵管理SAを確立します。しかし、グループ鍵管理は、最大3つの以上の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は、2つの異なる方法で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は、SAS（図3（B））の集合です。 GSAは、複数のSASで構成され、これらのSAは、いくつかの独立した目的のために使用されてもよいです。
+---------------+ +-------------------+
| GSA | | GSA |
| | | +-----+ +-----+ |
| | | | SA1 | | SA2 | |
| +----+ | | +-----+ +-----+ |
| | SA | | | +-----+ |
| +----+ | | | SA3 | |
| | | +-----+ |
+---------------+ +-------------------+
(a) superset (b) aggregation
（A）スーパーセット（B）の凝集
Figure 3: Relationship of GSA to SA
図3：SAへのGSAの関係
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 | |
| +-----------------+ +-----------------+ |
| |
| |
+------------------------------------------------------------+
Figure 4: GSA Structure and 3 categories of SAs
図4：GSA構造とSAの3つのカテゴリ
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）：GCKSと各グループメンバ間の別個のユニキャストSAに関わらず、グループメンバが送信者または受信者であるか、または両方のロールに作用するかどうか。
- Re-key SA (REKEY): A single multicast SA between the GCKS and all of the group members.
- 再鍵SA（REKEY）：GCKSとグループメンバーのすべてとの間の単一のマルチキャスト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の3つのカテゴリが、一般的グループ通信に必要な通信の3種類に対応しています。このセクションでは、SASは、詳細に、図4に示され記載されています。
- 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）：SAはGCKSとグループメンバとの間の（双方向）ユニキャスト通信（それは送信者または受信者であること）のために必要とされます。このSAだけGCKSとメンバーの間で確立されています。 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はGCKSからGSA情報を引き出すためにメンバーによって開始されます。これは、メンバーのリクエストがセキュアグループに参加する方法である、またはそのGSAキーがグループから切断された後に再初期化された（例えば、そのホストコンピュータが再キー動作中にオフにされた場合）。 GCKSからプルダウンGSA情報は、GSAの一部として定義され、他の2つの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の定義における他の2つの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.
グループのメンバー（送信者及び/又は受信機）が存在するように1つの所与のGCKSの観点から、のような多くのユニークな登録の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（REKEY）：いくつかのケースでは、GCKSは、GSAの一環として、新しいSAを「プッシュ」する機能が必要です。これらの新しいSAは、すべてのグループメンバーに送信する必要があります。他の例では、GCKSはすぐに1つ以上のグループのメンバーへのアクセスを取り消す能力を必要とします。これらのニーズの両方が再キー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は、すべてのグループメンバーへのGCKSから鍵管理メッセージの一方向のマルチキャスト伝送です。このように、このSAはGCKSによって、グループのすべてのメンバーに知られています。
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は、ネゴシエートされません。したがって、GCKSは、この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は、他のグループメンバーに送信者からのデータメッセージのマルチキャスト送信に必要とされます。このSAは、GCKSによって、グループのすべてのメンバーによって知られています。
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がネゴシエートされていません。むしろ、すべてのグループメンバーがGCKSからそれを得ます。 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がある場合、データ・セキュリティ・プロトコルは、（SPI付き例えば、）SAを区別する手段を有していなければなりません。
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を展開します。レシーバは1つだけのデータセキュリティSAを維持することができるだろう。
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上に分散することができる「ペイ・パー・セッション」のアプリケーション、。何REKEY SAが存在しないので、再キーとデータSAの再初期化、必要ではないかもしれません。 - 鍵材料をサブスクリプション・グループは、メンバーシップの変更として変更されました。 REG SAは、他のSAを配布するために必要とされます。 REKEY 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]).
このセキュリティサービスは、グループコントローラとメンバーの登録、およびグループコントローラからのメンバーの登録解除の機能について説明します。これらは、「結合」とメンバーがグループアドミッション制御プロトコルの一部として実行する必要があるかもしれないことを操作「のまま」（すなわち、IGMP [RFC3376]を、MLD [RFC3019]）IPマルチキャストグループから独立しているセキュリティ機能です。
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.
- GCKSグループメンバーに（送信者または受信者）は、現在の鍵材料（例えば、グループ暗号化および認証鍵、グループ管理、ソース認証のためのキー、等のために使用される補助キー）についての通知。 - 状況やポリシーに応じ、現在の鍵素材の更新、。 - 安全なグループ自体と関連した鍵材料を含む、安全な方法でグループの終了。
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 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).
相互運用性と安全なIPマルチキャストセキュリティプロトコルを可能にするために、このセキュリティサービスは、グループセキュリティアソシエーションデータベース（GSAD）とIPマルチキャストセキュリティのためのグループ・セキュリティ・ポリシー・データベース（GSPD）としてホスト抽象化を指定する必要があるかもしれません。 IPマルチキャストおよびアプリケーションレイヤマルチキャストキー管理との間の重なりの程度を考慮する必要があります。このように、このセキュリティサービスは、アカウントにIPマルチキャストのための鍵管理要件、アプリケーション層マルチキャストのための鍵管理要件を取り、どの程度までマルチキャストキー管理セキュリティサービスの具体的な実現には、両方を満たすことができます。 ISAKMPは、更に、IPマルチキャストおよびアプリケーションレイヤマルチキャストセキュリティ[RFC2408]の両方のための鍵管理をマルチキャストする拡張できるように設計されています。このように、マルチキャストキー管理プロトコルは、おそらく（例えばGDOI [RFC3547]またはアプリケーションレイヤマルチキャストセキュリティなど）が必要と拡張子を持つ、既存のISAKMPの標準のフェーズ1とフェーズ2のプロトコルを使用してもよいです。
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.
マルチキャストポリシー管理セキュリティサービスは、Policy Serverのインスタンスに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.
この文書では、暗号化プロトコルで、マルチキャストグループトラフィックを保護するためのアーキテクチャフレームワークについて説明します。 3つの機能領域は、フレームワーク内で識別されています。各機能領域は、固有のセキュリティ上の考慮事項があり、これらについては後述します。
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.
グループ鍵管理プロトコルは、暗号鍵やグループメンバーにポリシーを提供します。彼らは、これらのキーを明らかにする前に、トランジットの際にそれらのキーの機密性と認証を提供するためのグループメンバーを認証および認可する責任があります。彼らはまた、ポリシーは、キーの有効期間を指定する場合には、グループを再入力するための手段を提供する責任があります。 1つ以上のグループのメンバーが取り消されたグループのメンバーであるために彼らの許可を受けた後、彼らはまた、グループメンバーシップの取り消しを担当しています。 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.
この文書内のテキストの多くは、2本の研究論文から得られました。このドキュメントのための枠組みはカネッティ、マーク・Baugher、そしてピートDinsmore蘭、紙トーマスHardjonoによる共著から来ました。 GSAの説明はヒューハーニー、マーク・Baugher、とトーマスHardjonoによる共著文書から来ました。ジョージ・グロスは、このドキュメントの以降のバージョンに含まれていた多くの改良を示唆しました。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、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]モーガン、D.、Shertler、M.、シュナイダー、M.とJ.ターナー、 "インターネットセキュリティ協会と鍵管理プロトコル"、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.カネッティ、P.チェン、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.カネッティ、L. Dondeti、F.リンドホルム、 "グループ鍵管理アーキテクチャ"、進歩、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.マグリュー、A.シャーマン、大規模な動的グループのためのキー管理：一方向関数の木と償却の初期化、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]カネッティ、R.、チェンPC、Pendarakis D.、ラオ、J.、Rohatgi P.、サハD.、 "安全なインターネットマルチキャストのためのIPSecベースのホストのアーキテクチャ"、http://www.isoc.org / ISOC /会議/ 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.
[ディン] Dinsmore、P.、Balenson、D.、ヘイマン、M.、Kruus、P.、Scace、C.、およびシャーマン、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.ハーニー、ら。ら、 "GSAKMP"、進歩、2003年10月に作業。
[Har1] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[HAR1]ハーニー、H.およびC. Muckenhirn、 "グループ鍵管理プロトコル（GKMP）仕様"、RFC 2093、1997年7月。
[Har2] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
[HAR2]ハーニー、H.およびC. Muckenhirn、 "グループ鍵管理プロトコル（GKMP）アーキテクチャ"、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]マクダニエル、P.、ハニーマン、P.、およびプラカシュ、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.、カネッティ、R.とB. Whillock、TESLA：マルチキャストソース認証は進歩、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.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、C.、シャルマ、P.、およびL.魏、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様"、RFC 2362、1998年6月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2406bis] Kent, S., "IP Encapsulating Security Payload (ESP)", Work in Progress, March 2003.
[RFC2406bis]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、進歩、2003年3月での作業。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（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]ウォルナー、D.、ハーダー、E.およびR.アゲ、 "マルチキャストのためのキー管理：問題とアーキテクチャ"、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.ホールドレッジ、 "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]ダラム、D.、エド。、ボイル、J.、コーエン、R.、Herzong、S.、ラジャン、R.とA. Sastry、 "COPS（コモンオープンポリシーサービス）プロトコル"、RFC 2748、1月2000。
[RFC3019] Haberman, B. and R. Worzella, "IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol", RFC 3019, January 2001.
[RFC3019]ハーバーマン、B.とR. Worzella、RFC 3019 "マルチキャストリスナ発見プロトコルのためのIPバージョン6管理情報ベース"、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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、M.、ハンドレー、M.及びJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（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.、ヴァイス、B.、Hardjono、T.とH.ハーニー、 "解釈のグループドメイン"、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.、シュタイナー、Tsudik、G.、Waidner、M.、クリーク：グループキー契約、IEEE ICDCS'98、1998年5月への新しいアプローチ。
Thomas Hardjono VeriSign 487 E. Middlefield Rd. Mountain View, CA 94043, USA
トーマスHardjonoベリサイン487 E.ミドルRdを。マウンテンビュー、CA 94043、USA
Phone:(650) 426-3204 EMail: thardjono@verisign.com
電話：（650）426-3204 Eメール：thardjono@verisign.com
Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706, USA
ブライアン・ワイスシスコシステムズ170 W.タスマン・ドライブ、サンノゼ、CA 95134-1706、USA
Phone: (408) 526-4796 EMail: bew@cisco.com
電話：（408）526-4796 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。