RFC 4442 - Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA) 日本語訳

URL : https://tools.ietf.org/html/rfc4442
タイトル : RFC 4442 - ブートストラップ時限効率的なストリーム損失トレラント認証（TESLA）
翻訳編集 : 自動生成

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)

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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（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は、マルチメディアデータを保護するために適用されるシナリオでは、マルチキャスト認証を対象に、公開されています。この溶液をTESLAパラメータは、アウトオブバンドメカニズムによって利用可能にされることを前提としています。

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）プロトコルのペイロードを指定します。テスラは、ユニキャスト、マルチキャスト、またはブロードキャストを介して送信されたデジタル署名MIKEYメッセージを用いて、例えば、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

1. Introduction

1. はじめに

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.

多くのマルチキャスト、ブロードキャスト、ユニキャスト通信のシナリオでは、受信したメッセージが専用のソースから送信されており、中に改ざんされていないことを保証する必要があります。ユニキャスト通信では、一般的ペアワイズセキュリティアソシエーションは、メッセージの整合性とデータ起源の検証を可能に存在します。キーは、通常、グループのメンバー間で共有されるので、データ発信元認証のために使用されない場合があり、ここでのように、グループベースの通信におけるアプローチは、異なっています。いくつかの用途では、送信者の専用の識別が必要とされるように、マルチキャストのシナリオでも、データ発信元認証をサポートするための要件が存在します。これを支持する方法の一つは、テスラ[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は、保護されるべきマルチメディアセッションごとにセキュリティ・パラメータとセキュリティポリシーを記述した専用の暗号コンテキストを必要とします。この暗号コンテキストは、TESLAのパラメータのセットで強化する必要があります。実際のマルチキャストセッションが開始される前に、これらのパラメータを提供することが必要です。 [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は、ポイントツーポイントならびにグループ通信のために標的化されます。グループ通信の文脈では、管理エンティティは、通信セッションに参加して関連するエンティティへのセッション鍵を配布することができます。このシナリオでは、一方のエンティティが通信される情報の完全性を保証することができるような方法で多くの人に情報を提供することができるTESLAのためにも適用可能です。マイキーとTESLAの組み合わせは、すべての関連するエンティティにTESLAのパラメータ情報を配布するためにMIKEYフレームワークを利用することにより、このグループベースのアプローチをサポートしています。このドキュメントではなく、これらのパラメータの生成に、パラメータのみの分布に焦点を当てていることに注意してください。

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鍵交換方式への拡張が定義されています。第四の鍵配布方法は、[DHHMAC]によって提供され、対称的に保護されたディフィー・ヘルマン鍵合意を記載しています。さらなるオプションは、証明書の交換をインバンドサポート、拡張非対称交換変異体を記載している[RSA-R]で提案されています。上述のすべての異なる鍵管理スキームがTESLAのパラメータを提供するために使用することができます。この文書はMIKEY内のそれらの輸送を説明しながら、交換する必要がTESLAのパラメータが既に、[RFC4383]に記載されています。

The following security requirements have to be placed on the exchange of TESLA parameters:

以下のセキュリティ要件は、TESLAのパラメータの交換を上に配置する必要があります：

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.

特に最初のキーに、TESLAパラメータを送信するとき、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のブートストラップ手順にのみ適用されます。 TESLAを使用してアプリケーションのセキュリティ要件は、このドキュメントの範囲を超えています。 SRTP用TESLAの利用のために[RFC4082]で説明されているTESLA自体に関連するセキュリティ面、およびセキュリティ上の問題は[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]に記載されているように、メディアトラフィックはTESLAを用いて固定されると仮定すると、（a）は、鍵材料と、（b）TESLAのパラメータが必要です。この文書では、パラメータと合わせることの材料を提供するために、MIKEYで使用される認証方法を貢献しています。 TESLAのためのパラメータ交換も改ざんから保護する必要があります。この保護はまた、MIKEYによって提供されます。

2. Terminology

2.用語

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]に記載されているように解釈されます。

3. TESLA Parameter Overview

3. TESLAパラメータの概要

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]によれば、変換に依存するパラメータの数は、適切なTESLA動作のために提供される必要があります。パラメータの完全なリストは、[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はすでにもTESLAの同期のために提供して同期したクロックを必要とします。また、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).

