[要約] RFC 6584は、ALCおよびNORMプロトコルのための簡単な認証スキームについての要約です。このRFCの目的は、これらのプロトコルのセキュリティを向上させるために、効果的な認証手法を提供することです。
Internet Engineering Task Force (IETF) V. Roca
Request for Comments: 6584 INRIA
Category: Standards Track April 2012
ISSN: 2070-1721
Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
非同期レイヤードコーディング（ALC）およびNACK指向の信頼性の高いマルチキャスト（NORM）プロトコル用の単純な認証スキーム
Abstract
概要
This document introduces four schemes that provide per-packet authentication, integrity, and anti-replay services in the context of the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) protocols. The first scheme is based on RSA Digital Signatures. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). The third scheme relies on a Group-keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the Digital Signature and group schemes. These schemes have different target use cases, and they do not all provide the same service.
このドキュメントでは、非同期レイヤードコーディング（ALC）およびNACK指向の信頼性の高いマルチキャスト（NORM）プロトコルのコンテキストで、パケットごとの認証、整合性、およびアンチリプレイサービスを提供する4つのスキームを紹介します。最初のスキームは、RSAデジタル署名に基づいています。 2番目の方式は、楕円曲線デジタル署名アルゴリズム（ECDSA）に依存しています。 3番目のスキームは、グループキー付きメッセージ認証コード（MAC）に依存しています。最後に、4番目のスキームは、デジタル署名とグループスキームをマージします。これらのスキームはターゲットのユースケースが異なり、すべてが同じサービスを提供するわけではありません。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6584.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6584で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Scope of This Document .....................................6
1.2. Terminology, Notations, and Definitions ....................6
2. Authentication Scheme Identification with the ASID Field ........7
3. RSA Digital Signature Scheme ....................................8
3.1. Authentication Header Extension Format .....................8
3.2. Parameters ................................................10
3.3. Processing ................................................11
3.3.1. Signature Processing ...............................11
3.3.2. Anti-Replay Processing .............................12
3.4. In Practice ...............................................13
4. Elliptic Curve Digital Signature Scheme ........................14
4.1. Authentication Header Extension Format ....................14
4.2. Parameters ................................................15
4.3. Processing ................................................15
4.3.1. Signature Processing ...............................15
4.3.2. Anti-Replay Processing .............................16
4.4. In Practice ...............................................16
5. Group-Keyed Message Authentication Code (MAC) Scheme ...........17
5.1. Authentication Header Extension Format ....................17
5.2. Parameters ................................................19
5.3. Processing ................................................20
5.3.1. Signature Processing ...............................20
5.3.2. Anti-Replay Processing .............................20
5.4. In Practice ...............................................20
6. Combined Use of the RSA/ECC Digital Signatures and
Group-Keyed MAC Schemes ........................................21
6.1. Authentication Header Extension Format ....................21
6.2. Parameters ................................................23
6.3. Processing ................................................23
6.3.1. Signature Processing ...............................23
6.3.2. Anti-Replay Processing .............................24
6.4. In Practice ...............................................24
7. Security Considerations ........................................25
7.1. Dealing with DoS Attacks ..................................25
7.2. Dealing with Replay Attacks ...............................26
7.2.1. Impacts of Replay Attacks on the Simple
Authentication Schemes .............................26
7.2.2. Impacts of Replay Attacks on NORM ..................26
7.2.3. Impacts of Replay Attacks on ALC ...................27
7.3. Dealing with Attacks on the Parameters Sent Out-of-Band ...28
8. Acknowledgments ................................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................29
Many applications using multicast and broadcast communications require that each receiver be able to authenticate the source of any packet it receives, to check its integrity. For instance, ALC [RFC5775] and NORM [RFC5740] are two Content Delivery Protocols (CDPs) designed to reliably transfer objects (e.g., files) between a session's sender and several receivers.
マルチキャストおよびブロードキャスト通信を使用する多くのアプリケーションでは、各受信者が受信したパケットの送信元を認証して、その完全性を確認できる必要があります。たとえば、ALC [RFC5775]とNORM [RFC5740]は、セッションの送信者と複数の受信者の間でオブジェクト（ファイルなど）を確実に転送するように設計された2つのコンテンツ配信プロトコル（CDP）です。
The NORM protocol is based on bidirectional transmissions. With NORM, each receiver acknowledges data received or, in the case of packet erasures, asks for retransmissions. On the contrary, the ALC protocol defines unidirectional transmissions. With ALC, reliability can be achieved by means of cyclic transmissions of the content within a carousel, or by the use of proactive Forward Error Correction (FEC) codes, or by the joint use of these mechanisms. Being purely unidirectional, ALC is massively scalable, while NORM is intrinsically limited in terms of the number of receivers that can be handled in a session. 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.
NORMプロトコルは、双方向伝送に基づいています。 NORMを使用すると、各受信者は受信したデータを確認するか、パケット消去の場合は再送信を要求します。逆に、ALCプロトコルは単方向送信を定義します。 ALCを使用すると、カルーセル内のコンテンツの周期的送信、プロアクティブな前方誤り訂正（FEC）コードの使用、またはこれらのメカニズムの併用により、信頼性を実現できます。純粋に単方向であるため、ALCは非常にスケーラブルですが、NORMはセッションで処理できるレシーバーの数に関して本質的に制限されます。どちらのプロトコルも、送信中にパケットが失われる（消去される）消去チャネル（インターネットなど）の上のアプリケーションレベルで動作するという共通点があります。
With these CDPs, an attacker might impersonate the ALC or NORM session sender and inject forged packets to the receivers, thereby corrupting the objects reconstructed by the receivers. An attacker might also impersonate a NORM session receiver and inject forged feedback packets to the NORM sender.
これらのCDPを使用すると、攻撃者はALCまたはNORMセッションの送信者になりすまし、受信者に偽造パケットを注入し、それによって受信者によって再構築されたオブジェクトを破壊する可能性があります。攻撃者は、NORMセッションレシーバーになりすまして、偽造されたフィードバックパケットをNORMセンダーに注入する可能性もあります。
In the case of group communications, several solutions exist to provide the receiver some guaranties on the integrity of the packets it receives and on the identity of the sender of these packets. These solutions have different features that make them more or less suited to a given use case:
グループ通信の場合、受信者が受信するパケットの整合性とこれらのパケットの送信者のIDにいくつかの保証を提供するためにいくつかのソリューションが存在します。これらのソリューションにはさまざまな機能があり、特定のユースケースに多かれ少なかれ適しています。
o Digital Signatures [RFC4359] (see Sections 3 and 4 of this document): This scheme is well suited to low data rate flows, when a packet sender authentication and packet integrity service is needed. However, Digital Signatures based on RSA asymmetric cryptography are limited by high computational costs and high transmission overheads. The use of ECC (Elliptic Curve Cryptography) [RFC6090] significantly relaxes these constraints. For instance, the following key lengths provide equivalent security: a 1024-bit RSA key versus a 160-bit ECC key, or a 2048-bit RSA key versus a 224-bit ECC key. However, RSA puts more load on the signer but much less load on the verifier, whereas ECC puts more similar load on both; hence, with many verifiers, more CPU is consumed overall.
o デジタル署名[RFC4359]（このドキュメントのセクション3および4を参照）：このスキームは、パケット送信者認証およびパケット整合性サービスが必要な場合に、低データレートフローに適しています。ただし、RSA非対称暗号に基づくデジタル署名は、高い計算コストと高い伝送オーバーヘッドによって制限されます。 ECC（楕円曲線暗号）[RFC6090]を使用すると、これらの制約が大幅に緩和されます。たとえば、次のキーの長さは同等のセキュリティを提供します。1024ビットのRSAキーと160ビットのECCキー、または2048ビットのRSAキーと224ビットのECCキー。ただし、RSAは署名者により多くの負荷をかけますが、検証者にははるかに少ない負荷をかけますが、ECCは両方に同様の負荷をかけます。したがって、多くのベリファイアを使用すると、全体としてより多くのCPUが消費されます。
o Group-keyed Message Authentication Codes (MACs) (see Section 5): This scheme is well suited to high data rate flows, when transmission overheads must be minimized. However, this scheme cannot protect against attacks coming from inside the group, where a group member impersonates the sender and sends forged messages to other receivers.
o グループキー付きメッセージ認証コード（MAC）（セクション5を参照）：このスキームは、伝送オーバーヘッドを最小限に抑える必要がある場合に、高データレートフローに適しています。ただし、このスキームでは、グループのメンバーが送信者になりすまし、偽造されたメッセージを他の受信者に送信するグループ内からの攻撃を防ぐことはできません。
o TESLA (Timed Efficient Stream Loss-tolerant Authentication) [RFC4082] [RFC5776]: This scheme is well suited to high data rate flows, when transmission overheads must be minimized, and when a packet sender authentication and packet integrity service is needed. The price is an increased complexity -- in particular, the need to loosely synchronize the receivers and the sender -- as well as the need to wait for the key to be disclosed before being able to authenticate a packet (i.e., the authentication check is delayed).
o TESLA（Timed Efficient Stream Loss-tolerant Authentication）[RFC4082] [RFC5776]：このスキームは、伝送オーバーヘッドを最小限に抑える必要があり、パケット送信者認証とパケット整合性サービスが必要な場合に、高データレートフローに適しています。価格は複雑さが増します-特に、受信者と送信者を緩やかに同期する必要性-パケットを認証できるようになる前にキーが開示されるのを待つ必要性（つまり、認証チェックは遅延）。
The following table summarizes the pros and cons of each authentication/integrity scheme used at the application/transport level (where "-" means con, "0" means neutral, and "+" means pro):
次の表は、アプリケーション/トランスポートレベルで使用される各認証/整合性スキームの長所と短所をまとめたものです（「-」はconを意味し、「0」は中立を意味し、「+」はproを意味します）。
+-----------------+-------------+-------------+-------------+-------+
| | RSA Digital | ECC Digital | Group-Keyed | TESLA |
| | Signature | Signature | MAC | |
+-----------------+-------------+-------------+-------------+-------+
| Sender auth and | Yes | Yes | No (group | Yes |
| packet | | | security) | |
| integrity | | | | |
| Non-delayed | Yes | Yes | Yes | No |
| authentication | | | | |
| Anti-replay | Opt | Opt | Opt | No |
| protection | | | | |
| Processing load | - | sender: -, | + | + |
| | | recv: 0 | | |
| Transmission | - | 0 | + | + |
| overhead | | | | |
| Complexity | + | + | + | - |
+-----------------+-------------+-------------+-------------+-------+
Several authentication schemes MAY be used in the same ALC or NORM session, even on the same communication path. This is made possible through a dedicated identifier, the "ASID" (Authentication Scheme IDentifier), that is present in each HET=1 (EXT_AUTH) header extension and that tells a receiver how to interpret this HET=1 header extension. This is discussed in Section 2.
同じ通信パス上であっても、いくつかの認証スキームが同じALCまたはNORMセッションで使用される場合があります。これは、各HET = 1（EXT_AUTH）ヘッダー拡張に存在し、このHET = 1ヘッダー拡張を解釈する方法を受信者に通知する専用の識別子、「ASID」（認証方式IDentifier）によって可能になります。これについては、セクション2で説明します。
All the applications built on top of ALC and NORM directly benefit from the source authentication and packet integrity services defined in this document. For instance, this is the case of the File Delivery over Unidirectional Transport (FLUTE) application [RMT-FLUTE], which is built on top of ALC.
ALCおよびNORMの上に構築されたすべてのアプリケーションは、このドキュメントで定義されているソース認証およびパケット整合性サービスから直接恩恵を受けます。たとえば、これはALCの上に構築された一方向トランスポート経由のファイル配信（FLUTE）アプリケーション[RMT-FLUTE]の場合です。
The current specification assumes that several parameters (like keying material) are communicated out-of-band, sometimes securely, between the sender and the receivers. This is detailed in Sections 3.2, 4.2, 5.2, and 6.2.
現在の仕様では、送信者と受信者の間で、いくつかのパラメータ（キー情報など）が帯域外で、場合によっては安全に通信されることを前提としています。これについては、セクション3.2、4.2、5.2、および6.2で詳しく説明しています。
[RFC5776] explains how to use TESLA in the context of the ALC and NORM protocols.
[RFC5776]は、ALSおよびNORMプロトコルのコンテキストでTESLAを使用する方法を説明しています。
The current document specifies the use of the Digital Signature based on RSA asymmetric cryptography, the Elliptic Curve Digital Signature Algorithm (ECDSA), and Group-keyed MAC schemes. The current document also specifies the joint use of Digital Signature and Group-keyed MAC schemes.
現在のドキュメントでは、RSA非対称暗号化、楕円曲線デジタル署名アルゴリズム（ECDSA）、およびグループキー付きMACスキームに基づくデジタル署名の使用を指定しています。現在のドキュメントでは、デジタル署名とグループキー付きMACスキームの併用についても規定しています。
Unlike the TESLA scheme, this specification considers the authentication/integrity of the packets generated by the session's sender as well as those generated by the receivers (NORM).
TESLAスキームとは異なり、この仕様では、セッションの送信者によって生成されたパケットと、受信者によって生成されたパケット（NORM）の認証/整合性が考慮されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The following notations and definitions are used throughout this document:
このドキュメントでは、次の表記と定義が使用されています。
o MAC is the Message Authentication Code;
o MACはメッセージ認証コードです。
o HMAC is the Keyed-Hash Message Authentication Code;
o HMACはキー付きハッシュメッセージ認証コードです。
o "sender" denotes the sender of a packet that needs the authentication/integrity check service. It can be an ALC or NORM session sender, or a NORM session receiver in the case of feedback traffic;
o 「送信者」は、認証/完全性チェックサービスを必要とするパケットの送信者を示します。 ALCまたはNORMセッションの送信側、またはフィードバックトラフィックの場合はNORMセッションの受信側になります。
o "receiver" denotes the receiver of a packet that needs the authentication/integrity check service. It can be an ALC or NORM session receiver, or a NORM session sender in the case of feedback traffic;
o 「レシーバー」は、認証/完全性チェックサービスを必要とするパケットのレシーバーを示します。 ALCまたはNORMセッションレシーバー、またはフィードバックトラフィックの場合はNORMセッションセンダーになります。
o "ASID" is the Authentication Scheme IDentifier.
o 「ASID」は認証方式識別子です。
Key definitions for Digital Signatures are as follows:
デジタル署名の主な定義は次のとおりです。
o The public key is used by a receiver to check a packet's signature. This key MUST be communicated to all receivers before starting the session;
o 公開鍵は、パケットの署名をチェックするために受信者によって使用されます。このキーは、セッションを開始する前にすべての受信者に伝達されなければなりません。
o The private key is used by a sender to generate a packet's signature;
o 秘密鍵は、送信者がパケットの署名を生成するために使用します。
o The private key and public key length are expressed in bits. For security considerations [RFC5751], when using RSA, RSASSA-PSS, and Digital Signature Algorithm (DSA) signatures, key sizes of length strictly inferior to 1024 bits SHOULD NOT be used. Key sizes of length between 1024 and 2048 bits inclusive SHOULD be used. Key sizes of length strictly superior to 2048 bits MAY be used.
o 秘密鍵と公開鍵の長さはビットで表されます。セキュリティに関する考慮事項[RFC5751]で、RSA、RSASSA-PSS、およびデジタル署名アルゴリズム（DSA）署名を使用する場合、1024ビットよりも厳密に短い長さのキーサイズは使用しないでください。 1024〜2048ビットの長さの鍵サイズを使用する必要があります（SHOULD）。 2048ビットを厳密に超える長さの鍵サイズを使用できます。
Key definitions for Group-keyed MAC are as follows:
Group-keyed MACの主な定義は次のとおりです。
o The shared group key is used by the senders and the receivers. This key MUST be communicated to all group members, confidentially, before starting the session;
o 共有グループキーは、送信者と受信者が使用します。このキーは、セッションを開始する前に、すべてのグループメンバーに機密情報として伝えなければなりません。
o The group key length is expressed in bits;
o グループキーの長さはビットで表されます。
o n_m is the length of the truncated output of the MAC [RFC2104]. Only the n_m leftmost bits (most significant bits) of the MAC output are kept.
o n_mは、MAC [RFC2104]の切り捨てられた出力の長さです。 MAC出力の左端のn_mビット（最上位ビット）のみが保持されます。
As mentioned in Section 1, several authentication schemes MAY be used in the same ALC or NORM session, even on the same communication path (i.e., from a sender to a receiver, or vice versa). All the schemes mentioned in Section 1 (some of which are specified in this document) use the same HET=1 (EXT_AUTH) Authentication Header extension mechanism defined in [RFC5651]. Therefore, the same 4-bit ASID field has been reserved in all the specifications (see Sections 3.1, 4.1, 5.1, and 6.1, as well as Section 5.1 of [RFC5776]). For a given ALC or NORM session, the ASID value contained in an incoming packet enables a receiver to differentiate the actual use and format of the contents of the HET=1 (EXT_AUTH) header extension.
セクション1で述べたように、同じ通信パス（送信者から受信者へ、またはその逆）でも、同じALCまたはNORMセッションでいくつかの認証方式を使用できます（MAY）。セクション1で言及されているすべてのスキーム（その一部はこのドキュメントで指定されています）は、[RFC5651]で定義されている同じHET = 1（EXT_AUTH）認証ヘッダー拡張メカニズムを使用します。したがって、同じ4ビットのASIDフィールドがすべての仕様で予約されています（セクション3.1、4.1、5.1、6.1、および[RFC5776]のセクション5.1を参照）。特定のALCまたはNORMセッションでは、着信パケットに含まれるASID値により、受信者はHET = 1（EXT_AUTH）ヘッダー拡張の内容の実際の使用とフォーマットを区別できます。
The association between the ASID value and the actual authentication scheme of a given ALC or NORM session is defined at session startup and communicated to all the session members by an out-of-band mechanism. This association is per ALC or NORM session, and different sessions MAY reuse the same ASID values for different authentication schemes.
ASID値と特定のALCまたはNORMセッションの実際の認証方式との関連付けは、セッションの起動時に定義され、アウトオブバンドメカニズムによってすべてのセッションメンバーに伝達されます。この関連付けはALCまたはNORMセッションごとであり、異なるセッションが異なる認証スキームに同じASID値を再利用する場合があります。
With ALC, the ASID value is scoped by the {sender IP address; Transport Session Identifier (TSI)} tuple [RFC5651] that fully identifies an ALC session. Since [RFC5651] requires that "the TSI MUST be unique among all sessions served by the sender during the period when the session is active, and for a large period of time preceding and following when the session is active", there is no risk of confusion between different sessions. This is in line with Section 7.2.3.
ALCでは、ASID値のスコープは{送信者IPアドレスです。トランスポートセッション識別子（TSI）} ALCセッションを完全に識別するタプル[RFC5651]。 [RFC5651]は、「TSIは、セッションがアクティブな期間中に送信者がサービスするすべてのセッション間で一意である必要があり、セッションがアクティブなときに前後の長い期間にわたって」、リスクがないことを要求します。異なるセッション間の混乱。これはセクション7.2.3に沿っています。
With NORM, there is no session identifier within NORM packets. Therefore, depending on whether an Any Source Multicast (ASM) or Source Specific Multicast (SSM) group communication is used, the ASID value is scoped either by the {destination multicast address; destination port number} or {source IP address; destination multicast address; destination port number} tuple that fully identifies a NORM session [RFC5740]. Care should be taken that the above tuples remain unique, within a given scope and for a sufficient period of time preceding, during, and following when the session is active, to avoid confusion between different sessions. However, this is a recommendation for NORM sessions, rather than something specific to an authentication scheme. Note also that the ASID value is not scoped by the {source_id; instance_id} tuple, which uniquely identifies a host's participation in a NORM session, rather than the session itself (Section 7.2.2).
NORMでは、NORMパケット内にセッションIDはありません。したがって、Any Source Multicast（ASM）またはSource Specific Multicast（SSM）グループ通信のどちらを使用するかに応じて、ASID値は{destination multicast address;宛先ポート番号}または{送信元IPアドレス;宛先マルチキャストアドレス。宛先ポート番号} NORMセッションを完全に識別するタプル[RFC5740]。異なるセッション間の混乱を避けるために、上記のタプルは、特定のスコープ内で、セッションがアクティブなときの前後、十分な時間、一意であるように注意する必要があります。ただし、これは認証スキームに固有のものではなく、NORMセッションの推奨事項です。また、ASID値のスコープは{source_id;ではありません。 instance_id}タプル。これは、セッション自体ではなく、NORMセッションへのホストの参加を一意に識別します（セクション7.2.2）。
In any case, because this ASID field is 4 bits long, there is a maximum of 16 authentication schemes per ALC or NORM session.
いずれの場合も、このASIDフィールドは4ビット長であるため、ALCまたはNORMセッションごとに最大16の認証方式があります。
The integration of Digital Signatures is similar in ALC and NORM and relies on the header extension mechanism defined in both protocols. More precisely, this document details the HET=1 (EXT_AUTH) header extension defined in [RFC5651].
デジタル署名の統合はALCとNORMで類似しており、両方のプロトコルで定義されているヘッダー拡張メカニズムに依存しています。より正確には、このドキュメントは、[RFC5651]で定義されているHET = 1（EXT_AUTH）ヘッダー拡張について詳しく説明します。
Several fields are added, in addition to the HET (Header Extension Type) and HEL (Header Extension Length) fields (Figure 1).
HET（Header Extension Type）およびHEL（Header Extension Length）フィールドに加えて、いくつかのフィールドが追加されます（図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 | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+ +
~ anti-replay Sequence Number (SN) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Signature |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the Digital Signature EXT_AUTH Header Extension
図1：デジタル署名EXT_AUTHヘッダー拡張の形式
The fields of the Digital Signature EXT_AUTH header extension are as follows:
デジタル署名EXT_AUTHヘッダー拡張のフィールドは次のとおりです。
ASID (4 bits):
ACID（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値と実際の認証方式の間の関連付けは、セッション開始時に帯域外で定義されます。
rsvd (Reserved) (3 bits):
rsvd（予約済み）（3ビット）：
This is a reserved field that MUST be set to zero and ignored by receivers.
これは予約済みフィールドで、ゼロに設定する必要があり、受信者は無視する必要があります。
AR (anti-replay) (1 bit):
AR（アンチリプレイ）（1ビット）：
The AR field, when set to 0, indicates that the anti-replay service is not used. When set to 1, it indicates that the anti-replay service is used.
ARフィールドは、0に設定されている場合、アンチリプレイサービスが使用されていないことを示します。 1に設定されている場合、アンチリプレイサービスが使用されていることを示します。
SN (Sequence Number) (8 or 40 bits):
SN（シーケンス番号）（8または40ビット）：
The SN field contains an optional Sequence Number. When AR = 0, this is an 8-bit field that MUST be set to zero. No anti-replay mechanism is used in that case. When AR = 1, this is a 40-bit field (32 bits + 8 bits), and all of the 40 bits MUST be considered by the anti-replay mechanism.
SNフィールドには、オプションのシーケンス番号が含まれます。 AR = 0の場合、これはゼロに設定する必要がある8ビットのフィールドです。その場合、アンチリプレイメカニズムは使用されません。 AR = 1の場合、これは40ビットのフィールド（32ビット+ 8ビット）であり、40ビットのすべてをアンチリプレイメカニズムで考慮する必要があります。
Signature (variable size, multiple of 32 bits):
署名（可変サイズ、32ビットの倍数）：
The Signature field contains a Digital Signature of the message. If need be, this field is padded (with 0) up to a multiple of 32 bits.
[署名]フィールドには、メッセージのデジタル署名が含まれます。必要に応じて、このフィールドは32ビットの倍数まで（0で）パディングされます。
Several parameters MUST be initialized by an out-of-band mechanism. The sender or group controller
いくつかのパラメータは、帯域外メカニズムによって初期化する必要があります。送信者またはグループのコントローラー
o MUST communicate its public key, for each receiver to be able to verify the signature of the packets received. For security reasons [RFC5751], the use of key sizes between 1024 and 2048 bits inclusive is RECOMMENDED. Key sizes inferior to 1024 bits SHOULD NOT be used. Key sizes above 2048 bits MAY be used. As a side effect, the receivers also know the key length and the signature length, the two parameters being equal;
o 各受信者が受信したパケットの署名を検証できるように、公開鍵を通信する必要があります。セキュリティ上の理由から[RFC5751]、1024〜2048ビットのキーサイズを使用することをお勧めします。 1024ビットよりも小さい鍵サイズは使用しないでください。 2048ビットを超える鍵サイズを使用できます。副作用として、受信者はキーの長さと署名の長さも知っており、2つのパラメータは同じです。
o MAY communicate a certificate (which also means that a PKI has been set up), for each receiver to be able to check the sender's public key;
o 各受信者が送信者の公開鍵を確認できるように、証明書（PKIが設定されていることも意味する）を通信する場合があります。
o MUST communicate the signature-encoding algorithm. For instance, [RFC3447] defines the RSASSA-PKCS1-v1_5 and RSASSA-PSS algorithms that are usually used for that purpose;
o 署名エンコーディングアルゴリズムを通信する必要があります。たとえば、[RFC3447]は、通常その目的で使用されるRSASSA-PKCS1-v1_5およびRSASSA-PSSアルゴリズムを定義しています。
o MUST communicate the One-way Hash Function -- for instance, SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512. Because of security threats on SHA-1, the use of SHA-256 is RECOMMENDED [RFC6194];
o 一方向ハッシュ関数を通信する必要があります-たとえば、SHA-1、SHA-224、SHA-256、SHA-384、またはSHA-512。 SHA-1のセキュリティ上の脅威のため、SHA-256の使用が推奨されています[RFC6194]。
o MUST associate a value to the ASID field of the EXT_AUTH header extension (Section 3.1);
o EXT_AUTHヘッダー拡張（セクション3.1）のASIDフィールドに値を関連付ける必要があります。
o MUST communicate whether or not the anti-replay service is used for this session.
o このセッションでアンチリプレイサービスを使用するかどうかを伝達する必要があります。
These parameters MUST be communicated to all receivers before they can authenticate the incoming packets. For instance, it can be communicated in the session description, or initialized in a static way on the receivers, or communicated by means of an appropriate protocol. The details of this out-of-band mechanism are beyond the scope of this document.
これらのパラメータは、着信パケットを認証する前に、すべての受信者に通知する必要があります。たとえば、セッションの説明で通信したり、レシーバーで静的に初期化したり、適切なプロトコルを使用して通信したりできます。このアウトオブバンドメカニズムの詳細は、このドキュメントの範囲外です。
The computation of the Digital Signature, using the private key, MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP/MAC headers MUST NOT be included. During this computation, the Signature field MUST be set to 0.
秘密鍵を使用したデジタル署名の計算には、ALCまたはNORMヘッダー（さまざまなヘッダー拡張を含む）および該当する場合はペイロードを含める必要があります。 UDP / IP / MACヘッダーを含めることはできません。この計算中、Signatureフィールドは0に設定する必要があります。
Several signature-encoding algorithms can be used, including RSASSA-PKCS1-v1_5 and RSASSA-PSS. With these encodings, several one-way hash functions can be used, like SHA-256.
RSASSA-PKCS1-v1_5やRSASSA-PSSなど、いくつかの署名エンコーディングアルゴリズムを使用できます。これらのエンコーディングを使用すると、SHA-256などのいくつかの一方向ハッシュ関数を使用できます。
First, let us consider a packet sender. More specifically, as noted in [RFC4359], Digital Signature generation is performed as described in Section 8.2.1 of [RFC3447] (RSASSA-PKCS1-v1_5) and in Section 8.1.1 of [RFC3447] (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]のセクション8.2.1（RSASSA-PKCS1-v1_5）および[RFC3447]のセクション8.1.1（RSASSA-PSS）の説明に従って実行されます。パケットの認証された部分がメッセージ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 Digital Signature (also called the Integrity Check Value (ICV) in [RFC4359]) MUST be prepended with between 1 and 7 bits set to zero such that the Digital Signature is a multiple of 8 bits [RFC4359]. The key length, 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 beyond the scope of this document.
RSASSA-PKCS1-v1_5およびRSASSA-PSS署名では、RSA係数が8ビットの倍数でない限り、署名のサイズは「RSA係数」に等しくなります。その場合、デジタル署名（[RFC4359]では整合性チェック値（ICV）とも呼ばれます）の先頭に、デジタル署名が8ビットの倍数になるように1〜7ビットをゼロに設定する必要があります[RFC4359]。キーの長さは、実際にはRSAモジュラスにも等しく、セキュリティに大きな影響があります。 [RFC4359]は、セッションの予想される最大存続期間に応じて、この値を選択する方法を説明しています。この選択は、このドキュメントの範囲を超えています。
Now, let us consider a receiver. As noted in [RFC4359], Digital Signature verification is performed as described in Section 8.2.2 of [RFC3447] (RSASSA-PKCS1-v1_5) and Section 8.1.2 of [RFC3447] (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 using the sender's public key, and validates that the appropriate encoding was applied. The two SHA-256 hashes are compared, and if they are identical, the validation is successful.
ここで、レシーバについて考えてみましょう。 [RFC4359]に記載されているように、デジタル署名の検証は、[RFC3447]のセクション8.2.2（RSASSA-PKCS1-v1_5）および[RFC3447]のセクション8.1.2（RSASSA-PSS）の説明に従って実行されます。受信すると、デジタル署名はSとして検証関数に渡されます。パケットの認証済み部分はメッセージMとして使用され、RSA公開鍵は（n、e）として渡されます。要約すると（SHA-256が使用されている場合）、検証機能は認証されたパケットバイトのSHA-256ハッシュを計算し、送信者の公開鍵を使用してパケット内のSHA-256ハッシュを復号化し、適切なエンコーディングが適用されていることを検証します。 2つのSHA-256ハッシュが比較され、それらが同一である場合、検証は成功します。
Let us assume the anti-replay service is used. The principles are similar to the Sequence Number mechanism described in [RFC4303], with the exception that the present document uses a 40-bit field that contains all the bits of the Sequence Number counter.
アンチリプレイサービスが使用されていると仮定します。原則は、[RFC4303]で説明されているシーケンス番号メカニズムに似ていますが、現在のドキュメントでは、シーケンス番号カウンターのすべてのビットを含む40ビットのフィールドを使用している点が異なります。
At the sender, the mechanism works as follows (Section 2.2 of [RFC4303]). The sender's Sequence Number counter is initialized to 0 at session startup. The sender increments the Sequence Number counter for this session and inserts the value into the SN field. Thus, the first packet sent will contain an SN of 1. The SN value of the Authentication Header extension MUST be initialized before the signature generation process, in order to enable a receiver to check the SN value during the integrity verification process.
送信者では、このメカニズムは次のように機能します（[RFC4303]のセクション2.2）。送信者のシーケンス番号カウンターは、セッションの開始時に0に初期化されます。送信者は、このセッションのシーケンス番号カウンターを増分し、値をSNフィールドに挿入します。したがって、最初に送信されるパケットには1のSNが含まれます。認証ヘッダー拡張のSN値は、受信者が完全性検証プロセス中にSN値をチェックできるようにするために、署名生成プロセスの前に初期化する必要があります。
The sender SHOULD ensure that the counter does not cycle before inserting the new value in the SN field. Failing to follow this rule would enable an attacker to replay a packet sent during the previous cycle; i.e., it would limit the anti-replay service to a single SN cycle. Since the Sequence Number is contained in a 40-bit field, it is expected that cycling will never happen in most situations. For instance, on a 10-Gbps network, with small packets (i.e., 64 bytes long), cycling will happen after slightly more than 15 hours.
送信者は、SNフィールドに新しい値を挿入する前に、カウンターが循環しないことを保証する必要があります（SHOULD）。このルールに従わない場合、攻撃者は前のサイクル中に送信されたパケットを再生することができます。つまり、アンチリプレイサービスを単一のSNサイクルに制限します。シーケンス番号は40ビットのフィールドに含まれているため、ほとんどの状況で循環が発生することはありません。たとえば、10 Gbpsネットワークでは、小さなパケット（つまり、64バイト長）の場合、15時間を少し超えると循環が発生します。
At the receiver, the mechanism works as follows (Section 3.4.3 and Appendix A2 of [RFC4303]). For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the session. If this preliminary check fails, the packet is discarded, thus avoiding the need for any cryptographic operations by the receiver. If the preliminary check is successful, the receiver cannot yet modify its local counter, because the integrity of the Sequence Number has not been verified at this point.
受信側では、このメカニズムは次のように機能します（[RFC4303]のセクション3.4.3および付録A2）。受信したパケットごとに、受信者は、パケットに、セッション中に受信した他のパケットのシーケンス番号と重複しないシーケンス番号が含まれていることを確認する必要があります。この予備チェックが失敗した場合、パケットは破棄されるため、受信者による暗号化操作は不要になります。予備チェックが成功した場合、シーケンス番号の整合性がこの時点で確認されていないため、レシーバはまだローカルカウンタを変更できません。
Duplicates are rejected through the use of a sliding receive window. The "right" edge of the window represents the highest, validated Sequence Number value received on this session. Packets that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window (how this list is managed is a local, implementation-based decision). This window limits how far out of order a packet can be, relative to the packet with the highest Sequence Number that has been authenticated so far.
スライディング受信ウィンドウを使用すると、重複が拒否されます。ウィンドウの「右」端は、このセッションで受信した検証済みのシーケンス番号の最大値を表します。ウィンドウの「左」端よりも小さいシーケンス番号を含むパケットは拒否されます。ウィンドウ内に入るパケットは、ウィンドウ内で受信したパケットのリストと照合されます（このリストの管理方法は、ローカルの実装ベースの決定です）。このウィンドウは、これまでに認証されたシーケンス番号が最も大きいパケットと比較して、パケットがどれだけ順序が狂っているかを制限します。
If the received packet falls within the window and is not a duplicate, or if the packet is to the right of the window, then the receiver proceeds to integrity verification. If the integrity check fails, the receiver MUST discard the received packet as invalid; otherwise, the receive window is updated and packet processing continues.
受信したパケットがウィンドウ内にあり、重複していない場合、またはパケットがウィンドウの右側にある場合、受信者は整合性検証に進みます。完全性チェックが失敗した場合、受信者は受信したパケットを無効として破棄しなければなりません（MUST）。それ以外の場合は、受信ウィンドウが更新され、パケット処理が続行されます。
Each packet sent MUST contain exactly one Digital Signature EXT_AUTH header extension. A receiver MUST drop all the packets that do not contain a Digital Signature EXT_AUTH header extension.
送信される各パケットには、デジタル署名EXT_AUTHヘッダー拡張が1つだけ含まれている必要があります。受信者は、デジタル署名EXT_AUTHヘッダー拡張を含まないすべてのパケットをドロップする必要があります。
All receivers MUST recognize EXT_AUTH but might not be able to parse its content, for instance, because they do not support Digital Signatures. In that case, the Digital Signature EXT_AUTH header extension is ignored.
すべての受信者はEXT_AUTHを認識しなければなりません（MUST）が、たとえばデジタル署名をサポートしていないため、そのコンテンツを解析できない場合があります。その場合、デジタル署名EXT_AUTHヘッダー拡張は無視されます。
If the anti-replay mechanism is used, each packet sent MUST contain a valid Sequence Number. All the packets that fail to contain a valid Sequence Number MUST be immediately dropped.
アンチリプレイメカニズムが使用されている場合、送信される各パケットには有効なシーケンス番号が含まれている必要があります。有効なシーケンス番号が含まれていないすべてのパケットは、すぐにドロップする必要があります。
For instance, Figure 2 shows the Digital Signature EXT_AUTH header extension when using 128-byte (1024-bit) key Digital Signatures (which also means that the Signature field is 128 bytes long). The Digital Signature EXT_AUTH header extension is then 132 bytes long.
たとえば、図2は、128バイト（1024ビット）のキーデジタル署名を使用する場合のデジタル署名EXT_AUTHヘッダー拡張を示しています（これは、署名フィールドが128バイト長であることも意味します）。デジタル署名のEXT_AUTHヘッダー拡張は、132バイトの長さになります。
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 (=33) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature (128 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 2: Example: Format of the Digital Signature EXT_AUTH Header Extension Using 1024-Bit Signatures, without Any Anti-Replay Protection
図2：例：1024ビット署名を使用したデジタル署名EXT_AUTHヘッダー拡張のフォーマット、アンチリプレイ保護なし
This document focuses on the Elliptic Curve Digital Signature Algorithm (ECDSA). However, [RFC6090] describes alternative elliptic curve techniques, like KT-I signatures. The use of such alternatives is not considered in this document, but may be added in the future.
このドキュメントでは、楕円曲線デジタル署名アルゴリズム（ECDSA）に焦点を当てています。ただし、[RFC6090]は、KT-Iシグネチャのような代替の楕円曲線技法について説明しています。このような代替の使用は、このドキュメントでは考慮されていませんが、将来追加される可能性があります。
The integration of ECC Digital Signatures is similar to that of RSA Digital Signatures. Several fields are added, in addition to the HET and HEL fields, as illustrated in Figure 1.
ECCデジタル署名の統合は、RSAデジタル署名の統合に似ています。図1に示すように、HETおよびHELフィールドに加えて、いくつかのフィールドが追加されます。
The fields of the Digital Signature EXT_AUTH header extension are as follows:
デジタル署名EXT_AUTHヘッダー拡張のフィールドは次のとおりです。
ASID (4 bits):
ACID（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値と実際の認証方式の間の関連付けは、セッション開始時に帯域外で定義されます。
rsvd (3 bits):
rsvd（3ビット）：
This is a reserved field that MUST be set to zero and ignored by receivers.
これは予約済みフィールドで、ゼロに設定する必要があり、受信者は無視する必要があります。
AR (1 bit):
AR（1ビット）：
The AR field, when set to 0, indicates that the anti-replay service is not used. When set to 1, it indicates that the anti-replay service is used.
ARフィールドは、0に設定されている場合、アンチリプレイサービスが使用されていないことを示します。 1に設定されている場合、アンチリプレイサービスが使用されていることを示します。
SN (8 or 40 bits):
SN（8または40ビット）：
The SN field contains an optional Sequence Number. When AR = 0, this is an 8-bit field that MUST be set to zero. No anti-replay mechanism is used in that case. When AR = 1, this is a 40-bit field (32 bits + 8 bits), and all of the 40 bits MUST be considered by the anti-replay mechanism.
SNフィールドには、オプションのシーケンス番号が含まれます。 AR = 0の場合、これはゼロに設定する必要がある8ビットのフィールドです。その場合、アンチリプレイメカニズムは使用されません。 AR = 1の場合、これは40ビットのフィールド（32ビット+ 8ビット）であり、40ビットのすべてをアンチリプレイメカニズムで考慮する必要があります。
Signature (variable size, multiple of 32 bits):
署名（可変サイズ、32ビットの倍数）：
The Signature field contains a Digital Signature of the message. If need be, this field is padded (with 0) up to a multiple of 32 bits.
[署名]フィールドには、メッセージのデジタル署名が含まれます。必要に応じて、このフィールドは32ビットの倍数まで（0で）パディングされます。
Several parameters MUST be initialized by an out-of-band mechanism. The sender or group controller
いくつかのパラメータは、帯域外メカニズムによって初期化する必要があります。送信者またはグループのコントローラー
o MUST communicate its public key, for each receiver to be able to verify the signature of the packets received. As a side effect, the receivers also know the key length and the signature length, the two parameters being equal;
o 各受信者が受信したパケットの署名を検証できるように、公開鍵を通信する必要があります。副作用として、受信者はキーの長さと署名の長さも知っており、2つのパラメータは同じです。
o MAY communicate a certificate (which also means that a PKI has been set up), for each receiver to be able to check the sender's public key;
o 各受信者が送信者の公開鍵を確認できるように、証明書（PKIが設定されていることも意味する）を通信する場合があります。
o MUST communicate the message digest algorithm;
o メッセージダイジェストアルゴリズムを通信する必要があります。
o MUST communicate the elliptic curve;
o 楕円曲線を伝達する必要があります。
o MUST associate a value to the ASID field of the EXT_AUTH header extension (Section 3.1);
o EXT_AUTHヘッダー拡張（セクション3.1）のASIDフィールドに値を関連付ける必要があります。
o MUST communicate whether or not the anti-replay service is used for this session.
o このセッションでアンチリプレイサービスを使用するかどうかを伝達する必要があります。
These parameters MUST be communicated to all receivers before they can authenticate the incoming packets. For instance, it can be communicated in the session description, or initialized in a static way on the receivers, or communicated by means of an appropriate protocol. The details of this out-of-band mechanism are beyond the scope of this document.
これらのパラメータは、着信パケットを認証する前に、すべての受信者に通知する必要があります。たとえば、セッションの説明で通信したり、レシーバーで静的に初期化したり、適切なプロトコルを使用して通信したりできます。このアウトオブバンドメカニズムの詳細は、このドキュメントの範囲外です。
The computation of the ECC Digital Signature, using the private key, MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP/MAC headers MUST NOT be included. During this computation, the Signature field MUST be set to 0.
秘密鍵を使用したECCデジタル署名の計算には、ALCまたはNORMヘッダー（さまざまなヘッダー拡張を含む）および該当する場合はペイロードを含める必要があります。 UDP / IP / MACヘッダーを含めることはできません。この計算中、Signatureフィールドは0に設定する必要があります。
Several elliptic curve groups can be used, as well as several hash algorithms. In practice, both choices are related, and there is a minimum hash algorithm size for any key length. Using a larger hash algorithm and then truncating the output is also feasible; however, it consumes more processing power than is necessary. In order to promote interoperability, [RFC4754] and [RFC5480] list several possible choices (see table below).
いくつかの楕円曲線グループ、およびいくつかのハッシュアルゴリズムを使用できます。実際には、両方の選択が関連しており、どのキー長にも最小のハッシュアルゴリズムサイズがあります。より大きなハッシュアルゴリズムを使用してから出力を切り捨てることも可能です。ただし、必要以上の処理能力を消費します。相互運用性を促進するために、[RFC4754]と[RFC5480]はいくつかの可能な選択肢をリストしています（下の表を参照）。
+---------------------------+--------+------------------+-----------+
| Digital Signature | Key | Message Digest | Elliptic |
| Algorithm Name [RFC4754] | Size | Algorithm | Curve |
+---------------------------+--------+------------------+-----------+
| ECDSA-256 (default) | 256 | SHA-256 | secp256r1 |
| ECDSA-384 | 384 | SHA-384 | secp384r1 |
| ECDSA-521 | 512 | SHA-512 | secp521r1 |
+---------------------------+--------+------------------+-----------+
ECDSA-256, ECDSA-384, and ECDSA-521 are designed to offer security comparable with AES-128, AES-192, and AES-256, respectively [RFC4754]. Among them, the use of ECDSA-256/secp256r1 is RECOMMENDED.
ECDSA-256、ECDSA-384、およびECDSA-521は、それぞれAES-128、AES-192、およびAES-256に匹敵するセキュリティを提供するように設計されています[RFC4754]。その中で、ECDSA-256 / secp256r1の使用が推奨されます。
The anti-replay processing follows the principles described in Section 3.3.2.
リプレイ防止処理は、セクション3.3.2で説明されている原則に従います。
Each packet sent MUST contain exactly one ECC Digital Signature EXT_AUTH header extension. A receiver MUST drop all the packets that do not contain an ECC Digital Signature EXT_AUTH header extension.
送信される各パケットには、正確に1つのECCデジタル署名EXT_AUTHヘッダー拡張が含まれている必要があります。受信者は、ECCデジタル署名EXT_AUTHヘッダー拡張を含まないすべてのパケットをドロップする必要があります。
All receivers MUST recognize EXT_AUTH but might not be able to parse its content, for instance, because they do not support ECC Digital Signatures. In that case, the Digital Signature EXT_AUTH header extension is ignored.
すべての受信者はEXT_AUTHを認識しなければなりませんが、たとえば、ECCデジタル署名をサポートしていないため、そのコンテンツを解析できない可能性があります。その場合、デジタル署名EXT_AUTHヘッダー拡張は無視されます。
If the anti-replay mechanism is used, each packet sent MUST contain a valid Sequence Number. All the packets that fail to contain a valid Sequence Number MUST be immediately dropped.
アンチリプレイメカニズムが使用されている場合、送信される各パケットには有効なシーケンス番号が含まれている必要があります。有効なシーケンス番号が含まれていないすべてのパケットは、すぐにドロップする必要があります。
For instance, Figure 3 shows the Digital Signature EXT_AUTH header extension when using ECDSA-256 (256-bit) ECC Digital Signatures. The ECC Digital Signature EXT_AUTH header extension is then 36 bytes long.
たとえば、図3は、ECDSA-256（256ビット）ECCデジタル署名を使用する場合のデジタル署名EXT_AUTHヘッダー拡張を示しています。その場合、ECCデジタル署名EXT_AUTHヘッダー拡張は36バイトの長さになります。
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 (=9) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 3
+ + | 2
. . |
. Signature (32 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 3: Example: Format of the ECC Digital Signature EXT_AUTH Header Extension Using ECDSA-256 Signatures, without Any Anti-Replay Protection
図3：例：アンチリプレイ保護なしのECDSA-256署名を使用したECCデジタル署名EXT_AUTHヘッダー拡張のフォーマット
The integration of Group-keyed MAC is similar in ALC and NORM and relies on the header extension mechanism defined in both protocols. More precisely, this document details the HET=1 (EXT_AUTH) header extension defined in [RFC5651].
Group-keyed MACの統合はALCとNORMで類似しており、両方のプロトコルで定義されているヘッダー拡張メカニズムに依存しています。より正確には、このドキュメントは、[RFC5651]で定義されているHET = 1（EXT_AUTH）ヘッダー拡張について詳しく説明します。
Several fields are added, in addition to the HET and HEL fields (Figure 4).
HETおよびHELフィールドに加えて、いくつかのフィールドが追加されます（図4）。
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 | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+ +
~ anti-replay Sequence Number (SN) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Group-keyed MAC |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of the Group-Keyed MAC EXT_AUTH Header Extension
図4：グループキー付きMAC EXT_AUTHヘッダー拡張のフォーマット
The fields of the Group-keyed MAC EXT_AUTH header extension are as follows:
Group-keyed MAC EXT_AUTHヘッダー拡張のフィールドは次のとおりです。
ASID (4 bits):
ACID（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値と実際の認証方式の間の関連付けは、セッション開始時に帯域外で定義されます。
rsvd (3 bits):
rsvd（3ビット）：
This is a reserved field that MUST be set to zero and ignored by receivers.
これは予約済みフィールドで、ゼロに設定する必要があり、受信者は無視する必要があります。
AR (1 bit):
AR（1ビット）：
The AR field, when set to 0, indicates that the anti-replay service is not used. When set to 1, it indicates that the anti-replay service is used.
ARフィールドは、0に設定されている場合、アンチリプレイサービスが使用されていないことを示します。 1に設定されている場合、アンチリプレイサービスが使用されていることを示します。
SN (8 or 40 bits):
SN（8または40ビット）：
The SN field contains an optional Sequence Number. When AR = 0, this is an 8-bit field that MUST be set to zero. No anti-replay mechanism is used in that case. When AR = 1, this is a 40-bit field (32 bits + 8 bits), and all of the 40 bits MUST be considered by the anti-replay mechanism.
SNフィールドには、オプションのシーケンス番号が含まれます。 AR = 0の場合、これはゼロに設定する必要がある8ビットのフィールドです。その場合、アンチリプレイメカニズムは使用されません。 AR = 1の場合、これは40ビットのフィールド（32ビット+ 8ビット）であり、40ビットのすべてをアンチリプレイメカニズムで考慮する必要があります。
Group-keyed MAC (variable size, multiple of 32 bits):
グループキー付きMAC（可変サイズ、32ビットの倍数）：
The Group-keyed MAC field contains a truncated Group-keyed MAC of the message. If need be, this field is padded (with 0) up to a multiple of 32 bits.
Group-keyed MACフィールドには、メッセージの切り捨てられたGroup-keyed MACが含まれています。必要に応じて、このフィールドは32ビットの倍数まで（0で）パディングされます。
Several parameters MUST be initialized by an out-of-band mechanism. The sender or group controller
いくつかのパラメータは、帯域外メカニズムによって初期化する必要があります。送信者またはグループのコントローラー
o MUST communicate the Cryptographic MAC Function -- for instance, HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512. As a side effect, with these functions, the receivers also know the key length and the non-truncated MAC output length. Because of security threats on SHA-1, the use of HMAC-SHA-256 is RECOMMENDED [RFC6194];
o 暗号化MAC機能（例：HMAC-SHA-1、HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384、またはHMAC-SHA-512）を通信する必要があります。副作用として、これらの関数を使用すると、受信者はキーの長さと切り捨てられていないMAC出力長も認識します。 SHA-1のセキュリティ上の脅威のため、HMAC-SHA-256の使用が推奨されています[RFC6194]。
o MUST communicate the length of the truncated output of the MAC, n_m, which depends on the Cryptographic MAC Function chosen. Only the n_m leftmost bits (most significant bits) of the MAC output are kept. Of course, n_m MUST be less than or equal to the key length;
o 選択された暗号化MAC関数に依存する、MACの切り詰められた出力の長さn_mを通信する必要があります。 MAC出力の左端のn_mビット（最上位ビット）のみが保持されます。もちろん、n_mはキーの長さ以下でなければなりません。
o MUST communicate the group key to the receivers, confidentially, before starting the session. This key might have to be periodically refreshed for improved robustness;
o セッションを開始する前に、グループキーを秘密裏に受信者に通信する必要があります。堅牢性を向上させるには、このキーを定期的に更新する必要がある場合があります。
o MUST associate a value to the ASID field of the EXT_AUTH header extension (Section 5.1);
o EXT_AUTHヘッダー拡張（セクション5.1）のASIDフィールドに値を関連付ける必要があります。
o MUST communicate whether or not the anti-replay service is used for this session.
o このセッションでアンチリプレイサービスを使用するかどうかを伝達する必要があります。
These parameters MUST be communicated to all receivers before they can authenticate the incoming packets. For instance, it can be communicated in the session description, or initialized in a static way on the receivers, or communicated by means of an appropriate protocol (this will often be the case when periodic re-keying is required). The details of this out-of-band mechanism are beyond the scope of this document.
これらのパラメータは、着信パケットを認証する前に、すべての受信者に通知する必要があります。たとえば、セッションの説明で通信したり、レシーバーで静的に初期化したり、適切なプロトコルを使用して通信したりできます（これは、定期的な再キーが必要な場合によく見られます）。このアウトオブバンドメカニズムの詳細は、このドキュメントの範囲外です。
The computation of the Group-keyed MAC, using the group key, includes the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP/MAC headers are not included. During this computation, the weak Group-keyed MAC field MUST be set to 0. Then, the sender truncates the MAC output to keep the n_m most significant bits and stores the result in the Group-keyed MAC Authentication Header.
グループキーを使用したグループキー付きMACの計算には、ALCまたはNORMヘッダー（さまざまなヘッダー拡張を含む）および該当する場合はペイロードが含まれます。 UDP / IP / MACヘッダーは含まれていません。この計算中、弱いグループキー付きMACフィールドは0に設定する必要があります。次に、送信者はMAC出力を切り捨ててn_m最上位ビットを維持し、結果をグループキー付きMAC認証ヘッダーに格納します。
Upon receiving this packet, the receiver computes the Group-keyed MAC, using the group key, and compares it to the value carried in the packet. During this computation, the Group-keyed MAC field MUST also be set to 0. If the check fails, the packet MUST be immediately dropped.
このパケットを受信すると、受信者はグループキーを使用してグループキー付きMACを計算し、それをパケットで伝送される値と比較します。この計算中、Group-keyed MACフィールドも0に設定する必要があります。チェックに失敗した場合、パケットは直ちにドロップする必要があります。
[RFC2104] explains that it is current practice to truncate the MAC output, on condition that the truncated output length, n_m, be not less than half the length of the hash and not less than 80 bits. However, this choice is beyond the scope of this document.
[RFC2104]は、切り詰められた出力長n_mがハッシュの長さの半分以上80ビット以上であるという条件で、MAC出力を切り詰めることが現在の慣行であると説明しています。ただし、この選択はこのドキュメントの範囲を超えています。
The anti-replay processing follows the principles described in Section 3.3.2.
リプレイ防止処理は、セクション3.3.2で説明されている原則に従います。
Each packet sent MUST contain exactly one Group-keyed MAC EXT_AUTH header extension. A receiver MUST drop packets that do not contain a Group-keyed MAC EXT_AUTH header extension.
送信される各パケットには、グループキー付きMAC EXT_AUTHヘッダー拡張が1つだけ含まれている必要があります。受信者は、グループキー付きMAC EXT_AUTHヘッダー拡張を含まないパケットをドロップする必要があります。
All receivers MUST recognize EXT_AUTH but might not be able to parse its content, for instance, because they do not support Group-keyed MAC. In that case, the Group-keyed MAC EXT_AUTH extension is ignored.
すべてのレシーバーはEXT_AUTHを認識しなければなりません（MUST）が、たとえば、グループキー付きMACをサポートしていないため、コンテンツを解析できない場合があります。その場合、グループキー付きMAC EXT_AUTH拡張は無視されます。
If the anti-replay mechanism is used, each packet sent MUST contain a valid Sequence Number. All the packets that fail to contain a valid Sequence Number MUST be immediately dropped.
アンチリプレイメカニズムが使用されている場合、送信される各パケットには有効なシーケンス番号が含まれている必要があります。有効なシーケンス番号が含まれていないすべてのパケットは、すぐにドロップする必要があります。
For instance, Figure 5 shows the Group-keyed MAC EXT_AUTH header extension when using HMAC-SHA-256. The Group-keyed MAC EXT_AUTH header extension is then 16 bytes long.
たとえば、図5は、HMAC-SHA-256を使用する場合のグループキー付きMAC EXT_AUTHヘッダー拡張を示しています。その場合、グループキー付きMAC EXT_AUTHヘッダー拡張は16バイト長です。
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 (=4) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Group-keyed MAC (16 bytes) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example: Format of the Group-Keyed MAC EXT_AUTH Header Extension Using HMAC-SHA-256, without Any Anti-Replay Protection
図5：例：アンチリプレイ保護なしのHMAC-SHA-256を使用したグループキー付きMAC EXT_AUTHヘッダー拡張の形式
6. Combined Use of the RSA/ECC Digital Signatures and Group-Keyed MAC Schemes
6. RSA / ECCデジタル署名とグループキー付きMACスキームの併用
The integration of combined RSA/ECC Digital Signatures and Group-keyed MAC schemes is similar in ALC and NORM and relies on the header extension mechanism defined in both protocols. More precisely, this document details the HET=1 (EXT_AUTH) header extension defined in [RFC5651].
結合されたRSA / ECCデジタル署名とグループキー付きMACスキームの統合は、ALCとNORMで類似しており、両方のプロトコルで定義されているヘッダー拡張メカニズムに依存しています。より正確には、このドキュメントは、[RFC5651]で定義されているHET = 1（EXT_AUTH）ヘッダー拡張について詳しく説明します。
Several fields are added, in addition to the HET and HEL fields (Figure 6).
HETおよびHELフィールドに加えて、いくつかのフィールドが追加されます（図6）。
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 | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+ +
| anti-replay Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Signature |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group-keyed MAC |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of the Group-Keyed MAC EXT_AUTH Header Extension
図6：グループキー付きMAC EXT_AUTHヘッダー拡張のフォーマット
The fields of the Group-keyed MAC EXT_AUTH header extension are as follows:
Group-keyed MAC EXT_AUTHヘッダー拡張のフィールドは次のとおりです。
ASID (4 bits):
ACID（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値と実際の認証方式の間の関連付けは、セッション開始時に帯域外で定義されます。
rsvd (3 bits):
rsvd（3ビット）：
This is a reserved field that MUST be set to zero and ignored by receivers.
これは予約済みフィールドで、ゼロに設定する必要があり、受信者は無視する必要があります。
AR (1 bit):
AR（1ビット）：
The AR field MUST be set to 1, indicating that the anti-replay service is used (see Section 6.3).
ARフィールドは1に設定しなければならず（MUST）、アンチリプレイサービスが使用されていることを示します（6.3節を参照）。
SN (8 or 40 bits):
SN（8または40ビット）：
The SN field contains a Sequence Number. Since AR = 1, this is a 40-bit field (32 bits + 8 bits), and all of the 40 bits MUST be considered by the anti-replay mechanism.
SNフィールドにはシーケンス番号が含まれます。 AR = 1であるため、これは40ビットのフィールド（32ビット+ 8ビット）であり、40ビットのすべてをアンチリプレイメカニズムで考慮する必要があります。
Signature (variable size, multiple of 32 bits):
署名（可変サイズ、32ビットの倍数）：
The Signature field contains a Digital Signature of the message. If need be, this field is padded (with 0) up to a multiple of 32 bits.
[署名]フィールドには、メッセージのデジタル署名が含まれます。必要に応じて、このフィールドは32ビットの倍数まで（0で）パディングされます。
Group-keyed MAC (variable size, multiple of 32 bits, by default 32 bits):
グループキー付きMAC（可変サイズ、32ビットの倍数、デフォルトでは32ビット）：
The Group-keyed MAC field contains a truncated Group-keyed MAC of the message.
Group-keyed MACフィールドには、メッセージの切り捨てられたGroup-keyed MACが含まれています。
Several parameters MUST be initialized by an out-of-band mechanism, as defined in Sections 3.2, 4.2, and 5.2.
セクション3.2、4.2、および5.2で定義されているように、いくつかのパラメータは、アウトオブバンドメカニズムによって初期化する必要があります。
In some situations, it can be interesting to use both authentication schemes. The goal of the Group-keyed MAC is to mitigate denial-of-service (DoS) attacks coming from attackers that are not group members [RFC4082], by adding a light authentication scheme as a front-end.
状況によっては、両方の認証スキームを使用することが興味深い場合があります。 Group-keyed MACの目的は、軽い認証スキームをフロントエンドとして追加することにより、グループメンバーではない攻撃者からのサービス拒否（DoS）攻撃[RFC4082]を軽減することです。
Before sending a message, the sender sets the Signature field and Group-keyed MAC field to zero. Then, the sender computes the signature as detailed in Section 3.3 or in Section 4.3 and stores the value in the Signature field. Then, the sender computes the Group-keyed MAC as detailed in Section 5.3 and stores the value in the Group-keyed MAC field. The (RSA or ECC) Digital Signature value is therefore protected by the Group-keyed MAC, which avoids DoS attacks where the attacker corrupts the Digital Signature itself.
メッセージを送信する前に、送信者はSignatureフィールドとGroup-keyed MACフィールドをゼロに設定します。次に、送信者は、セクション3.3またはセクション4.3で詳しく説明されているように署名を計算し、その値を[署名]フィールドに格納します。次に、送信者は、セクション5.3で詳しく説明されているように、グループキー付きMACを計算し、その値をグループキー付きMACフィールドに格納します。したがって、（RSAまたはECC）デジタル署名値は、グループキー付きMACによって保護され、攻撃者がデジタル署名自体を破損するDoS攻撃を回避します。
Upon receiving the packet, the receiver first checks the Group-keyed MAC, as detailed in Section 5.3. If the check fails, the packet MUST be immediately dropped. Otherwise, the receiver checks the Digital Signature, as detailed in Section 3.3. If the check fails, the packet MUST be immediately dropped.
パケットを受信すると、レシーバーは、セクション5.3で詳述されているように、最初にグループキー付きMACをチェックします。チェックが失敗した場合、パケットはすぐにドロップされる必要があります。それ以外の場合は、セクション3.3で詳しく説明されているように、受信者はデジタル署名をチェックします。チェックが失敗した場合、パケットはすぐにドロップされる必要があります。
This scheme features a few limits:
このスキームにはいくつかの制限があります。
o The Group-keyed MAC is of no help if a group member (who knows the group key) impersonates the sender and sends forged messages to other receivers. DoS attacks are still feasible;
o （グループキーを知っている）グループメンバーが送信者になりすまし、偽造メッセージを他の受信者に送信する場合、グループキー付きMACは役に立ちません。 DoS攻撃は依然として実行可能です。
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 Authentication Headers. In order to limit this problem, the length of the truncated output of the MAC, n_m, SHOULD be kept small (see Section 9.5 of [RFC3711]). In the current specification, n_m MUST be a multiple of 32 bits, and the default value is 32 bits. As a side effect, with n_m = 32 bits, the authentication service is significantly weakened, since the probability that any packet would be successfully forged is one in 2^32. Since the Group-keyed MAC check is only a pre-check that is followed by the standard signature authentication check, this is not considered to be an issue.
o 認証ヘッダーのサイズが大きくなります。この問題を制限するために、MACの切り捨てられた出力の長さn_mは小さく保つ必要があります（[RFC3711]のセクション9.5を参照）。現在の仕様では、n_mは32ビットの倍数である必要があり、デフォルト値は32ビットです。副作用として、n_m = 32ビットでは、パケットが正常に偽造される確率が2 ^ 32分の1であるため、認証サービスが大幅に低下します。 Group-keyed MACチェックは、標準の署名認証チェックが後に続く事前チェックにすぎないため、これは問題とは見なされません。
For a given use case, the benefits brought by the Group-keyed MAC must be balanced against these limitations.
特定の使用例では、グループキー付きMACによってもたらされる利点は、これらの制限とバランスを取る必要があります。
The anti-replay processing follows the principles described in Section 3.3.2. Here, an anti-replay service MUST be used. Indeed, failing to enable anti-replay protection would facilitate DoS attacks, since all replayed (but otherwise valid) packets would pass the light authentication scheme and oblige a receiver to perform a complex signature verification.
リプレイ防止処理は、セクション3.3.2で説明されている原則に従います。ここでは、アンチリプレイサービスを使用する必要があります。実際、リプレイされないすべてのパケットがライト認証スキームを通過し、受信者に複雑な署名検証を実行させるため、アンチリプレイ保護を有効にしないと、DoS攻撃が容易になります。
Each packet sent MUST contain exactly one combined Digital Signature/ Group-keyed MAC EXT_AUTH header extension. A receiver MUST drop packets that do not contain a combined Digital Signature/Group-keyed MAC EXT_AUTH header extension.
送信された各パケットには、デジタル署名/グループキー付きMAC EXT_AUTHヘッダー拡張が1つだけ含まれている必要があります。受信者は、デジタル署名/グループキー付きMAC EXT_AUTHヘッダー拡張の組み合わせを含まないパケットをドロップする必要があります。
All receivers MUST recognize EXT_AUTH but might not be able to parse its content, for instance, because they do not support combined Digital Signature/Group-keyed MAC. In that case, the combined Digital Signature/Group-keyed MAC EXT_AUTH extension is ignored.
すべての受信者はEXT_AUTHを認識しなければなりません（MUST）が、たとえば、デジタル署名/グループキー付きMACの組み合わせをサポートしていないため、コンテンツを解析できない場合があります。その場合、結合されたデジタル署名/グループキー付きMAC EXT_AUTH拡張は無視されます。
Since the anti-replay mechanism MUST be used, each packet sent MUST contain a valid Sequence Number. All the packets that fail to contain a valid Sequence Number MUST be immediately dropped.
アンチリプレイメカニズムを使用する必要があるため、送信される各パケットには有効なシーケンス番号が含まれている必要があります。有効なシーケンス番号が含まれていないすべてのパケットは、すぐにドロップする必要があります。
It is RECOMMENDED that the n_m parameter of the group authentication scheme be small, and by default equal to 32 bits (Section 6.3).
グループ認証方式のn_mパラメータは小さく、デフォルトで32ビットに等しいことをお勧めします（セクション6.3）。
For instance, Figure 7 shows the combined Digital Signature/ Group-keyed MAC EXT_AUTH header extension when using 128-byte (1024-bit) key RSA Digital Signatures (which also means that the Signature field is 128 bytes long). The EXT_AUTH header extension is then 140 bytes long.
たとえば、図7は、128バイト（1024ビット）のキーRSAデジタル署名（つまり、署名フィールドが128バイト長であること）を使用する場合の、デジタル署名とグループキー付きMAC EXT_AUTHヘッダー拡張の組み合わせを示しています。 EXT_AUTHヘッダー拡張は、140バイトの長さになります。
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 (=35) | ASID | 0 |1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| anti-replay Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature (128 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Group-keyed MAC (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 7: Example: Format of the Combined RSA Digital Signature/ Group-Keyed MAC EXT_AUTH Header Extension Using 1024-Bit Signatures, with Anti-Replay Protection
図7：例：1024ビット署名を使用したRSAデジタル署名/グループキー付きMAC EXT_AUTHヘッダー拡張の組み合わせ、リプレイ防止保護付き
Let us consider packets secured through the use of a Digital Signature scheme first. Because faked packets are easy to create but checking them requires computation of a costly Digital Signature, this scheme introduces new opportunities for an attacker to mount DoS attacks. More precisely, an attacker can easily saturate the processing capabilities of the receiver.
最初にデジタル署名方式を使用して保護されたパケットについて考えてみましょう。偽造されたパケットは簡単に作成できますが、チェックには高価なデジタル署名の計算が必要であるため、このスキームは攻撃者がDoS攻撃を仕掛ける新しい機会をもたらします。より正確には、攻撃者は受信機の処理能力を簡単に飽和させることができます。
In order to mitigate these attacks, it is RECOMMENDED that the combined Digital Signature/Group-keyed MAC scheme (Section 6.3) be used. However, no mitigation is possible if a group member acts as an attacker. Additionally, even if checking a Group-keyed MAC is significantly faster than checking a Digital Signature, there are practical limits on how many Group-keyed MACs can be checked per time unit. Therefore, it is RECOMMENDED that limiting the number of authentication checks per time unit be done when the number of incoming packets that fail the authentication check exceeds a given threshold (i.e., in the case of a DoS attack).
これらの攻撃を軽減するために、デジタル署名とグループキーイングされたMACスキーム（セクション6.3）を組み合わせて使用することをお勧めします。ただし、グループメンバーが攻撃者として機能する場合、緩和策はありません。さらに、グループキー付きMACをチェックする方がデジタル署名をチェックするよりも大幅に高速であっても、時間単位ごとにチェックできるグループキー付きMACの数には実際的な制限があります。したがって、認証チェックに失敗した着信パケットの数が所定のしきい値を超えた場合（つまり、DoS攻撃の場合）、時間単位あたりの認証チェックの数を制限することをお勧めします。
The RECOMMENDED action of limiting the number of checks per time unit under (presumed) attack situations can be extended to the other authentication schemes.
（想定される）攻撃状況下での時間単位あたりのチェック数を制限するという推奨されるアクションは、他の認証スキームに拡張できます。
Replay attacks involve an attacker storing a valid message and replaying it later. It is RECOMMENDED that the anti-replay service defined in this document be used with the signature and Group-keyed MAC solutions, and this anti-replay service MUST be used in the case of a combined use of signatures and Group-keyed MAC schemes (see Section 6.3.2).
リプレイ攻撃には、攻撃者が有効なメッセージを保存し、後でそれをリプレイすることが含まれます。このドキュメントで定義されているアンチリプレイサービスは、署名とグループキー付きMACソリューションで使用することをお勧めします。このアンチリプレイサービスは、署名とグループキー付きMACスキームを組み合わせて使用する場合に使用する必要があります（セクション6.3.2を参照してください）。
The following section details some of the potential consequences of not using anti-replay protection.
次のセクションでは、アンチリプレイ保護を使用しない場合の潜在的な結果について詳しく説明します。
Since all the above authentication schemes are stateless, replay attacks have no impact on these schemes.
上記の認証スキームはすべてステートレスであるため、リプレイ攻撃はこれらのスキームに影響を与えません。
In this subsection, we review 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, congestion control protocols.
このサブセクションでは、NORMコンポーネントに対するリプレイ攻撃の潜在的な影響を確認します。ここでは、NORMとともに使用できるプロトコル（輻輳制御プロトコルなど）は考慮しないことに注意してください。
First, let us consider replay attacks within a given NORM session. As NORM is a stateful protocol, replaying a packet may have consequences.
まず、特定のNORMセッション内でのリプレイ攻撃について考えてみましょう。 NORMはステートフルプロトコルであるため、パケットを再生すると影響が生じる可能性があります。
NORM defines a "sequence" field that may 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. Using this field for anti-replay protection would be possible if there is no wrapping to zero, i.e., would only be possible if at most 65535 packets are sent; this may be true for some use cases but not for the general case. Using this field for anti-replay protection would also be possible if the keying material is updated before wrapping to zero happens; this may be true for some use cases but not for the general case.
NORMは、特定のNORMセッション内のリプレイアタック[RFC5740]から保護するために使用できる「シーケンス」フィールドを定義します。このシーケンスフィールドは、メッセージの発信者（送信者または受信者）によって、送信される各NORMメッセージで増加する単調に増加する数値として設定される16ビット値です。ゼロへの折り返しがない場合、つまり、最大65535のパケットが送信された場合にのみ、このフィールドを使用してアンチリプレイ保護を行うことができます。これは一部のユースケースでは当てはまる場合がありますが、一般的なケースでは当てはまりません。このフィールドをアンチリプレイ保護に使用することは、ゼロへのラップが発生する前にキー情報が更新される場合にも可能です。これは一部のユースケースでは当てはまる場合がありますが、一般的なケースでは当てはまりません。
Now, let us consider replay attacks across several NORM sessions. A host participating in a NORM session is uniquely identified by the {source_id; instance_id} tuple. Therefore, when a given host participates in several NORM sessions, it is RECOMMENDED that instance_id be changed for each NORM instance. It is also RECOMMENDED, when the Group-keyed MAC authentication/integrity check scheme is used, that the shared group key be changed across sessions. Therefore, NORM can be made robust when confronted with replay attacks across different sessions.
ここで、いくつかのNORMセッションでのリプレイ攻撃について考えてみましょう。 NORMセッションに参加しているホストは、{source_id;によって一意に識別されます。 instance_id}タプル。したがって、特定のホストが複数のNORMセッションに参加している場合、各NORMインスタンスのinstance_idを変更することをお勧めします。また、グループキー付きMAC認証/整合性チェックスキームを使用する場合は、セッション間で共有グループキーを変更することをお勧めします。したがって、さまざまなセッションにわたるリプレイ攻撃に直面した場合、NORMを堅牢にすることができます。
In this subsection, we review 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, layered or wave-based congestion control protocols.
このサブセクションでは、ALCコンポーネントに対するリプレイ攻撃の潜在的な影響を確認します。ここでは、ALCとともに使用できるプロトコルについては考慮していません。たとえば、レイヤードまたはウェーブベースの輻輳制御プロトコルです。
First, let us consider replay attacks within a given ALC session:
まず、特定のALCセッション内でのリプレイ攻撃について考えてみましょう。
o Replayed encoding symbol: A replayed encoding symbol (coming from a replayed data packet) is detected, thanks to the object/block/ symbol identifiers, and is silently discarded.
o 再生されたエンコーディングシンボル：オブジェクト/ブロック/シンボル識別子のおかげで、再生されたエンコーディングシンボル（再生されたデータパケットからのもの）が検出され、通知なく破棄されます。
o Replayed control information:
o 再生された制御情報：
* At the end of the session, a "close session" (A flag) packet is sent. Replaying a packet containing this flag has no impact, since the receivers have already left the session.
* セッションの終わりに、「セッションを閉じる」（フラグ）パケットが送信されます。受信者がすでにセッションを離れているため、このフラグを含むパケットを再生しても影響はありません。
* 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フラグ）を含むパケットを再生しても影響はありません。これは、このオブジェクトがおそらくレシーバーによってクローズ済みとしてマークされているためです。
* Timing information sent as part of a Layered Coding Transport (LCT) EXT_TIME header extension [RFC5651] may be more sensitive to replay attacks. For instance, replaying a packet containing an ERT (Expected Residual Time) may mislead a receiver to believe an object transmission will continue for some time whereas the transmission of symbols for this object is about to stop. Replaying a packet containing a Sender Current Time (SCT) is easily identified if the receiver verifies that time progresses upon receiving such EXT_TIME header extensions.
* レイヤードコーディングトランスポート（LCT）のEXT_TIMEヘッダー拡張[RFC5651]の一部として送信されるタイミング情報は、リプレイ攻撃に対してより敏感になる場合があります。たとえば、ERT（予想残余時間）を含むパケットを再生すると、オブジェクトのシンボルの送信が停止している間、オブジェクトの送信がしばらく続くと誤解する可能性があります。送信者の現在時刻（SCT）を含むパケットの再生は、受信者がそのようなEXT_TIMEヘッダー拡張の受信時に時間が経過していることを確認すれば、簡単に識別できます。
Replaying a packet containing a Session Last Changed (SLC) is easily identified if the receiver verifies the chronology upon receiving such EXT_TIME header extensions.
そのようなEXT_TIMEヘッダー拡張の受信時に受信者が年表を検証すると、Session Last Changed（SLC）を含むパケットの再生を簡単に識別できます。
This analysis shows that ALC might be, to a limited extent, sensitive to replay attacks within the same session if timing information is used. Otherwise, ALC is robust when confronted with replay attacks within the same session.
この分析は、タイミング情報が使用されている場合、ALCは、限られた範囲で、同じセッション内のリプレイ攻撃に敏感である可能性があることを示しています。それ以外の場合、ALCは、同じセッション内でリプレイ攻撃に直面したときに堅牢です。
Now, let us consider replay attacks across several ALC sessions. An ALC session is uniquely identified by the {sender IP address; TSI} tuple. Therefore, when a given sender creates several sessions, the TSI MUST be changed for each ALC session, so that each TSI is unique among all active sessions of this sender and for a long period of time preceding and following when the session is active [RFC5651]. Therefore, ALC can be made robust when confronted with replay attacks across different sessions. Of course, when the Group-keyed MAC authentication/integrity check scheme is used, the shared group key SHOULD be changed across sessions if the set of receivers changes.
ここで、いくつかのALCセッションでのリプレイ攻撃について考えてみましょう。 ALCセッションは、{送信者IPアドレスによって一意に識別されます。 TSI}タプル。したがって、特定の送信者が複数のセッションを作成するとき、各TSIがこの送信者のすべてのアクティブなセッション間で、またセッションがアクティブなときに前後に長期間にわたって一意になるように、ALCセッションごとにTSIを変更する必要があります[RFC5651 ]。したがって、異なるセッション間でリプレイ攻撃に直面した場合、ALCを堅牢にすることができます。もちろん、グループキー付きMAC認証/整合性チェックスキームが使用されている場合、レシーバーのセットが変更された場合、共有グループキーをセッション間で変更する必要があります（SHOULD）。
This specification requires that several parameters be communicated to the receiver(s) via an out-of-band mechanism that is beyond the scope of this document. This is in particular the case for the mapping between an ASID value and the associated authentication scheme (Section 1). Since this mapping is critical, this information SHOULD be carried in a secure way from the sender to the receiver(s).
この仕様では、このドキュメントの範囲外のアウトオブバンドメカニズムを介して、いくつかのパラメーターをレシーバーに通信する必要があります。これは特に、ASID値と関連する認証方式の間のマッピングの場合に当てはまります（セクション1）。このマッピングは重要であるため、この情報は送信者から受信者への安全な方法で運ばれる必要があります。
The author is grateful to the authors of [RFC4303], [RFC4359], [RFC4754], and [RFC5480]; their documents inspired several sections of the present document. The author is also grateful to all the IESG members, and in particular to David Harrington, Stephen Farrell, and Sean Turner for their very detailed reviews.
著者は、[RFC4303]、[RFC4359]、[RFC4754]、および[RFC5480]の著者に感謝しています。彼らの文書は、現在の文書のいくつかのセクションに影響を与えました。著者はまた、すべてのIESGメンバー、特に、David Harrington、Stephen Farrell、およびSean Turnerの非常に詳細なレビューに感謝しています。
[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：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[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月。
[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、「Layered Coding Transport（LCT）Building Block」、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-Oriented Reliable Multicast（NORM）Transport Protocol」、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、「Asynchronous Layered Coding（ALC）Protocol Instantiation」、RFC 5775、2010年4月。
[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 Cryptography Specifications Version 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]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年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、「Timed Efficient Stream Loss-Tolerant Authentication（TESLA）：Multicast Source Authentication Transform Introduction」、RFC 4082、 2005年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[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月。
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007.
[RFC4754] Fu、D。およびJ. Solinas、「楕円曲線デジタル署名アルゴリズム（ECDSA）を使用したIKEおよびIKEv2認証」、RFC 4754、2007年1月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号サブジェクト公開鍵情報」、RFC 5480、2009年3月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 5776, April 2010.
[RFC5776] Roca、V.、Francillon、A。、およびS. Faurite、「非同期レイヤードコーディング（ALC）およびNACK指向の信頼性のあるマルチキャスト（NORM）プロトコルでの時限効率的なストリーム損失許容認証（TESLA）の使用」 、RFC 5776、2010年4月。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、2011年2月。
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
[RFC6194] Polk、T.、Chen、L.、Turner、S。、およびP. Hoffman、「SHA-0およびSHA-1メッセージダイジェストアルゴリズムのセキュリティに関する考慮事項」、RFC 6194、2011年3月。
[RMT-FLUTE] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", Work in Progress, March 2012.
[RMT-FLUTE] Paila、T.、Walsh、R.、Luby、M.、Roca、V。、およびR. Lehtonen、「FLUTE-単一方向トランスポートを介したファイル配信」、作業中、2012年3月。
Author's Address
著者のアドレス
Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
ヴィンセントロカINRIA 655、av。イノヴァリーヨーロッパの; Montbonnot ST ISMIER cedex 38334フランス
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/