RFC4442 日本語訳
4442 Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication(TESLA). S. Fries, H. Tschofenig. March 2006. (Format: TXT=37345 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Fries
Request for Comments: 4442 H. Tschofenig
Category: Standards Track Siemens
March 2006
フライドポテトがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4442時間Tschofenigカテゴリ: 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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
テスラ(Timed Efficient Stream Loss許容性があるAuthenticationプロトコル)はマルチキャストシナリオで認証をソースに提供します。 テスラは、多くの受信機に比例する少ないコミュニケーションと計算オーバーヘッドがある効率的なプロトコルであり、また、パケット損失を黙認します。 テスラは送付者と受信機の間のゆるい時間同期化に基づいています。 ソース認証は、テスラにメッセージ立証コード(MAC)推論を使用することによって、実現されます。 Secureレアル-時間Transportプロトコル(SRTP)の中のテスラの使用は発行されました、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を使用することでテスラを独力で進むとMultimediaインターネットKeying(マイキー)プロトコルにペイロードを指定します。 テスラはマイキーかぎ管理アプローチの1つを使用することで独力で進まれるかもしれません、例えば、ユニキャスト、マルチキャスト、または放送で送られたデジタルに署名しているマイキーメッセージを使用することによって。
Fries & Tschofenig Standards Track [Page 1] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[1ページ]RFC4442
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. 序論…3 2. 用語…4 3. テスラパラメタ概要…4 4. マイキーの中のパラメタコード化…6 4.1. 安全保障政策(SP)有効搭載量…6 4.2. テスラ方針…7 4.3. 時間同期化…8 4.4. 重要なデータはマイキーの一般拡大の中で有効搭載量を輸送します…10 5. セキュリティ問題…11 5.1. 中央の男性攻撃…11 5.2. 攻撃を格下げします…12 5.3. サービス妨害攻撃…12 5.4. 反射攻撃…13 5.5. トラフィック分析…13 6. IANA問題…14 7. 承認…15 8. 参照…16 8.1. 標準の参照…16 8.2. 有益な参照…16
Fries & Tschofenig Standards Track [Page 2] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[2ページ]RFC4442
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.
多くのマルチキャスト、放送、およびユニキャストコミュニケーションシナリオでは、受信されたメッセージがひたむきなソースから送られて、トランジットで変更されていないのを保証するのが必要です。 ユニキャストコミュニケーションでは、一般的にメッセージの保全とデータ発生源の合法化を可能にする対状セキュリティ協会は存在します。 グループベースのコミュニケーションにおけるアプローチは異なっています、ここで、キーが、通常、グループのメンバーの間で共有されて、その結果、データ発生源認証に使用されないかもしれません。 使用目的によっては送付者のひたむきな識別が必要であるように、データがマルチキャストシナリオでも発生源認証であるとサポートするという要件は存在しています。 これをサポートするメソッドの1つはテスラ[RFC4082]です。 テスラは、マルチキャストシナリオで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.
マルチキャストシナリオにおけるソース認証のために、テスラ[RFC4082]をサポートして、[RFC4383]はSRTP[RFC3711]のために拡大について説明します。 SRTPの必要性は保護されるためにマルチメディアセッションあたりのセキュリティパラメタと安全保障政策を説明する暗号の文脈を捧げました。 この暗号の文脈は、1セットのテスラパラメタで高められる必要があります。 実際のマルチキャストセッションが始まる前にこれらのパラメタを提供するのが必要です。 [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.
初期のキーと同様にテスラ方針のためのパラメータ分布によるテスラパラメタのこのドキュメント詳細ブートストラップ法、Multimediaを使用して、インターネットKeying(マイキー)[RFC3830]は議定書を作ります。 マイキーはリアルタイムのアプリケーション(ピアツーピアコミュニケーションとグループコミュニケーションのための)に使用できる認証とかぎ管理フレームワークを定義します。 特に、[RFC3830]は、他の目的にも使用されるためにそれが第一にSRTPをサポートすることを意図しますが、増進に開かれている方法で定義されます。 [RFC3830]で記述に続いて、マイキーはグループコミュニケーションと同様にポイントのポイントに狙います。 グループコミュニケーションの文脈では、管理者実体はコミュニケーションセッションのときに参加する関連実体のセッションキーを分配できます。 また、テスラにとって、このシナリオも1つの実体がコミュニケートしている情報の保全を保証できる方法で多くの他のものに情報を提供するかもしれないところで適切です。 マイキーとテスラの組み合わせは、すべてのかかわった実体にテスラパラメタ情報を分配するのにマイキーフレームワークを利用することによって、このグループベースのアプローチをサポートします。 このドキュメントがそれらのパラメタの世代ではなく、パラメタの分配だけに焦点を合わせることに注意してください。
MIKEY [RFC3830] itself describes three authentication and key exchange protocols (symmetric key encryption, public key encryption,
マイキー[RFC3830]自身が3つの認証と主要な交換プロトコルについて説明する、(対称鍵暗号化、公開鍵暗号化
Fries & Tschofenig Standards Track [Page 3] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[3ページ]RFC4442
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.
署名しているディフィー-ヘルマン) マイキーキー交換メソッドへの拡大は定義されました。 4番目の主要な分配メソッドは、[DHHMAC]によって提供されて、対称的に保護されたディフィーヘルマンキー協定について説明します。 さらなるオプションはまた、「不-バンド」が証明書交換であるとサポートして、高められた非対称の交換異形について説明する[RSA-R]で提案されました。 前記のようにすべての異なったかぎ管理体系が、テスラパラメタを提供するのに使用されるかもしれません。 必要な交換されるべきテスラパラメタは[RFC4383]で既に説明されますが、このドキュメントはマイキーの中で彼らの輸送について説明します。
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 テスラパラメタを送るとき、認証とIntegrityを提供しなければなりません、特に初期のキーのために。o Confidentialityをテスラパラメタに提供するかもしれません。
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].
これらのセキュリティ要件はテスラブートストラップ法手順だけに適用されます。 テスラを使用するアプリケーションのためのセキュリティ要件はこのドキュメントの範囲を超えています。 テスラ自身に関連するセキュリティ局面が[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つの断片であることに注意するのは重要です。 (a) メディアトラフィックが[RFC4383]で説明されるようにテスラを使用することで機密保護されることであると仮定する場合、テスラへの材料を合わせて、(b)パラメタが必要です。 このドキュメントは材料を合わせるのに供給するのにマイキーで使用されるパラメタと認証方法を寄付します。 また、テスラへのパラメータ変換は、改ざんに対して機密保護される必要があります。 また、この保護はマイキーによって提供されます。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. TESLA Parameter Overview
3. テスラパラメタ概要
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が本書ではそれを計算できるので省略されることに注意してください。
Fries & Tschofenig Standards Track [Page 4] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[4ページ]RFC4442
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.
マイキーは既に連動している時計を必要とします(また、テスラのために同期に備えます)。 そのうえ、セクション4.3は、送付者と受信機の間の時計ドリフト決断にマイキーを使用するためにオプションを述べます。その結果、マイキーでこのパラメタによって直接伝えられる必要はありません。
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. 一方向関数Fがテスラ(チェーンでキーを引き出す)の(x)であり、一方向関数Fが'(x) テスラ(TESLA MACのためにキーからチェーンでキーを引き出す)では、例えば合わせられたハッシュを示すのは機能します(デフォルトHMAC-SHA1)'であると実装するPRF(TESLA PRF)のための識別子。
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が噛み付いたデフォルト)で使用されるなら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の出力の長さを測定する非負の整数'、すなわち、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. TESLA MACに関して、それはFの出力を受け入れます。識別子、'(x) キーとして、例えば合わせられた論じ尽くすことを示すのは機能(デフォルトHMAC-SHA1)'。
5. A non-negative integer, determining the length of the output of
the TESLA MAC (default 80 bit).
5. 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. 送付者が立場を明らかにしたチェーンの初期のキー。
Fries & Tschofenig Standards Track [Page 5] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[5ページ]RFC4442
4. Parameter Encoding within 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で言及されるように、テスラパラメタは、実際にセッションを始める前に輸送される必要があります。 マイキーは、現在、SRTP方針を輸送するためにペイロードを定義するだけです([RFC3830]のセクション6.10を見てください)。 このセクションはさらに、テスラ方針の輸送を許容するマイキーの増進について説明します。初期のテスラキー。
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].
Security Policyペイロードは特定のセキュリティプロトコルに適用される1セットの方針を定義します。 ここでの定義は[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ビット): 地元の同輩は現在のマイキーセッションの異なった数をそれぞれの安全保障政策ペイロードに与えなければなりません。 この数は、暗号のセッションを特定保険証券に写像するのに使用されます(また、.1セクション6.1[RFC3830]を見てください)。
* 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番目の値は、以下に示すように定義される必要があります: (マイキーは既に値0を定義します。)
Prot type | Value |
---------------------------
SRTP | 0 |
TESLA | 1 |
Protはタイプします。| 値| --------------------------- SRTP| 0 | テスラ| 1 |
* Policy param length (16 bits):
This field defines the total length of the
policy parameters for the selected security protocol.
* 方針paramの長さ(16ビット): この分野は選択されたセキュリティプロトコルのための方針パラメタの全長を定義します。
Fries & Tschofenig Standards Track [Page 6] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[6ページ]RFC4442
* 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.
Policy param部分は1セットのType/長さ/値(TLV)のペイロードによって確立されます。 それぞれのセキュリティプロトコルにおいて、定義されるように1セットの可能なタイプ/値の組を交渉できます。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (8 bits):
Specifies the type of the parameter.
* タイプしてください(8ビット): パラメタのタイプを指定します。
* Length (8 bits):
Specifies the length of the Value field (in bytes).
* 長さ(8ビット): Value分野(バイトによる)の長さを指定します。
* Value (variable length):
Specifies the value of the parameter.
* (可変長さ)を評価してください: パラメタの値を指定します。
4.2. TESLA Policy
4.2. テスラ方針
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
タイプ| 意味| 可能な値--------------------------------------------------------------- 1 | 'fとfのためのPRF識別子'、わかること| F(x)とFより下で'(x)2'を見てください。| 'PRF fの長さ'出力| 160 3 | テスラMACのための識別子| 4未満を見てください。| TESLA MAC出力の長さ| 80 (端が欠ける)の5| セッションの始まり| バイト6で| 間隔持続時間(msecにおける)| バイト7で| 主要な公開遅れ| バイト8で| キーチェーンの長さ(間隔の数)| バイト9で| 地方のタイムスタンプメディア受信機| 以下を見てください。
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
時間的価値は、項目5と9SHALLにNTP- UTC形式で輸送されるように述べました。(形式は[RFC3830]のセクション6.6で説明された3つのオプションの1つです)。 方針項目6のための4バイトの整数値と方針項目7のための2バイトの整数値はRECOMMENDEDです、間隔持続時間と主要な公開遅れを運んで。 9が述べた方針タイプ
Fries & Tschofenig Standards Track [Page 7] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[7ページ]RFC4442
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.
上は任意です、そして、時間同期化が中でセクション4.3について説明したならSHOULDが使用されて、ポイントtwoは使用されています。 そうでなければ、それ、SHOULD、省略されてください。
For the PRF realizing F(x) and F'(x), a one-byte length is
sufficient. The currently defined possible values are:
PRF換金F(x)とFでは、'(x)、1バイトの長さは十分です'。 現在定義された可能な値は以下の通りです。
TESLA PRF F(x), F'(x) | Value
------------------------------
HMAC-SHA1 | 0
テスラPRF F(x)、F'(x)'| 値------------------------------ 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
テスラMac| 値----------------------- 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:
テスラが交信の時間同期化を必要とするとき、また、マイキーはじっと見ます。 マイキーは、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]の中で既にお勧めです。 このアプローチの利点は半分往復旅行の中で働くマイキーかぎ管理異形を使用するオプションです。 不都合は追加議定書を通した必要な時間同期化です。
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における可能な「不-バンド」同期についてスケッチします。 このアプローチはここ、マイキーの文脈にまとめられます。 ここに、実際のテスラ方針ペイロードがマイキー応答者メッセージの一部として伝えられることに注意してください。
* 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.
* データ受信装置。(そのデータ受信装置は、マイキー創始者であるだろう、現地時間パラメタt_rを設定して、[RFC3830]の説明されるとしてのタイムスタンプペイロードの一部としてそれを送ります)。 この値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
* マイキー創始者メッセージを受け取り次第、データ送付者はデータ受信装置(パラメタ11)でマイキー応答者メッセージ、現地時間が押し込む設定で値t_rに関して返答します。
Fries & Tschofenig Standards Track [Page 8] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[8ページ]RFC4442
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].
マイキー創始者メッセージで受信して、[RFC3830]で説明されるようにタイムスタンプペイロードに64ビットのUTC値のt_sとして現地時間で彼のものを設定します。
MIKEY initiator message
[MIKEY parameter incl. local timestamp (t_r)]
------------------>
マイキー創始者メッセージ[マイキーパラメタinclローカルのタイムスタンプ(t_r)]------------------>。
MIKEY responder message
[MIKEY parameter incl. local timestamp (t_s), TESLA policy
payload, received local time stamp t_r]
<------------------
マイキー応答者メッセージ[マイキーパラメタinclローカルのタイムスタンプ(t_s)(テスラ方針ペイロード)は現地時間スタンプ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.
* マイキー応答者メッセージを受け取ると、データ受信装置セット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.
このアプローチで、それがする利点は追加時間同期化プロトコルを必要としません。 不都合は完全なマイキー握手を実行して、正しいパラメタ輸送を可能にする必要性です。 そのうえ、このアプローチは方向に依存しています、それがまた、メディア受信機がマイキー創始者である場合にだけ適用されるとき。
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)を使用する同期は時計同期のためのRECOMMENDEDアプローチです。 またメディア受信機がマイキー創始者便乗であるシナリオでは、マイキー(すなわち、代替の2)のタイムスタンプ情報は、送付者と受信機の間の時計ドリフトの「不-バンド」決断を考慮するのに使用されるかもしれません。
Fries & Tschofenig Standards Track [Page 9] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[9ページ]RFC4442
4.4. Key Data Transport within MIKEY's General Extension Payload
4.4. マイキーの一般拡大有効搭載量の中の重要なデータ輸送
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.
一般Extensions有効搭載量は、その都度完全に新しいペイロードを定義する必要性なしで可能な拡大をマイキーに許すために定義されました。 このペイロードは、どんなマイキーメッセージでも使用できて、認証されたか署名しているデータ部分の一部です。
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ビット): 一般的なペイロードのタイプを特定します。 マイキーは既に値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
タイプ| 値| コメント---------------------------------------------------- ベンダーID| 0 | ベンダーの特定のバイトストリングSDP ID| 1 | SDPの主要な管理IDテスラI-キーのリスト| 2 | テスラ初期のキー
* Length (16 bits):
The length in bytes of the Data field.
* 長さ(16ビット): Data分野のバイトで表現される長さ。
* Data (variable length):
The general payload data.
* データ(可変長): 一般的なペイロードデータ。
Fries & Tschofenig Standards Track [Page 10] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[10ページ]RFC4442
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.
マルチキャストシナリオにおけるソース認証のために、テスラ[RFC4082]をサポートして、SRTP-テスラ[RFC4383]はSRTP[RFC3711]のために拡大について説明します。 そういうものとして、テスラ([PCST]と[RFC4082]を見る)、[RFC4383]を写像するTESLA SRTP、および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.
その上、MultimediaインターネットKeying(マイキー)[RFC3830]プロトコルを使用しているテスラのこのドキュメント詳細ブートストラップ法以来、マイキーのセキュリティ問題はこのドキュメントに適切です。
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 マイキー[RFC3830]は、認証と合わせることの材料の安全な分配を実行するために必要な実体の間で処刑されます。 次にテスラを使用するために、本書では説明されたパラメタはマイキーを使用することで分散されています。 マイキー自身はすなわち、パラメタ輸送、Session記述プロトコル(SDP)[RFC2327]に別のプロトコルを使用します。 SDPは、必要な実体の間のセッションをセットアップするのに再びSession Initiationプロトコル(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-テスラ[RFC4383]を通したデータ通信量保護を使用できます。 SRTP-テスラ自身はSRTPプロトコル、およびそういうものとしてテスラのガイドラインが続かれるように必要とする処理にテスラを適用します。
5.1. Man-in-the-Middle Attack
5.1. 介入者攻撃
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
ドキュメント中では、パラメータ変換がすなわち、別のプロトコルを使用する交換パラメタであることが保証されると思われます。
Fries & Tschofenig Standards Track [Page 11] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[11ページ]RFC4442
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.
そして、アルゴリズムは認証と主要な交換プロトコル(すなわち、マイキー)の一部です。 先のシグナリング交換がソースを認証するために便宜を与えなかったなら、グループとマルチキャストコミュニケーションのソース認証をデータ通信量に提供できません。 必要なパラメタを引き出すのがうまくいっているプロトコル交換の一部で不可能になるときセッションキーを提供しない認証プロトコルを使用するのがテスラが必要です。 マイキーはセッションの主要な設立を提供します。 さらに、パラメタとアルゴリズムの交換を認証しなければなりませんでした、そして、保全は保護されました。 パラメータ変換の機密保持は、同じレベルか、より高いレベルのセキュリティを提供する必要があります。
5.2. Downgrading Attack
5.2. 攻撃を格下げします。
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.
テスラパラメタブートストラップ法はパラメタとそれらの値の変更を防ぐために保護された保全であるに違いありません。 そのうえ、未知の情報源からの変更されていないパラメタが役に立たないので、認証を提供しなければなりません。 この機能性は本書では説明されたメカニズムによって提供されません。 代わりに、基本的な認証と主要な交換プロトコル(マイキー)の能力はこのために再利用されます。
5.3. Denial of Service Attack
5.3. サービス不能攻撃
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.
敵はそれぞれのコミュニケーション実体で異なった州の情報を確立するために交信実体の間で交換されたパラメタを変更したがっているかもしれません。 例えば、敵は、テスラアルゴリズムが、参加しているコミュニケーション実体が、同じパラメタがセットしたのを知っていると仮定するので後の状態で通信システムを遮断するように主要な公開遅れか間隔持続時間を変更したがっているかもしれません。
Fries & Tschofenig Standards Track [Page 12] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[12ページ]RFC4442
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.
交換されたパラメタ、パラメタ、およびアルゴリズムは受取人が、敵が、交換された情報を変更するのを試みたかどうか検出するのを許容するために保護された保全であるに違いありません。 認証とマイキーによって提供された主要な交換アルゴリズムはこの保護を提供します。
5.4. Replay Attack
5.4. 反射攻撃
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つを立ち聞きできる敵か複数のプロトコル交換(パラメタが本書では説明されているマイキー交換)が後のプロトコル交換でペイロードを再演できるかもしれません。 受取人がパラメタとアルゴリズム(または、これらのペイロードを運ぶメッセージさえ)を受け入れるなら、サービス、格下げ、または介入者攻撃の否定は結果であるかもしれません(再演された属性とメッセージの全体のセットによって)。
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.
反射攻撃を防ぐために、新しさ保証を提供しなければなりません。 そういうものとして、テスラブートストラップ法交換処理は、ユニークであって、新鮮でなければなりません、そして、対応する認証と主要な交換プロトコルは同じ資産を提供しなければなりません。 事実上、制限されるに違いない認証と主要な交換プロトコル走行の一部として主要なユニークで新鮮なプロトコルセッションまでのセッションを引き出すのは不可欠です。 これは交換されたパラメタを含んでいます。
5.5. Traffic Analysis
5.5. トラヒック分析
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
すなわち、利用可能なマイキー認証と主要な交換プロトコルの部分集合、公開鍵暗号化と対称鍵を提供するものは秘密性保護を提供できます。
Fries & Tschofenig Standards Track [Page 13] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[13ページ]RFC4442
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つである)はハッシュチェーンの特性による秘密性保護を必要としません。
6. IANA Considerations
6. IANA問題
This document requires an IANA registration for the following attributes. The registries are provided by MIKEY [RFC3830].
このドキュメントは以下の属性のためのIANA登録を必要とします。 登録はマイキー[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.
一般的なペイロードのタイプを特定します。 一般Extensions有効搭載量は、その都度完全に新しいペイロードを定義する必要性なしで可能な拡大をマイキーに許すために定義されました。 セクション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
Protはタイプします。| 値| 記述----------------------------------------------------- テスラ| 1 | セキュリティプロトコルとしてのテスラ
The value of 1 for the 'Prot Type' must be added to the 'Prot type' registry created by [RFC3830].
[RFC3830]によって作成された'Protタイプ'登録に'Prot Type'のための1の価値を高めなければなりません。
Type:
以下をタイプしてください。
Type | Value | Description
-------------------------------------------
TESLA I-Key | 2 | TESLA initial key
タイプ| 値| 記述------------------------------------------- テスラI-キー| 2 | テスラ初期のキー
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]によって作成された'タイプ'登録に'タイプ'のための2の価値を高めなければなりません。 0と1の値は[RFC3830]に既に示されます。
Fries & Tschofenig Standards Track [Page 14] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[14ページ]RFC4442
Also, the IANA has created two new registries:
また、IANAは2つの新しい登録を作成しました:
TESLA-PRF: Pseudo-random Function (PRF) used in the TESLA policy:
テスラ-PRF: テスラ方針で使用される擬似ランダムFunction(PRF):
This attribute specifies values for pseudo-random functions used
in the TESLA policy (see Section 4.2).
この属性はテスラ方針で使用される擬似ランダム機能に値を指定します(セクション4.2を見てください)。
TESLA-MAC: MAC Function used in TESLA:
テスラ-Mac: テスラで中古のMAC Function:
This attribute specifies values for pseudo-random functions used
in the TESLA policy (see Section 4.2).
この属性はテスラ方針で使用される擬似ランダム機能に値を指定します(セクション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]に概説された方針に従って、上の属性のためのテスラ-PRFのための値と最大240(240を含んでいる)の範囲でのテスラ-MAC登録はMSECワーキンググループかその指定された後継者による専門のレビューの後に割り当てられます。 241〜255までの範囲の値は私的使用目的で予約されます。
IANA has added the following values to the TESLA-PRF and the TESLA-MAC registry:
IANAはテスラ-PRFとテスラ-MAC登録に以下の値を加えました:
TESLA-PRF:
テスラ-PRF:
PRF Function | Value
--------------------------
HMAC-SHA1 | 0
PRF機能| 値-------------------------- HMAC-SHA1| 0
TESLA-MAC:
テスラ-Mac:
MAC Function | Value
--------------------------
HMAC-SHA1 | 0
MAC機能| 値-------------------------- 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とRanカネッティに感謝したがっています。 さらに、彼らのドキュメントレビューと彼らの指導についてLakshminath Dondeti、ラスHousley、およびアリソン・マンキンに感謝申し上げます。
Fries & Tschofenig Standards Track [Page 15] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[15ページ]RFC4442
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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(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.、ジーター、M.、およびK.Norrman、「マイキー:」 「マルチメディアインターネットの合わせる」RFC3830、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.ブリスコウ、「効率的な状態で調節されて、損失許容性がある認証(テスラ)を流してください」 「マルチキャストソース認証変換序論」、RFC4082、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.カラーラ、「安全なリアルタイムのトランスポート・プロトコル(SRTP)における調節された効率的なストリーム損失許容性がある認証(テスラ)の使用」、RFC4383、2006年2月。
8.2. Informative References
8.2. 有益な参照
[DHHMAC] Euchner, M., "HMAC-authenticated Diffie-Hellman for
MIKEY", Work in Progress, April 2005.
M.、「マイキーのためのHMACによって認証されたディフィー-ヘルマン」という[DHHMAC]Euchnerは進歩、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.とカネッティとR.とSong、D.とD.Tygar、「マルチキャストのための効率的で安全なソース認証」Proc NetworkとDistributed System Security Symposium NDSS2001、ページについて 35-46, 2001.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC1305] 工場、D.、「ネットワーク時間プロトコル(バージョン3)仕様、実装」RFC1305、3月1992日
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC2327] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Fries & Tschofenig Standards Track [Page 16] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[16ページ]RFC4442
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3711] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[RSA-R] Ignjatic, D., "An additional mode of key distribution in
MIKEY: MIKEY-RSA-R", Work in Progress, February 2006.
[RSA-R]Ignjatic、D.、「マイキーの主要な分配の追加方法:」 「マイキー-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
Fries & Tschofenig Standards Track [Page 17] RFC 4442 Bootstrapping TESLA March 2006
2006年のテスラ行進のときに独力で進むフリーズとTschofenig標準化過程[17ページ]RFC4442
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Fries & Tschofenig Standards Track [Page 18]
フライドポテトとTschofenig標準化過程[18ページ]
一覧
スポンサーリンク
