[要約] RFC 5776は、Asynchronous Layered Coding（ALC）およびNACK-Oriented Reliable Multicast（NORM）プロトコルでのTimed Efficient Stream Loss-Tolerant Authentication（TESLA）の使用に関するものです。このRFCの目的は、ALCおよびNORMプロトコルでのデータの信頼性とセキュリティを向上させるために、TESLAを使用する方法を提案することです。
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
非同期層コーディング（ALC）およびNACK指向の信頼できるマルチキャスト（NORM）プロトコルでのタイミングの効率的なストリーム損失耐性認証（TESLA）の使用
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
マルチキャストおよびブロードキャスト通信の場合にソース認証とメッセージの整合性サービスを提供する通常のソリューションは、非対称の暗号化に依存し、デジタル署名を使用することで構成されています。しかし、このソリューションは、高い計算コストと高いトランスミッションオーバーヘッドによって制限されています。時限効率の高いストリーム損失耐性認証（TESLA）プロトコルは、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).
このドキュメントでは、TESLAソース認証とパケット整合性プロトコルをALCおよびNORM CDPに統合する方法について説明します。ALCおよびNORMの上に構築されたアプリケーションは、Teslaが輸送層で提供するサービスから直接恩恵を受けます。特に、これは単方向輸送（フルート）を介したファイル配信の場合です。
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プロトコルとその原則の詳細については、[RFC4082]および[Perrig04]を参照してください。ALCとNormの詳細については、それぞれ[RFC5775]、[RFC5651]、および[RFC5740]を参照してください。フルートの詳細については、[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);
o セッションの送信者の公開キーまたは証明書（セクション2.2.2）を安全に伝える。
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;
o 該当する場合（セクション3.3.3）、グループMac機能で使用されるグループキーK_Gを安全かつ秘密に通信するため。状況によっては、このグループキーを定期的に更新する必要があります。
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.
これらのメカニズムは、送信者と受信機でテスラをブートストラップするために必要であり、テスラと並行して展開する必要があります。また、キーチェーンの主キーのランダム性（セクション3.1.2）は、テスラのセキュリティにとって不可欠です。したがって、送信者は、このランダムキーを生成するために適切なメカニズムを必要とします。
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 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.
テスラのいくつかの技術的詳細は、キー開示の送信と新しいキーチェーンへのコミットメント、キー開示の送信と以前のキーチェーンの最後の鍵、または開示の間を交互に交互に交互に行う最も適切な方法のように、テスラのいくつかの技術的詳細キーとキーを開示しないコンパクトなフレーバーは、ターゲットユースケースに固有のものです（セクション3.1.2）。たとえば、時間間隔ごとに送信されるパケットの数、目的の堅牢性と許容可能な送信オーバーヘッドに依存します。これは、ユースケースの特異性を考慮した後にのみ最適化できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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はキーチェーンの長さです。キーチェーンにはn 1キーがあります：k_0、k_1、...、k_n。いくつかのチェーンを使用する場合、すべてのチェーンは同じ長さを持ち、キーは時間間隔番号に続いて連続して番号が付けられている必要があります。
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は共有グループキーであり、テスラのブートストラップ中にすべてのグループメンバーと秘密に伝えられます（セクション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は通常、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は、セッションの開始に対応する開始時間、つまり時間間隔0（NTPタイムスタンプ形式）の開始時間です。
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タイムスタンプ形式は、1900年1月1日の0Hに比べて秒で64ビットの符号なしの固定点数で構成されています。整数部は最初の32ビット、および最後の32ビットの分数部分[RFC1305]です。
The ALC and NORM protocols have features and requirements that largely impact the way TESLA can be used.
ALCおよびNORMプロトコルには、テスラの使用方法に大きな影響を与える機能と要件があります。
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);
o ALCは純粋に一方向の輸送チャネルの上で動作することができます。これはALCの資産の1つであり、単方向チャネルの例には衛星（一部のユースケースでバックチャネルが存在している場合でも）やデジタルビデオブロードキャストなどの放送ネットワークが含まれます。ハンドヘルドへの衛星サービス（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).
o ALCセッションは潜在的に非常に長いです。セッションは、カルーセル内でコンテンツが継続的に送信される数日または数ヶ月続く可能性があります。コンテンツは、静的（ソフトウェアの更新など）または動的（たとえば、Webサイト）のいずれかです。
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:
規範の場合：
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は中規模のセッション用に設計されています。実際、ノルムはフィードバックメッセージに依存しており、フィードバックメッセージレートが高すぎると送信者が崩壊する場合があります。
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には双方向輸送チャネルが必要です。1つのレシーバーによって送信される制御トラフィックは、下流トラフィックよりも1桁低いため、バックチャネルは必ずしも高データレートチャネルではありません。非対称接続性（例：高レートの衛星ダウンリンクと低レートのリターンチャネルなど）を備えたネットワークが適切です。
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の実装は、相互運用性の目的でバンド内メカニズムの使用をサポートすることをお勧めします。
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（Multimedia Internet Keying）プロトコルの使用について説明しています。副作用として、マイキーはテスラが利益を得ることができるゆるい時間同期機能も提供します。たとえば、これらのソリューションが必要なセキュリティレベルを提供することを条件に、拡張セッションの説明に基づいて他のソリューションが可能です。
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.
この仕様は、帯域内のメカニズムについて説明します。一部のユースケースでは、追加の外部メカニズムを使用することなくブートストラップが行われることが望まれる場合があります。たとえば、各デバイスは、テスラが必要とする時間の精度の前で無視できる既知の時間削減を備えた時計を備えており、各デバイスは送信者の公開鍵を埋め込むことができます。また、ユースケースは、Mikeyのような帯域外プロトコルの使用を防ぐ双方向チャネルを備えていない可能性もあります。これらの2つの例では、ブートストラップ情報メッセージの交換（セクション3.4.1で説明）といくつかの追加パラメーターの知識（以下にリスト）は、受信者でテスラをブートストラップするのに十分です。
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.
o NTP/SNTP（Simple Network Time Protocol）を使用して時間同期が実行される場合、送信者またはグループコントローラーは、有効なNTP/SNTPサーバーのリストをすべてのセッションメンバー（Senderを含む）に通信する必要があります。同じ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.
o グループMac機能を使用する場合、送信者またはグループコントローラーは、すべてのセッションメンバー（送信者を含む）に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:
テスラが提供するセキュリティは、時間通りに大きく依存しています。したがって、セッションの送信者と各レシーバーは、安全な方法で時間同期する必要があります。その目的のために、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:
この同期方法は、シンプルで安全です。しかし、2つの潜在的な問題があります。
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の問題になるとは予想されていません。しかし、このドキュメントの範囲外のメカニズムを使用して、送信者が崩壊する可能性のあるリスクがある場合、直接時間同期要求メッセージの送信を時間の経過とともに広めることが必要です。
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）バックチャネルがない可能性があり、（2）膨大な数の受信機が存在しないため、送信者が崩壊するリスクがあるため、直接時間同期はALCと潜在的に互換性がありません。
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]サーバーの階層を介して同期できます。各NTPメッセージを個別に認証するには、NTPV3の認証メカニズムを使用する必要があります。たとえば、攻撃者が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]サーバーの階層を介して同期することができます。各NTPメッセージを個別に認証するには、NTPV4のAutokeyセキュリティプロトコルを使用する必要があります。
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（Simple Network Time Protocol 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またはGalileo（または同様の）デバイスを介して同期することができます。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 各送信者と受信機に埋め込まれた専用のハードウェアのおかげで同期することができます。このハードウェアは、テスラの時間精度要件の前で無視できるタイムドリフトを時計に提供します。この機能により、デバイスは、埋め込みクロックを時々（極端な場合は製造時に一度）随時公式の時間参照と同期し、既知の最大クロックドリフトに依存する期間自律的なままにします。
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スキームを使用しても不可能です。もう1つの側面は、ALCのスケーラビリティ要件と、より低い範囲の規範です。この観点から見ると、上記のメカニズムは通常、直接時間同期スキームとは異なり、問題を引き起こしません。したがって、間接的な時間同期を使用することは良い選択です。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 受信者は、送信中のレシーバーの現地時間であるT_Rを含む直接時間同期要求メッセージを送信者に送信します（セクション4.2.2.1）。
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を記録し、T_R（リクエストから取得）とT_Sを含む直接時間同期応答を受信者に送信し、この返信に署名します（セクション3.4.2）。
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 -T_R S_SRを計算します。ここで、S_SRはセッション期間中、送信者と受信機の間のクロックドリフトの推定境界です。このドキュメントでは、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_r d_t。
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回の参照があると仮定しましょう。
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値はTime同期スキームの仕様の一部です。たとえば、NTPV3 [RFC1305]は、「一次基準ソースへの同期が失われた時期が長くなった後でも、ミリ秒の順に精度が可能」のアルゴリズムを定義します。実際には、NTPサーバーの層によっては、精度が少し悪化する可能性があります。その場合、d_t = security_factor *（1ms 1ms）。Security_Factorは、NTPの不正確さのいくつかのソースを補正することを目的としています。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（rep。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（Resp。GroupMac）のコンピューティングは、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プロトコルとその原則の詳細については、[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から始まり、連続して増加します。インターバルインデックスは、署名されていない32ビット整数に保存する必要があり、0にラッピングが2 ^^ 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は次のように定義される一方向関数です：f（k）= f_k（0）、ここで、f_k（0）はprf fをkと0に適用した結果です。セクション7）、kはキーとして使用され、[rfc2104]で説明されているアルゴリズムを使用して、メッセージとして使用されます。
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 'は次のように定義される一方向関数です：f'（k）= f_k（1）。ここで、f_k（1）は同じprf fをkと1の適用の結果です。
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_nを使用して、k_ {i-1} = f（k_i）を使用して、チェーンのすべてのキーを再帰的に計算します。したがって、k_i = f^{n-i}（k_n）。ここで、f^i（x）は、引数x、i timesの関数fの実行です。レシーバーは、中間値がない場合でも、K_Nからキーチェーン内の任意の値を計算できます[RFC4082]。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].
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で停止し、新しいキーチェーンはK_ {n 1}（つまり、F（k_ {n 1}）とK_Nが2つの異なるキーである（k_ {n 1}）で始まるとしましょう。次に、送信者は、古いキーチェーンで認証されたパケットに新しいキーチェーンにコミットメント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.
レシーバーは、間隔N 1 dでキーK_ {n 1}が開示されるまでコミットメントを維持します。次に、受信者は、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.
キーチェーンが変更されると、古いキーチェーンから以前のキーを回復することが不可能になります。これは、レシーバーが古いキーチェーンの最後のキーを開示するパケットを失った場合の問題です。ソリューションは、古いキーチェーンの最後のキーであるK_Nを再配置することで構成されています（セクション3.4.6を参照）。これは、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
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
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）で開示されません。その目的のために、送信者はキー開示なしで認証タグを使用します。セクション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、セッションの開始に対応する開始時間、つまり時間間隔0（NTPタイムスタンプ形式）;
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は、あまりにも多くの役に立たないキーを計算する必要があります。[RFC4082]のセクション3.2および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:
送信者で、テスラは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 ブートストラップ情報：帯域外または帯域内のいずれかを送信できます。後者の場合、デジタル署名されたパケットには、受信者でテスラをブートストラップするために必要なすべての情報が含まれています。
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 Bootstrap情報メッセージは、デジタルで署名する必要があります（セクション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またはノルムセッションで特に重要です。信頼性を向上させるために、ブートストラップ情報は一定数に送信される場合があります。
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は3種類のセキュリティタグを作成します。
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 2つの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;
o Interval Index、Iは、このパケットのMacの計算に使用されるキーのインデックスでもあります。
o the MAC of the message: MAC(K'_i, M), where K'_i=F'(K_i);
o メッセージのMac：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またはノルムヘッダー（さまざまなヘッダー拡張機能）とペイロード（該当する場合）を含める必要があります。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つのメッセージには、デジタル署名を保持する「署名」フィールドが含まれています。ブートストラップ情報メッセージには、「署名エンコードアルゴリズム」、「署名暗号化関数」、および受信者が「署名」フィールドを処理できるようにする「署名長」フィールドも含まれています。これらのパラメーターがすでに既知であると想定されているため、直接タイム同期応答メッセージの場合、そのような「署名エンコードアルゴリズム」、「署名暗号化関数」、および「署名長」フィールドはないことに注意してください（つまり、受信者はどちらかです。Bootstrap情報メッセージを以前に受け取ったか、これらの値が帯域外に伝えられています）。
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またはノルムヘッダー（さまざまなヘッダー拡張機能）とペイロードを含める必要があります。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]から：[RFC3447]に記載されているデジタル署名生成は、RSASSA-PKCS1-V1_5のセクション8.2.1、RSASSA-PSSのセクション8.1.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.
rsassa-pkcs1-v1_5およびrsassa-pss署名を使用すると、「RSAモジュラス」が8ビットの倍数ではない場合を除き、署名のサイズは「RSAモジュラス」に等しくなります。その場合、署名は1〜7ビットがゼロに設定されているため、署名が8ビットの倍数になるように準備する必要があります[RFC4359]。実際には「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は、グループメンバーではない攻撃者からのサービス拒否（DOS）攻撃を緩和するために使用できます[RFC4082]。この機能は、グループキーであるK_Gが送信者とすべてのレシーバーによって共有されることを前提としています。攻撃者がグループメンバーではない場合、送信されるすべてのパケットにグループMacを追加する利点は3つあります。
o a receiver can immediately drop faked packets, without having to wait for the disclosure delay, d;
o 受信者は、開示遅延を待つことなく、すぐに偽造パケットをドロップできます。
o a sender can immediately drop faked direct time synchronization requests, and avoid checking the digital signature, a computation intensive task;
o 送信者は、Faked Direct Time同期リクエストをすぐにドロップし、計算集中タスクであるデジタル署名のチェックを避けることができます。
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 受信者は、計算集約型タスクであるデジタル署名を確認することなく、Faked Direct Time同期応答とブートストラップメッセージをすぐにドロップできます。
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の計算自体に含まれているため計算されます。次に、送信者はMAC出力を切り捨ててN_Wを最も重要なビットに保ち、結果を「グループ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メッセージは、ALCまたはNORMパケットのext_Authヘッダー拡張機能として実行されるため（セクション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」フラグは、このテスラセッションが単一のキーチェーン（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）かどうかを示します。使用すると、Tesla Ext_Authヘッダー拡張機能（このブートストラップメッセージを含む）を含むすべてのパケットに「グループMAC」フィールドが追加されます。
"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.
「a」フラグは、「p」フラグと「d^o_t」フィールドが存在するか（a == 1）かどうかを示します（a == 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タイプ」は、F（キーチェーンの場合）およびF '（Macキーの場合）関数（セクション7）を導出するために使用されるF関数の参照番号です。
"MAC Function Type" field (8 bits):
「Mac Function Type」フィールド（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の計算に使用される暗号化MAC関数の参照番号が含まれています（セクション7）。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.
「キーチェーンのコミットメント」は、現在のキーチェーン、つまり間隔iに対応するキーチェーンへのコミットメントです。たとえば、最初のキーチェーンでは、このコミットメントはf（k_0）に等しく、2番目のキーチェーンでは、このコミットメントはf（k_ {n 1}）などに等しくなります。必要に応じて、このフィールドは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).
「P」フラグはオプションであり、「A」フラグが1に等しい場合にのみ存在します。間接時間同期モードでのみ使用されます。このフラグは、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.
「d^o_t」フィールドはオプションであり、「a」フラグが1に等しい場合にのみ存在します。間接時間同期モードでのみ使用されます。これは、時間参照に関する送信者の時計の遅れの上限です。いくつかの時間参照が指定されている場合（例：いくつかの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が含まれています。ビット中のフィールドの長さは、N_Wによって与えられます。N_Wは、グループMAC関数タイプがわかっていると知られています（セクション7）。
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が含まれています。ビット中のフィールドの長さは、N_Wによって与えられます。N_Wは、グループMAC関数タイプがわかっていると知られています（セクション7）。
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」は、このパケットのMACを計算するために使用されるキー（K'_I）に関連付けられたインターバルインデックスです。
"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_ {i-D}キーを開示することが有利です。残りのパケット。K_ {I-D}キーを開示するパケットの数を決定するのは、実装者に任されています。重要な開示なしのこの認証タグは、最初の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：キー開示なしの認証タグの形式
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
図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.
開示間隔後の新しいキーチェーンの最初のN_TX_LASTKEY間隔では、DENDERは古いキーチェーンの最後のキーを開示する必要があります。これは、認証タグの開示されたキーを古いチェーンの最後のキーであるK_N（またはK_ {2N 1}に置き換えることによって行われます。図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
図7：古いチェーンを使用した認証タグの形式最後のキー開示
This section describes the TESLA operations at a receiver.
このセクションでは、受信機でのテスラ操作について説明します。
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:
このセクションでは、着信パケットの3つの可能な認証情報のそれぞれを検証するために必要な計算手順を詳しく説明します。検証は、厳密な順序に従う必要があります。
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またはノルムヘッダー（さまざまなヘッダー拡張機能）とペイロードを含める必要があります。UDP/IPヘッダーを含めてはなりません。この計算中、「署名」フィールドは、存在するときにオプションのグループMACと同様に0に設定する必要があります。
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]、[RFC3447]、セクション8.1.2（RSASSA-PSS）に記載されているように、デジタル署名検証が実行されます。受領すると、デジタル署名はSとして検証関数に渡されます。パケットの認証された部分はメッセージMとして使用され、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を再計算するには、「Mac」フィールドの値を保存し、このフィールドを0に設定し、送信者と同じ計算を行う必要があります（セクション3.3.1を参照）。
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）。帯域内のメカニズムに焦点を当てましょう。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を参照）、受信機はTeslaコンポーネントを初期化できます。レシーバーは、次のブートストラップ情報メッセージを無視する必要があります。例外があります。ただし、新しいキーチェーンが使用され、受信者がこの新しいキーチェーンのすべてのコミットメントを逃した場合、このレシーバーは将来のブートストラップ情報メッセージのいずれかを処理する必要があります。この新しいキーチェーンに関連付けられた着信パケット。
Before TESLA has been initialized, a receiver MUST discard incoming packets other than the bootstrap information message and direct time synchronization response.
テスラが初期化される前に、受信者はブートストラップ情報メッセージと直接時間同期応答以外の着信パケットを破棄する必要があります。
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が含まれています。ビット中のフィールドの長さは、N_Wによって与えられます。N_Wは、グループMAC関数タイプがわかっていると知られています（セクション7）。
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サーバーのオプションの証明書とともに、信頼するNTPサーバーのURLまたはIPアドレスを帯域外に提供する場合があります。いくつかの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サーバーの間の時間オフセットを計算します。レシーバーは現地時間を更新する必要がないことに注意してください（多くの場合、ルート特権が必要です）、時間オフセットを計算するだけで十分です。
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).
このシナリオでは、各クライアントが送信者を信頼し、提案された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_j = t d_t。レシーバーは、送信者がhight_i = floor（（t_j -t_0） / t_int）にある可能性がある最高の間隔を計算します。また、認証タグから「i」間隔インデックスを取得します。レシーバーは、「安全なパケット」テストを進めることができます。hist_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.
* 新しいキーインデックステスト：レシーバーは、同じインデックス（つまり、I-D）で正当なキーが既に存在するかどうかを確認します。そのような正当なキーが存在する場合、受信者はその値を現在の開示キーと比較し、それらが同一である場合、「未検証のキーテスト」と「キー検証テスト」をスキップします。そのような正当なキーが存在するが、値が異なる場合、受信者はパケットを破棄する必要があります。
* 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.
* 未検証のキーテスト：開示されたキーインデックスが新しくなった場合、このキーチェーンに以前の開示された正当なキーが存在しないため、開示されたキーの検証を妨げる可能性があります。これは、開示されたキーが古いキーチェーンに属し、この古いキーチェーンへのコミットメントがこれまでに受け取られていない場合に発生します（たとえば、Latecomerが受け取った最初のブートストラップパケットは現在のキーチェーンのためであり、したがって、現在のキーチェーンではなく、以前のキーチェーンではありません）。これが発生した場合、受信者は開示されたキー（とにかく役に立たない）を無視し、キー検証テストをスキップする必要があります。
* 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 <i-dを使用）について、K_Vとfを検証することにより、k_ {i-d}の正当性をチェックします。^{i-d-v}（k_ {i-d}）は同一です。言い換えれば、受信者は、必要な数の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]。この機能が潜在的なDOS攻撃につながる場合（攻撃者は、パケット損失をシミュレートするために間違ったシーケンス番号を備えた偽のパケットを送信できます）、テスラが提供するセキュリティ機能を損なうことはなく、実際の渋滞の問題の前で迅速な反応を可能にします。
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.
6. その後、受信機は、後の認証のためにパケットをバッファリングします。対応するキーが開示され（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を、これまでのところレシーバーが知っている正当なキーの最小インデックスとします。V <W <= i-Dを使用したすべての新しいキーK_Wについて、このパケット（つまり、k_ {i-d}）によって開示されているか、k_ {i-d}（つまり、間隔のキー{v 1、..i-d-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を使用するレシーバーはすぐに安全でないパケットをドロップする必要があります。しかし、受信者は、テスラ拡張を無視して、安全でない（不安定な）モードで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.
上記の2つのテストのいずれかが成功した場合、送信者は、それらを認証する方法がないため、すべての待機中のパケットを破棄できます。
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：テスラ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):
「タイプ」フィールド（4ビット）：
The "Type" field identifies the type of TESLA information carried in this header extension. This specification defines the following types:
「タイプ」フィールドは、このヘッダー拡張機能で運ばれるテスラ情報のタイプを識別します。この仕様では、次のタイプを定義します。
* 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.
これは、ヘッダーエクステンションで運ばれるテスラ情報であり、そのタイプは「タイプ」フィールドで与えられます。
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 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（type == 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
図10：例：SHA-256/1024ビット署名、デフォルトのHMAC-SHA-256、およびグループMACを使用したブートストラップ情報メッセージ（タイプ0）の形式
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は、SHA-256/128バイト（1024ビット）のキーデジタル署名（これも意味する、PRF、Mac、およびグループMAC関数にHMAC-SHA-256変換を使用する場合のブートストラップ情報メッセージを示しています（これも意味します。「署名」フィールドの長さは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.
たとえば、図11と12は、PRFおよびMAC関数に（デフォルト）HMAC-SHA-256変換を使用する場合、K_ {I-D}キー開示の有無にかかわらず、それぞれ認証タグの形式を示しています。これらの例では、グループMAC機能は使用されていません。
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（Type == 7）は、NORM_CMD（アプリケーション）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はセッションの送信者からレシーバーまで、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）。
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（Type == 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]は、一般的にテスラのセキュリティについて説明しています。これらの考慮事項は、現在の仕様、つまり：
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.
o 着信パケットとデータを使用するアプリケーションを認証する検証剤が2つの異なるコンポーネントである場合、これらのコンポーネントの間にある攻撃者が偽造データを注入するリスクがあります。同様に、検証剤と安全なタイミングシステムが2つの異なるコンポーネントである場合、これらのコンポーネントの間にある攻撃者が偽造されたタイミング情報を注入するリスクがあります。たとえば、検証者が専用のシステムコール（GetTimeOf（）など）によって現地時間を読み取ると、攻撃者がホストを制御する場合、システムコールをキャッチして偽造時間情報を返すことがあります。
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).
テスラは、攻撃者がDOS攻撃をマウントするための新しい機会を紹介します。たとえば、攻撃者は受信機の処理機能を飽和させようとすることができます（偽造パケットは簡単に作成できますが、それらをチェックするには、パケットを介してMacを計算したり、ブートストラップと直接のタイム同期応答メッセージと同様にデジタル署名をチェックする必要があります）。また、攻撃者は受信機のメモリを飽和させることもできます（認証が遅れ、認証されていないパケットが蓄積されるため）、または受信者に混雑が発生したと信じさせることもできます（come渋面パケットを認証する前に輻輳制御を実行する必要があるため、セクション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:
攻撃者が有効なメッセージを保存して後でリプレイするリプレイ攻撃は、メッセージタイプに応じて、大きな影響を与える可能性があります。2つのレベルの影響を区別する必要があります。
o within the TESLA protocol, and
o テスラプロトコル内、および
o within the ALC or NORM protocol.
o ALCまたはNORMプロトコル内。
Replay attacks can impact the TESLA component itself. We review here the potential impacts of such an attack depending on the TESLA message type:
リプレイ攻撃は、テスラコンポーネント自体に影響を与える可能性があります。ここでは、テスラメッセージタイプに応じて、このような攻撃の潜在的な影響をレビューします。
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.
o 直接時間同期リクエスト：グループMACスキームが使用されている場合、グループのメンバーではない攻撃者はパケットを再生し、送信者に応答することを義務付けます。グループMACスキームが使用されていない場合、攻撃者はとにかくリクエストを簡単に偽造できます。どちらの場合も、攻撃はテスラコンポーネントを妥協するものではなく、DOSを作成する可能性があります。これが懸念事項である場合、グループMACスキームを使用する場合、送信者はリクエストに含まれる「T_R」NTPタイムスタンプを確認し、この値がこのレシーバーから受け取った値よりも厳密に大きい場合にのみ応答することが推奨されます。Group Macスキームを使用しない場合、この攻撃は、処理される1秒あたりのリクエスト数を制限することで軽減できます。
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).
o 認証タグを含むその他のメッセージ：Tesla認証タグを含むパケットをリプレイすることは、Teslaコンポーネント自体を妥協することはありません（ただし、おそらく基礎となるALCまたはNORMコンポーネントは以下を参照）。
To conclude, TESLA itself is robust in front of replay attacks.
結論として、テスラ自体はリプレイ攻撃の前で堅牢です。
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とともに使用できるプロトコルをここでは考慮していないことに注意してください。
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]から保護するために使用できる「シーケンス」フィールドを定義します。この「シーケンス」フィールドは、送信された各ノルムメッセージで単調に増加する数を単調に増加させるために、メッセージオリジナル（送信者または受信機）によって設定される16ビット値です。レシーバーは、この「シーケンス」フィールドと再生されたと見なされるメッセージをドロップするメッセージをチェックすることをお勧めします。同様に、送信者がこのシーケンスを各既知のレシーバーに対してチェックし、再生されたと見なされるメッセージをドロップすることをお勧めします。どちらの場合も、パケットのテスラ処理の前にこの「シーケンス」フィールドを確認する必要があります。「シーケンス」フィールドが破損していない場合、リプレイ攻撃はすぐに識別されます。それ以外の場合、パケットは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は、さまざまなセッションでリプレイ攻撃の前で堅牢です。
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は、このドキュメントに従って次の属性を登録しています。レジストリは、[RFC4442]によって「タイミングの効率的なストリーム損失耐性認証（TESLA）パラメーター」レジストリ[Tesla-Reg]の下で提供されます。[RFC4442]で概説されているポリシーに続いて、MSECワーキンググループまたはその指定後継者による専門家のレビューの後に、次の属性の最大240（240を含む）の範囲の値が割り当てられます。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とGroup 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つの新しいレジストリを作成しました。ここでも、MSECワーキンググループまたはその指定された後継者による専門家のレビューの後に、次の属性の最大240（240を含む）の範囲の値が割り当てられます。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.
著者は、この文書を準備しながら貴重なコメントをしてくれたヤロン・シェファー、ブライアン・ワイス、ラム・パナヤッパン、ラン・カネッティ、デビッド・L・ミルズ、ブライアン・アダムソン、ライオネル・ジローに感謝しています。著者は、デジタル署名の詳細についてもブライアン・ワイスに感謝しています。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305] Mills、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Song、D.、Canetti、R.、Tygar、J。、およびB. Briscoe、「タイミング効率の高いストリーム損失耐性認証（TESLA）：マルチキャストソース認証変換導入」、RFC 4082、2005年6月。
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, October 2009.
[RFC5651] Luby、M.、Watson、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] Adamson、B.、Bormann、C.、Handley、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] Luby、M.、Watson、M。、およびL. Vicisano、「非同期層コーディング（ALC）プロトコルインスタンス化」、RFC 5775、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] Burbank、J.、Kasch、W.、Martin、J.、Ed。、およびD. Mills、「ネットワークタイムプロトコルバージョン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 Academic Publishers 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.、Bellare、M。、およびR. CaNetti、「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] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（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] Mills、D。、「IPv4、IPv6およびOSI用のSimple Network Time Protocol（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] Weis、B。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）のカプセル化内でのRSA/SHA-1シグネチャの使用」、RFC 4359、2006年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. Carrara、「安全なリアルタイム輸送プロトコル（SRTP）でのタイミングの効率的なストリーム損失耐性認証（TESLA）の使用」、RFC 4383、2006年2月。
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)", RFC 4442, March 2006.
[RFC4442] Fries、S。and 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.、Walsh、R.、Luby、M.、Lehtonen、R.、およびV. Roca、「フルート - 単方向輸送を介したファイル配信」、2009年8月の作業。
[RMT-SIMPLE-AUTH] Roca, V., "Simple Authentication Schemes for the ALC and NORM Protocols", Work in Progress, October 2009.
[RMT-Simple-Auth] Roca、V。、「ALCおよびNORMプロトコルの単純な認証スキーム」、2009年10月、進行中の作業。
Authors' Addresses
著者のアドレス
Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
Vincent Roca Inria 655、av。de l'uepore inovallee;Montbonnot St Ismier Cedex 38334フランス
EMail: 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
Aurelien Francillon Inria 655、av。de l'uepore inovallee;Montbonnot St Ismier Cedex 38334フランス
EMail: aurelien.francillon@inria.fr
URI: http://planete.inrialpes.fr/~francill/
Sebastien Faurite INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
Sebastien Faurite Inria 655、av。de l'uepore inovallee;Montbonnot St Ismier Cedex 38334フランス
EMail: faurite@lcpc.fr