Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Quantum Safe IPsec VPN

Learn how to use and configure the out-of-band key retrieval mechanisms in the IKED process to negotiate with quantum secured IKE and IPsec SAs.

Quantum Security Overview

The IPsec communication channel relies on the Internet Key Exchange (IKE) protocol. The IKE maintains security parameters to protect the data traffic. The security parameters include encryption and authentication algorithms, and associated keys.

The security protocols rely on asymmetric cryptographic algorithms such as Diffie Hellman (DH) or Elliptic Curve Diffie Hellman (ECDH) to establish keys are vulnerable to attacks.

To avoid security attacks, the RFC8784 introduces a method out-of-band method. The out-of-band method adds a secret key at the initiator and the responder. The secret key is Post-quantum Pre-shared Key (PPK).

  • You can use the PPK in addition to the authentication method in IKEv2.

  • PPK provides quantum resistance to any child SAs in initial negotiated IPsec SAs and any subsequent reeked IPsec SAs.

  • With PPK and peer authentication key, initiator and responder can detect key mismatch.

Quantum Security Overview

The IPsec communication channel relies on the Internet Key Exchange (IKE) protocol. The IKE maintains security parameters to protect the data traffic. The security parameters include encryption and authentication algorithms, and associated keys.

The security protocols rely on asymmetric cryptographic algorithms such as Diffie Hellman (DH) or Elliptic Curve Diffie Hellman (ECDH) to establish keys are vulnerable to attacks.

To avoid security attacks, the RFC8784 introduces a method out-of-band method. The out-of-band method adds a secret key at the initiator and the responder. The secret key is Post-quantum Pre-shared Key (PPK).

  • You can use the PPK in addition to the authentication method in IKEv2.

  • PPK provides quantum resistance to any child SAs in initial negotiated IPsec SAs and any subsequent reeked IPsec SAs.

  • With PPK and peer authentication key, initiator and responder can detect key mismatch.

Junos Key Manager Overview

You can use Junos Key Manager (JKM) to configure the static keys or dynamics keys to protect the data plane and control plane.

The JKM process acts as a key store and a proxy between the client or crypto application. The client or crypto application requires a key to establish an encrypted and authenticated quantum safe session with peer or application. The quantum safe uses the out-of-band key retrieval mechanism that lets two peers have the key. Different out-of-band mechanisms will have different protocols or methods to communicate. The JKM provides a common uniform interface for client or crypto applications to communicate.

Key Retrieval Mechanism

Two out-of-band key retrieval mechanisms in the IKED process to negotiate with quantum secured IKE and IPsec SAs.

  • Static Key—With static key profiles, you can configure a static key ID and a corresponding key. The same static key ID and key gets generated every time a request to JKM over a static key profile.

  • Quantum Key Manager—With quantum key manager key profiles, you can access the Quantum Key Distribution (QKD) devices and Quantum Network. The Quantum Network generates and exchange quantum keys between peers. Generates a different key ID and key every time on request to JKM over a quantum key manager key profile.

Junos Key Manager Overview

You can use Junos Key Manager (JKM) to configure the static keys or dynamics keys to protect the data plane and control plane.

The JKM process acts as a key store and a proxy between the client or crypto application. The client or crypto application requires a key to establish an encrypted and authenticated quantum safe session with peer or application. The quantum safe uses the out-of-band key retrieval mechanism that lets two peers have the key. Different out-of-band mechanisms will have different protocols or methods to communicate. The JKM provides a common uniform interface for client or crypto applications to communicate.

Key Retrieval Mechanism

Two out-of-band key retrieval mechanisms in the IKED process to negotiate with quantum secured IKE and IPsec SAs.

  • Static Key—With static key profiles, you can configure a static key ID and a corresponding key. The same static key ID and key gets generated every time a request to JKM over a static key profile.

  • Quantum Key Manager—With quantum key manager key profiles, you can access the Quantum Key Distribution (QKD) devices and Quantum Network. The Quantum Network generates and exchange quantum keys between peers. Generates a different key ID and key every time on request to JKM over a quantum key manager key profile.

Use Key Profile for Quantum Safe IPsec VPN

With static key profiles, you can configure a static key ID and a corresponding key. To establish the quantum safe IPsec SAs, use the static key profile as Post-Quantum Pre-Shared Key (PPK) profile in the IPsec-VPN configuration. Uses the same key and key ID to re-authenticate existing IKE SA.

With quantum key manager key profile profiles, to access the Quantum Networks you need access to the QKD devices. The Quantum Network generates and exchanges quantum keys between peers. You can configure all the necessary parameters such as local SAE ID, URL to the QKD device, and so on. To establish IPsec SAs, use the quantum key manager key profile as Post-Quantum Pre-Shared Key (PPK) profile in the IPsec VPN configuration. Uses a different key and key ID to re-authenticate existing IKE SA.

Use Key Profile for Quantum Safe IPsec VPN

With static key profiles, you can configure a static key ID and a corresponding key. To establish the quantum safe IPsec SAs, use the static key profile as Post-Quantum Pre-Shared Key (PPK) profile in the IPsec-VPN configuration. Uses the same key and key ID to re-authenticate existing IKE SA.

With quantum key manager key profile profiles, to access the Quantum Networks you need access to the QKD devices. The Quantum Network generates and exchanges quantum keys between peers. You can configure all the necessary parameters such as local SAE ID, URL to the QKD device, and so on. To establish IPsec SAs, use the quantum key manager key profile as Post-Quantum Pre-Shared Key (PPK) profile in the IPsec VPN configuration. Uses a different key and key ID to re-authenticate existing IKE SA.

Quantum Key Distribution

Quantum key distribution (QKD) is a secure key distribution method that uses quantum. Networks use quantum channels for generating the same key at both ends and monitor the quantum channel between the peers. These keys are dynamic, protects the data plane, and control plane.

Key Management Entity (KME) is the term we use to refer to the QKD devices on the management or control layer. QKD devices connect to each other through their quantum or QKD network. The KMEs connects over the public network through the secure channels for exchanging any control messages. The applications, Secure Application Entity (SAEs), and devices interact with KMEs through the secure channels as per ETSI specification. HTTPS combines with mutual TLS authentication and enables secure operations over the QKD network.

Figure 1: Two Devices Interacting with Their Corresponding QKD Devices to Establish a Quantum Secured SessionTwo Devices Interacting with Their Corresponding QKD Devices to Establish a Quantum Secured Session

In the Figure 1 describes how the two devices interacting with their corresponding QKD devices to establish a quantum secured session

  • SAE A role is primary. SAE A acts as the initiator to establish a quantum secured session with SAE B.

  • The SAE B role is secondary. SAE B acts as the responder.

  • The SAE A request the KME A through the Get key API to generate and share a new quantum key with SAE B with target SAE ID.

  • The KME A performs the operation and responds to SAE A with the generated key ID and key material.

  • KME B receives the key material and the generated ID key over the QKD network.

  • The SAE A initiates secured session with SAE B directly using the same key and key ID.

  • An exchange of messages establishes a secure session with SAE B.

  • SAE A sends the key ID in plaintext or encrypted for the corresponding quantum key that is used to secure the session with SAE B.

  • Once SAE B receives the key ID, the SAE B contacts KME B through the Get key with IDs API to get the corresponding quantum-key for the given key ID and target SAE ID or SAE A.

  • After SAE B gets the key, a fully quantum secured session establishes between SAE A and SAE B.

Quantum Key Distribution

Quantum key distribution (QKD) is a secure key distribution method that uses quantum. Networks use quantum channels for generating the same key at both ends and monitor the quantum channel between the peers. These keys are dynamic, protects the data plane, and control plane.

Key Management Entity (KME) is the term we use to refer to the QKD devices on the management or control layer. QKD devices connect to each other through their quantum or QKD network. The KMEs connects over the public network through the secure channels for exchanging any control messages. The applications, Secure Application Entity (SAEs), and devices interact with KMEs through the secure channels as per ETSI specification. HTTPS combines with mutual TLS authentication and enables secure operations over the QKD network.

Figure 2: Two Devices Interacting with Their Corresponding QKD Devices to Establish a Quantum Secured SessionTwo Devices Interacting with Their Corresponding QKD Devices to Establish a Quantum Secured Session

In the Figure 2 describes how the two devices interacting with their corresponding QKD devices to establish a quantum secured session

  • SAE A role is primary. SAE A acts as the initiator to establish a quantum secured session with SAE B.

  • The SAE B role is secondary. SAE B acts as the responder.

  • The SAE A request the KME A through the Get key API to generate and share a new quantum key with SAE B with target SAE ID.

  • The KME A performs the operation and responds to SAE A with the generated key ID and key material.

  • KME B receives the key material and the generated ID key over the QKD network.

  • The SAE A initiates secured session with SAE B directly using the same key and key ID.

  • An exchange of messages establishes a secure session with SAE B.

  • SAE A sends the key ID in plaintext or encrypted for the corresponding quantum key that is used to secure the session with SAE B.

  • Once SAE B receives the key ID, the SAE B contacts KME B through the Get key with IDs API to get the corresponding quantum-key for the given key ID and target SAE ID or SAE A.

  • After SAE B gets the key, a fully quantum secured session establishes between SAE A and SAE B.

