Internet Engineering Task Force (IETF) V. Smyslov
Request for Comments: 9867 ELVIS-PLUS
Category: Standards Track November 2025
ISSN: 2070-1721
An Internet Key Exchange Protocol Version 2 (IKEv2) extension defined in RFC 8784 allows IPsec traffic to be protected against someone storing VPN communications and decrypting them later, when (and if) a Cryptographically Relevant Quantum Computer (CRQC) is available. The protection is achieved by means of a Post-quantum Preshared Key (PPK) that is mixed into the session keys calculation. However, this protection does not cover an initial IKEv2 Security Association (SA), which might be unacceptable in some scenarios. This specification defines an alternative way to provide protection against quantum computers, which is similar to the solution defined in RFC 8784, but it also protects the initial IKEv2 SA.
RFC 8784 で定義されているインターネット キー交換プロトコル バージョン 2 (IKEv2) 拡張機能により、暗号関連量子コンピューター (CRQC) が使用可能な場合に、誰かが VPN 通信を保存し、後で復号化する行為から IPsec トラフィックを保護できます。この保護は、セッション キーの計算に混合されるポスト量子事前共有キー (PPK) によって実現されます。ただし、この保護は初期の IKEv2 セキュリティ アソシエーション (SA) をカバーしていないため、シナリオによっては受け入れられない可能性があります。この仕様は、量子コンピューターに対する保護を提供する代替方法を定義します。これは、RFC 8784 で定義されているソリューションに似ていますが、初期 IKEv2 SA も保護します。
RFC 8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 SA is created. If a fresh PPK is available before the IKE SA expires, then the only way to use it is to delete the current IKE SA and create a new one from scratch, which is inefficient. This specification defines a way to use PPKs in active IKEv2 SAs for creating additional IPsec SAs and rekey operations.
RFC 8784 は、PPK が静的であることを前提としているため、最初の IKEv2 SA が作成されるときにのみ使用されます。IKE SA の有効期限が切れる前に新しい PPK が利用可能な場合、それを使用する唯一の方法は、現在の IKE SA を削除して、新しい PPK を最初から作成することですが、これは非効率的です。この仕様は、追加の IPsec SA およびキー再生成操作を作成するために、アクティブな IKEv2 SA で PPK を使用する方法を定義します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9867.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9867 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology and Notation
3. Protocol Description
3.1. Creating Initial IKE SA
3.1.1. Computing IKE SA Keys
3.2. Using PPKs in the CREATE_CHILD_SA Exchange
3.2.1. Computing Keys
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Comparison of this Specification with RFC 8784
Acknowledgements
Author's Address
The Internet Key Exchange Protocol Version 2 (IKEv2), defined in [RFC7296], is used in the IPsec architecture for performing authenticated key exchange. An extension to IKEv2 for mixing preshared keys for post-quantum security is defined in [RFC8784]. This extension allows today's IPsec traffic to be protected against future quantum computers. The protection is achieved by means of using a Post-quantum Preshared Key (PPK) that is mixed into the session keys calculation. At the time this extension was being developed, the consensus in the IPsecME WG was that it was more important to protect the IPsec traffic than the IKE traffic. It was believed that information transferred over IKE SA (including peers' identities) is less important and that extending the protection to also cover the initial IKE SA would require serious modifications to the core IKEv2 protocol. One of the goals was to minimize such changes. It was also decided that immediate rekey of initial IKE SA would add this protection to the new IKE SA (albeit it would not provide protection of the identity of the peers).
[RFC7296] で定義されているインターネット鍵交換プロトコル バージョン 2 (IKEv2) は、認証された鍵交換を実行するために IPsec アーキテクチャで使用されます。ポスト量子セキュリティのために事前共有鍵を混合するための IKEv2 の拡張機能が [RFC8784] で定義されています。この拡張機能により、現在の IPsec トラフィックを将来の量子コンピューターから保護できるようになります。この保護は、セッション キーの計算に混合されるポスト量子事前共有キー (PPK) を使用することによって実現されます。この拡張機能の開発当時、IPsecME WG のコンセンサスは、IKE トラフィックよりも IPsec トラフィックを保護することが重要であるということでした。IKE SA 経由で転送される情報 (ピアの ID を含む) はそれほど重要ではなく、最初の IKE SA もカバーするように保護を拡張するには、コアの IKEv2 プロトコルに大幅な変更が必要になると考えられていました。目標の 1 つは、そのような変化を最小限に抑えることでした。また、最初の IKE SA の即時キー再生成により、この保護が新しい IKE SA に追加されることも決定されました (ただし、ピアの ID は保護されません)。
However, in some situations, it is desirable to have this protection for the IKE SA from the very beginning, when an initial IKE SA is created. An example of such a situation is the Group Key Management protocol using IKEv2, defined in [RFC9838]. In this protocol, the group policy and session keys are transferred from a Group Controller/Key Server (GCKS) to the Group Members (GMs) immediately once an initial IKE SA is created. While session keys are additionally protected with a key derived from SK_d (and thus are immune to quantum computers if PPKs [RFC8784] are employed), the other sensitive data, including group policy, is not.
ただし、状況によっては、最初の IKE SA が作成されるとき、最初から IKE SA にこの保護を適用することが望ましい場合があります。このような状況の例としては、[RFC9838] で定義されている IKEv2 を使用するグループ キー管理プロトコルがあります。このプロトコルでは、最初の IKE SA が作成されるとすぐに、グループ ポリシーとセッション キーがグループ コントローラー/キー サーバー (GCKS) からグループ メンバー (GM) に転送されます。セッション鍵は SK_d から派生した鍵でさらに保護されます (したがって、PPK [RFC8784] が使用されている場合は量子コンピューターの影響を受けません) が、グループ ポリシーを含む他の機密データは保護されません。
Another issue with using PPKs as defined in [RFC8784] is that this approach assumes that PPKs are static entities, which are changed very infrequently. For this reason, PPKs are only used once when an initial IKE SA is established. This restriction makes it difficult to use PPKs as defined in [RFC8784] when they are changed relatively frequently, for example, via the use of Quantum Key Distribution (QKD). If a fresh PPK becomes available before the IKE SA is expired, there is no way to use it except for deleting the IKE SA and recreating a new one from scratch using the fresh PPK.
[RFC8784] で定義されている PPK の使用に関するもう 1 つの問題は、このアプローチでは PPK が静的エンティティであり、変更される頻度が非常に低いことを前提としていることです。このため、PPK は最初の IKE SA が確立されるときに 1 回だけ使用されます。この制限により、たとえば量子鍵配布 (QKD) の使用などによって PPK が比較的頻繁に変更される場合、[RFC8784] で定義されているように PPK を使用することが困難になります。IKE SA の有効期限が切れる前に新しい PPK が利用可能になった場合、IKE SA を削除し、新しい PPK を使用して新しい PPK を最初から再作成する以外に、それを使用する方法はありません。
Some time after the protocol extension for mixing preshared keys in IKEv2 for post-quantum security was defined in [RFC8784], a new IKE_INTERMEDIATE exchange for IKEv2 [RFC9242] was developed. While the primary motivation for developing this exchange was to allow multiple key exchanges to be used in IKEv2 (which is defined in [RFC9370]), the IKE_INTERMEDIATE exchange itself can be used for other purposes too.
ポスト量子セキュリティのために IKEv2 で事前共有鍵を混合するためのプロトコル拡張が [RFC8784] で定義されてからしばらくして、IKEv2 用の新しい IKE_INTERMEDIATE 交換 [RFC9242] が開発されました。この交換を開発する主な動機は、IKEv2 ([RFC9370] で定義されている) で複数の鍵交換を使用できるようにすることでしたが、IKE_INTERMEDIATE 交換自体は他の目的にも使用できます。
This specification defines the use of PPKs in the IKE_INTERMEDIATE exchange of IKEv2 for post-quantum security, which allows getting full protection against quantum computers for initial IKE SA.
この仕様は、ポスト量子セキュリティのための IKEv2 の IKE_INTERMEDIATE 交換での PPK の使用を定義します。これにより、初期 IKE SA で量子コンピューターに対する完全な保護を得ることができます。
This specification also defines the use of PPKs in the CREATE_CHILD_SA exchange for creating additional IPsec SAs and for rekeying IKE and IPsec SAs. This allows implementations to leverage fresh PPKs without the need to delete the IKE SA and create it from scratch.
この仕様は、追加の IPsec SA の作成および IKE および IPsec SA のキー更新のための CREATE_CHILD_SA 交換での PPK の使用も定義します。これにより、実装では、IKE SA を削除して最初から作成することなく、新しい PPK を利用できるようになります。
This specification does not replace the approach defined in [RFC8784]. Both approaches for using PPKs in IKEv2 can be used depending on the circumstances (see Appendix A).
この仕様は、[RFC8784] で定義されたアプローチを置き換えるものではありません。IKEv2 で PPK を使用するための両方のアプローチは、状況に応じて使用できます (付録 A を参照)。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document uses the terms defined in [RFC7296]. In particular, readers should be familiar with the terms "initiator" and "responder" as used in that document.
この文書では、[RFC7296] で定義されている用語を使用します。特に、読者は、このドキュメントで使用されている「イニシエーター」と「レスポンダー」という用語に精通している必要があります。
The approach defined in [RFC8784] is referred to as "using PPKs in the IKE_AUTH exchange" or simply "using PPKs in IKE_AUTH" throughout this document.
[RFC8784] で定義されているアプローチは、この文書全体を通じて「IKE_AUTH 交換での PPK の使用」または単に「IKE_AUTH での PPK の使用」と呼ばれます。
The IKE initiator, which supports the IKE_INTERMEDIATE exchange and wants to use a PPK to protect the initial IKE SA, includes the INTERMEDIATE_EXCHANGE_SUPPORTED notification and a notification of type USE_PPK_INT in the IKE_SA_INIT request. If the responder supports the IKE_INTERMEDIATE exchange and is willing to use PPK for initial IKE SA protection, it includes both these notifications in the IKE_SA_INIT response.
IKE_INTERMEDIATE 交換をサポートし、初期 IKE SA を保護するために PPK を使用する IKE イニシエーターには、IKE_SA_INIT リクエストに INTERMEDIATE_EXCHANGE_SUPPORTED 通知とタイプ USE_PPK_INT の通知が含まれます。レスポンダが IKE_INTERMEDIATE 交換をサポートし、初期 IKE SA 保護に PPK を使用することを希望する場合、これらの通知の両方が IKE_SA_INIT 応答に含まれます。
Initiator Responder
------------------------------------------------------------------
HDR, SAi1, KEi, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED),
N(USE_PPK_INT) --->
<--- HDR, SAr1, KEr, Nr, [CERTREQ,]
N(INTERMEDIATE_EXCHANGE_SUPPORTED),
N(USE_PPK_INT)
The USE_PPK_INT is a Status Type IKEv2 notification. Its Notify Message Type is 16445; the Protocol ID is set to 0; the Security Parameter Index (SPI) is absent, so the SPI Size is set to 0 too. This specification does not define any data that this notification may contain, so the Notification Data is left empty. However, future extensions of this specification may make use of it. Implementations MUST ignore any data in the notification that they do not understand.
USE_PPK_INT は、ステータス タイプの IKEv2 通知です。通知メッセージ タイプは 16445 です。プロトコル ID は 0 に設定されます。セキュリティ パラメータ インデックス (SPI) が存在しないため、SPI サイズも 0 に設定されます。この仕様では、この通知に含まれるデータは定義されていないため、通知データは空のままです。ただし、この仕様の将来の拡張ではこれが使用される可能性があります。実装は、通知内の理解できないデータを無視しなければなりません (MUST)。
Note that this negotiation is independent from the negotiation of using PPKs as specified in [RFC8784]. An initiator that supports both the use of PPKs in IKE_AUTH [RFC8784] and IKE_INTERMEDIATE MAY include both the USE_PPK_INT and USE_PPK notifications if configured to do so. However, if the responder supports both specifications and is configured to use PPKs, it has to choose one to use; thus, it MUST return either a USE_PPK_INT or a USE_PPK notification in the response but not both.
このネゴシエーションは、[RFC8784] で規定されている PPK を使用するネゴシエーションから独立していることに注意してください。IKE_AUTH [RFC8784] と IKE_INTERMEDIATE での PPK の両方の使用をサポートするイニシエーターは、そうするように設定されている場合、USE_PPK_INT と USE_PPK 通知の両方を含めてもよい(MAY)。ただし、レスポンダが両方の仕様をサポートし、PPK を使用するように構成されている場合は、使用する方を選択する必要があります。したがって、応答で USE_PPK_INT または USE_PPK 通知のいずれかを返さなければなりません (両方を返すことはできません)。
If the initiator did not propose using this extension in the IKE_SA_INIT request and the responder's policy mandates protecting initial IKE SA with a PPK, then the responder MUST return the NO_PROPOSAL_CHOSEN notification.
イニシエーターが IKE_SA_INIT リクエストでこの拡張機能の使用を提案せず、レスポンダーのポリシーが初期 IKE SA を PPK で保護することを義務付けている場合、レスポンダーは NO_PROPOSAL_CHOSEN 通知を返さなければなりません (MUST)。
If the negotiation was successful, the initiator includes one or more PPK_IDENTITY_KEY notifications in the IKE_INTERMEDIATE request with PPK identities that the initiator believes are appropriate for the IKE SA being created.
ネゴシエーションが成功した場合、イニシエーターは、作成中の IKE SA に適切であるとイニシエーターが判断した PPK ID を含む 1 つ以上の PPK_IDENTITY_KEY 通知を IKE_INTERMEDIATE リクエストに含めます。
The PPK_IDENTITY_KEY is a Status Type IKEv2 notification. Its Notify Message Type is 16446; the Protocol ID and the SPI Size fields are both set to 0. The format of the Notification Data is shown below in Figure 1.
PPK_IDENTITY_KEY はステータス タイプ IKEv2 通知です。通知メッセージ タイプは 16446 です。プロトコル ID フィールドと SPI サイズ フィールドは両方とも 0 に設定されます。通知データの形式を以下の図 1 に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ PPK_ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ PPK Confirmation +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PPK_IDENTITY_KEY Notification Data Format
図 1: PPK_IDENTITY_KEY 通知データ形式
Where:
ただし：
PPK_ID (variable):
PPK_ID (変数):
PPK_ID as defined in Section 5.1 of [RFC8784]. The receiver can determine the length of PPK_ID by subtracting 8 (the length of PPK Confirmation) from the Notification Data length.
[RFC8784] のセクション 5.1 で定義されている PPK_ID。受信者は、通知データ長から 8 (PPK 確認の長さ) を減算することで、PPK_ID の長さを決定できます。
PPK Confirmation (8 octets):
PPK 確認 (8 オクテット):
A value that allows the responder to check whether it has the same PPK as the initiator for a given PPK_ID. This field contains the first 8 octets of a string computed as prf( PPK, Ni | Nr | SPIi | SPIr ), where:
レスポンダーが、指定された PPK_ID のイニシエーターと同じ PPK を持っているかどうかを確認できる値。このフィールドには、prf( PPK, Ni | Nr | SPIi | SPIr ) として計算された文字列の最初の 8 オクテットが含まれます。
* "prf" is the negotiated PRF;
* 「prf」はネゴシエートされた PRF です。
* PPK is the key value for a specified PPK_ID;
* PPK は、指定された PPK_ID のキー値です。
* Ni, Nr, SPIi, SPIr are nonces and IKE SPIs for the SA being established.
* Ni、Nr、SPIi、SPIr は、確立中の SA のノンスおよび IKE SPI です。
If a series of the IKE_INTERMEDIATE exchanges takes place, the PPK_IDENTITY_KEY notification(s) MUST be sent in the last one, i.e., in the IKE_INTERMEDIATE exchange immediately preceding the IKE_AUTH exchange. If this IKE_INTERMEDIATE exchange contains other payloads aimed for some other purpose, then the notification(s) MAY be piggybacked with these payloads. Note that future IKEv2 extensions utilizing the IKE_INTERMEDIATE exchange may allow one or more of these exchanges to happen after the one concerned with PPK for the case when such extensions are negotiated.
一連の IKE_INTERMEDIATE 交換が行われる場合、PPK_IDENTITY_KEY 通知は最後の交換、つまり IKE_AUTH 交換の直前の IKE_INTERMEDIATE 交換で送信されなければなりません。この IKE_INTERMEDIATE 交換に他の目的を目的とした他のペイロードが含まれている場合、通知はこれらのペイロードに便乗してもよい(MAY)。IKE_INTERMEDIATE 交換を利用する将来の IKEv2 拡張では、そのような拡張がネゴシエートされる場合に、PPK に関連する交換の後にこれらの交換が 1 つ以上行われる可能性があることに注意してください。
Initiator Responder
------------------------------------------------------------------
HDR, SK { ... N(PPK_IDENTITY_KEY, PPK_ID_1)
[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->
Depending on the responder's capabilities and policy, the following situations are possible:
レスポンダの能力とポリシーに応じて、次の状況が考えられます。
1. If the responder is configured with a PPK with an ID that is among the IDs sent by the initiator, and if this PPK matches the initiator's PPK (based on the information from the PPK Confirmation field), then the responder selects this PPK and returns its identity in the PPK_IDENTITY notification. The PPK_IDENTITY notification is defined in [RFC8784].
1. レスポンダーが、イニシエーターによって送信された ID の中にある ID を持つ PPK で構成されており、この PPK がイニシエーターの PPK と一致する場合 (PPK 確認フィールドからの情報に基づいて)、レスポンダーはこの PPK を選択し、PPK_IDENTITY 通知でその ID を返します。PPK_IDENTITY 通知は [RFC8784] で定義されています。
Initiator Responder
---------------------------------------------------------------
<--- HDR, SK { ... N(PPK_IDENTITY, PPK_ID_i)}
In this case, the IKE_AUTH exchange is performed as defined in IKEv2 [RFC7296]. However, the keys for the IKE SA are computed using PPK, as described in Section 3.1.1. If the responder returns a PPK identity that was not proposed by the initiator, then the initiator MUST treat this as fatal and abort the IKE SA establishment.
この場合、IKE_AUTH 交換は IKEv2 [RFC7296] の定義に従って実行されます。ただし、IKE SA のキーは、セクション 3.1.1 で説明されているように、PPK を使用して計算されます。レスポンダがイニシエータによって提案されていない PPK ID を返した場合、イニシエータはこれを致命的として扱い、IKE SA の確立を中止しなければなりません (MUST)。
2. If the responder does not have a PPK with an ID that matches any of IDs sent by the initiator, or if the responder has some of the proposed PPKs but their values are mismatched from the initiator's PPKs (based on the information from the PPK Confirmation field), and if using PPK is mandatory for the responder, then it MUST return an AUTHENTICATION_FAILED notification and abort creating the IKE SA.
2. レスポンダがイニシエータによって送信された ID のいずれかと一致する ID を持つ PPK を持たない場合、またはレスポンダが提案された PPK の一部を持っているが、その値がイニシエータの PPK と一致しない場合（PPK 確認フィールドからの情報に基づく）、およびレスポンダにとって PPK の使用が必須の場合、レスポンダは AUTHENTICATION_FAILED 通知を返し、IKE SA の作成を中止しなければなりません。
Initiator Responder
---------------------------------------------------------------
<--- HDR, SK {... N(AUTHENTICATION_FAILED)}
3. If the responder does not have any PPKs proposed by the initiator, or if it has only some of the proposed PPKs but their values mismatch the initiator's ones (based on the information from the PPK Confirmation field), and if using PPK is optional for the responder, then it does not include any PPK_IDENTITY notification to the response.
3. レスポンダーがイニシエーターによって提案された PPK を持たない場合、または提案された PPK の一部のみを持っているが、その値がイニシエーターの値と一致しない場合 (PPK 確認フィールドからの情報に基づく)、および PPK の使用がレスポンダーにとってオプションである場合、応答には PPK_IDENTITY 通知が含まれません。
Initiator Responder
---------------------------------------------------------------
<--- HDR, SK {...}
In this case, the initiator cannot achieve quantum computer resistance using the proposed PPKs. If this is a requirement for the initiator, then it MUST abort creating the IKE SA. Otherwise, the initiator continues with the IKE_AUTH exchange as described in IKEv2 [RFC7296].
この場合、イニシエータは、提案された PPK を使用して量子コンピュータ耐性を達成することはできません。これがイニシエータの要件である場合、イニシエータは IKE SA の作成を中止しなければなりません (MUST)。それ以外の場合、イニシエーターは IKEv2 [RFC7296] で説明されているように、IKE_AUTH 交換を続行します。
Table 1 summarizes the above logic for the responder:
表 1 は、レスポンダ用の上記のロジックをまとめたものです。
+===========+=============+========+===========+====================+
|Received | Supports |Has one | PPK is | Action |
|USE_PPK_INT| USE_PPK_INT |of the | mandatory | |
| | |proposed| for | |
| | |PPKs | initial | |
| | | | IKE SA | |
+===========+=============+========+===========+====================+
|No | * |* | No | [RFC8784] (if |
| | | | | proposed) or |
| | | | | standard IKEv2 |
| | | | | protocol |
+-----------+-------------+--------+-----------+--------------------+
|No | Yes |* | Yes | Send |
| | | | | NO_PROPOSAL_CHOSEN |
+-----------+-------------+--------+-----------+--------------------+
|Yes | Yes |Yes | * | Section 3.1, |
| | | | | Paragraph 14, Item |
| | | | | 1 (use this |
| | | | | extension) |
+-----------+-------------+--------+-----------+--------------------+
|Yes | Yes |No | Yes | Section 3.1, |
| | | | | Paragraph 14, Item |
| | | | | 2 (abort |
| | | | | negotiation) |
+-----------+-------------+--------+-----------+--------------------+
|Yes | Yes |No | No | Section 3.1, |
| | | | | Paragraph 14, Item |
| | | | | 3 (standard IKEv2 |
| | | | | protocol) |
+-----------+-------------+--------+-----------+--------------------+
Table 1: Responder's Behavior
表 1: 応答者の行動
Since the responder selects a PPK before it knows the identity of the initiator, a situation may occur where the responder agrees to use some PPK in the IKE_INTERMEDIATE exchange but then, during the IKE_AUTH exchange, discovers that this particular PPK is not associated with the initiator's identity in its local policy. Note that the responder does have this PPK, but it is just not listed among the PPKs to be used with this initiator. In this case, the responder SHOULD abort negotiation and return back the AUTHENTICATION_FAILED notification to be consistent with its policy. However, the responder MAY continue creating IKE SA using the negotiated "wrong" PPK if this is acceptable according to its local policy.
レスポンダはイニシエータの ID を知る前に PPK を選択するため、レスポンダが IKE_INTERMEDIATE 交換で何らかの PPK を使用することに同意したものの、IKE_AUTH 交換中に、この特定の PPK がローカル ポリシー内のイニシエータの ID に関連付けられていないことが判明するという状況が発生する可能性があります。レスポンダーはこの PPK を持っていますが、このイニシエーターで使用される PPK の中にリストされていないだけであることに注意してください。この場合、レスポンダは、そのポリシーと一致するように、ネゴシエーションを中止し、AUTHENTICATION_FAILED 通知を返す必要があります (SHOULD)。ただし、ローカルポリシーに従って許容される場合、レスポンダはネゴシエートされた「間違った」PPK を使用して IKE SA の作成を続けてもよい(MAY)。
Once the PPK is negotiated in the IKE_INTERMEDIATE exchange, the IKE SA keys are recalculated. Note that if the IKE SA keys are also recalculated as a result of other actions performed in this IKE_INTERMEDIATE exchange (for example, as defined in [RFC9370]), then applying the PPK MUST be done after all of them so that recalculating IKE SA keys with the PPK is the last action before they are used in the next exchange. Note that future IKEv2 extensions utilizing the IKE_INTERMEDIATE exchange may update this requirement for the case when such extensions are negotiated.
IKE_INTERMEDIATE 交換で PPK がネゴシエートされると、IKE SA キーが再計算されます。この IKE_INTERMEDIATE 交換で実行される他のアクションの結果として IKE SA キーも再計算される場合 (たとえば、[RFC9370] で定義されているように)、PPK を使用した IKE SA キーの再計算が次の交換で使用される前の最後のアクションとなるように、PPK の適用はすべてのアクションの後に行われなければならないことに注意してください。IKE_INTERMEDIATE 交換を利用する将来の IKEv2 拡張では、そのような拡張がネゴシエートされる場合に備えて、この要件が更新される可能性があることに注意してください。
The IKE SA keys are computed differently compared to how PPKs are used in IKE_AUTH. A new SKEYSEED' value is computed using the negotiated PPK and the most recently computed SK_d key. Note that the PPK is applied to SK_d exactly how it is specified in [RFC8784], and the result is used as SKEYSEED'.
IKE SA キーは、IKE_AUTH での PPK の使用方法とは異なる方法で計算されます。新しい SKEYSEED' 値は、ネゴシエートされた PPK と最後に計算された SK_d キーを使用して計算されます。PPK は [RFC8784] で指定されているとおりに SK_d に適用され、その結果が SKEYSEED' として使用されることに注意してください。
SKEYSEED' = prf+ (PPK, SK_d)
Then the SKEYSEED' is used to recalculate all SK_* keys as defined in Section 2.14 of [RFC7296].
次に、[RFC7296] のセクション 2.14 で定義されているように、SKEYSEED' を使用してすべての SK_* キーが再計算されます。
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr )
In the formula above, Ni and Nr are nonces from the IKE_SA_INIT exchange, and SPIi and SPIr are the SPIs of the IKE SA being created. Note that SK_d, SK_pi, and SK_pr are not individually recalculated using PPK, as defined in [RFC8784].
上の式で、Ni と Nr は IKE_SA_INIT 交換からのノンスで、SPIi と SPIr は作成される IKE SA の SPI です。[RFC8784] で定義されているように、SK_d、SK_pi、および SK_pr は PPK を使用して個別に再計算されないことに注意してください。
The resulting keys are then used in the IKE_AUTH exchange and in the created IKE SA.
結果のキーは、IKE_AUTH 交換と作成された IKE SA で使用されます。
If a fresh PPK is available to both peers at the time when an IKE SA is active, peers MAY use this fresh PPK without creating a new IKE SA from scratch when they have a need to create additional IPsec SAs or to rekey existing SAs. In this case, the PPK can be used for creating additional IPsec SAs and for rekeying both IKE and IPsec SAs regardless of whether the current IKE SA was created with the use of a PPK (no matter how: in IKE_AUTH, in IKE_INTERMEDIATE, or in CREATE_CHILD_SA) or not.
IKE SA がアクティブなときに両方のピアで新しい PPK が利用できる場合、追加の IPsec SA を作成する必要がある場合、または既存の SA のキーを再作成する必要がある場合、ピアは新しい IKE SA を最初から作成せずに、この新しい PPK を使用してもよい(MAY)。この場合、現在の IKE SA が PPK を使用して作成されたかどうか (IKE_AUTH、IKE_INTERMEDIATE、CREATE_CHILD_SA などの方法は関係ありません) に関係なく、追加の IPsec SA の作成と IKE と IPsec SA の両方のキーの再作成に PPK を使用できます。
If the initiator wants to use a PPK in the CREATE_CHILD_SA exchange, it includes one or more PPK_IDENTITY_KEY notifications containing PPK identities that the initiator believes are appropriate for the SA being created in the CREATE_CHILD_SA request. In this case, the PPK Confirmation field contains the first 8 octets of a string computed as prf( PPK, Ni | SPIi | SPIr ), where Ni is the initiator's nonce from the CREATE_CHILD_SA request and SPIi/SPIr are the SPIs of the current IKE SA. If the responder supports using PPKs in the CREATE_CHILD_SA exchange and is configured and ready to do it, then it sends back the PPK_IDENTITY notification containing the ID of the selected PPK, as depicted in the figures below.
イニシエーターが CREATE_CHILD_SA 交換で PPK を使用したい場合、それには、イニシエーターが CREATE_CHILD_SA リクエストで作成される SA に適切であると考える PPK ID を含む 1 つ以上の PPK_IDENTITY_KEY 通知が含まれます。この場合、PPK 確認フィールドには、prf( PPK, Ni | SPIi | SPIr ) として計算された文字列の最初の 8 オクテットが含まれます。ここで、Ni は CREATE_CHILD_SA リクエストからのイニシエーターのノンス、SPIi/SPIr は現在の IKE SA の SPI です。レスポンダが CREATE_CHILD_SA 交換での PPK の使用をサポートし、設定されて準備ができている場合は、以下の図に示すように、選択された PPK の ID を含む PPK_IDENTITY 通知を送り返します。
Initiator Responder
------------------------------------------------------------------
HDR, SK {[N(REKEY_SA),] SA, Ni, [KEi,] TSi, TSr,
N(PPK_IDENTITY_KEY, PPK_ID_1)
[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->
<--- HDR, SK {SA, Nr [KEr,] TSi, TSr,
N(PPK_IDENTITY, PPK_ID_i)}
Figure 2: CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs
図 2: 子 SA を作成またはキー更新するための CREATE_CHILD_SA Exchange
Initiator Responder
------------------------------------------------------------------
HDR, SK {SA, Ni, KEi,
N(PPK_IDENTITY_KEY, PPK_ID_1)
[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->
<--- HDR, SK {SA, Nr, KEr,
N(PPK_IDENTITY, PPK_ID_i)}
Figure 3: CREATE_CHILD_SA Exchange for Rekeying IKE SA
図 3: IKE SA のキーを再生成するための CREATE_CHILD_SA Exchange
If the responder does not support (or is not configured for) using PPKs in the CREATE_CHILD_SA exchange or does not have a PPK with an ID that matches any of IDs sent by the initiator, or if the responder has some of the proposed PPKs but their values are mismatched from the initiator's PPKs (based on the information from the PPK Confirmation field), then it will not include any PPK_IDENTITY notifications in the response, and new SA is created as defined in IKEv2 [RFC7296]. If this is inappropriate for the initiator, it can immediately delete this SA.
レスポンダーが CREATE_CHILD_SA 交換での PPK の使用をサポートしていない (またはそのように構成されていない) 場合、またはイニシエーターによって送信された ID のいずれかと一致する ID を持つ PPK を持っていない場合、またはレスポンダーが提案された PPK の一部を持っているが、その値がイニシエーターの PPK と一致しない場合 (PPK 確認フィールドの情報に基づく)、応答には PPK_IDENTITY 通知が含まれず、新しい SA が作成されます。IKEv2 [RFC7296] で定義されているとおり。これがイニシエータにとって不適切な場合は、この SA を直ちに削除できます。
If using PPKs in CREATE_CHILD_SA is mandatory for the responder, and the initiator does not include any PPK_IDENTITY_KEY notifications in the request, or if the responder does not have a PPK with an ID that matches any of IDs sent by the initiator, or if the responder has some of the proposed PPKs but with mismatched values from the initiator's PPKs (based on the information from the PPK Confirmation field), then the responder MUST return the NO_PROPOSAL_CHOSEN notification.
CREATE_CHILD_SA での PPK の使用がレスポンダーにとって必須であり、イニシエーターがリクエストに PPK_IDENTITY_KEY 通知を含まない場合、またはレスポンダーがイニシエーターによって送信された ID のいずれかと一致する ID を持つ PPK を持たない場合、またはレスポンダーが提案された PPK の一部を持っているが、イニシエーターの PPK の値が一致しない場合 (PPK 確認フィールドからの情報に基づく)、レスポンダーはNO_PROPOSAL_CHOSEN 通知を返さなければなりません。
Otherwise, the new SA is created using the selected PPK.
それ以外の場合、選択した PPK を使用して新しい SA が作成されます。
For the purpose of calculation session keys for the new SA, the current SK_d key is first mixed with the selected PPK:
新しい SA のセッション キーを計算するために、最初に現在の SK_d キーが選択された PPK と混合されます。
SK_d' = prf+ (PPK, SK_d)
The resulting key SK_d' is then used instead of SK_d in all formulas for computing keys for the new SA (Sections 2.17 and 2.18 of [RFC7296] and Section 2.2.4 of [RFC9370]).
結果の鍵 SK_d' は、新しい SA の鍵を計算するためのすべての式で SK_d の代わりに使用されます ([RFC7296] のセクション 2.17 および 2.18、および [RFC9370] のセクション 2.2.4)。
Note that if the PPK that was used for the IKE SA establishment is not changed, then there is no point to use it in the CREATE_CHILD_SA exchange.
IKE SA の確立に使用された PPK が変更されていない場合、それを CREATE_CHILD_SA 交換で使用する意味がないことに注意してください。
Security considerations for using Post-quantum Preshared Keys in the IKEv2 protocol are discussed in [RFC8784]. Unlike using PPKs in IKE_AUTH, this specification makes even initial IKE SA quantum secure. In addition, a PPK is mixed into the SK_* keys calculation before the IKE_AUTH exchange starts, and since the PPK is used in authentication too, this exchange is quantum secure even against an active attacker.
IKEv2 プロトコルでポスト量子事前共有キーを使用する場合のセキュリティに関する考慮事項は、[RFC8784] で説明されています。IKE_AUTH での PPK の使用とは異なり、この仕様により、初期の IKE SA クォンタムも安全になります。さらに、IKE_AUTH 交換が開始される前に、PPK が SK_* キーの計算に混合されます。PPK は認証にも使用されるため、この交換はアクティブな攻撃者に対しても量子的に安全です。
This specification relies on the IKE_INTERMEDIATE exchange. Refer to [RFC9242] for discussion of related security issues.
この仕様は、IKE_INTERMEDIATE 交換に依存しています。関連するセキュリティ問題については、[RFC9242] を参照してください。
Section 4 of [RFC9370] discusses the potential impact of when a CRQC is accessible on various cryptographic primitives used in IKEv2. It is worthwhile to repeat here that it is believed that the security of symmetric key cryptographic primitives will not be affected by CRQC.
[RFC9370] のセクション 4 では、CRQC が IKEv2 で使用されるさまざまな暗号化プリミティブにアクセスできる場合の潜在的な影響について説明しています。ここで繰り返しておく価値があるのは、対称キー暗号化プリミティブのセキュリティは CRQC の影響を受けないと考えられているということです。
Per this document, IANA has added the following Notify Message Types in the "IKEv2 Notify Message Status Types" registry:
この文書に従って、IANA は次の通知メッセージ タイプを「IKEv2 通知メッセージ ステータス タイプ」レジストリに追加しました。
16445
16445
USE_PPK_INT
USE_PPK_INT
16446
16446
PPK_IDENTITY_KEY
PPK_IDENTITY_KEY
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC9838] Smyslov, V. and B. Weis, "Group Key Management Using the
Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 9838, DOI 10.17487/RFC9838, November 2025,
<https://www.rfc-editor.org/info/rfc9838>.
[RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
Key Exchanges in the Internet Key Exchange Protocol
Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May
2023, <https://www.rfc-editor.org/info/rfc9370>.
This specification is not intended to be a replacement for using PPKs in IKE_AUTH as defined in [RFC8784]. Instead, it is supposed to be used in situations where the approach defined there does not meet the requirements, like the need to make the initial IKE SA quantum-secure or the need to choose between several available PPKs. However, if the peers support both using PPKs in IKE_AUTH and this specification, then the latter may also be used in situations where using PPKs in IKE_AUTH suffices (e.g., when the initial IKE SA is not required to be quantum-protected).
この仕様は、[RFC8784] で定義されている IKE_AUTH での PPK の使用に代わるものではありません。代わりに、最初の IKE SA を量子的に安全にする必要がある場合や、複数の利用可能な PPK から選択する必要がある場合など、そこで定義されたアプローチが要件を満たさない状況で使用されることを想定しています。ただし、ピアが IKE_AUTH での PPK の使用とこの仕様の両方をサポートしている場合、IKE_AUTH での PPK の使用で十分な状況 (たとえば、最初の IKE SA が量子保護される必要がない場合) では後者も使用できます。
The approach defined in this document has the following advantages:
このドキュメントで定義されているアプローチには次の利点があります。
1. The main advantage of using PPK in the IKE_INTERMEDIATE exchange instead of the IKE_AUTH exchange is that it allows IKE_AUTH to be fully protected. This means that the ID payloads and any other sensitive content sent in the IKE_AUTH are protected against quantum computers. The same is true for the sensitive data sent in the GSA_AUTH exchange in the G-IKEv2 protocol [RFC9838].
1. IKE_AUTH 交換ではなく IKE_INTERMEDIATE 交換で PPK を使用する主な利点は、IKE_AUTH を完全に保護できることです。これは、IKE_AUTH で送信される ID ペイロードおよびその他の機密コンテンツが量子コンピューターから保護されることを意味します。同じことが、G-IKEv2 プロトコル [RFC9838] の GSA_AUTH 交換で送信される機密データにも当てはまります。
2. In addition to the IKE_AUTH exchange being fully protected, the initial IKE SA is also fully protected, which is important when sensitive information is transferred over initial IKE SA. Examples of such a situation are the CREATE_CHILD_SA exchange of IKEv2 and the GSA_REGISTRATION exchange of G-IKEv2 [RFC9838].
2. IKE_AUTH 交換が完全に保護されていることに加えて、初期 IKE SA も完全に保護されています。これは、機密情報が初期 IKE SA を介して転送される場合に重要です。このような状況の例としては、IKEv2 の CREATE_CHILD_SA 交換や G-IKEv2 [RFC9838] の GSA_REGISTRATION 交換があります。
3. As the PPK exchange happens as a separate exchange before IKE_AUTH, this means that initiator can propose several PPKs and the responder can pick one. This is not possible when the PPK exchange happens in the IKE_AUTH. This feature could simplify PPK rollover.
3. PPK 交換は IKE_AUTH の前に別の交換として行われるため、開始側が複数の PPK を提案し、応答側が 1 つを選択できることを意味します。PPK 交換が IKE_AUTH で行われる場合、これは不可能です。この機能により、PPK ロールオーバーが簡素化される可能性があります。
4. With this specification there is no need for the initiator to calculate the content of the AUTH payload twice (with and without PPK) to support a situation when using PPK is optional for both sides.
4. この仕様を使用すると、PPK の使用が両側でオプションである場合の状況をサポートするために、イニシエーターが AUTH ペイロードの内容を 2 回 (PPK の有無にかかわらず) 計算する必要がなくなります。
The main disadvantage of the approach defined in this document is that it always requires an additional round trip (the IKE_INTERMEDIATE exchange) to set up the IKE SA and the initial IPsec SA. However, if the IKE_INTERMEDIATE exchange has to be used for some other purposes in any case, then the PPK-related payloads can be piggybacked with other payloads, thus eliminating this penalty.
このドキュメントで定義されているアプローチの主な欠点は、IKE SA と最初の IPsec SA を設定するために追加の往復 (IKE_INTERMEDIATE 交換) が常に必要になることです。ただし、いずれの場合でも IKE_INTERMEDIATE 交換を他の目的に使用する必要がある場合は、PPK 関連のペイロードを他のペイロードに便乗させることができるため、このペナルティを排除できます。
Author would like to thank Paul Wouters for valuable comments and Tero Kivinen who made a thorough review of the document and proposed a lot of text improvements, and who also pointed out to the problem of mismatched preshared keys. Thanks to Rebecca Guthrie for providing comments and proposals for the document and to Mikhail Borodin for discovering the problem of calculating PPK Confirmation in CREATE_CHILD_SA.
著者は、貴重なコメントをくれた Paul Wouters と、文書を徹底的にレビューして多くのテキストの改善を提案し、事前共有キーの不一致の問題も指摘してくれた Tero Kivinen に感謝したいと思います。このドキュメントにコメントと提案を提供してくれた Rebecca Guthrie と、CREATE_CHILD_SA での PPK 確認の計算の問題を発見してくれた Mikhail Borodin に感謝します。
Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd)
124460
Russian Federation
Phone: +7 495 276 0211
Email: svan@elvis.ru