rfc9867v1.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 180 skipping to change at line 180
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 16445; the Protocol ID and Security Parameter Index Message Type is 16445; the Protocol ID is set to 0; the Security
(SPI) Size are both set to 0. This specification does not define any Parameter Index (SPI) is absent, so the SPI Size is set to 0 too.
data that this notification may contain, so the Notification Data is This specification does not define any data that this notification
left empty. However, future extensions of this specification may may contain, so the Notification Data is left empty. However, future
make use of it. Implementations MUST ignore any data in the extensions of this specification may make use of it. Implementations
notification that they do not understand. MUST ignore any data in the notification that they do not understand.
Note that this negotiation is independent from the negotiation of Note that this negotiation is independent from the negotiation of
using PPKs as specified in [RFC8784]. An initiator that supports using PPKs as specified in [RFC8784]. An initiator that supports
both the use of PPKs in IKE_AUTH [RFC8784] and IKE_INTERMEDIATE MAY 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 include both the USE_PPK_INT and USE_PPK notifications if configured
to do so. However, if the responder supports both specifications and 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 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 return either a USE_PPK_INT or a USE_PPK notification in the response
but not both. but not both.
skipping to change at line 207 skipping to change at line 207
IKE_SA_INIT request and the 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 notifications in the IKE_INTERMEDIATE request with PPK_IDENTITY_KEY notifications in the IKE_INTERMEDIATE request with
PPK identities that the initiator believes are appropriate for the PPK identities that the initiator believes are appropriate for the
IKE SA 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 16446; the Protocol ID and SPI Size fields are both Message Type is 16446; the Protocol ID and the SPI Size fields are
set to 0. The format of the Notification Data is shown below in 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 ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at line 245 skipping to change at line 245
computed as prf( PPK, Ni | Nr | SPIi | SPIr ), where: computed as prf( PPK, Ni | Nr | SPIi | SPIr ), where:
* "prf" is the negotiated PRF; * "prf" is the negotiated PRF;
* PPK is the key value for a specified PPK_ID; * PPK is the key value for a specified PPK_ID;
* Ni, Nr, SPIi, SPIr are nonces and IKE SPIs for the SA being * Ni, Nr, SPIi, SPIr are nonces and IKE SPIs for the SA being
established. 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 fatal and abort the IKE SA then the initiator MUST treat this as fatal and abort the IKE 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 if 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 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 initiator, or if it has only some of the proposed PPKs but their
values mismatch the initiator's ones (based on the information values mismatch the initiator's ones (based on the information
from the PPK Confirmation field), and if using PPK is optional from the PPK Confirmation field), and if using PPK is optional
for the responder, then it does not include any PPK_IDENTITY for the responder, then it does not include any PPK_IDENTITY
skipping to change at line 354 skipping to change at line 358
that the responder does have this PPK, but it is just not listed 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 among the PPKs to be used with this initiator. In this case, the
responder SHOULD abort negotiation and return back the responder SHOULD abort negotiation and return back the
AUTHENTICATION_FAILED notification to be consistent with its policy. AUTHENTICATION_FAILED notification to be consistent with its policy.
However, the responder MAY continue creating IKE SA using the However, the responder MAY continue creating IKE SA using the
negotiated "wrong" PPK if this is acceptable according to its local negotiated "wrong" PPK if this is acceptable according to its local
policy. 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
skipping to change at line 431 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 if 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 PPKs (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 a 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 notifications in the initiator does not include any PPK_IDENTITY_KEY notifications in
the request, or if the responder does not have any of the PPKs which the request, or if the responder does not have a PPK with an ID that
IDs 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)
skipping to change at line 478 skipping to change at line 486
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 is accessible on various cryptographic primitives used in IKEv2. It
worthwhile to repeat here that it is believed that the security of is worthwhile to repeat here that it is believed that the security of
symmetric key cryptographic primitives will not be affected by CRQC. symmetric key cryptographic primitives will not be affected by CRQC.
5. IANA Considerations 5. IANA Considerations
Per this document, IANA has added the following Notify Message Types Per this document, IANA has added the following Notify Message Types
in the "IKEv2 Notify Message Status Types" registry: in the "IKEv2 Notify Message Status Types" registry:
16445 USE_PPK_INT 16445 USE_PPK_INT
16446 PPK_IDENTITY_KEY 16446 PPK_IDENTITY_KEY
skipping to change at line 522 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 553 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. 15 change blocks. 
52 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.48.