Post-Quantum Transition Planning Best Practices

Starting Early
—If your company has long-lived data and is a potential target of harvesting attacks, each day you delay taking action risks allowing attackers to harvest more information to decrypt later. The earlier you take action, the sooner you stop attackers from harvesting data to decrypt in the future.
Leveraging Existing Resources
—When you take your crypto inventory, leverage work you have already done for audits, Zero Trust, network enhancements, and other activities.
Educating Yourself
—Learn about the quantum computing threat, post-quantum cryptography (PQC), technologies and methods to harden your network against quantum attacks, and the new and emerging PQCs that you can use to protect your network. Learn from government mandates, plans, and laws, RFCs, and other information sources.

Cryptography Best Practices

Follow RFC 6379 for
Suite B Cryptographic Suites for IPsec
to upgrade your VPN connections to tough cipher suites. Use Suite-B-GCM-256 and avoid weaker 128-bit AES algorithms, which are vulnerable to Grover's algorithm.
Upgrade your CA to 4K RSA key sizes to mitigate brute force attacks that can break smaller key sizes.
Migrate your VPN certificate authentication to new certificates with larger key sizes.
Upgrade to higher-bit SHA hash sizes such as SHA-384 and SHA-512. Stop using weak hashes such as MD5 and SHA-1.
Upgrade SSL/TLS connections to tough cipher suites; use TLSv1.3 with Perfect Forward Secrecy (PFS) ciphers.
Tunnel SSL/TLS sessions in hardened, client-to-server VPN sessions.
Configure your Vulnerability Protection profiles to block unsanctioned PQCs for traffic that you don't decrypt. For traffic that you decrypt, use a Decryption profile to block unsanctioned PQCs (the Decryption profile only allows the ciphers that you enable and the firewall blocks all other ciphers). Unsanctioned PQCs might indicate a breach or an internal bad actor attempting to use PQCs to compromise your network. Make exceptions as needed for your internal PEN testing teams.

VPN Configuration Best Practices

Implement RFC 8784 to create IKEv2 VPNs that resist quantum attacks.
Implement RFC 9242 and RFC 9370 to create IKEv2 VPNs that resist quantum attacks.
RFC 8784 can be used with RFC 9242 and RFC 9370 to provide an additional layer of protection and this can meet cryptographic agility requirements.

Don't use IKEv1. IKEv1 is considered to be a weak protocol and does not support post-quantum VPNs. If both IKE peers can support it, upgrade your VPN connections to IKEv2 and select
IKEv2 only mode
when you configure the IKE gateways (
Network
Network Profiles
IKE Gateways
General
).
Set the
Negotiation Mode
to
Mandatory
whenever you know both peers support RFC 8784. Using
Mandatory
mode ensures that the VPN resists post-quantum attacks and attackers can't harvest the data now and decrypt it later using a CRQC running Shor's algorithm.
Shor's algorithm can crack the dynamic key exchange in the IKEv2 handshake that uses asymmetric encryption, given enough processing power. However, Shor's algorithm can't crack the IPSec tunnel symmetric encryption. To protect the symmetric IPSec encryption, use AES-256 to protect against Grover's algorithm and use the stronger hashes and key lengths recommended in the previous section on cryptography best practices.
When peering with external devices, try to ascertain whether the peer supports RFC 8784 and work with the other administrator to use the same PQ PPKs for the connection so that you can use Mandatory mode.
Manually specify or automatically generate a PPK Secret that is at least 64 characters (32 bytes, or 256 bits of entropy) in length to create a strong key. You can manually specify or automatically generate a
PPK Secret
that is up to 128 characters (64 bytes, 512 bits of entropy) long. The longer the PPK Secret, the greater the number of entropy bits, which makes the PPK Secret harder to crack.
The number of entropy bits provides half that number of bits of post-quantum security. For example, 256 bits of entropy provides 128 bits of post-quantum security and 512 bits of entropy provides 256 bits of post-quantum security. A minimum of 256 bits of entropy provides the security equivalent to Category 5 as defined in the NIST Post-Quantum Cryptography Call for Proposals. The Security Considerations section of RFC 8784 provides more details about entropy and what amount of entropy is sufficient.
The PPK secret is only shown in cleartext when you configure it or generate it automatically. After you configure or generate the PPK secret and navigate away from the screen that shows the secret in cleartext, it's never shown in cleartext again to help prevent compromising the key.
Copy the PPK secret and KeyID pair and store it securely. If you don't store the key when you configure or generate it, you can't retrieve it later. (You can delete the PQ PPK and configure another one if necessary.)
Other best practices for handling PQ PPKs include:
Create multiple active PQ PPKs. Using multiple active keys, not just one, adds an element of randomness to key selection during the key exchange.
Ensure that each IKEv2 peer has exactly the same set of activated PQ PPKs (KeyID plus PPK secret pairs) to negotiate the key exchange.
If Panorama manages the peers, configure the PQ PPKs and push them to managed firewalls for easier, faster, and more automatic configuration.
If you need to communicate the PQ PPK to another administrator, use a cryptographically secure communication method such as encrypted email.
Store the PPK secret string securely. Don't keep it on sticky notes or anywhere unauthorized administrators might discover it.
The NSA publishes guidance on how to handle pre-shared keys safely, including RFC 8784 quantum pre-shared keys.

