rfc9867v4.txt   rfc9867.txt 
Internet Engineering Task Force (IETF) V. Smyslov Internet Engineering Task Force (IETF) V. Smyslov
Request for Comments: 9867 ELVIS-PLUS Request for Comments: 9867 ELVIS-PLUS
Category: Standards Track September 2025 Category: Standards Track November 2025
ISSN: 2070-1721 ISSN: 2070-1721
Mixing Preshared Keys in the IKE_INTERMEDIATE and CREATE_CHILD_SA Mixing Preshared Keys in the IKE_INTERMEDIATE and CREATE_CHILD_SA
Exchanges of the Internet Key Exchange Protocol Version 2 (IKEv2) for Exchanges of the Internet Key Exchange Protocol Version 2 (IKEv2) for
Post-Quantum Security Post-Quantum Security
Abstract Abstract
An Internet Key Exchange Protocol Version 2 (IKEv2) extension defined An Internet Key Exchange Protocol Version 2 (IKEv2) extension defined
in RFC 8784 allows IPsec traffic to be protected against someone in RFC 8784 allows IPsec traffic to be protected against someone
skipping to change at line 102 skipping to change at line 102
identities) is less important and that extending the protection to identities) is less important and that extending the protection to
also cover the initial IKE SA would require serious modifications to also cover the initial IKE SA would require serious modifications to
the core IKEv2 protocol. One of the goals was to minimize such the core IKEv2 protocol. One of the goals was to minimize such
changes. It was also decided that immediate rekey of initial IKE SA 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 would add this protection to the new IKE SA (albeit it would not
provide protection of the identity of the peers). provide protection of the identity of the peers).
However, in some situations, it is desirable to have this protection 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 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 created. An example of such a situation is the Group Key Management
protocol using IKEv2, defined in [G-IKEV2]. In this protocol, the protocol using IKEv2, defined in [RFC9838]. In this protocol, the
group policy and session keys are transferred from a Group group policy and session keys are transferred from a Group
Controller/Key Server (GCKS) to the Group Members (GMs) immediately Controller/Key Server (GCKS) to the Group Members (GMs) immediately
once an initial IKE SA is created. While session keys are once an initial IKE SA is created. While session keys are
additionally protected with a key derived from SK_d (and thus are additionally protected with a key derived from SK_d (and thus are
immune to quantum computers if PPKs [RFC8784] are employed), the immune to quantum computers if PPKs [RFC8784] are employed), the
other sensitive data, including group policy, is not. other sensitive data, including group policy, is not.
Another issue with using PPKs as defined in [RFC8784] is that this Another issue with using PPKs as defined in [RFC8784] is that this
approach assumes that PPKs are static entities, which are changed approach assumes that PPKs are static entities, which are changed
very infrequently. For this reason, PPKs are only used once when an very infrequently. For this reason, PPKs are only used once when an
skipping to change at line 530 skipping to change at line 530
RFC 8784, DOI 10.17487/RFC8784, June 2020, RFC 8784, DOI 10.17487/RFC8784, June 2020,
<https://www.rfc-editor.org/info/rfc8784>. <https://www.rfc-editor.org/info/rfc8784>.
[RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key [RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key
Exchange Protocol Version 2 (IKEv2)", RFC 9242, Exchange Protocol Version 2 (IKEv2)", RFC 9242,
DOI 10.17487/RFC9242, May 2022, DOI 10.17487/RFC9242, May 2022,
<https://www.rfc-editor.org/info/rfc9242>. <https://www.rfc-editor.org/info/rfc9242>.
6.2. Informative References 6.2. Informative References
[G-IKEV2] Smyslov, V. and B. Weis, "Group Key Management using [RFC9838] Smyslov, V. and B. Weis, "Group Key Management Using the
IKEv2", Work in Progress, Internet-Draft, draft-ietf- Internet Key Exchange Protocol Version 2 (IKEv2)",
ipsecme-g-ikev2-23, 31 July 2025, RFC 9838, DOI 10.17487/RFC9838, November 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme- <https://www.rfc-editor.org/info/rfc9838>.
g-ikev2-23>.
[RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van [RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
Key Exchanges in the Internet Key Exchange Protocol Key Exchanges in the Internet Key Exchange Protocol
Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May
2023, <https://www.rfc-editor.org/info/rfc9370>. 2023, <https://www.rfc-editor.org/info/rfc9370>.
Appendix A. Comparison of this Specification with RFC 8784 Appendix A. Comparison of this Specification with RFC 8784
This specification is not intended to be a replacement for using PPKs This specification is not intended to be a replacement for using PPKs
skipping to change at line 561 skipping to change at line 560
IKE_AUTH suffices (e.g., when the initial IKE SA is not required to IKE_AUTH suffices (e.g., when the initial IKE SA is not required to
be quantum-protected). be quantum-protected).
The approach defined in this document has the following advantages: The approach defined in this document has the following advantages:
1. The main advantage of using PPK in the IKE_INTERMEDIATE exchange 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 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 fully protected. This means that the ID payloads and any other
sensitive content sent in the IKE_AUTH are protected against sensitive content sent in the IKE_AUTH are protected against
quantum computers. The same is true for the sensitive data sent quantum computers. The same is true for the sensitive data sent
in the GSA_AUTH exchange in the G-IKEv2 protocol [G-IKEV2]. in the GSA_AUTH exchange in the G-IKEv2 protocol [RFC9838].
2. In addition to the IKE_AUTH exchange being fully protected, the 2. In addition to the IKE_AUTH exchange being fully protected, the
initial IKE SA is also fully protected, which is important when initial IKE SA is also fully protected, which is important when
sensitive information is transferred over initial IKE SA. sensitive information is transferred over initial IKE SA.
Examples of such a situation are the CREATE_CHILD_SA exchange of Examples of such a situation are the CREATE_CHILD_SA exchange of
IKEv2 and the GSA_REGISTRATION exchange of G-IKEv2 [G-IKEV2]. IKEv2 and the GSA_REGISTRATION exchange of G-IKEv2 [RFC9838].
3. As the PPK exchange happens as a separate exchange before 3. As the PPK exchange happens as a separate exchange before
IKE_AUTH, this means that initiator can propose several PPKs and IKE_AUTH, this means that initiator can propose several PPKs and
the responder can pick one. This is not possible when the PPK the responder can pick one. This is not possible when the PPK
exchange happens in the IKE_AUTH. This feature could simplify exchange happens in the IKE_AUTH. This feature could simplify
PPK rollover. PPK rollover.
4. With this specification there is no need for the initiator to 4. With this specification there is no need for the initiator to
calculate the content of the AUTH payload twice (with and without calculate the content of the AUTH payload twice (with and without
PPK) to support a situation when using PPK is optional for both PPK) to support a situation when using PPK is optional for both
 End of changes. 5 change blocks. 
9 lines changed or deleted 8 lines changed or added

This html diff was produced by rfcdiff 1.48.