[要約] RFC 3740は、マルチキャストグループのセキュリティアーキテクチャに関するものであり、マルチキャスト通信のセキュリティを向上させるためのガイドラインを提供しています。このRFCの目的は、マルチキャストグループのセキュリティに関する問題を理解し、適切な対策を講じるための情報を提供することです。
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.
Copyright（c）The Internet Society（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.
このアーキテクチャでは、IPマルチキャスト入場制御プロトコル（例：IGMP [RFC3376]、MLD [RFC3019]）が安全なマルチキャストグループの一部であることを要求していません。そのため、安全なグループの「結合」または「leave」操作は、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.
このドキュメントのもう1つの重要な項目は、ユニキャストセキュリティ協会（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-to-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.
グループが安全にコミュニケーションする方法を一緒に定義するセキュリティ協会（SAS）のバンドル。GSAには、登録プロトコルSA、REKEYプロトコルSA、および1つ以上のデータセキュリティプロトコルSASが含まれる場合があります。
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.
このセクションでは、参照フレームワークのコンテキストでマルチキャストセキュリティの複雑な問題を検討します。この参照フレームワークは、機能領域、機能要素、およびインターフェイスを分類するために使用されます。参照フレームワークの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-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.
参照フレームワーク図を検討する場合、フレームワーク内の単数形の「ボックス」が、特定の関数を実装する対応する特異エンティティを必ずしも意味するわけではないことを認識することが重要です。むしろ、フレームワーク内のボックスは、関数領域に関連する特定の関数に関係するものとしてゆるく解釈する必要があります。その関数が実際に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）は、機能が多少異なり、原則として別々のエンティティと見なされる場合があります。現在、このフレームワークは、2つのエンティティを1つの「ボックス」と見なし、設計を簡素化し、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のマルチキャストグループでは、グループにデータを送信することが許可されている1つの送信者のみが許可されています。M-to-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.
参照フレームワーク内のポリシーサーバーと他のエンティティとの間の相互作用は、特定のポリシーで対処されているセキュリティ状況に大きく依存しています。
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.
送信者と受信機の両方が同じGCKSエンティティ（集中アーキテクチャ）を採用し、送信者と受信機が異なるGCKSエンティティ（分散アーキテクチャ）を使用する状況に対応する2つのレシーバーボックスが表示されます。分散設計では、すべての受信機が同一のキーとポリシーを取得する必要があります。マルチキャストグループの各メンバーは、プライマリ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エンティティと別の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]は、マルチキャストセキュリティの主要な管理アーキテクチャをさらに定義します。Group Security Association（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].
マルチキャストセキュリティポリシーにおける作業の例には、動的暗号化コンテキスト管理プロジェクト[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.
Group Key Managementは、ポイントツーポイントキー管理システム（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.
グループキー管理のセキュリティ協会（SAS）はより複雑であり、通常、ポイントツーポイントキー管理アルゴリズムよりも多くのものです。後者は、アプリケーションSAS（通常はプロトコルに応じて1つまたは2つ）を保護するための主要な管理SAを確立します。ただし、グループキー管理には最大3つ以上のSASが必要になる場合があります。これらの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は複数のSAで構成されており、これらのSAはいくつかの独立した目的に使用される場合があります。
+---------------+ +-------------------+
| 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に集約できるSASの3つのカテゴリを示しています。
+------------------------------------------------------------+
| |
| +------------------+ |
| | GCKS | |
| | | |
| | REG REG | |
| | / REKEY \ | |
| +---/-----|----\---+ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| +----------/------+ | +------\----------+ |
| | REG | | | REG | |
| | REKEY-----+----REKEY | |
| | Sender | | Receiver | |
| | DATA----------DATA | |
| +-----------------+ +-----------------+ |
| |
| |
+------------------------------------------------------------+
Figure 4: GSA Structure and 3 categories of SAs
図4：GSA構造とSASの3つのカテゴリ
The three categories of SAs are:
SAの3つのカテゴリは次のとおりです。
- 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.
- Rekey 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（データ）：各マルチキャストソーススピーカーとグループのレシーバーの間のマルチキャストSA。グループのポリシーで許可されているマルチキャストソースがあるのと同じくらい多くのデータSASがあるかもしれません。
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つの異なる種類の通信に対応しています。このセクションでは、図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）：SAは、GCKSとグループメンバーの間の（双方向の）ユニキャスト通信に必要です（送信者であろうとレシーバーであろうと）。この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は、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つのSASとは分離できません。
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が存在し、他のSASを保護するために使用されることです。
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の1つの観点からは、グループにメンバー（送信者および/または受信機）と同じくらい多くの一意の登録SASがあります。これは、一部のアプリケーションのスケーラビリティの関心事を構成する場合があります。登録SAは短い寿命でオンデマンドで確立される場合がありますが、少なくとも彼らがサポートするセッションの存続期間中、RECKEとデータセキュリティSASは確立されます。
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.
- Rekey SA（Rekey）：場合によっては、GCKSにはGSAの一部として新しいSASを「プッシュ」する機能が必要です。これらの新しい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.
この鍵は、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は交渉されていません。したがって、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.
Reke SAは、GSAの一部である必要は絶対に必要ありません。たとえば、一部のグループの寿命は十分に短いため、再キーが必要ではないようになります。逆に、グループのポリシーは、異なるタイプの複数のReke SASを指定できます。たとえば、GCとKSが個別のエンティティである場合、GCはグループメンバーシップを調整するRekeメッセージを配信し、KSは新しいデータSASでRekeyメッセージを配信する場合があります。
- Data Security SA (DATA): The Data Security SA protects data between member senders and member receivers.
- データセキュリティSA（データ）：データセキュリティ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.
送信者から他のグループメンバーへのデータメッセージのマルチキャスト送信には、1つ以上の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.
この3番目のカテゴリの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).
受信機の観点から見ると、グループ内にメンバー送信者（1つ以上）に少なくとも1つのデータセキュリティSAがあります。グループに複数のデータセキュリティSAがある場合、データセキュリティプロトコルにはSASを区別する手段が必要です（例：SPI）。
There are a number of possibilities with respect to the number of data security SAs:
データセキュリティSASの数に関しては、多くの可能性があります。
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を割り当てることができ、それにより、各受信者はグループに送信者と同じくらい多くのデータセキュリティSASを維持する必要があります。この場合、各送信者は、ソースオリジン認証手法を使用して検証できます。
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のみを維持できます。
3. A combination of 1. and 2.
3. 1と2の組み合わせ。
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を介して配布される可能性がある「セッションごとのペイセッション」アプリケーション。データSASの再目的化と再目的化は必要ない場合があるため、Rekey SAはありません。 - メンバーシップが変更されるとキーイング素材が変更されるサブスクリプショングループ。他のSASを配布するには、Reg SAが必要です。メンバーシップが変更されたときにデータSAを再目的化するには、Rekey 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）、しかし、マルチキャストキー管理に必要なサービスは、マルチキャストと同様にユニキャストである場合があります。したがって、マルチキャストセキュリティリファレンスフレームワークのセキュリティサービスは、1つ以上の図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マルチキャストアプリケーションのコネクションレスおよびリアルタイムの要件により、マルチキャストセキュリティのより難しい分野の1つです。ただし、アプリケーション層マルチキャストセキュリティにはクラスがありますが、オフラインソースとデータ認証で十分です。前述のように、すべてのマルチキャストアプリケーションがリアルタイム認証とデータパケットの整合性を必要とするわけではありません。ただし、マルチキャストソースとデータ認証に対する堅牢なソリューションは、マルチキャストセキュリティの完全なソリューションに必要です。
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.
このセキュリティサービスは、送信されたデータの限られた量の信頼性を提供します。これは、グループメンバーの1人から発信された（または最後に変更された）データのみを保証します。他のグループメンバーが信頼されていない場合に備えて、データの信ity性を保証するものではありません。
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]）の一部として実行する必要がある「結合」および「去る」オペレーションから独立したセキュリティ関数であり、操作です。
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マルチキャストセキュリティプロトコルを可能にするために、このセキュリティサービスは、IPマルチキャストセキュリティ用のグループセキュリティ協会データベース（GSAD）やグループセキュリティポリシーデータベース（GSPD）などのホスト抽象化を指定する必要がある場合があります。IPマルチキャストとアプリケーションレイヤーマルチキャストキー管理の間の重複の程度を考慮する必要があります。したがって、このセキュリティサービスは、IPマルチキャストの主要な管理要件、アプリケーション層マルチキャストの主要な管理要件、およびマルチキャストキー管理セキュリティサービスの特定の実現が両方を満たすことができる程度を考慮しています。さらに、ISAKMPは、IPマルチキャストとアプリケーションレイヤーマルチキャストセキュリティの両方のマルチキャストキー管理に拡張できるように設計されています[RFC2408]。したがって、マルチキャストキー管理プロトコルは、既存の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.
このセキュリティサービスは、メンバーシップポリシーやマルチキャストキー管理ポリシーなど、マルチキャストグループポリシーに関連するすべての問題を処理します。実際、このセキュリティサービスをさらに定義する最初のタスクの1つは、マルチキャストポリシーのさまざまな分野を特定することです。マルチキャストポリシー管理には、マルチキャストセキュリティのためのポリシーサーバーの設計、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.
このドキュメントでは、暗号化プロトコルでマルチキャストとグループトラフィックを保護するためのアーキテクチャのフレームワークについて説明します。フレームワーク内で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.
グループキー管理プロトコルは、グループメンバーに暗号化キーとポリシーを提供します。それらは、これらのキーを明らかにする前に、グループメンバーを認証および承認し、輸送中にそれらのキーの機密性と認証を提供する責任があります。また、ポリシーがキーの生涯を指定する場合、グループを再キーする手段を提供する責任があります。彼らはまた、グループメンバーが取り消されたグループメンバーになるという許可を取得した後、グループメンバーシップの取り消しの責任もあります。セクション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つの研究論文から派生していました。このドキュメントのフレームワークは、トーマス・ハードジョノ、ラン・カネッティ、マーク・ボーサー、ピート・ディンスモアが共著した紙から来ました。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、et。al。、「マイキー：マルチメディアインターネットキーイング」、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、「Group Key Management Architecture」、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-of.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/Proceedings/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 Information Survivability Conference and Exposition、http：//download.nai.com/products/media/nai/doc/discex-10199.doc。
[GSAKMP] H. Harney, et. al., "GSAKMP", Work in Progress, October 2003.
[GSAKMP] H. Harney、et。al。、「gsakmp」、2003年10月、進行中の作業。
[Har1] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[Har1] Harney、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] Harney、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] McDaniel、P.、Honeyman、P。、およびPrakash、A。、「Antigone：安全なグループコミュニケーションのための柔軟なフレームワーク」、8つのUSENIXセキュリティシンポジウムの議事録、PP 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。and 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.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M.、Jacobson、V.、Liu、C.、Sharma、P。and 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月、Work in Progress。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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。and 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。、ed。、Boyle、J.、Cohen、R.、Herzong、S.、Rajan、R.、A。Sastry、「Cops（Common Open Policy Service）Protocol」、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] 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。and A. Thyagarajan、 "Internet Group Management Protocol、Version 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、「The Group Domain of Strettation」、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.、Cliques：A Group Key Agreementへの新しいアプローチ、IEEE ICDCS'98、1998年5月。
Thomas Hardjono VeriSign 487 E. Middlefield Rd. Mountain View, CA 94043, USA
Thomas Hardjono Verisign 487 E. Middlefield Rd。マウンテンビュー、CA 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
ブライアン・ワイス・シスコ・システム170 W.タスマン・ドライブ、サンノゼ、CA 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.
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。