[要約] RFC 4442は、TESLAプロトコルの効率的なストリーム損失耐性認証のブートストラップに関するものです。このRFCの目的は、ネットワーク上での認証の信頼性と効率性を向上させることです。
Network Working Group S. Fries
Request for Comments: 4442 H. Tschofenig
Category: Standards Track Siemens
March 2006
Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
ブートストラップの時限効率的なストリーム損失耐性認証（TESLA）
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
概要
TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead that scales to large numbers of receivers and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published, targeting multicast authentication in scenarios where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms.
タイミングの効率的なストリーム損失耐性認証プロトコルであるTeslaは、マルチキャストシナリオでソース認証を提供します。Teslaは、通信および計算オーバーヘッドが少ない効率的なプロトコルであり、多数の受信機にスケーリングし、パケットの損失を許容します。テスラは、送信者と受信機の間のゆるい時間同期に基づいています。ソース認証は、メッセージ認証コード（MAC）チェーンを使用することにより、Teslaで実現されます。安全なリアルタイムトランスポートプロトコル（SRTP）内でのTeslaの使用が公開されており、マルチメディアデータを保護するためにSRTPが適用されるシナリオでマルチキャスト認証をターゲットにしています。このソリューションは、テスラパラメーターが帯域外のメカニズムによって利用可能になることを前提としています。
This document specifies payloads for the Multimedia Internet Keying (MIKEY) protocol for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast, or broadcast.
このドキュメントは、SRTPを使用した安全なグループ通信のソース認証のためのブートストラップTESLAのマルチメディアインターネットキーイング（Mikey）プロトコルのペイロードを指定します。Teslaは、Mikey Key Managementアプローチの1つを使用してブートストラップされる可能性があります。たとえば、ユニキャスト、マルチキャスト、またはブロードキャストを介して送信されたデジタルで署名されたMikeyメッセージを使用して。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. TESLA Parameter Overview ........................................4
4. Parameter Encoding within MIKEY .................................6
4.1. Security Policy (SP) Payload ...............................6
4.2. TESLA Policy ...............................................7
4.3. Time Synchronization .......................................8
4.4. Key Data Transport within MIKEY's General
Extension Payload .........................................10
5. Security Considerations ........................................11
5.1. Man-in-the-Middle Attack ..................................11
5.2. Downgrading Attack ........................................12
5.3. Denial of Service Attack ..................................12
5.4. Replay Attack .............................................13
5.5. Traffic Analysis ..........................................13
6. IANA Considerations ............................................14
7. Acknowledgements ...............................................15
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................16
In many multicast, broadcast, and unicast communication scenarios, it is necessary to guarantee that a received message has been sent from a dedicated source and has not been altered in transit. In unicast communication, commonly a pairwise security association exists that enables the validation of message integrity and data origin. The approach in group-based communication is different, as here a key is normally shared between the members of a group and thus may not be used for data origin authentication. As in some applications a dedicated identification of a sender is required, there exists the requirement to support data origin authentication also in multicast scenarios. One of the methods supporting this is TESLA [RFC4082]. TESLA provides source authentication in multicast scenarios by using MAC chaining. It is based on loose time synchronization between the sender and the receivers.
多くのマルチキャスト、ブロードキャスト、ユニキャスト通信シナリオでは、受信したメッセージが専用のソースから送信され、輸送中に変更されていないことを保証する必要があります。ユニキャスト通信では、一般的に、メッセージの整合性とデータ起源の検証を可能にするペアワイズセキュリティ協会が存在します。グループベースの通信のアプローチは異なります。ここでは、キーは通常、グループのメンバー間で共有されるため、データの起源認証には使用されない可能性があります。一部のアプリケーションと同様に、送信者の専用の識別が必要であるように、マルチキャストシナリオでもデータの起源認証をサポートするための要件が存在します。これをサポートする方法の1つは、テスラ[RFC4082]です。Teslaは、Macチェーンを使用してマルチキャストシナリオでソース認証を提供します。これは、送信者と受信機の間のゆるい時間同期に基づいています。
[RFC4383] describes extensions for SRTP [RFC3711] in order to support TESLA [RFC4082] for source authentication in multicast scenarios. SRTP needs dedicated cryptographic context describing the security parameter and security policy per multimedia session to be protected. This cryptographic context needs to be enhanced with a set of TESLA parameters. It is necessary to provide these parameters before the actual multicast session starts. [RFC4383] does not address the bootstrapping for these parameters.
[RFC4383]は、マルチキャストシナリオのソース認証のためにTesla [RFC4082]をサポートするために、SRTP [RFC3711]の拡張を説明しています。SRTPには、保護されるマルチメディアセッションごとのセキュリティパラメーターとセキュリティポリシーを説明する専用の暗号化コンテキストが必要です。この暗号化コンテキストは、一連のテスラパラメーターを使用して強化する必要があります。実際のマルチキャストセッションが開始される前に、これらのパラメーターを提供する必要があります。[RFC4383]は、これらのパラメーターのブートストラップに対処しません。
This document details bootstrapping of TESLA parameters in terms of parameter distribution for TESLA policy as well as the initial key, using the Multimedia Internet Keying (MIKEY) [RFC3830] protocol. MIKEY defines an authentication and key management framework that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, [RFC3830] is defined in a way that is intended to support SRTP in the first place but is open to enhancements to be used for other purposes too. Following the description in [RFC3830], MIKEY is targeted for point-to-point as well as group communication. In the context of group communication, an administrator entity can distribute session keys to the associated entities participating in the communication session. This scenario is also applicable for TESLA where one entity may provide information to many others in a way that the integrity of the communicated information can be assured. The combination of MIKEY and TESLA supports this group-based approach by utilizing the MIKEY framework to distribute TESLA parameter information to all involved entities. Note that this document focuses only on the distribution of the parameters, not on the generation of those parameters.
このドキュメントでは、マルチメディアインターネットキーイング（Mikey）[RFC3830]プロトコルを使用して、Teslaポリシーと初期キーのパラメーター分布の観点からTeslaパラメーターのブートストラップを詳しく説明しています。Mikeyは、リアルタイムアプリケーション（ピアツーピアコミュニケーションとグループコミュニケーションの両方）に使用できる認証と主要な管理フレームワークを定義します。特に、[RFC3830]は、そもそもSRTPをサポートすることを目的とした方法で定義されていますが、他の目的にも使用される機能強化に開かれています。[RFC3830]の説明に従って、Mikeyはポイントツーポイントとグループコミュニケーションをターゲットにしています。グループコミュニケーションのコンテキストでは、管理者エンティティは、コミュニケーションセッションに参加する関連エンティティにセッションキーを配布できます。このシナリオは、1つのエンティティが通信情報の完全性を保証できる方法で他のエンティティに情報を提供できるテスラにも適用できます。MikeyとTeslaの組み合わせは、Mikey Frameworkを利用してTeslaパラメーター情報をすべての関係者に配布することにより、このグループベースのアプローチをサポートしています。このドキュメントは、これらのパラメーターの生成ではなく、パラメーターの分布のみに焦点を当てていることに注意してください。
MIKEY [RFC3830] itself describes three authentication and key exchange protocols (symmetric key encryption, public key encryption, and signed Diffie-Hellman). Extensions to the MIKEY key exchange methods have been defined. A fourth key distribution method is provided by [DHHMAC] and describes a symmetrically protected Diffie-Hellman key agreement. A further option has been proposed in [RSA-R] that describes an enhanced asymmetric exchange variant, also supporting inband certificate exchange. All the different key management schemes mentioned above may be used to provide the TESLA parameters. The required TESLA parameters to be exchanged are already described in [RFC4383], while this document describes their transport within MIKEY.
Mikey [RFC3830]自体は、3つの認証とキー交換プロトコル（対称キー暗号化、公開キー暗号化、および署名されたDiffie-Hellman）について説明しています。Mikey Key Exchangeメソッドへの拡張が定義されています。[DHHMAC]によって4番目の主要な分布方法が提供され、対称的に保護されたdiffie-hellmanキー契約について説明します。[RSA-R]では、強化された非対称交換バリアントを記述する[RSA-R]でさらにオプションが提案されており、帯域帯証明書交換もサポートしています。上記のすべての異なる主要な管理スキームを使用して、Teslaパラメーターを提供することができます。交換される必要なテスラパラメーターは[RFC4383]ですでに説明されていますが、このドキュメントではMikey内での輸送について説明しています。
The following security requirements have to be placed on the exchange of TESLA parameters:
次のセキュリティ要件は、テスラパラメーターの交換に配置する必要があります。
o Authentication and Integrity MUST be provided when sending the TESLA parameters, especially for the initial key. o Confidentiality MAY be provided for the TESLA parameters.
o テスラパラメーターを送信するとき、特に初期キーの場合、認証と整合性を提供する必要があります。o Teslaパラメーターの機密性が提供される場合があります。
These security requirements apply to the TESLA bootstrapping procedure only. Security requirements for applications using TESLA are beyond the scope of this document. Security aspects that relate to TESLA itself are described in [RFC4082], and security issues for TESLA usage for SRTP are covered in [RFC4383].
これらのセキュリティ要件は、テスラブートストラップ手順のみに適用されます。Teslaを使用したアプリケーションのセキュリティ要件は、このドキュメントの範囲を超えています。テスラ自体に関連するセキュリティの側面は[RFC4082]で説明されており、SRTPのテスラ使用に関するセキュリティの問題は[RFC4383]でカバーされています。
It is important to note that this document is one piece of a complete solution. Assuming that media traffic is to be secured using TESLA as described in [RFC4383], then (a) keying material and (b) parameters for TESLA are required. This document contributes the parameters and the authentication methods used in MIKEY to provide the keying material. The parameter exchange for TESLA also needs to be secured against tampering. This protection is also provided by MIKEY.
このドキュメントは完全なソリューションの1つであることに注意することが重要です。[RFC4383]に記載されているように、テスラを使用してメディアトラフィックを保護すると仮定すると、（a）キーイング材料と（b）テスラのパラメーターが必要です。このドキュメントは、キーイング材料を提供するためにマイキーで使用されるパラメーターと認証方法に寄与します。テスラのパラメーター交換も、改ざんに対して保護する必要があります。この保護はマイキーによっても提供されます。
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]で説明されているように解釈されます。
According to [RFC4383], a number of transform-dependent parameters need to be provided for proper TESLA operation. The complete list of parameters can be found in Section 4.3 of [RFC4383]. Note that parameter 10 of [RFC4383], describing the lag of the receiver clock relative to the sender clock, is omitted in this document since it can be computed.
[RFC4383]によると、適切なテスラ操作のために、多くの変換依存パラメーターを提供する必要があります。パラメーターの完全なリストは、[RFC4383]のセクション4.3に記載されています。[RFC4383]のパラメーター10は、送信者クロックに対するレシーバークロックの遅れを記述しているが、このドキュメントで計算できるため省略されていることに注意してください。
MIKEY already requires synchronized clocks, which also provides for synchronization for TESLA. Moreover, Section 4.3 states an option to use MIKEY for clock drift determination between the sender and receiver. Thus, this parameter does not need to be transmitted in MIKEY directly.
Mikeyはすでに同期したクロックを必要としています。これは、テスラの同期も提供します。さらに、セクション4.3では、送信者と受信機の間のクロックドリフト決定にMikeyを使用するオプションを示しています。したがって、このパラメーターはMikeyで直接送信する必要はありません。
The information in brackets provides the default values as specified in Section 6.2 of [RFC4383].
括弧内の情報は、[RFC4383]のセクション6.2で指定されているデフォルト値を提供します。
1. An identifier for the PRF (TESLA PRF), implementing the one-way function F(x) in TESLA (to derive the keys in the chain), and the one-way function F'(x) in TESLA (to derive the keys for the TESLA MAC, from the keys in the chain), e.g., to indicate the keyed hash function (default HMAC-SHA1).
1. PRF（Tesla PRF）の識別子、テスラに一方向関数f（x）を実装（チェーン内のキーを導出する）、一方向関数f '（x）はテスラ（キーを導出するために）テスラMACの場合、チェーン内のキーから）、たとえば、キー付きハッシュ関数（デフォルトのHMAC-SHA1）を示すため。
2. A non-negative integer, determining the length of the F output, i.e., the length of the keys in the chain, which is also the key disclosed in an SRTP packet if TESLA is used in the SRTP context (default 160 bit).
2. F出力の長さを決定する非陰性整数、つまりチェーン内のキーの長さは、SRTPコンテキスト（デフォルト160ビット）でTeslaが使用される場合にSRTPパケットに開示されるキーでもあります。
3. A non-negative integer, determining the length of the output of F', i.e., the length of the key for the TESLA MAC (default 160 bit).
3. f 'の出力の長さを決定する非陰性整数、つまりテスラMACのキーの長さ（デフォルト160ビット）。
4. An identifier for the TESLA MAC that accepts the output of F'(x) as its key, e.g., to indicate a keyed hashing function (default HMAC-SHA1).
4. f '（x）の出力をキーとして受け入れるテスラMACの識別子、たとえば、キー付きハッシュ関数（デフォルトのHMAC-SHA1）を示すために。
5. A non-negative integer, determining the length of the output of the TESLA MAC (default 80 bit).
5. テスラMACの出力の長さを決定する非陰性整数（デフォルト80ビット）。
6. The beginning of the session for which a key will be applied.
6. キーが適用されるセッションの開始。
7. The interval duration (in milliseconds) for which a dedicated key will be used.
7. 専用キーが使用される間隔持続時間（ミリ秒単位）。
8. The key disclosure delay (in number of intervals) characterizes the period after which the key will be sent to the involved entities (e.g., as part of SRTP packets).
8. キー開示遅延（間隔数）は、キーが関係するエンティティに送信される期間を特徴付けます（たとえば、SRTPパケットの一部として）。
9. Non-negative integer, determining the length of the key chain, which is determined based on the expected duration of the stream.
9. 非陰性整数、キーチェーンの長さを決定します。これは、ストリームの予想される期間に基づいて決定されます。
10. The initial key of the chain to which the sender has committed himself.
10. 送信者が自分自身をコミットしたチェーンの最初のキー。
As mentioned in Section 3, TESLA parameters need to be transported before actually starting a session. MIKEY currently only defines a payload for transporting the SRTP policy (see Section 6.10 of [RFC3830]). This section describes the enhancement of MIKEY to allow the transport of a TESLA policy and additionally the initial TESLA key.
セクション3で述べたように、実際にセッションを開始する前にテスラパラメーターを輸送する必要があります。Mikeyは現在、SRTPポリシーを輸送するためのペイロードのみを定義しています（[RFC3830]のセクション6.10を参照）。このセクションでは、マイキーの強化について説明して、テスラポリシーの輸送、さらに初期のテスラキーを輸送できるようにします。
The Security Policy payload defines a set of policies that apply to a specific security protocol. The definition here relies on the security policy payload definition in [RFC3830].
セキュリティポリシーのペイロードは、特定のセキュリティプロトコルに適用される一連のポリシーを定義します。ここでの定義は、[RFC3830]のセキュリティポリシーペイロード定義に依存しています。
0 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 ! Policy no ! Prot type ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): Identifies the payload that is added after this payload. See Section 6.1 of [RFC3830] for more details.
* 次のペイロード（8ビット）：このペイロード後に追加されたペイロードを識別します。詳細については、[RFC3830]のセクション6.1を参照してください。
* Policy no (8 bits): Each security policy payload must be given a distinct number for the current MIKEY session by the local peer. This number is used to map a cryptographic session to a specific policy (see also Section 6.1.1 of [RFC3830]).
* ポリシー番号（8ビット）：各セキュリティポリシーのペイロードには、地元のピアによる現在のマイキーセッションの明確な番号を指定する必要があります。この数値は、暗号化セッションを特定のポリシーにマッピングするために使用されます（[RFC3830]のセクション6.1.1も参照）。
* Prot type (8 bits): This value defines the security protocol. A second value needs to be defined as shown below: (MIKEY already defines the value 0.)
* PROTタイプ（8ビット）：この値はセキュリティプロトコルを定義します。2番目の値は、以下に示すように定義する必要があります：（Mikeyはすでに値0を定義しています）
Prot type | Value |
---------------------------
SRTP | 0 |
TESLA | 1 |
* Policy param length (16 bits): This field defines the total length of the policy parameters for the selected security protocol.
* ポリシーパラメーション長（16ビット）：このフィールドは、選択したセキュリティプロトコルのポリシーパラメーターの全長を定義します。
* Policy param (variable length): This field defines the policy for the specific security protocol.
* ポリシーパラマ（変数長）：このフィールドは、特定のセキュリティプロトコルのポリシーを定義します。
The Policy param part is built up by a set of Type/Length/Value (TLV) payloads. For each security protocol, a set of possible type/value pairs can be negotiated as defined.
ポリシーのパラマリ部分は、タイプ/長さ/値（TLV）ペイロードのセットによって構築されます。各セキュリティプロトコルについて、可能なタイプ/バリューペアのセットを定義されたとおりに交渉できます。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Length ! Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Type (8 bits): Specifies the type of the parameter.
* タイプ（8ビット）：パラメーターのタイプを指定します。
* Length (8 bits): Specifies the length of the Value field (in bytes).
* 長さ（8ビット）：値フィールドの長さ（バイト単位）を指定します。
* Value (variable length): Specifies the value of the parameter.
* 値（変数長）：パラメーターの値を指定します。
This policy specifies the parameters for TESLA. The types/values that can be negotiated are defined by the following table. The concrete default values are taken from [RFC4383], but other values may also be used:
このポリシーは、テスラのパラメーターを指定します。交渉できるタイプ/値は、次の表で定義されます。具体的なデフォルト値は[RFC4383]から取得されますが、他の値も使用できます。
Type | Meaning | Possible values
---------------------------------------------------------------
1 | PRF identifier for f and f', realising | see below
F(x) and F'(x)
2 | Length of PRF f' output | 160
3 | Identifier for the TESLA MAC | see below
4 | Length of TESLA MAC output | 80 (truncated)
5 | Start of session | in bytes
6 | Interval duration (in msec) | in bytes
7 | Key disclosure delay | in bytes
8 | Key chain length (number of intervals) | in bytes
9 | Local timestamp media receiver | see below
The time values stated in items 5 and 9 SHALL be transported in NTP-UTC format, which is one of the three options described in Section 6.6 of [RFC3830]. A four-byte integer value for policy item 6 and a two-byte integer value for policy item 7 are RECOMMENDED, carrying interval duration and key disclosure delay. Policy type 9 stated above is optional and SHOULD be used if the time synchronization described in Section 4.3, point two, is used. Otherwise, it SHOULD be omitted.
項目5および9に記載されている時間値は、[RFC3830]のセクション6.6で説明されている3つのオプションの1つであるNTP-UTC形式で輸送されます。ポリシー項目6の4バイトの整数値とポリシーアイテム7の2バイト整数値が推奨され、間隔の持続時間と主要な開示遅延があります。上記のポリシータイプ9はオプションであり、セクション4.3、ポイント2で説明されている時間同期が使用される場合は使用する必要があります。それ以外の場合は、省略する必要があります。
For the PRF realizing F(x) and F'(x), a one-byte length is sufficient. The currently defined possible values are:
f（x）およびf '（x）を実現するPRFでは、1バイトの長さで十分です。現在定義されている可能性のある値は次のとおりです。
TESLA PRF F(x), F'(x) | Value
------------------------------
HMAC-SHA1 | 0
For the TESLA MAC, a one-byte length is enough. The currently defined possible values are:
Tesla Macの場合、1バイトの長さで十分です。現在定義されている可能性のある値は次のとおりです。
TESLA MAC | Value
-----------------------
HMAC-SHA1 | 0
MIKEY as well as TESLA require the time synchronization of the communicating peers. MIKEY requires time synchronization to provide timestamp-based replay protection for the one-roundtrip authentication and key exchange protocols. TESLA, on the other hand, needs this information to determine the clock drift between the senders and the receivers in order to release the disclosed key appropriately. Two alternatives are available for time synchronization:
マイキーとテスラには、通信仲間の時間同期が必要です。Mikeyは、1つのラウンドトリップ認証と主要な交換プロトコルにタイムスタンプベースのリプレイ保護を提供するために時間同期を必要とします。一方、テスラは、開示されたキーを適切にリリースするために、送信者と受信機の間のクロックドリフトを決定するためにこの情報を必要とします。時間同期には、2つの選択肢があります。
1. Usage of out-of-band synchronization using NTP [RFC1305]. This approach is already recommended within [RFC3830]. The advantage of this approach is the option to use the MIKEY key management variants that perform within a half-roundtrip. The disadvantage is the required time synchronization via an additional protocol.
1. NTP [RFC1305]を使用した帯域外同期の使用。このアプローチは、[RFC3830]内ですでに推奨されています。このアプローチの利点は、ハーフラウンドトリップ内で実行されるMikeyキー管理バリアントを使用するオプションです。欠点は、追加のプロトコルを介して必要な時間同期です。
2. [RFC4082] also sketches a possible inband synchronization in Section 3.3.1. This approach is summarized here in the context of MIKEY. Note that here the actual TESLA policy payload is transmitted as part of the MIKEY responder message.
2. [RFC4082]は、セクション3.3.1で可能なインバンド同期もスケッチしています。このアプローチは、Mikeyのコンテキストでここにまとめられています。ここでは、実際のTeslaポリシーペイロードがMikey Responderメッセージの一部として送信されることに注意してください。
* The data receiver, which would be the MIKEY initiator, sets the local time parameter t_r and sends it as part of the timestamp payload as described in [RFC3830]. This value t_r needs to be stored locally.
* マイキーイニシエーターであるデータレシーバーは、[RFC3830]で説明されているように、現地時間パラメーターT_Rを設定し、タイムスタンプペイロードの一部として送信します。この値T_Rはローカルに保存する必要があります。
* Upon receipt of the MIKEY initiator message, the data sender replies with the MIKEY responder message, setting the local time stamp at data receiver (parameter 11) to the value t_r received in the MIKEY initiator message, and sets his local time as a 64-bit UTC value t_s in the timestamp payload as described in [RFC3830].
* Mikey Initiatorメッセージを受信すると、データ送信者はMikey Responderメッセージで返信し、Data Recever（パラメーター11）のローカルタイムスタンプをMikey Initiatorメッセージで受信した値T_Rに設定し、ローカルタイムを64-に設定します。[RFC3830]で説明されているように、タイムスタンプペイロードのビットUTC値T_S。
MIKEY initiator message
[MIKEY parameter incl. local timestamp (t_r)]
------------------>
MIKEY responder message
[MIKEY parameter incl. local timestamp (t_s), TESLA policy
payload, received local time stamp t_r]
<------------------
* Upon receiving the MIKEY responder message the data receiver sets D_t = t_s - t_r + S, where S is an estimated bound on the clock drift throughout the duration of the session.
* Mikey Responderメッセージを受信すると、データレシーバーはD_T = T_S -T_R Sを設定します。ここで、Sはセッション期間中ずっとクロックドリフトにバインドされています。
This approach has the advantage that it does not require an additional time synchronization protocol. The disadvantage is the necessity to perform a full MIKEY handshake, to enable correct parameter transport. Moreover this approach is direction dependent, as it may only be applied if the media receiver is also the MIKEY initiator.
このアプローチには、追加の時間同期プロトコルを必要としないという利点があります。欠点は、正しいパラメーター輸送を可能にするために、完全なマイキーの握手を実行する必要性です。さらに、このアプローチは方向に依存します。これは、メディアレシーバーがMikeyイニシエーターでもある場合にのみ適用される可能性があるためです。
Out-of-band synchronization using NTP (i.e., alternative 1) is the RECOMMENDED approach for clock synchronization. In scenarios where the media receiver is also the MIKEY initiator piggybacking timestamp information in MIKEY (i.e., alternative 2) MAY be used to allow for inband determination of the clock drift between sender and receiver.
NTP（つまり、代替1）を使用したバンド外の同期は、クロック同期に推奨されるアプローチです。メディアレシーバーがマイキーイニシエーターのピギーバックタイムスタンプ情報であるシナリオでは、マイキー（つまり、代替2）を使用して、送信者とレシーバーの間のクロックドリフトのインバンドの決定を可能にすることができます。
The General Extensions Payload was defined to allow possible extensions to MIKEY without the need for defining a completely new payload each time. This payload can be used in any MIKEY message and is part of the authenticated/signed data part.
一般的な拡張ペイロードは、毎回完全に新しいペイロードを定義する必要なく、Mikeyに可能な拡張機能を可能にするために定義されました。このペイロードは、任意のマイキーメッセージで使用でき、認証/署名されたデータパーツの一部です。
0 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): Identifies the payload following this payload.
* 次のペイロード（8ビット）：このペイロード後のペイロードを識別します。
* Type (8 bits): Identifies the type of general payload. MIKEY already defines the values 0 and 1. This document introduces a new value (2).
* タイプ（8ビット）：一般的なペイロードのタイプを識別します。Mikeyはすでに値0と1を定義しています。このドキュメントは、新しい値を導入します（2）。
Type | Value | Comments
----------------------------------------------------
Vendor ID | 0 | Vendor specific byte string
SDP IDs | 1 | List of SDP key mgmt IDs
TESLA I-Key | 2 | TESLA initial key
* Length (16 bits): The length in bytes of the Data field.
* 長さ（16ビット）：データフィールドのバイトの長さ。
* Data (variable length): The general payload data.
* データ（変数長）：一般的なペイロードデータ。
The security properties of multi-media data in a multicast environment depends on a number of building blocks.
マルチキャスト環境におけるマルチメディアデータのセキュリティプロパティは、多くの構成要素に依存します。
SRTP-TESLA [RFC4383] describes extensions for SRTP [RFC3711] in order to support TESLA [RFC4082] for source authentication in multicast scenarios. As such, security considerations described with TESLA (see [PCST] and [RFC4082]), the TESLA SRTP mapping [RFC4383], and SRTP [RFC3711] itself are relevant in this context.
SRTP-TESLA [RFC4383]は、マルチキャストシナリオのソース認証のためにTesla [RFC4082]をサポートするために、SRTP [RFC3711]の拡張を説明しています。そのため、テスラ（[PCST]および[RFC4082]を参照）で説明されているセキュリティ上の考慮事項、Tesla SRTPマッピング[RFC4383]、およびSRTP [RFC3711]自体がこのコンテキストで関連しています。
Furthermore, since this document details bootstrapping of TESLA using the Multimedia Internet Keying (MIKEY) [RFC3830] protocol, the security considerations of MIKEY are applicable to this document.
さらに、このドキュメントは、マルチメディアインターネットキーイング（Mikey）[RFC3830]プロトコルを使用してTeslaのブートストラップを詳述しているため、Mikeyのセキュリティに関する考慮事項がこのドキュメントに適用されます。
As a summary, in order for a multi-media application to support TESLA, the following protocol interactions (in relationship to this document) are necessary:
要約として、マルチメディアアプリケーションがテスラをサポートするために、次のプロトコルの相互作用（このドキュメントとの関係）が必要です。
o MIKEY [RFC3830] is executed between the desired entities to perform authentication and a secure distribution of keying material. In order to subsequently use TESLA, the parameters described in this document are distributed using MIKEY. MIKEY itself uses another protocol for parameter transport, namely, the Session Description Protocol (SDP) [RFC2327]. SDP might again be used within Session Initiation Protocol (SIP, [RFC3261]) to set up a session between the desired entities.
o Mikey [RFC3830]は、認証とキーイング材料の安全な分布を実行するために、目的のエンティティ間で実行されます。その後、Teslaを使用するために、このドキュメントで説明されているパラメーターはMikeyを使用して配布されます。Mikey自体は、パラメータートランスポートの別のプロトコル、つまりセッション説明プロトコル（SDP）[RFC2327]を使用しています。SDPは、セッション開始プロトコル（SIP、[RFC3261]）内で再び使用され、目的のエンティティ間でセッションを設定することができます。
o After the algorithms, parameters, and session keys are available at the respective communication entities, data traffic protection via SRTP-TESLA [RFC4383] can be used. SRTP-TESLA itself applies TESLA to the SRTP protocol, and as such the processing guidelines of TESLA need to be followed.
o アルゴリズム、パラメーター、およびセッションキーがそれぞれの通信エンティティで利用可能になった後、SRTP-TESLA [RFC4383]を介したデータトラフィック保護を使用できます。SRTP-Tesla自体は、TeslaをSRTPプロトコルに適用するため、Teslaの処理ガイドラインに従う必要があります。
Threat:
脅威：
The exchange of security-related parameters and algorithms without mutual authentication of the two peers can allow an adversary to perform a man-in-the-middle attack. The mechanisms described in this document do not themselves provide such an authentication and integrity protection.
2人のピアを相互に認証することなく、セキュリティ関連のパラメーターとアルゴリズムの交換により、敵が中間の攻撃を行うことができます。このドキュメントで説明されているメカニズム自体は、そのような認証と整合性の保護を提供しません。
Countermeasures:
対策：
Throughout the document, it is assumed that the parameter exchange is secured using another protocol, i.e., the exchange parameters and algorithms are part of a authentication and key exchange protocol (namely, MIKEY). Source authentication of group and multicast communication cannot be provided for the data traffic if the prior signaling exchange did not provide facilities to authenticate the source. Using an authentication protocol that does not provide session keys as part of a successful protocol exchange will make it impossible to derive the necessary parameters required by TESLA. MIKEY provides session key establishment. Additionally, the exchange of parameters and algorithms MUST be authenticated and integrity protected. The security protection of the parameter exchange needs to provide the same level or a higher level of security.
ドキュメント全体で、パラメーター交換は別のプロトコルを使用して保護されていると想定されています。つまり、交換パラメーターとアルゴリズムは、認証およびキー交換プロトコル（すなわち、Mikey）の一部です。以前の信号交換がソースを認証するための施設を提供しなかった場合、グループとマルチキャスト通信のソース認証はデータトラフィックに提供できません。プロトコル交換の成功の一部としてセッションキーを提供しない認証プロトコルを使用すると、テスラが必要とする必要なパラメーターを導き出すことができなくなります。Mikeyはセッションキー施設を提供します。さらに、パラメーターとアルゴリズムの交換は認証され、整合性を保護する必要があります。パラメーター交換のセキュリティ保護は、同じレベルまたはより高いレベルのセキュリティを提供する必要があります。
Threat:
脅威：
The exchange of security-related parameters and algorithms is always subject to downgrading whereby an adversary modifies some (or all) of the provided parameters. For example, a few parameters require that a supported hash algorithm be listed. To mount an attack, the adversary has to modify the list of provided algorithms and to select the weakest one.
セキュリティ関連のパラメーターとアルゴリズムの交換は、敵が提供されたパラメーターの一部（またはすべて）を変更するために、常に格下げされます。たとえば、いくつかのパラメーターでは、サポートされているハッシュアルゴリズムをリストする必要があります。攻撃を実施するには、敵は提供されたアルゴリズムのリストを変更し、最も弱いアルゴリズムを選択する必要があります。
Countermeasures:
対策：
TESLA parameter bootstrapping MUST be integrity protected to prevent modification of the parameters and their values. Moreover, since unmodified parameters from an unknown source are not useful, authentication MUST be provided. This functionality is not provided by mechanisms described in this document. Instead, the capabilities of the underlying authentication and key exchange protocol (MIKEY) are reused for this purpose.
Teslaパラメーターブートストラップは、パラメーターとその値の変更を防ぐために整合性保護されている必要があります。さらに、未知のソースからの未修正パラメーターは役に立たないため、認証を提供する必要があります。この機能は、このドキュメントで説明されているメカニズムによって提供されません。代わりに、基礎となる認証とキー交換プロトコル（Mikey）の機能は、この目的のために再利用されます。
Threat:
脅威：
An adversary might want to modify parameters exchanged between the communicating entities in order to establish different state information at the respective communication entities. For example, an adversary might want to modify the key disclosure delay or the interval duration in order to disrupt the communication at a later state since the TESLA algorithm assumes that the participating communication entities know the same parameter set.
敵は、それぞれの通信事業体で異なる州の情報を確立するために、通信事業体間で交換されたパラメーターを変更したいと思うかもしれません。たとえば、敵は、テスラアルゴリズムが参加通信エンティティが同じパラメーターセットを知っていると想定しているため、後の状態で通信を混乱させるために、主要な開示遅延または間隔の持続時間を変更したい場合があります。
Countermeasures:
対策：
The exchanged parameters and the parameters and algorithms MUST be integrity protected to allow the recipient to detect whether an adversary attempted to modify the exchanged information. Authentication and key exchange algorithms provided by MIKEY offer this protection.
交換されたパラメーターとパラメーターとアルゴリズムは、敵が交換された情報の変更を試みたかどうかを受信者が検出できるように、整合性保護されている必要があります。Mikeyが提供する認証とキー交換アルゴリズムは、この保護を提供します。
Threat:
脅威：
An adversary who is able to eavesdrop on one or multiple protocol exchanges (MIKEY exchanges with the parameters described in this document) might be able to replay the payloads in a later protocol exchange. If the recipients accept the parameters and algorithms (or even the messages that carry these payloads), then a denial of service, downgrading, or a man-in-the-middle attack might be the consequence (depending on the entire set of replayed attributes and messages).
1つまたは複数のプロトコル交換（このドキュメントで説明されているパラメーターとのMikey交換）を盗聴できる敵は、後のプロトコル交換でペイロードを再生できる場合があります。受信者がパラメーターとアルゴリズム（またはこれらのペイロードを伝えるメッセージ）を受け入れる場合、サービスの拒否、格下げ、または中間の攻撃が結果である可能性があります（リプレイされた属性のセット全体に応じておよびメッセージ）。
Countermeasures:
対策：
In order to prevent replay attacks, a freshness guarantee MUST be provided. As such, the TESLA bootstrapping message exchange MUST be unique and fresh, and the corresponding authentication and key exchange protocol MUST provide the same properties. In fact, it is essential to derive a unique and fresh session key as part of the authentication and key exchange protocol run that MUST be bound to the protocol session. This includes the exchanged parameters.
リプレイ攻撃を防ぐには、新鮮さの保証を提供する必要があります。そのため、テスラのブートストラップメッセージ交換は一意で新鮮でなければならず、対応する認証とキー交換プロトコルは同じプロパティを提供する必要があります。実際、プロトコルセッションにバインドする必要がある認証とキーエクスチェンジプロトコルの実行の一部として、ユニークで新鮮なセッションキーを導き出すことが不可欠です。これには、交換されたパラメーターが含まれます。
Threat:
脅威：
An adversary might be able to learn parameters and algorithms if he is located along the signaling path. This information can then later be used to mount attacks against the end-to-end multimedia communication. In some high-security and military environments, it might even be desirable not to reveal information about the used parameters to make it more difficult to launch an attack.
敵は、シグナリングパスに沿って配置されている場合、パラメーターとアルゴリズムを学習できる可能性があります。その後、この情報は、後でエンドツーエンドのマルチメディア通信に対する攻撃を取り付けるために使用できます。一部の高セキュリティおよび軍事環境では、使用済みのパラメーターに関する情報を明らかにして攻撃を開始することをより困難にすることが望ましいかもしれません。
Countermeasures:
対策：
Confidentiality protection can be provided by a subset of the available MIKEY authentication and key exchange protocols, namely, those providing public key encryption and symmetric key encryption. The initial hash key, which is also one of the TESLA bootstrapping parameters, does not require confidentiality protection due to the properties of a hash chain.
機密性保護は、利用可能なマイキー認証とキーエクスチェンジプロトコルのサブセット、つまり公開キー暗号化と対称キー暗号化を提供するものによって提供できます。テスラブートストラップパラメーターの1つでもある最初のハッシュキーは、ハッシュチェーンの特性のために機密保護を必要としません。
This document requires an IANA registration for the following attributes. The registries are provided by MIKEY [RFC3830].
このドキュメントでは、次の属性のIANA登録が必要です。レジストリはMikey [RFC3830]によって提供されます。
Prot Type:
PROTタイプ：
This attribute specifies the protocol type for the security protocol as described in Section 4.1.
この属性は、セクション4.1で説明されているセキュリティプロトコルのプロトコルタイプを指定します。
Type:
タイプ：
Identifies the type of the general payload. The General Extensions Payload was defined to allow possible extensions to MIKEY without the need for defining a completely new payload each time. Section 4.4 describes this attribute in more detail.
一般的なペイロードのタイプを識別します。一般的な拡張ペイロードは、毎回完全に新しいペイロードを定義する必要なく、Mikeyに可能な拡張機能を可能にするために定義されました。セクション4.4では、この属性について詳しく説明します。
Following the policies outlined in [RFC3830], the values in the range up to 240 (including 240) for the above attributes are assigned after expert review by the MSEC working group or its designated successor. The values in the range from 241 to 255 are reserved for private use.
[RFC3830]で概説されているポリシーに続いて、上記の属性の最大240（240を含む）の範囲の値は、MSECワーキンググループまたはその指定された後継者による専門家のレビューの後に割り当てられます。241〜255の範囲の値は、私的使用のために予約されています。
The IANA has added the following attributes and their respective values to an existing registry created in [RFC3830]:
IANAは、[RFC3830]で作成された既存のレジストリに次の属性とそれぞれの値を追加しました。
Prot Type:
PROTタイプ：
Prot Type | Value | Description
-----------------------------------------------------
TESLA | 1 | TESLA as a security protocol
The value of 1 for the 'Prot Type' must be added to the 'Prot type' registry created by [RFC3830].
[RFC3830]によって作成された「PROTタイプ」レジストリに「PROTタイプ」の値1の値を追加する必要があります。
Type:
タイプ：
Type | Value | Description
-------------------------------------------
TESLA I-Key | 2 | TESLA initial key
The value of 2 for the 'Type' must be added to the 'Type' registry created by [RFC3830]. The values of 0 and 1 are already registered in [RFC3830].
[タイプ]の値は、[RFC3830]によって作成された「タイプ」レジストリに追加する必要があります。0と1の値は、[RFC3830]に既に登録されています。
Also, the IANA has created two new registries:
また、IANAは2つの新しいレジストリを作成しました。
TESLA-PRF: Pseudo-random Function (PRF) used in the TESLA policy:
Tesla-PRF：テスラポリシーで使用される擬似ランダム機能（PRF）：
This attribute specifies values for pseudo-random functions used in the TESLA policy (see Section 4.2).
この属性は、Teslaポリシーで使用される擬似ランダム関数の値を指定します（セクション4.2を参照）。
TESLA-MAC: MAC Function used in TESLA:
Tesla-Mac：Teslaで使用されるMAC関数：
This attribute specifies values for pseudo-random functions used in the TESLA policy (see Section 4.2).
この属性は、Teslaポリシーで使用される擬似ランダム関数の値を指定します（セクション4.2を参照）。
Following the policies outlined in [RFC2434], the values for the TESLA-PRF and the TESLA-MAC registry in the range up to 240 (including 240) for the above attributes are assigned after expert review by the MSEC working group or its designated successor. The values in the range from 241 to 255 are reserved for private use.
[RFC2434]で概説されているポリシーに続いて、上記の属性について最大240（240を含む）までのTesla-PRFとTesla-Macレジストリの値は、MSECワーキンググループまたはその指定された後継者による専門家レビューの後に割り当てられます。241〜255の範囲の値は、私的使用のために予約されています。
IANA has added the following values to the TESLA-PRF and the TESLA-MAC registry:
IANAは、Tesla-PRFとTesla-Macレジストリに次の値を追加しました。
TESLA-PRF:
Tesla-PRF：
PRF Function | Value
--------------------------
HMAC-SHA1 | 0
TESLA-MAC:
テスラマック：
MAC Function | Value
--------------------------
HMAC-SHA1 | 0
The authors would like to thank Mark Baugher and Ran Canetti for the discussions in context of time synchronization. Additionally, we would like to thank Lakshminath Dondeti, Russ Housley, and Allison Mankin for their document reviews and for their guidance.
著者は、Mark Baugherに感謝し、時間同期の文脈での議論についてCanettiを実行したいと思います。さらに、Lakshminath Dondeti、Russ Housley、およびAllison Mankinのドキュメントレビューとガイダンスに感謝します。
[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月。
[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月。
[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月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082] Perrig、A.、Song、D.、Canetti、R.、Tygar、J。、およびB. Briscoe、「タイミング効率の高いストリーム損失耐性認証（TESLA）：マルチキャストソース認証変換紹介」、RFC 4082、2005年6月。
[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月。
[DHHMAC] Euchner, M., "HMAC-authenticated Diffie-Hellman for MIKEY", Work in Progress, April 2005.
[Dhhmac] Euchner、M。、「Hmac-authenticed Diffie-hellman for Mikey」、2005年4月、進行中の作業。
[PCST] Perrig, A., Canetti, R., Song, D., and D. Tygar, "Efficient and Secure Source Authentication for Multicast", in Proc. of Network and Distributed System Security Symposium NDSS 2001, pp. 35-46, 2001.
[PCST] Perrig、A.、Canetti、R.、Song、D。、およびD. Tygar、「マルチキャストの効率的かつ安全なソース認証」、Proc。ネットワークおよび分散型システムセキュリティシンポジウムNDSS 2001、pp。35-46、2001。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装」、RFC 1305、1992年3月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[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月。
[RSA-R] Ignjatic, D., "An additional mode of key distribution in MIKEY: MIKEY-RSA-R", Work in Progress, February 2006.
[RSA-R] Ignjatic、D。、「Mikeyの主要な分布の追加モード：Mikey-RSA-R」、2006年2月、進行中の作業。
Authors' Addresses
著者のアドレス
Steffen Fries Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Steffen Fries Siemens Otto-Hahn-Ring6 Munich、Bavaria 81739ドイツ
EMail: steffen.fries@siemens.com
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich、Bavaria 81739ドイツ
EMail: Hannes.Tschofenig@siemens.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）によって提供されます。