In the previous blog on Palo Alto Networks’ post-quantum VPN solution feature introduced in PAN-OS 11.1, we reviewed how RFC 8784 standard-based quantum VPN tunnel helps protect against harvest now decrypt later (HNDL) type Quantum attacks for an organization’s site-to-site VPN tunnel. This first PQ VPN component based on RFC 8784 allows our customers to deploy a Quantum-Safe VPN solution quickly without needing more advanced PQ KEMs.
This blog will review the second PQ VPN component based on two additional standards - RFC 9242 Intermediate Key Exchange and RFC 9370 IETF Multi-key Implementation in IKEv2. With these technologies, customers can create crypto profiles to allow the firewall and its peer to negotiate up to 8 (1 IKEv2 default/classic KEM and an additional 7 PQ KEMs) rounds of key exchange to produce a hybrid key.
The essence of RFC 9242 is that it enhances VPN setup using IKEv2 to allow large-sized PQ keys. RFC 9370 allows multiple rounds of key exchanges that can use classic and PQ algorithms together.
Let’s take an example for IKE profile below
Default KEM Round: Diffie Hellman Group 21
Additional Key Exchange Round 1: ML-KEM (Crystals-Kyber)
Additional Key Exchange Round 2: BIKE-L1
Additional Key Exchange Round 3: HQC
In this example, we use classic DH Group 21 to ensure the key is resistant to any of today's (pre-QC) attacks. The hybrid key is created by adding three additional KEM rounds with ML-KEM (Crystals-Kyber), BIKE-L1, and HQC, one after the other. The result is a key based on three PQ KEM and DH technologies.
For a quantum attack to succeed, all KEMs used in the hybrid key exchange would need to fall to a vulnerability. Using at least 3 KEM methods would ensure a relatively robust hybrid key that can be used for symmetric encryption with AES-256. Customers can select which PQ KEMs are used and quickly switch out weak or vulnerable KEMs with crypto-agility capabilities.
Customers can also deploy a “quantum defense-in-depth” approach by using both RFC 8784 pre-shared private keys (PPKs) and hybrid keys produced with RFC 9242 and RFC 9370 by enabling both technologies. The NSA, NIAP, BSI (Germany), and other government organizations around the world have approved and recommended using an RFC standard-based layered approach in which both PQ VPN methods are used to provide additional quantum resistance during the transition to a post-quantum world.
The PAN-OS next-generation firewall (NGFW) provides support for the two RFC standards in its PQ VPN Hybrid Key feature as follows:
To enable the new PQ VPN Hybrid Key feature, reference the configuration screens below to configure each PQ KEM component. The new PQ VPN capabilities are introduced in the IKEv2 Gateway’s Advanced Options/PQ KEM, IKE Crypto Profile’s Advanced Options, and IPSec Crypto Profile’s Advanced Options.
IKE Gateway Configuration
In the IKEv2 Gateway’s Advanced Options, select the PQ KEM tab as shown in the illustration below.
Enable Post-Quantum Key Exchange: To enable or disable PQ KEM’s hybrid key functionality, check or uncheck the box. By default, PQ KEM is disabled.
Block IKEv2 if Vulnerable Cipher is Used: If enabled (checked), the NGFW performs a lookup in its vulnerable cipher list and blocks vulnerable ciphers from being used in any new IKEv2 negotiations. The blocked cipher is logged to allow administrators to see the reason why an IKEv2 peering failed. Existing IKEv2 peerings are allowed to continue operating to prevent disruptions to the network, and event messages are logged to inform the administrator of the compromised PQCs being used.
Best Practice Tip If a vulnerable cipher is allowed, the resulting key may be broken by a QC in the future with a harvesting attack. The best practice is to replace all vulnerable ciphers as soon as possible and to not use the affected cipher in any new IKEv2 peerings. You can replace the vulnerable cipher by unselecting it and substituting it with a good cipher from the crypto list in each of the negotiation rounds.
PAN-OS added support for the new PQ KEMs in the IKE and IPSec crypto profiles and the configuration workflow is consistent with how the classic crypto profiles work to ensure a smooth transition.
The IKE Crypto Profile allows you to configure the KEMs used in the IKEv2 peering process. There are two locations to select which KEM to use.
With the addition of hybrid key support, you can also select a supported PQ KEM as the first IKEv2 KEM in the DH GROUP selection list and omit the classic exchange. If you decide to only use PQ KEMs in the first (default) key exchange, IKEv2 creates a hybrid key without any classic DH key exchanges, allowing you to move to a pure PQ KEM IKEv2 peering environment.
You can also elect not to use any additional KEM rounds after the default IKEv2 key exchange, which allows you to perform a 1:1 substitution of the classic DH KEM for a PQ KEM. For example, you can migrate from classic Diffie-Hellman to Crystals-Kyber directly without using a hybrid key as a transition strategy.
Best Practice Tip As the world transitions from classic KEMs to PQ KEMs, there will be a period where the new PQ KEMs are validated through mass adoption and other industry vetting processes, and it can take many years before a new KEM gains wide acceptance and high confidence. It is safer to use a combination of a classic DH KEM and one or more PQ KEMs to ensure adequate quantum resistance.
2. Advanced Options: Allows optional KEMs to be added to the IKEv2 key exchange to generate a PQ hybrid VPN key. You can specify up to an additional seven KEMs (Round 1 through Round 7) to use and these can be either classic or PQ KEMs as shown below. Use the Add function to display the list of supported KEMs and select the KEM to use for that round.
In our example, Round 1 tries to negotiate one of the ML-KEM (Kyber-768) with the responder to create a hybrid key. If the responder can also support one of the Crystals-Kyber ciphers, the resulting key is created using DH Group 19 and Crystals-Kyber.
If you want to add a third KEM, select additional supported PQ KEMs for Round 2. If the responder cannot support the selected PQ KEMs, the proposed KEM will not be used as part of the hybrid key generation.
In the example below, the HQC PQC KEM was selected for Round 2. An additional BIKE PQC KEM is used in Round 3.
If there is MORE THAN ONE PQC listed in the AKE round, the negotiation and selection priority is performed in TOP DOWN order. The PQC placed at the top of the list is the most preferred, and the one at the bottom of the list is the least preferred. Best practice is to place the most secure PQC at the top if higher security is desired over higher performance.
The IPSec crypto profile includes a new Advanced Options tab to allow you to enable PQ KEM and hybrid key capabilities for the IPSec key refresh.
Round (1 - 7): The process of selecting additional KEMs is similar to how you selected the KEMs to use for the additional key exchange rounds in the IKE Crypto Profile, you can use the drop-down boxes for each additional round in the IPSec Crypto Profile to select the desired KEM to use.
During the transition to post-quantum cryptography, which could take many years, hybrid key technologies help ease the transition and protect against future PQC vulnerabilities. To protect against Harvest Now Decrypt Later attacks, the following NIST Round 4 PQC candidates are supported.
If a PQC on the supported list is compromised in the future, you can replace the affected PQC with a non-vulnerable PQC from the supported list. Unfortunately, any harvested information secured with the vulnerable PQC is forfeited as the bad actor can decrypt the payload with a CRQC later.
The following CLI commands can be used to help validate the IKEv2 key negotiation between the VPN endpoints.
debug ike global on dump
debug ike stat
show vpn ike-sa gateway
test vpn ike-sa gateway
show vpn ipsec-sa
test vpn ipsec-sa
tail follow yes mp-log ikemgr.log
You can also validate the key exchange algorithm used by the two participating peers through the UI and CLI commands. The examples below show a site-to-site Post Quantum Safe VPN tunnel between Palo Alto Networks FW1 and FW2.
Below is a CLI confirmation of the Handshake the two participating peers negotiated. You can see, in addition to the classical ciphers (DH21/AES256/SHA512), PQ PPK (RFC874 standard) as well as three rounds of hybrid KEMs are used (Round 1 - Kyber-768, Round 2 - HQC-192, Round 3 - Bike-L3). The status of the connection is Established and the role of this FW2 is Initiator.
PAN-OS Administrator’s Guide to test VPN connectivity
Troubleshooting PAN-OS VPN Connectivity Issues
Getting Started with PAN-OS VPN
With Palo Alto Networks’ Quantum Safe VPN solution, customers can confidently roll out new PQ technology without fear of breaking existing classic connections (automatic fallback to classic IKEv2 with RFC8784) as soon as they’re ready. With quick adoption, they can reduce the exposure and risk of Harvest Now Decrypt Later attacks.
To learn more about the cybersecurity impact of quantum computers and how your organization can begin your Quantum Readiness journey now, check out our new CISO’s Guide to Quantum Security video series. Or follow our Quantum Readiness Blog, Quantum documentation, and how Palo Alto Networks is helping customers in their Quantum Secure journey.
