RFC3740 日本語訳
3740 The Multicast Group Security Architecture. T. Hardjono, B. Weis. March 2004. (Format: TXT=65531 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Hardjono
Request for Comments: 3740 Verisign
Category: Informational B. Weis
Cisco
March 2004
Hardjonoがコメントのために要求するワーキンググループT.をネットワークでつないでください: 3740年のVerisignカテゴリ: 2004年の情報のB.ウィスコクチマス行進
The Multicast Group Security Architecture
マルチキャストグループセキュリティー体系
Status of this Memo
この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)インターネット協会(2004)。 All rights reserved。
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.
このドキュメントはデータが大きいマルチキャストグループのパケットであると機密保護するのに使用されるマルチキャストセキュリティー体系の概要と原理を提供します。 ドキュメントは、Multicast Security Reference Frameworkを導入することによって始まって、安全なマルチキャストソリューションの一部であるかもしれないセキュリティー・サービスを特定しかけます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Summary of Contents of Document. . . . . . . . . . . . . 3
1.3. Audience . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
2. Architectural Design: The Multicast Security Reference
Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Reference Framework. . . . . . . . . . . . . . . . . 4
2.2. Elements of the Centralized Reference Framework. . . . . 5
2.2.1. Group Controller and Key Server. . . . . . . . . 6
2.2.2. Sender and Receiver. . . . . . . . . . . . . . . 7
2.2.3. Policy Server. . . . . . . . . . . . . . . . . . 7
2.3. Elements of the Distributed Reference Framework. . . . . 8
3. Functional Areas . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 9
3.2. Group Key Management . . . . . . . . . . . . . . . . . . 10
3.3. Multicast Security Policies. . . . . . . . . . . . . . . 11
4. Group Security Associations (GSA). . . . . . . . . . . . . . . 12
4.1. The Security Association . . . . . . . . . . . . . . . . 12
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 範囲。 . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. ドキュメントのコンテンツの概要。 . . . . . . . . . . . . 3 1.3. 聴衆. . . . . . . . . . . . . . . . . . . . . . . . 4 1.4。 用語。 . . . . . . . . . . . . . . . . . . . . . . 4 2. 建築デザイン: マルチキャストセキュリティ参照フレームワーク。 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. 参照フレームワーク。 . . . . . . . . . . . . . . . . 4 2.2. 集結された参照フレームワークのElements。 . . . . 5 2.2.1. グループコントローラと主要なサーバ… 6 2.2 .2。 送付者と受信機… 7 2.2 .3。 方針サーバ7………………2.3。 分配された参照フレームワークのElements。 . . . . 8 3. 機能的な領域. . . . . . . . . . . . . . . . . . . . . . . 9 3.1。 マルチキャストデータハンドリング。 . . . . . . . . . . . . . . . . 9 3.2. Key Management. . . . . . . . . . . . . . . . . . 10 3.3を分類してください。 マルチキャスト安全保障政策。 . . . . . . . . . . . . . . 11 4. セキュリティ協会(GSA)を分類してください。 . . . . . . . . . . . . . . 12 4.1. セキュリティ協会. . . . . . . . . . . . . . . . 12
Hardjono & Weis Informational [Page 1] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[1ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
4.2. Structure of a GSA: Introduction . . . . . . . . . . . . 13
4.3. Structure of a GSA: Reasoning. . . . . . . . . . . . . . 14
4.4. Definition of GSA. . . . . . . . . . . . . . . . . . . . 15
4.5. Typical Compositions of a GSA. . . . . . . . . . . . . . 17
5. Security Services. . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Multicast Data Confidentiality . . . . . . . . . . . . . 18
5.2. Multicast Source Authentication and Data Integrity . . . 18
5.3. Multicast Group Authentication . . . . . . . . . . . . . 19
5.4. Multicast Group Membership Management. . . . . . . . . . 19
5.5. Multicast Key Management . . . . . . . . . . . . . . . . 20
5.6. Multicast Policy Management. . . . . . . . . . . . . . . 21
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
6.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 22
6.2. Group Key Management . . . . . . . . . . . . . . . . . . 22
6.3. Multicast Security Policies. . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 23
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
4.2. GSAの構造: 序論. . . . . . . . . . . . 13 4.3。 GSAの構造: 推理。 . . . . . . . . . . . . . 14 4.4. GSAの定義。 . . . . . . . . . . . . . . . . . . . 15 4.5. GSAの典型的な構成。 . . . . . . . . . . . . . 17 5. セキュリティー・サービス。 . . . . . . . . . . . . . . . . . . . . . . 17 5.1. マルチキャストデータの機密性. . . . . . . . . . . . . 18 5.2。 マルチキャストソース認証とデータの保全. . . 18 5.3。 マルチキャストグループ認証. . . . . . . . . . . . . 19 5.4。 マルチキャストグループ会員資格管理。 . . . . . . . . . 19 5.5. マルチキャストKey Management. . . . . . . . . . . . . . . . 20 5.6。 マルチキャスト政策管理。 . . . . . . . . . . . . . . 21 6. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 22 6.1. マルチキャストデータハンドリング。 . . . . . . . . . . . . . . . . 22 6.2. Key Management. . . . . . . . . . . . . . . . . . 22 6.3を分類してください。 マルチキャスト安全保障政策。 . . . . . . . . . . . . . . 22 7. 承認. . . . . . . . . . . . . . . . . . . . . . . 23 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1。 引用規格. . . . . . . . . . . . . . . . . . 23 8.2。 有益な参照. . . . . . . . . . . . . . . . . 23 9。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 25 10。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 26
1. Introduction
1. 序論
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マルチキャストプロトコル群には、多くのソリューションの異なった局面を扱う機能的な領域がなければなりません。 このドキュメントはそれらの機能的な領域とそれらがどう関係づけられるかを説明します。
1.1. Scope
1.1. 範囲
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.
このアーキテクチャは大きいマルチキャストグループを機密保護するのに関係があります。 また、より小さいグループにそれを使用できますが、それは必ず最も効率的な手段であるというわけではありません。 小さい広告-hocグループコミュニケーションには、他のアーキテクチャ(例えば、Cliquesアーキテクチャ[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])を必要としません。 不適当なルーティングはこのアーキテクチャに従う応用層グループに対するサービスの否定を引き起こすかもしれません。 しかしながら、ルーティングはグループ・データか管理パケットの信憑性か秘密保持に影響できません。 マルチキャストルーティング・プロトコルがそうすることができた、自分たち、このアーキテクチャを使用して、それら自身のマルチキャストとグループパケットを保護してください。 しかしながら、これはどんな安全な応用層グループからも独立しているでしょう。
Hardjono & Weis Informational [Page 2] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[2ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
This architecture does not require IP multicast admission control protocols (e.g., IGMP [RFC3376], MLD [RFC3019]) to be a part of secure multicast groups. As such, a "join" or "leave" operation for a secure group is independent of a "join" or "leave" of an IP multicast group. For example, the process of joining a secure group requires being authenticated and authorized by a security device, while the process of joining an IP multicast group entails contacting a multicast-aware router. Admission control protocols could themselves use this architecture to protect their own multicast packets. However, this would be independent of any secure application layer group.
このアーキテクチャは、IPマルチキャスト入場制御プロトコル(例えば、IGMP[RFC3376]、MLD[RFC3019])が安全なマルチキャストグループの一部であることを必要としません。 そのようなもの、「接合してください」または「休暇」として、安全なグループのための操作はIPマルチキャストグループの「接合してください」か「休暇」から独立しています。 例えば、安全なグループに加わるプロセスは、セキュリティデバイスによって認証されて、認可されるのを必要とします、IPマルチキャストグループに加わるプロセスは、マルチキャスト意識しているルータに連絡するのを伴いますが。 入場制御プロトコルがそうすることができた、自分たち、このアーキテクチャを使用して、それら自身のマルチキャストパケットを保護してください。 しかしながら、これはどんな安全な応用層グループからも独立しているでしょう。
This architecture does not explicitly describe how secure multicast groups deal with Network Address Translation (NAT) [RFC2663]. Multicast routing protocols generally require the source and destination addresses and ports of an IP multicast packet to remain unchanged. This allows consistent multicast distribution trees to be created throughout the network. If NAT is used in a network, then the connectivity of senders and receivers may be adversely affected. This situation is neither improved or degraded as a result of deploying this architecture.
このアーキテクチャは明らかに安全なマルチキャストグループがどう、Network Address Translation(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])の使用は安全なマルチキャストグループの有用性を高めます。 しかしながら、グループ・データか管理パケットの信憑性か秘密保持が展開からその能力の省略で影響を受けません。
1.2. Summary of Contents of Document
1.2. ドキュメントのコンテンツの概要
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.
このドキュメントは大きいマルチキャストグループを保証するのに必要であるセキュリティー・サービスについて概説する建築概要を提供します。 それで、アーキテクチャの中で様々な要素を組織化するのにReference Frameworkを提供して、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.
Reference Frameworkは、セキュリティに関しながら、3Functional Areasに沿ってアーキテクチャの原理を組織化します。 それがグループに送られることになっているとき、これらの要素はデータの処理をカバーしています、データを保護するのに使用される材料、および方針を合わせることの経営者側がグループを支配して。
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.
別の重要案件は、本書ではGroup Security Associations(GSA)に関する定義と説明です。(Group Security AssociationsはユニキャストSecurity Association(SA)のマルチキャスト対応者です)。 GSAはマルチキャストセキュリティに特定であり、グループ重要管理に対する仕事の基礎です。
Hardjono & Weis Informational [Page 3] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[3ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
1.3. Audience
1.3. 聴衆
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マルチキャストセキュリティー技術のimplementers、およびマルチキャストセキュリティの一般的なバックグラウンド理解を獲得したがっていた他のものに扱われます。 このドキュメントは、読者がインターネットプロトコル、プロトコル(例えば、[RFC2401])のIPsecスイート、関連するネットワーク・テクノロジー、総合証券用語、および概念に詳しいと仮定します。
1.4. Terminology
1.4. 用語
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.
そんなに一緒にいるSecurity Associations(SAs)のバンドリングはグループがどうしっかりと交信するかを定義します。 GSAは登録プロトコルSA、rekeyプロトコルSA、および1つ以上のデータ機密保護のプロトコルSAsを含むかもしれません。
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)
セキュリティ協会(SA)
A set of policy and cryptographic keys that provide security
services to network traffic that matches that policy.
セキュリティを提供する1セットの方針と暗号化キーがその方針に合っているトラフィックをネットワークに修理します。
2. Architectural Design: The Multicast Security Reference Framework
2. 建築デザイン: マルチキャストセキュリティ参照フレームワーク
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.
このセクションはReference Frameworkの文脈におけるマルチキャストセキュリティの複雑な問題を考えます。 このReference Frameworkは、機能的な領域、機能要素、およびインタフェースを分類するのに使用されます。 Reference Frameworkの2つのデザインが示されます: 集結されたデザイン、および非常に大きいグループのために集結されたデザインを広げる分配されたデザイン。
2.1. The Reference Framework
2.1. 参照フレームワーク
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
Reference Frameworkは3つの広い機能的な領域に基づいています(図1に示されるように)。 Reference Frameworkがマルチキャストセキュリティに関連する主な実体と機能を取り入れる、表現
Hardjono & Weis Informational [Page 4] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[4ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
the inter-relations among them. It also expresses multicast security from the perspective of multicast group types (1-to-N and M-to-N), and classes of protocols (the exchanged messages) needed to secure multicast packets.
それらの中の相互関係。 また、それはマルチキャストグループタイプ(1〜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.
Reference Frameworkの目的は、機能的な領域の周りで何らかの一般情勢を提供して、機能的な領域の間で関係を提供することです。 いくつかの問題が1つ以上の機能的な領域にかかることに注意してください。 事実上、フレームワークは1つ以上の機能的な領域にかかわる問題かただ一つの機能的な領域に関して言い表すのが難しいものの正確な識別と定式化を奨励します。 そのような場合に関する例はグループキーに関する方針の式です。(その式はグループ重要管理とマルチキャスト方針の両方の機能的な領域にかかわります)。
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.
Reference Frameworkダイヤグラムを考えるとき、フレームワークにおけるまれな「箱」が必ず与えられた機能を実装する対応するまれな実体を含意するというわけではないとわかるのは重要です。 むしろ、フレームワークにおける箱は、機能的な領域に関連する与えられた機能に関しながら、緩く解釈されるべきです。 その機能が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.
同様に、Reference Frameworkは、事実上、いくつかの実装が多くの「箱」をただ一つの物理的実体に合併するかもしれないと認めます。 これは機能的な領域の向こう側にさえ本当であるかもしれません。 例えば、グループにおける実体はGroup ControllerとSenderの両方としてグループに機能できました。
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.
標準化されるべきプロトコルは様々な箱を接続する矢によってReference Frameworkダイヤグラムで表現されます。 以下のセクション4でその他の詳細を見てください。
2.2. Elements of the Centralized Reference Framework
2.2. 集結された参照フレームワークのElements
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のReference Frameworkダイヤグラムは箱と矢を含んでいます。 箱は機能的な実体です、そして、矢はそれらの間のインタフェースです。 標準プロトコルがインタフェースに必要です。(インタフェースはマルチキャストが機能的な実体の間のサービスであるとサポートします)。
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.
いくつかの場合、マルチキャストセキュリティー体系を実装するシステムは、あらゆるインタフェースを説明するためにプロトコルを実装する必要はないかもしれません。 むしろ、それらはアプリケーションに必要でないなら、それらのインタフェースが、手動の構成の使用で満たされているか、または省略さえされるかもしれません。
Hardjono & Weis Informational [Page 5] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[5ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
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 | | |
| +------+ |
| |
+--------------------------------------+
+--------------------------------------+ | | | | | 機能的| | 領域| | | | +------+ | | マルチキャスト|方針| | | セキュリティ|サーバ| | | 方針+------+ | | ^ | | | | | | | | v| | +------+ | | グループ|グループ| | | キー|Ctrl/| <、-、-、-、-、-、-、-、--+ | | 管理|キー| | | | |サーバ| V| | +------+ +--------+ | | ^ | | | | | |受信機| | | | | | | | +に対して--------+ | | +------+ ^ | | | | | | | マルチキャスト|送付者|----------+ | | データ| | | | 取り扱い| | | | +------+ | | | +--------------------------------------+
Figure 1: Centralized Multicast Security Reference Framework
図1: 集結されたマルチキャストセキュリティ参照フレームワーク
2.2.1. Group Controller and Key Server
2.2.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.
Group ControllerとKey Server(GCKS)は発行に関連する実体と機能とマルチキャストグループによって使用された暗号化キーの経営者側の両方を表します。 また、GCKSはマルチキャストグループの候補メンバーのユーザー認証と許可検査を行います。
Hardjono & Weis Informational [Page 6] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[6ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
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.
Key Server(カンザス)とGroup Controller(GC)はいくらか異なった機能性を持って、原則として別々の実体と見なされるかもしれません。 現在の、フレームワークは、デザインを簡素化して、カンザスとGCの間のプロトコルの標準化を強制しない命令で見なすために2つの実体を1「箱」と見なします。 カンザスとGCが共同見つけられる必要はないと強調されます。 その上、将来のデザインは、他のコンポーネントを変更しないでGCとカンザスの間のプロトコルを標準化するのを選ぶかもしれません。
2.2.2. Sender and Receiver
2.2.2. 送付者と受信機
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.
Senderはマルチキャストグループにデータを送る実体です。 Nへの1つのマルチキャストグループだけでは、独身の送付者がデータをグループに送るのに権限を与えられます。 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.
SenderとReceiverの両方がかぎ管理の目的のために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.
SendersとReceiversはGCKS実体から彼らの方針の多くを受け取るかもしれません。 マルチキャストグループに加わるイベントは、GCKS実体から材料を合わせながら、Sender/受信機入手に通常結びつけられます。 これはSender/受信機とPolicy Serverの間の直接的な相互作用を排除しません。
2.2.3. Policy Server
2.2.3. 方針サーバ
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.
Policy Serverはマルチキャストグループに特定の安全保障政策を作成して、管理するのに使用される実体と機能の両方を表します。 Policy Serverは、与えられたマルチキャストグループと関連するものの会員資格に関連する安全保障政策をインストールして、管理するためにマルチキャストグループのために材料を合わせながら、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.
Reference FrameworkのPolicy Serverと他の実体との相互作用は、与えられた方針で扱われながら、大体においてセキュリティ事情に依存しています。
Hardjono & Weis Informational [Page 7] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[7ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
2.3. Elements of the Distributed Reference Framework
2.3. 分配された参照フレームワークのElements
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は大きいグループスケーラビリティをサポートする分配されたデザインがどうReference Frameworkに収まるかを示しています。
+-----------------------------------------------------------------+
| |
| |
| 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 | | | | |
| +------+ +--------+ |
+-----------------------------------------------------------------+
+-----------------------------------------------------------------+ | | | | | 機能的| | 領域| | +------+ +------+ | | マルチキャスト|方針|<-------------------------------->|方針| | | セキュリティ|サーバ| |サーバ| | | 方針+------+ +------+ | | ^ ^ | | | | | | | | | | vに対して| | +------+ +------+ | | グループ|グループ|<------------------------------->| 分類してください。| | | キー|Ctrl/| <、-、-、-、-、-、-、-、--+ |Ctlr/| | | 管理|キー| | |キー| | | |サーバ| V|サーバ| | | +------+ +--------+ +------+ | | ^ | | ^ | | | |受信機| | | | | | | | | | +に対して--------+ | | | +------+ ^ V | | | | | +--------+ | | マルチキャスト|送付者|----------+ | | | | データ| |-------------------------------->|受信機| | | 取り扱い| | | | | | +------+ +--------+ | +-----------------------------------------------------------------+
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実体、承認の手段、およびしっかりと相互作用する手段を認証する手段を必要とするでしょう。
Hardjono & Weis Informational [Page 8] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[8ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
Similarly, Policy Servers must interact with each other securely to allow the communication and enforcement of policies across the Internet.
同様に、Policy Serversは、インターネットの向こう側に方針のコミュニケーションと実施を許すためにしっかりと互いに対話しなければなりません。
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.
SenderとReceiverの両方が同じGCKS実体(アーキテクチャを集結する)を使って、SenderとReceiverが異なったGCKS実体(分配されたアーキテクチャ)を使う状況に対応しながら、2個のReceiver箱を表示します。 分配されたデザインでは、すべてのReceiversが同じキーと方針を入手しなければなりません。 マルチキャストグループの各メンバーはプライマリGCKS実体(例えばa明確で一貫するのに関してメートル法で測定された“nearest" GCKS実体)と対話するかもしれません。 同様に、GCKS実体はまた、分配されたアーキテクチャでアレンジされた1Policy Serversと対話するかもしれません。
3. Functional Areas
3. 機能的な領域
The Reference Framework identifies three functional areas. They are:
Reference Frameworkは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.
- Key Managementを分類してください。 この領域は材料を合わせる安全な分配と軽い飲食物に関係があります。 セクション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でさらにこの機能的な領域について議論します。
3.1. Multicast Data Handling
3.1. マルチキャストデータハンドリング
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つの風味を取ります: a。 ソース認証とデータ保全。 この機能性は、データが要求されたソースを発して、途中で変更されなかったのを(グループのメンバーか外部の攻撃者で)保証します。
Hardjono & Weis Informational [Page 9] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[9ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
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]はデータ通信量のためにMulticastのための定義に超能力を供給します。 「マルチキャストソース認証変換仕様」[PCW]はマルチキャストでテスラアルゴリズムのソース認証の使用を定義します。
3.2. Group Key Management
3.2. グループKey Management
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.
与えられた状況の中で広がっている方針の文脈で合わせることの材料の管理に関連する要件を見なければなりません。
Hardjono & Weis Informational [Page 10] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[10ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
Core to the area of key management is Security Association (SA) Management, which will be discussed further below.
かぎ管理の領域へのコアはSecurity Association(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.
「グループKey Managementアーキテクチャ」というドキュメント[BCDL]はマルチキャストセキュリティのためにさらにかぎ管理アーキテクチャを定義します。 それは、Group Security Association(GSA)概念に建てて、さらにKey ServerとGroup Controllerの役割を定義します。
"The Group Domain of Interpretation" [RFC3547], "GSAKMP" [GSAKMP], and "MIKEY" [ACLNM] are three instances of protocols implementing the group key management function.
「InterpretationのGroup Domain」[RFC3547]、"GSAKMP"[GSAKMP]、および「マイキー」[ACLNM]はグループが主要な管理機能であると実装するプロトコルの3つのインスタンスです。
3.3. Multicast Security Policies
3.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.
マルチキャストSecurity PoliciesはReference Frameworkの他の要素のための操作のための規則を提供しなければなりません。 セキュリティPoliciesは臨時のファッションである場合に分配されるかもしれません。 しかしながら、Policy ControllerがSecurity Policies方針をグループに分配するなら、保証の、より良いコーディネートと、より高いレベルは達成されます。
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:
Group Controller要素とメンバー(送付者と受信機)要素の方針の適用について説明しなければなりません。 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].
マルチキャスト安全保障政策における仕事に関する例はDynamic Cryptographic Context Managementプロジェクト[騒々しい音をたてる]、Group Key Managementプロトコル[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,
安全なマルチキャストのための方針作成で、既存のユニキャスト方針フレームワークでただ一つの管理者特約保険証券より多くの数個の寸法を想定します。 安全なマルチキャストグループで、通常、大きく、彼らのまさしくその本質はいくつかの管理ドメインに及びます。
Hardjono & Weis Informational [Page 11] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[11ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
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つのデータモデルから別のモデルまでの翻訳はマルチキャストグループ環境ではるかに難しいです。 グループ会員資格が複数の管理ドメインにかかるとき、これは特に本当です。 利用可能な安全保障政策メカニズムがともに理解して、実装することができるより正確な規則にPolicy Managementツールで高いレベルで指定された方針を翻訳しなければなりません。 マルチキャストコミュニケーションとその複数の関係者に対応するとき、個々の翻訳が他の翻訳のすべての結果で共同利用できるメカニズムの使用におけるそれぞれの関与している結果のために働いたのは、不可欠です。 通常、ハイレベルの方針から特定保険証券オブジェクトまでの翻訳は、グループのメンバーのすべてのコミュニケーションを達成するために同じオブジェクトをもたらさなければなりません。 方針翻訳が同じオブジェクトをもたらすという要件はハイレベルの方針で使用と表現に規制を置きます。
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.
また、方針交渉と翻訳が仲間に入る不可欠の部分として実行されるのも、重要です。 彼らがグループコミュニケーションに参加できないなら、メンバーをグループに追加するのは無意味です。
4. Group Security Associations (GSA)
4. グループセキュリティ協会(GSA)
4.1. The Security Association
4.1. セキュリティ協会
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])の一般的に使用された期間です。 このドキュメントは、その方針に合っているネットワークトラフィックのためのセキュリティー・サービスを提供するどんなセットの方針と暗号化キーも意味するのに用語を使用します。 通常、Security Associationは以下の属性を含んでいます:
- 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)かクッキー組と、アイデンティティに索引をつけます。 - モード、主要な生涯、およびキー長が認証か秘密性にアルゴリズムなどのように使用した暗号の方針。 - 認証や、暗号化や署名キーなどのキー。
Hardjono & Weis Informational [Page 12] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[12ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
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]などの)より異なった抽象化を使用します。 GroupのKey Managementの機能的な領域で使用される抽象化は二地点間かぎ管理抽象化から組み込まれるかもしれません。
4.2. Structure of a GSA: Introduction
4.2. GSAの構造: 序論
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を設立します。 しかしながら、グループ重要経営者側は最大3SAsを必要とするかもしれません。 これらのSAsは後のセクションで説明されます。
A GSA contains all of the SA attributes identified in the previous section, as well some additional attributes pertaining to the group. As shown in Figure 3, the GSA builds on the SA in two distinct ways.
GSAは、グループに関しながら、前項の、そして、よくいくつかとして追加している特定されたコネが結果と考えるSA属性のすべてを含んでいます。 図3に示されるように、GSAはSAに2つの異なった方法で建てます。
- 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.
- 2番目、GSAはSAsの集合です。(図3(b))。 GSAは複数のSAsから成ります、そして、これらのSAsはいくつかの独立している目的に使用されるかもしれません。
+---------------+ +-------------------+
| GSA | | GSA |
| | | +-----+ +-----+ |
| | | | SA1 | | SA2 | |
| +----+ | | +-----+ +-----+ |
| | SA | | | +-----+ |
| +----+ | | | SA3 | |
| | | +-----+ |
+---------------+ +-------------------+
+---------------+ +-------------------+ | GSA| | GSA| | | | +-----+ +-----+ | | | | | SA1| | SA2| | | +----+ | | +-----+ +-----+ | | | SA| | | +-----+ | | +----+ | | | SA3| | | | | +-----+ | +---------------+ +-------------------+
(a) superset (b) aggregation
(a) スーパーセット(b)集合
Figure 3: Relationship of GSA to SA
図3: SAへのGSAの関係
Hardjono & Weis Informational [Page 13] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[13ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
4.3. Structure of a GSA: Reasoning
4.3. GSAの構造: 推理
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 | |
| +-----------------+ +-----------------+ |
| |
| |
+------------------------------------------------------------+
+------------------------------------------------------------+ | | | +------------------+ | | | GCKS| | | | | | | | レッジ・レッジ| | | | /REKEY\| | | +---/-----|----\---+ | | / | \ | | / | \ | | / | \ | | / | \ | | / | \ | | +----------/------+ | +------\----------+ | | | レッジ| | | レッジ| | | | REKEY-----+----REKEY| | | | 送付者| | 受信機| | | | データ----------データ| | | +-----------------+ +-----------------+ | | | | | +------------------------------------------------------------+
Figure 4: GSA Structure and 3 categories of SAs
図4: SAsのGSA Structureと3つのカテゴリ
The three categories of SAs are:
SAsの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.
- 再主要な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.
それぞれのこれらのSAsはさらに詳細に次のセクションで定義されます。
Hardjono & Weis Informational [Page 14] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[14ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
4.4. Definition of GSA
4.4. GSAの定義
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.
SAsの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とグループのメンバーとの(双方向)のユニキャストコミュニケーションに必要です(SenderかReceiverであることにかかわらず)。 このSAはGCKSとメンバーだけの間に設立されます。 グループキー、メンバー(または、将来のメンバー)への方針分配、およびSenderとReceiverメンバーへのグループキー普及と共にアクセスコントロールで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.
Registration SAは、GCKSからGSA情報を引くためにメンバーによって開始されます。 これはメンバーがグループから切断された後にどのように安全を接合するために、分類するよう要求するか、またはGSAキーを再初期化させるかという(例えば、ホストコンピュータはいつ再主要な操作の間、オフにされていますか)ことです。 GCKSから引き下げられたGSA情報はGSAの一部と定義された他の2SAsに関連します。
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の他の要素を保護するのに使用されることに注意してください。 そういうものとして、Registration SAは重要であり、GSAの定義で他の2SAsから不可分です。
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の要件は登録プロトコルがそのRegistration SAを作成する必要性を含意しません。 いくつかの手動の手段で登録SAは代わりにスマートカードで分配されるようにセットアップであるかもしれません。 したがって、重要なことはRegistration 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.
1与えられたGCKSの見解から、グループにはメンバー(Senders、そして/または、Receivers)がいるのと同じくらい多くのユニークな登録SAsが来ています。 これはいくつかのアプリケーションに関するスケーラビリティ心配を構成するかもしれません。 登録SAは短い生涯で要求次第で設立されるかもしれませんが、再キーとデータ機密保護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が再同期か反登録目的の役に立つそのような長い期間。
Hardjono & Weis Informational [Page 15] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[15ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
- 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の一部として新しいSAsを「押す」能力を必要とします。 これらの新しいSAsをすべてのグループのメンバーに送らなければなりません。 他の場合では、GCKSはすぐに1人以上のグループのメンバーへのアクセスを取り消す能力を必要とします。 これらの必要性の両方がRe主要な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からすべてのグループのメンバーまでこのRe主要なSAはかぎ管理メッセージの単方向のマルチキャスト伝達です。 そういうものとして、この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.
rekey SAは、GSAの一部になるのに絶対に必要ではありません。 例えば、いくつかのグループの寿命が十分短いかもしれないので、rekeyは必要ではありません。 逆に、グループのための方針は異なったタイプの複数のrekey SAsを指定するかもしれません。 例えば、GCとカンザスが別々の実体であるなら、GCはグループ会員資格を調整してください。そうすれば、カンザスが新しいDATA SAsと共にrekeyメッセージを提供してもよいというrekeyメッセージを提供するかもしれません。
- Data Security SA (DATA):
The Data Security SA protects data between member senders and
member receivers.
- データ機密保護SA(データ): Data Security 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.
1SAsがデータメッセージのSenderから他のグループのメンバーまでのマルチキャスト伝達に必要です。 この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のこの3番目のカテゴリのインスタンスの数にかかわらず、この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).
Receiversの見解から、メンバー送付者(1以上)のための少なくとも1つのデータ機密保護のSAはグループで来ています。 グループに1つ以上のデータ機密保護のSAがあるなら、データ機密保護プロトコルには、SAs(例えば、SPIと)を差別化する手段がなければなりません。
Hardjono & Weis Informational [Page 16] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[16ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
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の組み合わせ。
4.5. Typical Compositions of a GSA
4.5. GSAの典型的な構成
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、および独身のDATA SAだけを必要とするかもしれません。 - 「1セッションあたりの賃金」アプリケーション。(そこでは、セッションに必要であるSA情報のすべてがREG SAの上に分配されるかもしれません)。 DATA SAsの再キーと再初期化は必要でないかもしれないので、REKEY SAが全くありません。 - 購読グループ。(そこでは、会員資格が変化するのに従って、材料を合わせるのが変えられます)。 REG SAが他のSAsを分配するのに必要です。 REKEY SAが、時間会員資格変化でDATA SAを再初期化するのに必要です。
5. Security Services
5. セキュリティー・サービス
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にSendersとReceiversとのマルチキャストデータインタフェースに起こります。 また、認証と秘密性サービスがKey Serverとグループのメンバー(すなわち、図2のSendersとReceivers)の間で必要であるかもしれませんが、マルチキャストかぎ管理に必要であるサービスはマルチキャストと同様にユニキャストであるかもしれません。 したがって、Multicast Security Reference Frameworkのセキュリティー・サービスは1個以上の図2のインタフェースに沿って具体的な機能を特定します。
Hardjono & Weis Informational [Page 17] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[17ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
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マルチキャストと応用層マルチキャストセキュリティのための信頼関係、詳細な機能条件書、性能要件、適当なアルゴリズム、およびプロトコル仕様を分析するのを試みません。 代わりに、セキュリティー・サービスがアルゴリズムとプロトコルでさらに定義されて、実現されるようにその仕事は起こるでしょう。
5.1. Multicast Data Confidentiality
5.1. マルチキャストデータの機密性
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.
このセキュリティー・サービスはReceiverの終わりにSenderの終わりと復号化でマルチキャストデータの暗号化を扱います。 また、このセキュリティー・サービスはMulticast Policy Managementに応じてMulticast Key Managementによって供給される合わせることの材料を適用するかもしれませんが、それは両方から独立しています。
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.
識別にはセキュリティー・サービスがあるMulticast Data Confidentialityの重要な部分とマルチキャストデータに使用されるべきである特定の暗号に関する動機。 明らかに、すべてではなく、暗号は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.
応用層マルチキャストに関して、何らかの考慮が、マルチキャストの環境の欠いている入場コントロールにおける暗号化されたデータを送るという効果を考えるのに必要です。そこでは、実際にどんなアプリケーション・プログラムもマルチキャストセキュリティプロトコルへの参加の如何にかかわらずマルチキャストイベントを接合できます。 したがって、また、このセキュリティー・サービスはアプリケーション・プログラムへのマルチキャスト秘密性サービス(意図していてそうでない)の効果に関係があります。SendersとReceiversの両方への効果は考えられます。
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では、Multicast Data Confidentialityセキュリティー・サービスはSendersとReceiversとのインタフェースに沿ってMulticast Data Handling Areaに置かれます。 マルチキャストデータの機密性が必要であるときに、このセキュリティー・サービスに対する仕事から実現されるアルゴリズムとプロトコルは図2の他のインタフェースと領域に適用されるかもしれません。
5.2. Multicast Source Authentication and Data Integrity
5.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
このセキュリティー・サービスはマルチキャストデータのソース認証と保全検証を扱います。 それはSenderの終わりとReceiverの終わりにされる変換を含んでいます。 それは、Multicast Policy Managementに応じて適切な署名と検証キーが以下で説明されるようにMulticast Key Managementを通して提供されると仮定します。 これはコネクションレスでリアルタイムによるマルチキャストセキュリティの、より困難な領域の1つです。
Hardjono & Weis Informational [Page 18] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[18ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
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では、Multicast SourceとData Authenticationセキュリティー・サービスはSendersとReceiversとのインタフェースに沿ってMulticast Data Handling Areaに置かれます。 この機能的な領域に作成されるアルゴリズムとプロトコルは他の機能的な領域でのGroup Key Managementなどのマルチキャストサービスを利用するセキュリティー・サービスに適用性を持っているかもしれません。
5.3. Multicast Group Authentication
5.3. マルチキャストグループ認証
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.
Multicast Group Authenticationセキュリティー・サービスはSendersとReceiversとのインタフェースに沿ってMulticast Data Handling Areaに置かれます。
5.4. Multicast Group Membership Management
5.4. マルチキャストグループ会員資格管理
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]).
このセキュリティー・サービスはGroup ControllerからGroup Controllerとのメンバーの登録、およびメンバーの反-登録の機能性について説明します。 これらはセキュリティ機能です。(その機能はIPマルチキャストグループが「接合し」て、「いなくなる」というメンバーがグループ入場制御プロトコル(すなわち、IGMP[RFC3376]、MLD[RFC3019])の一部として実行する必要があるかもしれない操作によって独立しています)。
Registration includes member authentication, notification and negotiation of security parameters, and logging of information according to the policies of the group controller and the would-be
グループコントローラとひとりよがりの方針によると、登録はセキュリティパラメタ、および情報の伐採のメンバー認証、通知、および交渉を含んでいます。
Hardjono & Weis Informational [Page 19] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[19ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
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では、Multicast Group Membershipセキュリティー・サービスは、Group Key Management Areaに置かれて、SendersとReceiversにインタフェースを持っています。
5.5. Multicast Key Management
5.5. マルチキャストKey Management
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.
- 材料(例えば、グループ暗号化と認証キー、キーが集団経営に使用した補助物、ソース認証のためのキーなど)を合わせる電流に関するメンバー(送付者かReceiver)通知を分類する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.
このセキュリティの責任の中では、サービスは、Key Serversとグループのメンバーの間のキーの安全な管理、材料、およびスケーラビリティを合わせるマルチキャスト分配のための問題提示またはマルチキャストかぎ管理[RFC2627、BMS]のための他の性能要件です。 主要なServersとグループのメンバーは認証と承認の増強されたスケーラビリティに、一般的な公開鍵暗号基盤(PKI)を利用するかもしれません。
To allow for an interoperable and secure IP multicast security protocol, this security service may need to specify host abstractions such as a group security association database (GSAD) and a group security policy database (GSPD) for IP multicast security. The degree of overlap between IP multicast and application-layer multicast key management needs to be considered. Thus, this security service takes into account the key management requirements for IP
共同利用できて安全なIPマルチキャストセキュリティプロトコルを考慮するために、このセキュリティー・サービスは、グループセキュリティ協会データベース(GSAD)やIPマルチキャストセキュリティのためのグループ安全保障政策データベース(GSPD)などのホスト抽象化を指定する必要があるかもしれません。 考えられるべきIPマルチキャストと応用層マルチキャストかぎ管理の必要性の間のオーバラップの度合い。 したがって、このセキュリティー・サービスはIPのためのかぎ管理要件を考慮に入れます。
Hardjono & Weis Informational [Page 20] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[20ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
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).
マルチキャスト、応用層マルチキャストと、Multicast Key Managementセキュリティー・サービスのどんな度合いの特定の実現が両方を満たすことができるかへのかぎ管理要件。 そのうえ、ISAKMPは、IPマルチキャストと応用層マルチキャストセキュリティ[RFC2408]の両方のためのマルチキャストかぎ管理に広げることができるように設計されています。 したがって、マルチキャストかぎ管理プロトコルは既存のISAKMP規格のPhase1とPhase2つのプロトコルを使用するかもしれません、ことによると必要な拡大(GDOIなどの[RFC3547]か応用層マルチキャストセキュリティ)で。
This security service also describes the functionality of the communication related to key management among different GCKS servers in a distributed group design.
また、このセキュリティー・サービスは分配されたグループデザインにおける異なったGCKSサーバの中でかぎ管理に関連するコミュニケーションの機能性について説明します。
Multicast Key Management appears in both the centralized and distributed designs as shown in Figure 2 and is placed in the Group Key Management Area.
マルチキャストKey Managementは、図2に示されるように集結されて分配されたデザインで見えて、Group Key Management Areaに置かれます。
5.6. Multicast Policy Management
5.6. マルチキャスト政策管理
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つはマルチキャスト方針の異なった領域を特定することです。 マルチキャストPolicy Managementはマルチキャストセキュリティのための方針サーバ、IPマルチキャストと応用層マルチキャストセキュリティに使用される、特定の方針定義、およびPolicy ServerとKey Serverの間の通信プロトコルのデザインを含んでいます。このセキュリティー・サービスは、Policy Decision Point(PDP)とPolicy Enforcement Point(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.
Multicast Policy Managementセキュリティー・サービスはGCKSのインスタンスのコミュニケーションの機能性についてPolicy Serverのインスタンスに説明します。伝えられた情報はグループに関して方針を含むかもしれません、会員資格、物質的な定義、彼らの許されている用途、および他の情報を合わせて。 また、このセキュリティー・サービスはPolicy Serversの間と、そして、Policy Serversの中でコミュニケーションについて説明します。 グループのメンバーが直接このセキュリティー・サービスに参加しないと予想されます。 しかしながら、このオプションは除外されません。
Hardjono & Weis Informational [Page 21] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[21ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
6. Security Considerations
6. セキュリティ問題
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はマルチキャストグループセキュリティー体系にネットワークインフラの関係について説明します。
6.1. Multicast Data Handling
6.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はこの領域のためのセキュリティ要件について詳しく説明します。
6.2. Group Key Management
6.2. グループKey Management
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はさらに詳細にこの領域のセキュリティ要件について説明します。
6.3. Multicast Security Policies
6.3. マルチキャスト安全保障政策
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.
マルチキャスト安全保障政策を提供する暗号のプロトコルがその方針を分配するのに原因となるので、方針の保全は維持されます。 また、方針自体が秘密であるなら、彼らもグループコントローラとグループのメンバーを認証して、トランジットの間、方針の秘密性を提供するのに原因となります。
Hardjono & Weis Informational [Page 22] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[22ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
7. Acknowledgements
7. 承認
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つの研究論文からテキストの多くを本書では得ました。 このドキュメントのためのフレームワークはトーマスHardjono、Ranカネッティ、マークBaugher、およびピートDinsmoreによって共同書かれた論文から来ました。 GSAの記述はヒュー・ハーニー、マークBaugher、およびトーマスHardjonoによって共同執筆されたドキュメントから来ました。 ジョージGrossはこのドキュメントの後のバージョンに含まれていた多くの改良を勧めました。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、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.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは議定書を作ります」、RFC2408、1998年11月。
8.2. Informative References
8.2. 有益な参照
[ACLNM] J. Arkko, et. al., "MIKEY: Multimedia Internet KEYing",
Work in Progress, December 2003.
et[ACLNM]J.Arkko、アル、「マイキー:」 「マルチメディアインターネットの合わせること」は進歩、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のためのマルチキャストフレームワーク、超能力、」、10月2002、進行中で、働いてください。
[BCDL] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, "Group
Key Management Architecture", Work in Progress,
September 2003.
R.カネッティ、L.Dondeti、F.リンドホルム、「グループKey Managementアーキテクチャ」という[BCDL]M.Baugherは進歩、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.シャーマン、大きいダイナミックなグループのためのKey Management: 1方法のFunction TreesとAmortized初期設定、しばしば00.txtをgroupkeymgmtしている http://www.securemulticast.org/draft-balenson- 、Progress、1999年2月のWork。
[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.、チェンP.C.、Pendarakis D.、ラオ、J.、Rohatgi P.、シャハD.、「安全なインターネットマルチキャストのためのIPSecベースのホストアーキテクチャ」、 http://www.isoc.org/isoc/conferences/ndss/2000/ 議事/028.pdf(NDSS2000)。
Hardjono & Weis Informational [Page 23] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[23ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
[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.、「大きいダイナミックなグループのための方針を拠点とするセキュリティ管理:」 DARPA情報の「DCCMプロジェクトの概要」と生存性コンファレンスとエキスポ、 http://download.nai.com/products/media/nai/doc/discex- 110199.doc。
[GSAKMP] H. Harney, et. al., "GSAKMP", Work in Progress, October
2003.
et[GSAKMP]H.ハーニー、アル、10月2003、"GSAKMP"は進行中で働いています。
[Har1] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Specification", RFC 2093, July 1997.
[Har1] ハーニーとH.とC.Muckenhirn、「グループKey Managementプロトコル(GKMP)仕様」、RFC2093、1997年7月。
[Har2] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094, July 1997.
[Har2] ハーニーとH.とC.Muckenhirn、「グループKey Managementプロトコル(GKMP)アーキテクチャ」、RFC2094、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.、「アンチゴーネ:」 「Secure Group CommunicationのためのFlexible Framework」、Eight USENIX Security SymposiumのProceedings、pp99-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、テスラ: 「マルチキャストソース認証変換仕様」、処理中の作業、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)を議定書の中で述べてください」 「プロトコル仕様」、RFC2362、1998年6月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC2406bis] Kent, S., "IP Encapsulating Security Payload (ESP)",
Work in Progress, March 2003.
「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」という[RFC2406bis]ケント、S.は進歩、2003年3月に働いています。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 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.エージー、「マルチキャストのための管理を合わせてください」 「問題とアーキテクチャ」、RFC2627、9月1998日
[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)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
Hardjono & Weis Informational [Page 24] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[24ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
[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.、Rajan、R.、およびA.Sastry)は「プロトコルを獲得(一般的なオープンポリシーサービス)」、RFC2748、2000年1月。
[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、「マルチキャストリスナー発見プロトコルのためのIPバージョン6管理情報ベース」、RFC3019、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インチ、RFC3376、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.とリゾーとM.とハンドレーとM.とJ.クロウクロフト、「信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の使用」、RFC3453、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.ハーニー、「解釈のグループドメイン」、RFC3547、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.、徒党: Agreement、IEEE ICDCS1998年5月98年に主要なGroupへのNew Approach。
9. Authors' Addresses
9. 作者のアドレス
Thomas Hardjono VeriSign 487 E. Middlefield Rd. Mountain View, CA 94043, USA
トーマスHardjonoベリサイン487E.Middlefield通り マウンテンビュー、カリフォルニア 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
ブライアンウィスシスコシステムズ170w.タスマンDrive、サンノゼ、カリフォルニア95134-1706、米国
Phone: (408) 526-4796 EMail: bew@cisco.com
以下に電話をしてください。 (408) 526-4796 メールしてください: bew@cisco.com
Hardjono & Weis Informational [Page 25] RFC 3740 Multicast Group Security Architecture March 2004
Hardjonoとウィス情報[25ページ]のRFC3740Multicastは2004年のセキュリティー体系行進のときに分類されます。
10. Full Copyright Statement
10. 完全な著作権宣言文
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)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Hardjono & Weis Informational [Page 26]
HardjonoとウィスInformationalです。[26ページ]
一覧
スポンサーリンク