Don't use IKEv1. IKEv1 is considered to be a weak protocol and does not support post-quantum VPNs. If both IKE peers can support it, upgrade your VPN connections to IKEv2 and select
IKEv2 only mode
when you configure the IKE gateways (
Network
Network Profiles
IKE Gateways
General
).
Create the hybrid key using a strong classic KEM, such as Diffie-Hellman Group 20 and above, and at least one PQC in the additional KEM rounds, such as Kyber-768 (ML-KEM), when you configure the IKE crypto profiles (
Network
Network Profiles
IKE Crypto
General and Advanced Options
).
Use only PQCs that are rated at a security strength level of L3 or higher for sensitive information. Each additional PQC added to the key creation process increases the key’s ability to resist a quantum attack, but it also adds latency and overhead to the IKEv2 peering process. In general, adding a security level L3 PQC adds approximately 20 to 30 ms to the IKEv2 key exchange, and adding a security level L5 PQC adds 40 to 60 ms. Stronger PQCs that use larger keys, such as Classic McEliese, can potentially add more than 800 ms to the key exchange and introduce high levels of fragmentation. Familiarize yourself with the PQC key sizes and security strengths to select the best PQC for your VPN communications.
Coordinate the PQCs used in each key negotiation round with the administrator who manages the peer VPN device. When both VPN devices on each side of the tunnel are configured with the same PQCs in each optional key negotiation round, interoperability issues are minimized. Try to agree on the PQC and its security strength to ensure both sides are configured with the same parameters. For firewalls managed under the same organization, central management tools can be used to ensure consistent configuration and PQC selection in each key negotiation round.
Enable cryptographic agility to safeguard your data during the transition to a pure PQC environment. The transition can take as much as 5 to 10 years before the industry fully trusts the new PQCs.
For organizations that must use PQCs standardized by NIST and approved by FIPS, cryptographic agility can be achieved by enabling RFC 8784 with RFC 9242 and RFC 9370. If the PQC used in the hybrid key falls to a vulnerability, the PPK string used in RFC 8784 can still provide quantum resistance to prevent a successful harvesting attack.
For organizations that are allowed to use both NIST standardized and non-standardized PQCs, cryptographic agility can be achieved by using at least two PQCs with a strong classic KEM, such as Diffie-Hellman Group 21. Ideally, the PQC KEMs should be using different mathematical technologies where one KEM is based on lattice and the other based on code-based or other non-lattice technologies. Optionally, RFC 8784 can also be enabled with the hybrid key to add an extra layer of security and extend cryptographic agility.
Reduce the key lifetime value from its default value to a lower value to facilitate faster rekeying.
Enable IPSec to use hybrid keys when you configure the IPSec crypto profiles (
Network
Network Profiles
IPSec Crypto
General and Advanced Options
). Both sides of the IPSec tunnel must be configured to use the same PQC and security strength in each additional key exchange round.