Configure Static Key Profile for Junos Key Manager

This example shows how to configure static key profile for Junos key manager. Configure the static keys on concerned gateways and do not need share static keys over the Internet to establish the IPsec tunnel.

Requirements

  1. Hardware requirements —Juniper Networks® SRX1500 Firewall and higher-numbered device models or Juniper Networks® vSRX Virtual Firewall (vSRX3.0).

  2. Software requirements—Junos OS Release 22.4R1 or later with JUNOS ike and JUNOS Key Manager packages.

Overview

With static key based profiles you need to configure a static key ID and a corresponding key. If you use the static key profile in the IPsec VPN object, when the re-authentication for existing IKE SA the same key and key ID are used.

Configuration

Configure the static key profile for Junos key manager.

Verification

Purpose

Verify the static key profile and keys.

Action

From operational mode, enter the request security key-manager profiles get profile-keys name km_profile_1 to view the static key profile and keys.

From operational mode, enter the show security key-manager profiles name km_profile_1 detail to view the static key profile details.

Meaning

The request security key-manager profiles get profile-keys name km_profile_1 displays the status, static key profile name, type, key size, key ID, and keys.

The show security key-manager profiles name km_profile_1 detail displays the static key profile name, type, and request status.

Example: Configure Static Keys Profile for Site-to-Site VPN

Use this configuration example to configure the static key profile. You can use the static key profile to secure an IPsec Site-to-Site VPN infrastructure.

You can secure an IPsec Site-to-Site VPN infrastructure by configuring the static key profile.

In this configuration example, the SRX1 and SRX2 devices use the static key profile to fetch the QKD keys on IPsec VPN. The QKD keys help to send traffic securely over the Internet.

Tip:
Table 1: Estimated Timers

Reading Time

Less than an hour

Configuration Time

Less than an hour

Example Prerequisites

Table 2: Requirements

Hardware requirements

Juniper Networks® SRX1500 Firewall or higher-numbered device models or Juniper Networks® vSRX Virtual Firewall (vSRX3.0)

Software requirements

Junos OS Release 22.4R1 or later.

Before You Begin

Table 3: Benefits, Resources, and Additional Information

Benefits

  • Threat identification

    By configuring quantum keys, you can establish a secure quantum channel between the QKD devices. This improves threat identification and secures the network.

  • Extend security

    You can merge the existing keys with quantum keys and encrypt and decrypt them over existing VPN tunnels. This improves the security of the IPsec VPN infrastructure.

  • Enhanced cryptographic strength

    RFC 8784 compliance provides you with an easy way to prevent attackers from eavesdropping on the connection and intercepting the keys. This also ensures interoperability with other devices that adhere to the standard.

Useful Resources

 

Know more

Hands-on experience

vLABs Sandbox

Learn more

RFC 8784 - Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security

Functional Overview

Table 4: Static Key Manager Functional Overview
IPsec VPN

Deploy a IPsec VPN topology where SRX Series Firewall devices are connected by VPN tunnels that send traffic through the IPsec VPN tunnel. The VPN tunnels are later configured to use quantum keys making them quantum-safe VPN tunnels.

IKE gateway

Establish a secure connection, the IKE gateway uses the IKE policy to limit itself to the configured group of CAs (ca-profiles) while validating the certificate.

Proposals
IKE proposal

Define the algorithms and keys used to establish the secure IKE connection with the peer security gateway.

IKE creates the dynamic SAs and negotiates them for IPsec.

IPsec proposal

List protocols, algorithms, and security services to be negotiated with the remote IPsec peer.

Policies
IKE policy

Define a combination of security parameters (IKE proposals) to be used during IKE negotiation.

IPsec policy

Contain rules and security policies to allow group VPN traffic between the zones specified.

Security policy

Allows you to select the type of data traffic to secure through the IPsec SAs.

  • VPN-OUT – Permits traffic from the trust zone to the vpn zone, where the match criteria is:

    • source-address: HOST-1-Net

    • destination-address: HOST-2-Net

    • application: any

  • VPN-IN – Permits traffic from the vpn zone to the trust zone, where the match criteria is:

    • source-address: HOST-2-Net

    • destination-address: HOST-1-Net

    • application: any

Profiles

Key profile

Define how the SRX Series Firewall devices use the static key profile to fetch the QKD keys on IPsec VPN to send traffic securely over the Internet.

  • Key profile—A static key-profile km_profile_1 is configured for applications and services to retrieve the configured key-id and corresponding key.

  • IKE proposal—An IKE proposal IKE_PROP is configured with the required algorithms to establish an IKE SA.

  • IKE policy—An IKE policy IKE_POL is configured to set the runtime negotiation and authentication attributes.

  • IKE gateway—An IKE gateway IKE_GW is configured to manage the IPsec tunnels between endpoints. A ppk-profile indicates which key-profile to use to establish Quantum safe IKE or IPsec SA.

  • IPsec proposal—An IPsec proposal IPSEC_PROP is configured with the required algorithms to establish an IPsec SA.

  • IPsec policy—An IPsec policy IPSEC_POL is configured to set the runtime IPsec negotiation attributes.

  • IPsec VPN—An IPsec VPN policy IPSEC_VPN is configured to set the range of subnets that needs to be secured.

  • Security zone—Three different security zones trust, untrust and vpn are configured for better segregation of expected traffic within each of these zones.

  • Security policy—Security policies trust to vpn and vpn to trust are configured between the security zones to filter out which type of data traffic gets secured through the IPsec SAs.

PPK Profile

Indicate which key profile to use to establish quantum-safe IKE or IPsec SAs by referencing the key profile under the IKE gateway.

Certificates
CA certificate Verify identity of devices and authenticate communication link between them.
Local certificate Generate PKI and enroll it with the CA certificate for verification.
KME certificate Third-party certificate generated by vendor
Security Zones
trust

Network segment at the host zone

untrust

Network segment at the destination server zone

vpn

Network segment through which the SRX1 and SRX2 devices interact.

Primary verification tasks

Verify the established IKE and IPsec SAs are Quantum safe.

Topology Overview

In this example, SRX1 initiates the negotiation of quantum safe IPsec tunnels with SRX2 using CLI configured static key. SRX2 responds to this request by verifying SRX1’s identity along with the key and establishes a quantum safe IPsec VPN. Once the tunnel is established, data traffic between Host1 and Host2 are secured using the established IPsec tunnel.

Table 5: Devices, Role, and Functionality used in this Configuration

Hostname

Role

Function

SRX1

SRX Series Firewall capable of establishing IPsec tunnels

Initiates IKE or IPsec SA negotiation and establishes Quantum-safe IPsec tunnels with SRX2 using static key configured on the SRX1.

SRX2 SRX Series Firewall capable of establishing IPsec tunnels Responds to the IKE or IPsec SA negotiation initiated by SRX1 and establishes Quantum-safe IPsec tunnels using static key configured on the SRX2.
Host1 A Host inside the trusted zone or LAN side of SRX1 Initiates client-side traffic toward Host2
Host2 A Host inside the trusted zone or LAN side of SRX2 Responds to client-side traffic from Host1

Topology Illustration

Figure 3: Site-to-Site VPN Site-to-Site VPN

Step-By-Step Configuration on SRX Series Firewall Devices

Note:

For complete sample configurations on the DUT, see:

This configuration is applicable for only SRX1 and SRX2 devices. You must make the appropriate device-specific configuration changes.

  1. Configure the interfaces.

  2. Configure a key profile of type static with a key-id and a corresponding key.

  3. Configure the security zones.

Verification

This section provides a list of show commands that you can use to verify the feature in this example.

Table 6: Show Commands to Verify

Command

Verification Task

show security ike security-associations detail

Verify that the IKE SAs are established.

show security ipsec security-associations detail

Verify that the IPsec SAs are established.

show security ipsec statistics

Verify IPsec encryption and decryption statistics.

show security key-manager profiles detail

Verify key profile statistics.

ping 192.168.80.20 source 192.168.90.20 count 4

Ping from HOST1 to HOST2 or vice versa.

Verify IKE SAs

Purpose

Verify the IKE SAs

Action

From operational mode, enter the show security ike security-associations detail command to view the IKE SAs.

Meaning

The Role: Initiator, State: UP, PPK-profile: km_profile_1 Optional: No, IPSec security associations: 4 created, and Flags: IKE SA is created fields shows the IKE SAs are created successfully.

Verify IPsec SAs

Purpose

Verify the IPsec SAs

Action

From operational mode, enter the show security ipsec security-associations detail command to view the IPsec SAs.

Meaning

The Version: IKEv2 Quantum Secured: Yes and tunnel-establishment: establish-tunnels-immediately IKE SA Index: 1 fields shows the IPsec SAs are created successfully.

The sample output confirms the IPsec SAs.

Verify IPsec Statistics

Purpose

Verify the IPsec statistics.

Action

From operational mode, enter the show security ipsec statistics command to view the IPsec statistics.

Meaning

The ESP Statistics and AH Statistics fields shows the IPsec statistics.

Verify Key Manager Profile

Purpose

Verify the key manager profile.

Action

From operational mode, enter the show security key-manager profiles detail to view the key manager profile.

Meaning

The Name: km_profile_1 and Type: Static fields shows the key manager profile.

