RFC2627 日本語訳
2627 Key Management for Multicast: Issues and Architectures. D.Wallner, E. Harder, R. Agee. June 1999. (Format: TXT=59263 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Wallner
Request for Comments: 2627 E. Harder
Category: Informational R. Agee
National Security Agency
June 1999
コメントを求めるワーキンググループD.ウォルナーの要求をネットワークでつないでください: 2627年のE.の、より困難なカテゴリ: 情報のR.エージー国家安全保障局1999年6月
Key Management for Multicast: Issues and Architectures
マルチキャストのための主要な管理: 問題とアーキテクチャ
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 (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. A rekey may be necessary upon the compromise of a user or for other reasons (e.g., periodic rekey). In particular, this report identifies a technique which allows for secure compromise recovery, while also being robust against collusion of excluded users. This is one important feature of multicast key management which has not been addressed in detail by most other multicast key management proposals [1,2,4]. The benefits of this proposed technique are that it minimizes the number of transmissions required to rekey the multicast group and it imposes minimal storage requirements on the multicast group.
このレポートはマルチキャストコミュニケーションセッションのためのかぎ管理の難問の議論を含んでいます。 それは一般的なネットのキーでマルチキャストグループを初期化して、マルチキャストグループを「再-合わせ」て、あるかぎ管理に関して重要な2つの主な領域に焦点を合わせます。 rekeyがユーザの感染か他の理由(例えば、周期的なrekey)に必要であるかもしれません。 特に、このレポートはまた、除かれたユーザの共謀に対して強健である間に安全な感染回復を考慮するテクニックを特定します。 これは他のほとんどのマルチキャストかぎ管理提案[1、2、4]で詳細に演説されていないマルチキャストかぎ管理の1つの重要な特徴です。 この提案されたテクニックの利益はマルチキャストが分類するrekeyに必要であるトランスミッションの数を最小にするということです、そして、それは最小量のストレージ要件をマルチキャストグループに課します。
1.0 MOTIVATION
1.0 動機
It is recognized that future networks will have requirements that will strain the capabilities of current key management architectures. One of these requirements will be the secure multicast requirement. The need for high bandwidth, very dynamic secure multicast communications is increasingly evident in a wide variety of commercial, government, and Internet communities. Specifically, the secure multicast requirement is the necessity for multiple users who share the same security attributes and communication requirements to securely communicate with every other member of the multicast group using a common multicast group net key. The largest benefit of the
将来のネットワークには現在のかぎ管理アーキテクチャの能力を張る要件があると認められます。 これらの要件の1つは安全なマルチキャスト要件になるでしょう。 高帯域の必要性、非常にダイナミックな安全なマルチキャストコミュニケーションはますますさまざまなコマーシャル、政府、およびインターネットコミュニティで明白です。 明確に、安全なマルチキャスト要件は同じセキュリティー属性を共有する複数のユーザの必要性です、そして、一般的なマルチキャストを使用することでしっかりとマルチキャストグループのすべての他のメンバーとコミュニケートするというコミュニケーション要件はネットのキーを分類します。 最も大きいのは利益を得ます。
Wallner, et al. Informational [Page 1] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[1ページ]のRFC2627Key Management
multicast communication being that multiple receivers simultaneously get the same transmission. Thus the problem is enabling each user to determine/obtain the same net key without permitting unauthorized parties to do likewise (initializing the multicast group) and securely rekeying the users of the multicast group when necessary. At first glance, this may not appear to be any different than current key management scenarios. This paper will show, however, that future multicast scenarios will have very divergent and dynamically changing requirements which will make it very challenging from a key management perspective to address.
複数の受信機が同時に同じトランスミッションを得るということであるマルチキャストコミュニケーション。 したがって、問題は、必要であるときに、マルチキャストグループのユーザを「再-合わせ」ながら権限のないパーティーが同様(マルチキャストグループを初期化する)にしっかりとすることを許可しない、各ユーザが同じネットのキーを決定するか、または入手するのを可能にしています。 一見したところでは、これは現在のかぎ管理シナリオと少しも異なるように見えないかもしれません。 しかしながら、この論文は、将来のマルチキャストシナリオにはそれを非常にかぎ管理見解からアドレスまでやりがいがあるようにする非常に分岐していてダイナミックに変化している要件があるのを示すでしょう。
2.0 INTRODUCTION
2.0 序論
The networks of the future will be able to support gigabit bandwidths for individual users, to large groups of users. These users will possess various quality of service options and multimedia applications that include video, voice, and data, all on the same network backbone. The desire to create small groups of users all interconnected and capable of communicating with each other, but who are securely isolated from all other users on the network is being expressed strongly by users in a variety of communities.
未来のネットワークは個々のユーザのためにユーザの大きいグループにギガビット帯域幅をサポートすることができるでしょう。 これらのユーザには、様々なサービスの質オプションとビデオ、声、およびデータを含んでいるマルチメディア応用があるでしょう、すべて同じネットワーク基幹で。 すべてインタコネクトされていて互いにコミュニケートだったことできる状態で小集団のユーザを創造するネットワークの他のすべてのユーザからしっかりと孤立しているのが、さまざまな共同体でユーザによって強く言い表すことにされるのであるということである願望。
The key management infrastructure must support bandwidths ranging from kilobits/second to gigabits/second, handle a range of multicast group sizes, and be flexible enough for example to handle such communications environments as wireless and mobile technologies. In addition to these performance and communications requirements, the security requirements of different scenarios are also wide ranging. It is required that users can be added and removed securely and efficiently, both individually and in bulk. The system must be resistant to compromise, insofar as users who have been dropped should not be able to read any subsequent traffic, even if they share their secret information. The costs we seek to minimize are time required for setup, storage space for each end user, and total number of transmissions required for setup, rekey and maintenance. It is also envisioned that any proposed multicast security mechanisms will be implemented no lower than any layer with the characteristics of the network layer of the protocol stack. Bandwidth efficiency for any key management system must also be considered. The trade-off between security and performance of the entire multicast session establishment will be discussed in further detail later in this document.
かぎ管理インフラストラクチャは、キロビット/秒からギガビット/秒まで及ぶ帯域幅をサポートして、さまざまなマルチキャストグループサイズを扱って、例えばワイヤレスの、そして、モバイルの技術のようなコミュニケーション環境を扱うほどフレキシブルでなければなりません。 これらの性能とコミュニケーション要件に加えて異なったシナリオのセキュリティ要件はまた、広い及ぶことです。 しっかりと、効率的にユーザを加えて、外すことができるのが個別と大量に必要です。 システムは妥協するために抵抗力がなければなりません、下げられたユーザがどんなその後のトラフィックも読むことができないべきである限り、彼らが自分達の秘密の情報を共有しても。 私たちが最小にしようとするコストはセットアップに必要である時間です、と各エンドユーザ、および総数の送信のための集積スペースはセットアップ、rekey、およびメインテナンスのために必要としました。 また、思い描かれて、どんな提案されたマルチキャストセキュリティー対策もプロトコル・スタックのネットワーク層の特性があるどんな層よりも低く実装されないのは、そうです。 また、どんなかぎ管理システムのための帯域幅効率も考えなければなりません。 後で詳細で本書では全体のマルチキャストセッション設立のセキュリティと性能の間のトレードオフについて議論するでしょう。
Wallner, et al. Informational [Page 2] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[2ページ]のRFC2627Key Management
The following section will explain several potential scenarios where multicast capabilities may be needed, and quantify their requirements from both a performance and security perspective. It will be followed in Section 4.0 by a list of factors one must consider when designing a potential solution. While there are several security services that will be covered at some point in this document, much of the focus of this document has been on the generation and distribution of multicast group net keys. It is assumed that all potential multicast participants either through some manual or automated, centralized or decentralized mechanism have received initialization keying material (e.g. certificates). This document does not address the initialization key distribution issue. Section 5 will then detail several potential multicast key management architectures, manual (symmetric) and public key based (asymmetric), and highlight their relative advantages and disadvantages (Note:The list of advantages and disadvantages is by no means all inclusive.). In particular, this section emphasizes our technique which allows for secure compromise recovery.
以下のセクションは、マルチキャスト能力が必要であるかもしれないいくつかの潜在的シナリオについて説明して、性能とセキュリティ見解の両方からのそれらの要件を定量化するでしょう。 セクション4.0では、要素のリストは、潜在的ソリューションを設計すると考えなければならないということになるでしょう。 本書ではこのドキュメントの焦点の大部分が何らかのポイントであったところでカバーされているいくつかのセキュリティー・サービスがある間、マルチキャストの生成と分配のときに、ネットのキーを分類してください。 何らかの手動の、または、自動化されたか、集結されたか分散しているメカニズムを通どちらかだったすべての潜在的マルチキャスト関係者が材料(例えば、証明書)を合わせる初期化を受けたと思われます。 このドキュメントは初期化の主要な分配問題を扱いません。 次に、セクション5がいくつかの潜在的マルチキャストかぎ管理アーキテクチャを詳しく述べて、マニュアル(左右対称の)と公開鍵は、それらの相対的な利点と損失を基礎づけて(非対称の)、目立たせます(注意: 利点と損失のリストはすべて決して包括的ではありません。)。 特に、このセクションは安全な感染回復を考慮する私たちのテクニックを強調します。
3.0 MULTICAST SCENARIOS
3.0 マルチキャストシナリオ
There are a variety of potential scenarios that may stress the key management infrastructure. These scenarios include, but are not limited to, wargaming, law enforcement, teleconferencing, command and control conferencing, disaster relief, and distributed computing. Potential performance and security requirements, particularly in terms of multicast groups that may be formed by these users for each scenario, consists of the potential multicast group sizes, initialization requirements (how fast do users need to be brought on-line), add/drop requirements (how fast a user needs to be added or deleted from the multicast group subsequent to initialization), size dynamics (the relative number of people joining/leaving these groups per given unit of time), top level security requirements, and miscellaneous special issues for each scenario. While some scenarios describe future secure multicast requirements, others have immediate security needs.
かぎ管理インフラストラクチャを強調するかもしれないさまざまな潜在的シナリオがあります。 これらのシナリオは法施行、机上で検討する電子会議に制限されないで、命令して、会議を制御するのを除いた災害救助、および分散コンピューティングを含んでいます。 特に各シナリオのためにこれらのユーザによって結成されるかもしれないマルチキャストグループに関する潜在的性能とセキュリティ要件は潜在的マルチキャストグループサイズから成ります、初期化要件(どれくらい速く、オンラインで持って来られるべきユーザの必要性をするか); 要件(初期化へのその後のマルチキャストグループから加えられるのが必要である、または削除されたどれくらい速いユーザ)、サイズ力学(これらの時間の与えられた単位あたりのグループを加わるか、または残す人々の相対数)、最高平らなセキュリティ要件、および各シナリオのための種々雑多な増刊を加えるか、または下げてくださいか。 いくつかのシナリオが将来の安全なマルチキャスト要件について説明している間、他のものには、即座の安全要求があります。
As examples, let us consider two scenarios, distributed gaming and teleconferencing.
例と、2つのシナリオ、分配されたゲーミング、および電子会議を考えましょう。
Distributed gaming deals with the government's need to simulate a conflict scenario for the purposes of training and evaluation. In addition to actual communications equipment being used, this concept would include a massive interconnection of computer simulations containing, for example, video conferencing and image processing. Distributed gaming could be more demanding from a key management perspective than an actual scenario for several reasons. First, the nodes of the simulation net may be dispersed throughout the country.
分配されたゲーミングはトレーニングと評価の目的のために闘争シナリオをシミュレートする政府の必要性に対処します。 使用される実際の通信装置に加えて、この概念は例えばビデオ会議とイメージプロセッシングを含むコンピュータ・シミュレーションの大規模なインタコネクトを含んでいるでしょう。 分配されたゲーミングはいくつかの理由で実際のシナリオよりかぎ管理見解から過酷であるかもしれません。 まず最初に、シミュレーションネットのノードは全国いたる所で分散されるかもしれません。
Wallner, et al. Informational [Page 3] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[3ページ]のRFC2627Key Management
Second, very large bandwidth communications, which enable the possibility for real time simulation capabilities, will drive the need to drop users in and out of the simulation quickly. This is potentially the most demanding scenario of any considered.
2(非常に大きい帯域幅コミュニケーション)番目はシミュレーションとシミュレーションからユーザをすばやく下げる必要性を追い立てるでしょう。(コミュニケーションは実時間シミュレーション能力のために可能性を可能にします)。 考えられて、これは潜在的に最も過酷なシナリオですどんなも。
This scenario may involve group sizes of potentially 1000 or more participants, some of which may be collected in smaller subgroups. These groups must be initialized very rapidly, for example, in a ten second total initialization time. This scenario is also very demanding in that users may be required to be added or dropped from the group within one second. From a size dynamics perspective, we estimate that approximately ten percent of the group members may change over a one minute time period. Data rate requirements are broad, ranging from kilobits per second (simulating tactical users) to gigabits per second (multicast video). The distributed gaming scenario has a fairly thorough set of security requirements covering access control, user to user authentication, data confidentiality, and data integrity. It also must be "robust" which implies the need to handle noisy operating environments that are typical for some tactical devices. Finally, the notion of availability is applied to this scenario which implies that the communications network supplying the multicast capability must be up and functioning a specified percentage of the time.
このシナリオは潜在的に1000人以上の関係者のグループサイズにかかわるかもしれません。その或るものは、より小さいサブグループで集められるかもしれません。 例えば、12番目の総初期化時間の後に非常に急速にこれらのグループを初期化しなければなりません。 また、1秒以内にユーザによってグループから加えられなければならないか、または下げられなければならないかもしれないので、このシナリオも非常に過酷です。 サイズ力学見解から、私たちは、グループのメンバーのおよそ10パーセントが1分の期間にわたって変化するかもしれないと見積もっています。 秒(マルチキャストビデオ)あたり1秒あたりのキロビット(戦術のユーザをシミュレートする)からギガビットまで及んで、データ信号速度要件は広いです。 分配されたゲーミングシナリオには、アクセスコントロール、ユーザー認証へのユーザ、データの機密性、およびデータ保全を含んでいるかなり徹底的なセットのセキュリティ要件があります。 また、それも「強健でなければならない」(いくつかの戦術のデバイスに、典型的な騒がしい操作環境を扱う必要性を含意します)。 最終的に、有用性の概念は、マルチキャスト能力を供給する通信網が上がるに違いないのを含意するこのシナリオに適用されて、現代の指定された割合に機能しています。
The teleconference scenario may involve group sizes of potentially 1000 or more participants. These groups may take up to minutes to be initialized. This scenario is less demanding in that users may be required to be added or dropped from the group within seconds. From a size dynamics perspective, we estimate that approximately ten percent of the group members may change over a period of minutes. Data rate requirements are broad, ranging from kilobits per second to 100's of Mb per second. The teleconference scenario also has a fairly thorough set of security requirements covering access control, user to user authentication, data confidentiality, data integrity, and non-repudiation. The notion of availability is also applicable to this scenario. The time frame for when this scenario must be provided is now.
電子会議シナリオは潜在的に1000人以上の関係者のグループサイズにかかわるかもしれません。 これらのグループは、初期化されるために数分まで取るかもしれません。 秒以内にユーザによってグループから加えられなければならないか、または下げられなければならないかもしれないので、このシナリオはそれほど過酷ではありません。 サイズ力学見解から、私たちは、グループのメンバーのおよそ10パーセントが数分の期間変化するかもしれないと見積もっています。 データ信号速度要件が広い、1秒あたりのキロビットから変化するのは、100への1秒あたりのMbのそうです。 また、電子会議シナリオには、アクセスコントロール、ユーザー認証へのユーザ、データの機密性、データ保全、および非拒否を含んでいるかなり徹底的なセットのセキュリティ要件があります。 また、有用性の概念もこのシナリオに適切です。 このシナリオを提供しなければならない時の間の時間枠は現在です。
4.0 ARCHITECTURAL ISSUES
4.0 建築問題
There are many factors that must be taken into account when developing the desired key management architecture. Important issues for key management architectures include level (strength) of security, cost, initializing the system, policy concerns, access control procedures, performance requirements and support mechanisms. In addition, issues particular to multicast groups include:
必要なかぎ管理アーキテクチャを開発するとき考慮に入れなければならない多くの要素があります。 かぎ管理アーキテクチャのための切迫した課題はセキュリティのレベル(強さ)を含んでいます、費用、システム、方針関心、アクセス制御手順、性能要件、およびサポートメカニズムを初期化して。さらに、マルチキャストグループに特定の問題は:
Wallner, et al. Informational [Page 4] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[4ページ]のRFC2627Key Management
1. What are the security requirements of the group members? Most
likely there will be some group controller, or controllers. Do
the other members possess the same security requirements as the
controller(s)?
1. グループのメンバーのセキュリティ要件は何ですか? たぶん、何人かのグループコントローラ、またはコントローラがあるでしょう。 他のメンバーには、コントローラと同じセキュリティ要件がありますか?
2. Interdomain issues - When crossing from one "group domain" to
another domain with a potentially different security policy,
which policy is enforced? An example would be two users
wishing to communicate, but having different cryptoperiods
and/or key length policies.
2. Interdomain問題--潜在的に異なった安全保障政策で1「グループドメイン」から別のドメインまで交差するとき、どの方針が励行されますか? 例は交信することを願っていますが、異なったcryptoperiods、そして/または、キー長方針を持っている2人のユーザでしょう。
3. How does the formation of the multicast group occur? Will the
group controller initiate the user joining process, or will the
users initiate when they join the formation of the multicast
group?
3. マルチキャストグループの構成はどのように起こりますか? グループコントローラは彼らがマルチキャストグループの構成に参加するときユーザが開始するユーザ接合プロセス、または意志を開始するでしょうか?
4. How does one handle the case where certain group members have
inferior processing capabilities which could delay the
formation of the net key? Do these users delay the formation
of the whole multicast group, or do they come on-line later
enabling the remaining participants to be brought up more
quickly?
4. 1つはどのように、確信しているグループのメンバーがネットのキーの構成を遅らせることができた劣った処理能力を持っているケースを扱いますか? これらのユーザが全体のマルチキャストグループの構成を遅らせますか、または後で残っている関係者が、よりすばやく育つのを可能にしながら、彼らはオンラインで来ますか?
5. One must minimize the number of bits required for multicast
group net key distribution. This greatly impacts bandwidth
limited equipments.
5. マルチキャストグループネット主要な分配に必要であるビットの数を最小にしなければなりません。 これは帯域幅の限られた機器に大いに影響を与えます。
All of these and other issues need to be taken into account, along with the communication protocols that will be used which support the desired multicast capability. The next section addresses some of these issues and presents some candidate architectures that could be used to tackle the key management problem for multicasting.
これらと他の問題のすべてが、考慮に入れられる必要があって、通信プロトコルと共に、それは使用されるでしょう(必要なマルチキャスト能力をサポートします)。 次のセクションは、マルチキャスティングのためにかぎ管理問題に取り組むために、これらの問題のいくつかを扱って、使用できたいくつかの候補アーキテクチャを提示します。
5.0 CANDIDATE ARCHITECTURES
5.0 候補アーキテクチャ
There are several basic functions that must be performed in order for a secure multicast session to occur. The order in which these functions will be performed, and the efficiency of the overall solution results from making trade-offs of the various factors listed above. Before looking at specific architectures, these basic functions will be outlined, along with some definition of terms that will be used in the representative architectures. These definitions and functions are as follows:
安全なマルチキャストセッションが起こるように実行しなければならないいくつかの基本機能があります。 これらの機能が実行される注文、および上に様々な要素のトレードオフを記載させるのからの総合的なソリューション結果の効率。 特定のアーキテクチャを見る前に、これらの基本機能は概説されるでしょう、代表しているアーキテクチャに使用される用語の何らかの定義と共に。 これらの定義と機能は以下の通りです:
Wallner, et al. Informational [Page 5] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[5ページ]のRFC2627Key Management
1. Someone determines the need for a multicast session, sets the
security attributes for that particular session (e.g.,
classification levels of traffic, algorithms to be used, key
variable bit lengths, etc.), and creates the group access
control list which we will call the initial multicast group
participant list. The entity which performs these functions
will be called the INITIATOR. At this point, the multicast
group participant list is strictly a list of users who the
initiator wants to be in the multicast group.
1. だれかが、マルチキャストセッションの必要性を決定して、その特定のセッション(例えば、トラフィックの分類レベル、使用されるべきアルゴリズム、基本変数は長さなどに噛み付いた)のためにセキュリティー属性を設定して、私たちが初期のマルチキャストグループ関係者リストを呼ぶつもりであるグループアクセスコントロールリストを作成します。 これらの機能を実行する実体はINITIATORと呼ばれるでしょう。 ここに、マルチキャストグループ関係者リストは厳密に、創始者がマルチキャストでものになりたがっているユーザのリストに分類されるということです。
2. The initiator determines who will control the multicast group.
This controller will be called the ROOT (or equivalently the
SERVER). Often, the initiator will become the root, but the
possibility exists where this control may be passed off to
someone other than the initiator. (Some key management
architectures employ multiple roots, see [4].) The root's job
is to perform the addition and deletion of group participants,
perform user access control against the security attributes of
that session, and distribute the traffic encryption key for the
session which we will call the multicast group NET KEY. After
initialization, the entity with the authority to accept or
reject the addition of future group participants, or delete
current group participants is called the LIST CONTROLLER.
2. 創始者は、だれがマルチキャストグループを制御するかを決心しています。 このコントローラがROOTと呼ばれる、(同等である、SERVER) しばしば、創始者は根になるでしょうが、可能性はこのコントロールが創始者以外のだれかに行われるかもしれないところに存在しています。 (いくつかのかぎ管理アーキテクチャが、重解を使って、[4]を見ます。) 根の仕事は、団体での申込者の追加と削除を実行して、そのセッションのセキュリティー属性に対してユーザアクセスコントロールを実行して、私たちがマルチキャストグループNET KEYと呼ぶつもりであるセッションのために主要なトラフィック暗号化を広げることです。 初期化の後に、将来の団体での申込者の追加を受け入れるか、拒絶する、または現在の団体での申込者を削除する権威がある実体はLIST CONTROLLERと呼ばれます。
This may or may not be the initiator. The list controller has
been distinguished from the root for reasons which will become
clear later. In short, it may be desirable for someone to have
the authority to accept or reject new members, while another
party (the root) would actually perform the function.
これは創始者であるかもしれません。 リストコントローラは後で明確になる理由で根と区別されました。 要するに、だれかには新しいメンバーを受け入れるか、または拒絶する権威があるのは、望ましいかもしれません、別のパーティー(根)は実際に機能を実行するでしょうが。
3. Every participant in the multicast session will be referred to
as a GROUP PARTICIPANT. Specific group participants other than
the root or list controller will be referred to as LEAVES.
3. マルチキャストセッションのすべての関係者がGROUP PARTICIPANTと呼ばれるでしょう。 根かリストコントローラ以外の特定の団体での申込者はLEAVESと呼ばれるでしょう。
4. After the root checks the security attributes of the
participants listed on the multicast group participant list to
make sure that they all support the required security
attributes, the root will then pass the multicast group list to
all other participants and create and distribute the Net Key.
If a participant on the multicast group list did not meet the
required security attributes, the leaf must be deleted from the
list.
4. ネットKeyを根がマルチキャストグループの関係者に記載された関係者のセキュリティー属性をチェックした後に、記載して、彼らが皆、必要なセキュリティー属性をサポートして、次に、根がマルチキャストグループリストを他のすべての関係者に渡すのを確実にして、作成して、分配してください。 マルチキャストグループリストの上の関係者が必要なセキュリティー属性を満たさなかったなら、リストから葉を削除しなければなりません。
Multiple issues can be raised with the distribution of the
multicast group list and Net Key.
マルチキャストグループリストとネットKeyの分配で複数の問題を提起できます。
Wallner, et al. Informational [Page 6] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[6ページ]のRFC2627Key Management
a. An issue exists with the time ordering of these functions.
The multicast group list could be distributed before or
after the link is secured (i.e. the Net Key is
distributed).
a。 時間がこれらの機能を注文している状態で、問題は存在しています。 以前かリンクが固定された(すなわち、ネットKeyは分配されています)後にマルチキャストグループリストを分配できました。
b. An issue exists when a leaf refuses to join the session.
If a leaf refuses to join a session, we can send out a
modified list before sending out the Net Key, however
sending out modified lists, potentially multiple times,
would be inefficient. Instead, the root could continue
on, and would not send the Net Key to those participants
on the list who rejected the session.
b。 葉が、セッションに参加するのを拒否するとき、問題は存在しています。 葉が、接合するのを拒否するなら、セッションであり、ネットKeyを出す前に私たちは変更されたリストを出すことができて、しかしながら、出している変更されたリスト(潜在的に複数の回)は効率が悪いでしょう。 根は、代わりに、続くことができて、リストの上のセッションを拒絶した関係者にネットKeyを送らないでしょう。
For the scenario architectures which follow, we assume the
multicast group list will be distributed to the group
participants once before the Net Key is distributed. Unlike
the scheme described in [4], we recommend that the multicast
group participant list be provided to all leaves. By
distributing this list to the leaves, it allows them to
determine upfront whether they desire to participate in the
multicast group or not, thus saving potentially unnecessary
key exchanges.
従うシナリオアーキテクチャのために、私たちは、ネットKeyが分配されている前にマルチキャストグループリストが一度団体での申込者に分配されると思います。 [4]で説明された体系と異なって、私たちは、マルチキャストグループ関係者リストがすべての葉に提供されることを勧めます。 このリストを葉に分配することによって、それでマルチキャストグループに参加することを望んでいるかどうか前払いで決定できます、その結果、潜在的に不要な主要な交換を保存します。
Four potential key management architectures to distribute keying material for multicast sessions are presented. Recall that the features that are highly desirable for the architecture to possess include the time required to setup the multicast group should be minimized, the number of transmissions should be minimized, and memory/storage requirements should be minimized. As will be seen, the first three proposals each fall short in a different aspect of these desired qualities, whereas the fourth proposal appears to strike a balance in the features desired. Thus, the fourth proposal is the one recommended for general implementation and use.
マルチキャストセッションのための材料を合わせる分配する4つの潜在的かぎ管理アーキテクチャが提示されます。 トランスミッションの数は最小にされるべきです、そして、アーキテクチャが所有するのにおいて非常に望ましい特徴がセットアップするのが必要である場合マルチキャストグループが最小にされるべきである時を含んでいると思い出してください、そして、メモリ/ストレージ要件は最小にされるべきです。 見られるように、最初の3つの提案がこれらの必要な品質の異なった局面にそれぞれ不足しますが、4番目の提案は特徴におけるバランスをとって、必要にするように見えます。 したがって、4番目の提案は一般的な実装と使用のために推薦されたものです。
Please note that these approaches also address securely eliminating users from the multicast group, but don't specifically address adding new users to the multicast group following initial setup because this is viewed as evident as to how it would be performed.
また、これらのアプローチがマルチキャストグループからユーザに排泄にしっかりと演説することに注意しなさい、ただし、これがそれがどう実行されるだろうかに関して明白な状態で見られるので初期のセットアップに続いて、明確にマルチキャストグループへの新しいユーザに付加に演説しないでください。
5.1 MANUAL KEY DISTRIBUTION
5.1 手動の主要な分配
Through manual key distribution, symmetric key is delivered without the use of public key exchanges. To set up a multicast group Net Key utilizing manual key distribution would require a sequence of events where Net Key and spare Net Keys would be ordered by the root of the multicast session group. Alternate (supersession) Net Keys are ordered (by the root) to be used in case of a compromise of a group participant(s). The Net Keys would be distributed to each individual
手動の主要な分配で、対称鍵は公開鍵交換の使用なしで提供されます。 マルチキャストをセットアップするために、手動の主要な分配を利用するグループネットKeyはネットKeyと予備Netキーズがマルチキャストセッション・グループの根によって注文されるイベントの系列を必要とするでしょう。 グループの関係者の感染の場合に代替の(更迭)ネットのキーズが使用されるよう命令されます(根に従って)。 Netキーズは各個人に分配されるでしょう。
Wallner, et al. Informational [Page 7] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[7ページ]のRFC2627Key Management
group participant, often through some centralized physical intermediate location. At some predetermined time, all group participants would switch to the new Net Key. Group participants use this Net Key until a predetermined time when they need another new Net Key. If the Net Key is compromised during this time, the alternate Net Key is used. Group participants switch to the alternate Net Key as soon as they receive it, or upon notification from the root that everyone has the new Net Key and thus the switch over should take place. This procedure is repeated for each cryptoperiod.
しばしばいくらかの集結された物理的な中間的な場所を通って関係者を分類してください。 いつかの予定された時に、すべての団体での申込者が新しいネットKeyに切り替わるでしょう。 団体での申込者は彼らが別の新しいネットKeyを必要とする予定された時までこのネットKeyを使用します。 ネットKeyがこの間に感染されるなら、代替のネットKeyは使用されています。 彼らがそれを受けるとすぐに、団体での申込者が代替のネットKeyに切り替わるか、または根からの通知のときに、皆で新しいネットKeyとその結果、スイッチが終わるようになるのは行われるべきです。 この手順は各cryptoperiodのために繰り返されます。
A scheme like this may be attractive because the methods exist today and are understood by users. Unfortunately, this type of scheme can be time consuming to set up the multicast group based on time necessary to order keying material and having it delivered. For most real time scenarios, this method is much too slow.
メソッドが今日、存在して、ユーザに解釈されるので、このような体系は魅力的であるかもしれません。 残念ながら、このタイプの体系は材料を合わせて、それを提供させながら注文するのに必要な時間に基づくマルチキャストグループを設立するのにおいて時間がかかっている場合があります。 ほとんどのリアルタイムのシナリオにおいて、このメソッドは非常に遅過ぎます。
5.2 N Root/Leaf Pairwise Keys Approach
5.2 N根/葉の対状キーアプローチ
This approach is a brute force method to provide a common multicast group Net Key to the group participants. In this scheme, the initiator sets the security attributes for a particular session, generates a list of desired group participants and transmits the list to all group participants. The leaves then respond with an initial acceptance or rejection of participation. By sending the list up front, time can be saved by not performing key exchanges with people who rejected participation in the session. The root (who for this and future examples is assumed to be the initiator) generates a pairwise key with one of the participants (leaves) in the multicast group using some standard public key exchange technique (e.g., a Diffie-Hellman public key exchange.) The root will then provide the security association parameters of the multicast (which may be different from the parameters of the initial pairwise key) to this first leaf. Parameters may include items such as classification and policy. Some negotiation (through the use of a Security Association Management Protocol, or SAMP) of the parameters may be necessary. The possibility exists for the leaf to reject the connection to the multicast group based on the above parameters and multicast group list. If the leaf rejects this session, the root will repeat this process with another leaf.
このアプローチは一般的なマルチキャストグループネットKeyを団体での申込者に提供する力任せのメソッドです。 この体系では、創始者は、特定のセッションのためにセキュリティー属性を設定して、必要な団体での申込者のリストを生成して、すべての団体での申込者にリストを伝えます。 そして、葉は参加の初期の承認か拒絶で応じます。 前払いでリストを送ることによって、セッションにおける参加を拒絶した人々と共に主要な交換を実行しないことによって、時間を節約できます。 根(これと将来の例のために創始者であると思われる)は、マルチキャストグループで何らかの標準の公開鍵取引技術(例えば、ディフィー-ヘルマンの公開鍵交換)を使用することで関係者のひとりにとって、主要な対状(いなくなる)を作ります。 そして、根はマルチキャスト(初期の対状キーのパラメタと異なっているかもしれない)のセキュリティ協会パラメタをこの最初の葉に提供するでしょう。 パラメタは分類や方針などの項目を含むかもしれません。 パラメタの何らかの交渉(Security Association Managementプロトコル、またはSAMPの使用による)が必要であるかもしれません。 葉が上記のパラメタとマルチキャストグループリストに基づくマルチキャストグループに接続を拒絶するように、可能性は存在しています。 葉がこのセッションを拒絶すると、根は別の葉でこのプロセスを繰り返すでしょう。
Once a leaf accepts participation in the multicast session, these two then choose a Net Key to be used by the multicast group. The Net Key could be generated through another public key exchange between the two entities, or simply chosen by the root, depending upon the policy which is in place for the multicast group ( i.e. this policy decision will not be a real time choice). The issue here is the level of trust that the leaf has in the root. If the initial pairwise key exchange provides some level of user authentication, then it seems
一度、葉はマルチキャストセッションにおける参加を受け入れて、マルチキャストグループによって使用されるように、次に、これらの2はネットKeyを選びます。 ネットKeyを2つの実体の間の別の公開鍵交換を通して生成したか、または根で単に選ぶことができました、どれがマルチキャストグループのために適所にあるかに方針によって(すなわち、この政策決定はリアルタイムの選択でないでしょう)。 ここの問題は葉が根で持っている信頼のレベルです。 初期の対状主要な交換が何らかのレベルのユーザー認証を提供するなら、それは見えます。
Wallner, et al. Informational [Page 8] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[8ページ]のRFC2627Key Management
adequate to just have the root select the Net Key at this stage. Another issue is the level of trust in the strength of the security of the generated key. Through a cooperative process, both entities (leaf and root) will be providing information to be used in the formation of the Net Key.
根に現在のところネットKeyをただ選択させるように、適切です。 別の問題は発生しているキーのセキュリティの強さにおいて、信頼のレベルです。 協同過程で、両方の実体(葉と根)は、ネットKeyの構成に使用されるために情報を提供するでしょう。
The root then performs a pairwise key exchange with another leaf and optionally performs the negotiation discussed earlier. Upon acceptance by the leaf to join the multicast group, the root sends the leaf the Net Key.
根は、次に、別の葉で対状の主要な交換を実行して、任意により早く議論した交渉を実行します。 マルチキャストグループに加わる葉による承認のときに、根はネットKeyを葉に送ります。
This pairwise key exchange and Net Key distribution continues for all N users of the multicast group.
この対状の主要な交換とネットKey分配はマルチキャストグループのすべてのNユーザのために続きます。
Root/leaves cache pairwise keys for future use. These keys serve as Key Encryption Keys (KEKs) used for rekeying leaves in the net at a later time. Only the root will cache all of the leaves' pairwise keys. Each individual leaf will cache only its own unique pairwise Key Encryption Key.
根/葉は今後の使用のための対状キーをキャッシュします。 これらのキーは後でネットで葉を「再-合わせ」るのに使用されるKey Encryptionキーズ(KEKs)として機能します。 根だけが葉の対状キーのすべてをキャッシュするでしょう。 それぞれの個々の葉はそれ自身だけのユニークな対状Key Encryption Keyをキャッシュするでしょう。
There are two cases to consider when caching the KEKs. The first case is when the Net key and KEK are per session keys. In this case, if one wants to exclude a group participant from the multicast session (and rekey the remaining participants with a new Net Key), the root would distribute a new Net key encrypted with each individual KEK to every legitimate remaining participant. These KEKs are deleted once the multicast session is completed.
KEKsをキャッシュすると考えるために、2つのケースがあります。 最初のケースはネットキーとKEKがセッションキー単位である時です。 この場合、人がマルチキャストセッション(そして、新しいネットKeyをもっている残っている関係者のrekey)にグループの関係者を入れないようにしたいなら、根はそれぞれの個々のKEKと共にすべての正統の残っている関係者に暗号化された新しいネットキーを分配するでしょう。 マルチキャストセッションがいったん終了されていると、これらのKEKsは削除されます。
The second case to consider is when the KEKs are valid for more than one session. In this case, the Net Key may also be valid for multiple sessions, or the Net Key may still only be valid for one session as in the above case. Whether the Net Key is valid for one session or more than one session, the KEK will be cached. If the Net Key is only valid per session, the KEKs will be used to encrypt new Net Keys for subsequent multicast sessions. The deleting of group participants occurs as in the previous case described above, regardless of whether the Net Key is per session or to be used for multiple sessions.
考える2番目のケースはKEKsが1つ以上のセッションのために有効である時です。 また、この場合、ネットKeyが複数のセッションのために有効であるかもしれませんか、またはネットKeyは単に1つのセッションのために上のケースのようにまだ有効であるかもしれません。 ネットKeyが1つのセッションか1つ以上のセッションのために有効であるか否かに関係なく、KEKはキャッシュされるでしょう。 ネットKeyがセッション単位で有効であるだけであるなら、KEKsは、その後のマルチキャストセッションのために新しいNetキーズを暗号化するのに使用されるでしょう。 または、団体での申込者の削除は上で説明された先の事件のように起こります、ネットKeyがセッション単位であることにかかわらず複数のセッションに使用されるために。
A scheme like this may be attractive to a user because it is a straightforward extension of certifiable public key exchange techniques. It may also be attractive because it does not involve third parties. Only the participants who are part of the multicast session participate in the keying mechanism. What makes this scheme so undesirable is that it will be transmission intensive as we scale
それが証明可能な公開鍵取引技術の簡単な拡大であるので、ユーザにとって、このような体系は魅力的であるかもしれません。 また、それも、第三者にかかわらないので、魅力的であるかもしれません。 マルチキャストセッションの一部である唯一の関係者は合わせるメカニズムに参加します。 この体系をとても望ましくなくすることは私たちが比例するときトランスミッション徹底的になるということです。
Wallner, et al. Informational [Page 9] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[9ページ]のRFC2627Key Management
up in numbers, even for the most computationally efficient participants, not to mention those with less capable hardware (tactical, wireless, etc.). Every time the need arises to drop an "unauthorized" participant, a new Net Key must be distributed.
最も計算上有能な関係者さえの数では、それほどできないハードウェア(戦術の、そして、ワイヤレスのなど)があるそれらは言うまでもなく、上がります。 必要性が「権限のない」関係者を下げるために起こるときはいつも、新しいネットKeyを分配しなければなりません。
This distribution requires a transmission from the Root to each remaining participant, whereby the new Net Key will be encrypted under the cover of each participant's unique pairwise Key Encryption Key (KEK).
この分配はRootから残っているそれぞれの関係者までのトランスミッションを必要とします。(新しいネットKeyは各関係者のユニークな対状Key Encryption Key(KEK)のカバーの下でその関係者が暗号化されるでしょう)。
Note: This approach is essentially the same as one proposal to the Internet Engineering Task Force (IETF) Security Subworking Group [Ref 1,2].
以下に注意してください。 このアプローチはインターネット・エンジニアリング・タスク・フォース(IETF)セキュリティSubworking Group[審判1、2]への1つの提案と本質的には同じです。
Also note that there exist multiple twists to an approach like this. For example, instead of having the root do all N key exchanges, the root could pass some of this functionality (and control) to a number of leaves beneath him. For example, the multicast group list could be split in half and the root tells one leaf to take half of the users and perform a key exchange with them (and then distribute the Net key) while the root will take care of the other half of the list. (The chosen leaves are thus functioning as a root and we can call them "subroots." These subroots will have leaves beneath them, and the subroots will maintain the KEK of each leaf beneath it.) This scales better than original approach as N becomes large. Specifically, it will require less time to set up (or rekey) the multicast net because the singular responsibility of performing pairwise key exchanges and distributing Net Key will be shared among multiple group participants and can be performed in parallel, as opposed to the root only distributing the Net Key to all of the participants.
また、このようなアプローチへの複数のねじれが存在することに注意してください。 例えば、根にすべてのN主要な交換をさせることの代わりに、根は彼の下でこの機能性(制御する)のいくつかを多くの葉に通過するかもしれません。 例えば、半分にマルチキャストグループリストを分けられることができて、根は根がリストのもう片方の半分の世話をしている間、それら(次に、ネットキーを分配する)で半分のユーザと同じくらい取って、主要な交換を実行するように1枚の葉に言います。 その結果、選ばれた葉は根として機能しています、そして、私たちはそれらを"「副-ルーツ」"と呼ぶことができます。(These subrootsの下に葉があって、「副-ルーツ」はそれの下のそれぞれの葉のKEKを主張するでしょう。) これはNとしてのオリジナルのアプローチが大きくなるよりよく比例します。 明確に、対状の主要な交換を実行して、ネットKeyを分配するまれな責任を複数の団体での申込者で共有して、平行で実行できるので(または、rekey)マルチキャストネットをセットアップするより少ない時間を必要とするでしょう、関係者のすべてにネットKeyを分配するだけである根と対照的に。
This scheme is not without its own security concerns. This scheme pushes trust down to each subgroup controller - the root assumes that these "subroot" controllers are acting in a trustworthy way. Every control element (root and subroots) must remain in the system throughout the multicast. This effectively makes removing someone from the net (especially the subroots) harder and slower due to the distributed control. When removing a participant from the multicast group which has functioned on behalf of the root, as a subroot, to distribute Net Key, additional steps will be necessary. A new subroot must be delegated by the root to replace the removed subroot. A key exchange (to generate a new pairwise KEK) must occur between the new subroot and each leaf the removed subroot was responsible for. A new Net Key will now be distributed from the root, to the subroots, and to the leaves. Note that this last step would have been the only step required if the removed party was a leaf with no controlling responsibilities.
この体系はそれ自身の安全上の配慮と共にあります。 この体系は信頼をそれぞれのサブグループコントローラまで押します--根は、これらの"「副-根」"コントローラが信頼できる方法で行動していると仮定します。 あらゆる制御要素(根と「副-ルーツ」)がマルチキャスト中にシステムに留まらなければなりません。 これで、事実上、ネット(特に「副-ルーツ」)からだれかを外すのは分散制御のために、より困難でより遅くなります。 ネットKeyを分配するために「副-根」として根を代表して機能したマルチキャストグループから関係者を外すとき、追加ステップは必要になるでしょう。 根で取り外された「副-根」を取り替えるのを新しい「副-根」を代表として派遣しなければなりません。 主要な交換(新しい対状がKEKであると生成する)は取り外された「副-根」が責任があった新しい「副-根」と各葉の間に起こらなければなりません。 新しいネットKeyは現在、根から「副-ルーツ」まで葉に分配されるでしょう。 この最後のステップが取り除かれたパーティーであるなら必要である唯一のステップであっただろうというメモは制御責任がなければ葉でした。
Wallner, et al. Informational [Page 10] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[10ページ]のRFC2627Key Management
5.3 COMPLEMENTARY VARIABLE APPROACH
5.3 補足的な可変アプローチ
Let us suppose we have N leaves. The Root performs a public key exchange with each leaf i (i= 1,2, ..., N). The Root will cache each pairwise KEK. Each leaf stores their own KEK. The root would provide the multicast group list of participants and attributes to all users. Participants would accept or reject participation in the multicast session as described in previous sections. The root encrypts the Net Key for the Multicast group to each leaf, using their own unique KEK(i). (The Root either generated this Net Key himself, or cooperatively generated with one of the leaves as was discussed earlier). In addition to the encrypted Net Key, the root will also encrypt something called complementary variables and send them to the leaves.
私たちにはN葉があると思いましょう。 Rootは各葉で公開鍵交換を実行します。i(N、iは1、2、…と等しいです)。 Rootは各対状KEKをキャッシュするでしょう。 各葉はそれら自身のKEKを保存します。 根は関係者と属性のマルチキャストグループリストをすべてのユーザに提供するでしょう。 関係者は、前項で説明されるようにマルチキャストセッションにおける参加を受け入れるか、または拒絶するでしょう。 それら自身のユニークなKEK(i)を使用して、根はMulticastグループのためにネットKeyを各葉に暗号化します。 (このネットKey自身であると生成されるか、または、より早く議論した葉の1つで協力して生成されたRoot。) 暗号化されたネットKeyに加えて、根は、また、補足的な変数と呼ばれる何かを暗号化して、それらを葉に送るでしょう。
A leaf will NOT receive his own complementary variable, but he will receive the other N-1 leaf complementary variables. The root sends the Net Key and complementary variables j, where j=1,2,...,N and j not equal to i, encrypted by KEK(i) to each leaf. Thus, every leaf receives and stores N variables which are the Net key, and N-1 complementary variables.
葉は彼自身の補足的な変数を受け取らないでしょうが、彼は他のN-1の葉の補足的な変数を受け取るでしょう。 ネットKeyと補足的な変数j、どこj=1、2、…を根は送るか。KEK(i)によって各葉に暗号化されたiと等しくないNとj。 したがって、あらゆる葉が、ネットキーであるN変数、およびN-1の補足的な変数を受け取って、保存します。
Thus to cut a user from the multicast group and get the remaining participants back up again on a new Net Key would involve the following. Basically, to cut leaf number 20 out of the net, one message is sent out that says "cut leaf 20 from the net." All of the other leaves (and Root) generate a new Net Key based on the current Net Key and Complementary variable 20. [Thus some type of deterministic key variable generation process will be necessary for all participants of the multicast group]. This newly generated variable will be used as the new Net Key by all remaining participants of the multicast group. Everyone except leaf 20 is able to generate the new Net Key, because they have complementary variable 20, but leaf 20 does not.
したがって、新しいネットKeyでマルチキャストグループからユーザを切って、再び残っている関係者を起こして戻すのは以下にかかわるでしょう。 基本的に、ネットから葉のNo.20を切り取るために、「ネットから葉20を切ってください」と言う1つのメッセージを出します。 他の葉(そして、Root)のすべてが、新しいネットが現在のネットKeyに基づくKeyとComplementaryの可変20であると生成します。 [その結果、タイプの決定論的な基本変数発生経過はマルチキャストグループのすべての関係者に必要になるでしょう。] マルチキャストのすべての残っている関係者による新しいネットKeyが分類するとき、この新たに生成している変数は使用されるでしょう。 葉20以外の皆は新しいネットKeyを生成することができます、彼らには補足的な可変20があるので葉20はそうするというわけではありません。
A scheme like this seems very desirable from the viewpoint of transmission savings since a rekey message encrypted with each individual KEK to every leaf does not have to be sent to delete someone from the net. In other words, there will be one plaintext message to the multicast group versus N encrypted rekey messages. There exists two major drawbacks with this scheme. First are the storage requirements necessary for the (N-1) complementary variables. Secondly, when deleting multiple users from the multicast group, collusion will be a concern. What this means is that these deleted users could work together and share their individual complementary variables to regain access to the multicast session.
このような体系は、ネットからだれかを削除するためにそれぞれの個々のKEKと共にあらゆる葉に暗号化されたrekeyメッセージを送る必要はないので、トランスミッション貯蓄の観点から非常に望ましく思えます。 言い換えれば、マルチキャストグループへの1つの平文メッセージがN暗号化されたrekeyメッセージに反対しているでしょう。 この体系がある2つの主要な欠点が存在しています。 まず最初に、(N-1)補足的な変数に必要なストレージ要件があります。 マルチキャストグループから複数のユーザを削除するとき、第二に、共謀は関心になるでしょう。 これがこれらがユーザを削除したということであることを意味することは、マルチキャストセッションへのアクセスを取り戻すために彼らの個々の補足的な変数を一緒に扱って、共有できました。
Wallner, et al. Informational [Page 11] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[11ページ]のRFC2627Key Management
5.4 HIERARCHICAL TREE APPROACH
5.4 階層木アプローチ
The Hierarchical Tree Approach is our recommended approach to address the multicast key management problem. This approach provides for the following requisite features:
Hierarchical Tree Approachはそのマルチキャストかぎ管理問題を訴える私たちのお勧めのアプローチです。 このアプローチは以下の必要な特徴に備えます:
1. Provides for the secure removal of a compromised user from the
multicast group
1. マルチキャストグループから感染しているユーザの安全な解任に備えます。
2. Provides for transmission efficiency
2. 伝達効率に備えます。
3. Provides for storage efficiency
3. 充てん率に備えます。
This approach balances the costs of time, storage and number of required message transmissions, using a hierarchical system of auxiliary keys to facilitate distribution of new Net Key. The result is that the storage requirement for each user and the transmissions required for key replacement are both logarithmic in the number of users, with no background transmissions required. This approach is robust against collusion of excluded users. Moreover, while the scheme is hierarchical in nature, no infrastructure is needed beyond a server (e.g., a root), though the presence of such elements could be used to advantage (See Figure 1).
このアプローチは必要なメッセージ送信の時間のコスト、ストレージ、および数のバランスをとっています、新しいネットKeyの分配を容易にするのに補助のキーの階級制度を使用して。 結果は各ユーザのためのストレージ要件と主要な交換に必要であるトランスミッションがユーザの数でともに対数であるということです、バックグラウンド送信は全く必要でない状態で。 このアプローチは除かれたユーザの共謀に対して体力を要します。 そのうえ、体系が現実に階層的である間、インフラストラクチャは全くサーバ(例えば、根)を超えて必要ではありません、そのような要素の存在が利点に慣れることができましたが(図1を見てください)。
--------------------------
| |
| S E R V E R |
| |
--------------------------
| | |
| | . . . . |
- - -
|1| |2| |n|
- - -
-------------------------- | | | S E R V E R| | | -------------------------- | | | | | . . . . | - - - |1| |2| |n| - - -
Figure 1: Assumed Communication Architecture
図1: 通信アーキテクチャであると思われます。
The scheme, advantages and disadvantages are enumerated in more detail below. Consider Figure 2 below. This figure illustrates the logical key distribution architecture, where keys exist only at the server and at the users. Thus, the server in this architecture would hold Keys A through O, and the KEKs of each user. User 11 in this architecture would hold its own unique KEK, and Keys F, K, N, and O.
体系、利点、および損失はさらに詳細に以下に列挙されます。 以下の図2を考えてください。 この図は論理的な主要な分配アーキテクチャを例証します。そこでは、キーがサーバにおいてだけユーザに存在します。 したがって、このアーキテクチャのサーバはOを通したキーズA、およびそれぞれのユーザのKEKsを支えるでしょう。 このアーキテクチャのユーザ11はそれ自身のユニークなKEK、およびキーズF、K、N、およびOを持っているでしょう。
Wallner, et al. Informational [Page 12] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[12ページ]のRFC2627Key Management
net key Key O
-------------------------------------
intermediate | |
keys | |
Key M Key N
----------------- --------------------
| | | |
| | | |
Key I Key J Key K Key L
-------- -------- --------- ----------
| | | | | | | |
| | | | | | | |
Key A Key B Key C Key D Key E Key F Key G Key H
--- --- --- --- --- ---- ---- ----
| | | | | | | | | | | | | | | |
- - - - - - - - - -- -- -- -- -- -- --
|1| |2| |3| |4| |5| |6| |7| |8| |9| |10| |11| |12| |13| |14| |15| |16|
- - - - - - - - - -- -- -- -- -- -- --
users
ネットの主要なKey O------------------------------------- 中間的| | キー| | 主要なM主要なN----------------- -------------------- | | | | | | | | 主要な私主要なJ主要なKキーL-------- -------- --------- ---------- | | | | | | | | | | | | | | | | キーは主要な主要な主要な主要なB E主要なF主要なG C DキーHです。--- --- --- --- --- ---- ---- ---- | | | | | | | | | | | | | | | | - - - - - - - - - -- -- -- -- -- -- -- |1| |2| |3| |4| |5| |6| |7| |8| |9| |10| |11| |12| |13| |14| |15| |16| - - - - - - - - - -- -- -- -- -- -- -- ユーザ
Figure 2: Logical Key Distribution Architecture
図2: 論理的な主要な分配アーキテクチャ
We now describe the organization of the key hierarchy and the setup process. It will be clear from the description how to add users after the hierarchy is in place; we will also describe the removal of a user. Note: The passing of the multicast group list and any negotiation protocols is not included in this discussion for simplicity purposes.
私たちは現在、主要な階層構造とセットアッププロセスの組織について説明します。 記述によって、階層構造が適所にあった後にどのようにユーザを加えるかは明確でしょう。 また、私たちはユーザの解任について説明するつもりです。 以下に注意してください。 マルチキャストグループリストとどんな交渉プロトコルの通過も簡単さ目的のためのこの議論に含まれていません。
We construct a rooted tree (from the bottom up) with one leaf corresponding to each user, as in Figure 2. (Though we have drawn a balanced binary tree for convenience, there is no need for the tree to be either balanced or binary - some preliminary analysis on tree shaping has been performed.) Each user establishes a unique pairwise key with the server. For users with transmission capability, this can be done using the public key exchange protocol. The situation is more complicated for receive-only users; it is easiest to assume these users have pre-placed key.
私たちは図2のように各ユーザにとって、対応する1枚の葉で根づいている木(下から)を組み立てます。 (私たちは便宜のためにバランスのとれている2進の木を描きましたが、木がバランスをとっているか、または2進になる必要は全くありません--木の形成の何らかの予備的な分析が実行されました。) 各ユーザはサーバによって主要なユニークな対状を確立します。トランスミッション能力があるユーザに関して、これは公開鍵交換プロトコルを使用し終わることができます。 状況は受信専用ユーザのためにさらに複雑にされます。 これらのユーザがキーをあらかじめ置いたと仮定するのは最も簡単です。
Once each user has a pairwise key known to the server, the server generates (according to the security policy in place for that session) a key for each remaining node in the tree. The keys themselves should be generated by a robust process. We will also assume users have no information about keys they don't need. (Note: There are no users at these remaining nodes, (i.e., they are logical nodes) and the key for each node need only be generated by the server
各ユーザが対状キーをサーバにいったん知らせると、サーバは木のそれぞれの残っているノードのためにキーを生成します(そのセッションのために適所にある安全保障政策によると)。 キー自体は強健なプロセスによって生成されるべきです。 また、私たちは、ユーザには彼らが必要としないキーの情報が全くないと思うつもりです。 (注意: ユーザが全くノードのままで残っているこれらにいない、(すなわち、それらは論理的なノードです)、各ノードのためのキーはサーバによって生成されるだけでよいです。
Wallner, et al. Informational [Page 13] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[13ページ]のRFC2627Key Management
via secure means.) Starting with those nodes all of whose children are leaves and proceeding towards the root, the server transmits the key for each node, encrypted using the keys for each of that node's children. At the end of the process, each user can determine the keys corresponding to those nodes above her leaf. In particular, all users hold the root key, which serves as the common Net Key for the group. The storage requirement for a user at depth d is d+1 keys (Thus for the example in Figure 2, a user at depth d=4 would hold five keys. That is, the unique Key Encryption Key generated as a result of the pairwise key exchange, three intermediate node keys - each separately encrypted and transmitted, and the common Net Key for the multicast group which is also separately encrypted.)
安全な手段で。) 子供がだれのものであるかに関するすべてが残すそれらのノードから始まって、根に向かって続いて、サーバはそのノードの子供各人にキーを使用することで暗号化された各ノードのためにキーを送ります。 プロセスの終わりでは、各ユーザは彼女の葉の上のそれらのノードに対応するキーを決定できます。 特に、すべてのユーザがルートキーを持っています。(それは、グループのための一般的なネットKeyとして機能します)。 深さdのユーザのためのストレージ要件はd+1キーです。(したがって、図2の例に関して、深さd=4のユーザは5個のかぎを握るでしょう。 すなわち、ユニークなKey Encryption Keyは対状の結果、また、別々に暗号化されるマルチキャストグループのために主要な交換、別々にそれぞれ暗号化されて、伝えられた3個の中間的ノードキー、および一般的なネットKeyを生成しました。)
It is also possible to transmit all of the intermediate node keys and root node key in one message, where the node keys would all be encrypted with the unique pairwise key of the individual leaf. In this manner, only one transmission (of a larger message) is required per user to receive all of the node keys (as compared to d transmissions). It is noted for this method, that the leaf would require some means to determine which key corresponds to which node level.
また、ノードキーが個々の葉のユニークな対状キーですべて暗号化されるだろう1つのメッセージで主要な中間的ノードキーと根のノードのすべてを伝えるのも可能です。 この様に、1個のトランスミッション(より大きいメッセージの)だけが、ノードキーのすべてを受けるのにユーザ単位で必要です(dトランスミッションと比べて)。 それはこのメソッドで有名であり、葉がいくつかを必要とするだろうというのがどのキーがどのノードレベルに対応するかを決定することを意味します。
It is important to note that this approach requires additional processing capabilities at the server where other alternative approaches may not. In the worst case, a server will be responsible for generating the intermediate keys required in the architecture.
このアプローチが他の代替的アプローチがそうしないかもしれないサーバで追加処理能力を必要とすることに注意するのは重要です。 最悪の場合には、サーバはアーキテクチャで必要である中間的キーを生成するのに原因となるようになるでしょう。
5.4.1 The Exclusion Principle
5.4.1 排他原理
Suppose that User 11 (marked on Figure 2 in black) needs to be deleted from the multicast group. Then all of the keys held by User 11 (bolded Keys F, K, N, O) must be changed and distributed to the users who need them, without permitting User 11 or anyone else from obtaining them. To do this, we must replace the bolded keys held by User 11, proceeding from the bottom up. The server chooses a new key for the lowest node, then transmits it encrypted with the appropriate daughter keys (These transmissions are represented by the dotted lines). Thus for this example, the first key replaced is Key F, and this new key will be sent encrypted with User 12's unique pairwise key.
User11(黒で図2にマークされます)が、マルチキャストグループから削除される必要であると仮定してください。 次に、User11によって握られたかぎ(キーズF、K N、Oをboldedした)のすべてを彼らを必要とするユーザに、変えられて、分配しなければなりません、彼らを得るのでUser11か他の誰も可能にしないで。 これをするために、私たちは下から続いて、User11によって握られたboldedかぎを取り替えなければなりません。 サーバは、最も少ないノードのための新しいキーを選んで、次に、適切な娘キーで暗号化されていた状態でそれを伝えます(これらのトランスミッションは点線によって表されます)。 したがって、この例に関して、取り替えられた最初のキーはKey Fです、そして、User12のユニークな対状キーで暗号化されていた状態でこの新しいキーを送るでしょう。
Since we are proceeding from the bottom up, each of the replacement keys will have been replaced before it is used to encrypt another key. (Thus, for the replacement of Key K, this new key will be sent encrypted in the newly replaced Key F (for User 12) and will also be sent as one multicast transmission encrypted in the node key shared by Users 9 and 10 (Key E). For the replacement of Key N, this new key will be sent encrypted in the newly replaced Key K (for Users 9, 10,
私たちが下から続いているので、別のキーを暗号化するのにそれを使用する前に、それぞれの交換キーを取り替えてしまうでしょう。 その結果、Key Kの交換において、この新しいキーを新たに取り替えられたKey Fで暗号化されていた状態で送って(User12のために)、また、Users9と10(キーE)によってノードキーで暗号化された1つのマルチキャスト送信が共有されたように送るでしょう。(Key Nの交換において、新たに取り替えられたKey Kで暗号化されていた状態でこの新しいキーを送る、(Users9、10のために
Wallner, et al. Informational [Page 14] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[14ページ]のRFC2627Key Management
and 12) and will also be encrypted in the node key shared by Users 13, 14, 15, and 16 (Key L). For the replacement of Key O, this new key will be sent encrypted in the newly replaced Key N (for Users 9, 10, 12, 13, 14, 15, and 16) and will also be encrypted in the node key shared by Users 1, 2 , 3, 4, 5, 6, 7, and 8 (Key M).) The number of transmissions required is the sum of the degrees of the replaced nodes. In a k-ary tree in which a sits at depth d, this comes to at most kd-1 transmissions. Thus in this example, seven transmissions will be required to exclude User 11 from the multicast group and to get the other 15 users back onto a new multicast group Net Key that User 11 does not have access to. It is easy to see that the system is robust against collusion, in that no set of users together can read any message unless one of them could have read it individually.
12)、また、Users13、14、15、および16(キーL)によって共有されたノードキーでは、暗号化されるでしょう。 Key Oの交換において、この新しいキーは、新たに取り替えられたKey Nで暗号化されていた状態で送られて(Users9、10、12、13、14、15、および16のために)、また、Users1、2、3、4、5、6、7、および8(キーM)によって共有されたノードキーで暗号化されるでしょう。 必要であるトランスミッションの数は取り替えられたノードの度合いの合計です。 aが深さdに座るk-ary木では、これは高々kd-1トランスミッションに来ます。 したがって、この例では、7個のトランスミッションがマルチキャストグループにUser11を入れないようにするのに必要でしょう、そして、もう片方を得るために、15人のユーザがUser11が近づく手段を持っていないグループネットKeyを新しいマルチキャストに支持します。 システムが共謀に対して強健であることがわかるのは簡単です、彼らのひとりが個別にそれを読むことができなかったなら一緒にユーザのどんなセットもどんなメッセージも読むことができないので。
If the same strategy is taken as in the previous section to send multiple keys in one message, the number of transmissions required can be reduced even further to four transmissions. Note once again that the messages will be larger in the number of bits being transmitted. Additionally, there must exist a means for each leaf to determine which key in the message corresponds to which node of the hierarchy. Thus, in this example, for the replacement of keys F, K, N, and O to User 12, the four keys will be encrypted in one message under User 12's unique pairwise key. To replace keys K, N, and O for Users 9 and 10, the three keys will be encrypted in one message under the node key shared by Users 9 and 10 (Key E). To replace keys N and O for Users 13, 14, 15, 16, the two keys will be encrypted in one message under the node key shared by Users 13, 14, 15, and 16 (Key L). Finally, to replace key O for Users 1, 2 , 3, 4, 5, 6, 7, and 8, key O will be encrypted under the node key shared by Users 1, 2 , 3, 4, 5, 6, 7, and 8 (Key M). Thus the number of transmission required is at most (k-1)d.
1つのメッセージで複数のキーを送る前項のように同じ戦略を取るなら、4個のトランスミッションに加えてさえ必要であるトランスミッションの数を減少させることができます。 もう一度メッセージが伝えられるビットの数で、より大きくなることに注意してください。 さらに、各葉がメッセージのどのキーが階層構造のどのノードに対応するかを決定する手段は存在しなければなりません。 したがって、この例では、User12のキーF、K、N、およびOの交換において、4個のキーがUser12のユニークな対状キーの下の1つのメッセージで暗号化されるでしょう。 Users9と10のためにキーK、N、およびOを取り替えるために、3個のキーがUsers9と10(キーE)によって共有されたノードキーの下の1つのメッセージで暗号化されるでしょう。 Users13、14、15、16のためにキーNとOを取り替えるために、2個のキーがUsers13、14、15、および16(キーL)によって共有されたノードキーの下の1つのメッセージで暗号化されるでしょう。 最終的に、Users1、2、3、4、5、6、7、および8のためにキーOを取り替えるために、キーOはUsers1、2、3、4、5、6、7、および8(キーM)によって共有されたノードキーの下で暗号化されるでしょう。 したがって、必要であるトランスミッションの数は高々(k-1)dです。
The following table demonstrates the removal of a user, and how the storage and transmission requirements grow with the number of users.
以下のテーブルはユーザと、ユーザの数に応じてストレージとトランスミッション要件がどう成長するかに関する取り外しを示します。
Wallner, et al. Informational [Page 15] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[15ページ]のRFC2627Key Management
Table 1: Storage and Transmission Costs
テーブル1: ストレージとトランスミッションコスト
Number Degree Storage per user Transmissions to Transmissions
of users (k) (d+1) rekey remaining to rekey
participants of remaining
multicast group- participants of
one key per message multicast
(kd-1) group -
multiple keys
per message
(k-1)d
8 2 4 5 3
9 3 3 5 4
16 2 5 7 4
2048 2 12 21 11
2187 3 8 20 14
131072 2 18 33 17
177147 3 12 32 22
ユーザTransmissionsあたりの数のDegree Storageに、ユーザ(k)(d+1)のTransmissionsに、2 5 7 4が複数のメッセージ(k-1)d8 2 4 5 3 9 3 3 5 4 16あたりのキーに、あるメッセージマルチキャスト(kd-1)あたりのキーの関係者が分類するマルチキャストグループのままで残るrekey関係者のままで残りながらrekeyされている、2048、2、12 21 11 2187、3 8、20 14 131072、2、18 33 17 177147、3、12 32 22
The benefits of a scheme such as this are:
これなどの体系の利益は以下の通りです。
1. The costs of user storage and rekey transmissions are balanced
and scalable as the number of users increases. This is not the
case for [1], [2], or [4].
1. ユーザの数が増加するのに従って、ユーザストレージとrekeyトランスミッションのコストは、バランスのとれてスケーラブルです。 これは[1]、[2]、または[4]のためのそうではありません。
2. The auxiliary keys can be used to transmit not only other keys,
but also messages. Thus the hierarchy can be designed to place
subgroups that wish to communicate securely (i.e. without
transmitting to the rest of the large multicast group) under
particular nodes, eliminating the need for maintenance of
separate Net Keys for these subgroups. This works best if the
users operate in a hierarchy to begin with (e.g., military
operations), which can be reflected by the key hierarchy.
2. 他のキーだけではなく、メッセージも送るのに補助のキーを使用できます。 したがって、階層構造はしっかりと(すなわち、大きいマルチキャストグループの残りに伝わらないで)特定のノードの下で交信したがっているサブグループを置くように設計される場合があります、これらのサブグループのために別々のNetキーズのメインテナンスの必要性を排除して。 ユーザが初めに(例えば、軍事行動)階層構造で働いているなら、これはうまくいきます(主要な階層構造で、反映できます)。
3. The hierarchy can be designed to reflect network architecture,
increasing efficiency (each user receives fewer irrelevant
messages). Also, server responsibilities can be divided up
among subroots (all of which must be secure).
3. 効率を増強して、階層構造は、ネットワークアーキテクチャを反映するように設計される場合があります(各ユーザは、より少ない無関係のメッセージを受け取ります)。 また、「副-ルーツ」(それのすべてが安全であるに違いない)の中でサーバ責任を分割できます。
4. The security risk associated with receive-only users can be
minimized by collecting such users in a particular area of the
tree.
4. 木の特定の領域にそのようなユーザを集めることによって、受信専用ユーザに関連しているセキュリティリスクを最小にすることができます。
5. This approach is resistant to collusion among arbitrarily many
users.
5. このアプローチは任意に多くのユーザの中で共謀に抵抗力があります。
Wallner, et al. Informational [Page 16] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[16ページ]のRFC2627Key Management
As noted earlier, in the rekeying process after one user is compromised, in the case of one key per message, each replaced key must be decrypted successfully before the next key can be replaced (unless users can cache the rekey messages). This bottleneck could be a problem on a noisy or slow network. (If multiple users are being removed, this can be parallelized, so the expected time to rekey is roughly independent of the number of users removed.)
より早く注意される「再-合わせ」るプロセスでは、1メッセージあたり1個のキーの場合で1人のユーザに感染した後に次のキーを取り替えることができる(ユーザがrekeyメッセージをキャッシュできないなら)前に首尾よくそれぞれの取り替えられたキーを解読しなければなりません。 このボトルネックは騒がしいか遅いネットワークの問題であるかもしれません。 (複数のユーザが外されるなら、これをparallelizedされることができるので、ユーザの数の如何にかかわらず手荒くrekeyへの予想された時間を取り除きます。)
By increasing the valences and decreasing the depth of the tree, one can reduce the storage requirements for users at the price of increased transmissions. For example, in the one key per message case, if n users are arranged in a k-ary tree, each user will need storage. Rekeying after one user is removed now requires transmissions. As k approaches n, this approaches the pairwise key scheme described earlier in the paper.
原子価を増強して、木の深さを減少させることによって、1つは増強されたトランスミッションの価格でユーザのためのストレージ要件を減らすことができます。 例えば、メッセージケースあたり1個のキーでは、nユーザがk-ary木に配置されると、各ユーザはストレージを必要とするでしょう。 1人のユーザが現在外された後にRekeyingするのはトランスミッションを必要とします。 kがnにアプローチするのに従って、これは、より早く紙で説明された対状の主要な体系にアプローチします。
5.4.2 Hierarchical Tree Approach Options
5.4.2 階層木アプローチオプション
5.4.2.1 Distributed Hierarchical Tree Approach
5.4.2.1 分配された階層木アプローチ
The Hierarchical Tree Approach outlined in this section could be distributed as indicated in Section 5.2 to more closely resemble the proposal put forth in [4]. Subroots could exist at each of the nodes to handle any joining or rekeying that is necessary for any of the subordinate users. This could be particularly attractive to users which do not have a direct connection back to the Root. Recall as indicated in Section 5.2, that the trust placed in these subroots to act with the authority and security of a Root, is a potentially dangerous proposition. This thought is also echoed in [4].
セクション5.2にみられるようにより密接に[4]で差し出された提案に類似するようにこのセクションで概説されたHierarchical Tree Approachは分配できました。 Subrootsは、下位のユーザのいずれにも必要などんな接合や「再-合わせ」ることを扱うためにそれぞれのノードに存在できました。 ユーザには、これは特に魅力的であるかもしれません(ダイレクト接続をRootに返してもらいません)。 セクションにみられるように思い出してください。5.2 Rootの権威とセキュリティで行動するためにこれらの「副-ルーツ」に置かれた信頼は潜在的に危険な提案です。 また、この考えは[4]で反響されます。
Some practical recommendations that might be made for these subroots include the following. The subroots should not be allowed to change the multicast group participant list that has been provided to them from the Root. One method to accomplish this, would be for the Root to sign the list before providing it to the subroots. Authorized subroots could though be allowed to set up new multicast groups for users below them in the hierarchy.
これらの「副-ルーツ」のためにされるかもしれないいくつかの実用的な推薦状が以下を含んでいます。 「副-ルーツ」はRootからそれらに提供されたマルチキャストグループ関係者リストを変えることができないはずです。 これを達成するあるメソッドであり、それを「副-ルーツ」に供給する前に、Rootはリストに署名することになっているでしょう。 ユーザのために彼らの下に階層構造で新しいマルチキャストグループを設立するのが許容されましたが、認可された「副-ルーツ」はそうすることができました。
It is important to note that although this distribution may appear to provide some benefits with respect to the time required to initialize the multicast group (as compared to the time required to initialize the group as described in Section 5.4) and for periodic rekeying, it does not appear to provide any benefit in rekeying the multicast group when a user has been compromised.
この分配がマルチキャストグループ(グループを初期化するのに必要である時間とセクション5.4で説明されるのと同じくらい比べている)を初期化するのに必要である時間と周期的な「再-合わせ」るのにいくつかの利益を提供するように見えるかもしれませんが、それはユーザに感染されたときマルチキャストグループを「再-合わせ」るのにどんな利益も提供するように見えないことに注意するのが重要です。
It is also noted that whatever the key management scheme is (hierarchical tree, distributed hierarchical tree, core based tree, GKMP, etc.), there will be a "hit" incurred to initialize the
また、初期化するために被られた状態で「打たれた」aがかぎ管理体系が何(階層木、分配された階層木、コアに基づいている木、GKMPなど)であっても、あることに注意されます。
Wallner, et al. Informational [Page 17] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[17ページ]のRFC2627Key Management
multicast group with the first multicast group net key. Thus, the hierarchical tree approach does not suffer from additional complexity with comparison to the other schemes with respect to initialization.
最初のマルチキャストがあるマルチキャストグループはネットのキーから構成されています。 したがって、階層木アプローチに初期化に関して比較がある追加複雑さから他の体系まで苦しみません。
5.4.2.2 Multicast Group Formation
5.4.2.2 マルチキャスト集団形成
Although this paper has presented the formation of the multicast group as being Root initiated, the hierarchical approach is consistent with user initiated joining. User initiated joining is the method of multicast group formation presented in [4]. User initiated joining may be desirable when some core subset of users in the multicast group need to be brought up on-line and communicating more quickly. Other participants in the multicast group can then be brought in when they wish. In this type of approach though, there does not exist a finite period of time by when it can be ensured all participants will be a part of the multicast group.
この紙はRootが開始した存在としてマルチキャストグループの構成を提示しましたが、階層的なアプローチはユーザの開始している接合と一致しています。 ユーザの開始している接合は[4]に提示されたマルチキャスト集団形成のメソッドです。 マルチキャストグループのユーザの何らかのコア部分集合がオンラインで持って来られて、よりすばやく交信するのに望ましくなければならないときに、ユーザの開始している接合は望ましいかもしれません。 そして、彼らが願っているとき、マルチキャストグループの他の関係者を引きつけることができます。 もっとも、このタイプのアプローチでは、すべての関係者がマルチキャストグループの一部になるのを確実にすることができる時までに有限期間は存在していません。
For example, in the case of a single root, the hierarchy is set up once, in the beginnning, by the initiator (also usually the root) who also generates the group participant list. The group of keys for each participant can then be individually requested (pulled) as soon as, but not until, each participant wishes to join the session.
例えば、ただ一つの根の場合では、階層構造は一度セットアップされます、beginnningで、また、グループが関与しているリストであると生成する創始者(通常も根)で。 次に、同じくらいすぐ個別に各関係者のためのキーのグループを要求できる、(引かれます)各関係者はセッションに参加したがっています。
5.4.2.3 Sender Specific Authentication
5.4.2.3 送付者の特定の認証
In the multicast environment, the possibility exists that participants of the group at times may want to uniquely identify which participant is the sender of a multicast group message. In the multicast key distribution system described by Ballardie [4], the notion of "sender specific keys" is presented.
マルチキャスト環境で、グループの関係者が、時にはどの関係者がマルチキャストグループメッセージの送付者であるかを唯一特定したがっているかもしれない可能性は存在しています。 Ballardie[4]によって説明されたマルチキャストの主要な流通制度では、「送付者の特定のキー」の概念は提示されます。
Another option to allow participants of a multicast group to uniquely determine the sender of a message is through the use of a signature process. When a member of the multicast group signs a message with their own private signature key, the recipients of that signed message in the multicast group can use the sender's public verification key to determine if indeed the message is from who it is claimed to be from.
マルチキャストグループの関係者が唯一メッセージの送付者を決心しているのを許容する別のオプションは署名プロセスの使用であります。 マルチキャストグループのメンバーがそれら自身の個人的な署名キーでメッセージに署名するとき、マルチキャストグループにおけるメッセージであると署名されるその受取人は送付者の本当に、それがあるとだれに主張されるかからメッセージが来ているかを決定するために主要な公共の検証を使用できます。
Another related idea to this is the case when two users of a multicast group want to communicate strictly with each other, and want no one else to listen in on the communication. If this communication relationship is known when the multicast group is originally set up, then these two participants could simply be placed adjacent to one another at the lowest level of the hierarchy (below a binary node). Thus, they would naturally share a secret pairwise key. Otherwise, a simple way to accomplish this is to perform a public key based pairwise key exchange between the two users to
マルチキャストグループの2人のユーザが、厳密に互いにコミュニケートして、他の誰もにコミュニケーションで聴かないで欲しくしたがっているときに、これへの別の関連する考えはケースです。 マルチキャストグループが元々設立されるとき、このコミュニケーション関係が知られているなら、これらの2人の関係者が単にお互いに隣接して階層構造(2進のノードの下における)の最も低いレベルに置かれるかもしれません。 したがって、彼らは自然に秘密の対状キーを共有するでしょう。 そうでなければ、これを達成するのがある2人のユーザの間の公開鍵に基づいている対状主要な交換を実行する簡単な方法
Wallner, et al. Informational [Page 18] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[18ページ]のRFC2627Key Management
generate a traffic encryption key for their private unicast communications. Through this process, not only will the encrypted transmissions between them be readable only by them, but unique sender authentication can be accomplished via the public key based pairwise exchange.
それらの個人的なユニキャストコミュニケーションに、主要なトラフィック暗号化を生成してください。 このプロセスを通して、それらの間の暗号化されたトランスミッションが単にそれらだけで読み込み可能になるのではなく、公開鍵に基づいている対状交換でユニークな送付者認証を実行できます。
5.4.2.4 Rekeying the Multicast Group and the Use of Group Key
Encryption Keys
5.4.2.4 グループの主要な暗号化キーのマルチキャストグループと使用をRekeyingすること。
Reference [4] makes use of a Group Key Encryption Key that can be shared by the multicast group for use in periodic rekeys of the multicast group. Aside from the potential security drawbacks of implementing a shared key for encrypting future keys, the use of a Group Key Encryption Key is of no benefit to a multicast group if a rekey is necessary due to the known compromise of one of the members. The strategy for rekeying the multicast group presented in Section 5.4.1 specifically addresses this critical problem and offers a means to accomplish this task with minimal message transmissions and storage requirements.
参照[4]はマルチキャストグループがマルチキャストグループの周期的な「再-キー」における使用のために共有できるGroup Key Encryption Keyを利用します。 将来のキーを暗号化するための共有されたキーを実装する潜在的セキュリティ欠点は別として、rekeyがメンバーの一人の知られている感染のために必要であるなら、Group Key Encryption Keyの使用はマルチキャストグループにおいてどんな利益ともなりません。 セクション5.4.1で提示されたマルチキャストグループを「再-合わせ」るための戦略は、明確にこの重大問題を扱って、最小量のメッセージ送信とストレージ要件でこのタスクを達成する手段を提供します。
The question though can now be asked as to whether the rekey of a multicast group will be necessary in a non-compromise scenario. For example, if a user decides they do not want to participate in the group any longer, and requests the list controller to remove them from the multicast group participant list, will a rekey of the multicast group be necessary? If the security policy of the multicast group mandates that deleted users can no longer receive transmissions, than a rekey of a new net key will be required. If the multicast group security policy does not care that the deleted person can still decrypt any transmissions (encrypted in the group net key that they might still hold), but does care that they can not encrypt and transmit messages, a rekey will once again be necessary. The only alternative to rekeying the multicast group under this scenario would require a recipient to check every received message sender, against the group participant list. Thus rejecting any message sent by a user not on the list. This is not a practical option. Thus it is recommended to always rekey the multicast group when someone is deleted, whether it is because of compromise reasons or not.
質問、缶ですが、マルチキャストグループのrekeyが非感染シナリオで必要になるかどうかに関して今、尋ねられてください。 例えば、ユーザが、彼らがもうグループに参加したがっていないと決めて、マルチキャストからそれらを取り除くリストコントローラが関係者を分類するという要求がリストアップされると、マルチキャストグループのrekeyは必要になるでしょうか? ユーザを削除したマルチキャストグループ命令の安全保障政策がもうそうすることができるなら、トランスミッションを受けてください、新しいネットのキーのrekeyが必要であるというよりも。 マルチキャストグループ安全保障政策が、削除された人がまだ、どんなトランスミッション(それらがまだ握っているかもしれないグループのネットのかぎでは、暗号化される)も解読することができるのを気にかけませんが、彼らがメッセージを暗号化して、送ることができないのを気にかけると、rekeyはもう一度必要になるでしょう。 マルチキャストグループを「再-合わせ」ることへの唯一の選択肢が、受取人がすべての容認されたメッセージ送付者をチェックするのをこのような筋書で必要とするでしょう、グループ関係者リストに対して。 その結果、リストの上のユーザによって送られたどんなメッセージも拒絶します。 これは実用的なオプションではありません。 だれかが削除されるとき、したがって、それはいつもrekeyへのマルチキャストグループに推薦されます、感染理由のためにそれがそうであるか否かに関係なく。
5.4.2.5 Bulk Removal of Participants
5.4.2.5 関係者の大量の解任
As indicated in Section 2, the need may arise to remove users in bulk. If the users are setup as discussed in Section 5.4.1 into subgroups that wish to communicate securely all being under the same node, bulk user removal can be done quite simply if the whole node is to be removed. The same technique as described in Section 5.4.1 is performed to rekey any shared node key that the remaining
セクション2にみられるように、必要性は、大量のユーザを外すために起こるかもしれません。 ユーザがセクション5.4.1でしっかりと同じノードの下におけるすべての存在を伝えたがっているサブグループと議論するようにセットアップであるなら、全体のノードが取り除くことであるなら全く単に大口利用者取り外しができます。 セクション5.4.1で説明されるのと同じテクニックがどんな共有されたノードキーもrekeyするように実行される、それ、残り
Wallner, et al. Informational [Page 19] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[19ページ]のRFC2627Key Management
participants hold in common with the removed node.
関係者は取り除かれたノードと共用して成立します。
The problem of bulk removal becomes more difficult when the participants to be removed are dispersed throughout the tree. Depending on how many participants are to be removed, and where they are located within the hierarchy, the number of transmissions required to rekey the multicast group could be equivalent to brute force rekeying of the remaining participants. Also the question can be raised as to at what point the remaining users are restructured into a new hierarchical tree, or should a new multicast group be formed. Restructuring of the hierarchical tree would most likely be the preferred option, because it would not necessitate the need to perform pairwise key exchanges again to form the new user unique KEKs.
取り除かれるべき関係者が木中で分散されるとき、大量の取り外しの問題は、より難しくなります。 何人の関係者が外されることになっていて、彼らが階層構造の中にどこに位置しているかによって、トランスミッションの数は獣と同等物が残っている関係者に「再-合わせ」られる力であったかもしれないならマルチキャストグループをrekeyに必要としました。 また、新しい階層木に再構築されているか、または新しいマルチキャストが分類されるなら残っているユーザがどんなポイントのそうであるかに形成されるように疑問を引き起こすことができます。 階層木の企業再構築はたぶん都合のよいオプションでしょう、新しいユーザユニークなKEKsを形成するために再び対状の主要な交換を実行する必要性を必要としないでしょう、したがって。
5.4.2.6 ISAKMP Compatibility
5.4.2.6 ISAKMPの互換性
Thus far this document has had a major focus on the architectural trade-offs involved in the generation, distribution, and maintenance of traffic encryption keys (Net Keys) for multicast groups. There are other elements involved in the establishment of a secure connection among the multicast participants that have not been discussed in any detail. For example, the concept of being able to "pick and choose" and negotiating the capabilities of the key exchange mechanism and various other elements is a very important and necessary aspect.
これまでのところ、このドキュメントはマルチキャストグループのためにトラフィック暗号化キー(ネットのキーズ)の生成、分配、およびメインテナンスにかかわる建築トレードオフに主要な焦点を持っていました。 どんな詳細にも議論していないマルチキャスト関係者の中で安全な接続の設立に伴われる他の要素があります。 例えば、「慎重に選ぶことができ」て、主要な交換メカニズムと他の様々な要素の能力を交渉する概念は非常に重要で必要な局面です。
The NSA proposal to the Internet Engineering Task Force (IETF) Security Subworking Group [Ref. 3] entitled "Internet Security Association and Key Management Protocol (ISAKMP)" has attempted to identify the various functional elements required for the establishment of a secure connection for the largest current network, the Internet. While the proposal has currently focused on the problem of point to point connections, the functional elements should be the same for multicast connections, with appropriate changes to the techniques chosen to implement the individual functional elements. Thus the implementation of ISAKMP is compatible with the use of the hierarchical tree approach.
インターネット・エンジニアリング・タスク・フォース(IETF)セキュリティSubworking GroupへのNSA提案[審判。 3] 題して、「インターネットセキュリティ協会とKey Managementプロトコル(ISAKMP)」は、最も大きい現在のネットワークのために安全な接続の設立に必要である様々な機能要素を特定するのを試みました、インターネット。 提案が現在接続を指すためにポイントの問題に焦点を合わせた間、マルチキャスト接続に、機能要素は同じであるべきです、適切な変化が個々の機能要素を実装するためにテクニックに選ばれている状態で。 したがって、ISAKMPの実装は階層木アプローチの使用と互換性があります。
6.0 SUMMARY
6.0 概要
As discussed in this report, there are two main areas of concern when addressing solutions for the multicast key management problem. They are the secure initialization and rekeying of the multicast group with a common net key. At the present time, there are multiple papers which address the initialization of a multicast group, but they do not adequately address how to efficiently and securely remove a compromised user from the multicast group.
マルチキャストかぎ管理問題によってソリューションを扱うとき、このレポートで議論するように、関心の2つの主な領域があります。 それらは、一般的なネットのキーでマルチキャストグループを安全な初期化と「再-合わせ」ることです。 現在に、マルチキャストグループの初期化を扱う複数の書類がありますが、それらは適切にマルチキャストグループから感染しているユーザをどう効率的にしっかりと外すかを扱いません。
Wallner, et al. Informational [Page 20] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[20ページ]のRFC2627Key Management
This paper proposed a hierarchical tree approach to meet this difficult problem. It is robust against collusion, while at the same time, balancing the number of transmissions required and storage required to rekey the multicast group in a time of compromise.
この論文は、この難問を満たすために階層木アプローチを提案しました。 それは共謀に対して強健です、同時に、トランスミッションの数のバランスをとるのが必要であり、ストレージは感染の時間マルチキャストグループをrekeyに必要としましたが。
It is also important to note that the proposal recommended in this paper is consistent with other multicast key management solutions [4], and allows for multiple options for its implementation.
また、この紙のお勧めの提案が他のマルチキャストかぎ管理解決[4]と一致していて、実装に関して複数のオプションを考慮することに注意するのも重要です。
7.0 Security Considerations
7.0 セキュリティ問題
Security concerns are discussed throughout this memo.
このメモ中で安全上の配慮について議論します。
8.0 REFERENCES
8.0の参照箇所
1. Harney, H., Muckenhirn, C. and T. Rivers, "Group Key Management
Protocol Architecture", RFC 2094, September 1994.
1. ハーニーとH.とMuckenhirnとC.とT.川、「グループKey Managementプロトコルアーキテクチャ」、RFC2094、1994年9月。
2. Harney, H., Muckenhirn, C. and T. Rivers, "Group Key Management
Protocol Specification", RFC 2093, September 1994.
2. ハーニーとH.とMuckenhirnとC.とT.川、「グループKey Managementプロトコル仕様」、RFC2093、1994年9月。
3. Maughan, D., Schertler, M. Schneider, M. and J.Turner, "Internet
Security Association and Key Management Protocol, Version 7",
February 1997.
3. Maughan、D.、Schertler、M.シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは1997年2月についてバージョン7インチ議定書の中で述べます」。
4. Ballardie, T., "Scalable Multicast Key Distribution", RFC 1949,
May 1996.
4. Ballardie(T.、「スケーラブルなマルチキャスト主要な分配」、RFC1949)は1996がそうするかもしれません。
5. Wong, C., Gouda, M. and S. Lam, "Secure Group Communications Using
Key Graphs", Technical Report TR 97-23, Department of Computer
Sciences, The University of Texas at Austin, July 1997.
5. ウォン、C.、合田、M.、およびS.ラムは「主要なグラフを使用して、グループコミュニケーションを保証します」、技術報告書TR97-23、コンピューターサイエンシズの部、テキサス大学オースティン校、1997年7月。
Wallner, et al. Informational [Page 21] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[21ページ]のRFC2627Key Management
Authors' Addresses
作者のアドレス
Debby M. Wallner National Security Agency Attn: R2 9800 Savage Road STE 6451 Ft. Meade, MD. 20755-6451
デビーM.ウォルナー国家安全保障局Attn: 6451フィートのR2 9800野蛮人道路STE ミード(MD)。 20755-6451
Phone: 301-688-0331 EMail: dmwalln@orion.ncsc.mil
以下に電話をしてください。 301-688-0331 メールしてください: dmwalln@orion.ncsc.mil
Eric J. Harder National Security Agency Attn: R2 9800 Savage Road STE 6451 Ft. Meade, MD. 20755-6451
エリックJ.の、より固い国家安全保障局Attn: 6451フィートのR2 9800野蛮人道路STE ミード(MD)。 20755-6451
Phone: 301-688-0850 EMail: ejh@tycho.ncsc.mil
以下に電話をしてください。 301-688-0850 メールしてください: ejh@tycho.ncsc.mil
Ryan C. Agee National Security Agency Attn: R2 9800 Savage Road STE 6451 Ft. Meade, MD. 20755-6451
ライアンC.エージー国家安全保障局Attn: 6451フィートのR2 9800野蛮人道路STE ミード(MD)。 20755-6451
Wallner, et al. Informational [Page 22] RFC 2627 Key Management for Multicast June 1999
ウォルナー、他 マルチキャスト1999年6月のための情報[22ページ]のRFC2627Key Management
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Wallner, et al. Informational [Page 23]
ウォルナー、他 情報[23ページ]
一覧
スポンサーリンク
