[要約] RFC 9370 は、IKEv2 に複数の鍵交換を許可する方法を記述し、IKE_SA のセットアップ中に共有シークレットを計算する際に複数の鍵交換を行うことを可能にします。この文書は、IKE_SA の確立時に複数の鍵交換を行うために IKE_INTERMEDIATE 交換を使用し、IKE SA が再鍵交換されるか追加の Child SA が作成される際に同じ目的で IKE_FOLLOWUP_KE 交換を導入します。
Internet Engineering Task Force (IETF) CJ. Tjhai
Request for Comments: 9370 M. Tomlinson
Updates: 7296 Post-Quantum
Category: Standards Track G. Bartlett
ISSN: 2070-1721 Quantum Secret
S. Fluhrer
Cisco Systems
D. Van Geest
ISARA Corporation
O. Garcia-Morchon
Philips
V. Smyslov
ELVIS-PLUS
May 2023
This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup.
このドキュメントでは、インターネットキーエクスチェンジプロトコルバージョン2（IKEV2）を拡張して、セキュリティ協会（SA）のセットアップ中に共有秘密を計算しながら複数のキー交換が行われるようにする方法について説明します。
This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs.
このドキュメントでは、IKE_INTERMEDIATE Exchangeを利用しています。この交換では、IKE SAが確立されているときに複数のキー交換が実行されます。また、新しいIKEV2 ExchangeであるIKE_Followup_keも導入されます。IKESAが再キーになっているか、追加の子SASを作成している場合、同じ目的で使用されます。
This document updates RFC 7296 by renaming a Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2.
このドキュメントは、「Diffie-Hellman Group（D-H）」から「Key Exchange Method（KE）」に変換タイプ4を改名し、キーエクスチェンジペイロードのフィールドを「Diffie-Hellman Group Num」から「キー」に変更することにより、RFC 7296を更新します。交換方法」。また、この変換タイプのIANAレジストリを「変換タイプ4- Diffie -Hellmanグループ変換ID」から「タイプ4-キー交換メソッド変換ID」に変更します。これらの変更は、IKEV2で使用できる主要な交換アルゴリズムを一般化します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc9370.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9370で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Problem Description
1.2. Proposed Extension
1.3. Document Organization
2. Multiple Key Exchanges
2.1. Design Overview
2.2. Protocol Details
2.2.1. IKE_SA_INIT Round: Negotiation
2.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges
2.2.3. IKE_AUTH Exchange
2.2.4. CREATE_CHILD_SA Exchange
2.2.5. Interaction with IKEv2 Extensions
3. IANA Considerations
4. Security Considerations
5. References
5.1. Normative References
5.2. Informative References
Appendix A. Sample Multiple Key Exchanges
A.1. IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange
Payloads
A.2. No Additional Key Exchange Used
A.3. Additional Key Exchange in the CREATE_CHILD_SA Exchange
Only
A.4. No Matching Proposal for Additional Key Exchanges
Appendix B. Design Criteria
Appendix C. Alternative Design
Acknowledgements
Authors' Addresses
The Internet Key Exchange Protocol version 2 (IKEv2), as specified in [RFC7296], uses the Diffie-Hellman (DH) or the Elliptic Curve Diffie-Hellman (ECDH) algorithm, which shall be referred to as "(EC)DH" collectively, to establish a shared secret between an initiator and a responder. The security of the (EC)DH algorithms relies on the difficulty to solve a discrete logarithm problem in multiplicative (and, respectively, elliptic curve) groups when the order of the group parameter is large enough. While solving such a problem remains infeasible with current computing power, it is believed that general-purpose quantum computers will be able to solve this problem, implying that the security of IKEv2 is compromised. There are, however, a number of cryptosystems that are conjectured to be resistant to quantum-computer attacks. This family of cryptosystems is known as "post-quantum cryptography" (or "PQC"). It is sometimes also referred to as "quantum-safe cryptography" (or "QSC") or "quantum-resistant cryptography" (or "QRC").
[RFC7296]で指定されているインターネットキー交換プロトコルバージョン2（IKEV2）は、diffie-hellman（dh）または楕円曲線diffie-hellman（ecdh）アルゴリズムを使用します。集合的に、イニシエーターとレスポンダーの間に共有された秘密を確立します。（EC）DHアルゴリズムのセキュリティは、グループパラメーターの順序が十分に大きい場合、乗算的（およびそれぞれ楕円曲線）グループの離散対数問題を解決するのが難しいことに依存しています。このような問題を解決することは現在のコンピューティング能力では実行不可能ですが、一般的な量子コンピューターはこの問題を解決できると考えられており、IKEV2のセキュリティが侵害されていることを意味します。ただし、量子コンピューター攻撃に耐性があると推測される多くの暗号システムがあります。この暗号系のファミリーは、「Quantum後の暗号」（または「PQC」）として知られています。また、「量子セーフ暗号」（または「QSC」）または「量子耐性暗号」（または「QRC」）とも呼ばれることもあります。
It is essential to have the ability to perform one or more post-quantum key exchanges in conjunction with an (EC)DH key exchange so that the resulting shared key is resistant to quantum-computer attacks. Since there is currently no post-quantum key exchange that is as well-studied as (EC)DH, performing multiple key exchanges with different post-quantum algorithms along with the well-established classical key-exchange algorithms addresses this concern, since the overall security is at least as strong as each individual primitive.
結果として得られる共有キーが量子コンピューター攻撃に耐性があるように、（EC）DHキー交換と組み合わせて、1つ以上のカントゥム後のキー交換を実行できることが不可欠です。現在、（EC）DHと同様に研究されている質量のキー交換はないため、さまざまな四半期後のアルゴリズムを使用して複数のキー交換を実行し、確立された古典的なキーエクスチャンツアルゴリズムがこの懸念に対処します。セキュリティは、少なくとも個々の原始と同じくらい強力です。
This document describes a method to perform multiple successive key exchanges in IKEv2. This method allows integration of PQC in IKEv2, while maintaining backward compatibility, to derive a set of IKE keys that is resistant to quantum-computer attacks. This extension allows the negotiation of one or more PQC algorithms to exchange data, in addition to the existing (EC)DH key exchange data. It is believed that the feature of using more than one post-quantum algorithm is important, as many of these algorithms are relatively new, and there may be a need to hedge the security risk with multiple key exchange data from several distinct PQC algorithms.
このドキュメントでは、IKEV2で複数の連続したキー交換を実行する方法について説明します。この方法により、後方互換性を維持しながら、IKEV2でのPQCの統合を可能にし、量子コンピューター攻撃に耐性のあるIKEキーのセットを導き出します。この拡張機能により、既存の（EC）DHキー交換データに加えて、1つまたは複数のPQCアルゴリズムとデータを交換する交渉が可能になります。これらのアルゴリズムの多くは比較的新しいものであり、いくつかの異なるPQCアルゴリズムからの複数のキー交換データを使用してセキュリティリスクをヘッジする必要があるため、複数の質量後アルゴリズムを使用することの特徴が重要であると考えられています。
IKE peers perform multiple successive key exchanges to establish an IKE SA. Each exchange produces some shared secret, and these secrets are combined in a way such that:
IKEピアは、IKE SAを確立するために複数の連続したキー交換を実行します。各交換は共有された秘密を生み出し、これらの秘密は次のような方法で組み合わされています。
(a) the final shared secret is computed from all of the component key exchange secrets;
(a) 最終的な共有秘密は、すべてのコンポーネントキーエクスチェンジシークレットから計算されます。
(b) unless both peers support and agree to use the additional key exchanges introduced in this specification, the final shared secret equivalent to the shared secret specified in [RFC7296] is obtained; and
(b) 両方のピアがこの仕様で導入された追加のキー交換をサポートし、使用することに同意しない限り、[RFC7296]で指定された共有秘密に相当する最終的な共有の秘密が得られます。そして
(c) if any part of the component key exchange method is a post-quantum algorithm, the final shared secret is post-quantum secure.
(c) コンポーネントのキー交換方法の一部が質量後アルゴリズムである場合、最終的な共有秘密は後Quantum後の安全です。
Some post-quantum key exchange payloads may have sizes larger than the standard maximum transmission unit (MTU) size. Therefore, there could be issues with fragmentation at the IP layer. In order to allow the use of those larger payload sizes, this mechanism relies on the IKE_INTERMEDIATE exchange as specified in [RFC9242]. With this mechanism, the key exchange is initiated using a smaller, possibly classical primitive, such as (EC)DH. Then, before the IKE_AUTH exchange, one or more IKE_INTERMEDIATE exchanges are carried out, each of which contains an additional key exchange. As the IKE_INTERMEDIATE exchange is encrypted, the IKE fragmentation protocol [RFC7383] can be used. The IKE SK_* values are updated after each exchange, as described in Section 2.2.2; thus, the final IKE SA keys depend on all the key exchanges. Hence, the keys are secure if any of the key exchanges are secure.
一部の四分位のキーエクスチェンジペイロードは、標準の最大透過ユニット（MTU）サイズよりも大きいサイズを持っている場合があります。したがって、IPレイヤーで断片化に問題がある可能性があります。これらの大きなペイロードサイズを使用できるようにするために、このメカニズムは[RFC9242]で指定されているIKE_INTERMEDIATE Exchangeに依存しています。このメカニズムにより、キー交換は、（EC）DHなどのより小さく、おそらく古典的な原始を使用して開始されます。次に、IKE_AUTH Exchangeの前に、1つ以上のIKE_INTERMEDIATE Exchangeが実行され、それぞれに追加のキー交換が含まれています。ike_intermediate Exchangeが暗号化されるため、IKEフラグメンテーションプロトコル[RFC7383]を使用できます。セクション2.2.2で説明されているように、IKE SK_*値は、各交換の後に更新されます。したがって、最終的なIke SAキーはすべてのキー交換に依存します。したがって、キー交換のいずれかが安全である場合、キーは安全です。
While this extension is primarily aimed at IKE SAs due to the potential fragmentation issue discussed above, it also applies to CREATE_CHILD_SA exchanges as illustrated in Section 2.2.4 for creating/rekeying of Child SAs and rekeying of IKE SAs.
この拡張機能は、主に上記の断片化の潜在的な問題のためにIKE SASを対象としていますが、セクション2.2.4に示されているように、CREATE_CHILD_SA交換にも適用され、子SASの作成/再キーを作成し、IKE SASの再キーを作成します。
Note that readers should consider the approach defined in this document as providing a long-term solution in upgrading the IKEv2 protocol to support post-quantum algorithms. A short-term solution to make IKEv2 key exchange quantum secure is to use post-quantum pre-shared keys as specified in [RFC8784].
読者は、このドキュメントで定義されているアプローチを、IKEV2プロトコルのアップグレードを提供して、Quantum後アルゴリズムをサポートするために長期的なソリューションを提供すると考える必要があることに注意してください。IKEV2キー交換量子安全性を作成するための短期的なソリューションは、[RFC8784]で指定されているように、測量後の事前共有キーを使用することです。
Note also that the proposed approach of performing multiple successive key exchanges in such a way, when the resulting session keys depend on all of them, is not limited to only addressing the threat of quantum computers. It can also be used when all of the performed key exchanges are classical (EC)DH primitives, where, for various reasons (e.g., policy requirements), it is essential to perform multiple key exchanges.
また、結果のセッションキーがそれらすべてに依存する場合、そのような方法で複数の連続したキー交換を実行するという提案されたアプローチは、量子コンピューターの脅威のみに対処することに限定されないことに注意してください。また、実行されたすべてのキー交換が古典的（EC）DHプリミティブである場合にも使用できます。ここで、さまざまな理由（ポリシー要件など）で複数のキー交換を実行することが不可欠です。
This specification does not attempt to address key exchanges with KE payloads longer than 64 KB; the current IKE payload format does not allow such a possibility. At the time of writing, it appears likely that there are a number of key exchanges available that would not have such a requirement. [BEYOND-64K] discusses approaches that could be taken to exchange huge payloads if such a requirement were needed.
この仕様では、64 kbを超えるKEペイロードとのキー交換に対処しようとはしません。現在のIKEペイロード形式では、そのような可能性は許可されていません。執筆時点では、そのような要件がないような多くの主要な交換が利用可能である可能性が高いようです。[64Kを超えて]そのような要件が必要な場合、巨大なペイロードを交換するために取られる可能性のあるアプローチについて説明します。
The remainder of this document is organized as follows. Section 2 describes how multiple key exchanges are performed between two IKE peers and how keying materials are derived for both SAs and Child SAs. Section 3 discusses IANA considerations for the namespaces introduced in this document. Section 4 discusses security considerations. In the Appendices, some examples of multiple key exchanges are illustrated in Appendix A. Appendix B summarizes design criteria and alternative approaches that have been considered. These approaches are later discarded, as described in Appendix C.
このドキュメントの残りの部分は、次のように整理されています。セクション2では、2つのIKEピア間で複数のキー交換がどのように実行され、SASと子SASの両方でキーイング素材がどのように導出されるかについて説明します。セクション3では、このドキュメントで導入された名前空間のIANAの考慮事項について説明します。セクション4では、セキュリティ上の考慮事項について説明します。付録では、複数のキー交換の例をいくつかの例を付録Aに示します。付録Bは、考慮された設計基準と代替アプローチをまとめたものです。付録Cで説明されているように、これらのアプローチは後で破棄されます。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Most post-quantum key agreement algorithms are relatively new. Thus, they are not fully trusted. There are also many proposed algorithms that have different trade-offs and that rely on different hard problems. The concern is that some of these hard problems may turn out to be easier to solve than anticipated; thus, the key agreement algorithm may not be as secure as expected. A hybrid solution, when multiple key exchanges are performed and the calculated shared key depends on all of them, allows us to deal with this uncertainty by combining a classical key exchange with a post-quantum one, as well as leaving open the possibility of combining it with multiple post-quantum key exchanges.
ほとんどの質量契約契約アルゴリズムは比較的新しいものです。したがって、それらは完全に信頼されていません。また、さまざまなトレードオフを持ち、異なる困難な問題に依存する多くの提案されたアルゴリズムもあります。懸念は、これらの困難な問題のいくつかは、予想よりも解決しやすいことが判明する可能性があるということです。したがって、主要な合意アルゴリズムは、予想ほど安全ではない場合があります。ハイブリッドソリューションは、複数のキー交換が実行され、計算された共有キーがそれらのすべてに依存する場合、古典的なキー交換と後Quantumの交換を組み合わせることで、この不確実性に対処することができます。それは、複数の質量のキー交換を伴います。
In order to be able to use IKE fragmentation [RFC7383] for those key exchanges that may have long public keys, this specification utilizes the IKE_INTERMEDIATE exchange defined in [RFC9242]. The initial IKE_SA_INIT messages do not have any inherent fragmentation support within IKE. However, IKE_SA_INIT messages can include a relatively short KE payload. The additional key exchanges are performed using IKE_INTERMEDIATE messages that follow the IKE_SA_INIT exchange. This is to allow the standard IKE fragmentation mechanisms (which cannot be used in IKE_SA_INIT) to be available for the potentially large Key Exchange payloads with post-quantum algorithm data.
長い公開キーを持つ可能性のある重要な交換にIKEフラグメンテーション[RFC7383]を使用できるようにするために、この仕様は[RFC9242]で定義されたIKE_INTERMEDIATE Exchangeを利用します。最初のIKE_SA_INITメッセージには、IKE内に固有の断片化サポートがありません。ただし、IKE_SA_INITメッセージには、比較的短いKEペイロードを含めることができます。追加のキー交換は、IKE_SA_INIT Exchangeに従うIKE_INTERMEDIATEメッセージを使用して実行されます。これは、標準のIKEフラグメンテーションメカニズム（IKE_SA_INITで使用できない）を、Quantum後アルゴリズムデータを使用して潜在的に大規模なキーエクスチェンジペイロードに利用できるようにするためです。
Note that this document assumes that each key exchange method requires one round trip and consumes exactly one IKE_INTERMEDIATE exchange. This assumption is valid for all classic key exchange methods defined so far and for all post-quantum methods currently known. For hypothetical future key exchange methods that require multiple round trips to complete, a separate document should define how such methods are split into several IKE_INTERMEDIATE exchanges.
このドキュメントでは、各キーエクスチェンジ方法には1回の往復が必要であり、IKE_INTERMEDIATE Exchangeが1つだけ消費することを想定しています。この仮定は、これまでに定義されているすべての古典的なキー交換方法と、現在既知のすべての測量後の方法に対して有効です。複数のラウンド旅行を完了する必要がある仮説的な将来の主要な交換方法の場合、個別のドキュメントは、そのような方法がいくつかのIKE_INTERMEDIATE取引所にどのように分割されるかを定義する必要があります。
In order to minimize communication overhead, only the key shares that are agreed upon are actually exchanged. To negotiate additional key exchanges, seven new Transform Types are defined. These transforms and Transform Type 4 share the same Transform IDs.
通信オーバーヘッドを最小限に抑えるために、合意された主要株のみが実際に交換されます。追加のキー交換を交渉するために、7つの新しい変換タイプが定義されています。これらの変換と変換タイプ4は、同じ変換IDを共有します。
It is assumed that new Transform Type 4 identifiers will be assigned later for various post-quantum key exchanges [IKEV2TYPE4ID]. This specification does not make a distinction between classical (EC)DH and post-quantum key exchanges, nor between post-quantum algorithms that are true key exchanges and post-quantum algorithms that act as key transport mechanisms: all are treated equivalently by the protocol. This document renames a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". This document also renames Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)". The corresponding renaming to the IANA registry is described in Section 3.
新しい変換タイプ4識別子は、さまざまな四分位のキー交換[IKEV2Type4ID]に後で割り当てられると想定されています。この仕様は、クラシック（EC）DHとQuantum後のキー交換を区別するものではなく、真のキー交換と主要な輸送メカニズムとして機能する四分位のアルゴリズムとの間も区別しません。すべてがプロトコルによって同等に扱われます。。このドキュメントは、キーエクスチェンジペイロードのフィールドを「diffie-hellman group num」から「キー交換方法」に変更します。また、このドキュメントは、変換タイプ4を「diffie-hellmanグループ（D-H）」から「キー交換方法（KE）」に改名します。IANAレジストリに対応する名前の変更については、セクション3で説明します。
The fact that newly defined transforms share the same registry for possible Transform IDs with Transform Type 4 allows additional key exchanges to be of any type: either post-quantum or classical (EC)DH. This approach allows any combination of the defined key exchange methods to take place. This also allows IKE peers to perform a single post-quantum key exchange in the IKE_SA_INIT without additional key exchanges, provided that the IP fragmentation is not an issue and that hybrid key exchange is not needed.
新たに定義された変換が、タイプ4を使用して可能な変換IDと同じレジストリを共有するという事実により、追加のキー交換は、ポストQuantumまたはClassical（EC）DHのいずれかのタイプになります。このアプローチにより、定義されたキー交換方法の任意の組み合わせが行われます。これにより、IKEの断片化が問題ではなく、ハイブリッドキー交換が必要ない場合、IKEピアは追加のキー交換なしでIKE_SA_INITで1回の質量キーエクスチェンジを実行することができます。
The SA payload in the IKE_SA_INIT message includes one or more newly defined transforms that represent the extra key exchange policy required by the initiator. The responder follows the usual IKEv2 negotiation rules: it selects a single transform of each type and returns all of them in the IKE_SA_INIT response message.
IKE_SA_INITメッセージのSAペイロードには、イニシエーターが必要とする追加のキー交換ポリシーを表す1つ以上の新たに定義された変換が含まれています。レスポンダーは、通常のIKEV2ネゴシエーションルールに従います。各タイプの単一の変換を選択し、IKE_SA_INIT応答メッセージでそれらすべてを返します。
Then, provided that additional key exchanges are negotiated, the initiator and the responder perform one or more IKE_INTERMEDIATE exchanges. Following that, the IKE_AUTH exchange authenticates peers and completes IKE SA establishment.
次に、追加のキー交換が交渉され、イニシエーターとレスポンダーが1つまたは複数のIKE_INTERMEDIATE EXCHANGEを実行します。それに続いて、IKE_AUTH Exchangeはピアを認証し、IKE SAの設立を完了します。
Initiator Responder
---------------------------------------------------------------------
<-- IKE_SA_INIT (additional key exchanges negotiation) -->
<-- {IKE_INTERMEDIATE (additional key exchange)} -->
...
<-- {IKE_INTERMEDIATE (additional key exchange)} -->
<-- {IKE_AUTH} -->
In the simplest case, the initiator starts a single key exchange (and has no interest in supporting multiple), and it is not concerned with possible fragmentation of the IKE_SA_INIT messages (because either the key exchange that it selects is small enough not to fragment or the initiator is confident that fragmentation will be handled either by IP fragmentation or by transport via TCP).
最も単純な場合、イニシエーターは単一のキー交換を開始します（そして複数をサポートすることに興味がありません）、IKE_SA_INITメッセージの断片化の可能性には関係ありません（選択するキー交換は、断片化するのに十分なほど小さいか、またはイニシエーターは、断片化がIP断片化またはTCPを介した輸送のいずれかによって処理されると確信しています。
In this case, the initiator performs the IKE_SA_INIT for a single key exchange using a Transform Type 4 (possibly with a post-quantum algorithm) and including the initiator KE payload. If the responder accepts the policy, it responds with an IKE_SA_INIT response, and IKE continues as usual.
この場合、イニシエーターは、Transform Type 4（おそらく後Quantumアルゴリズムを使用）を使用して単一のキーエクスチェンジでIKE_SA_INITを実行し、イニシエーターKEペイロードを含みます。レスポンダーがポリシーを受け入れると、IKE_SA_INIT応答で応答し、IKEは通常どおり継続します。
If the initiator wants to negotiate multiple key exchanges, then the initiator uses the protocol behavior listed below.
イニシエーターが複数のキー交換を交渉したい場合、イニシエーターは以下にリストされているプロトコル動作を使用します。
Multiple key exchanges are negotiated using the standard IKEv2 mechanism via SA payload. For this purpose, seven new transform types are defined: Additional Key Exchange 1 (ADDKE1) with IANA-assigned value 6, Additional Key Exchange 2 (ADDKE2) (7), Additional Key Exchange 3 (ADDKE3) (8), Additional Key Exchange 4 (ADDKE4) (9), Additional Key Exchange 5 (ADDKE5) (10), Additional Key Exchange 6 (ADDKE6) (11), and Additional Key Exchange 7 (ADDKE7) (12). They are collectively called "Additional Key Exchange (ADDKE) Transform Types" in this document and have slightly different semantics than the existing IKEv2 Transform Types. They are interpreted as an indication of additional key exchange methods that peers agree to perform in a series of IKE_INTERMEDIATE exchanges following the IKE_SA_INIT exchange. The allowed Transform IDs for these transform types are the same as the IDs for Transform Type 4, so they all share a single IANA registry for Transform IDs.
SAペイロードを介して標準のIKEV2メカニズムを使用して、複数のキー交換が交渉されます。この目的のために、7つの新しい変換タイプが定義されています：IANAが割り当てられた値6を備えた追加のキーエクスチェンジ1（ADDKE1）、追加のキーエクスチェンジ2（ADDKE2）（7）、追加のキーエクスチェンジ3（ADDKE3）（8）、追加のキー交換4（addke4）（9）、追加のキーエクスチェンジ5（addke5）（10）、追加のキーエクスチェンジ6（addke6）（11）、および追加のキー交換7（addke7）（12）。これらは、このドキュメントでは「追加のキーエクスチェンジ（ADDKE）変換タイプ」と集合的に呼ばれ、既存のIKEV2変換タイプとはわずかに異なるセマンティクスを持っています。それらは、IKE_SA_INIT Exchangeに続いて、ピアがIKE_INTERMEDIATE Exchangeで実行することに同意する追加の主要な交換方法の兆候として解釈されます。これらの変換タイプの許可された変換IDは、Transform Type 4のIDSと同じであるため、すべてTransform IDの単一のIANAレジストリを共有しています。
The key exchange method negotiated via Transform Type 4 always takes place in the IKE_SA_INIT exchange, as defined in [RFC7296]. Additional key exchanges negotiated via newly defined transforms MUST take place in a series of IKE_INTERMEDIATE exchanges following the IKE_SA_INIT exchange, performed in an order of the values of their Transform Types. This is so that the key exchange negotiated using Additional Key Exchange i always precedes that of Additional Key Exchange i + 1. Each additional key exchange method MUST be fully completed before the next one is started.
[RFC7296]で定義されているように、変換タイプ4を介して交渉された主要な交換方法は、IKE_SA_INIT Exchangeで常に行われます。新たに定義された変革を介して交渉された追加のキー交換は、IKE_SA_INIT Exchangeに続く一連のIKE_INTERMEDIATE Exchangeで行われ、変換型の値の順序で実行されなければなりません。これは、追加のキーエクスチェンジを使用して交渉されたキーエクスチェンジが、常に追加のキーエクスチェンジIの先に先行するようにするためです。追加のキー交換方法は、次のキー交換方法を開始する前に完全に完了する必要があります。
With these semantics, note that ADDKE Transform Types are not associated with any particular type of key exchange and do not have any Transform IDs that are specific per Transform Type IANA registry. Instead, they all share a single registry for Transform IDs, namely "Transform Type 4 - Key Exchange Method Transform IDs". All key exchange algorithms (both classical or post-quantum) should be added to this registry. This approach gives peers flexibility in defining the ways they want to combine different key exchange methods.
これらのセマンティクスを使用すると、Addke変換タイプは特定のタイプのキーエクスチェンジに関連付けられておらず、Transmince Type IANAレジストリごとに特定の変換IDがないことに注意してください。代わりに、それらはすべて、変換IDの単一のレジストリ、すなわち「タイプ4-キーエクスチェンジメソッド変換ID」を共有します。すべてのキーエクスチェンジアルゴリズム（クラシックまたはポストカントゥムの両方）をこのレジストリに追加する必要があります。このアプローチは、異なる主要な交換方法を組み合わせる方法を定義する際に、ピアが柔軟に柔軟に行うことができます。
When forming a proposal, the initiator adds transforms for the IKE_SA_INIT exchange using Transform Type 4. In most cases, they will contain classical (EC)DH key exchange methods, but that is not a requirement. Additional key exchange methods are proposed using ADDKE Transform Types. All of these transform types are optional; the initiator is free to select any of them for proposing additional key exchange methods. Consequently, if none of the ADDKE Transform Types are included in the proposal, then this proposal indicates the performing of standard IKEv2, as defined in [RFC7296]. On the other hand, if the initiator includes any ADDKE Transform Type in the proposal, the responder MUST select one of the algorithms proposed using this type. Note that this is not a new requirement; this behavior is already specified in Section 2.7 of [RFC7296]. A Transform ID NONE MAY be added to those transform types that contain key exchange methods which the initiator believes are optional according to its local policy.
提案を形成するとき、イニシエーターは、Transform Type 4を使用してIKE_SA_INIT Exchangeの変換を追加します。追加のキー交換方法は、Addke Transformタイプを使用して提案されています。これらの変換タイプはすべてオプションです。イニシエーターは、追加のキー交換方法を提案するためにそれらのいずれかを自由に選択できます。したがって、[RFC7296]で定義されているように、この提案はAddke変換タイプが提案に含まれていない場合、標準のIKEV2の実行を示します。一方、イニシエーターに提案にaddke変換タイプが含まれている場合、レスポンダーはこのタイプを使用して提案されたアルゴリズムの1つを選択する必要があります。これは新しい要件ではないことに注意してください。この動作は、[RFC7296]のセクション2.7ですでに指定されています。変換IDは、イニシエーターがそのローカルポリシーに従ってオプションであると考えている主要な交換方法を含む変換タイプに追加される場合があります。
The responder performs the negotiation using the standard IKEv2 procedure described in Section 3.3 of [RFC7296]. However, for the ADDKE Transform Types, the responder's choice MUST NOT contain duplicated algorithms (those with an identical Transform ID and attributes), except for the Transform ID of NONE. An algorithm is represented as a transform. In some cases, the transform could include a set of associated attributes that define details of the algorithm. In this case, two transforms can be the same, but the attributes must be different. Additionally, the order of the attributes does not affect the equality of the algorithm, so the following two transforms define the same algorithm: "ID=alg1, ATTR1=attr1, ATTR2=attr2" and "ID=alg1, ATTR2=attr2, ATTR1=attr1". If the responder is unable to select algorithms that are not duplicated for each proposed key exchange (either because the proposal contains too few choices or due to the local policy restrictions on using the proposed algorithms), then the responder MUST reject the message with an error notification of type NO_PROPOSAL_CHOSEN. If the responder's message contains one or more duplicated choices, the initiator should log the error and MUST treat the exchange as failed. The initiator MUST NOT initiate any IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE) exchanges so that no new SA is created. If this happens in the CREATE_CHILD_SA exchange, then the initiator MAY delete the IKE SA over which the invalid message was received by sending a Delete payload.
レスポンダーは、[RFC7296]のセクション3.3で説明されている標準のIKEV2手順を使用して交渉を実行します。ただし、AddKe変換タイプの場合、Responderの選択には、Noneの変換IDを除き、重複したアルゴリズム（同一の変換IDと属性を持つもの）を含めるべきではありません。アルゴリズムは変換として表されます。場合によっては、変換には、アルゴリズムの詳細を定義する関連属性のセットを含めることができます。この場合、2つの変換は同じである可能性がありますが、属性は異なる必要があります。さらに、属性の順序はアルゴリズムの等式に影響しないため、次の2つの変換は同じアルゴリズムを定義します。= attr1 "。提案されたキー交換ごとに複製されていないアルゴリズムを選択できない場合（提案には選択肢が少なすぎるか、提案されたアルゴリズムを使用する際のローカルポリシーの制限のため）、レスポンダーはエラーでメッセージを拒否する必要がありますタイプno_proposal_chosenの通知。Responderのメッセージに1つ以上の重複した選択肢が含まれている場合、イニシエーターはエラーをログにし、失敗したように交換を扱う必要があります。イニシエーターは、新しいSAが作成されないように、ike_intermediate（またはike_followup_ke）交換を開始してはなりません。これがcreate_child_sa Exchangeで発生した場合、イニシエーターは、削除ペイロードを送信することにより、無効なメッセージが受信されたIKE SAを削除する場合があります。
If the responder selects NONE for some ADDKE Transform Types (provided they are proposed by the initiator), then any corresponding additional key exchanges MUST NOT take place. Therefore, if the initiator includes NONE in all of the ADDKE Transform Types and the responder selects this value for all of them, then no IKE_INTERMEDIATE exchanges performing additional key exchanges will take place between the peers. Note that the IKE_INTERMEDIATE exchanges may still take place for other purposes.
ResponderがいくつかのAddke変換タイプ（イニシエーターによって提案されている場合）に対して何も選択しない場合、対応する追加のキー交換は行われてはなりません。したがって、イニシエーターにすべてのADDKE変換タイプになしが含まれ、レスポンダーがそれらすべてに対してこの値を選択する場合、追加のキー交換を実行するIKE_INTERMEDIATE取引所はピア間で行われません。ike_intermediate取引所は、他の目的のためにまだ行われる場合があることに注意してください。
The initiator MAY propose ADDKE Transform Types that are not consecutive, for example, proposing ADDKE2 and ADDKE5 Transform Types only. The responder MUST treat all of the omitted ADDKE transforms as if they were proposed with Transform ID NONE.
イニシエーターは、addke2およびaddke5変換タイプのみを提案するなど、連続していないaddke変換タイプを提案する場合があります。レスポンダーは、変換IDなしで提案されているかのように、省略されたすべてのAddke Transformsをすべて扱う必要があります。
Below is an example of the SA payload in the initiator's IKE_SA_INIT request message. Here, the abbreviation "KE" is used for the Key Exchange transform, which this document renames from the Diffie-Hellman Group transform. Additionally, the notations PQ_KEM_1, PQ_KEM_2, and PQ_KEM_3 are used to represent Transform IDs that have yet to be defined of some popular post-quantum key exchange methods.
以下は、イニシエーターのIKE_SA_INITリクエストメッセージのSAペイロードの例です。ここでは、略語「KE」はキーエクスチェンジ変換に使用されます。このドキュメントは、Diffie-Hellman Group Transformから変更します。さらに、表記PQ_KEM_1、PQ_KEM_2、およびPQ_KEM_3は、いくつかの一般的なポストカンタムポストキー交換方法でまだ定義されていない変換IDを表すために使用されます。
SA Payload
|
+--- Proposal #1 ( Proto ID = IKE(1), SPI Size = 8,
| 9 transforms, SPI = 0x35a1d6f22564f89d )
|
+-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
| +-- Attribute ( Key Length = 256 )
|
+-- Transform KE ( ID = 4096-bit MODP Group )
|
+-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
|
+-- Transform ADDKE2 ( ID = PQ_KEM_1 )
|
+-- Transform ADDKE2 ( ID = PQ_KEM_2 )
|
+-- Transform ADDKE3 ( ID = PQ_KEM_1 )
|
+-- Transform ADDKE3 ( ID = PQ_KEM_2 )
|
+-- Transform ADDKE5 ( ID = PQ_KEM_3 )
|
+-- Transform ADDKE5 ( ID = NONE )
In this example, the initiator proposes performing the initial key exchange using a 4096-bit MODP Group followed by two mandatory additional key exchanges (i.e., ADDKE2 and ADDKE3 Transform Types) using PQ_KEM_1 and PQ_KEM_2 methods in any order followed by an additional key exchange (i.e., ADDKE5 Transform Type) using the PQ_KEM_3 method that may be omitted.
この例では、イニシエーターは、4096ビットMODPグループを使用して初期キー交換を実行することを提案し、その後、PQ_KEM_1およびPQ_KEM_2メソッドを使用して2つの必須の追加キー交換（つまり、ADDKE2およびADDKE3変換タイプ）が続き、追加のキー交換が続きます（つまり、省略される可能性のあるPQ_KEM_3メソッドを使用して、addke5変換タイプ）。
The responder might return the following SA payload, indicating that it agrees to perform two additional key exchanges, PQ_KEM_2 followed by PQ_KEM_1, and that it does not want to additionally perform PQ_KEM_3.
レスポンダーは、次のSAペイロードを返す可能性があり、PQ_KEM_2の2つの追加のキー交換を実行することに同意し、PQ_KEM_1が続くことを示し、PQ_KEM_3をさらに実行したくないことを示します。
SA Payload
|
+--- Proposal #1 ( Proto ID = IKE(1), SPI Size = 8,
| 6 transforms, SPI = 0x8df52b331a196e7b )
|
+-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
| +-- Attribute ( Key Length = 256 )
|
+-- Transform KE ( ID = 4096-bit MODP Group )
|
+-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
|
+-- Transform ADDKE2 ( ID = PQ_KEM_2 )
|
+-- Transform ADDKE3 ( ID = PQ_KEM_1 )
|
+-- Transform ADDKE5 ( ID = NONE )
If the initiator includes any ADDKE Transform Types into the SA payload in the IKE_SA_INIT exchange request message, then it MUST also negotiate the use of the IKE_INTERMEDIATE exchange, as described in [RFC9242] by including an INTERMEDIATE_EXCHANGE_SUPPORTED notification in the same message. If the responder agrees to use additional key exchanges while establishing an initial IKE SA, it MUST also return this notification in the IKE_SA_INIT response message, confirming that IKE_INTERMEDIATE exchange is supported and will be used for transferring additional key exchange data. If the IKE_INTERMEDIATE exchange is not negotiated, then the peers MUST treat any ADDKE Transform Types in the IKE_SA_INIT exchange messages as unknown transform types and skip the proposals they appear in. If no other proposals are present in the SA payload, the peers will proceed as if no proposal has been chosen (i.e., the responder will send a NO_PROPOSAL_CHOSEN notification).
イニシエーターがIKE_SA_INIT ExchangeリクエストメッセージのSAペイロードにADDKE変換タイプを含めている場合、同じメッセージにIntermediate_Exchange_Supported通知を含めることにより、[RFC9242]に記載されているように、IKE_INTERMEDIATE Exchangeの使用も交渉する必要があります。Responderが最初のIKE SAを確立しながら追加のキー交換を使用することに同意した場合、IKE_SA_INIT応答メッセージにこの通知を返す必要があり、IKE_INTERMEDIATE Exchangeがサポートされており、追加のキーエクスチェンジデータの転送に使用されることを確認する必要があります。ike_intermediate Exchangeが交渉されていない場合、ピアはIKE_SA_INIT ExchangeメッセージのADDKE変換タイプを不明な変換タイプとして扱い、表示される提案をスキップする必要があります。提案が選択されていない場合（つまり、レスポンダーはNO_PROPOSAL_CHOSEN通知を送信します）。
Initiator Responder
---------------------------------------------------------------------
HDR, SAi1(.. ADDKE*...), KEi, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED) --->
HDR, SAr1(.. ADDKE*...), KEr, Nr,
[CERTREQ],
<--- N(INTERMEDIATE_EXCHANGE_SUPPORTED)
It is possible for an attacker to manage to send a response to the initiator's IKE_SA_INIT request before the legitimate responder does. If the initiator continues to create the IKE SA using this response, the attempt will fail. Implementers may wish to consider strategies as described in Section 2.4 of [RFC7296] to handle such an attack.
攻撃者は、合法的なレスポンダーが行う前に、イニシエーターのIKE_SA_INITリクエストに応答を送信することができます。この応答を使用してIke SAの作成を継続し続けると、試みは失敗します。実装者は、このような攻撃を処理するために[RFC7296]のセクション2.4で説明されているように戦略を検討することをお勧めします。
For each additional key exchange agreed to in the IKE_SA_INIT exchange, the initiator and the responder perform an IKE_INTERMEDIATE exchange, as described in [RFC9242].
IKE_SA_INIT Exchangeで合意された追加のキー交換ごとに、[RFC9242]で説明されているように、IKE_INTERMEDIATE Exchangeをイニシエーターとレスポンダーが実行します。
Initiator Responder
---------------------------------------------------------------------
HDR, SK {KEi(n)} -->
<-- HDR, SK {KEr(n)}
The initiator sends key exchange data in the KEi(n) payload. This message is protected with the current SK_ei/SK_ai keys. The notation "KEi(n)" denotes the n-th IKE_INTERMEDIATE KE payload from the initiator; the integer "n" is sequential starting from 1.
イニシエーターは、KEI（n）ペイロードにキーエクスチェンジデータを送信します。このメッセージは、現在のSK_EI/SK_AIキーで保護されています。表記「kei（n）」は、イニシエーターからのn番目のike_intermediate keペイロードを示します。整数「n」は1から順次開始されます。
On receiving this, the responder sends back key exchange payload KEr(n); "KEr(n)" denotes the n-th IKE_INTERMEDIATE KE payload from the responder. Similar to how the request is protected, this message is protected with the current SK_er/SK_ar keys.
これを受け取ると、レスポンダーはキーエクスチェンジペイロードker（n）を送り返します。「ker（n）」は、レスポンダーからのn-th ike_intermediate keペイロードを示します。リクエストの保護方法と同様に、このメッセージは現在のSK_ER/SK_ARキーで保護されています。
The former "Diffie-Hellman Group Num" (now called "Key Exchange Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th negotiated additional key exchange.
KEI（N）およびKER（n）のペイロードの以前の「Diffie-Hellman Group Num」（現在は「キー交換方法」と呼ばれる）フィールドは、N-Theの追加のキー交換と一致する必要があります。
Once this exchange is done, both sides compute an updated keying material:
この交換が完了すると、双方が更新されたキーイング素材を計算します。
SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)
From this exchange, SK(n) is the resulting shared secret. Ni and Nr are nonces from the IKE_SA_INIT exchange. SK_d(n-1) is the last generated SK_d (derived from IKE_SA_INIT for the first use of IKE_INTERMEDIATE and, otherwise, from the previous IKE_INTERMEDIATE exchange). The other keying materials, SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr, are generated from the SKEYSEED(n) as follows:
この交換から、SK（n）は結果の共有秘密です。NIとNRは、IKE_SA_INIT Exchangeの非能力です。Sk_d（n-1）は、最後に生成されたSK_D（IKE_INTERMEDIATEを最初に使用するためのIKE_SA_INITから派生したものです。他のキーイング素材、SK_D、SK_AI、SK_AR、SK_EI、SK_ER、SK_PI、およびSK_PRは、次のようにSkeySeed（n）から生成されます。
{SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) |
SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr)
Both the initiator and the responder use these updated key values in the next exchange (IKE_INTERMEDIATE or IKE_AUTH).
イニシエーターとレスポンダーの両方が、次のExchange（IKE_INTERMEDIATEまたはIKE_AUTH）でこれらの更新されたキー値を使用します。
After all IKE_INTERMEDIATE exchanges have completed, the initiator and the responder perform an IKE_AUTH exchange. This exchange is the standard IKE exchange, as described in [RFC7296], with the modification of AUTH payload calculation described in [RFC9242].
結局、IKE_INTERMEDIATE EXCHANGEが完了した後、イニシエーターとレスポンダーはIKE_AUTH Exchangeを実行します。[RFC7296]で説明されているように、この交換は標準的なIKE交換であり、[RFC9242]で説明されている認証ペイロード計算の変更があります。
The CREATE_CHILD_SA exchange is used in IKEv2 for the purposes of creating additional Child SAs, rekeying these Child SAs, and rekeying IKE SA itself. When creating or rekeying Child SAs, the peers may optionally perform a key exchange to add a fresh entropy into the session keys. In the case of an IKE SA rekey, the key exchange is mandatory. Peers supporting this specification may want to use multiple key exchanges in these situations.
Create_Child_Sa Exchangeは、追加の子供SASを作成し、これらの子供のSASを再起動し、Ike SA自体を再ケーブする目的でIKEV2で使用されます。子SASを作成または再キーインするとき、ピアはオプションでキーエクスチェンジを実行して、セッションキーに新しいエントロピーを追加することができます。Ike Sa Rekeyの場合、キー交換は必須です。この仕様をサポートするピアは、これらの状況で複数のキー交換を使用したい場合があります。
Using multiple key exchanges with a CREATE_CHILD_SA exchange is negotiated in a similar fashion to the initial IKE exchange, see Section 2.2.1. If the initiator includes any ADDKE Transform Types in the SA payload (along with Transform Type 4), and if the responder agrees to perform additional key exchanges, then the additional key exchanges are performed in a series of new IKE_FOLLOWUP_KE exchanges that follow the CREATE_CHILD_SA exchange. The IKE_FOLLOWUP_KE exchange is introduced especially for transferring data of additional key exchanges following the one performed in the CREATE_CHILD_SA. Its Exchange Type value is 44.
create_child_sa交換で複数のキー交換を使用することは、最初のIKE交換と同様の方法で交渉されます。セクション2.2.1を参照してください。イニシエーターにSAペイロードに（変換タイプ4とともに）addke変換タイプが含まれており、レスポンダーが追加のキー交換を実行することに同意した場合、Create_Child_Sa Exchangeに続く一連の新しいike_followup_ke取引所で追加のキー交換が実行されます。。IKE_FOLLOWUP_KE Exchangeは、Create_Child_Saで実行されたものに続いて追加のキー取引所のデータを転送するために特に導入されています。その交換タイプの値は44です。
The key exchange negotiated via Transform Type 4 always takes place in the CREATE_CHILD_SA exchange, as per the IKEv2 specification [RFC7296]. Additional key exchanges are performed in an order of the values of their Transform Types so that the key exchange negotiated using Additional Key Exchange i always precedes the key exchange negotiated using Additional Key Exchange i + 1. Each additional key exchange method MUST be fully completed before the next one is started. Note that this document assumes that each key exchange method consumes exactly one IKE_FOLLOWUP_KE exchange. For the methods that require multiple round trips, a separate document should define how such methods are split into several IKE_FOLLOWUP_KE exchanges.
IKEV2仕様[RFC7296]によると、変換タイプ4を介して交渉されたキーエクスチェンジは、create_child_sa Exchangeで常に行われます。追加のキー交換が変換タイプの値の順序で実行されるため、追加のキーエクスチェンジを使用してネゴシエートされたキーエクスチェンジは、追加のキーエクスチェンジを使用して交渉されたキーエクスチェンジの前に常に行われます。次のものが開始されます。このドキュメントは、各キー交換方法が正確に1つのIKE_FOLLOWUP_KE Exchangeを消費することを前提としていることに注意してください。複数のラウンド旅行を必要とする方法については、個別のドキュメントでは、そのような方法がいくつかのIKE_FOLLOWUP_KE交換にどのように分割されるかを定義する必要があります。
After an IKE SA is created, the window size may be greater than one; thus, multiple concurrent exchanges may be in progress. Therefore, it is essential to link the IKE_FOLLOWUP_KE exchanges together with the corresponding CREATE_CHILD_SA exchange. Once an IKE SA is created, all IKE exchanges are independent and IKEv2 doesn't have a built-in mechanism to link an exchange with another one. A new status type notification called "ADDITIONAL_KEY_EXCHANGE" is introduced for this purpose. Its Notify Message Type value is 16441, and the Protocol ID and SPI Size are both set to 0. The data associated with this notification is a blob meaningful only to the responder so that the responder can correctly link successive exchanges. For the initiator, the content of this notification is an opaque blob.
IKE SAが作成された後、ウィンドウサイズが1より大きくなる場合があります。したがって、複数の同時交換が進行中である可能性があります。したがって、IKE_FOLLOWUP_KE交換を対応するCreate_Child_Sa Exchangeとリンクすることが不可欠です。IKE SAが作成されると、すべてのIKE交換は独立しており、IKEV2には別の交換をリンクするための組み込みメカニズムがありません。この目的のために、「追加_KEY_EXCHANGE」と呼ばれる新しいステータスタイプの通知が導入されています。通知メッセージタイプ値は16441で、プロトコルIDとSPIサイズは両方とも0に設定されています。この通知に関連付けられたデータは、レスポンダーにとってのみ意味のあるBLOBであるため、レスポンダーが連続した交換を正しくリンクできます。イニシエーターの場合、この通知の内容は不透明なブロブです。
The responder MUST include this notification in a CREATE_CHILD_SA or IKE_FOLLOWUP_KE response message in case the next IKE_FOLLOWUP_KE exchange is expected, filling it with some data that would allow linking the current exchange to the next one. The initiator MUST send back this notification intact in the request message of the next IKE_FOLLOWUP_KE exchange.
Responderは、次のIKE_FOLLOWUP_KE Exchangeが予想される場合に備えて、Create_Child_SaまたはIKE_Followup_Ke応答メッセージにこの通知を含める必要があります。イニシエーターは、次のIKE_FOLLOWUP_KE Exchangeのリクエストメッセージでこの通知をそのまま送信する必要があります。
Below is an example of CREATE_CHILD_SA exchange followed by three additional key exchanges.
以下は、create_child_sa交換の例と、3つの追加のキー交換を使用します。
Initiator Responder
---------------------------------------------------------------------
HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
<-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr,
N(ADDITIONAL_KEY_EXCHANGE)(link1)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(1),
N(ADDITIONAL_KEY_EXCHANGE)(link1)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1),
N(ADDITIONAL_KEY_EXCHANGE)(link2)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(2),
N(ADDITIONAL_KEY_EXCHANGE)(link2)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2),
N(ADDITIONAL_KEY_EXCHANGE)(link3)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(3),
N(ADDITIONAL_KEY_EXCHANGE)(link3)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(3)}
The former "Diffie-Hellman Group Num" (now called "Key Exchange Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th negotiated additional key exchange.
KEI（N）およびKER（n）のペイロードの以前の「Diffie-Hellman Group Num」（現在は「キー交換方法」と呼ばれる）フィールドは、N-Theの追加のキー交換と一致する必要があります。
Due to some unexpected events (e.g., a reboot), it is possible that the initiator may lose its state, forget that it is in the process of performing additional key exchanges, and never start the remaining IKE_FOLLOWUP_KE exchanges. The responder MUST handle this situation gracefully and delete the associated state if it does not receive the next expected IKE_FOLLOWUP_KE request after some reasonable period of time. Due to various factors such as computational resource and key exchange algorithm used, note that it is not possible to give normative guidance on how long this timeout period should be. In general, 5-20 seconds of waiting time should be appropriate in most cases.
いくつかの予期しないイベントのため（例：再起動）、イニシエーターがその状態を失い、追加のキー交換を実行する過程にあることを忘れて、残りのike_followup_ke交換を開始しない可能性があります。レスポンダーは、この状況を優雅に処理し、次の予想されるIKE_FOLLOWUP_KEリクエストをある程度の期間後に受け取らない場合は、関連状態を削除する必要があります。使用された計算リソースやキーエクスチェンジアルゴリズムなどのさまざまな要因により、このタイムアウト期間がどれくらいの期間であるかについて規範的なガイダンスを提供することはできないことに注意してください。一般に、ほとんどの場合、5〜20秒の待ち時間が適切であるはずです。
It may also take too long for the initiator to prepare and to send the next IKE_FOLLOWUP_KE request, or, due to the network conditions, the request could be lost and retransmitted. In this case, the message may reach the responder when it has already deleted the associated state, following the advice above. If the responder receives an IKE_FOLLOWUP_KE message for which it does not have a key exchange state, it MUST send back a new error type notification called "STATE_NOT_FOUND". This is an error notification that is not fatal to the IKE SA. Its Notify Message Type value is 47, its Protocol ID and SPI Size are both set to 0, and the data is empty. If the initiator receives this notification in response to an IKE_FOLLOWUP_KE exchange performing an additional key exchange, it MUST cancel this exchange and MUST treat the whole series of exchanges started from the CREATE_CHILD_SA exchange as having failed. In most cases, the receipt of this notification is caused by the premature deletion of the corresponding state on the responder (the time period between IKE_FOLLOWUP_KE exchanges appeared to be too long from the responder's point of view, e.g., due to a temporary network failure). After receiving this notification, the initiator MAY start a new CREATE_CHILD_SA exchange, which may eventually be followed by the IKE_FOLLOWUP_KE exchanges, to retry the failed attempt. If the initiator continues to receive STATE_NOT_FOUND notifications after several retries, it MUST treat this situation as a fatal error and delete the IKE SA by sending a DELETE payload.
また、イニシエーターが次のIKE_FOLLOWUP_KE要求を準備して送信するには時間がかかりすぎる場合があります。または、ネットワーク条件により、リクエストが失われて再送信される可能性があります。この場合、上記のアドバイスに従って、関連状態が既に削除されている場合、メッセージはレスポンダーに到達する場合があります。Responderがキーエクスチェンジ状態を持たないIKE_FOLLOWUP_KEメッセージを受信した場合、「State_Not_Found」と呼ばれる新しいエラータイプ通知を送信する必要があります。これは、IKE SAにとって致命的ではないエラー通知です。通知メッセージタイプ値は47で、プロトコルIDとSPIサイズは両方とも0に設定されており、データは空です。イニシエーターがIKE_FOLLOWUP_KE交換に応じてこの通知を受け取った場合、追加のキーエクスチェンジを実行するには、この交換をキャンセルする必要があり、Create_Child_Sa Exchangeから開始された一連の交換を失敗したと扱う必要があります。ほとんどの場合、この通知の受領は、対応する状態がレスポンダーでの早期削除によって引き起こされます（IKE_FOLLOWUP_KE交換の間の期間は、たとえば、一時的なネットワークの障害により、レスポンダーの観点から長すぎるように見えました）。この通知を受け取った後、イニシエーターは新しいcreate_child_sa Exchangeを開始する場合があり、最終的にはIKE_FOLLOWUP_KE Exchangesが続いて、失敗した試みを再試行することができます。イニシエーターがいくつかの再試行後にstate_not_found通知を引き続き受信し続ける場合、この状況を致命的なエラーとして扱い、削除ペイロードを送信してIKE SAを削除する必要があります。
It is possible that the peers start rekeying the IKE SA or the Child SA at the same time, which is called "simultaneous rekeying". Sections 2.8.1 and 2.8.2 of [RFC7296] describe how IKEv2 handles this situation. In a nutshell, IKEv2 follows the rule that, in the case of simultaneous rekeying, if two identical new IKE SAs (or two pairs of Child SAs) are created, then one of them should be deleted. Which one to delete is determined by comparing the values of four nonces that are used in the colliding CREATE_CHILD_SA exchanges. The IKE SA (or pair of Child SAs) created by the exchange in which the smallest nonce is used should be deleted by the initiator of this exchange.
ピアが「同時に再キーリング」と呼ばれるIKE SAまたはChild SAを同時に再ケーニングし始める可能性があります。[RFC7296]のセクション2.8.1および2.8.2は、IKEV2がこの状況をどのように処理するかについて説明します。一言で言えば、IKEV2は、同時に再キーリングする場合、2つの同一の新しいIKE SAS（または2つの子供SAS）が作成された場合、そのうちの1つを削除する必要があるというルールに従います。削除するものは、衝突するcreate_child_sa交換で使用されている4つの非能力の値を比較することによって決定されます。最小のNonCEが使用される交換によって作成されたIKE SA（または子SASのペア）は、この交換の開始者によって削除する必要があります。
With multiple key exchanges, the SAs are not yet created when the CREATE_CHILD_SA is completed. Instead, they would be created only after the series of IKE_FOLLOWUP_KE exchanges is finished. For this reason, if additional key exchanges are negotiated in the CREATE_CHILD_SA exchange in which the smallest nonce is used, then, because there is nothing to delete yet, the initiator of this exchange just stops the rekeying process, and it MUST NOT initiate the IKE_FOLLOWUP_KE exchange.
複数のキー交換で、create_child_saが完了したときにSASはまだ作成されていません。代わりに、IKE_FOLLOWUP_KE交換のシリーズが終了した後にのみ作成されます。このため、最小のノンセが使用されるcreate_child_sa交換で追加のキー交換が交渉された場合、削除するものがまだないため、この交換のイニシエーターは再キーイングプロセスを停止し、ike_followup_keを開始してはなりません。交換。
In most cases, rekey collisions are resolved in the CREATE_CHILD_SA exchange. However, a situation may occur when, due to packet loss, one of the peers receives the CREATE_CHILD_SA message requesting the rekey of an SA that is already being rekeyed by this peer (i.e., the CREATE_CHILD_SA exchange initiated by this peer has already been completed, and the series of IKE_FOLLOWUP_KE exchanges is in progress). In this case, a TEMPORARY_FAILURE notification MUST be sent in response to such a request.
ほとんどの場合、Rekey衝突はCreate_Child_Sa Exchangeで解決されます。ただし、パケットの損失により、ピアの1人がcreate_child_saメッセージを受信して、このピアによってすでに再キーされているSAの再キーを要求する場合の状況が発生する可能性があります（つまり、このピアによって開始されたcreate_child_sa取引所はすでに完了しています。そして、一連のIKE_FOLLOWUP_KE交換が進行中です）。この場合、そのようなリクエストに応じて一時的な_failure通知を送信する必要があります。
If multiple key exchanges are negotiated in the CREATE_CHILD_SA exchange, then the resulting keys are computed as follows.
create_child_sa Exchangeで複数のキー交換が交渉されている場合、結果のキーは次のように計算されます。
In the case of an IKE SA rekey:
Ike sa rekeyの場合：
SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n))
In the case of a Child SA creation or rekey:
子SAの作成または再キーの場合：
KEYMAT = prf+ (SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n))
In both cases, SK_d is from the existing IKE SA; SK(0), Ni, and Nr are the shared key and nonces from the CREATE_CHILD_SA, respectively; SK(1)...SK(n) are the shared keys from additional key exchanges.
どちらの場合も、SK_Dは既存のIKESAからのものです。SK（0）、Ni、およびNRは、それぞれCreate_Child_saの共有キーと非能力です。SK（1）... SK（n）は、追加のキー交換の共有キーです。
It is believed that this specification requires no modification to the IKEv2 extensions defined so far. In particular, the IKE SA resumption mechanism defined in [RFC5723] can be used to resume IKE SAs created using this specification.
この仕様には、これまでに定義されたIKEV2拡張機能の変更は必要ないと考えられています。特に、[RFC5723]で定義されているIKE SA再開メカニズムを使用して、この仕様を使用して作成されたIKE SASを再開できます。
It is possible to establish IKE SAs with post-quantum algorithms by only using IKE_FOLLOWUP_KE exchanges and without the use of IKE_INTERMEDIATE exchanges. In this case, the IKE SA that is created from the IKE_SA_INIT exchange, can be immediately rekeyed with CREATE_CHILD_SA with additional key exchanges, where IKE_FOLLOWUP_KE messages are used for these additional key exchanges. If the classical key exchange method is used in the IKE_SA_INIT message, the very first Child SA created in IKE_AUTH will offer no resistance against the quantum threats. Consequently, if the peers' local policy requires all Child SAs to be post-quantum secure, then the peers can avoid creating the very first Child SA by adopting [RFC6023]. In this case, the initiator sends two types of proposals in the IKE_SA_INIT request: one with and another one without ADDKE Transform Types. The responder chooses the latter proposal type and includes a CHILDLESS_IKEV2_SUPPORTED notification in the IKE_SA_INIT response. Assuming that the initiator supports childless IKE SA extension, both peers perform the modified IKE_AUTH exchange described in [RFC6023], and no Child SA is created in this exchange. The peers should then immediately rekey the IKE SA and subsequently create the Child SAs, all with additional key exchanges using a CREATE_CHILD_SA exchange.
ike_followup_ke交換のみを使用して、ike_intermediate取引所を使用せずに、IKE_followup_ke交換のみを使用して、quantum後のアルゴリズムでIKE SASを確立することができます。この場合、IKE_SA_INIT Exchangeから作成されたIKE SAは、これらの追加のキー交換にIKE_FOLLOWUP_KEメッセージが使用される追加のキー交換を使用して、create_child_saですぐに再キーを作成できます。IKE_SA_INITメッセージで古典的なキー交換方法が使用されている場合、IKE_AUTHで作成された最初の子供SAは、量子の脅威に対して抵抗を提供しません。その結果、ピアのローカルポリシーがすべての子SASを四方階に安全にする必要がある場合、ピアは[RFC6023]を採用することで、最初の子供SAの作成を避けることができます。この場合、イニシエーターはIKE_SA_INITリクエストで2種類の提案を送信します。1つはADDKE Transformタイプのないものです。Responderは後者の提案タイプを選択し、IKE_SA_INIT応答にChildLess_ikev2_supported通知を含みます。イニシエーターが子供のいないIKE SA拡張をサポートしていると仮定すると、両方のピアは[RFC6023]に記載されている修正されたIKE_AUTH Exchangeを実行し、この交換では子供SAが作成されません。その後、ピアはすぐにIKE SAを再キーし、その後、CREATE_CHILD_SA Exchangeを使用して追加のキー交換を使用して、子SASを作成する必要があります。
It is also possible for the initiator to send proposals without any ADDKE Transform Types in the IKE_SA_INIT message. In this instance, the responder will have no information about whether or not the initiator supports the extension in this specification. This may not be efficient, as the responder will have to wait for the subsequent CREATE_CHILD_SA request to determine whether or not the initiator's request is appropriate for its local policy.
また、IKE_SA_INITメッセージにaddke変換タイプなしで、イニシエーターが提案を送信することもできます。この例では、レスポンダーには、イニシエーターがこの仕様の拡張機能をサポートするかどうかについての情報はありません。レスポンダーは、その後のCREATE_CHILD_SA要求が現地ポリシーに適切かどうかを判断するために、その後のCREATE_CHILD_SA要求を待たなければならないため、これは効率的ではないかもしれません。
The support for childless IKE SA is not negotiated, but it is the responder that indicates the support for this mode. As such, the responder cannot enforce that the initiator use this mode. Therefore, it is entirely possible that the initiator does not support this extension and sends IKE_AUTH request as per [RFC7296] instead of [RFC6023]. In this case, the responder may respond with an error that is not fatal, such as the NO_PROPOSAL_CHOSEN notify message type.
子供のいないIke SAのサポートは交渉されていませんが、このモードのサポートを示すのは応答者です。そのため、レスポンダーは、イニシエーターがこのモードを使用することを強制できません。したがって、[RFC6023]の代わりに[RFC7296]に従って、イニシエーターがこの拡張機能をサポートせず、IKE_AUTH要求を送信する可能性は完全にあります。この場合、NO_PROPOSAL_CHOSEN通知メッセージタイプなど、レスポンダーは致命的ではないエラーで応答する場合があります。
Note that if the initial IKE SA is used to transfer sensitive information, then this information will not be protected using the additional key exchanges, which may use post-quantum algorithms. In this arrangement, the peers will have to use post-quantum algorithm in Transform Type 4 in order to mitigate the risk of quantum attack.
初期のIKE SAが機密情報を転送するために使用される場合、この情報は、ポストカントゥムアルゴリズムを使用する可能性のある追加のキー交換を使用して保護されないことに注意してください。この配置では、ピアは量子攻撃のリスクを軽減するために、変換タイプ4の四方四分位アルゴリズムを使用する必要があります。
This document adds a new exchange type into the "IKEv2 Exchange Types" registry:
このドキュメントでは、新しいExchangeタイプを「IKEV2 Exchange Type」レジストリに追加します。
44 IKE_FOLLOWUP_KE
This document renames Transform Type 4 defined in the "Transform Type Values" registry from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)".
このドキュメントは、「Diffie-Hellman Group（D-H）」から「Key Exchange Method（ke）」に「変換タイプ値」レジストリで定義されたType 4 Type 4 Type 4を変更します。
This document renames the IKEv2 registry originally titled "Transform Type 4 - Diffie-Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs".
このドキュメントは、「Transform Type 4 -Diffie -Hellman Group IDS」というタイトルのIKEV2レジストリの名前を「タイプ4-キー交換メソッド変換ID」に変更します。
This document adds the following Transform Types to the "Transform Type Values" registry:
このドキュメントでは、次の変換タイプを「transform type値」レジストリに追加します。
+======+====================================+===============+
| Type | Description | Used In |
+======+====================================+===============+
| 6 | Additional Key Exchange 1 (ADDKE1) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
| 7 | Additional Key Exchange 2 (ADDKE2) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
| 8 | Additional Key Exchange 3 (ADDKE3) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
| 9 | Additional Key Exchange 4 (ADDKE4) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
| 10 | Additional Key Exchange 5 (ADDKE5) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
| 11 | Additional Key Exchange 6 (ADDKE6) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
| 12 | Additional Key Exchange 7 (ADDKE7) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
Table 1: "Transform Type Values" Registry
表1：「transform type値」レジストリ
This document defines a new Notify Message Type in the "IKEv2 Notify Message Types - Status Types" registry:
このドキュメントでは、「IKEV2通知メッセージタイプ - ステータスタイプ」レジストリの新しい通知メッセージタイプを定義します。
16441 ADDITIONAL_KEY_EXCHANGE
This document also defines a new Notify Message Type in the "IKEv2 Notify Message Types - Error Types" registry:
このドキュメントでは、「IKEV2通知メッセージタイプ - エラータイプ」レジストリの新しいNOTIFYメッセージタイプも定義します。
47 STATE_NOT_FOUND
IANA has added the following instructions for designated experts for the "Transform Type 4 - Key Exchange Method Transform IDs" subregistry:
IANAは、「Transform Type 4 -Key Exchange Method Transform ID」の指定された専門家に次の指示を追加しました。
* While adding new Key Exchange (KE) methods, the following considerations must be applied. A KE method must take exactly one round-trip (one IKEv2 exchange), and at the end of this exchange, both peers must be able to derive the shared secret. In addition, any public value that peers exchanged during a KE method must fit into a single IKEv2 payload. If these restrictions are not met for a KE method, then there must be documentation on how this KE method is used in IKEv2.
* 新しいキーエクスチェンジ（KE）メソッドを追加している間、次の考慮事項を適用する必要があります。KEメソッドは正確に1つの往復（1つのIKEV2 Exchange）を取る必要があり、この交換の終わりに、両方のピアが共有された秘密を導き出すことができなければなりません。さらに、KEメソッド中にピアが交換した公共の価値は、単一のIKEV2ペイロードに適合する必要があります。これらの制限がKEメソッドで満たされていない場合、このKEメソッドがIKEV2でどのように使用されるかについてのドキュメントが必要です。
IANA has also completed the following changes. It is assumed that [RFC9370] refers to this specification.
IANAは、次の変更も完了しました。[RFC9370]はこの仕様を指していると想定されています。
* Added a reference to [RFC9370] in what was the "Transform Type 4 - Diffie-Hellman Group Transform IDs" registry.
* 「Transform Type 4 -Diffie -Hellman Group Transform IDS」レジストリで[RFC9370]への参照を追加しました。
* Replaced the Note on what was the "Transform Type 4 - Diffie-Hellman Group Transform IDs" registry with the following notes:
* 「Transform Type 4 -Diffie -Hellman Group Transform IDS」レジストリが次のメモで何であったかについてのメモを置き換えました。
* This registry was originally named "Transform Type 4 - Diffie-Hellman Group Transform IDs" and was referenced using that name in a number of RFCs published prior to [RFC9370], which gave it the current title.
* このレジストリはもともと「Transform Type 4 -Diffie -Hellman Group Transform IDS」と名付けられ、[RFC9370]より前に公開された多くのRFCでその名前を使用して参照され、現在のタイトルが与えられました。
* This registry is used by the "Key Exchange Method (KE)" transform type and by all "Additional Key Exchange (ADDKE)" transform types.
* このレジストリは、「キー交換方法（KE）」変換タイプとすべての「追加のキーエクスチェンジ（ADDKE）」変換タイプによって使用されます。
* To find out requirement levels for Key Exchange Methods for IKEv2, see [RFC8247].
* IKEV2の主要な交換方法の要件レベルを見つけるには、[RFC8247]を参照してください。
* Appended [RFC9370] to the Reference column of Transform Type 4 in the "Transform Type Values" registry.
* [RFC9370]は、「変換タイプ値」レジストリに変換タイプ4の参照列に追加されました。
* Added these notes to the "Transform Type Values" registry:
* これらのメモを「transform type値」レジストリに追加しました。
* "Key Exchange Method (KE)" transform type was originally named "Diffie-Hellman Group (D-H)" and was referenced by that name in a number of RFCs published prior to [RFC9370], which gave it the current title.
* 「Key Exchange Method（KE）」変換タイプは、もともと「Diffie-Hellman Group（D-H）」と名付けられ、[RFC9370]より前に公開された多くのRFCでその名前で参照され、現在のタイトルを与えました。
* All "Additional Key Exchange (ADDKE)" entries use the same "Transform Type 4 - Key Exchange Method Transform IDs" registry as the "Key Exchange Method (KE)" entry.
* すべての「追加のキーエクスチェンジ（ADDKE）」エントリは、「キーエクスチェンジメソッド（KE）」エントリとして、同じ「Transform Typent 4 -Key ExchangeメソッドID」レジストリを使用します。
The extension in this document is intended to mitigate two possible threats in IKEv2: the compromise of (EC)DH key exchange using Shor's algorithm while remaining backward compatible and the potential compromise of existing or future PQC key exchange algorithms. To address the former threat, this extension allows the establishment of a shared secret by using multiple key exchanges: typically, one classical (EC)DH and the other one post-quantum algorithm. In order to address the latter threat, multiple key exchanges using a post-quantum algorithm can be performed to form the shared key.
このドキュメントの拡張機能は、IKEV2の2つの可能な脅威を軽減することを目的としています。Shorのアルゴリズムを使用した（EC）DHキー交換の妥協と、後方互換性のあるままであり、既存または将来のPQCキー交換アルゴリズムの潜在的な妥協です。前者の脅威に対処するために、この拡張機能は、複数のキー交換を使用することにより、共有された秘密の確立を可能にします。通常、1つの古典（EC）DHともう1つのポストカントムアルゴリズムです。後者の脅威に対処するために、質量後アルゴリズムを使用した複数のキー交換を実行して、共有キーを形成できます。
Unlike key exchange methods (Transform Type 4), the Encryption Algorithm (Transform Type 1), the Pseudorandom Function (Transform Type 2), and the Integrity Algorithm (Transform Type 3) are not susceptible to Shor's algorithm. However, they are susceptible to Grover's attack [GROVER], which allows a quantum computer to perform a brute force key search, using quadratically fewer steps than the classical counterpart. Simply increasing the key length can mitigate this attack. It was previously believed that one needed to double the key length of these algorithms. However, there are a number of factors that suggest that it is quite unlikely to achieve the quadratic speedup using Grover's algorithm. According to NIST [NISTPQCFAQ], current applications can continue using an AES algorithm with the minimum key length of 128 bits. Nevertheless, if the data needs to remain secure for many years to come, one may want to consider using a longer key size for the algorithms in Transform Types 1-3.
キー交換方法（変換タイプ4）とは異なり、暗号化アルゴリズム（変換タイプ1）、擬似ランダム関数（変換タイプ2）、および整合性アルゴリズム（変換タイプ3）は、Shorのアルゴリズムの影響を受けません。ただし、それらはGroverの攻撃[Grover]の影響を受けやすく、これにより、Quantum Computerは、古典的なカウンターパートよりも四半期に少ないステップを使用して、ブルートフォースキー検索を実行できます。キーの長さを増やすだけで、この攻撃を軽減できます。以前は、これらのアルゴリズムのキー長を2倍にする必要があると信じられていました。ただし、Groverのアルゴリズムを使用して2次スピードアップを達成する可能性が非常に低いことを示唆する多くの要因があります。NIST [NISTPQCFAQ]によると、現在のアプリケーションは、128ビットの最小キー長を持つAESアルゴリズムを使用し続けることができます。それにもかかわらず、データが今後何年も安全なままでいる必要がある場合、変換タイプ1〜3のアルゴリズムに長いキーサイズを使用することを検討することをお勧めします。
SKEYSEED is calculated from shared SK(x), using an algorithm defined in Transform Type 2. While a quantum attacker may learn the value of SK(x), if this value is obtained by means of a classical key exchange, other SK(x) values generated by means of a post-quantum algorithm ensure that the final SKEYSEED is not compromised. This assumes that the algorithm defined in the Transform Type 2 is quantum resistant.
SKEYSEEDは、変換タイプ2で定義されたアルゴリズムを使用して共有SK（x）から計算されます。一方、量子攻撃者はSK（x）の値を学習できますが、この値が古典的なキー交換によって取得される場合、他のSK（x（x））Quantum後のアルゴリズムによって生成された値は、最終的なSkeyseedが損なわれないことを保証します。これは、変換タイプ2で定義されているアルゴリズムが量子耐性であることを前提としています。
The ordering of the additional key exchanges should not matter in general, as only the final shared secret is of interest. Nonetheless, because the strength of the running shared secret increases with every additional key exchange, an implementer may want to first perform the most secure method (in some metrics) followed by less secure methods.
最終的な共有された秘密のみが興味深いため、追加のキー交換の順序は一般的には重要ではありません。それにもかかわらず、ランニングの共有秘密の強度は、追加のキーエクスチェンジごとに増加するため、実装者は最初に最も安全な方法（一部のメトリックで）を実行し、その後の安全性の低い方法を実行したい場合があります。
The main focus of this document is to prevent a passive attacker from performing a "harvest-and-decrypt" attack: in other words, attackers that record messages exchanged today and proceed to decrypt them once they have access to cryptographically relevant quantum computers. This attack is prevented due to the hybrid nature of the key exchange. Other attacks involving an active attacker using a quantum-computer are not completely solved by this document. This is for two reasons:
このドキュメントの主な焦点は、受動的な攻撃者が「収穫とデクリプト」攻撃を実行するのを防ぐことです。つまり、今日のメッセージを記録した攻撃者が暗号化に関連する量子コンピューターにアクセスしたら、それらを復号化することです。この攻撃は、キー交換のハイブリッド性のために防止されます。量子コンピューターを使用したアクティブな攻撃者が関与する他の攻撃は、このドキュメントによって完全に解決されるわけではありません。これには2つの理由があります。
* The first reason is that the authentication step remains classical. In particular, the authenticity of the SAs established under IKEv2 is protected by using a pre-shared key or digital signature algorithms. While the pre-shared key option, provided the key is long enough, is post-quantum secure, the other algorithms are not. Moreover, in implementations where scalability is a requirement, the pre-shared key method may not be suitable. Post-quantum authenticity may be provided by using a post-quantum digital signature.
* 最初の理由は、認証ステップが古典的なままであることです。特に、IKEV2に基づいて確立されたSASの信頼性は、事前に共有キーまたはデジタル署名アルゴリズムを使用して保護されます。キーが十分に長い場合、事前に共有されたキーオプションは、Quantum後の安全性がありますが、他のアルゴリズムはそうではありません。さらに、スケーラビリティが要件である実装では、事前共有キーメソッドが適切ではない場合があります。質量後のデジタル署名を使用して、ポストカンタムの真正性を提供できます。
* Secondly, it should be noted that the purpose of post-quantum algorithms is to provide resistance to attacks mounted in the future. The current threat is that encrypted sessions are subject to eavesdropping and are archived with decryption by quantum computers at some point in the future. Until quantum computers become available, there is no point in attacking the authenticity of a connection because there are no possibilities for exploitation. These only occur at the time of the connection, for example, by mounting an on-path attack. Consequently, there is less urgency for post-quantum authenticity compared to post-quantum confidentiality.
* 第二に、ポストQuantumアルゴリズムの目的は、将来的に取り付けられた攻撃に対する抵抗を提供することであることに注意する必要があります。現在の脅威は、暗号化されたセッションが盗聴の対象となり、将来のある時点で量子コンピューターによる復号化でアーカイブされることです。量子コンピューターが利用可能になるまで、搾取の可能性がないため、接続の信頼性を攻撃する意味はありません。これらは、接続時にのみ発生します。たとえば、パス上の攻撃を取り付けることによって。したがって、質量後の守秘義務と比較して、後四半期の真正性に対する緊急性は少なくなります。
Performing multiple key exchanges while establishing an IKE SA increases the responder's susceptibility to DoS attacks because of an increased amount of resources needed before the initiator is authenticated. This is especially true for post-quantum key exchange methods, where many of them are more memory and/or CPU intensive than the classical counterparts.
IKE SAを確立しながら複数のキー交換を実行すると、イニシエーターが認証される前に必要なリソースの量が増えるため、DOS攻撃に対するResponderの感受性が増加します。これは、特に、それらの多くが古典的なカウンターパートよりも多くのメモリおよび/またはCPU集中的であるポストカントムの主要な交換方法に当てはまります。
Responders may consider recommendations from [RFC8019] to deal with increased DoS-attack susceptibility. It is also possible that the responder only agrees to create an initial IKE SA without performing additional key exchanges if the initiator includes such an option in its proposals. Then, peers immediately rekey the initial IKE SA with the CREATE_CHILD_SA exchange, and additional key exchanges are performed via the IKE_FOLLOWUP_KE exchanges. In this case, at the point when resource-intensive operations are required, the peers have already authenticated each other. However, in the context of hybrid post-quantum key exchanges, this scenario would leave the initial IKE SA (and initial Child SA, if it is created) unprotected against quantum computers. Nevertheless, the rekeyed IKE SA (and Child SAs that will be created over it) will have a full protection. This is similar to the scenario described in [RFC8784]. Depending on the arrangement and peers' policy, this scenario may or may not be appropriate. For example, in the G-IKEv2 protocol [G-IKEV2], the cryptographic materials are sent from the group controller to the group members when the initial IKE SA is created.
応答者は、[RFC8019]からの推奨事項を、DOS攻撃感受性の増加に対処することを検討する場合があります。また、イニシエーターにその提案にそのようなオプションが含まれている場合、追加のキー交換を実行せずに最初のIKE SAを作成することにのみ、レスポンダーが同意する可能性もあります。その後、ピアはすぐにcreate_child_sa Exchangeを使用して最初のIKE SAを再キーし、IKE_FOLLOWUP_KE交換を介して追加のキー交換が実行されます。この場合、リソース集約型の操作が必要な時点で、ピアはすでにお互いを認証しています。ただし、ハイブリッドポストカントムキー交換のコンテキストでは、このシナリオは、量子コンピューターに対して保護されていない最初のIKE SA（および最初の子SAを作成している場合）を残します。それにもかかわらず、再キーリングされたIke SA（およびその上に作成される子SAS）には完全な保護があります。これは、[RFC8784]で説明されているシナリオに似ています。アレンジメントとピアのポリシーに応じて、このシナリオが適切である場合とそうでない場合があります。たとえば、G-kikev2プロトコル[G-kikev2]では、最初のIKESAが作成されたときに、グループコントローラーからグループメンバーに暗号化材料が送信されます。
[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>.
[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>.
[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>.
[RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key
Exchange Protocol Version 2 (IKEv2)", RFC 9242,
DOI 10.17487/RFC9242, May 2022,
<https://www.rfc-editor.org/info/rfc9242>.
[BEYOND-64K]
Tjhai, CJ., Heider, T., and V. Smyslov, "Beyond 64KB Limit
of IKEv2 Payloads", Work in Progress, Internet-Draft,
draft-tjhai-ikev2-beyond-64k-limit-03, 28 July 2022,
<https://datatracker.ietf.org/doc/html/draft-tjhai-ikev2-
beyond-64k-limit-03>.
[G-IKEV2] Smyslov, V. and B. Weis, "Group Key Management using
IKEv2", Work in Progress, Internet-Draft, draft-ietf-
ipsecme-g-ikev2-09, 19 April 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
g-ikev2-09>.
[GROVER] Grover, L., "A fast quantum mechanical algorithm for
database search", Proc. of the Twenty-Eighth Annual ACM
Symposium on the Theory of Computing (STOC), pp. 212-219,
DOI 10.48550/arXiv.quant-ph/9605043, May 1996,
<https://doi.org/10.48550/arXiv.quant-ph/9605043>.
[IKEV2TYPE4ID]
IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters:
Transform Type 4 - Diffie-Hellman Group Transform IDs",
<https://www.iana.org/assignments/ikev2-parameters/>.
[NISTPQCFAQ]
NIST, "Post-Quantum Cryptography Standard", January 2023,
<https://csrc.nist.gov/Projects/post-quantum-cryptography/
faqs>.
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
DOI 10.17487/RFC5723, January 2010,
<https://www.rfc-editor.org/info/rfc5723>.
[RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A
Childless Initiation of the Internet Key Exchange Version
2 (IKEv2) Security Association (SA)", RFC 6023,
DOI 10.17487/RFC6023, October 2010,
<https://www.rfc-editor.org/info/rfc6023>.
[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>.
[RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
Protocol Version 2 (IKEv2) Implementations from
Distributed Denial-of-Service Attacks", RFC 8019,
DOI 10.17487/RFC8019, November 2016,
<https://www.rfc-editor.org/info/rfc8019>.
[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
"Algorithm Implementation Requirements and Usage Guidance
for the Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8247, DOI 10.17487/RFC8247, September 2017,
<https://www.rfc-editor.org/info/rfc8247>.
[RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov,
"Mixing Preshared Keys in the Internet Key Exchange
Protocol Version 2 (IKEv2) for Post-quantum Security",
RFC 8784, DOI 10.17487/RFC8784, June 2020,
<https://www.rfc-editor.org/info/rfc8784>.
This appendix shows some examples of multiple key exchanges. These examples are not normative, and they describe some message flow scenarios that may occur in establishing an IKE or Child SA. Note that some payloads that are not relevant to multiple key exchanges may be omitted for brevity.
この付録は、複数のキー交換の例を示しています。これらの例は規範的ではなく、IKEまたはチャイルドSAの確立で発生する可能性のあるメッセージフローシナリオを説明しています。複数のキー交換に関連しないいくつかのペイロードは、簡潔にするために省略される場合があることに注意してください。
The exchanges below show that the initiator proposes the use of additional key exchanges to establish an IKE SA. The initiator proposes three sets of additional key exchanges, all of which are optional. Therefore, the responder can choose NONE for some or all of the additional exchanges if the proposed key exchange methods are not supported or for whatever reasons the responder decides not to perform the additional key exchange.
以下の交換は、イニシエーターがIKE SAを確立するために追加のキー交換を使用することを提案していることを示しています。イニシエーターは、3セットの追加キー交換を提案します。これらはすべてオプションです。したがって、提案されたキー交換方法がサポートされていない場合、またはレスポンダーが追加のキー交換を実行しないことを決定した場合、レスポンダーは追加の交換の一部またはすべてを選択できます。
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = PQ_KEM_1)
Transform ADDKE1 (ID = PQ_KEM_2)
Transform ADDKE1 (ID = NONE)
Transform ADDKE2 (ID = PQ_KEM_3)
Transform ADDKE2 (ID = PQ_KEM_4)
Transform ADDKE2 (ID = NONE)
Transform ADDKE3 (ID = PQ_KEM_5)
Transform ADDKE3 (ID = PQ_KEM_6)
Transform ADDKE3 (ID = NONE)
<--- HDR(IKE_SA_INIT), SAr1(.. ADDKE*...),
KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = PQ_KEM_2)
Transform ADDKE2 (ID = NONE)
Transform ADDKE3 (ID = PQ_KEM_5)
HDR(IKE_INTERMEDIATE), SK {KEi(1)(PQ_KEM_2)} -->
<--- HDR(IKE_INTERMEDIATE), SK {KEr(1)(PQ_KEM_2)}
HDR(IKE_INTERMEDIATE), SK {KEi(2)(PQ_KEM_5)} -->
<--- HDR(IKE_INTERMEDIATE), SK {KEr(2)(PQ_KEM_5)}
HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } --->
<--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2,
TSi, TSr }
In this particular example, the responder chooses to perform two additional key exchanges. It selects PQ_KEM_2, NONE, and PQ_KEM_5 for the first, second, and third additional key exchanges, respectively. As per [RFC7296], a set of keying materials is derived, in particular SK_d, SK_a[i/r], and SK_e[i/r]. Both peers then perform an IKE_INTERMEDIATE exchange, carrying PQ_KEM_2 payload, which is protected with SK_e[i/r] and SK_a[i/r] keys. After the completion of this IKE_INTERMEDIATE exchange, the SKEYSEED is updated using SK(1), which is the PQ_KEM_2 shared secret, as follows.
この特定の例では、レスポンダーは2つの追加のキー交換を実行することを選択します。それぞれ1番目、2番目、および3番目の追加キー交換で、PQ_KEM_2、NONE、PQ_KEM_5をそれぞれ選択します。[RFC7296]によると、特にSK_D、SK_A [I/R]、およびSK_E [I/R]、キーイング材料のセットが導出されます。両方のピアは、IKE_INTERMEDIATE EXCHENDYを実行し、PQ_KEM_2ペイロードを運びます。これはSK_E [I/R]およびSK_A [I/R]キーで保護されています。このike_intermediate Exchangeが完了した後、SkeseedはSK（1）を使用して更新されます。SK（1）は、次のようにPQ_KEM_2共有秘密です。
SKEYSEED(1) = prf(SK_d, SK(1) | Ni | Nr)
The updated SKEYSEED value is then used to derive the following keying materials.
次に、更新されたSkeySeed値を使用して、次のキーイング材料を導き出します。
{SK_d(1) | SK_ai(1) | SK_ar(1) | SK_ei(1) | SK_er(1) | SK_pi(1) |
SK_pr(1)} = prf+ (SKEYSEED(1), Ni | Nr | SPIi | SPIr)
As per [RFC9242], both peers compute IntAuth_i1 and IntAuth_r1 using the SK_pi(1) and SK_pr(1) keys, respectively. These values are required in the IKE_AUTH phase of the exchange.
[RFC9242]によると、SK_PI（1）とSK_PR（1）キーをそれぞれ使用して、両方のピアがINTAUTH_I1とINTAUTH_R1を計算します。これらの値は、交換のIKE_AUTHフェーズで必要です。
In the next IKE_INTERMEDIATE exchange, the peers use SK_e[i/r](1) and SK_a[i/r](1) keys to protect the PQ_KEM_5 payload. After completing this exchange, keying materials are updated as follows:
次のike_intermediate Exchangeでは、ピアはSK_E [I/R]（1）およびSK_A [I/R]（1）キーを使用して、PQ_KEM_5ペイロードを保護します。この交換を完了した後、キーイングマテリアルは次のように更新されます。
SKEYSEED(2) = prf(SK_d(1), SK(2) | Ni | Nr)
{SK_d(2) | SK_ai(2) | SK_ar(2) | SK_ei(2) | SK_er(2) | SK_pi(2) |
SK_pr(2)} = prf+ (SKEYSEED(2), Ni | Nr | SPIi | SPIr)
In this update, SK(2) is the shared secret from the third additional key exchange, i.e., PQ_KEM_5. Then, both peers compute the values of IntAuth_[i/r]2 using the SK_p[i/r](2) keys.
このアップデートでは、SK（2）は、3番目の追加キーエクスチェンジ、つまりPQ_KEM_5の共有秘密です。次に、SK_P [I/R]（2）キーを使用して、両方のピアがINTAUTH_ [I/R] 2の値を計算します。
After the completion of the second IKE_INTERMEDIATE exchange, both peers continue to the IKE_AUTH exchange phase. As defined in [RFC9242], the values IntAuth_[i/r]2 are used to compute IntAuth, which, in turn, is used to calculate InitiatorSignedOctets and ResponderSignedOctets blobs (see Section 3.3.2 of [RFC9242]).
2回目のIKE_INTERMEDIATE Exchangeが完了した後、両方のピアはIKE_AUTH Exchangeフェーズに進みます。[rfc9242]で定義されているように、値intauth_ [i/r] 2を使用してintauthを計算するために使用されます。
The initiator proposes two sets of optional additional key exchanges, but the responder does not support any of them. The responder chooses NONE for each set. Consequently, the IKE_INTERMEDIATE exchange does not take place, and the exchange proceeds to the IKE_AUTH phase. The resulting keying materials are the same as those derived with [RFC7296].
イニシエーターは、2セットのオプションの追加キー交換を提案しますが、レスポンダーはそれらのいずれもサポートしていません。レスポンダーは、各セットに対して何も選択しません。したがって、IKE_INTERMEDIATE EXCHANGEは行われず、ExchangeはIKE_AUTHフェーズに進みます。結果として生じるキーイング材料は、[RFC7296]で導出された材料と同じです。
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = PQ_KEM_1)
Transform ADDKE1 (ID = PQ_KEM_2)
Transform ADDKE1 (ID = NONE)
Transform ADDKE2 (ID = PQ_KEM_3)
Transform ADDKE2 (ID = PQ_KEM_4)
Transform ADDKE2 (ID = NONE)
<--- HDR(IKE_SA_INIT), SAr1(.. ADDKE*...),
KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = NONE)
Transform ADDKE2 (ID = NONE)
HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } --->
<--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2,
TSi, TSr }
The exchanges below show that the initiator does not propose the use of additional key exchanges to establish an IKE SA, but they are required in order to establish a Child SA. In order to establish a fully quantum-resistant IPsec SA, the responder includes a CHILDLESS_IKEV2_SUPPORTED notification in their IKE_SA_INIT response message. The initiator understands and supports this notification, exchanges a modified IKE_AUTH message with the responder, and rekeys the IKE SA immediately with additional key exchanges. Any Child SA will have to be created via a subsequent CREATED_CHILD_SA exchange.
以下の交換は、イニシエーターがIKE SAを確立するために追加のキー交換を使用することを提案していないことを示していますが、子供SAを確立するために必要です。完全に量子耐性のIPSEC SAを確立するために、レスポンダーには、IKE_SA_INIT応答メッセージにChildLess_ikev2_supported通知が含まれています。イニシエーターは、この通知を理解およびサポートし、修正されたIKE_AUTHメッセージをレスポンダーと交換し、追加のキー交換でIKE SAをすぐに再キーします。子SAは、その後のcreated_child_sa Exchangeを介して作成する必要があります。
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1, --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED)
<--- HDR(IKE_SA_INIT), SAr1,
KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
N(CHILDLESS_IKEV2_SUPPORTED)
HDR(IKE_AUTH), SK{ IDi, AUTH } --->
<--- HDR(IKE_AUTH), SK{ IDr, AUTH }
HDR(CREATE_CHILD_SA),
SK{ SAi(.. ADDKE*...), Ni, KEi(Curve25519) } --->
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = PQ_KEM_1)
Transform ADDKE1 (ID = PQ_KEM_2)
Transform ADDKE2 (ID = PQ_KEM_5)
Transform ADDKE2 (ID = PQ_KEM_6)
Transform ADDKE2 (ID = NONE)
<--- HDR(CREATE_CHILD_SA), SK{ SAr(.. ADDKE*...),
Nr, KEr(Curve25519),
N(ADDITIONAL_KEY_EXCHANGE)(link1) }
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = PQ_KEM_2)
Transform ADDKE2 (ID = PQ_KEM_5)
HDR(IKE_FOLLOWUP_KE), SK{ KEi(1)(PQ_KEM_2), --->
N(ADDITIONAL_KEY_EXCHANGE)(link1) }
<--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(1)(PQ_KEM_2),
N(ADDITIONAL_KEY_EXCHANGE)(link2) }
HDR(IKE_FOLLOWUP_KE), SK{ KEi(2)(PQ_KEM_5), --->
N(ADDITIONAL_KEY_EXCHANGE)(link2) }
<--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(2)(PQ_KEM_5) }
The initiator proposes the combination of PQ_KEM_1, PQ_KEM_2, PQ_KEM_3, and PQ_KEM_4 as the additional key exchanges. The initiator indicates that either PQ_KEM_1 or PQ_KEM_2 must be used to establish an IKE SA, but ADDKE2 Transform Type is optional. Therefore, the responder can either select PQ_KEM_3 or PQ_KEM_4 or omit this key exchange by selecting NONE. Although the responder supports the optional PQ_KEM_3 and PQ_KEM_4 methods, it does not support either the PQ_KEM_1 or the PQ_KEM_2 mandatory method; therefore, it responds with a NO_PROPOSAL_CHOSEN notification.
イニシエーターは、PQ_KEM_1、PQ_KEM_2、PQ_KEM_3、およびPQ_KEM_4の組み合わせを追加のキー交換として提案します。イニシエーターは、PQ_KEM_1またはPQ_KEM_2のいずれかを使用してIKE SAを確立する必要があることを示していますが、ADDKE2変換タイプはオプションです。したがって、レスポンダーはPQ_KEM_3またはPQ_KEM_4を選択するか、[なし]を選択してこのキー交換を省略します。レスポンダーはオプションのPQ_KEM_3およびPQ_KEM_4メソッドをサポートしていますが、PQ_KEM_1またはPQ_KEM_2の必須メソッドのいずれもサポートしていません。したがって、no_proposal_chosen通知で応答します。
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = PQ_KEM_1)
Transform ADDKE1 (ID = PQ_KEM_2)
Transform ADDKE2 (ID = PQ_KEM_3)
Transform ADDKE2 (ID = PQ_KEM_4)
Transform ADDKE2 (ID = NONE)
<--- HDR(IKE_SA_INIT), N(NO_PROPOSAL_CHOSEN)
The design of the extension is driven by the following criteria:
拡張の設計は、次の基準によって駆動されます。
1) Need for PQC in IPsec
1) IPSECのPQCが必要です
1) Quantum computers, which might become feasible in the near future, pose a threat to our classical public key cryptography. PQC, a family of public key cryptography that is believed to be resistant to these computers, needs to be integrated into the IPsec protocol suite to restore confidentiality and authenticity.
1) 近い将来に実行可能になる可能性のある量子コンピューターは、古典的な公開キーの暗号に脅威をもたらします。これらのコンピューターに耐性があると考えられている公開鍵暗号のファミリーであるPQCは、機密性と信頼性を回復するために、IPSECプロトコルスイートに統合する必要があります。
2) Hybrid
2) ハイブリッド
2) There is currently no post-quantum key exchange that is trusted at the level that (EC)DH is trusted for defending against conventional (non-quantum) adversaries. A hybrid post-quantum algorithm to be introduced, along with the well-established primitives, addresses this concern, since the overall security is at least as strong as each individual primitive.
2) 現在、（EC）DHが従来の（非Quantum）敵に対する防御に対して信頼されているレベルで信頼されているQuantum後のキー交換はありません。紹介されるハイブリッドの質量アルゴリズムと、確立されたプリミティブとともに、全体的なセキュリティは少なくとも個々の原始と同じくらい強いため、この懸念に対処します。
3) Focus on post-quantum confidentiality
3) 階級後の機密性に焦点を当てます
3) A passive attacker can store all monitored encrypted IPsec communication today and decrypt it once a quantum computer is available in the future. This attack can have serious consequences that will not be visible for years to come. On the other hand, an attacker can only perform active attacks, such as impersonation of the communicating peers, once a quantum computer is available sometime in the future. Thus, this specification focuses on confidentiality due to the urgency of this problem and presents a defense against the serious attack described above, but it does not address authentication because it is less urgent at this stage.
3) 受動的な攻撃者は、今日監視されているすべての暗号化されたIPSEC通信を今日保存し、将来量子コンピューターが利用可能になったらそれを復号化できます。この攻撃は、今後何年も見えない深刻な結果をもたらす可能性があります。一方、攻撃者は、将来のQuantumコンピューターが利用可能になると、通信ピアのなりすましなどのアクティブな攻撃のみを実行できます。したがって、この仕様は、この問題の緊急性のために機密性に焦点を当てており、上記の深刻な攻撃に対する防御を提示しますが、この段階では緊急性が低いため、認証に対処しません。
4) Limit the amount of exchanged data
4) 交換されたデータの量を制限します
4) The protocol design should be such that the amount of exchanged data, such as public keys, is kept as small as possible, even if the initiator and the responder need to agree on a hybrid group or if multiple public keys need to be exchanged.
4) プロトコル設計は、イニシエーターとレスポンダーがハイブリッドグループに同意する必要がある場合でも、または複数のパブリックキーを交換する必要がある場合でも、パブリックキーなどの交換データの量が可能な限り小さくなるようにする必要があります。
5) Not post-quantum specific
5) 後四分位ではありません
5) Any cryptographic algorithm could be potentially broken in the future by currently unknown or impractical attacks. Quantum computers are merely the most concrete example of this. The design does not categorize algorithms as "post-quantum" or "non-post-quantum", nor does it create assumptions about the properties of the algorithms; meaning that if algorithms with different properties become necessary in the future, this extension can be used unchanged to facilitate migration to those algorithms.
5) 暗号化アルゴリズムは、現在未知または非実用的な攻撃によって将来的に壊れる可能性があります。量子コンピューターは、これの最も具体的な例にすぎません。このデザインは、アルゴリズムを「ポストカントム」または「非ポストQuantum」と分類したり、アルゴリズムのプロパティに関する仮定を作成したりしません。つまり、将来的に異なるプロパティを持つアルゴリズムが必要になる場合、この拡張機能を使用して使用してこれらのアルゴリズムへの移行を促進できます。
6) Limited amount of changes
6) 限られた量の変更
6) A key goal is to limit the number of changes required when enabling a post-quantum handshake. This ensures easier and quicker adoption in existing implementations.
6) 重要な目標は、後四半期の握手を可能にするときに必要な変更の数を制限することです。これにより、既存の実装におけるより簡単かつ迅速な採用が保証されます。
7) Localized changes
7) ローカライズされた変更
7) Another key requirement is that changes to the protocol are limited in scope, in particular, limiting changes in the exchanged messages and in the state machine, so that they can be easily implemented.
7) もう1つの重要な要件は、プロトコルの変更が範囲が制限されていること、特に交換されたメッセージと状態マシンの変更を制限して、簡単に実装できることです。
8) Deterministic operation
8) 決定論的操作
8) This requirement means that the hybrid post-quantum exchange and, thus, the computed keys will be based on algorithms that both client and server wish to support.
8) この要件は、ハイブリッドの質量交換、したがって、計算されたキーがクライアントとサーバーの両方がサポートしたいアルゴリズムに基づいていることを意味します。
9) Fragmentation support
9) 断片化サポート
9) Some PQC algorithms could be relatively bulky and might require fragmentation. Thus, a design goal is the adaptation and adoption of an existing fragmentation method or the design of a new method that allows for the fragmentation of the key shares.
9) 一部のPQCアルゴリズムは比較的かさばる可能性があり、断片化が必要になる場合があります。したがって、設計目標は、既存の断片化方法の適応と採用、またはキー共有の断片化を可能にする新しい方法の設計です。
10) Backward compatibility and interoperability
10）後方互換性と相互運用性
10) This is a fundamental requirement to ensure that hybrid post-quantum IKEv2 and standard IKEv2 implementations as per [RFC7296] are interoperable.
10）これは、[RFC7296]に従って、ハイブリッドの質量IKEV2および標準のIKEV2実装が相互運用可能であることを保証するための基本的な要件です。
11) Compliance with USA Federal Information Processing Standards (FIPS)
11）米国連邦情報処理基準（FIPS）へのコンプライアンス
11) IPsec is widely used in Federal Information Systems, and FIPS certification is an important requirement. However, at the time of writing, none of the algorithms that is believed to be post-quantum is yet FIPS compliant. Nonetheless, it is possible to combine this post-quantum algorithm with a FIPS-compliant key establishment method so that the overall design remains FIPS compliant [NISTPQCFAQ].
11）IPSECは連邦情報システムで広く使用されており、FIPS認定は重要な要件です。ただし、執筆時点では、ポストカントムと考えられているアルゴリズムはまだFIPSに準拠していません。それにもかかわらず、FIPSに準拠したキー確立方法とFIPSに準拠したキー確立方法を組み合わせて、FIPS全体の設計がFIPSに準拠したままになることができます[NISTPQCFAQ]。
12) Ability to use this method with multiple classical (EC)DH key exchanges
12）複数のクラシック（EC）DHキー交換でこの方法を使用する機能
12) In some situations, peers have no single, mutually trusted, key exchange algorithm (e.g., due to local policy restrictions). The ability to combine two (or more) key exchange methods in such a way that the resulting shared key depends on all of them allows peers to communicate in this situation.
12）状況によっては、ピアには、相互に信頼された単一の主要な交換アルゴリズムがありません（たとえば、現地の政策制限のため）。結果の共有キーがそれらすべてに依存するように、2つの（またはそれ以上の）キー交換方法を組み合わせる機能により、この状況でピアがコミュニケーションをとることができます。
This section gives an overview on a number of alternative approaches that have been considered but later discarded. These approaches are as follows.
このセクションでは、考慮されたが後で破棄された多くの代替アプローチの概要を説明します。これらのアプローチは次のとおりです。
* Sending the classical and post-quantum key exchanges as a single transform
* 単一の変換として古典的および四方階建てのキー交換を送信する
* A method to combine the various key exchanges into a single large KE payload was considered. This effort is documented in a previous version of this document (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This method allows us to cleanly apply hybrid key exchanges during the Child SA. However, it does add considerable complexity and requires an independent fragmentation solution.
* さまざまなキー交換を単一の大きなKEペイロードに組み合わせた方法が考慮されました。この取り組みは、このドキュメントの以前のバージョン（ドラフト-TJHAI-IPSECME-HYBRID-QSKE-YIKEV2-01）に文書化されています。この方法により、Child SAの間にハイブリッドキー交換をきれいに適用できます。ただし、かなりの複雑さを追加し、独立した断片化ソリューションが必要です。
* Sending post-quantum proposals and policies in the KE payload only
* KEペイロードのみに四方階の提案とポリシーを送信する
* With the objective of not introducing unnecessary notify payloads, a method to communicate the hybrid post-quantum proposal in the KE payload during the first pass of the protocol exchange was considered. Unfortunately, this design is susceptible to the following downgrade attack. Consider the scenario where there is an on-path attacker sitting between an initiator and a responder. Through the SAi payload, the initiator proposes using a hybrid post-quantum group and, as a fallback, a Diffie-Hellman group; and through the KEi payload, the initiator proposes a list of hybrid post-quantum proposals and policies. The on-path attacker intercepts this traffic and replies with N(INVALID_KE_PAYLOAD), suggesting a downgrade to the fallback Diffie-Hellman group instead. The initiator then resends the same SAi payload and the KEi payload containing the public value of the fallback Diffie-Hellman group. Note that the attacker may forward the second IKE_SA_INIT message only to the responder. Therefore, at this point in time, the responder will not have the information that the initiator prefers the hybrid group. Of course, it is possible for the responder to have a policy to reject an IKE_SA_INIT message that (a) offers a hybrid group but does not offer the corresponding public value in the KEi payload and (b) the responder has not specifically acknowledged that it does not support the requested hybrid group. However, the checking of this policy introduces unnecessary protocol complexity. Therefore, in order to fully prevent any downgrade attacks, using a KE payload alone is not sufficient, and the initiator MUST always indicate its preferred post-quantum proposals and policies in a notify payload in the subsequent IKE_SA_INIT messages following an N(INVALID_KE_PAYLOAD) response.
* 不必要な通知ペイロードを導入しないという目的で、プロトコル交換の最初のパス中にKEペイロードでハイブリッドの測量後提案を伝える方法が考慮されました。残念ながら、このデザインは、次のダウングレード攻撃の影響を受けやすいです。イニシエーターとレスポンダーの間に座っている攻撃者が座っているシナリオを考えてください。SAIペイロードを通じて、イニシエーターは、ハイブリッドポストクアントゥムグループを使用し、フォールバックとしてDiffie-Hellmanグループを使用して提案します。また、KEIペイロードを通じて、イニシエーターは、ハイブリッド後のQuantumの提案とポリシーのリストを提案します。オンパス攻撃者はこのトラフィックをインターセプトし、N（Invalid_ke_Payload）で返信し、代わりにフォールバックDiffie-Hellmanグループのダウングレードを示唆しています。その後、イニシエーターは、同じSAIペイロードと、フォールバックdiffie-hellmanグループの公共価値を含むKEIペイロードを再送信します。攻撃者は、2番目のIKE_SA_INITメッセージをResponderにのみ転送できることに注意してください。したがって、この時点で、レスポンダーは、イニシエーターがハイブリッドグループを好むという情報を持っていません。もちろん、ResponderがIKE_SA_INITメッセージを拒否するポリシーを持つことができます。要求されたハイブリッドグループをサポートしていません。ただし、このポリシーのチェックにより、不必要なプロトコルの複雑さが導入されます。したがって、ダウングレード攻撃を完全に防ぐために、KEペイロードのみを使用するだけでは十分ではありません。イニシエーターは、N（Invalid_Ke_Payload）応答に続く後続のIKE_SA_INITメッセージの通知ペイロードで、その好ましい測量後の提案とポリシーを常に示す必要があります。。
* New payload types to negotiate hybrid proposals and to carry post-quantum public values
* ハイブリッド提案を交渉し、Quantum後のパブリックバリューを伝えるための新しいペイロードタイプ
* Semantically, it makes sense to use a new payload type, which mimics the SA payload, to carry a hybrid proposal. Likewise, another new payload type that mimics the KE payload could be used to transport hybrid public value. Although, in theory, a new payload type could be made backward compatible by not setting its critical flag as per Section 2.5 of [RFC7296], it is believed that it may not be that simple in practice. Since the original release of IKEv2 in RFC 4306, no new payload type has ever been proposed; therefore, this creates a potential risk of having a backward-compatibility issue from nonconformant IKEv2 implementations. Since there appears to be no other compelling advantages apart from a semantic one, the existing Transform Type and notify payloads are used instead.
* 意味的には、ハイブリッドの提案を運ぶために、SAペイロードを模倣する新しいペイロードタイプを使用することは理にかなっています。同様に、KEペイロードを模倣する別の新しいペイロードタイプを使用して、ハイブリッドの公共価値を輸送できます。理論的には、[RFC7296]のセクション2.5に従って批判的なフラグを設定しないことにより、新しいペイロードタイプを後方に互換性のあるものにすることができますが、実際にはそれほど単純ではないかもしれないと考えられています。RFC 4306でのIKEV2の元のリリース以来、新しいペイロードタイプは提案されていません。したがって、これにより、不適合IKEV2実装から後方互換性の問題が発生する潜在的なリスクが生じます。セマンティックなもの以外に他の説得力のある利点はないように見えるため、既存の変換タイプと通知ペイロードは代わりに使用されます。
* Hybrid public value payload
* ハイブリッドパブリックバリューペイロード
* One way to transport the negotiated hybrid public payload, which contains one classical Diffie-Hellman public value and one or more post-quantum public values, is to bundle these into a single KE payload. Alternatively, these could also be transported in a single new hybrid public value payload. However, following the same reasoning as above may not be a good idea from a backward-compatibility perspective. Using a single KE payload would require encoding or formatting to be defined so that both peers are able to compose and extract the individual public values. However, it is believed that it is cleaner to send the hybrid public values in multiple KE payloads: one for each group or algorithm. Furthermore, at this point in the protocol exchange, both peers should have indicated support for handling multiple KE payloads.
* 交渉されたハイブリッドのパブリックペイロードを輸送する1つの方法は、1つの古典的なdiffie-hellmanの公共価値と1つ以上のquantum後のパブリックバリューを含む、これらを単一のKEペイロードに束ねることです。あるいは、これらは単一の新しいハイブリッドパブリックバリューペイロードで輸送することもできます。ただし、上記と同じ推論に従って、後方互換性の観点からは良い考えではないかもしれません。単一のKEペイロードを使用するには、両方のピアが個々のパブリック値を構成して抽出できるように、エンコードまたはフォーマットを定義する必要があります。ただし、複数のKEペイロードでハイブリッドパブリック値を送信することはクリーンであると考えられています。1つはグループまたはアルゴリズムです。さらに、プロトコル交換のこの時点で、両方のピアが複数のKEペイロードを処理するためのサポートを示す必要があります。
* Fragmentation
* 断片化
* The handling of large IKE_SA_INIT messages has been one of the most challenging tasks. A number of approaches have been considered, and the two prominent ones that have been discarded are outlined as follows.
* 大規模なIKE_SA_INITメッセージの処理は、最も挑戦的なタスクの1つです。多くのアプローチが考慮されており、破棄された2つの著名なアプローチが次のように概説されています。
* The first approach is to treat the entire IKE_SA_INIT message as a stream of bytes, which is then split into a number of fragments, each of which is wrapped onto a payload that will fit into the size of the network MTU. The payload that wraps each fragment has a new payload type, and it is envisaged that this new payload type will not cause a backward-compatibility issue because, at this stage of the protocol, both peers should have indicated support of fragmentation in the first pass of the IKE_SA_INIT exchange. The negotiation of fragmentation is performed using a notify payload, which also defines supporting parameters, such as the size of fragment in octets and the fragment identifier. The new payload that wraps each fragment of the messages in this exchange is assigned the same fragment identifier. Furthermore, it also has other parameters, such as a fragment index and total number of fragments. This approach has been discarded due to its blanket approach to fragmentation. In cases where only a few payloads need to be fragmented, this approach appears to be overly complicated.
* 最初のアプローチは、IKE_SA_INITメッセージ全体をバイトのストリームとして扱うことです。これは、多くのフラグメントに分割され、それぞれがネットワークMTUのサイズに適合するペイロードにラップされます。各フラグメントをラップするペイロードには新しいペイロードタイプがあり、この新しいペイロードタイプが後方互換性の問題を引き起こさないことを想定しています。IKE_SA_INIT Exchangeの。フラグメンテーションの交渉は、オクテットのフラグメントのサイズやフラグメント識別子などのサポートパラメーターも定義する通知ペイロードを使用して実行されます。この交換でメッセージの各フラグメントをラップする新しいペイロードには、同じフラグメント識別子が割り当てられます。さらに、フラグメントインデックスやフラグメントの総数など、他のパラメーターもあります。このアプローチは、断片化への毛布アプローチのために廃棄されました。いくつかのペイロードを断片化する必要がある場合、このアプローチは非常に複雑であるように見えます。
* Another idea that has been discarded is fragmenting an individual payload without introducing a new payload type. The idea is to use the 9-th bit (the bit after the critical flag in the RESERVED field) in the generic payload header as a flag to mark that this payload is fragmented. As an example, if a KE payload is to be fragmented, it may look as follows.
* 破棄されたもう1つのアイデアは、新しいペイロードタイプを導入せずに個々のペイロードを断片化することです。アイデアは、一般的なペイロードヘッダーの9番目のビット（予約済みフィールドの批判的なフラグの後にビット）をフラグとして使用することです。このペイロードが断片化されていることをマークすることです。例として、KEペイロードを断片化する場合、次のように見える場合があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C|F| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Number | Fragment Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Index | Total Fragments |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total KE Payload Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Fragmented KE Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Example of How to Fragment a KE Payload
図1：KEペイロードを断片化する方法の例
* When the flag F is set, the current KE payload is a fragment of a larger KE payload. The Payload Length field denotes the size of this payload fragment in octets: including the size of the generic payload header. The 2-octet RESERVED field following Diffie-Hellman Group Number was to be used as a fragment identifier to help the assembly and disassembly of fragments. The Fragment Index and Total Fragments fields are self-explanatory. The Total KE Payload Data Length indicates the size of the assembled KE payload data in octets. Finally, the actual fragment is carried in Fragment KE Payload field.
* フラグFが設定されると、現在のKEペイロードは、より大きなKEペイロードのフラグメントです。ペイロード長さフィールドは、一般的なペイロードヘッダーのサイズを含む、オクテットのこのペイロードフラグメントのサイズを示します。Diffie-Hellmanグループ番号に続く2-OCTET予約フィールドは、断片のアセンブリと分解を支援するフラグメント識別子として使用されます。フラグメントインデックスと総フラグメントフィールドは、自明です。合計KEペイロードデータの長さは、オクテットの組み立てられたKEペイロードデータのサイズを示します。最後に、実際のフラグメントは、フラグメントKEペイロードフィールドで運ばれます。
* This approach has been discarded because it is believed that the working group may not want to use the RESERVED field to change the format of a packet, and that implementers may not like the added complexity from checking the fragmentation flag in each received payload. More importantly, fragmenting the messages in this way may leave the system to be more prone to denial-of-service (DoS) attacks. This issue can be solved using IKE_INTERMEDIATE [RFC9242] to transport the large post-quantum key exchange payloads and using the generic IKEv2 fragmentation protocol [RFC7383].
* このアプローチは、ワーキンググループが予約済みフィールドを使用してパケットの形式を変更したくない場合があり、実装者が受信した各ペイロードのフラグメンテーションフラグをチェックすることで追加された複雑さを好まない可能性があると考えられているため、破棄されています。さらに重要なことは、この方法でメッセージを断片化すると、システムがより拒否（DOS）攻撃を起こしやすくなる可能性があることです。この問題は、IKE_INTERMEDIATE [RFC9242]を使用して、大規模なQuantum後のキーエクスチェンジペイロードを輸送し、一般的なIKEV2断片化プロトコル[RFC7383]を使用して解決できます。
* Group sub-identifier
* グループサブインテッドフィア
* As discussed before, each group identifier is used to distinguish a post-quantum algorithm. Further classification could be made on a particular post-quantum algorithm by assigning an additional value alongside the group identifier. This sub-identifier value may be used to assign different security-parameter sets to a given post-quantum algorithm. However, this level of detail does not fit the principles of the document where it should deal with generic hybrid key exchange protocol and not a specific ciphersuite. Furthermore, there are enough Diffie-Hellman group identifiers should this be required in the future.
* 前に説明したように、各グループの識別子は、四方測量後アルゴリズムを区別するために使用されます。グループ識別子とともに追加値を割り当てることにより、特定の四半期後のアルゴリズムにさらなる分類を行うことができます。このサブインテッド値を使用して、異なるセキュリティパラメーターセットを特定の質量アルゴリズムに割り当てることができます。ただし、このレベルの詳細は、特定の暗号化されていない一般的なハイブリッドキーエクスチェンジプロトコルを扱う必要があるドキュメントの原則に適合しません。さらに、将来これが必要な場合、十分なdiffie-hellmanグループ識別子があります。
The authors would like to thank Frederic Detienne and Olivier Pelerin for their comments and suggestions, including the idea to negotiate the post-quantum algorithms using the existing KE payload. The authors are also grateful to Tobias Heider and Tobias Guggemos for valuable comments. Thanks to Paul Wouters for reviewing the document.
著者は、Frederic DetienneとOlivier Pelerinのコメントや提案に感謝します。これには、既存のKEペイロードを使用して、Quantum後のアルゴリズムを交渉するというアイデアが含まれます。著者はまた、貴重なコメントをしてくれたTobias HeiderとTobias Guggemosにも感謝しています。ドキュメントを確認してくれたPaul Woutersに感謝します。
Cen Jung Tjhai
Post-Quantum
Email: cjt@post-quantum.com
Martin Tomlinson
Post-Quantum
Email: mt@post-quantum.com
Graham Bartlett
Quantum Secret
Email: graham.ietf@gmail.com
Scott Fluhrer
Cisco Systems
Email: sfluhrer@cisco.com
Daniel Van Geest
ISARA Corporation
Email: daniel.vangeest.ietf@gmail.com
Oscar Garcia-Morchon
Philips
Email: oscar.garcia-morchon@philips.com
Valery Smyslov
ELVIS-PLUS
Email: svan@elvis.ru