Ping from HOST 1 to HOST 2

Purpose

Verify the connectivity from HOST 1 to HOST 2.

Action

From operational mode, enter the ping 192.168.80.20 source 192.168.90.20 count 4 to view the connectivity from HOST 1 to HOST 2.

Meaning

The PING 192.168.80.20 (192.168.80.20): 56 data bytes confirms the connectivity from HOST 1 to HOST 2.

Appendix 1: Set Commands on all Devices

Set command output on all devices.

Set Commands on SRX1
Set Commands on SRX2

Appendix 2: Show Configuration Output on DUT

SRX1

From configuration mode, confirm your configuration by entering the show security key-manager profiles, show security key-manager, show interfaces, show security zones, show security policies, show security ike proposal IKE_PROP, show security ike policy IKE_POL, show security ike gateway IKE_GW, show security ipsec proposal IPSEC_PROP, show security ipsec policy IPSEC_POL, and show security ipsec vpn IPSEC_VPN commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

SRX2

From configuration mode, confirm your configuration by entering the show security key-manager profiles, show security key-manager, show interfaces, show security zones, show security policies, show security ike proposal IKE_PROP, show security ike policy IKE_POL, show security ike gateway IKE_GW, show security ipsec proposal IPSEC_PROP, show security ipsec policy IPSEC_POL, and show security ipsec vpn IPSEC_VPN commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Example: Configure Quantum-Secured IPsec AutoVPN Topology Using Quantum Key Manager Key Profile

Use this configuration example to secure an IPsec AutoVPN infrastructure by configuring the quantum key manager key profile.

The Hub, Spoke 1, and Spoke 2 use quantum key manager key profiles to communicate with KME Hub, KME Spoke 1, and KME Spoke 2 to fetch the QKD keys and establish then IPsec VPN tunnels.

Tip:
Table 7: Estimated Timers

Reading Time

Less than an hour.

Configuration Time

Less than an hour.

Example Prerequisites

Table 8: Hardware and Software Requirements

Hardware requirements

  • Juniper Networks® SRX1500 Firewall or higher-numbered device models or Juniper Networks® vSRX Virtual Firewall (vSRX3.0)

  • Third-party Key Management Entity (KME) or Quantum Key Distribution (QKD) devices. The KME parameters are as per ETSI GS QKD 014 specification.

Software requirements

Junos OS Release 22.4R1 or later.

Before You Begin

Table 9: Benefits, Resources, and Additional Information

Benefits

  • Threat identification

    Establish a secure quantum channel between the QKD devices that guarantees threat identification with the help of quantum keys.

  • Extend security

    Merge existing keys with quantum keys and encrypt and decrypt them over existing VPN tunnels thereby extending security of the IPsec VPN infrastructure.

  • RFC 8784 compliant

    Extend the already standardized RFC 8784 procedure.

Useful Resources

 

Know more

Hands-on Experience

vLab Sandbox: IPsec VPN - Policy-based

Learn more

Functional Overview

Table 10 provides a quick summary of the configuration components deployed in this example.

Table 10: Quantum Key Manager Functional Overview
IPsec VPN

Deploy a hub-and-spoke IPsec VPN topology where spokes are connected by VPN tunnels that send traffic through the hub. These VPN tunnels are later configured to use quantum keys making them quantum-safe VPN tunnels.

IKE gateway

Establish a secure connection, the IKE gateway uses the IKE policy to limit itself to the configured group of CAs (ca-profiles) while validating the certificate.

Proposals
IKE proposal

Define the algorithms and keys used to establish the secure IKE connection with the peer security gateway.

IKE creates the dynamic SAs and negotiates them for IPsec.

IPsec proposal

List protocols, algorithms, and security services to be negotiated with the remote IPsec peer.

Policies
IKE policy

Define a combination of security parameters (IKE proposals) to be used during IKE negotiation.

IPsec policy

Contain rules and security policies to allow group VPN traffic between the zones specified.

Security policy

Allows you to select the type of data traffic to secure through the IPsec SAs.

  • VPN-OUT – Permits traffic from the trust zone to the vpn zone, where the match criteria is:

    • source-address: HOST-1-Net

    • destination-address: HOST-2-Net

    • application: any

  • VPN-IN – Permits traffic from the vpn zone to the trust zone, where the match criteria is:

    • source-address: HOST-2-Net

    • destination-address: HOST-1-Net

    • application: any

Profiles

Key profile

Define how the SRX devices communicate with the KME devices to retrieve QKD keys from the external KME server. Key profiles are configured on the hub (HUB_KM_PROFILE_1) and spokes (SPOKE_1_KM_PROFILE_1 and SPOKE_2_KM_PROFILE_1) separately.

Configure SPOKE-1 and SPOKE-2 for applications and services to retrieve QKD keys from external server.

  • Key profile—Configure the following quantum key manager key profiles on the Hub.

    • HUB_KM_PROFILE_1

    • SPOKE_1_KM_PROFILE_1

    • SPOKE_2_KM_PROFILE_1

  • Configure SPOKE-1 and SPOKE-2 with the required algorithms to establish an IKE SAs.

    IKE proposal—Configure the following IKE proposals on the Hub.

    • HUB_IKE_PROP

    • SPOKE_1_IKE_PROP

    • SPOKE_2_IKE_PROP

  • Configure SPOKE-1 and SPOKE-2 to set the runtime negotiation and authentication attributes.

    IKE policy—Configure the following IKE policies on the Hub.

    • HUB_IKE_POL

    • SPOKE_1_IKE_POL

    • SPOKE_3_IKE_POL

  • Configure SPOKE-1 and SPOKE-2 to set the endpoints between the IPsec tunnels.

    IKE gateway—Configure the following IKE gateways on the Hub.

    A ppk-profile indicates which key-profile to use to establish quantum-safe IKE or IPsec SA.

    • HUB_IKE_GW

    • SPOKE_1_IKE_GW

    • SPOKE_2_IKE_GW

  • Configure SPOKE-1 and SPOKE-2 with the required algorithms to establish an IPsec SA.

    IPsec proposal—Configure the following IPsec proposals on the Hub.

    • HUB_IPSEC_PROP

    • SPOKE_1_IPSEC_PROP

    • SPOKE_2_IPSEC_PROP

  • Configure SPOKE-1 and SPOKE-2 to set the runtime IPsec negotiation attributes.

    IPsec policy—Configure the following IPsec policies on the Hub.

    • HUB_IPSEC_POL

    • SPOKE_1_IPSEC_POL

    • SPOKE_2_IPSEC_POL

  • Configure SPOKE-1 and SPOKE-2 to set the range of subnets that need to be secured.

    IPsec VPN—Configure the following IPsec VPNs on the Hub.

    • HUB_IPSEC_VPN

    • SPOKE_1_IPSEC_VPN

    • SPOKE_2_IPSEC_VPN

  • Security zone—Configure three different security zones to segregate the traffic.

    • trust

    • untrust

    • vpn

  • Security policy—Configure the security policies trust to vpn and vpn to trust to select the type of data traffic that is secured through the IPsec SAs.

PPK Profile

Indicate which key profile to use to establish quantum-safe IKE or IPsec SAs by referencing the key profile under the IKE gateway.

Certificates
CA certificate Verify identity of devices and authenticate communication link between them.
Local certificate Generate PKI and enroll it with the CA certificate for verification.
KME certificate Third-party certificate generated by vendor.
Security Zones
trust

Network segment at the host zone.

untrust

Network segment at the destination server zone.

vpn

Network segment through which the hub and spokes interact.

Primary verification tasks

Verify the established IKE and IPsec SAs are Quantum safe.

Topology Overview

In this example, we secure the hub-and-spoke IPsec VPN tunnels using quantum keys generated by third-party KME devices. The KME devices (KME-Hub, KME-Spoke 1, and KME-Spoke 2) are connected to each other through a quantum channel that is highly secure and capable of threat identification. Using this channel, the Hub and Spoke devices retrieve quantum keys from their corresponding KME device and merge it with the existing keys to make the VPN tunnels quantum secure.

Table 11: Quantum Key Manager Topology Components

Topology Components

Role

Function

Hub SRX Series Firewall capable of establishing IPsec tunnels Responds to IKE or IPsec SA negotiation and establishes Quantum-safe IPsec tunnels using QKD key from KME-HUB QKD device on SPOKE-1 and SPOKE-2.
SPOKE-1 SRX Series Firewall capable of establishing IPsec tunnels Initiates IKE or IPsec SA negotiation and establishes Quantum-safe IPsec tunnels with hub using QKD key from KME-SPOKE-1 QKD device.
SPOKE-2 SRX Series Firewall capable of establishing IPsec tunnels Initiates IKE or IPsec SA negotiation and establishes Quantum-safe IPsec tunnels with hub using QKD key from KME-SPOKE-2 QKD device.
HOST-1 Host inside the trusted zone or LAN side of SPOKE 1. Host 1 is secured by SPOKE 1. Initiates client-side traffic toward HOST-3
HOST-2 Host inside the trusted zone or LAN side of SPOKE 2. Host 2 is secured by SPOKE 2. Initiates client-side traffic toward HOST-3
HOST- 3 Host inside the trusted zone or LAN side of hub. Host 3 is secured by Hub. Responds to client-side traffic from HOST-1 and HOST-2
KME-HUB Third-party QKD device Provides QKD keys in response to key requests from HUB
KME-SPOKE-1 Third-party QKD device Provides QKD keys in response to key requests from SPOKE-1
KME-SPOKE-2 Third-party QKD device Provides QKD keys in response to key requests from SPOKE-2

