RFC2093 日本語訳
2093 Group Key Management Protocol (GKMP) Specification. H. Harney, C.Muckenhirn. July 1997. (Format: TXT=48678 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Harney
Request for Comments: 2093 C. Muckenhirn
Category: Experimental SPARTA, Inc.
July 1997
コメントを求めるワーキンググループH.ハーニーの要求をネットワークでつないでください: 2093年のC.Muckenhirnカテゴリ: 実験的なスパルタInc.1997年7月
Group Key Management Protocol (GKMP) Specification
グループ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. Background..................................................... 1 2. Overview: GKMP Roles.......................................... 3 3. Data Item primitives........................................... 4 4. Message definitions............................................ 6 5. State definitions.............................................. 9 6. Functional Definitions--Group Key Management Protocol.......... 13 7. Security Considerations........................................ 23 8. Author's Address............................................... 23
1. バックグラウンド… 1 2. 概要: GKMPの役割… 3 3. データItem基関数… 4 4. メッセージ定義… 6 5. 定義を述べてください… 9 6. 機能定義--グループの主要な管理は議定書を作ります… 13 7. セキュリティ問題… 23 8. 作者のアドレス… 23
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 Background
1 バックグラウンド
Traditional key management distribution has mimicked the military paper based key accounting system. Key was distributed, ordered, and accounted physically leading to large lead times and expensive operations.
伝統的なかぎ管理分配は軍用の紙に基づいている主要な会計システムをまねました。 キーは、物理的に大きい先行時間と高価な操作に通じながら、分配されて、注文されて、説明されました。
Cooperative key management algorithms exist that allow pairwise keys to be generated between two equipment's. This gives the a quicker more reliable key management structure capable of supporting large numbers of secure communications. Unfortunately, only pairwise keys are supported using these methods today.
対状キーが設備の2ところの間で生成する協力的なかぎ管理アルゴリズムは存在しています。 これはaより迅速なより信頼できるかぎ管理構造を多くの安全なコミュニケーションをサポートすることができるのに与えます。 残念ながら、対状キーだけが、今日これらのメソッドを使用することで支えられます。
Harney & Muckenhirn Experimental [Page 1] RFC 2093 GKMP Specification July 1997
[1ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
This document describes a protocol for establishing and rekeying groups of cryptographic keys (more than two) on the internet. We refer to the approach as the Group Key Management Protocol (GKMP).
このドキュメントは、インターネットで暗号化キー(2以上)のグループを設立して、「再-合わせ」るためにプロトコルについて説明します。 私たちはGroup Key Managementプロトコル(GKMP)とアプローチを呼びます。
1.1 Protocol Overview
1.1 プロトコル概要
The GKMP creates key for cryptographic groups, distributes key to the group members, ensures (via peer to peer reviews) rule based access control of keys, denies access to known compromised hosts, and allow hierarchical control of group actions.
GKMPは、暗号のグループのためのキーを作成して、グループのメンバーのキーを分配して、規則がキーのアクセスコントロールを基礎づけたのを確実にして(ピアツーピアレビューで)、アクセスが感染されたホストを知って、集団行動の階層制御を許容することを否定します。
The key generation concept used by the GKMP is cooperative generation between two protocol entities. There are several key generation algorithms viable for use in the GKMP (i.e., RSA, Diffe-Hellman, elliptic curves). All these algorithms use asymmetric key technology to pass information between two entities to create a single cryptographic key.
GKMPによって使用されたキー生成概念は2つのプロトコル実体の間の協力的な世代です。 GKMP(すなわち、RSA、Diffe-ヘルマン、楕円曲線)における使用に、実行可能ないくつかのキー生成アルゴリズムがあります。 これらのすべてのアルゴリズムが単一の暗号化キーを作成するために2つの実体の間で情報を通過する非対称の主要な技術を使用します。
The GKMP then distributes the group keys to qualified GKMP entities. This distribution process is a mutually suspicious process (all actions and identities must be verified).
そして、GKMPは適切なGKMP実体のグループキーを分配します。 この分配プロセスは互いに疑わしげなプロセス(すべての動作とアイデンティティについて確かめなければならない)です。
The GKMP provides a peer to peer review process. Protocol entities pass permission certificates (PC) as part of the group key distribution process. The PCs contain access control information about a particular site. This access control information is assigned by a higher authority which then signs the PC. Therefor each entity can verify the permissions of any other GKMP entity but can modify none. Each protocol entity checks the permissions and compares them the level of service requested. If the permissions do not exceed or equal the request, the service is denied.
GKMPはピアツーピア吟味の過程を提供します。 プロトコル実体はグループキー分配プロセスの一部として許可証明書(PC)を渡します。 PCは特定のサイトに関するアクセス制御情報を含んでいます。 どれがその時PCに署名するかというこのアクセス制御情報は、より高い権威によって割り当てられます。 そのために、各実体は、いかなる他のGKMP実体の許容についても確かめることができますが、なにも変更できません。 それぞれのプロトコル実体は、許容をチェックして、それらを比較します。要求されたサービスのレベル。 許容が要求と超えてもいませんし、等しくしもしないなら、サービスは否定されます。
The GKMP supports compromise recovery. A list of compromised GKMP entities is distributed to group members during key management actions. In essence, a Compromise Recovery List (CRL) allows group members to drop connections with compromised entities. The GKMP delegates control of groups to specific group controllers so it will be somewhat easier to distribute the CRL to the most important GKMP entities. During each key management action the CRL version number is passed, when a CRL update is detected it is downloaded and verified (it is signed by a higher authority).
GKMPは感染回復をサポートします。 感染しているGKMP実体のリストは、かぎ管理動作の間、メンバーを分類するために分配されます。 本質では、Compromise Recovery List(CRL)はグループのメンバーに感染している実体との関係を下げさせます。 代表が制御する特有へのグループのGKMPがコントローラを分類するので、最も重要なGKMP実体にCRLを分配するのはいくらか簡単になるでしょう。 CRLバージョン番号が通過されるそれぞれのかぎ管理動作の間、CRLアップデートが検出されるとき、それは、ダウンロードされて、確かめられます(それは、より高い権威によって署名されます)。
The GKMP allows control of group actions. In certain networks it is desirable for a higher authority to strictly control the generation of groups. These networks usually have a central network operations authority. The GKMP allows these authorities to remotely order group actions. These orders are signed by that authority and verified by all entities involved with the group.
GKMPは集団行動のコントロールを許します。 あるネットワークでは、厳密にグループの世代を制御するより高い権威に、それは望ましいです。 これらのネットワークには、通常、主要なネットワーク操作権威があります。 GKMPはこれらの当局に集団行動を離れて命令させます。 これらの命令は、その権威によって署名されて、グループにかかわるすべての実体によって確かめられます。
Harney & Muckenhirn Experimental [Page 2] RFC 2093 GKMP Specification July 1997
[2ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
The GKMP is an application layer protocol. It's independent of the underlying communication protocol. However, if multicast service is available it will speed the rekey of the cryptographic groups. Hence, the GKMP does use multicast services if they are available.
GKMPは応用層プロトコルです。 それは基本的な通信プロトコルから独立しています。 しかしながら、マルチキャストサービスが利用可能であるなら、それは暗号のグループのrekeyを促進するでしょう。 したがって、それらが利用可能であるなら、GKMPはマルチキャストサービスを利用します。
2 Overview: GKMP Roles
2概要: GKMPの役割
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 key distributor and member. The controller initiates the creation of the key, forms the key distribution messages, and collects acknowledgment of key receipt from the receivers. The members wait for a distribution message, decrypt, validate, and acknowledge the receipt of new key.
分類されたキーの作成と分配は役割の課題を必要とします。 これらは、個々のホストがプロトコルでどんな機能を実行するかを特定します。 2つのプライマリ役割が主要なディストリビュータとメンバーのものです。 コントローラは、キーの作成を開始して、主要な分配メッセージを形成して、受信機から主要な領収書の承認を集めます。 メンバーは、新しいキーの領収書を分配メッセージを待っていて、解読して、有効にして、受け取ったことを知らせます。
2.1 Group controller
2.1 グループコントローラ
The group controller (GC) 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 GC and could assume this duty upon assignment.
グループコントローラ(GC)は重要なプロトコル動作を実行する権威があるaグループのメンバー(すなわち、キーを作成してください、そして、キーを分配してください、そして、グループrekeyメッセージを作成してください、そして、これらの動作の進歩に関して報告する)です。 すべてのグループのメンバーが、GCである能力を持って、課題のときにこの義務を引き受けることができました。
The GC 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). Hence, someone has to be in charge -- that is the controller.
GCは、暗号のグループが主要な同期に達して、維持するのを助けます。 グループは同じ左右対称の暗号化キーを運用しなければなりません。 グループの一部が損をするか、または不適当に変化するなら主要である、それは正しいキーを作動させる別のホストに、データを送ることができませんし、受け取ることができないでしょう。 そのために、キーを作成するか、または変えるそれらの操作が明白で制御されているのは(すなわち、複数のホストが同時にrekeyにネットを試みるのは、適切でないでしょう)、重要です。 したがって、だれかが担当していなければなりません--それはコントローラです。
2.2 Group member
2.2 グループのメンバー
Simply stated a group member is any group host who is not acting as the controller. The group members 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リストを維持してください、そして、かぎ管理動作の同輩レビューを実行してください、そして、地方のキーを管理してください。
Harney & Muckenhirn Experimental [Page 3] RFC 2093 GKMP Specification July 1997
[3ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
3 Data Item primitives
3つのデータItem基関数
3.1 Group members list:
3.1 グループのメンバーは記載します:
In a sender oriented group, the GC must be given a list of net members. The controller will then initiate contact with these net members and create the group.
送付者指向のグループでは、ネットのメンバーのリストをGCに与えなければなりません。 コントローラは、次に、これらのネットのメンバーとの接触を起こして、グループを創設するでしょう。
3.2 Group Token:
3.2 トークンを分類してください:
The group token is created by the authority which commands a group. The Token contains information the net members need to ensure a controller is authorized to create a group and exactly what constrains are intended to be places on the group. The group token contains the following fields: Group identification,
グループトークンはグループを命令する権威によって作成されます。 Tokenがまさにネットのメンバーがコントローラがグループを創設するのに権限を与えられるのを保証するために必要とする情報を含んでいる、何、抑制、グループの場所であることを意図するか。 グループトークンは以下の分野を含んでいます: 識別を分類してください。
o GC ID,
o GC ID
o Group action (create, rekey, delete),
o 集団行動、(rekeyに作成、削除、)
o Group permissions (rules to guide access control),
o 許容を分類してください(誘導する規則はコントロールにアクセスします)。
o Rekey interval (life span of group key),
o Rekey間隔(グループキーの寿命)
o Token version (identifier to identify current token),
o トークンバージョン(現在のトークンを特定する識別子)
o Token signature (asymmetric signature using the group
commanders private key),
o トークン署名(グループ指揮官秘密鍵を使用する非対称の署名)
o Group commanders public key (this public key is itself signed by
the network security manager to bind the public to a specific net
member ID).
o 指揮官公開鍵を分類してください(この公開鍵は特定のネットのメンバーIDに公衆を縛るためにネットワークセキュリティマネージャによって署名されます)。
3.3 Grp ID:
3.3 Grp ID:
The group must be uniquely identified to allow for several different groups to coexist on a network.
いくつかの異なったグループがネットワークに共存するのを許容するために唯一グループを特定しなければなりません。
3.4 GTEK ID:
3.4 GTEK ID:
Unique identifier of GTEK (can include state information).
GTEK(州の情報を含むことができる)のユニークな識別子。
3.5 GKEK ID:
3.5 GKEK ID:
Unique identifier of GKEK (can include state information).
GKEK(州の情報を含むことができる)のユニークな識別子。
Harney & Muckenhirn Experimental [Page 4] RFC 2093 GKMP Specification July 1997
[4ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
3.6 GTEK creation field:
3.6GTEK作成分野:
In a cooperative key creation protocol each party contributes some field used to create the key.
各当事者が寄付する協力的な主要な作成プロトコルでは、何らかの分野が以前はキーをよく作成していました。
3.7 GKEK creation field:
3.7GKEK作成分野:
In a cooperative key creation protocol each party contributes some field used to create the key.
各当事者が寄付する協力的な主要な作成プロトコルでは、何らかの分野が以前はキーをよく作成していました。
3.8 Distributor signature:
3.8ディストリビュータ署名:
Asymmetric signature using the GCs private key.
GCs秘密鍵を使用する非対称の署名。
3.9 Distributor public key:
3.9ディストリビュータ公開鍵:
Public half of the GCs signature key pair. (this public key is itself signed by the network security manager to bind the public to a specific net member ID.
GCs署名キーの公共の半分は対にされます。 (この公開鍵は、特定のネットのメンバーIDに公衆を縛るためにネットワークセキュリティマネージャによって署名されます。
3.10 Member signature:
3.10メンバー署名:
Asymmetric signature using the selected members private key.
選択されたメンバー秘密鍵を使用する非対称の署名。
3.11 Member public:
3.11メンバー公衆:
Public half of the selected members signature key pair. (this public key is itself signed by the network security manager to bind the public to a specific net member ID.
選択されたメンバー署名キーの公共の半分は対にされます。 (この公開鍵は、特定のネットのメンバーIDに公衆を縛るためにネットワークセキュリティマネージャによって署名されます。
3.12 Controller permissions:
3.12 コントローラ許容:
Controller permissions are assigned by the security manager. The security managers signature will bind the permissions to the controller ID.
コントローラ許容はセキュリティマネージャによって割り当てられます。 セキュリティマネージャ署名はコントローラIDに許容を縛るでしょう。
3.13 SKEK ID:
3.13 SKEK ID:
This field identifies exactly which SKEK is being created. This allows multiple groups to interoperate on a net simultaneously.
この分野は、まさにどのSKEKが作成されているかを特定します。 これで、複数のグループが同時に、ネットに共同利用します。
3.14 SKEK creation field:
3.14SKEK作成分野:
This field contains the information contributed for use in the KEK creation process.
この分野はKEK作成プロセスにおける使用のために寄付された情報を含んでいます。
Harney & Muckenhirn Experimental [Page 5] RFC 2093 GKMP Specification July 1997
[5ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
3.15 Member permissions:
3.15 メンバー許容:
Member permissions are assigned by the security manager. The security managers signature will bind the permissions to the controller ID.
メンバー許容はセキュリティマネージャによって割り当てられます。 セキュリティマネージャ署名はコントローラIDに許容を縛るでしょう。
3.16 Encrypted Grp Keys:
3.16 暗号化されたGrpキー:
This data item is encrypted in the KEK (session or group) created for the download of keys. It is the GTEK and GKEK created for a group. A checksum is also encrypted. This ensures the confidentiality and data integrity of the GTEK and GKEK.
このデータ項目はキーのダウンロードのために作成されたKEK(セッションかグループ)で暗号化されます。 それは、グループのために作成されたGTEKとGKEKです。 また、チェックサムは暗号化されます。 これはGTEKとGKEKの秘密性とデータ保全を確実にします。
3.17 Confirmation of decryption:
3.17 復号化の確認:
This is a short (byte) field indicating decryption of the message and exactly what type of message was decrypted.
これはメッセージの復号化とまさにどんなタイプに関するメッセージが解読されたかを示す短い(バイト)分野です。
3.18 Request:
3.18は以下を要求します。
A request field contains the specific request one net member may make to another. The requests range from (group join, CRL update, pairwise TEK generation, detection, group creation, status).
要求分野は1人のネットのメンバーが別のものにするかもしれない特定の要求を含んでいます。 要求が及ぶ、(グループは加わって、CRLアップデート、対状TEK世代、検出は作成、状態を分類します。)
Member delete list:
メンバーはリストを削除します:
A list of group members being administratively deleted from the group.
グループから行政上削除されるグループのメンバーのリスト。
4 Message definitions
4 メッセージ定義
4.1 Command_Create Group:
4.1 コマンド_はグループを創設します:
This message contains the following data item primitives (Group members, Grp ID, Grp controller ID, Grp action, Grp permissions, Rekey interval, Token version, Token signature, Token public key). This message may be confidential due to the group permissions field. In sensitive systems it will need encryption prior to transmission.
このメッセージは以下のデータ項目基関数を含んでいます(メンバーを分類してください、Grp GrpコントローラID(ID)Grp動作、Grp許容、Rekey間隔、Tokenバージョン、Token署名、Token公開鍵)。 このメッセージはグループ許容分野のために秘密であるかもしれません。 敏感なシステムでは、それはトランスミッションの前に暗号化を必要とするでしょう。
4.2 Create Grp Keys_1:
4.2 Grpキー_1を作成してください:
This message passes the information needed to create the group keys from the GC to the selected net member. This message contains (Grp ID, Request, GTEK ID, GKEK ID, GTEK creation field, GKEK creation field, Grp token, Controller signature, Controller public)
このメッセージはGCから選択されたネットのメンバーまでのグループキーを作成するのに必要である情報を通過します。 このメッセージは含んでいます。(Grp ID、Request、GTEK ID、GKEK ID、GTEK作成分野、GKEK作成分野、Grpトークン、Controller署名、Controller公衆)
Harney & Muckenhirn Experimental [Page 6] RFC 2093 GKMP Specification July 1997
[6ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
4.3 Create Grp Keys_2:
4.3 Grpキー_2を作成してください:
This message passes the information needed to create the group keys from the selected net member to the GC. This message contains: (Grp ID, GTEK ID, GKEK ID, GTEK creation field, GKEK creation field, member signature, member public)
このメッセージは選択されたネットのメンバーからGCまでのグループキーを作成するのに必要である情報を通過します。 このメッセージは以下を含んでいます。 (Grp ID、GTEK ID、GKEK ID、GTEK作成分野、GKEK作成分野、メンバー署名、メンバー公衆)
4.4 Negotiate Grp Keys_1:
4.4 Grpキー_1を交渉してください:
This message passes the group token and GCs permissions to the selected net member. This information can be sensitive and needs to be protected. Therefor, this message is encrypted in the GTEK just created. This encryption includes the appropriate data integrity checks. This message1 contains: (Grp ID, TEK ID, KEK ID, Group token, Controller permissions)
このメッセージはグループトークンとGCs許容を選択されたネットのメンバーに渡します。 この情報は、敏感である場合があり、保護される必要があります。 そのために、このメッセージはただ作成されたGTEKで暗号化されます。 この暗号化は適切なデータ保全チェックを含んでいます。 このmessage1は以下を含んでいます。 (Grp ID、TEK ID、KEK ID、Groupトークン、Controller許容)
4.5 Negotiate Grp Keys_2:
4.5 Grpキー_2を交渉してください:
This message passes the selected net members permissions to the GC. This message1 contains: (Grp ID, GTEK ID, GKEK ID, Member permissions). This information can be sensitive and needs to be protected. Therefor, this message is encrypted in the GTEK just created. This encryption includes the appropriate data integrity checks.
このメッセージは選択されたネットのメンバーにGCへの許容を渡します。 このmessage1は以下を含んでいます。 (Grp ID、GTEK ID、GKEK ID、メンバー許容。) この情報は、敏感である場合があり、保護される必要があります。 そのために、このメッセージはただ作成されたGTEKで暗号化されます。 この暗号化は適切なデータ保全チェックを含んでいます。
4.6 Create Session KEK_1:
4.6 セッションKEK_1を作成してください:
This message sends information to create a KEK for one time use between the GC and selected net member.
このメッセージは、1回の使用のためにGCと選択されたネットのメンバーの間でKEKを作成するために情報を送ります。
4.7 Create Session KEK_2:
4.7 セッションKEK_2を作成してください:
This message sends information to create a KEK for one time use between the selected net member and GC.
このメッセージは、1回の使用のために選択されたネットのメンバーとGCの間でKEKを作成するために情報を送ります。
4.8 Negotiate Session Keys_1:
4.8 セッションキー_1を交渉してください:
This message passes the group ID, SKEK ID, CRL version number, Group token and GCs permissions to the selected net member. This information can be sensitive and needs to be protected. Therefor, this message is encrypted. If an appropriate pairwise key is available then that key should be used. If not the KEK just created could be used to encrypt the message.
このメッセージはグループID、SKEK ID、CRLバージョン番号、Groupトークン、およびGCs許容を選択されたネットのメンバーに渡します。 この情報は、敏感である場合があり、保護される必要があります。 そのために、このメッセージは暗号化されています。 適切な対状キーが利用可能であるなら、そのキーは使用されるべきです。 そうでなければ、メッセージを暗号化するのにただ作成されたKEKは使用できました。
Harney & Muckenhirn Experimental [Page 7] RFC 2093 GKMP Specification July 1997
[7ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
4.9 Negotiate Session Keys_2:
4.9 セッションキー_2を交渉してください:
This message identifies the group, SKEK, CRL version number and the member permissions. This information can also be sensitive and needs protection.
このメッセージはグループ、SKEK、CRLバージョン番号、およびメンバー許容を特定します。 この情報は、また、敏感である場合があり、保護を必要とします。
4.10 Download Grp Keys:
4.10 Grpキーをダウンロードしてください:
This message includes a GRP ID and Encrypted Grp Keys data items.
このメッセージはGRP IDとEncrypted Grpキーズデータ項目を含んでいます。
4.11 Key download ack:
4.11 主要なダウンロードack:
This message contains the GRP ID and Confirmation_decryption data items. It confirms the receipt and verified decryption of the GTEK and GKEK.
このメッセージはGRP IDとConfirmation_復号化データ項目を含んでいます。それはGTEKとGKEKの領収書と確かめられた復号化を確認します。
4.12 Rekey _Multicast:
4.12Rekey_マルチキャスト:
This message contains: Grp ID, GTEK ID, GKEK ID, Group token, Controller permissions. The rekey message is encrypted in the GKEK already resident in all the group member sites. This leads to a single message capable of being accepted by all group members.
このメッセージは以下を含んでいます。 Grp ID、GTEK ID、GKEK ID、Groupトークン、Controller許容。 rekeyメッセージはすべてのグループメンバーサイトでGKEKで既に居住していた状態で暗号化されます。 これはすべてのグループのメンバーが受け入れることができるただ一つのメッセージに通じます。
4.13 Request_Group_Join:
4.13 _グループ_が接合するよう要求してください:
This message contains Request, Grp ID, Member Signature, Member Public.
このメッセージはRequest、Grp IDメンバーSignature、メンバーPublicを含んでいます。
4.14 Delete_Group_Keys:
4.14 _グループ_キーを削除してください:
This message contains: grp ID, Request, Member delete list, Controller signature, Controllers public.
このメッセージは以下を含んでいます。 Controllers公衆、grp ID、Request、メンバーはリストを削除して、Controllerは署名です。
4.15 Grp_Keys_Deleted_Ack:
4.15 Grp_キー_は_Ackを削除しました:
This message contains (grp ID, member ID, member signature, member public.
このメッセージが含んでいる、(grp ID、メンバーID、メンバー署名、メンバー公衆。
4.16 Delete_Group_Keys:
4.16 _グループ_キーを削除してください:
This message contains (grp ID, request, member delete list, controller signature, controller public).
このメッセージは含んでいます(コントローラ公衆、grp ID、要求、メンバーがリストを削除して、コントローラは署名です)。
4.17 Grp_Keys_Deleted_Ack:
4.17 Grp_キー_は_Ackを削除しました:
This message contains (grp ID, member ID, member signature, member public)
このメッセージは含んでいます。(grp ID、メンバーID、メンバー署名、メンバー公衆)
Harney & Muckenhirn Experimental [Page 8] RFC 2093 GKMP Specification July 1997
[8ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
5 State definitions
5 州の定義
There are thirteen separate states the in the protocol. They are described below:
13の別々の州がコネです。そこ、プロトコル。 それらは以下で説明されます:
5.1 State 1:
5.1 州1:
The source address is checked to ensure it is not on the CRL.
ソースアドレスは、それがCRLにないのを保証するためにチェックされます。
The token field is validated with the public key of the source.
トークン分野はソースの公開鍵で有効にされます。
The token version number is checked to ensure this token is current.
トークンバージョン番号は、このトークンが確実に現在になるようにするためにチェックされます。
The group ID is checked to see if this group exists.
グループIDは、このグループが存在するかどうか確認するためにチェックされます。
The controller ID field is then read. If the receiver is listed as the GC, the receiver assumes the role of controller. If not, the role assumed is that of receiver.
そして、コントローラID分野は読まれます。 受信機がGCとして記載されるなら、受信機はコントローラの役割を引き受けます。 そうでなければ、引き受けられた役割は受信機のものです。
The GC reads the group permission field in the group token. It then verifies that its' personnel permissions exceed or equal those of the group.
GCはグループトークンにおけるグループ許可分野を読みます。 'そして、それは、'人員許容がグループのものと超えているか、または等しいことを確かめます。
The GC will creates its' portion of the key creation message.
'GC意志は主要な作成メッセージについて'部分を作成します。
The Create Grp Keys_1 message is completed and transmitted.
Create Grpキーズ_1メッセージは、完成して、送られます。
5.2 State 2:
5.2 2は述べます:
The source signature field is validated using the public key of the source.
ソース署名分野は、ソースの公開鍵を使用することで有効にされます。
The source ID field is compared against the local CRL. If the source is on the CRL the association is terminated.
ソースID分野は地方のCRLに対して比較されます。 ソースがCRLにあるなら、協会は終えられます。
The request field is read. The local contributions to the group keys are created.
要求分野は読まれます。 グループキーへの地方の貢献は作成されます。
The Group keys are created and stored pending negotiation.
Groupキーは、交渉まで作成されて、保存されます。
The key table is updated to show the group key pending negotiation.
主要な未定の交渉をグループに示しているために主要なテーブルをアップデートします。
5.3 State 3:
5.3 3は述べます:
The permission certificate is retrieved and validated using the security managers public key. The permissions of the message source are checked to verify they meet or exceed those of the group.
許可証明書は、セキュリティマネージャ公開鍵を使用することで検索されて、有効にされます。 メッセージ源の許容が確かめるためにチェックされる、それらは、グループのものを会うか、または超えています。
Harney & Muckenhirn Experimental [Page 9] RFC 2093 GKMP Specification July 1997
[9ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
The group token is retrieved and validated using the appropriate public key.
グループトークンは、適切な公開鍵を使用することで検索されて、有効にされます。
The token version number is checked to ensure the token is current.
トークンバージョン番号は、トークンが確実に現在になるようにするためにチェックされます。
The group ID specified in the token is compared with the actual group ID. If they are different the exchange is terminated.
トークンで指定されたグループIDは実際のグループIDにたとえられます。 それらが異なるなら、交換は終えられます。
The controller ID specified in the token is compared with the GC ID. If they do not match the exchange is terminated.
トークンで指定されたコントローラIDはGC IDと比較されます。 彼らが合っていないなら、交換は終えられます。
The local permissions are compared to the permissions specified for the group. If they do not meet or exceed the group permissions the exchange is terminated and a report is generated.
地方の許容はグループに指定された許容にたとえられます。 彼らがグループ許容を満たしもしませんし、超えてもいないなら、交換は終えられます、そして、レポートは発生しています。
The rekey interval specified in the token is stored locally.
トークンで指定されたrekey間隔は局所的に保存されます。
The key table is updated to reflect the key permissions, rekey interval, group ID and current time.
主要な許容、rekey間隔、グループID、および現在の時間を反映するために主要なテーブルをアップデートします。
5.4 State 4:
5.4 4は述べます:
The permission certificate is retrieved and validated using the security members public key. The permissions of the message source are checked to verify they meet or exceed those of the group.
許可証明書は、セキュリティメンバー公開鍵を使用することで検索されて、有効にされます。 メッセージ源の許容が確かめるためにチェックされる、それらは、グループのものを会うか、または超えています。
The key table is updated to reflect the key permissions, rekey interval, group ID and current time.
主要な許容、rekey間隔、グループID、および現在の時間を反映するために主要なテーブルをアップデートします。
5.5 State 5:
5.5 5は述べます:
The source signature field is validated using the public key of the source.
ソース署名分野は、ソースの公開鍵を使用することで有効にされます。
The source ID field is compared against the local CRL. If the source is on the CRL, the association is terminated.
ソースID分野は地方のCRLに対して比較されます。 ソースがCRLにあるなら、協会は終えられます。
The request field is read. The local contribution to the SKEK are created. The SKEK is created and stored pending negotiation.
要求分野は読まれます。 SKEKへの地方の貢献は作成されます。 SKEKは交渉まで作成されて、保存されます。
The key table is updated to show the SKEK pending negotiation.
交渉までSKEKを見せているために主要なテーブルをアップデートします。
5.6 State 6:
5.6 6は述べます:
The permission certificate is retrieved and validated using the security managers public key. The permissions of the message source are checked to verify they meet or exceed those of the group.
許可証明書は、セキュリティマネージャ公開鍵を使用することで検索されて、有効にされます。 メッセージ源の許容が確かめるためにチェックされる、それらは、グループのものを会うか、または超えています。
Harney & Muckenhirn Experimental [Page 10] RFC 2093 GKMP Specification July 1997
[10ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
The group token is retrieved and validated using the appropriate public key.
グループトークンは、適切な公開鍵を使用することで検索されて、有効にされます。
The token version number is checked to ensure the token is current.
トークンバージョン番号は、トークンが確実に現在になるようにするためにチェックされます。
The group ID specified in the token is stored.
トークンで指定されたグループIDは保存されます。
The controller ID specified in the token is compared with the GC ID. If they do not match the exchange is terminated.
トークンで指定されたコントローラIDはGC IDと比較されます。 彼らが合っていないなら、交換は終えられます。
The local permissions are compared to the permissions specified for the group. If they do not meet or exceed the group permissions the exchange is terminated and a report is generated.
地方の許容はグループに指定された許容にたとえられます。 彼らがグループ許容を満たしもしませんし、超えてもいないなら、交換は終えられます、そして、レポートは発生しています。
The rekey interval specified in the token is stored locally.
トークンで指定されたrekey間隔は局所的に保存されます。
The key table is updated to reflect the key permissions, rekey interval, group ID and current time.
主要な許容、rekey間隔、グループID、および現在の時間を反映するために主要なテーブルをアップデートします。
5.7 State 7:
5.7 7は述べます:
The permission certificate is retrieved and validated using the security managers public key. The permissions of the message source are checked to verify they meet or exceed those of the group.
許可証明書は、セキュリティマネージャ公開鍵を使用することで検索されて、有効にされます。 メッセージ源の許容が確かめるためにチェックされる、それらは、グループのものを会うか、または超えています。
The key table is updated.
主要なテーブルをアップデートします。
5.8 State 8:
5.8 8は述べます:
The group ID is checked.
グループIDはチェックされます。
The group keys are decrypted using the SKEK. Data integrity checks are validated to ensure proper decryption.
グループキーは、SKEKを使用することで解読されます。 データの保全チェックは、適切な復号化を確実にするために有効にされます。
The key table is updated to reflect the new group keys, key permissions, rekey interval, group ID and current time.
新しいグループキー、主要な許容、rekey間隔、グループID、および現在の時間を反映するために主要なテーブルをアップデートします。
5.9 State 9:
5.9 9は述べます:
Update group management log.
集団経営ログをアップデートしてください。
5.10 State 10:
5.10 10は述べます:
The permission certificate is retrieved and validated using the security managers public key. The permissions of the message source are checked to verify they meet or exceed those of the group.
許可証明書は、セキュリティマネージャ公開鍵を使用することで検索されて、有効にされます。 メッセージ源の許容が確かめるためにチェックされる、それらは、グループのものを会うか、または超えています。
Harney & Muckenhirn Experimental [Page 11] RFC 2093 GKMP Specification July 1997
[11ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
The group token is retrieved and validated using the appropriate public key.
グループトークンは、適切な公開鍵を使用することで検索されて、有効にされます。
The token version number is checked to ensure the token is current.
トークンバージョン番号は、トークンが確実に現在になるようにするためにチェックされます。
The group ID specified in the token is checked.
トークンで指定されたグループIDはチェックされます。
The controller ID specified in the token is compared with the GC ID. If they do not match the exchange is terminated.
トークンで指定されたコントローラIDはGC IDと比較されます。 彼らが合っていないなら、交換は終えられます。
The local permissions are compared to the permissions specified for the group. If they do not meet or exceed the group permissions the exchange is terminated and a report is generated.
地方の許容はグループに指定された許容にたとえられます。 彼らがグループ許容を満たしもしませんし、超えてもいないなら、交換は終えられます、そして、レポートは発生しています。
The rekey interval specified in the token is stored locally.
トークンで指定されたrekey間隔は局所的に保存されます。
The new group keys are decrypted with the current GKEK. The data integrity field is checked to ensure proper decryption.
新しいグループキーは現在のGKEKと共に解読されます。 データ保全分野は、適切な復号化を確実にするためにチェックされます。
The key table is updated to reflect the key permissions, rekey interval, group ID and current time.
主要な許容、rekey間隔、グループID、および現在の時間を反映するために主要なテーブルをアップデートします。
5.11 State 11:
5.11 11は述べます:
Validate signature using sources public key.
ソース公開鍵を使用して、署名を有効にしてください。
Check to see if member initiated group join is available. If not, ignore. If so begin distribution of group keys.
メンバーの開始しているグループが加わるなら、見るチェックは利用可能です。 そうでなければ、無視します。 そうだとすれば、グループキーの分配を始めてください。
5.12 State 12:
5.12 12は述べます:
Validate signature using GCs public.
GCs公衆を使用して、署名を有効にしてください。
Retrieve delete list. Check to see if on delete list, if so continue.
検索、リストを削除してください。 チェックして、オンであるならリストを削除して、そうだとすれば、続くように確実にしてください。
Create Grp_Keys_Deleted_Ack
_Grp_キーズの削除された_Ackを作成してください。
Delete group keys
グループキーを削除してください。
5.13 State 13:
5.13 13は述べます:
Validate signature using GCs public.
GCs公衆を使用して、署名を有効にしてください。
Retrieve delete list. If list is global delete, verify alternative key.
検索、リストを削除してください。 リストがグローバルである、削除、代替のキーについて確かめてください。
Switch group operations to alternative key.
グループ操作を代替のキーに切り換えてください。
Harney & Muckenhirn Experimental [Page 12] RFC 2093 GKMP Specification July 1997
[12ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
Create Grp_Keys_Deleted_Ack.
_Grp_キーズの削除された_Ackを作成してください。
Delete group keys.
グループキーを削除してください。
6 Functional Definitions--Group Key Management Protocol
6つの機能定義--グループKey Managementプロトコル
The GKMP consists of multiple functions necessary to create, distribute, rekey and manage groups of symmetric keys. These functions are:
GKMPは対称鍵のグループを作成して、分配して、rekeyして、経営するのに必要な多面的機能から成ります。 これらの機能は以下の通りです。
o Group creation (sender initiated group)
o グループ作成(送付者の開始しているグループ)
-- Create Group keys
-- Groupキーを作成してください。
-- Distribute Group keys
-- Groupキーを分配してください。
o Group rekey
o グループrekey
-- Create Group keys
-- Groupキーを作成してください。
-- Rekey Group
-- Rekeyグループ
o Member initiated join
o 開始されたメンバーは加わります。
o Group member delete
o メンバーが削除するグループ
The following sections will describe each function, including data primitives and message constructs. The associated diagrams will represent the specifics (sequence, location and communications sources and destinations) of the messages and processes necessary.
以下のセクションはデータ基関数とメッセージ構造物を含む各機能について説明するでしょう。 関連ダイヤグラムは必要な状態でメッセージとプロセスの詳細(系列、位置、コミュニケーションソース、および目的地)を表すでしょう。
6.1 Group creation
6.1 グループ作成
Member initialization is a three-step function that involves commanding the creation of the group, creation of the group keys and then distribution of those keys to "other" group members. Messages between the GC and the first member generate two keys for future group actions: the group traffic encryption key (GTEK) and the group key encryption key (GKEK). Messages between the GC and the other members are for the purpose of distributing the keys. These functions are described in the following sections.
メンバー初期化は「他」のグループのメンバーにグループの創設、グループキーの作成を命令して、次に、それらのキーの分配を命令することを伴う3階段関数です。 GCと第1代メンバーの間のメッセージは今後の集団行動のための2個のキーを生成します: グループトラフィック暗号化キー(GTEK)とグループキー暗号化キー(GKEK)。 GCと他のメンバーの間のメッセージはキーを分配する目的のためのものです。 これらの機能は以下のセクションで説明されます。
Harney & Muckenhirn Experimental [Page 13] RFC 2093 GKMP Specification July 1997
[13ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
6.1.1 Group command
6.1.1 グループコマンド
The very first action is for some entity to command the group. This command is sent to the GC.
まさしくその最初の動きは何らかの実体がグループを命令することです。 このコマンドをGCに送ります。
6.1.2 Create group keys
6.1.2 グループキーを作成してください。
The first member must cooperate with the GC to create future group keys. Reliance on two separate hosts to create group keys maximizes the probability that the resulting key will have the appropriate cryptographic properties. A single host could create the key if the randomization function were robust and trusted. Unfortunately this usually requires specialized hardware not available at most host sites. The intent of this protocol was to utilize generic hardware to enhance the extendibility of the GKMP. Hence, cooperative key generation mechanisms are used.
第1代メンバーは、将来のグループキーを作成するためにGCと協力しなければなりません。 グループキーを作成する2人の別々のホストへの信用は結果として起こるキーには適切な暗号の特性があるという確率を最大にします。 無作為化機能が強健で信じられるなら、独身のホストはキーを作成できるでしょうに。 残念ながら、通常、これはほとんどのホストサイトで利用可能でない専門化しているハードウェアを必要とします。 このプロトコルの意図はGKMPの拡張性を高めるのにジェネリックハードウェアを利用することでした。 したがって、協力的なキー生成メカニズムは使用されています。
To facilitate a well ordered group creation, management information must be passed between the controller and the group members. This information uniquely identifies the GC identity, it's permissions, authorization to create keys, the future groups permissions, current state of the compromise list, and management information pertaining to the keys being created. All this information is protected from forgery by asymmetric signature technologies. The public key used to verify net wide parameters (e.g., individual host permissions) are widely held. The public key to verify locally generated information, like peer identity, is sent with the messages. This alleviates the hosts public key storage requirements.
よく命令されたグループ作成を容易にするために、コントローラとグループのメンバーの間で経営情報を通過しなければなりません。 それが許容、キーを作成する承認である、この情報は唯一GCのアイデンティティを特定して、未来は許容、感染リスト、および作成されるキーに関係する経営情報の現状を分類します。 このすべての情報が偽造から非対称の署名技術で保護されます。 ネットの広いパラメタ(例えば、個々のホスト許容)について確かめるのに使用される公開鍵は広く保持されます。 同輩のアイデンティティのように、メッセージと共に局所的に生成している情報について確かめる公開鍵を送ります。 これはホスト公開鍵ストレージ要件を軽減します。
The goals of the key creation process are:
主要な作成プロセスの目標は以下の通りです。
o cooperatively generate a GTEK and GKEK,
o 協力してGTEKとGKEKを生成してください。
o allow the key creators to verify the identity of the key
creation partner by verifying the messages signatures.
o 主要なクリエイターにメッセージ署名について確かめることによって、主要な作成パートナーのアイデンティティについて確かめさせてください。
o share public keys
o 公開鍵を共有してください。
o allow validation of the GC, by signing the group
identification, GC identification, and group permissions.
o グループが識別と、GC識別と、グループ許容であると署名することによって、GCの合法化を許してください。
o send the group identity, GC identity, group member identities,
group permissions, and group rekey interval to the first member,
signed by the group commander (when the group was remotely
commanded).
o グループのアイデンティティ、GCのアイデンティティ、グループメンバーのアイデンティティ、グループ許容、およびグループrekey間隔を第1代グループ指揮官によって署名されたメンバーに送ってください(グループが離れて命令されたとき)。
Harney & Muckenhirn Experimental [Page 14] RFC 2093 GKMP Specification July 1997
[14ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
This function consists of four messages between the GC and the first member. The initial messages are for the establishment of the GTEK and GKEK. This is accomplished by the GC sending a signed Create_Group_Keys_1 message to the first member. This message contains two random values necessary to generate the GTEK and GKEK. This message also contains the public key of the GC.
この機能はGCと第1代メンバーの間の4つのメッセージから成ります。 初期のメッセージはGTEKとGKEKの設立のためのものです。 これは署名している_Create_Groupキーズに_1つのメッセージを送るGCによって第1代メンバーに達成されます。 このメッセージはGTEKとGKEKを生成するのに必要な2つの無作為の値を含んでいます。 また、このメッセージはGCの公開鍵を含んでいます。
The first member validates the signed Create_Group_Keys_1 message, builds and sends a signed Create_Group_Keys_2 message to the GC. He generates the GTEK and GKEK, and stores the received public key. The Create_Group_Keys_2 message contains the random values necessary for the GC to generate the GTEK and GKEK. This message also contains the public key of the first member.
第1代メンバーは、署名している_Create_Groupキーズに_GCへの2メッセージを署名しているCreate_Group_キーズ_1メッセージを有効にして、築き上げて、送ります。 彼は、GTEKとGKEKを生成して、容認された公開鍵を保存します。 Create_Group_キーズ_2メッセージはGCがGTEKとGKEKを生成するのに必要な無作為の値を含んでいます。 また、このメッセージは第1代メンバーの公開鍵を含んでいます。
The GC validates the signed Create_Group_Keys_2 message, generates the GTEK and GKEK, builds the Negotiate_Group_Keys_1 message for transmission to the first member, and stores the received public key.
GCは署名している__2Create_Groupキーズメッセージを有効にして、GTEKとGKEKを生成して、第1代メンバーへの伝送のためNegotiate_Group_キーズに_1つのメッセージを築き上げて、容認された公開鍵を保存します。
The GC sends the Negotiate_Group_Keys_1 message to the first member encrypted in the GTEK that was just generated.
GCは_第1代ただ生成されたGTEKで暗号化されたメンバーへの1つのメッセージをNegotiate_Group_キーズに送ります。
|___Net_Controller___|__________Messages__________|____Net_Member_B____|
|The Create Group |<---- Command-Create Group | |
|command is | | |
|received by net | | |
|member A. | | |
|State 1 | | |
| |Create Grp Keys_1----> | |
| | |State 2 |
| |<-----Create Grp Keys_2 | |
|State 2 | | |
| |Negotiate Grp Keys_1------> | |
| | |State 3 |
| |<-----Negotiate Grp Keys_2 | |
|State 4 | | |
Figure 1: State Diagram: Create Group Keys
|___ネット_コントローラ___|__________メッセージ__________|____ネット_メンバー_B____| |グループを創設してください。| <、-、-、-- グループをコマンドで創設してください。| | |コマンドはそうです。| | | |ネットで、受信します。| | | |メンバーA。| | | |状態1| | | | |Grpキー_1を作成してください。---->|、|、|、| |状態2| | | <、-、-、-、--Grpキー_2を作成してください。| | |状態2| | | | |Grpキー_1を交渉してください。------>|、|、|、| |状態3| | | <、-、-、-、--Grpキー_2を交渉してください。| | |状態4| | | 図1: ダイヤグラムを述べてください: グループキーを作成してください。
The first member decrypts the Negotiate_Group_Keys_1 message and extracts the group identification, GC identification, group members, group permissions, key rekey interval, CRL version number, and certifying authority signature. The group identification, GC identification, and group permissions fields are validated based on the extracted group commanders signature (if this is a remotely commanded group this signature identifies the remote host). If these fields validate, the first members internal structures are updated.
第1代メンバーは、Negotiate_Group_キーズ_1メッセージと抽出がグループ識別、GC識別、グループのメンバー、グループ許容、主要なrekey間隔、CRLバージョン番号、および公認権威署名であると解読します。 グループ識別、GC識別、およびグループ許容分野は抽出されたグループ指揮官署名に基づいて有効にされます(これが離れて命令されたグループであるなら、この署名はリモートホストを特定します)。 分野が有効にするこれらであり、インターナルが構造化する最初のメンバーをアップデートします。
Harney & Muckenhirn Experimental [Page 15] RFC 2093 GKMP Specification July 1997
[15ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
6.1.3 Distributing Group Keys to Other Members
6.1.3 他のメンバーのグループキーを分配すること。
The other group members must get the group keys before the group is fully operational. The purpose of other group member initialization is as follows:
グループが操作上に完全になる前に他のグループのメンバーはグループキーを手に入れなければなりません。 他のグループメンバー初期化の目的は以下の通りです:
o cooperatively generate a session key encryption key (SKEK) for the
transmission of the GTEK and GKEK from the GC,
o GTEKとGKEKのトランスミッションのためにGCからセッションの主要な暗号化がキー(SKEK)であると協力して生成してください。
o allow each member to verify the identify of the controller and
visa versa,
o 各メンバーが確かめるのを許容する、versaをコントローラを特定して、ビザを与えさせてください。
o allow each member to verify the controllers authorization to
create the group,
o 各メンバーにコントローラ承認について確かめさせて、グループを創設してください。
o send the key packet (KP) (consisting of the GTEK, GKEK), group
identity, GC identity, group member identities, group permissions,
and group rekey interval to the other members,
o 主要なパケット(KP)(GTEKから成るGKEK)、グループのアイデンティティ、GCのアイデンティティ、グループメンバーのアイデンティティ、グループ許容、およびグループrekey間隔を他のメンバーに送ってください。
This function consists of six messages between the GC and the other members. The initial messages are for the establishment of a SKEK. This is accomplished by the GC sending a signed Create_Session_KEK_1 message to the other member. This message contains the random value necessary for the other member to generate the SKEK. This message also contains the public key of the GC.
この機能はGCと他のメンバーの間の6つのメッセージから成ります。 初期のメッセージはSKEKの設立のためのものです。 これは署名している_Create_Session KEKに_1つのメッセージを送るGCによってもう片方のメンバーに達成されます。 このメッセージはもう片方のメンバーがSKEKを生成するのに必要な無作為の値を含んでいます。 また、このメッセージはGCの公開鍵を含んでいます。
The other member validates the Create_Session_KEK_1 message, builds and sends a Create_Session_KEK_2 message to the GC, generates the SKEK, and stores the received public key. The Create_Session_KEK_2 message contains the random value necessary for the GC to generate the SKEK. This message also contains the public key of the other member.
もう片方のメンバーは、Create_Session_KEK_1メッセージを有効にして、Create_Session_KEKに_GCへの2メッセージを築き上げて、送って、SKEKを生成して、容認された公開鍵を保存します。 Create_Session_KEK_2メッセージはGCがSKEKを生成するのに必要な無作為の値を含んでいます。 また、このメッセージはもう片方のメンバーの公開鍵を含んでいます。
The GC validates the Create_Session_KEK_2 message, generates the SKEK, builds the Negotiate_Session_ KEK_1 message for transmission to the other member, and stores the received public key.
GCはCreate_Session_KEK_2メッセージを有効にして、SKEKを生成して、もう片方のメンバーへの伝送のためNegotiate_Session_KEKに_1つのメッセージを築き上げて、容認された公開鍵を保存します。
The GC sends the Negotiate_Session_KEK_1 message to the other member encrypted in the SKEK that was just generated. The Negotiate_Session_KEK_1 message includes the group ID, group token, controller permissions, and CRL version number.
GCは_ただ生成されたSKEKで暗号化されたもう片方のメンバーへの1つのメッセージをNegotiate_Session_KEKに送ります。 Negotiate_Session_KEK_1メッセージはグループID、グループトークン、コントローラ許容、およびCRLバージョン番号を含んでいます。
The other member decrypts the Negotiate_Session_KEK_1 message, verifies the authority and identification of the controller, ensures the local CRL is up to date, and builds a Negotiate_Session_KEK_2 message for transmission to the GC.
もう片方のメンバーは、Negotiate_Session_KEK_が1つのメッセージであると解読して、コントローラの権威と識別について確かめて、地方のCRLが確実に最新になるようにして、GCへの伝送のためNegotiate_Session_KEKに_2メッセージを築き上げます。
Harney & Muckenhirn Experimental [Page 16] RFC 2093 GKMP Specification July 1997
[16ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
The GC receives the Negotiate_Session_KEK_2 message and builds a Download_Grp_Keys message for transmission to the other member.
GCはNegotiate_Session_KEK_2メッセージを受け取って、もう片方のメンバーへの伝送のためDownload_Grp_キーズメッセージを築き上げます。
The GC sends the Download_Grp_Keys message to the other member encrypted in the SKEK that was just generated. (note: the key used to encrypt the negotiation messages can be combined differently to create the KEK.)
GCはDownload_Grp_キーズメッセージをただ生成されたSKEKで暗号化されたもう片方のメンバーに送ります。 (注意: KEKを作成するために交渉メッセージを暗号化するのに使用されるキーは異なって結合できます。)
The other members decrypts the Download_Grp_Keys message and extracts the KP, group identification, GC identification, group members, group permissions, key rekey interval, and group commanders signature. The group identification, GC identification, and group permissions fields are validated based on the signature. If these fields validate, the other members internal key storage tables are updated with the new keys.
他のメンバーは、Download_Grp_キーズメッセージと抽出がKPと、グループ識別と、GC識別と、グループのメンバーと、グループ許容と、主要なrekey間隔と、グループ指揮官署名であると解読します。 グループ識別、GC識別、およびグループ許容分野は署名に基づいて有効にされます。 分野が有効にするこれらであり、新しいキーで内部の主要なストレージがテーブルの上に置く他のメンバーをアップデートします。
6.2 Group Rekey
6.2 グループRekey
Rekey is a two-step function that involves message exchange between the GC and a "first member" and "other members." Messages between the GC and the first member are exactly as described for group creation. Messages between the GC and the other members are for the purpose of distributing the new GTEK and the new GKEK. These functions are
RekeyはGCと、「最初のメンバー」と「他のメンバー」の間の交換処理にかかわるツーステップ機能です。 GCと第1代メンバーの間のメッセージはまさにグループ作成のために説明されるようにそうです。 GCと他のメンバーの間のメッセージは新しいGTEKと新しいGKEKを分配する目的のためのものです。 これらの機能はそうです。
|___Net_Controller___|__________Messages________|Net_members,individual|
| |Create Session KEK_1----> | |
| | |State 5 |
| |<-----Create Session KEK_2 | |
|State 5 | | |
| |Negotiate ess. Keys_1----->| |
| | |State 6 |
| |<-----NegotiateSess. Keys_2| |
|State 7 | | |
| |Download Grp Keys--------> | |
| | |State 8 |
| |<----- Key download ack | |
|State 9 | | |
Figure 2: State Diagram: Distribute Keys
|___ネット_コントローラ___|__________メッセージ________|個人のネット_メンバー| | |セッションKEK_1を作成してください。---->|、|、|、| |状態5| | | <、-、-、-、--セッションKEK_2を作成してください。| | |状態5| | | | |essを交渉してください。 キー_1----->|、|、|、| |状態6| | | <、-、-、-、--NegotiateSess。 キー_2| | |状態7| | | | |Grpキーをダウンロードしてください。-------->|、|、|、| |状態8| | | <、-、-、-、-- 主要なダウンロードack| | |状態9| | | 図2: ダイヤグラムを述べてください: キーを分配してください。
described in the following sections.
以下のセクションで、説明されます。
6.2.1 Create Group Keys
6.2.1 グループキーを作成してください。
The first member function for a rekey operation is the same as that for key initialization. Please refer to the group creation section entitled "2.1 Create group keys".
rekey操作のための最初のメンバー機能は主要な初期化のためのそれと同じです。 「2.1個のCreateグループキー」の権利を与えられたグループ作成部を参照してください。
Harney & Muckenhirn Experimental [Page 17] RFC 2093 GKMP Specification July 1997
[17ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
6.2.2 Rekey
6.2.2 Rekey
The purpose of rekey is as follows:
rekeyの目的は以下の通りです:
o send the new GTEK and new GKEK to the other members,
o 新しいGTEKと新しいGKEKを他のメンバーに送ってください。
o allow each member to verify the identify of the controller,
o 各メンバーが確かめるのを許容する、特定、コントローラについて
o allow each member to verify the controllers authorization to
rekey the group, group identification, and GC identification,
o 各メンバーにコントローラ承認について確かめさせて、グループ、グループ識別、およびGC識別をrekeyしてください。
o send the group identity, GC identity, group member identities,
group permissions, and group rekey interval to the other members,
o グループのアイデンティティ、GCのアイデンティティ、グループメンバーのアイデンティティ、グループ許容、およびグループrekey間隔を他のメンバーに送ってください。
The messages to create and negotiate the group keys are the same as stated during group creation. As such they have been omitted here.
グループキーを作成して、交渉するメッセージはグループ作成の間、述べられているのと同じです。 そういうものとして、それらはここで省略されました。
The rekey portion of this function consists of one message between the GC and the other members. The GC builds a signed Rekey_Multicast message for transmission to the other member. As the name implies this
この機能のrekey部分はGCと他のメンバーの間の1つのメッセージから成ります。 GCはもう片方のメンバーへの伝送のため署名しているRekey_Multicastメッセージを築き上げます。 名前がこれを含意するので
|___Net_Controller___|__________Messages________|Net_members,individual|
|The Create Group |<---- Command-Create Group | |
|command is | | |
|received by net | | |
|member A. | | |
|State 1 | | |
| |Create Grp Keys_1----> | |
| | |State 2 |
| |<-----Create Grp Keys_2 | |
|State 2 | | |
| |Negotiate Grp Keys_1------>| |
| | |State 3 |
| |<-----Negotiate Grp Keys_2 | |
|State 4 | | |
| |Rekey _Multicast-------> | |
| | |State 10 |
Figure 3: State Diagram: Rekey
|___ネット_コントローラ___|__________メッセージ________|個人のネット_メンバー| |グループを創設してください。| <、-、-、-- グループをコマンドで創設してください。| | |コマンドはそうです。| | | |ネットで、受信します。| | | |メンバーA。| | | |状態1| | | | |Grpキー_1を作成してください。---->|、|、|、| |状態2| | | <、-、-、-、--Grpキー_2を作成してください。| | |状態2| | | | |Grpキー_1を交渉してください。------>|、|、|、| |状態3| | | <、-、-、-、--Grpキー_2を交渉してください。| | |状態4| | | | |Rekey_マルチキャスト------->|、|、|、| |状態10| 図3: ダイヤグラムを述べてください: Rekey
message can be multicast to the entire group. The GC sends the signed Rekey_Multicast message to the other members encrypted in the current GKEK.
メッセージは全体のグループへのマルチキャストであるかもしれません。 GCは署名しているRekey_Multicastメッセージを現在のGKEKで暗号化された他のメンバーに送ります。
The other members decrypt and validate the signed Rekey_Multicast message and extract the new KP, group identification, GC identification, group members, group permissions, key rekey interval, and rekey command signature. The group identification, GC
他のメンバーは、署名しているRekey_Multicastメッセージを解読して、有効にして、新しいKP、グループ識別、GC識別、グループのメンバー、グループ許容、主要なrekey間隔、およびrekeyコマンド署名を抽出します。 グループ識別、GC
Harney & Muckenhirn Experimental [Page 18] RFC 2093 GKMP Specification July 1997
[18ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
identification, and group permissions fields are validated based on the extracted rekey command signature. If these fields validate, the key database tables are updated.
識別、およびグループ許容分野はそうです。抽出されたrekeyコマンド署名に基づいて、有効にされます。 分野が有効にするこれらであり、主要なデータベースのテーブルをアップデートします。
6.3 Member Initiated Join
メンバーが開始した6.3は接合します。
The GKMP will support member initiated joins to the group. This type of service is most attractive when the group initiator does not need to control group membership other than to verify that all members of the group conform to some previously agreed upon rules.
サポートメンバーが開始したGKMP意志はグループにつなぎます。 グループの創始者がグループのすべてのメンバーが以前に規則で同意されたいくつかに従うことを確かめるのを除いたグループ会員資格を制御する必要はないとき、このタイプのサービスは最も魅力的です。
One example of this type of group is corporations job vacancies. A corporation may want to keep its job vacancies confidential and may decide to encrypt the announcements. The group creator doesn't care who gets the announcements as long as they are in the corporation. When an employee tries to access the information the GC looks at the employees permissions (signed by some higher authority). If they indicate the employee is part of the corporation the controller allows access to the group.
このタイプのグループに関する1つの例が会社仕事の欠員です。 会社は、仕事の欠員を秘密にしたくて、発表を暗号化すると決めるかもしれません。 グループのクリエイターは、会社にそれらがある限り、だれが発表を得るかを気にかけません。 従業員が情報にアクセスしようとするとき、GCは従業員許容(何らかのより高い権威で、署名される)を見ます。 彼らが、従業員が会社の一部であることを示すなら、コントローラはグループへのアクセスを許します。
Before a potential group member can join group operations, they must request the key from the GC, unambiguously identify themselves, pass their permissions, and receive the keys. These require several messages to pass between GC and the joining member. The purpose of these messages are as follows:
潜在的グループのメンバーがグループ操作に参加できる前に、彼らは、GCからキーを要求して、明白に自分たちを特定して、彼らの許容を通過して、キーを受けなければなりません。 これらはGCと接合メンバーの間を通るいくつかのメッセージを必要とします。 これらのメッセージの目的は以下の通りです:
o Request group join from controller
o グループがコントローラから加わるよう要求してください。
o cooperatively generate a SKEK for the transmission of the group
traffic encryption and GKEK from the GC,
o グループトラフィック暗号化とGKEKのトランスミッションのためにGCからSKEKを協力して生成してください。
o allow each member to verify the identify of the controller and
visa versa,
o 各メンバーが確かめるのを許容する、versaをコントローラを特定して、ビザを与えさせてください。
o allow each member to verify the controllers authorization to
create the group,
o 各メンバーにコントローラ承認について確かめさせて、グループを創設してください。
o send the KP, group identity, GC identity, group member identities,
group permissions, and group rekey interval to the other members,
o KP、グループのアイデンティティ、GCのアイデンティティ、グループメンバーのアイデンティティ、グループ許容、およびグループrekey間隔を他のメンバーに送ってください。
The series of messages for a member initiated join is very similar to the series of messages to distribute group keys during group creation. In fact, the series are identical except for the addition of a request to join message sent from the joining member to the controller when the join is member initiated. This message should not require encryption since it probably does not contain sensitive information. However, in some military systems the fact that a member wants to join a group maybe sensitive from a traffic analysis
開始されたメンバーが加わるので、メッセージのシリーズはグループ作成の間にグループキーを分配するメッセージのシリーズと非常に同様です。 事実上、メッセージを接合するのが接合メンバーからコントローラにいつを送ったかという要求の追加を除いて、シリーズが同じである、接合、開始されたメンバーはそうです。 たぶん機密情報を含んでいないので、このメッセージは暗号化を必要とするべきではありません。 しかしながら、いくつかの軍用システムで、メンバーがそうしたがっているという事実はトラヒック分析によって多分敏感なグループに加わります。
Harney & Muckenhirn Experimental [Page 19] RFC 2093 GKMP Specification July 1997
[19ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
viewpoint. In these specialized instances, a pairwise TEK may be created, if one does not already exist, to hide the service request.
観点。 これらの専門化しているインスタンス、TEKがそうする対状では、作成されてください、1つがサービスのリクエストを隠すために既に存在していないなら。
This function consists of seven messages between the GC and the joining member. The first message is created by the joining member and sent to the GC. It simply request membership in the group from the controller. The controller makes the decision whether to respond to the request based on the group parameters - membership limits, membership lists.
この機能はGCと接合メンバーの間の7つのメッセージから成ります。 最初のメッセージを接合メンバーが作成して、GCに送ります。 それはコントローラからグループで会員資格を単に要求します。 コントローラはグループパラメタに基づく要求に応じるかどうかという決定をします--会員資格限界(会員名簿)。
The next messages are for the establishment of a SKEK. This is accomplished by the GC sending a signed Create_Session_KEK_1 message to the other member. This message contains the random value necessary for the other member to generate the SKEK. This message also contains the public key of the GC.
次のメッセージはSKEKの設立のためのものです。 これは署名している_Create_Session KEKに_1つのメッセージを送るGCによってもう片方のメンバーに達成されます。 このメッセージはもう片方のメンバーがSKEKを生成するのに必要な無作為の値を含んでいます。 また、このメッセージはGCの公開鍵を含んでいます。
The other member validates the Create_Session_KEK_1 message, builds and sends a Create_Session_KEK_2 message to the GC, generates the SKEK, and stores the received public key. The Create_Session_KEK_2 message contains the random value necessary for the GC to generate the SKEK. This message also contains the public key of the other member.
もう片方のメンバーは、Create_Session_KEK_1メッセージを有効にして、Create_Session_KEKに_GCへの2メッセージを築き上げて、送って、SKEKを生成して、容認された公開鍵を保存します。 Create_Session_KEK_2メッセージはGCがSKEKを生成するのに必要な無作為の値を含んでいます。 また、このメッセージはもう片方のメンバーの公開鍵を含んでいます。
The GC validates the Create_Session_KEK_2 message, generates the SKEK,
GCはCreate_Session_KEK_2メッセージを有効にして、SKEKを生成します。
|___Net_Controller___|__________Messages________|Net_Members,individual|
| |<------ Request_Group_Join | |
|State 11 | | |
| |Create Session KEK_1----> | |
| | |State 5 |
| |<-----Create Session KEK_2 | |
|State 5 | | |
| |NegotiateSess. Keys_1----->| |
| | |State 6 |
| |<-----NegotiateSess. Keys_2| |
|State 7 | | |
| |Download Grp Keys--------> | |
| | |State 8 |
| |<----- Key download ack | |
|State 9 | | |
Figure 4: State Diagram: Member Join
|___ネット_コントローラ___|__________メッセージ________|個人のネット_メンバー| | | <、-、-、-、-、-- _グループ_が接合するよう要求してください。| | |状態11| | | | |セッションKEK_1を作成してください。---->|、|、|、| |状態5| | | <、-、-、-、--セッションKEK_2を作成してください。| | |状態5| | | | |NegotiateSess。 キー_1----->|、|、|、| |状態6| | | <、-、-、-、--NegotiateSess。 キー_2| | |状態7| | | | |Grpキーをダウンロードしてください。-------->|、|、|、| |状態8| | | <、-、-、-、-- 主要なダウンロードack| | |状態9| | | 図4: ダイヤグラムを述べてください: メンバーは加わります。
builds the Negotiate_Session_ KEK_1 message for transmission to the other member, and stores the received public key.
もう片方のメンバーへの伝送のためNegotiate_Session_KEKに_1つのメッセージを築き上げて、容認された公開鍵を保存します。
The GC sends the Negotiate_Session_KEK_1 message to the other member encrypted in the SKEK that was just generated.
GCは_ただ生成されたSKEKで暗号化されたもう片方のメンバーへの1つのメッセージをNegotiate_Session_KEKに送ります。
Harney & Muckenhirn Experimental [Page 20] RFC 2093 GKMP Specification July 1997
[20ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
The other member decrypts the Negotiate_Session_KEK_1 message and builds a Negotiate_Session_KEK_2 message for transmission to the GC.
もう片方のメンバーは、Negotiate_Session_がKEK_1メッセージであると解読して、GCへの伝送のためNegotiate_Session_KEKに_2メッセージを築き上げます。
The GC receives the Negotiate_Session_KEK_2 message and builds a Download_Grp_Keys message for transmission to the other member.
GCはNegotiate_Session_KEK_2メッセージを受け取って、もう片方のメンバーへの伝送のためDownload_Grp_キーズメッセージを築き上げます。
The GC sends theDownload_Grp_Keys message to the other member encrypted in the SKEK that was just generated. (note: the key used to encrypt the negotiation messages can be combined differently to create the KEK.)
GCはtheDownload_Grp_キーズメッセージをただ生成されたSKEKで暗号化されたもう片方のメンバーに送ります。 (注意: KEKを作成するために交渉メッセージを暗号化するのに使用されるキーは異なって結合できます。)
The other members decrypts theDownload_Grp_Keys message and extracts the KP, group identification, GC identification, group members, group permissions, key rekey interval, and group commanders signature. The group identification, GC identification, and group permissions fields are validated based on the signature. If these fields validate, the other members internal key storage tables are updated with the new keys.
他のメンバーは、theDownload_Grp_キーズメッセージと抽出がKPと、グループ識別と、GC識別と、グループのメンバーと、グループ許容と、主要なrekey間隔と、グループ指揮官署名であると解読します。 グループ識別、GC識別、およびグループ許容分野は署名に基づいて有効にされます。 分野が有効にするこれらであり、新しいキーで内部の主要なストレージがテーブルの上に置く他のメンバーをアップデートします。
6.4 Member Deletion
6.4 メンバー削除
There are two types of member deletion scenarios - cooperative and hostile. The cooperative deletion scenarios is the removal of a trusted group member for some management reason (i.e., reduce group size, prepare the member for a move). The hostile deletion usually results in
2つのタイプのメンバー削除シナリオがあります--協力的であって、敵対的です。 協力的な削除シナリオは何らかの管理理由による信じられたグループのメンバーの解任(すなわち、グループサイズを減少させてください、そして、移動のためにメンバーを用意する)です。 通常、削除がもたらす敵対的
|___Net_Controller___|__________Messages__________|_____Net_Members_____|
| |Delete_Group_Keys ------> | |
| | |State 12 |
| |<------ Grp_Keys_Deleted_Ack| |
|State 9 | | |
Figure 5: State Diagram: Cooperative Delete
|___ネット_コントローラ___|__________メッセージ__________|_____ネット_メンバー_____| | |_グループ_キーを削除してください。------>|、|、|、| |状態12| | | <、-、-、-、-、-- Grp_キー_は_Ackを削除しました。| | |状態9| | | 図5: ダイヤグラムを述べてください: 協力して削除します。
a loss of secure state at the members site (i.e., compromise, equipment breakage).
メンバーサイト(すなわち、感染、設備折損)の安全な状態の損失。
The two scenarios present different challenges to the network. Minimization of network impact is paramount in the cooperative scenario. We would like to leave the key group intact and have confidence that removing the cooperative group member will have no impact on the security of future group operations. In the case of a hostile deletion, the goal is to return to a secure operating state as fast as possible. In fact there is a trade-off. We could eliminate the compromised group as soon as the compromise is discovered, but this may cripple an important asset. So security concerns need to be balanced with operational concerns.
2つのシナリオがネットワークへの異なった挑戦を提示します。 ネットワーク影響の最小化は協力的なシナリオで最高のです。 私たちは、主要なグループを完全なままにし、協同団体のメンバーを免職するのが今後のグループ操作のセキュリティに影響力を全く持たないという信用が欲しいと思います。 敵対的な削除の場合では、目標はできるだけ速く安全な作動状態に戻ることです。 事実上、トレードオフがあります。 感染が発見されるとすぐに、私たちは感染しているグループを排除できましたが、これは重要な資産を無力にするかもしれません。 それで、安全上の配慮は、操作上の関心とバランスをとる必要があります。
Harney & Muckenhirn Experimental [Page 21] RFC 2093 GKMP Specification July 1997
[21ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
6.4.1 Cooperative Deletion
6.4.1 協力的な削除
The cooperative deletion function occurs between a trusted member and the GC. It results in a reliable deletion of the group key encryption and GTEKs at the deleted member. This deletion is intended to be an administrative function.
協力的な削除機能は信じられたメンバーとGCの間に起こります。 それは削除されたメンバーでグループキー暗号化とGTEKsの信頼できる削除をもたらします。 この削除は行政機能であることを意図します。
This function consists of two messages between the GC and the member. The GC sends the Delete_Group_ Keys message to the group, encrypted in the GTEK. The message identifies the member(s) that need to delete the group keys. The member(s) decrypt the Delete_Group_Keys message, extract the group identification, check the deleted member list, deletes the group traffic and key encryption keys for that group, and build the Group_Keys_Deleted_Ack message for transmission to the GC.
この機能はGCとメンバーの間の2つのメッセージから成ります。 GCはDelete_Group_キーズメッセージをGTEKで暗号化されたグループに送ります。 メッセージはグループキーを削除する必要があるメンバーを特定します。 メンバーは、Delete_Group_キーズメッセージを解読して、グループ識別を抽出して、削除されたメンバーリストをチェックして、そのグループのためにグループトラフィックと主要な暗号化キーを削除して、GCへの伝送のためGroup_キーズ_Deleted_Ackメッセージを築き上げます。
The Grp_Keys_Deleted_Ack message is encrypted in the group traffic key. The GC receives the Grp_Keys_Deleted_Ack message, decrypts it, and updates the group definition.
Grp_キーズ_Deleted_Ackメッセージはグループトラフィックキーで暗号化されます。 GCはGrp_キーズ_Deleted_Ackメッセージを受け取って、それを解読して、グループ定義をアップデートします。
|___Net_Controller___|__________Messages____________|_____Net_Members__|
| |Delete_Group_Keys ------> | |
| | |State 13 |
Figure 6: State Diagram: Hostile Delete
|___ネット_コントローラ___|__________メッセージ____________|_____ネット_メンバー__| | |_グループ_キーを削除してください。------>|、|、|、| |状態13| 図6: ダイヤグラムを述べてください: 敵対的である、削除
6.4.2 Hostile Deletion (Compromise)
6.4.2 敵対的な削除(感染)
Hostile deletion occurs when a the group losses trust in a member. We assume that all keys resident at the members site have been lost. We also assume the member will not cooperate. Therefor, we must essentially create another group, minus the untrusted member, and transfer group operations to that new group. When the group losses trust in the controller, another controller must be appointed and then the hostile deletion process can proceed.
グループの損失がメンバーを信じるとき、敵対的な削除は起こります。 私たちは、メンバーサイトのすべてのキーの居住者が迷子になったと思います。 また、私たちは、メンバーが協力しないと思います。 そのために、私たちは、本質的には信頼されていないメンバーを引いて別のグループを創設して、その新しいグループにグループ操作を移さなければなりません。 グループの損失がコントローラを信じるとき、別のコントローラを任命しなければなりません、そして、次に、敵対的な削除プロセスは続くことができます。
There are some security and operational management issues surrounding compromise recovery. The essence of the issues involve a tradeoff between operational continuity and security vulnerability. If a member is found to be bad, from a security point of view all traffic on the network should stop. However, if that traffic is supporting a critical operation, the group may prefer to live with the security leak rather than interrupt the group communication.
感染回復を囲む何らかのセキュリティと運営管理問題があります。 問題の本質は操作上の連続とセキュリティの脆弱性の間の見返りにかかわります。 メンバーが悪いのがわかっているなら、セキュリティ観点から、ネットワークにおけるすべての通行が止まるべきです。 しかしながら、そのトラフィックが重要な操作をサポートしているなら、グループは、グループコミュニケーションを中断するよりむしろ安全保障機密の漏洩を受け入れるのを好むかもしれません。
Harney & Muckenhirn Experimental [Page 22] RFC 2093 GKMP Specification July 1997
[22ページ]RFC2093GKMP仕様1997年7月に実験的なハーニーとMuckenhirn
The GKMP provides two mechanisms to help restrict access of compromised members. First, it implements a Certificate Revocation List (CRL) which is checked during the group creation process. Thus it will not allow a compromised member to be included in a new group. Second, the GKMP facilitates the creation of another group (minus the compromised member(s)). However, it does not dictate whether or not the group may continue to operate with a compromised member.
GKMPは、感染しているメンバーのアクセスを制限するのを助けるために2つのメカニズムを提供します。 まず最初に、それはグループ作成プロセスの間にチェックされるCertificate Revocation List(CRL)を実装します。 したがって、それで、感染しているメンバーは新しいグループが包含しないでしょう。 2番目、GKMPは別のグループの創設を容易にします。(感染しているメンバー(s))を引いて。 しかしながら、それは、グループが、感染しているメンバーと共に作動し続けるかもしれないかどうかと決めません。
The mechanism the GKMP uses to remove a compromised member is to key that member out. This entails creating a new group, without the compromised member, and switching group operations. The old group is canceled by several multicasts of a group delete message.
GKMPが感染しているメンバーを免職するのに使用するメカニズムはそのメンバーを外に合わせることです。 これは、感染しているメンバーなしで新しいグループを創設して、グループ操作を切り換えるのを伴います。 古いグループは取り消されて、グループのいくつかのマルチキャストがメッセージを削除するということです。
This function consists of one message from the GC to all members. The GC sends the Delete_Group message to all members encrypted in the GTEK. This results in the deletion of the group traffic and key encryption keys in all group members. All members decrypt the received Delete_Group message, validate the authorization, extracts the group identification, and delete the group traffic and key encryption keys.
この機能は1つのGCからすべてのメンバーまでのメッセージから成ります。 GCはDelete_GroupメッセージをGTEKで暗号化されたすべてのメンバーに送ります。 これはすべてのグループのメンバーでのグループトラフィックと主要な暗号化キーの削除をもたらします。 すべてのメンバーが、受信されたDelete_Groupメッセージを解読して、承認を有効にして、グループ識別を抽出して、グループトラフィックと主要な暗号化キーを削除します。
7 Security Conditions
7つの治安状況
This document, in entirety, concerns security.
全体では、このドキュメントはセキュリティに関係があります。
8 Addresses of Authors
作者の8つのアドレス
Hugh Harney SPARTA, Inc. Secure Systems Engineering Division 9861 Broken Land Parkway, Suite 300 Columbia, MD 21046-1170 United States Phone: +1 410 381 9400 (ext. 203) EMail: hh@columbia.sparta.com
安全なシステム工学事業部9861起伏の多いLandスイート300コロンビア、MD21046-1170パークウェイ(合衆国)が電話をするヒューハーニースパルタInc.: +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 Phone: +1 410 381 9400 (ext. 208) EMail: cfm@columbia.sparta.com
安全なシステム工学事業部9861起伏の多いLandスイート300コロンビア、MD21046-1170パークウェイ(合衆国)が電話をするカールMuckenhirnスパルタInc.: +1 410 381 9400 (ext。 208) メール: cfm@columbia.sparta.com
Harney & Muckenhirn Experimental [Page 23]
ハーニーとMuckenhirn実験的です。[23ページ]
一覧
スポンサーリンク
