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
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).
著作権（C）インターネット協会（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）キー管理プロトコルの共通アーキテクチャを定義して、さまざまなアプリケーション、トランスポート、およびネットワーク層のセキュリティプロトコルをサポートします。 また、グループセキュリティアソシエーション（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ネットワークのグループおよびマルチキャストアプリケーションには、さまざまなセキュリティ要件があります[TAXONOMY]。 セクション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グループキー管理アーキテクチャと呼ばれます。 これは、GKMP [RFC2094]で開発されたグループコントロールまたはキーサーバーモデルに基づいており、LKH [RFC2627]、OFT [OFT]、およびMARKS [MARKS]などのグループキー管理アルゴリズムによって想定されています。 このアーキテクチャでは、高度に分散されたクリークグループキー管理プロトコル[CLIQUES]やブロードキャストキー管理スキーム[FN93、Wool]など、考慮されていない他のアプローチがあります。 MSECキー管理は、実際には他のグループキー管理設計を補完するものですが、MSECグループキー管理とCliques、ブロードキャストキー管理、または他のグループキーシステムの統合は、このドキュメントでは考慮されていません。
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研究グループ[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ではキー再生成プロトコルについても同じことを行います。 セクション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.
ビデオブロードキャストやマルチキャストファイル転送などのマルチキャストアプリケーションには、通常、次のキー管理要件があります（[TAXONOMY]も参照）。 このリストは、すべてのアプリケーションに適用されるものでも、網羅的なものでもないことに注意してください。
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.グループキーに関連付けられたポリシーに加えて、グループ所有者またはGroup Controller and Key Server（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.大規模なグループを管理するGCKSを圧倒しないように、プロトコルは、メンバーとGroup Controller and Key Server（GCKS）間のユニキャスト交換なしでスケーラブルなグループキー再生成操作をサポートする必要があります。
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]またはデジタルビデオディスクプレーヤーなどのネットワーク化されていないデバイスの場合のブロードキャストキー管理です。 双方向通信を使用した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をデータ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.
これは、Group Controller and Key Server（GCKS）と参加グループメンバー間のユニキャストプロトコルです。 このプロトコルでは、GCKSと参加メンバーは相互に認証します。 認証に成功し、GCKSが参加メンバーが許可されていることを検出した場合、GCKSは参加メンバーに次の情報を提供します。（a）参加メンバー内のデータSAを初期化するための十分な情報。 この情報は、キー再生成プロトコルの一部として、またはそれに加えて、グループセキュリティポリシーが登録時にデータ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）加入メンバー内でRekey SAを初期化するための十分な情報（このSAの詳細については以下を参照）。 この情報は、グループセキュリティポリシーがキー再生成プロトコルを要求する場合に提供されます。
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と呼びます。 補完的な登録解除プロトコルは、Registration SA状態を明示的に削除するのに役立ちます。 メンバーは登録SA状態を削除することを選択できます。
(2) Rekey Protocol
（2）キー再生成プロトコル
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は、キーの再生成情報をグループメンバーに送信することにより、データSAを定期的に更新または変更する場合があります。 キーの再生成メッセージは、グループメンバーシップの変更、グループセキュリティポリシーの変更、特定のグループの新しいトラフィック保護キー（TPK、次のセクションを参照）の作成、またはキーの有効期限から発生する場合があります。 キー再生成メッセージは、登録プロトコルで初期化されたキー再生成SAによって保護されます。 Rekey SAやData 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]では、GCKSはセキュアグループのライフタイムのさまざまな期間のTPKを事前に決定し、メンバーシップ期間に基づいてメンバーにキーを配布します。 GCKSがセキュアグループを解散し、新しいデータSAで新しいグループを開始するなどの代替スキームも可能ですが、これは通常、小さなグループに限定されます。
Rekey messages are authenticated using one of the two following options:
キー再生成メッセージは、次の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）ソース認証[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）対称キーを使用したグループベースの認証のみを使用します。 メンバーは、キーの再生成メッセージがグループ内で発生したことのみを保証できます。 したがって、これは、グループのすべてのメンバーがGCKSを偽装しないことが信頼されている場合にのみ適用されます。 キー再生成メッセージのグループ認証は、通常、公開キー暗号化が特定のグループに適していない場合に使用されます。
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.
キー再生成プロトコルは、すべてのメンバーがキー再生成情報をタイムリーに受信することを保証します。 さらに、キー再生成プロトコルは、パーティがGCKSにアクセスして、キーの有効期限が切れ、更新されたキーを受信していない場合に再同期するためのメカニズムを指定します。 大規模グループ向けのキー再生成プロトコルは、爆縮問題を回避し、キーイングマテリアルの配信における信頼性を確保するメカニズムを提供します。
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.
キー再生成SAは登録プロトコルによって確立されますが、キー再生成プロトコルを使用して更新されます。 メンバーがグループを離れると、GSAのローカルコピーが破棄されます。 登録解除メッセージを使用することは、メンバーがSAを破壊したか、破壊しようとしていることを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プロトコルの全体的な設計を示しています。 各グループメンバー（送信者または受信者）は、登録プロトコルを使用して、特定のグループ、そのポリシー、およびそのキーへの承認および認証されたアクセスを取得します。 グループキーには、キー暗号化キー（KEK）とトラフィック暗号化キー（TEK）の2種類があります。 キー再生成メッセージまたはデータのグループ認証には、キー整合性またはトラフィック整合性キーも使用できます。 保護キーという用語を使用して、整合性キーと暗号化キーの両方を指します。 たとえば、トラフィック保護キー（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は、通常、新しいRekey SA（KEKを含む）および/またはData SA（TPK / TEKを含む）を含む、キー再生成メッセージを保護する単一のキーである場合があります。 Rekey SAには、グループキーメンバーシップアルゴリズム[RFC2627、OFT、TAXONOMY、SD1、SD2]の一部であるキーのベクトルも含まれる場合があります。 データセキュリティプロトコルはTPKを使用して、データセキュリティプロトコルによって送受信されるストリーム、ファイル、またはその他のデータを保護します。 したがって、登録プロトコルおよび/またはキー再生成プロトコルは、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がキー再生成メッセージを使用する場合、許可されたメンバーはキー再生成SAを受け取ります。 キー再生成SAには、グループのキー再生成ポリシー（すべてのポリシーをメンバーに公開する必要はないことに注意してください）と、少なくともグループKEKが含まれています。 さらに、GCKSは、キー再生成メッセージの整合性保護のためにグループキー整合性キーを送信します。 効率的なキー再生成にグループキー管理アルゴリズムが使用されている場合、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キーの再生成メッセージがグループに使用されていない場合、許可されたメンバーは（データセキュリティSAの一部として）TPKを受信し、メンバーのデータセキュリティプロトコルに渡されます（IKEが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は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.
KEKとTPKはグループ全体に共通しているため、GCKSはKEKとTPKを作成し、各メンバーにダウンロードします。 GCKSは、グループ所有者によって設定されたグループポリシーに従ってメンバーの認証と承認を実行する独立した論理エンティティです。 GCKSは、グループオーナーがグループメンバーに署名した資格情報を提示して、メンバーがGCKSの承認を確認できるようにします。 メンバーと同じ場所にあるか、物理的に分離されているGCKSは、キー再生成プロトコルを実行して、更新されたKEK、新しいTPK、および/または更新されたTPKを含むキー再生成メッセージをメンバーにプッシュします。 一部のグループ鍵管理アルゴリズムは、KEKのいずれかを（潜在的に）更新しますが、他のグループ鍵管理アルゴリズムはグループ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）を送信することができます。 前述のように、キー再生成メッセージはユニキャストまたはマルチキャスト配信を使用して送信できます。 キー再生成メッセージまたは登録プロトコル交換を介して（データSAの一部として）TPKを受信すると、メンバーのグループキー管理機能ブロックは、新しいまたは更新されたセキュリティアソシエーション（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.
Data SAは、図1に示すDATA SECURITY PROTOCOLとラベル付けされたアークで送信されるデータを保護します。 すべてのキー、KEKおよびTPKは、図1に示す登録プロトコル交換によって配信でき、これらのキーを更新する必要がないため、キーの再生成メッセージはオプションです。 登録プロトコルは、GCKSと各メンバー間の3番目のユニキャストSAによって保護されています。 これは登録SAと呼ばれます。 登録プロトコル交換の完了後、登録SAが所定の場所に残る必要はないかもしれません。 登録解除プロトコルは、SAの明示的なティアダウンが望ましい場合（電話または会議が終了する場合など）に使用できます。 3つのSAがGSAを構成します。 オプションのSAはRekey 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]の完全なアーキテクチャの一部としてのSAとその使用をさらに明確にします。
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）登録プロトコルでの認証済みキー交換とキー再生成プロトコルの分離を可能にし、（2）キー再生成プロトコルがグループおよびデータキーのユニキャストプッシュまたはマルチキャスト配信を使用できるようにすることで、スケーラブルな操作を実現します オプション、（3）ユニキャスト登録プロトコルによってすべてのキーを取得できるようにする、（4）GCKSの機能を複数のエンティティ間で委任する、つまり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で単純に暗号化され、キー再生成プロトコルでユニキャストまたはマルチキャストで送信されます。
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 SAまたは1つ以上のデータSA、または両方のタイプのSAを確立します。 SAの少なくとも1つが存在します（それ以外の場合、登録SAには目的がありません）。 キー再生成SAは、キー再生成SAを更新するか、1つ以上のデータSAを確立または更新します。 個々のプロトコルまたは構成では、この柔軟性を使用して効率的な操作を実現できます。
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のブロック図では、グループキー管理プロトコルがGCKSとメンバープリンシパル間で実行され、グループセキュリティアソシエーション（GSA）を確立しています。 GSAは、データSA、オプションのキー再生成SA、および登録SAで構成されます。 GCKSは、GCKSによって署名された委任資格を持つ、送信者などの委任されたプリンシパルを使用できます。 図2のメンバーは、マルチキャストまたはユニキャストデータの送信者または受信者である場合があります。 図には2つの機能ブロックがあります
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はGKMとラベル付けされ、それらの間に2つのアークがあり、グループキー管理登録（reg）およびキー再生成（rek）プロトコルを表します。 メッセージ交換は、上記の登録プロトコルとキー再生成プロトコルである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は、完全なグループキー管理機能仕様にメッセージ交換以外の多くの要素が含まれていることを示しています。 これらの機能ブロックの一部とそれらの間のアークは、IPsecの更新をサポートする製品のベンダー仕様など、オペレーティングシステム（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のCRED）。
+----------------------------------------------------------+
| |
| +-------------+ +------------+ |
| | 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.
CONTROL関数は、GCKSにグループの確立、メンバーの承認、メンバーの削除を指示するか、メンバーにグループへの参加またはグループからの脱退を指示します。 CONTROLにはグループポリシー[GSPT]の対象となる承認が含まれますが、その実装はGCKSに固有です。大規模なマルチキャストセッションの場合、CONTROLはセッションアナウンスメント機能を実行して、グループに参加したりグループデータを受信したりする可能性があることを潜在的なグループメンバーに通知できます（データセキュリティプロトコルで保護されたファイル転送のストリームなど）。発表は、安全なマルチキャストデータ送信の前にマルチキャストSAを確立するようにグループメンバーに通知します。セッション記述プロトコル（SDP）は、アナウンスメントが取る可能性のある1つの形式です[RFC2327]。アナウンス機能は、セッションディレクトリツール、電子番組ガイド（EPG）、またはその他の手段で実装できます。データセキュリティ機能またはアナウンス機能は、アプリケーションプログラミングインターフェイス（API）を使用してグループキー管理を指示します。これは、ホストOSに固有の特性です。グループキー管理用の汎用APIは今後の検討用ですが、グループ（KEK）およびデータ（TPK）キーの確立を特定のアプリケーションに拡張できるようにするには、この機能が必要です。 GCKSアプリケーションプログラムは、APIを使用して、メンバーがセキュリティで保護されたグループに参加し、ストリーム、ファイル、またはその他のデータのキーを受信するセキュリティプロトコルに代わってSAを確立する手順を開始します。
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.
交換の目標は、鍵管理の実装と特定のセキュリティプロトコルのSADの更新を通じて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.
登録プロトコルの設計は柔軟であり、さまざまなアプリケーションシナリオをサポートできます。 選択された登録プロトコルソリューションは、特定のシナリオの特定の要件を反映しています。 原則として、トンネル化されたGSAKMP [tGSAKMP]の場合、IPsecやTLSなどのセキュアチャネルプロトコルに基づいて登録プロトコルを作成できます。 GDOI [RFC3547]は、IKEフェーズ1を安全なチャネルとして再利用して、キー再生成やデータSAをダウンロードします。 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.
一部の登録プロトコルは、既存のセキュリティ機能を活用したり、セッションのセットアップ時間全体を最適化するために、データシグナリングプロトコルをトンネリングする必要があります。 たとえば、電話にはセットアップ時間の遅延に関する厳しい制限があります。 後者はしばしばアドレスを解決するため、セキュリティセットアップをコールセットアップと並行して実行することは現実的ではありません。 呼び出し元が呼び出し先のアドレスを知る前に、呼び出しのセットアップを完了する必要があります。 この場合、呼び出し確立[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によって保護されます。 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.
登録プロトコルに必要な設計プロパティには、さまざまなトレードオフがあります。 完全な前方秘匿性とID保護を提供するプロトコルは、パフォーマンスまたは効率と引き換えにセキュリティを向上させますが、1つまたは2つのメッセージで完了するプロトコルは、セキュリティ機能（ID保護など）と引き換えに効率を高めることができます。
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つの解決策は、リプレイキャッシュを過剰にプロビジョニングすることですが、これは大きなリプレイキャッシュにつながる可能性があります。 別の解決策は、実行時に許容クロックスキューを動的に変更できるようにすることです。 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].
交換で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メッセージ交換の一部としてID保護を提供します。 ただし、セキュリティ機能が追加されると、複雑さが増します。たとえば、ID保護では追加のメッセージが必要になるだけでなく、リソースが既に割り当てられた後の交換の後半段階で認証が実行されるため、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つのメッセージのセットアップを使用するプロトコルは、待ち時間と計算要件が低いのに対し、安全な時間などのインフラストラクチャが必要な場合や、ID保護がないなどのセキュリティが低い場合があります。 どのトレードオフが許容され、どのトレードオフが許容されないかは、アプリケーションとアプリケーション環境によって大きく左右されます。
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 TEARDOWN [RFC2326]やSIP BYE [RFC3261]などのセッション確立プロトコルがよくあります。 エンドポイント間のセッション確立の交換は、エンドポイントでGSA状態の終了を通知する機会を提供します。 この交換は、GSAが破棄されるという片側からの単方向通知のみで十分です。 この通知の認証には、一方から他方へのグループキーの所有証明を使用する場合があります。 一部のアプリケーションでは、RTSAやSIPセッションなどのセッションの確立に伴うGSAの相互の2メッセージ交換シグナリングの確立での確認応答が役立ちます。 この場合、双方向の所有証明は、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.
グループキー再生成プロトコルは、GCKSとセキュリティで保護された通信グループのメンバー間のキーとSAの転送用です。 GCKSはキー再生成メッセージを送信して、キー再生成SAを更新するか、データSAを初期化/更新するか、またはその両方を行います。 キー再生成メッセージはキー再生成SAによって保護されます。 グループメンバーシップが変更された場合、またはKEKまたはTPKが期限切れになった場合、GCKSはRekey SAを更新する場合があります。 KEKはRekey SAに対応し、TPKはData SAに対応することを思い出してください。
The following are some desirable properties of the rekey protocol.
キー再生成プロトコルの望ましいプロパティを次に示します。
o The rekey protocol ensures that all members receive the rekey information in a timely manner.
oキー再生成プロトコルは、すべてのメンバーがキー再生成情報をタイムリーに受信することを保証します。
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キーの再生成プロトコルは、パーティがGCKSにアクセスして、キーの有効期限が切れて更新が受信されない場合に再同期できるメカニズムを指定します。
o The rekey protocol avoids implosion problems and ensures reliability in delivering Rekey information.
oキー再生成プロトコルは、内破問題を回避し、キー再生成情報の配信における信頼性を確保します。
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.
さらに、キー再生成プロトコルは、グループキー管理アーキテクチャのスケーラビリティに主に関与していることに注意してください。 したがって、上記のプロパティをスケーラブルに提供することが不可欠です。 問題の一部に関する解決策が文献（IETF標準と研究記事の両方）に存在することに注意してください。 たとえば、キー再生成プロトコルは、スケーラブルグループキー管理アルゴリズム（GKMA）を使用して、キー再生成メッセージで送信されるキーの数を減らすことができます。 GKMAの例には、LKH、OFT、サブセット差分ベースのスキームなどが含まれます。
The goals of the rekey protocol are:
キー再生成プロトコルの目標は次のとおりです。
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グループメンバーシップの変更後またはキー（KEK）の有効期限が切れた後の効率的なキー再生成
o reliable delivery of rekey messages,
oキー再生成メッセージの信頼できる配信、
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:
キー再生成プロトコルの設計におけるいくつかの主要な問題を特定します。
1. rekey message format,
1.メッセージ形式をキー変更します、
2. reliable transport of rekey messages,
2.キー再生成メッセージの信頼できる転送、
3. implosion,
3.内破、
4. recovery from out-of-sync GSA,
4.非同期GSAからの回復、
5. incorporating GKMAs in rekey messages, and
5.キー再生成メッセージにGKMAを組み込む
6. interoperability of GKMAs.
6. GKMAsの相互運用性。
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がグループのキー再生成に成功するには不十分であることに注意してください。 また、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.
キー再生成メッセージには、キー再生成および/またはデータSAとKEKおよびTPKが含まれます。 これらのメッセージは機密情報であり、認証され、リプレイおよび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.
キーの再生成メッセージは、機密性のためにグループKEKで暗号化されます。 GKMAと組み合わせて使用する場合、キー再生成メッセージの一部は、GKMAによって指定された適切なKEKで最初に暗号化されます。 GCKSは、グループ認証キーを使用して計算されたMACまたはデジタル署名のいずれかを使用してキー再生成メッセージを認証します。 どちらの場合も、リプレイ攻撃から保護するために、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.
グループ認証に対称キーが提供される場合、キー再生成メッセージはグループの他のメンバーによる攻撃に対して脆弱です。 キーの再生成メッセージは、グループメンバーが相互に信頼していない場合にデジタル署名されます。 非対称認証が使用される場合、キー再生成メッセージを受信するメンバーは、DoS攻撃に対して脆弱です。 外部の攻撃者は偽のキー再生成メッセージを送信する場合がありますが、メンバーは高価なデジタル署名操作を実行するまで識別できません。 このような攻撃から保護するために、キー再生成メッセージの一部としてMACを送信できます。 メンバーは、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].
キー再生成メッセージには、単一の[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は、すべてのメンバーが現在のデータセキュリティSAとキー再生成SAを持っていることを確認する必要があります。 そうしないと、許可されたメンバーがグループ通信の受信から誤って除外される可能性があります。 したがって、GCKSは、本質的に信頼できるキー変更アルゴリズムを使用するか、キー変更メッセージを送信するために信頼できるトランスポートメカニズムを使用する必要があります。
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とのユニキャスト交換が必要になる場合があります。ただし、サブセット差分アルゴリズムは、キーの再生成メッセージで必要なすべての状態を伝達するため、メンバーが常にオンラインであるか状態を維持する必要はありません。サブセット差分アルゴリズムはバックチャネルを必要とせず、ブロードキャストネットワーク上で動作できます。キー再生成メッセージが送信中に失われると、サブセット差分アルゴリズムは、失われたキー再生成メッセージを介して送信されたTPKで暗号化されたメッセージを解読できません。文献で提案されている自己回復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のうち、半数のメンバーが単一のKEKのみを必要とします。 キー再生成メッセージとその信頼性の高い配信のためのプロトコルを設計する際に、これらのプロパティを利用する場合があります。
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.キー再生成メッセージを繰り返し送信します。 多くの場合、キー再生成メッセージは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を使用します（フィードバックとしてNACKを使用）[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より大きいシーケンス番号を持つキー再生成メッセージを受信した場合、GCKSと同期していない可能性があります。これは、GCKSメンバーがキー再生成メッセージを見逃したことを検出する1つの手段です。あるいは、データセキュリティアプリケーションは、古いキーを使用していることを検出すると、グループキー管理モジュールに通知することができます。 GCKSメンバーが実行するアクションは、グループポリシーの問題です。 GCKSメンバーは状態をログに記録し、GCKSに連絡して再登録プロトコルを再実行し、新しいグループキーを取得する必要があります。グループポリシーでは、キーの再生成が頻繁に発生し、IPネットワークで2つのメッセージの順序が変更される可能性がある場合に、キーの順序変更のメッセージなどの境界条件を考慮する必要があります。グループキーポリシーでは、サブネットワークまたはメンバーのサブセットが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メンバーは、GCKSとの単純な保護されていない接続（TCPなど）を開き、現在の（またはいくつかの最近の）キー再生成メッセージを取得できます。 キー再生成メッセージはすでに署名されており、平文でマルチキャストされているため、ここでは認証や暗号化の必要がないことに注意してください。 これにより、多くの偽のリクエストにより、DoS攻撃に対するGCKSが開かれたと考えるかもしれません。 ただし、これによって状況が悪化することはありません。 実際、偽の再同期リクエストでGCKSを攻撃すると、はるかに問題が多くなります。
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サイト）にキーの再生成メッセージを投稿でき、非同期メンバーはそのサイトからキーの再生成メッセージを取得できます。
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.
GCKSは、再同期の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.
キー再生成メッセージは、信頼できるマルチキャストを使用して送信できます。プロパティが異なる信頼性の高いマルチキャストプロトコルにはいくつかの種類があります。ただし、現時点で公開されている信頼できるマルチキャストプロトコルの標準追跡はありませんが、標準追跡への移行を目的とした2つのプロトコルでIETFの合意に達しました[NORM、RFC3450]。したがって、このドキュメントでは、信頼できるグループのキー再生成を目的として、特定の信頼できるマルチキャストプロトコルまたはプロトコルセットを推奨していません。 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グループキー管理プロトコルは、キー再生成メッセージとともに認証されるシーケンス番号によるキー再生成メッセージのシーケンスをサポートしています。 キー再生成メッセージの送信者は、同じシーケンス番号を持っている限り、メッセージの複数のコピーを再送信できます。 したがって、メッセージを再送信することは、ネットワークパスに沿った損失を克服するための基本的な手段です。 キー再生成メッセージを受信したメンバーは、シーケンス番号をチェックして、キー再生成メッセージの重複および欠落を検出します。 メンバー受信者は、受信した重複メッセージを破棄します。 LKHまたはOFTツリー構造を含むメッセージなどの大きなキー再生成メッセージは、標準ベースの方法が利用可能になる将来、トランスポート層FECの恩恵を受ける可能性があります。 前方誤り訂正（FEC）メソッドが、単一のメッセージ内に収まる短いキー再生成メッセージの恩恵を受けることはほとんどありません。 この場合、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つの理由のいずれかが原因で発生する場合があります。 まず、キー再生成プロトコルの目標の1つがGSAの同期であることを思い出してください。 キーの再生成またはデータ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番目のケースは、キー再生成メッセージの信頼できる配信です。 信頼できるマルチキャストプロトコルは、フィードバック（NACKまたはACK）を使用して、どのパケットを再送信する必要があるかを判断します。 パケットが失われると、多くのメンバーがNACKをGCKSに送信する可能性があります。 これをフィードバック爆縮と呼びます。
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のコンテキストでも役立つ場合があります。 メンバーは、非同期メッセージまたはフィードバックメッセージを送信する前にランダムな時間待機する場合があります。 一方、メンバーは必要なキーの更新を受信する可能性があるため、フィードバックメッセージを送信しません。 別の解決策は、メンバーが同期していないときに複数の登録サーバーの1つに連絡することです。 これには、複数の登録サーバー間の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.
一部の信頼性の高いマルチキャストプロトコルで採用されているフィードバックアグリゲーションとローカルリカバリは、キー再生成メッセージの転送に簡単に適応できません。 集約は認証の問題を引き起こします。 メンバーはローカル修復サーバーでSAを確立する必要があるため、ローカル回復はより複雑です。 グループのメンバーまたは下位GCKSが修復サーバーとして機能し、キー再生成メッセージの再送信を担当する場合があります。
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.
メンバーはグループSA、より具体的にはRekey SAを使用して、修復サーバーに送信された要求を認証できます。 ただし、リプレイ保護には、メンバーの状態の維持とサーバーの修復が必要です。 修復要求の認証は、DoS攻撃から保護することを目的としています。 また、非同期メンバーは期限切れのRekey SAを使用して修復要求を認証する場合があり、古いSAによって保護されたメッセージを修復サーバーが受け入れる必要があることに注意してください。
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.
あるいは、単純なメカニズムを使用して、局所修復を効率的に達成することができます。 各メンバーは、グループ操作ポリシー情報の一部としてローカル修復サーバーアドレスのセットを受け取ります。 メンバーは、キーの再生成メッセージを受信しない場合、ローカル修復サーバーの1つに「シーケンス番号n以上のリプレイメッセージの再送信」メッセージを送信できます。 修復サーバーは、ビジー状態の場合は要求を無視するか、GCKSから受信した要求されたキー再生成メッセージを再送信できます。 別のメンバーでもある修復サーバーは、特定の期間（つまり、レート制限応答）または特定のキー再生成メッセージごとにm個の要求のみを処理することを選択できます。 要求と応答のレート制限により、修理サーバーとグループの他のメンバーが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.
グループキー管理アルゴリズムは、ステートフル、ステートレス、および自己修復の3つのカテゴリに分類されます。
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.
ステートフルアルゴリズム[RFC2627、OFT]は、過去のキー変更インスタンスからのKEKを使用して、現在および将来のキー変更インスタンスに対応するKEKを暗号化（保護）します。 これらのスキームの主な欠点は、メンバーがオフラインだったり、過去のキー再生成インスタンスからKEKを受信できなかった場合、将来のすべてのキー再生成インスタンスからKEKを受信できても、GSAを同期できなくなる可能性があることです。 唯一の解決策は、再同期のために明示的にGCKSに連絡することです。 最初のキー再生成インスタンスのKEKは登録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.
ステートレスGKMAs [SD1、SD2]は、登録プロトコル中に送信されたKEKでキー再生成メッセージを暗号化します。 キー再生成メッセージは過去のキー再生成メッセージ（つまり、KEKによって保護されていないメッセージ）から独立しているため、メンバーはオフラインになる可能性がありますが、将来の通信を解読し続ける可能性があります。 ただし、ステートレス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.
自己修復スキーム[Self-Healing]では、メンバーは過去および将来のキー再生成メッセージを受信する限り、失われたキー再生成メッセージを再構築できます。
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仕様ではパケット形式を指定していませんが、多くのグループキー管理アルゴリズムでは相互運用性のために形式を指定する必要があります。 キーツリーを管理し、キーツリー内のノードに番号を付けるには、いくつかの代替方法があります。 次の情報は、Rekey 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 <古いID、新しい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アーキテクチャは、登録、キーの再生成、およびデータセキュリティプロトコル間のインターフェイスを、これらのプロトコルのセキュリティアソシエーション（SA）の観点から定義します。 これらのプロトコルを統一されたインターフェースの背後で分離することにより、アーキテクチャは実装がニーズに最適なプロトコルを使用できるようにします。 たとえば、小さなグループのキー再生成プロトコルは対称認証で複数のユニキャスト送信を使用できますが、大きなグループのキー再生成プロトコルはパケットレベルの前方誤り訂正とソース認証で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、キー再生成SA、データSAの3つのSAで構成されています。 Rekey SAはオプションです。 3つのSA間の関係の定義には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つ以上のデータSA（ファイルまたはストリームを保護する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：キー再生成プロトコルを保護するために、キー再生成SAを使用してグループキー管理が行われます。 登録プロトコルは、正常に完了すると、1つ以上のRekey SAとゼロ以上のData SAを初期化します。 データSAが登録プロトコルで初期化されていない場合、初期化はキー再生成プロトコルで行われます。 キー再生成プロトコルは、キー再生成SAを更新し、データSAを確立します。
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ページなど）を介して配布できます。 グループキー管理プロトコルは、SAとそれが確立するキーの暗号化ポリシー、およびグループの安全な運用のための追加ポリシーを伝送します。
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グループ所有者のID、認証方法、およびグループのGCKSを識別するための委任方法。
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.
グループポリシーは、登録およびキー再生成プロトコルがキー再生成およびデータSAを初期化または更新する方法を決定します。 次のセクションでは、キー再生成およびデータSAについてGCKSが送信する潜在的な情報について説明します。 メンバーは、キー再生成とデータSAを確立するために、次のセクションで指定された情報を必要とします。
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.
キー再生成SAはキー再生成プロトコルを保護します。 SA、リプレイ保護情報、およびキー保護キーを一意に識別するための暗号化ポリシー、グループID、およびセキュリティパラメータインデックス（SPI）[RFC2401]が含まれています。
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、TAXONOMY、SD1、SD2]が含まれます。 キー失効アルゴリズムがNULLの場合、Rekey SAにはグループKEKとして機能するKEKが1つだけ含まれます。 キー再生成メッセージは、通常どおりデータSAを初期化または更新します。 ただし、Rekey SA自体は、メンバーが参加するか、KEKの有効期限が近づいたときに更新できます（グループKEKのキーを再生成できます）。 キー再生成は、キー再生成プロトコルを介してキー再生成SAを再初期化することによって行われます。
o KEK ENCRYPTION ALGORITHM
o KEK暗号化アルゴリズム
This specifies a standard encryption algorithm such as 3DES or AES, and also the KEK KEY LENGTH.
これは、3DESやAESなどの標準暗号化アルゴリズム、およびKEK KEY LENGTHも指定します。
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の計算に対称シークレットを使用します。 対称認証は、グループメンバーが特定のソースになりすますことができるという点で、より弱い認証を提供します。 AUTHENTICATION KEY LENGTHも指定されます。
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.
このアドレスは、キー再生成メッセージのマルチキャスト送信に使用されます。 この情報は、アナウンスメントプロトコルやコールセットアップメッセージなどの制御チャネルを介して送信されます。 制御グループアドレスが保護される程度は、グループポリシーの問題です。
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.
このアドレスにより、登録サーバーは、登録およびキー再生成プロトコルの将来の呼び出しなどのために、キー再生成に使用されるサーバーとは異なるエンティティになることができます。 登録サーバーとキー再生成サーバーが2つの異なるエンティティである場合、登録サーバーはキー再生成SAの一部としてキー再生成サーバーのアドレスを送信します。
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.
特定のグループキー管理プロトコルにより、登録プロトコルの1回の呼び出しで複数のグループを初期化できる場合、または1つのキー再生成メッセージで複数のグループを更新できる場合、グループIDは識別子としてSA（ペイロード）情報を伴います。 多くの場合、各登録呼び出しを単一のグループに制限する方が簡単ですが、そのような制限は不要です。 Rekey SAを確立するときは、SPIを介して暗黙的に、または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.
キー管理アルゴリズムに対応して、Rekey SAには1つ以上のKEKが含まれています。 GCKSはグループのキー暗号化キーを保持し、メンバーはキー管理アルゴリズムの仕様に従ってキーを受け取ります。 グループに複数のKEKがある場合（LKHツリーのように）、各KEKをキーIDに関連付ける必要があります。キーIDは、解読に必要なキーを識別するために使用されます。 各KEKにはLIFETIMEが関連付けられており、その後は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は、キーの再生成メッセージの認証に対称キーまたは公開キーを提供します。 対称キー認証は、すべてのグループメンバーがGCKSを偽装しないと信頼できる場合にのみ適切です。 アーキテクチャは、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.
タプル<Group identity、SPI>は、Rekey SAを一意に識別します。 SPIは、KEKが変わるたびに変わります。
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
GCKSは、送信者から受信メンバーへのデータの安全な送信に使用されるデータセキュリティプロトコルを指定します。 データセキュリティプロトコルの例には、IPsec ESP [RFC2401]およびSRTP [RFC3711]が含まれます。 これらの各プロトコルのコンテンツは
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.
このドキュメントの範囲では、登録プロトコル（またはキー再生成プロトコル）によって送信された情報をリストして、データ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.
登録プロトコルの単一の呼び出しまたは単一のキー再生成メッセージで複数のグループのデータSAが初期化またはキー再生成される場合、グループIDは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.
グループ所有者が許可されたメンバーのみにソースIDを公開することを選択した場合、SAにはソース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）を使用して、多数の電話会議メンバーを1つのセッションに集約できます。 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.特定のグループに以前に登録したメンバーのセキュリティプロトコルにデータキーを提供するためのユニキャスト交換の必要はありません。 データキーはキー再生成プロトコルでプッシュできます。
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.メンバーがグループシークレットを受信する方法に柔軟性を持たせるために、登録プロトコルとキー再生成プロトコルは分離可能です。 グループは、登録プロトコルの代わりにスマートカードベースのシステムを使用して、たとえば、テレビの条件付きアクセスシステムなどのブロードキャストアプリケーションのバックチャネルなしでキー再生成プロトコルを使用できます。
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.登録およびキー再生成プロトコルは、アーキテクチャ内の新しいキー、アルゴリズム、認証メカニズム、および承認インフラストラクチャをサポートします。 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グループキー管理アーキテクチャは、潜在的な大量同時登録要求を処理するために階層的に編成されたキー配布を提案します。 図3の構成は、中央のGCKSサイトの従来のクラスタリングおよび負荷分散ソリューションが顧客の要件を満たすことができない場合に必要になることがあります。 ただし、従来のキャッシングネットワークやコンテンツ配信ネットワークとは異なり、図3に示す構成には、GCKSの物理的なセキュリティに追加のセキュリティ上の影響があります。
+----------------------------------------+
| +-------+ |
| | 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.
アーキテクチャが大規模なマルチキャストアプリケーションをどの程度効果的かつ安全にサポートできるかを判断するには、グループキー管理アーキテクチャのプロトコルのインスタンス化について、より多くの分析と作業が必要です。 中間者攻撃、リプレイ攻撃、リフレクション攻撃に対するペアワイズキー管理と同じくらい安全であることに加えて、グループキー管理プロトコルには追加のセキュリティニーズがあります。 ペアワイズキー管理とは異なり、グループキー管理は、GCKSになりすましたり、GCKSの動作を妨害しようとするグループメンバーや非メンバーによる攻撃に対して安全である必要があります。
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.
したがって、セキュリティで保護されたグループは、メンバーがグループを攻撃しているとき、グループに参加してグループから離脱しているとき、またはグループから追い出されているときに、共通のグループキーに収束する必要があります。 また、DoS攻撃またはネットワークパーティションが多数の同期された要求につながる場合、グループキー管理プロトコルは堅牢である必要があります。 したがって、グループキー管理のインスタンス化では、指定されたGCKSに代わってキーを提供するために、グループ所有者によって指定された複数のGCKSにGCKS操作を分散する方法を考慮する必要があります。 GSAKMP [GSAKMP]プロトコルはポリシートークンを使用し、一部のメンバーを従属GCKSとして指定して、このスケーラビリティの問題に対処できます。
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番目のプロトコルであるグループキー管理キー再生成プロトコルは新しく、未知のリスクがあります。 上記のソース認証のリスクは、公開鍵暗号方式を使用することで回避されます。 マルチキャスト配信を使用すると、マルチキャストの使用に基づく信頼性、内破、サービス拒否攻撃などの追加のセキュリティ問題が発生する場合があります。 キー再生成プロトコルの仕様では、これらの問題に対する安全なソリューションを提供する必要があります。 GSAKMP RekeyやGDOI Groupkey-push操作など、キー再生成プロトコルの各インスタンスは、キー再生成仕様のセキュリティを検証する必要があります。
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.、他、「Reliable Group Rekeying：Design and Performance Analysis」、Proc。 ACM SIGCOMM、カリフォルニア州サンディエゴ、2001年8月。
[CLIQUES] Steiner, M., Tsudik, G., and M. Waidner, "CLIQUES: A New Approach to Group Key Agreement", IEEE ICDCS 97, May 1997
[CLIQUES] Steiner、M.、Tsudik、G.、およびM. Waidner、「CLIQUES：グループキー契約への新しいアプローチ」、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. and M. Naor、 "Broadcast Encryption、Advances in Cryptology"、CRYPTO 93 Proceedings、Lecture Notes in 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 Building Block：Group Security Association（GSA）Definition」、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]国際電気通信連合、「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会議、pp。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.
[MARKS] Briscoe、B。、「MARKS：任意に明らかにされたキーシーケンスを使用したゼロサイドエフェクトマルチキャストキー管理」、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、「Appliced 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 Work in Progress、2000年8月
[RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC2093] Harney、H。、およびC. Muckenhirn、「Group Key Management Protocol（GKMP）Specification」、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、「Real Time Streaming Protocol（RTSP）」、RFC 2326、1998年4月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327] Handley、M。、およびV. Jacobson、「SDP：Session Description Protocol」、RFC 2327、1998年4月。
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367]マクドナルド、D。、メス、C。、およびB.ファン、「PF_KEY鍵管理API、バージョン2」、RFC 2367、1998年7月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S。、およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、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、「インターネットキーエクスチェンジ（IKE）」、RFC 2409、1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]オーマン、H。、「オークリーキー決定プロトコル」、RFC 2412、1998年11月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522]カーン、P。およびW.シンプソン、「Photuris：セッションキー管理プロトコル」、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]エリソン、C。、フランツ、B。、ランプソン、B。、リベスト、R。、トーマス、B。、およびT.イロネン、「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]ローゼンバーグ、J。、シュルズリンネ、H。、カマリロ、G。、ジョンストン、A。、ピーターソン、J。、スパークス、R。、ハンドリー、M。、およびE.スクーラー、「SIP：Session Initiation 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、「Asynchronous Layered Coding（ALC）Protocol Instantiation」、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、「解釈のグループドメイン」、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、「ステートレスレシーバーの失効およびトレーススキーム」、暗号の進歩-カリフォルニア州サンタバーバラのクリプト：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。、およびB. Pinkas、「効率的な追跡と取り消しスキーム」、Proceedings of Financial Cryptography 2000、アングィラ、イギリス領西インド諸島、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.
[自己回復]スタドン、J.、et。 al。、「失効を伴う自己修復キー配布」、Proc。 2002セキュリティおよびプライバシーに関するIEEEシンポジウム、カリフォルニア州オークランド、2002年5月。
[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 Secure Networks and Distributed Systems Symposium、サンディエゴ、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。van Oorschot、M。、およびJ. Wiener、「Authentication and Authenticated Key Exchanges」、Designs、Codes and Cryptography、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。 他、「マルチキャストセキュリティ：分類法といくつかの効率的な構造」、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 Transform Introduction」、Work in Progress、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：マルチキャストソース認証変換仕様」、Work in Progress、2002年4月。
[tGSAKMP] Harney, H., et. al., "Tunneled Group Secure Association Key Management Protocol", Work in Progress, May 2003.
[tGSAKMP] Harney、H.、et。 他、「トンネル化グループセキュアアソシエーションキー管理プロトコル」、Work in Progress、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。、「暗号化されたブロードキャストのキー管理」、コンピューターおよび通信セキュリティに関する第5回ACM会議、カリフォルニア州サンフランシスコ、1998年11月。
Authors' Addresses
著者のアドレス
Mark Baugher Cisco Systems 5510 SW Orchid St. Portland, OR 97219, USA
Mark Baugher Cisco Systems 5510 SW Orchid St. Portland、OR 97219、米国
Phone: +1 408-853-4418 EMail: mbaugher@cisco.com
電話：+1 408-853-4418電子メール：mbaugher@cisco.com
Ran Canetti IBM Research 30 Saw Mill River Road Hawthorne, NY 10532, USA
Ran Canetti IBM Research 30 Saw Mill River Road Hawthorne、NY 10532、USA
Phone: +1 914-784-7076 EMail: canetti@watson.ibm.com
電話：+1 914-784-7076メール：canetti@watson.ibm.com
Lakshminath R. Dondeti Qualcomm 5775 Morehouse Drive San Diego, CA 92121
Lakshminath R. Dondeti Qualcomm 5775 Morehouse Driveサンディエゴ、CA 92121
Phone: +1 858 845 1267 EMail: ldondeti@qualcomm.com
電話：+1 858 845 1267電子メール：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
電話：+46 8 58531705メール：fredrik.lindholm@ericsson.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/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のietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。