Topology Illustration

Figure 4: Quantum Key Manager with AutoVPNQuantum Key Manager with AutoVPN

Step-By-Step Configuration on Hub

Note:

For complete sample configurations on the hub and spoke devices, see:

  1. Configure the hub interfaces.

  2. Configure hub-spoke the IPsec VPN. This includes configuring the security zones, security policies, and relevant certificates for authenticating device identities and their communication links.

    Configure the hub to fetch the CA certificate from the CA server, or load a locally available CA certificate from the device.

    Note:

    The KME certificates need to configured as per third-party vendor instructions.

    Configure the IPsec proposal and policy. Configure the IKE policy, proposal and gateway for the IPsec VPN.

  3. Configure the quantum key manager key profile to retrieve quantum keys from the corresponding KME-Hub device.

  4. Bind the quantum key manager key profile as the IKE gateway ppk-profile to make the VPN tunnels quantum-safe.

If you are done configuring the device, enter commit from configuration mode.

Step-By-Step Configuration on Spoke Devices

Note:

For complete sample configurations on the devices, see:

This configuration is applicable for Spoke 1 and Spoke 2 devices, you must make the appropriate device-specific configuration changes.

  1. Configure the spoke interfaces.

  2. Configure hub-spoke the IPsec VPN. This includes configuring the security zones, security policies, and relevant certificates for authenticating device identities and their communication links.

    Configure the hub to fetch the CA certificate from the CA server, or load a locally available CA certificate from the device.

    Note:

    The KME certificates need to configured as per third-party vendor instructions.

    Configure the IPsec proposal and policy. Configure the IKE policy, proposal and gateway for the IPsec VPN.

  3. Configure the quantum key manager key profile to retrieve quantum keys from the corresponding spoke device.

  4. Bind the quantum key manager key profile as the IKE gateway ppk-profile to make the VPN tunnels quantum-safe.

If you are done configuring the device, enter commit from configuration mode.

Verification

This section provides a list of show commands that you can use to verify the feature in this example.

Table 12: Verification Tasks
Command Verification Task

show security ike security-associations detail

Verify the IKE SAs.

show security ipsec security-associations detail

Verify the IPsec SAs.

show security ipsec statistics

Verify IPsec encryption and decryption statistics.

show security key-manager profiles detail

Verify key profile statistics.

ping 192.168.90.20 source 192.168.80.20 count 4

Ping from Host 1 to Host 3.

ping 192.168.90.20 source 192.168.70.20 count 4

Ping from Host 2 to Host 3.

Verify IKE SAs

Purpose

Verify the IKE SAs.

Action

From operational mode, enter the show security ike security-associations detail command to view the IKE SAs.

Meaning

The sample output confirms the IKE SAs.

Verify IPsec SAs

Purpose

Verify the IPsec SAs.

Action

From operational mode, enter the show security ipsec security-associations detail command to view the IPsec SAs.

Meaning

The sample output confirms the IPsec SAs.

Verify IPsec Statistics

Purpose

Verify the IPsec statistics.

Action

From operational mode, enter the show security ipsec statistics command to view the IPsec statistics.

Meaning

The sample output confirms the IPsec statistics.

Verify Key Manager Profile

Purpose

Verify the key manager profile.

Action

From operational mode, enter the show security key-manager profiles detail command and verify the Success field in the Request stats option.

Meaning

The sample output confirms the quantum key manager profile.

Ping from Host 1 to Host 3

Purpose

Verify the connectivity from Host 1 to Host 3.

Action

From operational mode, enter the ping 192.168.90.20 source 192.168.80.20 count 5 command to view the connectivity from Host 1 to Host 3.

Meaning

The sample output confirms the connectivity from Host 1 to Host 3.

Ping from Host 2 to Host 3

Purpose

Verify the connectivity from Host 2 to Host 3.

Action

From operational mode, enter the ping 192.168.90.20 source 192.168.80.20 count 5 command to view the connectivity from Host 2 to Host 3.

Meaning

The sample output confirms the connectivity from Host 2 to Host 3.

Appendix 1: Set Commands on all Devices

Set command output on all devices.

Set Commands on Hub
Set Commands on Spoke 1
Set Commands on Spoke 2

Appendix 2: Show Configuration Output on DUT

Show command output on the DUT.

Hub

From configuration mode, confirm your configuration by entering the show security pki ca-profile Root-CA, show security key-manager, show security ike proposal HUB_IKE_PROP, show security ike policy HUB_IKE_POL, show security ike gateway HUB_IKE_GW, show security ipsec proposal HUB_IPSEC_PROP, show security ipsec policy HUB_IPSEC_POL, show security ipsec vpn HUB_IPSEC_VPN, show security zones security-zone untrust, show security zones security-zone trust, show security policies from-zone trust to-zone vpn, show security policies from-zone vpn to-zone trust, and show interfaces commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Spoke 1

From configuration mode, confirm your configuration by entering the show security pki ca-profile Root-CA, show security key-manager profiles SPOKE_1_KM_PROFILE_1, show security ike proposal SPOKE_1_IKE_PROP, show security ike policy SPOKE_1_IKE_POL, show security ike gateway SPOKE_1_IKE_GW, show security ipsec proposal SPOKE_1_IPSEC_PROP, show security ipsec policy SPOKE_1_IPSEC_POL, show security ipsec vpn SPOKE_1_IPSEC_VPN, show interfaces, show security zones security-zone untrust, show security zones security-zone trust, show security policies from-zone trust to-zone vpn, and show security policies from-zone vpn to-zone trust commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Spoke 2

From configuration mode, confirm your configuration by entering the show security pki ca-profile Root-CA, show security key-manager profiles SPOKE_1_KM_PROFILE_1, show security ike proposal SPOKE_1_IKE_PROP, show security ike policy SPOKE_1_IKE_POL, show security ike gateway SPOKE_1_IKE_GW, show security ipsec proposal SPOKE_1_IPSEC_PROP, show security ipsec policy SPOKE_1_IPSEC_POL, show security ipsec vpn SPOKE_1_IPSEC_VPN, show interfaces, show security zones security-zone untrust, show security zones security-zone trust, show security policies from-zone trust to-zone vpn, and show security policies from-zone vpn to-zone trust commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Example: Configure Static Keys Profile for AutoVPN

Use this configuration example to secure an IPsec AutoVPN infrastructure by configuring the static key profile.

You can secure an IPsec AutoVPN infrastructure by configuring the static key profile.

In this configuration example, the Hub, Spoke 1, and Spoke 2 use static key profiles to fetch the QKD keys on IPsec VPN. The QKD keys help send traffic securely over the Internet.

Tip:
Table 13: Estimated Timers

Reading Time

Less than an hour

Configuration Time

Less than an hour

Example Prerequisites

Table 14: Requirements

Hardware requirements

  • Juniper Networks® SRX1500 Firewall or higher-numbered device models or Juniper Networks® vSRX Virtual Firewall (vSRX3.0)

  • Third-party Key Management Entity (KME) or Quantum Key Distribution (QKD) devices. The KME parameters are as per ETSI GS QKD 014 specification.

Software requirements

Junos OS Release 22.4R1 or later.

Before You Begin

Table 15: Benefits, Resources, and Additional Information

Benefits

  • Threat identification

    By configuring quantum keys, you can establish a secure quantum channel between the QKD devices. This improves threat identification and secures the network.

  • Extend security

    You can merge the existing keys with quantum keys and encrypt and decrypt them over existing VPN tunnels. This improves the security of the IPsec VPN infrastructure.

  • Enhanced cryptographic strength

    RFC 8784 compliance provides you with an easy way to prevent attackers from eavesdropping on the connection and intercepting the keys. This also ensures interoperability with other devices that adhere to the standard.

Useful Resources

 

Know more

Hands-on experience

vLABs Sandbox

Learn more

RFC 8784 - Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security

Obtain the address of the certificate authority (CA) and the information they require (such as the challenge password) then you submits requests for local certificates. See Understanding Local Certificate Requests.

Enroll the digital certificates in each device. See Example: Loading CA and Local Certificates Manually.

Functional Overview

Table 16: Static Key Manager Functional Overview
IPsec VPN

Deploys a hub-and-spoke IPsec VPN topology where spokes are connected by VPN tunnels that send traffic through the hub. These VPN tunnels are later configured to use quantum keys making them quantum-safe VPN tunnels.

IKE gateway

Establishes a secure connection, the IKE gateway uses the IKE policy to limit itself to the configured group of CAs (ca-profiles) while validating the certificate.

Proposals
IKE proposal

Defines the algorithms and keys used to establish the secure IKE connection with the peer security gateway.

IKE creates the dynamic SAs and negotiates them for IPsec.

IPsec proposal

Lists protocols, algorithms, and security services to be negotiated with the remote IPsec peer.

Policies
IKE policy

Defines a combination of security parameters (IKE proposals) to be used during IKE negotiation.

