RFC4046 日本語訳
4046 Multicast Security (MSEC) Group Key Management Architecture. M.Baugher, R. Canetti, L. Dondeti, F. Lindholm. April 2005. (Format: TXT=97885 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Baugher
Request for Comments: 4046 Cisco
Category: Informational R. Canetti
IBM
L. Dondeti
Qualcomm
F. Lindholm
Ericsson
April 2005
Baugherがコメントのために要求するワーキンググループM.をネットワークでつないでください: 4046年のコクチマスカテゴリ: 情報のR.のDondetiクアルコムF.リンドホルムエリクソンカネッティIBM L.2005年4月
Multicast Security (MSEC) Group Key Management Architecture
マルチキャストセキュリティ(msec)グループKey Managementアーキテクチャ
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
Multicast Security(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
1. 序論: このDocumentの目的…2 2. グループKey Managementの要件は議定書を作ります…4 3. グループKey Managementアーキテクチャの総合的なデザイン…6 3.1. 概要…6 3.2. GKMアーキテクチャの詳述…8 3.3. デザインの特性…11 3.4. Key Managementブロック図を分類してください…11 4. 登録プロトコル…13 4.1. PiggybackingかプロトコルReuseを通した登録プロトコル。13 4.2. 代替の登録交換の特性はタイプされます…14
Baugher, et al. Informational [Page 1] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[1ページ]のRFC4046msecグループ
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
4.3. 代替の登録交換タイプのためのインフラストラクチャ…15 4.4. 反-登録交換…16 5. Rekeyは議定書を作ります…16 5.1. Rekeyの目標は議定書を作ります…17 5.2. Rekeyメッセージ転送と保護…17 5.3. Rekeyメッセージの信頼できる輸送…18 5.4. 信頼できるマルチキャストインフラストラクチャで最先端…20 5.5. 内部破裂…21 5.6. グループKey Managementアルゴリズムを取り入れます…22 5.7. 状態がないStateful、および自己回復Rekeyingアルゴリズム…22 5.8. GKMAの相互運用性…23 6. セキュリティ協会を分類してください…24 6.1. 方針を分類してください…24 6.2. Rekey SAのコンテンツ…25 6.2.1. Rekey SA方針…26 6.2.2. アイデンティティを分類してください…27 6.2.3. KEKs…27 6.2.4. 認証キー…27 6.2.5. 保護を再演してください…27 6.2.6. セキュリティパラメタインデックス(SPI)…27 6.3. データSAのコンテンツ…27 6.3.1. アイデンティティを分類してください…28 6.3.2. ソースのアイデンティティ…28 6.3.3. トラフィック保護キー…28 6.3.4. データ認証キー…28 6.3.5. 一連番号…28 6.3.6. セキュリティパラメタインデックス(SPI)…28 6.3.7. データSA方針…28 7. スケーラビリティ問題…29 8. セキュリティ問題…31 9. 承認…32 10. 有益な参照…33
1. Introduction: Purpose of this Document
1. 序論: このDocumentの目的
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.
Multicast Security(MSEC)かぎ管理プロトコルがさまざまなアプリケーション、輸送、およびネットワーク層セキュリティにプロトコルをサポートするように、このドキュメントは一般的なアーキテクチャを定義します。 それは、また、グループセキュリティ協会(GSA)を定義して、GSAを設立するのを助けるかぎ管理プロトコルについて説明します。 本書では説明されたフレームワークとガイドラインはグループかぎ管理プロトコルのモジュールの、そして、フレキシブルなデザインをアプリケーションの必要性に専門にされるさまざまな異なった設定に可能にします。 MSECかぎ管理プロトコルは、安全な1〜多く、多くへの多くへの1、または1つのコミュニケーションを容易にするのに使用されるかもしれません。
Baugher, et al. Informational [Page 2] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[2ページ]のRFC4046msecグループ
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]や、マークなど[マーク]のグループかぎ管理アルゴリズムによって思われた集団経営か主要なサーバモデルに基づいています。 このアーキテクチャで考えられない他のアプローチがあります、非常に分配されたCliquesグループかぎ管理プロトコル[CLIQUES]や放送かぎ管理体系[FN93、Wool]のように。 MSECかぎ管理は事実上他のグループかぎ管理デザインを補足しているかもしれませんが、CliquesとのMSECグループ重要管理、放送重要管理、または他のグループキーシステムの統合は本書では考えられません。
Key management protocols are difficult to design and validate. The common architecture described in this document eases this burden by defining common abstractions and an overall design that can be specialized for different uses.
かぎ管理プロトコルは設計して、有効にするのは難しいです。 本書では説明された一般的なアーキテクチャは、異なった用途のために専門にすることができる一般的な抽象化と総合的なデザインを定義することによって、この負担をゆるめます。
This document builds on and extends the Group Key Management Building Block document of the IRTF SMuG research group [GKMBB] and is part of the MSEC document roadmap. The MSEC architecture [MSEC-Arch] defines a complete multicast or group security architecture, of which key management is a component.
このドキュメントは、IRTF SMuG研究グループ[GKMBB]について建てて、Group Key ManagementビルBlockドキュメントを広げています、そして、MSECドキュメント道路地図が部分がありますか? MSECアーキテクチャ[MSEC-アーチ]は完全なマルチキャストかグループセキュリティー体系を定義します。(かぎ管理はそれでコンポーネントです)。
The rest of this document is organized as follows. Section 2 discusses the security, performance and architectural requirements for a group key management protocol. Section 3 presents the overall architectural design principles. Section 4 describes the registration protocol in detail, and Section 5 does the same for rekey protocol. Section 6 considers the interface to the Group Security Association (GSA). Section 7 reviews the scalability issues for group key management protocols and Section 8 discusses security considerations.
このドキュメントの残りは以下の通り組織化されます。 セクション2はグループかぎ管理プロトコルのためのセキュリティ、性能、および建築要件について論じます。 セクション3は総合的な建築設計原理を提示します。 セクション4は詳細に登録プロトコルについて説明します、そして、セクション5はrekeyプロトコルのために同じようにします。 セクション6はGroup Security Association(GSA)とインタフェースを考えます。 セクション7はグループかぎ管理プロトコルのためにスケーラビリティ問題を批評します、そして、セクション8はセキュリティ問題について議論します。
Baugher, et al. Informational [Page 3] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[3ページ]のRFC4046msecグループ
2. Requirements of a Group Key Management Protocol
2. グループKey Managementプロトコルの要件
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と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)攻撃に対して安全であるべきです(このメモのSecurity Considerations部を見てください)。
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. プロトコルはグループのメンバーの追加と解任を容易にするべきです。 彼らがグループに加わって、彼らの出発に続いて、取り除かれたメンバーが主要な材料にアクセスを失うべき前に使用される主要な材料へのアクセスは任意に加えられるメンバーに拒絶されるかもしれません。
Baugher, et al. Informational [Page 4] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[4ページ]のRFC4046msecグループ
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とKey Server(GCKS)の間のユニキャスト交換なしでスケーラブルなグループがrekey操作であるとサポートするべきです。
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や超能力、そして/または、応用層セキュリティプロトコルなどの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
現在のかぎ管理アーキテクチャはソース特有のマルチキャストグループなどの大きい独身の送付者グループで安全なコミュニケーションをカバーしています。 また、さまざまなグループサイズへのスケーラブルな操作は望ましい特徴です、そして、より良いグループかぎ管理プロトコルは多くを持っているグループと同様に大きくて、独身の送付者のグループをサポートするでしょう。
Baugher, et al. Informational [Page 5] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[5ページ]のRFC4046msecグループ
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.
2つの非要件を強調するのは役に立ちます: 技術的な保護は(TPM)[TPM]と放送重要管理を測定します。 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.
チャンネル[FN93、JKKV94]かデジタル・ビデオディスクプレーヤーなどの非ネットワークでつながれたデバイスのための後部が全くないとき、2番目の非要件は放送重要管理です。 私たちはしかしながら、2道がコミュニケーションであって、非対称であることでのIPネットワーク操作、およびメンバー登録に用いることができる認証された主要な交換手順を仮定します。 全面散布は以下で説明されるように一方向インターネットグループかぎ管理プロトコルメッセージと一方向rekeyメッセージを使用するかもしれません。
3. Overall Design of Group Key Management Architecture
3. グループKey Managementアーキテクチャの総合的なデザイン
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 rekeyingのためにグループコントローラを任命します。
3.1. Overview
3.1. 概要
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をData 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:
これは、Group ControllerとKey Server(GCKS)の間のユニキャストプロトコルと接合グループのメンバーです。 このプロトコルでは、GCKSと接合メンバーは互いに互いを認証します。 認証が成功して、GCKSが、接合メンバーが認可されているのがわかるなら、GCKSは以下の情報を接合メンバーに提供します:
Baugher, et al. Informational [Page 6] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[6ページ]のRFC4046msecグループ
(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.
(a) 接合メンバーの中でData SAを初期化できるくらいの情報。 に加えての代わりにする、グループ安全保障政策が、登録でData SAを初期化するように求める場合にだけこの情報を与える、rekeyの一部として、議定書を作ってください。
(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) 接合メンバー(以下のこのSAに関するその他の詳細を見る)の中でRekey SAを初期化できるくらいの情報。 グループ安全保障政策がrekeyプロトコルを求めるなら、この情報を与えます。
The registration protocol must ensure that the transfer of
information from GCKS to member is done in an authenticated and
confidential manner over a security association. We call this SA
the Registration SA. A complementary de-registration protocol
serves to explicitly remove Registration SA state. Members may
choose to delete Registration SA state.
登録プロトコルは、認証されて秘密の方法で情報のGCKSからメンバーまでの転送をセキュリティ協会の上にするのを確実にしなければなりません。 私たちは、このSAをRegistration SAと呼びます。 補足的な反-登録プロトコルは、明らかにRegistration SA状態を取り除くのに役立ちます。 メンバーは、Registration SA状態を削除するのを選ぶかもしれません。
(2) Rekey Protocol
(2) Rekeyプロトコル
A GCKS may periodically update or change the Data SA, by sending
rekey information to the group members. Rekey messages may result
from group membership changes, from changes in group security
policy, from the creation of new traffic-protection keys (TPKs,
see next section) for the particular group, or from key
expiration. Rekey messages are protected by the Rekey SA, which
is initialized in the registration protocol. They contain
information for updating the Rekey SA and/or the Data SA and can
be sent via multicast to group members or via unicast from the
GCKS to a particular group member.
GCKSは、rekey情報をグループのメンバーに送ることによって、Data SAを定期的にアップデートするか、または変えるかもしれません。 Rekeyメッセージは特定のグループのための新しいトラフィック保護キー(TPKs、次のセクションを見る)の作成、または、グループ安全保障政策における変化か、主要な満了からのグループ会員資格変化から生じるかもしれません。 RekeyメッセージはRekey SAによって保護されます。(Rekey 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とメンバーとの相互作用なしでData SAを管理する(例えば、期限が切れるかリフレッシュ)ための他の手段があることに注意してください。 例えば、マーク[マーク]では、GCKSは安全なグループの生涯、異なった期間、TPKsをあらかじめ決定して、彼らの会員資格の期間に基づいてメンバーのキーを分配します。 また、安全なグループを解散して、新しいData SAから新しいグループを始めるGCKSなどの代替の体系も可能です、これは小集団に通常制限されますが。
Rekey messages are authenticated using one of the two following
options:
Rekeyメッセージは2つの次のオプションの1つを使用することで認証されます:
(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]を使用して、すなわち、それぞれのグループのメンバーがそれについて確かめるのを可能にして、rekeyメッセージはGCKSと他のなにも発案ではありません。
Baugher, et al. Informational [Page 7] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[7ページ]のRFC4046msecグループ
(2) Using only group-based authentication with a symmetric key.
Members can only be assured that the rekey messages originated
within the group. Therefore, this is applicable only when all
members of the group are trusted not to impersonate the GCKS.
Group authentication for rekey messages is typically used when
public-key cryptography is not suitable for the particular
group.
(2) 対称鍵によるグループベースの認証だけを使用すること。 メンバーはrekeyメッセージがグループの中で起因したと確信できるだけです。 したがって、グループのすべてのメンバーがGCKSをまねないと信じられるときだけ、これは適切です。 公開鍵暗号が特定のグループに適していないとき、rekeyメッセージのためのグループ認証は通常使用されます。
The rekey protocol ensures that all members receive the rekey
information in a timely manner. In addition, the rekey protocol
specifies mechanisms for the parties to contact the GCKS and re-
synch if their keys expired and an updated key has not been
received. The rekey protocol for large-scale groups offers
mechanisms to avoid implosion problems and to ensure reliability
in its delivery of keying material.
rekeyプロトコルは、すべてのメンバーが直ちにrekey情報を受け取るのを確実にします。 さらに、彼らのキーが期限が切れて、アップデートされたキーが受け取られていないなら、パーティーがGCKSと再の同時性に連絡するように、rekeyプロトコルはメカニズムを指定します。 大規模なグループのためのrekeyプロトコルは、内部破裂問題を避けて、合わせることの材料の配送における信頼性を確実にするためにメカニズムを提供します。
Although the Rekey SA is established by the registration protocol,
it is updated using a rekey protocol. When a member leaves the
group, it destroys its local copy of the GSA. Using a de-
registration message may be an efficient way for a member to
inform the GCKS that it has destroyed, or is about to destroy, the
SAs. Such a message may prompt the GCKS to cryptographically
remove the member from the group (i.e., to prevent the member from
having access to future group communication). In large-scale
multicast applications, however, de-registration can potentially
cause implosion at the GCKS.
登録プロトコルでRekey SAを設立しますが、rekeyプロトコルを使用することでそれをアップデートします。 メンバーが仲間から抜けるとき、それはGSAの地方のコピーを破壊します。 反-登録メッセージを使用するのは、メンバーがそれが破壊しようとしていたか、または破壊しようとしているGCKSに知らせる効率的な方法であるかもしれません、SAs。 そのようなメッセージは、GCKSがグループ(すなわち、メンバーが将来のグループコミュニケーションに近づく手段を持っているのを防ぐ)からメンバーを暗号で免職するようにうながすかもしれません。 しかしながら、大規模なマルチキャストアプリケーションでは、反-登録はGCKSで潜在的に内部破裂を引き起こす場合があります。
3.2. Detailed Description of the GKM Architecture
3.2. GKMアーキテクチャの詳述
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プロトコルの総合的なデザインについて表現します。 それぞれのグループのメンバー(送付者か受信機)は、特定のGroup、方針、およびそのキーへの認可されて認証されたアクセスを得るのに登録プロトコルを使用します。 2つのタイプのグループキーは、主要な暗号化キー(KEKs)とトラフィック暗号化キー(TEKs)です。 また、rekeyメッセージかデータのグループ認証のために、主要な保全かトラフィック保全キーが使用されるかもしれません。 私たちは、保全と暗号化キーの両方について言及するのに保護キーという用語を使用します。 例えば、用語トラフィック保護キー(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
KEKはrekeyメッセージを保護する単一のキーであるかもしれません、新しいRekey SA(KEKを含んでいる)、そして/または、Data SAを通常含んでいて(TPK/TEKを含んでいて)。 また、Rekey SAはグループキー会員資格アルゴリズム[RFC2627、OFT、TAXONOMY、SD1、SD2]の一部であるキーのベクトルを含むかもしれません。 ストリームを保護する用途TPKs、ファイル、または他のデータが送って、受信したデータ機密保護プロトコル
Baugher, et al. Informational [Page 8] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[8ページ]のRFC4046msecグループ
the data security protocol. Thus the registration protocol and/or the rekey protocol establish the KEK(s) and/or the TPKs.
データ機密保護プロトコル。 したがって、登録プロトコル、そして/または、rekeyプロトコルはKEK(s)、そして/または、TPKsを設立します。
+------------------------------------------------------------------+ | +-----------------+ +-----------------+ | | | 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-------+ | | | | | | | +--------------------------------------------------------------+ | | | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | +-----------------+ +-----------------+ | | | 方針| | 承認| | | | インフラストラクチャ| | インフラストラクチャ| | | +-----------------+ +-----------------+ | | ^ ^ | | | | | | vに対して| | +--------------------------------------------------------------+ | | | | | | | +--------------------+ | | | | +------>| GCKS| <、-、-、-、-、--+ | | | | | +--------------------+ | | | | | または登録。| または登録。| | | | 反-登録| 反-登録| | | | プロトコル| プロトコル| | | | | | | | | | | REKEY vに対して| | | | +-----------------+ プロトコル+-----------------+ | | | | | | (任意)です。 | | | | | | | 送付者(S)| <、-、-、-、-、-、--+-------->| 受信機(S)| | | | | | | | | | | | | +-----------------+ +-----------------+ | | | | | ^ | | | | v| | | | | +-------データ機密保護プロトコル-------+ | | | | | | | +--------------------------------------------------------------+ | | | +------------------------------------------------------------------+
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 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.
Baugher, et al. Informational [Page 9] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher, et al. Informational [Page 9] RFC 4046 MSEC Group Key Management Architecture April 2005
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 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 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 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.
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.
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.
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.
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.
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.
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.
Baugher, et al. Informational [Page 10] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher, et al. Informational [Page 10] RFC 4046 MSEC Group Key Management Architecture April 2005
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].
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].
3.3. Properties of the Design
3.3. Properties of the Design
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.
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.
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.
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.
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.
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.
3.4. Group Key Management Block Diagram
3.4. Group Key Management Block Diagram
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
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
Baugher, et al. Informational [Page 11] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher, et al. Informational [Page 11] RFC 4046 MSEC Group Key Management Architecture April 2005
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 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.
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
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
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.
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.
+----------------------------------------------------------+
| |
| +-------------+ +------------+ |
| | CONTROL | | CONTROL | |
| +------^------+ +------|-----+ +--------+ |
| | | +-----| CRED | |
| | | | +--------+ |
| +----v----+ +----v--v-+ +--------+ |
| | <-----Reg-----> |<->| SAD | |
| | GKM -----Rek-----> GKM | +--------+ |
| | | | | +--------+ |
| | ------+ | |<->| SPD | |
| +---------+ | +-^-------+ +--------+ |
| +--------+ | | | | |
| | CRED |----->+ | | +-------------------+ |
| +--------+ | | +--------------------+ | |
| +--------+ | +-V-------+ +--------+ | | |
| | SAD <----->+ | |<->| SAD <-+ | |
| +--------+ | |SECURITY | +--------+ | |
| +--------+ | |PROTOCOL | +--------+ | |
| | SPD <----->+ | |<->| SPD <----+ |
| +--------+ +---------+ +--------+ |
| |
| (A) GCKS (B) MEMBER |
+----------------------------------------------------------+
+----------------------------------------------------------+ | | | +-------------+ +------------+ | | | 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
Figure 2: Group Key Management Block in a Host
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
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
Baugher, et al. Informational [Page 12] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher, et al. Informational [Page 12] RFC 4046 MSEC Group Key Management Architecture April 2005
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.
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.
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.
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.
4. Registration Protocol
4. Registration Protocol
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.
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.
4.1. Registration Protocol via Piggybacking or Protocol Reuse
4.1. Registration Protocol via Piggybacking or Protocol Reuse
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
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
Baugher, et al. Informational [Page 13] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher, et al. Informational [Page 13] RFC 4046 MSEC Group Key Management Architecture April 2005
call establishment [H.235,MIKEY], so that both can complete (or fail, see below) at the same time.
call establishment [H.235,MIKEY], so that both can complete (or fail, see below) at the same time.
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.
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.
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.
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.
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.
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.
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.
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.
4.2. Properties of Alternative Registration Exchange Types
4.2. Properties of Alternative Registration Exchange Types
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.
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.
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-
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-
Baugher, et al. Informational [Page 14] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher, et al. Informational [Page 14] RFC 4046 MSEC Group Key Management Architecture April 2005
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.
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.
A challenge-response mechanism (using Nonces) obviates the need for synchronized clocks for replay protection when the exchange uses three or more messages [MVV].
A challenge-response mechanism (using Nonces) obviates the need for synchronized clocks for replay protection when the exchange uses three or more messages [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.
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.
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.
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.
4.3. Infrastructure for Alternative Registration Exchange Types
4.3. Infrastructure for Alternative Registration Exchange Types
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.
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.
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.
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.
Baugher, et al. Informational [Page 15] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher, et al. Informational [Page 15] RFC 4046 MSEC Group Key Management Architecture April 2005
4.4. De-registration Exchange
4.4. De-registration Exchange
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.
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.
5. Rekey Protocol
5. Rekey Protocol
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.
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.
The following are some desirable properties of the rekey protocol.
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 The rekey protocol ensures that all members receive the rekey information in a timely manner.
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 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 The rekey protocol avoids implosion problems and ensures
reliability in delivering Rekey information.
o The rekey protocol avoids implosion problems and ensures reliability in delivering Rekey information.
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.
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.
Baugher, et al. Informational [Page 16] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher, et al. Informational [Page 16] RFC 4046 MSEC Group Key Management Architecture April 2005
5.1. Goals of the Rekey Protocol
5.1. Goals of the Rekey Protocol
The goals of the rekey protocol are:
The goals of the rekey protocol are:
o to synchronize a GSA,
o to synchronize a GSA,
o to provide privacy and (symmetric or asymmetric)
authentication, replay protection and DoS protection,
o to provide privacy and (symmetric or asymmetric) authentication, replay protection and DoS protection,
o efficient rekeying after changes in group membership or when
keys (KEKs) expire,
o efficient rekeying after changes in group membership or when keys (KEKs) expire,
o reliable delivery of rekey messages,
o reliable delivery of rekey messages,
o member recovery from an out-of-sync GSA,
o member recovery from an out-of-sync GSA,
o high throughput and low latency, and
o high throughput and low latency, and
o support IP Multicast or multi-unicast.
o support IP Multicast or multi-unicast.
We identify several major issues in the design of a rekey protocol:
We identify several major issues in the design of a rekey protocol:
1. rekey message format,
1. rekey message format,
2. reliable transport of rekey messages,
2. reliable transport of rekey messages,
3. implosion,
3. implosion,
4. recovery from out-of-sync GSA,
4. recovery from out-of-sync GSA,
5. incorporating GKMAs in rekey messages, and
5. incorporating GKMAs in rekey messages, and
6. interoperability of GKMAs.
6. interoperability of 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.
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.
The rest of this section discusses these topics in detail.
The rest of this section discusses these topics in detail.
5.2. Rekey Message Transport and Protection
5.2. Rekey Message Transport and Protection
Rekey messages contain Rekey and/or Data SAs along with KEKs and TPKs. These messages need to be confidential, authenticated, and protected against replay and DoS attacks. They are sent via multicast or multi-unicast from the GCKS to the members.
Rekey 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.
Baugher, et al. Informational [Page 17] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher, et al. Informational [Page 17] RFC 4046 MSEC Group Key Management Architecture April 2005
Rekey messages are encrypted with the Group KEK for confidentiality. When used in conjunction with a GKMA, portions of the rekey message are first encrypted with the appropriate KEKs as specified by the GKMA. The GCKS authenticates rekey messages using either a MAC, computed using the group Authentication key, or a digital signature. In both cases, a sequence number is included in computation of the MAC or the signature to protect against replay attacks.
Rekey 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.
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.
When group authentication is provided with a symmetric key, rekey messages are vulnerable to attacks by other members of the group. Rekey messages are digitally signed when group members do not trust each other. When asymmetric authentication is used, members receiving rekey messages are vulnerable to DoS attacks. An external adversary may send a bogus rekey message, which a member cannot identify until after it performs an expensive digital signature operation. To protect against such an attack, a MAC may be sent as part of the rekey message. Members verify the signature only upon successful verification of the MAC.
Rekey messages contain group key updates corresponding to a single [RFC2627,OFT] or multiple membership changes [SD1,SD2,BatchRekey] and may contain group key initialization messages [OFT].
Rekey 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].
5.3. Reliable Transport of Rekey Messages
5.3. Reliable Transport of Rekey Messages
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.
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.
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.
問題への二次元があります。 それがオフラインであるときに、グループキーをアップデートするメッセージは、トランジットで失われているか、またはホストによって逃されるかもしれません。 LKHとOFTグループかぎ管理アルゴリズムはホストによって受けられるアップデートの過去の歴史を当てにします。 オンラインで来るとき、ホストがオフラインで行くと、グループ主要な状態を再連動させるのが必要でしょう。 これはGCKSとのユニキャスト交換を必要とするかもしれません。 Subset Differenceアルゴリズムは、しかしながら、rekeyメッセージをすべての必要な状態を運んで、いつもオンラインである、または状態を維持するのにメンバーを必要としません。 Subset Differenceアルゴリズムは、戻っているチャンネルを必要としないで、放送網を経営できます。 rekeyメッセージがトランスミッションで失われているなら、Subset Differenceアルゴリズムは無くなっているrekeyメッセージでTPKを送って暗号化されたメッセージを解読することができません。 メンバーが無くなっているrekeyメッセージを回復できる文学で提案された自己の治療のGKMAsがあります、無くなっているrekeyメッセージの前後にrekeyメッセージが受信されている限り。
Baugher, et al. Informational [Page 18] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[18ページ]のRFC4046msecグループ
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.
Rekeyメッセージは通常短いです(信頼できる配信プロトコルを設計するのを簡単にします)(単一の会員資格変化と小集団のための)。 他方では、セキュリティ要件は扱う追加寸法を加えるかもしれません。 会員資格変化がバッチとして処理されるいくつかの特別な場合があります、rekeyメッセージの頻度を減少させますが、それらのサイズを増強して。 その上、rekeyメッセージで送られたすべてのKEKsの中では、メンバーの半分が独身のKEKだけを必要とします。 私たちは彼らの信頼できる配信のためにrekeyメッセージとプロトコルを設計する際にこれらの特性を利用するかもしれません。
Three categories of solutions have been proposed:
ソリューションの3つのカテゴリが提案されました:
1. Repeatedly transmit the rekey message. In many cases rekey
messages translate to only one or two IP packets.
1. 繰り返してrekeyメッセージを送ってください。 多くの場合、rekeyメッセージは1か2つのIPパケットだけに翻訳されます。
2. Use an existing reliable multicast protocol/infrastructure.
2. 既存の信頼できるマルチキャストプロトコル/インフラストラクチャを使用してください。
3. Use FEC for encoding rekey packets (with NACKs as feedback)
[BatchRekey].
3. rekeyパケット(フィードバックとしてのNACKsと)[BatchRekey]をコード化するのにFECを使用してください。
Note that for small messages, category 3 is essentially the same as category 1.
小さいメッセージに関して、カテゴリ3がカテゴリ1と本質的には同じであることに注意してください。
The group member might be out of synchrony with the GCKS if it receives a rekey message having a sequence number that is more than one greater than the last sequence number processed. This is one means by which the GCKS member detects that it has missed a rekey message. Alternatively, the data-security application, upon detecting that it is using an out-of-date key, may notify the group key management module. The action taken by the GCKS member is a matter of group policy. The GCKS member should log the condition and may contact the GCKS to rerun the re-registration protocol to obtain a fresh group key. The group policy needs to take into account boundary conditions, such as reordered rekey messages when rekeying is so frequent that two messages might get reordered in an IP network. The group key policy also needs to take into account the potential for denial of service attacks where an attacker delays or deletes a rekey message in order to force a subnetwork or subset of the members to simultaneously contact the GCKS.
最後の一連番号が処理されたよりすばらしい状態でさらに1以上である一連番号を持っているrekeyメッセージを受け取るなら、グループのメンバーはGCKSと共に同期から脱しているかもしれません。 これによる人が、GCKSメンバーが検出するものでrekeyメッセージを逃したことを意味するということです。 あるいはまた、データ機密保護アプリケーションは時代遅れなキーを使用する検出のときにグループかぎ管理モジュールに通知するかもしれません。 GCKSメンバーによって取られた行動はグループ方針の問題です。 GCKSメンバーは、状態を登録するべきであり、新鮮なグループキーを入手するために再登録プロトコルを再放送するためにGCKSに連絡するかもしれません。 「再-合わせ」るのがIPネットワークで2つのメッセージを再命令できるくらい頻繁であるときに、グループ方針は、reordered rekeyメッセージなどの境界状態を考慮に入れる必要があります。 メンバーのサブネットワークか部分集合を同時にGCKSに連絡させるように、また重要政策がサービスの否定の可能性を考慮に入れる必要があるグループは攻撃者がrekeyメッセージを遅らせるか、または削除するところで攻撃されます。
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
o メンバーがGCKSとの純真な保護のない接続(例えば、TCP)を開いて、電流を得ることができる、(数個、最近、)、rekeyメッセージ。 または認証の必要は全くないことに注意してください。
Baugher, et al. Informational [Page 19] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[19ページ]のRFC4046msecグループ
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.
rekeyメッセージが既に署名されて、明確のマルチキャストである時からここでの暗号化。 これがにせのそのようなものが要求する多くで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は何らかの公共のサイト(例えば、ウェブサイト)にrekeyメッセージを掲示できます、そして、同時性で出かけているメンバーはそのサイトからrekeyメッセージを得ることができます。
The GCKS may always provide all three ways of resynching (i.e., re- registration, simple TCP, and public posting). This way, the member may choose how to resynch; it also avoids adding yet another field to the policy token [GSPT]. Alternatively, a policy token may contain a field specifying one or more methods supported for resynchronization of a GSA.
GCKSはいつも(すなわち、再登録、簡単なTCP、および公共の任命)をresynchingするすべての3つの方法を提供するかもしれません。 このように、メンバーは「再-同時性」へのその方法を選ぶかもしれません。 また、それは、方針トークン[GSPT]にさらに別の分野を加えるのを避けます。 あるいはまた、方針トークンは指定1つ以上のメソッドがGSAの再同期のためにサポートした分野を含むかもしれません。
5.4. State-of-the-art on Reliable Multicast Infrastructure
5.4. 信頼できるマルチキャストインフラストラクチャでは、最先端です。
The rekey message may be sent using reliable multicast. There are several types of reliable multicast protocols with different properties. However, there are no standards track reliable multicast protocols published at this time, although IETF consensus has been reached on two protocols that are intended to go into the standards track [NORM,RFC3450]. Thus, this document does not recommend a particular reliable multicast protocol or set of protocols for the purpose of reliable group rekeying. The suitability of NAK-based, ACK-based or other reliable multicast methods is determined by the application needs and operational environment. In the future, group key management protocols may choose to use particular standards-based approaches that meet the needs of the particular application. A secure announcement facility may be needed to signal the use of a reliable multicast protocol, which could be specified as part of group policy. The reliable multicast announcement and policy specification, however, can only follow the establishment of reliable multicast standards and are not considered further in this document.
rekeyメッセージに信頼できるマルチキャストを使用させるかもしれません。 異なった特性があるいくつかのタイプの信頼できるマルチキャストプロトコルがあります。 しかしながら、このとき発表されているどんな標準化過程の信頼できるマルチキャストプロトコルもありません、IETFコンセンサスに標準化過程[NORM、RFC3450]に入ることを意図する2つのプロトコルで達しましたが。 したがって、このドキュメントは信頼できるグループが「再-合わせ」られる目的のために特定の信頼できるマルチキャストプロトコルか1セットのプロトコルを推薦しません。 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,
今日、いくつかのMSECグループかぎ管理プロトコルが一連番号を通したrekeyメッセージの配列をサポートします。一連番号はrekeyメッセージと共に認証されます。 それらに同じ一連番号があれば、rekeyメッセージの送付者はメッセージの複本を再送するかもしれません。 したがって、メッセージを再送するのは、ネットワーク経路に沿って損失を克服する初歩的な手段です。 rekeyメッセージを受け取るメンバーは、写しとなくなったrekeyメッセージを検出するために一連番号をチェックするでしょう。 メンバー受信機は受信するという写しメッセージを捨てるでしょう。 LKHを含むものかOFT木構造などの大きいrekeyメッセージ
Baugher, et al. Informational [Page 20] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[20ページ]のRFC4046msecグループ
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.
未来にトランスポート層FECの利益を得るかもしれません。(その時、規格ベースのメソッドは利用可能になります)。 前進型誤信号訂正(FEC)メソッドがただ一つのメッセージの中で合う短いrekeyメッセージのためになるのは、ありそうもないです。 この場合、FECはメッセージの簡単な「再-トランスミッション」に退化しています。
5.5. Implosion
5.5. 内部破裂
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つのため起こるかもしれません。 まず最初に、rekeyプロトコルの目標の1つがGSAを連動させることであると思い出してください。 rekeyかData SAが期限が切れると、メンバーはアップデートのためにGCKSに連絡するかもしれません。 多くであっても、メンバーはほぼ同じ頃GCKSに連絡して、GCKSはそれらのすべてのメッセージを扱うことができるかもしれないというわけではありません。 私たちは同期していない内部破裂にこれについて言及します。
The second case is in the reliable delivery of rekey messages. Reliable multicast protocols use feedback (NACK or ACK) to determine which packets must be retransmitted. Packet losses may result in many members sending NACKs to the GCKS. We refer to this as feedback implosion.
2番目のケースはrekeyメッセージの信頼できる配信中です。 信頼できるマルチキャストプロトコルは、どのパケットを再送しなければならないかを決定するのに、フィードバック(ナックかACK)を使用します。 パケット損失はNACKsを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.
いくつかの信頼できるマルチキャストプロトコルによって使われたフィードバック集合と地方の回復は容易にrekeyメッセージの輸送に適っていません。 集合は認証問題を提起します。 メンバーが、局部的修繕サーバでSAsを設立する必要があるので、地方の回復は、より複雑です。グループのどんなメンバーか下位のGCKSも修理サーバとして勤めるかもしれません。(それは、再送rekeyメッセージに原因となる場合があります)。
Members may use the group SA, more specifically the Rekey SA, to authenticate requests sent to the repair server. However, replay protection requires maintaining state at members as well as repair servers. Authentication of repair requests is meant to protect against DoS attacks. Note also that an out-of-sync member may use an expired Rekey SA to authenticate repair requests, which requires repair servers to accept messages protected by old SAs.
メンバーは、修理サーバに送られた要求を認証するのにグループSA、より明確にRekey SAを使用するかもしれません。しかしながら、反復操作による保護は、修理サーバと同様にメンバーで状態を維持するのを必要とします。 修理要求の認証はDoS攻撃から守ることになっています。 また、同期していないメンバーが修理要求を認証する満期のRekey SAを使用するかもしれないことに注意してください。(Rekey SAは、古いSAsによって保護されたメッセージを受け入れるために修理サーバを必要とします)。
Baugher, et al. Informational [Page 21] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[21ページ]のRFC4046msecグループ
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セットの局部的修繕サーバアドレスを受け取ります。 メンバーがrekeyメッセージを受け取らないとき、それは「一連番号がnで、より高い状態で再生メッセージを再送してください」メッセージを局部的修繕サーバの1つに送ることができます。 それがGCKSから受け取るように要求されたrekeyメッセージを忙しくするか、または再送することであるなら、修理サーバは要求を無視できます。 修理サーバであり、また、どれが別のメンバーであるかは、mだけに与えられた期間(すなわち、限界が応答であると評定する)か与えられたrekeyメッセージあたりの要求に役立つのを選ぶかもしれません。 要求と応答を制限するレートがDoS攻撃からグループの他のメンバーと同様に修理サーバを保護します。
5.6. Incorporating Group Key Management Algorithms
5.6. グループKey Managementアルゴリズムを取り入れます。
Group key management algorithms make rekeying scalable. Large group rekeying without employing GKMAs is prohibitively expensive.
グループかぎ管理アルゴリズムで、「再-合わせ」るのはスケーラブルになります。 GKMAsを使わないで「再-合わせ」られる大きいグループは法外に高価です。
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は、メンバーに加わる場合過去のデータを解読することができないのを確実にするはずです。
5.7. Stateless, Stateful, and Self-healing Rekeying Algorithms
5.7. 状態がなくて、Statefulの、そして、自己の治療のRekeyingアルゴリズム
We classify group key management algorithms into three categories: stateful, stateless, and self-healing.
私たちはグループかぎ管理アルゴリズムを3つのカテゴリに分類します: statefulで、状態がないのと、自己は治療です。
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
Statefulアルゴリズム[RFC2627、OFT]は、インスタンスを「再-合わせ」る電流と未来に対応するKEKsを暗号化すること(保護する)にインスタンスを「再-合わせ」る過去からKEKsを使用します。 これらの体系における主な不都合はインスタンスを「再-合わせ」ながらすべての未来からKEKsを受けることができますが、メンバーがオフラインであった、またはそうでなければ、過去の「再-合わせ」るインスタンスからKEKsを受け取らなかったなら、もうGSAを連動させることができないかもしれないということです。 唯一のソリューションはGCKSに連絡することです。
Baugher, et al. Informational [Page 22] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[22ページ]のRFC4046msecグループ
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.
明らかである、再同期のために。 最初の「再-合わせ」るインスタンスのためのKEKsがRegistration 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]は登録プロトコルの間、KEKsを送ってrekeyメッセージを暗号化します。 rekeyメッセージがどんな過去のrekeyメッセージからも独立しているので(すなわち、それはそこにKEKsによって保護されません)、メンバーは、オフラインで行きますが、将来のコミュニケーションを解読し続けるかもしれません。 しかしながら、状態がないGKMAsは、メッセージを「再-合わせ」ながら過ぎて回復するためにメカニズムを全く提供しません。 特に非常にダイナミックなグループにおける即座(バッチでない)の「再-合わせ」るには、状態がない「再-合わせ」るのは比較的効率が悪いかもしれません。
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.
自己の治療の体系[自己の治療の]では、何らかの過去のメッセージといくつかの将来のrekeyメッセージを受け取る限り、メンバーは無くなっているrekeyメッセージを再建できます。
5.8. Interoperability of a GKMA
5.8. GKMAの相互運用性
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、部分集合差)
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 1キーあたりの情報:
- key ID,
- key lifetime (creation/expiration data) ,
- encrypted key, and
- encryption key's ID (optional).
- そして、主要なID(主要な生涯(作成/満了データ))がキーを暗号化した、--暗号化キーのID(任意の)。
Baugher, et al. Informational [Page 23] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[23ページ]のRFC4046msecグループ
Key IDs may change in some implementations in which case one needs to send:
主要なIDはケース1が発信する必要があるいくつかの実装で変化するかもしれません:
o List of <old id, new id> pairs.
o <の古いイド、新しいイド>組のリスト。
6. Group Security Association
6. グループセキュリティ協会
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アーキテクチャはそれらのプロトコルのSecurity Associations(SAs)に関して登録と、rekeyと、データ機密保護プロトコルとのインタフェースを定義します。 一定のインタフェースの後ろにこれらのプロトコルを隔離することによって、実装はアーキテクチャでそれらの必要に最もよくぴったりとしたプロトコルを使用できます。 例えば、小さいグループのためのrekeyプロトコルは左右対称の認証による複数のユニキャスト送信を使用するかもしれません、大きいグループのためのrekeyプロトコルがパケット・レベルForward Error Correctionとソース認証があるIP Multicastを使用するかもしれませんが。
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は3SAsから成ります: 登録SA、Rekey SA、およびデータSA。 Rekey SAは任意です。 3SAsの間の関係を定義するのにおいて2つのケースがあります。 どちらの場合も、Registration 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を使用することでグループ重要管理にWITHOUTをします。 登録プロトコルは、1Data SAsを初期化して、アップデートします(TPKsを保護する持っているのは、ファイルするか、または流れます)。 各Data SAはただ一つのグループに対応しています。(それは、1Data SAを持っているかもしれません)。
Case 2: Group key management is done WITH a Rekey SA to protect the
rekey protocol. The registration protocol initializes the one or
more Rekey SAs as well as zero or more Data SAs, upon successful
completion. When a Data SA is not initialized in the registration
protocol, initialization is done in the rekey protocol. The rekey
protocol updates Rekey SA(s) AND establishes Data SA(s).
ケース2: グループ重要管理は処理されて、rekeyを保護するRekey SAが議定書を作るということです。 登録プロトコルはゼロと同様に1Rekey SAsか、より多くのData SAsを初期化します、無事終了に関して。 登録プロトコルでData SAを初期化しないとき、rekeyプロトコルでは、初期化します。 rekeyプロトコルは、Rekey SA(s)をアップデートして、Data SA(s)を設立します。
6.1. Group Policy
6.1. グループ方針
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.
グループ方針はGroup Security Policy Tokenドキュメント[GSPT]で詳細に説明されます。 グループ発表、かぎ管理プロトコル、および他のバンドで出ている手段(例えば、ウェブページを通した)でグループ方針を分配できます。 グループかぎ管理プロトコルはSAsとそれが設立するキーの暗号の方針を運びます、グループの安全な操作のための追加方針と同様に。
Baugher, et al. Informational [Page 24] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[24ページ]のRFC4046msecグループ
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.
彼らがかぎ管理交換のどれかに先行するので、登録プロトコルのための許容できる暗号の方針(IPsec、またはIKE)は、グループかぎ管理プロトコルで伝えられません。(それは、TLS[TLS]をひくかもしれません)。 したがって、何らかのアクセス・プロトコルを持っている安全保障政策倉庫は、その設立のための初期の暗号の方針を決定するためにかぎ管理セッションを確立する前に質問される必要があるかもしれません。 このドキュメントは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 グループのためにGCKSを特定するためのGroup所有者のアイデンティティ、認証方法、および委譲メソッド。
o the group GCKS, authentication method, and delegation method
for any subordinate GCKSs for the group;
o グループのためのどんな下位のGCKSsのためのグループGCKS、認証方法、および委譲メソッドも。
o the group membership rules or list and authentication method.
o グループ会員資格規則かリストと認証方法。
There are two additional policy-related requirements external to group key management.
かぎ管理を分類するためには外部の2つの追加方針関連の要件があります。
o There is an authentication and authorization infrastructure
such as X.509 [RFC3280], SPKI [RFC2693], or a pre-shared key
scheme, in accordance with the group policy for a particular
group.
o X.509[RFC3280]、SPKI[RFC2693]、またはあらかじめ共有された主要な体系などの認証と承認インフラストラクチャがあります、特定のグループのためのグループ方針によると。
o There is an announcement mechanism for secure groups and
events, which operates according to group policy for a
particular group.
o 安全なグループとイベントのための発表メカニズムがあります。(グループ方針によると、それは、特定のグループのために動作します)。
Group policy determines how the registration and rekey protocols initialize or update Rekey and Data SAs. The following sections describe potential information sent by the GCKS for the Rekey and Data SAs. A member needs the information specified in the next sections to establish Rekey and Data SAs.
グループ方針は、登録とrekeyプロトコルがどのようにRekeyとData SAsを初期化するか、またはアップデートするかを決定します。 以下のセクションはRekeyとData SAsのためにGCKSによって送られた潜在的情報について説明します。 メンバーは、RekeyとData SAsを証明するために次のセクションで情報を指定する必要があります。
6.2. Contents of the Rekey SA
6.2. Rekey 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.
Rekey SAはrekeyプロトコルを保護します。 それは唯一SA、反復操作による保護情報、および主要な保護キーを特定する暗号の方針、Group Identity、およびSecurity Parameter Index(SPI)[RFC2401]を含んでいます。
Baugher, et al. Informational [Page 25] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[25ページ]のRFC4046msecグループ
6.2.1. Rekey SA Policy
6.2.1. Rekey SA方針
o GROUP KEY MANAGEMENT ALGORITHM
o グループかぎ管理アルゴリズム
This represents the group key revocation algorithm that
enforces forward and backward access control. Examples of key
revocation algorithms include LKH, LKH+, OFT, OFC, and Subset
Difference [RFC2627,OFT,TAXONOMY,SD1,SD2]. If the key
revocation algorithm is NULL, the Rekey SA contains only one
KEK, which serves as the group KEK. The rekey messages
initialize or update Data SAs as usual. However, the Rekey SA
itself can be updated (the group KEK can be rekeyed) when
members join or the KEK is about to expire. Leave rekeying is
done by re-initializing the Rekey SA through the rekey
protocol.
これは前進の、そして、後方のアクセスコントロールを実施するグループキー取消しアルゴリズムを表します。 主要な取消しアルゴリズムに関する例はLKH、LKH+、OFT、OFC、およびSubset Difference[RFC2627、OFT、TAXONOMY、SD1、SD2]を含んでいます。 主要な取消しアルゴリズムがNULLであるなら、Rekey SAは1KEKだけを含んでいます。(KEKはグループKEKとして機能します)。 rekeyメッセージは、通常通りのData SAsを初期化するか、またはアップデートします。 しかしながら、メンバーが加わるか、またはKEKが期限が切れようとしているとき、Rekey SA自身をアップデートできます(グループKEKを「再-合わせ」ることができます)。 「再-合わせ」ることがrekeyプロトコルを通してRekey 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認証(すべての共有秘密キーはいくつかかすべてのメンバーにとってグループを知られているので)、または何らかの左右対称の秘密にグループ認証のためにMACsを計算する際にデジタル署名を使用します。 どんなグループのメンバーも特定のソースをまねることができるので、左右対称の認証は、より弱い認証を提供します。 また、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.
このアドレスはrekeyメッセージのマルチキャスト伝達に使用されます。 ANNOUNCEMENTプロトコルや呼び出しセットアップメッセージなどの制御チャンネルの上にこの情報を送ります。 制御集団アドレスが保護される度合いはグループ方針の問題です。
o REKEY SERVER ADDRESS
o REKEYサーバアドレス
This address allows the registration server to be a different
entity from the server used for rekeying, such as for future
invocations of the registration and rekey protocols. If the
registration server and the rekey server are two different
entities, the registration server sends the rekey server's
address as part of the Rekey SA.
このアドレスは、登録サーバが「再-合わせ」る登録とrekeyプロトコルの将来の実施などのように使用されるサーバからの異なった実体であることを許容します。 登録サーバとrekeyサーバが2つの異なった実体であるなら、登録サーバはRekey SAの一部としてrekeyサーバのアドレスを送ります。
Baugher, et al. Informational [Page 26] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[26ページ]のRFC4046msecグループ
6.2.2. Group Identity
6.2.2. グループのアイデンティティ
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.
特定のグループ重要管理が議定書を作るならただ一つのrekeyメッセージでアップデートするために識別子で登録プロトコルのただ一つの実施、または複数のグループで複数のグループを初期設定されるとき、グループのアイデンティティはSA(ペイロード)情報に伴います。 それぞれの登録実施をただ一つのグループに制限するのがしばしばより簡単ですが、そのような制限は不要です。 SAパラメタとそれとなくSPIか明らかにRekey SAを書き立てるとき、グループを特定するのがいつも必要です。
6.2.3. KEKs
6.2.3. KEKs
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は1KEKsを含んでいます。 GCKSはグループの主要な暗号化かぎを握ります、かぎ管理アルゴリズムの仕様に従って、メンバーがキーを受け取りますが。 グループのための複数のKEKsがあるとき(LKH木のように)、各KEKは、Key IDに関連している必要があります。(IDは、それを解読するのに必要であるキーを特定するのに使用されます)。 各KEKにはそれに関連しているLIFETIMEがあります。(その時、KEKは期限が切れました後)。
6.2.4. Authentication Key
6.2.4. 認証キー
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が左右対称の状態でaを提供するか、またはrekeyの認証のための公開鍵は通信します。 すべてのグループのメンバーがGCKSをまねないと信じることができるときだけ、対称鍵認証は適切です。 アーキテクチャはGCKSからそれらを押すよりメンバー[RFC2409]でむしろ左右対称の認証キーを引き出すためのメソッドを除外しません。
6.2.5. Replay Protection
6.2.5. 反復操作による保護
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メッセージは、再生/反射攻撃から保護される必要があります。 一連番号はこのために使用されます、そして、Rekey SA(議定書を作る)はこの情報を含んでいます。
6.2.6. Security Parameter Index (SPI)
6.2.6. セキュリティパラメタインデックス(SPI)
The tuple <Group identity, SPI> uniquely identifies a Rekey SA. The SPI changes each time the KEKs change.
tuple<Groupのアイデンティティであり、SPI>は唯一Rekey SAを特定します。 SPIはその都度、KEKs変化を変えます。
6.3. Contents of the Data SA
6.3. データSAのコンテンツ
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超能力[RFC2401]とSRTP[RFC3711]を含んでいます。 それぞれのこれらのコンテンツをプロトコルがあるゆったり過ごしてください。
Baugher, et al. Informational [Page 27] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[27ページ]のRFC4046msecグループ
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.
このドキュメントの範囲、私たちは登録プロトコル(または、rekeyプロトコル)によって送られた、Data SAを初期化するか、またはアップデートした情報をリストアップします。
6.3.1. Group Identity
6.3.1. グループのアイデンティティ
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.
GroupのアイデンティティはData SAsがいつ登録プロトコルのただ一つの実施かただ一つのRekeyメッセージの複数のグループのために初期化されるか、または「再-合わせ」られるかというSA情報に伴います。
6.3.2. Source Identity
6.3.2. ソースのアイデンティティ
The SA includes source identity information when the group owner chooses to reveal source identity to authorized members only. A public channel such as the announcement protocol is only appropriate when there is no need to protect source or group identities.
SAはグループの所有者が、いつ認可されたメンバーだけへのソースのアイデンティティを明らかにするのを選ぶかというソースアイデンティティ情報を含んでいます。 ソースかグループのアイデンティティを保護する必要は全くないときだけ、発表プロトコルなどの公共のチャンネルが適切です。
6.3.3. Traffic Protection Keys
6.3.3. トラフィック保護キー
Regardless of the data security protocol used, the GCKS supplies the TPKs, or information to derive TPKs for traffic protection.
使用されるデータ機密保護プロトコルにかかわらず、GCKSはTPKs、またはトラフィック保護のためにTPKsを引き出す情報を提供します。
6.3.4. Data Authentication Keys
6.3.4. データ認証キー
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つ以上のキー、機能(例えば、テスラ[テスラ-INFO、テスラ-SPEC])、または他のパラメタを渡すかもしれません。
6.3.5. Sequence Numbers
6.3.5. 一連番号
The GCKS passes sequence numbers when needed by the data security protocol, for SA synchronization and replay protection.
データ機密保護プロトコルがSA同期と反復操作による保護に必要であると、GCKSは一連番号を通過します。
6.3.6. Security Parameter Index (SPI)
6.3.6. セキュリティパラメタインデックス(SPI)
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はData SAコンテンツの一部としてSAの中でSAかキーを特定するのにSPIか同様のメカニズムを使用するデータ機密保護プロトコルに識別子を提供するかもしれません。
6.3.7. Data SA policy
6.3.7. データ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.
Data SAパラメタは、データ機密保護プロトコルに特定ですが、一般に、暗号化アルゴリズムとパラメタ、そして/または、ソース認証アルゴリズムとパラメタ、そして/または、グループ認証アルゴリズムとパラメタ、反復操作による保護情報を含んでいます。
Baugher, et al. Informational [Page 28] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[28ページ]のRFC4046msecグループ
7. Scalability Considerations
7. スケーラビリティ問題
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)は多くのただ一つのセッションまでの電子会議メンバーに集めるのに使用されるかもしれません。 また、MCUsは階層的で組織化されるかもしれません。 [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.
Requirements部で説明されるように、セクション2、かぎ管理アーキテクチャが独身の送付者と共にマルチキャストアプリケーションをサポートするグループです。 この紙で説明されたアーキテクチャは以下の特徴を通した大きいスケール操作をサポートします。
1. There is no need for a unicast exchange to provide data keys to a
security protocol for members who have previously registered in
the particular group; data keys can be pushed in the rekey
protocol.
1. ユニキャスト交換が以前に特定のグループで登録したメンバーにセキュリティプロトコルのデータキーを提供する必要は全くありません。 rekeyプロトコルでデータキーを押すことができます。
2. The registration and rekey protocols are separable to allow
flexibility in how members receive group secrets. A group may use
a smart-card based system in place of the registration protocol,
for example, to allow the rekey protocol to be used with no back
channel for broadcast applications such as television conditional
access systems.
2. 登録とrekeyプロトコルはメンバーがどうグループ秘密を受け取るかの柔軟性を許容するのにおいて分離できます。 グループは、登録プロトコルに代わって例えば、rekeyプロトコルがテレビの限定受信システムなどの全面散布に戻っているチャンネルなしで使用されるのを許容するのにスマートカードに基づいているシステムを使用するかもしれません。
3. The registration and rekey protocols support new keys, algorithms,
authentication mechanisms and authorization infrastructures in the
architecture. When the authorization infrastructure supports
delegation, as in X.509 and SPKI, the GCKS function can be
distributed as shown in Figure 3 below.
3. 登録とrekeyプロトコルはアーキテクチャの新しいキー、アルゴリズム、認証機構、および承認インフラストラクチャをサポートします。 承認インフラストラクチャがX.509とSPKIのように委譲をサポートするとき、以下の図3に示されるようにGCKS機能を分配できます。
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
メンバーが既にグループに属すとき、リストにおける最初の特徴はデータ機密保護プロトコルを速い合わせることを許します。 満足しているイベントを提供するサービスプロバイダーの加入者グループと顧客にとって、これが現実的である間、イベント時点でメンバー登録を許すアプリケーションにおいて、それは制限し過ぎているかもしれません。 MSECグループかぎ管理アーキテクチャは、潜在的大規模同時の登録要求を扱うために主要な分配が階層的で結団されたと示唆します。 主要なGCKSサイトの従来のクラスタリングとロードバランシング解答が顧客の要求を満たすことができないなら、図3構成が必要であるかもしれません。 従来のキャッシュと内容と異なって
Baugher, et al. Informational [Page 29] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[29ページ]のRFC4046msecグループ
distribution networks, however, the configuration shown in Figure 3 has additional security ramifications for physical security of a GCKS.
しかしながら、流通機構であり、図3に示された構成はGCKSの物理的なセキュリティのための追加担保分岐を持っています。
+----------------------------------------+
| +-------+ |
| | GCKS | |
| +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| +-------------+ |
| | | |
| v ... v |
| +-------+ +-------+ |
| | GCKS | | GCKS | |
| +-------+ +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| ... |
+----------------------------------------+
+----------------------------------------+ | +-------+ | | | GCKS| | | +-------+ | | | ^ | | | | | | | +---------------+ | | | ^ ^ | | | | ... | | | | +--------+ +--------+ | | | | メンバー| | メンバー| | | | +--------+ +--------+ | | v| | +-------------+ | | | | | | v v…| | +-------+ +-------+ | | | GCKS| | GCKS| | | +-------+ +-------+ | | | ^ | | | | | | | +---------------+ | | | ^ ^ | | | | ... | | | | +--------+ +--------+ | | | | メンバー| | メンバー| | | | +--------+ +--------+ | | 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の操作を中断するのを試みるグループのメンバー、および非会員による攻撃に対して安全である必要があります。
Baugher, et al. Informational [Page 30] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[30ページ]のRFC4046msecグループ
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を代表してキーに役立つようにグループの所有者によって指定された複数のGCKSsの向こう側にどのように広げられるかもしれないかを考える必要があります。 GSAKMP[GSAKMP]プロトコルは、方針トークンを使用して、下位のGCKSsとして何人かのメンバーを任命するとこのスケーラビリティ問題が扱われるのを許容します。
8. Security Considerations
8. セキュリティ問題
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.
認証された主要な交換[通り、SKEME、RFC2408、RFC2412、RFC2409]のテクニックは中央の人と接続が攻撃をハイジャックするという効果を制限します。 一連番号と低い計算通報認証のテクニックは再生と反射攻撃に対して効果的である場合があります。 適切に実装されると、クッキー[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
グループ重要管理の別の制限は方針の複雑さです。 ピアツーピア安全保障政策は個々の同輩の方針の交差点ですが、グループの所有者はグループ安全保障政策を設定します。
Baugher, et al. Informational [Page 31] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[31ページ]のRFC4046msecグループ
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.
中で外部的にグループを保証してください。 このドキュメントは、グループ重要管理における、暗号の、または、他のセキュリティパラメタの交渉が全くないと仮定します。 したがって、グループ安全保障政策は安全なグループから発信するメンバーと受信データに新しい危険を引き起こします。 セキュリティ管理者、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番目のプロトコル(グループかぎ管理rekeyプロトコル)は、新しく、未知のリスクを持っています。 公開鍵暗号の使用で上で説明されたソース認証危険を取り除きます。 マルチキャスト配送の使用はマルチキャストの使用に基づく信頼性や、内部破裂や、サービス不能攻撃などの追加担保問題を提起するかもしれません。 提供するrekeyプロトコル仕様の必要性は. これらの問題への解決がrekeyプロトコルの各具体化であると機密保護します、GSAKMP RekeyやGDOI Groupkey-プッシュ操作のように、それらのrekey仕様のセキュリティを有効にする必要性。
Novelty and complexity are the biggest risks to group key management protocols. Much more analysis and experience are needed to ensure that the architecture described in this document can provide a well- articulated standard for security and risks of group key management.
目新しさと複雑さはかぎ管理プロトコルを分類する最も大きいリスクです。 ずっと多くの分析と経験が、本書では説明されたアーキテクチャがグループ重要管理のセキュリティとリスクの上手に明確に話された規格を提供できるのを保証するのに必要です。
9. Acknowledgments
9. 承認
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ビルBlock[GKMBB]I-Dはこのドキュメントへの先駆でした。 それらの取り組みのためにトーマスHardjonoとヒュー・ハーニーをありがとうございます。 このドキュメントを準備するコースの間、MSEC WG、GSEC、およびSMuG研究グループのアンドレア・コールグローブ、ブライアン・ウィス、ジョージGross、および数人の他のものがこのドキュメントを改良するのを助けた貴重なコメントを提供しました。 作者はこのドキュメントへの彼らの貢献に感謝します。
Baugher, et al. Informational [Page 32] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[32ページ]のRFC4046msecグループ
10. Informative References
10. 有益な参照
[BatchRekey] Yang, Y. R., et al., "Reliable Group Rekeying: Design
and Performance Analysis", Proc. ACM SIGCOMM, San
Diego, CA, August 2001.
[BatchRekey]陽、Y.R.、他、「信頼できるグループRekeying:」 「デザインと機能解析」、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
[徒党]のスタイナー、M.、Tsudik、G.、およびM.Waidner、「徒党:」 「グループの主要な協定への新しいアプローチ」、IEEE ICDCS97、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]法令(A.とM.Naor)は、「暗号理論で暗号化、進歩を放送しました」、CRYPTO93Proceedings、コンピュータScienceのLecture Notes、Vol.773、ページ 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]ハーニー、H.、M.Baugher、およびT.Hardjono、「GKMブロック:」 「グループセキュリティ協会(GSA)定義」、処理中の作業、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]ハーニー、H.、コールグローブ、A.、進行中(2003年2月)で、より一生懸命、E.、メタンフェタミン、U.、およびR.フレイシャー、「グループの安全な協会Key Managementプロトコル」は働いています。
[GSPT] Hardjono, T., Harney, H., McDaniel, P., Colegrove,
A., and P. Dinsmore, "The MSEC Group Security Policy
Token", Work in Progress, August 2003.
T.とハーニーとH.とマクダニエルとP.とコールグローブ、A.とP.Dinsmore、「msecグループ安全保障政策トークン」という[GSPT]Hardjonoは進行中(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]国際Telecommunications Union、「H-シリーズのためのセキュリティとEncryption、(H.323で他、H.245ベース、)、マルチメディアTerminals、」、ITU-T Recommendation H.235バージョン3、進行中のWork、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]M.、まさしくKranakis E.、Krizanc、D.とP.バンOorschot、「True Broadcastingを通したKey Distribution」Proc。 コンピュータとCommunications Security、ページの第2ACMコンファレンス 81-88と、1994年11月。
[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.
[マークします] ブリスコウ(B.)は「以下をマークします」。 「任意に明らかにされたキー順を使用しないどんな副作用マルチキャストKey Managementも」、Proc。 1999年11月のネットワークでつながれたグループコミュニケーション(NGC)、ピサ、イタリアに関する国際労働者協会ワークショップ。
[MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,
and K. Norrman, "MIKEY: Multimedia Internet KEYing",
RFC 3830, August 2004.
[マイキー]Arkko、J.、カラーラ、E.、リンドホルム、F.、ジーター、M.、およびK.Norrman、「マイキー:」 「マルチメディアインターネットの合わせる」RFC3830、2004年8月。
Baugher, et al. Informational [Page 33] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[33ページ]のRFC4046msecグループ
[MSEC-Arch] Hardjono, T. and B. Weis, "The Multicast Group
Security Architecture", RFC 3740, March 2004.
[msecアーチ] HardjonoとT.とB.ウィス、「マルチキャストグループセキュリティー体系」、RFC3740、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.とバンOorschot、P.C.とS.A.Vanstone、「適用された暗号のハンドブック」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.
[標準]Adamon、B.、ボルマン、C.、ハンドレー、M.、およびJ.Macker、「否定応答の(ナック)指向の信頼できるマルチキャスト(標準)プロトコル」、RFC3940、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.
[しばしば] Balenson、D.、マグリュー、P.C.、およびA.シャーマン、「大きいダイナミックなグループのために管理を合わせてください」 IRTFは、進歩、2000年8月に「一方向関数木と清算された初期設定」と扱います。
[RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC2093] ハーニーとH.とC.Muckenhirn、「グループKey Managementプロトコル(GKMP)仕様」、RFC2093、1997年7月。
[RFC2094] Harney, H., and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture" RFC 2094, July 1997.
[RFC2094]ハーニー、H.、およびC.Muckenhirn、「グループKey Managementプロトコル(GKMP)アーキテクチャ」RFC2094、1997年7月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[RFC2326]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session
Description Protocol", RFC 2327, April 1998.
[RFC2327] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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.Phan、「pfの_の主要なKey Management API、バージョン2インチ、RFC2367、1998年7月。」
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、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.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[RFC2412] Orman、H.、「オークリーの主要な決断プロトコル」、RFC2412、1998年11月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key
Management Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P.、およびW.シンプソン、「Photuris:」 「セッションKey Managementプロトコル」、RFC2522、1999年3月。
Baugher, et al. Informational [Page 34] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[34ページ]のRFC4046msecグループ
[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.、Rivest、R.、トーマス、B.、およびT.Ylonen、「SPKI証明書理論」、RFC2693(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.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management
for Multicast: Issues and Architectures", RFC 2627,
June 1999.
[RFC2627] ウォルナー、D.、ハーダー、E.、およびR.エージー、「マルチキャストのための管理を合わせてください」 「問題とアーキテクチャ」、RFC2627、6月1999日
[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.、リゾー、L.、およびJ.クロウクロフト、「非同期な層にされたコード化(ALC)は具体化について議定書の中で述べます」、RFC3450、2002年12月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney,
"The Group Domain of Interpretation", RFC 3547, July
2003.
2003年7月の[RFC3547]BaugherとM.とウィスとB.とHardjono、T.とH.ハーニー、「解釈のグループドメイン」RFC3547。
[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.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、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] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[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.、および「状態がない受信機の取消しと追跡体系」というLotspiechが暗号理論--暗号で進めるJ.、サンタバーバラ、カリフォルニア: 追出石Verlag Inc.、LNCS2139、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.ピンカス、「効率的な跡と取消し体系」、財政的な暗号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.
[自己の治療の] etアルStaddon、J.、「自己に、取消しとの主要な分配を癒す」Proc。 2002年のセキュリティとプライバシーに関するIEEEシンポジウム、オークランド、カリフォルニアは2002がそうするかもしれません。
Baugher, et al. Informational [Page 35] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[35ページ]のRFC4046msecグループ
[SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", ISOC Secure Networks and
Distributed Systems Symposium, San Diego, 1996.
[SKEME]H.Krawczyk、「SKEME:」 「インターネットへの多能な安全な主要な交換メカニズム」、ISOCは、ネットワークと分散システムがシンポジウム、サンディエゴ、1996であると機密保護します。
[STS] Diffie, P. van Oorschot, M., and J. Wiener,
"Authentication and Authenticated Key Exchanges",
Designs, Codes and Cryptography, 2, 107-125 (1992),
Kluwer Academic Publishers.
[STS]ディフィー、P.バンOorschot、M.とJ.Wienerと「認証と認証されたキー交換」とDesignsとCodesとCryptography、2、107-125(1992)、Kluwer Academic Publishers。
[TAXONOMY] Canetti, R., et. al., "Multicast Security: A Taxonomy
and some Efficient Constructions", IEEE INFOCOM,
1999.
[TAXONOMY] etカネッティ、R.、アル、「マルチキャストセキュリティ:」 「TaxonomyといくつかのEfficient Constructions」、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.
[テスラ-インフォメーション] Perrig、A.、カネッティ、R.、歌、D.、Tygar、D.、およびB.ブリスコウ、「テスラ:」 「マルチキャストソース認証変換序論」、処理中の作業、2004年12月。
[TESLA-SPEC] Perrig, A., R. Canetti, and Whillock, "TESLA:
Multicast Source Authentication Transform
Specification", Work in Progress, April 2002.
[テスラ-仕様]のPerrig、A.、R.カネッティ、およびWhillock、「テスラ:」 「マルチキャストソース認証変換仕様」、処理中の作業、2002年4月。
[tGSAKMP] Harney, H., et. al., "Tunneled Group Secure
Association Key Management Protocol", Work in
Progress, May 2003.
[tGSAKMP] etハーニー、H.、アル、「トンネルを堀られたグループ安全な協会Key Managementプロトコル」、Progress、5月2003日のWork
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0," RFC 2246, January 1999.
[TLS]Dierks、T.、およびC.アレン、「TLSプロトコルバージョン1.0」、1999年1月のRFC2246。
[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] マーク、D.、およびB.ターンブル、「技術的な保護は測定します」。 「技術、法、および商業ライセンスの交差点」、著作権に関する世界知的所有権機関条約(WCT)の導入問題に関するワークショップ、実演およびレコードに関する世界知的所有権条約(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.、「EncryptedのためのKey Managementは放送しました」、コンピュータとCommunications Security、サンフランシスコ(カリフォルニア)1998年11月に関する第5ACMコンファレンス。
Baugher, et al. Informational [Page 36] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[36ページ]のRFC4046msecグループ
Authors' Addresses
作者のアドレス
Mark Baugher Cisco Systems 5510 SW Orchid St. Portland, OR 97219, USA
5510年のマークBaugherシスコシステムズSW Orchid聖ポートランド、または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
カネッティIBM Research30製材機械川の道路サンザシ、ニューヨーク 10532、米国を経営していました。
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クアルコム5775モアハウス・Driveサンディエゴ、カリフォルニア 92121
Phone: +1 858 845 1267 EMail: ldondeti@qualcomm.com
以下に電話をしてください。 +1 1267年の858 845メール: ldondeti@qualcomm.com
Fredrik Lindholm Ericsson Research SE-16480 Stockholm, Sweden
フレドリック・リンドホルム・エリクソン研究SE-16480ストックホルム(スウェーデン)
Phone: +46 8 58531705 EMail: fredrik.lindholm@ericsson.com
以下に電話をしてください。 +46 8 58531705 メール: fredrik.lindholm@ericsson.com
Baugher, et al. Informational [Page 37] RFC 4046 MSEC Group Key Management Architecture April 2005
Baugher、他 管理体系2005年4月に主要な情報[37ページ]のRFC4046msecグループ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Baugher, et al. Informational [Page 38]
Baugher、他 情報[38ページ]
一覧
スポンサーリンク
