Postquantum preshared keys
If the preshared keys contain sufficient entropy, session keys derived from them are resistant to quantum attacks. As a result, the system is secure against both modern classical attackers and future quantum attackers.
RFC 8784 (Mixing Preshared Keys in IKEv2 for Postquantum Security) specifies how IKEv2 can use PPKs for quantum resistance, enabling PPK negotiation, PPK ID transmission, integration into session key derivation, and fallback to sessions not using PPKs.
Dynamic postquantum preshared keys
Cisco Secure Key Integration Protocol
A Cisco Secure Key Integration Protocol is a security protocol that
-
uses HTTPS as a transport to securely import preshared keys (PPKs) into Cisco encryption devices,
-
acts as a client on encryption devices and a server on external key sources to enable automated and coordinated key provisioning, and
-
provides reliable out-of-band synchronization, ensuring both initiator and responder devices receive identical key material.
Externally imported PPKs via SKIP are called dynamic PPKs. For successful integration, encryption devices must implement the SKIP client, and external sources (such as Quantum Key Distribution [QKD] devices or Cisco Session Key Service [SKS] servers) must implement the SKIP server.
SKIP compliance requirements
To be SKIP-compliant, an external key source must:
-
implement the SKIP protocol or API as specified in the Cisco SKIP specification,
-
provide the same preshared key (PPK) to both the initiator and responder devices using a reliable out-of-band synchronization mechanism,
-
contact Cisco for technical guidance during implementation, especially for vendors supplying Quantum Key Distribution (QKD) or third-party solutions.
Workflow for dynamic postquantum preshared keys
Summary
The key components involved in the process are:
-
IKEv2 initiator: Requests and uses PPKs, communicating with the peer during session establishment.
-
IKEv2 responder: Uses synchronized PPKs to ensure secure and matching session derivation.
-
External key sources (SKIP server): Provide PPKs to devices and synchronize key material out-of-band.
-
SKIP client: Runs on encryption devices to interact securely with the key source.
Workflow
Thiw figure shows quantum-safe IKEv2 and OTNsec session keys using dynamic PPK.
The process involves the following stages:
- The IKEv2 initiator requests a preshared key (PPK) from its configured external key source using SKIP. The key source replies with a PPK and associated PPK ID.
- The initiator’s key source synchronizes the PPK to the responder’s key source out-of-band, based on the type of key source. Simultaneously, the initiator communicates the PPK ID to the responder via IKEv2 using RFC 8784 extensions.
- The responder requests the correct PPK from its own key source using the received PPK ID and obtains the matching PPK.
- Both initiator and responder mix the PPK into the key derivation process as specified in RFC 8784, generating quantum-safe IKEv2 and OTNsec session keys.
Result
The process ensures that both participating devices use a synchronized cryptographic key with enhanced entropy, enabling secure, quantum-resistant session establishment.
Configuring Dynamic PPK using SKS SKIP
Use the following commands to configure the dynamic PPK for one or more peers or groups of peers, in the IKEv2 keyring.
configure terminal
keyring dynamic
peer name
ppk dynamic sks-profile-name [required]
pre-shared-key key-string
address {ipv4-address mask}
ikev2 profile name
match identity remote address {ipv4-address mask}
keyring ppk keyring-name
keyring keyring-name
sks profile profile-name type remote
kme server ipv4 ip-address port port-number
exit
exit
Example :
RP/0/RP0/CPU0:ios#configure terminal
RP/0/RP0/CPU0:ios(config)#keyring dynamic
RP/0/RP0/CPU0:ios(config-ikev2-keyring)#peer peer1
RP/0/RP0/CPU0:ios(config-ikev2-keyring-peer)#ppk dynamic qkd required
RP/0/RP0/CPU0:ios(config-ikev2-keyring-peer)#pre-shared-key cisco123!cisco123
RP/0/RP0/CPU0:ios(config-ikev2-keyring-peer)#address 10.0.0.1 255.0.0.0
RP/0/1/CPU0:ios(config)#ikev2 profile test
RP/0/1/CPU0:ios(config-ikev2-profile-test)#keyring dynamic
RP/0/1/CPU0:ios(config-ikev2-profile-test)#keyring ppk dynamic
RP/0/1/CPU0:ios(config-ikev2-profile-name)#match address 10.0.0.1 255.255.255.0
RP/0/1/CPU0:ios(config)#sks profile qkd type remote
RP/0/1/CPU0:ios(config-sks-profile)#kme server ipv4 192.0.2.34 port 10001
RP/0/RP0/CPU0:ios(config-ikev2-keyring-peer)#exit
RP/0/RP0/CPU0:ios(config)#exitManual postquantum preshared keys
This figure illustrates that the session keys of quantum-safe IKEv2 and OTNsec are obtained through a manual PPK:
Configure a manual PPK in an IKEv2 keyring
Define a manual PPK for one or more IKEv2 peers or peer groups to enhance VPN authentication security.
Manually configuring PPKs in IKEv2 keyrings allows for more flexible peer authentication in secure VPN deployments. From Release 24.3.1, Type 6 passwords are supported for preshared keys, providing enhanced protection. See Enable Type 6 password.
Follow these steps to configure a manual PPK in an IKEv2 keyring:
Procedure
|
Step 1 |
Access global configuration mode and create or enter an IKEv2 keyring using the keyring keyring-name command. Example: |
|
Step 2 |
Define the peer and configure the manual PPK and preshared key using the keywords peer name password [required]. Example: |
|
Step 3 |
Define the pre-shred-key and peer adress using the keywords pre-shared-key key-string address {ipv4-address mask } Example: |
|
Step 4 |
Exit to global configuration mode. Example: |
|
Step 5 |
Create or modify the IKEv2 profile, associating the keyring and matching remote peer identity using the keywords ikev2 profile namematch identity remote address {ipv4-address mask}keyring ppk keyring-name keyring keyring-name |
|
Step 6 |
Exit to global configuration mode. Example: |
Feedback