IPsec policy

Contains rules and security policies to allow group VPN traffic between the zones specified.

Security policy

Allows you to select the type of data traffic to secure through the IPsec SAs.

  • VPN-OUT—Permits traffic from the trust zone to the vpn zone, where the match criteria is:

    • source-address: HOST-1-Net

    • destination-address: HOST-2-Net

    • application: any

  • VPN-IN—Permits traffic from the vpn zone to the trust zone, where the match criteria is:

    • source-address: HOST-2-Net

    • destination-address: HOST-1-Net

    • application: any

Profiles

Key profile

Define how the SRX Series Firewall devices communicate with the KME devices to retrieve QKD keys from the external KME server. Key profiles are configured on the hub (HUB_KM_PROFILE_1) and spokes (SPOKE_1_KM_PROFILE_1 and SPOKE_2_KM_PROFILE_1) separately.

  • Key profile—Static key-profiles HUB_KM_PROFILE_1, SPOKE_1_KM_PROFILE_1 and SPOKE_2_KM_PROFILE_1 are configured on the HUB, SPOKE-1 and SPOKE-2 respectively for applications/services to retrieve a CLI configured key-id and corresponding key.

  • IKE proposal—IKE proposals HUB_IKE_PROP, SPOKE_1_IKE_PROP and SPOKE_2_IKE_PROP are configured on the HUB, SPOKE-1 and SPOKE-2 respectively with the required algorithms for establishing an IKE security association.

  • IKE policy—IKE policies HUB_IKE_POL, SPOKE_1_IKE_POL and SPOKE_3_IKE_POL are configured on the HUB, SPOKE-1 and SPOKE-2 respectively to set the runtime negotiation/authentication attributes.

  • IKE gateway—IKE gateways HUB_IKE_GW, SPOKE_1_IKE_GW and SPOKE_2_IKE_GW are configured on the HUB, SPOKE-1 and SPOKE-2 respectively to set the endpoints between whom the IPsec tunnels need to be established, reference the configured IKE policy, the version of IKE that needs to be used and a ppk-profile to signify which key-profile needs to be used to establish Quantum safe IKE/IPsec security associations.

  • IPsec proposal—IPSEC proposals HUB_IPSEC_PROP, SPOKE_1_IPSEC_PROP and SPOKE_2_IPSEC_PROP are configured on the HUB, SPOKE-1 and SPOKE-2 respectively with the required algorithms for establishing an IPSEC security association.

  • IPsec policy—IPSEC policies HUB_IPSEC_POL, SPOKE_1_IPSEC_POL and SPOKE_2_IPSEC_POL are configured on the HUB, SPOKE-1 and SPOKE-2 respectively to set the runtime IPsec negotiation attributes.

  • IPsec VPN—IPSEC VPNs HUB_IPSEC_VPN, SPOKE_1_IPSEC_VPN and SPOKE_2_IPSEC_VPN are configured on the HUB, SPOKE-1 and SPOKE-2 respectively to set the range of subnets that needs to be secured, reference the configured ipsec policy and ike gateway.

  • Security zone—3 different security zones trust, untrust and vpn are configured for better segregation of expected traffic within each of these zones.

  • Security policy—Security policies trust to vpn and vpn to trust are configured between the security zones to filter out which type of data traffic get secured through the IPsec security associations.

PPK Profile

Indicates which key profile to use to establish quantum-safe IKE or IPsec SAs by referencing the key profile under the IKE gateway.

Certificates
CA certificate Verifies identity of devices and authenticate communication link between them.
Local certificate Generates PKI and enroll it with the CA certificate for verification.
KME certificate Third-party certificate generated by vendor.
Security Zones
trust

Network segment at the host zone.

untrust

Network segment at the destination server zone.

vpn

Network segment through which the hub-and-spoke interacts.

Primary verification tasks

Verify the established IKE and IPsec SAs are Quantum safe.

Topology Overview

In this example, SPOKE 1 and SPOKE 2 initiate the negotiation of quantum-safe IPsec tunnels with the Hub using CLI-configured static key. The Hub responds to the requests by verifying the identity of Spoke 1 and Spoke 2 along with their respective keys and establishes a quantum-safe IPsec VPN with both the spokes. Once the tunnels are established, data traffic between Host 1 and Host 3, and between Host 2 and Host 3 are secured using the established IPsec tunnels.

Table 17: Devices, Role, and Functionality used in this Configuration

Hostname

Role

Function

Hub SRX Series Firewall capable of establishing IPsec tunnels Responds to IKE or IPsec SA negotiation initiated by SPOKE 1 and SPOKE 2 and establishes quantum-safe IPsec tunnels using static key configured on the Hub device.
Spoke 1 SRX Series Firewall capable of establishing IPsec tunnels Initiates IKE/IPsec SA negotiation and establishes quantum-safe IPsec tunnels with the Hub using static key configured on the Spoke 1.
Spoke 2 SRX Series Firewall capable of establishing IPsec tunnels Initiates IKE or IPsec SA negotiation and establishes quantum-safe IPsec tunnels with the Hub using static key configured on the Spoke 2.
Host 1 Host inside the trusted zone or LAN side of Spoke 1 Initiates client-side traffic toward Host 3.
Host 2 Host inside the trusted zone or LAN side of Spoke 2 Initiates client-side traffic toward Host 3.
Host 3 Host inside the trusted zone or LAN side of HUB Responds to client-side traffic from Host 1 and Host 2.

Topology Illustration

Figure 5: Static Key with Auto VPN Static Key with Auto VPN

Step-By-Step Configuration on Hub

Note:

For complete sample configurations on the DUT, see:

This configuration is applicable for only the Hub devices. You must make the appropriate device-specific configuration changes.

  1. Configure the hub interfaces.

  2. Configure the CA profile and CA certificate.

  3. From the operational mode, bind the CA certificate to CA profile.

  4. Configure the static key manager profile.

  5. Configure the hub-spoke on the IPsec VPN. This includes configuring the security zones, security policies, and relevant certificates for authenticating device identities and their communication links.

Step-By-Step Configuration on Spoke Devices

Note:

For complete sample configurations on the DUT, see:

This configuration is applicable for Spoke 1 and Spoke 2 devices. For other devices, you must make appropriate device-specific configuration changes.

  1. Configure the spoke interfaces.

  2. Configure hub-spoke on the IPsec VPN. This includes configuring the security zones, security policies, and relevant certificates for authenticating device identities and their communication links.

  3. Configure the static key manager profile.

Verification

This section provides a list of show commands that you can use to verify the feature in this example.

Command Verification Task

show security ike security-associations detail

Verify that the IKE SAs are established.

show security ipsec security-associations detail

PurposeVerify that the IPsec SAs are established.

show security ipsec statistics

PurposeVerify IPsec encryption and decryption statistics.

show security key-manager profiles detail

Verify key profile statistics.

ping 192.168.90.20 source 192.168.80.20 count 4

Ping from Host 1 to Host 3 or vice versa.

Verify IKE SAs

Purpose

Verify the IKE SAs.

Action

From operational mode, enter the show security ike security-associations detail command to view the IKE SAs.

Meaning

The Role: Responder, State: UP, PPK-profile: HUB_KM_PROFILE_1, IPSec security associations: 2 created, 0 deleted, and Flags: IKE SA is created fields shows the IKE SAs are created successfully.

Verify IPsec SAs

Purpose

Verify the IPsec SAs.

Action

From operational mode, enter the show security ipsec security-associations detail command to view the IPsec SAs.

Meaning

The Quantum Secured: Yes, Passive mode tunneling: Disabled, Policy-name: HUB_IPSEC_POL, and IPsec SA negotiation succeeds (1 times) fields shows the IPsec SAs are created successfully.

Verify IPsec Statistics

Purpose

Verify the IPsec statistics.

Action

From operational mode, enter the show security ipsec statistics command to view the IPsec statistics.

Meaning

The ESP Statistics and AH Statistics fields shows the IPsec statistics.

Verify Key Manager Profile

Purpose

Verify the key manager profile.

Action

From operational mode, enter the show security key-manager profiles detail command to view the key manager profile.

Meaning

The Name: HUB_KM_PROFILE_1 and Type: Static fields shows the key manager profile

Ping from Host 1 to Host 3 or vice versa

Purpose

Verify the connectivity from Host 1 to Host 3.

Action

From operational mode, enter the ping 192.168.90.20 source 192.168.80.20 count 4 command to view the connectivity from Host 1 to Host 3.

Meaning

The PING 192.168.80.20 (192.168.80.20): 56 data bytes confirms the connectivity from HOST 1 to HOST 3.

Ping from Host 2 to Host 3 or vice versa

Purpose

Verify the connectivity from Host 2 to Host 3.

Action

From operational mode, enter the ping 192.168.90.20 source 192.168.80.20 count 4 to view the connectivity from Host 2 to Host 3.

Meaning

The PING 192.168.80.20 (192.168.80.20): 56 data bytes confirms the connectivity from HOST 2 to HOST 3.

Appendix 1: Set Commands on all Devices

Set command output on all devices.

Set Commands on Hub
Set Commands on Spoke 1
Set Commands on Spoke 2

Appendix 2: Show Configuration Output on DUT

Hub

