Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security

3.1. Creating Initial IKE SA

The IKE initiator which supports the IKE_INTERMEDIATE exchange and wants to use PPK to protect initial IKE SA includes the INTERMEDIATE_EXCHANGE_SUPPORTED notification and a notification of type USE_PPK_ALT in the IKE_SA_INIT request. If the responder supports the IKE_INTERMEDIATE exchange and is willing to use PPK for initial IKE SA protection, it includes both these notifications in the IKE_SA_INIT response.¶

Initiator                       Responder
------------------------------------------------------------------
HDR, SAi1, KEi, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED),
N(USE_PPK_ALT)              --->
                        <---    HDR, SAr1, KEr, Nr, [CERTREQ,]
                                N(INTERMEDIATE_EXCHANGE_SUPPORTED),
                                N(USE_PPK_ALT)

The USE_PPK_ALT is a Status Type IKEv2 notification. Its Notify Message Type is <TBA by IANA>, Protocol ID and SPI Size are both set to 0. This specification doesn't define any data that this notification may contain, so the Notification Data is left empty. However, future extensions of this specification may make use of it. Implementations MUST ignore any data they don't understand.¶

Note, that this negotiation is independent from negotiation of using PPK defined in [RFC8784]. The initiator that supports both RFC8784 and this specification MAY include both the USE_PPK_ALT (along with the INTERMEDIATE_EXCHANGE_SUPPORTED) and the USE_PPK notifications if it is configured to use either specification. However, the responder supporting both specifications have to choose one to use, thus it MUST return either USE_PPK_ALT or USE_PPK notification in the response, but not both.¶

If the negotiation was successful, the initiator includes one or more PPK_IDENTITY_KEY notification containing PPK identities the initiator believes are appropriate for the IKE SA being created, into the IKE_INTERMEDIATE request.¶

The PPK_IDENTITY_KEY is a Status Type IKEv2 notification. Its Notify Message Type is <TBA by IANA>, Protocol ID and SPI Size fields are both set to 0. The format of the notification data is shown below on Figure 1.¶

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                             PPK_ID                            ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                        PPK Confirmation                       +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:¶

• PPK_ID (variable) -- PPK_ID as defined in Section 5.1 of [RFC8784].¶

• PPK Confirmation (8 octets) -- value, which allows the responder to check whether it has the same PPK as the initiator for a given PPK_ID. This field contains the first 8 octets of a string computed as prf( PPK, Ni | Nr | SPIi | SPIr ), where prf is the negotiated PRF; PPK is the key value for a specified PPK_ID; Ni, Nr, SPIi, SPIr -- nonces and IKE SPIs for the SA being established.¶

If a series of the IKE_INTERMEDIATE exchanges takes place, the PPK_IDENTITY_KEY notification(s) MUST be sent in the last one, i.e. in the IKE_INTERMEDIATE exchange immediately preceding the IKE_AUTH exchange. If the last IKE_INTERMEDIATE exchange contains other payloads aimed for some other purpose, then the notification(s) MAY be piggybacked with these payloads.¶

Initiator                         Responder
------------------------------------------------------------------
HDR, SK { ... N(PPK_IDENTITY_KEY, PPK_ID_1)
           [, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
           [, N(PPK_IDENTITY_KEY, PPK_ID_n)]}   --->

Depending on the responder's capabilities and policy the following situations are possible.¶

1. If the responder is configured with one of the PPKs which IDs were sent by the initiator and this PPK matches the initiator's one (based on the information from the PPK Confirmation field), then the responder selects this PPK and returns back its identity in the PPK_IDENTITY notification. The PPK_IDENTITY notification is defined in [RFC8784].¶

   Initiator                       Responder
   ---------------------------------------------------------------
                  <---    HDR, SK { ... N(PPK_IDENTITY, PPK_ID_i)}
   

   ¶

   In this case the IKE_AUTH exchange is performed as defined in [RFC7296]. However, the keys for the IKE SA are computed using PPK, as described in Section 3.1.1. If the responder returns PPK identity that was not proposed by the initiator, then the initiator should treat this as a fatal error and MUST abort the IKE SA establishment.¶

2. If the responder doesn't have any of the PPKs which IDs were sent by the initiator or it has some of proposed PPKs, but their values mismatch the initiator's ones (based on the information from the PPK Confirmation field), and using PPK is mandatory for the responder, then it MUST return AUTHENTICATION_FAILED notification and abort creating the IKE SA.¶

   Initiator                       Responder
   ---------------------------------------------------------------
                    <---    HDR, SK {... N(AUTHENTICATION_FAILED)}
   

   ¶

3. If the responder doesn't have any of the PPKs which IDs were sent by the initiator or it has some of proposed PPKs, but their values mismatch the initiator's ones (based on the information from the PPK Confirmation field), and using PPK is optional for the responder, then it doesn't include any PPK_IDENTITY notification to the response.¶

   Initiator                       Responder
   ---------------------------------------------------------------
                           <---    HDR, SK {...}
   

   ¶

   In this case the initiator cannot achieve quantum computer resistance using the proposed PPKs. If this is a requirement for the initiator, then it MUST abort creating IKE SA. Otherwise, the initiator continues with the IKE_AUTH exchange as described in [RFC7296].¶

Since the responder selects PPK before it knows the identity of the initiator, a situation may occur, when the responder agrees to use some PPK in the IKE_INTERMEDIATE exchange, but during the IKE_AUTH exchange discovers that this particular PPK is not associated with the initiator's identity in its local policy. Note, that the responder does have this PPK, but it is just not listed among the PPKs for using with this initiator. In this case the responder SHOULD abort negotiation and return back the AUTHENTICATION_FAILED notification to be consistent with its policy. However, if using PPK with this initiator is marked optional in the local policy, then the responder MAY continue creating IKE SA using the negotiated "wrong" PPK.¶

SKEYSEED' = prf+ (PPK, SK_d)

{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
                           = prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr )

3.2. Using PPKs in the CREATE_CHILD_SA Exchange

If a fresh PPK is available to both peers at the time when IKE SA created using old PPK is still active, peers MAY use this PPK without re-creating the IKE SA. In this case the PPK can be used for creating additional IPsec SAs and rekeying both IKE and IPsec SAs. Since the content of the CREATE_CHILD_SA messages is similar in all these cases, all the payloads not relevant to this specifications are omitted from the diagrams below for brevity. Refer to Section 1.3 of [RFC7296] for the content of the CREATE_CHILD_SA messages.¶

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 identities the initiator believes are appropriate for the SA being created, into the CREATE_CHILD_SA request. The responder sends back the PPK_IDENTITY notification containing the ID of the selected PPK.¶

Initiator                         Responder
------------------------------------------------------------------
HDR, SK { ... N(PPK_IDENTITY_KEY, PPK_ID_1)
        [, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
        [, N(PPK_IDENTITY_KEY, PPK_ID_n)]}   --->
                  <---    HDR, SK { ... N(PPK_IDENTITY, PPK_ID_i)}

In case the responder doesn't support (or is not configured for) using PPKs in the CREATE_CHILD_SA exchange, or doesn't have any of the PPKs which IDs were sent by the initiator, or it has some of proposed PPKs, but their values mismatch the initiator's ones (based on the information from the PPK Confirmation field), then it doesn't include any PPK_IDENTITY notification in the response and new SA is created as defined in [RFC7296]. If this is inappropriate for the initiator, it MAY immediately delete this SA.¶

Otherwise the new SA is created using the selected PPK.¶

SK_d' = prf+ (PPK, SK_d)