rfc9867v1.txt   rfc9867.txt 
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 ID that matches any of
sent by the initiator, or if it has some of the proposed PPKs but 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
 End of changes. 8 change blocks. 
35 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.48.