From configuration mode, confirm your configuration by entering the show security ike proposal HUB_IKE_PROP, show security ike policy HUB_IKE_POL, show security ike gateway HUB_IKE_GW, show security ipsec proposal HUB_IPSEC_PROP, show security ipsec policy HUB_IPSEC_POL, show security ipsec vpn HUB_IPSEC_VPN, show interfaces, show security zones, and show security policies commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Spoke 1

From configuration mode, confirm your configuration by entering the show security pki ca-profile Root-CA, show security key-manager profiles SPOKE_1_KM_PROFILE_1, show security ike proposal SPOKE_1_IKE_PROP, show security ike policy SPOKE_1_IKE_POL, show security ike gateway SPOKE_1_IKE_GW, show security ipsec proposal SPOKE_1_IPSEC_PROP, show security ipsec policy SPOKE_1_IPSEC_POL, show security ipsec vpn SPOKE_1_IPSEC_VPN, show interfaces, show security zones, show security policies, and show security pki commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Spoke 2

From configuration mode, confirm your configuration by entering the show security pki, show security key-manager, show security ike proposal SPOKE_2_IKE_PROP, show security ike policy SPOKE_2_IKE_POL, show security ike gateway SPOKE_2_IKE_GW, show security ipsec proposal SPOKE_2_IPSEC_PROP, show security ipsec vpn SPOKE_2_IPSEC_VPN, show interfaces, show security zones, and show security policies commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Configure Quantum Key Manager Key Profile for Junos Key Manager

This example shows how to configure quantum key profile for Junos key manager. Configure the quantum key manager key profile to generate and send the generated keys to establish quantum safe IPsec VPN tunnel.

Requirements

  1. Hardware requirements —Juniper Networks® SRX1500 Firewall and higher-numbered device models or Juniper Networks® vSRX Virtual Firewall (vSRX3.0).

  2. Software requirements—Junos OS Release 22.4R1 or later with JUNOS ike and JUNOS Key Manager packages.

  3. Use any QKD device supporting ETSI Quantum Key Distribution (QKD) Rest API standard for communication.

  4. Load the local certificates on the device. We recommended you to provide full path to the certificate.

Overview

The SRX Series Firewall devices use the IPsec VPN to send traffic securely over the Internet. Configure the quantum key manager key profile in the IPsec VPN, to re-authenticate the existing IKE SA and a new key and key.

The quantum key manager key profile uses secure key distribution method based on QKD to generate and distribute keys that are quantum safe. These keys are dynamic.

Configuration

  1. Configure the CA certificate.

  2. Load the CA certificate.

  3. Enroll the CA certificate.

  4. Configure the quantum key manager profile.

Verification

Purpose

Verify the quantum key manager key profile and keys.

Action

From operational mode, enter the show security pki ca-certificate ca-profile Root-CA to view the CA profile and CA certificates.

From operational mode, enter the show security pki local-certificate certificate-id SAE_A_CERT to view the PKI local certificates.

From operational mode, enter the request security key-manager profiles get profile-keys name km_profile_1 peer-sae-id SAE_B to view peer device key manager profile and keys.

From operational mode, enter the show security key-manager profiles name KM_PROFILE_1 detail to view key manager profile details.

Meaning

The show security pki ca-certificate ca-profile Root-CA displays PKI CA profile name, certificate identifier, validity, public key algorithm, and so on.

The show security pki local-certificate certificate-id SAE_A_CERT displays the local CA profile name, certificate identifier, validity, public key algorithm, and so on.

The request security key-manager profiles get profile-keys name km_profile_1 peer-sae-id SAE_B displays peer device key manager profile and keys.

The show security key-manager profiles name KM_PROFILE_1 detail displays the security key manager profile name, URL, requests, and so on.

Example: Configure Quantum Key Manager Key Profile for Site-to-Site IPsec VPN

Use this configuration example to secure an IPsec Site-to-Site VPN infrastructure by configuring the quantum key manager key profile.

You can secure an IPsec Site-to-Site VPN infrastructure by configuring the quantum key manager key profile.

In this configuration example, The SRX1 and SRX2 devices use the quantum key manager profile to fetch the QKD keys on IPsec VPN. The QKD keys help send traffic securely over the Internet.

Tip:
Table 18: Estimated Timers

Reading Time

Less than an hour

Configuration Time

Less than an hour

Example Prerequisites

Table 19: Hardware and Software Requirements

Hardware requirements

Juniper Networks® SRX1500 Firewall or higher-numbered device models or Juniper Networks® vSRX Virtual Firewall (vSRX3.0)

Software requirements

Junos OS Release 22.4R1 or later.

Before You Begin

Table 20: Benefits, Resources, and Additional Information

Benefits

  • Threat identification

    By configuring quantum keys, you can establish a secure quantum channel between the QKD devices. This improves threat identification and secures the network.

  • Extended security

    You can merge the existing keys with quantum keys and encrypt and decrypt them over existing VPN tunnels. This improves the security of the IPsec VPN infrastructure.

  • Enhanced cryptographic strength

    RFC 8784 compliance provides you with an easy way to prevent attackers from eavesdropping on the connection and intercepting the keys. This also ensures interoperability with other devices that adhere to the standard.

  • Interoperability support

    You can use any QKD device that supports ETSI QKD Rest API.

Useful Resources

 

Know more

Hands-on experience

vLABs Sandbox

Learn more

RFC 8784 - Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security

ETSI QKD Rest API

Functional Overview

Table 21: Quantum Key Manager Key Profile Functional Overview
IPsec VPN

Deploys a hub-and-spoke IPsec VPN topology where spokes are connected by VPN tunnels that send traffic through the hub. These VPN tunnels are later configured to use quantum keys making them quantum-safe VPN tunnels.

IKE gateway

Establishes a secure connection. The IKE gateway uses the IKE policy to limit itself to the configured group of certificate authority (CA) profiles while validating the certificate.

Proposals
IKE proposal

Defines the algorithms and keys used to establish the secure IKE connection with the peer security gateway.

IKE creates the dynamic security associations (SAs) and negotiates them for IPsec.

IPsec proposal

Lists protocols, algorithms, and security services to be negotiated with the remote IPsec peer.

Policies
IKE policy

Defines a combination of security parameters (IKE proposals) to be used during IKE negotiation.

IPsec policy

Contains rules and security policies to allow group VPN traffic between the zones specified.

Security policy

Allows you to select the type of data traffic to secure through the IPsec SAs.

  • VPN-OUT—Permits traffic from the trust zone to the vpn zone, where the match criteria is:

    • source-address: HOST-1-Net

    • destination-address: HOST-2-Net

    • application: any

  • VPN-IN—Permits traffic from the vpn zone to the trust zone, where the match criteria is:

    • source-address: HOST-2-Net

    • destination-address: HOST-1-Net

    • application: any

Profiles

Key profile

Defines how the SRX Series Firewall devices communicate with the KME devices to retrieve QKD keys from the external KME server. Key profiles are configured on the hub (HUB_KM_PROFILE_1) and spokes (SPOKE_1_KM_PROFILE_1 and SPOKE_2_KM_PROFILE_1) separately.

  • Key profile—A quantum key manager profile km_profile_1 is configured for applications and services to retrieve QKD keys from an external server.

  • IKE proposal—An IKE proposal IKE_PROP is configured with the required algorithms to establish an IKE SA.

  • IKE policy—An IKE policy IKE_POL is configured to set the runtime negotiation and authentication attributes.

  • IKE gateway—An IKE gateway IKE_GW is configured to manage the IPsec tunnels between endpoints. A ppk-profile indicates which key-profile to use to establish Quantum safe IKE or IPsec SA.

  • IPsec proposal—An IPsec proposal IPSEC_PROP is configured with the required algorithms to establish an IPsec SA.

  • IPsec policy—An IPsec policy IPSEC_POL is configured to set the runtime IPsec negotiation attributes.

  • IPsec VPN—An IPsec VPN policy IPSEC_VPN is configured to set the range of subnets that needs to be secured.

  • Security zone—Three different security zones trust, untrust and vpn are configured for better segregation of expected traffic within each of these zones.

  • Security policy—Security policies trust to vpn and vpn to trust are configured between the security zones to filter out which type of data traffic gets secured through the IPsec SAs.

PPK Profile

Indicates which key profile to use to establish quantum-safe IKE or IPsec SAs by referencing the key profile under the IKE gateway.

Certificates
CA certificate Verifies identity of devices and authenticate communication link.
Local certificate Generates PKI and enroll it with the CA certificate for verification.
KME certificate Third-party certificate generated by vendor.
Security Zones
trust

Network segment at the host zone.

untrust

Network segment at the destination server zone.

vpn

Network segment through which the hub and spokes interact.

Primary verification tasks

Verify the established IKE and IPsec SAs are Quantum safe.

Topology Overview

In this example, we secure the SRX1 and SRX2 IPsec VPN tunnels by using quantum keys generated by third-party KME devices. The KME devices (KME-A and KME-B) are connected to each other through a quantum channel that is highly secure and capable of threat identification. Using this channel, the SRX1 and SRX2 devices retrieve quantum keys from their corresponding KME device and merge it with the existing keys to make the VPN tunnels quantum secure.

Table 22: Devices, Role, and Functionality used in this Configuration

