RFC1949 日本語訳
1949 Scalable Multicast Key Distribution. A. Ballardie. May 1996. (Format: TXT=41853 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Ballardie Request for Comments: 1949 University College London Category: Experimental May 1996
Ballardieがコメントのために要求するワーキンググループA.をネットワークでつないでください: 1949年のユニバーシティ・カレッジロンドンカテゴリ: 実験的な1996年5月
Scalable Multicast Key Distribution
スケーラブルなマルチキャスト主要な分配
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
The benefits of multicasting are becoming ever-more apparent, and its use much more widespread. This is evident from the growth of the MBONE [1]. Providing security services for multicast, such as traffic integrity, authentication, and confidentiality, is particularly problematic since it requires securely distributing a group (session) key to each of a group's receivers. Traditionally, the key distribution function has been assigned to a central network entity, or Key Distribution Centre (KDC), but this method does not scale for wide-area multicasting, where group members may be widely-distributed across the internetwork, and a wide-area group may be densely populated.
マルチキャスティングの利益は明らかな状態で絶えずさらにふさわしく、使用ははるかに広範囲です。 これはMBONE[1]の成長によって明白です。 しっかりとそれぞれのグループの受信機に主要なグループ(セッション)を配布するのが必要であるので、トラフィック保全や、認証や、秘密性などのマルチキャストのためのセキュリティー・サービスを提供するのは特に問題が多いです。 伝統的に、中央のネットワーク実体、またはKey Distribution Centre(KDC)に主要な分配機能を割り当ててありますが、このメソッドは広い領域マルチキャスティングのために比例しません、グループのメンバーがインターネットワークの向こう側に広く分配されているかもしれなくて、広い領域グループが人口密度が高いかもしれないところで。
Even more problematic is the scalable distribution of sender-specific keys. Sender-specific keys are required if data traffic is to be authenticated on a per-sender basis.
さらに問題が多いのは、送付者特有のキーのスケーラブルな分配です。 送付者特有のキーがデータ通信量が1送付者あたり1個のベースで認証されることであるなら必要です。
This memo provides a scalable solution to the multicast key distribution problem.
このメモはマルチキャストの主要な分配問題にスケーラブルな解決法を提供します。
NOTE: this proposal requires some simple support mechanisms, which, it is recommended here, be integrated into version 3 of IGMP. This support is described in Appendix B.
以下に注意してください。 この提案がいくつかの簡単なサポートメカニズムを必要とする、どれ、それはここでお勧めであり、IGMPのバージョン3と統合されてくださいか。 このサポートはAppendix Bで説明されます。
1. Introduction
1. 序論
Growing concern about the integrity of Internet communication [13] (routing information and data traffic) has led to the development of an Internet Security Architecture, proposed by the IPSEC working group of the IETF [2]. The proposed security mechanisms are implemented at the network layer - the layer of the protocol stack at which networking resources are best protected [3].
インターネット通信[13](ルーティング情報とデータ通信量)の保全に関する増加している心配はIETF[2]のIPSECワーキンググループによって提案されたインターネットSecurity Architectureの開発につながりました。 提案されたセキュリティー対策はネットワーク層で実装されます--ネットワークリソースが最も良いプロトコル・スタックの層は[3]を保護しました。
Ballardie Experimental [Page 1] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[1ページ]RFC1949
Unlike many network layer protocols, the Core Based Tree (CBT) multicast protocol [4] makes explicit provision for security; it has its own protocol header, unlike existing IP multicast schemes [10,11], and other recently proposed schemes [12].
多くのネットワーク層プロトコルと異なって、Core Based Tree(CBT)マルチキャストプロトコル[4]はセキュリティへの明白な設備をします。 それには、既存のIPマルチキャスト体系[10、11]、および他の最近提案された体系[12]と異なってそれ自身のプロトコルヘッダーがあります。
In this document we describe how the CBT multicast protocol can provide for the secure joining of a CBT group tree, and how this same process can provide a scalable solution to the multicast key distribution problem. These security services are an integral part of the CBT protocol [4]. Their use is optional, and is dependent on each individual group's requirements for security. Furthermore, the use of the CBT multicast protocol for multicast key distribution does not preclude the use of other multicast protocols for the actual multicast communication itself, that is, CBT need only be the vehicle with which to distribute keys.
本書では私たちは、CBTマルチキャストプロトコルがどうしたらCBTグループ木の安全な接合に備えることができるか、そして、この同じプロセスがどうしたらマルチキャストの主要な分配問題にスケーラブルな解決法を提供できるかを説明します。 これらのセキュリティー・サービスはCBTプロトコル[4]の不可欠の部分です。 彼らの使用は、任意であり、セキュリティのためのそれぞれの個々のグループの要件に依存しています。 その上、CBTマルチキャストプロトコルのマルチキャストの主要な分配の使用は他のマルチキャストプロトコルの実際のマルチキャストコミュニケーション自体の使用を排除しません、すなわち、CBTがキーを分配する乗り物であるだけでよいです。
Secure joining implies the provision for authentication, integrity,
and optionally, confidentiality, of CBT join messages. The scheme we
describe provides for the authentication of tree nodes (routers) and
receivers (end-systems) as part of the tree joining process. Key
distribution (optional) is an integral part of secure joining.
安全な接合が任意に認証、保全への支給を含意する、秘密性、CBTでは、メッセージを接合してください。 私たちが説明する体系は木のノード(ルータ)の認証に備えます、そして、木の接合の一部としての受信機(エンドシステム)は処理されます。 主要な分配(任意の)は安全な接合の不可欠の部分です。
Network layer multicast protocols, such as DVMRP [7] and M-OSPF [9], do not have their own protocol header(s), and so cannot provision for security in themselves; they must rely on whatever security is provided by IP itself. Multicast key distribution is not addressed to any significant degree by the new IP security architecture [2].
DVMRP[7]とM-OSPF[9]などのネットワーク層マルチキャストプロトコルは、それら自身のプロトコルヘッダーを持っていないので、自分たちのセキュリティへの支給を持つことができません。 彼らはIP自身によって提供されるどんなセキュリティも当てにしなければなりません。 マルチキャストの主要な分配は新しいIPセキュリティー体系[2]によってどんな重要な度合いにも扱われません。
The CBT security architecture is independent of any particular cryptotechniques, although many security services, such as authentication, are easier if public-key cryptotechniques are employed.
CBTセキュリティー体系はどんな特定のcryptotechniquesからも独立しています、公開鍵cryptotechniquesが採用しているなら、認証などの多くのセキュリティー・サービスが、より簡単ですが。
What follows is an overview of the CBT multicasting. The description of our proposal in section 6.1 assumes the reader is reasonably familiar with the CBT protocol. Details of the CBT architecture and protocol can be found in [7] and [4], respectively.
続くことはCBTマルチキャスティングの概要です。 セクション6.1での私たちの提案の記述は、読者が合理的にCBTプロトコルに詳しいと仮定します。 [7]と[4]でそれぞれCBTアーキテクチャとプロトコルの詳細を見つけることができます。
2. Overview of BCT Multicasting
2. BCTマルチキャスティングの概要
CBT is a new architecture for local and wide-area IP multicasting, being unique in its utilization of just one shared delivery tree per group, as opposed to the source-based delivery tree approach of existing IP multicast schemes, such as DVMRP and MOSPF.
CBTは地方の、そして、広い領域のIPマルチキャスティングのための新しいアーキテクチャです、1グループあたりちょうど1本の共有された配送木の利用でユニークであることで、既存のIPマルチキャスト体系のソースベースの配送木のアプローチと対照的に、DVMRPやMOSPFのように。
A shared multicast delivery tree is built around several so-called core routers. A group receiver's local multicast router is required to explicitly join the corresponding delivery tree after receiving an
共有されたマルチキャスト配送木はいくつかのいわゆるコアルータの周りに建てられます。 グループ受信機の地方のマルチキャストルータが、受信した後に明らかに対応する配送木に合流するのに必要です。
Ballardie Experimental [Page 2] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[2ページ]RFC1949
IGMP [8] group membership report over a directly connected interface. A CBT join message is targeted at one of the group's core routers. The resulting acknowledgement traverses the reverse-path of the join, resulting in the creation of a tree branch. Routers along these branches are called non-core routers for the group, and there exists a parent-child relationship between adjacent routers along a branch of the same tree (group).
IGMP[8]は直接接続されたインタフェースの上で会員資格レポートを分類します。 CBTはメッセージを接合します。グループのコアルータの1つでは、狙います。 結果として起こる承認が逆経路を横断する、木の枝の作成をもたらして、接合してください。 これらの支店に沿ったルータはグループのために中核でないルータと呼ばれます、そして、親子関係は間に同じ木(グループ)の枝に沿ったルータに隣接して存在します。
3. How the CBT Architecture Complements Security
3. CBTアーキテクチャはどうセキュリティの補足となるか。
The CBT architecture requires "leaf" routers to explicitly join a CBT tree. Hence, CBT is not data driven; the ack associated with a join "fixes" tree state in the routers that make up the tree. This so- called "hard state" remains until the tree re-configures, for example, due to receivers leaving the group, or because an upstream failure has occurred. The CBT protocol incorporates mechanisms enabling a CBT tree to repair itself in the event of the latter.
CBTアーキテクチャは、明らかにCBT木に合流するために「葉」ルータを必要とします。 したがって、CBTは追い立てられたデータではありません。 aに関連しているackは「フィックス」木の状態に木を作るルータで加わります。 木が例えば支払われるべきものを仲間から抜ける受信機に再構成するか、または上流の失敗が起こったのでこのそのように呼ばれた「固い状態」は残っています。 CBTプロトコルはCBT木が後者の場合、それ自体を修理するのを可能にするメカニズムを組み込みます。
As far as the establishment of an authenticated multicast distribution tree is concerned, DVMRP, M-OSPF, and PIM, are at a disadvan- tage; the nature of their "soft state" means a delivery tree only exists as long as there is data flow. Also, routers implementing a multicast protocol that builds its delivery tree based on a reverse-path check (like DVMRP and PIM dense mode) cannot be sure of the previous-hop router, but only the interface a multicast packet arrived on.
認証されたマルチキャスト分配木の設立に関する限り、DVMRP(M-OSPF、およびPIM)はdisadvan- tageにあります。 それらの「軟性国家」の自然は、データフローがある限り、配送木が存在するだけであることを意味します。 また、逆経路チェック(DVMRPとPIMの濃いモードのような)に基づく配送木をそれが築き上げるマルチキャストプロトコルに実装するルータも前のホップルータが確かである場合があるのではなく、マルチキャストパケットが到着したインタフェースだけが確かです。
These problems do not occur in the CBT architecture. CBT's hard state approach means that all routers that make up a delivery tree know who their on-tree neighbours are; these neighbours can be authenticated as part of delivery tree set-up. As part of secure tree set-up, neighbours could exchange a secret packet handle for inclusion in the CBT header of data packets exchanged between those neighbours, allowing for the simple and efficient hop-by-hop authentication of data packets (on-tree).
これらの問題はCBTアーキテクチャで起こりません。 CBTの困難な州のアプローチは、配送木を作るすべてのルータが、木の上の彼らの隣人がだれであるかを知っていることを意味します。 配送木のセットアップの一部としてこれらの隣人を認証できます。 安全な木のセットアップの一部として、隣人はそれらの隣人の間で交換されたデータ・パケットのCBTヘッダーでの包含のための秘密のパケットハンドルを交換できました、ホップごとのデータ・パケット(木の)の簡単で効率的な認証を考慮して。
The presence of tree focal points (i.e. cores) provides CBT trees with natural authorization points (from a security viewpoint) -- the formation of a CBT tree requires a core to acknowledge at least one join in order for a tree branch to be formed. Thereafter, authorization and key distribution capability can be passed on to joining nodes that are authenticated.
焦点(すなわち、コア)が自然な承認ポイントがあるCBT木を提供する木(セキュリティ観点からの)の存在--CBT木の構成は、少なくとも1つが木の枝が形成される命令に参加すると認めるためにコアを必要とします。 その後、承認と主要な分配能力を認証されるノードを接合するのに越えることができます。
In terms of security, CBT's hard state approach offers several additional advantages: once a multicast tree is established, tree state maintained in the routers that make up the tree does not time out or change necessarily to reflect underlying unicast topology. The security implications of this are that nodes need not be subject
セキュリティに関して、CBTの困難な州のアプローチはいくつかの追加利点を示します: かつて、マルチキャスト木はユニキャストトポロジーの基礎となる反映する必ずタイムアウトか変化ではなく、ルータにおける木がするその化粧であることが支持された設立された木の州です。 このセキュリティ含意はノードが受けることがある必要はないということです。
Ballardie Experimental [Page 3] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[3ページ]RFC1949
to repeated authentication subsequent to a period of inactivity, and tree nodes do not need to re-authenticate themselves as a result of an underlying unicast topology change, unless of course, an network (node) failure has occurred.
ノードが基本的なユニキャストトポロジー変化の結果、自分たちを再認証するために必要としない不活発、および木の期間へのその後の繰り返された認証に、もちろんない場合、ネットワーク(ノード)失敗は起こりました。
Hard-state protocol mechanisms are often thought of as being less fault tolerant than soft-state schemes, but there are pros and cons to both approaches; we see here that security is one of the pros.
固い州のプロトコルメカニズムはフォルト・トレラントであるより柔らかい状態の体系のようにしばしば考えられますが、両方のアプローチへの賛否両論があります。 私たちは、セキュリティがプロのひとりであることがここがわかります。
4. The Multicast Key Distribution Problem
4. マルチキャストの主要な分配問題
We believe that multicast key distribution needs to be combined with group access control. Without group access control, there is no point in employing multicast key distribution, since, if there are no group restrictions, then it should not matter to whom multicast information is divulged.
私たちは、マルチキャストの主要な分配が、グループアクセスコントロールに結合される必要であると信じています。 グループアクセスコントロールがなければ、次に、グループ制限が全くなければ、重要であるべきでない時からマルチキャスト情報が明かされるマルチキャストの主要な分配を使う意味が全くありません。
There are different ways of addressing group access control. The group access control we describe requires identifying one group member (we suggest in [14] that this should be the group initiator) who has the ability to create, modify and delete all or part of a group access control list. The enforcement of group access control may be done by a network entity external to the group, or by a group member.
グループアクセスがコントロールであると扱う異なった方法があります。 私たちが説明するグループアクセス制御は、グループアクセスコントロールリストのすべてか一部を作成して、変更して、削除する能力を持っている1人のグループのメンバー(私たちは、[14]にこれがグループの創始者であるべきであると示唆する)を特定するのを必要とします。 グループへの外部のネットワーク実体、またはグループのメンバーがグループアクセスコントロールの実施を完了しているかもしれません。
The essential problem of distributing a session (or group) key to a group of multicast receivers lies in the fact that some central key management entity, such as a key distribution centre (KDC) (A Key Distribution Centre (KDC) is a network entity, usually residing at a well-known address. It is a third party entity whose responsibility it to generate and distribute symmetric key(s) to peers, or group receivers in the case of multicast, wishing to engage in a "secure" communication. It must therefore be able to identify and reliably authenticate requestors of symmetric keys.), must authenticate each of a group's receivers, as well as securely distribute a session key to each of them. This involves encrypting the relevant message n times, once with each secret key shared between the KDC and corresponding receiver (or alternatively, with the public key of the receiver), before multicasting it to the group. (Alternatively, the KDC could send an encrypted message to each of the receivers individually, but this does not scale either.) Potentially, n may be very large. Encrypting the group key with the secret key (of a secret-public key pair) of the KDC is not an option, since the group key would be accessible to anyone holding the KDC's public key, and public keys are either well-known or readily available. In short, existing multicast key distribution methods do not scale.
マルチキャスト受信機のグループに主要なセッション(分類する)を広げる主要問題が主要な分配などの何らかの中央のかぎ管理実体が(KDC)を集中させるという事実にあります。(通常、よく知られるアドレスに住んでいて、Key Distribution Centre(KDC)はネットワーク実体です。 第三者実体は責任です。それ、同輩の対称鍵を生成して、分配するそれ、または「安全な」コミュニケーションに従事したがっているマルチキャストの場合におけるグループ受信機。 それは、対称鍵の要請者を特定して、したがって、確か、認証できなければなりません。), それぞれのグループの受信機を認証して、しっかりとそれぞれのそれらに、主要なセッションを広げなければなりません。 これは、n回関連メッセージを暗号化することを伴います、各秘密鍵がKDCと対応する受信機の間で共有されている一度(あるいはまた、受信機の公開鍵、)、マルチキャスティングの前、それ、グループに。 (あるいはまた、KDCは個別にそれぞれの受信機に暗号化メッセージを送ることができましたが、これは比例しません。) 潜在的に、nは非常に大きいかもしれません。 KDCの秘密鍵(1秘密の公開鍵組の)によって主要なグループを暗号化するのは、オプションではありません、公開鍵がだれにとっても、グループキーがKDCの公開鍵を保持するのにおいてアクセスしやすいだろう、よく知られるか、または容易に利用可能であるので。 要するに、既存のマルチキャスト主要な分配メソッドは比例しません。
Ballardie Experimental [Page 4] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[4ページ]RFC1949
The scaling problem of secure multicast key distribution is compounded for the case where sender-specific keys need to be distributed to a group. This is required for sender-specific authentication of data traffic. It is not possible to achieve per- sender authentication, given only a group session key.
安全なマルチキャスト主要な分配のスケーリング問題は送付者特有のキーがグループに分配される必要があるケースのために悪化します。 これがデータ通信量の送付者特有の認証に必要です。 それが達成するのにおいて可能でない、-、グループだけにセッション主要な状態で与えられた送付者認証。
Recently a proposal has emerged, called the Group Key Management Protocol (GKMP) [15]. This was designed for military networks, but the authors have demonstrated how the architecture could be applied to a network like the Internet, running receiver-oriented multicast applications.
最近、Group Key Managementプロトコル(GKMP)[15]と呼ばれて、提案は現れました。 これはミリタリー・ネットワークのために設計されましたが、作者はどうインターネットのようなネットワークにアーキテクチャを適用できたかを示しました、受信機指向のマルチキャストアプリケーションを実行して。
GKMP goes a considerable way to addressing the problems of multicast key distribution: it does not rely on a centralised KDC, but rather places the burden of key management on a group member(s). This is the approach adopted by the CBT solution, but our solution can take this distributed approach further, which makes our scheme that much more scalable. Furthermore, our scheme is relatively simple.
GKMPはマルチキャストの主要な分配のその問題を訴えるのにかなりの道で行きます: それは、集中化されたKDCを当てにしませんが、むしろグループのメンバーにかぎ管理の負担をかけます。 これはCBTソリューションによって取られたアプローチです、しかし、私たちのソリューションがさらにこの分散型アプローチを取ることができます(私たちの体系をスケーラブルなそのさらに多くにします)。 その上、私たちの体系は比較的簡単です。
The CBT model for multicast key distribution is unique in that it is integrated into the CBT multicast protocol itself. It offers a simple, low-cost, scalable solution to multicast key distribution. We describe the CBT multicast key distribution approach below.
それがCBTマルチキャストプロトコル自体と統合されるので、マルチキャストの主要な分配のためのCBTモデルはユニークです。 それは簡単で、安価の、そして、スケーラブルなソリューションをマルチキャストの主要な分配に提供します。 私たちは以下でのCBTのマルチキャストの主要な分配アプローチについて説明します。
5. Multicast Security Associations
5. マルチキャストセキュリティ協会
The IP security architecture [2] introduces the concept of "Security Associations" (SAs), which must be negotiated in advance during the key management phase, using a protocol such as Photuris [20], or ISAKMP [21]. A Security Association is normally one-way, so if two- way communication is to take place (e.g. a typical TCP connection), then two Security Associations need to be negotiated. During the negotiation phase, the destination system normally assigns a Security Parameter Index to the association, which is used, together with the destination address (or, for the sender, the sender's user-id) to index into a Security Association table, maintained by the communicating parties. This table enables those parties to index the correct security parameters pertinent to an association. The security association parameters include authentication algorithm, algorithm mode, cryptographic keys, key lifetime, sensitivity level, etc.
IPセキュリティー体系[2]はあらかじめかぎ管理段階の間、交渉しなければならない「セキュリティ協会」(SAs)の概念を紹介します、Photuris[20]、またはISAKMP[21]などのプロトコルを使用して。 Security Associationが通常一方向であるので、コミュニケーションが2つの方法で行われるつもりであるなら(例えば、典型的なTCP接続)、2Security Associationsが、交渉される必要があります。 交渉段階の間、通常、目的地システムは協会にSecurity Parameter Indexを配属します。(それは、交信パーティーによって維持されたSecurity Associationテーブルに索引をつけるのに送付先アドレス(または、送付者のための送付者のユーザID)と共に使用されます)。 このテーブルは、それらのパーティーが協会に適切な正しいセキュリティパラメタに索引をつけるのを可能にします。 セキュリティ協会パラメタは認証アルゴリズム、アルゴリズムモード、暗号化キー、主要な生涯、感度レベルなどを含んでいます。
The establishment of Security Associations (SA) for multicast communication does not scale using protocols like Photuris, or ISAKMP. This is why it is often assumed that a multicast group will be part of a single Security Association, and hence share a single SPI. It is assumed that one entity (or a pair of entities) creates the SPI "by some means" (which may be an SA negotiation protocol,
マルチキャストコミュニケーションがプロトコルを使用することで比例しないで、Security Associations(SA)の設立はPhoturis、またはISAKMPが好きです。 これはしばしばマルチキャストグループが独身のSecurity Associationの一部であり、したがって、独身のSPIを共有すると思われる理由です。 1つの実体(または、1組の実体)が「どうでも」SPIを作成すると思われます。(どれがSA交渉であるかもしれないかは議定書を作ります。
Ballardie Experimental [Page 5] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[5ページ]RFC1949
like [20] and [21]), which is then simply multicast, together with the SA parameters, to the group for subsequent use. However, this precludes multicast receivers from performing sender-specific origin authentication; all a receiver can be sure of is that the sender is part of the multicast Security Association.
[20]と[21])のように。(次に、[21])はその後の使用のためのグループへのSAパラメタと共に単にマルチキャストです)。 しかしながら、これは送付者特有の発生源認証を実行するので、マルチキャスト受信機を排除します。 受信機が確かである場合があるすべては送付者がマルチキャストSecurity Associationの一部であるということです。
We advocate that the primary core, either alone, or in conjunction with the group initiator, establish the security parameters to be used in the group communication. These are distributed as part of the secure join process. Thereafter, individual senders can distribute their own key and security parameters to the group. In the case of the latter, there are two cases to consider:
私たちはプライマリ単独のコアかグループの創始者に関連してそれについて提唱して、セキュリティパラメタを確立して、グループコミュニケーションで使用されてください。 安全の一部がプロセスを接合するとき、これらは分配されています。 その後、個々の送付者はそれら自身のキーとセキュリティパラメタをグループに分配できます。 後者の場合には、考える2つのケースがあります:
+ the sender is already a group member. In this case, the sender
can decide upon/generate its own security parameters, and multi-
cast them to the group using the current group session key.
+ 送付者は既にグループのメンバーです。 この場合、送付者は、現在のグループセッションキーを使用することでそれ自身のセキュリティパラメタの、そして、マルチキャストのそれらをグループに決めるか、または生成することができます。
+ the sender is not a group member. In this case, before the
sender begins sending, it must first negotiate the security
parameters with the primary core, using a protocol such as Pho-
turis [20] or ISAKMP [21]. Once completed, the primary core
multicasts (securely) the new sender's session key and security
parameters to the group.
+ 送付者はグループのメンバーではありません。 この場合、送付者が発信し始める前に最初にプライマリコアとセキュリティパラメタを交渉しなければなりません、Pho- turis[20]かISAKMP[21]などのプロトコルを使用して。 いったん完成されると、予備選挙は新しい送付者のセッションが合わせるマルチキャスト(しっかりと)とセキュリティパラメタのグループに芯を取ります。
Given that we assume the use of asymmetric cryptotechniques throughout, this scheme provides a scalable solution to multicast origin authentication.
私たちがあらゆる点で非対称のcryptotechniquesの使用を仮定するなら、この体系はマルチキャスト発生源認証にスケーラブルな解決法を提供します。
Sender-specific keys are also discussed in section 8.
また、セクション8で送付者特有のキーについて議論します。
6. The CBT Multicast Key Distribution Model
6. CBTのマルチキャストの主要な分配モデル
The security architecture we propose allows not only for the secure joining of a CBT multicast tree, but also provides a solution to the multicast key distribution problem [16]. Multicast key distribution is an optional, but integral, part of the secure tree joining process; if a group session key is not required, its distribution may be omitted.
CBTマルチキャスト木の安全な接合でないののためだけに許容しますが、また、私たちが提案するセキュリティー体系はマルチキャストの主要な分配問題[16]に解決法を提供します。 マルチキャストの主要な分配は安全な木の接合プロセスの任意の、しかし、不可欠の部分です。 グループセッションキーは必要でないなら、分配が省略されるかもしれません。
The use of CBT for scalable multicast key distribution does not preclude the use of other multicast protocols for the actual multicast communication. CBT could be used solely for multicast key distribution -- any multicast protocol could be used for the actual multicast communication itself.
CBTのスケーラブルなマルチキャスト主要な分配の使用は他のマルチキャストプロトコルの実際のマルチキャストコミュニケーションの使用を排除しません。 唯一マルチキャストの主要な分配にCBTを使用できました--実際のマルチキャストコミュニケーション自体にどんなマルチキャストプロトコルも使用できました。
The model that we propose does not rely on the presence of a centralised KDC -- indeed, the KDC we propose need not be dedicated to key distribution. We are proposing that each group have its own
私たちが提案するモデルは集中化されたKDCの存在を当てにしません--本当に、私たちが提案するKDCは主要な分配に捧げられる必要はありません。 私たちは、各グループにはそれ自身のものがあるよう提案しています。
Ballardie Experimental [Page 6] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[6ページ]RFC1949
group key distribution centre (GKDC), and that the functions it provides should be able to be "passed on" to other nodes as they join the tree. Hence, our scheme involves truly distributed key distribution capability, and is therefore scalable. It does not require dedicated KDCs. We are proposing that a CBT primary core initially take on the role of a GKDC.
主要な分配センター(GKDC)を分類してください。そうすれば、それが提供する機能がそれらのように他のノードに「進むことができるべきであること」が木に合流します。 したがって、私たちの体系は、本当に、分配された主要な分配能力にかかわって、したがって、スケーラブルです。 それは専用KDCsを必要としません。 私たちは、CBTのプライマリコアが初めはGKDCの役割を引き受けるよう提案しています。
6.1 Operational Overview
6.1 操作上の概要
When a CBT group is created, it is the group initiator's responsibility to create a multicast group access control list (ACL) [14]. It is recommended that this list is a digitally signed "document", the same as (or along the lines of) an X.509 certificate [9], such that it can be authenticated. The group initiator subsequently unicasts the ACL to the primary core for the group. This communication is not part of the CBT protocol. The ACL's digital signature ensures that it cannot be modified in transit without detection. If the group membership itself is sensitive information, the ACL can be additionally encrypted with the public key of the primary core before being sent. The ACL can be an "inclusion" list or an "exclusion" list, depending on whether group membership includes relatively few, or excludes relatively few.
CBTグループが創設されるとき、マルチキャストグループアクセスコントロールリスト(ACL)[14]を作成するのは、グループの創始者の責任です。 このリストがデジタルに署名している「ドキュメント」であることはお勧めです、同じである、(系列、)、X.509証明書[9](それを認証できるようなもの) 次に、創始者を分類してください。予備選挙へのACLがグループのために芯を取るユニキャスト。 このコミュニケーションはCBTプロトコルの一部ではありません。 ACLのデジタル署名は、検出なしでトランジットでそれを変更できないのを確実にします。 グループ会員資格自体が機密情報であるなら、送る前にプライマリコアの公開鍵でさらに、ACLを暗号化できます。 「包含」リストか「除外」リスト、依存がオンであったならACLがそうすることができる、比較的わずかな状態で会員資格インクルードを分類してください、除外、比較的わずかです。
The ACL described above consists of group membership (inclusion or exclusion) information, which can be at the granularity of hosts or users. How these granularities are specified is outside the scope of this document. Additionally, it may be desirable to restrict key distribution capability to certain "trusted" nodes (routers) in the network, such that only those trusted nodes will be given key distribution capability should they become part of a CBT delivery tree. For this case, an additional ACL is required comprising "trusted" network nodes.
上で説明されたACLはグループ会員資格(包含か除外)情報から成ります。(ホストかユーザの粒状にそれは、あることができます)。 このドキュメントの範囲の外にこれらの粒状がどう指定されるかがあります。 さらに、ネットワークで、ある「信じられた」ノード(ルータ)への主要な分配能力を制限するのは望ましいかもしれません、ものだけが、CBT配送木の一部になるなら主要な分配能力がノードに与えられると信じたように。 このような場合、追加ACLが、「信じられた」ネットワーク・ノードを包括しながら、必要です。
The primary core creates a session key subsequent to receiving and authenticating the message containing the access control list. The primary core also creates a key encrypting key (KEK) which is used for re-keying the group just prior to an old key exceeding its life- time. This re-keying strategy means that an active key is less likely to become compromised during its lifetime.
プライマリコアはアクセスコントロールリストを含むメッセージを受けて、認証するのにその後でセッションキーを作成します。 また、プライマリコアは、寿命時間を超えながら古いキーのすぐ前でグループを再合わせるのに使用されるキー(KEK)を暗号化しながら、キーを作成します。 この再の合わせる戦略は、アクティブなキーが生涯感染されるように、よりなりそうにないことを意味します。
The ACL(s), group key, and KEK are distributed to secondary cores as they become part of the distribution tree.
分配木の一部になるとき、ACL(s)、グループキー、およびKEKはセカンダリコアに分配されます。
Any tree node with this information can authenticate a joining member, and hence, secure tree joining and multicast session key distribution are truly distributed across already authenticated tree nodes.
この情報があるどんな木のノードも接合メンバーを認証できます、そして、したがって、本当に、安全な木の接合とマルチキャストのセッションの主要な分配は既に認証された木のノードの向こう側に広げられます。
Ballardie Experimental [Page 7] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[7ページ]RFC1949
6.2 Integrated Join Authentication and Multicast Key Distribution
統合された6.2は認証とマルチキャストの主要な分配に参加します。
For simplicity, in our example we assume the presence of an internetwork-wide asymmetric key management scheme, such as that proposed in [17]. However, we are not precluding the use of symmetric cryptographic techniques -- all of the security services we are proposing, i.e. integrity, authentication, and confidentiality, can all be achieved using symmetric cryptography, albeit a greater expense, e.g. negotiation with a third party to establish pairwise secret keys. For these reasons, we assume that a public (asymmetric) key management scheme is globally available, for example, through the Domain Name System (DNS) [17] or World Wide Web [18].
簡単さのために、例では、私たちはインターネットワーク全体の非対称のかぎ管理体系の存在を仮定します、[17]で提案されたそれなどのように。 しかしながら、私たちは左右対称の暗号のテクニックの使用を排除していません--左右対称の暗号を使用することで私たちが提案しているセキュリティー・サービスのすべて(すなわち、保全、認証、および秘密性)をすべて達成できます、より大きい費用ですが、例えば、対状秘密鍵を設立する第三者との交渉。 これらの理由で、私たちは、公共(非対称の)のかぎ管理体系が例えばドメインネームシステム(DNS)[17]かWorld Wide Web[18]を通してグローバルに利用可能であると思います。
NOTE: given the presence of asymmetric keys, we can assume digital signatures provide integrity and origin authentication services combined.
以下に注意してください。 非対称のキーの存在を考えて、私たちは、デジタル署名が結合された保全と発生源認証サービスを提供すると思うことができます。
The terminology we use here is described in Appendix A. We formally define some additional terms here:
私たちがここで使用する用語はWeがいくつかの追加期間、ここで正式に定義するAppendix A.で説明されます:
+ grpKey: group key used for encrypting group data traffic.
+ grpKey: グループキーは、グループ・データを暗号化するのにトラフィックを使用しました。
+ ACL: group access control list.
+ ACL: アクセスコントロールリストを分類してください。
+ KEK: key encrypting key, used for re-keying a group with a new
group key.
+ KEK: グループを再合わせるのに、新しいグループキーで主要で、中古の主要な暗号化。
+ SAparams: Security Association parameters, including SPI.
+ SAparams: SPIを含むセキュリティAssociationパラメタ。
+ group access package (grpAP): sent from an already verified tree
node to a joining node.
+ グループアクセスパッケージ(grpAP): 既に確かめられた木のノードから接合ノードまで発信しました。
[token_sender, [ACL]^SK_core, {[grpKey, KEK,
SAparams]^SK_core}^PK_origin-host,
{[grpKey, KEK, SAparams]^SK_core}^PK_next-hop]^SK_sender
[トークン_送付者、[ACL]^SK_コア、[grpKey、KEK、SAparams]^SK_コア^PK_発生源ホスト、[grpKey、KEK、SAparams]^SK_コア^PK_次ホップ] ^SK_送付者
NOTE: SK_core is the secret key of the PRIMARY core.
以下に注意してください。 SK_コアはPRIMARYコアの秘密鍵です。
As we have already stated, the elected primary core of a CBT tree takes on the initial role of GKDC. In our example, we assume that a group access control list has already been securely communicated to the primary core. Also, it is assumed the primary core has already participated in a Security Association estabishment protocol [20,21], and thus, holds a group key, a key-encrypting key, and an SPI.
私たちが既に述べたように、CBT木の選出されたプライマリコアはGKDCの初期の役割を引き受けます。 例では、私たちは、グループアクセスコントロールリストが既にしっかりとプライマリコアに伝えられたと思います。 また、プライマリコアが既にSecurity Association estabishmentプロトコル[20、21]に参加して、その結果、グループキー、キーを暗号化するキー、およびSPIを保持すると思われます。
NOTE, there is a minor modification required to the CBT protocol
[4], which is as follows: when a secondary core receives a join,
instead of sending an ack followed by a re-join to the primary,
注意、以下の通りであるCBTプロトコル[4]に必要である小さい方の変更があります: セカンダリコアがaを受けたら接合してください、そして、aがあとに続いたackを送ることの代わりに予備選挙に再接合してください。
Ballardie Experimental [Page 8] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[8ページ]RFC1949
the secondary forwards the join to the primary; the ack travels
from the primary (or intermediate on-tree router) back to the join
origin. All routers (or only specific routers) become GKDCs after
they receive the ack.
セカンダリフォワード、予備選挙につないでください。 ackがプライマリ(または、木の上の中間的ルータ)の後部から旅行する、発生源を接合してください。 彼らがackを受けた後にすべてのルータ(または、特定のルータだけ)がGKDCsになります。
We now demonstrate, by means of an example, how CBT routers join a tree securely, and become GKDCs. For clarity, in the example, it is assumed all routers are authorised to become GKDCs, i.e. there is no trusted-router ACL.
私たちは現在、例によってCBTルータがしっかりと木に合流して、どうGKDCsになるかを示します。 明快において、例では、すべてのルータがGKDCsになるのが認可されると思われて、すなわち、信じられたルータACLが全くありません。
In the diagram below, only one core (the primary) is shown. The process of a secondary joining the primary follows exactly what we describe here.
以下のダイヤグラムで、1つのコア(予備選挙)だけが示されます。 予備選挙に加わる2番目のプロセスはまさに私たちがここで説明することに続きます。
In the diagram, host h wishes to join multicast group G. Its local multicast router (router A) has not yet joined the CBT tree for the group G.
ダイヤグラムには、Itsの地方のマルチキャストルータ(ルータA)が持っているマルチキャストグループG.に加わるというホストh願望はグループGのためにまだCBT木に合流していませんでした。
b b b-----b
\ | |
\ | |
b---b b------b
/ \ / KEY....
/ \/
b C C = Core (Initial Group Key Dist'n Centre)
/ \ A, B, b = non-core routers
/ \
/ \ ======= LAN where host h is located
B b------b
\
\ NOTE: Only one core is shown, but typically
host h A a CBT tree is likely to comprise several.
o |
=====================
b b b-----b\| | \ | | b---b b------b/\/KEY… /\/b C C=コア(初期のGroup Key Dist'n Centre)/\A、B、bは中核でないルータ/\/\と等しいです。======= ホストhが見つけられたB bであるLAN------b\\注意: あるコアだけが示されますが、通常、ホストh A a CBT木が数個を包括しそうである、o| =====================
Figure 1: Example of Multicast Key Distribution using CBT
図1: CBTを使用するマルチキャストの主要な分配に関する例
A branch is created as part of the CBT secure tree joining process, as follows:
ブランチは以下の通りCBTの安全な木の接合プロセスの一部として創設されます:
+ Immediately subsequent to a multicast application starting up on
host h, host h immediately sends an IGMP group membership
report, addressed to the group. This report is not suppressible
(see Appendix B), like other IGMP report types, and it also
includes the reporting host's token, which is digitally signed
+、すぐに、ホストhで始動するマルチキャストアプリケーションにその後です、ホストhはすぐに、グループに扱われたIGMPグループ会員資格レポートを送ります。 このレポートはsuppressible(Appendix Bを見る)ではありません、他のIGMPがタイプを報告して、また、報告しているホストのトークン(デジタルに署名される)を含んでいるように
h --> DR (A): [[token_h]^SK_h, IGMP group membership report]
h-->DR(A): [トークン_h]^SK_h、IGMPグループ会員資格レポート]
Ballardie Experimental [Page 9] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[9ページ]RFC1949
(A host's token differs in two respects compared with tokens
defined in [9]. To refresh, a token assists a recipient in the
verification process, and typically contains: recipient's
unique identity, a timestamp, and a pseudo-random number. A
token is also usually digitally signed by its originator.
Firstly, A host's token does not contain the intended
recipient's identity, since this token may need to traverse
several CBT routers before reaching a GKDC. A host does not
actually know which router, i.e. GKDC, will actually
acknowledge the join that it invoked. Secondly, the host's
token is digitally signed -- this is usual for a token.
However, tokens generated by routers need not be explicitly
digitally signed because the JOIN-REQUESTs and JOIN-ACKs that
carry them are themselves digitally signed.)
( リフレッシュするために9で定義されるトークンと比べて、ホストのトークンが2つの点において異なって、トークンは、検証プロセスに受取人を助けて、: 受取人のユニークなアイデンティティ、タイムスタンプ、および擬似乱数を通常含んでいます。また、通常、トークンは創始者によってデジタルに署名されます。まず第一に、Aホストのトークンは意図している受取人のアイデンティティを含みません; 以来に、このトークンは、GKDCに達する前にいくつかのCBTルータを横断する必要があるかもしれません。接合してください。. 第二にホストのトークンを呼び出したのはデジタルに署名されます--トークンに、これは普通です。ホストが、どのルータ(すなわち、GKDC)が実際に承認するかを実際に知らない、彼らを運ぶJOIN-REQUESTsとJOIN-ACKsがデジタルに署名されるので、しかしながら、ルータによって生成されたトークンは明らかにデジタルに署名される必要はありません; )
+ In response to receiving the IGMP report, the local designated
router (router A) authenticates the host's enclosed token. If
successful, router A formulates a CBT join-request, whose target
is core C (the primary core). Router A includes its own token in
the join, as well as the signed token received from host h. The
join is digitally signed by router A.
+ 受信に対応したIGMPは報告して、地方の代表ルータ(ルータA)はホストの同封のトークンを認証します。 うまくいく、Aが定式化するルータ、CBT、要求に参加する、目標がコアCである(プライマリコア)。 ルータAがそれ自身のトークンを含んでいる、ホストhから受け取られた署名しているトークンと同様に、接合してください。 接合してください。ルータAであるとデジタルに署名されます。
NOTE 1: router A, like all CBT routers, is configured with the
unicast addresses of a prioritized list of cores, for different
group sets, so that joins can be targeted accordingly.
注意1: すべてのCBTルータのように、ルータAはユニキャストによって構成されて、それが異なったグループセットのためのコア接合して、最優先するリストのアドレスがそれに従って、狙うことができるということです。
NOTE 2: the host token is authenticated at most twice, once by
the host's local CBT router, and once by a GKDC. If the local
router is already a GKDC, then authentication only happens once.
If the local router is not already a GKDC, a failed authentica-
tion check removes the overhead of generating and sending a CBT
join-request.
注意2: ホストトークンは高々二度一度GKDCによる一度ホストの地方のCBTルータによって認証されます。 ローカルルータが既にGKDCであるなら、認証は一度起こるだけです。 失敗したauthentica- tionチェックがローカルルータが既にGKDCでないなら、生成するのと送付のオーバーヘッドを取り除く、CBT、要求に参加します。
Router A unicasts the join to the best next-hop router on the
path to core C (router B).
ルータAユニキャスト、コアC(ルータB)への経路で最も良い次のホップルータにつないでください。
A --> B: [[token_A], [token_h]^SK_h, JOIN-REQUEST]^SK_A
A-->B: [[トークン_h]^SK_hの、そして、要求に参加している[トークン]] ^SK
+ B authenticates A's join-request. If successful, B repeats the
previous step, but now the join is sent from B to C (the pri-
mary, and target), and the join includes B's token. Host h's
token is copied to this new join.
+ Bは要求に参加する状態でAのものを認証します。 そして、うまくいって、Bが現在前のステップを繰り返すかどうか、接合、BからC(pri- mary、および目標)に送る、インクルードビーズトークンを接合してください。 hのトークンがこれほど新しくコピーされるホストは加わります。
B --> C: [[token_B], [token_h]^SK_h, JOIN-REQUEST]^SK_B
B-->C: [トークン_B]、[トークン_h]^SK_hと、要求に参加します]の^SK_B
+ C authenticates B's join. As the tree's primary authorization
point (and GKDC), C also authenticates host h, which triggered
the join process. For this to be successful, host h must be
+Cはビーズを認証します。接合してください。 また、木のプライマリ承認ポイント(そして、GKDC)として、Cがホストhを認証する、どれ、引き金となるか、プロセスを接合してください。 ホストhは、これがうまくいっているためには、そうでなければなりません。
Ballardie Experimental [Page 10] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[10ページ]RFC1949
included in the GKDC's access control list for the group. If h
is not in the corresponding access control list, authentication
is redundant, and a join-nack is returned from C to B, which
eventually reaches host h's local DR, A.
グループのためのGKDCのアクセスコントロールリストでは、含まれています。 対応するアクセスコントロールリストにhがないなら、認証は余分です、そして、CからBまで-nackに接合しているaを返します。(それは、結局、ホストhの地方のDR(A)に達します)。
Assuming successful authentication of B and h, C forms a group
access package (grpAP), encapsulates it in a join-ack, and digi-
tally signs the complete message. C's token, host h's signed
token, a signed ACL, and two (group key, KEK) pairs are included
in the group access package; one for the originating host, and
one for the next-hop CBT router to which the join-ack is des-
tined. Each key pair is digitally signed by the issuer, i.e. the
primary core for the group. The host key pair is encrypted using
the public key of the originating host, so as to be only deci-
pherable by the originating host, and the other key pair is
encrypted using the public key of the next-hop router to which
the ack is destined -- in this case, B. Host h's token is used
by the router connected to the subnet where h resides so as to
be able to identify the new member.
Bとhのうまくいっている認証(グループアクセスがパッケージするCフォーム(grpAP))がackを接合して、digi合札でそれをカプセル化すると仮定するのが完全なメッセージに署名します。 署名しているCのトークン、ホストhの署名しているトークン、ACL、および2(キーを分類してください、KEK)組はグループアクセスパッケージに含まれています。 ackを接合するのが、des- tinedである送信元ホストのためのもの、および次のホップCBTルータのためのもの。 それぞれの主要な組はすなわち、発行人、グループのためのプライマリコアによってデジタルに署名されます。 もう片方の主要な組はackが運命づけられている次のホップルータの公開鍵を使用することで暗号化されています--ホスト重要組はデシpherableであるだけでありなるように送信元ホストの公開鍵を使用することで送信元ホストによって暗号化されています、そして、この場合、B.Host hのトークンはhが新しいメンバーを特定できるように住んでいるところでサブネットに関連づけられたルータによって使用されます。
C --> B: [[token^h]^SK_h, grpAP, JOIN-ACK]^SK_C
C-->B: [grpAPの、そして、ACKを接合している[トークン^h]^SK_h] ^SK_C
+ B authenticates the join-ack from C. B extracts its encrypted
key pair from the group access package, decrypts it, authenti-
cates the primary core, and stores the key pair in encrypted
form, using a local key. B also verifies the digital signature
included with the access control list. It subsequently stores
the ACL in an appropriate table. The originating host key pair
remains enciphered.
+ Bは、C.からackを接合するのを認証します。Bは、グループアクセスパッケージから暗号化された主要な組を抽出して、それを解読して、authenti美味はプライマリコアであり、店は暗号化されたフォームでの主要な組です、地方のキーを使用して。 また、Bはアクセスコントロールリストで含まれていたデジタル署名について確かめます。 それは次に、適切なテーブルにACLを保存します。 送信元ホスト主要な組は暗号化されたままで残っています。
The other copy of router B's key pair is taken and deciphered
using its secret key, and immediately enciphered with the public
key of next-hop to which a join-ack must be passed, i.e. router
A. A group access package is formulated by B for A. It contains
B's token, the group ACL (which is digitally signed by the pri-
mary core), a (group key, KEK) pair encrypted using the public
key of A, and the originating host's key pair, already
encrypted. The group access package is encapsulated in a join-
ack, the complete message is digitally signed by B, then for-
warded to A.
もう片方のコピーのルータビーズ主要な組は、秘密鍵を使用することで取られて、解読されて、すぐに-ackに接合しているaを通過しなければならない次のホップの公開鍵で暗号化されます、すなわち、ルータA.AグループアクセスパッケージはA.のためにBによって定式化されます。Itはビーズトークン(ACL(pri- maryコアによってデジタルに署名されます)(Aの公開鍵、および送信元ホストの主要な組を使用することで暗号化されなかったa(キーを分類してください、KEK))が既に暗号化したグループ)を含んでいます。 アクセスパッケージがaでカプセル化されるグループはackに合流して、完全なメッセージはBによってデジタルに署名されます、そして-、Aに避けられます。
B --> A: [[token^h]^SK_h, grpAP, JOIN-ACK]^SK_B
B-->A: [grpAPの、そして、ACKを接合している[トークン^h]^SK_h] ^SK_B
+ A authenticates the join-ack received from B. A copy of the
encrypted key pair that is for itself is extracted from the
group access package and deciphered, and the key issuer (primary
core) is authenticated. If successful, the enciphered key pair
is stored by A. The digital signature of the included access
+ Aは、ackを接合するのをB.から受け取られる認証します。それ自体に賛成する暗号化された主要な組のAコピーは、グループアクセスパッケージから抽出されて、解読されます、そして、主要な発行人(プライマリコア)は認証されます。 うまくいくなら、暗号化された主要な組はA. 含まれているアクセスのデジタル署名で保存されます。
Ballardie Experimental [Page 11] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[11ページ]RFC1949
control list is also verified, and stored in an appropriate
table. The key pair encrypted for host h is extracted from the
group access package, and is forwarded directly to host h, which
is identified from the presence of its signed token. On
receipt, host h decrypts the key pair for subsequent use, and
stores the SA parameters in its SA table.
コントロールリストは、適切なテーブルにまた、確かめられて、保存されます。 ホストhのために暗号化された主要な組を、グループアクセスパッケージから抽出して、直接ホストhに送ります。(そのホストは、署名しているトークンの存在から特定されます)。 領収書の上では、ホストhは、その後の使用のために主要な組を解読して、SAテーブルにSAパラメタを保存します。
A --> h: [[token^h]^SK_h, {grpKey, KEK, SAparams}^PK_h]
A-->h: [トークン^h]^SK_h、grpKey、KEK、SAparams、^PK_h]
Going back to the initial step of the tree-joining procedure, if the DR for the group being joined by host h were already established as part of the corresponding tree, it would already be a GKDC. It would therefore be able to directly pass the group key and KEK to host h after receiving an IGMP group membership report from h:
ホストhによって加わられるグループのためのDRが対応する木の一部と既に書き立てられたなら木に合流する手順の初期段階に戻って、それは既にGKDCでしょう。 したがって、hからIGMPグループ会員資格レポートを受け取った後に、それは直接グループキーとKEKをホストhに渡すことができるでしょう:
A --> h: [[token^h]^SK_h, {grpKey, KEK, SAparams}^PK_h]
A-->h: [トークン^h]^SK_h、grpKey、KEK、SAparams、^PK_h]
If paths, or nodes fail, a new route to a core is gleaned as normal from the underlying unicast routing table, and the re-joining process (see [4]) occurs in the same secure fashion.
コアへの新しいルートは経路、またはノードやり損ないであるなら、標準として基本的なユニキャスト経路指定テーブル、および再接合プロセスから収集されます。([4])が同じ安全なファッションで起こるのを確実にしてください。
7. A Question of Trust
7. 信頼の問題
The security architecture we have described, involving multicast key distribution, assumes that all routers on a delivery tree are trusted and do not misbehave. A pertinent question is: is it reasonable to assume that network routers do not misbehave and are adequately protected from malicious attacks?
マルチキャストの主要な分配にかかわって、私たちが説明したセキュリティー体系は配送木の上のすべてのルータが信じられて、ふらちな事をするというわけではないと仮定します。 適切な質問は以下の通りです。 ネットワークルータがふらちな事をしないで、悪意ある攻撃から適切に保護されると仮定するのは妥当ですか?
Many would argue that this is not a reasonable assumption, and therefore the level of security should be increased to discount the threat of misbehaving routers. As we described above, routers periodically decrypt key pairs in order to verify them, and/or re- encrypt them to pass them on to joining neighbour routers.
多くが、これが妥当な想定でないと主張するでしょう、そして、したがって、セキュリティのレベルは、ふらちな事するルータの脅威を無視するために増強されるべきです。 私たちが上で説明したように、ルータは、彼らについて確かめるために定期的に主要な組を解読する、そして/または、隣人ルータを接合するのに彼らを通過するために彼らを再暗号化します。
In view of the above, we suggest that if more stringent security is required, the model we presented earlier should be slightly amended to accommodate this requirement. However, depending on the security requirement and perceived threat, the model we presented may be acceptable.
上記から見て、私たちは、より厳しいセキュリティが必要であるなら、私たちが、より早く提示したモデルがこの要件を収容するためにわずかに修正されるべきであると示唆します。 しかしながら、セキュリティ要件と知覚された脅威によって、私たちが提示したモデルは許容できるかもしれません。
We recommend the following change to the model already presented above, to provide a higher level of security:
私たちは、以下が、より高いレベルのセキュリティを提供するために上に既に提示されたモデルに変化することを勧めます:
All join-requests must be authenticated by a core router, i.e. a join arriving at an on-tree router must be forwarded upstream to a core if the join is identified as being a "secure" join (as indicated by the presence of a signed host token).
接合してください。すべての要求に参加している必須がコアルータによって認証されて、すなわち、aがaへの進められた上流がコアであったに違いないなら木の上のルータに到着しながら接合する、「安全」であることが接合するとき(署名しているホストトークンの存在によって示されるように)、特定されます。
Ballardie Experimental [Page 12] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[12ページ]RFC1949
The implication of this is that key distribution capability remains with the core routers and is not distributed to non-core routers whose joins have been authenticated. Whilst this makes our model somewhat less distributed than it was before, the concept of key distribution being delegated to the responsibility of individual groups remains. Our scheme therefore retains its attractiveness over centralized schemes.
この含意が主要な分配能力がコアルータで残っていて、中核でないルータに分配されないということである、だれのもの、接合、認証されてください、そうした。 以前のそれよりこれで私たちのモデルをいくらか分配しませんが、個々のグループの責任へ代表として派遣される主要な分配の概念は残っています。 したがって、私たちの体系は集結された体系の上で魅力を保有します。
8. The Multicast Distribution of Sender-Specific Keys
8. 送付者特有のキーのマルチキャスト分配
Section 5, in part, discussed the scalable distribution of sender- specific keys and sender-specific security parameters to a multicast group, for both member-senders, and non-member senders. If asymmetric cryptotechniques are employed, this allows for sender-specific origin authentication.
セクション5は送付者の特定のキーと送付者特有のセキュリティパラメタのスケーラブルな分配についてマルチキャストグループに一部論じました、メンバー送付者と非会員送付者の両方のために。 非対称のcryptotechniquesが採用しているなら、これは送付者特有の発生源認証を考慮します。
For member-senders, the following message is multicast to the group, encrypted using the current group session key, prior to the new sender transmitting data:
メンバー送付者にとって、以下のメッセージは現在のグループセッションキーを使用することで暗号化されたグループへのデータを送る新しい送付者の前のマルチキャストです:
{[sender_key, senderSAparams]^SK_sender}^group_key
[送付者_キー、senderSAparams]^SK_送付者^グループ_キー
Non-member senders must first negotiate (e.g. using Photuris or ISAKMP) with the primary core, to establish the security association parameters, and the session key, for the sender. The sender, of course, is subject to access control at the primary. Thereafter, the primary multicasts the sender-specific session key, together with sender's security parameters to the group, using the group's current session key. Receivers are thus able to perform origin authentication.
非会員送付者は、最初に、セキュリティ協会パラメタ、および送付者にとって、主要なセッションを証明するためにプライマリコアと交渉しなければなりません(例えば、PhoturisかISAKMPを使用します)。 送付者はもちろん予備選挙においてアクセスコントロールを受けることがあります。 その後、グループの現在のセッションキーを使用する送付者特有のセッションがグループへの送付者のセキュリティパラメタと共に合わせるプライマリマルチキャスト。 その結果、受信機は発生源認証を実行できます。
Photuris or ISAKMP
1. sender <----------------------> primary core
PhoturisかISAKMP1送付者<。---------------------->のプライマリコア
2. {[sender_key, senderSAparams]^SK_primary}^group_key
2. [送付者_キー、senderSAparams]^SK_予備選挙^グループ_キー
For numerous reasons, it may be desirable to exclude certain group members from all or part of a group's communication. We cannot offer any solution to providing this capability, other than requiring new keys to be distributed via the establishment of a newly-formed group (CBT tree).
多数の理由で、グループのコミュニケーションのすべてか一部に確信しているグループのメンバーを入れないようにするのは望ましいかもしれません。 私たちはこの能力を提供するのにどんなソリューションも提供できません、新しいキーが新たに形成されたグループ(CBT木)の設立を通して分配されるのが必要であるのを除いて。
Ballardie Experimental [Page 13] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[13ページ]RFC1949
9. Summary
9. 概要
This memo has offered a scalable solution to the multicast key distribution problem. Our solution is based on the CBT architecture and protocol, but this should not preclude the use of other multicast protocols for secure multicast communication subsequent to key distribution. Furthermore, virtually all of the functionality present in our solution is in-built in the secure version of the CBT protocol, making multicast key distribution an optional, but integral part, of the CBT protocol.
このメモはマルチキャストの主要な分配問題にスケーラブルなソリューションを提供しました。 私たちのソリューションはCBTアーキテクチャとプロトコルに基づいていますが、これは他のマルチキャストプロトコルの主要な分配へのその後の安全なマルチキャストコミュニケーションの使用を排除するべきではありません。 その上、私たちのソリューションにおける現在の機能性のほとんどすべてがCBTプロトコルの安全なバージョンで中で組立しています、マルチキャストの主要な分配をCBTプロトコルの任意の、しかし、不可欠の部分にして。
Ballardie Experimental [Page 14] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[14ページ]RFC1949
Appendix A
付録A
The following terminology is used throughout this document:
以下の用語はこのドキュメント中で使用されます:
+ PK_A indicates the public key of entity A.
+ PKは実体Aの公開鍵を示します。
+ SK_A indicates the secret key of entity A. The secret key can be
used by a sender to digitally sign a digest of the message,
which is computed using a strong, one-way hash function, such as
MD5 [19].
送付者はメッセージのダイジェストにデジタルに署名するのに秘密鍵を使用できます、MD5[19]などのように。+ SKは実体A.の秘密鍵を示します。メッセージは、強くて、一方向のハッシュ関数を使用することで計算されます。
+ Unencrypted messages will appear enclosed within square brack-
ets, e.g. [X, Y, Z]. If a message is digitally signed, a super-
script will appear outside the right hand bracket, indicating
the message signer. Encrypted messages appear enclosed within
curly braces, with a superscript on the top right hand side out-
side the closing curly brace indicating the encryption key, e.g.
{X, Y, Z}^{PK_A}.
+ Unencryptedメッセージは例えば、正方形の裂け目ets、[X、Y、Z]の中に同封されているように見えるでしょう。 メッセージがデジタルに署名されると、メッセージ署名者を示して、超スクリプトは右手のブラケットの外に現れるでしょう。 暗号化メッセージは巻き毛の支柱の中に同封されているように見えて、先端の上付き文字に、右手側アウトは暗号化キーを示す終わりの巻き毛の支柱、例えば、X、Y、Zに面があります。^PK。
+ a token is information sent as part of a strong authentication
exchange, which aids a receiver in the message verification pro-
cess. It consists of a timestamp, t (to demonstrate message
freshness), a random, non-repeating number, r (to demonstrate
message originality), and the unique name of the message
recipient (to demonstrate that the message is indeed intended
for the recipient). A digital signature is appended to the
token by the sender (which allows the recipient to authenticate
the sender). The token is as follows:
+ トークンはメッセージ検証親課税で受信機を支援する強い認証交換の一部として送られた情報です。 それはタイムスタンプ、t(メッセージの新しさを示す)、無作為の、そして、非反復している数、r(メッセージの独創性を示す)、およびメッセージ受取人のユニークな名前(本当に、メッセージが受取人のために意図するのを示す)から成ります。 デジタル署名は送付者(受取人は送付者を認証できる)によってトークンに追加されます。 トークンは以下の通りです:
[t_A, r_A, B]^{SK_A} -- token sent from A to B.
[t、r、B]^SK--トークンはAからBまで発信しました。
+ A --> B: -- denotes a message sent from A to B.
+ A-->B: -- AからBに送られたメッセージを指示します。
Appendix B
付録B
The group access controls described in this document require a few simple support mechanisms, which, we recommend, be integrated into version 3 of IGMP. This would be a logical inclusion to IGMP, given that version 3 is expected to accommodate a variety of multicast requirements, including security. Furthermore, this would remove the need for the integration of a separate support protocol in hosts.
本書では説明されたグループアクセス制御がいくつかの簡単なサポートメカニズムを必要とする、どれ、私たちは、IGMPのバージョン3と統合されるように勧めるか。 これはIGMPへの論理的な包含でしょう、バージョン3がさまざまなマルチキャスト要件を収容すると予想されるなら、セキュリティを含んでいて。 その上、これはホストの別個の支持体プロトコルの統合の必要性を取り除くでしょう。
To refresh, IGMP [8] is a query/response multicast support protocol that operates between a multicast router and attached hosts.
リフレッシュするために、IGMP[8]はマルチキャストルータと付属ホストの間で作動する質問/応答マルチキャストサポートプロトコルです。
Whenever an multicast application starts on a host, that host generates a small number of IGMP group membership reports in quick succession (to overcome potential loss). Thereafter, a host only
マルチキャストアプリケーションがホストを始めるときはいつも、そのホストは間断なく(潜在的損失を克服する)少ない数のIGMPグループ会員資格レポートを作ります。 その後、ホスト専用
Ballardie Experimental [Page 15] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[15ページ]RFC1949
issues a report in response to an IGMP query (issued by the local multicast router), but only if the host has not received a report for the same group (issued by some other host on the same subnet) before the host's IGMP random response timer expires. Hence, IGMP, incorporates a report "suppression" mechanism to help avoid "IGMP storms" on a subnet, and generally conserve bandwidth.
ホストのIGMPランダム応答タイマが期限が切れる前にホストが同じグループ(同じサブネットである他のホストによって発行される)のためのレポートを受け取っていない場合にだけ、IGMP質問(地方のマルチキャストルータで、発行される)に対応してレポートを発行します。 したがって、IGMP、サブネットで「IGMP嵐」を避けて、一般に、帯域幅を保存するのを助けるためにレポート「抑圧」メカニズムを組み込みます。
We propose that IGMP accommodate "secure joins" - IGMP reports that indicate the presence of a digitally signed host (or user) token. These report types must not be suppressible, as is typically the case with IGMP reports; it must be possible for each host to independently report its group presence to the local router, since a GKDC bases its group access control decision on this information.
私たちがそのIGMPを提案する、収容、「安全である、接合、」 --デジタルに署名しているホスト(または、ユーザ)トークンの存在を示すIGMPレポート。 通常、IGMPレポートに関してそうであるようにこれらのレポートタイプはsuppressibleであるはずがありません。 各ホストが独自にグループ存在をローカルルータに報告するのは、可能であるに違いありません、GKDCがグループアクセス制御決定をこの情報に基礎づけるので。
This functionality should not adversely affect backwards compatibility with earlier versions of IGMP that may be present on the same subnet; the new reports will simply be ignored by older IGMP versions, which thus continue to operate normally.
この機能性は後方に同じサブネットに存在するかもしれないIGMPの以前のバージョンとの互換性に悪影響を与えるべきではありません。 最新の報告は、より古いIGMPバージョンによって単に無視されるでしょう。(その結果、バージョンは通常、作動し続けています)。
Security Considerations
セキュリティ問題
Security issues are discussed throughout this memo.
このメモ中で安全保障問題について議論します。
Author's Address
作者のアドレス
Tony Ballardie, Department of Computer Science, University College London, Gower Street, London, WC1E 6BT, ENGLAND, U.K.
トニーBallardie、コンピュータサイエンス学部、ユニバーシティ・カレッジロンドン、ガウアー・ストリート、ロンドンWC1E 6BT、イギリスイギリス
Phone: ++44 (0)71 419 3462 EMail: A.Ballardie@cs.ucl.ac.uk
以下に電話をしてください。 + +44 3462がメールする(0)71 419: A.Ballardie@cs.ucl.ac.uk
References
参照
[1] MBONE, The Multicast BackbONE; M. Macedonia and D. Brutzman; available from http://www.cs.ucl.ac.uk/mice/mbone_review.html.
[1]MBONE、マルチキャストバックボーン。 M。 マケドニアとD.Brutzman。 http://www.cs.ucl.ac.uk/mice/mbone_review.html から、利用可能です。
[2] R. Atkinson. Security Architecture for the Internet Protocol; RFC 1825, SRI Network Information Center, August 1995.
[2] R.アトキンソン。 インターネットプロトコルのためのセキュリティー体系。 RFC1825、様のネットワーク情報センター、1995年8月。
[3] D. Estrin and G. Tsudik. An End-to-End Argument for Network Layer, Inter-Domain Access Controls; Journal of Internetworking & Experience, Vol 2, 71-85, 1991.
[3] D.EstrinとG.Tsudik。 ネットワーク層のための終わりから終わりへの議論、相互ドメインアクセス制御。 インターネットワーキングと経験、Vol2、71-85のジャーナル、1991。
Ballardie Experimental [Page 16] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[16ページ]RFC1949
[4] A. Ballardie, S. Reeve, N. Jain. Core Based Tree (CBT) Multicast - Protocol Specification; Work in Progress, 1996. Available from: ftp://cs.ucl.ac.uk/darpa/IDMR/draft-ietf-idmr-cbt-spec-XX.txt.
[4] A.Ballardie、S.奉行、N.ジャイナ教徒。 コアベースの木(CBT)のマルチキャスト--仕様を議定書の中で述べてください。 進歩、1996年に働いてください。 利用可能: ftp://cs.ucl.ac.uk/darpa/IDMR/draft-ietf-idmr-cbt-spec-XX.txt 。
[5] R. Atkinson. IP Authentication Header; RFC 1826, SRI Network Information Center, August 1995.
[5] R.アトキンソン。 IP認証ヘッダー。 RFC1826、様のネットワーク情報センター、1995年8月。
[6] R. Atkinson. IP Encapsulating Security Payload; RFC 1827, SRI Net- work Information Center, August 1995.
[6] R.アトキンソン。 セキュリティが有効搭載量であるとカプセル化するIP。 RFC1827、SRIネットは1995年8月にインフォメーション・センターを扱います。
[7] A. Ballardie. Core Based Tree (CBT) Multicast Architecture; Work in progress, 1996. Available from: ftp://cs.ucl.ac.uk/darpa/IDMR/draft-ietf-idmr-cbt-arch-XX.txt
[7] A.Ballardie。 コアは木(CBT)のマルチキャストアーキテクチャを基礎づけました。 進歩、1996年に働いてください。 利用可能: ftp://cs.ucl.ac.uk/darpa/IDMR/draft-ietf-idmr-cbt-arch-XX.txt
[8] W. Fenner. Internet Group Management Protocol, version 2 (IGMPv2), Work in progress, 1996.
[8] W.フェナー。 インターネットGroup Managementプロトコル、バージョン2(IGMPv2)、進行中のWork、1996。
[9] CCITT Data Communication Networks Directory (Blue Book). Recommen- dation X.509, Authentication Framework.
[9] CCITTデータ通信はディレクトリ(紳士録)をネットワークでつなぎます。 Recommen- dation X.509、Authentication Framework。
[10] T. Pusateri. Distance-Vector Multicast Routing Protocol (DVMRP) version 3. Working draft, February 1996.
[10] T.Pusateri。 ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル(DVMRP)バージョン3。 1996年2月の概要版。
[11] J. Moy. Multicast Extensions to OSPF; RFC 1584, SRI Network Information Center, March 1994.
[11] J.Moy。 OSPFへのマルチキャスト拡大。 RFC1584、様のネットワーク情報センター、1994年3月。
[12] D. Estrin et al. Protocol Independent Multicast, protocol specif- ication; Work in progress, January 1996.
[12] D.Estrin他 無党派Multicast、プロトコルspecifについて議定書の中で述べてください、。 進歩、1996年1月に、働いてください。
[13] R. Braden, D. Clark, S. Crocker and C. Huitema. Security in the Internet Architecture. RFC 1636, June 1994.
[13] R.ブレーデン、D.クラーク、S.クロッカー、およびC.Huitema。 インターネットアーキテクチャにおけるセキュリティ。 1994年6月のRFC1636。
[14] A. Ballardie and J. Crowcroft. Multicast-Specific Security Threats and Counter-Measures. In ISOC Symposium on Network and Distri- buted System Security, February 1995.
[14] A.BallardieとJ.クロウクロフト。 マルチキャスト特有の軍事的脅威と対応策。 NetworkとDistri- buted System Security、1995年2月のISOC Symposiumで。
[15] H. Harney, C. Muckenhirn, and T. Rivers. Group Key Management Protocol (GKMP) Architecture. Working draft, 1994.
[15] H.ハーニー、C.Muckenhirn、およびT.川。 グループ重要経営者側は(GKMP)アーキテクチャについて議定書の中で述べます。 概要版、1994。
[16] N. Haller and R. Atkinson. RFC 1704, On Internet Authentication. SRI Network Information Center, October 1994.
[16] N.ハラーとR.アトキンソン。 インターネット認証でのRFC1704。 1994年10月の様のネットワークインフォメーション・センター。
[17] C. Kaufman and D. Eastlake. DNS Security Protocol Extensions. Working draft, January 1996.
[17] C.コーフマンとD.イーストレーク。 DNSセキュリティは拡大について議定書の中で述べます。 1996年1月の概要版。
[18] T. Berners-Lee, R. Cailliau, A. Luotonen, H. Frystyk Nielsen, A. Secret. The World Wide Web. Communications of the ACM, 37(8):76-82, August 1994.
[18] T.バーナーズ・リー、R.Cailliau、A.Luotonen、H.Frystykニールセン、A.秘密。 WWW。 ACMに関するコミュニケーション、37(8): 76-82と、1994年8月。
Ballardie Experimental [Page 17] RFC 1949 Scalable Multicast Key Distribution May 1996
主要なマルチキャスト分配1996年5月にスケーラブルなBallardie実験的な[17ページ]RFC1949
[19] R. Rivest. RFC 1321, The MD-5 Message Digest Algorithm, SRI Net- work Information Center, 1992.
[19]、R. 最もRivest。 RFC1321、MD-5Message Digest Algorithmであり、SRIネットはインフォメーション・センター、1992を扱います。
[20] P. Karn, W. Simpson. The Photuris Session Key Management Proto- col; Working draft, January 1996.
[20] P.Karn、W.シンプソン。 Photuris Session Key Managementプロトあん部。 1996年1月の概要版。
[21] D. Maughan, M. Schertler. Internet Security Association and Key Management Protocol; Working draft, November 1995.
[21] D.Maughan、M.Schertler。 インターネットセキュリティ協会とKey Managementは議定書を作ります。 1995年11月の概要版。
Ballardie Experimental [Page 18]
Ballardie実験的です。[18ページ]
一覧
スポンサーリンク
