Quantum Security Made Easy with RFC 8784 Standard

[ashah1]

The RFC 8784 standard, Mixing Preshared Keys in Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security, enables you to create IKEv2 VPNs that are resistant to attacks based on quantum computers (QCs) and post-quantum cryptographies (PQCs) today.

The essence of RFC 8784 is exchanging static post-quantum pre-shared keys (PQ PPKs) out-of-band, separately from the IKE key exchange, and mixing the out-of-band PQ PPK material with the classical Diffie-Hellman (DH) key material that is transmitted in band during the IKEv2 key exchange. This enhances the key exchange in two ways:

1. The mixed key is no longer based on prime numbers (a DH key by itself is based on prime numbers and is vulnerable to QCs using Shor's algorithm). This makes the key resistant to quantum computers (QCs) that use Shor's algorithm to attempt to factor the key, identify the prime numbers on which the key is based, crack the key, and then decrypt the data.
2. A listener, or man-in-the-middle, can't harvest all of the key material to decrypt later. The classical DH portion of the key is sent in the IKE peering key exchange, but the PQ PPK that the IKE peers mix with the DH key material is never transmitted during the key exchange or in the VPN after it's been established, so even with the DH portion of the key material, attackers can't decrypt the data that traverses the VPN.

In RFC8784 implementation, the mixing of post-quantum pre-shared keys is performed after IKEv2 DH key exchange. The IKEv2 peers know which PQ PPK to use based on a Key ID. Each PQ PPK consists of two elements, a KeyID and a pre-shared secret. The pre-shared secret is the key material that you share with the IKEv2 peer out-of-band. It is never transmitted inband with the DH key material or with the data after establishing the VPN. Instead, the administrator of one IKEv2 peer manually creates the static pre-shared secret and communicates it securely, for example by secure email or by pushing from Panorama to the Next Gen Firewall of the other IKEv2 peer. Each administrator programs the pre-shared secret into their IKE Gateway peer, so the secret is never revealed in the IKE connection.

The Key ID, which is transmitted in-band during the key exchange, identifies the pre-shared secret on the IKEv2 peer. The IKEv2 peer uses the Key ID to look up the pre-shared secret and mixes it with the DH key material to create new key material that isn't based on prime numbers and can't be stolen by eavesdropping on the communication.

Now let’s look into the configuration option that is available in PAN-OS 11.1. All the configuration is done in the Network Profile and IKE Gateways Advanced options: Under the new PQ PPK tab. 

It is important to note that PQ PPK is supported for IKEv2 only - i.e., the version needs to be set to either IKEv2 only mode or IKEv2 preferred mode on IKE Gateway > General.

Here, the preferred mode implies and allows us to fall back to “regular” IKEv2 (no PQ PPK) if the peer device does not support PQ PPK. PAN-OS lets us specify up to 10 PQ PPKs at any given time. PAN-OS randomly selects one of the active keys for each IKE negotiation. Admin can deactivate a particular key (checkbox) at any given time if it has been determined that one of the PQ PPK keys has been compromised. Needless to say, both PPK KEYID and the actual PPK (secret) need to match on both ends of the connection!

PPK KeyID can be up to 31 characters (ASCII). The supported length of the PPK itself is a range of 32-128 characters. We even make it simpler to auto-generate and copy the PPK secret so it can be easily and securely shared with the administrator of the peer IKE Gateway. 

Now let’s look at some of the system logs that might be helpful for troubleshooting.  

System Logs: 

Successful PPK Negotiation would look like this. Notice that N(PPK_Identity) message with notify type 16436 indicates that PQ-PPK is being used. 

Initiator

Responder

Below is a sample of how the same information is visible on the CLI. It is worth noting that CLI shows the use of DH2+PPK algorithm. 

There are several benefits of using RFC 8784 type open standard. First, let’s consider this. RFC 8784 being an approved open standard, has a growing industry multi-vendor support. It enables our customers to leverage their existing deployments and secure them with quantum-resistant VPN where possible while continuing to interoperate with vendors still relying on classic encryptions. Second, RFC 8784 implementation is also resource-friendly. There are no PQ KEMs needed in this phase of implementation. This allows customer implementations to be backward compatible, involves fewer changes, and therefore enables faster adoption. 

It is worth noting that RFC 8784 could be better. Manually configuring PPKs is not scalable for many sites, and gets tough after 25+ peers. Central management through Panorama or Strata Cloud Manager can help scale this for large deployments. Still, The PPK must remain secret and secured, a leaked or lost PPK significantly increases the risk of breach. Customers may be able to control their employees, but what about their partner employees? Relying on humans to create long and strong PPK can also be problematic. One must consider these against the benefits that RFC 8784 brings to the table. It is a precursor while the PQ KEM and hybrid key technologies are being developed. 

Quantum computing presents a significant threat to the security of VPN connections. By adopting post-quantum cryptography and implementing quantum-resistant measures like post-quantum pre-shared keys (PQ PPKs) in Palo Alto NGFW IPSEC VPN, customers can ensure the privacy and security of their users in a post-quantum world.

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.