[要約] 要約：RFC 4563は、Multimedia Internet KEYing（MIKEY）の一般拡張ペイロードにおけるキーID情報タイプに関する仕様です。 目的：このRFCの目的は、MIKEYプロトコルで使用されるキーID情報タイプの定義と使用方法を提供することです。
Network Working Group E. Carrara
Request for Comments: 4563 KTH
Category: Standards Track V. Lehtovirta
K. Norrman
Ericsson
June 2006
The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)
マルチメディアインターネットキーイング（Mikey）の一般的な拡張ペイロードのキーID情報タイプ
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This memo specifies a new Type (the Key ID Information Type) for the General Extension Payload in the Multimedia Internet KEYing (MIKEY) Protocol. This is used in, for example, the Multimedia Broadcast/Multicast Service specified in the Third Generation Partnership Project.
このメモは、マルチメディアインターネットキーイング（Mikey）プロトコルの一般的な拡張ペイロードの新しいタイプ（キーID情報タイプ）を指定します。これは、たとえば、第3世代パートナーシッププロジェクトで指定されたマルチメディアブロードキャスト/マルチキャストサービスで使用されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Rationale .......................................................2
3. Relations to MIKEY and GKMARCH ..................................3
4. The Key ID Information Type for the General Extension Payload ...4
5. Empty Map Type Definition for the CS ID Map Type ................5
6. Transport Considerations ........................................5
7. Security Considerations .........................................5
8. IANA Considerations .............................................7
9. Acknowledgements ................................................7
10. References .....................................................8
10.1. Normative References ......................................8
10.2. Informative References ....................................8
The Third Generation Partnership Project (3GPP) is currently involved in the development of a multicast and broadcast service, the Multimedia Broadcast/Multicast Service (MBMS), and its security architecture [MBMS].
サードジェネレーションパートナーシッププロジェクト（3GPP）は現在、マルチキャストおよびブロードキャストサービス、マルチメディアブロードキャスト/マルチキャストサービス（MBMS）、およびそのセキュリティアーキテクチャ[MBMS]の開発に関与しています。
[MBMS] requires the use of the Multimedia Internet KEYing (MIKEY) Protocol [RFC3830] to convey the keys and related security parameters needed to secure multimedia that is multicast or broadcast.
[MBMS]では、マルチキャストまたはブロードキャストのマルチメディアを保護するために必要なキーと関連するセキュリティパラメーターを伝えるために、マルチメディアインターネットキーイング（Mikey）プロトコル[RFC3830]を使用する必要があります。
One of the requirements that MBMS puts on security is the ability to perform frequent updates of the keys. The rationale behind this is that it will be costly for subscribers to re-distribute the decryption keys to non-subscribers. The cost for re-distributing the keys using the unicast channel should be higher than the cost of purchasing the keys for this scheme to have an effect. To implement this, MBMS uses a three-level key management, to distribute group keys to the clients, and be able to re-key by pushing down a new group key. As illustrated in the section below, MBMS has the need to identify which types of keys are involved in the MIKEY message and their identity.
MBMSがセキュリティにかける要件の1つは、キーの頻繁な更新を実行できることです。この背後にある理論的根拠は、加入者が復号化キーを非補助者に再配布するのに費用がかかるということです。ユニキャストチャネルを使用してキーを再配布するためのコストは、このスキームのキーを購入するコストよりも高くなる必要があります。これを実装するために、MBMSは3階建てのキー管理を使用して、クライアントにグループキーを配布し、新しいグループキーを押し下げることで再キーできるようになります。以下のセクションに示すように、MBMSには、マイキーメッセージとそのアイデンティティにどのタイプのキーが関与しているかを特定する必要があります。
This memo specifies a new Type for the General Extension Payload in MIKEY, to identify the type and identity of keys involved.
このメモは、関連するキーのタイプとアイデンティティを識別するために、マイキーの一般的な拡張ペイロードの新しいタイプを指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
An application where this extension is used is MBMS key management. The key management solution adopted by MBMS uses three-level key management. The keys are used in the way described below. "Clients" refers to the clients who have subscribed to a given multicast/broadcast service.
この拡張機能が使用されるアプリケーションは、MBMSキー管理です。MBMSが採用するキー管理ソリューションは、3レベルのキー管理を使用します。キーは、以下で説明する方法で使用されます。「クライアント」とは、特定のマルチキャスト/ブロードキャストサービスを購読したクライアントを指します。
* The MBMS User Key (MUK), a point-to-point key between the multicast server and each client.
* MBMSユーザーキー（MUK）、マルチキャストサーバーと各クライアントの間のポイントツーポイントキー。
* The MBMS Service Key (MSK), a group key between the multicast server and all the clients.
* MBMSサービスキー（MSK）は、マルチキャストサーバーとすべてのクライアントの間のグループキーです。
* The MBMS Traffic Key (MTK), a group traffic key between the multicast server and all clients.
* MBMSトラフィックキー（MTK）、マルチキャストサーバーとすべてのクライアントの間のグループトラフィックキー。
The Traffic Keys are the keys that are regularly updated.
トラフィックキーは、定期的に更新されるキーです。
The point-to-point MUK (first-level key) is shared between the multicast server and the client via means defined by MBMS [MBMS]. The MUK is used as a pre-shared key to run MIKEY with the pre-shared key method [RFC3830], and to deliver (point-to-point) the MSK. The same MSK is pushed to all the clients, to be used as a (second-level) group key.
ポイントツーポイントMUK（第1レベルのキー）は、MBMS [MBM]によって定義された手段を介して、マルチキャストサーバーとクライアントの間で共有されます。MUKは、事前に共有キーメソッド[RFC3830]を使用してマイキーを実行し、MSKを（ポイントツーポイント）配信するための事前共有キーとして使用されます。同じMSKがすべてのクライアントにプッシュされ、（第2レベルの）グループキーとして使用されます。
Then, the MSK is used to push to all the clients an MTK (third-level key), the actual group key that is used for the protection of the media traffic. For example, the MTK could be the master key for the Secure Real-time Transport Protocol (SRTP) [RFC3711] in the streaming case.
次に、MSKは、メディアトラフィックの保護に使用される実際のグループキーであるMTK（第3レベルのキー）とすべてのクライアントにプッシュするために使用されます。たとえば、MTKは、ストリーミングの場合の安全なリアルタイム輸送プロトコル（SRTP）[RFC3711]のマスターキーになる可能性があります。
A Key Domain identifier defines the domain where the group keys are valid or applicable. For example, it may define a specific service provider.
キードメイン識別子は、グループキーが有効または適用できるドメインを定義します。たとえば、特定のサービスプロバイダーを定義する場合があります。
To allow the key distribution described above, an indication of the type and identity of keys being carried in a MIKEY message is needed. This indication is carried in a new Type of the General Extension Payload in MIKEY.
上記の重要な分布を許可するには、マイキーメッセージで運ばれるキーのタイプとアイデンティティの兆候が必要です。この兆候は、マイキーの一般的な拡張ペイロードの新しいタイプで運ばれます。
It is necessary to specify what Crypto Session ID (CS ID) map type is associated with a given key. There are cases (for example, the download case in MBMS) where the required parameters are signalled in-band (each downloaded Digital Rights Management Content Format object [DCF] contains the necessary parameters needed by the receiver to process it). Since the parameters are not transported by MIKEY, this implies that a CS ID map type needs to be registered to the "empty map", as defined in Table 3, which is to be used when the map/policy information is conveyed outside of MIKEY.
Crypto Session ID（CS ID）マップタイプが特定のキーに関連付けられていることを指定する必要があります。必要なパラメーターがバンド内に信号されている場合（たとえば、MBMSのダウンロードケース）ケースがあります（各ダウンロードされたデジタル権利管理コンテンツフォーマットオブジェクト[DCF]には、受信者が処理するために必要なパラメーターが含まれています）。パラメーターはMikeyによって輸送されないため、これは、CS IDマップタイプを「空のマップ」に登録する必要があることを意味します。表3で定義されています。。
According to [RFC3830], MIKEY is a registration protocol that supports re-keying for unicast in the terms of the MSEC Group Key Management Architecture [RFC4046]. MBMS uses MIKEY both as a registration protocol and a re-key protocol, and the specified extension implements the necessary additions to [RFC3830] that allows MIKEY to function both as a unicast and multicast re-key protocol in the MBMS setting.
[RFC3830]によると、MikeyはMSECグループキー管理アーキテクチャ[RFC4046]の観点からユニキャストの再キーをサポートする登録プロトコルです。MBMSはMikeyを登録プロトコルとRekeyプロトコルの両方として使用し、指定された拡張機能により、MBMS設定でMikeyがユニキャストとマルチキャストの再キープロトコルの両方として機能できるようにする[RFC3830]に必要な追加を実装します。
The General Extension payload in MIKEY is defined in Section 6.15 of [RFC3830]. The General Extension payload type (Key ID Information) defined in the present document is not restricted to MBMS. Applications using this General Extension payload type may define new Key ID types, and these applications MUST define the semantics and usage of the Key ID Type sub-payloads according to Section 8. The MBMS use of the Key ID Type sub-payloads, defined in Table 2, is specified in [MBMS].
マイキーの一般的な拡張ペイロードは、[RFC3830]のセクション6.15で定義されています。現在のドキュメントで定義されている一般的な拡張ペイロードタイプ（キーID情報）は、MBMに限定されていません。この一般的な拡張ペイロードタイプを使用するアプリケーションは、新しいキーIDタイプを定義する場合があり、これらのアプリケーションは、セクション8に従ってキーIDタイプのサブペイロードのセマンティクスと使用を定義する必要があります。表2は[MBMS]で指定されています。
The Key ID Information Type (Type 3) formats the General Extension payload as follows:
キーID情報タイプ（タイプ3）は、次のように一般的な拡張ペイロードをフォーマットします。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key ID Information ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The Key ID Information General Extension Payload
図1.キーID情報一般拡張ペイロード
Next Payload and Length are defined in Section 6.15 of [RFC3830].
次のペイロードと長さは、[RFC3830]のセクション6.15で定義されています。
* Type (8 bits): identifies the type of the General Extension Payload [RFC3830]. This memo adds Type 3 to the ones already defined in [RFC3830].
* タイプ（8ビット）：一般的な拡張ペイロード[RFC3830]のタイプを識別します。このメモは、[RFC3830]ですでに定義されているものにタイプ3を追加します。
Type | Value | Comments
------------------------------------------------------------
Key ID | 3 | information on type and identity of keys
Table 1. Definition of the New General Extension Payload
表1.新しい一般的な拡張ペイロードの定義
* Key ID Information (variable length): the general payload data transporting the type and identifier of a key. This field is formed by Key ID Type sub-payloads as specified below.
* キーID情報（変数長）：キーのタイプと識別子を輸送する一般的なペイロードデータ。このフィールドは、以下に指定されているキーIDタイプのサブペイロードによって形成されます。
The Key ID Type sub-payload is formatted as follows:
キーIDタイプのサブペイロードは、次のようにフォーマットされます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key ID Type ! Key ID Length ! Key ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. The Key ID Type Sub-payload
図2.キーIDタイプのサブペイロード
* Key ID Type (8 bits): describes the type of the key ID. Predefined types are listed in Table 2.
* キーIDタイプ（8ビット）：キーIDのタイプについて説明します。事前定義されたタイプを表2に示します。
Key ID Type | Value | Comment
-----------------------------------------------------------
MBMS Key Domain ID | 0 | ID of the group key domain
MBMS Service Key ID | 1 | ID of the group key
MBMS Traffic Key ID | 2 | ID of the group traffic key
Table 2. Type definitions for Key IDs
表2.キーIDの定義を入力します
* Key ID Length (8 bits): describes the length of the Key ID field in octets.
* キーIDの長さ（8ビット）：オクテットのキーIDフィールドの長さについて説明します。
* Key ID (variable length): defines the identity of the key.
* キーID（変数長）：キーのIDを定義します。
Note that there may be more than one Key ID Type sub-payload in an extension, and that the overall length (i.e., the sum of lengths of all Key ID Type sub-payloads) of the Key ID information field cannot exceed 2^16 - 1 octets.
拡張機能に複数のキーIDタイプのサブペイロードがあり、キーID情報フィールドの全長（つまり、すべてのキーIDタイプのサブペイロードの長さの合計）が2^16を超えることはできないことに注意してください。-1オクテット。
When the security policy information is conveyed outside of MIKEY, the CS ID map type is set to a value defined in Table 3 to indicate "empty map". In this case, there MUST NOT be any Security Policy payload present in the message.
セキュリティポリシー情報がMikeyの外で伝えられると、CS IDマップタイプは、「空のマップ」を示すために表3で定義された値に設定されます。この場合、メッセージにはセキュリティポリシーのペイロードが存在してはなりません。
CS ID map type | Value | Comments
-------------------------------------------------------------
Empty map | 1 | Used when the map/policy information
| | is conveyed outside of MIKEY
Table 3. Definition of the CS ID Map Type.
表3. CS IDマップタイプの定義。
As specified in Section 7 of [RFC3830], the underlying transport of the MIKEY protocol has to be defined for each type of transport. When the Key-ID payload is used with MBMS, the transport is UDP, and the usage of MIKEY over UDP in the MBMS setting is defined in [MBMS].
[RFC3830]のセクション7で指定されているように、マイキープロトコルの基礎となる輸送は、各タイプの輸送について定義する必要があります。Key-IDペイロードがMBMSで使用されると、トランスポートはUDPであり、MBMS設定でのUDPよりもMikeyの使用法は[MBMS]で定義されます。
The usage of MIKEY for updating the traffic encryption key (MTK) in the broadcast manner, described in Section 2, deviates from the way MIKEY [RFC3830] was originally designed. There are two main points that are related to the security of the described usage.
セクション2で説明されている放送方法でトラフィック暗号化キー（MTK）を更新するためのMikeyの使用は、Mikey [RFC3830]が元々設計された方法から逸脱しています。説明されている使用法のセキュリティに関連する2つの主要なポイントがあります。
First, the delivery of the MTK is not source origin authenticated, but rather protected by a group MAC, keyed by the group key (MSK). The threat this raises is that users that are part of the group are able to send fake MTK messages to other group members. The origin of the MTK messages is a node inside the core network, and the trust model used in MBMS is that only trusted traffic is allowed to be sent (from within the operator's network) on the MBMS bearers. However, there is always the risk that traffic is injected on the air interface between the base stations and the user equipment. It is possible for members of the group (i.e., with access to the MSK) to spoof MTK updates to other members of the group. 3GPP decided that the technical difficulties and costs involved in performing such an attack are large enough compared to the expected gain for the attacker, that the risk was deemed acceptable. Note that, since the delivery of the MTK is not source origin authenticated, there is nothing gained by adding source origin authentication to the RTP streams (e.g., using SRTP-TESLA [RFC4383]). Hence, the current use of the specified extension is not compatible with SRTP-TESLA, which requires source origin authentication of the integrity key.
まず、MTKの配信は、Source Originが認証されているのではなく、グループキー（MSK）によってキーになったグループMACによって保護されています。これが提起する脅威は、グループの一部であるユーザーが偽のMTKメッセージを他のグループメンバーに送信できることです。MTKメッセージの起源はコアネットワーク内のノードであり、MBMSで使用される信頼モデルは、MBMSベアラーの信頼されたトラフィックのみを（オペレーターのネットワーク内から）送信できることです。ただし、ベースステーションとユーザー機器の間のエアインターフェースにトラフィックが注入されるリスクが常にあります。グループのメンバー（つまり、MSKにアクセスできる）が、グループの他のメンバーにMTK更新をスプーフィングする可能性があります。3GPPは、そのような攻撃の実行に伴う技術的な困難とコストは、攻撃者の予想される利益と比較して十分に大きいと判断し、リスクは許容されるとみなされました。MTKの配信はソースオリジンの認証されていないため、RTPストリームにソースオリジン認証を追加することで得られるものは何もないことに注意してください（たとえば、SRTP-TESLA [RFC4383]を使用）。したがって、指定された拡張機能の現在の使用は、SRTP-TESLAと互換性がありません。SRTP-TESLAには、整合性キーのソースオリジン認証が必要です。
Note that in MBMS the MSK is protected end-to-end, from the multicast server to the clients, using a client-unique key MUK, but the MTK is delivered under protection by the group key MSK, so source origin authentication is not achieved.
MBMSでは、MSKはマルチキャストサーバーからクライアントにエンドツーエンドで保護されており、クライアントとユニークのキーMUKを使用していますが、MTKはグループキーMSKによって保護されているため、ソースオリジン認証は達成されないことに注意してください。。
Secondly, the delivery of the MTK is separated from the delivery of the security policy. The security policy is delivered with the MSK. The delivery of the MTKs is assumed to be frequent (some scenarios require the delivery of MTKs to be as frequent as a few seconds apart). This would imply that the cost (in terms of bandwidth) would be very high if the security policy was delivered together with each MTK. Furthermore, the security policy parameters of the streaming session are not anticipated to change during the session, even though there would be an update of the MTK. It was decided in 3GPP that there was no need for updating the policy during an ongoing session, and that the cost of allowing such a feature, only to be on the safe side, would be too high. On the other hand, updating the security policy during an ongoing session would be possible by updating the MSK.
第二に、MTKの配信は、セキュリティポリシーの提供から分離されています。セキュリティポリシーはMSKで配信されます。MTKの配信は頻繁に発生すると想定されています（一部のシナリオでは、MTKの配信を数秒ほど離れて頻繁に行う必要があります）。これは、セキュリティポリシーが各MTKとともに配信された場合、（帯域幅の観点から）コストが非常に高くなることを意味します。さらに、MTKの更新があるにもかかわらず、ストリーミングセッションのセキュリティポリシーパラメーターは、セッション中に変更されるとは予想されません。3GPPでは、進行中のセッション中にポリシーを更新する必要はなく、そのような機能を許可するコストは安全な側にあるだけであると決定されました。一方、MSKを更新することにより、進行中のセッション中にセキュリティポリシーを更新することが可能です。
The Empty map type used when the security policy is delivered in band relies on the security provided by DCF [DCF], and MIKEY is, in this case, only used to provide the master key for the DCF processing.
セキュリティポリシーがバンドで配信されるときに使用される空のマップタイプは、DCF [DCF]が提供するセキュリティに依存しており、Mikeyはこの場合、DCF処理のマスターキーを提供するためにのみ使用されます。
According to Section 10 of RFC 3830, IETF consensus is required to register values in the range 0-240 in the Type namespace of the MIKEY General Extension Payload and the CS ID map type namespace of the Common Header Payload.
RFC 3830のセクション10によると、IETFコンセンサスは、Mikey General Extensionペイロードのタイプ名空間と共通ヘッダーペイロードのCS IDマップタイプの名前空間の範囲0-240に値を登録するために必要です。
A new value in the MIKEY General Extension Payload Type name space has been registered for this purpose. The registered value for Key ID is 3 according to Section 4.
この目的のために、Mikey General Extension Payload Type Name Spaceの新しい値が登録されています。キーIDの登録値は、セクション4によると3です。
Also, the value 1 has been registered for the Empty map in the existing CS ID map namespace of the Common Header Payload, as specified in Table 3, in Section 5.
また、値1は、セクション5で表3に指定されているように、既存のCS IDマップマップ名前空間の共通ヘッダーペイロードの名前空間に登録されています。
The new name space for the following field in the Key ID information sub-payload (from Sections 4 and 5) has been established and will be managed by IANA:
キーID情報サブペイロード（セクション4および5から）の次のフィールドの新しい名前スペースが確立され、IANAによって管理されます。
* Key ID Type
* キーIDタイプ
The IANA has registered the pre-defined types of Table 2 for this namespace. IANA will also manage the definition of additional values in the future. Values in the range 0-240 for each name space SHOULD be approved by the process of IETF consensus, and values in the range 241-255 are reserved for Private Use, according to [RFC2434].
IANAは、この名前空間に事前に定義されたタイプの表2を登録しています。IANAは、将来の追加値の定義も管理します。[RFC2434]によると、各名前スペースの範囲0-240の値はIETFコンセンサスのプロセスによって承認され、範囲241-255の値は個人用に予約されています。
We would like to thank Fredrik Lindholm.
フレドリック・リンドホルムに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、RFC 3830、2004年8月。
[MBMS] 3GPP TS 33.246, "Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security; Security of Multimedia Broadcast/Multicast Service".
[MBMS] 3GPP TS 33.246、「技術仕様第3世代パートナーシッププロジェクト、技術仕様グループサービスとシステムの側面、セキュリティ、マルチメディアブロードキャスト/マルチキャストサービスのセキュリティ」。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[DCF] Open Mobile Alliance, OMA-DRM-DCF-V2_0-20050329-C, "DRM Content Format V2.0", Candidate Version 2.0 - 29 March 2005.
[DCF]オープンモバイルアライアンス、OMA-DRM-DCF-V2_0-20050329-C、「DRMコンテンツフォーマットV2.0」、候補バージョン2.0-29 2005年3月。
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006.
[RFC4383] Baugher、M。and E. Carrara、「安全なリアルタイム輸送プロトコル（SRTP）でのタイミングの効率的なストリーム損失耐性認証（TESLA）の使用」、RFC 4383、2006年2月。
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005.
[RFC4046] Baugher、M.、Canetti、R.、Dondeti、L。、およびF. Lindholm、「マルチキャストセキュリティ（MSEC）グループキー管理アーキテクチャ」、RFC 4046、2005年4月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
Authors' Addresses
著者のアドレス
Elisabetta Carrara Royal Institute of Technology Stockholm Sweden
エリザベッタ・カララ・ロイヤル・インスティテュート・オブ・テクノロジー・ストックホルム・スウェーデン
EMail: carrara@kth.se
Vesa Lehtovirta Ericsson Research 02420 Jorvas Finland
Vesa Lehtovirta Ericsson Research 02420 Jorvas Finland
Phone: +358 9 2993314
EMail: vesa.lehtovirta@ericsson.com
Karl Norrman Ericsson Research SE-16480 Stockholm Sweden
Karl Norrman Ericsson Research SE-16480ストックホルムスウェーデン
Phone: +46 8 4044502
EMail: karl.norrman@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。