| Internet-Draft | Multi-Path Secret Sharing for QKD Key Re | February 2026 |
| Li & Li | Expires 31 August 2026 | [Page] |
Trusted relay is currently the most practical deployment model for Quantum Key Distribution (QKD) networks. However, trusted relay nodes pose inherent security vulnerabilities, as intermediate nodes can access the plaintext random number used to derive the end-to-end QKD key, leading to complete key exposure if any single relay node is compromised. To mitigate this risk, this document proposes a Multi-Path Secret Sharing (MPSS) mechanism for QKD key relay. The core idea is to split the random number into multiple shares using a threshold secret sharing scheme, distribute each share through independent QKD relay paths planned by the Key Management Plane (KMP), and reconstruct the complete random number only at the destination node. This mechanism transforms the security model from "all-or-nothing" to "threshold security". Notably, this mechanism leverages an extended IPv6 Destination Option Header (DOH) to carry key share-related metadata and utilizes Segment Routing over IPv6 (SRv6) to enforce strict path isolation.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 31 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The integration of Quantum Key Distribution (QKD) with classical IP networks, specifically for securing IPsec tunnels, is an active area of standardization within the IETF.¶
However, a critical challenge remains in large-scale QKD networks: the reliance on Trusted Relay Nodes. In current deployments, if a QKD link exceeds the physical distance limit, keys are decrypted, stored, and re-encrypted at intermediate nodes. If any single trusted node is compromised (physically or logically), the end-to-end secrecy of the key is completely broken. Taking an operational "QKD trunk line" as an example, 32 trusted relay nodes are distributed along a 2,000-kilometer path, and an attacker only needs to breach one node to undermine the end-to-end security of QKD.¶
This document proposes a Multi-Path Secret Sharing (MPSS) scheme to address this vulnerability. Instead of transmitting the raw key through a single path of trusted nodes, the scheme adopts a (t, n)-threshold secret sharing mechanism, splits the key material into n shares, and utilizes the physical isolation capability of network forwarding paths provided by Segment Routing over IPv6 (SRv6) [RFC8754] to transmit the shares simultaneously over n physically disjoint paths. The original key can only be reconstructed if the receiver successfully obtains at least t shares, ensuring that even if fewer than t nodes are compromised, the attacker cannot obtain any valid information about the key.¶
This mechanism can serve as a security enhancement layer for the QKD-IPsec integration architecture, effectively defending against insider threats and node compromise risks in the relay network. The scheme is designed to be compatible with the key management interfaces defined in [I-D.nagayama-ipsecme-ipsec-with-qkd] and supports various secret sharing algorithms.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997) and [RFC8174] (Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017).¶
QKD: Quantum Key Distribution.¶
Trusted Node (TN): An intermediate node in a QKD network that temporarily holds the key material in plaintext during the relay process.¶
Threshold Secret Sharing Scheme (SSS): A cryptographic method for distributing a secret among a group of participants, where the secret can only be reconstructed when a specific threshold number of shares are combined. Examples include Shamir's Secret Sharing and Blakley's scheme.¶
(t, n)-Threshold Scheme: A scheme where the secret can be reconstructed only if at least $t$ out of $n$ shares are combined.¶
SRv6: Segment Routing over IPv6.¶
KMP: Key Management Plane, the logical entity responsible for coordinating QKD key generation, distribution, path calculation, and SRv6 policy enforcement.¶
Disjoint Paths: Network paths that do not share any common intermediate nodes (node-disjoint) or links (link-disjoint).¶
QKD-DOH: A proposed IPv6 Destination Option Header extension for carrying QKD share metadata.¶
In traditional QKD relay networks, the security model assumes that all intermediate nodes are fully trusted. The key flow is typically: Alice --(QKD)--> TN_1 --(Classical)--> TN_2 --(...)--> Bob¶
If an attacker compromises TN_i, they can access the plaintext key material being relayed. As the network scales, the probability of at least one node being compromised increases, creating a significant bottleneck for high-security applications.¶
To ensure that the compromise of intermediate nodes does not lead to key leakage, the n shares shall be forwarded through disjoint paths as much as possible. This document leveragesSRv6 to explicitly encode these paths in the packet header.¶
The source node constructs n IPv6 packets, each carrying one share S_i, and encapsulates information such as the sharing algorithm and share sequence number into the DOH header. Each share S_i is mapped to a different SRv6 Policy through the information in the DOH header. By utilizing the SRv6 Policy mechanism, the source can ensure:¶
The destination node collects the incoming shares. Once t valid shares are received, the KMP reconstructs the original seed R using the corresponding inverse algorithm. The reconstructed seed is then processed to generate the final key, which is used for IPsec/IKEv2 as defined in [RFC8784] and [I-D.nagayama-ipsecme-ipsec-with-qkd].¶
To carry necessary metadata without modifying the upper-layer protocol, this document defines a new IPv6 Destination Option, which is used to map SRv6 Policies and enable the receiver to identify the sharing algorithm and parameters required for reconstruction.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Option Type |Option Data Len| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm ID | Total Shares | Threshold | Share Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type: To be assigned by IANA (TBD)¶
Option Data Format:¶
Key ID (4 bytes): Identifies the QKD session¶
Share Index (1 byte): Indicates which share (1…n) this packet carries¶
Total Shares (1 byte): Value n¶
Threshold (1 byte): Value t¶
Algorithm ID (1 byte): Identifies the secret sharing algorithm used (e.g., 0x01 for Shamir, 0x02 for Blakley, etc.), ensuring extensibility¶
This option is primarily processed by the source node and the destination node.¶
The MPSS mechanism is transparent to the IPsec stack. The KMP interacts with the following modules:¶
QKD Quantum Layer: To fetch raw key seeds¶
SDN Controller/PCE: To compute n disjoint paths and generate SIDs¶
Application Layer (IPsec/IKE Daemon): To deliver the reconstructed key for use as a PPK, in accordance with [RFC8784]¶
The KMP is responsible for synchronizing the state of share transmission, negotiating the Algorithm ID during session setup, and triggering retransmission if fewer than t shares arrive within a timeout window.¶
The random number R is transmitted through a single path, and any compromised intermediate node can obtain the plaintext R, leading to the complete exposure of Key_AB. The security risk is 1/N_node (N_node is the number of intermediate nodes in the path), and the attack success rate is 100% for a single node compromise.¶
R is split into N shares through (k, N) threshold secret sharing, and each share is transmitted through a completely non-overlapping path. An attacker needs to compromise at least k paths (i.e., at least one node in each of k paths) to obtain k valid shares and reconstruct R. The security improvement is reflected in two aspects:¶
Threshold Security: The attack threshold is raised from "compromise 1 node" to "compromise k paths (at least k nodes)". For (2,3) configuration, the attacker needs to compromise at least 2 non-overlapping paths (2 nodes) to reconstruct R, and the attack success rate is significantly reduced.¶
Isolation of Shares: Since the paths are completely non-overlapping, compromising a single node only exposes a single share, and the attacker cannot obtain any information about R from a single share (due to the perfect secrecy of the threshold secret sharing algorithm).¶
Assume that the probability of a single QKD node being compromised is P, and the MPSS mechanism uses (k, N) threshold sharing with completely non-overlapping paths (each path has m intermediate nodes). The probability of the attacker successfully reconstructing R is:¶
P_{MPSS} = C_N^k * (P^m)^k¶
For the traditional single-path model (1 path, m nodes), the probability of successful attack is:¶
P_{Traditional} = 1 - (1-P)^m¶
Example: If P=0.01 (1% compromise probability per node), m=3 (3 intermediate nodes per path), (k=2, N=3) for MPSS:¶
The attack success probability of MPSS is reduced by 9 orders of magnitude compared with the traditional model, which significantly improves security.¶
This document requests IANA to assign: 1. A new IPv6 Destination Option type under the "IPv6 Extension Header Types" registry for the QKD‑DOH defined in Section 5.1. 2. A new "QKD Secret Sharing Algorithm IDs" registry to manage the Algorithm ID field, initially populated with: - 0x01: Shamir's Secret Sharing - 0x02: Blakley's Scheme - 0x03‑0xFF: Unassigned / Experimental # Security Considerations TBD.¶
The authors would like to thank the following for their valuable contributions of this document: TBD¶