TESLA 1. PRF（TESLA PRF）の識別子、一方向関数TESLAにおけるF（X）を（チェーン内のキーを導出するために）を実装し、一方向関数F '（x）は（導出しますチェーン内のキー）、例えば、からTESLA 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).

F出力の長さを決定する。2.非負の整数、すなわち、TESLAは、SRTPの文脈で使用される場合も、SRTPパケットに開示されているキーであるチェーン、（デフォルト160ビット）のキーの長さ。

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).

Fの出力」の長さを決定する前記非負の整数、すなわち、TESLA 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）の出力を受け付けるTESLA MACのための識別子は、鍵付きハッシュ関数（既定HMAC-SHA1）を示します。

5. A non-negative integer, determining the length of the output of the TESLA MAC (default 80 bit).

5. A非負整数、TESLA 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.送信者が自分自身をコミットしているにチェーンの最初の鍵。

4. Parameter Encoding within MIKEY

MIKEY内4.パラメータの符号化

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節で述べたように、TESLAのパラメータは、実際にセッションを開始する前に輸送する必要があります。 MIKEYは、現在のみ（[RFC3830]のセクション6.10を参照）SRTPポリシーを輸送するためのペイロードを定義します。このセクションでは、TESLAポリシー、さらに初期TESLAキーの輸送を可能にするために、MIKEYの拡張を記述しています。

4.1. Security Policy (SP) Payload

4.1. セキュリティポリシー（SP）ペイロード

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ビット）：各セキュリティポリシーペイロードがローカルピアによって現在MIKEYセッションの異なる番号を与えられなければなりません。この番号は、（また、[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ビット）：この値は、セキュリティプロトコルを定義します。（MIKEYが既に値0を定義する）：第2の値は以下のように定義される必要があります

         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.

*ポリシーPARAM長（16ビット）：このフィールドは、選択されたセキュリティプロトコルのポリシーパラメータの全体の長さを規定します。

* Policy param (variable length): This field defines the policy for the specific security protocol.

*ポリシーのparam（可変長）：このフィールドは、特定のセキュリティプロトコルのためのポリシーを定義します。

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.

ポリシーのparamパートは、タイプ/長さ/値（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.

*値（可変長）：パラメータの値を指定します。

4.2. TESLA Policy

4.2. TESLAポリシー

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:

このポリシーは、TESLAのパラメータを指定します。ネゴシエートすることができる種類/値は次の表によって定義されます。具体的なデフォルト値は[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つのオプションのいずれかであるNTP-UTC形式で輸送しなければなりません。ポリシー項目6とポリシー項目7用の2バイトの整数値の4バイトの整数値は、間隔の持続時間と鍵開示遅延を担持する、推奨されます。上述したポリシータイプ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

4.3. Time Synchronization

4.3. 時刻同期

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などTESLAは、通信ピアの時刻同期を必要とします。 MIKEYは一往復の認証と鍵交換プロトコル用のタイムスタンプベースのリプレイ保護を提供するために、時刻同期が必要です。テスラは、一方で、適切に開示されたキーを解放するために、送信側と受信側との間のクロックドリフトを決定するためにこの情報を必要とします。 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.

NTP [RFC1305]を使用して、帯域外同期1.使用。このアプローチは、すでに[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で可能帯域内同期をスケッチ。このアプローチは、マイキーの文脈でここに要約されます。ここで、実際のTESLAポリシーペイロードはMIKEYの応答メッセージの一部として送信されることに留意されたいです。

       *  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.

* 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開始メッセージを受信すると、データ送信者はT_RはMIKEY開始メッセージで受信した値にデータ受信（パラメータ11）のローカルタイムスタンプを設定し、MIKEYの応答メッセージで応答し、そして64として彼のローカル時間を設定しますタイムスタンプペイロードにおけるビットUTC値T_S [RFC3830]に記載されているように。

           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.

+ S T_R、Sが推定セッション期間にわたってクロックドリフトに結合している - * MIKEYの応答メッセージを受信するデータ受信部は、D_t = T_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ハンドシェイクを実行する必要があることです。メディア受信機はまた、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）クロック同期のために推奨されるアプローチです。メディア受信機はまた、MIKEYにタイムスタンプ情報をピギーバックMIKEYイニシエータであるシナリオでは（すなわち、別の2）は送信側と受信側との間のクロックドリフトの帯域内決意を可能にするために使用されるかもしれません。

4.4. Key Data Transport within MIKEY's General Extension Payload

4.4. MIKEYの一般的な拡張ペイロード内のキーデータ転送

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に可能な拡張を可能にするために定義されました。このペイロードは任意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は既にこのドキュメントでは、新しい値（2）を導入値0と1を定義します。

         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.

*データ（可変長）：一般的なペイロードデータ。

5. Security Considerations

5.セキュリティについての考慮事項

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]のための拡張機能について説明します。このように、TESLA（[PCST]参照[RFC4082]）、TESLA SRTPマッピング[RFC4383]、およびSRTP [RFC3711]自体で説明したセキュリティ上の考慮事項は、このコンテキストに関連しています。

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].

「Protの種類」の1の値は、[RFC3830]によって作成された「Protの種類」レジストリに追加されなければなりません。

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].

