Configure Post-Quantum IKEv2 VPNs with RFC 8784 PPKs

1. Select NetworkNetwork ProfilesIKE Gateways and Add a new gateway.
2. Configure the General tab settings and select either IKEv2 only mode or IKEv2 preferred mode as the Version.
   In IKEv2 only mode, if the peer doesn't support IKEv2, the firewall aborts the connection. In IKEv2 preferred mode, if the peer doesn't support IKEv2, the firewall falls back to IKEv1. However, the VPN must negotiate IKEv2 to use the post-quantum VPN features, so if the firewall falls back to IKEv1, those features aren't available.

   IKEv1 is considered to be weak. If both IKE peers can support it, upgrade your VPN connections to IKEv2 and select IKEv2 only mode to ensure adequate levels of security and the ability to use PQ VPNs.
3. Select Advanced Options and configure the non-quantum options.
   If you selected IKEv2 preferred mode as the Version, there are tabs for IKEv1 and IKEv2; select IKEv2. If you selected IKEv2 only mode as the Version, only IKEv2 options display.

   Select PQ PPK (post-quantum pre-shared key) to configure the post-quantum elements of your IKEv2 VPN. (General enables you to add an IKE Crypto profile and set the Liveness Check.)
4. Enable Post-Quantum Pre-Shared Key (PPK) to enable using post-quantum resistance features on the VPN. This option is disabled by default.
   You must configure and activate at least one PQ PPK when you Enable Post-Quantum Pre-Shared Key (PPK) so that the firewall has a PQ PPK to use during IKEv2 negotiation and can support RFC 8784.
5. Set the Negotiation Mode to Preferred or Mandatory.
   • Preferred—When the firewall negotiates with the peer, the firewall first attempts to negotiate using PQ PPKs. If the peer doesn't support RFC 8784, the firewall falls back to a classical key exchange for the connection. If you don't know or don't have control over whether the peer supports RFC 8784, Preferred mode preserves backward compatibility to ensure connections fall back instead of dropping. Preferred is the default mode.
   • Mandatory—When the firewall negotiates with the peer, the peer must support RFC 8784 PQ PPKs. If the responding peer doesn't support RFC 8784, the firewall aborts the connection. Use Mandatory mode when you know the peer supports RFC 8784 PQ PPKs.
     Use Mandatory mode when you can for best security.

6. Add and Activate up to ten unique PQ PPKs.
   A PQ PPK consists of two paired elements: a PPK KeyID and a PPK Secret. The PPK KeyID is a unique string that identifies the PPK Secret and can be anything you want up to 31 characters, such as PPK-1 or Super Strong PPK. The PPK Secret is the random pre-shared key, which is never transmitted through the VPN because the administrators of both peers share the key using a secure communication method and configure it on the peers out-of-band. The firewall only transmits the KeyID in the IKEv2 VPN so that the peer can look up the PPK Secret locally.

   The number of PQ PPKs you can define depends on what the IKE peer can support. Some vendors' implementations allow fewer than ten unique PQ PPks; some implementations even allow only one. Don't define more PQ PPKs than the peer can support because both peers must have exactly the same PQ PPKs available.

   Configure multiple active PQ PPKs for peers that support multiple PQ PPKs. The firewall chooses randomly from the active PQ PPKs, which adds an element of randomness to the IKEv2 negotiation.

   Configuring multiple PQ PPKs is most secure because it adds a random element to PQ PPK selection.

   You can create the PPK Secret manually or use the firewall to generate a strong secret for you. Configure the PPK Secret manually if you want to generate the key yourself or if you receive a PQ PPK from a peer's administrator and you need to configure it on your firewall. The longer the PPK Secret, the greater the number of entropy bits, which makes the PPK Secret harder to crack.

   To configure the PPK Secret manually, which you can specify using ASCII characters:
   1. Specify a unique PPK KeyID of up to 31 characters.
   2. Specify a unique, random PPK Secret string. The string can be from 32-128 characters (16-64 bytes, which equates to 128-512 bits of entropy).
      Specify a PPK Secret that is at least 64 characters (32 bytes, or 256 bits of entropy) in length to create a strong key.
   3. Specify exactly the same string in Confirm PPK Secret.
      Store the PPK secret securely. The PPK secret is not displayed in cleartext, so if you don't store it now, you can't retrieve it later. (You can delete the PQ PPK and configure another one if necessary.) Because the IKEv2 peer must have the same PQ PPK (KeyID plus PPK Secret), you might need to communicate the PPK secret to another administrator. If so, make sure the communication method used is cryptographically secure and make sure the PPK secret is securely stored.

      The NSA publishes guidance on how to handle pre-shared keys safely, including RFC 8784 quantum pre-shared keys.
   4. Activate is selected by default so the firewall can use the PPK KeyID and PPK Secret pair (the PQ PPK) to negotiate with the peer. If you don't want the firewall to use this PPK KeyID and PPK Secret pair when negotiating with peers, uncheck Activate.
      For example, if you configure a new PQ PPK on a firewall, you might want to deactivate it until the peer's administrator can add the same PQ PPK to the peer to avoid a connection failure because the initiator uses a PQ PPK that isn't installed on the peer yet.
   5. Click OK. The PQ PPK tab shows the PPK KeyID in cleartext,hides the pre-shared key, and shows the activate state of the PQ PPK.

   To configure the PPK Secret using the firewall's automatic strong PPK generation, which uses hexadecimal characters:

   1. Specify a unique PPK KeyID of up to 31 characters.
   2. Set the PPK length (characters) to the length you want to generate for the PPK Secret. The default is 32 characters (16 bytes).
      Set PPK length (characters) to at least 64 characters (32 bytes, or 256 bits of entropy) in length to generate a strong key.
   3. Click Generate Strong PPK. The firewall generates and displays a strong PPK secret of the length specified in PPK length (characters).
      This is the only time the PPK secret is displayed in cleartext. If you do not securely store the secret, you can't retrieve it. (You can delete the PQ PPK and configure another one if necessary.) Because the IKEv2 peer must have the same PQ PPK (KeyID plus PPK Secret), you might need to communicate the PPK secret to another administrator. If so, make sure the communication method used is cryptographically secure and make sure the PPK secret is securely stored.
      Copy the PPK secret, click OK, and paste it into the PPK Secret and Confirm PPK Secret fields.
   4. Activate is selected by default so the firewall can use the PPK KeyID and PPK Secret pair (the PQ PPK) to negotiate with the peer. If you don't want the firewall to use this PPK KeyID and PPK Secret pair when negotiating with peers, uncheck Activate.
      For example, if you configure a new PQ PPK on a firewall, you might want to deactivate it until the peer's administrator can add the same PQ PPK to the peer to avoid a connection failure because the initiator uses a PQ PPK that isn't installed on the peer yet.
   5. Click OK. The PQ PPK tab shows the PPK KeyID in cleartext,hides the pre-shared key, and shows the activate state of the PQ PPK.
7. Click OK to create the VPN.
8. Commit the configuration.
   The Post-Quantum IKEv2 RFC 8784 Configuration Example topic provides an example of a simple topology and how to configure post-quantum IKEv2 VPN support for the topology.
9. If you aren't the administrator of both IKEv2 peers, securely communicate the PQ PPK (KeyID plus PPK Secret) to the peer's administrator for installation on the peer. Secure PQ PPK communication and storage are critical for securing your data.
   Both IKEv2 peers must have the same active Key IDs and associated pre-shared secrets to bring up the post-quantum VPN connection.