Network Working Group A. Perrig
Request for Comments: 4082 D. Song
Category: Informational Carnegie Mellon University
R. Canetti
IBM
J. D. Tygar
University of California, Berkeley
B. Briscoe
BT
June 2005
Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
Multicast Source Authentication Transform Introduction
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document introduces Timed Efficient Stream Loss-tolerant Authentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties.
この文書では、時限効率的なストリーム損失トレラント認証（TESLA）を紹介します。 TESLAは、すべての受信機は、整合性をチェックして、マルチキャストまたはブロードキャストデータストリーム内の各パケットの送信元を認証することができます。テスラは、受信機の間に信頼関係を必要としない送信側と受信側の両方でパケットごとの低コストオペレーションを使用して、再送信することなく、損失の任意のレベルに耐えることができ、送信者でない単位の受信状態を必要としません。 TESLAは、特定の状況では、サービス拒否攻撃から受信機を保護することができます。各受信機は緩やかに時間同期メッセージを確認するために、ソースである必要がありますが、それ以外の受信機は、任意のメッセージを送信する必要はありません。 TESLAだけでは第三者へのデータソースの否認防止をサポートすることはできません。
This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts.
この情報のドキュメントは、異なるコンテキストでTESLAに基づくプロトコルに対して標準化し、安全な仕様を書くのを支援することを意図しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Notation ...................................................3
2. Functionality ...................................................4
2.1. Threat Model and Security Guarantee ........................5
2.2. Assumptions ................................................5
3. The Basic TESLA Protocol ........................................6
3.1. Protocol Sketch ............................................6
3.2. Sender Setup ...............................................7
3.3. Bootstrapping Receivers ....................................8
3.3.1. Time Synchronization ................................9
3.4. Broadcasting Authenticated Messages .......................10
3.5. Authentication at Receiver ................................11
3.6. Determining the Key Disclosure Delay ......................12
3.7. Denial of Service Protection ..............................13
3.7.1. Additional Group Authentication ....................14
3.7.2. Not Re-using Keys ..................................15
3.7.3. Sender Buffering ...................................17
3.8. Some Extensions ...........................................17
4. Layer Placement ................................................17
5. Security Considerations ........................................18
6. Acknowledgements ...............................................19
7. Informative References .........................................19
In multicast, a single packet can reach millions of receivers. Unfortunately, this introduces the danger that an attacker can potentially also reach millions of receivers with a malicious packet. Through source authentication, receivers can ensure that a received multicast packet originates from the correct source. In these respects, a multicast is equivalent to a broadcast to a superset of the multicast receivers.
マルチキャストでは、単一のパケットは、受信機の数百万人に達することができます。残念ながら、これは、攻撃者が潜在的に悪質なパケットを受信機の数百万人に達することができるという危険性を紹介します。ソース認証を介して、受信機は、受信したマルチキャストパケットが正しいソースに由来することを確実にすることができます。これらの点で、マルチキャストは、マルチキャスト受信機のスーパーセットにブロードキャストすることと等価です。
In unicast communication, we can achieve data authentication through a simple mechanism: the sender and the receiver share a secret key to compute a message authentication code (MAC) of all communicated data. When a message with a correct MAC arrives, the receiver is assured that the sender generated that message. Standard mechanisms achieve unicast authentication this way; for example, TLS or IPsec [1,2].
ユニキャスト通信では、我々は、簡単な機構を介してデータの認証を達成することができる：送信者と受信者は、全ての通信データのメッセージ認証コード（MAC）を計算するために秘密鍵を共有します。正しいMACを有するメッセージが到着すると、受信機は、送信者がそのメッセージを生成したことが保証されます。標準的なメカニズムは、ユニキャスト認証この方法を実現します。例えば、TLSやIPsec [1,2]。
Symmetric MAC authentication is not secure in a broadcast setting. Consider a sender that broadcasts authentic data to mutually mistrusting receivers. The symmetric MAC is not secure: every receiver knows the MAC key and therefore could impersonate the sender and forge messages to other receivers. Intuitively, we need an asymmetric mechanism to achieve authenticated broadcast, such that every receiver can verify the authenticity of messages it receives, without being able to generate authentic messages. Achieving this in an efficient way is a challenging problem [3].
対称MAC認証は、放送設定では安全ではありません。相互mistrustingレシーバに本物のデータをブロードキャスト送信者を考えてみましょう。すべての受信機は、MACキーを知っているので、送信者を偽装して、他の受信者にメッセージを偽造可能性：対称MACは安全ではありません。直感的に、我々は、すべての受信機が本格的なメッセージを生成できず、それが受信したメッセージの信頼性を確認することができるように、認証された放送を、達成するために非対称のメカニズムが必要です。効率的な方法でこれを達成することは困難な問題である[3]。
The standard approach to achieving such asymmetry for authentication is to use asymmetric cryptography; e.g., a digital signature. Digital signatures have the required asymmetric property: the sender generates the signature with its private key, and all receivers can verify the signature with the sender's public key, but a receiver with the public key alone cannot generate a digital signature for a new message. A digital signature provides non-repudiation, a stronger property than authentication. However, digital signatures have a high cost: they have a high computation overhead for both the sender and the receiver, and most signatures also have a high-bandwidth overhead. Since we assume broadcast settings for which the sender does not retransmit lost packets, and the receiver still wants to authenticate each packet it receives immediately, we would need to attach a digital signature to each message. Because of the high overhead of asymmetric cryptography, this approach would restrict us to low-rate streams, and to senders and receivers with powerful workstations. We can try to amortize one digital signature over multiple messages. However, this approach is still expensive in contrast to symmetric cryptography, since symmetric cryptography is in general 3 to 5 orders of magnitude more efficient than asymmetric cryptography. In addition, the straight-forward amortization of one digital signature over multiple packets requires reliability, as the receiver needs to receive all packets to verify the signature. A number of schemes that follow this approach are [4,5,6,7]. See [8] for more details.
認証のために、このような非対称性を達成するための標準的なアプローチは、非対称暗号化を使用することです。例えば、デジタル署名。送信者は、秘密鍵で署名を生成し、すべての受信機は、送信者の公開鍵で署名を検証することができますが、単独の公開鍵を用いて受信機には、新しいメッセージのデジタル署名を生成することができません：デジタル署名が必要な非対称性を有しています。デジタル署名は、否認防止、認証よりも強力な特性を提供します。しかし、デジタル署名は、高コストを持っている：彼らは、送信者と受信者の両方のための高い計算オーバーヘッドを持っており、ほとんどの署名は、高帯域幅のオーバーヘッドを持っています。私たちは、送信者が失われたパケットを再送しないため、ブロードキャストの設定を前提とし、受信機はまだそれがすぐに受信した各パケットを認証したいので、私たちは、各メッセージにデジタル署名を添付する必要があります。そのため、非対称暗号の高いオーバーヘッド、このアプローチは、低レートのストリームに、そして強力なワークステーションと送信側と受信側に私たちを制限します。私たちは、複数のメッセージを介して1人のデジタル署名を償却しようとすることができます。対称暗号、非対称暗号方式よりも効率的大きさの一般的な3~5桁であるので、このアプローチは、対称暗号とは対照的に、依然として高価です。受信機は、署名を検証するすべてのパケットを受信する必要があるように加えて、複数のパケットにわたって一つのデジタル署名のストレートフォワード償却は、信頼性を必要とします。このアプローチを以下のスキームの数は、[4,5,6,7]です。詳細については、[8]を参照してください。
This document presents the Timed Efficient Stream Loss-tolerant Authentication protocol (TESLA). TESLA uses mainly symmetric cryptography, and uses time-delayed key disclosure to achieve the required asymmetry property. However, TESLA requires loosely synchronized clocks between the sender and the receivers. See more details in Section 3.3.1. Schemes that follow a similar approach to TESLA are [9,10,11].
この文書では、時限効率的なストリーム損失トレラント認証プロトコル（TESLA）を提示しています。 TESLAは、主に対称暗号化を使用し、必要な非対称特性を達成するために、時間遅延キー開示を使用しています。しかし、TESLAは、送信者と受信者の間で緩やかに同期したクロックを必要とします。セクション3.3.1で詳細を参照してください。 TESLAに同様のアプローチを以下のスキームである[9,10,11]。
To denote the subscript or an index of a variable, we use the underscore between the variable name and the index; e.g., the key K with index i is K_i, and the key K with index i+d is K_{i+d}. To write a superscript, we use the caret; e.g., function F with the argument x executed i times is F^i(x).
添字や変数のインデックスを示すために、我々は、変数名とインデックスの間にアンダースコアを使用します。例えば、インデックスの鍵K iはK_Iであり、インデックス付き鍵K iがDを+がK_ {iがDを+}です。上付き文字を書くために、私たちはキャレットを使用します。例えば、引数を有する関数Fは、I回実行xはFである^ I（X）。
TESLA provides delayed per-packet data authentication and integrity checking. The key idea to providing both efficiency and security is a delayed disclosure of keys. The delayed key disclosure results in an authentication delay. In practice, the delay is on the order of one RTT (round-trip-time).
TESLAが遅れ、パケットごとのデータの認証と整合性のチェックを行います。効率性とセキュリティの両方を提供するためのキーアイデアは、キーの遅れ開示です。認証遅延で遅れたキーの開示結果。実際には、遅延は1 RTT（ラウンドトリップ時間）のオーダーです。
TESLA has the following properties:
TESLAは、次のプロパティがあります。
o Low computation overhead for generation and verification of authentication information.
認証情報の生成および検証のためのO低計算オーバーヘッド。
o Low communication overhead.
O低通信オーバーヘッド。
o Limited buffering required for the sender and the receiver, and therefore timely authentication for each individual packet.
Oリミテッドのバッファリングは、個々のパケットの送信者と受信者、およびので、タイムリーな認証に必要。
o Strong robustness to packet loss.
パケットロスにO強い堅牢性。
o Scales to a large number of receivers.
O多数の受信機にスケールします。
o Protects receivers from denial of service attacks in certain circumstances if configured appropriately.
適切に設定されている場合、Oは、特定の状況でサービス拒否攻撃から受信機を保護します。
o Each receiver cannot verify message authenticity unless it is loosely time-synchronized with the source, where synchronization can take place at session setup. Once the session is in progress, receivers need not send any messages or acknowledgements.
それは緩く時間同期同期はセッションセットアップで行うことができるソース、である場合を除き、O各レシーバは、メッセージの真正性を検証することはできません。セッションが進行中であるならば、受信機は、任意のメッセージや受信確認を送信する必要はありません。
o Non-repudiation is not supported; each receiver can know that a stream is from an authentic source, but cannot prove this to a third party.
O否認防止がサポートされていません。各受信機は、ストリームが本物のソースからのものであることを知ることができますが、第三者にこれを証明することはできません。
TESLA can be used in the network layer, in the transport layer, or in the application layer. Delayed authentication, however, requires buffering of packets until authentication is completed. Certain applications intolerant of delay may be willing to process packets in parallel to being buffered while awaiting authentication, as long as roll-back is possible if packets are later found to be unauthenticated. For instance, an interactive video may play out packets still awaiting authentication, but if they are later found to be unauthenticated, it could stop further play-out and warn the viewer that the last x msec were unauthenticated and should be ignored. However, in the remainder of this document, for brevity, we will assume that packets are not processed in parallel to buffering.
テスラは、トランスポート層、またはアプリケーション層では、ネットワーク層で使用することができます。認証が完了するまでの遅延認証、しかし、パケットのバッファリングが必要です。遅延の不耐性、特定のアプリケーションが認証を待っている間、パケットが後に認証されていないことが判明している場合にロールバックが可能である限り、バッファリングされることに並行してパケットを処理するために喜んであってもよいです。例えば、対話型のビデオはまだ認証を待っているパケットを演じるかもしれないが、彼らが後に認証されていないことが判明している場合、それはさらにプレイアウトを停止して、ミリ秒のx、最後のビューアに警告することができ、認証されていないた、無視してください。しかし、この文書の残りの部分では、簡潔にするために、我々は、パケットがバッファリングに並行して処理されていないことを前提としています。
We design TESLA to be secure against a powerful adversary with the following capabilities:
我々は、次の機能を備えた強力な敵に対して安全であることをTESLAを設計します。
o Full control over the network. The adversary can eavesdrop, capture, drop, re-send, delay, and alter packets.
ネットワーク上のOフルコントロール。敵は、キャプチャ、ドロップ、再送信、遅延を盗聴し、パケットを変更することができます。
o Access to a fast network with negligible delay.
無視できる程度の遅延で高速なネットワークへのOアクセス。
o The adversary's computational resources may be very large, but not unbounded. In particular, this means that the adversary can perform efficient computations, such as computing a reasonable number of pseudo-random function applications and MACs with negligible delay. Nonetheless, the adversary cannot find the key of a pseudo-random function (or distinguish it from a random function) with non-negligible probability.
O敵の計算リソースは非常に大きいが、無制限ではないかもしれません。特に、これは、敵対者がそのような無視できる遅延を有する擬似ランダム関数のアプリケーションとMACの合理的な数を計算するなど、効率的な計算を行うことができることを意味します。それにもかかわらず、敵は無視できない確率で（またはランダム関数と区別）擬似ランダム関数の鍵を見つけることができません。
The security property of TESLA guarantees that the receiver never accepts M_i as an authentic message unless the sender really sent M_i. A scheme that provides this guarantee is called a secure broadcast authentication scheme.
TESLAのセキュリティプロパティは、受信者が送信者が本当にM_Iを送らない限り、本物のメッセージとしてM_Iを受け入れないことを保証します。この保証を提供スキームは、安全なブロードキャスト認証方式と呼ばれています。
Because TESLA expects the receiver to buffer packets before authentication, the receiver needs to protect itself from a potential denial of service (DoS) attack due to a flood of bogus packets (see Section 3.8).
TESLAは、受信機が認証する前にパケットをバッファリングすることを期待するので、受信機は、（3.8節を参照）偽のパケットの洪水によるサービス拒否（DoS）攻撃の可能性否定から自身を保護する必要があります。
TESLA makes the following assumptions in order to provide security:
TESLAは、セキュリティを提供するために、次のことを前提とします
1. The sender and the receiver must be loosely time-synchronized. Specifically, each receiver must be able to compute an upper bound on the lag of the receiver clock relative to the sender clock. We denote this quantity with D_t. (That is, D_t = sender time - receiver time). We note that an upper bound on D_t can easily be obtained via a simple two-message exchange. (Such an exchange can be piggybacked on any secure session initiation protocol. Alternatively, standard protocols such as NTP [15] can be used.
1.送信者と受信者が緩く時間同期でなければなりません。具体的には、各受信機は、送信側クロックと受信機クロックの相対的な遅れの上限を計算することができなければなりません。私たちは、D_tでこの量を表します。 （ - 受信時刻すなわち、D_t =センダ時間です）。私たちは、D_tの上限は、簡単な2つのメッセージ交換を介して取得することができることに注意してください。 （このような交換は、任意のセキュアなセッション開始プロトコルにピギーバックすることができる。あるいは、NTP [15]などの標準プロトコルを使用することができます。
2. TESLA MUST be bootstrapped at session setup through a regular data authentication system. One option is to use a digital signature algorithm for this purpose, in which case the receiver is required to have an authentic copy of either the sender's public key certificate or a root key certificate in case of a PKI (public-key infrastructure). Alternatively, this initialization step can be done using any secure session initiation protocol.
2. TESLAは、通常のデータ認証システムを通じてセッションセットアップでブートストラップされなければなりません。 1つのオプションは、受信側が送信者の公開鍵証明書またはPKI（公開鍵基盤）の場合のルート鍵証明書のいずれかの本物のコピーを持つことが必要とされる場合には、この目的のためにデジタル署名アルゴリズムを使用することです。あるいは、この初期化ステップは、任意のセキュアなセッション開始プロトコルを用いて行うことができます。
3. TESLA uses cryptographic MAC and PRF (pseudo-random functions). These MUST be cryptographically secure. Further details on the instantiation of the MAC and PRF are in Section 3.4.
3テスラは暗号MACおよびPRF（擬似乱数関数）を使用します。これらは、暗号安全でなければなりません。 MACとPRFのインスタンス化に関する詳細については、セクション3.4です。
We would like to emphasize that the security of TESLA does NOT rely on any assumptions about network propagation delay.
私たちは、TESLAのセキュリティはネットワーク伝播遅延についての仮定に依存しないことを強調したいと思います。
TESLA is described in several academic publications: A book on broadcast security [12], a journal paper [13], and two conference papers [7,14]. Please refer to these publications for in-depth proofs of security, experimental results, etc.
ブロードキャストセキュリティに関する書籍[12]、ジャーナル紙[13]、および2本の会議の論文[7,14]：TESLAは、いくつかの学術刊行物に記載されています。セキュリティの詳細な証拠、実験結果などのためにこれらの出版物を参照してください
We first outline the main ideas behind TESLA.
私たちは、最初のTESLAの背後にある主要なアイデアの概要を説明します。
As we argue in the introduction, broadcast authentication requires a source of asymmetry. TESLA uses time for asymmetry. We first make sure that the sender and receivers are loosely time-synchronized as described above. Next, the sender forms a one-way chain of keys, in which each key in the chain is associated with a time interval (say, a second). Here is the basic approach:
我々は導入で主張したように、ブロードキャスト認証は、非対称性の源を必要とします。 TESLAは、非対称性のために時間を使用しています。私たちは、まず上記のように、送信者と受信機が緩やかに時間同期していることを確認してください。次に、送信者は、チェーン内の各キーは、時間間隔（例えば、秒）に関連付けられたキーの一方向チェーンを形成します。ここでは基本的なアプローチは次のとおりです。
o The sender attaches a MAC to each packet. The MAC is computed over the contents of the packet. For each packet, the sender uses the current key from the one-way chain as a cryptographic key to compute the MAC.
O送信者は、各パケットにMACを付加します。 MACは、パケットの内容にわたって計算されます。各パケットのために、送信者はMACを計算するための暗号鍵として一方向チェーンから現在のキーを使用しています。
o The sender discloses a key from the one-way chain after some pre-defined time delay (e.g., the key used in time interval i is disclosed at time interval i+3).
O送信者がいくつかの事前定義された時間遅延の後、一方向チェーンからキーが開示されている（例えば、時間間隔に使用されるキーは、Iは、時間間隔iが+ 3に開示されています）。
o Each receiver receives the packet. Each receiver knows the schedule for disclosing keys and, since it has an upper bound on the local time at the sender, it can check that the key used to compute the MAC was not yet disclosed by the sender. If it was not, then the receiver buffers the packet. Otherwise the packet is dropped due to inability to authenticate. Note that we do not know for sure whether a "late packet" is a bogus one or simply a delayed packet. We drop the packet because we are unable to authenticate it. (Of course, an implementation may choose not to drop packets and to use them unauthenticated.)
Oの各受信機は、パケットを受信します。それは、送信者のローカル時間に上限がありますので、各受信機は、キーを開示するスケジュールを知っていると、それがMACを計算するために使用される鍵は、まだ送信者によって明らかにされていないことを確認することができます。それがなかった場合、受信機はパケットをバッファリング。それ以外の場合は、パケットが原因認証することができないことに落とされます。 「後半パケットは」偽の1、または単に遅れたパケットであるかどうか、我々は確かに知っていないことに注意してください。我々はそれを認証することができないので、我々はパケットをドロップします。 （もちろん、実装はパケットをドロップし、それらを認証されていない使用しないことも選択できます。）
o Each receiver checks that the disclosed key belongs to the hash-chain (by checking against previously released keys in the chain) and then checks the correctness of the MAC. If the MAC is correct, the receiver accepts the packet.
Oの各受信機が開示されているキー（チェーンに以前にリリースされたキーに対してチェックすることにより）ハッシュチェーンに属し、その後、MACの正当性をチェックすることをチェックします。 MACが正しい場合、受信機はパケットを受け入れます。
Note that one-way chains have the property that if intermediate values of the one-way chain are lost, they can be recomputed using subsequent values in the chain. Even if some key disclosures are lost, a receiver can recover the corresponding keys and check the correctness of earlier packets.
一方向の鎖が一方向チェーンの中間値が失われた場合、彼らはチェーン内の後続の値を使用して再計算することが可能という特性を持っていることに注意してください。いくつかの重要な開示が失われた場合でも、受信機は、対応するキーを回復し、以前のパケットの正しさを確認することができます。
We now describe the stages of the basic TESLA protocol in this order: sender setup, receiver bootstrap, sender transmission of authenticated broadcast messages, and receiver authentication of broadcast messages.
我々は今、この順序で、基本的なTESLAプロトコルの段階を説明します。送信者の設定、受信機のブートストラップ、認証されたブロードキャストメッセージの送信者、送信、およびブロードキャストメッセージの受信認証を。
The sender divides the time into uniform intervals of duration T_int. The sender assigns one key from the one-way chain to each time interval in sequence.
送信者は、期間T_INTの均一な間隔に時間を分割します。送信者は、シーケンス内の各時間間隔に一方向鎖からの1つのキーを割り当てます。
The sender determines the length N of the one-way chain K_0, K_1, ..., K_N, and this length limits the maximum transmission duration before a new one-way chain must be created. The sender picks a random value for K_N. Using a pseudo-random function (PRF), f, the sender constructs the one-way function F: F(k) = f_k(0). The rest of the chain is computed recursively using K_i = F(K_{i+1}). Note that this gives us K_i = F^{N-i}(K_N), so the receiver can compute any value in the key chain from K_N, even if it does not have intermediate values. The key K_i will be used to authenticate packets sent in time interval i.
送信者は、一方向チェーンK_0、K_1、...、K_Nの長さNを決定し、新たな一方向チェーンが作成されなければならない前に、この長さは、最大送信時間を制限します。送信者はK_Nのためのランダムな値を選びます。擬似ランダム関数（PRF）を使用して、F、送信者は、一方向性関数Fを構築：F（K）= F_K（0）。鎖の残りはK_I = F（K_を{I + 1}）を使用して再帰的に計算されます。これは私達にK_I = F ^ {N-I}（K_N）を与えることに注意し、それは中間値を有していない場合でも、受信機は、K_Nからキーチェーン内の任意の値を計算することができます。キーK_Iは、時間間隔Iに送信されたパケットを認証するために使用されます。
Jakobsson [20] and Coppersmith and Jakobsson [21] present a storage-and computation-efficient mechanism for one-way chains. For a chain of length N, storage is about log(N) elements, and the computation overhead to reconstruct each element is also about log(N).
Jakobsson [20]と銅細工とJakobsson [21]は、一方向チェーンのストレージおよび計算効率の機構を提示します。長さNの鎖のため、ストレージは、各要素がログ（N）についても再構成するためにログ（N）元素、及び計算オーバーヘッド程度です。
The sender determines the duration of a time interval, T_int, and the key disclosure delay, d. (T_int is measured in time units, say milliseconds, and d is measured in number of time intervals. That is, a key that is used for time interval i will be disclosed in time interval i+d.) It is stressed that the scheme remains secure for any values of T_int and d>0. Still, correct choice of T_int and d is crucial for the usability of the scheme. The choice is influenced by the estimated network delay, the length of the transmission, and the tolerable delay at the receiver. A T_int that is too short will cause the keys to run out too soon. A T_int that is too long will cause excessive delay in authentication for some of the packets (those that were sent at the beginning of a time period). A delay d that is too short will cause too many packets to be unverifiable by the receiver. A delay d that is too long will cause excessive delay in authentication.
送信者は、時間間隔、T_INT、及び鍵開示遅延、Dの持続時間を決定します。 （T_INTはミリ秒を言う、時間単位で測定され、そしてDは、時間間隔の数で測定される。つまり、私はDを+時間間隔に開示された時間間隔に使用されるキーである。）これは、スキームことが強調されていますT_INTと、d> 0の任意の値のための安全なまま。それでも、T_INTとDの正しい選択は、制度の利便性のために重要です。選択は、推定されたネットワーク遅延、送信の長さ、および受信機における許容遅延によって影響されます。短すぎるT_INTは、キーがあまりにも早くなくなってしまいます。長すぎるT_INTは、パケット（期間の開始時に送信されたもの）のいくつかの認証における過度の遅延が発生します。短すぎる遅延dは、あまりにも多くのパケットが受信機によって証明できないことになります。長すぎる遅延dは、認証における過度の遅延が発生します。
The sender estimates a reasonable upper bound on the network delay between the sender and any receiver as m milliseconds. This includes any delay expected in the stack (see Section 4, on layer placement). If the sender expects to send a packet every n milliseconds, then a reasonable value for T_int is max(n,m). Based on T_int, a rule of thumb for determining the key disclosure delay, d, is given in Section 3.6.
送信者は、送信者およびmミリ秒のような任意の受信機との間のネットワーク遅延に合理的上限推定します。これは、スタック（層配置のセクション4を参照）で予想される任意の遅延を含みます。送信者は、パケットごとにnミリ秒を送信するために想定している場合、その後、T_INTのための合理的な値は、（n、m）が最大です。 T_INT、鍵開示遅延を決定するための経験則に基づいて、Dは、3.6節に記載されています。
The above value for T_int is neither an upper or a lower bound; it is merely the value that reduces key change processing to a minimum without causing authentication delay to be higher than necessary. If the application can tolerate higher authentication delay, then T_int can be made appropriately larger. Also, if m (or n) increases during the session, perhaps due to congestion or a late joiner on a high delay path, T_int need not be revised.
T_INTのための上記の値は、上限または下限もありません。単に必要以上に高くなるように、認証遅延を生じることなく最小限に鍵変更処理を低減する値です。アプリケーションがより高い認証遅延を許容できる場合には、T_INT適宜大きくすることができます。また、輻輳又は高遅延経路上の後期建具によるおそらく、M（またはN）がセッション中に増加する場合、T_INTが改訂される必要はありません。
Finally, the sender needs to allow each receiver to synchronize its time with the sender. See more details on how this can be done in Section 3.3.1. (It is stressed that estimating the network delay is a separate task from the time synchronization between the sender and the receivers.)
最後に、送信者は、各受信者が送信者とその時刻を同期できるようにする必要があります。これはセクション3.3.1で行うことができる方法の詳細を参照してください。 （ネットワーク遅延を推定することは、送信者と受信機との間の時間同期とは別タスクであることが強調されます。）
Before a receiver can authenticate messages with TESLA, it needs to have the following:
受信機はTESLAとのメッセージを認証する前に、それは次のように持っている必要があります：
o An upper bound, D_t, on the lag of its own clock with respect to the clock of the sender. (That is, if the local time reading is t, the current time reading at the sender is at most t+D_t.).
O上限、D_t、送信側のクロックに対する自身のクロックの遅れに。 （これは現地時間の読書をtであれば、送信側で読み出し電流の時間が最もT + D_tである。、です）。
o One authenticated key of the one-way key chain. (Typically, this will be the last key in the chain; i.e., K_0. This key will be signed by the sender, and all receivers will verify the signature with the public key of the signer.)
一方向キーチェーンのひとつに認証キーO。 （典型的には、これは、チェーン内の最後のキーであろう;即ち、K_0このキーは、送信者によって署名され、すべての受信機は、署名者の公開鍵で署名を確認します。）
o The disclosure schedule of the following keys:
以下のキーの開示スケジュールO：
- T_int, the interval duration.
- T_0, the start time of interval 0.
- N, the length of the one-way key chain.
- d, the key disclosure delay d (in number of intervals).
The receiver can perform the time synchronization and get the authenticated TESLA parameters in a two-round message exchange, as described below. We stress again that time synchronization can be performed as part of the registration protocol between any receiver (including late joiners) and the sender, or between any receiver and a group controller.
受信機は、時間同期化を実行し、以下に説明するように、2ラウンドのメッセージ交換で認証TESLAのパラメータを取得することができます。我々は再び同期が（後期ジョイナを含む）任意の受信機と送信者との間の、または任意の受信機とグループコントローラとの間の登録手順の一部として行うことができる時間を強調する。
Various approaches exist for time synchronization [15,16,17,18]. TESLA only requires the receiver to know an upper bound on the delay of its local clock with respect to the sender's clock, so a simple algorithm is sufficient. TESLA can be used with direct, indirect, and delayed synchronization as three default options. The specific synchronization method will be part of each instantiation of TESLA.
様々なアプローチは、時間同期[15,16,17,18]のために存在します。 TESLAのみ送信者のクロックに対するそのローカルクロックの遅延の上限を知るために受信機を必要とするので、単純なアルゴリズムで十分です。 TESLAは、3つのデフォルトのオプションとして、直接的、間接的、および遅延同期で使用することができます。特定の同期方法は、TESLAの各インスタンスの一部となります。
For completeness, we sketch a simple method for direct synchronization between the sender and a receiver:
完全を期すために、私たちは、送信者と受信者の間の直接の同期のための簡単な方法をスケッチ：
o The receiver sends a (sync t_r) message to the sender and records its local time, t_r, at the moment of sending.
oを受信機が送信の瞬間に、送信者に（同期T_R）メッセージを送信し、そのローカル時間を記録し、T_R。
o Upon receipt of the (sync t_r) message, the sender records its local time, t_s, and sends (synch, t_r,t_s) to the receiver.
O（同期T_R）メッセージを受信すると、送信者は、そのローカル時間を記録T_S、及び受信機に（同期、T_R、T_S）を送信します。
o Upon receiving (synch,t_r,t_s), the 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、 - O（同期、T_R、T_S）を受信すると、受信機は、D_t = T_Sを設定します。
Note:
注意：
o Assuming that the messages are authentic (i.e., the message received by the receiver was actually sent by the sender), and assuming that the clock drift is at most S, then at any point throughout the session T_s < T_r + D_t, where T_s is the current time at the sender and T_r is the current time at the receiver.
（すなわち、受信機によって受信されたメッセージが実際に送信者によって送信された）メッセージが真正であると仮定すると、次いでT_SセッションT_S <T_R + D_t、全体にわたって任意の点で、クロックドリフトが最もSであると仮定すると、O現在の時刻は、送信者であるとT_Rは、受信機で、現在の時刻です。
o The exchange of sync messages needs to be authenticated. This can be done in a number of ways; for instance, with a secure NTP protocol or in conjunction with a session set-up protocol.
O同期メッセージの交換は、認証する必要があります。これは、いくつかの方法で行うことができます。例えば、安全なNTPプロトコルまたはセッションセットアッププロトコルと組み合わせて使用します。
For indirect time synchronization (e.g., synchronization via a group controller), the sender and the controller engage in a protocol for finding the value D^0_t between them. Next, each receiver, R, interacts with the group controller (say, when registering to the group) and finds the value D^R_t between the group controller and R. The overall value of D_t within R is set to the sum D_t = D^R_t + D^0_t.
間接的な時刻同期（グループコントローラを介して、例えば、同期化）のために、送信者とコントローラは、それらの間の値D ^ 0_tを見つけるためのプロトコルに従事します。次に、各受信機は、Rは、グループコントローラと相互作用（例えば、グループに登録するとき）、グループコントローラとR.間の値D ^ R_TをR内D_tの全体的な値を合計D_t = Dに設定されている発見します^ R_T + D ^ 0_t。
Each key in the one-way key chain corresponds to a time interval. Every time a sender broadcasts a message, it appends a MAC to the message, using the key corresponding to the current time interval. The key remains secret for the next d-1 intervals, so messages that a sender broadcasts in interval j effectively disclose key K_j-d. We call d the key disclosure delay.
一方向キーチェーンの各キーには、時間間隔に対応しています。送信者がメッセージをブロードキャストするたびに、それが現在の時間間隔に対応するキーを使用して、メッセージにMACを付加します。キーは、間隔j内の送信者の放送が効果的にキーK_j-Dを開示するメッセージので、次のD-1の間隔のための秘密のまま。私たちは、Dキー開示遅延を呼び出します。
We do not want to use the same key multiple times in different cryptographic operations; that is, using key K_j to derive the previous key of the one-way key chain K_{j-1}, and using the same key K_j as the key to compute the MACs in time interval j may potentially lead to a cryptographic weakness. Using a pseudo-random function (PRF), f', we construct the one-way function F': F'(k) = f'_k(1). We use F' to derive the key to compute the MAC of messages in each interval. The sender derives the MAC key as follows: K'_i = F'(K_i). Figure 1 depicts the one-way key chain construction and MAC key derivation. To broadcast message M_j in interval i the sender constructs the packet
私たちは、さまざまな暗号化操作で同じキーを複数回使用したくありません。すなわち、一方向キーチェーンK_ {J-1}の以前の鍵を導出する鍵K_jを使用して、潜在的に暗号衰弱をもたらし得る時間間隔jにおけるMACを計算するための鍵と同じ鍵K_jを用いて、です。 、擬似ランダム関数（PRF）を使用してF」、我々は、一方向関数Fを構築 'F'（k）= f'_k（1）。私たちは、各区間内のメッセージのMACを計算するための鍵を導出するために」Fを使用しています。 K'_i = F '（K_I）を次のように送信者はMACキーを導出します。図1は、一方向キーチェーンの構築およびMAC鍵導出を示します。送信側がパケットを構築し、私の間隔でメッセージM_jを放送します
P_j = {M_j || i || MAC(K'_i,M_j) || K_{i-d}}
P_j = {M_j || I || MAC（K'_i、M_j）||キッド}}
where || denotes concatenation.
どこ||連結を示しています。
F(K_i) F(K_{i+1}) F(K_{i+2})
K_{i-1} <------- K_i <------- K_{i+1} <------- K_{i+2}
| | |
| F'(K_{i-1}) | F'(K_i) | F'(K_{i+1})
| | |
V V V
K'_{i-1} K'_i K'_{i+1}
K '_ {I-1} K'_i K' _ {I + 1}
Figure 1: At the top of the figure, we see the one-way key chain (derived using the one-way function F), and the derived MAC keys (derived using the one-way function F').
図1：図の上部に、我々は（一方向関数Fを使用して導出）一方向キーチェーンを見ると、派生MACキー（一方向関数F 'を使用して導出されます）。
Once a sender discloses a key, we must assume that all parties might have access to that key. An adversary could create a bogus message and forge a MAC using the disclosed key. So whenever a packet arrives, the receiver must verify that the MAC is based on a safe key; a safe key is one that is still secret (known only by the sender). We define a safe packet or safe message as one with a MAC that is computed with a safe key.
送信者がキーを開示すると、我々はすべての当事者がそのキーへのアクセス権を持っているかもしれないと仮定しなければなりません。敵は偽のメッセージを作成し、公開鍵を使用してMACを偽造できます。パケットが到着するたびので、受信機は、MACが安全なキーに基づいていることを確認する必要があります。安全な鍵は、（送信者によってのみ知られている）まだ秘密であるものをです。私たちは、安全な鍵を使用して計算されたMACとの一つとして、安全なパケットや安全なメッセージを定義します。
If a packet proves safe, it will be buffered, only to be released when its own key, disclosed in a later packet, proves its authenticity. Although a newly arriving packet cannot immediately be authenticated, it may disclose a new key so that earlier, buffered packets can be authenticated. Any newly disclosed key must be checked to determine whether it is genuine; then authentication of buffered packets that have been waiting for it can proceed.
パケットが安全であることが判明した場合、それだけで、後のパケットで開示された独自のキーは、その信憑性を証明しているときに解放されるように、バッファリングされます。新しく到着したパケットがすぐに認証することはできませんが、以前、バッファリングされたパケットを認証することができるように、それは新しい鍵を開示することがあります。新しく公開鍵は、それが本物であるかどうかを判断するためにチェックする必要があります。それは進むことができます待っているバッファされたパケットの認証。
We now describe TESLA authentication at the receiver with more detail, listing all of these steps in the exact order they should be carried out:
私たちは今、彼らは行われるべき正確な順序でこれらのステップの全てを列挙し、より詳細に受信機でTESLA認証について説明します。
1. Safe packet test: When the receiver receives packet P_j, which carries an interval index i, and a disclosed key K_{i-d}, it first records local time T at which the packet arrived. The receiver then computes an upper bound t_j on the sender's clock at the time when the packet arrived: t_j = T + D_t. To test whether the packet is safe, the receiver then computes the highest interval x the sender could possibly be in; namely x = floor((t_j - T_0) / T_int). The receiver verifies that x < i + d (where i is the interval index), which implies that the sender is not yet in the interval during which it discloses the key K_i.
1.安全なパケット試験：受信間隔インデックスi、及びパケットが到着した公開鍵K_ {I-D}、それは最初のレコードのローカル時間Tを搬送するパケットP_jを受信した場合。 T_J = T + D_t：受信機は、パケットが到着した時点で、送信者のクロックの上限T_Jを計算します。パケットが安全であるかどうかをテストするために、受信機は、送信者X最高の間隔は、おそらくになり得る計算します。すなわち、X =フロア（（T_J - T_0）/ T_INT）。送信者は、それがキーK_Iを開示している間の間隔にまだないことを意味し、（iは間隔指数である）受信機iは、Dを+ X <ことを検証します。
Even if the packet is safe, the receiver cannot yet verify the
authenticity of this packet sent in interval i without key
K_i, which will be disclosed later. Instead, it adds the
triplet ( i, M_j, MAC( K'_i, M_j) ) to a buffer and verifies
the authenticity after it learns K'_i.
If the packet is unsafe, then the receiver considers the packet unauthenticated. It should discard unsafe packets, but, at its own risk it may choose to use them unverified.
パケットが安全でない場合、受信機は、パケットが認証されていないと考えます。それは危険なパケットを破棄すべきであるが、しかし、自身の責任でそれが検証されていないそれらを使用することもできます。
2. New key index test: Next the receiver checks whether a key K_v has already been disclosed with the same index v as the current disclosed key K_{i-d}, or with a later one; that is, with v >= i-d.
2.新しいキーインデックス試験：キーK_vが既に現在の公開鍵K_ {I-D}、又は1つ後と同じインデックスvで開示されているか否かを受信チェック次に、それは、V> = I-dは、です。
3. Key verification test: If the disclosed key index is new, the receiver checks the legitimacy of K_{i-d} by verifying, for some earlier disclosed key K_v (v<i-d), that K_v = F^{i-d-v}(K_{i-d}).
3.鍵確認試験：開示されたキーインデックスが新しい場合、受信機は、いくつかの以前に開示されているキーK_v（V <ID）のために、検証することによってK_ {ID}の正当性をチェックし、そのK_v = F ^ {IDV}（K_ { ID}）。
If key verification fails, the newly arrived packet P_j should
be discarded.
4. Message verification tests: If the disclosed key is legitimate, the receiver then verifies the authenticity of any earlier safe, buffered packets of interval i-d. To authenticate one of the buffered packets P_h containing message M_h protected with a MAC that used key index i-d, the receiver will compute K'_{i-d} = F'(K_{i-d}) from which it can compute MAC( K'_{i-d}, M_h).
4.メッセージ検証テスト：公開鍵が正当である場合、受信機は、間隔I-Dの以前の安全、バッファされたパケットの正当性を検証します。 （K'_を、受信機はそこからMACを計算することができる（K_ {ID}）「_ {ID} = F」Kを計算するキーインデックスIDを使用MACで保護含むメッセージM_h P_Hバッファされたパケットのいずれかを認証するために{ID}、M_h）。
If this MAC equals the MAC stored in the buffer, the packet is
authenticated and can be released from the buffer. If the
MACs do not agree, the buffered packet P_h should be
discarded.
The receiver continues to verify and release (or not) any remaining buffered packets that depend on the newly disclosed key K_{i-d}.
受信機は、確認及び放出（またはしない）新たに開示された鍵K_ {I-D}に依存して任意の残りのバッファされたパケットを継続します。
Using a disclosed key, we can calculate all previous disclosed keys, so even if packets are lost, we will still be able to verify buffered, safe packets from earlier time intervals. Thus, if i-d-v>1, the receiver can also verify the authenticity of the stored packets of intervals v+1 ... i-d-1.
公開鍵を使用して、我々は以前のすべての開示されたキーを計算することができますので、パケットが失われた場合でも、我々はまだ早い時間間隔から、安全なパケットをバッファリング検証することができます。したがって、I-D-V> 1は、受信機はまた、間隔V + 1 ... I-D-1の格納されたパケットの正当性を検証することができる場合。
An important TESLA parameter is the key disclosure delay d. Although the choice of the disclosure delay does not affect the security of the system, it is an important performance factor. A short disclosure delay will cause packets to lose their safety property, so receivers will not be able to authenticate them; but a long disclosure delay leads to a long authentication delay for receivers. We recommend determining the disclosure delay as follows: In direct time synchronization, let the RTT, 2m, be a reasonable upper bound on the round trip time between the sender and any receiver including worst-case congestion delay and worst-case buffering delay in host stacks. Then choose d = ceil( 2m / T_int) + 1. Note that rounding up the quotient ensures that d >= 2. Also note that a disclosure delay of one time interval (d=1) does not work. Consider packets sent close to the boundary of the time interval: After the network propagation delay and the receiver time synchronization error, a receiver will not be able to authenticate the packet, because the sender will already be in the next time interval when it discloses the corresponding key.
重要なTESLAのパラメータは、キーの開示遅延dです。開示遅延の選択は、システムのセキュリティに影響を与えませんが、それは重要な性能因子です。受信機は、それらを認証することはできませんので、短い開示遅延は、パケットがその安全性が失われます。しかし、長い開示遅延が受信機のための長い認証遅延につながります。次のように私たちは、開示の遅延を決定するお勧めします：直接時刻同期では、RTT、2メートルを聞かせて、送信者とホストにおける最悪の場合の渋滞遅延と最悪の場合、バッファリング遅延を含む任意の受信機の間の往復時間の合理的な上限もスタック。次に、商を切り上げするD> = 2は、1つの時間間隔（D = 1）の開示遅延が機能しないことに注意することを保証することがD = CEIL（2M / T_INT）+ 1メモを選択します。時間間隔の境界に近い送信されたパケットを考える：それは開示されている場合、送信者は、既に次の時間間隔になるため、ネットワーク伝播遅延と受信時刻同期エラーが発生した後、受信機は、パケットを認証することができません対応するキー。
Measuring the delay to each receiver before determining m will still not adequately predict the upper bound on delay to late joiners, or where congestion delay rises later in the session. It may be adequate to use a hard-coded historic estimate of worst-case delay (e.g., round trip delays to any host on the intra-planetary Internet rarely exceed 500msec if routing remains stable).
Mを決定する前に、各受信機に対して遅延を測定することは依然として十分遅くジョイナに、遅延の上限を予測していない、または場合輻輳遅延は、セッションの後半に上昇するであろう。最悪の場合の遅延（ルーティングが安定したままであれば、例えば、イントラ遊星インターネット上の任意のホストに往復遅延はほとんど500msec超えない）のハードコードされた歴史的な推定値を使用することが適切であり得ます。
We stress that the security of TESLA does not rely on any assumptions about network propagation delay: If the delay is longer than expected, then authentic packets may be considered unauthenticated. Still, no inauthentic packet will be accepted as authentic.
私たちは、TESLAのセキュリティはネットワーク伝播遅延についての仮定に依存しないことを強調：遅延が予想以上である場合には、本物のパケットが認証されていないと考えることができます。それでも、何も本物でないパケットは本物として受け入れません。
Because TESLA authentication is delayed, receivers seem vulnerable to flooding attacks that cause them to buffer excess packets, even though they may eventually prove to be inauthentic. When TESLA is deployed in an environment with a threat of flooding attacks, the receiver can take a number of extra precautions.
TESLA認証が遅れているため、受信機は、彼らが最終的には本物でないことを証明することにもかかわらず、彼らは余分なパケットをバッファリングする原因フラッディング攻撃に対して脆弱に見えます。 TESLAは、フラッド攻撃の脅威と環境に展開されている場合、受信機は、余分な予防策の数を取ることができます。
First, we list simple DoS mitigation precautions that can and should be taken by any receiver independently of others, thus requiring no changes to the protocol or sender behaviour. We precisely specify where these extra steps interleave with the receiver authentication steps already given in Section 3.5.
まず、ひいてはプロトコルまたは送信者行動への変更を必要としない、独立して、他の任意の受信機で撮影する必要がありますすることができ、単純なDoS攻撃の軽減対策を一覧表示します。これらの追加の手順は、すでに3.5節で与えられた受信機の認証手順でインターリーブどこ我々は正確に指定します。
o Session validity test: Before the safe packet test (Step 1), check that arriving packets have a valid source IP address and port number for the session, that they do not replay a message already received in the session, and that they are not significantly larger than the packet sizes expected in the session.
Oセッションの有効性試験：安全なパケット検査（ステップ1）、彼らはすでにセッション中に受信したメッセージを再生しないことが、到着したパケットがセッションのために有効な送信元IPアドレスとポート番号を持っていることを確認し、そうでないことをする前にセッション中に予想されるパケットサイズよりかなり大きいです。
o Reasonable misordering test: Before the key verification test (Step 3), check whether the disclosed key index i-d of the arriving packet is within g of the previous highest disclosed key index v; thus, for example, i-d-v <= g. g sets the threshold beyond which an out-of-order key index is assumed to be malicious rather than just misordered. Without this test, an attacker could exploit the iterated test in Step 3 to make receivers consume inordinate CPU time checking along the hash chain for what appear to be extremely misordered packets.
合理的な誤った順序テストをO：鍵検証テスト（ステップ3）の前に、到着パケットの公開鍵インデックスi-dが前最高開示されたキーインデックスV gの範囲内であるかどうかをチェック。従って、例えば、I-D-V <= G。 Gは、アウトオブオーダキーインデックスが悪意のあるだけでなくmisorderedことが想定される超え閾値を設定します。このテストがなければ、攻撃者は、受信機は非常にmisorderedパケットのように見える何のためのハッシュ・チェーンに沿ってチェック過度のCPU時間を消費するために、ステップ3で反復テストを悪用する可能性があります。
Each receiver can independently adapt g to prevailing attack conditions; for instance, by using the following algorithm. Initially, g should be set to g_max (say, 16). But whenever an arriving packet fails the reasonable misordering test above or the key verification test (Step 3), g should be dropped to g_min (>0 and typically 1). At each successful key verification (Step 3), g should be incremented by 1 unless it is already g_max. These precautions will guarantee that sustained attack packets cannot cause the receiver to execute more than an average of g_min hashes each, unless they are paced against genuine packets. In the latter case, attacks are limited to g_max/(g_max-g_min) hashes per each genuine packet.
各受信機は、独立して、攻撃の条件を優勢にGを適合させることができます。例えば、以下のアルゴリズムを使用して。当初、Gは（たとえば16）をG_MAXに設定する必要があります。到着したパケットは、上記妥当誤った順序試験またはキー検証テスト（ステップ3）が失敗したときはいつでもなく、Gはg_min（> 0および典型的には1）に低下されるべきです。既にG_MAXでない限り、成功した各キー照合（ステップ3）において、Gは1だけ増分されなければなりません。これらの予防措置はg_minの平均は、それぞれをハッシュよりも、彼らは本物のパケットに対してペースでされていない限り、持続的な攻撃パケットは、受信機がより多くを実行させることができないことを保証します。後者の場合、攻撃は/（G_MAX-g_min）をG_MAX各純正パケットごとにハッシュに限定されています。
When choosing g_max and g_min, note that they limit the average gap in a packet sequence to g.max(n,m)/n packets (see Section 3.2 for definitions of n and m). So with g=1, m=100msec RTT, and n=4msec inter-packet period, reordering would be limited to gaps of 25 packets on average. Bigger naturally occurring gaps would have to be written off as if they were losses.
G_MAXとg_minを選択するとき、それらはパケットのシーケンスの平均ギャップが（N、M）をg.maxに限界/ Nパケット（nおよびmの定義については、セクション3.2を参照）ことに注意してください。 G = 1、M = 100ミリ秒RTT、およびn = 4msecパケット間の期間を持つように、並べ替えは平均25のパケットの隙間に限定されるであろう。大きな天然に存在するギャップは、彼らは損失であるかのように償却しなければならないであろう。
Stronger DoS protection requires that both senders and receivers arrange additional constraints on the protocol. Below, we outline three alternative extensions to basic TESLA; the first adding group authentication, the second not re-using keys during a time interval, and the third moving buffering to the sender.
より強力なDoSの保護は送信側と受信側の両方がプロトコルに追加の制約を手配する必要があります。以下では、基本的なTESLAの3つの代替の拡張機能の概要を説明します。第1の加算グループ認証、時間間隔中に第2の再使用しないキー、及び送信者に第三の動画バッファリング。
It is important to understand the applicability of each scheme, as the first two schemes use slightly more (but bounded) resources in order to prevent attackers from consuming unbounded resources. Adding group authentication requires larger per-packet overhead. Never re-using a key requires both ends to process two hashes per packet (rather than per time interval), and the sender must store or re-generate a longer hash chain. The merits of each scheme, summarised after each is described below, must be weighed against these additional costs.
最初の二つの方式が無制限のリソースを消費するから攻撃を防ぐために少し（しかし有界）のリソースを使用するように、それぞれの方式の適用性を理解することが重要です。グループ認証を追加すると、より大きなパケットごとのオーバヘッドを必要とします。キーを再利用する（むしろ、時間間隔当たりより）パケットごとに2つのハッシュを処理するために両端を必要とせず、送信者が保管またはより長いハッシュチェーンを再生成しなければなりません。それぞれ、以下に説明された後にまとめ、それぞれの方式のメリットは、これらの追加料金を比較検討しなければなりません。
This scheme simply involves addition of a group MAC to every packet. That is, a shared key K_g common to the whole group is communicated as an additional step during receiver bootstrap (Section 3.3). Then, during broadcast of message M_j (Section 3.4), the sender computes the group MAC of each packet MAC(K_g, P_j), which it appends to the packet header. Note that the group MAC covers the whole packet P_j; that is, the concatenation of the message M_j and the additional TESLA authentication material, using the formula in Section 3.4.
この方式では、単純にすべてのパケットにグループMAC添加することを含みます。それは、グループ全体に共通の共有鍵K_Gはレシーバブートストラップ（3.3節）中に追加のステップとして通信されます。その後、メッセージM_j（セクション3.4）の放送中に、送信側は、パケットヘッダに付加し、各パケットのグループMAC MAC（K_G、P_j）を計算します。グループMACはP_jパケット全体をカバーすることに注意してください。それはセクション3.4での式を使用して、メッセージM_jおよび追加TESLA認証材の連結です。
Immediately upon packet arrival, each receiver can check that each packet came from a group member, by recomputing and comparing the group MAC.
直ちに、パケット到着時に、各受信機は、各パケットがグループMACを再計算し、比較することによって、グループのメンバーから来たことを確認することができます。
Note that TESLA source authentication is only necessary when other group members cannot be trusted to refrain from spoofing the source; otherwise, simpler group authentication would be sufficient. Therefore, additional group authentication will only make sense in scenarios where other group members are trusted to refrain from flooding the group, but where they are still not trusted to refrain from spoofing the source.
TESLA源認証は他のグループメンバーがソースを偽装控えるように信頼できない場合にのみ必要であることに注意してください。それ以外の場合は、単純なグループ認証が十分であろう。そのため、追加のグループ認証は、他のグループのメンバーがグループをフラッディング控えるように信頼されているが、彼らはまだソースを偽装控えるように信頼されていない場所のシナリオで意味を行います。
In TESLA as described so far, each MAC key was used repeatedly for all the packets sent in a time interval. If instead the sender were to guarantee never to use a MAC key more than once, each disclosed key could assume an additional purpose on top of authenticating a previously buffered packet. Each key would also immediately show each receiver that the sender of each arriving packet knew the next key back along the hash chain, which is now only disclosed once, similar to S/KEY [22]. Therefore a reasonable receiver strategy would be to discard any arriving packets that disclosed a key seen already. The fill rate of the receiver's buffer would then be clocked by each packet revealed by the genuine sender, preventing memory flooding attacks.
これまで説明したようにTESLAにおいて、各MAC鍵は、時間間隔で送信されたすべてのパケットのために繰り返し使用されました。代わりに、送信者が複数回MACキーを使用しないために決して保証していた場合は、開示された各キーは、以前にバッファリングされたパケットを認証の上に追加の目的を想定できます。各キーは直ちに各到着パケットの送信者がS / KEY [22]と同様今一度しか開示されているバックハッシュチェーンに沿って次のキーを、知っていることを各受信機を示すであろう。したがって、合理的な受信機戦略が既に見鍵を開示された任意の到着するパケットを破棄することであろう。受信側のバッファのフィルレートは、メモリフラッディング攻撃を防ぐこと、本物の送信者によって明らかにされた各パケットによってクロック駆動できます。
An attacker with control of a network element or of a faster bypass network could intercept messages and overtake or replace them with different messages but with the same keys. However, as long as packets are only buffered if they also pass the delay safety test, these bogus packets will fail TESLA verification after the disclosure delay. Admittedly, receivers could be fooled into discarding genuine messages that had been overtaken by bogus ones. But it is hard to overtake messages without compromising a network element, and any attacker that can compromise a network element can discard genuine messages anyway. We will now describe this scheme in more detail.
ネットワーク要素のまたはより高速なバイパスネットワークの制御と攻撃者がメッセージを傍受し、異なるメッセージではなく、同じキーでそれらを追い抜くか、置き換えることができます。しかし、限り、彼らはまた、遅延安全性試験に合格した場合、パケットがバッファリングされているだけのように、これらの偽のパケットは、開示の遅延の後にTESLA検証を失敗します。確かに、受信機は、偽のものに取って代わられていた本物のメッセージを破棄して、だまされてはいけでした。しかし、ネットワーク要素を犠牲にすることなく、メッセージを追い越すことは困難であり、ネットワーク要素を損なう可能性がある任意の攻撃者は、とにかく本物のメッセージを破棄することができます。私たちは今、より詳細にこのスキームを説明します。
For the sender, the scheme is hardly different from TESLA. It merely uses an interval duration short enough to ensure a new key back along the hash chain for each packet. So the rule of thumb given in Section 3.2 for an efficient re-keying interval T_int no longer applies. Instead, T_int is simply n, the inter-arrival time between packets in milliseconds. The rule of thumb for calculating d, the key disclosure delay, remains unchanged from that given in Section 3.6.
送信者のために、スキームはTESLAからほとんど変わりません。それは単にバック各パケットのハッシュチェーンに沿って、新しいキーを保証するのに十分に短い間隔の持続時間を使用しています。だから、効率的なキーの再発行間隔T_INTについては、セクション3.2で与えられた親指のルールが適用されなくなりました。その代わりに、T_INTは単にN、ミリ秒単位のパケット間の到着時間間隔です。 D、鍵開示遅延を計算するための経験則は、セクション3.6で与えられたものと変わりません。
If the packet rate is likely to vary, for safety n should be taken as the minimum inter-departure time between any two packets. (In fact, n need not be so strict; it can be the minimum average packet inter-departure time over any burst of d packets expected throughout the session.)
パケットレートが変動する可能性がある場合は、安全のnの任意の二つのパケット間の最小間の出発時刻として解釈されるべきです。 （実際には、nはそれほど厳密である必要はない;それはセッションを通して予想Dパケットのバーストにわたる最小平均パケット間出発時間であってもよいです。）
Note that if the packet rate slows down, whenever no packets are sent in a key change interval, the key index must increment along the hash chain once for each missed interval. (During a burst, if the less strict definition of n above has been used, packets may need to depart before their key change interval. The sender can safely continue changing the key for each packet, using keys from future key intervals, because if n has been chosen as defined above, such bursts will never sustain long enough to cause the associated key to be disclosed in a period less than the disclosure delay later.)
パケットレートが遅くなる場合は何のパケットがキー変更間隔で送信されない時はいつでも、キーインデックスは、各逃した区間について、一度ハッシュチェーンに沿ってインクリメントする必要があることに注意してください。 Nの少ない厳密な定義は、上記で使用された場合（バースト中に、パケットは、それらの鍵交換間隔の前に出発する必要があるかもしれない。送信者は、安全に、将来のキー間隔から鍵を使用して、各パケットのためのキーを変更する続けることができ、もしNため上記で定義した選択された、そのようなバーストは、関連付けられたキーが開示遅延後未満の期間に開示させるために十分に長く維持することはありません。）
To be absolutely clear, the precise guarantees that the sender keeps to by following the above guidance are:
絶対的に明確にするために、送信者が上記のガイダンスに従うことを続けることを正確な保証は、以下のとおりです。
o not to re-use a MAC key,
O MACキーを再使用しないように、
o not to use a MAC key K_i after its time interval i, and
Oその時間間隔Iの後にMACキーK_Iを使用しない、と
o not to disclose key K_i sooner than the disclosure delay d * T_int following the packet it protects.
O早くそれが保護パケットに続く* T_INT dの開示遅延よりもキーK_Iを開示しません。
Sender setup, receiver bootstrapping, and broadcasting authenticated messages are otherwise all identical to the descriptions in Sections 3.2, 3.3, and 3.4, respectively. However, the following step must be added to the receiver authentication steps in Section 3.5:
送信者の設定、受信機のブートストラップ、および放送は、それぞれ、3.4メッセージはすべてそうでない場合、セクション3.2、3.3の記述と一致している認証された、と。ただし、次のステップは、3.5節での受信機の認証手順に追加する必要があります。
o After Step 2, if a packet arrives carrying a key index i-d that has already been received, it should not be buffered.
パケットが既に受信されたキーインデックスi-Dを運んで到着した場合、Oステップ2の後、それはバッファリングするべきではありません。
This simple scheme would suffice against DoS, were it not for the fact that a network sometimes misorders packets without being compromised. Even without control of a network element, an attacker can opportunistically exploit such openings to fool a receiver into buffering a bogus packet and discarding a later genuine one. A receiver can choose to set aside a fixed size cache and can manage it to minimise the chances of discarding a genuine packet. However, given such vulnerabilities are rare and unpredictable, it is simpler to count these events as additions to the network loss rate. As always, TESLA authentication will still uncover any bogus packets after the disclosure delay.
この簡単なスキームは、それがないネットワーク時々misordersパケットが危険にさらされているという事実のためではなかった、DoS攻撃に対して十分であろう。ネットワーク要素の制御なしに、攻撃者は、日和見偽のパケットをバッファリングし、後で純正品を廃棄に受信機をだますためにこのような開口部を利用することができます。受信機は、固定サイズのキャッシュを脇に設定するかを選択することができますし、本物のパケットを廃棄する可能性を最小限に抑えるために、それを管理することができます。しかし、そのような脆弱性は稀で、予測不可能になっている指定された、ネットワークの損失率への追加として、これらのイベントをカウントするように簡単です。いつものように、TESLA認証はまだ開示の遅延の後に任意の偽のパケットを発見します。
To summarise, avoiding re-using keys has the following properties, even under extreme flooding attacks:
再使用してキーを避け、要約すると極端なフラッディング攻撃の下で、次のプロパティがあります。
o After delayed TESLA authentication, packets arriving within the disclosure delay will always be identified as authentic if they are and as inauthentic if they are not authentic.
彼らは本物ではないかのように本物でないで、場合O遅延TESLAの認証後、開示の遅延以内に到着するパケットは、常に本物と識別されます。
o The fill rate of the receiver's buffer is clocked by each packet revealed by the genuine sender, preventing memory flooding attacks.
O受信側のバッファのフィルレートは、メモリフラッディング攻撃を防ぐこと、本物の送信者によって明らかにされた各パケットによってクロックされます。
o An attacker with control of a network element can cause any loss rate it chooses (but that's always true anyway).
Oネットワーク要素の制御と、攻撃者は、それが選択した任意の損失率を引き起こす可能性があります（それはとにかく常に真です）。
o Where attackers do not have control of any network elements, the effective loss rate is bounded by the sum of the network's actual loss rate and its re-ordering rate.
攻撃者が任意のネットワーク要素の制御を持っていない場合は、O、効果的な損失率は、ネットワークの実際の損失率とその再発注率の合計によって制限されます。
Buffering of packets can be moved to the sender side; then receivers can authenticate packets immediately upon receipt. This method is described in [14].
パケットのバッファリングは、送信者側に移動することができます。その後、受信機は、受信時にすぐにパケットを認証することができます。この方法は、[14]に記載されています。
Let us mention two salient extensions of the basic TESLA scheme. A first extension allows having multiple TESLA authentication chains for a single stream, where each chain uses a different delay for disclosing the keys. This extension is typically used to deal with heterogeneous network delays within a single multicast transmission. A second extension allows having most of the buffering of packets at the sender side (rather than at the receiver side). Both extensions are described in [14].
私たちは、基本的なTESLA・スキームの2つの顕著な拡張を言及してみましょう。最初の拡張は、各鎖は、キーを公開するために異なる遅延を使用して、単一のストリームのための複数のTESLA認証鎖を有することができます。この拡張は、典型的には、単一のマルチキャスト伝送内異種ネットワーク遅延に対処するために使用されます。第二の拡張は（というよりも受信側で）送信側でパケットのバッファリングの大部分を有することができます。両方の拡張機能は[14]に記載されています。
TESLA's requirement that a key be received in a later packet for authentication prevents a receiver from authenticating the last part of a message. Thus, to enable authentication of the last part of a message or of the last message before a transmission suspension, the sender needs to send an empty message with the key.
キーは認証のための後のパケットで受信することTESLAの要件は、メッセージの最後の部分を認証から受信を防ぐことができます。これにより、送信停止前にメッセージのまたは最後のメッセージの最後の部分の認証を可能にするために、送信者は、鍵を使用して空のメッセージを送信する必要があります。
TESLA authentication can be performed at any layer in the networking stack. Three natural places are the network, transport, or application layer. We list some considerations regarding the choice of layer:
TESLA認証は、ネットワークスタックのあらゆる層で行うことができます。三つの自然な場所では、ネットワーク、トランスポート、またはアプリケーション層です。私たちは、層の選択に関するいくつかの考慮事項をリスト：
o Performing TESLA in the network layer has the advantage that the transport or application layer only receives authenticated data, potentially aiding a reliability protocol and mitigating denial of service attacks. (Indeed, reliable multicast tools based on forward error correction are highly susceptible to denial of service due to bogus packets.)
Oネットワーク層にTESLAを実行するトランスポート又はアプリケーションレイヤのみ、潜在的信頼性プロトコルを支援し、サービス拒否攻撃を緩和、認証されたデータを受信するという利点を有します。 （確かに、前方誤り訂正に基づく信頼性の高いマルチキャストのツールが原因偽のパケットにサービス拒否の影響を非常に受けやすいです。）
o Performing TESLA in either the transport or the application layer has the advantage that the network layer remains unchanged, but it has the potential drawback that packets are obtained by the application layer only after being processed by the transport layer. Consequently, if buffering is used in the transport, then this may introduce additional and unpredictable delays on top of the unavoidable network delays.
O輸送またはアプリケーション層のいずれかにTESLAを実行すると、ネットワーク層は変わらないという利点を有するが、それは、パケットのみトランスポート層で処理された後、アプリケーション層によって得られる潜在的な欠点を有しています。バッファリングは、輸送に使用される場合、結果として、これは避けられないネットワーク遅延の上に追加し、予測不可能な遅延を導入することができます。
o Note that because TESLA relies upon timing of packets, deploying TESLA on top of a protocol or layer that aggressively buffers packets and hides the true packet arrival time will significantly reduce TESLA's performance.
O TESLAは、パケットのタイミングに依存しているので、積極的にパケットをバッファリングし、真のパケット到着時間を隠すプロトコルまたは層の上にTESLAを展開すると、大幅にTESLAのパフォーマンスが低下することに注意してください。
See the academic publications on TESLA [7,13,19] for several security analyses. Regarding the security of implementations, by far the most delicate point is the verification of the timing conditions. Care should be taken to make sure that (a) the value bound D_t on the clock skew is calculated according to the spec at session setup and that (b) the receiver records the arrival time of the packet as soon as possible after the packet's arrival, and computes the safety condition correctly.
いくつかのセキュリティ分析のために[7,13,19] TESLAの学術出版物を参照してください。実装のセキュリティに関しては、これまでで最も微妙な点は、タイミング条件の検証です。ケアは、パケットの到着後できるだけ早くセッションのセットアップの仕様とその（b）は、受信機がパケットの到着時刻を記録による（a）のクロック・スキューにD_tをバインド値が計算されていることを確認するために取られるべきです正しく安全条件を計算します。
It should be noted that a change to the key disclosure schedule for a message stream should never be declared within the message stream itself. This would introduce a vulnerability, because a receiver that did not receive the notification of the change would still believe in the old key disclosure schedule.
メッセージストリームのためのキー開示スケジュールに変更がメッセージストリーム自体の中で宣言してはならないことに留意すべきです。変更の通知を受け取っていない受信機がまだ古いキー開示スケジュールを信じてしまうので、これは、脆弱性を導入します。
Finally, in common with all authentication schemes, if verification is located separately from the ultimate destination application (e.g., an IPSec tunnel end point), a trusted channel must be present between verification and the application. For instance, the interface between the verifier and the application might simply assume that packets received by the application must have been verified by the verifier (because otherwise they would have been dropped). The application is then vulnerable to reception of packets that have managed to bypass the verifier.
検証は、最終的な宛先アプリケーション（例えば、IPSecのトンネルエンドポイント）とは別個に配置されている場合、最終的に、すべての認証方式と共通に、高信頼チャネルは、検証とアプリケーションとの間に存在しなければなりません。例えば、検証者とアプリケーションとの間のインターフェースは、単に、（そうでない場合は廃棄されていたため）、アプリケーションによって受信されたパケットは検証者によって検証されていなければならないと仮定かもしれません。アプリケーションは、検証を回避するために管理しているパケットの受信にその後脆弱です。
We would like to thank the following for their feedback and support: Mike Luby, Mark Baugher, Mats Naslund, Dave McGrew, Ross Finlayson, Sylvie Laniepce, Lakshminath Dondeti, Russ Housley, and the IESG reviewers.
マイク・ルビー、マーク・Baugher、マッツ・ナズランド、デイブマグリュー、ロスフィンレイソン、シルヴィLaniepce、Lakshminath Dondeti、ラスHousley、およびIESGの審査：私たちは、彼らのフィードバックとサポートのために次のことを感謝したいと思います。
[1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[1]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[2] IPsec, "IP Security Protocol, IETF working group" http://www.ietf.org/html.charters/OLD/ipsec-charter.html.
[2]のIPsec、 "IPセキュリティプロトコル、IETFワーキンググループ" http://www.ietf.org/html.charters/OLD/ipsec-charter.html。
[3] D. Boneh, G. Durfee, and M. Franklin, "Lower bounds for multicast message authentication," in Advances in Cryptology -- EUROCRYPT 2001 (B. Pfitzmann, ed.), Vol. 2045 of Lecture Notes in Computer Science, (Innsbruck, Austria), p. 434-450, Springer-Verlag, Berlin Germany, 2001.
[3] D. Boneh、G.ダーフィー、及びM.フランクリン、暗号理論における進歩で "マルチキャストメッセージ認証のための下界、" - EUROCRYPT 2001（B. Pfitzmann、編）、巻。コンピュータサイエンス、（インスブルック、オーストリア）、Pでの講義ノートの2045年。 434から450、シュプリンガー・フェアラーク、ベルリンドイツ、2001年。
[4] R. Gennaro and P. Rohatgi, "How to Sign Digital Streams", tech. rep., IBM T.J.Watson Research Center, 1997.
[4] R.ジェンナーロとP. Rohatgiは、ハイテク、 "どのようにデジタルストリームに署名します"。議員、IBM T.J.Watson研究センター、1997。
[5] P. Rohatgi, "A compact and fast hybrid signature scheme for multicast packet authentication", 6th ACM Conference on Computer and Communications Security , November 1999.
[5] P. Rohatgi、「マルチキャストパケット認証のためのコンパクトで高速なハイブリッド署名方式」、コンピュータおよび通信セキュリティ、1999年11月第6回ACM会議。
[6] C. K. Wong and S. S. Lam, "Digital signatures for flows and multicasts," in Proc. IEEE ICNP `98, 1998.
[6] C. K.ウォンとS. S.ラム、PROCで "フローおよびマルチキャストのためのデジタル署名"。 IEEE ICNP `98、1998。
[7] A. Perrig, R. Canetti, J. Tygar, and D. X. Song, "Efficient authentication and signing of multicast streams over lossy channels", IEEE Symposium on Security and Privacy, May 2000.
[7] A. Perrig、R.カネッティ、J. Tygar、及びD. X.歌、「効率的な認証とロッシーチャネル上でマルチキャストストリームの署名」、セキュリティとプライバシー、2000年5月にIEEEシンポジウム。
[8] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor, and B. Pinkas, "Multicast security: A taxonomy and some efficient constructions", Infocom '99, 1999.
[8] R.カネッティ、J.ガライ、G. Itkis、D. Micciancio、M. Naor、及びB.ピンカス、 "マルチキャストセキュリティ：分類といくつかの効率的構成"、インフォコム'99、1999。
[9] S. Cheung, "An efficient message authentication scheme for link state routing", 13th Annual Computer Security Applications Conference, 1997.
[9] S.チャン、「リンク状態ルーティングのための効率的なメッセージ認証スキーム」、第13回コンピュータセキュリティアプリケーションの会議、1997。
[10] F. Bergadano, D. Cavagnino, and B. Crispo, "Chained stream authentication," in Selected Areas in Cryptography 2000, (Waterloo, Canada), August 2000. A talk describing this scheme was given at IBM Watson in August 1998.
[10] F. Bergadano、D. Cavagnino、およびB. Crispo、「連鎖ストリーム認証、」暗号2000年に選択された領域、（ウォータールー、カナダ）で、2000年8月このスキームを記述した話は8月にIBMワトソンで与えられました1998。
[11] F. Bergadano, D. Cavalino, and B. Crispo, "Individual single source authentication on the mbone", ICME 2000, August 2000. A talk containing this work was given at IBM Watson, August 1998.
[11] F. Bergadano、D. Cavalino、およびB. Crispo、 "MBONE上の個々の単一ソース認証"、ICME 2000は、2000年8月、この作品を含むトークはIBMワトソン、1998年8月に与えられました。
[12] A. Perrig and J. D. Tygar, Secure Broadcast Communication in Wired and Wireless Networks Kluwer Academic Publishers, October 2002. ISBN 0792376501.
[12] A. PerrigおよびJ. D. Tygar、有線およびワイヤレスネットワークKluwerの学術出版社、2002年10月ISBN 0792376501にブロードキャスト通信を保護します。
[13] A. Perrig, R. Canetti, J. D. Tygar, and D. Song, "The tesla broadcast authentication protocol," RSA CryptoBytes, Volume 5, No. 2 Summer/Fall 2002.
[13] A. Perrig、R.カネッティ、J. D. Tygar、及びD.ソング、 "テスラ放送認証プロトコルは、" RSA CryptoBytes、第5巻、第2号は、夏/ 2002年秋。
[14] A. Perrig, R. Canetti, D. Song, and J. D. Tygar, "Efficient and secure source authentication for multicast", Network and Distributed System Security Symposium, NDSS '01, p. 35-46, February 2001.
[14] A. Perrig、R.カネッティ、D.ソン、およびJ. D. Tygar、 "マルチキャストのための効率的で安全なソース認証"、ネットワークと分散システムセキュリティシンポジウム、NDSS '01、P。 35-46、2001年2月。
[15] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[15]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装と分析"、RFC 1305、1992年3月。
[16] B. Simons, J. Lundelius-Welch, and N. Lynch, "An overview of clock synchronization", Fault-Tolerant Distributed Computing (B. Simons and A. Spector, eds.), No. 448 in LNCS, p. 84-96, Springer-Verlag, Berlin Germany, 1990.
[16] B.シモンズ、J. Lundelius・ウェルチ、およびN.リンチ、「クロック同期の概要」、フォールトトレラント分散コンピューティング（B.サイモンズおよびA.スペクター編）、LNCSのNo. 448、 P。 84から96、シュプリンガー・フェアラーク、ベルリンドイツ、1990年。
[17] D. Mills, "Improved algorithms for synchronizing computer network clocks", Proceedings of the conference on Communications architectures, protocols and applications, SIGCOMM 94, (London, England), p. 317-327, 1994.
[17] D.ミルズ、「コンピュータ・ネットワーク・クロックを同期させるための改良アルゴリズム」、通信アーキテクチャ、プロトコルおよびアプリケーションに会議の議事録、SIGCOMM 94、（ロンドン、イングランド）、P。 317-327、1994。
[18] L. Lamport and P. Melliar-Smith, "Synchronizing clocks in the presence of faults", J. ACM, Volume 32, No. 1, p. 52-78, 1985.
[18] L.ランポート及びP. Melliar・スミス、 "故障の存在下でのクロックの同期"、J. ACM、巻32、第1号、P。 52から78、1985。
[19] P. Broadfoot and G. Lowe, "Analysing a Stream Authentication Protocol using Model Checking", Proceedings of the 7th European Symposium on Research in Computer Security (ESORICS), 2002.
[19] P. BroadfootとG.・ロウ、コンピュータセキュリティ（ESORICS）、2002年の研究第7回ヨーロッパシンポジウム「モデル検査を用いて、ストリーム認証プロトコルの分析」。
[20] M. Jakobsson, "Fractal hash sequence representation and traversal", Cryptology ePrint Archive, http://eprint.iacr.org/2002/001/, January 2002.
[20] M. Jakobsson、 "フラクタルハッシュ系列表現とトラバーサル"、暗号学ePrintのアーカイブ、http://eprint.iacr.org/2002/001/、2002年1月。
[21] D. Coppersmith and M. Jakobsson, "Almost optimal hash sequence traversal", Proceedings of the Sixth International Financial Cryptography Conference (FC '02), March 2002.
[21] D.銅細工とM. Jakobsson、「ほぼ最適なハッシュ・シーケンストラバーサル」、第6回国際金融暗号化会議（FC '02）、2002年3月の議事。
[22] Haller, N., "The S/KEY One-Time Password System", RFC 1760, February 1995.
[22]ハラー、N.、 "S / KEYワンタイムパスワードシステム"、RFC 1760、1995年2月。
Authors' Addresses
著者のアドレス
Adrian Perrig ECE Department Carnegie Mellon University Pittsburgh, PA 15218 US
エイドリアンPerrig ECE部門カーネギーメロン大学、ピッツバーグ、PA 15218米国
EMail: perrig@cmu.edu
メールアドレス：perrig@cmu.edu
Ran Canetti IBM Research 30 Saw Mill River Rd Hawthorne, NY 10532 US
カネッティIBMリサーチ30は、ミルリバーRdのホーソーン、NY 10532米国を見た蘭
EMail: canetti@watson.ibm.com
メールアドレス：canetti@watson.ibm.com
Dawn Song ECE Department Carnegie Mellon University Pittsburgh, PA 15218 US
ドーン・ソングECE部門カーネギーメロン大学、ピッツバーグ、PA 15218米国
EMail: dawnsong@cmu.edu
メールアドレス：dawnsong@cmu.edu
J. D. Tygar UC Berkeley - EECS & SIMS 102 South Hall 4600 Berkeley, CA 94720-4600 US
J. D. Tygar UCバークレー - EECS＆SIMS 102南ホール4600バークレー、CA 94720から4600米
EMail: doug.tygar@gmail.com
メールアドレス：doug.tygar@gmail.com
Bob Briscoe BT Research B54/77, BT Labs Martlesham Heath Ipswich, IP5 3RE UK
ボブ・ブリスコーBT研究B54 / 77、BT研究所Martleshamヒースイプスウィッチ、IP5 3RE英国
EMail: bob.briscoe@bt.com
メールアドレス：bob.briscoe@bt.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。