[要約] RFC 8750は、ESP（Encapsulating Security Payload）でのカウンタベースの暗号に対する暗黙のIV（初期化ベクトル）に関する要件を定義しています。このRFCの目的は、カウンタベースの暗号を使用する際にセキュリティを向上させるための明確なガイドラインを提供することです。
Internet Engineering Task Force (IETF) D. Migault
Request for Comments: 8750 Ericsson
Category: Standards Track T. Guggemos
ISSN: 2070-1721 LMU Munich
Y. Nir
Dell Technologies
March 2020
Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)
カプセル化セキュリティペイロード（ESP）のカウンターベースの暗号の暗黙的な初期化ベクトル（IV）
Abstract
概要
Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written. When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case of AES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this.
カプセル化セキュリティペイロード（ESP）は、各パケットで初期化ベクトル（IV）を送信します。 IVのサイズは適用される変換に依存し、通常、このドキュメントが作成されたときに定義された変換の8または16オクテットです。 IPsecと共に使用する場合、AES-GCM、AES-CCM、ChaCha20-Poly1305などの一部のアルゴリズムは、IVを取得して、暗号化および復号化の入力パラメーターとして使用されるナンスを生成します。このIVは一意である必要がありますが、予測可能です。その結果、ESPシーケンス番号（SN）で提供される値を使用して、ナンスを生成できます。これにより、IV自体の送信が回避され、AES-GCM、AES-CCM、およびChaCha20-Poly1305の場合、パケットごとに8オクテットが節約されます。このドキュメントでは、これを行う方法について説明します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8750.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8750で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Requirements Notation
3. Terminology
4. Implicit IV
5. IKEv2 Initiator Behavior
6. IKEv2 Responder Behavior
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
Counter-based AES modes of operation such as AES-CCM [RFC4309] and AES-GCM [RFC4106] require the specification of a nonce for each ESP packet. The same applies for ChaCha20-Poly1305 [RFC7634]. Currently, this nonce is generated thanks to the initialization vector (IV) provided in each ESP packet [RFC4303]. This practice is designated in this document as "explicit IV".
AES-CCM [RFC4309]やAES-GCM [RFC4106]などのカウンターベースのAES動作モードでは、ESPパケットごとにナンスを指定する必要があります。 ChaCha20-Poly1305 [RFC7634]についても同様です。現在、このnonceは、各ESPパケット[RFC4303]で提供される初期化ベクトル（IV）のおかげで生成されます。このプラクティスは、このドキュメントでは「明示的なIV」と呼ばれています。
In some contexts, such as the Internet of Things (IoT), it may be preferable to avoid carrying the extra bytes associated to the IV and instead generate it locally on each peer. The local generation of the IV is designated in this document as "implicit IV".
モノのインターネット（IoT）などの一部のコンテキストでは、IVに関連付けられた余分なバイトを運ばないで、代わりに各ピアでローカルに生成することが望ましい場合があります。 IVのローカル世代は、このドキュメントでは「暗黙のIV」と指定されています。
The size of this IV depends on the specific algorithm, but all of the algorithms mentioned above take an 8-octet IV.
このIVのサイズは特定のアルゴリズムによって異なりますが、上記のすべてのアルゴリズムは8オクテットIVを使用します。
This document defines how to compute the IV locally when it is implicit. It also specifies how peers agree with the Internet Key Exchange version 2 (IKEv2) [RFC7296] on using an implicit IV versus an explicit IV.
このドキュメントでは、暗黙的にIVをローカルで計算する方法を定義します。また、暗黙のIVと明示のIVの使用に関して、ピアがインターネットキーエクスチェンジバージョン2（IKEv2）[RFC7296]にどのように同意するかも指定します。
This document limits its scope to the algorithms mentioned above. Other algorithms with similar properties may later be defined to use similar mechanisms.
このドキュメントでは、その範囲を上記のアルゴリズムに限定しています。同様のプロパティを持つ他のアルゴリズムは、後で同様のメカニズムを使用するように定義できます。
This document does not consider AES-CBC [RFC3602], as AES-CBC requires the IV to be unpredictable. Deriving it directly from the packet counter as described below is insecure, as mentioned in Section 6 of [RFC3602], and has led to real-world chosen plaintext attacks such as BEAST [BEAST].
AES-CBCはIVを予測不能にする必要があるため、このドキュメントではAES-CBC [RFC3602]については考慮していません。 [RFC3602]のセクション6で説明されているように、以下で説明するようにパケットカウンターから直接取得することは安全ではなく、BEAST [BEAST]などの実際に選択された平文攻撃につながっています。
This document does not consider AES-CTR [RFC3686], as it focuses on the recommended Authenticated Encryption with Associated Data (AEAD) suites provided in [RFC8221].
このドキュメントでは、[RFC8221]で提供される関連データ付きの認証済み暗号化（AEAD）スイートに焦点を当てているため、AES-CTR [RFC3686]については考慮していません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
IoT: Internet of Things
IoT：モノのインターネット
IV: Initialization Vector
IV：初期化ベクトル
IIV: Implicit Initialization Vector
7配置された初期化ベクトル
Nonce: A fixed-size octet string used only once. In this document, the IV is used to generate the nonce input for the encryption/decryption.
ノンス：一度だけ使用される固定サイズのオクテット文字列。このドキュメントでは、IVを使用して、暗号化/復号化のためのノンス入力を生成します。
With the algorithms listed in Section 1, the 8-byte IV MUST NOT repeat for a given key. The binding between an ESP packet and its IV is provided using the Sequence Number or the Extended Sequence Number. Figures 1 and 2 represent the IV with a regular 4-byte Sequence Number and an 8-byte Extended Sequence Number, respectively.
セクション1にリストされているアルゴリズムでは、8バイトのIVは特定のキーに対して繰り返されてはなりません。 ESPパケットとそのIV間のバインディングは、シーケンス番号または拡張シーケンス番号を使用して提供されます。図1と2は、それぞれ通常の4バイトのシーケンス番号と8バイトの拡張シーケンス番号を持つIVを表しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Implicit IV with a 4-Byte Sequence Number
図1：4バイトのシーケンス番号を使用した暗黙のIV
Sequence Number: The 4-byte Sequence Number carried in the ESP packet.
シーケンス番号：ESPパケットで運ばれる4バイトのシーケンス番号。
Zero: A 4-byte array with all bits set to zero.
ゼロ：すべてのビットがゼロに設定された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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended |
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Implicit IV with an 8-Byte Extended Sequence Number
図2：8バイトの拡張シーケンス番号を使用した暗黙のIV
Extended Sequence Number: The 8-byte Extended Sequence Number of the Security Association. The four low-order bytes are carried in the ESP packet.
拡張シーケンス番号：セキュリティアソシエーションの8バイトの拡張シーケンス番号。 ESPパケットでは、下位4バイトが伝送されます。
This document solely defines the IV generation of the algorithms defined in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM, and [RFC7634] for ChaCha20-Poly1305. All other aspects and parameters of those algorithms are unchanged and are used as defined in their respective specifications.
このドキュメントでは、AES-GCMの[RFC4106]、AES-CCMの[RFC4309]、ChaCha20-Poly1305の[RFC7634]で定義されているアルゴリズムのIV生成のみを定義しています。これらのアルゴリズムの他のすべての側面とパラメーターは変更されておらず、それぞれの仕様で定義されているとおりに使用されます。
An initiator supporting this feature SHOULD propose implicit IV (IIV) algorithms in the Transform Type 1 (Encryption Algorithm) Substructure of the Proposal Substructure inside the Security Association (SA) payload in the IKEv2 Exchange. To facilitate backward compatibility with non-supporting peers, the initiator SHOULD also include those same algorithms with explicit IV as separate transforms.
この機能をサポートするイニシエーターは、IKEv2 Exchangeのセキュリティアソシエーション（SA）ペイロード内の提案サブ構造の変換タイプ1（暗号化アルゴリズム）サブ構造で暗黙のIV（IIV）アルゴリズムを提案する必要があります（SHOULD）。サポートされていないピアとの下位互換性を促進するために、イニシエーターは、個別の変換として明示的なIVを持つ同じアルゴリズムも含める必要があります（SHOULD）。
The rules of SA payload processing require that the responder pick its algorithms from the proposal sent by the initiator, thus ensuring that the responder will never send an SA payload containing the IIV transform to an initiator that did not propose it.
SAペイロード処理のルールでは、レスポンダがイニシエータから送信された提案からアルゴリズムを選択する必要があるため、IIV変換を含むSAペイロードを、提案者が提案していないイニシエータに送信しないようにします。
Nonce generation for these algorithms has not been explicitly defined. It has been left to the implementation as long as certain security requirements are met. Typically, for AES-GCM, AES-CCM, and ChaCha20-Poly1305, the IV is not allowed to be repeated for one particular key. This document provides an explicit and normative way to generate IVs. The mechanism described in this document meets the IV security requirements of all relevant algorithms.
これらのアルゴリズムのノンス生成は明示的に定義されていません。特定のセキュリティ要件が満たされている限り、実装に任されています。通常、AES-GCM、AES-CCM、およびChaCha20-Poly1305では、特定の1つのキーに対してIVを繰り返すことはできません。このドキュメントは、IVを生成するための明示的で規範的な方法を提供します。このドキュメントで説明するメカニズムは、関連するすべてのアルゴリズムのIVセキュリティ要件を満たしています。
As the IV must not repeat for one SA when Counter-Mode ciphers are used, implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. The sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet for an SA that does not use an Extended Sequence Number and prior to the transmission of the 2^64th packet for an SA that does use an Extended Sequence Number. This prevents Sequence Number overlaps for the mundane point-to-point case. Multicast as described in [RFC5374], [RFC6407], and [G-IKEv2] is a prominent example in which many senders share one secret and thus one SA. As such, implicit IV may only be used with Multicast if some mechanisms are employed that prevent the Sequence Number from overlapping for one SA; otherwise, implicit IV MUST NOT be used with Multicast.
カウンターモード暗号が使用されている場合、IVは1つのSAに対して繰り返されてはならないため、このドキュメントで説明されている暗黙のIVは、1つのSAのシーケンス番号が重複する可能性があるセットアップでは使用してはなりません。送信者のカウンターと受信者のカウンターは、拡張シーケンス番号を使用しないSAの2 ^ 32番目のパケットの送信前、および送信前に、（新しいSAを確立することによって新しいキーを使用して）リセットする必要があります。拡張シーケンス番号を使用するSAの2 ^ 64番目のパケット。これにより、平凡なポイントツーポイントのケースでシーケンス番号が重複するのを防ぎます。 [RFC5374]、[RFC6407]、および[G-IKEv2]で説明されているマルチキャストは、多くの送信者が1つのシークレット、つまり1つのSAを共有する際立った例です。そのため、暗黙のIVは、シーケンス番号が1つのSAで重複しないようにするメカニズムが採用されている場合にのみ、マルチキャストで使用できます。それ以外の場合、暗黙のIVをマルチキャストで使用してはなりません（MUST NOT）。
This document defines three new encryption transforms that use implicit IV. Unlike most encryption transforms defined to date, which can be used for both ESP and IKEv2, these transforms are defined for ESP only and cannot be used in IKEv2. The reason for this is that IKEv2 messages don't contain a unique per-message value that can be used for IV generation. The Message-ID field in the IKEv2 header is similar to the SN field in the ESP header, but recent IKEv2 extensions [RFC6311] [RFC7383] do allow it to repeat, so there is not an easy way to derive unique IV from IKEv2 header fields.
このドキュメントでは、暗黙のIVを使用する3つの新しい暗号化トランスフォームを定義しています。 ESPとIKEv2の両方に使用できる、現在までに定義されているほとんどの暗号化トランスフォームとは異なり、これらのトランスフォームはESPに対してのみ定義されており、IKEv2では使用できません。これは、IKEv2メッセージには、IV生成に使用できる一意のメッセージごとの値が含まれていないためです。 IKEv2ヘッダーのMessage-IDフィールドは、ESPヘッダーのSNフィールドに似ていますが、最近のIKEv2拡張[RFC6311] [RFC7383]で繰り返すことができるため、IKEv2ヘッダーから一意のIVを簡単に導出する方法はありません田畑。
IANA has updated the "Internet Key Exchange Version 2 (IKEv2) Parameters" registry [RFC7296] by adding the following new code points to the "Transform Type 1 - Encryption Algorithm Transform IDs" subregistry under the "Transform Type Values" registry [IANA]:
IANAは、「Transform Type Values」レジストリの下の「Transform Type 1-Encryption Algorithm Transform IDs」サブレジストリに次の新しいコードポイントを追加することにより、「Internet Key Exchange Version 2（IKEv2）Parameters」レジストリ[RFC7296]を更新しました[IANA] ：
+--------+----------------------------+---------------+-----------+
| Number | Name | ESP Reference | IKEv2 |
| | | | Reference |
+========+============================+===============+===========+
| 29 | ENCR_AES_CCM_8_IIV | RFC 8750 | Not |
| | | | allowed |
+--------+----------------------------+---------------+-----------+
| 30 | ENCR_AES_GCM_16_IIV | RFC 8750 | Not |
| | | | allowed |
+--------+----------------------------+---------------+-----------+
| 31 | ENCR_CHACHA20_POLY1305_IIV | RFC 8750 | Not |
| | | | allowed |
+--------+----------------------------+---------------+-----------+
Table 1: Additions to "Transform Type 1 - Encryption Algorithm Transform IDs" Registry
表1：「トランスフォームタイプ1-暗号化アルゴリズムトランスフォームID」レジストリへの追加
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, DOI 10.17487/RFC3602, September 2003, <https://www.rfc-editor.org/info/rfc3602>.
[RFC3602]フランケルS.、グレンR.、およびS.ケリー、「AES-CBC暗号アルゴリズムとIPsecでのその使用」、RFC 3602、DOI 10.17487 / RFC3602、2003年9月、<https：// www。 rfc-editor.org/info/rfc3602>。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, <https://www.rfc-editor.org/info/rfc3686>.
[RFC3686] Housley、R。、「IPsecカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）カウンターモードの使用」、RFC 3686、DOI 10.17487 / RFC3686、2004年1月、<https：//www.rfc-editor。 org / info / rfc3686>。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, DOI 10.17487/RFC4106, June 2005, <https://www.rfc-editor.org/info/rfc4106>.
[RFC4106] Viega、J。およびD. McGrew、「The Use of Galois / Counter Mode（GCM）in IPsec Encapsulating Security Payload（ESP）」、RFC 4106、DOI 10.17487 / RFC4106、2005年6月、<https：// www .rfc-editor.org / info / rfc4106>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<https://www.rfc-editor.org/info/rfc4303>。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, DOI 10.17487/RFC4309, December 2005, <https://www.rfc-editor.org/info/rfc4309>.
[RFC4309] Housley、R。、「IPsecカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）CCMモードの使用」、RFC 4309、DOI 10.17487 / RFC4309、2005年12月、<https：//www.rfc-editor。 org / info / rfc4309>。
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, <https://www.rfc-editor.org/info/rfc5374>.
[RFC5374] Weis、B.、Gross、G。、およびD. Ignjatic、「インターネットプロトコルのセキュリティアーキテクチャに対するマルチキャスト拡張」、RFC 5374、DOI 10.17487 / RFC5374、2008年11月、<https：//www.rfc -editor.org/info/rfc5374>。
[RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D. Zhang, "Protocol Support for High Availability of IKEv2/ IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011, <https://www.rfc-editor.org/info/rfc6311>.
[RFC6311] Singh、R.、Ed。、Kalyani、G.、Nir、Y.、Sheffer、Y.、and D. Zhang、 "Protocol Support for High Availability of IKEv2 / IPsec"、RFC 6311、DOI 10.17487 / RFC6311 、2011年7月、<https://www.rfc-editor.org/info/rfc6311>。
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[RFC6407] Weis、B.、Rowles、S.、T。Hardjono、「The Group Domain of Interpretation」、RFC 6407、DOI 10.17487 / RFC6407、2011年10月、<https://www.rfc-editor.org/ info / rfc6407>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<https://www.rfc-editor.org/info/rfc7296>。
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, <https://www.rfc-editor.org/info/rfc7383>.
[RFC7383] Smyslov、V。、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）メッセージの断片化」、RFC 7383、DOI 10.17487 / RFC7383、2014年11月、<https://www.rfc-editor.org/info/rfc7383> 。
[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, DOI 10.17487/RFC7634, August 2015, <https://www.rfc-editor.org/info/rfc7634>.
[RFC7634] Nir、Y。、「ChaCha20、Poly1305、およびインターネットキー交換プロトコル（IKE）およびIPsecでのそれらの使用」、RFC 7634、DOI 10.17487 / RFC7634、2015年8月、<https：//www.rfc-editor .org / info / rfc7634>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017, <https://www.rfc-editor.org/info/rfc8221>.
[RFC8221] Wouters、P.、Migault、D.、Mattsson、J.、Nir、Y。、およびT. Kivinen、「暗号化アルゴリズムの実装要件およびカプセル化セキュリティペイロード（ESP）および認証ヘッダー（AH）の使用ガイダンス」 、RFC 8221、DOI 10.17487 / RFC8221、2017年10月、<https://www.rfc-editor.org/info/rfc8221>。
[BEAST] Duong, T. and J. Rizzo, "Here Come The xor Ninjas", May 2011, <https://www.researchgate.net/ publication/266529975_Here_Come_The_Ninjas>.
[BEAST] Duong、T.およびJ. Rizzo、「Here Come The xor Ninjas」、2011年5月、<https://www.researchgate.net/ publication / 266529975_Here_Come_The_Ninjas>。
[G-IKEv2] Weis, B. and V. Smyslov, "Group Key Management using IKEv2", Work in Progress, Internet-Draft, draft-ietf-ipsecme-g-ikev2-00, 8 January 2020, <https://tools.ietf.org/html/draft-ietf-ipsecme-g-ikev2-00>.
[G-IKEv2] Weis、B。およびV. Smyslov、「IKEv2を使用したグループキー管理」、作業中、インターネットドラフト、draft-ietf-ipsecme-g-ikev2-00、2020年1月8日、<https：/ /tools.ietf.org/html/draft-ietf-ipsecme-g-ikev2-00>。
[IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <https://www.iana.org/assignments/ikev2-parameters>.
[IANA] IANA、「インターネットキーエクスチェンジバージョン2（IKEv2）パラメーター」、<https://www.iana.org/assignments/ikev2-parameters>。
Acknowledgements
謝辞
We would like to thank Valery Smyslov, Éric Vyncke, Alexey Melnikov, Adam Roach, and Magnus Nyström (security directorate) as well as our three Security ADs -- Eric Rescorla, Benjamin Kaduk, and Roman Danyliw -- for their valuable comments. We also would like to thank David Schinazi for his implementation as well as Tero Kivinen and David Waltermire (the IPSECME Chairs) for moving this work forward.
Valery Smyslov、ÉricVyncke、Alexey Melnikov、Adam Roach、およびMagnusNyström（セキュリティ総局）のほか、Eric Rescorla、Benjamin Kaduk、Roman Danyliwの3人のセキュリティADに貴重なコメントをいただき、ありがとうございました。また、David Schinazi氏の実装と、この作業を前進させてくれたTero Kivinen氏とDavid Waltermire（IPSECME議長）にも感謝します。
Authors' Addresses
著者のアドレス
Daniel Migault Ericsson 8275 Trans Canada Route Saint Laurent QC H4S 0B6 Canada
Daniel Migault Ericsson 8275 Trans Canada Route Saint Laurent QC H4S 0B6 Canada
Email: daniel.migault@ericsson.com
Tobias Guggemos LMU Munich Oettingenstr. 67 80538 Munich Germany
Tobias Guggemos LMUミュンヘンOettingenstr。 67 80538ドイツミュンヘン
Email: guggemos@nm.ifi.lmu.de
URI: http://mnm-team.org/~guggemos
Yoav Nir Dell Technologies 9 Andrei Sakharov St Haifa 3190500 Israel
Yoav Nir Dell Technologies 9 Andrei Sakharov St Haifa 3190500 Israel
Email: ynir.ietf@gmail.com