Supported quantum RFCs, upgrade and downgrade considerations, HA, etc.
Where Can I Use This?
What Do I Need?
PAN-OS
PAN-OS 11.1 or later.
Support for post-quantum features and capabilities includes RFCs, HA, and upgrade and
downgrade considerations. It's early in the development of post-quantum standards and
features as nations, vendors, and enterprises grapple with how to defend their data from
post-quantum attacks. As standards progress and Palo Alto Networks platforms support
them, this topic will be updated to indicate that support.
Palo Alto Networks devices interoperate with other devices that support the same
standards, although some vendors implementations might differ based on the
interpretation of the RFCs. For example, some vendors might not offer the ability to
configure as many post-quantum pre-shared keys (PQ PPKs) with RFC 8784 or they might
not support the broad set of PQCs Palo Alto Networks supports with RFC 9370.
HA Support
High availability (HA) for IKE VPNs is the same as before the introduction of
post-quantum features: VPN tunnels continue to run after a failover, and IKE peers
re-sync and refresh IKE keys after a failover.
Quantum-Safe Cipher Translation
As quantum computing advances, traditional public key cryptography becomes
increasingly vulnerable to attacks that could compromise sensitive data.
Organizations face significant challenges in upgrading numerous internal and custom
applications to use post-quantum cryptography (PQC). This migration process is
time-consuming and sometimes impractical due to outdated codebases, resource
constraints, or lack of expertise. Palo Alto Networks Next-Generation Firewalls
(NGFWs) address this challenge through Quantum-Safe Cipher Translation, allowing you
to protect your communications against quantum threats while maintaining
compatibility with legacy systems that still use classical encryption.
Quantum-Safe Cipher Translation functions as an intermediary between
quantum-safe connections of end-users and your systems using classical cryptography
algorithms. When a client connects using quantum-safe encryption protocols, your
NGFW acts as a translation proxy. It terminates the quantum-safe connection from the
client, and then establishes a new connection to your internal application using
classical encryption that the application supports.
This translation occurs transparently, allowing modern clients that
implement post-quantum cryptography to securely communicate with your internal
applications that do not currently support PQC. External communications from end
users to the NGFW use quantum-safe encryption, while connections from the NGFW to
internal applications use classical encryption methods
You can implement Quantum-Safe Cipher Translation as part of a decryption profile configured on your NGFW. When selecting the key
exchange algorithms, you have the option to select PQC algorithms—PQC-Standard and
PQC-Experimental.
PQC-Standard allows your NGFW to use ML-KEM and Kyber key exchange
mechanisms (KEM) families.
PQC-Experimental allows your NGFW to use Frodo, Bike, and HQC KEM
families.
Additionally, you can specify your Preferred Session Settings, which allows you to
secure your client-side sessions or server-side sessions using PQC.
In the following example, the user selected PQC-Standard, as well as, allowing
client-side and server-side traffic to be post-quantum secure.
Client-side—if a PQC-Standard family is available in the
ClientHello, the NGFWuses that PQC-Standard KEM. Otherwise, the NGFW uses a
classical KEM.
Server-side—the NGFW sends both classical and PQC-Standard KEMs in the
ClientHello. If the server supports one of the PQC-Standard KEMs, that KEM is
used. If not, the session uses a classical KEM.
Upgrade and Downgrade Considerations
When you upgrade from a version that doesn't support post-quantum IKEv2 VPNs, the
platform provides support for the post-quantum features and capabilities.
When you downgrade to a version that supports the post-quantum features you
configured, the configuration is not changed and the post-quantum IKEv2 VPN security
remains in place.
When you downgrade to a version that doesn't support the post-quantum IKEv2 VPN
features:
If you didn't configure post-quantum IKEv2 VPNs, the downgrade proceeds as
usual and the post-quantum IKEv2 VPN security configuration options are
removed.
If you configured post-quantum IKEv2 VPNs, the downgrade is blocked because
the downgrade version doesn't support the post-quantum configuration
options. A warning message appears when the downgrade is blocked that
notifies you to remove the post-quantum IKEv2 VPN configuration and to
select the cipher you want to use for the VPN after the downgrade.
After you remove the post-quantum IKEv2 VPN configuration and select the
cipher, you can proceed with the downgrade.
The log files retain the post-quantum logs after the downgrade.