Hostname

Role

Function

SRX1 SRX Series Firewall device capable of establishing IPsec tunnels Initiates IKE or IPsec SA negotiation and establishes quantum-safe IPsec tunnels with SRX2 using QKD key fetched from KME-A QKD device.
SRX2 SRX Series Firewall device capable of establishing IPsec tunnels Responds to IKE or IPsec SA negotiation and establishes quantum-safe IPsec tunnels using QKD key from KME-B QKD device.
HOST1 Host inside the trusted zone or LAN side of SRX1 Initiates client-side traffic toward HOST 2
HOST2 Host inside the trusted zone or LAN side of SRX2 Responds to client-side traffic from HOST 1.
KME-A Third-party vendor QKD device Provides QKD keys in response to key requests from SRX1.
KME-B Third-party vendor QKD device Provides QKD keys in response to key requests from SRX2.

Topology Illustration

Figure 6: Site-to-Site VPN Site-to-Site VPN

Step-By-Step Configuration on SRX Series Firewall Devices

Note:

For complete sample configurations on the DUT, see:

This configuration is applicable to SRX1 and SRX2 devices. For other devices, you must make the appropriate device-specific configuration changes.

  1. Configure the interfaces.

  2. Configure a key profile of type quantum-key-manager with the must or recommended parameters.

    Define the CA certificate, configure the URL of the KME server, configure the SAE-ID to be used by the local end, configure the corresponding certificate for the local SAE-ID, and configure the previously defined CA certificate.

  3. Configure Site-to-Site IPsec VPN. This includes configuring the security zones, security policies, and relevant certificates for authenticating device identities and their communication links.

Verification

This section provides a list of show commands that you can use to verify the feature in this example.

Command Verification Task

show security ike security-associations detail

PurposeVerify that the IKE SAs are established.

show security ipsec security-associations detail

Verify that the IPsec SAs are established.

show security ipsec statistics

Verify IPsec encryption and decryption statistics.

show security key-manager profiles detail

Verify key profile statistics.

ping 192.168.80.20 source 192.168.90.20 count 5

Ping from HOST 1 to HOST 2 or vice versa.

Verify IKE SAs

Purpose

Verify the IKE SAs.

Action

From operational mode, enter the show security ike security-associations detail command to view the IKE SAs.

Meaning

The Role: Initiator, State: UP, PPK-profile: km_profile_1, IPSec security associations: 2 created, 0 deleted Phase 2 negotiations in progress: 1, and Flags: IKE SA is created fields shows the IKE SAs are created successfully.

Verify IPsec SAs

Purpose

Verify the IPsec SAs.

Action

From operational mode, enter the show security ipsec security-associations detail command to view the IPsec SAs.

Meaning

The Quantum Secured: Yes, Policy-name: IPSEC_POL, IPsec SA negotiation succeeds (1 times), and tunnel-establishment: establish-tunnels-immediately IKE SA Index: 21 fields shows the IPsec SAs are created successfully.

Verify IPsec Statistics

Purpose

Verify the IPsec statistics.

Action

From operational mode, enter the show security ipsec statistics command to view the IPsec statistics.

Meaning

The ESP Statistics and AH Statistics fields shows the IPsec statistics.

Verify Key Manager Profile

Purpose

Verify the key manager profile.

Action

From operational mode, enter the show security key-manager profiles detail command to view the key manager profile.

Meaning

The Name: km_profile_1 and Quantum-key-manager fields shows the key manager profile.

Ping from HOST 1 to HOST 2 or vice versa

Purpose

Verify the connectivity from HOST 1 to HOST 2.

Action

From operational mode, enter the ping 192.168.80.20 source 192.168.90.20 count 5 to view the connectivity from HOST 1 to HOST 2.

Meaning

The PING 192.168.80.20 (192.168.80.20): 56 data bytes count 5 confirms the connectivity from HOST 1 to HOST 2.

Appendix 1: Set Commands on all Devices

Set command output on all devices.

Set Commands on SRX1
Set Commands on SRX2

Appendix 2: Show Configuration Output on DUT

Show command output on the DUT.

SRX1

SRX 2

Example: Configure Quantum-Secured IPsec AutoVPN Topology Using Quantum Key Manager Key Profile

Use this configuration example to secure an IPsec AutoVPN infrastructure by configuring the quantum key manager key profile.

The Hub, Spoke 1, and Spoke 2 use quantum key manager key profiles to communicate with KME Hub, KME Spoke 1, and KME Spoke 2 to fetch the QKD keys and establish then IPsec VPN tunnels.

Tip:
Table 23: Estimated Timers

Reading Time

Less than an hour.

Configuration Time

Less than an hour.

Example Prerequisites

Table 24: Hardware and Software Requirements

Hardware requirements

  • Juniper Networks® SRX1500 Firewall or higher-numbered device models or Juniper Networks® vSRX Virtual Firewall (vSRX3.0)

  • Third-party Key Management Entity (KME) or Quantum Key Distribution (QKD) devices. The KME parameters are as per ETSI GS QKD 014 specification.

Software requirements

Junos OS Release 22.4R1 or later.

Before You Begin

Table 25: Benefits, Resources, and Additional Information

Benefits

  • Threat identification

    Establish a secure quantum channel between the QKD devices that guarantees threat identification with the help of quantum keys.

  • Extend security

    Merge existing keys with quantum keys and encrypt and decrypt them over existing VPN tunnels thereby extending security of the IPsec VPN infrastructure.

  • RFC 8784 compliant

    Extend the already standardized RFC 8784 procedure.

Useful Resources

 

Know more

Hands-on Experience

vLab Sandbox: IPsec VPN - Policy-based

Learn more

Functional Overview

Table 10 provides a quick summary of the configuration components deployed in this example.

Table 26: Quantum Key Manager Functional Overview
IPsec VPN

Deploy a hub-and-spoke IPsec VPN topology where spokes are connected by VPN tunnels that send traffic through the hub. These VPN tunnels are later configured to use quantum keys making them quantum-safe VPN tunnels.

IKE gateway

Establish a secure connection, the IKE gateway uses the IKE policy to limit itself to the configured group of CAs (ca-profiles) while validating the certificate.

Proposals
IKE proposal

Define the algorithms and keys used to establish the secure IKE connection with the peer security gateway.

IKE creates the dynamic SAs and negotiates them for IPsec.

IPsec proposal

List protocols, algorithms, and security services to be negotiated with the remote IPsec peer.

Policies
IKE policy

Define a combination of security parameters (IKE proposals) to be used during IKE negotiation.

IPsec policy

Contain rules and security policies to allow group VPN traffic between the zones specified.

Security policy

Allows you to select the type of data traffic to secure through the IPsec SAs.

  • VPN-OUT – Permits traffic from the trust zone to the vpn zone, where the match criteria is:

    • source-address: HOST-1-Net

    • destination-address: HOST-2-Net

    • application: any

  • VPN-IN – Permits traffic from the vpn zone to the trust zone, where the match criteria is:

    • source-address: HOST-2-Net

    • destination-address: HOST-1-Net

    • application: any

Profiles

Key profile

Define how the SRX devices communicate with the KME devices to retrieve QKD keys from the external KME server. Key profiles are configured on the hub (HUB_KM_PROFILE_1) and spokes (SPOKE_1_KM_PROFILE_1 and SPOKE_2_KM_PROFILE_1) separately.

Configure SPOKE-1 and SPOKE-2 for applications and services to retrieve QKD keys from external server.

  • Key profile—Configure the following quantum key manager key profiles on the Hub.

    • HUB_KM_PROFILE_1

    • SPOKE_1_KM_PROFILE_1

    • SPOKE_2_KM_PROFILE_1

  • Configure SPOKE-1 and SPOKE-2 with the required algorithms to establish an IKE SAs.

    IKE proposal—Configure the following IKE proposals on the Hub.

    • HUB_IKE_PROP

    • SPOKE_1_IKE_PROP

    • SPOKE_2_IKE_PROP

  • Configure SPOKE-1 and SPOKE-2 to set the runtime negotiation and authentication attributes.

    IKE policy—Configure the following IKE policies on the Hub.

    • HUB_IKE_POL

    • SPOKE_1_IKE_POL

    • SPOKE_3_IKE_POL

  • Configure SPOKE-1 and SPOKE-2 to set the endpoints between the IPsec tunnels.

    IKE gateway—Configure the following IKE gateways on the Hub.

    A ppk-profile indicates which key-profile to use to establish quantum-safe IKE or IPsec SA.

    • HUB_IKE_GW

    • SPOKE_1_IKE_GW

    • SPOKE_2_IKE_GW

  • Configure SPOKE-1 and SPOKE-2 with the required algorithms to establish an IPsec SA.

    IPsec proposal—Configure the following IPsec proposals on the Hub.

    • HUB_IPSEC_PROP

    • SPOKE_1_IPSEC_PROP

    • SPOKE_2_IPSEC_PROP

  • Configure SPOKE-1 and SPOKE-2 to set the runtime IPsec negotiation attributes.

    IPsec policy—Configure the following IPsec policies on the Hub.

    • HUB_IPSEC_POL

    • SPOKE_1_IPSEC_POL

    • SPOKE_2_IPSEC_POL

  • Configure SPOKE-1 and SPOKE-2 to set the range of subnets that need to be secured.

    IPsec VPN—Configure the following IPsec VPNs on the Hub.

    • HUB_IPSEC_VPN

    • SPOKE_1_IPSEC_VPN

    • SPOKE_2_IPSEC_VPN

  • Security zone—Configure three different security zones to segregate the traffic.

    • trust

    • untrust

    • vpn

  • Security policy—Configure the security policies trust to vpn and vpn to trust to select the type of data traffic that is secured through the IPsec SAs.

