RFC 8784
Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security
RFC 8784: Mixing Preshared Keys in IKEv2 for Post-quantum Security 🦋
Okay bestie, this one is from the IETF (Internet Engineering Task Force) and it's RFC 8784 💖. It's on the Standards Track (meaning it's a real Internet standard, not just a suggestion), and its ISSN is 2070-1721. It was published in June 2020 by S. Fluhrer, P. Kampanakis, D. McGrew (all from Cisco Systems) and V. Smyslov (from ELVIS-PLUS) 🧚. The title block doesn't list anything it obsoletes or updates, so it's a standalone doc 🌸.
Abstract
Quantum computers are a huge threat to the crypto we use everywhere right now 😭. IKEv2 is one of the protocols that could get cracked: someone could totally save your VPN traffic today and decrypt it later once a quantum computer exists. People expect IKEv2 to get quantum-safe key exchange algorithms eventually, but that's probably not happening anytime soon 💀. So this doc gives IKEv2 an extension that makes it resistant to quantum computers by using preshared keys 🔥.
Status of This Memo
This is an Internet Standards Track document 👑.
This document is a product of the Internet Engineering Task Force (IETF) 🌈. It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication ✨. If you want more info on Internet Standards, check out Section 2 of RFC 7841 🎀.
Info about the current status of this doc, any errata, and how to send feedback is at https://www.rfc-editor.org/info/rfc8784 🦋.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they stand on the date this doc was published 📜. Please read these carefully, because they explain your rights and restrictions for this doc 🫶. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💅.
Table of Contents
1. Introduction
1.1. Requirements Language
2. Assumptions
3. Exchanges
4. Upgrade Procedure
5. PPK
5.1. PPK_ID Format
5.2. Operational Considerations
5.2.1. PPK Distribution
5.2.2. Group PPK
5.2.3. PPK-Only Authentication
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Discussion and Rationale
Acknowledgements
Authors' Addresses1. Introduction ✨
Okay so recent progress in building quantum computers shows it's probably doable to build one that's cryptographically significant 😳. If that happens, a lot of the crypto algorithms and protocols we use today would be insecure 💀. A quantum computer could solve Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) problems in polynomial time [C2PQ], which means the security of existing IKEv2 [RFC7296] systems would be compromised 🔥. IKEv1 [RFC2409] is different: when it's used with strong preshared keys, quantum attacks don't work on it, because those keys are one of the inputs to the key derivation function 🧠. If the preshared key has enough entropy and the Pseudorandom Function (PRF), encryption, and authentication transforms are quantum secure, then the whole system is believed to be quantum secure. That means it's secure against today's classical attackers and also against future attackers with a quantum computer 🌸.
This doc is all about giving IKEv2 that same property 🦋. As long as the two end systems share a long secret key, the resulting exchange is quantum secure ✨. Bringing post-quantum security to IKEv2 means you don't have to fall back on an obsolete version of IKE just to get that security goal 🫶.
Here's the general idea: we add an extra secret that's shared between the initiator and the responder 🎀. This secret is on top of the authentication method IKEv2 already has. We stir it into the SK_d value, which is used to make the key material (KEYMAT) for the Child Security Associations (SAs), and also the SKEYSEED for the IKE SAs that get created from the initial IKE SA rekey 💅. That secret is what gives quantum resistance to the IPsec SAs and to any IKE SAs after them 👑. We also stir the secret into the SK_pi and SK_pr values, so both sides can detect a secret mismatch cleanly 🙈.
Minimizing changes to IKEv2 was a big priority 💜. The existing mechanisms for authentication and key exchange stay exactly where they are. That means we still do (EC)DH and, if it's configured, PKI authentication 🌈. This doc doesn't replace the authentication checks the protocol already does. Instead, it strengthens them by adding an extra secret key 💪.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📖.
2. Assumptions 🌸
We assume every IKE peer has a list of Post-quantum Preshared Keys (PPKs) along with their identifiers (PPK_ID) 🔑. Any potential IKE initiator picks which PPK to use with a specific responder 🎯. Implementations also have a configurable flag that says whether that PPK is mandatory ⭐. This PPK is totally independent of any preshared key (if there is one) that IKEv2 uses for authentication. That's because the IKEv2 preshared key isn't used in any key derivation, so it doesn't protect against quantum computers 💀. The PPK-specific configuration each node is assumed to have is this tuple:
Peer, PPK, PPK_ID, mandatory_or_notWe assume the reader already knows the payload notation defined in Section 1.2 of [RFC7296] 🧚.
3. Exchanges 💖
If the initiator is set up to use a PPK with the responder (whether or not using the PPK is mandatory), then it MUST include a notification USE_PPK in the IKE_SA_INIT request message, like this 🦋:
Initiator Responder
------------------------------------------------------------------
HDR, SAi1, KEi, Ni, N(USE_PPK) --->N(USE_PPK) is a status notification payload with the type 16435 ✨. It has a protocol ID of 0, no Security Parameter Index (SPI), and no notification data attached 🎀.
If the initiator has to resend this initial message with a COOKIE notification, the resend includes the USE_PPK notification only if the original message did 🔁 (see Section 2.6 of [RFC7296]).
If the responder doesn't support this spec, or it doesn't have any PPK configured, then it ignores the received notification 🙈. It does that the way [RFC7296] says to handle unknown status notifications, and it keeps going with IKEv2 like normal 💅. Otherwise, the responder replies with an IKE_SA_INIT message that includes a USE_PPK notification in the response 🫶:
Initiator Responder
------------------------------------------------------------------
<--- HDR, SAr1, KEr, Nr, [CERTREQ,] N(USE_PPK)When the initiator gets this reply, it checks whether the responder included the USE_PPK notification 👀. If the responder didn't include it, and the mandatory_or_not flag says PPKs are mandatory for talking to this responder, then the initiator MUST abort the exchange 🚨. This can happen with a misconfiguration: the initiator thinks it has a mandatory-to-use PPK for the responder, but the responder either doesn't support PPKs at all or doesn't have any PPK configured for the initiator 😬. Check Section 6 for the possible impacts of this situation 📚.
If the responder didn't include the USE_PPK notification and using a PPK with this particular responder is optional, then the initiator just keeps going with IKEv2 as normal, without PPKs 🌈.
If the responder did include the USE_PPK notification, then the initiator selects a PPK along with its identifier PPK_ID ✨. Then it computes this modified version of the standard IKEv2 key derivation from Section 2.14 of [RFC7296] 🧮:
SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr'}
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr)
SK_d = prf+ (PPK, SK_d')
SK_pi = prf+ (PPK, SK_pi')
SK_pr = prf+ (PPK, SK_pr')So basically, we run the standard IKEv2 key derivation process 🔥. The only difference is that the three resulting subkeys SK_d, SK_pi, and SK_pr (the ones with primes in the formula above) then go through prf+ again, this time using the PPK as the key 💜. The output is the unprimed versions of those keys, and those are what get used in the later steps of the IKEv2 exchange 🎀.
Using a prf+ construction makes sure you can always get keys the same size as the originals, even when the underlying PRF's output size is different from its key size 📏. At the time of writing, all PRFs defined for IKEv2 (see the "Transform Type 2 - Pseudorandom Function Transform IDs" subregistry [IANA-IKEV2]) have an output size equal to their (preferred) key size 💅. For those PRFs, only the first iteration of prf+ is needed:
SK_d = prf (PPK, SK_d' | 0x01)
SK_pi = prf (PPK, SK_pi' | 0x01)
SK_pr = prf (PPK, SK_pr' | 0x01)⚠️ Heads up: the PPK is used in the SK_d, SK_pi, and SK_pr calculations only during the initial IKE SA setup. It MUST NOT be used when these subkeys are calculated as the result of an IKE SA rekey, resumption, or other similar operations 🙅♀️.
Then the initiator sends the IKE_AUTH request message, including the PPK_ID value like this 🦋:
Initiator Responder
------------------------------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2,
TSi, TSr, N(PPK_IDENTITY, PPK_ID), [N(NO_PPK_AUTH)]} --->PPK_IDENTITY is a status notification with the type 16436 🌟. It has a protocol ID of 0 and no SPI, and its notification data is the identifier PPK_ID 🫶.
That's the end of part 1 🍓.
A situation can pop up where the responder has some PPKs but doesn't have one matching the PPK_ID the initiator sent 🥺. In that case the responder can't continue with the PPK (it can't authenticate the initiator with it), BUT it might still be able to carry on with normal IKEv2 if the initiator sent its authentication data computed the regular way, without PPKs ✨. So if using PPKs with this responder is optional for the initiator (based on the mandatory_or_not flag), the initiator MUST include a NO_PPK_AUTH notification in the message above 💌. That notification tells the responder "PPKs are optional, so you can authenticate me without one" 🫶.
NO_PPK_AUTH is a status notification with type 16437 🔢. Its protocol ID is 0 and it has no SPI. The Notification Data field holds the initiator's authentication data, computed using SK_pi', which was worked out WITHOUT PPKs 🔐. This is the same stuff that would normally go in the Authentication Data field of an AUTH payload. Since the notification doesn't have an Auth Method field, the authentication method used to compute that data MUST be the same as the method listed in the AUTH payload 🙌. Heads up though, bestie: if the initiator includes NO_PPK_AUTH, it has to do the authentication data computation TWICE 😩, which can eat up a lot of computing power (like if digital signatures are involved) 💀.
When the responder gets this encrypted exchange, it first computes these values ✨:
SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr'}
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr)Then it uses the SK_ei/SK_ai values to decrypt and check the message, and scans through the payloads for the PPK_ID attached to the PPK_IDENTITY notification 🔍. If there's no PPK_IDENTITY notification AND the peers successfully swapped USE_PPK notifications during IKE_SA_INIT, the responder MUST send back an AUTHENTICATION_FAILED notification and then fail the negotiation 🚫.
If the PPK_IDENTITY notification has a PPK_ID that the responder doesn't know, or that isn't set up for the identity from the IDi payload, then the responder checks two things: whether using PPKs for this initiator is mandatory, and whether the initiator included a NO_PPK_AUTH notification 👀. If PPKs are mandatory OR there's no NO_PPK_AUTH notification, the responder MUST send back an AUTHENTICATION_FAILED notification and then fail the negotiation 💔. Otherwise (when the PPK is optional AND the initiator included NO_PPK_AUTH), the responder MAY continue the regular IKEv2 protocol 🌸. The only twist is that it uses the data from the NO_PPK_AUTH notification as the authentication data (the stuff that usually lives in the AUTH payload) for checking the initiator 🕵️♀️. The authentication method still gets indicated in the AUTH payload, so don't forget that part 📝.
Table 1 sums up this logic for the responder 📊:
+==========+=============+============+===========+================+
| Received | Received | Configured | PPK is | Action |
| USE_PPK | NO_PPK_AUTH | with PPK | Mandatory | |
+==========+=============+============+===========+================+
| No | * | No | * | Standard IKEv2 |
| | | | | protocol |
+----------+-------------+------------+-----------+----------------+
| No | * | Yes | No | Standard IKEv2 |
| | | | | protocol |
+----------+-------------+------------+-----------+----------------+
| No | * | Yes | Yes | Abort |
| | | | | negotiation |
+----------+-------------+------------+-----------+----------------+
| Yes | No | No | * | Abort |
| | | | | negotiation |
+----------+-------------+------------+-----------+----------------+
| Yes | Yes | No | Yes | Abort |
| | | | | negotiation |
+----------+-------------+------------+-----------+----------------+
| Yes | Yes | No | No | Standard IKEv2 |
| | | | | protocol |
+----------+-------------+------------+-----------+----------------+
| Yes | * | Yes | * | Use PPK |
+----------+-------------+------------+-----------+----------------+
Table 1If a PPK is in use, the responder pulls out the matching PPK and computes these values 🧮:
SK_d = prf+ (PPK, SK_d')
SK_pi = prf+ (PPK, SK_pi')
SK_pr = prf+ (PPK, SK_pr')Next, the responder carries on with the IKE_AUTH exchange as usual (validating the AUTH payload the initiator sent) and sends back a response 💃. That response includes a PPK_IDENTITY notification with no data, which says "yep, I'm using the PPK" 🎀:
Initiator Responder
------------------------------------------------------------------
<-- HDR, SK {IDr, [CERT,]
AUTH, SAr2,
TSi, TSr, N(PPK_IDENTITY)}When the initiator gets the response, it checks for the PPK_IDENTITY notification 🕵️. If it's there, the initiator marks the SA as using the configured PPK to generate SK_d, SK_pi, and SK_pr (as shown above), and the content of the received PPK_IDENTITY (if any) MUST be ignored 🙈. If the initiator does NOT get PPK_IDENTITY, it MUST either fail the IKE SA negotiation by sending an AUTHENTICATION_FAILED notification in an INFORMATIONAL exchange (if the PPK was configured as mandatory), or keep going without the PPK (if the PPK wasn't configured as mandatory AND the initiator included NO_PPK_AUTH in the request) 🌈.
If the Extensible Authentication Protocol (EAP) is used in the IKE_AUTH exchange, the initiator doesn't include the AUTH payload in the first request message 🧐. The responder does send the AUTH payload back in the first reply, though. Then the peers swap AUTH payloads once EAP has successfully finished 🥳. So the responder sends the AUTH payload twice (in the first and last IKE_AUTH reply messages), while the initiator only sends it in the last IKE_AUTH request 📨. If you want more EAP details for IKEv2, check out Section 2.16 of [RFC7296] 📚.
The general rule for using a PPK in IKE_AUTH (EAP included!) is that the initiator puts a PPK_IDENTITY notification (and optionally a NO_PPK_AUTH notification) in the request message that carries the AUTH payload 💅. So with EAP, the responder always computes the AUTH payload in the first IKE_AUTH reply WITHOUT a PPK (using SK_pr'), because it doesn't know the PPK_ID yet 🤷♀️. Once the IKE_AUTH request with the PPK_IDENTITY notification shows up, the responder follows the rules from above for the non-EAP case 🔁:
Initiator Responder
----------------------------------------------------------------
HDR, SK {IDi, [CERTREQ,]
[IDr,] SAi2,
TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
EAP}
HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)}
HDR, SK {AUTH,
N(PPK_IDENTITY, PPK_ID)
[, N(NO_PPK_AUTH)]} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr
[, N(PPK_IDENTITY)]}Quick note: this diagram shows both situations, where the responder uses a PPK and where it skips it (as long as the initiator sent NO_PPK_AUTH). That's why the responder's PPK_IDENTITY notification is marked as optional 🫶. Also, the IKE_SA_INIT exchange with a PPK works as described above (including the USE_PPK notification swap), whether or not EAP is used in IKE_AUTH 💖.
4. Upgrade Procedure ✨
This algorithm was designed so someone can bring PPKs into an existing IKE network WITHOUT causing network disruption 🦋. Iconic, right? 👑
In the first phase of the upgrade, the network administrator visits each IKE node and configures:
- The set of PPKs (and matching PPK_IDs) that this node would need to know 🔑.
- The PPK that will be used for each peer this node would initiate to 🎀.
- The value "false" for the mandatory_or_not flag for each peer this node would initiate to (so using PPKs is NOT mandatory 🌸).
With this setup, the node keeps working with nodes that haven't been upgraded yet 🥰. That's thanks to the USE_PPK notification and the NO_PPK_AUTH notification 🪄. If the initiator hasn't been upgraded, it won't send USE_PPK (so the responder knows the peers won't use a PPK). If the responder hasn't been upgraded, it won't send USE_PPK either (so the initiator knows to skip the PPK) 🙃. If BOTH peers are upgraded but the responder isn't configured with the PPK for the initiator yet, the responder can still carry on with standard IKEv2 as long as the initiator sent NO_PPK_AUTH 🫠. And if both the responder and initiator are upgraded AND properly configured, they'll both realize it, and the Child SAs will be quantum secure 🔐⚡.
As an OPTIONAL second step, once all nodes are upgraded, the administrator should go back through the nodes and mark PPK use as mandatory 💪. This doesn't change the strength against a passive attacker 👀, but it means an active attacker with a quantum computer (fast enough to break the (EC)DH in real time) would NOT be able to pull off a downgrade attack 🚫🧠.
5. PPK
5.1. PPK_ID Format 💖
okay so this is where we pin down what a PPK_ID actually looks like 🎀 Both the initiator and the responder have to have a secret PPK value, and the responder picks the right PPK by looking at the PPK_ID the initiator sends ✨ In this standard, both sides get fixed PPK and PPK_ID values and do the lookup based on the PPK_ID value. Later specs are expected to let PPK values change dynamically, so to make that possible, the PPK_ID's very first octet is going to be the PPK_ID type value 🧚 This doc defines two types:
PPK_ID_OPAQUE(1): for this one, the format of the PPK_ID (and the PPK itself) isn't specified here. It's just assumed that the initiator and responder can both make sense of it 🤷♀️ This type is meant for implementations that don't want to reveal what kind of PPK they're using to active attackers 🙈PPK_ID_FIXED(2): here the PPK_ID and the PPK are fixed octet strings, and the remaining bytes of the PPK_ID are a configured value 💅 We assume there's a fixed mapping between PPK_ID and PPK, configured locally on both the initiator and the responder, so the responder can use the PPK_ID to look up the matching PPK value. Not every implementation can configure arbitrary octet strings, though, so for better interoperability, in thePPK_ID_FIXEDcase both the PPK and the PPK_ID strings are recommended to be limited to the base64 character set [RFC4648] 🌸
5.2. Operational Considerations 🍓
The need to maintain several independent sets of security credentials can seriously complicate a security admin's life, and it could slow down widespread adoption of this spec 😭 Admins are expected to try to make their jobs easier by keeping the number of credentials they have to manage low. This section covers some of the things to think about for PPK management 📝
5.2.1. PPK Distribution 🚚
PPK_IDs of the type PPK_ID_FIXED (and the matching PPKs) are assumed to be configured within the IKE device out-of-band 🔐 The distribution method is a local matter and is out of scope for this document and for IKEv2. That said, [RFC6030] describes a format for transporting and provisioning symmetric keys 👀 That format could be reused with the PIN profile (defined in Section 10.2 of [RFC6030]), where the "Id" attribute of the <Key> element is the PPK_ID (without the PPK_ID type octet for a PPK_ID_FIXED) and the <Secret> element contains the PPK 🎀
5.2.2. Group PPK 👯♀️
This document doesn't explicitly require that the PPK be unique for each pair of peers. If that's the case, the solution gives full peer authentication, but it also means every host needs as many independent PPKs as the peers it's going to talk to 😩 As the number of peers grows, the PPKs won't scale 📉
It's possible to use a single PPK for a whole group of users. Since each peer uses classical public key cryptography on top of a PPK for key exchange and authentication, group members can neither impersonate each other nor read each other's traffic, unless they use quantum computers to break the public key operations 🛡️ However, group members can record any traffic they can access that comes from other group members, and decrypt it later once they get access to a quantum computer 👀
Also, the fact that the PPK is known to a (potentially large) group of users makes it more susceptible to theft 🥺 When an attacker with a quantum computer gets access to a group PPK, all communications inside the group are revealed 💀
So for all these reasons, using a group PPK is NOT RECOMMENDED 🚫
5.2.3. PPK-Only Authentication 🌈
If quantum computers become a reality, classical public key cryptography will provide little security, so admins might find it appealing not to use it at all for authentication 🤔 That cuts down the number of credentials they need to maintain, since they only have to maintain PPK credentials ✨ Combining a group PPK with PPK-only authentication is NOT RECOMMENDED, because then any member of the group can impersonate any other member, even without quantum computers 😱
PPK-only authentication can be achieved in IKEv2 if the NULL Authentication method [RFC7619] is used. Without a PPK, the NULL Authentication method provides no authentication of the peers. However, since a PPK is stirred into the SK_pi and the SK_pr, the peers become authenticated if a PPK is in use 🧠 Using PPKs MUST be mandatory for the peers if they advertise support for PPKs in IKE_SA_INIT and use NULL Authentication 🔒 Also, since the peers are authenticated via PPKs, the ID Type in the IDi/IDr payloads SHOULD NOT be ID_NULL, even though they're using the NULL Authentication method 💅
6. Security Considerations 🚨
okay bestie, this part is SERIOUS 😤 A critical consideration is how to make sure this post-quantum preshared key is actually random 🎲 Quantum computers can run Grover's algorithm [GROVER], which effectively halves the size of a symmetric key. On top of that, an adversary impersonating the server, even with a conventional computer, can run a dictionary search over plausible post-quantum preshared key values 💀 The strongest practice is to make sure any post-quantum preshared key has at least 256 bits of entropy. That gives 128 bits of post-quantum security while also protecting against conventional dictionary attacks 🛡️ This is the security equivalent of Category 5 as defined in the NIST Post-Quantum Cryptography Call for Proposals [NISTPQCFP]. Deriving a post-quantum preshared key from a password, name, or other low-entropy source is not secure because of these known attacks 🙅♀️
With this protocol, the computed SK_d is a function of the PPK. Assuming the PPK has sufficient entropy (for example, at least 2^(256) possible values), then even if an attacker could recover the rest of the inputs to the PRF function, it would be infeasible to use Grover's algorithm with a quantum computer to recover the SK_d value 🔥 Similarly, all keys that are a function of SK_d are also quantum secure. That includes all Child SA keys and all keys for subsequent IKE SAs (created when the initial IKE SA is rekeyed), assuming the PPK was of high enough entropy and all the subkeys are sufficiently long ✨
An attacker with a quantum computer who can decrypt the initial IKE SA has access to all the information exchanged over it, such as the identities of the peers, configuration parameters, and all negotiated IPsec SA information (including traffic selectors). The one exception is the cryptographic keys used by the IPsec SAs, which are protected by the PPK 🔐
Deployments that treat this information as sensitive, or that send other sensitive data (like cryptographic keys) over IKE SAs, MUST rekey the IKE SA before the sensitive information is sent, so that it's protected by the PPK 🫶 It's possible to create a childless IKE SA as specified in [RFC6023]. This stops Child SA configuration information from being sent over the original IKE SA, which isn't protected by a PPK 🙌 Some information related to the IKE SA that's sent in the IKE_AUTH exchange, such as peer identities, feature notifications, vendor IDs, and so on, can't be hidden from the attack described above, even if the additional IKE SA rekey is performed 😬
Also, the policy SHOULD be set to negotiate only quantum-secure symmetric algorithms. This RFC doesn't claim to give advice on which algorithms are secure, since that may change with future cryptographic results. Still, here's a list of defined IKEv2 and IPsec algorithms that should not be used, because they're known to provide less than 128 bits of post-quantum security 💅
- Any IKEv2 encryption algorithm, PRF, or integrity algorithm with a key size less than 256 bits.
- Any ESP transform with a key size less than 256 bits.
PRF_AES128_XCBCandPRF_AES128_CBC: even though they can take an input key of arbitrary size, such input keys are converted into a 128-bit key for internal use 🥲
Section 3 requires the initiator to abort the initial exchange if using PPKs is mandatory for it but the responder doesn't include the USE_PPK notification in the response. In this situation, when the initiator aborts, it leaves a half-open IKE SA on the responder (because IKE_SA_INIT completes successfully from the responder's point of view) 😵 This half-open SA will eventually expire and be deleted. But if the initiator keeps trying to create IKE SAs at a high enough rate, the responder may see it as a denial-of-service (DoS) attack and take protective measures (see [RFC8019] for more details) 🚨 So in this situation, it is RECOMMENDED that the initiator cache the negative result of the negotiation and not try to create the SA again for some time. The exact period may vary, but it's believed that waiting at least a few minutes won't make the responder treat it as a DoS attack ⏳ Note that this situation would most likely come from a misconfiguration, so some reconfiguration of the peers would probably be needed 🛠️
If using PPKs is optional for both peers and they authenticate themselves using digital signatures, then an attacker in between, equipped with a quantum computer that can break public key operations in real time, can mount a downgrade attack. It does this by removing the USE_PPK notification from IKE_SA_INIT and forging digital signatures in the subsequent exchange 👻 If using PPKs is mandatory for at least one of the peers, or if a preshared key mode is used for authentication, then the attack will be detected and the SA won't be created 🙌
If using PPKs is mandatory for the initiator, then an attacker who can eavesdrop on and inject packets into the network can prevent the creation of an IKE SA by mounting the following attack 😈 The attacker intercepts the initial request containing the USE_PPK notification and injects a forged response containing no USE_PPK. If the attacker manages to inject this packet before the responder sends a genuine response, the initiator would abort the exchange. To thwart this kind of attack, it is RECOMMENDED that, if using PPKs is mandatory for the initiator and the received response doesn't contain the USE_PPK notification, the initiator does not abort the exchange immediately. Instead, it waits for more response messages, retransmitting the request as if no responses had been received at all, until either a received message contains the USE_PPK notification or the exchange times out (see Section 2.4 of [RFC7296] for more details about retransmission timers in IKEv2). If none of the received responses contains USE_PPK, then the exchange is aborted 🧐
If using a PPK is optional for both peers, then in case of misconfiguration (e.g., a mismatched PPK_ID), the IKE SA will be created without protection against quantum computers 😭 It's advised that if a PPK was configured but wasn't used for a particular IKE SA, then implementations SHOULD audit this event 📋
7. IANA Considerations ✨
okay so this section is the IANA paperwork bit, and it's giving registry energy 💅 This document defines three brand-new Notify Message Types in the "IKEv2 Notify Message Types - Status Types" subregistry under the "Internet Key Exchange Version 2 (IKEv2) Parameters" registry [IANA-IKEV2]:
+=======+================================+===========+
| Value | NOTIFY MESSAGES - STATUS TYPES | Reference |
+=======+================================+===========+
| 16435 | USE_PPK | RFC 8784 |
+-------+--------------------------------+-----------+
| 16436 | PPK_IDENTITY | RFC 8784 |
+-------+--------------------------------+-----------+
| 16437 | NO_PPK_AUTH | RFC 8784 |
+-------+--------------------------------+-----------+
Table 2Per this document, IANA has created a brand-new subregistry called "IKEv2 Post-quantum Preshared Key ID Types" under that same IKEv2 Parameters registry [IANA-IKEV2] 🦋 It's specifically for the PPK_ID types used in the PPK_IDENTITY notification defined here. The starting contents look like this:
+=========+==========================+===========+
| Value | PPK_ID Type | Reference |
+=========+==========================+===========+
| 0 | Reserved | RFC 8784 |
+---------+--------------------------+-----------+
| 1 | PPK_ID_OPAQUE | RFC 8784 |
+---------+--------------------------+-----------+
| 2 | PPK_ID_FIXED | RFC 8784 |
+---------+--------------------------+-----------+
| 3-127 | Unassigned | RFC 8784 |
+---------+--------------------------+-----------+
| 128-255 | Reserved for Private Use | RFC 8784 |
+---------+--------------------------+-----------+
Table 3So the rules are: PPK_ID type value 0 is reserved 🙅♀️, values 3-127 get assigned by IANA 🌸, and values 128-255 are for private use among mutually consenting parties 🫶 To register a new PPK_ID in the Unassigned range, you need a type name, a value between 3 and 127, and a reference specification. Changes and additions to the Unassigned range are made using the Expert Review policy [RFC8126]. Changes and additions to the Reserved for Private Use range are made using the Private Use policy [RFC8126] ✨
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.8.2. Informative References
[C2PQ] Hoffman, P., "The Transition from Classical to Post-
Quantum Cryptography", Work in Progress, Internet-Draft,
draft-hoffman-c2pq-07, 26 May 2020,
<https://tools.ietf.org/html/draft-hoffman-c2pq-07>.
[GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for
Database Search", STOC '96: Proceedings of the Twenty-
Eighth Annual ACM Symposium on the Theory of Computing,
pp. 212-219", DOI 10.1145/237814.237866, July 1996,
<https://doi.org/10.1145/237814.237866>.
[IANA-IKEV2]
IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters",
<https://www.iana.org/assignments/ikev2-parameters/>.
[NISTPQCFP]
NIST, "Submission Requirements and Evaluation Criteria for
the Post-Quantum Cryptography Standardization Process",
December 2016, <https://csrc.nist.gov/CSRC/media/Projects/
Post-Quantum-Cryptography/documents/call-for-proposals-
final-dec-2016.pdf>.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<https://www.rfc-editor.org/info/rfc2409>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A
Childless Initiation of the Internet Key Exchange Version
2 (IKEv2) Security Association (SA)", RFC 6023,
DOI 10.17487/RFC6023, October 2010,
<https://www.rfc-editor.org/info/rfc6023>.
[RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
Key Container (PSKC)", RFC 6030, DOI 10.17487/RFC6030,
October 2010, <https://www.rfc-editor.org/info/rfc6030>.
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
Method in the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
<https://www.rfc-editor.org/info/rfc7619>.
[RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
Protocol Version 2 (IKEv2) Implementations from
Distributed Denial-of-Service Attacks", RFC 8019,
DOI 10.17487/RFC8019, November 2016,
<https://www.rfc-editor.org/info/rfc8019>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.Appendix A. Discussion and Rationale 🧠
The main goal here is to beef up IKEv2 so it's protected against quantum computers without needing brand-new crypto algorithms 💜 The vibe is: a quantum computer can easily reconstruct the shared secret of an (EC)DH exchange, but it can't as easily recover a secret from a symmetric exchange. So this document makes SK_d (and therefore also the IPsec KEYMAT and any later IKE SA's SKEYSEED) depend on both the symmetric PPK and the Diffie-Hellman exchange. Say the attacker knows everything except the PPK during the exchange, and there are 2^(n) plausible PPKs. Then a quantum computer using Grover's algorithm would need O(2^(n/2)) time to find the PPK. So even if the (EC)DH gets trivially solved, the attacker still can't recover any key material (except for the SK_ei, SK_er, SK_ai, and SK_ar values for the initial IKE exchange) unless they find the PPK, and that's too hard if the PPK has enough entropy (for example, 256 bits) 🔐 Note that we do allow an attacker with a quantum computer to rederive the keying material for the initial IKE SA. That was a compromise so the responder could pick the correct PPK quickly ⚡
Another goal is to keep changes to IKEv2 minimal, especially inside its cryptography. By limiting our changes to notifications and only adjusting SK_d, SK_pi, and SK_pr, the hope is that this is implementable even on systems that do most of their IKEv2 processing in hardware 🛠️
A third goal is to be friendly to incremental rollout in real networks, where you might not want one global shared key, or where quantum-secure IKEv2 gets deployed bit by bit. That's why the PPK can depend on the peer, and why it can be configured as optional 🌈
A fourth goal is to not violate any of the security properties IKEv2 already gives you 💖
Acknowledgements 🫶
We would like to thank Tero Kivinen, Paul Wouters, Graham Bartlett, Tommy Pauly, Quynh Dang, and the rest of the IPSECME Working Group for their feedback and suggestions for the scheme. Huge thanks to all of them, bestie ✨
Authors' Addresses 💌
Scott Fluhrer
Cisco Systems
Email: sfluhrer@cisco.com
Panos Kampanakis
Cisco Systems
Email: pkampana@cisco.com
David McGrew
Cisco Systems
Email: mcgrew@cisco.com
Valery Smyslov
ELVIS-PLUS
Phone: +7 495 276 0211
Email: svan@elvis.ruThat's a wrap on RFC 8784! 🌈 Post-quantum IKEv2 with a PPK, all the way through. Slay. 👑
📦 where this page comes from
- ietf: rfc8784 2020-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms