Cryptographically relevant quantum computers (CRQCs) threaten traditional cryptographic systems by dramatically reducing the time needed to break encryption algorithms. VPN communications secured by IKEv2 are vulnerable to the threats posed by CRQCs because IKEv2 uses Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) for key exchange. Delays in implementing post-quantum cryptography (PQC) increase the risk of Harvest Now, Decrypt Later attacks. In these attacks, adversaries capture and store encrypted data today for future decryption when CRQCs become available. If you handle sensitive data requiring long-term storage, you are especially susceptible.

To future-proof VPN communications against this emerging threat, PAN-OS® 11.1 implements quantum-resistant IKEv2 VPNs based on RFC 8784. RFC 8784 specifies the mixing of post-quantum pre-shared keys (PQ PPKs) with DH keys to create quantum-resistant connections. The implementation involves a PQ PPK and a public key ID associated with the secret. You must share the secret with both VPN peers out-of-band. After the peers perform a standard DH key exchange, one peer sends the key ID to the other in-band. Both peers use that key ID to identify the PQ PPK to mix with the DH key material. This method creates a new, quantum-resistant key that provides multiple layers of protection. CRQCs can't compromise the resulting key because it isn't based on prime number factorization that Shor's algorithm exploits. Harvesting attacks fail because the PPK itself never leaves your IKEv2 peers; adversaries can't capture the key material required for future decryption, even if they compromise the DH key.

Palo Alto Networks implementation of RFC 8784 ensures a seamless transition to PQC. The standard doesn't require cryptography upgrades, so you can introduce PPKs into existing IPsec VPN deployments without network disruption. It also supports falling back to classical cryptography if a peer doesn't support RFC 8784. Further, the standard is interoperable with multiple vendors and works with other standards such as RFC 9370.

The following example topology shows three VPN termination sites. Sites A and C support post-quantum VPNs based on RFC 8784, while Site B supports classical VPNs only. Site A must be able to communicate with both Site B and Site C. When communicating with Site B, Site A can either fall back to classical negotiation or abort the connection, depending on your configured preference. When communicating with Site C, Site A uses a PQ PPK because Site C supports this.