[要約] RFC 4046は、マルチキャストセキュリティ（MSEC）グループキー管理アーキテクチャに関するものであり、マルチキャストグループのセキュリティを確保するためのキー管理の仕組みを提案しています。このRFCの目的は、マルチキャストグループのセキュリティを向上させるための効果的なキー管理アーキテクチャを提供することです。
Network Working Group M. Baugher
Request for Comments: 4046 Cisco
Category: Informational R. Canetti
IBM
L. Dondeti
Qualcomm
F. Lindholm
Ericsson
April 2005
Multicast Security (MSEC) Group Key Management Architecture
マルチキャストセキュリティ（MSEC）グループキー管理アーキテクチャ
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document defines the common architecture for Multicast Security (MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication.
このドキュメントでは、さまざまなアプリケーション、トランスポート、ネットワークレイヤーセキュリティプロトコルをサポートするために、マルチキャストセキュリティ（MSEC）の主要な管理プロトコルの共通アーキテクチャを定義しています。また、Group Security Association（GSA）を定義し、GSAの確立に役立つ主要な管理プロトコルについて説明します。このドキュメントで説明されているフレームワークとガイドラインは、アプリケーションのニーズに特化したさまざまなさまざまな設定のグループキー管理プロトコルのモジュール式で柔軟な設計を許可します。MSEC主要な管理プロトコルを使用して、1対多、多目的、または1対1のコミュニケーションを安全に促進できます。
Table of Contents
目次
1. Introduction: Purpose of this Document ..........................2
2. Requirements of a Group Key Management Protocol .................4
3. Overall Design of Group Key Management Architecture .............6
3.1. Overview ...................................................6
3.2. Detailed Description of the GKM Architecture ...............8
3.3. Properties of the Design ..................................11
3.4. Group Key Management Block Diagram ........................11
4. Registration Protocol ..........................................13
4.1. Registration Protocol via Piggybacking or Protocol Reuse ..13
4.2. Properties of Alternative Registration Exchange Types .....14
4.3. Infrastructure for Alternative Registration
Exchange Types ............................................15
4.4. De-registration Exchange ..................................16
5. Rekey Protocol .................................................16
5.1. Goals of the Rekey Protocol ...............................17
5.2. Rekey Message Transport and Protection ....................17
5.3. Reliable Transport of Rekey Messages ......................18
5.4. State-of-the-art on Reliable Multicast Infrastructure .....20
5.5. Implosion .................................................21
5.6. Incorporating Group Key Management Algorithms .............22
5.7. Stateless, Stateful, and Self-healing Rekeying
Algorithms ................................................22
5.8. Interoperability of a GKMA ................................23
6. Group Security Association .....................................24
6.1. Group Policy ..............................................24
6.2. Contents of the Rekey SA ..................................25
6.2.1. Rekey SA Policy ....................................26
6.2.2. Group Identity .....................................27
6.2.3. KEKs ...............................................27
6.2.4. Authentication Key .................................27
6.2.5. Replay Protection ..................................27
6.2.6. Security Parameter Index (SPI) .....................27
6.3. Contents of the Data SA ...................................27
6.3.1. Group Identity .....................................28
6.3.2. Source Identity ....................................28
6.3.3. Traffic Protection Keys ............................28
6.3.4. Data Authentication Keys ...........................28
6.3.5. Sequence Numbers ...................................28
6.3.6. Security Parameter Index (SPI) .....................28
6.3.7. Data SA Policy .....................................28
7. Scalability Considerations .....................................29
8. Security Considerations ........................................31
9. Acknowledgments ................................................32
10. Informative References ........................................33
This document defines a common architecture for Multicast Security (MSEC) key management protocols to support a variety of application-, transport-, and network-layer security protocols. It also defines the group security association (GSA) and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication.
このドキュメントでは、マルチキャストセキュリティ（MSEC）の一般的なアーキテクチャを定義して、さまざまなアプリケーション、トランスポート、およびネットワークレイヤーセキュリティプロトコルをサポートする主要な管理プロトコルです。また、グループセキュリティ協会（GSA）を定義し、GSAの確立に役立つ主要な管理プロトコルについて説明します。このドキュメントで説明されているフレームワークとガイドラインは、アプリケーションのニーズに特化したさまざまなさまざまな設定のグループキー管理プロトコルのモジュール式で柔軟な設計を許可します。MSEC主要な管理プロトコルを使用して、1対多、多目的、または1対1のコミュニケーションを安全に促進できます。
Group and multicast applications in IP networks have diverse security requirements [TAXONOMY]. Their key management requirements, briefly reviewed in Section 2.0, include support for internetwork-, transport- and application-layer security protocols. Some applications achieve simpler operation by running key management messaging over a pre-established secure channel (e.g., TLS or IPsec). Other security protocols benefit from a key management protocol that can run over an already-deployed session initiation or management protocol (e.g., SIP or RTSP). Finally, some benefit from a lightweight key management protocol that requires few round trips. For all these reasons, application-, transport-, and IP-layer data security protocols (e.g., SRTP [RFC3711] and IPsec [RFC2401]) benefit from different group key management systems. This document defines a common architecture and design for all group key management (GKM) protocols.
IPネットワークのグループおよびマルチキャストアプリケーションには、さまざまなセキュリティ要件があります[分類]。セクション2.0で簡単にレビューされている主要な管理要件には、インターネットワーク、輸送、アプリケーションレイヤーのセキュリティプロトコルのサポートが含まれています。一部のアプリケーションは、事前に確立された安全なチャネル（TLSやIPSECなど）でキー管理メッセージを実行することにより、より簡単な操作を実現します。他のセキュリティプロトコルは、すでに展開されているセッションの開始または管理プロトコル（SIPやRTSPなど）を実行できる主要な管理プロトコルの恩恵を受けます。最後に、ラウンド旅行はほとんど必要ない軽量の主要な管理プロトコルの恩恵を受けることができます。これらすべての理由により、アプリケーション、トランスポート、およびIP層データセキュリティプロトコル（例：SRTP [RFC3711]およびIPSEC [RFC2401]））は、さまざまなグループキー管理システムの恩恵を受けます。このドキュメントでは、すべてのグループキー管理（GKM）プロトコルの共通のアーキテクチャと設計を定義しています。
This common architecture for group key management is called the MSEC group key management architecture. It is based on the group control or key server model developed in GKMP [RFC2094] and assumed by group key management algorithms such as LKH [RFC2627], OFT [OFT], and MARKS [MARKS]. There are other approaches that are not considered in this architecture, such as the highly distributed Cliques group key management protocol [CLIQUES] or broadcast key management schemes [FN93,Wool]. MSEC key management may in fact be complementary to other group key management designs, but the integration of MSEC group key management with Cliques, broadcast key management, or other group key systems is not considered in this document.
グループキー管理のこの一般的なアーキテクチャは、MSEC Group Key Management Architectureと呼ばれます。これは、GKMP [RFC2094]で開発されたグループコントロールまたはキーサーバーモデルに基づいており、LKH [RFC2627]、OFT [MAKS]などのグループキー管理アルゴリズムによって想定されています。このアーキテクチャでは考慮されていない他のアプローチがあります。たとえば、高度に分散されたクリークグループキー管理プロトコル[クリーク]やキー管理スキーム[FN93、ウール]をブロードキャストします。MSEC Key Managementは、実際には他のグループキー管理デザインを補完する可能性がありますが、MSECグループキー管理のクリーク、ブロードキャストキー管理、または他のグループキーキーシステムとの統合は、このドキュメントでは考慮されていません。
Key management protocols are difficult to design and validate. The common architecture described in this document eases this burden by defining common abstractions and an overall design that can be specialized for different uses.
主要な管理プロトコルを設計および検証することは困難です。このドキュメントで説明されている一般的なアーキテクチャは、一般的な抽象化と、さまざまな用途に特化できる全体的な設計を定義することにより、この負担を緩和します。
This document builds on and extends the Group Key Management Building Block document of the IRTF SMuG research group [GKMBB] and is part of the MSEC document roadmap. The MSEC architecture [MSEC-Arch] defines a complete multicast or group security architecture, of which key management is a component.
このドキュメントは、IRTF Smug Research Group [GKMBB]のグループキー管理ビルディングブロックドキュメントに基づいて拡張され、MSECドキュメントロードマップの一部です。MSECアーキテクチャ[MSEC-ARCH]は、主要な管理がコンポーネントである完全なマルチキャストまたはグループセキュリティアーキテクチャを定義しています。
The rest of this document is organized as follows. Section 2 discusses the security, performance and architectural requirements for a group key management protocol. Section 3 presents the overall architectural design principles. Section 4 describes the registration protocol in detail, and Section 5 does the same for rekey protocol. Section 6 considers the interface to the Group Security Association (GSA). Section 7 reviews the scalability issues for group key management protocols and Section 8 discusses security considerations.
このドキュメントの残りの部分は、次のように整理されています。セクション2では、グループキー管理プロトコルのセキュリティ、パフォーマンス、およびアーキテクチャの要件について説明します。セクション3では、全体的なアーキテクチャデザインの原則を紹介します。セクション4では、登録プロトコルについて詳しく説明し、セクション5ではRekeyプロトコルについても同じことを行います。セクション6では、グループセキュリティ協会（GSA）へのインターフェイスを検討します。セクション7では、グループキー管理プロトコルのスケーラビリティの問題を確認し、セクション8でセキュリティ上の考慮事項について説明します。
A group key management (GKM) protocol supports protected communication between members of a secure group. A secure group is a collection of principals, called members, who may be senders, receivers, or both receivers and senders to other members of the group. Group membership may vary over time. A group key management protocol helps to ensure that only members of a secure group can gain access to group data (by gaining access to group keys) and can authenticate group data. The goal of a group key management protocol is to provide legitimate group members with the up-to-date cryptographic state they need for secrecy and authentication.
グループキー管理（GKM）プロトコルは、安全なグループのメンバー間の保護されたコミュニケーションをサポートします。安全なグループとは、メンバーと呼ばれる校長のコレクションであり、グループの他のメンバーへの送信者、受信者、または送信者の両方になる可能性があります。グループメンバーシップは時間とともに異なる場合があります。グループキー管理プロトコルは、安全なグループのメンバーのみがグループデータにアクセスできるように（グループキーへのアクセスを取得し、グループデータを認証できるようにするのに役立ちます。グループキー管理プロトコルの目標は、合法的なグループメンバーに、秘密と認証に必要な最新の暗号化状態を提供することです。
Multicast applications, such as video broadcast and multicast file transfer, typically have the following key management requirements (see also [TAXONOMY]). Note that the list is neither applicable to all applications nor exhaustive.
ビデオ放送やマルチキャストファイル転送などのマルチキャストアプリケーションには、通常、次の主要な管理要件があります（[分類]も参照）。リストは、すべてのアプリケーションにも網羅的でもないことに注意してください。
1. Group members receive security associations that include encryption keys, authentication/integrity keys, cryptographic policy that describes the keys, and attributes such as an index for referencing the security association (SA) or particular objects contained in the SA.
1. グループメンバーは、暗号化キー、認証/整合性キー、キーを記述する暗号化ポリシー、およびセキュリティ協会（SA）を参照するためのインデックスやSAに含まれる特定のオブジェクトなどの属性を含むセキュリティ協会を受け取ります。
2. In addition to the policy associated with group keys, the group owner or the Group Controller and Key Server (GCKS) may define and enforce group membership, key management, data security, and other policies that may or may not be communicated to the entire membership.
2. グループキーに関連付けられたポリシーに加えて、グループ所有者またはグループコントローラーおよびキーサーバー（GCKS）は、グループメンバーシップ、キー管理、データセキュリティ、およびメンバーシップ全体に伝えられる場合または通信されない可能性のあるその他のポリシーを定義および実施することができます。。
3. Keys will have a pre-determined lifetime and may be periodically refreshed.
3. キーには、寿命がかかると定期的に更新される場合があります。
4. Key material should be delivered securely to members of the group so that they are secret, integrity-protected and verifiably obtained from an authorized source.
4. 主要な資料は、グループのメンバーに安全に配信する必要があります。そうすれば、秘密で整合性保護され、認証されたソースから検証可能になります。
5. The key management protocol should be secure against replay attacks and Denial of Service(DoS) attacks (see the Security Considerations section of this memo).
5. 主要な管理プロトコルは、リプレイ攻撃とサービス拒否（DOS）攻撃に対して安全でなければなりません（このメモのセキュリティに関する考慮事項セクションを参照）。
6. The protocol should facilitate addition and removal of group members. Members who are added may optionally be denied access to the key material used before they joined the group, and removed members should lose access to the key material following their departure.
6. プロトコルは、グループメンバーの追加と除去を容易にする必要があります。追加されたメンバーは、オプションでグループに参加する前に使用される主要な資料へのアクセスを拒否される場合があり、削除されたメンバーは、出発後に重要な資料へのアクセスを失う必要があります。
7. The protocol should support a scalable group rekey operation without unicast exchanges between members and a Group Controller and Key Server (GCKS), to avoid overwhelming a GCKS managing a large group.
7. このプロトコルは、大規模なグループを管理するGCKを圧倒しないように、メンバーとグループコントローラーとキーサーバー（GCKS）の間のユニキャスト交換なしでスケーラブルなグループReke操作をサポートする必要があります。
8. The protocol should be compatible with the infrastructure and performance needs of the data security application, such as the IPsec security protocols AH and ESP, and/or application layer security protocols such as SRTP [RFC3711].
8. プロトコルは、IPSECセキュリティプロトコルAHやESPなどのデータセキュリティアプリケーションのインフラストラクチャとパフォーマンスのニーズと、SRTP [RFC3711]などのアプリケーションレイヤーセキュリティプロトコルと互換性がある必要があります。
9. The key management protocol should offer a framework for replacing or renewing transforms, authorization infrastructure, and authentication systems.
9. 主要な管理プロトコルは、変換、承認インフラストラクチャ、および認証システムを交換または更新するためのフレームワークを提供する必要があります。
10. The key management protocol should be secure against collusion among excluded members and non-members. Specifically, collusion must not result in attackers gaining any additional group secrets than each of them individually are privy to. In other words, combining the knowledge of the colluding entities must not result in revealing additional group secrets.
10. 主要な管理プロトコルは、除外されたメンバーと非会員の間の共謀に対して安全でなければなりません。具体的には、共謀により、攻撃者がそれぞれが個人的に秘密になっているよりも追加のグループの秘密を獲得してはなりません。言い換えれば、共謀するエンティティの知識を組み合わせることで、追加のグループ秘密が明らかにされてはなりません。
11. The key management protocol should provide a mechanism to securely recover from a compromise of some or all of the key material.
11. 主要な管理プロトコルは、重要な資料の一部またはすべての妥協から安全に回復するメカニズムを提供する必要があります。
12. The key management protocol may need to address real-world deployment issues such as NAT-traversal and interfacing with legacy authentication mechanisms.
12. 主要な管理プロトコルは、NATトラバーサルやレガシー認証メカニズムとのインターフェースなどの実際の展開の問題に対処する必要がある場合があります。
In contrast to typical unicast key and SA negotiation protocols such as TLS and IKE, multicast group key management protocols provide SA and key download capability. This feature may be useful for point-to-point as well as multicast communication, so that a group key management protocol may be useful for unicast applications. Group key management protocols may be used for protecting multicast or unicast communications between members of a secure group. Secure sub-group communication is also plausible using the group SA.
TLSやIKEなどの典型的なユニキャストキーおよびSAネゴシエーションプロトコルとは対照的に、マルチキャストグループキー管理プロトコルはSAおよびキーダウンロード機能を提供します。この機能は、マルチキャスト通信だけでなく、ポイントツーポイントにも役立つ場合があるため、グループキー管理プロトコルがユニキャストアプリケーションに役立つ場合があります。グループキー管理プロトコルは、安全なグループのメンバー間のマルチキャストまたはユニキャスト通信を保護するために使用できます。セキュアなサブグループ通信も、グループSAを使用してもっともらしいです。
There are other requirements for small group operation with many all members as potential senders. In this case, the group setup time may need to be optimized to support a small, highly interactive group environment [RFC2627].
潜在的な送信者として多くのすべてのメンバーがおり、小グループ操作には他の要件があります。この場合、小さなインタラクティブなグループ環境をサポートするために、グループのセットアップ時間を最適化する必要がある場合があります[RFC2627]。
The current key management architecture covers secure communication in large single-sender groups, such as source-specific multicast groups. Scalable operation to a range of group sizes is also a desirable feature, and a better group key management protocol will support large, single-sender groups as well as groups that have many senders. It may be that no single key management protocol can satisfy the scalability requirements of all group-security applications.
現在の主要な管理アーキテクチャは、ソース固有のマルチキャストグループなど、大規模なシングルセンダーグループの安全な通信をカバーしています。グループサイズの範囲へのスケーラブルな操作も望ましい機能であり、より優れたグループキー管理プロトコルは、大規模なシングルセンダーグループと多くの送信者がいるグループをサポートします。すべてのグループセキュリティアプリケーションのスケーラビリティ要件を満たすことができない単一の主要な管理プロトコルがない場合があります。
It is useful to emphasize two non-requirements: technical protection measures (TPM) [TPM] and broadcast key management. TPM are used for such things as copy protection by preventing the device user from getting easy access to the group keys. There is no reason why a group key management protocol cannot be used in an environment where the keys are kept in a tamper-resistant store, using various types of hardware or software to implement TPM. For simplicity, however, the MSEC key management architecture described in this document does not consider design for technical protection.
技術保護対策（TPM）[TPM]と放送キー管理の2つの非要約を強調すると便利です。TPMは、デバイスユーザーがグループキーに簡単にアクセスできないようにすることにより、コピー保護などに使用されます。さまざまなタイプのハードウェアまたはソフトウェアを使用してTPMを実装する、キーが改ざん耐性ストアにキーが保持されている環境でグループキー管理プロトコルを使用できない理由はありません。ただし、簡単にするために、このドキュメントで説明されているMSECキー管理アーキテクチャは、技術的保護のための設計を考慮していません。
The second non-requirement is broadcast key management when there is no back channel [FN93,JKKV94] or for a non-networked device such as a digital videodisc player. We assume IP network operation with two-way communication, however asymmetric, and authenticated key-exchange procedures that can be used for member registration. Broadcast applications may use a one-way Internet group key management protocol message and a one-way rekey message, as described below.
2番目の非追跡は、バックチャネル[FN93、JKKV94]がない場合、またはデジタルVideoDiscプレーヤーなどのネットワーク以外のデバイスの場合、ブロードキャストキー管理です。メンバー登録に使用できる、非対称で認証されたキーエクスチェンジ手順を備えた双方向通信を備えたIPネットワーク操作を想定しています。ブロードキャストアプリケーションは、以下で説明するように、一方向のインターネットグループキー管理プロトコルメッセージと一元配置リキーメッセージを使用する場合があります。
The overall group key management architecture is based upon a group controller model [RFC2093,RFC2094,RFC2627,OFT,GSAKMP,RFC3547] with a single group owner as the root-of-trust. The group owner designates a group controller for member registration and GSA rekeying.
グループ全体のキー管理アーキテクチャは、グループコントローラーモデル[RFC2093、RFC2094、RFC2627、OFT、GSAKMP、RFC3547]に基づいています。グループの所有者は、メンバー登録とGSAの再キーイングのグループコントローラーを指定します。
The main goal of a group key management protocol is to securely provide group members with an up-to-date security association (SA), which contains the needed information for securing group communication (i.e., the group data). We call this SA the Data SA. In order to obtain this goal, the group key management architecture defines the following protocols.
グループキー管理プロトコルの主な目標は、グループメンバーにグループ通信を確保するために必要な情報（つまり、グループデータ）を含む最新のセキュリティ協会（SA）を安全に提供することです。これをデータSAと呼びます。この目標を得るために、グループキー管理アーキテクチャは次のプロトコルを定義します。
(1) Registration Protocol
(1) 登録プロトコル
This is a unicast protocol between the Group Controller and Key Server (GCKS) and a joining group member. In this protocol, the GCKS and joining member mutually authenticate each other. If the authentication succeeds and the GCKS finds that the joining member is authorized, then the GCKS supplies the joining member with the following information: (a) Sufficient information to initialize the Data SA within the joining member. This information is given only if the group security policy calls for initializing the Data SA at registration, instead of, or in addition to, as part of the rekey protocol.
これは、グループコントローラーとキーサーバー（GCKS）と参加グループメンバーの間のユニキャストプロトコルです。このプロトコルでは、GCKSと参加者に参加して相互に認証します。認証が成功し、GCKSが参加メンバーが承認されていることを発見した場合、GCKSは参加メンバーに次の情報を提供します。（a）参加メンバー内のデータSAを初期化するのに十分な情報。この情報には、グループセキュリティポリシーが、Rekeyプロトコルの一部として、またはそれに加えて、登録時にデータSAを初期化することを要求する場合にのみ提供されます。
(b) Sufficient information to initialize a Rekey SA within the joining member (see more details about this SA below). This information is given if the group security policy calls for a rekey protocol.
(b) 参加メンバー内のReke SAを初期化するのに十分な情報（このSAの詳細については、以下の詳細を参照してください）。この情報は、グループセキュリティポリシーがRekeyプロトコルを要求する場合に提供されます。
The registration protocol must ensure that the transfer of information from GCKS to member is done in an authenticated and confidential manner over a security association. We call this SA the Registration SA. A complementary de-registration protocol serves to explicitly remove Registration SA state. Members may choose to delete Registration SA state.
登録プロトコルは、GCKSからメンバーへの情報の転送が、セキュリティ協会よりも認証された機密方法で行われることを保証する必要があります。これを登録SAと呼びます。補完的な解体プロトコルは、登録SA状態を明示的に削除するのに役立ちます。メンバーは、登録SA状態を削除することを選択できます。
(2) Rekey Protocol
(2) Rekeyプロトコル
A GCKS may periodically update or change the Data SA, by sending rekey information to the group members. Rekey messages may result from group membership changes, from changes in group security policy, from the creation of new traffic-protection keys (TPKs, see next section) for the particular group, or from key expiration. Rekey messages are protected by the Rekey SA, which is initialized in the registration protocol. They contain information for updating the Rekey SA and/or the Data SA and can be sent via multicast to group members or via unicast from the GCKS to a particular group member.
GCKSは、グループメンバーにReky情報を送信することにより、定期的にデータSAを更新または変更できます。Rekeyメッセージは、グループメンバーシップの変更、グループセキュリティポリシーの変更、特定のグループの新しい交通保護キー（TPK、次のセクションを参照）の作成、またはキーの有効期限から生じる場合があります。Rekeyメッセージは、Reke SAによって保護されており、登録プロトコルで初期化されています。これらには、Reke SAおよび/またはデータSAを更新するための情報が含まれており、マルチキャストを介してグループメンバーに、またはGCKSから特定のグループメンバーへのユニキャストを介して送信できます。
Note that there are other means for managing (e.g., expiring or refreshing) the Data SA without interaction between the GCKS and the members. For example in MARKS [MARKS], the GCKS pre-determines TPKs for different periods in the lifetime of the secure group and distributes keys to members based on their membership periods. Alternative schemes such as the GCKS disbanding the secure group and starting a new group with a new Data SA are also possible, although this is typically limited to small groups.
GCKSとメンバー間の相互作用なしにデータSAを管理する（例：期限切れまたは更新）他の手段があることに注意してください。たとえば、Marks [Marks]では、GCKは安全なグループの生涯のさまざまな期間にわたってTPKを事前に決定し、メンバーシップ期間に基づいてメンバーにキーを配布します。安全なグループを解散し、新しいデータSAを使用して新しいグループを開始するなどの代替スキームも可能ですが、これは通常小グループに限定されます。
Rekey messages are authenticated using one of the two following options:
Rekeyメッセージは、次の2つのオプションのいずれかを使用して認証されます。
(1) Using source authentication [TAXONOMY], that is, enabling each group member to verify that a rekey message originates with the GCKS and none other.
(1) Source Authentication [Taxonomy]を使用して、各グループメンバーがGCKSおよび他のものから発生していることを確認できるようにします。
(2) Using only group-based authentication with a symmetric key. Members can only be assured that the rekey messages originated within the group. Therefore, this is applicable only when all members of the group are trusted not to impersonate the GCKS. Group authentication for rekey messages is typically used when public-key cryptography is not suitable for the particular group.
(2) 対称キーを使用したグループベースの認証のみを使用します。メンバーは、グループ内で発信されたRekeyメッセージのみを保証できます。したがって、これは、グループのすべてのメンバーがGCKになりすまさないと信頼されている場合にのみ適用されます。Public-Key Cryptographyが特定のグループに適していない場合、Rekeyメッセージのグループ認証は通常使用されます。
The rekey protocol ensures that all members receive the rekey information in a timely manner. In addition, the rekey protocol specifies mechanisms for the parties to contact the GCKS and re-synch if their keys expired and an updated key has not been received. The rekey protocol for large-scale groups offers mechanisms to avoid implosion problems and to ensure reliability in its delivery of keying material.
Rekeyプロトコルは、すべてのメンバーがタイムリーにReke情報を受け取ることを保証します。さらに、REKEYプロトコルは、鍵が期限切れになり、更新されたキーが受信されていない場合、GCKSに連絡して再シンチするためのメカニズムを指定します。大規模なグループ向けのRekeyプロトコルは、崩壊の問題を回避し、キーイング材料の提供における信頼性を確保するためのメカニズムを提供します。
Although the Rekey SA is established by the registration protocol, it is updated using a rekey protocol. When a member leaves the group, it destroys its local copy of the GSA. Using a de-registration message may be an efficient way for a member to inform the GCKS that it has destroyed, or is about to destroy, the SAs. Such a message may prompt the GCKS to cryptographically remove the member from the group (i.e., to prevent the member from having access to future group communication). In large-scale multicast applications, however, de-registration can potentially cause implosion at the GCKS.
Reke SAは登録プロトコルによって確立されていますが、Rekeyプロトコルを使用して更新されます。メンバーがグループを去ると、GSAのローカルコピーを破壊します。登録解除メッセージを使用することは、メンバーがSASを破壊した、または破壊しようとしていることをGCKSに通知するための効率的な方法かもしれません。このようなメッセージは、GCKSにグループからメンバーを暗号化するように促す場合があります（つまり、メンバーが将来のグループコミュニケーションにアクセスできないようにします）。ただし、大規模なマルチキャストアプリケーションでは、登録解除はGCKSに崩壊を引き起こす可能性があります。
Figure 1 depicts the overall design of a GKM protocol. Each group member, sender or receiver, uses the registration protocol to get authorized and authenticated access to a particular Group, its policies, and its keys. The two types of group keys are the key encryption keys (KEKs) and the traffic encryption keys (TEKs). For group authentication of rekey messages or data, key integrity or traffic integrity keys may be used, as well. We use the term protection keys to refer to both integrity and encryption keys. For example, the term traffic protection key (TPK) is used to denote the combination of a TEK and a traffic integrity key, or the key material used to generate them.
図1は、GKMプロトコルの全体的な設計を示しています。各グループメンバーである送信者または受信者は、登録プロトコルを使用して、特定のグループ、そのポリシー、およびそのキーへの許可され認証されたアクセスを取得します。2種類のグループキーは、キー暗号化キー（KEK）とトラフィック暗号化キー（TEK）です。Rekeyメッセージまたはデータのグループ認証には、主要な整合性またはトラフィックインテグリティキーも使用できます。保護キーという用語を使用して、完全性キーと暗号化キーの両方を参照します。たとえば、The Traffic Protection Key（TPK）という用語は、TEKとトラフィックインテグリティキーの組み合わせ、またはそれらを生成するために使用されるキー資料を示すために使用されます。
The KEK may be a single key that protects the rekey message, typically containing a new Rekey SA (containing a KEK) and/or Data SA (containing a TPK/TEK). A Rekey SA may also contain a vector of keys that are part of a group key membership algorithm [RFC2627,OFT,TAXONOMY,SD1,SD2]. The data security protocol uses TPKs to protect streams, files, or other data sent and received by the data security protocol. Thus the registration protocol and/or the rekey protocol establish the KEK(s) and/or the TPKs.
KEKは、通常、新しいReke SA（KEKを含む）および/またはデータSA（TPK/TEKを含む）を含むRekeメッセージを保護する単一のキーである可能性があります。Rekey SAには、グループキーメンバーシップアルゴリズム[RFC2627、OFT、Taxonomy、SD1、SD2]の一部であるキーのベクトルも含まれている場合があります。データセキュリティプロトコルは、TPKを使用して、データセキュリティプロトコルによって送信および受信されたストリーム、ファイル、またはその他のデータを保護します。したがって、登録プロトコルおよび/またはRekeyプロトコルは、KEKおよび/またはTPKを確立します。
+------------------------------------------------------------------+
| +-----------------+ +-----------------+ |
| | POLICY | | AUTHORIZATION | |
| | INFRASTRUCTURE | | INFRASTRUCTURE | |
| +-----------------+ +-----------------+ |
| ^ ^ |
| | | |
| v v |
| +--------------------------------------------------------------+ |
| | | |
| | +--------------------+ | |
| | +------>| GCKS |<------+ | |
| | | +--------------------+ | | |
| | REGISTRATION or | REGISTRATION or | |
| | DE-REGISTRATION | DE-REGISTRATION | |
| | PROTOCOL | PROTOCOL | |
| | | | | | |
| | v REKEY v | |
| | +-----------------+ PROTOCOL +-----------------+ | |
| | | | (OPTIONAL) | | | |
| | | SENDER(S) |<-------+-------->| RECEIVER(S) | | |
| | | | | | | |
| | +-----------------+ +-----------------+ | |
| | | ^ | |
| | v | | |
| | +-------DATA SECURITY PROTOCOL-------+ | |
| | | |
| +--------------------------------------------------------------+ |
| |
+------------------------------------------------------------------+
Figure 1: Group Security Association Model
図1：グループセキュリティ協会モデル
There are a few distinct outcomes to a successful registration Protocol exchange.
登録プロトコル交換の成功には、いくつかの明確な結果があります。
o If the GCKS uses rekey messages, then the admitted member receives the Rekey SA. The Rekey SA contains the group's rekey policy (note that not all of the policy need to be revealed to members), and at least a group KEK. In addition, the GCKS sends a group key integrity key for integrity protection of rekey messages. If a group key management algorithm is used for efficient rekeying, the GCKS also sends one or more KEKs as specified by the key distribution policy of the group key management algorithm.
o GCKSがRekeyメッセージを使用する場合、入院したメンバーはRekey SAを受け取ります。Rekey SAには、グループのRekeyポリシーが含まれています（すべてのポリシーをメンバーに明らかにする必要はないことに注意してください）、少なくともグループKek。さらに、GCKSは、Rekeyメッセージの整合性保護のためのグループキーの整合性キーを送信します。Group Key Management Algorithmが効率的な再キーイングに使用される場合、GCKSは、グループキー管理アルゴリズムの主要な分布ポリシーで指定された1つ以上のKEKを送信します。
o If rekey messages are not used for the Group, then the admitted member receives TPKs (as part of the Data Security SAs) that are passed to the member's Data Security Protocol (as IKE does for IPsec).
o Rekeyメッセージがグループに使用されていない場合、入院メンバーは、メンバーのデータセキュリティプロトコルに渡されるTPK（データセキュリティSASの一部として）を受け取ります（IKESがIPSECで行うように）。
o The GCKS may pass one or more TPKs to the member even if rekey messages are used, for efficiency reasons and according to group policy.
o GCKSは、Rekeyメッセージが使用されていても、効率的な理由で、グループポリシーに従って、1つ以上のTPKをメンバーに渡すことができます。
The GCKS creates the KEK and TPKs and downloads them to each member, as the KEK and TPKs are common to the entire group. The GCKS is a separate logical entity that performs member authentication and authorization according to the group policy that is set by the group owner. The GCKS may present a credential signed by the group owner to the group member, so that member can check the GCKS's authorization. The GCKS, which may be co-located with a member or be physically separate, runs the rekey protocol to push rekey messages containing refreshed KEKs, new TPKs, and/or refreshed TPKs to members. Note that some group key management algorithms refresh any of the KEKs (potentially), whereas others only refresh the group KEK.
GCKSはKEKとTPKを作成し、各メンバーにダウンロードします。KEKとTPKはグループ全体に共通しているためです。GCKSは、グループ所有者によって設定されたグループポリシーに従ってメンバー認証と承認を実行する別の論理エンティティです。GCKSは、グループ所有者によって署名された資格情報をグループメンバーに提示する場合があり、メンバーがGCKSの承認を確認できるようにすることができます。メンバーと共同住宅されたり、物理的に分離されたりするGCKは、Rekeyプロトコルを実行して、更新されたKEK、新しいTPK、および/または更新されたTPKをメンバーに含むRekeメッセージをプッシュします。一部のグループキー管理アルゴリズムは、（潜在的に）keksのいずれかを更新するのに対し、他のグループKekのみを更新することに注意してください。
Alternatively, the sender may forward rekey messages on behalf of the GCKS when it uses a credential mechanism that supports delegation. Thus, it is possible for the sender, or other members, to source keying material (TPKs encrypted in the Group KEK) as it sources multicast or unicast data. As mentioned above, the rekey message can be sent using unicast or multicast delivery. Upon receipt of a TPK (as part of a Data SA) via a rekey message or a registration protocol exchange, the member's group key management functional block will provide the new or updated security association (SA) to the data security protocol. This protects the data sent from sender to receiver.
あるいは、送信者は、委任をサポートする資格情報メカニズムを使用する場合、GCKSに代わって再キーを転送することができます。したがって、送信者または他のメンバーが、マルチキャストまたはユニキャストデータを調達するため、キーイング素材（グループKEKで暗号化されたTPK）を調達することができます。上記のように、Rekeyメッセージはユニキャストまたはマルチキャスト配信を使用して送信できます。REKEYメッセージまたは登録プロトコル交換を介してTPK（データSAの一部として）を受信すると、メンバーのグループキー管理機能ブロックは、データセキュリティプロトコルに新規または更新されたセキュリティ協会（SA）を提供します。これにより、送信者から受信機への送信されたデータが保護されます。
The Data SA protects the data sent on the arc labeled DATA SECURITY PROTOCOL shown in Figure 1. A second SA, the Rekey SA, is optionally established by the key management protocol for rekey messages as shown in Figure 1 by the arc labeled REKEY PROTOCOL. The rekey message is optional because all keys, KEKs and TPKs, can be delivered by the registration protocol exchanges shown in Figure 1, and those keys may not need to be updated. The registration protocol is protected by a third, unicast, SA between the GCKS and each member. This is called the Registration SA. There may be no need for the Registration SA to remain in place after the completion of the registration protocol exchanges. The de-registration protocol may be used when explicit teardown of the SA is desirable (such as when a phone call or conference terminates). The three SAs compose the GSA. The only optional SA is the Rekey SA.
データSAは、図1に示すARCラベルのデータセキュリティプロトコルに送信されたデータを保護します。2番目のSAであるReke SAは、図1に示すように、REKEYメッセージの主要な管理プロトコルによってオプションで確立されます。すべてのキー、KEK、TPKは、図1に示す登録プロトコル交換によって配信できるため、Rekeyメッセージはオプションです。これらのキーを更新する必要がない場合があります。登録プロトコルは、3番目のユニキャスト、GCKSと各メンバーの間のSAによって保護されています。これは登録SAと呼ばれます。登録SAが登録プロトコル交換の完了後、登録SAが留まる必要はない場合があります。SAの明示的な分裂が望ましい場合（電話や会議が終了する場合など）、登録解除プロトコルを使用できます。3つのSASがGSAを構成します。唯一のオプションのSAはReke SAです。
Figure 1 shows two blocks that are external to the group key management protocol: The policy and authorization infrastructures are discussed in Section 6.1. The Multicast Security Architecture document further clarifies the SAs and their use as part of the complete architecture of a multicast security solution [MSEC-Arch].
図1は、グループキー管理プロトコルの外部にある2つのブロックを示しています。ポリシーと承認インフラストラクチャについては、セクション6.1で説明します。マルチキャストセキュリティアーキテクチャドキュメントは、マルチキャストセキュリティソリューション[MSEC-ARCH]の完全なアーキテクチャの一部として、SASとその使用をさらに明確にします。
The design of Section 3.2 achieves scalable operation by (1) allowing the de-coupling of authenticated key exchange in a registration protocol from a rekey protocol, (2) allowing the rekey protocol to use unicast push or multicast distribution of group and data keys as an option, (3) allowing all keys to be obtained by the unicast registration protocol, and (4) delegating the functionality of the GCKS among multiple entities, i.e., to permit distributed operation of the GCKS.
セクション3.2の設計は、（1）REKEYプロトコルからの登録プロトコルにおける認証されたキー交換のカップリングを可能にすることにより、スケーラブルな操作を実現します。（3）ユニキャスト登録プロトコルによってすべてのキーを取得できるようにするオプション、および（4）複数のエンティティ間のGCKの機能を委任する、つまりGCKSの分散操作を許可する。
High-capacity operation is obtained by (1) amortizing computationally-expensive asymmetric cryptography over multiple data keys used by data security protocols, (2) supporting multicast distribution of symmetric group and data keys, and (3) supporting key revocation algorithms such as LKH [RFC2627,OFT,SD1,SD2] that allow members to be added or removed at logarithmic rather than linear space/time complexity. The registration protocol may use asymmetric cryptography to authenticate joining members and optionally establish the group KEK. Asymmetric cryptography such as Diffie-Hellman key agreement and/or digital signatures are amortized over the life of the group KEK. A Data SA can be established without the use of asymmetric cryptography; the TPKs are simply encrypted in the symmetric KEK and sent unicast or multicast in the rekey protocol.
大容量操作は、（1）データセキュリティプロトコルで使用される複数のデータキーを介した計算的に高価な非対称暗号化、（2）対称グループとデータキーのマルチキャスト分布をサポートすること、および（3）LKHなどの主要な取り消しアルゴリズムをサポートすることによって得られます。[RFC2627、OFT、SD1、SD2]は、線形空間/時間の複雑さではなく、対数でメンバーを追加または削除できるようにします。登録プロトコルは、非対称の暗号化を使用して参加メンバーを認証し、オプションでグループKEKを確立する場合があります。Diffie-Hellmanキー契約やデジタル署名などの非対称暗号化は、グループKekの存続期間中に償却されます。データSAは、非対称暗号化を使用せずに確立できます。TPKは、対称Kekで単純に暗号化され、Rekeyプロトコルでユニキャストまたはマルチキャストを送信します。
The design of the registration and rekey protocols is flexible. The registration protocol establishes a Rekey SA or one or more Data SAs or both types of SAs. At least one of the SAs is present (otherwise, there is no purpose to the Registration SA). The Rekey SA may update the Rekey SA, or establish or update one or more Data SAs. Individual protocols or configurations may use this flexibility to obtain efficient operation.
登録およびRekeyプロトコルの設計は柔軟です。登録プロトコルは、Reke SAまたは1つ以上のデータSASまたは両方のタイプのSAを確立します。SASの少なくとも1つが存在します（そうでなければ、登録SAに目的はありません）。Rekey SAは、Reke SAを更新するか、1つ以上のデータSASを確立または更新する場合があります。個々のプロトコルまたは構成は、この柔軟性を使用して効率的な動作を取得する場合があります。
In the block diagram of Figure 2, group key management protocols run between a GCKS and member principal to establish a Group Security Association (GSA). The GSA consists of a Data SA, an optional Rekey SA, and a Registration SA. The GCKS may use a delegated principal, such as the sender, which has a delegation credential signed by the GCKS. The Member of Figure 2 may be a sender or receiver of multicast or unicast data. There are two functional blocks in Figure 2 labeled GKM, and there are two arcs between them depicting the group key-management registration (reg) and rekey (rek) protocols. The message exchanges are in the GSA establishment protocols, which are the registration protocol and the rekey protocol described above.
図2のブロック図では、GCKSとメンバープリンシパルの間でグループキー管理プロトコルが実行され、グループセキュリティ協会（GSA）を確立します。GSAは、データSA、オプションのReke SA、および登録SAで構成されています。GCKSは、GCKSが署名した代表団の資格情報を持つ送信者などの委任されたプリンシパルを使用する場合があります。図2のメンバーは、マルチキャストまたはユニキャストデータの送信者または受信者である場合があります。図2にはGKMというラベルが付いた2つの機能ブロックがあり、それらの間には、グループキー管理登録（REG）とREKEY（REK）プロトコルを描いた2つのアークがあります。メッセージ交換は、登録プロトコルであり、上記のRekeプロトコルであるGSA確立プロトコルにあります。
Figure 2 shows that a complete group-key management functional specification includes much more than the message exchange. Some of these functional blocks and the arcs between them are peculiar to an operating system (OS) or vendor product, such as vendor specifications for products that support updates to the IPsec
図2は、完全なグループキー管理機能仕様にメッセージ交換以上のものが含まれていることを示しています。これらの機能的ブロックとそれらの間のアークのいくつかは、IPSECECの更新をサポートする製品のベンダー仕様など、オペレーティングシステム（OS）またはベンダー製品に特有のものです。
Security Association Database (SAD) and Security Policy Database (SPD) [RFC2367]. Various vendors also define the functions and interface of credential stores, CRED in Figure 2.
セキュリティ協会データベース（SAD）およびセキュリティポリシーデータベース（SPD）[RFC2367]。さまざまなベンダーは、図2の信用ストアの関数とインターフェイスも定義しています。
+----------------------------------------------------------+
| |
| +-------------+ +------------+ |
| | CONTROL | | CONTROL | |
| +------^------+ +------|-----+ +--------+ |
| | | +-----| CRED | |
| | | | +--------+ |
| +----v----+ +----v--v-+ +--------+ |
| | <-----Reg-----> |<->| SAD | |
| | GKM -----Rek-----> GKM | +--------+ |
| | | | | +--------+ |
| | ------+ | |<->| SPD | |
| +---------+ | +-^-------+ +--------+ |
| +--------+ | | | | |
| | CRED |----->+ | | +-------------------+ |
| +--------+ | | +--------------------+ | |
| +--------+ | +-V-------+ +--------+ | | |
| | SAD <----->+ | |<->| SAD <-+ | |
| +--------+ | |SECURITY | +--------+ | |
| +--------+ | |PROTOCOL | +--------+ | |
| | SPD <----->+ | |<->| SPD <----+ |
| +--------+ +---------+ +--------+ |
| |
| (A) GCKS (B) MEMBER |
+----------------------------------------------------------+
Figure 2: Group Key Management Block in a Host
図2：ホストのグループキー管理ブロック
The CONTROL function directs the GCKS to establish a group, admit a member, or remove a member, or it directs a member to join or leave a group. CONTROL includes authorization that is subject to group policy [GSPT] but its implementation is specific to the GCKS. For large scale multicast sessions, CONTROL could perform session announcement functions to inform a potential group member that it may join a group or receive group data (e.g., a stream of file transfer protected by a data security protocol). Announcements notify group members to establish multicast SAs in advance of secure multicast data transmission. Session Description Protocol (SDP) is one form that the announcements might take [RFC2327]. The announcement function may be implemented in a session directory tool, an electronic program guide (EPG), or by other means. The Data Security or the announcement function directs group key management using an application programming interface (API), which is peculiar to the host OS in its specifics. A generic API for group key management is for further study, but this function is necessary to allow Group (KEK) and Data (TPKs) key establishment to be scalable to the particular application. A GCKS application program will use the API to initiate the procedures for establishing SAs on behalf of a Security Protocol in which members join secure groups and receive keys for streams, files, or other data.
コントロール関数は、GCKSにグループを確立したり、メンバーを認めたり、メンバーを削除したりするように指示します。または、メンバーにグループに参加または去るよう指示します。コントロールには、グループポリシー[GSPT]の対象となる認可が含まれますが、その実装はGCKSに固有です。大規模なマルチキャストセッションの場合、コントロールはセッションアナウンス関数を実行して、潜在的なグループメンバーにグループに参加したり、グループデータを受信したりすることができることを通知できます（たとえば、データセキュリティプロトコルによって保護されているファイル転送のストリーム）。発表は、安全なマルチキャストデータ送信に先立って、マルチキャストSASを確立するようグループメンバーに通知します。セッション説明プロトコル（SDP）は、発表が取る可能性のある1つの形式です[RFC2327]。アナウンス関数は、セッションディレクトリツール、電子プログラムガイド（EPG）、または他の手段で実装できます。データセキュリティまたはアナウンス関数は、アプリケーションプログラミングインターフェイス（API）を使用してグループキー管理を指示します。これは、その詳細でホストOSに特有のものです。グループキー管理の汎用APIはさらなる調査用ですが、この関数は、グループ（KEK）とデータ（TPK）の主要設立を特定のアプリケーションにスケーラブルにするために必要です。GCKSアプリケーションプログラムは、APIを使用して、メンバーがセキュアグループに参加し、ストリーム、ファイル、またはその他のデータのキーを受信するセキュリティプロトコルに代わってSASを確立する手順を開始します。
The goal of the exchanges is to establish a GSA through updates to the SAD of a key management implementation and particular Security Protocol. The Data Security Protocol ("SECURITY PROTOCOL") of Figure 2 may span internetwork and application layers or operate at the internetwork layer, such as AH and ESP.
取引所の目標は、主要な管理実装と特定のセキュリティプロトコルの悲しみへの更新を通じてGSAを確立することです。図2のデータセキュリティプロトコル（「セキュリティプロトコル」）は、AHやESPなどのインターネットワークとアプリケーションレイヤーに及ぶか、インターネットワークレイヤーで動作する場合があります。
The design of the registration protocol is flexible and can support different application scenarios. The chosen registration protocol solution reflects the specific requirements of specific scenarios. In principle, it is possible to base a registration protocol on any secure-channel protocol, such as IPsec and TLS, which is the case in tunneled GSAKMP [tGSAKMP]. GDOI [RFC3547] reuses IKE Phase 1 as the secure channel to download Rekey and/or Data SAs. Other protocols, such as MIKEY and GSAKMP, use authenticated Diffie-Hellman exchanges similar to IKE Phase 1, but they are specifically tailored for key download to achieve efficient operation. We discuss the design of a registration protocol in detail in the rest of this section.
登録プロトコルの設計は柔軟性があり、さまざまなアプリケーションシナリオをサポートできます。選択された登録プロトコルソリューションは、特定のシナリオの特定の要件を反映しています。原則として、IPSECやTLSなどの安全なチャネルプロトコルに基づいて登録プロトコルを基にすることができます。GDOI [RFC3547]は、Rekeyおよび/またはデータSASをダウンロードする安全なチャネルとしてIKEフェーズ1を再利用します。MikeyやGSAKMPなどの他のプロトコルは、IKEフェーズ1と同様の認証されたDiffie-Hellman交換を使用しますが、効率的な動作を実現するためにキーダウンロードに合わせて特別に調整されています。このセクションの残りの部分では、登録プロトコルの設計について詳しく説明します。
Some registration protocols need to tunnel through a data-signaling protocol to take advantage of already existing security functionality, and/or to optimize the total session setup time. For example, a telephone call has strict bounds for delay in setup time. It is not feasible to run security exchanges in parallel with call setup, since the latter often resolves the address. Call setup must complete before the caller knows the callee's address. In this case, it may be advantageous to tunnel the key exchange procedures inside call establishment [H.235,MIKEY], so that both can complete (or fail, see below) at the same time.
一部の登録プロトコルでは、既存のセキュリティ機能を活用して、セッションの合計セットアップ時間を最適化するために、データシグナル伝達プロトコルをトンネルする必要があります。たとえば、電話のセットアップ時間が遅れているため、電話は厳しい境界線を持っています。後者はアドレスを解決することが多いため、コールセットアップと並行してセキュリティ交換を実行することは不可能です。発信者がCalleeのアドレスを知る前に、コールセットアップが完了する必要があります。この場合、コールインスタンス[H.235、Mikey]内の主要な交換手順をトンネルすることが有利かもしれません。
The registration protocol has different requirements depending on the particular integration/tunneling approach. These requirements are not necessarily security requirements, but will have an impact on the chosen security solution. For example, the security association will certainly fail if the call setup fails in the case of IP telephony.
登録プロトコルには、特定の統合/トンネリングアプローチに応じて異なる要件があります。これらの要件は必ずしもセキュリティ要件ではありませんが、選択したセキュリティソリューションに影響を与えます。たとえば、IPテレフォニーの場合、コールセットアップが失敗した場合、セキュリティ協会は確かに失敗します。
Conversely, the registration protocol imposes requirements on the protocol that tunnels it. In the case of IP telephony, the call setup usually will fail when the security association is not successfully established. In the case of video-on-demand, protocols such as RTSP that convey key management data will fail when a needed security association cannot be established.
逆に、登録プロトコルは、それをトンネルするプロトコルに要件を課します。IPテレフォニーの場合、セキュリティ協会が正常に確立されていない場合、コールのセットアップは通常失敗します。ビデオオンデマンドの場合、主要な管理データを伝えるRTSPなどのプロトコルは、必要なセキュリティ協会を確立できないときに失敗します。
Both GDOI and MIKEY use this approach, but in different ways. MIKEY can be tunneled in SIP and RTSP. It takes advantage of the session information contained in these protocols and the possibility to optimize the setup time for the registration procedure. SIP requires that a tunneled protocol must use at most one roundtrip (i.e., two messages). This is also a desirable requirement from RTSP.
GdoiとMikeyはどちらもこのアプローチを使用していますが、さまざまな方法です。Mikeyは、SIPとRTSPでトンネリングできます。これらのプロトコルに含まれるセッション情報と、登録手順のセットアップ時間を最適化する可能性を活用します。SIPでは、トンネルプロトコルが最大1つの丸いトリップ（つまり、2つのメッセージ）で使用する必要があります。これは、RTSPからの望ましい要件でもあります。
The GDOI approach takes advantage of the already defined ISAKMP phase 1 exchange [RFC2409], and extends the phase 2 exchange for the registration. The advantage here is the reuse of a successfully deployed protocol and the code base, where the defined phase 2 exchange is protected by the SA created by phase 1. GDOI also inherits other functionality of the ISAKMP, and thus it is readily suitable for running IPsec protocols over IP multicast services.
GDOIアプローチは、すでに定義されているISAKMPフェーズ1エクスチェンジ[RFC2409]を利用し、登録のフェーズ2交換を延長します。ここでの利点は、成功したプロトコルとコードベースの再利用です。これは、フェーズ2交換がフェーズ1によって作成されたSAによって保護されています。GDOIはISAKMPの他の機能も継承しているため、IPSECECを実行するのに容易に適しています。IPマルチキャストサービスを介したプロトコル。
The required design properties of a registration protocol have different trade-offs. A protocol that provides perfect forward secrecy and identity protection trades performance or efficiency for better security, while a protocol that completes in one or two messages may trade security functionality (e.g., identity protection) for efficiency.
登録プロトコルの必要な設計プロパティには、トレードオフが異なります。1つまたは2つのメッセージを完成させるプロトコルは、より良いセキュリティのために完全な前方秘密とアイデンティティ保護のパフォーマンスまたは効率を提供するプロトコルは、効率のためにセキュリティ機能（アイデンティティ保護など）を取引することができます。
Replay protection generally uses either a timestamp or a sequence number. The first requires synchronized clocks, while the latter requires retention of state. In a timestamp-based protocol, a replay cache is needed to store the authenticated messages (or the hashes of the messages) received within the allowable clock skew. The size of the replay cache depends on the number of authenticated messages received during the allowable clock skew. During a DoS attack, the replay cache might become overloaded. One solution is to over- provision the replay cache, but this may lead to a large replay cache. Another solution is to let the allowable clock skew be changed dynamically during runtime. During a suspected DoS attack, the allowable clock skew is decreased so that the replay cache becomes manageable.
リプレイ保護は通常、タイムスタンプまたはシーケンス番号のいずれかを使用します。最初は同期されたクロックが必要ですが、後者は状態の保持を必要とします。タイムスタンプベースのプロトコルでは、許容時計スキュー内で受信した認証されたメッセージ（またはメッセージのハッシュ）を保存するには、リプレイキャッシュが必要です。リプレイキャッシュのサイズは、許容時計スキュー中に受信された認証されたメッセージの数に依存します。DOS攻撃中、リプレイキャッシュが過負荷になる可能性があります。解決策の1つは、リプレイキャッシュを過剰にプロビジョニングすることですが、これにより大きなリプレイキャッシュが発生する可能性があります。もう1つの解決策は、ランタイム中に許容時計スキューを動的に変更することです。DOS攻撃の疑いがある間、許容時計スキューが減少し、リプレイキャッシュが管理可能になります。
A challenge-response mechanism (using Nonces) obviates the need for synchronized clocks for replay protection when the exchange uses three or more messages [MVV].
チャレンジ応答メカニズム（非cesを使用）は、交換が3つ以上のメッセージ[MVV]を使用する場合、リプレイ保護のために同期されたクロックの必要性を取り除きます。
Additional security functions become possible as the number of allowable messages in the registration protocol increase. ISAKMP offers identity protection, for example, as part of a six-message exchange. With additional security features, however, comes added complexity: Identity protection, for example, not only requires additional messages, but may result in DoS vulnerabilities since authentication is performed in a late stage of the exchange after resources already have been devoted.
登録プロトコルの許容メッセージの数が増加するにつれて、追加のセキュリティ関数が可能になります。ISAKMPは、たとえば、6メッセージの交換の一環として、アイデンティティ保護を提供します。ただし、追加のセキュリティ機能により、複雑さが追加されています。たとえば、アイデンティティ保護には追加のメッセージが必要であるだけでなく、リソースが既に専用された後、交換の後期段階で認証が実行されるため、DOSの脆弱性をもたらす可能性があります。
In all cases, there are tradeoffs with the number of message exchanged, the desired security services, and the amount of infrastructure that is needed to support the group key management service. Whereas protocols that use two or even one-message setup have low latency and computation requirements, they may require more infrastructure such as secure time or offer less security such as the absence of identity protection. What tradeoffs are acceptable and what are not is very much dictated by the application and application environment.
すべての場合において、交換されたメッセージの数、目的のセキュリティサービス、およびグループキー管理サービスをサポートするために必要なインフラストラクチャの量とのトレードオフがあります。2つまたは1メッセージのセットアップを使用するプロトコルでは、遅延と計算要件が低いのに対し、安全な時間などのインフラストラクチャをより多く必要とするか、アイデンティティ保護の欠如などのセキュリティが少ない場合があります。トレードオフが受け入れられるものとそうでないものは、アプリケーションとアプリケーション環境によって非常に決定されます。
The registration protocol may need external infrastructures to handle authentication and authorization, replay protection, protocol-run integrity, and possibly other security services such as secure synchronized clocks. For example, authentication and authorization may need a PKI deployment (with either authorization-based certificates or a separate management) or may be handled using AAA infrastructure. Replay protection using timestamps requires an external infrastructure or protocol for clock synchronization.
登録プロトコルには、認証と承認、リプレイ保護、プロトコルが実行される整合性、およびセキュアー同期クロックなどの他のセキュリティサービスを処理するための外部インフラストラクチャが必要になる場合があります。たとえば、認証と承認には、PKIの展開（承認ベースの証明書または個別の管理）が必要になる場合や、AAAインフラストラクチャを使用して処理される場合があります。タイムスタンプを使用したリプレイ保護には、クロック同期のために外部インフラストラクチャまたはプロトコルが必要です。
However, external infrastructures may not always be needed; for example pre-shared keys are used for authentication and authorization. This may be the case if the subscription base is relatively small. In a conversational multimedia scenario (e.g., a VoIP call between two or more people), it may be the end user who handles the authorization by manually accepting/rejecting the incoming calls. In that case, infrastructure support may not be required.
ただし、外部インフラストラクチャが必ずしも必要とは限りません。たとえば、事前に共有キーは、認証と承認に使用されます。これは、サブスクリプションベースが比較的小さい場合に当てはまります。会話型マルチメディアシナリオ（たとえば、2人以上の間のVoIPコールなど）では、着信コールを手動で受け入れる/拒否することで承認を処理するのはエンドユーザーかもしれません。その場合、インフラストラクチャサポートは必要ない場合があります。
The session-establishment protocol (e.g., SIP, RTSP) that conveys a registration exchange often has a session-disestablishment protocol such as RTSP TEARDOWN [RFC2326] or SIP BYE [RFC3261]. The session-disestablishment exchange between endpoints offers an opportunity to signal the end of the GSA state at the endpoints. This exchange need only be a unidirectional notification by one side that the GSA is to be destroyed. For authentication of this notification, we may use a proof-of-possession of the group key(s) by one side to the other. Some applications benefit from acknowledgement in a mutual, two-message exchange signaling disestablishment of the GSA concomitant with disestablishment of the session, e.g., RTSP or SIP session. In this case, a two-way proof-of-possession might serve for mutual acknowledgement of the GSA disestablishment.
登録交換を伝えるセッション確立プロトコル（SIP、RTSPなど）には、多くの場合、RTSP分解[RFC2326]またはSIP Bye [RFC3261]などのセッション拡張プロトコルがあります。エンドポイント間のセッション拡張交換は、エンドポイントでGSA状態の終わりを通知する機会を提供します。この交換は、GSAが破壊されることを一方的に一方的な通知である必要があります。この通知の認証のために、一方の側にグループキーのプルーフポッセッションを使用する場合があります。一部のアプリケーションは、セッションの廃止を伴うGSAの相互の2メッセージ交換シグナル伝達の承認から恩恵を受けます。たとえば、RTSPやSIPセッションなど。この場合、双方向の証明の提案は、GSAの災害を相互に認めるのに役立つ可能性があります。
The group rekey protocol is for transport of keys and SAs between a GCKS and the members of a secure communications group. The GCKS sends rekey messages to update a Rekey SA, or initialize/update a Data SA or both. Rekey messages are protected by a Rekey SA. The GCKS may update the Rekey SA when group membership changes or when KEKs or TPKs expire. Recall that KEKs correspond to a Rekey SA and TPKs correspond to a Data SA.
グループRekeプロトコルは、GCKと安全な通信グループのメンバーの間のキーとSASの輸送用です。GCKSはREKEYメッセージを送信してReke SAを更新するか、データSAまたはその両方を初期化/更新します。RekeyメッセージはRekey SAによって保護されています。GCKSは、グループメンバーシップが変更されたとき、またはKEKSまたはTPKが期限切れになったときにReke SAを更新する場合があります。KeksはReke SAに対応し、TPKはデータSAに対応していることを思い出してください。
The following are some desirable properties of the rekey protocol.
以下は、Rekeyプロトコルのいくつかの望ましい特性です。
o The rekey protocol ensures that all members receive the rekey information in a timely manner.
o Rekeyプロトコルは、すべてのメンバーがタイムリーにReke情報を受け取ることを保証します。
o The rekey protocol specifies mechanisms allowing the parties to contact the GCKS and re-sync when their keys expire and no updates have been received.
o Rekeyプロトコルは、キーが期限切れになり、更新が受信されていないときに、当事者がGCKSに連絡し、再シンクすることを可能にするメカニズムを指定します。
o The rekey protocol avoids implosion problems and ensures reliability in delivering Rekey information.
o Rekey Protocolは、爆発の問題を回避し、Rekey情報の提供における信頼性を保証します。
We further note that the rekey protocol is primarily responsible for scalability of the group key management architecture. Hence, it is imperative that we provide the above listed properties in a scalable manner. Note that solutions exist in the literature (both IETF standards and research articles) for parts of the problem. For instance, the rekey protocol may use a scalable group key management algorithm (GKMA) to reduce the number of keys sent in a rekey message. Examples of a GKMA include LKH, OFT, Subset difference based schemes etc.
さらに、Rekeyプロトコルは、グループキー管理アーキテクチャのスケーラビリティに主に責任があることに注意してください。したがって、上記のリストされたプロパティをスケーラブルな方法で提供することが不可欠です。問題の一部については、文献（IETF標準と研究記事の両方）には解決策が存在することに注意してください。たとえば、Rekeyプロトコルは、スケーラブルなグループキー管理アルゴリズム（GKMA）を使用して、Rekeyメッセージで送信されるキーの数を減らすことができます。GKMAの例には、LKH、OFT、サブセット差ベースのスキームなどが含まれます。
The goals of the rekey protocol are:
Rekeyプロトコルの目標は次のとおりです。
o to synchronize a GSA,
o GSAを同期させるには、
o to provide privacy and (symmetric or asymmetric) authentication, replay protection and DoS protection,
o プライバシーと（対称的または非対称的または非対称）認証を提供するため、リプレイ保護とDOS保護、
o efficient rekeying after changes in group membership or when keys (KEKs) expire,
o グループメンバーシップの変更後、またはキー（keks）が期限切れになったときに効率的な再キーイング、
o reliable delivery of rekey messages,
o Rekeyメッセージの信頼できる配信、
o member recovery from an out-of-sync GSA,
o シンク外GSAからのメンバーの回復、
o high throughput and low latency, and
o 高スループットと低レイテンシー、および
o support IP Multicast or multi-unicast.
o IPマルチキャストまたはマルチユニカストをサポートします。
We identify several major issues in the design of a rekey protocol:
Rekeyプロトコルの設計におけるいくつかの主要な問題を特定します。
1. rekey message format,
1. 再キーメッセージフォーマット、
2. reliable transport of rekey messages,
2. Rekeyメッセージの信頼できる輸送、
3. implosion,
3. 内破、
4. recovery from out-of-sync GSA,
4. シンク外GSAからの回復、
5. incorporating GKMAs in rekey messages, and
5. GKMAをRekeyメッセージに組み込む、および
6. interoperability of GKMAs.
6. GKMAの相互運用性。
Note that interoperation of rekey protocol implementations is insufficient for a GCKS to successfully rekey a group. The GKMA must also interoperate, i.e., standard versions of the group key management algorithms such as LKH, OFT, or Subset Difference must be used.
GCKSがグループを正常に再キーするには、Rekeyプロトコルの実装の相互操作は不十分であることに注意してください。GKMAも相互運用する必要があります。つまり、LKH、OFT、またはサブセットの差などのグループキー管理アルゴリズムの標準バージョンを使用する必要があります。
The rest of this section discusses these topics in detail.
このセクションの残りの部分では、これらのトピックについて詳しく説明します。
Rekey messages contain Rekey and/or Data SAs along with KEKs and TPKs. These messages need to be confidential, authenticated, and protected against replay and DoS attacks. They are sent via multicast or multi-unicast from the GCKS to the members.
Rekeyメッセージには、KEKおよびTPKとともにRekeyおよび/またはデータSASが含まれています。これらのメッセージは、リプレイやDOS攻撃に対して機密、認証、保護される必要があります。それらは、GCKSからメンバーにマルチキャストまたはマルチユニカストを介して送信されます。
Rekey messages are encrypted with the Group KEK for confidentiality. When used in conjunction with a GKMA, portions of the rekey message are first encrypted with the appropriate KEKs as specified by the GKMA. The GCKS authenticates rekey messages using either a MAC, computed using the group Authentication key, or a digital signature. In both cases, a sequence number is included in computation of the MAC or the signature to protect against replay attacks.
Rekeyメッセージは、機密性を得るためにグループKekで暗号化されます。GKMAと組み合わせて使用する場合、REKEYメッセージの一部は、GKMAで指定された適切なKEKで最初に暗号化されます。GCKSは、グループ認証キーまたはデジタル署名を使用して計算されたMacを使用してRekeyメッセージを認証します。どちらの場合も、リプレイ攻撃から保護するために、MACまたは署名の計算にシーケンス番号が含まれています。
When group authentication is provided with a symmetric key, rekey messages are vulnerable to attacks by other members of the group. Rekey messages are digitally signed when group members do not trust each other. When asymmetric authentication is used, members receiving rekey messages are vulnerable to DoS attacks. An external adversary may send a bogus rekey message, which a member cannot identify until after it performs an expensive digital signature operation. To protect against such an attack, a MAC may be sent as part of the rekey message. Members verify the signature only upon successful verification of the MAC.
グループ認証に対称キーが提供されると、Rekeyメッセージはグループの他のメンバーによる攻撃に対して脆弱です。グループメンバーがお互いを信頼していない場合、リキーメッセージはデジタル署名されます。非対称認証を使用すると、Rekeyメッセージを受信するメンバーはDOS攻撃に対して脆弱です。外部の敵は偽のrekyメッセージを送信する場合があります。これは、高価なデジタル署名操作を実行するまでメンバーが識別できません。このような攻撃から保護するために、MacをRekeyメッセージの一部として送信できます。メンバーは、Macの検証が成功したときにのみ署名を確認します。
Rekey messages contain group key updates corresponding to a single [RFC2627,OFT] or multiple membership changes [SD1,SD2,BatchRekey] and may contain group key initialization messages [OFT].
Rekeyメッセージには、単一の[RFC2627、OFT]または複数のメンバーシップの変更[SD1、SD2、BatchRekey]に対応するグループキーの更新が含まれており、グループキーの初期化メッセージ[OFT]を含む場合があります。
The GCKS must ensure that all members have the current Data Security and Rekey SAs. Otherwise, authorized members may be inadvertently excluded from receiving group communications. Thus, the GCKS needs to use a rekey algorithm that is inherently reliable or employ a reliable transport mechanism to send rekey messages.
GCKSは、すべてのメンバーが現在のデータセキュリティと再キーサスを持っていることを確認する必要があります。それ以外の場合、承認されたメンバーは、グループコミュニケーションの受信から不注意に除外される場合があります。したがって、GCKSは、本質的に信頼性の高いRekeyアルゴリズムを使用するか、信頼できる輸送メカニズムを使用してRekeyメッセージを送信する必要があります。
There are two dimensions to the problem. Messages that update group keys may be lost in transit or may be missed by a host when it is offline. LKH and OFT group key management algorithms rely on past history of updates being received by the host. If the host goes offline, it will need to resynchronize its group-key state when it comes online; this may require a unicast exchange with the GCKS. The Subset Difference algorithm, however, conveys all the necessary state in its rekey messages and does not need members to be always online or keeping state. The Subset Difference algorithm does not require a back channel and can operate on a broadcast network. If a rekey message is lost in transmission, the Subset Difference algorithm cannot decrypt messages encrypted with the TPK sent via the lost rekey message. There are self-healing GKMAs proposed in the literature that allow a member to recover lost rekey messages, as long as rekey messages before and after the lost rekey message are received.
問題には2つの次元があります。グループキーを更新するメッセージは、輸送中に失われる可能性があるか、オフラインの場合、ホストが見逃す可能性があります。LKHおよびOFTグループキー管理アルゴリズムは、ホストが受け取っている更新の過去の歴史に依存しています。ホストがオフラインになった場合、オンラインになったときにグループキーの状態を再同期させる必要があります。これには、GCKSとのユニキャスト交換が必要になる場合があります。ただし、サブセットの差異アルゴリズムは、必要なすべての状態をRekeyメッセージで伝え、常にオンラインまたは状態を維持するメンバーを必要としません。サブセットの差異アルゴリズムは、バックチャネルを必要とせず、ブロードキャストネットワークで動作できます。Rekeyメッセージが送信で失われた場合、Subset Difference Algorithmは、Lost Rekeメッセージを介して送信されたTPKで暗号化されたメッセージを解読できません。Lost Rekeyメッセージが受信される前後に、メンバーが失われたRekeyメッセージを回復できるようにする文献に提案されている自己修復GKMAがあります。
Rekey messages are typically short (for single membership change as well as for small groups), which makes it easy to design a reliable delivery protocol. On the other hand, the security requirements may add an additional dimension to address. There are some special cases in which membership changes are processed as a batch, reducing the frequency of rekey messages but increasing their size. Furthermore, among all the KEKs sent in a rekey message, as many as half the members need only a single KEK. We may take advantage of these properties in designing a rekey message(s) and a protocol for their reliable delivery.
レキーメッセージは通常（単一のメンバーシップの変更と小グループの場合）短いため、信頼できる配信プロトコルを簡単に設計できます。一方、セキュリティ要件は、アドレスに追加の次元を追加する場合があります。メンバーシップの変更がバッチとして処理される特別なケースがいくつかあり、再キーメッセージの頻度を減らしますが、サイズを増やします。さらに、すべてのKEKの中で、Rekeyメッセージで送信された場合、メンバーの半分が1つのKekのみを必要とします。これらのプロパティを利用して、信頼できる配信のためのRekeyメッセージとプロトコルを設計することができます。
Three categories of solutions have been proposed:
ソリューションの3つのカテゴリが提案されています。
1. Repeatedly transmit the rekey message. In many cases rekey messages translate to only one or two IP packets.
1. Rekeyメッセージを繰り返し送信します。多くの場合、再キーメッセージは1つまたは2つのIPパケットのみに変換されます。
2. Use an existing reliable multicast protocol/infrastructure.
2. 既存の信頼できるマルチキャストプロトコル/インフラストラクチャを使用します。
3. Use FEC for encoding rekey packets (with NACKs as feedback) [BatchRekey].
3. FECを使用して、Rekeyパケット（フィードバックとしてNACKSを使用）[BatchRekey]をエンコードします。
Note that for small messages, category 3 is essentially the same as category 1.
小さなメッセージの場合、カテゴリ3は本質的にカテゴリ1と同じであることに注意してください。
The group member might be out of synchrony with the GCKS if it receives a rekey message having a sequence number that is more than one greater than the last sequence number processed. This is one means by which the GCKS member detects that it has missed a rekey message. Alternatively, the data-security application, upon detecting that it is using an out-of-date key, may notify the group key management module. The action taken by the GCKS member is a matter of group policy. The GCKS member should log the condition and may contact the GCKS to rerun the re-registration protocol to obtain a fresh group key. The group policy needs to take into account boundary conditions, such as reordered rekey messages when rekeying is so frequent that two messages might get reordered in an IP network. The group key policy also needs to take into account the potential for denial of service attacks where an attacker delays or deletes a rekey message in order to force a subnetwork or subset of the members to simultaneously contact the GCKS.
グループメンバーは、処理された最後のシーケンス番号よりも1つ以上大きいシーケンス番号を持つRekeyメッセージを受信した場合、GCKSと同期しない可能性があります。これは、GCKSメンバーがRekeyメッセージを見逃したことを検出する1つの手段です。あるいは、データセキュリティアプリケーションは、時代遅れのキーを使用していることを検出したときに、グループキー管理モジュールに通知する場合があります。GCKSメンバーが行ったアクションは、グループポリシーの問題です。GCKSメンバーは条件を記録し、GCKSに連絡して再登録プロトコルを再実行して、新しいグループキーを取得することができます。グループポリシーでは、再キーイングが非常に頻繁に頻繁に並ぶ場合、2つのメッセージがIPネットワークで並べ替える可能性がある場合、境界条件を考慮する必要があります。グループキーポリシーは、メンバーのサブネットワークまたはサブセットに同時にGCKSに連絡するように強制するために、攻撃者が再キーメッセージを遅らせたり削除したりするサービス拒否攻撃の可能性を考慮する必要があります。
If a group member becomes out-of-synch with the GSA then it should re-register with the GCKS. However, in many cases there are other, simpler methods for re-synching with the group:
グループメンバーがGSAでシンク外になった場合、GCKSで再登録する必要があります。ただし、多くの場合、グループと再シンチするための他のより単純な方法があります。
o The member can open a simple unprotected connection (e.g., TCP) with the GCKS and obtain the current (or several recent) rekey messages. Note that there is no need for authentication or encryption here, since the rekey message is already signed and is multicast in the clear. One may think that this opens the GCKS to DoS attacks by many bogus such requests. This, however, does not seem to worsen the situation; in fact, bombarding the GCKS with bogus resynch requests would be much more problematic.
o メンバーは、GCKを使用して単純な保護されていない接続（TCPなど）を開き、現在（または最近のいくつかの）再キーメッセージを取得できます。Rekeyメッセージは既に署名されており、明確なマルチキャストであるため、ここでは認証や暗号化の必要はないことに注意してください。これにより、GCKSが多くの偽物のようなリクエストによってDOS攻撃を開くと考えるかもしれません。ただし、これは状況を悪化させるようには見えません。実際、Bogus ResynchリクエストでGCKを砲撃することは、はるかに問題があります。
o The GCKS can post the rekey messages on some public site (e.g., a web site) and the out-of-synch member can obtain the rekey messages from that site.
o GCKSは、一部のパブリックサイト（たとえば、Webサイト）にRekeyメッセージを投稿でき、シンシア外のメンバーはそのサイトからRekeyメッセージを取得できます。
The GCKS may always provide all three ways of resynching (i.e., re-registration, simple TCP, and public posting). This way, the member may choose how to resynch; it also avoids adding yet another field to the policy token [GSPT]. Alternatively, a policy token may contain a field specifying one or more methods supported for resynchronization of a GSA.
GCKは、常に3つの再配置方法（つまり、再登録、単純なTCP、および公開投稿）をすべて提供する場合があります。このようにして、メンバーは再配置する方法を選択できます。また、ポリシートークン[GSPT]にさらに別のフィールドを追加することも避けます。あるいは、ポリシートークンには、GSAの再同期にサポートされている1つ以上の方法を指定するフィールドが含まれる場合があります。
The rekey message may be sent using reliable multicast. There are several types of reliable multicast protocols with different properties. However, there are no standards track reliable multicast protocols published at this time, although IETF consensus has been reached on two protocols that are intended to go into the standards track [NORM,RFC3450]. Thus, this document does not recommend a particular reliable multicast protocol or set of protocols for the purpose of reliable group rekeying. The suitability of NAK-based, ACK-based or other reliable multicast methods is determined by the application needs and operational environment. In the future, group key management protocols may choose to use particular standards-based approaches that meet the needs of the particular application. A secure announcement facility may be needed to signal the use of a reliable multicast protocol, which could be specified as part of group policy. The reliable multicast announcement and policy specification, however, can only follow the establishment of reliable multicast standards and are not considered further in this document.
Rekeyメッセージは、信頼できるマルチキャストを使用して送信できます。異なる特性を持つ信頼性の高いマルチキャストプロトコルには、いくつかのタイプがあります。ただし、この時点で公開された信頼性の高いマルチキャストプロトコルを追跡する標準追跡はありませんが、IETFコンセンサスは標準トラック[NORM、RFC3450]に移動することを目的とした2つのプロトコルで到達しています。したがって、このドキュメントでは、信頼できるグループの再キーイングを目的として、特定の信頼できるマルチキャストプロトコルまたはプロトコルのセットを推奨していません。NAKベース、ACKベース、またはその他の信頼できるマルチキャストメソッドの適合性は、アプリケーションのニーズと運用環境によって決定されます。将来、グループキー管理プロトコルは、特定のアプリケーションのニーズを満たす特定の標準ベースのアプローチを使用することを選択できます。グループポリシーの一部として指定できる信頼できるマルチキャストプロトコルの使用を知らせるために、安全なアナウンス施設が必要になる場合があります。ただし、信頼できるマルチキャストの発表とポリシー仕様は、信頼できるマルチキャスト基準の確立にのみ従うことができ、このドキュメントではこれ以上考慮されていません。
Today, the several MSEC group key management protocols support sequencing of the rekey messages through a sequence number, which is authenticated along with the rekey message. A sender of rekey messages may re-transmit multiple copies of the message provided that they have the same sequence number. Thus, re-sending the message is a rudimentary means of overcoming loss along the network path. A member who receives the rekey message will check the sequence number to detect duplicate and missing rekey messages. The member receiver will discard duplicate messages that it receives. Large rekey messages, such as those that contain LKH or OFT tree structures, might benefit from transport-layer FEC in the future, when standards-based methods become available. It is unlikely that forward error correction (FEC) methods will benefit short rekey messages that fit within a single message. In this case, FEC degenerates to simple retransmission of the message.
今日、いくつかのMSECグループキー管理プロトコルは、REKEYメッセージとともに認証されているシーケンス番号を介したRekeメッセージのシーケンスをサポートしています。Rekeyメッセージの送信者は、同じシーケンス番号がある場合、メッセージの複数のコピーを再送信する場合があります。したがって、メッセージを再配置することは、ネットワークパスに沿って損失を克服する初歩的な手段です。Rekeyメッセージを受信したメンバーは、シーケンス番号をチェックして、重複および欠落しているRekeメッセージを検出します。メンバーレシーバーは、受信した複製メッセージを破棄します。LKHやOFTツリー構造を含むような大きな再キーメッセージは、標準ベースの方法が利用可能になった将来、輸送層FECの恩恵を受ける可能性があります。フォワードエラー補正（FEC）メソッドが、単一のメッセージに適合する短いRekeメッセージに利益をもたらす可能性は低いです。この場合、FECはメッセージの単純な再送信に退化します。
Implosion may occur due to one of two reasons. First, recall that one of the goals of the rekey protocol is to synchronize a GSA. When a rekey or Data SA expires, members may contact the GCKS for an update. If all, or even many, members contact the GCKS at about the same time, the GCKS might not be able to handle all those messages. We refer to this as an out-of-sync implosion.
2つの理由のいずれかが原因で爆発が発生する可能性があります。まず、Rekeyプロトコルの目標の1つはGSAを同期することであることを思い出してください。RekeyまたはData SAの有効期限が切れると、メンバーは更新のためにGCKSに連絡することができます。すべて、または多くのメンバーが同時にGCKSに連絡した場合、GCKSはこれらすべてのメッセージを処理できない可能性があります。これを、皮膚外の爆発と呼びます。
The second case is in the reliable delivery of rekey messages. Reliable multicast protocols use feedback (NACK or ACK) to determine which packets must be retransmitted. Packet losses may result in many members sending NACKs to the GCKS. We refer to this as feedback implosion.
2番目のケースは、Rekeyメッセージの信頼できる配信です。信頼性の高いマルチキャストプロトコルは、フィードバック（NACKまたはACK）を使用して、どのパケットを再送信する必要があるかを判断します。パケットの損失により、多くのメンバーがGCKSにNACKを送信する可能性があります。これをフィードバックの爆発と呼びます。
The implosion problem has been studied extensively in the context of reliable multicasting. The proposed feedback suppression and aggregation solutions might be useful in the GKM context as well. Members may wait a random time before sending an out-of-sync or feedback message. Meanwhile, members might receive the necessary key updates and therefore not send a feedback message. An alternative solution is to have the members contact one of several registration servers when they are out-of-sync. This requires GSA synchronization between the multiple registration servers.
爆発の問題は、信頼できるマルチキャストの文脈で広範囲に研究されています。提案されたフィードバック抑制と集約ソリューションは、GKMコンテキストでも役立つ可能性があります。メンバーは、シンク外またはフィードバックメッセージを送信する前にランダムな時間を待つことができます。一方、メンバーは必要なキーアップデートを受け取る可能性があるため、フィードバックメッセージは送信されません。別の解決策は、メンバーがシンク外の場合に複数の登録サーバーのいずれかに連絡させることです。これには、複数の登録サーバー間のGSA同期が必要です。
Feedback aggregation and local recovery employed by some reliable multicast protocols are not easily adaptable to transport of rekey messages. Aggregation raises authentication issues. Local recovery is more complex because members need to establish SAs with the local repair server. Any member of the group or a subordinate GCKS may serve as a repair server, which can be responsible for resending rekey messages.
いくつかの信頼できるマルチキャストプロトコルに採用されたフィードバックの集約とローカル回復は、Rekeyメッセージの輸送に簡単に適応できません。集約により、認証の問題が発生します。メンバーはローカル修理サーバーでSASを確立する必要があるため、ローカルの回復はより複雑です。グループのメンバーまたは下位のGCKSは、Rekeyメッセージの復活を担当する修理サーバーとして機能する場合があります。
Members may use the group SA, more specifically the Rekey SA, to authenticate requests sent to the repair server. However, replay protection requires maintaining state at members as well as repair servers. Authentication of repair requests is meant to protect against DoS attacks. Note also that an out-of-sync member may use an expired Rekey SA to authenticate repair requests, which requires repair servers to accept messages protected by old SAs.
メンバーは、より具体的にはReke SAをより具体的に使用して、修理サーバーに送信されたリクエストを認証することができます。ただし、リプレイ保護には、メンバーと修理サーバーの状態を維持する必要があります。修理要求の認証は、DOS攻撃から保護することを目的としています。また、シンク外のメンバーが期限切れのRekey SAを使用して修理リクエストを認証する場合があります。これは、古いSASによって保護されているメッセージを受け入れるために修理サーバーが必要です。
Alternatively, a simple mechanism may be employed to achieve local repair efficiently. Each member receives a set of local repair server addresses as part of group operation policy information. When a member does not receive a rekey message, it can send a "Retransmit replay message(s) with sequence number n and higher" message to one of the local repair servers. The repair server can either ignore the request if it is busy or retransmit the requested rekey messages as received from the GCKS. The repair server, which is also another member may choose to serve only m requests in a given time period (i.e., rate limits responses) or per a given rekey message. Rate limiting the requests and responses protects the repair servers as well as other members of the group from DoS attacks.
あるいは、局所的な修復を効率的に達成するために、簡単なメカニズムを採用することもできます。各メンバーは、グループ操作ポリシー情報の一部として、ローカル修理サーバーアドレスのセットを受信します。メンバーがRekeyメッセージを受信しない場合、「シーケンス番号n以下のリプレイメッセージを再送信して、ローカル修理サーバーの1つに送信できます。修理サーバーは、忙しい場合はリクエストを無視するか、GCKSから受信した要求されたRekeyメッセージを再送信できます。別のメンバーである修理サーバーは、特定の期間（つまり、レート制限応答）または特定のRekeyメッセージごとにMリクエストのみを提供することを選択できます。レートリクエストと応答を制限すると、Repair ServersとGroupの他のメンバーがDOS攻撃から保護されます。
Group key management algorithms make rekeying scalable. Large group rekeying without employing GKMAs is prohibitively expensive.
グループキー管理アルゴリズムにより、スケーラブルになります。GKMAを使用せずに再キーリングする大規模なグループは、非常に高価です。
Following are some considerations in selecting a GKMA:
以下は、GKMAを選択する際のいくつかの考慮事項です。
o Protection against collusion.
o 共謀に対する保護。
Members (or non-members) should not be able to collaborate to deduce keys for which they are not privileged (following the GKMA key distribution rules).
メンバー（または非会員）は、特権ではないキーを推定するために協力してはいけません（GKMAキーディストリビューションルールに従ってください）。
o Forward access control
o フォワードアクセス制御
The GKMA should ensure that departing members cannot get access to future group data.
GKMAは、出発したメンバーが将来のグループデータにアクセスできないことを確認する必要があります。
o Backward access control
o 後方アクセス制御
The GKMA should ensure that joining members cannot decrypt past data.
GKMAは、参加メンバーが過去のデータを復号化できないことを確認する必要があります。
We classify group key management algorithms into three categories: stateful, stateless, and self-healing.
Group Key Management Algorithmsを3つのカテゴリに分類します：Stateful、Stateless、およびSelf Healing。
Stateful algorithms [RFC2627,OFT] use KEKs from past rekeying instances to encrypt (protect) KEKs corresponding to the current and future rekeying instances. The main disadvantage in these schemes is that if a member were offline or otherwise failed to receive KEKs from a past rekeying instance, it may no longer be able to synchronize its GSA even though it can receive KEKs from all future rekeying instances. The only solution is to contact the GCKS explicitly for resynchronization. Note that the KEKs for the first rekeying instance are protected by the Registration SA. Recall that communication in that phase is one to one, and therefore it is easy to ensure reliable delivery.
Stateful Algorithms [RFC2627、OFT]は、現在および将来の再キーイングインスタンスに対応するKEKを暗号化（保護）するために、過去の再キーイングインスタンスのKEKを使用します。これらのスキームの主な欠点は、メンバーがオフラインであるか、過去の再キーイングインスタンスからKEKを受け取ることができなかった場合、将来のすべての再キーイングインスタンスからKEKを受け取ることができても、GSAを同期できなくなる可能性があることです。唯一の解決策は、再同期のためにGCKSに明示的に接触することです。最初の再キーイングインスタンスのKEKSは、登録SAによって保護されていることに注意してください。そのフェーズでのコミュニケーションは1対1であることを思い出してください。したがって、信頼できる配信を確保するのは簡単です。
Stateless GKMAs [SD1,SD2] encrypt rekey messages with KEKs sent during the registration protocol. Since rekey messages are independent of any past rekey messages (i.e., that are not protected by KEKs therein), a member may go offline but continue to decipher future communications. However, stateless GKMAs offer no mechanisms to recover past rekeying messages. Stateless rekeying may be relatively inefficient, particularly for immediate (not batch) rekeying in highly dynamic groups.
Stateless GKMAS [SD1、SD2]は、登録プロトコル中に送信されたKEKを使用してRekeメッセージを暗号化します。Rekeyメッセージは、過去のRekeメッセージ（つまり、Keksによって保護されていない）に依存しないため、メンバーはオフラインになりますが、将来のコミュニケーションを解読し続けることができます。ただし、ステートレスGKMAは、過去の再キーイングメッセージを回復するメカニズムを提供しません。ステートレスの再キーキングは、特に非常にダイナミックなグループでの即時（バッチではない）の再キーを再キーにするために、比較的非効率的である可能性があります。
In self-healing schemes [Self-Healing], a member can reconstruct a lost rekey message as long as it receives some past and some future rekey messages.
自己修復スキーム[自己回復]では、メンバーは、過去と将来の再キーメッセージを受け取る限り、失われた再キーメッセージを再構築できます。
Most GKMA specifications do not specify packet formats, although many group key management algorithms need format specification for interoperability. There are several alternative ways to manage key trees and to number nodes within key trees. The following information is needed during initialization of a Rekey SA or included with each GKMA packet.
ほとんどのGKMA仕様はパケット形式を指定していませんが、多くのグループキー管理アルゴリズムには、相互運用性のために形式の仕様が必要です。キーツリーを管理し、キーツリー内のノードを番号にするいくつかの代替方法があります。Reke SAの初期化中に以下の情報が必要であるか、各GKMAパケットに含まれています。
o GKMA name (e.g., LKH, OFT, Subset Difference)
o GKMA名（例：LKH、OFT、サブセットの違い）
o GKMA version number (implementation specific). Version may imply several things such as the degree of a key tree, proprietary enhancements, and qualify another field such as a key ID.
o GKMAバージョン番号（実装固有）。バージョンは、キーツリーの程度、独自の機能強化など、キーIDなどの別のフィールドなどのいくつかのことを意味する場合があります。
o Number of keys or largest ID
o キーの数または最大ID
o Version-specific data
o バージョン固有のデータ
o Per-key information:
o キー情報：
- key ID, - key lifetime (creation/expiration data) , - encrypted key, and - encryption key's ID (optional).
- キーID、 - キーライフタイム（作成/有効期限データ）、 - 暗号化キー、および - 暗号化キーのID（オプション）。
Key IDs may change in some implementations in which case one needs to send:
キーIDは、いくつかの実装で変更される場合があります。その場合、送信する必要があります。
o List of <old id, new id> pairs.
o <old id、new id>ペアのリスト。
The GKM architecture defines the interfaces between the registration, rekey, and data security protocols in terms of the Security Associations (SAs) of those protocols. By isolating these protocols behind a uniform interface, the architecture allows implementations to use protocols best suited to their needs. For example, a rekey protocol for a small group could use multiple unicast transmissions with symmetric authentication, while a rekey protocol for a large group could use IP Multicast with packet-level Forward Error Correction and source authentication.
GKMアーキテクチャは、これらのプロトコルのセキュリティ協会（SAS）の観点から、登録、Reke、およびデータセキュリティプロトコルの間のインターフェイスを定義します。これらのプロトコルを均一なインターフェイスの背後に分離することにより、アーキテクチャにより、実装はニーズに最適なプロトコルを使用できます。たとえば、小グループのRekeyプロトコルでは、対称認証を備えた複数のユニキャスト送信を使用できますが、大規模グループのRekeyプロトコルは、パケットレベルのフォワードエラー補正とソース認証を備えたIPマルチキャストを使用できます。
The group key management architecture provides an interface between the security protocols and the group SA (GSA). The GSA consists of three SAs: Registration SA, Rekey SA, and Data SA. The Rekey SA is optional. There are two cases in defining the relationships between the three SAs. In both cases, the Registration SA protects the registration protocol.
グループキー管理アーキテクチャは、セキュリティプロトコルとグループSA（GSA）の間のインターフェイスを提供します。GSAは、登録SA、REKEY SA、およびデータSAの3つのSASで構成されています。Rekey SAはオプションです。3つのSAS間の関係を定義する上で2つのケースがあります。どちらの場合も、登録SAは登録プロトコルを保護します。
Case 1: Group key management is done WITHOUT using a Rekey SA. The registration protocol initializes and updates one or more Data SAs (having TPKs to protect files or streams). Each Data SA corresponds to a single group, which may have more than one Data SA.
ケース1：グループキー管理は、Rekey SAを使用せずに行われます。登録プロトコルは、1つ以上のデータSAS（ファイルまたはストリームを保護するためのTPKを持っている）を初期化および更新します。各データSAは単一のグループに対応しており、複数のデータSAがある場合があります。
Case 2: Group key management is done WITH a Rekey SA to protect the rekey protocol. The registration protocol initializes the one or more Rekey SAs as well as zero or more Data SAs, upon successful completion. When a Data SA is not initialized in the registration protocol, initialization is done in the rekey protocol. The rekey protocol updates Rekey SA(s) AND establishes Data SA(s).
ケース2：グループキー管理は、REKEY SAで行われ、Rekeyプロトコルを保護します。登録プロトコルは、正常に完了すると、1つ以上のReke SASとゼロ以上のデータSASを初期化します。データSAが登録プロトコルで初期化されていない場合、REKEYプロトコルで初期化が行われます。RekeyプロトコルはReke SA（S）を更新し、データSA（S）を確立します。
Group policy is described in detail in the Group Security Policy Token document [GSPT]. Group policy can be distributed through group announcements, key management protocols, and other out-of-band means (e.g., via a web page). The group key management protocol carries cryptographic policies of the SAs and the keys it establishes, as well as additional policies for the secure operation of the group.
グループポリシーは、グループセキュリティポリシートークンドキュメント[GSPT]で詳細に説明されています。グループポリシーは、グループアナウンス、主要な管理プロトコル、およびその他の帯域外の手段を通じて（例：Webページを介して）配布できます。グループキー管理プロトコルには、SASとキーが確立するキーの暗号化ポリシー、およびグループの安全な運用のための追加のポリシーが搭載されています。
The acceptable cryptographic policies for the registration protocol, which may run over TLS [TLS], IPsec, or IKE, are not conveyed in the group key management protocol since they precede any of the key management exchanges. Thus, a security policy repository having some access protocol may need to be queried prior to establishing the key-management session, to determine the initial cryptographic policies for that establishment. This document assumes the existence of such a repository and protocol for GCKS and member policy queries. Thus group security policy will be represented in a policy repository and accessible using a policy protocol. Policy distribution may be a push or a pull operation.
TLS [TLS]、IPSEC、またはIKEを介して実行される可能性のある登録プロトコルの許容可能な暗号化ポリシーは、主要な管理交換のいずれかに先行するため、グループキー管理プロトコルでは伝えられません。したがって、その施設の最初の暗号化ポリシーを決定するために、いくつかのアクセスプロトコルを持つセキュリティポリシーリポジトリをキー管理セッションを確立する前に照会する必要がある場合があります。このドキュメントでは、GCKSおよびメンバーポリシークエリ用のこのようなリポジトリとプロトコルの存在を想定しています。したがって、グループセキュリティポリシーは、ポリシーリポジトリに表され、ポリシープロトコルを使用してアクセス可能になります。ポリシーの分布は、プッシュまたはプル操作である場合があります。
The group key management architecture assumes that the following group policy information may be externally managed, e.g., by the content owner, group conference administrator or group owner:
グループキーマネジメントアーキテクチャは、次のグループポリシー情報が外部から管理される可能性があると想定しています。
o the identity of the Group owner, the authentication method, and the delegation method for identifying a GCKS for the group;
o グループ所有者の身元、認証方法、およびグループのGCKを識別する委任方法。
o the group GCKS, authentication method, and delegation method for any subordinate GCKSs for the group;
o グループGCKS、認証方法、およびグループの下位GCKSの委任方法。
o the group membership rules or list and authentication method.
o グループメンバーシップルールまたはリストおよび認証方法。
There are two additional policy-related requirements external to group key management.
キー管理をグループ化するための外部の2つの追加のポリシー関連の要件があります。
o There is an authentication and authorization infrastructure such as X.509 [RFC3280], SPKI [RFC2693], or a pre-shared key scheme, in accordance with the group policy for a particular group.
o 特定のグループのグループポリシーに従って、X.509 [RFC3280]、SPKI [RFC2693]、または事前に共有されたキースキームなどの認証および認証インフラストラクチャがあります。
o There is an announcement mechanism for secure groups and events, which operates according to group policy for a particular group.
o 特定のグループのグループポリシーに従って動作する安全なグループとイベントの発表メカニズムがあります。
Group policy determines how the registration and rekey protocols initialize or update Rekey and Data SAs. The following sections describe potential information sent by the GCKS for the Rekey and Data SAs. A member needs the information specified in the next sections to establish Rekey and Data SAs.
グループポリシーは、登録とRekeyのプロトコルがRekeyとData SASを初期化または更新する方法を決定します。次のセクションでは、GCKSがREKEYおよびデータSASのために送信した潜在的な情報について説明します。メンバーは、次のセクションで指定された情報を必要として、REKEYとデータSASを確立します。
The Rekey SA protects the rekey protocol. It contains cryptographic policy, Group Identity, and Security Parameter Index (SPI) [RFC2401] to uniquely identify an SA, replay protection information, and key protection keys.
Rekey SAは、Rekeyプロトコルを保護します。暗号化ポリシー、グループID、およびセキュリティパラメーターインデックス（SPI）[RFC2401]が含まれており、SA、リプレイ保護情報、およびキー保護キーを一意に識別します。
o GROUP KEY MANAGEMENT ALGORITHM
o グループキー管理アルゴリズム
This represents the group key revocation algorithm that enforces forward and backward access control. Examples of key revocation algorithms include LKH, LKH+, OFT, OFC, and Subset Difference [RFC2627,OFT,TAXONOMY,SD1,SD2]. If the key revocation algorithm is NULL, the Rekey SA contains only one KEK, which serves as the group KEK. The rekey messages initialize or update Data SAs as usual. However, the Rekey SA itself can be updated (the group KEK can be rekeyed) when members join or the KEK is about to expire. Leave rekeying is done by re-initializing the Rekey SA through the rekey protocol.
これは、前方および後方のアクセス制御を実施するグループキー取消アルゴリズムを表します。重要な取り消しアルゴリズムの例には、LKH、LKH、OFT、OFC、およびサブセットの差[RFC2627、OFT、分類法、SD1、SD2]が含まれます。重要な取り消しアルゴリズムがNULLの場合、Reke SAにはグループKEKとして機能する1つのKekのみが含まれています。Rekeyメッセージは、通常どおりデータSASを初期化または更新します。ただし、メンバーが参加したり、KEKが期限切れになったりすると、Reke SA自体を更新できます（グループKEKを再キーにすることができます）。Reke SaをRekey Protocolを使用して、Reke SAを再考することにより、Rekeyを残すことが行われます。
o KEK ENCRYPTION ALGORITHM
o Kek暗号化アルゴリズム
This specifies a standard encryption algorithm such as 3DES or AES, and also the KEK KEY LENGTH.
これは、3DEやAEなどの標準の暗号化アルゴリズムと、KEKキーの長さを指定します。
o AUTHENTICATION ALGORITHM
o 認証アルゴリズム
This algorithm uses digital signatures for GCKS authentication (since all shared secrets are known to some or all members of the group), or some symmetric secret in computing MACs for group authentication. Symmetric authentication provides weaker authentication in that any group member can impersonate a particular source. The AUTHENTICATION KEY LENGTH is also to be specified.
このアルゴリズムは、GCKS認証にデジタル署名を使用します（すべての共有秘密はグループの一部またはすべてのメンバーに知られているため）、またはグループ認証のためにMACを計算する際に対称的な秘密を使用します。対称認証は、特定のソースになりすましてもらうことができるという点で、より弱い認証を提供します。認証キーの長さも指定されます。
o CONTROL GROUP ADDRESS
o コントロールグループアドレス
This address is used for multicast transmission of rekey messages. This information is sent over the control channel such as in an ANNOUNCEMENT protocol or call setup message. The degree to which the control group address is protected is a matter of group policy.
このアドレスは、Rekeyメッセージのマルチキャスト送信に使用されます。この情報は、発表プロトコルやセットアップメッセージを呼び出すなどの制御チャネルを介して送信されます。コントロールグループの住所が保護されている程度は、グループポリシーの問題です。
o REKEY SERVER ADDRESS
o 再キーサーバーアドレス
This address allows the registration server to be a different entity from the server used for rekeying, such as for future invocations of the registration and rekey protocols. If the registration server and the rekey server are two different entities, the registration server sends the rekey server's address as part of the Rekey SA.
このアドレスにより、登録サーバーは、登録プロトコルの将来の呼び出しなど、再キーイングに使用されるサーバーとは異なるエンティティになることができます。登録サーバーとRekeyサーバーが2つの異なるエンティティである場合、登録サーバーはReke SAの一部としてRekey Serverのアドレスを送信します。
The group identity accompanies the SA (payload) information as an identifier if the specific group key management protocol allows multiple groups to be initialized in a single invocation of the registration protocol, or multiple groups to be updated in a single rekey message. It is often simpler to restrict each registration invocation to a single group, but such a restriction is unnecessary. It is always necessary to identify the group when establishing a Rekey SA, either implicitly through an SPI or explicitly as an SA parameter.
グループIDは、特定のグループキー管理プロトコルが登録プロトコルの単一の呼び出しで複数のグループを初期化できる場合、または複数のグループを単一のRekeメッセージで更新できる場合、識別子としてSA（ペイロード）情報を添付します。多くの場合、各登録の呼び出しを単一のグループに制限する方が簡単ですが、そのような制限は不要です。SPIを介して暗黙的に、またはSAパラメーターとして明示的に、REKEY SAを確立するときにグループを識別する必要があります。
Corresponding to the key management algorithm, the Rekey SA contains one or more KEKs. The GCKS holds the key encrypting keys of the group, while the members receive keys following the specification of the key management algorithm. When there are multiple KEKs for a group (as in an LKH tree), each KEK needs to be associated with a Key ID, which is used to identify the key needed to decrypt it. Each KEK has a LIFETIME associated with it, after which the KEK expires.
主要な管理アルゴリズムに対応して、Reke SAには1つ以上のKEKが含まれています。GCKSはグループのキー暗号化キーを保持し、メンバーはキー管理アルゴリズムの仕様に従ってキーを受け取ります。（LKHツリーのように）グループに複数のKEKがある場合、各kekはキーIDに関連付けられる必要があります。これは、それを復号化するために必要なキーを識別するために使用されます。各kekにはそれに関連する寿命があり、その後ケックの有効期限が切れます。
The GCKS provides a symmetric or public key for authentication of its rekey messages. Symmetric key authentication is appropriate only when all group members can be trusted not to impersonate the GCKS. The architecture does not rule out methods for deriving symmetric authentication keys at the member [RFC2409] rather than pushing them from the GCKS.
GCKSは、REKEYメッセージを認証するための対称または公開キーを提供します。対称キー認証は、すべてのグループメンバーがGCKになりすまさないと信頼できる場合にのみ適切です。アーキテクチャは、GCKSからプッシュするのではなく、メンバー[RFC2409]で対称認証キーを導出する方法を排除しません。
Rekey messages need to be protected from replay/reflection attacks. Sequence numbers are used for this purpose, and the Rekey SA (or protocol) contains this information.
再キーメッセージは、リプレイ/リフレクション攻撃から保護する必要があります。この目的にはシーケンス番号が使用され、Rekey SA（またはプロトコル）にはこの情報が含まれています。
The tuple <Group identity, SPI> uniquely identifies a Rekey SA. The SPI changes each time the KEKs change.
Tuple <Group Identity、spi>は、レキーSAを一意に識別します。KEKが変更されるたびにSPIが変更されます。
The GCKS specifies the data security protocol used for secure transmission of data from sender(s) to receiving members. Examples of data security protocols include IPsec ESP [RFC2401] and SRTP [RFC3711]. While the contents of each of these protocols are out of the scope of this document, we list the information sent by the registration protocol (or the rekey protocol) to initialize or update the Data SA.
GCKSは、送信者から受信メンバーへのデータの安全な送信に使用されるデータセキュリティプロトコルを指定します。データセキュリティプロトコルの例には、IPSEC ESP [RFC2401]およびSRTP [RFC3711]が含まれます。これらの各プロトコルの内容はこのドキュメントの範囲外ですが、登録プロトコル（またはRekeyプロトコル）から送信された情報をリストして、データSAを初期化または更新します。
The Group identity accompanies SA information when Data SAs are initialized or rekeyed for multiple groups in a single invocation of the registration protocol or in a single Rekey message.
グループIDは、登録プロトコルの単一の呼び出しまたは単一のRekeメッセージで、データSASが複数のグループに対して初期化または再キーにされた場合、SA情報を添付します。
The SA includes source identity information when the group owner chooses to reveal source identity to authorized members only. A public channel such as the announcement protocol is only appropriate when there is no need to protect source or group identities.
SAには、グループの所有者が認可されたメンバーのみにソースIDを表示することを選択したときにソースID情報が含まれています。発表プロトコルなどのパブリックチャネルは、ソースまたはグループのIDを保護する必要がない場合にのみ適切です。
Regardless of the data security protocol used, the GCKS supplies the TPKs, or information to derive TPKs for traffic protection.
使用されるデータセキュリティプロトコルに関係なく、GCKSはTPKまたは情報を提供して、トラフィック保護のためにTPKを導き出すために提供します。
Depending on the data authentication method used by the data security protocol, group key management may pass one or more keys, functions (e.g., TESLA [TESLA-INFO,TESLA-SPEC]), or other parameters used for authenticating streams or files.
データセキュリティプロトコルで使用されるデータ認証方法に応じて、グループキー管理は、1つ以上のキー、関数（Tesla [Tesla-Info、Tesla-Spec]）、またはストリームまたはファイルの認証に使用されるその他のパラメーターを渡すことができます。
The GCKS passes sequence numbers when needed by the data security protocol, for SA synchronization and replay protection.
GCKSは、SAの同期とリプレイ保護のために、データセキュリティプロトコルで必要なときにシーケンス番号を渡します。
The GCKS may provide an identifier as part of the Data SA contents for data security protocols that use an SPI or similar mechanism to identify an SA or keys within an SA.
GCKSは、SPIまたは同様のメカニズムを使用してSA内のSAまたはキーを識別するデータセキュリティプロトコルのデータSAコンテンツの一部として識別子を提供する場合があります。
The Data SA parameters are specific to the data security protocol but generally include encryption algorithm and parameters, the source authentication algorithm and parameters, the group authentication algorithm and parameters, and/or replay protection information.
データSAパラメーターはデータセキュリティプロトコルに固有ですが、一般に暗号化アルゴリズムとパラメーター、ソース認証アルゴリズムとパラメーター、グループ認証アルゴリズムとパラメーター、および/またはリプレイ保護情報が含まれます。
The area of group communications is quite diverse. In teleconferencing, a multipoint control unit (MCU) may be used to aggregate a number of teleconferencing members into a single session; MCUs may be hierarchically organized as well. A loosely coupled teleconferencing session [RFC3550] has no central controller but is fully distributed and end-to-end. Teleconferencing sessions tend to have at most dozens of participants. However, video broadcast that uses multicast communications and media-on-demand that uses unicast are large-scale groups numbering hundreds to millions of participants.
グループコミュニケーションの分野は非常に多様です。テレコンファレンスでは、多数のテレコンファレンスメンバーを単一のセッションに集約するために、マルチポイントコントロールユニット（MCU）を使用することができます。MCUも階層的に組織されている可能性があります。ゆるく結合された通信セッション[RFC3550]には、中央コントローラーはありませんが、完全に分布しており、エンドツーエンドです。テレコンファレンスセッションには、ほとんど数十人の参加者がいる傾向があります。ただし、ユニキャストを使用するマルチキャストコミュニケーションとメディアオンデマンドを使用するビデオブロードキャストは、数百人から数百万人の参加者を数える大規模なグループです。
As described in the Requirements section, Section 2, the group key management architecture supports multicast applications with a single sender. The architecture described in this paper supports large-scale operation through the following features.
要件セクションのセクション2で説明されているように、グループキー管理アーキテクチャは、単一の送信者とのマルチキャストアプリケーションをサポートしています。この論文で説明されているアーキテクチャは、次の機能を通じて大規模な操作をサポートしています。
1. There is no need for a unicast exchange to provide data keys to a security protocol for members who have previously registered in the particular group; data keys can be pushed in the rekey protocol.
1. 特定のグループに以前に登録したメンバーのセキュリティプロトコルにデータキーを提供するユニキャスト交換は必要ありません。データキーはRekeyプロトコルでプッシュできます。
2. The registration and rekey protocols are separable to allow flexibility in how members receive group secrets. A group may use a smart-card based system in place of the registration protocol, for example, to allow the rekey protocol to be used with no back channel for broadcast applications such as television conditional access systems.
2. 登録およびRekeyプロトコルは、メンバーがグループの秘密を受け取る方法の柔軟性を可能にするために分離可能です。グループは、たとえば、登録プロトコルの代わりにスマートカードベースのシステムを使用して、テレビ条件付きアクセスシステムなどのブロードキャストアプリケーション用のバックチャネルなしでRekeyプロトコルを使用できるようにすることができます。
3. The registration and rekey protocols support new keys, algorithms, authentication mechanisms and authorization infrastructures in the architecture. When the authorization infrastructure supports delegation, as in X.509 and SPKI, the GCKS function can be distributed as shown in Figure 3 below.
3. 登録およびRekeyプロトコルは、アーキテクチャの新しいキー、アルゴリズム、認証メカニズム、および認証インフラストラクチャをサポートしています。X.509およびSPKIのように、承認インフラストラクチャが代表団をサポートする場合、GCKS関数は以下の図3に示すように分布できます。
The first feature in the list allows fast keying of data security protocols when the member already belongs to the group. While this is realistic for subscriber groups and customers of service providers who offer content events, it may be too restrictive for applications that allow member enrollment at the time of the event. The MSEC group key management architecture suggests hierarchically organized key distribution to handle potential mass simultaneous registration requests. The Figure 3 configuration may be needed when conventional clustering and load balancing solutions of a central GCKS site cannot meet customer requirements. Unlike conventional caching and content distribution networks, however, the configuration shown in Figure 3 has additional security ramifications for physical security of a GCKS.
リストの最初の機能により、メンバーがすでにグループに属している場合、データセキュリティプロトコルを迅速にキーインすることができます。これは、コンテンツイベントを提供するサブスクライバーグループやサービスプロバイダーの顧客にとっては現実的ですが、イベントの時点でメンバーの登録を可能にするアプリケーションには制限が強すぎる可能性があります。MSEC Group Key Managementアーキテクチャは、潜在的な質量登録リクエストを処理するために階層的に整理されたキーディストリビューションを提案しています。中央GCKSサイトの従来のクラスタリングおよびロードバランシングソリューションが顧客の要件を満たしていない場合、図3構成が必要になる場合があります。ただし、従来のキャッシュやコンテンツ配信ネットワークとは異なり、図3に示す構成には、GCKの物理的セキュリティのための追加のセキュリティの影響があります。
+----------------------------------------+
| +-------+ |
| | GCKS | |
| +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| +-------------+ |
| | | |
| v ... v |
| +-------+ +-------+ |
| | GCKS | | GCKS | |
| +-------+ +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| ... |
+----------------------------------------+
Figure 3: Hierarchically Organized Key Distribution
図3：階層的に整理された重要な分布
More analysis and work is needed on the protocol instantiations of the group key management architecture, to determine how effectively and securely the architecture can support large-scale multicast applications. In addition to being as secure as pairwise key management against man-in-the-middle, replay, and reflection attacks, group key management protocols have additional security needs. Unlike pairwise key management, group key management needs to be secure against attacks by group members who attempt to impersonate a GCKS or disrupt the operation of a GCKS, as well as by non-members.
アーキテクチャが大規模なマルチキャストアプリケーションをどの程度効果的かつ安全にサポートできるかを判断するために、グループキー管理アーキテクチャのプロトコルインスタンス化にさらに分析と作業が必要です。中間者、リプレイ、リフレクション攻撃に対するペアワイズキー管理と同じくらい安全であることに加えて、グループキー管理プロトコルには追加のセキュリティニーズがあります。ペアワイズキー管理とは異なり、グループキー管理は、GCKになりすましたり、GCKの操作を破壊しようとするグループメンバーによる攻撃に対して安全である必要があります。
Thus, secure groups need to converge to a common group key when members are attacking the group, joining and leaving the group, or being evicted from the group. Group key management protocols also need to be robust when DoS attacks or network partition leads to large numbers of synchronized requests. An instantiation of group key management, therefore, needs to consider how GCKS operation might be distributed across multiple GCKSs designated by the group owner to serve keys on behalf of a designated GCKS. GSAKMP [GSAKMP] protocol uses the policy token and allows designating some of the members as subordinate GCKSs to address this scalability issue.
したがって、安全なグループは、メンバーがグループに攻撃したり、グループに参加して出発したり、グループから立ち退きしたりしているときに、共通のグループキーに収束する必要があります。Group Key Managementプロトコルは、DOS攻撃またはネットワークパーティションが多数の同期リクエストにつながる場合にも堅牢である必要があります。したがって、グループキー管理のインスタンス化は、指定されたGCKSに代わってキーを提供するためにグループ所有者によって指定された複数のGCKSにGCKS操作をどのように分配するかを検討する必要があります。GSAKMP [GSAKMP]プロトコルはポリシートークンを使用しており、一部のメンバーを下位GCKSSとして指定して、このスケーラビリティの問題に対処することができます。
This memo describes MSEC key management architecture. This architecture will be instantiated in one or more group key management protocols, which must be protected against man-in-the-middle, connection hijacking, replay, or reflection of past messages, and denial of service attacks.
このメモは、MSECキー管理アーキテクチャについて説明しています。このアーキテクチャは、1つまたは複数のグループキー管理プロトコルにインスタンス化されます。これは、中間者、接続ハイジャック、リプレイ、または過去のメッセージの反映、およびサービス攻撃の拒否に対して保護する必要があります。
Authenticated key exchange [STS,SKEME,RFC2408,RFC2412,RFC2409] techniques limit the effects of man-in-the-middle and connection hijacking attacks. Sequence numbers and low-computation message authentication techniques can be effective against replay and reflection attacks. Cookies [RFC2522], when properly implemented, provide an efficient means to reduce the effects of denial of service attacks.
認証されたキーエクスチェンジ[STS、Skeme、RFC2408、RFC2412、RFC2409]手法は、中間および接続のハイジャック攻撃の影響を制限します。シーケンス番号と低計算メッセージ認証手法は、リプレイおよび反射攻撃に対して効果的です。Cookie [RFC2522]は、適切に実装されている場合、サービス拒否攻撃の影響を減らすための効率的な手段を提供します。
This memo does not address attacks against key management or security protocol implementations such as so-called type attacks that aim to disrupt an implementation by such means as buffer overflow. The focus of this memo is on securing the protocol, not on implementing the protocol.
このメモは、バッファオーバーフローなどの手段で実装を破壊することを目的とする、いわゆるタイプ攻撃などの主要な管理またはセキュリティプロトコルの実装に対する攻撃に対処しません。このメモの焦点は、プロトコルの実装ではなく、プロトコルの保護にあります。
While classical techniques of authenticated key exchange can be applied to group key management, new problems arise with the sharing of secrets among a group of members: group secrets may be disclosed by a member of the group, and group senders may be impersonated by other members of the group. Key management messages from the GCKS should not be authenticated using shared symmetric secrets unless all members of the group can be trusted not to impersonate the GCKS or each other. Similarly, members who disclose group secrets undermine the security of the entire group. Group owners and GCKS administrators must be aware of these inherent limitations of group key management.
認証されたキー交換の古典的な手法はグループキー管理に適用できますが、メンバーのグループ間で秘密を共有することで新しい問題が発生します。グループの秘密はグループのメンバーによって開示され、グループ送信者は他のメンバーによって偽装される場合がありますグループの。GCKSからの主要な管理メッセージは、グループのすべてのメンバーがGCKSまたは互いになりすまさないと信頼できない限り、共有対称秘密を使用して認証されるべきではありません。同様に、グループの秘密を開示するメンバーは、グループ全体のセキュリティを損なうものです。グループ所有者とGCKS管理者は、グループキー管理のこれらの固有の制限に注意する必要があります。
Another limitation of group key management is policy complexity. While peer-to-peer security policy is an intersection of the policy of the individual peers, a group owner sets group security policy externally in secure groups. This document assumes there is no negotiation of cryptographic or other security parameters in group key management. Group security policy, therefore, poses new risks to members who send and receive data from secure groups. Security administrators, GCKS operators, and users need to determine minimal acceptable levels of security (e.g., authentication and admission policy of the group, key lengths, cryptographic algorithms and protocols used) when joining secure groups.
グループキー管理のもう1つの制限は、ポリシーの複雑さです。ピアツーピアセキュリティポリシーは個々のピアのポリシーの交差点ですが、グループ所有者は安全なグループでグループセキュリティポリシーを外部的に設定します。このドキュメントは、グループキー管理に暗号化またはその他のセキュリティパラメーターの交渉がないと想定しています。したがって、グループセキュリティポリシーは、安全なグループからデータを送信および受信するメンバーに新たなリスクをもたらします。セキュリティ管理者、GCKSオペレーター、およびユーザーは、安全なグループに参加する際に、最小限の許容レベルのセキュリティ（グループの認証と入学ポリシー、キー長、暗号化アルゴリズム、およびプロトコル）を決定する必要があります。
Given the limitations and risks of group security, the security of the group key management registration protocol should be as good as the base protocols on which it is developed, such as IKE, IPsec, TLS, or SSL. The particular instantiations of this group key management architecture must ensure that the high standards for authenticated key exchange are preserved in their protocol specifications, which will be Internet standards-track documents that are subject to review, analysis, and testing.
グループセキュリティの制限とリスクを考えると、グループキー管理登録プロトコルのセキュリティは、IKE、IPSEC、TLS、SSLなどのベースプロトコルと同じくらい良いものでなければなりません。このグループの主要な管理アーキテクチャの特定のインスタンス化は、認証されたキー交換の高い基準がプロトコル仕様に保存されていることを確認する必要があります。これは、レビュー、分析、テストの対象となるインターネット標準トラックドキュメントです。
The second protocol, the group key management rekey protocol, is new and has unknown risks. The source-authentication risks described above are obviated by the use of public-key cryptography. The use of multicast delivery may raise additional security issues such as reliability, implosion, and denial-of-service attacks based upon the use of multicast. The rekey protocol specification needs to offer secure solutions to these problems. Each instantiation of the rekey protocol, such as the GSAKMP Rekey or the GDOI Groupkey-push operations, need to validate the security of their rekey specifications.
2番目のプロトコルであるGroup Key Management Rekey Protocolは新しく、リスクが不明です。上記の源泉因子性のリスクは、パブリックキー暗号化の使用によって除外されます。マルチキャスト配信を使用すると、マルチキャストの使用に基づいて、信頼性、爆縮、サービス拒否攻撃などの追加のセキュリティ問題が発生する場合があります。Rekeyプロトコル仕様は、これらの問題に対する安全なソリューションを提供する必要があります。GSAKMP RekeyやGDOI GroupKey-Push操作など、Rekeyプロトコルの各インスタンス化は、REKEY仕様のセキュリティを検証する必要があります。
Novelty and complexity are the biggest risks to group key management protocols. Much more analysis and experience are needed to ensure that the architecture described in this document can provide a well-articulated standard for security and risks of group key management.
ノベルティと複雑さは、主要な管理プロトコルをグループ化するための最大のリスクです。このドキュメントに記載されているアーキテクチャが、グループキー管理のセキュリティとリスクに関する明確な基準を提供できるようにするために、さらに多くの分析と経験が必要です。
The GKM Building Block [GKMBB] I-D by SMuG was a precursor to this document; thanks to Thomas Hardjono and Hugh Harney for their efforts. During the course of preparing this document, Andrea Colegrove, Brian Weis, George Gross, and several others in the MSEC WG and GSEC and SMuG research groups provided valuable comments that helped improve this document. The authors appreciate their contributions to this document.
SmugのGKMビルディングブロック[GKMBB] I-Dは、このドキュメントの前兆でした。Thomas HardjonoとHugh Harneyの努力に感謝します。この文書の準備中に、Andrea Colegrove、Brian Weis、George Gross、およびMSEC WGおよびGSECおよびSmugの研究グループの他のいくつかは、この文書の改善に役立つ貴重なコメントを提供しました。著者は、この文書への貢献に感謝しています。
[BatchRekey] Yang, Y. R., et al., "Reliable Group Rekeying: Design and Performance Analysis", Proc. ACM SIGCOMM, San Diego, CA, August 2001.
[Batchrekey] Yang、Y。R.、et al。、「信頼できるグループの再キーイング：設計とパフォーマンス分析」、Proc。2001年8月、カリフォルニア州サンディエゴのACM Sigcomm。
[CLIQUES] Steiner, M., Tsudik, G., and M. Waidner, "CLIQUES: A New Approach to Group Key Agreement", IEEE ICDCS 97, May 1997
[クリーク] Steiner、M.、Tsudik、G。、およびM. Waidner、「Cliques：A Group Key契約への新しいアプローチ」、IEEE ICDCS 97、1997年5月
[FN93] Fiat, A. and M. Naor, "Broadcast Encryption, Advances in Cryptology", CRYPTO 93 Proceedings, Lecture Notes in Computer Science, Vol. 773, pp. 480-491, 1994.
[FN93] Fiat、A。およびM. Naor、「放送暗号化、暗号化の進歩」、Crypto 93 Proceedings、Computer Scienceの講義ノート、Vol。773、pp。480-491、1994。
[GKMBB] Harney, H., M. Baugher, and T. Hardjono, "GKM Building Block: Group Security Association (GSA) Definition," Work in Progress, September 2000.
[GKMBB] Harney、H.、M。Baugher、およびT. Hardjono、「GKMビルディングブロック：グループセキュリティ協会（GSA）定義」、Work in Progress、2000年9月。
[GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., and R. Fleischer, "Group Secure Association Key Management Protocol", Work in Progress, February 2003.
[GSAKMP] Harney、H.、Colegrove、A.、Harder、E.、Meth、U.、およびR. Fleischer、「Group Secure Association Key Management Protocol」、Work in Progress、2003年2月。
[GSPT] Hardjono, T., Harney, H., McDaniel, P., Colegrove, A., and P. Dinsmore, "The MSEC Group Security Policy Token", Work in Progress, August 2003.
[GSPT] Hardjono、T.、Harney、H.、McDaniel、P.、Colegrove、A。、およびP. Dinsmore、「The MSEC Group Security Policy Token」、Work in Progress、2003年8月。
[H.235] International Telecommunications Union, "Security and Encryption for H-Series (H.323 and other H.245-based) Multimedia Terminals", ITU-T Recommendation H.235 Version 3, Work in progress, 2001.
[H.235] International Telecommunications Union、「Hシリーズのセキュリティと暗号化（H.323およびその他のH.245ベース）マルチメディアターミナル」、ITU-T推奨H.235バージョン3、作業中、2001年。
[JKKV94] Just, M., Kranakis, E., Krizanc, D., and P. van Oorschot, "On Key Distribution via True Broadcasting", Proc. 2nd ACM Conference on Computer and Communications Security, pp. 81-88, November 1994.
[Jkkv94] Just、M.、Kranakis、E.、Krizanc、D。、およびP. Van Oorschot、「True Broadcastingを介したキーディストリビューション」、Proc。1994年11月、コンピューターおよび通信セキュリティに関する第2回ACM会議、81-88ページ。
[MARKS] Briscoe, B., "MARKS: Zero Side Effect Multicast Key Management Using Arbitrarily Revealed Key Sequences", Proc. First International Workshop on Networked Group Communication (NGC), Pisa, Italy, November 1999.
[マーク] Briscoe、B。、「マーク：ゼロ副作用マルチキャストキー管理を任意に公開したキーシーケンス」、Proc。1999年11月、イタリアのピサにあるネットワークグループコミュニケーション（NGC）に関する最初の国際ワークショップ。
[MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[Mikey] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、RFC 3830、2004年8月。
[MSEC-Arch] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[MSEC-ARCH] Hardjono、T。およびB. Weis、「マルチキャストグループセキュリティアーキテクチャ」、RFC 3740、2004年3月。
[MVV] Menzes, A.J., van Oorschot, P.C., and S.A. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1996.
[MVV] Menzes、A.J.、Van Oorschot、P.C。、およびS.A. Vanstone、「Handbook of Applied Cryptography」、CRC Press、1996。
[NORM] Adamon, B., Bormann, C., Handley, M., and J. Macker, "Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November 2004.
[Norm] Adamon、B.、Bormann、C.、Handley、M。、およびJ. Macker、「ネガティブ・クノウレッド（NACK）指向の信頼できるマルチキャスト（NORM）プロトコル」、RFC 3940、2004年11月。
[OFT] Balenson, D., McGrew, P.C., and A. Sherman, "Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization", IRTF Work in Progress, August 2000.
[OFT] Balenson、D.、McGrew、P.C。、およびA. Sherman、「大規模な動的グループの重要な管理：一方向の関数ツリーと償却初期化」、IRTF作業中の2000年8月。
[RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC2093] Harney、H。およびC. Muckenhirn、「グループキー管理プロトコル（GKMP）仕様」、RFC 2093、1997年7月。
[RFC2094] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture" RFC 2094, July 1997.
[RFC2094] Harney、H。、およびC. Muckenhirn、「グループキー管理プロトコル（GKMP）アーキテクチャ」RFC 2094、1997年7月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367] McDonald、D.、Metz、C。、およびB. Phan、「PF_KEY Key Management API、バージョン2」、RFC 2367、1998年7月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408] Maughan、D.、Schertler、M.、Schneider、M.、およびJ. Turner、「Internet Security Association and Key Management Protocol（ISAKMP）」、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412] Orman、H。、「The Oakley Key Deicination Protocol」、RFC 2412、1998年11月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P。およびW. Simpson、「Phyuris：Session-Key Management Protocol」、RFC 2522、1999年3月。
[RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999.
[RFC2693] Ellison、C.、Frantz、B.、Lampson、B.、Rivest、R.、Thomas、B。、およびT. Ylonen、「SPKI証明書理論」、RFC 2693、1999年9月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、Polk、W.、Ford、W.、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[RFC2627] Wallner、D.、Harder、E。、およびR. Agee、「マルチキャストの重要な管理：問題とアーキテクチャ」、RFC 2627、1999年6月。
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[RFC3450] Luby、M.、Gemmell、J.、Vicisano、L.、Rizzo、L。、およびJ. Crowcroft、「非同期層コーディング（ALC）プロトコルインスタンス化」、RFC 3450、2002年12月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、RFC 3547、2003年7月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[SD1] Naor, D., Naor, M., and J. Lotspiech, "Revocation and Tracing Schemes for Stateless Receiver", Advances in Cryptology - CRYPTO, Santa Barbara, CA: Springer-Verlag Inc., LNCS 2139, August 2001.
[SD1] Naor、D.、Naor、M。、およびJ. Lotspiech、「Stateless Receiverの取り消しと追跡スキーム」、Cryptogy -Crypto、Crypto、Santa Barbara、CA：Springer -Verlag Inc.、LNCS 2139、2001年8月。
[SD2] Naor, M. and B. Pinkas, "Efficient Trace and Revoke Schemes", Proceedings of Financial Cryptography 2000, Anguilla, British West Indies, February 2000.
[SD2] Naor、M。and B. Pinkas、「効率的なトレースと取り消しスキーム」、Proceedings of Financial Cryptography 2000、Anguilla、British West Indies、2000年2月。
[Self-Healing] Staddon, J., et. al., "Self-healing Key Distribution with Revocation", Proc. 2002 IEEE Symposium on Security and Privacy, Oakland, CA, May 2002.
[自己癒し] Staddon、J.、et。al。、「失効した自己治癒キーディストリビューション」、Proc。2002年5月、カリフォルニア州オークランドのセキュリティとプライバシーに関するIEEEシンポジウム。
[SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", ISOC Secure Networks and Distributed Systems Symposium, San Diego, 1996.
[Skeme] H. Krawczyk、「Skeme：インターネットの多目的な安全なキー交換メカニズム」、ISOCセキュアネットワークおよび分散システムシンポジウム、1996年。
[STS] Diffie, P. van Oorschot, M., and J. Wiener, "Authentication and Authenticated Key Exchanges", Designs, Codes and Cryptography, 2, 107-125 (1992), Kluwer Academic Publishers.
[STS] Diffie、P。VanOorschot、M。、およびJ. Wiener、「認証と認証されたキー交換」、デザイン、コード、暗号化、2、107-125（1992）、Kluwer Academic Publishers。
[TAXONOMY] Canetti, R., et. al., "Multicast Security: A Taxonomy and some Efficient Constructions", IEEE INFOCOM, 1999.
[分類法] Canetti、R.、et。al。、「マルチキャストセキュリティ：分類法と効率的な構造」、IEEE Infocom、1999。
[TESLA-INFO] Perrig, A., Canetti, R., Song, D., Tygar, D., and B. Briscoe, "TESLA: Multicast Source Authentication Transform Introduction", Work in Progress, December 2004.
[Tesla-Info] Perrig、A.、Canetti、R.、Song、D.、Tygar、D.、およびB. Briscoe、「Tesla：Multicast Source Authentication Transformintrolling」、2004年12月の作業。
[TESLA-SPEC] Perrig, A., R. Canetti, and Whillock, "TESLA: Multicast Source Authentication Transform Specification", Work in Progress, April 2002.
[Tesla-Spec] Perrig、A.、R。Canetti、およびWhillock、「Tesla：Multicast Source Authentication Transform Specification」、2002年4月の作業。
[tGSAKMP] Harney, H., et. al., "Tunneled Group Secure Association Key Management Protocol", Work in Progress, May 2003.
[TGSAKMP] Harney、H.、et。al。、「Tunneled Group Secure Association Key Management Protocol」、2003年5月に進行中の作業。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0," RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[TPM] Marks, D. and B. Turnbull, "Technical protection measures: The Intersection of Technology, Law, and Commercial Licenses", Workshop on Implementation Issues of the WIPO Copyright Treaty (WCT) and the WIPO Performances and Phonograms Treaty (WPPT), World Intellectual Property Organization, Geneva, December 6 and 7, 1999.
[TPM] Marks、D。およびB. Turnbull、「技術保護対策：技術、法律、および商業ライセンスの交差点」、WIPO著作権条約（WCT）の実装問題に関するワークショップとWIPOパフォーマンスとフォノグラム条約（WPPT）、世界知的財産組織、ジュネーブ、1999年12月6日と7日。
[Wool] Wool, A., "Key Management for Encrypted broadcast", 5th ACM Conference on Computer and Communications Security, San Francisco, CA, Nov. 1998.
[ウール]ウール、A。、「暗号化されたブロードキャストの主要な管理」、1998年11月、カリフォルニア州サンフランシスコのコンピューターおよび通信セキュリティに関する第5回ACM会議。
Authors' Addresses
著者のアドレス
Mark Baugher Cisco Systems 5510 SW Orchid St. Portland, OR 97219, USA
マーク・ボーアー・シスコ・システム5510 SWオーキッド・セント・ポートランド、または97219、米国
Phone: +1 408-853-4418
EMail: mbaugher@cisco.com
Ran Canetti IBM Research 30 Saw Mill River Road Hawthorne, NY 10532, USA
RAN CANETTI IBM Research30 Saw Saw Mill River Road Hawthorne、ニューヨーク10532、米国
Phone: +1 914-784-7076
EMail: canetti@watson.ibm.com
Lakshminath R. Dondeti Qualcomm 5775 Morehouse Drive San Diego, CA 92121
Lakshminath R. Dondeti Qualcomm 5775 Morehouse Drive San Diego、CA 92121
Phone: +1 858 845 1267
EMail: ldondeti@qualcomm.com
Fredrik Lindholm Ericsson Research SE-16480 Stockholm, Sweden
Fredrik Lindholm Ericsson Research SE-16480ストックホルム、スウェーデン
Phone: +46 8 58531705
EMail: fredrik.lindholm@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。