How RFC 9242 and RFC 9370 Resist Quantum Computing Threats
Focus
Focus
Network Security

How RFC 9242 and RFC 9370 Resist Quantum Computing Threats

Table of Contents

How RFC 9242 and RFC 9370 Resist Quantum Computing Threats

IKEv2 VPNs based on RFC 9242 and RFC 9370 resist quantum attacks today by safeguarding key exchange material.
Where Can I Use This?
What Do I Need?
  • PAN-OS
  • PAN-OS 11.2 or later.
The RFC 9242 standard,
Intermediate Key Exchange in the Internet Key Exchange Protocol 2 (IKEv2)
, enables IKEv2 to transfer large amounts of data in the IKEv2 Security Association (SA) establishment to support multiple PQC key exchanges with larger key sizes. The RFC 9370 standard,
Multiple Key Exchanges in the Internet Key Exchange Protocol 2 (IKEv2)
, allows multiple key exchanges to take place while computing a shared secret during the SA setup.
Together, these two RFC standards give IKEv2 the ability to create hybrid keys using both classic and PQC key exchange mechanisms (KEMs) to mitigate a quantum attack using Shor’s algorithm. The new PQCs are based on different mathematical technology that are not vulnerable to known classical or quantum attacks, and these include:
  • Lattice
  • Code-based
  • Hash-based
  • Symmetric Key
  • Isogeny-based
  • Multi-variate
The RFC 9370 standard allows an additional seven key exchange rounds, and these can be classic or PQC KEMs, such as ML-KEM, BIKE, HQC, Classic McEliese, and others, in addition to the IKEv2 default key exchange for a total of eight rounds.
To break the hybrid key, all KEM technologies used to create the encryption key must fall to a vulnerability and be compromised. For example, to create a hybrid key that is resistant to both today’s known vulnerabilities and future quantum computer (QC) threats, best practice recommends using both classic and one or more PQC KEMs that use different mathematical technologies.
  • Default KEM Round: Diffie-Hellman (DH) Group 21
  • Additional Key Exchange Round 1: ML-KEM-768 (CRYSTALS-Kyber-786)
  • Additional Key Exchange Round 2: BIKE-L3
In the previous example, classic DH Group 21 provides protection for today's prequantum attacks. Adding two additional PQC KEM rounds with ML-KEM-768 (lattice) and BIKE-L3 (code-based), one after the other, creates an encryption key based on three KEM technologies and provides protection for future attacks using Shor’s algorithm. Adding at least two PQCs to the DH key exchange provides a higher protection level against a single KEM failure and can help resist quantum attacks for a longer duration. In addition, using KEMs based on different types of mathematics can protect against future vulnerabilities against a specific type of PQC, such as all PQCs based on lattice technology.
The transition to the post-quantum world where PQCs are the only key exchange mechanism will take many years as the industry needs time to validate the new PQCs and gain confidence in their security abilities. During the transition period, hybrid keys based on RFC 9242 and RFC 9370 will be standard.
The standards process to approve new PQCs will come in phases, with NIST approving groups of PQCs for each approval round. As each PQC has performance and security tradeoffs, gaining an understanding of how each PQC performs is needed to determine which technology is best suited for the different security use cases. For example, Classic McEliece has proven itself as a very secure PQC over time, but the tradeoff for its high security is the large keys sizes it uses, which can limit Classic McEliece use in VPN and TLS communications.
World governments are recommending a security level of L3 or above to provide strong security and resistance to future quantum computer attacks.
During the transition period from classic encryption to post-quantum encryption, cryptographic agility will be required to allow rapid replacement of any compromised PQCs. Palo Alto Networks RFC 9242 and RFC 9370 post-quantum KEM solution provides a broad set of PQCs to achieve cryptographic agility from the beginning, allowing customers to select and remove any supported PQC from the IKEv2 key negotiation quickly without any software updates or changes to the existing network.
The following PQCs are supported for PAN-OS IKEv2:
  • ML-KEM (Kyber) 512, 768, 1024
  • BIKE L1, L3, L5
  • FrodoKEM 640-aes, 640-shake, 976-aes, 976-shake, 1344-aes, 1344-shake
  • HQC 128, 192, 256
  • NTRU-Prime sntrup761
  • Classic McEliece 348864, 348864f
The benefits of RFC 9242 and RFC 9370 include:
  • Approved standards with multivendor support.
  • High scalability with dynamic key exchange instead of RFC 8784’s static PPKs.
  • Support for a broad range of PQC KEMs.
  • IKEv2 backward compatibility allows fallback if the peer can’t support the RFCs.
  • Hybrid keys are more resistant to Shor’s algorithm as different PQC technologies can be used together.
  • Can be layered with RFC 8784 for quantum defense-in-depth and cryptographic agility.
The disadvantages of RFC 9242 and RFC 9370 include:
  • Early PQC standardized lists might not provide enough PQCs to achieve cryptographic agility at the beginning of the PQ transition.
  • New PQC might need many years to be fully vetted and trusted by industry.
  • Multiple KEMs can add additional overhead and slow the IKEv2 peering process.
  • New PQC KEMs can cause fragmentation as key sizes and data payloads are larger.
  • Not every device can be upgraded to support PQC KEMs.
  • Risk of Denial of Service (DoS) attacks can increase with the extended key exchange during the IKE_INTERMEDIATE due to the increased resources needed before the initiator is authenticated.
  • Hybrid keys are designed to protect against harvesting attacks where the encrypted information is saved and decrypted with a cryptographically relevant quantum computer (CRQC) at a later date. Attacks using a quantum computer in an active attack are not completely solved with hybrid keys for the following reasons:
    • Authentication is still performed using classical methods, either pre-shared key or digital signature algorithms. Pre-shared keys must be long and complex to be post-quantum secure, but they’re not scalable. Authentication with digital signatures must be performed with a post-quantum digital signature.
    • PQCs are designed to provide resistance to harvesting attacks and until CRQCs become available, attacking the authenticity of a connection does not matter because there are no possibilities for exploitation as these only occur at the time of connection.
It's recommended that you use RFC 9242 and RFC 9370 based IKEv2 VPNs to secure VPN connections against post-quantum threats by using hybrid keys based on multiple KEM technologies. With a broad set of PQCs, cryptographic agility can be achieved to safeguard against compromised PQCs during the transition to a post-quantum world.

Recommended For You