「タイプ」2の値は、[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：TESLAポリシーで使用される擬似ランダム関数（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]に概説された方針に続き、TESLA-PRFと上記の属性のための（240を含む）240までの範囲で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:

TESLA-MAC：

            MAC Function     | Value
            --------------------------
            HMAC-SHA1        |  0

7. Acknowledgements

7.謝辞

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.

著者はマークBaugherに感謝したいと時刻同期の文脈で議論をカネッティ蘭でしょう。さらに、我々は彼らの文書をレビュー用にと指導のためにLakshminath Dondeti、ラスHousley、およびアリソンマンキンに感謝したいと思います。

8. References

8.参照文献

8.1. Normative References

8.1. 引用規格

[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月。

[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.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、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.、歌、D.、カネッティ、R.、Tygar、J.、およびB.ブリスコウ、 "時限効率ストリーム損失トレラント認証（テスラ）：マルチキャスト発信元認証は、はじめの変換"、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.とE.カララ、RFC 4383、2006年2月「時限効率的なストリーム損失トレラントセキュアリアルタイム転送プロトコル（SRTP）での認証（TESLA）の使用」。

8.2. Informative References

8.2. 参考文献

[DHHMAC] Euchner, M., "HMAC-authenticated Diffie-Hellman for MIKEY", Work in Progress, April 2005.

[DHHMAC] EUCHNER、M.、 "MIKEYのためのHMAC-認証済みのDiffie-Hellmanは"、進歩、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.、PROCでカネッティ、R.、歌、D.、およびD. Tygar、 "マルチキャストのための効率的で安全なソース認証"。ネットワークと分散システムセキュリティシンポジウムNDSS 2001、頁35-46、2001。

[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.

[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装"、RFC 1305、1992年3月。

[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.

[RFC2327]ハンドリー、M.および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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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.、マグリュー、D.、Naslund、M.、カララ、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

ステファンのフリースシーメンスオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ

EMail: steffen.fries@siemens.com

メールアドレス：steffen.fries@siemens.com

Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany

ハンネスTschofenigシーメンスオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ

EMail: Hannes.Tschofenig@siemens.com

メールアドレス：Hannes.Tschofenig@siemens.com

Full Copyright Statement

完全な著作権声明

著作権（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）によって提供されます。