Palo Alto Networks Extends Support for Quantum Safe VPN with RFC 9242, RFC 9370 Standards, and Hybrid KEYs

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
L2 Linker

Title_Quantum-Safe-VPN_palo-alto-networks.jpg

 

Introduction 


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

 

Fig 1_Quantum-Safe-VPN_palo-alto-networks.png

 


















 

 

 

 

 

 

 

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.

 

How is Palo Alto Networks Implementing It

 

The PAN-OS next-generation firewall (NGFW) provides support for the two RFC standards in its PQ VPN Hybrid Key feature as follows:

 

  1. Adds an option to enable/disable multi-key exchange within the IKEv2 protocol.
  2. The current behavior will be to drop the IKEv2 peering if the other side cannot support RFC standards.
  3. It allows the block of the PQ key exchange if a vulnerable cipher is detected in the IKEv2 peering process.
  4. This allows you to configure an additional seven key exchange rounds using PQ KEMs after the initial IKEv2 key exchange.
  5. The initial IKEv2 key exchange can also support a PQ KEM and does not have to use the classic DH key exchange.
  6. Provides support for an additional seven key exchange rounds in the IPSec crypto profile to support PQ IPSec rekey exchange.
  7. It can be used in combination with PQ VPN RFC 8784 PPKs to create a defense-in-depth architecture.

 

Configuration Overview

 

Enabling IKEv2 with Multi-Key Exchange

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.

 

Fig 2_Quantum-Safe-VPN_palo-alto-networks.png

 

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.

 

Lightbulb_Quantum-Safe-VPN_palo-alto-networks.png

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. 

 

 

 


Configuring PQ KEMs for Key Exchange

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.

 

IKE Crypto Profile

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.

  1. General Tab: As part of the IKEv2 key exchange, you must specify at least ONE KEM.  With Classic IKEv2, this would be the DH Group, as shown below.  

Fig 3_Quantum-Safe-VPN_palo-alto-networks.png

 

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.

 

Lightbulb_Quantum-Safe-VPN_palo-alto-networks.png 

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.

Fig 4_Quantum-Safe-VPN_palo-alto-networks.png

 

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. 

 

Fig 5_Quantum-Safe-VPN_palo-alto-networks.png

 

Lightbulb_Quantum-Safe-VPN_palo-alto-networks.pngBest Practice Tip   The ordering of the additional key exchanges does not matter. Per RFC 9370, as the strength of the running shared secret increases with each additional key exchange round, you may want to perform the most secure method first, followed by less secure methods.

 

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.

 

 

 

IPSec Crypto Profile

 

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.

 

Fig 7_Quantum-Safe-VPN_palo-alto-networks.png

 

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.

 

Lightbulb_Quantum-Safe-VPN_palo-alto-networks.pngBest Practice Tip   If you need help with the PAN-OS CLI commands to verify the IKEv2 KEM negotiation or perform troubleshooting, please refer to the CLI Commands for Troubleshooting and CLI Screenshots section towards the end of this document.

 

 

 

How Do We Provide Crypto-Agility Support?

 

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. 

 

  • ML-KEM (Kyber512, Kyber768, Kyber1024)
  • BIKE (L1, L3, L5)
  • Classic McEliece (348864, 348864f)
  • HQC (128, 192, 256)
  • FrodoKEM (640-AES, 640-SHAKE, 976-AES, 976-SHAKE, 1344-AES, 1344-SHAKE)
  • NTRU-Prime (sntrup761)

 

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.  

 

Troubleshooting and CLI Screenshots 

 

The following CLI commands can be used to help validate the IKEv2 key negotiation between the VPN endpoints.

 

debug ike global on dump

  • Allows you to obtain granular information on the IKEv2 exchange

 

 debug ike stat

  • Displays detailed IKE statistics

 

show vpn ike-sa gateway 

  • Displays IKE gateway configuration information

 

 test vpn ike-sa gateway

  • Triggers and IKE Phase 1 peering 

 

show vpn ipsec-sa 

  • Displayed IPSec configuration information

 

test vpn ipsec-sa 

  • Triggers IPSec Phase 2 tunnel

 

tail follow yes mp-log ikemgr.log 

  • Displays real-time dump of ikemgr.log for IKE key negotiation and IPSec activity

 

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. 

 

Fig 8_Quantum-Safe-VPN_palo-alto-networks.png

 

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. 

 

Fig 9_Quantum-Safe-VPN_palo-alto-networks.png

 

Other VPN References

 

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

 

  • 6156 Views
  • 0 comments
  • 0 Likes
Register or Sign-in
Labels