[要約] 要約：RFC 2627は、マルチキャストの鍵管理に関する問題とアーキテクチャについてのガイドラインです。 目的：このRFCの目的は、マルチキャスト通信における鍵管理の課題を明確にし、適切なアーキテクチャを提案することです。
Network Working Group D. Wallner
Request for Comments: 2627 E. Harder
Category: Informational R. Agee
National Security Agency
June 1999
Key Management for Multicast: Issues and Architectures
マルチキャストの主要な管理：問題とアーキテクチャ
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
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つの主要な領域に焦点を当てています。これは、マルチキャストグループを共通のネットキーで初期化し、マルチキャストグループを再キーしています。ユーザーの妥協や他の理由（例：定期的なReke）に必要な場合があります。特に、このレポートは、安全な妥協回復を可能にする手法を特定しながら、除外されたユーザーの共謀に対しても堅牢です。これは、他のほとんどのマルチキャストキー管理提案[1,2,4]によって詳細に対処されていないマルチキャストキー管理の重要な機能の1つです。この提案された手法の利点は、マルチキャストグループを再キーするために必要なトランスミッションの数を最小限に抑え、マルチキャストグループに最小限のストレージ要件を課すことです。
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 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.
将来のネットワークには、現在の主要な管理アーキテクチャの機能に負担をかける要件があることが認識されています。これらの要件の1つは、安全なマルチキャスト要件です。高い帯域幅、非常に動的な安全なマルチキャスト通信の必要性は、さまざまな商業、政府、およびインターネットコミュニティでますます明らかになっています。具体的には、安全なマルチキャスト要件は、一般的なマルチキャストグループネットキーを使用して、マルチキャストグループの他のすべてのメンバーと安全に通信するために、同じセキュリティ属性と通信要件を共有する複数のユーザーにとって必要性です。マルチキャスト通信の最大の利点は、複数の受信機が同時に同じトランスミッションを取得することです。したがって、問題は、不正な関係者が同様に（マルチキャストグループを初期化する）ことを許可することなく、同じネットキーを決定/取得できるようにすることと、必要に応じてマルチキャストグループのユーザーを安全に再キーすることです。一見すると、これは現在の主要な管理シナリオとは異なるようには見えないかもしれません。ただし、このペーパーでは、将来のマルチキャストシナリオが非常に多様で動的に変化する要件を持ち、主要な管理の観点から非常に挑戦的に対処することを示しています。
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.
主要な管理インフラストラクチャは、キロビット/秒からギガビット/秒までの帯域幅をサポートし、さまざまなマルチキャストグループサイズを処理し、たとえばワイヤレスおよびモバイルテクノロジーなどの通信環境を処理するのに十分柔軟である必要があります。これらのパフォーマンスおよび通信要件に加えて、さまざまなシナリオのセキュリティ要件も幅広い範囲です。ユーザーを、個別に、そして一括で安全かつ効率的に追加および削除できる必要があります。秘密の情報を共有していても、ドロップされたユーザーがその後のトラフィックを読み取ることができないように、システムは妥協に耐性がなければなりません。私たちが最小化しようとするコストは、セットアップに必要な時間、各エンドユーザーのストレージスペース、セットアップ、再キー、メンテナンスに必要な送信の総数です。また、提案されたマルチキャストセキュリティメカニズムは、プロトコルスタックのネットワークレイヤーの特性を持つレイヤーよりも低く実装されることも想定されています。任意の主要な管理システムの帯域幅効率も考慮する必要があります。マルチキャストセッションの確立全体のセキュリティとパフォーマンスのトレードオフについては、このドキュメントの後半でさらに詳しく説明します。
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では、いくつかの潜在的なマルチキャストキー管理アーキテクチャ、マニュアル（対称）および公開キーベース（非対称）を詳しく説明し、相対的な利点と欠点を強調します（注：利点と短所のリストは決して包括的ではありません。）。特に、このセクションでは、妥協回復を安全に可能にする手法を強調しています。
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.
分配されたゲームは、トレーニングと評価を目的とするために、紛争シナリオをシミュレートする政府のニーズを扱っています。実際の通信機器が使用されていることに加えて、この概念には、たとえばビデオ会議や画像処理など、コンピューターシミュレーションの大規模な相互接続が含まれます。分散ゲームは、いくつかの理由で実際のシナリオよりも、主要な管理の観点からより要求が厳しい可能性があります。まず、シミュレーションネットのノードは全国に分散する可能性があります。
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.
第二に、リアルタイムのシミュレーション機能の可能性を可能にする非常に大きな帯域幅通信により、ユーザーをシミュレーションにすばやく出し入れする必要があります。これは潜在的に、考慮されるあらゆるものの中で最も要求の厳しいシナリオです。
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人以上の参加者のグループサイズが含まれる場合があり、その一部は小さなサブグループで収集される場合があります。これらのグループは、たとえば、10秒間の合計初期化時間で非常に迅速に初期化する必要があります。このシナリオは、ユーザーが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秒あたりのキロビットから1秒あたり100 MBの範囲です。また、Teleconferenceシナリオには、アクセス制御、ユーザーへのユーザー認証、データの機密性、データの整合性、および非繰り返しをカバーするセキュリティ要件のかなり徹底的なセットもあります。可用性の概念は、このシナリオにも適用されます。このシナリオを提供する必要がある時期は今です。
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:
目的の主要な管理アーキテクチャを開発する際には、考慮する必要がある多くの要因があります。主要な管理アーキテクチャの重要な問題には、セキュリティのレベル（強度）、コスト、システムの初期化、ポリシーの懸念、アクセス制御手順、パフォーマンス要件、サポートメカニズムが含まれます。さらに、マルチキャストグループに特化した問題には次のものがあります。
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. ドメイン間の問題 - ある「グループドメイン」から潜在的に異なるセキュリティポリシーを持つ別のドメインに渡るとき、どのポリシーが実施されますか？例としては、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. 特定のグループメンバーがネットキーの形成を遅らせる可能性のある劣った処理機能を持っているケースをどのように処理しますか？これらのユーザーは、マルチキャストグループ全体の形成を遅らせるのですか、それとも後でオンラインになって、残りの参加者をより迅速に育てることができますか？
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.
これらのすべておよびその他の問題は、目的のマルチキャスト機能をサポートする通信プロトコルとともに、考慮する必要があります。次のセクションでは、これらの問題のいくつかについて説明し、マルチキャストの主要な管理問題に取り組むために使用できる候補のアーキテクチャを提示します。
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:
安全なマルチキャストセッションが発生するために実行する必要があるいくつかの基本的な関数があります。これらの機能が実行される順序、および全体的なソリューションの効率は、上記のさまざまな要因のトレードオフを行うことから生じます。特定のアーキテクチャを見る前に、これらの基本的な関数の概要と、代表的なアーキテクチャで使用される用語の定義が概説されます。これらの定義と関数は次のとおりです。
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. 誰かがマルチキャストセッションの必要性を判断し、その特定のセッションのセキュリティ属性を設定します（たとえば、使用するトラフィックの分類レベル、使用するアルゴリズム、キー変数ビット長など）。最初のマルチキャストグループ参加者リスト。これらの関数を実行するエンティティは、イニシエーターと呼ばれます。この時点で、マルチキャストグループの参加者リストは、イニシエーターがマルチキャストグループに参加したいユーザーのリストです。
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. イニシエーターは、誰がマルチキャストグループを制御するかを決定します。このコントローラーは、ルート（または同等にサーバー）と呼ばれます。多くの場合、イニシエーターはルートになりますが、このコントロールがイニシエーター以外の誰かに受け継がれる可能性があります。（一部のキー管理アーキテクチャは複数のルートを使用しています。[4]を参照してください。）ルートのジョブは、グループ参加者の追加と削除を実行し、そのセッションのセキュリティ属性に対してユーザーアクセス制御を実行し、セッションのトラフィック暗号化キーを配布することです。これをマルチキャストグループネットキーと呼びます。初期化後、将来のグループ参加者の追加を受け入れるか拒否する権限を持つエンティティ、または現在のグループ参加者を削除することは、リストコントローラーと呼ばれます。
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. マルチキャストセッションのすべての参加者は、グループ参加者と呼ばれます。ルートまたはリストコントローラー以外の特定のグループ参加者は、葉と呼ばれます。
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. ルートがマルチキャストグループ参加者リストにリストされている参加者のセキュリティ属性をチェックして、必要なセキュリティ属性をすべてサポートすることを確認すると、ルートはマルチキャストグループリストを他のすべての参加者に渡し、ネットキーを作成および配布します。マルチキャストグループリストの参加者が必要なセキュリティ属性を満たしていない場合、葉をリストから削除する必要があります。
Multiple issues can be raised with the distribution of the multicast group list and Net Key.
マルチキャストグループリストとネットキーの分布により、複数の問題を提起できます。
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. これらの機能の時間順序に問題があります。マルチキャストグループリストは、リンクが保護される前または後に配布できます（つまり、ネットキーが分散されます）。
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. 葉がセッションに参加することを拒否した場合、問題が存在します。リーフがセッションへの参加を拒否した場合、ネットキーを送信する前に変更されたリストを送信することができますが、変更されたリストを複数回送信することは非効率的です。代わりに、ルートは続行することができ、セッションを拒否したリストの参加者にネットキーを送信しませんでした。
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.
以下のシナリオアーキテクチャについては、ネットキーが分散される前に、マルチキャストグループリストがグループ参加者に1回配布されると仮定します。[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.
これらのアプローチは、マルチキャストグループからユーザーを安全に排除するために安全に対処しているが、これがどのように実行されるかについて明らかであると見なされるため、最初のセットアップ後にマルチキャストグループに新しいユーザーの追加を特別に扱っていないことに注意してください。
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 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.
手動キーの配信により、対称キーは公開キーの交換を使用せずに配信されます。マニュアルキーを使用してマルチキャストグループネットキーを設定するには、マルチキャストセッショングループのルートによってネットキーとスペアネットキーが注文される一連のイベントが必要です。代替（スーパーセッション）ネットキーは、グループ参加者の妥協の場合に使用されるように（ルートで）注文されます。ネットキーは、多くの場合、集中化された物理的中間位置を通じて、個々のグループ参加者ごとに配布されます。ある時期に、すべてのグループ参加者が新しいネットキーに切り替えます。グループ参加者は、別の新しいネットキーが必要な場合に、このネットキーを使用します。この期間中にネットキーが侵害された場合、代替ネットキーが使用されます。グループ参加者は、受け取ったらすぐに代替ネットキーに切り替えます。または、全員が新しいネットキーを持っているため、スイッチが行われることをルートから通知します。この手順は、各暗号性について繰り返されます。
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.
このようなスキームは、今日存在し、ユーザーが理解しているため、魅力的かもしれません。残念ながら、このタイプのスキームは、キーイングを注文して配信するのに必要な時間に基づいてマルチキャストグループをセットアップするのに時間がかかる場合があります。ほとんどのリアルタイムシナリオでは、この方法は遅すぎます。
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.
このアプローチは、グループ参加者に共通のマルチキャストグループネットキーを提供するブルートフォースの方法です。このスキームでは、イニシエーターは特定のセッションのセキュリティ属性を設定し、目的のグループ参加者のリストを生成し、リストをすべてのグループ参加者に送信します。葉は、最初の受け入れまたは参加の拒否で反応します。リストを事前に送信することにより、セッションへの参加を拒否した人々と重要な交換を行わないことで時間を節約できます。ルート（これと将来の例のためにイニシエーターであると想定されるのは、標準的な公開キー交換技術（例：diffie-hellman公開キー交換）を使用して、マルチキャストグループの参加者（葉）の1人とペアワイズキーを生成します。）ルートは、この最初の葉にマルチキャストのセキュリティ関連パラメーター（初期ペアワイズキーのパラメーターとは異なる場合がある）を提供します。パラメーターには、分類やポリシーなどのアイテムが含まれる場合があります。パラメーターのいくつかの交渉（セキュリティ協会の管理プロトコル、または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 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.
リーフがマルチキャストセッションへの参加を受け入れると、これら2つはマルチキャストグループが使用するネットキーを選択します。ネットキーは、マルチキャストグループのために実施されているポリシーに応じて、2つのエンティティ間の別の公開キー交換を通じて生成するか、単にルートで選択することができます（つまり、このポリシーの決定はリアルタイムの選択ではありません）。ここでの問題は、葉が根にある信頼のレベルです。初期のペアワイズキーエクスチェンジがある程度のユーザー認証を提供する場合、この段階でルートにネットキーを選択するだけで十分と思われます。別の問題は、生成されたキーのセキュリティの強さに対する信頼のレベルです。協同プロセスを通じて、両方のエンティティ（葉と根）は、ネットキーの形成に使用する情報を提供します。
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.
次に、ルートは別のリーフとペアワイズキー交換を実行し、オプションで前述の交渉を実行します。マルチキャストグループに参加するためにリーフに受け入れられると、ルートは葉にネットキーを送ります。
This pairwise key exchange and Net Key distribution continues for all N users of the multicast group.
このペアワイズキーエクスチェンジとネットキーディストリビューションは、マルチキャストグループのすべての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.
将来の使用のために、ルート/残すペアワイズキー。これらのキーは、後でネットで葉を再キーするために使用されるキー暗号化キー（keks）として機能します。ルートのみが、すべての葉のペアワイズキーをキャッシュします。個々のリーフは、独自のペアワイズキー暗号化キーのみをキャッシュします。
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がセッションキーごとにある場合です。この場合、グループ参加者をマルチキャストセッションから除外したい場合（および残りの参加者に新しいネットキーを使用して再キー）、ルートは、個々のKEKとともに暗号化された新しいネットキーを正当な残りのすべての参加者に配布します。これらのKEKは、マルチキャストセッションが完了すると削除されます。
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番目のケースは、KEKが複数のセッションで有効である場合です。この場合、ネットキーは複数のセッションでも有効である場合があります。または、ネットキーは、上記の場合のように1つのセッションに対してのみ有効である場合があります。ネットキーが1つのセッションで有効であるか、複数のセッションで有効であるかどうかにかかわらず、Kekはキャッシュされます。ネットキーがセッションごとにのみ有効である場合、KEKSはその後のマルチキャストセッションのために新しいネットキーを暗号化するために使用されます。グループ参加者の削除は、ネットキーがセッションごとであるか、複数のセッションに使用されるかに関係なく、上記の前のケースのように発生します。
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 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.
このようなスキームは、認証可能な公開キー交換技術の簡単な拡張であるため、ユーザーにとって魅力的かもしれません。また、第三者が関与していないため、魅力的かもしれません。マルチキャストセッションの一部である参加者のみがキーイングメカニズムに参加します。このスキームを非常に望ましくないのは、最も計算効率の悪い参加者であっても、ハードウェアの能力が低い人（戦術、ワイヤレスなど）は言うまでもなく、数をスケールアップするため、伝送集中的になることです。「許可されていない」参加者を落とす必要性が発生するたびに、新しいネットキーを配布する必要があります。
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).
この分布には、ルートから残りの各参加者へのトランスミッションが必要です。これにより、新しいネットキーは、各参加者のユニークなペアワイズキー暗号化キー（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）セキュリティサブワーキンググループ[REF 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つのリーフにユーザーの半分を取り、キーエクスチェンジを実行する（そしてネットキーを配布）するように指示しますが、ルートはルートの残りの半分の世話をしますリスト。（したがって、選ばれた葉は根として機能しており、それらを「サブルート」と呼ぶことができます。これらの潜水艦はその下に葉を持ち、潜水艦はその下の各葉のkekを維持します。）大きい。具体的には、ペアワイズキー交換を実行し、ネットキーを配布するという特異な責任が複数のグループ参加者間で共有され、ルートのみとは対照的に並行して実行できるため、マルチキャストネットのセットアップ（または再キー）が必要な時間が少なくなります。すべての参加者にネットキーを配布します。
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.
このスキームには、独自のセキュリティの懸念がないわけではありません。このスキームは、各サブグループコントローラーに信頼を押し下げます - ルートは、これらの「サブルート」コントローラーが信頼できる方法で行動していると仮定します。すべての制御要素（ルートとサブルート）は、マルチキャスト全体でシステムに残る必要があります。これにより、分散コントロールのために、ネット（特にサブルート）をより激しくゆっくりと除去することが効果的になります。ネットキーを配布するために、ルートに代わって機能しているマルチキャストグループから参加者を削除すると、追加の手順が必要になります。削除されたサブルートを置き換えるには、新しいサブルートをルートに委任する必要があります。新しいサブルートと各リーフの間にキーエクスチェンジ（新しいペアワイズKEKを生成する）が発生する必要があります。これで、新しいネットキーが根、潜水艦、葉に配布されます。この最後のステップは、削除された当事者が制御責任のない葉である場合、必要な唯一のステップであったことに注意してください。
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の葉があると仮定しましょう。ルートは、各葉i（i = 1,2、...、n）との公開キー交換を実行します。ルートは各ペアワイズケックをキャッシュします。各葉には自分のケックが保管されています。ルートは、参加者のマルチキャストグループリストとすべてのユーザーに属性を提供します。参加者は、前のセクションで説明されているように、マルチキャストセッションへの参加を受け入れるか拒否します。ルートは、マルチキャストグループのネットキーを各葉に暗号化し、独自のkek（i）を使用します。（ルートは、このネットキー自身を生成するか、前述したように葉の1つで協力的に生成されました）。暗号化されたネットキーに加えて、ルートは相補変数と呼ばれるものを暗号化し、葉に送信します。
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リーフの相補的変数を受け取ります。ルートは、kek（i）によって各葉に暗号化されたj = 1,2、...、n、およびjがiに等しくないJ = 1,2、...、n、およびjで、ネットキーと補完的な変数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.
したがって、ユーザーをマルチキャストグループからカットし、残りの参加者を新しいネットキーで再びバックアップするには、以下が含まれます。基本的に、ネットから葉の数値を削減するために、「ネットから葉20をカットする」というメッセージが送信されます。他のすべての葉（およびルート）は、現在のネットキーと相補的変数20に基づいて新しいネットキーを生成します。この新しく生成された変数は、マルチキャストグループの残りのすべての参加者によって新しいネットキーとして使用されます。Leaf 20以外の誰もが新しいネットキーを生成することができます。これは、補完的な変数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と暗号化されたReke Messageがネットから誰かを削除するために送信する必要がないため、伝送の節約の観点から非常に望ましいと思われます。言い換えれば、マルチキャストグループに対して1つのプレーンテキストメッセージと暗号化されたRekeメッセージがあります。このスキームには、2つの大きな欠点があります。1つ目は、（N-1）相補変数に必要なストレージ要件です。第二に、マルチキャストグループから複数のユーザーを削除する場合、共謀が懸念事項になります。これが意味することは、これらの削除されたユーザーが協力して、個々の補完的な変数を共有して、マルチキャストセッションへのアクセスを取り戻すことができるということです。
The Hierarchical Tree Approach is our recommended approach to address the multicast key management problem. This approach provides for the following requisite features:
階層ツリーアプローチは、マルチキャストキー管理の問題に対処するための推奨アプローチです。このアプローチは、次の必要な機能を提供します。
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).
このアプローチは、新しいネットキーの配布を容易にするために、補助キーの階層システムを使用して、時間のコスト、ストレージ、および必要なメッセージ送信の数のバランスを取ります。その結果、各ユーザーのストレージ要件とキー交換に必要な送信は、両方ともユーザー数の対数であり、バックグラウンド送信は必要ありません。このアプローチは、除外されたユーザーの共謀に対して堅牢です。さらに、スキームは本質的に階層的ですが、サーバーを超えてインフラストラクチャは必要ありません（たとえば、ルート）。ただし、そのような要素の存在は有利に使用できます（図1を参照）。
--------------------------
| |
| 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を考えてみましょう。この図は、キーがサーバーとユーザーにのみ存在する論理キー配布アーキテクチャを示しています。したがって、このアーキテクチャのサーバーは、キーAをsを保持し、各ユーザーのkeksを保持します。このアーキテクチャのユーザー11は、独自のユニークなKekとKeys F、K、N、およびOを保持します。
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
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つの葉を使用して（下から）根付きツリーを構築します（便利なためにバランスのとれたバイナリツリーを描いたが、木をバランスをとるかバイナリのどちらかを必要としない - ツリーシェーピングに関するいくつかの予備分析が実行されました。）各ユーザーは、サーバーで一意のペアワイズキーを確立します。送信機能を備えたユーザーの場合、これは公開キーExchangeプロトコルを使用して実行できます。受信のみのユーザーにとって、状況はより複雑です。これらのユーザーが事前に配置されたキーを持っていると仮定するのが最も簡単です。
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 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.)
各ユーザーがサーバーに既知のペアワイズキーを持っていると、サーバーは（そのセッションのためのセキュリティポリシーに従って）ツリー内の残りの各ノードのキーを生成します。キー自体は、堅牢なプロセスによって生成される必要があります。また、ユーザーが必要ないキーに関する情報がないと仮定します。（注：これらの残りのノードにはユーザーがいません（つまり、論理ノードです）。各ノードのキーは、安全な手段を介してサーバーによってのみ生成される必要があります。ルートに向かって、サーバーは各ノードのキーを送信し、そのノードの各子供のキーを使用して暗号化されます。プロセスの最後に、各ユーザーは葉の上のノードに対応するキーを決定できます。特に、すべてのユーザーがルートキーを保持します。これは、グループの共通ネットキーとして機能します。深さDのユーザーのストレージ要件はD 1キーです（したがって、図2の例では、深さd = 4のユーザーが5つのキーを保持します。つまり、ペアワイズキーの結果として生成された一意のキー暗号化キーは交換、3つの中間ノードキー - それぞれ別々に暗号化および送信され、マルチキャストグループの共通ネットキーも個別に暗号化されています。）
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つのメッセージにすべての中間ノードキーとルートノードキーを送信することもできます。ここでは、ノードキーがすべて個々の葉の一意のペアワイズキーで暗号化されます。この方法で、すべてのノードキーを受信するには、ユーザーごとに（D送信と比較して）1つの送信のみがユーザーごとに必要です。この方法では、葉がどのキーがどのノードレベルに対応するかを決定するために何らかの手段を必要とすることが注目されています。
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.
このアプローチには、他の代替アプローチがそうでない場合があるサーバーで追加の処理機能が必要であることに注意することが重要です。最悪の場合、サーバーはアーキテクチャに必要な中間キーを生成する責任があります。
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.
ユーザー11（黒の図2にマークされている）をマルチキャストグループから削除する必要があると仮定します。次に、ユーザー11（BOLDED KEYS F、K、N、O）が保持するすべてのキーを変更し、必要なユーザーに配布する必要があります。これは、ユーザー11または他の誰かがそれらを取得することを許可せずに使用する必要があります。これを行うには、ボトムアップから進むユーザー11が保持している太字のキーを交換する必要があります。サーバーは、最小のノードの新しいキーを選択し、適切な娘キーで暗号化された暗号化されたものを送信します（これらの送信は点線で表されます）。したがって、この例では、最初のキーを交換したキーはキーFであり、この新しいキーはユーザー12の一意のペアワイズキーで暗号化されたものに送信されます。
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, 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.
ボトムアップから進むため、別のキーを暗号化するために使用される前に、交換キーのそれぞれが交換されます。（したがって、キーKを交換するために、この新しいキーは、新しく交換されたキーF（ユーザー12）で暗号化され、ユーザー9と10が共有するノードキーで暗号化された1つのマルチキャスト伝送として送信されます（キーはキーとして送信されます。e）。キーnを交換するために、この新しいキーは、新しく交換されたキーK（ユーザー9、10、および12用）で暗号化され、ユーザー13、14、15が共有するノードキーで暗号化されます。、および16（キーL）。キーOを置き換えるために、この新しいキーは、新しく交換されたキーn（ユーザー9、10、12、13、15、15、および16）で暗号化され、ユーザー1、2、3、4、5、6、7、8、および8（キーm）が共有するノードキーで暗号化されます。必要な送信数は、交換されたノードの程度の合計です。深さDに座っているK-アリーツリーでは、これはほとんどのKD-1トランスミッションになります。したがって、この例では、マルチキャストグループからユーザー11を除外し、他の15人のユーザーをユーザー11がアクセスできない新しいマルチキャストグループネットキーに戻すには、7つの送信が必要になります。システムが共謀に対して堅牢であることは簡単にわかります。これは、ユーザーのいずれかが個別に読むことができない限り、どんなメッセージも読むことができないからです。
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つの送信にさらに減らすことができます。もう一度、メッセージは送信されるビット数で大きくなることに注意してください。さらに、メッセージのどのキーが階層のノードに対応するかを決定するために、各リーフに手段が存在する必要があります。したがって、この例では、キーF、K、N、およびOをユーザー12に置き換えるために、4つのキーがユーザー12の一意のペアワイズキーの下で1つのメッセージで暗号化されます。ユーザー9および10のキーK、N、およびOを置き換えるために、3つのキーは、ユーザー9と10（キーE）が共有するノードキーの下の1つのメッセージで暗号化されます。ユーザー13、14、15、16のキーNとOを置き換えるために、2つのキーは、ユーザー13、14、15、および16（キーL）が共有するノードキーの下の1つのメッセージで暗号化されます。最後に、ユーザー1、2、3、4、5、6、7、および8のキーOを置き換えるために、キーOはユーザーが共有するノードキーの下で暗号化されます1、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.
次の表は、ユーザーの削除と、ユーザー数とともにストレージと送信の要件がどのように成長するかを示しています。
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
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. 補助キーを使用して、他のキーだけでなくメッセージも送信できます。したがって、階層は、特定のノードの下で安全に通信したい（つまり、大規模なマルチキャストグループの残りの部分に送信することなく）サブグループを配置するように設計でき、これらのサブグループの個別のネットキーのメンテナンスの必要性を排除します。これは、主要な階層によって反映される可能性のある階層（たとえば、軍事作戦など）から階層で動作する場合に最適に機能します。
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. このアプローチは、多くのユーザー間の共謀に耐性があります。
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つのキーの場合、次のキーを交換する前に、それぞれの交換されたキーを正常に復号化する必要があります（ユーザーがRekeメッセージをキャッシュできない限り）。このボトルネックは、騒々しいネットワークや遅いネットワークで問題になる可能性があります。（複数のユーザーが削除されている場合、これは並列化される可能性があるため、削除されたユーザーの数とほぼ独立しています。）
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つのキーでは、nユーザーがk-aryツリーに配置されている場合、各ユーザーはストレージが必要になります。1人のユーザーが削除された後に再キーするには、送信が必要です。Kがnに近づくと、これは論文で前述のペアワイズキースキームに近づきます。
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]で提案された提案にもっとよく似ているように配布できます。各ノードには、下位ユーザーに必要な結合または再キーイングを処理するために、各ノードにサブルートが存在する可能性があります。これは、ルートに直接接続されていないユーザーにとって特に魅力的です。セクション5.2に示されているように、ルートの権限と安全とともに行動するためにこれらの潜水艦に置かれた信頼は、潜在的に危険な提案であることを思い出してください。この考えは[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.
これらのサブルートのために作成される可能性のあるいくつかの実用的な推奨事項には、以下が含まれます。潜水艦は、ルートから提供されたマルチキャストグループ参加者リストを変更することを許可されてはなりません。これを達成するための1つの方法は、ルートがリストに署名する前にサブルートに提供することです。ただし、認定されたサブルートは、階層の下にあるユーザー用の新しいマルチキャストグループをセットアップすることができます。
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 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.
また、キー管理スキームが何であれ（階層ツリー、分散階層ツリー、コアベースのツリー、GKMPなど）、最初のマルチキャストグループネットキーを使用してマルチキャストグループを初期化するために発生する「ヒット」が発生することにも注意してください。したがって、階層ツリーアプローチは、初期化に関する他のスキームと比較して、追加の複雑さに悩まされません。
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.
このペーパーでは、マルチキャストグループのルートが開始されることとして形成されましたが、階層的アプローチはユーザーが開始された結合と一致しています。[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.
たとえば、単一のルートの場合、グループ参加者リストを生成するイニシエーター（通常もルート）によって階層が一度設定されます。各参加者のキーのグループは、各参加者がセッションへの参加を希望するまでは、すぐに個別にリクエスト（引っ張る）ことができます。
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 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.
これに別の関連するアイデアは、マルチキャストグループの2人のユーザーが互いに厳密にコミュニケーションを取り、他の誰もコミュニケーションに耳を傾けたくない場合です。マルチキャストグループが最初にセットアップされたときにこのコミュニケーション関係がわかっている場合、これら2人の参加者は、階層の最低レベル（バイナリノード以下）で互いに隣接するだけです。したがって、彼らは自然に秘密のペアワイズキーを共有します。それ以外の場合、これを達成する簡単な方法は、2人のユーザー間で公開キーベースのペアワイズキー交換を実行して、プライベートユニキャスト通信のトラフィック暗号化キーを生成することです。このプロセスを通じて、それらの間の暗号化された送信は、それらのみが読みやすくするだけでなく、公開キーベースのペアワイズ交換を介してユニークな送信者認証を実現できます。
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.
Reference [4]は、マルチキャストグループの定期的なRekeysで使用するためにマルチキャストグループが共有できるグループキー暗号化キーを使用しています。将来のキーを暗号化するための共有キーを実装する潜在的なセキュリティの欠点は別として、グループキー暗号化キーの使用は、メンバーの1人の既知の妥協のためにRekeyが必要な場合、マルチキャストグループに利点がありません。セクション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が必要になりますか？マルチキャストグループのセキュリティポリシーが、削除されたユーザーが送信を受信できなくなった場合、新しいネットキーの再キーが必要になる場合があります。マルチキャストグループのセキュリティポリシーが、削除された人がまだ送信を解読できることを気にしない（まだ保持される可能性のあるグループネットキーで暗号化された）が、メッセージを暗号化して送信できないことを気にしない場合、再キーはもう一度必要。このシナリオの下でマルチキャストグループを再キーする唯一の代替案では、受信者がグループ参加者リストに対して、受信したすべてのメッセージ送信者を確認する必要があります。したがって、リストに載っていないユーザーから送信されたメッセージを拒否します。これは実用的な選択肢ではありません。したがって、妥協の理由であるかどうかにかかわらず、誰かが削除されたときにマルチキャストグループを常に再キーすることをお勧めします。
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 participants hold in common with the removed node.
セクション2に示されているように、ユーザーを一括除去する必要がある場合があります。セクション5.4.1でセクション5.4.1ですべてが同じノードの下にあることを安全に通信したいサブグループに説明したようにセットアップされている場合、ノード全体を削除する場合、バルクユーザーの削除を非常に簡単に実行できます。セクション5.4.1で説明されているのと同じ手法が実行され、残りの参加者が削除されたノードと共通する共通のノードキーを再キーします。
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.
参加者を除去する場合、バルク除去の問題は、ツリー全体に分散されると、より困難になります。削除する参加者の数、および階層内にある参加者の数に応じて、マルチキャストグループを再キーするために必要な送信の数は、残りの参加者のbrute brute brute forceの再キーイングに相当する可能性があります。また、残りのユーザーがどの時点で新しい階層ツリーに再構築されるか、または新しいマルチキャストグループを形成する場合について、問題を提起することができます。階層ツリーの再構築は、新しいユーザーユニークなKEKを形成するために再びペアワイズキー交換を実行する必要がないため、優先オプションになる可能性が高いでしょう。
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）セキュリティサブワーキンググループへのNSA提案[参照。3]「Internet Security Association and Key Management Protocol（ISAKMP）」というタイトルは、最大の現在のネットワークであるインターネットに安全な接続を確立するために必要なさまざまな機能要素を特定しようとしました。提案は現在、ポイントツーポイント接続の問題に焦点を当てていますが、機能要素はマルチキャスト接続に対して同じである必要があり、個々の機能要素を実装するために選択された手法に適切な変更があります。したがって、ISAKMPの実装は、階層ツリーアプローチの使用と互換性があります。
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つの主要な分野があります。それらは、マルチキャストグループを共通のネットキーで安全に初期化し、再キーにすることです。現時点では、マルチキャストグループの初期化に対処する複数の論文がありますが、侵害されたユーザーをマルチキャストグループから効率的かつ安全に削除する方法については適切に対処していません。
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.
この論文は、この困難な問題を満たすために階層的なツリーアプローチを提案しました。共謀に対して堅牢ですが、同時に、妥協の時代にマルチキャストグループを再キーするために必要なトランスミッションの数と必要なストレージのバランスをとります。
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]と一致しており、その実装のための複数のオプションを許可することに注意することも重要です。
Security concerns are discussed throughout this memo.
このメモ全体でセキュリティの懸念について説明します。
1. Harney, H., Muckenhirn, C. and T. Rivers, "Group Key Management Protocol Architecture", RFC 2094, September 1994.
1. Harney、H.、Muckenhirn、C。and T. Rivers、「グループキー管理プロトコルアーキテクチャ」、RFC 2094、1994年9月。
2. Harney, H., Muckenhirn, C. and T. Rivers, "Group Key Management Protocol Specification", RFC 2093, September 1994.
2. Harney、H.、Muckenhirn、C。and T. Rivers、「グループキー管理プロトコル仕様」、RFC 2093、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。Schneider、M。and J.Turner、「インターネットセキュリティ協会および主要管理プロトコル、バージョン7」、1997年2月。
4. Ballardie, T., "Scalable Multicast Key Distribution", RFC 1949, May 1996.
4. Ballardie、T。、「スケーラブルマルチキャストキーディストリビューション」、RFC 1949、1996年5月。
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. Wong、C.、Gouda、M。、およびS. Lam、「キーグラフを使用した安全なグループコミュニケーション」、テクニカルレポートTR 97-23、1997年7月、テキサス大学オースティン校コンピューターサイエンス科。
Authors' Addresses
著者のアドレス
Debby M. Wallner National Security Agency Attn: R2 9800 Savage Road STE 6451 Ft. Meade, MD. 20755-6451
Debby M. Wallner National Security Agency attn：R2 9800 Savage Road Ste 6451 Ft。MEADE、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：R2 9800 Savage Road Ste 6451 Ft。MEADE、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
Ryan C. Agee National Security Agency attn：R2 9800 Savage Road Ste 6451 ft。MEADE、MD。20755-6451
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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エディター機能の資金は現在、インターネット協会によって提供されています。