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)
マルチメディア、インターネットキーイング全般拡張ペイロードのためのキーのID情報タイプ（MIKEY）
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).
著作権（C）インターネット協会（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.
このメモは、マルチメディア、インターネットキーイング（マイキー）プロトコルでの一般的な拡張ペイロードのための新しいタイプ（キー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は、キーの種類はMIKEYメッセージ及びそれらの同一性に関与しているかを特定する必要性を有しています。
This memo specifies a new Type for the General Extension Payload in MIKEY, to identify the type and identity of keys involved.
このメモは、関係するキーの種類や身元を特定するために、MIKEYにおける一般的な拡張ペイロードのための新しいタイプを指定します。
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（第一レベルのキー）がMBMS [MBMS]によって定義された手段を介してマルチキャストサーバとクライアントの間で共有されます。 MUKはMSKを事前共有鍵方式[RFC3830]とMIKEYを実行するため、及び（ポイントツーポイント）を送達するために事前共有キーとして使用されます。同じ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.
上記鍵配布を可能にするために、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.
暗号化セッションID（CS ID）マップの種類が指定されたキーに関連付けられているかを指定する必要があります。必要なパラメータは、帯域内通知されている（例えば、MBMSにおけるダウンロードの場合）の場合は、（それぞれダウンロードしたデジタル著作権管理コンテンツフォーマットのオブジェクト[DCF]がそれを処理するために受信機が必要とする必要なパラメータが含まれています）があります。パラメータはMIKEYによって輸送されないので、これはCS IDマップタイプがマップ/ポリシー情報はMIKEYの外に搬送されるときに使用される表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の両方を使用し、指定された拡張は、MIKEYは、MBMS設定におけるユニキャストおよびマルチキャスト再鍵プロトコルの両方として機能することを可能にする[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情報）は、MBMSに限定されるものではありません。この一般的な拡張ペイロードタイプを使用するアプリケーションは、新しいキーIDのタイプを定義することができ、これらのアプリケーションは、第8節で定義されたキーIDタイプのサブペイロードのMBMSの利用に応じてキー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
キーIDの表2型定義
* 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.
CS ID地図タイプの表3の定義。
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で指定されるように、MIKEYプロトコルの基礎となるトランスポートは、トランスポートの各タイプのために定義されなければなりません。キー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の送達は、認証されたソース由来ではなく、グループ鍵（MSK）をキーグループMACによって保護します。これが提起脅威は、グループの一部であるユーザーが、他のグループメンバーに偽のMTKメッセージを送信することができることです。 MTKメッセージの起源は、コアネットワーク内のノードであり、MBMSに使用される信頼モデルは、信頼できるトラフィックがMBMSベアラ上（事業者のネットワーク内から）送信することが許可されていることです。ただし、トラフィックは、基地局とユーザ機器との間のエアインタフェースに注入されてしまう危険性が常にあります。 （MSKへのアクセス権を持つ、すなわち、）グループのメンバーがグループの他のメンバーにMTKの更新をスプーフィングすることが可能です。 3GPPは、技術的な問題と、そのような攻撃を実行するのにかかるコストは、リスクが許容できるとみなされたことが、攻撃者にとって期待される利益に比べて十分に大きいことを決めました。 MTKの送達が認証原点を供給されていないので、なお、（例えば、SRTPテスラ[RFC4383]を使用して）RTPストリームにソース発信元認証を追加することによって得られるものは何もありません。したがって、指定された拡張子の現在の使用は、完全性キーのソース発信元認証を必要と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で配信されます。 MTKsの送達は、（いくつかのシナリオが離れて数秒ほど頻繁であることがMTKsの送達を必要とする）頻繁にあることが想定されます。これは、セキュリティポリシーは、各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一般的な拡張ペイロードと共通ヘッダーペイロードの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一般的な拡張ペイロードタイプのネームスペースに新しい値は、この目的のために登録されています。鍵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:
（セクション4および5からの）キーID情報サブペイロードで次のフィールドの新しい名前空間が確立され、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はまた、将来的に追加の値の定義を管理します。各名前空間の範囲は0から240の値は、[RFC2434]によれば、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、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.、マグリュー、D.、Naslund、M.、カララ、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 - 2005年3月29日。
[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.とE.カララ、RFC 4383、2006年2月「時限効率的なストリーム損失トレラントセキュアリアルタイム転送プロトコル（SRTP）での認証（TESLA）の使用」。
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005.
[RFC4046] Baugher、M.、カネッティ、R.、Dondeti、L.、およびF.リンドホルム、 "マルチキャストセキュリティ（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
メールアドレス：carrara@kth.se
Vesa Lehtovirta Ericsson Research 02420 Jorvas Finland
VESA Lehtoエリクソンパワー研究02420 Jorvasフィンランド
Phone: +358 9 2993314 EMail: vesa.lehtovirta@ericsson.com
電話：+358 9 2993314 Eメール：vesa.lehtovirta@ericsson.com
Karl Norrman Ericsson Research SE-16480 Stockholm Sweden
カールNorrmanエリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 4044502 EMail: karl.norrman@ericsson.com
電話：+46 8 4044502 Eメール：karl.norrman@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。