How RFC 8784 Resists Quantum Computing Threats
IKEv2 VPNs based on RFC 8784 resist quantum attacks today by safeguarding key
exchange material.
Where Can I Use This? | What Do I Need? |
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:
A DH key and variants of DH keys rely on the difficulty of solving the discrete
log problem, such as solving for the very large prime numbers on which DH is
based. However, with the advent of cryptographically relevant quantum computers
(CRQCs), DH keys become vulnerable to attacks based on
Shor's algorithm. Implementing RFC 8784 enhances the
cryptographic strength of the key because the mixed key is no longer based
solely on the difficulty of solving the discrete log problem (e.g., solving for
very large prime numbers), so the mixed key isn't vulnerable to Shor's
algorithm
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.
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 in band 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 administrator
of the other IKEv2 peer. Each administrator programs the pre-shared secret into their
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.
Both IKEv2 peers must use exactly the same Key ID and pre-shared secret PQ PPK pairs.
If the Key IDs and their associated pre-shared secrets don't match, the connection
is aborted. If you configure more than one PQ PPK, both IKEv2 peers must have
exactly the same set of active Key IDs and pre-shared secrets. (Palo Alto Networks
enables you to configure up to ten active PQ PPKs, but some vendors allow as few as
one PQ PPK so it's important to understand the capabilities of the peer.
This standards-based method provides an easy way to prevent attackers from eavesdropping
on the connection and intercepting the keys, which would allow attackers to decrypt the
data sent in the VPN after it's established, while also ensuring interoperability with
other devices that adhere to the standard. The benefits of RFC 8784 include:
Approved standard with multi-vendor support.
Consumes no extra network resources and adds virtually no latency.
Backward compatible, so you can use it in networks where not all peers support
IKEv2 and where you don't control all of the peers.
Key is no longer based on primes and so isn't vulnerable to Shor's algorithm.
PQ PPK isn't transmitted so it can't be used to decrypt harvested data.
Recommended by government agencies, including NIAP, the NSA, the German Federal
Office for Information Security, and many more across the globe. Additionally,
creating a strong, random secret that is 32 bytes or greater in length meets the
NIST Category 5 security level. Ensure that the secret is strong and random,
doesn't follow a pattern, and isn't subject to dictionary attacks.
You can layer RFC 8784 with future standards-based capabilities such as PQC
hybrid keys.
This adds up to faster adoption because there are few changes to make and there's no
danger of dropping connections due to incompatibility. However, there are a few
disadvantages to RFC 8784:
Configuring static PQ PPKs manually doesn't scale well for many sites, although
pushing PQ PPKs from Panorama to managed firewalls can help mitigate
scaling.
The PQ PPKs must be kept securely by all IKEv2 administrators with whom they are
shared. That includes not only administrators internal to your company, but also
administrators at partners, vendors, and other outside administrators who you
need to peer with. The risk comes from administrators writing down the PQ PPK
and losing them or having them stolen or compromised.
Relying on human beings to create long, strong random secrets that resist
dictionary attacks and other attacks might be challenging. Palo Alto Networks'
implementation enables you to automatically generate long, strong, hexadecimal
secrets instead of having to create them yourself.
RFC 8784 based IKEv2 VPNs are the recommended first step to a solution against PQCs and
post-quantum threats. After NIST standardizes the first PQCs, other methods that can
work with RFC 8784 will enhance resistance to quantum threats, such as
RFC
9242 and
RFC 9370.