PPK Profile

Indicate which key profile to use to establish quantum-safe IKE or IPsec SAs by referencing the key profile under the IKE gateway.

Certificates
CA certificate Verify identity of devices and authenticate communication link between them.
Local certificate Generate PKI and enroll it with the CA certificate for verification.
KME certificate Third-party certificate generated by vendor.
Security Zones
trust

Network segment at the host zone.

untrust

Network segment at the destination server zone.

vpn

Network segment through which the hub and spokes interact.

Primary verification tasks

Verify the established IKE and IPsec SAs are Quantum safe.

Topology Overview

In this example, we secure the hub-and-spoke IPsec VPN tunnels using quantum keys generated by third-party KME devices. The KME devices (KME-Hub, KME-Spoke 1, and KME-Spoke 2) are connected to each other through a quantum channel that is highly secure and capable of threat identification. Using this channel, the Hub and Spoke devices retrieve quantum keys from their corresponding KME device and merge it with the existing keys to make the VPN tunnels quantum secure.

Table 27: Quantum Key Manager Topology Components

Topology Components

Role

Function

Hub SRX Series Firewall capable of establishing IPsec tunnels Responds to IKE or IPsec SA negotiation and establishes Quantum-safe IPsec tunnels using QKD key from KME-HUB QKD device on SPOKE-1 and SPOKE-2.
SPOKE-1 SRX Series Firewall capable of establishing IPsec tunnels Initiates IKE or IPsec SA negotiation and establishes Quantum-safe IPsec tunnels with hub using QKD key from KME-SPOKE-1 QKD device.
SPOKE-2 SRX Series Firewall capable of establishing IPsec tunnels Initiates IKE or IPsec SA negotiation and establishes Quantum-safe IPsec tunnels with hub using QKD key from KME-SPOKE-2 QKD device.
HOST-1 Host inside the trusted zone or LAN side of SPOKE 1. Host 1 is secured by SPOKE 1. Initiates client-side traffic toward HOST-3
HOST-2 Host inside the trusted zone or LAN side of SPOKE 2. Host 2 is secured by SPOKE 2. Initiates client-side traffic toward HOST-3
HOST- 3 Host inside the trusted zone or LAN side of hub. Host 3 is secured by Hub. Responds to client-side traffic from HOST-1 and HOST-2
KME-HUB Third-party QKD device Provides QKD keys in response to key requests from HUB
KME-SPOKE-1 Third-party QKD device Provides QKD keys in response to key requests from SPOKE-1
KME-SPOKE-2 Third-party QKD device Provides QKD keys in response to key requests from SPOKE-2

Topology Illustration

Figure 7: Quantum Key Manager with AutoVPNQuantum Key Manager with AutoVPN

Step-By-Step Configuration on Hub

Note:

For complete sample configurations on the hub and spoke devices, see:

  1. Configure the hub interfaces.

  2. Configure hub-spoke the IPsec VPN. This includes configuring the security zones, security policies, and relevant certificates for authenticating device identities and their communication links.

    Configure the hub to fetch the CA certificate from the CA server, or load a locally available CA certificate from the device.

    Note:

    The KME certificates need to configured as per third-party vendor instructions.

    Configure the IPsec proposal and policy. Configure the IKE policy, proposal and gateway for the IPsec VPN.

  3. Configure the quantum key manager key profile to retrieve quantum keys from the corresponding KME-Hub device.

  4. Bind the quantum key manager key profile as the IKE gateway ppk-profile to make the VPN tunnels quantum-safe.

If you are done configuring the device, enter commit from configuration mode.

Step-By-Step Configuration on Spoke Devices

Note:

For complete sample configurations on the devices, see:

This configuration is applicable for Spoke 1 and Spoke 2 devices, you must make the appropriate device-specific configuration changes.

  1. Configure the spoke interfaces.

  2. Configure hub-spoke the IPsec VPN. This includes configuring the security zones, security policies, and relevant certificates for authenticating device identities and their communication links.

    Configure the hub to fetch the CA certificate from the CA server, or load a locally available CA certificate from the device.

    Note:

    The KME certificates need to configured as per third-party vendor instructions.

    Configure the IPsec proposal and policy. Configure the IKE policy, proposal and gateway for the IPsec VPN.

  3. Configure the quantum key manager key profile to retrieve quantum keys from the corresponding spoke device.

  4. Bind the quantum key manager key profile as the IKE gateway ppk-profile to make the VPN tunnels quantum-safe.

If you are done configuring the device, enter commit from configuration mode.

Verification

This section provides a list of show commands that you can use to verify the feature in this example.

Table 28: Verification Tasks
Command Verification Task

show security ike security-associations detail

Verify the IKE SAs.

show security ipsec security-associations detail

Verify the IPsec SAs.

show security ipsec statistics

Verify IPsec encryption and decryption statistics.

show security key-manager profiles detail

Verify key profile statistics.

ping 192.168.90.20 source 192.168.80.20 count 4

Ping from Host 1 to Host 3.

ping 192.168.90.20 source 192.168.70.20 count 4

Ping from Host 2 to Host 3.

Verify IKE SAs

Purpose

Verify the IKE SAs.

Action

From operational mode, enter the show security ike security-associations detail command to view the IKE SAs.

Meaning

The sample output confirms the IKE SAs.

Verify IPsec SAs

Purpose

Verify the IPsec SAs.

Action

From operational mode, enter the show security ipsec security-associations detail command to view the IPsec SAs.

Meaning

The sample output confirms the IPsec SAs.

Verify IPsec Statistics

Purpose

Verify the IPsec statistics.

Action

From operational mode, enter the show security ipsec statistics command to view the IPsec statistics.

Meaning

The sample output confirms the IPsec statistics.

Verify Key Manager Profile

Purpose

Verify the key manager profile.

Action

From operational mode, enter the show security key-manager profiles detail command and verify the Success field in the Request stats option.

Meaning

The sample output confirms the quantum key manager profile.

Ping from Host 1 to Host 3

Purpose

Verify the connectivity from Host 1 to Host 3.

Action

From operational mode, enter the ping 192.168.90.20 source 192.168.80.20 count 5 command to view the connectivity from Host 1 to Host 3.

Meaning

The sample output confirms the connectivity from Host 1 to Host 3.

Ping from Host 2 to Host 3

Purpose

Verify the connectivity from Host 2 to Host 3.

Action

From operational mode, enter the ping 192.168.90.20 source 192.168.80.20 count 5 command to view the connectivity from Host 2 to Host 3.

Meaning

The sample output confirms the connectivity from Host 2 to Host 3.

Appendix 1: Set Commands on all Devices

Set command output on all devices.

Set Commands on Hub
Set Commands on Spoke 1
Set Commands on Spoke 2

Appendix 2: Show Configuration Output on DUT

Show command output on the DUT.

Hub

From configuration mode, confirm your configuration by entering the show security pki ca-profile Root-CA, show security key-manager, show security ike proposal HUB_IKE_PROP, show security ike policy HUB_IKE_POL, show security ike gateway HUB_IKE_GW, show security ipsec proposal HUB_IPSEC_PROP, show security ipsec policy HUB_IPSEC_POL, show security ipsec vpn HUB_IPSEC_VPN, show security zones security-zone untrust, show security zones security-zone trust, show security policies from-zone trust to-zone vpn, show security policies from-zone vpn to-zone trust, and show interfaces commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Spoke 1

From configuration mode, confirm your configuration by entering the show security pki ca-profile Root-CA, show security key-manager profiles SPOKE_1_KM_PROFILE_1, show security ike proposal SPOKE_1_IKE_PROP, show security ike policy SPOKE_1_IKE_POL, show security ike gateway SPOKE_1_IKE_GW, show security ipsec proposal SPOKE_1_IPSEC_PROP, show security ipsec policy SPOKE_1_IPSEC_POL, show security ipsec vpn SPOKE_1_IPSEC_VPN, show interfaces, show security zones security-zone untrust, show security zones security-zone trust, show security policies from-zone trust to-zone vpn, and show security policies from-zone vpn to-zone trust commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Spoke 2

From configuration mode, confirm your configuration by entering the show security pki ca-profile Root-CA, show security key-manager profiles SPOKE_1_KM_PROFILE_1, show security ike proposal SPOKE_1_IKE_PROP, show security ike policy SPOKE_1_IKE_POL, show security ike gateway SPOKE_1_IKE_GW, show security ipsec proposal SPOKE_1_IPSEC_PROP, show security ipsec policy SPOKE_1_IPSEC_POL, show security ipsec vpn SPOKE_1_IPSEC_VPN, show interfaces, show security zones security-zone untrust, show security zones security-zone trust, show security policies from-zone trust to-zone vpn, and show security policies from-zone vpn to-zone trust commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.