RFC2094 日本語訳
2094 Group Key Management Protocol (GKMP) Architecture. H. Harney, C.Muckenhirn. July 1997. (Format: TXT=53097 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Harney
Request for Comments: 2094 C. Muckenhirn
Category: Experimental SPARTA, Inc.
July 1997
コメントを求めるワーキンググループH.ハーニーの要求をネットワークでつないでください: 2094年のC.Muckenhirnカテゴリ: 実験的なスパルタInc.1997年7月
Group Key Management Protocol (GKMP) Architecture
グループKey Managementプロトコル(GKMP)アーキテクチャ
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction................................................. 1 2. Multicast Key Management Architectures....................... 3 3. GKMP Protocol Overview....................................... 9 4. Issues....................................................... 19 5. Security Considerations...................................... 22 6. Authors' Address............................................. 22
1. 序論… 1 2. マルチキャストKey Managementアーキテクチャ… 3 3. GKMPは概要について議定書の中で述べます… 9 4. 問題… 19 5. セキュリティ問題… 22 6. 作者のアドレス… 22
Abstract
要約
This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This protocol has the following advantages: 1) virtually invisible to operator, 2) no central key distribution site is needed, 3) only group members have the key, 4) sender or receiver oriented operation, 5) can make use of multicast communications protocols.
この仕様は、分類された対称鍵を作成して、同輩を伝えるのにそれらを分配するためにプロトコルを提案します。 このプロトコルには、以下の利点があります: 1) 実際にはオペレータには目に見えません、2の)いいえ主要な主要な分配サイトが必要であり、3は)メンバーを分類するだけです。4)送付者がキーを持っていたか、または受信機は操作を適応させました、そして、5は)マルチキャスト通信規約を利用できます。
1 Introduction
1つの序論
This document describes an architecture for the management of cryptographic keys for multicast communications. We identify the roles and responsibilities of communications system elements in accomplishing multicast key management, define security and functional requirements of each, and provide a detailed introduction to the Group Key Management Protocol (GKMP) which provides the ability to create and distribute keys within arbitrary-sized groups without the intervention of a global/centralized key manager. The GKMP combines techniques developed for creation of pairwise keys with techniques used to distribute keys from a KDC (i.e., symmetric encryption of keys) to distribute symmetric key to a group of hosts.
このドキュメントはマルチキャストコミュニケーションのための暗号化キーの管理のためにアーキテクチャについて説明します。 私たちは、任意サイズのグループの中でグローバルであるか集結された主要なマネージャの介入なしでキーを作成して、分配する能力を提供するGroup Key Managementプロトコル(GKMP)に、マルチキャストかぎ管理を実行する際にコミュニケーションシステム・エレメントの役割と責任を特定して、それぞれに関するセキュリティと機能条件書を定義して、詳細な序論を提供します。 GKMPはテクニックが使用されている対状キーの作成がホストのグループの対称鍵を分配するためにKDC(すなわち、キーの左右対称の暗号化)からキーを分配するように見いだされた技術を結合します。
Harney & Muckenhirn Experimental [Page 1] RFC 2094 GKMP Architecture July 1997
[1ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
1.1 Multicast Communications Environments
1.1 マルチキャストコミュニケーション環境
The work leading to this report was primarily concerned with military command and control and weapons control systems, these systems tend to have top--down, commander--commanded, communications flows. The choice of what parties will be members of a particular communication (a multicast group for example) is at the discretion of the "higher" level party(ies). This "sender-initiated" (assuming the higher-level party is sending) model maps well to broadcast (as in electromagnetic, free-space, transmission) and circuit switched communications media (e.g., video teleconferencing, ATM multicast).
このレポートにつながる仕事は主として軍事機構に関係がありました、そして、コントロールと兵器削減システム、これらのシステムは先端(下に、指揮官)を命令させる傾向があります、コミュニケーション流れ。 「より高い」平らなパーティー(ies)の裁量には選択が何が特定のコミュニケーションのメンバーが(例えば、マルチキャストグループ)であるつもりであったならパーティーへ行くかをあります。 この「送付者によって開始している」(よりハイレベルのパーティーが発信すると仮定する)モデルは放送するために井戸を写像します、そして、(電磁の、そして、自由なスペースのトランスミッションのように)回路は通信機関(例えば、ビデオ遠隔会議、ATMマルチキャスト)を切り換えました。
In looking to apply this technology to the Internet, a somewhat different model appears to be at work (at least for some portion of Internet multicast traffic). IDRP and Distance Vector Multicast Routing Protocol (DVMRP) use multicast as a mechanism for parties to relay common information to their peers. Each party both sends and receives information in the multicast channel. As appropriate, a party may choose to leave or join the communication without the express permission of any of the other parties (this begs the question of meta-authorizations which allow the parties to cooperate). More interestingly, the multicast IP model has the receiver telling the network to add it to the distribution for a particular multicast address, whether it exists yet or not, and the transmitter not being consulted as to the addition of the receiver.
この技術をインターネットに適用するために見る際に、いくらか異なったモデルは、仕事(少なくともインターネットマルチキャストトラフィックの何らかの部分への)にはあるように見えます。 パーティーが彼らの同輩に一般的な情報をリレーするのにIDRPとディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル(DVMRP)はメカニズムとしてマルチキャストを使用します。 各当事者は、ともにマルチキャストチャンネルによる情報を送って、受け取ります。 適宜、パーティーは、いなくなるか、または相手のどれかの急行許可なしでコミュニケーションを接合するのを選ぶかもしれません(これはパーティーが協力できるメタ承認を論点を巧みに避けさせます)。 マルチキャストIPモデルは、よりおもしろく、受信機にまだ存在しているか否かに関係なく、特定のマルチキャストアドレスのための分配にそれを加えるようにネットワークに言わせて、受信機の追加に関して送信機を相談させません。
Other applications of multicast communications in the Internet, for example NASA Select broadcasts, can be viewed as implementing the sender model since the sender selects the broadcast time, channel, and content, though not the destinations.
送付者が放送時間、チャンネル、および内容を選ぶので送付者モデルを実装するとインターネットのマルチキャストコミュニケーションの他のアプリケーション(例えば、NASAのSelect放送)を見なすことができます、目的地ではありませんが。
It is our intention to provide key management services which support both communications (and implied access control) models and operate in either a circuit switched or packet switched environment.
両方のコミュニケーション(そして、暗示しているアクセスコントロール)がモデルであるとサポートして、回路が切り換えたどちらかかパケットの切り換えられた環境で作動するのは、かぎ管理サービスを提供するという私たちの意志です。
1.2 Security for Multicast
1.2 マルチキャストのためのセキュリティ
Multicast communications, as with unicast, may require any of the security services defined in ISO 7498, access control, data confidentiality, traffic confidentiality, integrity/data authentication, source authentication, sender and receiver non- repudiation and service assurance. From the perspective of key management processes, only data confidentiality, data authentication, and source authentication can be supported. The other services, traffic confidentiality, non-repudiation, and service assurance must be provided by the communications protocol, they may rely on cryptographic services but are not guaranteed by them.
マルチキャストコミュニケーションは、ユニキャストならISO7498、アクセスコントロール、データの機密性、トラフィック秘密性、保全/データ認証、ソース認証、送付者、および受信機で非拒否する状態でサービスが定義したセキュリティのどれかを必要として、保証を修理するかもしれません。 かぎ管理プロセスの見解から、データの機密性、データ認証、およびソース認証しかサポートすることができません。 他のサービス、トラフィック秘密性、非拒否、およびサービス保証はそれらが通信規約によって、暗号のサービスに依存するかもしれませんが、保証されないかどうかということであるに違いありません。
Harney & Muckenhirn Experimental [Page 2] RFC 2094 GKMP Architecture July 1997
[2ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
2 Multicast Key Management Architectures
2 マルチキャストKey Managementアーキテクチャ
2.1 Current Operations
2.1 現在の操作
There are several electronic mechanisms for generating and distributing symmetric keys to several computers (i.e., communications groups). These techniques, generally, rely on a key distribution center (KDC) to act as a go between in setting up the symmetric key groups. Military systems, such as BLACKER, STU- II/BELLFIELD, and EKMS, and commercial systems, such as X9.17 and Kerberos, all operate using dedicated KDCs. A group key request is sent to the KDC via various means (on- or off-line) The KDC acting as an access controller decides whether or not the request is proper (i.e., all members of a group are cleared to receive all the data on a group). The KDC would then call up each individual member of the group and down load the symmetric key. When each member had the key the KDC would notify the requester. Then secure group communication could begin. While this was certainly faster then anything that requires human intervention. It still requires quite a bit of set-up time. Also, a third party, whose primary interest isn't the communication, needs to get involved.
数台のコンピュータ(すなわち、コミュニケーショングループ)の対称鍵を生成して、分配するための数個の電子メカニズムがあります。 一般に、これらのテクニックは、間の対称鍵をセットアップすることにおける碁が分類されるとき行動するために、主要な配送センター(KDC)を当てにします。 BLACKERなどの軍用システム(X9.17やケルベロスなどのスチューII/BELLFIELD、EKMS、および商業の体系)は、専用KDCsを使用することですべて作動します。 要求が適切である(グループのすなわちすべてのメンバーがグループに関するすべてのデータを受け取るためにきれいにされます)か否かに関係なく、入場管理者としてのKDC芝居が決める様々な手段(オンであるかオフラインの)でグループ重要要求をKDCに送ります。 そして、KDCは、グループと下の各個人会員に負荷を対称鍵と呼ぶでしょう。 各メンバーがキーを持っていたとき、KDCはリクエスタに通知するでしょう。 そして、安全なグループコミュニケーションは始まることができました。 次に、これは確かに何かより速いものでしたが、それは人間の介入を必要とします。 それはまだかなりのセットアップ時間を必要としています。 また、第三者(主要な関心はコミュニケーションでない)は、かかわる必要があります。
Pairwise keys can be created autonomously by the host on a network by using any number of key generation protocols (FireFly, Diffe-Hellman, RSA). These protocols all rely on cooperative key generation algorithms to create a cryptographic key. These algorithms rely on random information generated by each host. These algorithms also rely on peer review of permissions to ensure that the communication partners are who they claim to be and have authorization to receive the information being transmitted. This peer review process relies on a trusted authority assigning permissions to each host in the network that wants the ability to create these keys. The real beauty of these pairwise key management protocols is that they can be integrated into the communication protocol or the application. This means that the key management becomes relatively invisible to the people in the system.
ホストは、ネットワークでプロトコル(FireFly、Diffe-ヘルマン、RSA)をいろいろなキー生成で使用することによって、自主的に対状キーを作成できます。 これらのプロトコルはすべて、暗号化キーを作成するために協力的なキー生成アルゴリズムを当てにします。 これらのアルゴリズムは各ホストによって生成された無作為の情報を当てにします。 また、これらのアルゴリズムは、送信される情報を受けるためにコミュニケーションパートナーが彼らが主張する人であり、承認を持っているのを保証するために許容の同輩レビューに依存します。 この同輩吟味の過程はこれらのキーを作成する能力を必要とするネットワークの各ホストに許容を割り当てる信じられた権威を当てにします。 これらの対状かぎ管理プロトコルの本当の美は通信プロトコルかアプリケーションとそれらを統合できるということです。 これは、かぎ管理がシステムの人々には比較的目に見えなくなることを意味します。
2.2 GKMP-Based Operations
2.2 GKMPベースの操作
The GKMP described below, delegates the access control, key generation, and distribution functions to the communicating entities themselves rather than relying on a third party (KDC) for these functions. As prelude to actually distributing key, a few things must be assumed (for purposes of this document): there exists a "security manager" responsible for creating and distributing to parties authentic identification and security permission information (The security manager function may be accomplished through a strictly hierarchical system (a la STU-III) or a more ad hoc system of
以下で説明されたGKMP、アクセスが監督する代表、キー生成、および分配はこれらの機能のために第三者(KDC)を当てにするよりむしろ交信実体自体に機能します。 実際にキーを分配することへのプレリュードとして、いくつかのものを想定しなければなりません(このドキュメントの目的のために): 正統の識別とセキュリティ許可情報をパーティーに作成して、広げるのに責任がある「セキュリティマネージャ」が存在している、(セキュリティマネージャ機能は厳密に階層的なシステム(STU-IIIのような)か、より臨時のシステムを通して達成されるかもしれません。
Harney & Muckenhirn Experimental [Page 3] RFC 2094 GKMP Architecture July 1997
[3ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
cooperating peer "domain managers," the implementation of the certification hierarchy is not addressed in this document.); communicating parties are online for the keys formed and distributed by the GKMP.
協力して、証明階層構造の実装は同輩「ドメインマネージャ」と扱われません。本書では)、。 GKMPによって形成されて、分配されたキーにおいて、交信パーティーはオンラインです。
2.2.1 Sender Initiated Operations
2.2.1 送付者は操作を開始しました。
This section describes the basic operational concept for multicast key management for sender initiated multicast support. This model of multicast communications was the basis for our original work on multicast key management. From a security viewpoint the sending application is able to control access to the transmission through both key distribution and communications distribution (not sending the transmission to some addresses).
このセクションは送付者の開始しているマルチキャストサポートのためのマルチキャストかぎ管理のための基本の操作上の概念について説明します。 マルチキャストコミュニケーションのこのモデルはマルチキャストかぎ管理に対する私たちのオリジナルの仕事の基礎でした。 セキュリティ観点から、送付アプリケーションは主要な分配とコミュニケーション分配の両方を通したトランスミッションへのアクセスを制御できます(いくつかのアドレスにトランスミッションを送らないで)。
Identification of Group Key Controller -- The originator of the multicast group creates or obtains a group management certificate from its certification hierarchy. The certificate identifies the holder as responsible for generation and distribution of the group key (Naming standards are not addressed here, the name should reflect the naming structures appropriate for the supported cryptographic service. For example, IP-level encryptors should use naming reflecting "host" identities (IP addresses, or DNS host names), RTP encryptor would use session names). The originator relays the membership list to the Group Key Management (GKM) application.
Group Key Controllerの識別--マルチキャストグループの創始者は、証明階層構造から集団経営証明書を作成するか、または入手します。 証明書は、所有者がグループキーの生成と分配に責任があると認識します。(命名規格はここで扱われないで、名前はサポートしている暗号のサービスに、適切な命名構造を反映するべきです。 例えば、IP-レベル暗号化する人は命名反射している「ホスト」のアイデンティティ(IPアドレス、またはDNSホスト名)を使用するべきであり、RTP暗号化する人はセッション名を使用するでしょう。). 創始者はGroup Key Management(GKM)アプリケーションに会員名簿をリレーします。
Group Key Creation -- The GKM application, operating on behalf of the originator, selects one member of the group, contacts it, and creates a Group Key Packet (GKP). A GKP contains the current group traffic encrypting key (GTEK) and future group key encrypting key (GKEK). The GKM application then identifies itself as the group key controller, which the member validates, under cover of the GTEK.
グループKey Creation--GKMアプリケーションは、創始者を代表して作動して、グループの1人のメンバーを選んで、それに連絡して、Group Key Packet(GKP)を作成します。 GKPはキー(GKEK)を暗号化しながら主要(GTEK)で将来のグループキーを暗号化する現在のグループトラフィックを含んでいます。 そして、GKMアプリケーションはグループキーコントローラであると名乗ります。(メンバーはGTEKのカバーの下でそのコントローラを有効にします)。
Group Key Packet (GKP) = [GTEKn,GKEKn+1]
グループ主要なパケット(GKP)=[GTEKn、GKEKn+1]
As part of group key packet formation, usage parameters, appropriate for the underlying crypto-system, are selected. Unlike normal parameter negotiation, where common security-level/range, and services are arrived at, the originator's GKM application selects these parameters and the member must comply.
グループキーパケット構成の一部として、基本的な暗号系に、適切な用法パラメタは選定されます。 通常のパラメタ交渉と異なって、到着して、創始者のGKMアプリケーションはこれらのパラメタを選択します、そして、メンバーは応じなければなりません。そこでは、一般的なセキュリティー・レベル/範囲、およびサービスがそうです。
Group Key Distribution -- After creation of the GKP, the group controller contacts each member of the group, creates a Session Key Package (SKP), validates their permissions (check member's certificate against group parameters), and create a Group Rekey
GKPの作成の後のグループKey Distribution、グループコントローラはグループの各メンバーに連絡して、Session Keyパッケージ(SKP)を作成して、彼らの許容を有効にします、そして、(グループパラメタに対してメンバーの証明書をチェックしてください)Group Rekeyを作成してください。
Harney & Muckenhirn Experimental [Page 4] RFC 2094 GKMP Architecture July 1997
[4ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
Package for that member. A SKP contains a session TEK and a session KEK for a particular member. A GRP contains the GKP encrypted in a KEK and signed using the originator's certificate.
そのメンバーのために、パッケージします。 SKPは特定のメンバーのためのセッションTEKとセッションKEKを含んでいます。 GRPはKEKで暗号化されて、創始者の証明書を使用することで署名されるGKPを含んでいます。
Session Key Package (SKP) = [STEK, SKEK]
セッションの主要なパッケージ(SKP)=[STEK、SKEK]
Group Rekey Package (GRP) = {[GKP]KEK} SignatureController
グループRekeyパッケージ(GRP)は[GKP]KEK SignatureControllerと等しいです。
Group Rekey -- When the group needs to be rekeyed, the originating GKM application selects a member, creates a new GKP, creates a new GRP (which is encrypted in the previously distributed next GKEK) and broadcasts it to the group.
Rekeyを分類してください--グループが、「再-合わせ」られる必要があると、起因しているGKMアプリケーションがメンバーを選んで、a新しいGKPを作成して、新しいGRPを作成する、(どれが次に以前に分配されているところで暗号化されるか、GKEK、)、それをグループに放送します。
This procedure is fairly complex, but other than for the distribution of site-specific certificates, no centralized key management resources are needed. The only parties to the key management communications are the same parties which will be participating in the group.
この手順はかなり複雑ですが、サイト特有の証明書の分配以外に、集結されたかぎ管理リソースは全く必要ではありません。 かぎ管理コミュニケーションへの唯一のパーティーがグループに参加する同じパーティーです。
2.2.2 Receiver Initiated Operations
2.2.2 受信機の開始している操作
This section describes key management operational concept for receiver initiated multicast communication support. The receiver initiated model presents some interesting problems from a security view point since the end-participants are not known a priori. Also, in a purely receiver initiated application (such as DVMRP), there is no concept of an "originator" and the participants in the group may be quite dynamic with participants changing on a minute by minute basis.
このセクションは受信機の開始しているマルチキャストコミュニケーションサポートのためにかぎ管理の操作上の概念について説明します。 終わり関係者が先験的に知られていないので、受信機の開始しているモデルはセキュリティ見地からいくつかのおもしろい問題を提示します。 また、aでは、純粋に、受信機はアプリケーション(DVMRPなどの)を開始しました、そして、「創始者」の概念が全くありません、そして、関係者が1分に微小な基礎で変化していて、グループの関係者はかなりダイナミックであるかもしれません。
For secure group communications to take place, all members must obtain the same key. This may be achieved by either using deterministic key generation techniques (using a secret, shared seed) or by making one member of the group responsible for creation of the key. The use of a deterministic key generator presents security problems, particularly regarding loss of the seed (it compromises both past and future traffic). The assignment of a member to the role of key "controller" also presents drawbacks, but these relate to determining which one should be the controller and the need for each member to contact him. The remainder of this discussion will look at how the "controller" concept from above could work in the receiver initiated case.
安全なグループコミュニケーションが行われるために、すべてのメンバーが同じキーを入手しなければなりません。 これは、決定論的なキー生成のテクニック(秘密の、そして、共有された種子を使用する)を使用するか、またはグループの1人のメンバーをキーの作成に責任があるようにすることによって、達成されるかもしれません。 決定論的なキー・ジェネレータの使用は警備上の問題を提示します、特に種子の損失に関して(それは、両方が過去の、そして、将来のトラフィックであると感染します)。 また、主要な「コントローラ」の役割へのメンバーの課題は欠点を提示しますが、これらはどれがコントローラであるべきであるかを決定して、各メンバーが彼に連絡する必要性に関連します。 この議論の残りは「コントローラ」概念が受信機の開始している場合でどう上から働くことができたかを見るでしょう。
Selection of Group Key Controller -- A group member will be made responsible for initial group establishment and periodic generation and dissemination of new GRPs. There is no need for the selected controller to be the controller for all time, but at any one time only one controller may be active for each group. Selection of
Group Key Controllerの選択--グループのメンバーを新しいGRPsの初期のグループ設立、周期的な世代、および普及に責任があるようにするでしょう。 時間中に、選択されたコントローラがコントローラである必要は全くありませんが、いかなる時も、各グループに、1台のコントローラだけがアクティブであるかもしれません。 選択
Harney & Muckenhirn Experimental [Page 5] RFC 2094 GKMP Architecture July 1997
[5ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
controller may be made through a voting system, by a simple default (the first to transmit to the group is the controller), or configuration.
コントローラは投票制度を通して作られているかもしれません、簡単なデフォルト(グループに伝わる1番目はコントローラである)、または構成で。
The current controller's identity must be made available to all members, and potential members, for initial group key load and error recovery. The information may be relayed by broacast on a key management "channel," or through a directory service.
現在のコントローラのアイデンティティをすべてのメンバー、および会員になる可能性のある人にとって利用可能にしなければなりません、初期のグループキー荷重とエラー回復のために。 情報はかぎ管理「チャンネル」の上、または、ディレクトリサービスを通してbroacastによってリレーされるかもしれません。
Group Key Creation -- The GKP is created and distributed in much the same way as in sender initiated operations. The controller creates a GKP with the first group member to initiate contact. The GKM application then identifies itself as the group key controller, which the member validates, under cover of the GTEK. Parameter negotiation is performed and the first group member is keyed.
グループKey Creation--GKPは大体同じようなやり方で送付者の開始している操作のように作成されて、分配されます。 コントローラは第1代接触を起こすグループのメンバーと共にGKPを作成します。 そして、GKMアプリケーションはグループキーコントローラであると名乗ります。(メンバーはGTEKのカバーの下でそのコントローラを有効にします)。 パラメタ交渉は実行されます、そして、第1代グループのメンバーは合わせられます。
Group Key Distribution -- After creation of the GKP, as other members contact the controller, a SKP is created, member permissions are validated and a GRP is loaded to the member.
GKPの作成、他のメンバーがコントローラに連絡するときSKPが作成されて、メンバー許容が有効にされて、GRPがメンバーに積み込まれた後にKey Distributionを分類してください。
For widely distributed groups, a form of distributed dissemination may be used. Some number of regional GKM applications are enabled with the ability to validate the permissions of new members and upon validation send to them the current GKP.(Access control is not defined in this document, but it is assumed that both hierarchical and discretionaly (rule-based and identity-based) access control will be supported.) These regional key distributors perform the same functions as the controller, except that they do not create the GKP. This concept can be expanded to the point where all current members are capable of downloading the GKP, and passing on that capability.
広く分配されたグループのために、分配された普及のフォームは使用されるかもしれません。 何らかの数の地方のGKMアプリケーションが許容を新しいメンバーに有効にして、合法化のときに現在のGKPを彼らに送る能力で可能にされます。. (アクセスコントロールは本書では定義されませんが、階層的なものと同様にdiscretionalyな(規則ベースの、そして、アイデンティティベースの)アクセスコントロールがサポートされると思われます。) GKPを作成しないのを除いて、これらの地方の主要なディストリビュータはコントローラと同じ機能を実行します。 すべての現在のメンバーができるGKPをダウンロードして、その能力を伝える意味にこの概念を広げることができます。
Group Rekey -- When the group need rekeying the procedure would be identical to the sender initiated case. The controlling GKM application selects a member, creates a new GKP, creates a new GRP (which is encrypted in the previously distributed next GKEK) and broadcasts it to the group.
手順を「再-合わせ」るグループの必要性が送付者の開始している事件と同じであるだろうというときに、Rekeyを分類してください。 制御GKMアプリケーションがメンバーを選んで、a新しいGKPを作成して、新しいGRPを作成する、(どれが次に以前に分配されているところで暗号化されるか、GKEK、)、それをグループに放送します。
2.3 GKMP Features
2.3 GKMPの特徴
This section highlights areas which we believe the GKMP approach has advantages over the "traditional" KDC based approaches.
このセクションは領域を強調します(「伝統的な」KDCベースのアプローチの上でうま味があります私たちが、GKMPアプローチを信じている)。
2.3.1 Multicast
2.3.1 マルチキャスト
Multicast protocols are a growing area of interest for the Internet. The largest benefit of a multicast protocol is the ability of several receivers to simultaneously get the same transmission. If the transmission is of a sensitive nature, it should be encrypted. This
マルチキャストプロトコルはインターネットへの興味がある成長地域です。 マルチキャストプロトコルの最も大きい利益は数台の受信機が同時に同じトランスミッションを得る能力です。 トランスミッションが敏感な本質のものであるなら、それは暗号化されるべきです。 これ
Harney & Muckenhirn Experimental [Page 6] RFC 2094 GKMP Architecture July 1997
[6ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
means that the all members of the group must share the same encryption key to take benefit of the multicast transmission.
それを意味する、すべてのメンバー、グループでは、必須はマルチキャスト送信の恩恵を取るために主要な同じ暗号化を共有します。
To date the only way of setting up a group of symmetric keys is with the assistance of a centralized key management facility. This facility would act as a key broker creating a distributing key to qualified group members. There are several problems with this centralized concept. These problems give rise to many of the following motivations for creating a distributed key management protocol.
これまで、対称鍵のグループを設立する唯一の方法が集結されたかぎ管理施設の支援と共にあります。 この施設は適任のグループのメンバーの分配キーを作成する主要なブローカーとして務めるでしょう。 この集結された概念に関するいくつかの問題があります。 これらの問題は分配されたかぎ管理プロトコルを作成することに関する以下の動機の多くをもたらします。
2.3.2 Increase the autonomy of key groups
2.3.2 主要なグループの自治を増強してください。
The GKMP proposes to extend the pairwise key paradigm to grouped keys. This protocol can be integrated into the communication protocols or applications and can become invisible to the host's operator. We will use peer review to enforce our security policy.
GKMPは、対状の主要なパラダイムを分類されたキーに広げるよう提案します。 このプロトコルは、通信プロトコルかアプリケーションと統合できて、ホストのオペレータにとって目に見えなくなることができます。 私たちは、私たちの安全保障政策を実施するのに同輩レビューを使用するつもりです。
The GKMP allows any host on a network to create and manage a secure group. Maintenance of these group keys can be performed by the hosts interested in the group. The groups themselves will be relatively autonomous. This simplifies the installation of this technology allowing more host to use secure multicast communications.
GKMPはネットワークのどんなホストにも安全なグループを創設して、経営させます。 グループに興味を持っているホストはこれらのグループキーのメインテナンスを実行できます。 グループ自体は比較的自治になるでしょう。 これは、より多くのホストが安全なマルチキャストコミュニケーションを使用できるこの技術のインストールを簡素化します。
2.3.3 Latency
2.3.3 潜在
Latency refers to the time to set-up or tear down or to re-key a group. In short this corresponds to the length of time it would take to set-up a multicast address.
潜在はキー下か再キーまでグループをセットアップするか、または引き裂く時間を参照します。 要するにこれはマルチキャストアドレスをセットアップするにはかかる時間の長さに対応しています。
The GKMP can allow delegation of group creation authority to any host in the network. In essence, when a host needs a group it will have the tools needed to create that group and manage it. Additionally, since the host only needs to create a single group it can concentrate on that particular group.
GKMPはネットワークのどんなホストへのグループ作成権威の委譲も許容できます。 本質では、ホストがそれが持っているグループを必要とするとき、ツールは、そのグループを創設して、それを管理する必要がありました。 さらに、ホストが、ただ一つのグループを創設する必要があるだけであるので、それはその特定のグループに集中できます。
In the current centralized key distribution approach. The group must be requested from the central site. The central site would process that request in accordance with it's priority and current workload. Latencies would develop if the workload of the central site gets unwieldy or if the communications to the site become overloaded.
現在の集結された主要な分配では、アプローチしてください。 主要なサイトからグループを要求しなければなりません。 それの優先権と現在のワークロードに従って、主要なサイトはその要求を処理するでしょう。 主要なサイトのワークロードが扱いにくくなるか、またはサイトへのコミュニケーションが積みすぎられるようになるなら、潜在は見いだされるでしょう。
2.3.4 Extendibility
2.3.4 拡張性
One of the problems with a centralized key distribution system is the concentration of key management workload at a single site. The process of creating key groups -- key creation, access review, communication to group members takes time and effort. As the number
集結された主要な流通制度に関する問題の1つはただ一つのサイトのかぎ管理ワークロードの集中です。 主要なグループを創設するプロセス--主要な作成、アクセスレビュー、コミュニケーションはグループのメンバーに時間と取り組みがかかります。 数として
Harney & Muckenhirn Experimental [Page 7] RFC 2094 GKMP Architecture July 1997
[7ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
of groups on the network grows and the number of group members group. The workload at that central sight quickly reaches capacity.
ネットワークに関するグループは成長します、そして、グループのメンバーの数は分類されます。 その主要な光景のワークロードはすぐに容量に達します。
GKMP should allow a great number of groups to exist on the Internet without overloading any particular host. Delegation of the net wide group creation and management workload places the burden of maintaining groups on the hosts interested in using those groups. Not only is this more efficient, but it places the burden in an appropriate location.
どんな特定のホストも積みすぎないで、GKMPはインターネットにかなりの数のグループを存在させるべきです。 ネットの広いグループ作成と管理ワークロードの委譲はそれらのグループを使用したがっていたホストにグループを維持する負担をかけます。 この以上が効率的であるだけではなく、それは適切な位置に負担をかけます。
The GKMP distributes the communication requirements to manage groups across the network. Each group manages the group using the same communication resources needed to pass traffic. It is likely that if a communication group can support the traffic of a group, it will be able to support the minimal traffic needed to management the keys for that group.
GKMPはネットワークの向こう側にグループを経営するというコミュニケーション要件を分配します。 各グループは、トラフィックを通過するのに必要である同じコミュニケーションリソースを使用することでグループを経営します。 コミュニケーショングループがグループのトラフィックをサポートすることができると、それのためのキーが分類する管理に必要である最小量のトラフィックをサポートすることができそうでしょう。
GKMP provides it's own access control, based on signed netwide permission certificates. This partially disseminates the burden of access control and permission management. A system wide authority must assign the permission certificates, but day to day access control decisions are a GKMP responsibility.
GKMPは署名しているnetwide許可証明書に基づいてそれの自己のアクセス制御を提供します。 これはアクセスコントロールと許可管理の負担を部分的に広めます。 システムの広い権威は許可証明書を割り当てなければなりませんが、日々に、アクセス制御決定はGKMP責任です。
2.3.5 Operating expense
2.3.5 営業費用
A centralized key distribution site contains, at one time or another, the keys for the net. This is a valuable target for someone to compromise. To protect this site physical and procedural security mechanisms are employed (e.g., guards, fences, intrusion alarms, two person safes, no-alone zones). These mechanisms do not come cheap.
集結された主要な分配サイトはいつか、ネットのためのキーを含みます。 これはだれかが感染する貴重な目標です。 このサイトを保護するために、物理的で手続き上のセキュリティー対策は採用しています(例えば、番人、フェンス、侵入が驚かせます、2個の人の金庫、いいえだけのゾーン)。 これらのメカニズムは安く上がりません。
Allowing the hosts to create and manage their keys eliminates the need for an on-line centralized key distribution site. The protocol approach restricts access to the keys to the hosts using them (the minimal set). Since, the encryption mechanisms will have already incurred the cost to be physically secured there is no additional cost levied on the system by the key management system.
ホストが彼らのキーを作成して、管理するのを許容するのがオンライン集結された主要な分配サイトの必要性を排除します。 プロトコルアプローチは、彼ら(極小集合)を使用することでアクセスをホストのキーに制限します。 以来、メカニズムがそこで物理的に機密保護されるために既に費用を被ってしまうだろう暗号化はかぎ管理システムによってシステムに別途費用が徴収されませんでした。
2.3.6 Communication Resources
2.3.6 コミュニケーションリソース
Because a centralized site is involved in creating, distributing, rekeying, and providing access control for every group, it is frequently accessed. The communication resources available to this site often become a bottle neck for the groups. Therefore a big pipe is usually installed to this facility.
集結されたサイトがアクセスコントロールをあらゆるグループに作成して、分配して、「再-合わせ」て、提供するのにかかわるので、それは頻繁にアクセスされます。 このサイトに利用可能なコミュニケーションリソースはしばしばグループのための隘路になります。 したがって、通常、大きいパイプはこの施設に設置されます。
Harney & Muckenhirn Experimental [Page 8] RFC 2094 GKMP Architecture July 1997
[8ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
The GKMP proposes delegating most of the key creation, distribution, rekey and access control mission to the hosts that need the secure communication. There no longer is a single third party that must be consulted prior to every group key management action. Hence, the communications requirements to manage the keys have shifted to the groups themselves. The need for special high capacity communications has been eliminated.
GKMPは主要な作成の大部分を代表として派遣する、分配、rekey、および安全なコミュニケーションを必要とするホストへのアクセス制御任務を提案します。 もう、あらゆるグループかぎ管理動作の前に相談しなければならない独身の第三者がいます。 したがって、キーを管理するというコミュニケーション要件はグループ自体に移行しました。 特別な高容量コミュニケーションの必要性は排除されました。
2.3.7 Reliability
2.3.7 信頼性
Delegating key management responsibility to the groups eliminates the centralized key management site as a single point of failure. The groups that will use the key are responsible for it. If the communications system fails for the key management it is also down for the communications.
かぎ管理責任をグループへ代表として派遣すると、集結されたかぎ管理サイトは1ポイントの失敗として排除されます。 キーを使用するグループはそれに責任があります。 通信網がかぎ管理のために失敗するなら、それはコミュニケーションのためにものですも。
The GKMP will attempt to delegate as many functions to the group as possible. There will be some functions which still need to be performed outside of the group (granting of privileges). These functions can still fail. The GKMP will operate on the old set of permissions. These functions need not be in-line. They are performed separate from the key management actions and are not crucial to day-to-day operation.
GKMPは、グループへのできるだけ多くの機能を代表として派遣するのを試みるでしょう。 まだグループ(特権を与える)の外で実行される必要があるいくつかの機能があるでしょう。 これらの機能はまだ失敗できます。 GKMPは古い許容を作動させるでしょう。 これらの機能はインラインである必要はありません。 それらは、かぎ管理動作から別々の状態で実行されて、日常業務に重要ではありません。
2.3.8 Security
2.3.8 セキュリティ
People are the most risky element for security. A distributed protocol eliminates many people from the key distribution chain. This limits "exposure" of the key.
人々はセキュリティのための最も危険な要素です。 分配されたプロトコルは主要な流通網から多くの人々を排除します。 これはキーの「暴露」を制限します。
3 GKMP Protocol Overview
3GKMPプロトコル概要
3.1 Supporting functions
3.1 機能をサポートすること。
A secure key management protocol needs a number of supporting functions, especially in a military environment. The two major support functions are security management and network group management. In the commercial world a company could provide these support functions.
安全なかぎ管理プロトコルは特に軍事環境における多くのサポート機能を必要とします。 2つの主要な支援機能が、セキュリティ管理とネットワーク集団経営です。 商業界に、会社はこれらの支援機能を提供できました。
The issue of Security Management is permission management, in a military environment separation of data occurs along classical classification lines (i.e., TOP SECRET to UNCLASSIFIED). In the commercial world these levels are proprietary or need to know access.
Security Managementの問題が許可管理である、データの軍事環境分離では、(すなわち、UNCLASSIFIEDへのTOP SECRET)は古典的な分類系列に沿って起こっています。 商業界では、これらのレベルは、独占である、またはアクセサリーを知る必要があります。
Network group management provides an interface to the communications system and control of network resources. Some entity either a commercial or military system, the host or network operations center,
ネットワーク集団経営はネットワーク資源の通信網とコントロールにインタフェースを供給します。 コマーシャルか軍用システムのどちらか、ホストまたはネットワーク操作が中心に置く何らかの実体
Harney & Muckenhirn Experimental [Page 9] RFC 2094 GKMP Architecture July 1997
[9ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
must provide the key management protocol with a list of the group members. Also, if the network resources, bandwidth and processing, are considered scarce a management structure must allocate them.
グループのメンバーのリストをかぎ管理プロトコルに提供しなければなりません。 また、ネットワーク資源(帯域幅と処理)が不十分であると考えられるなら、経営組織はそれらを割り当てなければなりません。
3.1.1 Security management
3.1.1 セキュリティ管理
Security management is a role performed for the entire network. It involves netwide issues of permission management, initialization of software, and compromise recovery. The GKMP relies on security management to operate. Refer to figure 1: Security management view.
セキュリティ管理は全体のネットワークのために実行された役割です。 それは許可管理のnetwide問題、ソフトウェアの初期化、および感染回復にかかわります。 GKMPは、作動するためにセキュリティ管理に依存します。 1について計算するには、参照してください: 経営者側が見るセキュリティ。
The GKMP must assume trusted handling of the protocol software prior and during installation. If the GKMP is to use peer to peer access control the system must control the assignment of permissions. These permissions must be monitored and updated as needed. Finally, overview of these permissions must include the maintenance of a Certificate Revocation List.
GKMPは優先的とインストールの間、プロトコル・ソフトウエアの信じられた取り扱いを仮定しなければなりません。 GKMPがピアツーピアアクセスコントロールを使用するつもりであるなら、システムは許容の課題を制御しなければなりません。 必要に応じてこれらの許容をモニターして、アップデートしなければなりません。 最終的に、これらの許容の概要はCertificate Revocation Listのメインテナンスを含まなければなりません。
Secure start-up We need to control the process of loading GKMP software onto a host and initializing it. The protocol needs keys,
安全な始動Weは、ローディングGKMPソフトウェアのプロセスをホストとそれを初期化するのに制御する必要があります。 プロトコルはキーを必要とします。
Security Manager --> --> --> --> --> --> --> --> --> --> --> Network
Permissions
Secure Start-ups
Compromise recovery
セキュリティマネージャ-->-->-->-->-->-->-->-->-->-->-->はCompromise回復をNetwork Permissions Secure Start上げます。
Figure 1: Security Management View
図1: セキュリティ管理視点
public and private, to operate. It also must have identify information of the host on whose behalf it will act.
公共であって、個人的である、操作するために。 また、それで、だれの代理を行動させるかに関してホストの情報を特定しなければなりません。
There are some life cycle and security concerns with the software while in transit, stored, distributed, and installed. A one time start-up procedure must verify the identity of the host. Procedural and physical identification techniques will verify the identity of the host (i.e., the Armed Forces Courier Service (ARFCS) accounting, or registered mail). Upon key delivery the security manager logs it's receipt and assumes responsibility for the key.
トランジットにはある間、保存されて、分配されて、インストールされて、ソフトウェアがあるいくつかのライフサイクルと安全上の配慮があります。 1つの時間始動手順がホストのアイデンティティについて確かめなければなりません。 手続き上的、そして、物理的な識別のテクニックはホスト(すなわち、軍伝書使部(ARFCS)の会計、または書留)のアイデンティティについて確かめるでしょう。 セキュリティマネージャが登録する主要な配送のときに、それは、領収書であり、キーへの責任を負います。
After proper installation of the software a paper trail verifies the recipient. The computer would initiate an association with the security management function to initialize the protocol software (create a unique public and private key pair for network operation and receive network permissions). This activation process uses keys distributed with the software (good only for initialization) to secure an exchange with the security manager. The host then creates a unique public and private pair and sends the public key to the
ソフトウェアの適切なインストールの後に、ペーパートレールは受取人について確かめます。 コンピュータは、プロトコル・ソフトウエア(ネットワーク操作のためにユニークな公衆と秘密鍵組を創設して、ネットワーク許容を受ける)を初期化するためにセキュリティ管理機能との協会を開始するでしょう。 この活性化過程はソフトウェア(初期化だけに、良い)で分配された、セキュリティマネージャと共に交換を保証したキーを使用します。 ホストは、次に、ユニークな公共の、そして、私設の組を創設して、公開鍵を送ります。
Harney & Muckenhirn Experimental [Page 10] RFC 2094 GKMP Architecture July 1997
[10ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
security manager. The security manager creates a credential that uniquely identifies the host and it permissions. This credential is signed by the security management with its private key and can be verified by all net members with the public key.
セキュリティマネージャ。 セキュリティマネージャは唯一ホストとそれを特定する資格証明書を作成します。許容。 この資格証明書にセキュリティ経営者側が秘密鍵で署名して、すべてのネットのメンバーが公開鍵で確かめることができます。
Permission management Each host on the network is given a permissions certificate signed by the security management which uniquely identify that host and identifies the access permissions it is allowed. These permission certificates are used by the network hosts to assign permissions to other hosts.
Eachがネットワークで主催する許可経営者側は、唯一そのホストを特定するセキュリティ経営者側によって署名された許容証明書を与えて、それが許容されているアクセス許容を特定します。 これらの許可証明書は、他のホストに許容を割り当てるのにネットワークホストによって使用されます。
This process assigns permissions to equipment or human beings in accordance with their duties. This process involves security clearances and human judgment therefore it is outside the scope of this protocol.
彼らの義務に従って、このプロセスは設備か人間に許容を割り当てます。 このプロセスは機密取扱者の人物調査と人間の判断にかかわります、したがって、このプロトコルの範囲の外にそれはあります。
The security management function, especially in military operations, would be responsible for managing permissions and classifications at each host. In the commercial world, permission management corresponds to projects or duties.
特に軍事行動では、セキュリティ管理機能は各ホストで許容と分類を管理するのに原因となるでしょう。 商業界では、許可管理がプロジェクトか義務に対応しています。
Compromise recovery management If a group member is found compromised, the protocol must facilitate the exclusion of the compromised member and return to secure operations. The security management function will provide control of compromise recovery.
グループのメンバーが見つけられる感染回復管理Ifが妥協して、プロトコルは感染しているメンバーの除外を容易にして、戻って、操作を保証しなければなりません。 セキュリティ管理機能は感染回復のコントロールを提供するでしょう。
Usually, physical inspections or accounting techniques find compromises. These separate systems report the compromise to the key management system. We must assume the loss of all key resident at that host. The security management function will rescind the permission allocated to this compromised host. We create a list of all know compromised hosts and distribution that list across the network. Each host is then responsible for reviewing the propriety of each association and enforcing access control to data.
通常、実査か会計技術が感染に当たります。 これらの別々のシステムはかぎ管理システムに感染を報告します。 私たちはそのホストのすべての主要な居住者の損失を仮定しなければなりません。 セキュリティ管理機能はこの感染されたホストに割り当てられた許可を無効にするでしょう。 私たちはネットワークの向こう側に記載するホストと分配であると感染されて、すべてのリストが知っているaを作成します。 それぞれのホストはその時、それぞれの協会の礼節を見直して、アクセスコントロールをデータに実施するのに責任があります。
3.1.2 Group management
3.1.2 集団経営
The group manager interacts with other management functions in the network to provide the GKMP with group membership lists and group relevant commands. The GKMP deals strictly with cryptographic key. It relies on external communication and network management services to supply network related information. Primarily, it relies on the network management service to provide it with the addresses of group members (if the group is sender initiated).
グループのマネージャは、グループ会員名簿をGKMPに提供して、関連コマンドを分類するためにネットワークで他の管理機能と対話します。 GKMPは厳密に暗号化キーに対処します。 それは外部コミュニケーションを当てにします、そして、供給するネットワーク管理サービスは関連する情報をネットワークでつなぎます。 主として、それは、グループのメンバーのアドレスをそれに提供するためにネットワーク管理サービスに依存します(グループが開始された送付者であるなら)。
Harney & Muckenhirn Experimental [Page 11] RFC 2094 GKMP Architecture July 1997
[11ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
The GKMP allows an external entity to determine the controller of a group. The controller of the group should be able to handle the additional processing and communication requirements associated with the role. If this is not a necessary function given the implementation, this assignment of controller duties can be set to some automated default. However, even if defaulted some external management entity determines how the role of controller is allocated.
GKMPは外部実体にグループのコントローラを決定させます。 グループのコントローラは追加処理と役割に関連しているコミュニケーション要件を扱うはずであることができます。 実装を考えて、これが必要な機能でないなら、コントローラ義務のこの課題を何らかの自動化されたデフォルトに設定できます。 しかしながら、デフォルトとしても、何らかの外部の経営体が、コントローラの役割がどのように割り当てられるかを決定します。
The group manager can receive group progress reports from the group controller. The GKMP provides a service for the network. It makes sense that someone in the network is interested in the progress of this service. The GKMP can provide progress reports. It is up to the network management to determine the manner and recipient of the reports. Reference figure 2: Network manager interaction.
グループのマネージャはグループコントローラからグループ経過報告書を受け取ることができます。 GKMPはサービスをネットワークに提供します。 ネットワークにおけるだれかがこのサービスの進行中に興味を持っているのは理解できます。 GKMPは経過報告書を提供できます。 レポートの方法と受取人を決定するのはネットワークマネージメントまで達しています。 参照は2について計算します: ネットワークマネージャ相互作用。
Group Manager --> --> --> --> --> --> --> --> -->Network Manager
/\
|
| Commands, Role assignments
| Group member list, Reports
|
\/
{[Group Controller] Network}
グループのマネージャ-->-->-->-->-->-->-->-->-->ネットワークマネージャ/\| | コマンド、Role課題| グループメンバーリスト、Reports| \/ [グループコントローラ]ネットワーク
Figure 2: Network Manager Interaction
図2: ネットワークマネージャ相互作用
Group to member mapping When the GKMP is implemented in sender initiated group establishment mode, a list of group member addresses must be provided as part of the group establishment command. The GKMP will use these addresses to contact the group members and create the group.
GKMPが送付者の開始しているグループ設立モードで実装されるメンバーマッピングWhenへのグループ、グループ設立命令の一部としてグループメンバーアドレスのリストを提供しなければなりません。 GKMPは、グループのメンバーに連絡して、グループを創設するのにこれらのアドレスを使用するでしょう。
The creation of groups involves the assignment of a group address, update of router databases, and distribution of this group address to the group members. This is a classic function of network management. The GKMP group controller would be another recipient of this information.
グループの創設はグループアドレスの課題、ルータデータベースのアップデート、およびこのグループアドレスの分配にグループのメンバーにかかわります。 これはネットワークマネージメントの古典的な機能です。 GKMPグループコントローラはこの情報の別の受取人でしょう。
Protocol role allocation The Group Management Protocol assigns roles to members of a particular group. These roles are binary one is either the control over the group or a member of a group. Some external entity will allocate the identity of the group controller and group receiver. This is a desirable aspect because some computers are more capable (i.e., central site, great deal of process power available to control a group). We allow some external entity to allocate these roles to individual group members, this is important in the military application do to the fact that in a
Group Managementプロトコルが役割を割り当てる役割の配分について特定のグループのメンバーに議定書の中で述べてください。 これらの役割は2進のものがグループのコントロールかグループのメンバーのどちらかであるということです。 何らかの外部実体がグループコントローラとグループ受信機のアイデンティティを割り当てるでしょう。いくつかのコンピュータが、よりできるので(すなわち、主要なサイト、グループを制御するために利用可能なプロセスパワーのかなりの取引)、これは望ましい局面です。 私たちは何らかの外部実体に個々のグループのメンバーにこれらの役割を割り当てさせて、これは軍事利用がそんなに中で事実にする重要なコネです。
Harney & Muckenhirn Experimental [Page 12] RFC 2094 GKMP Architecture July 1997
[12ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
commercial application the allocating authority and group controller may very well always be the same.
市販のアプリケーション、割り当て権威とグループコントローラはいつも非常によく同じであるかもしれません。
Group key progress reporting The Group Key Management Protocol has to be able to report to somebody. If we create a group, we should report it to group requester. Contrarily if we are not able to
Group Key Managementプロトコルを報告するグループキー進歩はだれかに報告できなければなりません。 グループを創設するなら、私たちは、それがリクエスタを分類すると報告するべきです。 反対である、私たちはできません。
Network = {[(Group 1 controller) Group 1 members],
[(Group 2 controller) Group 2 members],
[(Group 3 controller) Group 3 members], }
ネットワーク=[(1台のコントローラを分類します)グループの1人のメンバー]、[(2コントローラを分類します)グループの2人のメンバー][3人のメンバーを分類します(3コントローラを分類します)]
Figure 3: Distributed Group Management
図3: 分配された集団経営
create a group we should report that especially since failure to create a group at least as a first study will highly correlate with a failure of the underlying communications. The Group Key Management Protocol does not have an ability to fix the underlying communications so the communication management function must deal with these failures.
私たちが報告するべきであるグループを創設してください。それは、特に少なくとも第1としてグループを創設しない場合研究するので、基本的なコミュニケーションの失敗と非常に互いに関連するでしょう。 Group Key Managementプロトコルには基本的なコミュニケーションを修理する能力がないので、コミュニケーション管理機能はこれらの失敗に対処しなければなりません。
3.2 Protocol Roles
3.2 プロトコルの役割
Creation and distribution of grouped key require assignment of roles. These identify what functions the individual hosts perform in the protocol. The two primary roles are those of controller and receiver. The controller initiates the creation of the key, forms the key distribution messages, and collects acknowledgment of key receipt from the receivers. The receivers wait for a distribution message, decrypt, validate, and acknowledge the receipt of new key.
分類されたキーの作成と分配は役割の課題を必要とします。 これらは、個々のホストがプロトコルでどんな機能を実行するかを特定します。 2つのプライマリ役割がコントローラと受信機のものです。コントローラは、キーの作成を開始して、主要な分配メッセージを形成して、受信機から主要な領収書の承認を集めます。 新しいキーの領収書は、受信機が分配メッセージを待つと解読して、有効にして、認めます。
One of the essential concepts behind the GKMP is delegation of group control. Since each host in the network has the capability to act as a group controller, the processing and communication requirements of controlling the groups in the network can be distributed equitably throughout the network. This avoids potential single points of failure, communication congestion, and processor overloading. Refer to figure 3: Distributed group management.
GKMPの後ろの不可欠の概念の1つは集団経営の委譲です。 以来、ネットワークの各ホストには、行動する能力がネットワーク中に公正にネットワークでグループを制御するグループコントローラ、処理、およびコミュニケーション要件を広げることができるようにあります。 これは潜在的単一のポイントの失敗、コミュニケーション混雑、およびプロセッサ積みすぎを避けます。 3について計算するには、参照してください: 分配された集団経営。
3.2.1 Group controller
3.2.1 グループコントローラ
The group controller is the a group member with authority to perform critical protocol actions (i.e., create key, distribute key, create group rekey messages, and report on the progress of these actions). All group members have the capability to be a group controller and could assume this duty upon assignment.
グループコントローラは重要なプロトコル動作を実行する権威があるaグループのメンバー(すなわち、キーを作成してください、そして、キーを分配してください、そして、グループrekeyメッセージを作成してください、そして、これらの動作の進歩に関して報告する)です。 すべてのグループのメンバーが、グループコントローラである能力を持って、課題のときにこの義務を引き受けることができました。
Harney & Muckenhirn Experimental [Page 13] RFC 2094 GKMP Architecture July 1997
[13ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
The group controller helps the cryptographic group reach and maintain key synchronization. A group must operate on the same symmetric cryptographic key. If part of the group loses or inappropriately changes it's key, it will not be able to send or receive data to another host operating on the correct key. Therefor, it is important that those operations that create or change key are unambiguous and controlled (i.e., it would not be appropriate for multiple hosts to try to rekey a net simultaneously).
グループコントローラは、暗号のグループが主要な同期に達して、維持するのを助けます。 グループは同じ左右対称の暗号化キーを運用しなければなりません。 グループの一部が損をするか、または不適当に変化するなら主要である、それは正しいキーを作動させる別のホストに、データを送ることができませんし、受け取ることができないでしょう。 そのために、キーを作成するか、または変えるそれらの操作が明白で制御されているのは(すなわち、複数のホストが同時にrekeyにネットを試みるのは、適切でないでしょう)、重要です。
3.2.2 Group receiver
3.2.2 グループ受信機
Simply stated a group receiver is any group member who is not acting as the controller. The group receivers will: assist the controller in creating key, validate the controller authorization to perform actions, accept key from the controller, request key from the controller, maintain local CRL lists, perform peer review of key management actions, and manage local key.
単に、グループ受信機がコントローラとして務めていないあらゆるグループのメンバーであると述べました。 グループ受信機はそうするでしょう: コントローラ承認を有効にして、動作を実行してください、キーを作成するのにコントローラを助けてください、そして、コントローラからキーを受け入れてください、そして、コントローラからキーを要求してください、そして、ローカルのCRLリストを維持してください、そして、かぎ管理動作の同輩レビューを実行してください、そして、地方のキーを管理してください。
3.3 Scenarios
3.3 シナリオ
3.3.1 Group establishment
3.3.1 グループ設立
The protocol to establish a group of host that share a cryptographic key must create a high quality key, verify that all intended recipients have permission to join the group, distribute the key to all qualified members, and report on the progress. This process consists of two phases: creation of the key and distribution of the key. Refer to figure 4: Group Establishment.
暗号化キーを共有するホストのグループを確立するプロトコルは高品質のキーを作成しなければなりません、そして、すべての意図している受取人にはグループに加わる許可があることを確かめてください、そして、すべての適任のメンバーのキーを分配してください、そして、進歩に関して報告してください。 このプロセスは二相から成ります: キーの作成とキーの分配。 4について計算するには、参照してください: 設立を分類してください。
The group establishment process is proceeds in the following manner. First, a "create group" command is issued to the group commander. The group controller validates the command to ensure it came from an authorized commander and the group is within the controller's permission range. Next, the controller creates a key. Then that key is passed to the group members, after they pass the peer to peer review process.
グループ設立プロセスは以下の方法で売り上げです。 まず最初に、「グループを創設してください」というコマンドをグループ指揮官に発行します。 グループコントローラはそれが認可された指揮官から来たのを保証するコマンドを有効にします、そして、コントローラの許可範囲の中にグループがあります。 次に、コントローラはキーを作成します。 そして、彼らがピアツーピア吟味の過程を通過した後にそのキーはグループのメンバーに渡されます。
Harney & Muckenhirn Experimental [Page 14] RFC 2094 GKMP Architecture July 1997
[14ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
Group Controller
|
|
\/ Create group keys
|--> --> --> --> --> --> -->Group member
|
|
\/ Distribute keys
|--> --> --> --> --> --> --> Group member
|
|
\/ Distribute keys
|--> --> --> --> --> --> --> Group member
|
|
\/ Distribute keys
|--> --> --> --> --> --> --> Group member
グループコントローラ| | \/はグループキーを作成します。|-->-->-->-->-->-->-->グループのメンバー| | \/はキーを分配します。|-->-->-->-->-->-->-->グループのメンバー| | \/はキーを分配します。|-->-->-->-->-->-->-->グループのメンバー| | \/はキーを分配します。|-->-->-->-->-->-->-->グループのメンバー
Figure 4: Group Establishment
図4: グループ設立
Validate command The create group command is signed by the group commander ( they may be the same device). This signature should be asymmetric in nature. The public key to validate this command can be sent with the command itself, if the public bound to the identity of the commander.
コマンドを有効にしてください、コマンドがグループ指揮官によって調印されるグループを創設してください(それらは同じデバイスであるかもしれません)。 この署名は現実に非対称であるべきです。 コマンド自体と共にこのコマンドを有効にする公開鍵を送ることができます、公衆が指揮官のアイデンティティにバウンドするなら。
The group controller receives the command. It verifies that the signature, thereby ensuring the message was sent by the claimed source and the message has not been modified in transit.
グループコントローラはコマンドを受け取ります。 それは、署名、その結果、メッセージを確実にするのが要求されたソースによって送られて、メッセージがトランジットで変更されていないことを確かめます。
Creation of group keys The controller initiates the creation of two keys for use in the group. The creation of a cryptographic key requires that the key be sufficiently random. Randomizers, capable of creating high grade cryptographic key, tend to be hardware based and are not likely to be practical for this protocol. There are several established key creation protocols based in software (e.g., Diffe-Hellman, FireFly, RSA). All these software based algorithms involve two hosts cooperating to create a cryptographic key. These software algorithms are more appropriate for this protocol.
グループの創設はコントローラ開始のためにグループにおける使用のための2個のキーの作成を合わせます。 暗号化キーの作成は、キーが十分無作為であることを必要とします。 高いグレード暗号化キーを作成できる無作為抽出装置は、基づくハードウェアである傾向があって、このプロトコルに実用的である傾向がありません。 ソフトウェア(例えば、Diffe-ヘルマン、FireFly、RSA)に基づくいくつかの確立した主要な作成プロトコルがあります。 これらのソフトウェアに基づいているすべてのアルゴリズムが、協力して、暗号化キーを作成しながら、2人のホストを伴います。 このプロトコルには、これらのソフトウェアアルゴリズムは、より適切です。
Also important, in the creation of these keys, is verification of the authorization of the key creation partner. Authorization to posses the keys include permissions that equal or exceed the group traffic and identity verification.
また、これらのキーの作成で重要であるのは、主要な作成パートナーの承認の検証です。 承認、武装隊に、キーはグループトラフィックとアイデンティティ検証を等しい、または超えている許容を含めます。
Harney & Muckenhirn Experimental [Page 15] RFC 2094 GKMP Architecture July 1997
[15ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
Distribution of group keys The controller distributes the group keys to the net members. The controller must verify the identity and permissions of each member prior to the key being distributed.
グループの分配はコントローラを合わせます。ネットのメンバーのグループキーを分配します。 分配されていて、コントローラはキーの前でそれぞれのメンバーのアイデンティティと許容について確かめなければなりません。
Rekey Group
Group Controller --> --> --> --> --> -->{Group (group member 1-n)}
Rekeyグループグループコントローラ-->-->-->-->-->-->。(グループのメンバー1-n)を分類してください。
Figure 5: Group Rekey
図5: グループRekey
Likewise, the net member must verify the controller's identity, authorization to perform this action, and permissions.
同様に、ネットのメンバーは、この動作、および許容を実行するためにコントローラのアイデンティティ、承認について確かめなければなりません。
The key being distributed is the same level as the data that it will encrypt. Hence, we must encrypt the key during distribution. If no suitable key exists between the controller and member, a new key must be created. This new key is cooperatively created between the controller and net member in a similar manner as the net keys.
分配されるキーはそれが暗号化するデータとして平らな状態で同じです。 したがって、私たちは分配の間、キーを暗号化しなければなりません。 どんな適当なキーもコントローラとメンバーの間に存在していないなら、新しいキーを作成しなければなりません。 この新しいキーは同じようにネットのキーとしてコントローラとネットのメンバーの間で協力して作成されます。
The controller creates a message for encryption in the key held between the controller and member. This message will include key management information and the keys.
コントローラはコントローラとメンバーで握られるかぎで暗号化へのメッセージを作成します。 このメッセージは主要な経営情報とキーを含むでしょう。
3.3.2 Group rekey
3.3.2 グループrekey
Cryptographic key has a life span. New key must replace "old" key prior to the end of its cryptographic life. This process is rekey.
暗号化キーには、寿命があります。 新しいキーは暗号の寿命の終わりまでに「古い」キーを取り替えなければなりません。 このプロセスはrekeyです。
Rekey has the advantage of using an existing cryptographic association to distribute key. Also, there is no requirement to verify the identity and authorization for the other members. Identify and authorization are assumed.
Rekeyには、キーを分配する既存の暗号の協会を使用する利点があります。 また、他のメンバーのためにアイデンティティと承認について確かめるという要件が全くありません。 そして、特定、承認は想定されます。
A group rekey consists of two stages. First the Group Controller creates new group keys. Second these "new" keys are sent to the Group Members in a multicast message. Refer to figure 5: Group Rekey.
グループrekeyは2つのステージから成ります。 まず最初に、Group Controllerは新しいグループキーを作成します。 これらの「新しい」キーがマルチキャストメッセージのGroupメンバーに送られる秒。 5について計算するには、参照してください: Rekeyを分類してください。
Creation of group keys The controller of the rekey will create the new keys in exactly the same manner as used during group establishment.
rekeyのコントローラがそうするグループキーの作成はまさにグループ設立の間に使用されるのと同じ方法で新しいキーを作成します。
Harney & Muckenhirn Experimental [Page 16] RFC 2094 GKMP Architecture July 1997
[16ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
Distribution of group keys The GKMP creates a message for the group address. This message uses one of the keys distributed during group establishment to encrypt the new keys. It also contains an authorization token identifying the controller as the rekey agent and new management data. All members of the group using a multicast protocol (if one exists) accept this message.
グループの分配はGKMPを合わせます。グループアドレスへのメッセージを作成します。 このメッセージは新しいキーを暗号化するためにグループ設立の間に分配されたキーの1つを使用します。 また、それはコントローラがrekeyエージェントであると認識する承認トークンと新しい管理データを含んでいます。 マルチキャストプロトコル(1つが存在しているなら)を使用するグループのすべてのメンバーがこのメッセージを受け入れます。
The message which rekeys the group encrypts the new keys in the existing KEK. Since all group members possess the KEK the entire group can decrypt this message.
グループを「再-合わせ」るメッセージは既存のKEKで新しいキーを暗号化します。 すべてのグループのメンバーがKEKを所有しているので、全体のグループはこのメッセージを解読することができます。
The token authorizing the group controller to perform this rekey is also included. This token is asymmetrically signed by the group commander. It uniquely identifies the group controller's authority to rekey this group. It also identifies the group the level of traffic and rekey interval.
また、グループコントローラがこのrekeyを実行するのを認可するトークンは含まれています。 このトークンはグループ指揮官によって非対称的に署名されます。 それは唯一これが分類するrekeyへのグループコントローラの権威を特定します。 また、それはグループを特定します。トラフィックのレベルとrekey間隔。
3.3.3 Deletion
3.3.3 削除
It is desirable to be able to delete group members for either administrative purposes or security reasons. Administrative deletion is the deletion of a trusted group member. It is possible to confirm the deletion of trusted group members. Security relevant deletion is the deletion of an untrusted member. It assumes that the member is ignore all deletion commands.
管理目的かセキュリティ理由のどちらかでグループのメンバーを削除できるのは望ましいです。 管理削除は信じられたグループのメンバーの削除です。 信じられたグループのメンバーの削除を確認するのは可能です。 セキュリティの関連削除は信頼されていないメンバーの削除です。 それは、メンバーがすべての削除命令を無視することであると仮定します。
Administrative delete Administrative deletion removes the group keys from trusted group members. This deletion consists of two messages the first sends a command to the group encrypted in the groups TEK. The command essentially says: acknowledge receipt and then delete group keys. This command is signed by the group controller to prevent unauthorized deletions.
Administrative削除を削除してください。管理、信じられたグループのメンバーからグループキーを取り外します。 この削除は1番目がグループTEKで暗号化されたグループへのコマンドを送る2つのメッセージから成ります。 コマンドは本質的には言います: 領収書を受け取ったことを知らせてください、そして、次に、グループキーを削除してください。 このコマンドは、権限のない削除を防ぐためにグループコントローラによって調印されます。
The acknowledgment message is also encrypted under the group TEK and is sent to acknowledge receipt of the command. We could acknowledge accomplishment of the command if the net is willing to accept the burden of creating pairwise keys between the exiting group members and the group controller.
承認メッセージをまた、グループTEKの下で暗号化して、コマンドの領収書を受け取ったことを知らせるために送ります。 ネットが、出ているグループのメンバーとグループコントローラの間で対状キーを作成する負担を受け入れても構わないと思っているなら、私たちはコマンドの達成を承諾するかもしれません。
Compromise recovery Compromise recovery is the deletion of untrusted group members. This actually involves the creation of an entirely new group, without the untrusted member. Once the new group is created, net operations can be shifted to the new group, effectively denying the untrusted member access to the data.
感染回復Compromise回復は信頼されていないグループのメンバーの削除です。 これは実際に信頼されていないメンバーなしで完全に新しいグループの創設にかかわります。 新しいグループがいったん創設されると、ネットの操作は新しいグループに移行できます、事実上、信頼されていないメンバーデータへのアクセスを否定して。
Harney & Muckenhirn Experimental [Page 17] RFC 2094 GKMP Architecture July 1997
[17ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
There is always a trade-off between security and continued net operations when a member is found to be compromised. The security first position states that if a member is compromised, the group must be destroyed and then a new secure group created. However, operational concerns sometimes out weigh the security concerns. The operational position is that the group will continue to operate with the compromised member and will shift to a new secure group when it becomes available.
メンバーが感染されるのがわかっているとき、セキュリティと継続的なネットの操作の間には、トレードオフがいつもあります。 セキュリティ第1ポジションは、メンバーが感染されるなら、グループが破壊されていて次に、創設された新しい安全なグループであるに違いないと述べます。 しかしながら、時々、アウトは安全上の配慮の重さがあるという操作上の関心。 操作上の位置は、グループが、感染しているメンバーと共に作動し続けるということであり、利用可能になると、新しい安全なグループに移行するでしょう。
The GKMP does not mandate either position. However, the speed and flexibility of the GKMP does allow a new secure group to be created quickly. Thereby, restricting the potential damage done by a compromised member.
GKMPは位置を強制しません。 しかしながら、GKMPの速度と柔軟性は、新しい安全なグループがすぐに創設されるのを許容します。 その結果、感染しているメンバーによって行われた可能性のあるダメージを制限します。
Once a member is found to be compromised, that members certificate is added to a Certificate Revocation List (CRL). The CRL is an asymmetrically signed piece of data, signed by a security manager. The list is made up of compromised resource ID's, a version of the CRL, and perhaps an identifier of the security manager. The CRL is accessed every time a new key is negotiated. If one of the key creators is on the CRL the key is destroyed and interaction terminated.
メンバーが感染されるのがいったんわかっていると、そのメンバー証明書はCertificate Revocation List(CRL)に加えられます。 CRLはセキュリティマネージャによって署名された非対称的に署名している片のデータです。 リソースであると感染されて、リストを上がるようにします。ID、CRLのバージョン、および恐らくセキュリティマネージャの識別子。 新しいキーが交渉されるときはいつも、CRLはアクセスされています。 主要なクリエイターのひとりがCRLにいるなら、キーは破壊されました、そして、相互作用は終わりました。
The idea behind a CRL is each host would keep records of all open associations and compromised resources. The host would then make sure that it does not have and will not create a secure association open with anyone who is on the CRL. The CRL concept of becomes more complicated in the case of groups. This is because it is not necessary for every member in the group to know who the other group members are. Hence, a group member does not have sufficient information to identify compromised group associations. The GKMP proposes that the group controllers be responsible for reviewing the CRL and taking appropriate actions should a group member be compromised.
CRLの後ろの考えは各ホストがすべての開いている協会と感染しているリソースに関する記録をつけるだろうということです。 そして、ホストはそれがCRLにいる人はだれと共にもa安全な協会戸外を作成しないために持っていて、望んでいないのを確実にするでしょう。 CRL概念、グループの場合で、より複雑になります。 これはグループのすべてのメンバーが、他のグループのメンバーがだれであるかを知るのは必要でないからです。 したがって、グループのメンバーには、感染しているグループ協会を特定できるくらいの情報がありません。 GKMPは、グループコントローラがグループのメンバーが感染されるなら、CRLを見直して、適切な行動を取るのに責任があるよう提案します。
Another issue with CRLs is the speed that they can be distributed across a network. Every time a key is created the cooperating hosts exchange the version number of their current CRL. If the versions do not match. The most current version is passed to the host with the old version. Hence, CRLs propagate when keys are created. If this is infrequently and there is a single CRL insertion point, the list may take a few days to move across the net. The GKMP allows a speedier distribution of the CRL.
CRLsの別の問題はネットワークの向こう側の分配されていて、彼らがそうすることができる速度です。 キーが作成されるときはいつも、協力関係を持っているホストは彼らの現在のCRLのバージョン番号を交換します。 バージョンが合っていないなら。 最新版は古いバージョンでホストに渡されます。 キーが作成されるとき、したがって、CRLsは伝播します。 これがまれにそうであり、単一のCRL挿入ポイントがあって、リストがネットの向こう側に移行するには数日かかるかもしれないなら。 GKMPはCRLの、より迅速な分配を許します。
The GKMP delegates control of groups to specific group controllers (a subset of the network). These controllers are responsible for maintaining the security of the group. If quicker distribution of the CRL were desired, the CRL generator ( security management
特定のグループコントローラ(ネットワークの部分集合)へのグループのGKMP代表コントロール。 これらのコントローラはグループのセキュリティを維持するのに責任があります。 より迅速であるならCRLの分配が望まれていて、CRLがジェネレータである、(セキュリティ管理
Harney & Muckenhirn Experimental [Page 18] RFC 2094 GKMP Architecture July 1997
[18ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
function could seed the CRL at these controllers. Controllers are points of key management activity and are logical CRL staging areas.
機能はこれらのコントローラをCRLに種を蒔くかもしれません。 コントローラは、ポイントのかぎ管理活動であり、領域を上演する論理的なCRLです。
4 Issues
4冊
What are the unresolved issues with this protocol?
このプロトコルがある未解決問題は何ですか?
4.1 Access Control
4.1 アクセスコントロール
One interesting issue with a grouped key protocol is access control. This is because we are moving away from having humans in the loop or having a central authority to check the propriety of the group.
分類された主要なプロトコルのおもしろい1冊はアクセスコントロールです。 これは私たちが人間が輪にいるか、またはグループの礼節をチェックする主要な権威を持つのから遠くに移行しているからです。
The group protocol must police itself. It must ensure that each member of a group meets the classic military access control policy ( i.e., a group member`s classification level must be higher or equal to the classification of the group that it's in).
グループプロトコルは自分を管理しなければなりません。 それは、グループの各メンバーが古典的な軍事のアクセス制御方針を満たすのを確実にしなければなりません(すなわち、グループのメンバーの分類レベルは、それがあるグループの分類と、より高いか、または等しいに違いありません)。
Is allocation of permissions by a higher authority sufficient to provide access control? Or is a more discretionary mechanism necessary?
アクセスコントロールを提供できるくらいの、より高い権威による許容が配分がありますか? または、より任意のメカニズムが必要ですか?
4.2 MLS
4.2 MLS
A GKMP must be capable of operating in a multi-level secure environment. The integration of a key management protocol capable of creating keys of several different classifications with an operating system capable of operating with multiple classifications in non- trivial.
GKMPはマルチレベル安全な環境で作動できなければなりません。 中に多重分類がある状態で非些細なオペレーティングシステムが作動だったことできる状態でいくつかの異なった分類のキーを作成できるかぎ管理プロトコルの統合。
Classified label standards needed to be incorporated. The classification labels used by the key management protocol should coincide with the labels used by the MLS operating system. These interoperability issues need to be addressed.
分類されたラベル規格は、法人組織である必要がありました。 ラベルがMLSオペレーティングシステムで使用されている状態で、かぎ管理プロトコルによって使用される分類ラベルは一致するはずです。 これらの相互運用性問題は、扱われる必要があります。
4.3 Error Conditions
4.3 エラー条件
A group protocol is more complex than a pairwise protocol hence there are more possible error conditions. In a pairwise protocol you have two parties; they must communicate between themselves. It is relatively simple to define an take care of all the potential error conditions.
グループプロトコルは対状プロトコルより複雑です、したがって、より可能なエラー条件があります。 対状プロトコルでは、あなたは2回のパーティーを開きます。 彼らは自分たちの間で交信しなければなりません。 撮影を定義するのは比較的簡単です。すべての潜在的エラー条件の注意。
Harney & Muckenhirn Experimental [Page 19] RFC 2094 GKMP Architecture July 1997
[19ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
One assumption with any group protocol is the underlying internet is, to some degree, always broken. The protocol designer has to assume that messages will be delayed or destroyed in transit, all member will not receive all multicast messages, and acknowledgment of actions may not be delivered. This assumption is important if a protocol uses multicast functions to speed-up actions.
どんなグループプロトコルによる1つの仮定も基本的なインターネットがある程度いつも壊れているということです。 プロトコルデザイナーは、メッセージがトランジットで遅らせられるか、または無効にされて、すべてのメンバーがすべてのマルチキャストメッセージを受け取るというわけではなくて、動作の承認が提供されないかもしれないと仮定しなければなりません。 プロトコルが動作を早くするのにマルチキャスト機能を使用するなら、この仮定は重要です。
The protocol must provide recovery mechanisms to allow group members to recover from loss of messages. It must recover in a way that is transparent to the host and underlying communications network.
プロトコルはグループのメンバーがメッセージの損失から回復するのを許容する回収機構を提供しなければなりません。 それはホストにとって、見え透いた方法と基本的な通信網で回復しなければなりません。
For example, there is an issue whether or not we can create an application layer acknowledgment of multi-cast actions. The issue deals with the required bandwidth that acknowledgment would take up. It may be much more friendly to the underlying communications systems to have each member identify potential errors and correct them in a pairwise manner. The task of handling error conditions in a key management protocol is double difficult because many error conditions can be induced error condition (invoked by a third party trying to break the security of that system) to retrieve there key that is in transit or to block the successful dissemination of a key thereby attacking the system security mechanism.
例えば、私たちがマルチキャスト動作の応用層承認を作成できるか否かに関係なく、問題があります。 問題は承認が取る必要な帯域幅に対処します。 各メンバーが潜在的誤りを特定して、対状方法でそれらを修正するのを持っているのは基本的な通信網にはるかに好意的であるかもしれません。 多くのエラー条件がそこでトランジット中であることのキーを検索するか、またはその結果システムセキュリティー対策を攻撃するキーのうまくいっている普及を妨げる誘発されたエラー条件であるかもしれない(そのシステムのセキュリティを壊そうとする第三者によって呼び出される)ので、かぎ管理プロトコルの取り扱いエラー条件のタスクは難しい状態で二重です。
4.4 Commercial vs. Military
4.4 コマーシャル対軍
Commercial and military key management differ in many ways. Commercial Key management protocols tend to emphasize inter- operability, freedom of action, and performance. Military systems tend to emphasize security and control of operations.
商業の、そして、軍事のかぎ管理は様々な意味で異なります。 商業Key管理プロトコルは、相互の運転可能性、行動の自由、および性能を強調する傾向があります。 軍用システムは、操作のセキュリティとコントロールを強調する傾向があります。
There will be a difference in cryptographic algorithms. The military protocol would certainly use high grade encryption because of protecting classified information. The commercial system would probably using algorithms. and techniques certified for unclassified communication systems. The main difference is in the algorithms length and type.
暗号アルゴリズムの違いがあるでしょう。確かに、軍事のプロトコルは、機密情報を保護するので、高いグレード暗号化を使用するでしょう。 商業の体系は、たぶんアルゴリズム非分類された通信系のために公認されたテクニックを使用することであるでしょう。主な違いがアルゴリズムの長さとタイプであります。
A military protocol would require more management and structure than a commercial one. The military has always adopted a hierarchical communication structure and the commercial system, especially if you look at the internet, work mainly by anarchist style.
軍事のプロトコルは商業ものより管理と構造を必要とするでしょう。 軍はいつも階層通信構造と商業の体系を採用していました、特にあなたがインターネットを見るなら、主にアナキストスタイルによる仕事。
4.4.1 Algorithm Type
4.4.1 アルゴリズムタイプ
Another difference between military and commercial key management is the type of cryptographic algorithms. The commercial world uses encryption algorithms like DES and in the future Skipjack. The military uses other cryptographic algorithms that differ in key
軍事の、そして、商業のかぎ管理の別の違いは暗号アルゴリズムのタイプです。商業界はDESと将来のSkipjackの暗号化アルゴリズムを使用します。 軍はキーにおいて異なる他の暗号アルゴリズムを使用します。
Harney & Muckenhirn Experimental [Page 20] RFC 2094 GKMP Architecture July 1997
[20ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
length and have more restrictions. An example of this would be the identification of ACCORDION, as a military key encryption algorithm as used in the EKMS program run by NSA.
そして、長さ、 より多くの制限を持ってください。 この例はACCORDIONの識別でしょう、NSAによって動かされたEKMSプログラムで使用される軍事の主要な暗号化アルゴリズムとして。
Any experiments with a grouped key management protocol must consider the differences between military and commercial algorithms. The commercial algorithms tend to be quicker to implement, run faster, involve less processing time, and allows an unclassified experiment. However, we must be careful not paint an unrealistic picture of the performance of the protocol based on these commercial algorithms. A military algorithm tends to be more cumbersome to process, slow to process, require more bandwidth, a lot of unpleasant characteristics from the commercial stand point, but allow for a higher grade of cryptographic security. One way of dealing with the disparity between algorithms is to use the commercial cryptographic algorithms and leave the fields the size used by a comparative DOD cryptographic algorithms and insert delays to simulate DOD algorithm processing times.
分類されたかぎ管理プロトコルによるどんな実験も、より速く実行されて. 商業アルゴリズムは、より迅速になるように傾向がある軍事の、そして、商業のアルゴリズムの違いが、より少ない処理時間に道具にかかわると考えなければならなくて、非分類された実験を許します。 しかしながら、私たちはプロトコルの性能の非現実的な画像が商業アルゴリズム軍事のアルゴリズムが処理するために、より厄介になるように傾向があるこれらに基礎づけたどんな処理するのが遅い塗料も商業見地からの、より多くの帯域幅、多くの不快な特性を必要としますが、暗号のセキュリティの、より高いグレードを考慮しないのに慎重であるに違いありません。 アルゴリズムの間の不一致に対処する1つの方法は、商業暗号アルゴリズムを使用して、比較DOD暗号アルゴリズムで使用されるサイズに野原を出て、DODアルゴリズム処理回数をシミュレートするために遅れを挿入することです。
4.4.2 Management Philosophy
4.4.2 経営哲学
Management for a military network is far more structured than a commercial network. A military network would restrict the creation of network groups, the rekeying of those groups, and access to the data contained in those groups. In contrast the commercial world would enable any member in the network to create a group and allow any other member of the net to join that group.
ミリタリー・ネットワークのための管理は商業ネットワークよりずっと構造化されています。 ミリタリー・ネットワークはネットワークグループの創設、それらのグループを「再-合わせ」る、およびそれらのグループに含まれたデータへのアクセスを制限するでしょう。 対照的に、商業界は、ネットワークのどんなメンバーも、グループを創設して、ネットのいかなる他のメンバーもそのグループに加わるのを許すのを可能にするでしょう。
The group Key Management Protocol must allow for both these architectures i.e., all for very structure command control hierarchy and another free form group creation.
グループKey Managementプロトコルはすなわち、まさしくその構造コマンド制御の階層と別の自由形式グループ作成に関してすべて、これらのアーキテクチャの両方を考慮しなければなりません。
4.5 Receiver Initiated Operations
4.5受信機は操作を開始しました。
How do they actually work, what are the performance trades, experimentation needed.
どのようにがするか、彼らが実際に働いていて、性能取り引き、必要である実験は何ですか?
Who is the group leader?
グループのリーダーはだれですか?
How do we elect a new leader?
私たちはどのように新しいリーダーを選出しますか?
Will multiple leaders be created?
複数のリーダーが創造されるでしょうか?
Will rule based access control allow fine enough access disgression?
規則のベースのアクセスコントロールは十分すばらしいアクセス「不-転位」を許容するでしょうか?
Harney & Muckenhirn Experimental [Page 21] RFC 2094 GKMP Architecture July 1997
[21ページ]RFC2094GKMPアーキテクチャ1997年7月に実験的なハーニーとMuckenhirn
Methods for distributed GKP/GRP dissemination need to be examined. This includes:
分配されたGKP/GRP普及のためのメソッドは、調べられる必要があります。 これは:
o resolving group identification issues, such as how to notify
potential members of membership requirements without compromising
any security-relevant information about the group;
o 会員になるための条件についてどうグループのどんなセキュリティ関連している情報にも感染しないで会員になる可能性のある人に通知などかなどのグループ識別問題を解決します。
o approaches for rapidly identifying GKP/GRP sources must be
developed, such as a "Key ARP" whereby a new member broadcasts
into the group a request for key service and existing members
resolve which will provide service; and,
o 急速にGKP/GRPソースを特定するためのアプローチを開発しなければなりません、新しいメンバーがサービスを提供する主要なサービスと既存のメンバー決議を求める要求をグループに放送する「主要なARP」のように。 そして
o Security effects of distributing access control decisions must
also be reviewed.
o また、アクセス制御決定を広げるというセキュリティ効果を見直さなければなりません。
5 Security Considerations
5 セキュリティ問題
This document, in entirety, concerns security.
全体では、このドキュメントはセキュリティに関係があります。
6 Addresses of Authors
作者の6つのアドレス
Hugh Harney SPARTA, Inc. Secure Systems Engineering Division 9861 Broken Land Parkway, Suite 300 Columbia, MD 21046-1170 United States telephone: +1 410 381 9400 (ext. 203) electronic mail: hh@columbia.sparta.com
ヒューハーニースパルタInc.Secure Systems工務部9861Broken Land Suite300コロンビア、MD21046-1170パークウェイ(合衆国)に電話をします: +1 410 381 9400 (ext。 203) 電子メール: hh@columbia.sparta.com
Carl Muckenhirn SPARTA, Inc. Secure Systems Engineering Division 9861 Broken Land Parkway, Suite 300 Columbia, MD 21046-1170 United States telephone: +1 410 381 9400 (ext. 208) electronic mail: cfm@columbia.sparta.com
カールMuckenhirnスパルタInc.Secure Systems工務部9861Broken Land Suite300コロンビア、MD21046-1170パークウェイ(合衆国)に電話をします: +1 410 381 9400 (ext。 208) 電子メール: cfm@columbia.sparta.com
Harney & Muckenhirn Experimental [Page 22]
ハーニーとMuckenhirn実験的です。[22ページ]
一覧
スポンサーリンク
