Initial Considerations about QDKN Protocols

Status of This Memo

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 24 April 2025.¶

Copyright Notice

Copyright (c) 2024 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.¶

Table of Contents

1. Introduction

Quantum communication modules connected via a link, either via fiber or free-space communications, have been used since a while [darpa-qkd] to distribute random numbers as secure keys, but there also other use cases, such as time synchronization.¶

By today, a number of research and industrial efforts are underway to built complete networks, primary for secure key distribution, i.e., so-called Quantum Key Distribution Networks (QKDN) (see [qkd-overview] as one overview).¶

Quantum Links (QL) are quite limited in their distance between two adjacent Quantum Communication Modules (QCM), e.g., around 100 km distance or even below. To overcome this limitation, multiple segments of Quantum Links are concatenated. This concatenation typically requires an extra level of functionality, i.e., the use of Key Management Systems (KMS).¶

This memo briefly explores the space of QKDNs and identifies spots of potentials interest to develop standardized protocols specific for such networks.¶

2. Simplified Architecture

The ITU defines an extensive QKDN architecture in Y.3802 [itu-y-3802]. However, for our discussion we use a simplified architecture here.¶

The Figure below shows a simplified architecture for a single QKDN domain.¶

The Quantum Communication Modules (QCM) are in charge of exchanging random numbers between 2 QCM, or n modules for single-source entangled based systems.¶

The Key Management Systems (KMS) are in charge of allowing a secure end-to-end relay of a secret across the whole domain. They obtain the encryption keys, or some initial input to the encryption key, from their local KMS.¶

The Network Controller (NW cntrl) can be used to control and managed the operations of the KMS and also the QCM.¶

          (d)    +-------------+    (d)
      +----------|  NW cntrl   |----------+
      |          +-------------+          |
      |                 | (d)             |
      v                 v                 v
   +-----+  (a)  +-------------+  (a)  +-----+
   | KMS |<----->|     KMS     |<----->| KMS |
   +-----+       +-------------+       +-----+
      ^             ^       ^             ^
      | (b)         |  (b)  |             | (b)
      v             v       v             v
   +-----+  (c)  +-----+ +-----+  (c)  +-----+
   | QCM |<----->| QCM | | QCM |<----->| QCM |
   +-----+       +-----+ +-----+       +-----+

The interfaces between the components are:¶

• (a) KMS-to-KMS interface: this interface is used to facilitate the secure key forwarding between the KMS¶

• (b) KMS-to-QCM interface: this interface is used by the KMS to obtain the generated random numbers from the QCM¶

• (c) QCM-to-QCM interface: this interface is used between adjacent Quantum Communication Modules and consists actually out of two interfaces, i.e., the quantum link and the classical channel.¶

• (d) Network Controller to KMS interface: This interface, if a controller-based approach is used, controls the operation of the KMS.¶

3. Conclusion

This document does not yet have a conclusion, at it is a first attempt to gather information about protocols for QDKNS.¶

4. IANA Considerations

This document has no IANA actions.¶

5. Security Considerations

This document has no security considerations yet, but since the whole sense of a QDKN is to securely, i.e., secured against eavesdropping, tampering, and replay attacks, forward a key from end-to-end, security is a matter per se. Future revisions of this memo will discuss the security considerations.¶

Acknowledgements

Malte Bauch, Neil Schark and Fabian Seidl are funded by the German BMBF DemoQuanDT project. Martin Stiemerling is partially funded by the German BMBF DemoQuanDT project.¶

Authors' Addresses