Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security
Extracted elements (29)
Changes are intentionally limited to notifications and adjustments to SK_d/SK_pi/SK_pr to make the extension implementable even on hardware-accelerated IKEv2 systems, and to avoid disrupting existing authentication and key exchange mechanisms.
Only SK_d, SK_pi, and SK_pr are modified by the PPK; SK_ei, SK_er, SK_ai, and SK_ar are left as standard IKEv2 values. This allows the responder to decrypt the IKE_AUTH message using standard keys before it knows which PPK to use, keeping the PPK lookup efficient.
The optional mandatory_or_not flag and NO_PPK_AUTH fallback mechanism were designed to enable incremental deployment without network disruption: upgraded nodes interoperate with unupgraded nodes, and PPK can be made mandatory as a second step after all nodes are upgraded.
When EAP is used, the responder must compute the first AUTH payload in IKE_AUTH using SK_pr' (without PPK) because the PPK_ID is not yet known. The PPK is applied only after the PPK_IDENTITY notification is received in the final IKE_AUTH request containing the AUTH payload.
If a PPK was configured but was not used for a particular IKE SA (e.g., due to misconfiguration), implementations SHOULD audit this event.
If no PPK_IDENTITY notification is found and the peers successfully exchanged USE_PPK notifications in IKE_SA_INIT, the responder MUST send back an AUTHENTICATION_FAILED notification and fail the negotiation.
If the initiator is configured to use a PPK with the responder (whether mandatory or optional), it MUST include a USE_PPK notification in the IKE_SA_INIT request message.
If the PPK_IDENTITY notification contains an unknown PPK_ID and PPKs are mandatory (or no NO_PPK_AUTH was provided), the responder MUST send back an AUTHENTICATION_FAILED notification and fail the negotiation.
If the responder did not include the USE_PPK notification and the mandatory_or_not flag indicates that using PPKs is mandatory for communication with this responder, then the initiator MUST abort the exchange.
If using PPKs for communication with the responder is optional for the initiator, the initiator MUST include a NO_PPK_AUTH notification carrying authentication data computed using SK_pi' (without PPK) in the IKE_AUTH request.
If using PPKs is mandatory for the initiator and no received response contains USE_PPK, the initiator is RECOMMENDED to wait for further retransmissions rather than aborting immediately, to resist active injection attacks.
The PPK MUST NOT be used when SK_d, SK_pi, and SK_pr are calculated as a result of IKE SA rekey, resumption, or other similar operations; it is only used during the initial IKE SA setup.
The security policy SHOULD be set to negotiate only quantum-secure symmetric algorithms; algorithms with key sizes less than 256 bits (including PRF_AES128_XCBC and PRF_AES128_CBC) SHOULD NOT be used with this extension.
To avoid triggering DoS mitigations on the responder due to half-open SAs, it is RECOMMENDED that the initiator cache the negative result of a failed mandatory-PPK negotiation and not retry for at least a few minutes.
Using a group PPK is NOT RECOMMENDED because group members with quantum computers can decrypt each other's recorded traffic, and a stolen group PPK exposes all group communications.
When NULL Authentication is used alongside PPKs, using PPKs MUST be mandatory for the peers that advertise PPK support in IKE_SA_INIT; additionally, the ID Type in IDi/IDr SHOULD NOT be ID_NULL.
Each IKE peer is configured with a tuple (Peer, PPK, PPK_ID, mandatory_or_not). The PPK is independent of any IKEv2 preshared key used for authentication; the mandatory_or_not flag controls whether the exchange is aborted if the peer does not support PPKs.
NO_PPK_AUTH is a status notification (type 16437) included by the initiator when PPK use is optional; its Notification Data field contains authentication data computed using SK_pi' (the pre-PPK value), enabling fallback authentication if the responder lacks the PPK_ID.
PPK_IDENTITY is a status notification (type 16436) sent in IKE_AUTH to carry the PPK_ID selected by the initiator. The responder echoes it with no data to confirm PPK usage.
USE_PPK is a status notification (type 16435) included in IKE_SA_INIT by both initiator and responder to signal willingness to use a Post-quantum Preshared Key. It carries protocol ID 0, no SPI, and no notification data.
New 'IKEv2 Post-quantum Preshared Key ID Types' subregistry created under 'Internet Key Exchange Version 2 (IKEv2) Parameters'. Initial values: 0=Reserved, 1=PPK_ID_OPAQUE, 2=PPK_ID_FIXED, 3-127=Unassigned (Expert Review), 128-255=Private Use.
Three new values added to the 'IKEv2 Notify Message Types - Status Types' subregistry under 'Internet Key Exchange Version 2 (IKEv2) Parameters': 16435=USE_PPK, 16436=PPK_IDENTITY, 16437=NO_PPK_AUTH.
An active attacker can prevent IKE SA creation when PPK is mandatory by injecting a forged IKE_SA_INIT response without USE_PPK before the genuine response arrives, causing the initiator to abort. Mitigation: wait for retransmissions rather than aborting on the first non-USE_PPK response.
An attacker with a quantum computer that breaks the initial IKE SA can access peer identities, configuration parameters, and IPsec SA traffic selectors, but not the Child SA cryptographic keys protected by the PPK. Deployments treating this metadata as sensitive MUST rekey the IKE SA before transmitting it.
If PPK use is optional for both peers and digital signatures are used, a real-time quantum attacker can mount a downgrade attack by stripping the USE_PPK notification and forging signatures. Making PPK mandatory for at least one peer, or using preshared key authentication, prevents this.
The PPK must contain at least 256 bits of entropy to provide 128 bits of post-quantum security (equivalent to NIST Category 5) and resist Grover's algorithm. Deriving a PPK from a password or other low-entropy source is insecure.
The responder's PPK negotiation logic has seven distinct cases based on receipt of USE_PPK, receipt of NO_PPK_AUTH, whether PPK is configured, and whether PPK is mandatory. Outcomes are: standard IKEv2 protocol, use PPK, or abort negotiation (see Table 1).
PPK_ID is a variable-length octet string whose first octet is the PPK_ID type (1=PPK_ID_OPAQUE, 2=PPK_ID_FIXED). For PPK_ID_FIXED, the remaining bytes are the configured identifier value; it is recommended that both PPK and PPK_ID be limited to the base64 character set for interoperability.
The modified IKEv2 key derivation computes intermediate keys SK_d', SK_pi', SK_pr' via the standard process, then derives final keys as SK_d = prf+(PPK, SK_d'), SK_pi = prf+(PPK, SK_pi'), SK_pr = prf+(PPK, SK_pr'). For PRFs where output size equals key size, only one prf iteration is needed: SK_d = prf(PPK, SK_d' | 0x01).