rfc9867.original   rfc9867.txt 
Network Working Group V. Smyslov Internet Engineering Task Force (IETF) V. Smyslov
Internet-Draft ELVIS-PLUS Request for Comments: 9867 ELVIS-PLUS
Intended status: Standards Track 23 May 2025 Category: Standards Track September 2025
Expires: 24 November 2025 ISSN: 2070-1721
Mixing Preshared Keys in the IKE_INTERMEDIATE and in the CREATE_CHILD_SA Mixing Preshared Keys in the IKE_INTERMEDIATE and CREATE_CHILD_SA
Exchanges of IKEv2 for Post-quantum Security Exchanges of the Internet Key Exchange Protocol Version 2 (IKEv2) for
draft-ietf-ipsecme-ikev2-qr-alt-10 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 RFC8784 allows IPsec traffic to be protected against someone in RFC 8784 allows IPsec traffic to be protected against someone
storing VPN communications today and decrypting them later, when (and storing VPN communications and decrypting them later, when (and if) a
if) a Cryptographically Relevant Quantum Computer (CRQC) is Cryptographically Relevant Quantum Computer (CRQC) is available. The
available. The protection is achieved by means of a Post-quantum protection is achieved by means of a Post-quantum Preshared Key (PPK)
Preshared Key (PPK) which is mixed into the session keys calculation. that is mixed into the session keys calculation. However, this
However, this protection does not cover an initial IKEv2 Security protection does not cover an initial IKEv2 Security Association (SA),
Association (SA), which might be unacceptable in some scenarios. which might be unacceptable in some scenarios. This specification
This specification defines an alternative way to provide protection defines an alternative way to provide protection against quantum
against quantum computers, which is similar to the solution defined computers, which is similar to the solution defined in RFC 8784, but
in RFC8784, but also protects the initial IKEv2 SA. it also protects the initial IKEv2 SA.
RFC8784 assumes that PPKs are static and thus they are only used when RFC 8784 assumes that PPKs are static and thus they are only used
an initial IKEv2 SA is created. If a fresh PPK is available before when an initial IKEv2 SA is created. If a fresh PPK is available
the IKE SA expired, then the only way to use it is to delete the before the IKE SA expires, then the only way to use it is to delete
current IKE SA and create a new one from scratch, which is the current IKE SA and create a new one from scratch, which is
inefficient. This specification defines a way to use PPKs in active inefficient. This specification defines a way to use PPKs in active
IKEv2 SAs for creating additional IPsec SAs and rekey operations. IKEv2 SAs for creating additional IPsec SAs and rekey operations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 24 November 2025. 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.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4 2. Terminology and Notation
3. Protocol Description . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Description
3.1. Creating Initial IKE SA . . . . . . . . . . . . . . . . . 4 3.1. Creating Initial IKE SA
3.1.1. Computing IKE SA Keys . . . . . . . . . . . . . . . . 9 3.1.1. Computing IKE SA Keys
3.2. Using PPKs in the CREATE_CHILD_SA Exchange . . . . . . . 9 3.2. Using PPKs in the CREATE_CHILD_SA Exchange
3.2.1. Computing Keys . . . . . . . . . . . . . . . . . . . 11 3.2.1. Computing Keys
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. References
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References
7.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Comparison of this Specification with RFC 8784
Appendix A. Comparison of this Specification with RFC8784 . . . 13 Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address
1. Introduction 1. Introduction
The Internet Key Exchange protocol version 2, defined in [RFC7296], The Internet Key Exchange Protocol Version 2 (IKEv2), defined in
is used in the IPsec architecture for performing authenticated key [RFC7296], is used in the IPsec architecture for performing
exchange. An extension to IKEv2 for mixing preshared keys for post- authenticated key exchange. An extension to IKEv2 for mixing
quantum security is defined in [RFC8784]. This extension allows preshared keys for post-quantum security is defined in [RFC8784].
today's IPsec traffic to be protected against future quantum This extension allows today's IPsec traffic to be protected against
computers. The protection is achieved by means of using a Post- future quantum computers. The protection is achieved by means of
quantum Preshared Key (PPK) which is mixed into the session keys using a Post-quantum Preshared Key (PPK) that is mixed into the
calculation. At the time this extension was being developed, the session keys calculation. At the time this extension was being
consensus in the IPsecME WG was that the IPsec traffic was more developed, the consensus in the IPsecME WG was that it was more
important to be protected than the IKE traffic. It was believed that important to protect the IPsec traffic than the IKE traffic. It was
information transferred over IKE SA (including peers' identities) is believed that information transferred over IKE SA (including peers'
less important and extending the protection to also cover initial IKE identities) is less important and that extending the protection to
SA would require serious modifications to core IKEv2 protocol. One also cover the initial IKE SA would require serious modifications to
of the goals was to minimize such changes. It was also decided that the core IKEv2 protocol. One of the goals was to minimize such
immediate rekey of initial IKE SA would add this protection to the changes. It was also decided that immediate rekey of initial IKE SA
new IKE SA (albeit it would not provide protection of the identity of would add this protection to the new IKE SA (albeit it would not
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 [I-D.ietf-ipsecme-g-ikev2]. In this protocol using IKEv2, defined in [G-IKEV2]. In this protocol, the
protocol 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 (GM) 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 it is defined in [RFC8784] is that Another issue with using PPKs as defined in [RFC8784] is that this
this approach assumes that PPKs are static entities, which are approach assumes that PPKs are static entities, which are changed
changed very infrequently. For this reason PPKs are only used once - very infrequently. For this reason, PPKs are only used once when an
when an initial IKE SA is established. This restriction makes it initial IKE SA is established. This restriction makes it difficult
difficult to use PPKs as defined in [RFC8784] when they are changed to use PPKs as defined in [RFC8784] when they are changed relatively
relatively frequently, for example via the use of Quantum Key frequently, for example, via the use of Quantum Key Distribution
Distribution (QKD). If a fresh PPK becomes available before the IKE (QKD). If a fresh PPK becomes available before the IKE SA is
SA is expired, there is no way to use it except for deleting this IKE expired, there is no way to use it except for deleting the IKE SA and
SA and re-creating a new one from scratch using the fresh PPK. recreating a new one from scratch using the fresh PPK.
Some time after the protocol extension for mixing preshared keys in Some time after the protocol extension for mixing preshared keys in
IKEv2 for post-quantum security was defined in [RFC8784], a new IKEv2 for post-quantum security was defined in [RFC8784], a new
IKE_INTERMEDIATE exchange for IKEv2 [RFC9242] was developed. While IKE_INTERMEDIATE exchange for IKEv2 [RFC9242] was developed. While
the primary motivation for developing this exchange was to allow the primary motivation for developing this exchange was to allow
multiple key exchanges to be used in IKEv2 (which is defined in multiple key exchanges to be used in IKEv2 (which is defined in
[RFC9370]), the IKE_INTERMEDIATE exchange itself can be used for [RFC9370]), the IKE_INTERMEDIATE exchange itself can be used for
other purposes too. other purposes too.
This specification defines the use of PPKs in the IKE_INTERMEDIATE This specification defines the use of PPKs in the IKE_INTERMEDIATE
exchange of IKEv2 for post-quantum security, which allows getting exchange of IKEv2 for post-quantum security, which allows getting
full protection against quantum computers for initial IKE SA. full protection against quantum computers for initial IKE SA.
This specification also defines the use of PPKs in the This specification also defines the use of PPKs in the
CREATE_CHILD_SA exchange for creating additional IPsec SAs and for CREATE_CHILD_SA exchange for creating additional IPsec SAs and for
rekeying of IKE and IPsec SAs. This allows implementations to rekeying IKE and IPsec SAs. This allows implementations to leverage
leverage fresh PPKs without the need to delete IKE SA and create it fresh PPKs without the need to delete the IKE SA and create it from
from scratch. scratch.
This specification does not replace the approach defined in RFC 8784. This specification does not replace the approach defined in
Both approaches for using PPKs in IKEv2 can be used depending on the [RFC8784]. Both approaches for using PPKs in IKEv2 can be used
circumstances (see Appendix A). depending on the circumstances (see Appendix A).
2. Terminology and Notation 2. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses the terms defined in [RFC7296]. In particular, This document uses the terms defined in [RFC7296]. In particular,
readers should be familiar with the terms "initiator" and "responder" readers should be familiar with the terms "initiator" and "responder"
as used in that document. as used in that document.
The approach defined in RFC 8784 is referred to as "using PPKs in the The approach defined in [RFC8784] is referred to as "using PPKs in
IKE_AUTH exchange" or simply "using PPKs in IKE_AUTH" throughout this the IKE_AUTH exchange" or simply "using PPKs in IKE_AUTH" throughout
document. this document.
3. Protocol Description 3. Protocol Description
3.1. Creating Initial IKE SA 3.1. Creating Initial IKE SA
The IKE initiator which supports the IKE_INTERMEDIATE exchange and The IKE initiator, which supports the IKE_INTERMEDIATE exchange and
wants to use PPK to protect initial IKE SA includes the wants to use a PPK to protect the initial IKE SA, includes the
INTERMEDIATE_EXCHANGE_SUPPORTED notification and a notification of INTERMEDIATE_EXCHANGE_SUPPORTED notification and a notification of
type USE_PPK_INT in the IKE_SA_INIT request. If the responder 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 supports the IKE_INTERMEDIATE exchange and is willing to use PPK for
initial IKE SA protection, it includes both these notifications in initial IKE SA protection, it includes both these notifications in
the IKE_SA_INIT response. the IKE_SA_INIT response.
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
HDR, SAi1, KEi, Ni, HDR, SAi1, KEi, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED), N(INTERMEDIATE_EXCHANGE_SUPPORTED),
N(USE_PPK_INT) ---> N(USE_PPK_INT) --->
<--- HDR, SAr1, KEr, Nr, [CERTREQ,] <--- HDR, SAr1, KEr, Nr, [CERTREQ,]
N(INTERMEDIATE_EXCHANGE_SUPPORTED), N(INTERMEDIATE_EXCHANGE_SUPPORTED),
N(USE_PPK_INT) N(USE_PPK_INT)
The USE_PPK_INT is a Status Type IKEv2 notification. Its Notify The USE_PPK_INT is a Status Type IKEv2 notification. Its Notify
Message Type is <TBA1 by IANA>, Protocol ID and SPI Size are both set Message Type is 16445; the Protocol ID is set to 0; the Security
to 0. This specification does not define any data that this Parameter Index (SPI) is absent, so the SPI Size is set to 0 too.
notification may contain, so the Notification Data is left empty. This specification does not define any data that this notification
However, future extensions of this specification may make use of it. may contain, so the Notification Data is left empty. However, future
Implementations MUST ignore any data in the notification they do not extensions of this specification may make use of it. Implementations
understand. MUST ignore any data in the notification that they do not understand.
Note that this negotiation is independent from negotiation of using Note that this negotiation is independent from the negotiation of
PPKs as specified in [RFC8784]. An initiator that supports both the using PPKs as specified in [RFC8784]. An initiator that supports
use of PPKs in IKE_AUTH [RFC8784] and in IKE_INTERMEDIATE MAY include both the use of PPKs in IKE_AUTH [RFC8784] and IKE_INTERMEDIATE MAY
both the USE_PPK_INT and the USE_PPK notifications if configured to include both the USE_PPK_INT and USE_PPK notifications if configured
so. However, if the responder supports both specifications and is to do so. However, if the responder supports both specifications and
configured to use PPKs, it has to choose one to use, thus it MUST is configured to use PPKs, it has to choose one to use; thus, it MUST
return either USE_PPK_INT or USE_PPK notification in the response, return either a USE_PPK_INT or a USE_PPK notification in the response
but not both. but not both.
If the initiator did not propose using this extension in the If the initiator did not propose using this extension in the
IKE_SA_INIT request and responder's policy mandates protecting IKE_SA_INIT request and the responder's policy mandates protecting
initial IKE SA with a PPK, then the responder MUST return the initial IKE SA with a PPK, then the responder MUST return the
NO_PROPOSAL_CHOSEN notification. NO_PROPOSAL_CHOSEN notification.
If the negotiation was successful, the initiator includes one or more If the negotiation was successful, the initiator includes one or more
PPK_IDENTITY_KEY notification into the IKE_INTERMEDIATE request with PPK_IDENTITY_KEY notifications in the IKE_INTERMEDIATE request with
PPK identities the initiator believes are appropriate for the IKE SA PPK identities that the initiator believes are appropriate for the
being created, IKE SA being created.
The PPK_IDENTITY_KEY is a Status Type IKEv2 notification. Its Notify The PPK_IDENTITY_KEY is a Status Type IKEv2 notification. Its Notify
Message Type is <TBA2 by IANA>, Protocol ID and SPI Size fields are 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 on both set to 0. The format of the Notification Data is shown below in
Figure 1. Figure 1.
1 2 3 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 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_ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ PPK Confirmation + + PPK Confirmation +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PPK_IDENTITY_KEY Notification Data Format Figure 1: PPK_IDENTITY_KEY Notification Data Format
Where: Where:
* PPK_ID (variable) -- PPK_ID as defined in Section 5.1 of PPK_ID (variable): PPK_ID as defined in Section 5.1 of [RFC8784].
[RFC8784]. The receiver can determine the length of PPK_ID by The receiver can determine the length of PPK_ID by subtracting 8
subtracting 8 (the length of PPK Confirmation) from the (the length of PPK Confirmation) from the Notification Data
Notification Data length. length.
* PPK Confirmation (8 octets) -- value, which allows the responder PPK Confirmation (8 octets): A value that allows the responder to
to check whether it has the same PPK as the initiator for a given 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 PPK_ID. This field contains the first 8 octets of a string
computed as prf( PPK, Ni | Nr | SPIi | SPIr ), where prf is the computed as prf( PPK, Ni | Nr | SPIi | SPIr ), where:
negotiated PRF; PPK is the key value for a specified PPK_ID; Ni,
Nr, SPIi, SPIr -- nonces and IKE SPIs for the SA being * "prf" is the negotiated PRF;
established. * PPK is the key value for a specified PPK_ID;
* Ni, Nr, SPIi, SPIr are nonces and IKE SPIs for the SA being
established.
If a series of the IKE_INTERMEDIATE exchanges takes place, the 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. PPK_IDENTITY_KEY notification(s) MUST be sent in the last one, i.e.,
in the IKE_INTERMEDIATE exchange immediately preceding the IKE_AUTH in the IKE_INTERMEDIATE exchange immediately preceding the IKE_AUTH
exchange. If the last IKE_INTERMEDIATE exchange contains other exchange. If this IKE_INTERMEDIATE exchange contains other payloads
payloads aimed for some other purpose, then the notification(s) MAY aimed for some other purpose, then the notification(s) MAY be
be piggybacked with these payloads. 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.
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
HDR, SK { ... N(PPK_IDENTITY_KEY, PPK_ID_1) HDR, SK { ... N(PPK_IDENTITY_KEY, PPK_ID_1)
[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ... [, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} ---> [, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->
Depending on the responder's capabilities and policy the following Depending on the responder's capabilities and policy, the following
situations are possible. situations are possible:
1. If the responder is configured with one of the PPKs which IDs 1. If the responder is configured with a PPK with an ID that is
were sent by the initiator and this PPK matches the initiator's among the IDs sent by the initiator, and if this PPK matches the
one (based on the information from the PPK Confirmation field), initiator's PPK (based on the information from the PPK
then the responder selects this PPK and returns back its identity Confirmation field), then the responder selects this PPK and
in the PPK_IDENTITY notification. The PPK_IDENTITY notification returns its identity in the PPK_IDENTITY notification. The
is defined in [RFC8784]. PPK_IDENTITY notification is defined in [RFC8784].
Initiator Responder Initiator Responder
--------------------------------------------------------------- ---------------------------------------------------------------
<--- HDR, SK { ... N(PPK_IDENTITY, PPK_ID_i)} <--- HDR, SK { ... N(PPK_IDENTITY, PPK_ID_i)}
In this case the IKE_AUTH exchange is performed as defined in In this case, the IKE_AUTH exchange is performed as defined in
IKEv2 [RFC7296]. However, the keys for the IKE SA are computed IKEv2 [RFC7296]. However, the keys for the IKE SA are computed
using PPK, as described in Section 3.1.1. If the responder using PPK, as described in Section 3.1.1. If the responder
returns a PPK identity that was not proposed by the initiator, returns a PPK identity that was not proposed by the initiator,
then the initiator MUST treat this as a fatal and abort the IKE then the initiator MUST treat this as fatal and abort the IKE SA
SA establishment. establishment.
2. If the responder does not have any of the PPKs which IDs were 2. If the responder does not have a PPK with an ID that matches any
sent by the initiator or it has some of the proposed PPKs, but of IDs sent by the initiator, or if the responder has some of the
their values mismatch the initiator's ones (based on the proposed PPKs but their values are mismatched from the
information from the PPK Confirmation field), and using PPK is initiator's PPKs (based on the information from the PPK
mandatory for the responder, then it MUST return Confirmation field), and if using PPK is mandatory for the
AUTHENTICATION_FAILED notification and abort creating the IKE SA. responder, then it MUST return an AUTHENTICATION_FAILED
notification and abort creating the IKE SA.
Initiator Responder Initiator Responder
--------------------------------------------------------------- ---------------------------------------------------------------
<--- HDR, SK {... N(AUTHENTICATION_FAILED)} <--- HDR, SK {... N(AUTHENTICATION_FAILED)}
3. If the responder does not have any PPKs proposed by the initiator 3. If the responder does not have any PPKs proposed by the
or it has some of the proposed PPKs, but their values mismatch initiator, or if it has only some of the proposed PPKs but their
the initiator's ones (based on the information from the PPK values mismatch the initiator's ones (based on the information
Confirmation field), and using PPK is optional for the responder, from the PPK Confirmation field), and if using PPK is optional
then it does not include any PPK_IDENTITY notification to the for the responder, then it does not include any PPK_IDENTITY
response. notification to the response.
Initiator Responder Initiator Responder
--------------------------------------------------------------- ---------------------------------------------------------------
<--- HDR, SK {...} <--- HDR, SK {...}
In this case the initiator cannot achieve quantum computer In this case, the initiator cannot achieve quantum computer
resistance using the proposed PPKs. If this is a requirement for resistance using the proposed PPKs. If this is a requirement for
the initiator, then it MUST abort creating the IKE SA. the initiator, then it MUST abort creating the IKE SA.
Otherwise, the initiator continues with the IKE_AUTH exchange as Otherwise, the initiator continues with the IKE_AUTH exchange as
described in IKEv2 [RFC7296]. described in IKEv2 [RFC7296].
Table 1 summarizes the above logic for the responder: Table 1 summarizes the above logic for the responder:
+===========+=============+========+===========+====================+ +===========+=============+========+===========+====================+
|Received | Supports |Has one | PPK is | Action | |Received | Supports |Has one | PPK is | Action |
|USE_PPK_INT| USE_PPK_INT |of | mandatory | | |USE_PPK_INT| USE_PPK_INT |of the | mandatory | |
| | |proposed| for | | | | |proposed| for | |
| | |PPKs | initial | | | | |PPKs | initial | |
| | | | IKE SA | | | | | | IKE SA | |
+===========+=============+========+===========+====================+ +===========+=============+========+===========+====================+
|No | * |* | No | [RFC8784] (if | |No | * |* | No | [RFC8784] (if |
| | | | | proposed) or | | | | | | proposed) or |
| | | | | standard IKEv2 | | | | | | standard IKEv2 |
| | | | | protocol | | | | | | protocol |
+-----------+-------------+--------+-----------+--------------------+ +-----------+-------------+--------+-----------+--------------------+
|No | Yes |* | Yes | Send | |No | Yes |* | Yes | Send |
| | | | | NO_PROPOSAL_CHOSEN | | | | | | NO_PROPOSAL_CHOSEN |
+-----------+-------------+--------+-----------+--------------------+ +-----------+-------------+--------+-----------+--------------------+
|Yes | Yes |Yes | * | Section 3.1, | |Yes | Yes |Yes | * | Section 3.1, |
| | | | | Paragraph 16, Item | | | | | | Paragraph 14, Item |
| | | | | 1 (use this | | | | | | 1 (use this |
| | | | | extension) | | | | | | extension) |
+-----------+-------------+--------+-----------+--------------------+ +-----------+-------------+--------+-----------+--------------------+
|Yes | Yes |No | Yes | Section 3.1, | |Yes | Yes |No | Yes | Section 3.1, |
| | | | | Paragraph 16, Item | | | | | | Paragraph 14, Item |
| | | | | 2 (abort | | | | | | 2 (abort |
| | | | | negotiation) | | | | | | negotiation) |
+-----------+-------------+--------+-----------+--------------------+ +-----------+-------------+--------+-----------+--------------------+
|Yes | Yes |No | No | Section 3.1, | |Yes | Yes |No | No | Section 3.1, |
| | | | | Paragraph 16, Item | | | | | | Paragraph 14, Item |
| | | | | 3 (standard IKEv2 | | | | | | 3 (standard IKEv2 |
| | | | | protocol) | | | | | | protocol) |
+-----------+-------------+--------+-----------+--------------------+ +-----------+-------------+--------+-----------+--------------------+
Table 1: Responder's behavior Table 1: Responder's Behavior
Since the responder selects a PPK before it knows the identity of the Since the responder selects a PPK before it knows the identity of the
initiator, a situation may occur, when the responder agrees to use initiator, a situation may occur where the responder agrees to use
some PPK in the IKE_INTERMEDIATE exchange, but during the IKE_AUTH some PPK in the IKE_INTERMEDIATE exchange but then, during the
exchange discovers that this particular PPK is not associated with IKE_AUTH exchange, discovers that this particular PPK is not
the initiator's identity in its local policy. Note that the associated with the initiator's identity in its local policy. Note
responder does have this PPK, but it is just not listed among the that the responder does have this PPK, but it is just not listed
PPKs for using with this initiator. In this case the responder among the PPKs to be used with this initiator. In this case, the
SHOULD abort negotiation and return back the AUTHENTICATION_FAILED responder SHOULD abort negotiation and return back the
notification to be consistent with its policy. However, the AUTHENTICATION_FAILED notification to be consistent with its policy.
responder MAY continue creating IKE SA using the negotiated "wrong" However, the responder MAY continue creating IKE SA using the
PPK if this is acceptable according to its local policy. negotiated "wrong" PPK if this is acceptable according to its local
policy.
3.1.1. Computing IKE SA Keys 3.1.1. Computing IKE SA Keys
Once the PPK is negotiated in the last IKE_INTERMEDIATE exchange, the Once the PPK is negotiated in the IKE_INTERMEDIATE exchange, the IKE
IKE SA keys are recalculated. Note that if the IKE SA keys are also SA keys are recalculated. Note that if the IKE SA keys are also
recalculated as the result of the other actions performed in the recalculated as a result of other actions performed in this
IKE_INTERMEDIATE exchange (for example, as defined in [RFC9370]), IKE_INTERMEDIATE exchange (for example, as defined in [RFC9370]),
then applying the PPK MUST be done after all of them, so that 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 recalculating IKE SA keys with the PPK is the last action before they
are used in the IKE_AUTH exchange. 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.
The IKE SA keys are computed differently compared to how PPKs are The IKE SA keys are computed differently compared to how PPKs are
used in IKE_AUTH. A new SKEYSEED' value is computed using the used in IKE_AUTH. A new SKEYSEED' value is computed using the
negotiated PPK and the most recently computed SK_d key. Note that 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], the PPK is applied to SK_d exactly how it is specified in [RFC8784],
and the result is used as SKEYSEED'. and the result is used as SKEYSEED'.
SKEYSEED' = prf+ (PPK, SK_d) SKEYSEED' = prf+ (PPK, SK_d)
Then the SKEYSEED' is used to recalculate all SK_* keys as defined in Then the SKEYSEED' is used to recalculate all SK_* keys as defined in
Section 2.14 of [RFC7296]. Section 2.14 of [RFC7296].
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr ) = prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr )
In the formula above, Ni and Nr are nonces from the IKE_SA_INIT 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. 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 Note that SK_d, SK_pi, and SK_pr are not individually recalculated
using PPK, as it is defined in [RFC8784]. using PPK, as defined in [RFC8784].
The resulting keys are then used in the IKE_AUTH exchange and in the The resulting keys are then used in the IKE_AUTH exchange and in the
created IKE SA. created IKE SA.
3.2. Using PPKs in the CREATE_CHILD_SA Exchange 3.2. Using PPKs in the CREATE_CHILD_SA Exchange
If a fresh PPK is available to both peers at the time when an 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 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 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 to rekey existing SAs. In this case, the PPK can be used for
additional IPsec SAs and for rekeying both IKE and IPsec SAs creating additional IPsec SAs and for rekeying both IKE and IPsec SAs
regardless whether the current IKE SA was created with the use of a regardless of whether the current IKE SA was created with the use of
PPK (no matter how: in IKE_AUTH, in IKE_INTERMEDIATE or in a PPK (no matter how: in IKE_AUTH, in IKE_INTERMEDIATE, or in
CREATE_CHILD_SA) or not. CREATE_CHILD_SA) or not.
If the initiator wants to use a PPK in the CREATE_CHILD_SA exchange, If the initiator wants to use a PPK in the CREATE_CHILD_SA exchange,
it includes one or more PPK_IDENTITY_KEY notification containing PPK it includes one or more PPK_IDENTITY_KEY notifications containing PPK
identities the initiator believes are appropriate for the SA being identities that the initiator believes are appropriate for the SA
created, into the CREATE_CHILD_SA request. The PPK Confirmation being created in the CREATE_CHILD_SA request. In this case, the PPK
field in this case contains the first 8 octets of a string computed Confirmation field contains the first 8 octets of a string computed
as prf( PPK, Ni | SPIi | SPIr ), where Ni is the initiator's nonce as prf( PPK, Ni | SPIi | SPIr ), where Ni is the initiator's nonce
from the CREATE_CHILD_SA request and SPIi/SPIr - SPIs of the current from the CREATE_CHILD_SA request and SPIi/SPIr are the SPIs of the
IKE SA. If the responder supports using PPKs in the CREATE_CHILD_SA current IKE SA. If the responder supports using PPKs in the
exchange and is configured and ready to do it, then it sends back the CREATE_CHILD_SA exchange and is configured and ready to do it, then
PPK_IDENTITY notification containing the ID of the selected PPK, as it sends back the PPK_IDENTITY notification containing the ID of the
depicted in figures below. selected PPK, as depicted in the figures below.
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
HDR, SK {[N(REKEY_SA),] SA, Ni, [KEi,] TSi, TSr, HDR, SK {[N(REKEY_SA),] SA, Ni, [KEi,] TSi, TSr,
N(PPK_IDENTITY_KEY, PPK_ID_1) N(PPK_IDENTITY_KEY, PPK_ID_1)
[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ... [, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} ---> [, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->
<--- HDR, SK {SA, Nr [KEr,] TSi, TSr, <--- HDR, SK {SA, Nr [KEr,] TSi, TSr,
N(PPK_IDENTITY, PPK_ID_i)} N(PPK_IDENTITY, PPK_ID_i)}
skipping to change at page 10, line 36 skipping to change at line 437
HDR, SK {SA, Ni, KEi, HDR, SK {SA, Ni, KEi,
N(PPK_IDENTITY_KEY, PPK_ID_1) N(PPK_IDENTITY_KEY, PPK_ID_1)
[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ... [, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} ---> [, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->
<--- HDR, SK {SA, Nr, KEr, <--- HDR, SK {SA, Nr, KEr,
N(PPK_IDENTITY, PPK_ID_i)} N(PPK_IDENTITY, PPK_ID_i)}
Figure 3: CREATE_CHILD_SA Exchange for Rekeying IKE SA Figure 3: CREATE_CHILD_SA Exchange for Rekeying IKE SA
In case the responder does not support (or is not configured for) If the responder does not support (or is not configured for) using
using PPKs in the CREATE_CHILD_SA exchange, or does not have any of PPKs in the CREATE_CHILD_SA exchange or does not have a PPK with an
the PPKs which IDs were sent by the initiator, or it has some of ID that matches any of IDs sent by the initiator, or if the responder
proposed PPKs, but their values mismatch the initiator's ones (based has some of the proposed PPKs but their values are mismatched from
on the information from the PPK Confirmation field), then it does not the initiator's PPKs (based on the information from the PPK
include any PPK_IDENTITY notification in the response and new SA is Confirmation field), then it will not include any PPK_IDENTITY
created as defined in IKEv2 [RFC7296]. If this is inappropriate for notifications in the response, and new SA is created as defined in
the initiator, it can immediately delete this SA. IKEv2 [RFC7296]. If this is inappropriate for the initiator, it can
immediately delete this SA.
If using PPKs in CREATE_CHILD_SA is mandatory for the responder and If using PPKs in CREATE_CHILD_SA is mandatory for the responder, and
the initiator does not include any PPK_IDENTITY_KEY notification in the initiator does not include any PPK_IDENTITY_KEY notifications in
the request or the responder does not have any of the PPKs which IDs the request, or if the responder does not have a PPK with an ID that
were sent by the initiator, or it has some of proposed PPKs, but matches any of IDs sent by the initiator, or if the responder has
their values mismatch the initiator's ones (based on the information some of the proposed PPKs but with mismatched values from the
from the PPK Confirmation field), then the responder MUST return the initiator's PPKs (based on the information from the PPK Confirmation
NO_PROPOSAL_CHOSEN notification. field), then the responder MUST return the NO_PROPOSAL_CHOSEN
notification.
Otherwise the new SA is created using the selected PPK. Otherwise, the new SA is created using the selected PPK.
3.2.1. Computing Keys 3.2.1. Computing Keys
For the purpose of calculation session keys for the new SA, the For the purpose of calculation session keys for the new SA, the
current SK_d key is first mixed with the selected PPK: current SK_d key is first mixed with the selected PPK:
SK_d' = prf+ (PPK, SK_d) SK_d' = prf+ (PPK, SK_d)
The resulting key SK_d' is then used instead of SK_d in all formulas 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 for computing keys for the new SA (Sections 2.17 and 2.18 of
[RFC7296], Section 2.2.4 of [RFC9370]). [RFC7296] and Section 2.2.4 of [RFC9370]).
Note that if the PPK that was used for the IKE SA establishment is 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 not changed, then there is no point to use it in the CREATE_CHILD_SA
exchange. exchange.
4. Security Considerations 4. Security Considerations
Security considerations of using Post-quantum Preshared Keys in the Security considerations for using Post-quantum Preshared Keys in the
IKEv2 protocol are discussed in [RFC8784]. Unlike using PPKs in IKEv2 protocol are discussed in [RFC8784]. Unlike using PPKs in
IKE_AUTH, this specification makes even initial IKE SA quantum IKE_AUTH, this specification makes even initial IKE SA quantum
secure. In addition, a PPK is mixed into the SK_* keys calculation 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 before the IKE_AUTH exchange starts, and since the PPK is used in
authentication too, this exchange is quantum secure even against an authentication too, this exchange is quantum secure even against an
active attacker. active attacker.
This specification relies on the IKE_INTERMEDIATE exchange. Refer to This specification relies on the IKE_INTERMEDIATE exchange. Refer to
[RFC9242] for discussion of related security issues. [RFC9242] for discussion of related security issues.
Section 4 of [RFC9370] discusses the potential impact of appearing a Section 4 of [RFC9370] discusses the potential impact of when a CRQC
CRQC to various cryptographic primitives used in IKEv2. It is worth is accessible on various cryptographic primitives used in IKEv2. It
to repeat here that it is believed that security of symmetric key is worthwhile to repeat here that it is believed that the security of
cryptographic primitives will not be affected by CRQC. symmetric key cryptographic primitives will not be affected by CRQC.
5. IANA Considerations 5. IANA Considerations
This document defines two new Notify Message Types in the "IKEv2 Per this document, IANA has added the following Notify Message Types
Notify Message Status Types" registry: in the "IKEv2 Notify Message Status Types" registry:
<TBA1> USE_PPK_INT
<TBA2> PPK_IDENTITY_KEY
6. Acknowledgements
Author would like to thank Paul Wouters for valuable comments and 16445 USE_PPK_INT
Tero Kivinen who made a thorough review of the document and proposed 16446 PPK_IDENTITY_KEY
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.
7. References 6. References
7.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 12, line 44 skipping to change at line 528
"Mixing Preshared Keys in the Internet Key Exchange "Mixing Preshared Keys in the Internet Key Exchange
Protocol Version 2 (IKEv2) for Post-quantum Security", Protocol Version 2 (IKEv2) for Post-quantum Security",
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>.
7.2. Informative References 6.2. Informative References
[I-D.ietf-ipsecme-g-ikev2] [G-IKEV2] Smyslov, V. and B. Weis, "Group Key Management using
Smyslov, V. and B. Weis, "Group Key Management using
IKEv2", Work in Progress, Internet-Draft, draft-ietf- IKEv2", Work in Progress, Internet-Draft, draft-ietf-
ipsecme-g-ikev2-22, 16 March 2025, ipsecme-g-ikev2-23, 31 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme- <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
g-ikev2-22>. 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 RFC8784 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
in IKE_AUTH as defined in [RFC8784]. Instead, it is supposed to be 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 used in situations where the approach defined there does not meet the
requirements, like the need to make the initial IKE SA quantum-secure requirements, like the need to make the initial IKE SA quantum-secure
or the need to choose between several available PPKs. However, if or the need to choose between several available PPKs. However, if
the peers support both using PPKs in IKE_AUTH and this specification, 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 then the latter may also be used in situations where using PPKs in
IKE_AUTH suffices (e.g., when initial IKE SA is not required to be IKE_AUTH suffices (e.g., when the initial IKE SA is not required to
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 is the G-IKEv2 protocol in the GSA_AUTH exchange in the G-IKEv2 protocol [G-IKEV2].
[I-D.ietf-ipsecme-g-ikev2].
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 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 IKEv2 and the GSA_REGISTRATION exchange of G-IKEv2 [G-IKEV2].
[I-D.ietf-ipsecme-g-ikev2].
3. As the PPK exchange happens as separate exchange before IKE_AUTH 3. As the PPK exchange happens as a separate exchange before
this means that initiator can propose several PPKs and responder IKE_AUTH, this means that initiator can propose several PPKs and
can pick one. This is not possible when PPK exchange happens in the responder can pick one. This is not possible when the PPK
the IKE_AUTH. This feature could simplify PPK rollover. exchange happens in the IKE_AUTH. This feature could simplify
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
sides. sides.
The main disadvantage of the approach defined in this document is The main disadvantage of the approach defined in this document is
that it always requires an additional round trip (the that it always requires an additional round trip (the
IKE_INTERMEDIATE exchange) to set up IKE SA and initial IPsec SA. 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
However, if the IKE_INTERMEDIATE exchange has to be used for some some other purposes in any case, then the PPK-related payloads can be
other purposes in any case, then the PPK related payloads can be
piggybacked with other payloads, thus eliminating this penalty. piggybacked with other payloads, thus eliminating this penalty.
Acknowledgements
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.
Author's Address Author's Address
Valery Smyslov Valery Smyslov
ELVIS-PLUS ELVIS-PLUS
PO Box 81 PO Box 81
Moscow (Zelenograd) Moscow (Zelenograd)
124460 124460
Russian Federation Russian Federation
Phone: +7 495 276 0211 Phone: +7 495 276 0211
Email: svan@elvis.ru Email: svan@elvis.ru
 End of changes. 69 change blocks. 
249 lines changed or deleted 255 lines changed or added

This html diff was produced by rfcdiff 1.48.