Internet Engineering Task Force (IETF) V. Roca
Request for Comments: 5776 A. Francillon
Category: Experimental S. Faurite
ISSN: 2070-1721 INRIA
April 2010
Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
非同期階層における時限効率的なストリーム損失トレラント認証（TESLA）コーディング（ALC）とNACK指向リライアブルマルチキャスト（NORM）プロトコルの使用
Abstract
抽象
This document details the Timed Efficient Stream Loss-Tolerant Authentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document.
この文書では、時限効率的なストリーム損失トレラント認証（TESLA）パケットの送信元認証とパケット整合性検証プロトコルとその非同期階層内での統合コーディング（ALC）とNACK指向リライアブルマルチキャスト（NORM）、コンテンツ配信プロトコルを詳述します。この文書では、セッションの送信者によって生成されたパケットの認証/完全性の検証を考慮します。受信者が送信したパケットの認証と完全性の検証、いずれの場合には、この文書の範囲外です。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5776.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5776で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 6
1.2. Conventions Used in This Document . . . . . . . . . . . . 7
1.3. Terminology and Notations . . . . . . . . . . . . . . . . 7
1.3.1. Notations and Definitions Related to Cryptographic
Functions . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2. Notations and Definitions Related to Time . . . . . . 8
2. Using TESLA with ALC and NORM: General Operations . . . . . . 9
2.1. ALC and NORM Specificities That Impact TESLA . . . . . . . 9
2.2. Bootstrapping TESLA . . . . . . . . . . . . . . . . . . . 10
2.2.1. Bootstrapping TESLA with an Out-Of-Band Mechanism . . 10
2.2.2. Bootstrapping TESLA with an In-Band Mechanism . . . . 11
2.3. Setting Up a Secure Time Synchronization . . . . . . . . . 11
2.3.1. Direct Time Synchronization . . . . . . . . . . . . . 12
2.3.2. Indirect Time Synchronization . . . . . . . . . . . . 12
2.4. Determining the Delay Bounds . . . . . . . . . . . . . . . 13
2.4.1. Delay Bound Calculation in Direct Time
Synchronization Mode . . . . . . . . . . . . . . . . . 14
2.4.2. Delay Bound Calculation in Indirect Time
Synchronization Mode . . . . . . . . . . . . . . . . . 14
2.5. Cryptographic Parameter Values . . . . . . . . . . . . . . 15
3. Sender Operations . . . . . . . . . . . . . . . . . . . . . . 16
3.1. TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 16
3.1.1. Time Intervals . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Key Chains . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3. Time Interval Schedule . . . . . . . . . . . . . . . . 20
3.1.4. Timing Parameters . . . . . . . . . . . . . . . . . . 20
3.2. TESLA Signaling Messages . . . . . . . . . . . . . . . . . 21
3.2.1. Bootstrap Information . . . . . . . . . . . . . . . . 21
3.2.2. Direct Time Synchronization Response . . . . . . . . . 22
3.3. TESLA Authentication Information . . . . . . . . . . . . . 22
3.3.1. Authentication Tags . . . . . . . . . . . . . . . . . 23
3.3.2. Digital Signatures . . . . . . . . . . . . . . . . . . 23
3.3.3. Group MAC Tags . . . . . . . . . . . . . . . . . . . . 24
3.4. Format of TESLA Messages and Authentication Tags . . . . . 25
3.4.1. Format of a Bootstrap Information Message . . . . . . 26
3.4.2. Format of a Direct Time Synchronization Response . . . 31
3.4.3. Format of a Standard Authentication Tag . . . . . . . 32
3.4.4. Format of an Authentication Tag without Key
Disclosure . . . . . . . . . . . . . . . . . . . . . . 33
3.4.5. Format of an Authentication Tag with a "New Key
Chain" Commitment . . . . . . . . . . . . . . . . . . 34
3.4.6. Format of an Authentication Tag with a "Last Key
of Old Chain" Disclosure . . . . . . . . . . . . . . . 35
4. Receiver Operations . . . . . . . . . . . . . . . . . . . . . 36
4.1. Verification of the Authentication Information . . . . . . 36
4.1.1. Processing the Group MAC Tag . . . . . . . . . . . . . 36
4.1.2. Processing the Digital Signature . . . . . . . . . . . 37
4.1.3. Processing the Authentication Tag . . . . . . . . . . 37
4.2. Initialization of a Receiver . . . . . . . . . . . . . . . 38
4.2.1. Processing the Bootstrap Information Message . . . . . 38
4.2.2. Performing Time Synchronization . . . . . . . . . . . 38
4.3. Authentication of Received Packets . . . . . . . . . . . . 40
4.3.1. Discarding Unnecessary Packets Earlier . . . . . . . . 43
4.4. Flushing the Non-Authenticated Packets of a Previous
Key Chain . . . . . . . . . . . . . . . . . . . . . . . . 43
5. Integration in the ALC and NORM Protocols . . . . . . . . . . 44
5.1. Authentication Header Extension Format . . . . . . . . . . 44
5.2. Use of Authentication Header Extensions . . . . . . . . . 45
5.2.1. EXT_AUTH Header Extension of Type Bootstrap
Information . . . . . . . . . . . . . . . . . . . . . 45
5.2.2. EXT_AUTH Header Extension of Type Authentication
Tag . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.3. EXT_AUTH Header Extension of Type Direct Time
Synchronization Request . . . . . . . . . . . . . . . 49
5.2.4. EXT_AUTH Header Extension of Type Direct Time
Synchronization Response . . . . . . . . . . . . . . . 49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 50
6.1. Dealing with DoS Attacks . . . . . . . . . . . . . . . . . 50
6.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 51
6.2.1. Impacts of Replay Attacks on TESLA . . . . . . . . . . 51
6.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 52
6.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 53
6.3. Security of the Back Channel . . . . . . . . . . . . . . . 53
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1. Normative References . . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . . 56
Many applications using multicast and broadcast communications require that each receiver be able to authenticate the source of any packet it receives as well as the integrity of these packets. This is the case with ALC [RFC5775] and NORM [RFC5740], two Content Delivery Protocols (CDPs) designed to transfer objects (e.g., files) reliably between a session's sender and several receivers. The NORM protocol is based on bidirectional transmissions. Each receiver acknowledges data received or, in case of packet erasures, asks for retransmissions. On the opposite, the ALC protocol is based on purely unidirectional transmissions. Reliability is achieved by means of the cyclic transmission of the content within a carousel and/or by the use of proactive Forward Error Correction (FEC) codes. Both protocols have in common the fact that they operate at the application level, on top of an erasure channel (e.g., the Internet) where packets can be lost (erased) during the transmission.
マルチキャストおよびブロードキャスト通信を使用して多くのアプリケーションでは、各受信機が受信したパケットの送信元だけでなく、これらのパケットの完全性を認証できることが必要です。これは、ALC [RFC5775]とNORM [RFC5740]、確実にセッションの送信者と複数の受信機間でオブジェクト（例えば、ファイル）を転送するために設計された2つのコンテンツ配信プロトコル（のCDP）の場合です。 NORMプロトコルは双方向の伝送に基づいています。各受信機は、受信したデータを承認または、パケット消失の場合には、再送を要求します。反対に、ALCプロトコルは、純粋に単方向の伝送に基づいています。信頼性および/またはプロアクティブ順方向誤り訂正（FEC）符号を用いてカルーセル内のコンテンツのサイクリック伝送によって達成されます。両方のプロトコルは、一般的に、彼らはパケットが送信中に失われた（消去）することができる消去チャネル（例えば、インターネット）の上に、アプリケーションレベルで動作するという事実を持っています。
The goal of this document is to counter attacks where an attacker impersonates the ALC or NORM session's sender and injects forged packets to the receivers, thereby corrupting the objects reconstructed by the receivers.
このドキュメントの目標は、攻撃者がALCまたはNORMセッションの送信者を偽装することにより、受信機によって再構築されたオブジェクトを破壊、受信機にパケットを偽造噴射する攻撃に対抗するためです。
Preventing this attack is much more complex in the case of group communications than it is with unicast communications. Indeed, with unicast communications, a simple solution exists: the sender and the receiver share a secret key to compute a Message Authentication Code (MAC) of all messages exchanged. This is no longer feasible in the case of multicast and broadcast communications since sharing a group key between the sender and all receivers implies that any group member can impersonate the sender and send forged messages to other receivers.
この攻撃を防ぐことは、それがユニキャスト通信であるよりも、グループ通信の場合にははるかに複雑です。確かに、ユニキャスト通信と、シンプルなソリューションが存在します。送信者と受信者は、すべてのメッセージのメッセージ認証コード（MAC）は、交換を計算するために秘密鍵を共有します。これは、送信者の間で、グループ鍵を共有するので、もはや実現可能なマルチキャストおよびブロードキャスト通信の場合ではありませんし、すべての受信機は、任意のグループのメンバーは、送信者を偽装して、他の受信者に偽造メッセージを送ることができることを意味します。
The usual solution to provide the source authentication and message integrity services in the case of multicast and broadcast communications consists of relying on asymmetric cryptography and using digital signatures. Yet, this solution is limited by high computational costs and high transmission overheads. The Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol is an alternative solution that provides the two required services, while being compatible with high-rate transmissions over lossy channels.
マルチキャスト及びブロードキャスト通信の場合、ソース認証とメッセージ整合性サービスを提供する通常の解決策は、非対称暗号に依存し、デジタル署名を使用することからなります。しかし、このソリューションは、高い計算コストと高い伝送オーバーヘッドによって制限されています。時限効率ストリーム損失トレラント認証（テスラ）プロトコルは、損失の多いチャネル上で高速伝送との互換性でありながら、2つの必要なサービスを提供する別の解決策です。
This document explains how to integrate the TESLA source authentication and packet integrity protocol to the ALC and NORM CDP. Any application built on top of ALC and NORM will directly benefit from the services offered by TESLA at the transport layer. In particular, this is the case of File Delivery over Unidirectional Transport (FLUTE).
この文書では、ALCとNORM CDPにTESLAソース認証とパケット整合性プロトコルを統合する方法について説明します。 ALCとNORMの上に構築された任意のアプリケーションは直接トランスポート層でTESLAによって提供されるサービスの恩恵を受ける。特に、これは単方向交通（FLUTE）を超えるファイル配信の場合です。
For more information on the TESLA protocol and its principles, please refer to [RFC4082] and [Perrig04]. For more information on ALC and NORM, please refer to [RFC5775], [RFC5651], and [RFC5740], respectively. For more information on FLUTE, please refer to [RMT-FLUTE].
TESLAプロトコルとその原則の詳細については、[Perrig04] [RFC4082]を参照してください。 ALCおよびNORMの詳細については、それぞれ、[RFC5775]、[RFC5651]、および[RFC5740]を参照してください。 FLUTEの詳細については、[RMT-FLUTE]を参照してください。
This specification only considers the authentication and integrity verification of the packets generated by the session's sender. This specification does not consider the packets that may be sent by receivers, for instance, NORM's feedback packets. [RMT-SIMPLE-AUTH] describes several techniques that can be used to that purpose. Since this is usually a low-rate flow (unlike the downstream flow), using computing intensive techniques like digital signatures, possibly combined with a Group MAC scheme, is often acceptable. Finally, Section 5 explains how to use several authentication schemes in a given session thanks to the "ASID" (Authentication Scheme IDentifier) field.
この仕様は、セッションの送信者によって生成されたパケットの認証と完全性の検証を考慮しています。この仕様は、インスタンス、NORMのフィードバックパケットのために、受信機によって送信されるパケットを考慮しません。 [RMT-SIMPLE-AUTH]は、この目的に使用することができるいくつかの技術が記載されています。これは通常（下流流れとは異なり）、低速度流であるため、おそらくグループMACスキームと組み合わせたデジタル署名など計算集約的技術を使用して、しばしば許容されます。最後に、第5節では、「ASID」（認証スキーム識別子）フィールドに与えられたセッションのおかげで、いくつかの認証方式を使用する方法について説明します。
This specification relies on several external mechanisms, for instance:
この仕様は、例えば、いくつかの外部のメカニズムに依存しています：
o to communicate securely the public key or a certificate for the session's sender (Section 2.2.2);
安全に公開鍵またはセッションの送信者（2.2.2）の証明書を通信するために、O。
o to communicate securely and confidentially the group key, K_g, used by the Group MAC feature, when applicable (Section 3.3.3). In some situations, this group key will have to be periodically refreshed;
安全かつ機密グループMAC機能によって使用されるグループ鍵、K_Gを通信するためのO、該当する場合（セクション3.3.3）。いくつかの状況では、このグループのキーは定期的に更新する必要があります。
o to perform secure time synchronization in indirect mode (Section 2.3.2) or in direct mode (Section 2.3.1) to carry the request/response messages with ALC, which is purely unidirectional;
O（セクション2.3.2）またはダイレクトモード（2.3.1項）純粋に一方向であるALCとの要求/応答メッセージを運ぶために間接モードで安全な時刻同期を実行します。
These mechanisms are required in order to bootstrap TESLA at a sender and at a receiver and must be deployed in parallel to TESLA. Besides, the randomness of the Primary Key of the key chain (Section 3.1.2) is vital to the security of TESLA. Therefore, the sender needs an appropriate mechanism to generate this random key.
これらのメカニズムは、送信時と受信機でTESLAをブートストラップするために必要とされるとTESLAに並列に配備しなければなりません。また、キーチェーン（3.1.2）の主キーのランダム性がTESLAのセキュリティに不可欠です。したがって、送信者は、このランダムなキーを生成するための適切なメカニズムを必要とします。
Several technical details of TESLA, like the most appropriate way to alternate between the transmission of a key disclosure and a commitment to a new key chain, or the transmission of a key disclosure and the last key of the previous key chain, or the disclosure of a key and the compact flavor that does not disclose any key, are specific to the target use case (Section 3.1.2). For
キー開示の送信と新しいキーチェーン、またはキー開示の送信と前回のキーチェーンの最後のキー、または開示へのコミットメントとの間で交互にする最も適切な方法のようなTESLAのいくつかの技術的な詳細、キーと任意のキーを開示していないコンパクトな味は、対象のユースケース（セクション3.1.2）に固有のものです。ために
instance, it depends on the number of packets sent per time interval, on the desired robustness and the acceptable transmission overhead, which can only be optimized after taking into account the use-case specificities.
例えば、所望のロバスト性のみ考慮ユースケースの特異性を取った後に最適化することができる許容される伝送オーバーヘッド、上、時間間隔ごとに送信されたパケットの数に依存します。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The following notations and definitions are used throughout this document.
次の表記及び定義は、この文書全体で使用されています。
Notations and definitions related to cryptographic functions [RFC4082][RFC4383]:
暗号化機能に関連する表記と定義[RFC4082]、[RFC4383]：
o PRF is the Pseudo Random Function;
O PRFは、擬似ランダム関数です。
o MAC is the Message Authentication Code;
O MACは、メッセージ認証コードです。
o HMAC is the keyed-Hash Message Authentication Code;
O HMACは、ハッシュキーメッセージ認証コードです。
o F is the one-way function used to create the key chain (Section 3.1.2.1);
O Fは、キーチェーン（セクション3.1.2.1）を作成するために使用される一方向関数です。
o F' is the one-way function used to derive the HMAC keys (Section 3.1.2.1);
O F」は、HMACキー（セクション3.1.2.1）を導出するために使用される一方向関数です。
o n_p is the length, in bits, of the F function's output. This is therefore the length of the keys in the key chain;
O N_Pは、F関数の出力のビット単位の長さは、です。したがって、これは、キーチェーン内のキーの長さです。
o n_f is the length, in bits, of the F' function's output. This is therefore the length of the HMAC keys;
O n_fはF」関数の出力のビット単位の長さは、です。したがって、これは、HMACキーの長さです。
o n_m is the length, in bits, of the truncated output of the MAC [RFC2104]. Only the n_m most significant bits of the MAC output are kept;
O n_mはMAC [RFC2104]の切断出力のビット単位の長さは、です。 MAC出力だけn_m最上位ビットが保持されます。
o N is the length of a key chain. There are N+1 keys in a key chain: K_0, K_1, ..., K_N. When several chains are used, all the chains MUST have the same length and keys are numbered consecutively, following the time interval numbering;
O Nは、キーチェーンの長さです。 K_0、K_1、...、K_N：キーチェーンにおけるN + 1つのキーがあります。いくつかのチェーンが使用されている場合は、すべてのチェーンは、同じ長さでなければなりませんし、キーは、時間間隔の番号以下、連続的に番号付けされています。
o n_c is the number of keys in a key chain. Therefore, n_c = N+1;
O N_Cは、キーチェーン内のキーの数です。したがって、N_C = N + 1。
o n_tx_lastkey is the number of additional intervals during which the last key of the old key chain SHOULD be sent, after switching to a new key chain and after waiting for the disclosure delay d. These extra transmissions take place after the interval during which the last key is normally disclosed. The n_tx_lastkey value is either 0 (no extra disclosure) or larger. This parameter is sender specific and is not communicated to the receiver;
O n_tx_lastkeyは古いキーチェーンの最後のキーが新しいキーチェーンに切り替えた後及び開示の遅延dを待って、送信されるべき時に追加の間隔の数です。これらの追加の送信は、最後のキーが正常に開示されている間の時間間隔の後に行われます。 n_tx_lastkey値は0（余分な開示）以上のいずれかです。このパラメータは、送信者固有のものであり、受信機に伝達されません。
o n_tx_newkcc is the number of intervals during which the commitment to a new key chain SHOULD be sent, before switching to the new key chain. The n_tx_newkcc value is either 0 (no commitment sent within authentication tags) or larger. This parameter is sender specific and is not communicated to the receiver;
Oのn_tx_newkccは、新しいキーチェーンへのコミットメントは、新しいキーチェーンに切り替える前に、送信されるべき時に間隔の数です。 n_tx_newkcc値は0（コミットメントは認証タグ内に送信されない）以上のいずれかです。このパラメータは、送信者固有のものであり、受信機に伝達されません。
o K_g is a shared group key, communicated to all group members, confidentially, during the TESLA bootstrapping (Section 2.2);
O K_GはTESLAブートストラップ（セクション2.2）の間に、機密、すべてのグループメンバーに伝え共有グループ鍵です。
o n_w is the length, in bits, of the truncated output of the MAC of the optional group authentication scheme: only the n_w most significant bits of the MAC output are kept. n_w is typically small, a multiple of 32 bits (e.g., 32 bits).
O n_wは、オプションのグループ認証方式のMACの短縮出力の、ビットで、長さ：MAC出力のみn_w最上位ビットが保持されます。 n_wは、32ビット（例えば、32ビット）の倍数、典型的には小さいです。
Notations and definitions related to time:
時間に関連する表記法と定義：
o i is the time interval index. Interval numbering starts at 0 and increases consecutively. Since the interval index is stored as a 32-bit unsigned integer, wrapping to 0 might take place in long sessions.
O私は時間間隔のインデックスです。間隔番号は0から始まり、連続して増加します。間隔インデックスは、32ビットの符号なし整数として格納されているので、0にラップする長いセッションで起こるかもしれません。
o t_s is the sender local time value at some absolute time (in NTP timestamp format);
O T_Sは（NTPタイムスタンプ形式で）いくつかの絶対時間で送信側のローカル時間値です。
o t_r is the receiver local time value at the same absolute time (in NTP timestamp format);
O T_Rは（NTPタイムスタンプ形式で）同じ絶対時間で受信機のローカル時間値です。
o T_0 is the start time corresponding to the beginning of the session, i.e., the beginning of time interval 0 (in NTP timestamp format);
O T_0は（NTPタイムスタンプ形式）時間間隔0の始まり、すなわち、セッションの開始に対応する開始時間です。
o T_int is the interval duration (in milliseconds);
O T_INTは（ミリ秒）間隔期間です。
o d is the key disclosure delay (in number of intervals);
O Dは、（間隔の数で）鍵開示遅延です。
o D_t is the upper bound of the lag of the receiver's clock with respect to the clock of the sender;
O D_tは、送信側のクロックに対する受信機のクロックの遅延の上限です。
o S_sr is an estimated bound of the clock drift between the sender and a receiver throughout the duration of the session;
O S_sr、推定セッション期間を通じて送信側と受信側との間のクロックドリフトの結合しています。
o D^O_t is the upper bound of the lag of the sender's clock with respect to the time reference in indirect time synchronization mode;
O D ^ O_t間接時刻同期モードの時間基準に対する送信者のクロックの遅延の上限です。
o D^R_t is the upper bound of the lag of the receiver's clock with respect to the time reference in indirect time synchronization mode;
O D ^ R_T間接時刻同期モードの時間基準に対する受信機のクロックの遅延の上限です。
o D_err is an upper bound of the time error between all the time references, in indirect time synchronization mode;
O D_err間接時刻同期モードでは、すべての時間基準との間の時間誤差の上限です。
o NTP timestamp format consists in a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits, and the fraction part in the last 32 bits [RFC1305].
O NTPタイムスタンプ形式1月1日1900整数部分は最初の32ビットであるに0hに相対秒、64ビットの符号なしの固定小数点数で構成され、そして最後の32ビット[RFC1305]で小数部。
The ALC and NORM protocols have features and requirements that largely impact the way TESLA can be used.
ALCとNORMプロトコルは、主にTESLAを使用できる方法に影響を与える機能と要件を持っています。
In the case of ALC:
ALCの場合：
o ALC is massively scalable: nothing in the protocol specification limits the number of receivers that join a session. Therefore, an ALC session potentially includes a huge number (e.g., millions or more) of receivers;
O ALCは、大規模スケーラブルです：プロトコル仕様には何もセッションに参加する受信機の数を制限しません。したがって、ALCセッションは、潜在的に膨大な数の受信機（例えば、数百万以上）を含みます。
o ALC can work on top of purely unidirectional transport channels: this is one of the assets of ALC, and examples of unidirectional channels include satellite (even if a back channel might exist in some use cases) and broadcasting networks like Digital Video Broadcasting - Handhelds / Satellite services to Handhelds (DVB-H/SH);
ALCは、純粋に一方向のトランスポート・チャネル上で動作することができ、O：これはALCの資産の一つであり、単方向チャネルの例は、衛星（バックチャネルは、いくつかのユースケースに存在する可能性がある場合でも）、およびデジタルビデオ放送などの放送ネットワークを含む - ハンドヘルドハンドヘルド（DVB-H / SH）へ/衛星サービス。
o ALC defines an on-demand content delivery model [RFC5775] where receivers can arrive at any time, at their own discretion, download the content and leave the session. Other models (e.g., push or streaming) are also defined;
O ALCは、受信機が、自分の裁量で、いつでも到着するコンテンツをダウンロードして、セッションを残すことができ、オンデマンドコンテンツ配信モデル[RFC5775]を定義します。他のモデル（例えば、プッシュ又はストリーミング）も定義されています。
o ALC sessions are potentially very long: a session can last several days or months during which the content is continuously transmitted within a carousel. The content can be either static (e.g., a software update) or dynamic (e.g., a web site).
ALCセッションは、潜在的に非常に長い○：セッションは、コンテンツが連続してカルーセル内で送信されている間、数日または数ヶ月続くことができます。コンテンツ（例えば、ソフトウェア更新）静的または（例えば、ウェブサイト）動的のいずれかであり得ます。
Depending on the use case, some of the above features may not apply. For instance, ALC can also be used over a bidirectional channel or with a limited number of receivers.
ユースケースによっては、上記の機能の一部は適用されない場合があります。例えば、ALCは、双方向チャネルを介して、または受信機の限定された数で使用することができます。
In the case of NORM:
NORMの場合：
o NORM has been designed for medium-size sessions: indeed, NORM relies on feedback messages and the sender may collapse if the feedback message rate is too high;
O NORMは、中サイズのセッションのために設計されています。確かに、NORMは、フィードバックメッセージに依存しており、フィードバックメッセージ率が高すぎる場合、送信者が崩壊します。
o NORM requires a bidirectional transport channel: the back channel is not necessarily a high-data rate channel since the control traffic sent over it by a single receiver is an order of magnitude lower than the downstream traffic. Networks with an asymmetric connectivity (e.g., a high-rate satellite downlink and a low-rate return channel) are appropriate.
O NORMは、双方向トランスポートチャネルを必要とする：単一の受信機によってそれを介して送信される制御トラフィックはダウンストリームトラフィックよりも低い大きさのオーダーであるため、バックチャネルは、必ずしも高データレートチャネルはありません。非対称接続性（例えば、高速衛星ダウンリンク及び低速リターン・チャンネル）を有するネットワークが適切です。
In order to initialize the TESLA component at a receiver, the sender MUST communicate some key information in a secure way, so that the receiver can check the source of the information and its integrity. Two general methods are possible:
受信機は情報のソースとその完全性をチェックできるように、受信機でTESLAコンポーネントを初期化するために、送信者は、安全な方法でいくつかの重要な情報を通信しなければなりません。 2つの一般的な方法が考えられます。
o by using an out-of-band mechanism, or
Oアウトオブバンドメカニズムを使用することによって、又は
o by using an in-band mechanism.
インバンド・メカニズムを使用することにより、O。
The current specification does not recommend any mechanism to bootstrap TESLA. Choosing between an in-band and out-of-band scheme is left to the implementer, depending on the target use case. However, it is RECOMMENDED that TESLA implementations support the use of the in-band mechanism for interoperability purposes.
現在の仕様では、TESLAをブートストラップするための任意のメカニズムを推奨していません。バンドおよびアウトオブバンド方式を対象ユースケースに応じて、実装者に任されている間の選択。しかし、TESLAの実装は、相互運用性のために、インバンドのメカニズムの使用をサポートすることが推奨されます。
For instance, [RFC4442] describes the use of the MIKEY (Multimedia Internet Keying) protocol to bootstrap TESLA. As a side effect, MIKEY also provides a loose time synchronization feature from which TESLA can benefit. Other solutions, for instance, based on an extended session description, are possible, on the condition that these solutions provide the required security level.
例えば、[RFC4442]はTESLAをブートストラップするMIKEY（マルチメディアインターネットキーイング）プロトコルの使用を記載しています。副作用として、MIKEYはまたTESLAが利益を得ることができ、そこから緩い時刻同期機能を提供します。拡張セッション記述に基づいて、例えば、他のソリューションは、これらの解決策は、必要なセキュリティレベルを提供することを条件に、可能です。
This specification describes an in-band mechanism. In some use cases, it might be desired that bootstrapping take place without requiring the use of an additional external mechanism. For instance, each device may feature a clock with a known time-drift that is negligible in front of the time accuracy required by TESLA, and each device may embed the public key of the sender. It is also possible that the use case does not feature a bidirectional channel that prevents the use of out-of-band protocols like MIKEY. For these two examples, the exchange of a bootstrap information message (described in Section 3.4.1) and the knowledge of a few additional parameters (listed below) are sufficient to bootstrap TESLA at a receiver.
この仕様は、帯域内メカニズムについて説明します。いくつかのユースケースでは、ブートストラップは、追加の外部メカニズムの使用を必要とせずに場所を取ることが望まれるかもしれません。例えば、各装置はTESLAによって必要とされる時間精度の前に無視できる既知の時間ドリフトを有するクロックを備えていてもよく、各装置は、送信者の公開鍵を埋め込むことができます。ユースケースは、MIKEYなどのアウトオブバンドプロトコルの使用を防ぐ双方向チャネルを備えていないことも可能です。これら二つの例のために、ブートストラップ情報メッセージ（セクション3.4.1に記載）および（下記参照）、いくつかの追加のパラメータの知識の交換は、受信機でTESLAをブートストラップするのに十分です。
Some parameters cannot be communicated in-band. In particular:
いくつかのパラメータは、帯域内通信することはできません。特に：
o the sender or group controller MUST either communicate the public key of the sender or a certificate (which also means that a PKI has been set up) to all receivers, so that each receiver be able to verify the signature of the bootstrap message and direct time synchronization response messages (when applicable).
各受信機は、ブートストラップメッセージと直接の署名を検証することができるように、O送信者またはグループコントローラは、全ての受信機に（また、PKIが設定されていることを意味する）、送信者の公開鍵または証明書を通信しなければならないのいずれかで時刻同期応答メッセージ（該当する場合）。
o when time synchronization is performed with NTP/SNTP (Simple Network Time Protocol), the sender or group controller MUST communicate the list of valid NTP/SNTP servers to all the session members (sender included), so that they are all able to synchronize themselves on the same NTP/SNTP servers.
時刻同期はNTP / SNTP（簡易ネットワークタイムプロトコル）を用いて実施されたとき、彼らはすべて同期することができるように、O、送信者またはグループコントローラは、すべてのセッションメンバー（送信者が含まれています）に有効なNTP / SNTPサーバのリストを通信する必要があります同じNTP / SNTPサーバ上の自分自身。
o when the Group MAC feature is used, the sender or group controller MUST communicate the K_g group key to all the session members (sender included). This group key may be periodically refreshed.
グループMAC機能を使用する場合、O、送信者またはグループコントローラは、（送信者を含む）すべてのセッションメンバーにK_Gグループ鍵を通信しなければなりません。このグループキーは定期的に更新することができます。
The way these parameters are communicated is out of the scope of this document.
これらのパラメータが伝達される方法は、この文書の範囲外です。
The security offered by TESLA heavily relies on time. Therefore, the session's sender and each receiver need to be time synchronized in a secure way. To that purpose, two general methods exist:
TESLAによって提供されるセキュリティは重く、時間に依存しています。そのため、セッションの送信者と各受信機が安全な方法で同期した時間にする必要があります。その目的のために、2つの一般的な方法が存在します。
o direct time synchronization, and
Oダイレクト時刻同期、および
o indirect time synchronization.
O間接的な時刻同期。
It is also possible that a given session includes receivers that use the direct time synchronization mode while others use the indirect time synchronization mode.
与えられたセッションは、他の人が間接的な時刻同期モードを使用しながら、直接時刻同期モードを使用する受信機を含むことも可能です。
When direct time synchronization is used, each receiver asks the sender for a time synchronization. To that purpose, a receiver sends a direct time synchronization request (Section 4.2.2.1). The sender then directly answers each request with a direct time synchronization response (Section 3.4.2), signing this reply. Upon receiving this response, a receiver first verifies the signature, and then calculates an upper bound of the lag of his clock with respect to the clock of the sender, D_t. The details on how to calculate D_t are given in Section 2.4.1.
直接時刻同期を使用した場合、各受信機は、時間同期のために送信者に要求します。その目的のために、受信機は、直接、時刻同期要求（セクション4.2.2.1）を送信します。送信者は、直接この回答に署名、直接時刻同期応答（3.4.2項）で各要求に答えます。この応答を受信すると、受信機は、最初の署名を検証し、その後、送信側のクロック、D_tに対する彼のクロックの遅延の上限を算出します。 D_tの計算方法の詳細は、セクション2.4.1に記載されています。
This synchronization method is both simple and secure. Yet, there are two potential issues:
この同期方法は簡単で、安全な両方です。しかし、二つの潜在的な問題があります。
o a bidirectional channel must exist between the sender and each receiver, and
O双方向チャネルは、送信者と各受信機との間に存在しなければならず
o the sender may collapse if the incoming request rate is too high.
着信要求率が高すぎるとO送信者がつぶれることがあります。
Relying on direct time synchronization is not expected to be an issue with NORM since (1) bidirectional communications already take place, and (2) NORM scalability is anyway limited. Yet, it can be required that a mechanism, that is out of the scope of this document, be used to spread the transmission of direct time synchronization request messages over time if there is a risk that the sender may collapse.
直接時刻同期に頼っては、（1）双方向通信が既に行われ、および（2）NORMのスケーラビリティはとにかく限られているので、NORMの問題であることが予想されていません。しかし、この文書の範囲外にあるメカニズムは、送信者が崩壊する危険性がある場合は時間をかけて直接時刻同期要求メッセージの送信を拡散するために使用されることを必要とすることができます。
But direct time synchronization is potentially incompatible with ALC since (1) there might not be a back channel, and (2) there are potentially a huge number of receivers and therefore a risk that the sender will collapse.
しかし、直接的な時刻同期は、（1）バックチャンネルは存在しない可能性がありますので、ALCと潜在的に互換性がない、及び（2）受信機の膨大な数のため、送信者が崩壊するリスクが潜在的にあります。
When indirect time synchronization is used, the sender and each receiver must synchronize securely via an external time reference. Several possibilities exist:
間接的な時刻同期を使用した場合、送信者および各受信機は、外部の時間基準を介して確実に同期する必要があります。いくつかの可能性が存在します。
o sender and receivers can synchronize through an NTPv3 (Network Time Protocol version 3) [RFC1305] hierarchy of servers. The authentication mechanism of NTPv3 MUST be used in order to authenticate each NTP message individually. It prevents, for instance, an attacker from impersonating an NTP server;
O送信者と受信者は、サーバのNTPv3（ネットワーク・タイム・プロトコルバージョン3）[RFC1305]階層を同期させることができます。 NTPv3の認証機構は、個別に各NTPメッセージを認証するために使用されなければなりません。それは、例えば、NTPサーバを偽装からの攻撃を防ぎます。
o they can synchronize through an NTPv4 (Network Time Protocol version 4) [NTP-NTPv4] hierarchy of servers. The Autokey security protocol of NTPv4 MUST be used in order to authenticate each NTP message individually;
O彼らはNTPv4（ネットワーク・タイム・プロトコル・バージョン4）サーバの[NTP-NTPv4]階層を同期させることができます。 NTPv4のオートキーのセキュリティプロトコルは、個別に各NTPメッセージを認証するために使用されなければなりません。
o they can synchronize through an SNTPv4 (Simple Network Time Protocol version 4) [RFC4330] hierarchy of servers. The authentication features of SNTPv4 must then be used. Note that TESLA only needs a loose (but secure) time synchronization, which is in line with the time synchronization service offered by SNTP;
O彼らは、サーバのSNTPv4（簡易ネットワークタイムプロトコルバージョン4）[RFC4330]階層を同期させることができます。 SNTPv4の認証機能は、使用する必要があります。 TESLAのみSNTPによって提供される時間同期サービスに沿ったものであるルーズ（ただし、セキュアな）時間同期を必要とすることに留意されたいです。
o they can synchronize through a GPS or Galileo (or similar) device that also provides a high precision time reference. Spoofing attacks on the GPS system have recently been reported. Depending on the use case, the security achieved will or will not be acceptable;
O彼らはまた、高精度の時間基準を提供するGPS又はガリレオ（又は類似の）デバイスを介して同期させることができます。 GPSシステム上のスプーフィング攻撃は、最近報告されています。ユースケースによっては、セキュリティが意志を達成したり許容されません。
o they can synchronize thanks to a dedicated hardware, embedded on each sender and receiver, that provides a clock with a time-drift that is negligible in front of the TESLA time accuracy requirements. This feature enables a device to synchronize its embedded clock with the official time reference from time to time (in an extreme case once, at manufacturing time), and then to remain autonomous for a duration that depends on the known maximum clock drift.
OそれらはTESLA時間精度要件の前に無視できる時間ドリフトのクロックを提供し、各送信側と受信側に組み込まれた専用のハードウェア、のおかげで同期させることができます。この機能は、（製造時に、一度極端な場合には）随時公式時間基準との埋め込まれたクロックを同期させるデバイスを可能にし、その後、既知の最大クロックドリフトに依存する持続時間自律ままにします。
A bidirectional channel is required by the NTP/SNTP schemes. On the opposite, with the GPS/Galileo and high precision clock schemes, no such assumption is made. In situations where ALC is used on purely unidirectional transport channels (Section 2.1), using the NTP/SNTP schemes is not possible. Another aspect is the scalability requirement of ALC, and to a lesser extent of NORM. From this point of view, the above mechanisms usually do not raise any problem, unlike the direct time synchronization schemes. Therefore, using indirect time synchronization can be a good choice. It should be noted that the NTP/SNTP schemes assume that each client trusts the sender and accepts aligning its NTP/SNTP configuration to that of the sender. If this assumption does not hold, the sender SHOULD offer an alternative solution.
双方向チャネルは、NTP / SNTPスキームによって必要とされます。反対に、GPS /ガリレオと高精度クロック方式を用いて、そのような仮定は行われません。 ALCは、純粋に単方向トランスポートチャネル（セクション2.1）に使用される状況では、NTP / SNTPスキームを使用することは不可能です。別の態様は、ALCのスケーラビリティ要件であり、NORMの程度は低いです。この観点から、上記のメカニズムは、通常、直接時刻同期方式とは異なり、任意の問題を提起しません。そのため、間接的な時刻同期を使用することは良い選択することができます。 NTP / SNTPスキームは、各クライアントが送信者を信頼し、送信者のそれにそのNTP / SNTPの設定を合わせる受け入れることを前提としていことに留意すべきです。この仮定が成立しない場合は、送信者は、代替ソリューションを提供する必要があります。
The details on how to calculate an upper bound of the lag of a receiver's clock with respect to the clock of the sender, D_t, are given in Section 2.4.2.
送信者、D_tのクロックに対して、受信機のクロックの遅れの上限を計算する方法についての詳細は、2.4.2項に示されています。
Let us assume that a secure time synchronization has been set up. This section explains how to define the various timing parameters that are used during the authentication of received packets.
私たちは、安全な時刻同期が設定されていると仮定しよう。このセクションでは、受信したパケットの認証時に使用される種々のタイミング・パラメータを定義する方法について説明します。
In direct time synchronization mode, synchronization between a receiver and the sender follows the following protocol [RFC4082]:
直接時刻同期モードでは、受信機と送信者との間の同期は、以下のプロトコル[RFC4082]を次の
o The receiver sends a direct time synchronization request message to the sender, that includes t_r, the receiver local time at the moment of sending (Section 4.2.2.1).
レシーバO（セクション4.2.2.1）を送信する瞬間T_R、受信機のローカル時間を含む送信者に直接時刻同期要求メッセージを送信します。
o Upon receipt of this message, the sender records its local time, t_s, and sends to the receiver a direct time synchronization response that includes t_r (taken from the request) and t_s, signing this reply (Section 3.4.2).
Oこのメッセージを受信すると、送信者は、そのローカル時間を記録T_S、この応答（セクション3.4.2）に署名する、受信機（リクエストから取られた）T_Rを含む直接時刻同期応答とT_Sに送信します。
o Upon receiving this response, the receiver first verifies that he actually sent a request with t_r and then checks the signature. Then he calculates D_t = t_s - t_r + S_sr, where S_sr is an estimated bound of the clock drift between the sender and the receiver throughout the duration of the session. This document does not specify how S_sr is estimated.
Oこの応答を受信すると、受信機は、最初、彼が実際T_Rで要求を送信した後、署名をチェックすることを検証します。それから彼はD_t = T_Sを計算 - S_srは、セッションの間中、送信者と受信者の間のクロックドリフトの下限推定されている+ S_sr、T_R。この文書では、S_srを推定する方法を指定しません。
After this initial synchronization, at any point throughout the session, the receiver knows that: 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、およびT_Rは、受信機で現在の時刻です：この最初の同期の後、セッション全体で任意の時点で、受信機はそれを知っています。
In indirect time synchronization, the sender and the receivers must synchronize indirectly using one or several time references.
間接的な時刻同期では、送信者と受信機は、1つまたはいくつかの時間基準を使用して間接的に同期させる必要があります。
Let us assume that there is a single time reference.
私たちは、単一の時間基準が存在すると仮定しよう。
1. The sender calculates D^O_t, the upper bound of the lag of the sender's clock with respect to the time reference. This D^O_t value is then communicated to the receivers (Section 3.2.1).
1.送信者は、D ^ O_t、時間基準に対する送信者のクロックの遅延の上限を算出します。このD ^ O_t値は、その後、受信機（3.2.1）に伝達されます。
2. Similarly, a receiver R calculates D^R_t, the upper bound of the lag of the receiver's clock with respect to the time reference.
2.同様に、受信機Rは、D ^ R_T、時間基準に対する受信機のクロックの遅延の上限を算出します。
3. Then, for receiver R, the overall upper bound of the lag of the receiver's clock with respect to the clock of the sender, D_t, is the sum: D_t = D^O_t + D^R_t.
3.次に、受信機Rは、送信者、D_tのクロックに対する受信機のクロックのずれの全体的な上限のため、合計である：D_t = D ^ O_t + D ^ R_T。
The D^O_t and D^R_t calculation depends on the time synchronization mechanism used (Section 2.3.2). In some cases, the synchronization scheme specifications provide these values. In other cases, these parameters can be calculated by means of a scheme similar to the one specified in Section 2.4.1, for instance, when synchronization is achieved via a group controller [RFC4082].
D ^ O_t及びD ^ R_T計算が使用される時間同期機構（セクション2.3.2）に依存します。いくつかのケースでは、同期方式の仕様は、これらの値を提供します。他の場合では、これらのパラメータは、同期グループコントローラ[RFC4082]を介して達成された場合、例えば、セクション2.4.1で指定されたものと同様の方式によって計算することができます。
Let us now assume that there are several time references (e.g., several NTP/SNTP servers). The sender and receivers first synchronize with the various time references, independently. It results in D^O_t and D^R_t. Let D_err be an upper bound of the time error between all of the time references. Then, the overall value of D_t within receiver R is set to the sum: D_t = D^O_t + D^R_t + D_err.
私たちは今、いくつかの時間基準（例えば、いくつかのNTP / SNTPサーバ）があると仮定しましょう。送信者と受信者は最初に独立して、様々な時間基準と同期。これは、D ^ O_tとD ^ R_Tになります。 D_errは、時間基準の全ての間の時間の誤差の上限とします。次いで、受信機R内D_tの全体的な値を合計に設定されている：D_t = D ^ O_t + D ^ R_T + D_err。
In some cases, the D_t value is part of the time synchronization scheme specifications. For instance, NTPv3 [RFC1305] defines algorithms that are "capable of accuracies in the order of a millisecond, even after extended periods when synchronization to primary reference sources has been lost". In practice, depending on the NTP server stratum, the accuracy might be a little bit worse. In that case, D_t = security_factor * (1ms + 1ms), where the security_factor is meant to compensate several sources of inaccuracy in NTP. The choice of the security_factor value is left to the implementer, depending on the target use case.
いくつかのケースでは、D_t値は、時間同期方式の仕様の一部です。例えば、NTPv3 [RFC1305]は「一次基準源に同期が失われた場合でも、長期間の後、ミリ秒のオーダーで精度の可能」であるアルゴリズムを定義します。実際には、NTPサーバの階層に応じて、精度が少し悪くなるかもしれません。 security_factorがNTPに不正確さのいくつかの源を補償することを意図されている場合に、D_t = security_factor *（1ミリ秒+ 1ミリ秒）。 security_factor値の選択は、対象ユースケースによっては、実装者に任されています。
The F (resp. F') function output length is given by the n_p (resp. n_f) parameter. The n_p and n_f values depend on the PRF function chosen, as specified below:
F（それぞれF '）関数の出力長はN_P（RESP。n_f）パラメータによって与えられます。以下に指定されるようN_Pとn_f値は、選択されたPRF関数に依存します：
+------------------------+---------------------+
| PRF name | n_p and n_f |
+------------------------+---------------------+
| HMAC-SHA-1 | 160 bits (20 bytes) |
| HMAC-SHA-224 | 224 bits (28 bytes) |
| HMAC-SHA-256 (default) | 256 bits (32 bytes) |
| HMAC-SHA-384 | 384 bits (48 bytes) |
| HMAC-SHA-512 | 512 bits (64 bytes) |
+------------------------+---------------------+
The computing of regular MAC (resp. Group MAC) makes use of the n_m (resp. n_w) parameter, i.e., the length of the truncated output of the function. The n_m and n_w values depend on the MAC function chosen, as specified below:
定期的なMACの計算（それぞれグループMAC）がn_m（RESP。n_w）パラメータ、すなわち、関数の切り捨てられた出力の長さを利用します。以下に指定されるようn_mとn_w値は、選択されたMAC機能に依存します。
+------------------------+---------------------+-------------------+
| MAC name | n_m (regular MAC) | n_w (Group MAC) |
+------------------------+---------------------+-------------------+
| HMAC-SHA-1 | 80 bits (10 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-224 | 112 bits (14 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-256 (default) | 128 bits (16 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-384 | 192 bits (24 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-512 | 256 bits (32 bytes) | 32 bits (4 bytes) |
+------------------------+---------------------+-------------------+
This section describes the TESLA operations at a sender. For more information on the TESLA protocol and its principles, please refer to [RFC4082][Perrig04].
このセクションでは、送信側でTESLA操作について説明します。 TESLAプロトコルとその原則の詳細については、[RFC4082] [Perrig04]を参照してください。
The sender divides the time into uniform intervals of duration T_int. Time interval numbering starts at 0 and is incremented consecutively. The interval index MUST be stored in an unsigned 32-bit integer so that wrapping to 0 takes place only after 2^^32 intervals. For instance, if T_int is equal to 0.5 seconds, then wrapping takes place after approximately 68 years.
送信者は、期間T_INTの均一な間隔に時間を分割します。時間間隔の番号は0から始まり、連続して増加されます。 0にラップするだけ2つの^^ 32の間隔後に行われるようにインターバルインデックスは、符号なし32ビット整数に記憶されなければなりません。 T_INTが0.5秒に等しい場合たとえば、その後、ラッピングは約68年後に行われます。
The sender computes a one-way key chain of n_c = N+1 keys, and assigns one key from the chain to each interval, consecutively but in reverse order. Key numbering starts at 0 and is incremented consecutively, following the time interval numbering: K_0, K_1, ..., K_N.
送信者はN_Cの一方向キーチェーン= N + 1つのキーを計算し、各間隔に鎖からの1つのキー、連続しかし逆の順序で割り当てられます。キー番号は0から始まり、時間間隔ナンバリング以下、連続してインクリメントさ：K_0、K_1、...、K_N。
In order to compute this chain, the sender must first select a Primary Key, K_N, and a PRF function, f (Section 7, TESLA-PRF). The randomness of the Primary Key, K_N, is vital to the security and no one should be able to guess it.
このチェーンを計算するために、送信者は、まず主キー、K_N、およびPRF関数f（第7節、TESLA-PRF）を選択する必要があります。主キー、K_Nのランダム性は、セキュリティに不可欠であると誰もそれを推測することはできないはずです。
The function F is a one-way function that is defined as: F(k) = f_k(0), where f_k(0) is the result of the application of the PRF f to k and 0. When f is an HMAC (Section 7), k is used as the key, and 0 as the message, using the algorithm described in [RFC2104].
fはHMAC（ある場合F_K（0）PRF kにFおよび0.1を適用した結果であるF（K）= F_K（0）：関数Fは、のように定義される一方向関数でありますセクション7）、Kは、[RFC2104]に記載されたアルゴリズムを使用して、キー、およびメッセージとして0として使用されます。
Similarly, the function F' is a one-way function that is defined as: F'(k) = f_k(1), where f_k(1) is the result of the application of the same PRF f to k and 1.
F_Kは、（1）同じPRF kにF 1を適用した結果である（K）= F_K（1）：同様に、関数F「は、Fとして定義される一方向関数です」。
The sender then computes all the keys of the chain, recursively, starting with K_N, using: K_{i-1} = F(K_i). Therefore, K_i = F^{N-i}(K_N), where F^i(x) is the execution of function F with the argument x, i times. The receiver can then compute any value in the key chain from K_N, even if it does not have intermediate values [RFC4082]. The key for MAC calculation can then be derived from the corresponding K_i key by K'_i = F'(K_i).
K_ {I-1} = F（K_Iを）：送信者は、次に使用、K_N始まる、再帰的、チェーンのすべてのキーを計算します。したがって、K_I = F ^ {N-I}（K_N）、Fは^ I（x）は、引数xと関数Fの実行でI倍です。受信機は、それは中間値[RFC4082]を有していない場合でも、K_Nからキーチェーン内の任意の値を計算することができます。 MAC計算のための鍵は、その後K'_i = F '（K_I）によって、対応するK_Iキーから導出することができます。
The key chain has a finite length, N, which corresponds to a maximum time duration of (N + 1) * T_int. The content delivery session has a duration T_delivery, which may either be known in advance, or not. A first solution consists in having a single key chain of an appropriate length, so that the content delivery session finishes before the end of the key chain, i.e., T_delivery <= (N + 1) * T_int. But the longer the key chain, the higher the memory and computation required to cope with it. Another solution consists in switching to a new key chain, of the same length, when necessary [Perrig04].
キーチェーンは、（N + 1）* T_INTの最大持続時間に対応する有限の長さNを有します。コンテンツ配信セッションは、事前に知られている、またはしないことができるいずれかの期間T_deliveryを有しています。コンテンツデリバリセッションを終了するように第1の解決策は、キーチェーン、即ち、T_delivery <=（N + 1）* T_INTの終了前に、適切な長さの単一のキーチェーンを有することにあります。しかし、それに対処するために必要なメモリと計算高い、キーチェーン長いです。別の解決策は、同じ長さ、必要[Perrig04]から、新しいキーチェーンに切り替えることにあります。
When several key chains are needed, all of them MUST be of the same length. Switching from the current key chain to the next one requires that a commitment to the new key chain be communicated in a secure way to the receiver. This can be done by using either an out-of-band mechanism or an in-band mechanism. This document only specifies the in-band mechanism.
いくつかのキーチェーンが必要な場合は、それらのすべてが同じ長さでなければなりません。次のいずれかに現在のキーチェーンから切り替えると、新しいキーチェーンへのコミットメントが受信機に安全な方法で伝達されている必要があります。これは、アウトオブバンド機構や帯域内メカニズムのいずれかを使用して行うことができます。この文書では、唯一のインバンドのメカニズムを指定します。
< -------- old key chain --------- >||< -------- new key chain --...
+-----+-----+ .. +-----+-----+-----+||+-----+-----+-----+-----+-----+
0 1 .. N-2 N-1 N || N+1 N+2 N+3 N+4 N+5
||
Key disclosures: ||
N/A N/A .. K_N-4 K_N-3 K_N-2 || K_N-1 K_N K_N+1 K_N+2 K_N+3
| || | |
|< -------------- >|| |< ------------- >|
Additional key F(K_N+1) || K_N
disclosures (commitment to || (last key of the
(in parallel): the new chain) || old chain)
Figure 1: Switching to the Second Key Chain with the In-Band
Mechanism, Assuming That d=2, n_tx_newkcc=3, n_tx_lastkey=3
Figure 1 illustrates the switch to the new key chain, using the in-band mechanism. Let us say that the old key chain stops at K_N and the new key chain starts at K_{N+1} (i.e., F(K_{N+1}) and K_N are two different keys). Then, the sender includes the commitment F(K_{N+1}) to the new key chain into packets authenticated with the old key chain (see Section 3.4.5). This commitment SHOULD be sent during n_tx_newkcc time intervals before the end of the old key chain. Since several packets are usually sent during an interval, the sender SHOULD alternate between sending a disclosed key of the old key chain and the commitment to the new key chain. The details of how to alternate between the disclosure and commitment are out of the scope of this document.
図1は、インバンド・メカニズムを使用して、新しいキーチェーンへの切り替えを示します。私たちは、古いキーチェーンがK_ {N + 1}（すなわち、F（K_ {N + 1}）とK_N二つの異なる鍵である）でK_N、新しいキーチェーンの開始時に停止することとしましょう。次に、送信者は、古いキーチェーンを使用して認証パケットに新しいキーチェーンへのコミットメントF（K_ {N + 1}）（セクション3.4.5を参照）を含みます。この取り組みは、古いキーチェーンの終了前にn_tx_newkcc時間間隔の間に送ってください。複数のパケットは通常、インターバル中に送信されますので、送信者は古いキーチェーン、新しいキーチェーンへのコミットメントの公開鍵を送信する間で交互にすべきです。開示とコミットメントを交互にする方法の詳細は、この文書の範囲外です。
The receiver will keep the commitment until the key K_{N+1} is disclosed, at interval N+1+d. Then, the receiver will be able to test the validity of that key by computing F(K_{N+1}) and comparing it to the commitment.
受信機は、鍵K_ {N + 1}までの取り組みを続ける+ 1 + D間隔Nで、開示されています。次いで、受信機は、F（K_ {N + 1}）を計算し、コミットメントと比較することによって、そのキーの有効性をテストすることができるであろう。
When the key chain is changed, it becomes impossible to recover a previous key from the old key chain. This is a problem if the receiver lost the packets disclosing the last key of the old key chain. A solution consists in re-sending the last key, K_N, of the old key chain (see Section 3.4.6). This SHOULD be done during n_tx_lastkey additional time intervals after the end of the time interval where K_N is disclosed. Since several packets are usually sent during an interval, the sender SHOULD alternate between sending a disclosed key of the new key chain, and the last key of the old key chain. The details of how to alternate between the two disclosures are out of the scope of this document.
キーチェーンが変更されると、それは古いキーチェーンから、以前の鍵を復元することができなくなってしまいます。受信機は古いキーチェーンの最後のキーを公開するパケットを失った場合、これは問題です。解決策は、古いキーチェーン（3.4.6項を参照）の最後のキー、K_Nを、再送信で構成されています。これはK_Nが開示されている時間間隔の終了後n_tx_lastkey追加の時間間隔の間に行われるべきです。複数のパケットは通常、インターバル中に送信されますので、送信者は、新しいキーチェーンの公開鍵、および古いキーチェーンの最後のキーを送信する間で交互にすべきです。 2つの開示の間で交互にする方法の詳細は、この文書の範囲外です。
In some cases, a receiver having experienced a very long disconnection might have lost the commitment of the new chain. Therefore, this receiver will not be able to authenticate any packet related to the new chain or any of the following ones. The only solution for this receiver to catch up consists in receiving an additional bootstrap information message. This can happen by waiting for the next periodic transmission (if sent in-band) or through an external mechanism (Section 3.2.1).
いくつかのケースでは、非常に長い切断を経験した受信機は、新しいチェーンのコミットメントを失っているかもしれません。したがって、この受信機は、新たな鎖または以下のもののいずれかに関連するすべてのパケットを認証することはできません。追いつくために、この受信機のための唯一の解決策は、追加のブートストラップ情報メッセージを受信することにあります。これは、または外部機構（3.2.1）を介して（バンドで送信された場合）、次の定期送信を待つことによって起こることができます。
When several key chains and the in-band commitment mechanism are used, a sender MUST initialize the n_tx_lastkey and n_tx_newkcc parameters in such a way that no overlapping occurs. In other words, once a sender starts transmitting commitments for a new key chain, he MUST NOT send a disclosure for the last key of the old key chain any more. Therefore, the following property MUST be verified:
いくつかのキーチェーンとインバンドコミットメントメカニズムが使用される場合、送信者は重複が発生しないようにn_tx_lastkeyとn_tx_newkccパラメータを初期化する必要があります。送信者が新しいキーチェーンのための約束を送信を開始したら、他の言葉では、彼はもはや古いキーチェーンの最後のキーの開示を送ってはいけません。したがって、次のプロパティを確認する必要があります：
d + n_tx_lastkey + n_tx_newkcc <= N + 1
D + n_tx_lastkey + n_tx_newkcc <= N + 1
It is RECOMMENDED, for robustness purposes, that, once n_tx_lastkey has been chosen, then:
その後、n_tx_lastkeyが選択されたら、こと、堅牢性のために、お勧めします。
n_tx_newkcc = N + 1 - n_tx_lastkey - d
n_tx_newkcc = N + 1 - n_tx_lastkey - D
In other words, the sender starts transmitting a commitment to the following key chain immediately after having sent all the disclosures of the last key of the previous key chain. Doing so increases the probability that a receiver gets a commitment for the following key chain.
言い換えれば、送信者は、直前のキーチェーンの最後のキーのすべての開示を送信した後に次のキーチェーンへのコミットメントの送信を開始します。そうすることで、受信機が次のキーチェーンのためのコミットメントを取得する確率が高くなります。
In any case, these two parameters are sender specific and need not be transmitted to the receivers. Of course, as explained above, the sender alternates between the disclosure of a key of the current key chain and the commitment to the new key chain (or the last key of the old key chain).
いずれにせよ、これら2つのパラメータは、送信者固有のものであり、受信機に送信する必要はありません。もちろん、前述したように、現在のキーチェーンのキーの開示、新しいキーチェーンへのコミットメント（または古いキーチェーンの最後のキー）との間に、送信者を交互に。
Since a key cannot be disclosed before the disclosure delay, d, no key will be disclosed during the first d time intervals (intervals 0 and 1 in Figure 1) of the session. To that purpose, the sender uses the Authentication Tag without Key Disclosure, Section 3.4.4. The following key chains, if any, are not concerned since they will disclose the last d keys of the previous chain.
キーが開示遅延、Dの前に開示されていることができないので、何のキーは、セッションの最初のDの時間間隔（図1における間隔0と1）中に開示されていないであろう。その目的のために、送信者がキーDisclosure、セクション3.4.4ずに認証タグを使用しています。次のキーチェーンは、もしあれば、彼らは以前のチェーンの最後のDキーを開示しますので、心配はありません。
An ALC or NORM sender may stop transmitting packets for some time. For instance, it can be the end of the session and all packets have already been sent, or the use case may consist in a succession of busy periods (when fresh objects are available) followed by silent periods. In any case, this is an issue since the authentication of the packets sent during the last d intervals requires that the associated keys be disclosed, which will take place during d additional time intervals.
ALCまたはNORM送信者がいくつかの時間のためのパケットの送信を停止することがあります。例えば、それはセッションの終わりにすることができ、すべてのパケットが既に送信された、またはユースケースは、サイレント期間が続く（新鮮なオブジェクトが利用可能である）ビジー期間連続して構成されてもよいです。最後のD期間中に送信されるパケットの認証をd追加の時間間隔中に行われる、関連するキーが開示されている必要がありますので、いずれにせよ、これは問題です。
To solve this problem, it is recommended that the sender transmit empty packets (i.e., without payload) containing the TESLA EXT_AUTH Header Extension along with a Standard Authentication Tag during at least d time intervals after the end of the regular ALC or NORM packet transmissions. The number of such packets and the duration during which they are sent must be sufficient for all receivers to receive, with a high probability, at least one packet disclosing the last useful key (i.e., the key used for the last non-empty packet sent).
この問題を解決するために、定期的なALC又はNORMパケット送信の終了後、少なくともDの時間間隔の間、標準認証タグと共にTESLA EXT_AUTHヘッダ拡張を含む送信者が（ペイロードなしすなわち、）空のパケットを送信することをお勧めします。すべての受信機が受信するためにそのようなパケットの数と、それらが送信される間の期間は、高い確率で、最後に有用な鍵（すなわち、送信された最後の非空パケットに使用される鍵を開示する少なくとも1つのパケットで、十分でなければなりません）。
The sender must determine the following parameters:
送信者は、次のパラメータを決定する必要があります。
o T_0, the start time corresponding to the beginning of the session, i.e., the beginning of time interval 0 (in NTP timestamp format);
O T_0、セッションの開始に対応する開始時間、即ち、（NTPタイムスタンプ形式）時間間隔0の先頭。
o T_int, the interval duration (in milliseconds), usually ranging from 100 milliseconds to 1 second;
O T_INT、（ミリ秒）間隔の持続時間は、通常、100ミリ秒から1秒の範囲、
o d, the key disclosure delay (in number of intervals). It is the time to wait before disclosing a key;
O D、（間隔の数）キー開示遅延。キーを公開する前に待機する時間です。
o N, the length of a key chain.
O N、キーチェーンの長さ。
The correct choice of T_int, d, and N is crucial for the efficiency of the scheme. For instance, a T_int * d product that is too long will cause excessive delay in the authentication process. A T_int * d product that is too short prevents many receivers from verifying packets. An N * T_int product that is too small will cause the sender to switch too often to new key chains. An N that is too long with respect to the expected session duration (if known) will require the sender to compute too many useless keys. Sections 3.2 and 3.6 of [RFC4082] give general guidelines for initializing these parameters.
T_INT、D、及びNの正しい選択は、スキームの効率のために重要です。例えば、長すぎるT_INT * d個の製品が認証プロセスにおける過度の遅延が発生します。短すぎるT_INT * d個の製品がパケットを検証することから、多くの受信機を防ぎます。小さすぎるN * T_INT製品は、送信者が新しいキーチェーンにあまりにも頻繁に切り替わることがあります。 （既知の場合）期待されるセッション継続時間に関しては長すぎるNは、あまりにも多くの役に立たないキーを計算するために、送信者が必要になります。セクション3.2と[RFC4082]の3.6は、これらのパラメータを初期化するための一般的なガイドラインを与えます。
The T_0, T_int, d, and N parameters MUST NOT be changed during the lifetime of the session. This restriction is meant to prevent introducing vulnerabilities. For instance, if a sender was authorized to change the key disclosure schedule, a receiver that did not receive the change notification would still believe in the old key disclosure schedule, thereby creating vulnerabilities [RFC4082].
T_0、T_INT、D、およびNパラメータは、セッションの存続期間中に変更してはいけません。この制限は、脆弱性を導入防ぐためのものです。送信者がキー公開スケジュールを変更することを許可された場合例えば、変更通知を受信しなかった受信機はまだ、それによって脆弱性[RFC4082]を作成し、古いキー開示スケジュールを信じているでしょう。
In indirect time synchronization mode, the sender must determine the following parameter:
間接的な時刻同期モードでは、送信者は、次のパラメータを決定する必要があります。
o D^O_t, the upper bound of the lag of the sender's clock with respect to the time reference.
O D ^ O_t、時間基準に対する送信者のクロックの遅れの上限。
The D^O_t parameter MUST NOT be changed during the lifetime of the session.
D ^ O_tパラメータは、セッションの存続期間中に変更してはいけません。
At a sender, TESLA produces two types of signaling information:
送信側では、TESLAは、シグナリング情報の2種類を生成します。
o The bootstrap information: it can be either sent out-of-band or in-band. In the latter case, a digitally signed packet contains all the information required to bootstrap TESLA at a receiver;
ブートストラップ情報（O）それがいずれかの帯域外または帯域内で送信することができます。後者の場合には、デジタル署名されたパケットは、受信機でTESLAをブートストラップするために必要なすべての情報が含まれています。
o The direct time synchronization response, which enables a receiver to finish a direct time synchronization.
直接時間同期を完了するために受信機を可能に直接時刻同期応答、O。
In order to initialize the TESLA component at a receiver, the sender must communicate some key information in a secure way. This information can be sent in-band or out-of-band, as discussed in Section 2.2. In this section, we only consider the in-band scheme.
受信機でTESLAコンポーネントを初期化するために、送信者は、安全な方法でいくつかの重要な情報を通信しなければなりません。セクション2.2で議論するように、この情報は、帯域内または帯域外送信することができます。このセクションでは、我々は唯一のインバンドスキームを検討してください。
The TESLA bootstrap information message MUST be digitally signed (Section 3.3.2). The goal is to enable a receiver to check the packet source and packet integrity. Then, the bootstrap information can be:
TESLAブートストラップ情報メッセージは、デジタル（3.3.2）に署名しなければなりません。目標は、パケットの送信元とパケットの整合性をチェックするために受信機を有効にすることです。次に、ブートストラップ情報を指定できます。
o unicast to a receiver during a direct time synchronization request/response exchange;
O直接時刻同期要求/応答交換の間、受信機にユニキャスト。
o broadcast to all receivers. This is typically the case in indirect time synchronization mode. It can also be used in direct time synchronization mode, for instance, when a large number of clients arrive at the same time, in which case it is more efficient to answer globally.
Oすべての受信機にブロードキャスト。これは通常、間接的な時刻同期モードの場合です。多数のクライアントは、世界的に答えるために、より効率的である場合には同じ時刻、到着時には、例えば、直接時刻同期モードでも使用することができます。
Let us consider situations where the bootstrap information is broadcast. This message should be broadcast at the beginning of the session, before data packets are actually sent. This is particularly important with ALC or NORM sessions in "push" mode, when all clients join the session in advance. For improved reliability, bootstrap information might be sent a certain number of times.
私たちは、ブートストラップ情報が放送されている状況を考えてみましょう。データパケットが実際に送信される前に、このメッセージは、セッションの開始時に放送される必要があります。すべてのクライアントが事前にセッションに参加するとき、これは、「プッシュ」モードでALCまたはNORMのセッションでは特に重要です。信頼性向上のために、ブートストラップ情報は、特定の回数送信されるかもしれません。
A periodic broadcast of the bootstrap information message could also be useful when:
ブートストラップ情報メッセージの定期的な放送も時に役に立つかもしれません。
o the ALC session uses an "on-demand" mode, clients arriving at their own discretion;
O ALCセッションは、クライアントが自らの裁量で到着し、「オンデマンド」モードを使用しています。
o some clients experience an intermittent connectivity. This is particularly important when several key chains are used in an ALC or NORM session, since there is a risk that a receiver loses all the commitments to the new key chain.
O一部のクライアントは、断続的な接続を体験します。受信機は新しいキーチェーンにすべての約束を失うというリスクがあるので、いくつかのキーチェーンは、ALCまたはNORMセッションで使用されている場合、これは特に重要です。
A balance must be found between the signaling overhead and the maximum initial waiting time at the receiver before starting the delayed authentication process. A period of a few seconds for the transmission of this bootstrap information is often a reasonable value.
バランスは、遅延認証プロセスを開始する前に、受信機でのシグナリングオーバーヘッド及び最大初期待機時間の間に見出されなければなりません。このブートストラップ情報の伝送のため、数秒の期間は、多くの場合、妥当な値です。
In direct time synchronization, upon receipt of a synchronization request, the sender records its local time, t_s, and sends a response message that contains both t_r and t_s (Section 2.4.1). This message is unicast to the receiver. This direct time synchronization response message MUST be digitally signed in order to enable a receiver to check the packet source and packet integrity (Section 3.3.2). The receiver MUST also be able to associate this response and his request, which is the reason why t_r is included in the response message.
直接時間同期は、同期要求を受信すると、送信者は、そのローカル時間を記録T_S、及びT_RとT_S（2.4.1）の両方を含む応答メッセージを送信します。このメッセージは、受信側にユニキャストです。この直接時刻同期応答メッセージは、デジタルパケットの送信元とパケットの整合性（3.3.2）を確認するために受信機を有効にするために署名しなければなりません。また、受信機は、この応答とT_Rは、応答メッセージに含まれている理由でもある彼の要求を、関連付けることができなければなりません。
At a sender, TESLA produces three types of security tags:
送信側では、TESLAはセキュリティタグの三種類を生成します。
o an authentication tag, in case of data packets, and which contains the MAC of the packet;
OパケットのMACを含むデータパケットの場合には認証タグ、および。
o a digital signature, in case of one of the two TESLA signaling packets, namely a bootstrap information message or a direct time synchronization response; and
Oデジタル署名二TESLAシグナリングパケット、すなわち、ブートストラップ情報メッセージまたは直接時刻同期応答のうちの一方の場合に、そして
o an optional group authentication tag, that can be added to all the packets to mitigate attacks coming from outside of the group.
グループの外部からの攻撃を緩和するために、すべてのパケットに付加することができるオプションのグループ認証タグ、O。
Because of interdependencies, their computation MUST follow a strict order:
相互依存性により、その計算は厳密な順序に従う必要があります。
o first of all, compute the authentication tag (with data packet) or the digital signature (with signaling packet);
Oまず、（シグナリングパケットを有する）（データパケットに）認証タグまたはデジタル署名を計算します。
o finally, compute the Group Mac.
O最後に、グループのMacを計算します。
All the data packets sent MUST have an authentication tag containing:
送信されたすべてのデータパケットが含む認証タグを持っている必要があります。
o the interval index, i, which is also the index of the key used for computing the MAC of this packet;
また、このパケットのMACを計算するために使用されるキーのインデックスである区間インデックス、I、O。
o the MAC of the message: MAC(K'_i, M), where K'_i=F'(K_i);
メッセージのMAC O：MAC（K'_i、M）、K'_i = F '（K_I）。
o either a disclosed key (which belongs to the current key chain or the previous key chain), or a commitment to a new key chain, or no key at all.
O（現在のキーチェーンまたは以前のキーチェーンに属している）に開示されたキー、または新しいキーチェーンへのコミットメント、又は全くキーのいずれか。
The computation of MAC(K'_i, M) MUST include the ALC or NORM header (with the various header extensions) and the payload (when applicable). The UDP/IP headers MUST NOT be included. During this computation, the "MAC(K'_i, M)" field of the authentication tag MUST be set to 0.
MAC（K'_i、M）の計算は、（様々なヘッダ拡張子を持つ）ALC又はNORMヘッダとペイロード（適用）を含まなければなりません。 UDP / IPヘッダを含んではいけません。この計算の際に、認証タグの「MAC（K'_i、M）」フィールドは0に設定しなければなりません。
The bootstrap information message (with the in-band bootstrap scheme) and direct time synchronization response message (with the indirect time synchronization scheme) both need to be signed by the sender. These two messages contain a "Signature" field to hold the digital signature. The bootstrap information message also contains the "Signature Encoding Algorithm", the "Signature Cryptographic Function", and the "Signature Length" fields that enable a receiver to process the "Signature" field. Note that there are no such "Signature Encoding Algorithm", "Signature Cryptographic Function", and "Signature Length" fields in the case of a direct time synchronization response message since it is assumed that these parameters are already known (i.e., the receiver either received a bootstrap information message before or these values have been communicated out-of-band).
（帯域内のブートストラップ方式に）ブートストラップ情報メッセージと（間接時間同期方式で）直接時刻同期応答メッセージの両方が送信者によって署名される必要があります。これらの2件のメッセージがデジタル署名を保持するために「署名」フィールドが含まれています。ブートストラップ情報メッセージは、「署名符号化アルゴリズム」、「署名暗号化機能」、および「署名」フィールドを処理するために受信機を有効に「署名長」フィールドを含んでいます。 （すなわち、受信機のいずれかで、これらのパラメータが既知であると仮定されるので、そのような「オリジナル符号化アルゴリズム」、「署名暗号化機能」、および直接時刻同期応答メッセージの場合には「署名の長さ」フィールドが存在しないことに注意してください前にブートストラップ情報メッセージを受信し、またはこれらの値は、アウト・オブ・バンド）通信されてきました。
Several "Signature Encoding Algorithms" can be used, including RSASSA-PKCS1-v1_5, the default, and RSASSA-PSS (Section 7). With these encodings, SHA-256 is the default "Signature Cryptographic Function".
いくつかの "署名エンコーディングアルゴリズム" はRSASSA-PKCS1-v1_5の、デフォルト、およびRSASSA-PSS（セクション7）を含め、使用することができます。これらのエンコーディングでは、SHA-256はデフォルトで「署名の暗号化機能」です。
The computation of the signature MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP headers MUST NOT be included. During this computation, the "Signature" field MUST be set to 0 as well as the optional Group MAC, when present, since this Group MAC is calculated later.
署名の計算は、（様々なヘッダ拡張子を持つ）ALC又はNORMヘッダとペイロード適用を含まなければなりません。 UDP / IPヘッダを含んではいけません。存在する場合、このグループMACは後に計算されるので、この計算中に、「署名」フィールドは、0に設定するだけでなく、オプションのグループMACなければなりません。
More specifically, from [RFC4359]: Digital signature generation is performed as described in [RFC3447], Section 8.2.1 for RSASSA-PKCS1- v1_5 and Section 8.1.1 for RSASSA-PSS. The authenticated portion of the packet is used as the message M, which is passed to the signature generation function. The signer's RSA private key is passed as K. In summary, (when SHA-256 is used), the signature generation process computes a SHA-256 hash of the authenticated packet bytes, signs the SHA-256 hash using the private key, and encodes the result with the specified RSA encoding type. This process results in a value S, which is the digital signature to be included in the packet.
より具体的には、から[RFC4359]：RSASSA-PSSのためのRSASSA-PKCS1- v1_5の、セクション8.1.1のために[RFC3447]、セクション8.2.1に記載したように、デジタル署名の生成が行われます。パケットの認証された部分は、署名生成関数に渡されたメッセージMとして使用されます。署名者のRSA秘密鍵を要約K.として渡され、（SHA-256を使用する場合）、署名生成プロセスは、認証されたパケットのバイトのSHA-256ハッシュを計算し、秘密鍵を使用して、SHA-256ハッシュに署名し、そして指定されたRSA符号化タイプを用いて結果を符号化します。このプロセスは、値Sをもたらし、パケットに含まれるデジタル署名です。
With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the signature is equal to the "RSA modulus", unless the "RSA modulus" is not a multiple of 8 bits. In that case, the signature MUST be prepended with between 1 and 7 bits set to zero such that the signature is a multiple of 8 bits [RFC4359]. The key size, which in practice is also equal to the "RSA modulus", has major security implications. [RFC4359] explains how to choose this value depending on the maximum expected lifetime of the session. This choice is out of the scope of this document.
「RSAモジュラス」は8ビットの倍数でない場合を除きRSASSA-PKCS1-v1_5のとRSASSA-PSS署名と、署名のサイズは、「RSAモジュラス」に等しいです。その場合には、署名は、署名が8ビット[RFC4359]の倍数であるようにゼロに設定1〜7ビットで付加されなければなりません。実際にも、「RSAモジュラス」に等しいキーサイズは、主要なセキュリティ上の意味を持っています。 [RFC4359]はセッションの最大耐用年数に応じて、この値を選択する方法について説明します。この選択は、このドキュメントの範囲外です。
An optional Group MAC can be used to mitigate Denial-of-Service (DoS) attacks coming from attackers that are not group members [RFC4082]. This feature assumes that a group key, K_g, is shared by the sender and all receivers. When the attacker is not a group member, the benefits of adding a Group MAC to every packet sent are threefold:
オプションのグループMACは、グループメンバー[RFC4082]でない攻撃者からサービス拒否（DoS）攻撃を軽減するために使用することができます。この機能は、グループキー、K_Gは、送信者とすべての受信機によって共有されていることを前提としています。攻撃者はグループのメンバーでない場合は、送信されたすべてのパケットにグループMACを追加することの利点は3つある：
o a receiver can immediately drop faked packets, without having to wait for the disclosure delay, d;
O受信機は、直ちに開示遅延、Dを待つことなく、偽造パケットをドロップすることができます。
o a sender can immediately drop faked direct time synchronization requests, and avoid checking the digital signature, a computation intensive task;
O送信者は、すぐに偽造直接時刻同期要求をドロップし、デジタル署名、計算集約的なタスクのチェックを回避することができます。
o a receiver can immediately drop faked direct time synchronization response and bootstrap messages, without having to verify the digital signature, a computation-intensive task.
O受信機は直ちにデジタル署名、計算集中型タスクを確認することなく、偽造直接時刻同期応答とブートストラップメッセージをドロップすることができます。
The computation of the Group MAC, MAC(K_g, M), MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP headers MUST NOT be included. During this computation, the "Group MAC" field MUST be set to 0. However, the digital signature (e.g., of a bootstrap message) and the "MAC" fields (e.g., of an authentication tag), when present, MUST have been calculated since they are included in the Group MAC calculation itself. Then, the sender truncates the MAC output to keep the n_w most significant bits and stores the result in the "Group MAC" field.
グループMAC、MAC（K_G、M）の計算は、（様々なヘッダ拡張子を持つ）ALC又はNORMヘッダとペイロード適用を含まなければなりません。 UDP / IPヘッダを含んではいけません。この計算の際に、「グループMAC」フィールドは、しかしながら、0に（ブートストラップメッセージの例えば、）デジタル署名を設定しなければならなくて、「MAC」フィールド（例えば、認証タグの）、存在する場合、されていなければなりません彼らはグループMAC計算自体に含まれているので、計算。次に、送信者はn_w最上位ビットを維持するためにMAC出力を切り捨て、「グループMAC」フィールドに結果を格納します。
This scheme features a few limits:
このスキームは、いくつかの制限が特徴。
o it is of no help if a group member (who knows K_g) impersonates the sender and sends forged messages to other receivers;
Oそれは、グループのメンバーが（誰がK_Gを知っている）、送信者を偽装し、他の受信機への偽造メッセージを送信した場合役に立たないのです。
o it requires an additional MAC computing for each packet, both at the sender and receiver sides;
Oそれは両方の送信者と受信者側では、各パケットのための追加のMAC演算を必要とします。
o it increases the size of the TESLA authentication headers. In order to limit this problem, the length of the truncated output of the MAC, n_w, SHOULD be kept small (e.g., 32 bits) (see [RFC3711], Section 9.5). As a side effect, the authentication service is significantly weakened: the probability of any forged packet being successfully authenticated becomes one in 2^32. Since the Group MAC check is only a pre-check that must be followed by the standard TESLA authentication check, this is not considered to be an issue.
OはTESLA認証ヘッダのサイズを増大させます。この問題を制限するために、MACの切断出力の長さは、n_w、小さい（例えば、32ビット）が維持されるべきである（[RFC3711]セクション9.5を参照）。副作用として、認証サービスは著しく弱められる：正常に認証されている任意の偽造パケットの確率は2 ^ 32に1となります。グループMACチェックが標準TESLAの認証チェックが続かなければならない唯一の事前チェックであるので、これは問題ではないと考えられます。
For a given use case, the benefits brought by the Group MAC must be balanced against these limitations.
特定のユースケースでは、グループMACによってもたらされる利点は、これらの制限に対してバランスをとらなければなりません。
Note that the Group MAC function can be different from the TESLA MAC function (e.g., it can use a weaker but faster MAC function). Note also that the mechanism by which the group key, K_g, is communicated to all group members, and perhaps periodically updated, is out of the scope of this document.
グループMAC関数はTESLA MAC関数（例えば、それは弱いが、高速MAC関数を使用することができる）とは異なることができることに留意されたいです。グループキー、K_Gは、すべてのグループメンバーに伝え、おそらく定期的に更新される機構は、この文書の範囲外であることにも留意されたいです。
This section specifies the format of the various kinds of TESLA messages and authentication tags sent by the session's sender. Because these TESLA messages are carried as EXT_AUTH Header Extensions of the ALC or NORM packets (Section 5), the following formats do not start on 32-bit word boundaries.
このセクションでは、セッションの送信者によって送信されたTESLAメッセージおよび認証タグの様々な種類のフォーマットを指定します。これらTESLAメッセージがALCのEXT_AUTHヘッダーExtensionsまたはNORMパケット（第5節）として実施されているので、以下の形式は、32ビットのワード境界で開始されません。
When bootstrap information is sent in-band, the following message is used:
ブートストラップ情報は、帯域内送信されると、次のメッセージが使用されます。
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
+-+-+-+-+-+-+-+-+ ---
| V |resvd|S|G|A| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| d | PRF Type | MAC Func Type |Gr MAC Fun Type| | f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | i
| SigEncAlgo | SigCryptoFunc | Signature Length | | x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e
| Reserved | T_int | | d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | l
+ T_0 (NTP timestamp format) + | e
| | | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g
| N (Key Chain Length) | | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h
| Current Interval Index i | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| |
~ Current Key Chain Commitment +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
~ Signature ~
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| |
+-+ D^O_t Extension (optional, present if A==1) +
| (NTP timestamp diff, positive if P==1, negative if P==0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Bootstrap Information Format
図2：情報フォーマットブートストラップ
The format of the bootstrap information is depicted in Figure 2. The fields are:
ブートストラップ情報のフォーマットは、図2に示されているフィールドです。
"V" (Version) field (2 bits):
"V"（バージョン）フィールド（2ビット）：
The "V" field contains the version number of the protocol. For this specification, the value of 0 MUST be used.
「V」フィールドには、プロトコルのバージョン番号が含まれています。本明細書のために、0の値を使用しなければなりません。
"Reserved" field (3 bits):
"予約" フィールド（3ビット）：
This is a reserved field that MUST be set to zero in this specification.
これは、この仕様書にゼロに設定しなければならない予約フィールドです。
"S" (Single Key Chain) flag (1 bit):
"S"（シングルキーチェーン）フラグ（1ビット）：
The "S" flag indicates whether this TESLA session is restricted to a single key chain (S==1) or relies on one or multiple key chains (S==0).
「S」フラグは、このTESLAセッションが単一のキーチェーン（S == 1）に制限され、または1つのまたは複数のキーチェーン（S == 0）に依存しているかどうかを示します。
"G" (Group MAC Present) flag (1 bit):
"G"（グループMAC本）フラグ（1ビット）：
The "G" flag indicates whether the Group MAC feature is used (G==1) or not (G==0). When it is used, a "Group MAC" field is added to all the packets containing a TESLA EXT_AUTH Header Extension (including this bootstrap message).
"G" フラグは、グループMAC機能を使用するかどうかを示す（G == 1）か否（G == 0）。それが使用される場合、「グループMAC」フィールド（このブートストラップメッセージを含む）TESLA EXT_AUTHヘッダ拡張を含むすべてのパケットに付加されます。
"A" flag (1 bit):
"A" フラグ（1ビット）：
The "A" flag indicates whether the "P" flag and "D^O_t" fields are present (A==1) or not (A==0). In indirect time synchronization mode, A MUST be equal to 1 since these fields are needed.
「」フラグは「P」フラグおよび「D ^ O_t」フィールドは（== 1）であるか否か（== 0）が存在するかどうかを示します。これらのフィールドが必要とされているので、間接的な時刻同期モードでは、Aは、1に等しくなければなりません。
"d" field (8 bits):
"D" フィールド（8ビット）：
"d" is an unsigned integer that defines the key disclosure delay (in number of intervals). d MUST be greater than or equal to 2.
「D」は（間隔の数で）鍵開示遅延を定義する符号なし整数です。 dが2以上でなければなりません。
"PRF Type" field (8 bits):
"PRFタイプ" フィールド（8ビット）：
The "PRF Type" is the reference number of the f function used to derive the F (for key chain) and F' (for MAC keys) functions (Section 7).
「PRFタイプ」（MACキーの（）キーチェーン用）FとF」の機能（セクション7）を導出するために使用するF関数の参照番号です。
"MAC Function Type" field (8 bits):
"MAC関数型" フィールド（8ビット）：
The "MAC Function Type" is the reference number of the function used to compute the MAC of the packets (Section 7).
「MAC関数型」とは、パケットのMAC（セクション7）を計算するために使用される関数の参照番号です。
"Group MAC Function Type" field (8 bits):
「グループMAC機能タイプ」フィールド（8ビット）：
When G==1, this field contains the reference number of the cryptographic MAC function used to compute the Group MAC (Section 7). When G==0, this field MUST be set to zero.
G == 1は、このフィールドは、グループMAC（セクション7）を計算するために使用される暗号MAC機能の参照番号が含まれている場合。 G == 0は、このフィールドをゼロに設定する必要がある場合。
"Signature Encoding Algorithm" field (8 bits):
「署名エンコーディングアルゴリズム」フィールド（8ビット）：
The "Signature Encoding Algorithm" is the reference number (Section 7) of the digital signature used to authenticate this bootstrap information and included in the "Signature" field.
「署名符号化アルゴリズム」は、「署名」欄にこのブートストラップ情報を認証するために使用され、含まれるデジタル署名の参照番号（セクション7）です。
"Signature Cryptographic Function" field (8 bits):
「署名暗号化機能」フィールド（8ビット）：
The "Signature Cryptographic Function" is the reference number (Section 7) of the cryptographic function used within the digital signature.
「署名暗号化機能は、」デジタル署名内に使用される暗号化関数の参照番号（セクション7）です。
"Signature Length" field (16 bits):
「署名長」フィールド（16ビット）：
The "Signature Length" is an unsigned integer that indicates the "Signature" field size in bytes in the "Signature Extension" field. This is also the signature key length, since both parameters are equal.
「署名長」「署名拡張」フィールドのバイトに「署名」フィールドのサイズを示す符号なし整数です。両方のパラメータが等しいので、これは、また、署名鍵の長さです。
"Reserved" fields (16 bits):
"予約" フィールド（16ビット）：
This is a reserved field that MUST be set to zero in this specification.
これは、この仕様書にゼロに設定しなければならない予約フィールドです。
"T_int" field (16 bits):
"T_INT" フィールド（16ビット）：
"T_int" is an unsigned 16-bit integer that defines the interval duration (in milliseconds).
「T_INT」は（ミリ秒）間隔の持続時間を定義する符号なし16ビット整数です。
"T_0" field (64 bits):
"T_0" フィールド（64ビット）：
"T_0" is a timestamp in NTP timestamp format that indicates the beginning of the session, i.e., the beginning of time interval 0.
「T_0は」時間間隔0の始まり、即ち、セッションの始まりを示しNTPタイムスタンプ形式のタイムスタンプです。
"N" field (32 bits):
"N" フィールド（32ビット）：
"N" is an unsigned integer that indicates the key chain length. There are N + 1 keys per chain.
「N」は、キーチェーンの長さを示す符号なし整数です。鎖当たりN + 1のキーがあります。
"i" (Interval Index of K_i) field (32 bits):
"I"（K_I間隔インデックス）フィールド（32ビット）：
"i" is an unsigned integer that indicates the current interval index when this bootstrap information message is sent.
「i」は、このブートストラップ情報メッセージが送信された現在の間隔のインデックスを示す符号なし整数です。
"Current Key Chain Commitment" field (variable size, padded if necessary for 32-bit word alignment):
（必要であれば、32ビット・ワードのアライメントにパディング可変サイズ）「現在のキーチェーンコミットメント」フィールド：
"Key Chain Commitment" is the commitment to the current key chain, i.e., the key chain corresponding to interval i. For instance, with the first key chain, this commitment is equal to F(K_0), with the second key chain, this commitment is equal to F(K_{N+1}), etc.). If need be, this field is padded (with 0) up to a multiple of 32 bits.
「キーチェーンのコミットメントは、」現在のキーチェーン、すなわち、私の間隔に対応するキーチェーンへのコミットメントです。例えば、最初のキーチェーンと、このコミットメントは、第2のキーチェーンと、このコミットメントは、F（K_ {N + 1}）、等）に等しく、F（K_0）に等しいです。必要であれば、このフィールドは、32ビットの倍数まで（0と）埋め込まれています。
"Signature" field (variable size, padded if necessary for 32-bit word alignment):
「署名」フィールド（32ビット・ワードの位置合わせのための必要に応じてパディング可変サイズ）：
The "Signature" field is mandatory. It contains a digital signature of this message, as specified by the encoding algorithm, cryptographic function, and key length parameters. If the signature length is not a multiple of 32 bits, this field is padded with 0.
「署名」フィールドは必須です。符号化アルゴリズム、暗号化関数、およびキー長パラメータによって指定されるように、それは、このメッセージのデジタル署名を含みます。署名長が32ビットの倍数でない場合、このフィールドは0で埋められます。
"P" flag (optional, 1 bit if present):
"P" フラグ（1ビット存在する場合、オプション）：
The "P" flag is optional and only present if the "A" flag is equal to 1. It is only used in indirect time synchronization mode. This flag indicates whether the D^O_t NTP timestamp difference is positive (P==1) or negative (P==0).
「A」フラグは、それが唯一の間接的な時間同期モードで使用されている1に等しい場合、「P」フラグはオプションでのみ存在します。このフラグは、D ^ O_t NTPタイムスタンプの差が正（P == 1）または負（P == 0）であるかどうかを示します。
"D^O_t" field (optional, 63 bits if present):
"D ^ O_t" フィールド（オプション、63ビット存在する場合）。
The "D^O_t" field is optional and only present if the "A" flag is equal to 1. It is only used in indirect time synchronization mode. It is the upper bound of the lag of the sender's clock with respect to the time reference. When several time references are specified (e.g., several NTP servers), then D^O_t is the maximum upper bound of the lag with each time reference. D^O_t is composed of two unsigned integers, as with NTP timestamps: the first 31 bits give the time difference in seconds and the remaining 32 bits give the sub-second time difference.
「A」フラグは、それが唯一の間接的な時間同期モードで使用されている1に等しい場合、「D ^ O_t」フィールドはオプションでのみ存在します。それは時間の基準に対する送信者のクロックの遅れの上限です。いくつかの時間基準は、（例えば、いくつかのNTPサーバ）が指定された場合、次にD ^ O_t各時間基準とラグの最大上限です。 D ^ O_tは、NTPタイムスタンプを持つように、2つの符号なし整数で構成されている：最初の31ビットは、秒単位の時間差を与え、残りの32ビットは、サブ秒の時間差を与えます。
"Group MAC" field (optional, variable length, multiple of 32 bits):
「グループMAC」フィールド（オプション、可変長、32ビットの倍数）。
This field contains the Group MAC, calculated with the group key, K_g, shared by all group members. The field length, in bits, is given by n_w, which is known once the Group MAC function type is known (Section 7).
このフィールドは、すべてのグループメンバーが共有するグループキー、K_G、で計算グループMACが含まれています。フィールド長は、ビット単位で、グループMAC機能タイプは（セクション7）が知られると知られているn_w、によって与えられます。
Note that the first byte and the following seven 32-bit words are mandatory fixed-length fields. The "Current Key Chain Commitment" and "Signature" fields are mandatory but variable-length fields. The remaining "D^O_t" and "Group MAC" fields are optional.
最初のバイトと次の7つの32ビットワードは必須固定長フィールドであることに留意されたいです。 「現在のキーチェーンコミットメント」と「署名」フィールドは必須しかし、可変長フィールドです。残りの「D ^ O_t」と「グループMAC」フィールドはオプションです。
In order to prevent attacks, some parameters MUST NOT be changed during the lifetime of the session (Sections 3.1.3 and 3.1.4). The following table summarizes the parameter's status:
攻撃を防ぐために、いくつかのパラメータは、セッション（セクション3.1.3および3.1.4）の存続期間中に変更してはいけません。次の表は、パラメータのステータスをまとめたものです。
+--------------------------+----------------------------------------+
| Parameter | Status |
+--------------------------+----------------------------------------+
| V | set to 0 in this specification |
| S | static (during whole session) |
| G | static (during whole session) |
| A | static (during whole session) |
| T_O | static (during whole session) |
| T_int | static (during whole session) |
| d | static (during whole session) |
| N | static (during whole session) |
| D^O_t (if present) | static (during whole session) |
| PRF Type | static (during whole session) |
| MAC Function Type | static (during whole session) |
| Signature Encoding | static (during whole session) |
| Algorithm | |
| Signature Crypto. | static (during whole session) |
| Function | |
| Signature Length | static (during whole session) |
| Group MAC Func. Type | static (during whole session) |
| i | dynamic (related to current key chain) |
| K_i | dynamic (related to current key chain) |
| signature | dynamic, packet dependent |
| Group MAC (if present) | dynamic, packet dependent |
+--------------------------+----------------------------------------+
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_s (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_r (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
~ Signature ~
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of a Direct Time Synchronization Response
図3：直接時刻同期応答のフォーマット
The response to a direct time synchronization request contains the following information:
直接時刻同期要求に対する応答は、次の情報が含まれています。
"Reserved" field (8 bits):
"予約" フィールド（8ビット）：
This is a reserved field that MUST be set to zero in this specification.
これは、この仕様書にゼロに設定しなければならない予約フィールドです。
"t_s" (NTP timestamp, 64 bits):
"T_S"（NTPタイムスタンプ、64ビット）：
"t_s" is a timestamp in NTP timestamp format that corresponds to the sender local time value when receiving the direct time synchronization request message.
「T_Sは」直接時刻同期要求メッセージを受信した場合、送信者のローカル時間値に対応するNTPタイムスタンプ形式のタイムスタンプです。
"t_r" (NTP timestamp, 64 bits):
"T_R"（NTPタイムスタンプ、64ビット）：
"t_r" is a timestamp in NTP timestamp format that contains the receiver local time value received in the direct time synchronization request message.
「T_Rは」直接時刻同期要求メッセージで受信した受信機のローカル時間値が含まれているNTPタイムスタンプ形式のタイムスタンプです。
"Signature" field (variable size, padded if necessary for 32-bit word alignment):
「署名」フィールド（32ビット・ワードの位置合わせのための必要に応じてパディング可変サイズ）：
The "Signature" field is mandatory. It contains a digital signature of this message, as specified by the encoding algorithm, cryptographic function, and key length parameters communicated in the bootstrap information message (if applicable) or out-of-band. If the signature length is not a multiple of 32 bits, this field is padded with 0.
「署名」フィールドは必須です。符号化アルゴリズム、暗号化機能、ブートストラップ情報メッセージ（該当する場合）またはアウトオブバンド通信されるキーの長さパラメータによって指定されるように、それは、このメッセージのデジタル署名を含みます。署名長が32ビットの倍数でない場合、このフィールドは0で埋められます。
"Group MAC" field (optional, variable length, multiple of 32 bits):
「グループMAC」フィールド（オプション、可変長、32ビットの倍数）。
This field contains the Group MAC, calculated with the group key, K_g, shared by all group members. The field length, in bits, is given by n_w, which is known once the Group MAC function type is known (Section 7).
このフィールドは、すべてのグループメンバーが共有するグループキー、K_G、で計算グループMACが含まれています。フィールド長は、ビット単位で、グループMAC機能タイプは（セクション7）が知られると知られているn_w、によって与えられます。
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Disclosed Key K_{i-d} ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of the Standard Authentication Tag
図4：標準の認証タグのフォーマット
A Standard Authentication Tag is composed of the following fields:
標準の認証タグは、次のフィールドで構成されています。
"Reserved" field (8 bits):
"予約" フィールド（8ビット）：
The "Reserved" field is not used in the current specification and MUST be set to zero by the sender.
「予約」フィールドは、現在の仕様では使用されず、送信者によってゼロに設定しなければなりません。
"i" (Interval Index) field (32 bits):
"I"（インターバルインデックス）フィールド（32ビット）：
"i" is the interval index associated with the key (K'_i) used to compute the MAC of this packet.
「i」はキー（K'_i）に関連付けられた区間インデックスがこのパケットのMACを計算するために使用されます。
"Disclosed Key" (variable size, non padded):
「公開鍵」（可変サイズ、非パディング）：
The "Disclosed Key" is the key used for interval i-d: K_{i-d}. There is no padding between the "Disclosed Key" and "MAC(K'_i, M)" fields, and the latter MAY not start on a 32-bit boundary, depending on the n_p parameter.
「公開鍵」は間隔I-Dのために使用されるキーである。K_ {I-D}。 「公開鍵」と「MAC（K'_i、M）」フィールド、およびN_Pパラメータに応じて、32ビット境界で開始されない場合があり、後者の間にパディングはありません。
"MAC(K'_i, M)" (variable size, padded if necessary for 32-bit word alignment):
"MAC（K'_i、M）"（必要に応じて32ビットワードアライメントのために埋め可変サイズ）：
"MAC(K'_i, M)" is the truncated message authentication code of the current packet. Only the n_m most significant bits of the MAC output are kept [RFC2104].
「MAC（K'_i、M）」は、現在のパケットの切断メッセージ認証コードです。 MAC出力だけn_m最上位ビットが[RFC2104]を保持しています。
"Group MAC" field (optional, variable length, multiple of 32 bits):
「グループMAC」フィールド（オプション、可変長、32ビットの倍数）。
This field contains the Group MAC, calculated with a group key, K_g, shared by all group members. The field length is given by n_w, in bits.
このフィールドは、すべてのグループメンバーが共有するグループキー、K_G、で計算グループMACが含まれています。フィールド長はビットで、n_wによって与えられます。
Note that because a key cannot be disclosed before the disclosure delay, d, the sender MUST NOT use this tag during the first d intervals of the session: {0 .. d-1} (inclusive). Instead, the sender MUST use an Authentication Tag without Key Disclosure.
キーが開示遅延の前に開示されていることができないので、dは、送信者は、セッションの最初のD間隔中に、このタグを使用してはならないことに注意してください：{0 .. D-1}（包括的に）。代わりに、送信者はキー開示することなく、認証タグを使用する必要があります。
The Authentication Tag without Key Disclosure is meant to be used in situations where a high number of packets are sent in a given time interval. In such a case, it can be advantageous to disclose the K_{i-d} key only in a subset of the packets sent, using a Standard Authentication Tag, and to use the shortened version that does not disclose the K_{i-d} key in the remaining packets. It is left to the implementer to decide how many packets should disclose the K_{i-d} key. This Authentication Tag without Key Disclosure MUST also be used during the first d intervals: {0 .. d-1} (inclusive).
キー開示せずに認証タグは、大量のパケットが一定の時間間隔で送信された状況で使用されることを意味しています。このような場合には、標準的な認証タグを使用して、唯一の送信されたパケットのサブセットにおけるK_ {ID}鍵を開示することが有利であることができる、とにK_ {ID}鍵を開示していない短縮バージョンを使用します残りのパケット。多くのパケットがK_ {I-D}キーを開示すべき方法を決定するために実装者に任されています。キー開示せず、この認証タグはまた、第1のD間隔中に使用しなければなりません：{0 .. D-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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of the Authentication Tag without Key Disclosure
図5：キー開示せずに認証タグのフォーマット
3.4.5. Format of an Authentication Tag with a "New Key Chain" Commitment
3.4.5. 「新規キーチェーン」コミットメントと認証タグのフォーマット
During the last n_tx_newkcc intervals of the current key chain, the sender SHOULD send commitments to the next key chain. This is done by replacing the disclosed key of the Authentication Tag with a New Key Chain Commitment, F(K_{N+1}) (or F(K_{2N+2}) in case of a switch between the second and third key chains, etc.) Figure 6 shows the corresponding format.
現在のキーチェーンの最後n_tx_newkcc間隔の間に、送信者は、次のキーチェーンに約束を送るべきです。これは、第2および第3のキーとの間のスイッチの場合に新しいキーチェーンコミットメント、F（K_ {N + 1}）と認証タグ（またはF（K_ {2N + 2}）の公開鍵を交換することによって行われますチェーン等）図6は、対応するフォーマットを示しています。
Note that since there is no padding between the "F(K_{N+1})" and "MAC(K'_i, M)" fields, the latter MAY not start on a 32-bit boundary, depending on the n_p parameter.
「F（K_ {N + 1}）」と「MAC（K'_i、M）」フィールド間にパディングが存在しないので、後者はN_Pパラメータに応じて、32ビット境界で開始しないかもしれないことに注意してください。
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ New Key Commitment F(K_{N+1}) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of the Authentication Tag
with a New Key Chain Commitment
3.4.6. Format of an Authentication Tag with a "Last Key of Old Chain" Disclosure
3.4.6. 「最後のキーオールド・チェーンの」開示と認証タグのフォーマット
During the first n_tx_lastkey intervals of the new key chain after the disclosing interval, d, the sender SHOULD disclose the last key of the old key chain. This is done by replacing the disclosed key of the Authentication Tag with the Last Key of the Old Chain, K_N (or K_{2N+1} in case of a switch between the second and third key chains, etc.). Figure 7 shows the corresponding format.
、開示間隔の後、新しいキーチェーン、Dの最初のn_tx_lastkey間隔の間に、送信者は古いキーチェーンの最後のキーを開示すべきです。これは、（第2及び第3のキーチェーンとの間のスイッチ、等の場合に又はK_ {2N + 1}）古いチェーン、K_Nの最後のキーと認証タグの公開鍵を交換することによって行われます。図7は、対応するフォーマットを示しています。
Note that since there is no padding between the "K_N" and "MAC(K'_i, M)" fields, the latter MAY not start on a 32-bit boundary, depending on the n_p parameter.
「K_N」と「MAC（K'_i、M）」との間にパディングが存在しないのでフィールドが、後者はN_Pパラメータに応じて、32ビット境界で開始しなくてもよいことに留意されたいです。
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Last Key of Old Chain, K_N ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Format of the Authentication Tag
with an Old Chain Last Key Disclosure
This section describes the TESLA operations at a receiver.
このセクションでは、受信機でTESLAの動作について説明します。
This section details the computation steps required to verify each of the three possible authentication information of an incoming packet. The verification MUST follow a strict order:
このセクションでは、着信パケットの三つの可能な認証情報のそれぞれを検証するために必要な計算手順を詳述します。検証は、厳密な順序に従う必要があります。
o first of all, if the Group MAC is present and if the session uses this feature (e.g., if the G bit is set in the bootstrap information message), then verify the Group MAC. A packet that does not contain a Group MAC tag, whereas the session uses this feature, MUST be dropped immediately. On the opposite, if a packet contains a Group MAC tag whereas the session does not use this feature, this tag MUST be ignored;
Oまず、場合グループMACが存在し、セッションがこの機能を使用する場合（例えば、Gビットがブートストラップ情報メッセージに設定されている場合）には、グループMACを検証します。セッションは、この機能を使用するのに対し、グループMACタグが含まれていないパケットは、すぐに下げなければなりません。セッションは、この機能を使用していないのに対し、パケットがグループMACタグが含まれている場合は逆に、このタグは無視しなければなりません。
o then, verify the digital signature (with TESLA signaling packets) or enter the TESLA authentication process (with data packets).
O、次いで、（TESLAシグナリングパケットで）デジタル署名を確認するか（データパケットで）TESLA認証プロセスに入ります。
Upon receiving a packet containing a Group MAC tag, the receiver recomputes the Group MAC and compares it to the value carried in the packet. If the check fails, the packet MUST be dropped immediately.
グループMACタグを含むパケットを受信すると、受信機は、グループMACを再計算し、パケットで搬送される値と比較します。チェックに失敗した場合、パケットはすぐに下げなければなりません。
More specifically, recomputing the Group MAC requires saving the value of the "Group MAC" field, setting this field to 0, and doing the same computation as a sender does (see Section 3.3.3).
具体的には、グループMACを再計算すると、「グループMAC」フィールドの値を保存し、0にこのフィールドを設定すると、送信者が行うのと同じ計算を行うことが必要です（3.3.3項を参照してください）。
Upon receiving a packet containing a digital signature, the receiver verifies the signature as follows.
次のようにデジタル署名を含むパケットを受信すると、受信機は、署名を検証します。
The computation of the signature MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP headers MUST NOT be included. During this computation, the "Signature" field MUST be set to 0 as well as the optional Group MAC, when present.
署名の計算は、（様々なヘッダ拡張子を持つ）ALC又はNORMヘッダとペイロード適用を含まなければなりません。 UDP / IPヘッダを含んではいけません。存在する場合、この計算中に、「署名」フィールドは、0に設定するだけでなく、オプションのグループMACなければなりません。
From [RFC4359]: Digital signature verification is performed as described in [RFC3447], Section 8.2.2 (RSASSA-PKCS1-v1_5) and [RFC3447], Section 8.1.2 (RSASSA-PSS). Upon receipt, the digital signature is passed to the verification function as S. The authenticated portion of the packet is used as the message M, and the RSA public key is passed as (n, e). In summary (when SHA-256 is used), the verification function computes a SHA-256 hash of the authenticated packet bytes, decrypts the SHA-256 hash in the packet, and validates that the appropriate encoding was applied. The two SHA-256 hashes are compared, and if they are identical the validation is successful.
[RFC4359]、[RFC3447]に記載されているように、デジタル署名の検証が行われ、セクション8.2.2（RSASSA-PKCS1-v1_5の）及び[RFC3447]、セクション8.1.2（RSASSA-PSS）。受信すると、デジタル署名は、パケットの認証された部分は、メッセージMとして使用されているS.として検証関数に渡され、RSA公開鍵（N、e）のように渡されます。 （SHA-256が使用されている）要約すると、検証機能は、認証されたパケットのバイトのSHA-256ハッシュを計算パケットにSHA-256ハッシュを復号し、適切な符号化が適用されたことを検証します。 2 SHA-256ハッシュを比較し、それらが同一である場合、検証は成功です。
It is assumed that the receivers have the possibility to retrieve the sender's public key required to check this digital signature (Section 2.2). This document does not specify how the public key of the sender is communicated reliably and in a secure way to all possible receivers.
受信機は、このデジタル署名（2.2節）を確認するために必要な送信者の公開鍵を取得する可能性があることを想定しています。この文書では、送信者の公開鍵は、すべての可能な受信機に確実かつ安全な方法で通信する方法を指定しません。
When a receiver wants to authenticate a packet using an authentication tag and when he has the key for the associated time interval (i.e., after the disclosing delay, d), the receiver recomputes the MAC and compares it to the value carried in the packet. If the check fails, the packet MUST be immediately dropped.
受信機は、認証タグを使用してパケットを認証したいと彼は関連する時間間隔のためのキーを有する場合（すなわち、開示の遅延の後に、d）に、受信機は、MACを再計算し、パケットで搬送される値と比較します。チェックに失敗した場合、パケットはすぐに下げなければなりません。
More specifically, recomputing the MAC requires saving the value of the "MAC" field, setting this field to 0, and doing the same computation as a sender does (see Section 3.3.1).
具体的には、MACを再計算すること（セクション3.3.1を参照）、「MAC」フィールドの値を保存し、0にこのフィールドを設定すると、送信者が行うのと同じ計算を行うことが必要です。
A receiver MUST be initialized before being able to authenticate the source of incoming packets. This can be done by an out-of-band mechanism or an in-band mechanism (Section 2.2). Let us focus on the in-band mechanism. Two actions must be performed:
受信機は、着信パケットの送信元を認証することができる前に初期化されなければなりません。これは、アウトオブバンドメカニズムまたはインバンド機構（セクション2.2）によって行うことができます。私たちは、インバンドのメカニズムに焦点を当ててみましょう。二つのアクションを実行する必要があります。
o receive and process a bootstrap information message, and
O受信してブートストラップ情報メッセージを処理し、そして
o calculate an upper bound of the sender's local time. To that purpose, the receiver must perform time synchronization.
O送信者の現地時間の上限を計算します。その目的のために、受信機は、時刻同期を実行する必要があります。
A receiver must first receive a packet containing the bootstrap information, digitally signed by the sender. Once the bootstrap information has been authenticated (see Section 4.1), the receiver can initialize its TESLA component. The receiver MUST then ignore the following bootstrap information messages, if any. There is an exception though: when a new key chain is used and if a receiver missed all the commitments for this new key chain, then this receiver MUST process one of the future bootstrap information messages (if any) in order to be able to authenticate the incoming packets associated to this new key chain.
受信機は、最初のデジタル送信者によって署名されたブートストラップ情報を含むパケットを受信しなければなりません。ブートストラップ情報が認証されたら、受信機は、そのテスラコンポーネントを初期化することができ、（セクション4.1を参照）。もしあれば、受信機は、その後、次のブートストラップ情報メッセージを無視しなければなりません。新しいキーチェーンを使用した場合と、受信機は、この新しいキーチェーンのすべての約束を逃した場合、この受信機は、認証できるようにするために、将来のブートストラップ情報メッセージ（もしあれば）のいずれかを処理しなければならない：そこに例外は、しかしです着信パケットは、この新しいキーチェーンに関連します。
Before TESLA has been initialized, a receiver MUST discard incoming packets other than the bootstrap information message and direct time synchronization response.
TESLAが初期化される前に、受信機は、ブートストラップ情報メッセージと直接時刻同期応答以外の着信パケットを捨てなければなりません。
First of all, the receiver must know whether the ALC or NORM session relies on direct or indirect time synchronization. This information is communicated by an out-of-band mechanism (for instance, when describing the various parameters of an ALC or NORM session). In some cases, both mechanisms might be available and the receiver can choose the preferred technique.
まず第一に、受信機は、ALCまたはNORMセッションが直接または間接的な時刻同期に依存しているかどうかを知る必要があります。この情報は、アウトオブバンド機構によって通信される（例えば、ALC又はNORMセッションの各種パラメータを記述する場合）。いくつかのケースでは、両方のメカニズムが利用可能である可能性があり、受信機は、好適な技術を選択することができます。
In the case of a direct time synchronization, a receiver MUST synchronize with the sender. To that purpose, the receiver sends a direct time synchronization request message. This message includes the local time (in NTP timestamp format) at the receiver when sending the message. This timestamp will be copied in the sender's response for the receiver to associate the response to the request.
直接時間同期の場合、受信機は、送信側と同期しなければなりません。その目的のために、受信機は、直接、時刻同期要求メッセージを送信します。このメッセージは、メッセージを送信し、受信機において（NTPタイムスタンプ形式で）ローカル時刻を含んでいます。このタイムスタンプは、要求に対する応答を関連付けるために、受信のために送信者の応答にコピーされます。
The direct time synchronization request message format is the following:
直接時刻同期要求メッセージのフォーマットは以下の通りであります：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_r (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of a Direct Time Synchronization Request
図8：直接時刻同期要求のフォーマット
The direct time synchronization request (Figure 8) contains the following information:
直接時刻同期要求（図8）は、次の情報が含まれます。
"t_r" (NTP timestamp, 64 bits):
"T_R"（NTPタイムスタンプ、64ビット）：
"t_r" is a timestamp in NTP timestamp format that contains the receiver local time value when sending this direct time synchronization request message;
「T_R」はこの直接時刻同期要求メッセージを送信し、受信機のローカル時間値が含まれているNTPタイムスタンプ形式のタイムスタンプです。
"Group MAC" field (optional, variable length, multiple of 32 bits):
「グループMAC」フィールド（オプション、可変長、32ビットの倍数）。
This field contains the Group MAC, calculated with the group key, K_g, shared by all group members. The field length, in bits, is given by n_w, which is known once the Group MAC function type is known (Section 7).
このフィールドは、すべてのグループメンバーが共有するグループキー、K_G、で計算グループMACが含まれています。フィールド長は、ビット単位で、グループMAC機能タイプは（セクション7）が知られると知られているn_w、によって与えられます。
The receiver then awaits a response message (Section 3.4.2). Upon receiving this message, the receiver:
受信機は、応答メッセージ（3.4.2）を待ちます。このメッセージを受信すると、受信機：
checks that this response relates to the request, by comparing the "t_r" fields;
この応答は「T_R」フィールドを比較することにより、要求に関連することをチェックします。
checks the Group MAC if present;
グループMAC存在する場合は、チェックします。
checks the signature;
署名をチェックします。
retrieves the t_s value and calculates D_t (Section 2.4.1).
T_S値を取得し、D_t（2.4.1項）を算出します。
Note that in an ALC session, the direct time synchronization request message is sent to the sender by an out-of-band mechanism that is not specified by the current document.
ALCセッションで、直接時刻同期要求メッセージが現在のドキュメントで指定されていないアウトオブバンド機構によって送信者に送信されることに注意してください。
With the indirect time synchronization method, the sender MAY provide out-of-band the URL or IP address of the NTP server(s) he trusts along with an OPTIONAL certificate for each NTP server. When several NTP servers are specified, a receiver MUST choose one of them. This document does not specify how the choice is made, but for the sake of scalability, the clients SHOULD NOT use the same server if several possibilities are offered. The NTP synchronization between the NTP server and the receiver MUST be authenticated, either using the certificate provided by the server or another certificate the client may obtain for this NTP server.
間接的な時刻同期方式では、送信者がNTPサーバ（複数可）のアウトオブバンドURLまたはIPアドレスを提供するかもしれ彼は、各NTPサーバのオプション証明書と一緒に信頼します。複数のNTPサーバを指定した場合、受信機は、それらのいずれかを選択する必要があります。この文書では、選択が行われる方法を指定しませんが、いくつかの可能性が提供される場合は、スケーラビリティのために、クライアントが同じサーバーを使用しないでください。 NTPサーバと受信機との間のNTP同期は、サーバーまたはクライアントがこのNTPサーバに対して取得することができる別の証明書によって提供される証明書を使用して、認証されなければなりません。
Then the receiver computes the time offset between itself and the NTP server chosen. Note that the receiver does not need to update the local time, (which often requires root privileges), computing the time offset is sufficient.
次いで、受信機は、それ自体と選択されたNTPサーバとの間の時間オフセットを計算します。受信機はオフセットの時間が十分にあるコンピューティング、（多くの場合、root権限が必要です）ローカル時間を、更新する必要がないことに注意してください。
Since the offset between the server and the time reference, D^O_t, is indicated in the bootstrap information message (or communicated out-of-band), the receiver can now calculate an upper bound of the sender's local time (Section 2.4.2).
サーバと時間基準との間のオフセット、D ^ O_tは、ブートストラップ情報メッセージに示されている（またはアウトオブバンド連通）されているので、受信機は、現在（送信者のローカル時間の上限を計算することができ、セクション2.4.2 ）。
Note that this scenario assumes that each client trusts the sender and accepts aligning its NTP configuration to that of the sender, using one of the NTP server(s) suggested. If this assumption does not hold, the client MUST NOT use the NTP indirect time synchronization method (Section 2.3.2).
このシナリオでは、各クライアントが送信者を信頼し、（S）が提案NTPサーバのいずれかを使用して、送信者のそれにそのNTPコンフィギュレーションを揃える受け入れることを前提としています。この仮定が成立しない場合、クライアントはNTP間接的な時刻同期方式（セクション2.3.2）を使用してはなりません。
The receiver can now authenticate incoming packets (other than bootstrap information and direct time synchronization response packets). To that purpose, he MUST follow different steps (see [RFC4082], Section 3.5):
受信機は、現在（ブートストラップ情報と直接時刻同期応答パケット以外の）着信パケットを認証することができます。その目的のために、彼は異なるステップを（[RFC4082]、セクション3.5を参照してください）に従う必要があります。
1. The receiver parses the different packet headers. If none of the four TESLA authentication tags are present, the receiver MUST discard the packet. If the session is in "Single Key Chain" mode (e.g., when the "S" flag is set in the bootstrap information message), then the receiver MUST discard any packet containing an Authentication Tag with a New Key Chain Commitment or an Authentication Tag with a Last Key of Old Chain Disclosure.
1.受信機は、異なるパケットヘッダを解析します。 4つのTESLA認証タグのどれもが存在しない場合、受信機はパケットを捨てなければなりません。セッションが（「S」フラグは、ブートストラップ情報メッセージに設定されているなど、）「シングルキーチェーン」モードの場合、受信機は、新しいキーチェーンのコミットメントや認証タグと認証タグを含むすべてのパケットを捨てなければなりません古いチェーン開示の最後のキーを持ちます。
2. Safe packet test: When the receiver receives packet P_j, it first records the 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. The receiver then computes the highest interval the sender could possibly be in: highest_i = floor((t_j - T_0) / T_int). He also retrieves the "i" interval index from the authentication tag. The receiver can now proceed with the "safe packet" test. If highest_i < i + d, then the sender is not yet in the interval during which it discloses the key K_i. The packet is safe (but not necessarily authentic). If the test fails, the packet is unsafe, and the receiver MUST discard the packet.
2.安全なパケットのテスト：受信機がパケットP_jを受信すると、それは最初のパケットが到着した現地時間Tを記録します。 T_J = T + D_t：受信機は、パケットが到着した時点で、送信者のクロックの上限T_Jを計算します。 highest_i =フロア（ - T_0）/ T_INT（T_J）：受信機は、送信者が、おそらくであり得る最高の間隔を計算します。彼はまた、認証タグから「I」間隔のインデックスを取得します。受信機は現在、「安全なパケット」の試験に進むことができます。 highest_i iはDを - <場合、送信者は、それがキーK_Iを開示している間の時間間隔ではまだありません。パケットは、安全な（必ずしも本物ではない）です。テストが失敗した場合、パケットは安全ではない、と受信機は、パケットを捨てなければなりません。
3. Group MAC test: if the optional Group MAC tag is present and if the session uses this feature, then verify the Group MAC (Section 4.1.1). If the verification fails, the packet MUST be immediately dropped. A packet that does not contain a Group MAC tag whereas the session uses this feature MUST be immediately dropped. On the opposite, if a packet contains a Group MAC tag whereas the session does not use this feature, this tag MUST be ignored.
3.グループMAC検定：オプショングループMACタグが存在し、セッションは、この機能を使用する場合は、[グループMAC（4.1.1）を確認した場合。検証が失敗した場合、パケットはすぐに下げなければなりません。セッションのに対し、グループMACタグが含まれていないパケットは、この機能をすぐに下げなければなりません使用しています。セッションは、この機能を使用していないのに対し、パケットがグループMACタグが含まれている場合は逆に、このタグは無視しなければなりません。
4. Disclosed Key processing: When the packet discloses a key (i.e., with a Standard Authentication Tag, or with an Authentication Tag with a Last Key of Old Chain Disclosure), the following tests are performed:
4.キー処理を開示し：パケットがキー（すなわち、標準の認証タグを有する、または旧チェーン開示の最後のキーと認証タグを有する）を開示すると、次のテストが実行されます。
* New key index test: the receiver checks whether a legitimate
key already exists with the same index (i.e., i-d). If such a
legitimate key exists, the receiver compares its value with
the current disclosed key and if they are identical, skips the
"Unverifiable key test" and "Key verification test". If such
a legitimate key exists but the values differ, the receiver
MUST discard the packet.
* Unverifiable key test: when the disclosed key index is new, it is possible that no earlier disclosed and legitimate key exists for this key chain, thereby preventing the verification of the disclosed key. This happens when the disclosed key belongs to the old key chain and no commitment to this old key chain has ever been received (e.g., because the first bootstrap packet received by a latecomer is for the current key chain, and therefore includes a commitment to the current key chain, not the previous one). When this happens, the receiver MUST ignore the disclosed key (anyway useless) and skip the Key verification test.
*検証不能キーテスト：開示されたキーインデックスが新規である場合、それは以前に開示されていることが可能でなく、正規キーがそれによって公開鍵の検証を防止する、このキーチェーンのために存在します。後発で受信した最初のブートストラップパケットが現在のキーチェーンのためであり、したがってへのコミットメントが含まれているため、例えば（公開鍵は、古いキーチェーンに属しており、この古いキーチェーンへのコミットメントは、これまで受信していない場合に発生します現在のキーチェーンではなく、以前の1）。これが発生した場合、受信機は、公開鍵（とにかく役に立たない）を無視して、キーの確認テストをスキップしなければなりません。
* Key verification test: If the disclosed key index is new and the key can be verified, the receiver checks the legitimacy of K_{i-d} by verifying, for some earlier disclosed and legitimate key K_v (with v < i-d), that K_v and F^{i-d-v}(K_{i-d}) are identical. In other words, the receiver checks the disclosed key by computing the necessary number of PRF functions to obtain a previously disclosed and legitimate (i.e., verified) key. If the key verification fails, the receiver MUST discard the packet. If the key verification succeeds, this key is said to be legitimate and is stored by the receiver, as well as all the keys between indexes v and i-d.
*キー照合試験：開示されたキーインデックスは新規であり、キーが確認できた場合、受信機は、いくつかの以前に開示され、正規キーK_v（vで<ID）のために、検証することによってK_ {ID}の正当性をチェックし、そのK_vとF ^ {IDV}（K_ {ID}）は同一です。換言すれば、受信機は、以前に開示され、正当な（すなわち、検証）キーを取得するためにPRF関数の必要数を計算することによって、開示されたキーを確認します。キー照合が失敗した場合、受信機はパケットを捨てなければなりません。キー照合が成功した場合、このキーは正当であると言われ、受信機によって格納され、ならびに索引V及びI-Dとの間のすべてのキー。
5. When applicable, the receiver performs any congestion control related action (i.e., the ALC or NORM headers are used by the associated congestion control building block, if any), even if the packet has not yet been authenticated [RFC5651]. If this feature leads to a potential DoS attack (the attacker can send a faked packet with a wrong sequence number to simulate packet losses), it does not compromise the security features offered by TESLA and enables a rapid reaction in front of actual congestion problems.
5.該当する場合は、受信機は、パケットがまだ[RFC5651]を認証されていない場合でも、いずれかの輻輳制御に関連するアクション（もしあれば、すなわち、ALC又はNORMヘッダは、関連する輻輳制御ビルディングブロックによって使用される）を実行します。この機能は、潜在的なDoS攻撃につながる場合には（攻撃者は、パケットロスをシミュレートするために、間違ったシーケンス番号を偽造パケットを送信することができます）、それはTESLAによって提供されるセキュリティ機能を損ない、実際の輻輳問題の前に迅速な反応を可能にしません。
6. The receiver then buffers the packet for a later authentication, once the corresponding key will be disclosed (after d time intervals) or deduced from another key (if all packets disclosing this key are lost). In some situations, this packet might also be discarded later, if it turns out that the receiver will never be able to deduce the associated key.
前記受信機は、対応するキーが開示されると（D時間間隔の後に）、それ以降の認証用パケットをバッファまたは（このキーを開示するすべてのパケットが失われた場合）、別のキーから推定します。それは、受信機が関連する鍵を推測することはできないだろうということが判明した場合、いくつかの状況では、このパケットはまた、後に破棄される可能性があります。
7. Authentication test: Let v be the smallest index of the legitimate keys known by the receiver so far. For all the new keys K_w, with v < w <= i-d, that have been either disclosed by this packet (i.e., K_{i-d}) or derived by K_{i-d} (i.e., keys in interval {v+1,.. i-d-1}), the receiver verifies the authenticity of the safe packets buffered for the corresponding interval w. To authenticate one of the buffered packets P_h containing message M_h protected with a MAC that used key index w, the receiver will compute K'_w = F'(K_w) from which it can compute MAC( K'_w, M_h). If this MAC does not equal the MAC stored in the packet, the receiver MUST discard the packet. If the two MACs are equal, the packet is successfully authenticated and the receiver continues processing it.
7.認証試験：vは、これまでに受信機によって知られている合法的なキーの最小の指標とします。 K_wは、すべての新しいキーのために、Vと<W <=このパケットによって開示されているいずれかのID（すなわち、K_ {ID}）またはK_ {ID}間隔{V + 1（すなわち、キーにより導出,. 。ID-1}）、受信機は、対応する間隔Wの緩衝安全なパケットの正当性を検証します。 Wキーインデックスを使用MACで保護されたメッセージM_hを含むP_Hバッファされたパケットのいずれかを認証するために、受信機は、MAC（K'_w、M_h）を計算することができ、そこからK'_w = F '（K_w）を計算します。このMACは、パケットに格納されたMACと等しくない場合、受信機は、パケットを破棄しなければなりません。 2つのMACが等しい場合、パケットが正常に認証されると、受信機は、それを処理し続けます。
8. Authenticated new key chain commitment processing: If the authenticated packet contains a new key chain commitment and if no verified commitment already exists, then the receiver stores the commitment to the new key chain. Then, if there are non-authenticated packets for a previous chain (i.e., the key chain before the current one), all these packets can be discarded (Section 4.4).
8.認証新しいキーチェーンのコミットメント処理：認証されたパケットは、新しいキーチェーンのコミットメントが含まれており、何の検証コミットメントはすでに存在しない場合、受信機は、新しいキーチェーンへのコミットメントを格納した場合。次いで、前鎖に対する非認証パケットがある場合（すなわち、現在の前にキーチェーン）、これらの全てのパケットは廃棄することができる（4.4節）。
9. The receiver continues the ALC or NORM processing of all the packets authenticated during the authentication test.
9.受信機は、認証試験の間認証されたすべてのパケットのALCまたはNORM処理を継続します。
In this specification, a receiver using TESLA MUST immediately drop unsafe packets. But the receiver MAY also decide, at any time, to continue an ALC or NORM session in unsafe (insecure) mode, ignoring TESLA extensions. There SHOULD be an explicit user action to that purpose.
本明細書では、TESLAを用いて、受信機は直ちに危険なパケットを廃棄しなければなりません。しかし、受信機はまた、TESLA拡張を無視して、安全ではない（安全でない）モードでのALCまたはNORMセッションを継続するために、いつでも、決めることができます。そのために明示的なユーザアクションがあるはずです。
Following strictly the above steps can lead to excessive processing overhead in certain situations. This is the case when a receiver receives packets for an unwanted object with the ALC or NORM protocols, i.e., an object in which the application (or the end user) explicitly mentioned it is not interested. This is also the case when a receiver receives packets for an already decoded object, or when this object has been partitioned in several blocks, for an already decoded block. When such a packet is received, which is easily identified by looking at the receiver's status for the incoming ALC or NORM packet, the receiver MUST also check that the packet is a pure data packet that does not contain any signaling information of importance for the session.
厳密に上記の手順を実行すると、特定の状況における過度の処理オーバーヘッドにつながることができます。これは、受信機は、ALCまたはNORMプロトコル、アプリケーション（またはエンドユーザー）は明示的には興味がない述べている、すなわち、物体との望ましくないオブジェクトのパケットを受信した場合です。既に復号化されたブロックのために、受信機は、既に復号化されたオブジェクトのパケットを受信した場合、またはこのオブジェクトが複数のブロックに分割された場合にも同様です。このようなパケットを受信した場合、簡単に入ってくるALCまたはNORMパケットの受信機の状態を見ることで識別され、受信機は、パケットがセッションのために重要なのいずれかのシグナリング情報が含まれていない純粋なデータパケットがあることをチェックしなければなりません。
With ALC, a packet containing an "A" flag ("Close Session") or a "B" flag ("Close Object") MUST NOT be discarded before having been authenticated and processed normally. Otherwise, the receiver can safely discard the incoming packet for instance just after step 1 of Section 4.3. This optimization can dramatically reduce the processing overhead by avoiding many useless authentication checks.
ALC、「A」フラグ（「クローズセッション」）又は「B」フラグ（「近距離物体」）を含むパケットを用いて認証され、正常に処理された前に廃棄してはいけません。そうでない場合、受信機は、安全にちょうど4.3節の手順1の後にインスタンスの着信パケットを破棄することができます。この最適化は飛躍的に多くの無駄な認証チェックを回避することにより、処理のオーバーヘッドを減らすことができます。
In some cases, a receiver having experienced a very long disconnection might have lost all the disclosures of the last key(s) of a previous key chain. Let j be the index of this key chain for which there remains non-authenticated packets. This receiver can flush all the packets of the key chain j if he determines that:
いくつかのケースでは、非常に長い切断を経験した受信機は、前のキーチェーンの最後のキー（複数可）の全ての開示を失っているかもしれません。 jは非認証パケットが残っているため、このキーチェーンの指標とします。彼があると判断した場合、この受信機は、キーチェーンjのすべてのパケットをフラッシュすることができます。
o he has just switched to a chain of index j+2 (inclusive) or higher;
O彼はただ、インデックスjのチェーン+ 2（包括的）以上に切り替わりました。
o the sender has sent a commitment to the new key chain of index j+2 (Section 3.1.2.3). This situation requires that the receiver has received a packet containing such a commitment and that he has been able to check its integrity. In some cases, it might require receiving a bootstrap information message for the current key chain.
O送信者は、インデックスj + 2（セクション3.1.2.3）の新しいキーチェーンへのコミットメントを送りました。この状況は、受信機は、このようなコミットメントを含むパケットを受信したことを必要とし、彼はその整合性をチェックすることができたこと。いくつかのケースでは、それが現在のキーチェーンのためのブートストラップ情報メッセージを受信する必要がある場合があります。
If one of the above two tests succeeds, the sender can discard all the awaiting packets since there is no way to authenticate them.
上記二つの試験のいずれかが成功した場合、それらを認証する方法がないため、送信者はすべての待っているパケットを破棄することができます。
The integration of TESLA in ALC or NORM is similar and relies on the header extension mechanism defined in both protocols. More precisely, this document details the EXT_AUTH==1 header extension defined in [RFC5651].
ALC又はNORMでTESLAの統合は類似しており、両方のプロトコルで定義されたヘッダ拡張メカニズムに依存しています。より正確には、このドキュメントは[RFC5651]で定義さEXT_AUTH == 1ヘッダ拡張を詳述します。
Several fields are added in addition to the "HET" (Header Extension Type) and "HEL" (Header Extension Length) fields (Figure 9).
いくつかのフィールドは、「HET」（ヘッダ拡張タイプ）および「HEL」（ヘッダ拡張長）フィールド（図9）に加えて添加されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ ~
| Content |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Format of the TESLA EXT_AUTH Header Extension
図9：TESLA EXT_AUTHヘッダー拡張のフォーマット
The fields of the TESLA EXT_AUTH Header Extension are:
TESLA EXT_AUTHヘッダー拡張のフィールドは、次のとおりです。
"ASID" (Authentication Scheme IDentifier) field (4 bits):
"ASID"（認証スキーム識別子）フィールド（4ビット）：
The "ASID" identifies the source authentication scheme or protocol in use. The association between the "ASID" value and the actual authentication scheme is defined out-of-band, at session startup.
「ASID」は、使用中のソースの認証方式またはプロトコルを識別する。 「ASID」値と実際の認証方式との間の関連付けは、セッションの起動時に、アウトオブバンドに定義されています。
"Type" field (4 bits):
"Type" フィールド（4ビット）：
The "Type" field identifies the type of TESLA information carried in this header extension. This specification defines the following types:
「Type」フィールドは、このヘッダー拡張で搬送TESLA情報のタイプを識別する。この仕様は、次のタイプを定義します。
* 0: Bootstrap information, sent by the sender periodically or after a direct time synchronization request;
* 0：情報ブートストラップ、定期的に、または直接、時刻同期要求の後に送信者によって送られました。
* 1: Standard Authentication Tag for the ongoing key chain, sent by the sender along with a packet;
* 1：パケットとともに送信者から送られた継続的なキーチェーン、のための標準的な認証タグ。
* 2: Authentication Tag without Key Disclosure, sent by the sender along with a packet;
* 2：パケットとともに送信者から送られたキー情報開示せずに認証タグ、;
* 3: Authentication Tag with a New Key Chain Commitment, sent by the sender when approaching the end of a key chain;
* 3：キーチェーンの終わりに近づいたときに、送信者によって送信された新しいキーチェーンのコミットメント、と認証タグ。
* 4: Authentication Tag with a Last Key of Old Chain Disclosure, sent by the sender some time after moving to a new key chain;
* 4：新しいキーチェーンに移動した後、送信者がいくつかの時間を送った古いチェーン開示、の最後のキーと認証タグ。
* 5: Direct time synchronization request, sent by a NORM receiver. This type of message is invalid in the case of an ALC session since ALC is restricted to unidirectional transmissions. Yet, an external mechanism may provide the direct time synchronization functionality;
* 5：NORM受信機によって送信された直接時刻同期要求、。 ALCは、単方向伝送に制限されているので、このタイプのメッセージは、ALCセッションの場合は無効です。まだ、外部機構が直接時刻同期機能を提供することができます。
* 6: Direct time synchronization response, sent by a NORM sender. This type of message is invalid in the case of an ALC session since ALC is restricted to unidirectional transmissions. Yet, an external mechanism may provide the direct time synchronization functionality.
* 6：NORMの送信者によって送信された直接の時刻同期応答、。 ALCは、単方向伝送に制限されているので、このタイプのメッセージは、ALCセッションの場合は無効です。しかし、外部のメカニズムは、直接時刻同期機能を提供することができます。
"Content" field (variable length):
「コンテンツ」フィールド（可変長）：
This is the TESLA information carried in the header extension, whose type is given by the "Type" field.
これは、そのタイプ「タイプ」フィールドで与えられるヘッダ拡張で搬送さTESLA情報です。
Each packet sent by the session's sender MUST contain exactly one TESLA EXT_AUTH Header Extension.
セッションの送信者によって送られた各パケットは、1つのTESLA EXT_AUTHヘッダー拡張を含まなければなりません。
All receivers MUST recognize EXT_AUTH but MAY not be able to parse its content, for instance, because they do not support TESLA. In that case, these receivers MUST ignore the TESLA EXT_AUTH extensions. In the case of NORM, the packets sent by receivers MAY contain a direct synchronization request but MUST NOT contain any of the other five TESLA EXT_AUTH Header Extensions.
すべてのレシーバはEXT_AUTHを認識しなければならないが、彼らはTESLAをサポートしていないので、例えば、その内容を解析することができないかもしれません。その場合には、これらの受信機は、TESLA EXT_AUTH拡張子を無視しなければなりません。 NORMの場合は、受信機によって送信されたパケットは、直接同期要求を含んでいてもよいが、他の5つのTESLA EXT_AUTHヘッダー拡張機能のいずれかを含めることはできません。
The "bootstrap information" TESLA EXT_AUTH (Type==0) MUST be sent in a stand-alone control packet, rather than in a packet containing application data. The reason for that is the large size of this bootstrap information. By using stand-alone packets, the maximum payload size of data packets is only affected by the (mandatory) authentication information header extension.
「ブートストラップ情報」TESLA EXT_AUTH（タイプ== 0）がなく、アプリケーション・データを含むパケットよりも、スタンドアロンの制御パケットで送信されなければなりません。その理由は、このブートストラップ情報のサイズが大きいです。スタンドアロンパケットを使用して、データ・パケットの最大ペイロードサイズのみ（必須）認証情報ヘッダ拡張によって影響されます。
With ALC, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a control packet, i.e., containing no encoding symbol.
ALCと、「ブートストラップ情報」TESLA EXT_AUTHには、符号化シンボルを含まない、すなわち、制御パケットで送信されなければなりません。
With NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a NORM_CMD(APPLICATION) message.
NORMと、「ブートストラップ情報」TESLA EXT_AUTHはNORM_CMD（アプリケーション）メッセージで送信されなければなりません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| HET (=1) | HEL (=46) | ASID | 0 | 0 | 0 |0|1|0| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| d | 2 | 2 | 2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1 | 3 | 128 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 0 (reserved) | T_int | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
+ T_0 (NTP timestamp format) + | 5
| | | 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| N (Key Chain Length) | | b
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | y
| Current Interval Index i | | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e
| | | s
+ + |
| | |
+ Current Key Chain Commitment + |
| (20 bytes) | |
+ + |
| | |
+ + |
| | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature . | b
. (128 bytes) . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Group MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Example: Format of the Bootstrap Information Message
(Type 0) Using SHA-256/1024-Bit Signatures,
the Default HMAC-SHA-256, and a Group MAC
For instance, Figure 10 shows the bootstrap information message when using the HMAC-SHA-256 transform for the PRF, MAC, and Group MAC functions, along with SHA-256/128 byte (1024 bit) key digital signatures (which also means that the "Signature" field is 128 bytes long). The TESLA EXT_AUTH Header Extension is then 184 bytes long (i.e., 46 words of 32 bits).
例えば、図10は、またことを意味する（HMAC-SHA-256、SHA-128分の256バイト（1024ビット）のキーのデジタル署名と共に、PRF、MAC、及びグループMAC機能のために変換を使用してブートストラップ情報メッセージを示し「署名」フィールド）は128バイト長です。 TESLA EXT_AUTHヘッダ拡張は、その後で184バイト長（すなわち、32ビットの46ワード）。
The four "authentication tag" TESLA EXT_AUTH Header Extensions (Type 1, 2, 3, and 4) MUST be attached to the ALC or NORM packet (data or control packet) that they protect.
4つの「認証タグ」TESLA EXT_AUTHヘッダ拡張（タイプ1、2、3、および4）それらが保護することをALC又はNORMパケット（データまたは制御パケット）に取り付けなければなりません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=10) | ASID | 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Disclosed Key K_{i-d} +
| (20 bytes) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| MAC(K'_i, M) |
+ (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Example: Format of the Standard Authentication Tag (Type 1) Using the Default HMAC-SHA-256
図11：例：デフォルトHMAC-SHA-256を使用して標準的な認証タグ（タイプ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=5) | ASID | 2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| MAC(K'_i, M) |
+ (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Example: Format of the Authentication Tag without Key Disclosure (Type 2) Using the Default HMAC-SHA-256
図12：例：デフォルトHMAC-SHA-256を使用してキー・ディスクロージャー（タイプ2）せずに認証タグの形式
For instance, Figures 11 and 12 show the format of the authentication tags, respectively with and without the K_{i-d} key disclosure, when using the (default) HMAC-SHA-256 transform for the PRF and MAC functions. In these examples, the Group MAC feature is not used.
HMAC-SHA-256は、PRFとMAC機能のための変換、例えば、図11及び図12を用いておよびK_ {I-D}キー開示、（デフォルト）を使用することなく、それぞれの認証タグのフォーマットを示します。これらの例では、グループMAC機能が使用されていません。
5.2.3. EXT_AUTH Header Extension of Type Direct Time Synchronization Request
5.2.3. タイプのダイレクト時刻同期要求のEXT_AUTHヘッダー拡張
With NORM, the "direct time synchronization request" TESLA EXT_AUTH (Type==7) MUST be sent by a receiver in a NORM_CMD(APPLICATION) NORM packet.
NORMと、「直接時刻同期要求」TESLA EXT_AUTH（タイプ== 7）がNORM_CMD（APPLICATION）NORMパケットに受信機によって送信されなければなりません。
With ALC, the "direct time synchronization request" TESLA EXT_AUTH cannot be included in an ALC packet, since ALC is restricted to unidirectional transmissions, from the session's sender to the receivers. An external mechanism must be used with ALC for carrying direct time synchronization requests to the session's sender.
ALCは、受信機へのセッションの送信者から、一方向の伝送に制限されているので、ALC、「直接時刻同期要求」とTESLA EXT_AUTHは、ALCパケットに含めることはできません。外部機構は、セッションの送信者に直接、時刻同期要求を搬送するためにALCを使用する必要があります。
In the case of direct time synchronization, it is RECOMMENDED that the receivers spread the transmission of direct time synchronization requests over the time (Section 2.3.1).
直接時間同期の場合には、受信機が時間（2.3.1項）を直接時刻同期要求の送信を広げることが推奨されます。
5.2.4. EXT_AUTH Header Extension of Type Direct Time Synchronization Response
5.2.4. タイプのダイレクト時刻同期応答のEXT_AUTHヘッダー拡張
With NORM, the "direct time synchronization response" TESLA EXT_AUTH (Type==8) MUST be sent by the sender in a NORM_CMD(APPLICATION) message.
NORMと、「直接時刻同期応答」TESLA EXT_AUTH（タイプ== 8）がNORM_CMD（アプリケーション）メッセージに送信者によって送信されなければなりません。
With ALC, the "direct time synchronization response" TESLA EXT_AUTH can be sent in an ALC control packet (i.e., containing no encoding symbol) or through the external mechanism used to carry the direct time synchronization request.
ALCと、「直接時刻同期応答」TESLA EXT_AUTHは、ALC制御パケットで送信することができる（すなわち、全く符号化シンボルを含まない）、または直接時刻同期要求を搬送するために使用される外部機構を介し。
[RFC4082] discusses the security of TESLA in general. These considerations apply to the present specification, namely:
[RFC4082]は、一般に、TESLAのセキュリティを論じています。これらの考慮事項は、すなわち、本明細に適用されます。
o great care must be taken in the timing aspects. In particular, the D_t parameter is critical and must be correctly initialized;
O細心の注意は、タイミングの面で注意する必要があります。特に、D_tパラメータが重要であり、正しく初期化する必要があります。
o if the sender realizes that the key disclosure schedule is not appropriate, then the current session MUST be closed and a new one created. Indeed, Section 3.1.3 requires that these parameters be fixed during the whole session.
送信者は、キー公開スケジュールが適切でないことを認識した場合、O、その後、現在のセッションを閉じなければならないと新しいものを作成しました。確かに、3.1.3項では、これらのパラメータは、全体のセッションの間に固定されている必要があります。
o when the verifier that authenticates the incoming packets and the application that uses the data are two different components, there is a risk that an attacker located between these components inject faked data. Similarly, when the verifier and the secure timing system are two different components, there is a risk that an attacker located between these components inject faked timing information. For instance, when the verifier reads the local time by means of a dedicated system call (e.g., gettimeofday()), if an attacker controls the host, he may catch the system call and return a faked time information.
着信パケットの認証を検証し、データを使用するアプリケーションは、2つの異なる成分である場合、O、これらの構成要素の間に位置する攻撃者がデータを偽造注入するおそれがあります。検証者と安全なタイミングシステムは、2つの異なるコンポーネントである場合も同様に、これらの構成要素の間に位置する攻撃者がタイミング情報を偽造注入するおそれがあります。検証者は、専用のシステムコール（例えば、gettimeofdayの（））によってローカル時刻を読み取ると、攻撃者がホストを制御する場合、例えば、彼はシステムコールをキャッチし、偽造時刻情報を返すことができます。
The current specification discusses additional aspects with more details.
現在の仕様では、より詳細で追加の態様について説明します。
TESLA introduces new opportunities for an attacker to mount DoS attacks. For instance, an attacker can try to saturate the processing capabilities of the receiver (faked packets are easy to create but checking them requires computing a MAC over the packet or sometimes checking a digital signature as with the bootstrap and direct time synchronization response messages). An attacker can also try to saturate the receiver's memory (since authentication is delayed and non-authenticated packets will accumulate), or to make the receiver believe that a congestion has happened (since congestion control MUST be performed before authenticating incoming packets, Section 4.3).
TESLAは、DoS攻撃をマウントするには、攻撃者のための新しい機会を紹介します。例えば、攻撃者は、受信機の処理能力を飽和させるために試みることができる（偽造パケットが作成しやすいが、それを確認しているパケットの上にMACを計算するか、時々、ブートストラップと直接時刻同期応答メッセージと同様に、デジタル署名を確認する必要があります）。攻撃者はまた、（認証が遅れると非認証されているので、パケットが蓄積されます）受信機のメモリを飽和させるために、または受信機は（輻輳制御は、着信パケットを認証する前に実行しなければならないため、4.3節）の輻輳が発生したことを信じて作ってみることができます。
In order to mitigate these attacks, it is RECOMMENDED to use the Group MAC scheme (Section 3.3.3). No mitigation is possible if a group member acts as an attacker with Group MAC.
これらの攻撃を緩和するためには、グループMACスキーム（3.3.3）を使用することをお勧めします。グループメンバーがグループMACと、攻撃者として動作している場合いかなる緩和は可能ではありません。
Generally, it is RECOMMENDED that the amount of memory used to store incoming packets waiting to be authenticated be limited to a reasonable value.
一般に、認証されるのを待っている着信パケットを格納するために使用されるメモリの量は、合理的な値に限定されることが推奨されます。
Replay attacks, whereby an attacker stores a valid message and replays it later, can have significant impacts, depending on the message type. Two levels of impacts must be distinguished:
攻撃者は、それが後に、メッセージの種類に応じて、大きな影響を持つことができ、有効なメッセージとリプレイを保存することにより、リプレイ攻撃。影響の二つのレベルを区別する必要があります。
o within the TESLA protocol, and
TESLAプロトコル内O、及び
o within the ALC or NORM protocol.
ALCまたはNORMプロトコル内のO。
Replay attacks can impact the TESLA component itself. We review here the potential impacts of such an attack depending on the TESLA message type:
リプレイ攻撃はTESLAコンポーネント自体に影響を与えることができます。ここではTESLAメッセージの種類に応じて、このような攻撃の潜在的な影響を確認します。
o bootstrap information: Since most parameters contained in a bootstrap information message are static, replay attacks have no consequences. The fact that the "i" and "K_i" fields can be updated in subsequent bootstrap information messages does not create a problem either, since all "i" and "K_i" fields sent remain valid. Finally, a receiver that successfully initialized its TESLA component MUST ignore the following messages (see Section 4.2.1 for an exception to this rule), which voids replay attacks, unless he missed all the commitments to a new key chain (e.g., after a long disconnection) (Section 3.2.1).
O情報をブートストラップ：ブートストラップ情報メッセージに含まれるほとんどのパラメータは静的なので、リプレイ攻撃には影響がありません。送信されたすべての「i」と「K_I」フィールドが有効なままであるため、「I」と「K_I」のフィールドは、後続のブートストラップ情報メッセージで更新することができるという事実は、いずれかの問題を作成しません。最後に、成功した後、彼は例えば、新しいキーチェーン（にすべての約束を逃した場合を除き、次のメッセージを無視しなければなりませんそのTESLAコンポーネントは、リプレイ攻撃を無効に、（この規則の例外については、セクション4.2.1を参照）を初期化する受信機長い断線）（3.2.1節）。
o direct time synchronization request: If the Group MAC scheme is used, an attacker that is not a member of the group can replay a packet and oblige the sender to respond, which requires digitally signing the response, a time-consuming process. If the Group MAC scheme is not used, an attacker can easily forge a request anyway. In both cases, the attack will not compromise the TESLA component, but might create a DoS. If this is a concern, it is RECOMMENDED, when the Group MAC scheme is used, that the sender verify the "t_r" NTP timestamp contained in the request and respond only if this value is strictly larger than the previous one received from this receiver. When the Group MAC scheme is not used, this attack can be mitigated by limiting the number of requests per second that will be processed.
直接、時刻同期要求○：グループMAC方式を使用している場合、グループのメンバーではない攻撃者がデジタル応答、時間のかかるプロセスに署名必要とするパケットを再生し、応答するために送信者を義務付けることができます。グループMAC方式を使用していない場合、攻撃者が簡単にとにかくリクエストを偽造することができます。どちらの場合も、攻撃はTESLAコンポーネントを損なうことはありませんが、DoS攻撃を作成することがあります。これが懸念される場合には、送信者が要求に含まれる「T_R」NTPタイムスタンプを検証し、この値は、この受信機から受信した以前のものよりも厳密に大きい場合にのみ応答することを、グループMAC方式を使用する場合には、推奨されます。グループMACスキームを使用しない場合は、この攻撃が処理されます秒あたりの要求の数を制限することによって緩和することができます。
o direct time synchronization response: Upon receiving a response, a receiver who has no pending request MUST immediately drop the packet. If this receiver has previously issued a request, he first checks the Group MAC (if applicable), then the "t_r" field, to be sure it is a response to his request, and finally the digital signature. A replayed packet will be dropped during these verifications, without compromising the TESLA component.
直接時刻同期応答（O）応答を受信すると、保留中の要求を持っていない受信機はすぐにパケットを廃棄しなければなりません。この受信機は、以前に要求を発行した場合、彼は最初、それは彼の要求に応じて、最終的にはデジタル署名であることを確認するために、グループMAC（該当する場合）、そして「T_R」フィールドをチェックします。リプレイパケットはTESLAコンポーネントを損なうことなく、これらの検証中にドロップされます。
o other messages, containing an authentication tag: Replaying a packet containing a TESLA authentication tag will never compromise the TESLA component itself (but perhaps the underlying ALC or NORM component, see below).
認証タグを含む他のメッセージ、○：TESLAコンポーネント自体を損なうことはありませんTESLA認証タグを含むパケットをリプレイ（おそらく基礎となるALCまたはNORMコンポーネントは、以下を参照してください）。
To conclude, TESLA itself is robust in front of replay attacks.
結論するには、TESLA自体はリプレイ攻撃の前に堅牢です。
We review here the potential impacts of a replay attack on the NORM component. Note that we do not consider here the protocols that could be used along with NORM, for instance, the congestion control protocols.
ここではNORMコンポーネントのリプレイ攻撃の潜在的な影響を確認します。私たちはここに、たとえば、NORMと一緒に使用することができプロトコル、輻輳制御プロトコルを考慮していないことに注意してください。
First, let us consider replay attacks within a given NORM session. NORM defines a "sequence" field that can be used to protect against replay attacks [RFC5740] within a given NORM session. This "sequence" field is a 16-bit value that is set by the message originator (sender or receiver) as a monotonically increasing number incremented with each NORM message transmitted. It is RECOMMENDED that a receiver check this "sequence" field and drop messages considered as replayed. Similarly, it is RECOMMENDED that a sender check this sequence, for each known receiver, and drop messages considered as replayed. In both cases, checking this "sequence" field SHOULD be done before TESLA processing of the packet: if the "sequence" field has not been corrupted, the replay attack will immediately be identified; otherwise, the packet will fail the TESLA authentication test. This analysis shows that NORM itself is robust in front of replay attacks within the same session.
まず、私たちは与えられたNORMセッション内でリプレイ攻撃を考えてみましょう。 NORMは、与えられたNORMセッション内でリプレイ攻撃から保護するために使用することができ、「配列」フィールド[RFC5740]を定義します。この「配列」フィールドは、送信された各NORMメッセージでインクリメント単調に増加する数としてメッセージ発信元（送信者または受信者）によって設定された16ビットの値です。受信機が、この「順序」フィールドをチェックして、リプレイとして考えたメッセージをドロップすることが推奨されます。同様に、送信者が既知の各受信機のために、この配列を確認し、再生と考えるメッセージをドロップすることが推奨されます。どちらの場合も、この「順序」フィールドをチェックすることは、パケットのTESLA処理の前に行われるべきである：「順序」フィールドが破損していない場合は、リプレイ攻撃を即座に識別されます。そうでない場合、パケットはTESLA認証試験に失敗します。この分析は、NORM自体は同一セッション内でリプレイ攻撃の前に堅牢であることを示しています。
Now let us consider replay attacks across several NORM sessions. Since the key chain used in each session MUST differ, a packet replayed in a subsequent session will be identified as unauthentic. Therefore, NORM is robust in front of replay attacks across different sessions.
今、私たちはいくつかのNORMセッション間でリプレイ攻撃を考えてみましょう。各セッションで使用されるキーチェーンが異なるなければならないので、その後のセッションで再生パケットは、不正として識別されます。したがって、NORMは異なるセッション間でリプレイ攻撃の前に堅牢です。
We review here the potential impacts of a replay attack on the ALC component. Note that we do not consider here the protocols that could be used along with ALC, for instance, the layered or wave-based congestion control protocols.
ここではALCコンポーネントのリプレイ攻撃の潜在的な影響を確認します。私たちはここで例えば、ALCと一緒に使用することができプロトコル層または波ベースの輻輳制御プロトコルを考慮していないことに注意してください。
First, let us consider replay attacks within a given ALC session:
まず、私たちは与えられたALCセッション内でリプレイ攻撃を考えてみましょう：
o Regular packets containing an authentication tag: a replayed message containing an encoding symbol will be detected once authenticated, thanks to the object/block/symbol identifiers, and will be silently discarded. This kind of replay attack is only penalizing in terms of memory and processing load, but does not compromise the ALC behavior.
認証タグを含むO定期パケット：符号化シンボルを含む再生メッセージは、一度認証されたオブジェクト/ブロック/シンボル識別子のおかげで検出され、静かに捨てられるであろう。リプレイ攻撃のこの種の専用メモリと処理負荷の面で不利にされていますが、ALC動作を損ないません。
o Control packets containing an authentication tag: ALC control packets, by definition, do not include any encoding symbol and therefore do not include any object/block/symbol identifier that would enable a receiver to identify duplicates. However, a sender has a very limited number of reasons to send control packets. More precisely:
O認証タグを含む制御パケット：ALC制御パケットは、定義により、任意の符号化シンボルを含んでいない、従って、重複を識別するために受信機を可能にする任意のオブジェクト/ブロック/シンボルの識別子を含みません。ただし、送信者は、制御パケットを送信するための理由の非常に限られた数を持っています。より正確に：
* At the end of the session, a "Close Session" ("A" flag) packet is sent. Replaying this packet has no impact since the receivers already left.
*セッション、「閉じるセッション」の終わりに（「」フラグ）パケットが送信されます。このパケットを再生することは、すでに左の受信器からは影響を与えません。
* Similarly, replaying a packet containing a "Close Object" ("B" flag) has no impact since this object is probably already marked as closed by the receiver.
*同様に、「近距離物体」（「B」フラグ）を含むパケットを再生する受信機によって閉じられ、このオブジェクトはおそらく既にマークされているので、影響を及ぼしません。
This analysis shows that ALC itself is robust in front of replay attacks within the same session.
この分析は、ALC自体は同一セッション内でリプレイ攻撃の前に堅牢であることを示しています。
Now let us consider replay attacks across several ALC sessions. Since the key chain used in each session MUST differ, a packet replayed in a subsequent session will be identified as unauthentic. Therefore, ALC is robust in front of replay attacks across different sessions.
今、私たちはいくつかのALCセッション間でリプレイ攻撃を考えてみましょう。各セッションで使用されるキーチェーンが異なるなければならないので、その後のセッションで再生パケットは、不正として識別されます。したがって、ALCは異なるセッション間でリプレイ攻撃の前に堅牢です。
As specified in Section 1.1, this specification does not consider the packets that may be sent by receivers, for instance, NORM's feedback packets. When a back channel is used, its security is critical to the global security, and an appropriate security mechanism MUST be used. [RMT-SIMPLE-AUTH] describes several techniques that can be used to that purpose. However, the authentication and integrity verification of the packets sent by receivers on the back channel, if any, is out of the scope of this document.
1.1項に規定されているように、この仕様は、NORMのフィードバックパケットを、たとえば、受信機によって送信されるパケットを考慮しません。バックチャネルを使用する場合は、そのセキュリティは、世界の安全保障にとって重要な、そして適切なセキュリティメカニズムを使用しなければなりません。 [RMT-SIMPLE-AUTH]は、この目的に使用することができるいくつかの技術が記載されています。しかし、バックチャネル上で受信機によって送信されたパケットの認証と完全性の検証、いずれの場合には、この文書の範囲外です。
IANA has registered the following attributes according to this document. The registries are provided by [RFC4442] under the "Timed Efficient Stream Loss-tolerant Authentication (TESLA) Parameters" registry [TESLA-REG]. Following the policies outlined in [RFC4442], the values in the range up to 240 (including 240) for the following 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.
IANAは、この文書によると、以下の属性を登録しています。レジストリは、「時限効率ストリーム損失トレラント認証（テスラ）パラメータ」レジストリ[TESLA-REG]の[RFC4442]で提供されます。 [RFC4442]に概説された方針に続いて、次の属性について（240を含む）240までの範囲内の値はMSECワーキンググループによる専門家のレビューやその指定された後継者の後に割り当てられています。 241から255の範囲の値は、私的使用のために予約されています。
Cryptographic Pseudo-Random Function, TESLA-PRF: All implementations MUST support HMAC-SHA-256 (default).
暗号擬似ランダム関数は、TESLA-PRF：すべての実装はHMAC-SHA-256（デフォルト）をサポートしなければなりません。
+------------------------+-------+
| PRF name | Value |
+------------------------+-------+
| HMAC-SHA1 | 0 |
| HMAC-SHA-224 | 1 |
| HMAC-SHA-256 (default) | 2 |
| HMAC-SHA-384 | 3 |
| HMAC-SHA-512 | 4 |
+------------------------+-------+
Cryptographic Message Authentication Code (MAC) Function, TESLA-MAC: All implementations MUST support HMAC-SHA-256 (default). These MAC schemes are used both for the computing of regular MAC and the Group MAC (if applicable).
暗号メッセージ認証コード（MAC）機能、TESLA-MAC：すべての実装はHMAC-SHA-256（デフォルト）をサポートしなければなりません。これらのMAC方式は、通常のMACおよびグループMAC（該当する場合）のコンピューティングの両方に使用されています。
+------------------------+-------+
| MAC name | Value |
+------------------------+-------+
| HMAC-SHA1 | 0 |
| HMAC-SHA-224 | 1 |
| HMAC-SHA-256 (default) | 2 |
| HMAC-SHA-384 | 3 |
| HMAC-SHA-512 | 4 |
+------------------------+-------+
Furthermore, IANA has created two new registries. Here also, the values in the range up to 240 (including 240) for the following 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.
さらに、IANAは、2つの新しいレジストリを作成しました。ここでまた、以下の属性のための（240を含む）240までの範囲内の値はMSECワーキンググループによる専門家のレビューやその指定された後継者の後に割り当てられています。 241から255の範囲の値は、私的使用のために予約されています。
Signature Encoding Algorithm, TESLA-SIG-ALGO: All implementations MUST support RSASSA-PKCS1-v1_5 (default).
署名符号化アルゴリズム、TESLA-SIG-ALGO：すべての実装はRSASSA-PKCS1-v1_5の（デフォルト）をサポートしなければなりません。
+-----------------------------+-------+
| Signature Algorithm Name | Value |
+-----------------------------+-------+
| INVALID | 0 |
| RSASSA-PKCS1-v1_5 (default) | 1 |
| RSASSA-PSS | 2 |
+-----------------------------+-------+
Signature Cryptographic Function, TESLA-SIG-CRYPTO-FUNC: All implementations MUST support SHA-256 (default).
署名暗号化機能、TESLA-SIG-CRYPTO-FUNC：すべての実装は、SHA-256（デフォルト）をサポートしなければなりません。
+-----------------------------+-------+
| Cryptographic Function Name | Value |
+-----------------------------+-------+
| INVALID | 0 |
| SHA-1 | 1 |
| SHA-224 | 2 |
| SHA-256 (default) | 3 |
| SHA-384 | 4 |
| SHA-512 | 5 |
+-----------------------------+-------+
The authors are grateful to Yaron Sheffer, Brian Weis, Ramu Panayappan, Ran Canetti, David L. Mills, Brian Adamson, and Lionel Giraud for their valuable comments while preparing this document. The authors are also grateful to Brian Weis for the digital signature details.
この文書を準備している間、著者は彼らの貴重なコメントをヤロンシェファー、ブライアン・ワイス、のRamu Panayappan、カネッティ蘭、デビッドL.ミルズ、ブライアン・アダムソン、とライオネル・ジローに感謝しています。著者らはまた、デジタル署名の詳細については、ブライアン・ワイスに感謝しています。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装"、RFC 1305、1992年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082] Perrig、A.、歌、D.、カネッティ、R.、Tygar、J.、およびB.ブリスコウ、 "時限効率ストリーム損失トレラント認証（テスラ）：マルチキャスト発信元認証は、はじめの変換"、RFC 4082、 2005年6月。
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, October 2009.
[RFC5651]ルビー、M.、ワトソン、M.、およびL. Vicisano、 "階層符号化トランスポート（LCT）ビルディングブロック"、RFC 5651、2009年10月。
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009.
[RFC5740]アダムソン、B.、ボルマン、C.、ハンドレー、M.、およびJ. Macker、 "NACK指向高信頼マルチキャスト（NORM）トランスポートプロトコル"、RFC 5740、2009年11月。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010.
[RFC5775]ルビー、M.、ワトソン、M.、およびL. Vicisano、RFC 5775 "非同期階層は（ALC）プロトコルインスタンス化コーディング"、2010年4月。
[TESLA-REG] "TESLA Parameters IANA Registry", http://www.iana.org.
[TESLA-REG] "TESLAパラメータIANAレジストリ"、http://www.iana.org。
[NTP-NTPv4] Burbank, J., Kasch, W., Martin, J., Ed., and D. Mills, "The Network Time Protocol Version 4 Protocol And Algorithm Specification", Work in Progress, October 2009.
[NTP-NTPv4]バーバンク、J.、Kasch、W.、マーティン、J.、エド。、およびD.ミルズ、 "ネットワークタイムプロトコルバージョン4プロトコルとアルゴリズムの仕様"、進歩、2009年10月に作業。
[Perrig04] Perrig, A. and J. Tygar, "Secure Broadcast Communication in Wired and Wireless Networks", Kluwer Academic Publishers ISBN 0-7923-7650-1, 2004.
[Perrig04] Perrig、A.とJ. Tygarは、Kluwerの学術出版社ISBN 0-7923-7650-1、2004年 "有線および無線ネットワークにおけるブロードキャスト通信をセキュア"。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]ジョンソン、J.とB. Kaliski、 "公開鍵暗号規格（PKCS）＃1：RSA暗号仕様バージョン2.1"、RFC 3447、2003年2月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330]ミルズ、D.、 "IPv4、IPv6、およびOSIのため簡易ネットワークタイムプロトコル（SNTP）バージョン4"、RFC 4330、2006年1月。
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
[RFC4359]ヴァイス、B.、RFC 4359、2006年1月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）内のRSA / SHA-1署名の使用"。
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006.
[RFC4383] Baugher、M.とE.カララ、RFC 4383、2006年2月「時限効率的なストリーム損失トレラントセキュアリアルタイム転送プロトコル（SRTP）での認証（TESLA）の使用」。
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)", RFC 4442, March 2006.
[RFC4442]フライドポテト、S.およびH. Tschofenig、 "ブートストラップ時限効率的なストリーム損失トレラント認証（TESLA）"、RFC 4442、2006年3月。
[RMT-FLUTE] Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca, "FLUTE - File Delivery over Unidirectional Transport", Work in Progress, August 2009.
[RMT-FLUTE] Paila、T.、ウォルシュ、R.、ルビー、M.、Lehtonenの、R.、およびV.ロカ、 "FLUTE - 単方向トランスポート上でファイル配信"、進歩、2009年8月に作業。
[RMT-SIMPLE-AUTH] Roca, V., "Simple Authentication Schemes for the ALC and NORM Protocols", Work in Progress, October 2009.
[RMT-SIMPLE-AUTH]ロカ、V.、 "ALCおよびNORMプロトコルのための簡単な認証スキーム"、進歩、2009年10月に作業。
Authors' Addresses
著者のアドレス
Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
INRIAヴィンセントロカ655、AV。ドゥヨーロッパInovallée。フランス38334 CEDEX MontbonnotセントIsmier
EMail: vincent.roca@inria.fr URI: http://planete.inrialpes.fr/~roca/
電子メール：vincent.roca@inria.fr URI：http://planete.inrialpes.fr/~roca/
Aurelien Francillon INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
オーレリアンFrancillon INRIA 655、AV。ドゥヨーロッパInovallée。フランス38334 CEDEX MontbonnotセントIsmier
EMail: aurelien.francillon@inria.fr URI: http://planete.inrialpes.fr/~francill/
電子メール：URI aurelien.francillon@inria.fr：http://planete.inrialpes.fr/~francill/
Sebastien Faurite INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
セバスチャンFisset INRIA 655、AV。ドゥヨーロッパInovallée。フランス38334 CEDEX MontbonnotセントIsmier
EMail: faurite@lcpc.fr
メールアドレス：faurite@lcpc.fr