Post Quantum IKE VPN Support
Table of Contents
Post Quantum IKE VPN Support
RFC 8784 support provides post quantum resistance for quantum attacks on IKE
VPNs.
Post-quantum VPNs resist attacks based on quantum computing and post-quantum
cryptography (PQC). Palo Alto Networks post-quantum VPN support enables you to
configure quantum-resistant IKEv2 VPNs and is based on the RFC 8784 standard to maximize interoperability with
other vendors' equipment and with future standards. Multiple government agencies
around the world, including the NSA and NIAP, recommend implementing RFC 8784 to
improve quantum resistance. Implementing RFC 8784 is the simplest way to create
quantum-resistant VPNs because you don't need to upgrade crypto elements.
Addressing the quantum threat immediately is critical to defend against Harvest Now, Decrypt Later attacks that target
long-lived data because the development of cryptographically relevant quantum
computers (CRQCs) will vastly reduce the amount of time required to break classical
encryption.
Configuring quantum-resistant VPNs can prevent attackers from recording critical
encrypted key material and thus prevent them from decrypting the data even if they
steal it. If you have long-lived data, start planning now for the threat posed by
quantum computers and quantum cryptography and for your network's transition to a
post-quantum world. The first step is to make your VPN connections
quantum-resistant.
RFC 8784 provides a transition from today's classical cryptography to PQC.
Quantum-resistant VPNs based on RFC 8784 enable using post-quantum pre-shared keys
(PPKs) that are not transmitted with the data, so harvesting attacks fail because
they don't capture the key material that they need to decrypt the data later. A PPK
is a complex, strong hexadecimal string that you statically program into the IKE
peers at the ends of the VPN tunnel.
Adding a static PPK that's delivered out-of-band to the classical Diffie-Hellman (DH)
key prevents Shor's algorithm from cracking the key
because the key is no longer based on prime numbers. RFC 8784 enables using long,
strong PPKs that meet the NIST Category 5 security level.
In addition, RFC 8784 provides the backward compatibility to fall back to classical
cryptography if a peer can't support FRC 8784, so the implementation doesn't risk
refusing legitimate connections. Palo Alto Networks implementation of RFC 8784
provides flexibility and quantum resistance for your IKEv2 VPNs:
- You can add up to ten post-quantum (PQ) PPKs to each IKEv2 VPN. Each PQ PPK is associated with a PPK KeyID, which uniquely identifies the PPK, so you can configure up to ten PPK + KeyID pairs. You can configure PPKs yourself or use a built-in tool to generate strong PPK strings. Configuring multiple active PPKs enables the firewall that initiates the IKEv2 peering to randomly select one of the active PPKs to use with the peer.
- You can configure PPK strings from 16-64 bytes (32-128 characters) in length. For best security, use PPK strings that are at least 32 bytes (64 characters) in length.
- You can set theNegotiation Modeto control the ciphers used to establish the connection:
- Mandatory—Require that the responding peer use RFC 8784 and abort the connection if it only uses classical cryptography.
- Preferred—Allow the initiating device to fall back to classical cryptography if the peer doesn't support RFC 8784.
- You can activate and deactivate individual PQ PPKs, so if a PQ PPK is lost or exposed, you can disable it and remove it from the negotiation pool.
In addition to implementing RFC 8784 now:
- Migrate to tougher cipher suites. Follow RFC 6379 for Suite B Cryptographic Suites for IPsec, upgrade ciphers to Suite-B GCM-256, and avoid using weaker AES-128-bit algorithms.
- Upgrade to larger hash sizes such as SHA-384 or SHA-512. Don't use MD5 or SHA-1.
- Upgrade your CA to larger RSA key sizes. Use 4096-bit RSA key sizes and migrate VPN certificate authentication to new certificates.
The following example topology shows three VPN termination sites. Sites A and C
support post-quantum VPNs based on RFC 8784. Site B supports only classical VPNs.
Site A must be able to communicate with both Site B and Site C.
Site A uses both Mandatory and Preferred negotiation modes. When Site A communicates
with Site B, which only supports classical cryptography, Site A falls back to
classical negotiation. When Site A communicates with Site C, Site A uses a PQ PPK
because Site C supports using PQ PPKs.