IP Security Maintenance and Extensions (ipsecme) S. Nagayama Internet-Draft R. Van Meter Intended status: Experimental Keio University Expires: April 30, 2015 October 27, 2014 IKE for IPsec with QKD draft-nagayama-ipsecme-ipsec-with-qkd-01.txt Abstract Quantum Key Distribution (QKD) is a mechanism for creating shared, secret, random bits. This document describes extensions to the IKEv2 protocol to use random bits created via QKD as keys for IPsec. The Diffie-Hellman key agreement mechanism is replaced with QKD. The use of QKD-generated keys with standard IPsec will extend the lifetime of privacy guarantees for IPsec-protected data: future technological advances that break Diffie-Hellman key exchange will not disclose data until such time as the encryption algorithm used for the IPsec tunnel is broken. 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 http://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 April 30, 2015. Copyright Notice Copyright (c) 2014 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 (http://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 Nagayama & Van Meter Expires April 30, 2015 [Page 1] Internet-Draft IKE for IPsec with QKD October 2014 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Architecture and Assumptions . . . . . . . . . . . . . . . . 4 3. Data Formats and Information Exchange Sequences . . . . . . . 5 3.1. Data Formats . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. QKD KeyID Payload . . . . . . . . . . . . . . . . . . 5 3.1.2. QKD Fallback Payload . . . . . . . . . . . . . . . . 6 3.1.3. Transform Field for QKD in SA Payload . . . . . . . . 8 3.2. Sequence . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Initializing IKE_SA . . . . . . . . . . . . . . . . . 9 3.2.2. Rekeying IKE_SA . . . . . . . . . . . . . . . . . . . 11 3.3. Considerations for Multiple SAs . . . . . . . . . . . . . 14 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 14 5. Recommendations for use of QKD-generated keys . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7.1. Transform Type Values . . . . . . . . . . . . . . . . . . 16 7.2. Payload Type Values . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Implementation Considerations and Current Status . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Nagayama & Van Meter Expires April 30, 2015 [Page 2] Internet-Draft IKE for IPsec with QKD October 2014 Quantum key distribution (QKD) [BB84] creates shared, secret, random bits using quantum effects to guarantee that the probability of an undetected eavesdropper learning the secret bits is vanishingly small. Thus, the secret bits are a good source of cryptographic keying material. In the terminology proposed by the SECOQC Project[SECOQC07], a QKD network includes a "secrets plane" which delivers secret key material to other subsystems. QKD requires an optical path without amplification, and a bidirectional classical connection with authentication. IPsec is a standardized protocol suite for encrypted communication [RFC4301]. IPsec can be configured to use one of a number of algorithms for encryption and authentication to keep data secret and to guarantee the integrity. The bulk data encryption portion of IPsec requires the use of a secret key shared only between the pair of IPsec gateways. Internet Key Exchange (IKE) [RFC5996] provides several important functions: creation of the shared secret key, management of the use of that key, and negotiation of the details of the bulk data encryption method and conditions under which it is applied. Standard IKE negotiates parameters for distributed Diffie- Hellman calculation of the secret key, then executes that calculation. The security of D-H is predicated upon the difficulty of the integer factorization problem. Future development of large- scale quantum computers or advances in classical factoring algorithms may render the Diffie-Hellman-negotatied key vulnerable, even years after the actual network exchange, if the IKE packet exchanges have been recorded. Thus, the secrecy of the key itself and therefore of data communicated using IPsec should be considered secure only up to the advent of certain technological advances. Methods of key negotiation not dependent upon the difficulty of factoring therefore are desirable, and QKD is one such possibility. Commercial QKD devices available as of the writing of this document do not use a documented, standardized variant of IPsec and IKE. Publication of this I-D as an RFC will advance interoperability among different vendors when combined with the standardization of the physical implementations of QKD now under development in ETSI. As of the writing of this document, commercial QKD systems operate over dedicated optical fiber without amplifiers. Experimental QKD systems allow wavelength multiplexing of the QKD signals with classical information, and have also been demonstrated through free space and proposed to operate via satellite link. One key application of the quantum repeater systems being actively researched worldwide is to support long-distance QKD. Nagayama & Van Meter Expires April 30, 2015 [Page 3] Internet-Draft IKE for IPsec with QKD October 2014 2. Architecture and Assumptions This document describes modifications to IKEv2 to use keys created via QKD for the Internet Key Exchange IKE_SA[RFC5996], the key agreement protocol for IPsec[RFC4301] . With the exception of the use of the new payloads defined below and the removal of the Diffie- Hellman key agreement information, IKEv2 operates in standard fashion. The system design is shown in Figure 1. Each side has an IPsec Gateway and a QKD Device. The IPsec Gateways are connected via an IP network and the QKD Devices are connected through the QKD network. The IP network and QKD network MAY share all, some, or none of the physical links comprising their networks, e.g. via wavelength multiplexing. Either end MAY initiate the QKD connection. System Design Initiator Responder +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ ! IPsec Gateway !--------! IP network !-----------! IPsec Gateway ! +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | |local connection |local | |connection +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ ! QKD Device !---------! QKD Network !------------! QKD Device ! +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Figure 1 The connection between the IPsec Gateway and the QKD device, marked "local connection" MUST be secret, authenticated, and reliable. This MAY be achieved by incorporating both the IPsec Gateway and QKD device into a single system. The QKD device SHALL provide secret, shared, random bits to the IPsec gateway. The bits MUST be shared with an authenticated partner only. The key material SHALL be managed in such a manner that the IPsec gateways can independently map a Key ID to matching key material. Beyond this, the interface between the IPsec Gateway and QKD device is beyond the scope of this document. The technical details of the operation of the QKD network (including device physics, data filtering, node addressing, authentication, synchronization, etc.) are beyond the scope of this document. The QKD channel operates independently from the IP network that connects the IPsec gateways. QKD requires an authenticated classical channel Nagayama & Van Meter Expires April 30, 2015 [Page 4] Internet-Draft IKE for IPsec with QKD October 2014 which is not part of the IPsec connection; this channel can be unencrypted. The key name (Key ID) is chosen by the QKD subsystem. It is the QKD subsystem's responsibility to ensure that key names are unambiguous, e.g. that key names are not reused within a time frame that can cause confusion. 3. Data Formats and Information Exchange Sequences IKE must exchange two parameters to use QKD: an identifier indicating which QKD-generated key is to be used (KeyID) and the choice of fallback methods. One Key ID represents one unit of shared random bits, large enough for use as bulk data encryption key. Fallback methods are used when the QKD system key generation underruns. Additionally, the system should be able to choose the key exchange algorithm from an approved list including e.g. QKD, Diffie-Hellman key exchange and password-authenticated key [RFC5683]. 3.1. Data Formats There are three added data formats: QKD KeyID Payload, QKD Fallback Payload and Transform Field for QKD in the SA Payload. 3.1.1. QKD KeyID Payload Figure 2 defines the payload for the QKD KeyID. QKD KeyID Payload 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 Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! version !F! flags ! QKD Device ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Key ID Length ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! Key ID (variable length) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 The Next Payload field of the previous header MUST be set to the QKD KeyID Payload number (see Section 7). The first 32 bits of the payload are the Generic Payload Header. To avoid a man-in-the-middle attack downgrading the negotiated security level, the Critical bit must be set to 1. The responder MUST reply with an error message when it it is incapable of using QKD (see Section 4). Nagayama & Van Meter Expires April 30, 2015 [Page 5] Internet-Draft IKE for IPsec with QKD October 2014 o Version (one octet) specifies the format and semantics of this message. The current version is 1. o The "F" field contains the Running Mode configuration. IPsec with QKD has two modes, normal and fallback. Table 1 shows the modes and mode values. This field MUST be 0 for initiating IPsec. o Flags holds flag bits; this field MUST be zero. o QKD Device ID contains an ID number for the QKD device. Each IPsec Gateway may be equipped with more than one QKD device. This field carries an ID number to determine which QKD device should be used. The Device ID plus the Key ID MUST uniquely identify the key. o Key ID Length defines the length of Key ID field. o Key ID (variable length) is used to communicate which key to use for the encryption. Runnning mode values for the "F" field +------------------+------------+ | Running Mode | Mode Value | +------------------+------------+ | normal running | 0 | | | | | fallback running | 1 | +------------------+------------+ Table 1 3.1.2. QKD Fallback Payload The Next Payload field of the previous header MUST be set to the QKD Fallback Payload number (see Section 7). The first 32 bits of the payload are the Generic Payload Header. Nagayama & Van Meter Expires April 30, 2015 [Page 6] Internet-Draft IKE for IPsec with QKD October 2014 QKD Fallback Payload 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 Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! version ! FLAGS ! Fallback ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 o Version (one octet) specifies the format and semantics of this message. The current version is 1. o Flags holds flag bits; this field MUST be zero. o The Fallback field contains the configuration of fallback methods. There are three fallback methods, listed in Table 2. Fallback methods +-----------------+--------------+ | Fallback method | Method Value | +-----------------+--------------+ | WAIT_QKD | 1 | | | | | DIFFIE-HELLMAN | 2 | | | | | CONTINUE | 3 | +-----------------+--------------+ Table 2 The Fallback methods are as follows: WAIT_QKD indicating that IKE MUST wait for the QKD device to deliver a new key. When the IPsec tunnel key lifetime expires and no new QKD-generated key is available, the system MUST stop encrypting packets and forwarding them across the network; the tunnel should be considered to be down. CONTINUE indicating that IPsec MAY continue to use the most recent key until a new key becomes available. DIFFIE-HELLMAN indicating that IKE SHALL generate a new key in the existing IKE_SA using Diffie-Hellman. Nagayama & Van Meter Expires April 30, 2015 [Page 7] Internet-Draft IKE for IPsec with QKD October 2014 The Fallback Payload is encrypted, relying on the security of the IKE_SA, which is guaranteed by QKD. 3.1.3. Transform Field for QKD in SA Payload Figure 4 defines the Transform Field for QKD included in the SA Payload. Transform Field for QKD 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0(last) or 3 ! RESERVED ! 8 (Transform Length) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !(TransformType)! RESERVED ! 0 or 1 (Transform ID) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 The SA Payload carries proposals for all parameters, including the method for generating keys, in the Transform Fields. QKD must be proposed here like other key sharing algorithms. o Transform Length must be fixed at 8 since QKD does not need the Transform Attributes field. o Transform Type field MUST be set to the number for QKD (see Section 7) o Transform ID field contains the method for using QKD. Table 3 shows the modes and the values. Direct use means using QKD- generated key as encrypt key. In password-authenticated key mode, the QKD-generated key is used for D-H. See [RFC5683] for details. The use modes of QKD and values for Transform ID field +----------------------------+------------+ | Use Mode | Mode Value | +----------------------------+------------+ | Direct use | 0 | | | | | Password-authenticated key | 1 | +----------------------------+------------+ Table 3 Nagayama & Van Meter Expires April 30, 2015 [Page 8] Internet-Draft IKE for IPsec with QKD October 2014 3.2. Sequence To use QKD-generated keys, the Initiator and Responder must agree on a Key ID to use. This key will be used to encrypt the IKE_AUTH exchange, and does not change the IKE Sequence. Other parameters, defining the Fallback method, must be exchanged in IKE_AUTH, in the encrypted connection. Standard IKEv2 exchanges key data for Diffie-Hellman in IKE_SA_INIT in a synchronous fashion. The principle difficulty in using QKD- generated secret bits as keys for IPsec tunnels is coordinating the activity of the QKD secrets plane with IKE, because the QKD device must operate continuously and independently to monitor its path and create secret bits, as discussed in Appendix A. 3.2.1. Initializing IKE_SA When the initiator wishes to use QKD-generated keys, it MUST wait until the QKD device delivers one or more valid keys, shared with the responder, before sending the IKE_SA_INIT message. The initiator chooses a key and sends a proposal including the SA Payload including the Transform Field for QKD and the KeyID Payload in IKE_SA_INIT. The responder replies with an SA Payload as described in [RFC5996] section 3.3 and echos the Key ID. QKD fallback methods are exchanged in IKE_AUTH. The manner of choosing fallback methods follows IKE's algorithm to share configuration in [RFC5996] Section 2.7."Cryptographic Algorithm Negotiation". The key negotation process is described below. Payload names in this document are to be interpreted as described in [RFC5996]. The IKE_SA_INIT with QKD Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni KeyID --> HDR is the IKE Header. SAi1 is a payload which states the parameters and the cryptographic algorithms the initiator supports for the IKE_SA, including the Transform Field for QKD. KeyID is the QKD KeyID Payload described in Section 3.1.1. The NoKey bit MUST be 0 in IKE_SA_INIT. The KEi and Ni Payloads that are cantained in standard IKEv2 MUST be omitted because they are for Diffie-Hellman, and are not used with QKD. <-- HDR, SAr1, KEr, Nr, KeyID Nagayama & Van Meter Expires April 30, 2015 [Page 9] Internet-Draft IKE for IPsec with QKD October 2014 Responder echos Key ID in its KeyID Payload. The IKE_AUTH with QKD exchange Initiator Responder ----------- ----------- HDR, SK{IDi, [CERT,] [CERTREQ,] [IDr,] QKDfallback, AUTH, SAi2, TSi, TSr} --> The notation SK{...} means that payloads between {} are encrypted by the SA whose key is chosen in IKE_SA_INIT. QKDfallback Payload is the QKD Fallback Payload, containing the initiator's proposed fallback method. IDi, AUTH, SAi2, TSi, TSr are payloads which state the initiator's identification, authentication and CHILD_SA's parameters and traffic selectors of initiator and responder. <-- HDR, SK{IDr, [CERT,] QKDfallback AUTH, SAr2, TSi, TSr} Responder replies with its acceptance of fallback methods in its QKD fallback Payload. If the Responder does not agree with the Initiator's requested fallback method, it MUST respond with an error message and abort the IKE negotiation, as discussed in Section 4. Nagayama & Van Meter Expires April 30, 2015 [Page 10] Internet-Draft IKE for IPsec with QKD October 2014 Exchanges in initializing IKE_SA Initiator Responder | IKE_SA_INIT | |----------------------------------------->| | Transform Field for QKD: Transform ID=0 | | KeyID: Critical=1, Key ID=foo | | | | | | IKE_SA_INIT | |<-----------------------------------------| | Transform Field for QKD: Transform ID=0 | | KeyID: Critical=1, Key ID=foo | | | | | | IKE_AUTH | |----------------------------------------->| | Fallback: Critical=1, | | Fallback=[WAIT|DH|CONTINUE] | | | | | | IKE_AUTH | |<-----------------------------------------| | Fallback: Critical=1, | | Fallback=[WAIT|DH|CONTINUE] | | | | | Figure 5 During initialization, IKE_SA cannot use a fallback method. The key must be generated by QKD. Thus, the Critical bit is set to 1. If the system underruns in key generation, it MUST wait for the QKD device to generate a new key. 3.2.2. Rekeying IKE_SA In IKE two ways are defined to rekey an IKE_SA: repeating the original initiation sequence by exchanging IKE_SA_INIT and IKE_AUTH, and using the CREATE_CHILD_SA exchange. Because IKE_SA_INIT is exchanged without encryption, if the Initiator wishes to specify fallback behavior, it MUST create a child SA, rather than re- initialize. Nagayama & Van Meter Expires April 30, 2015 [Page 11] Internet-Draft IKE for IPsec with QKD October 2014 The CREATE_CHILD_SA with QKD Exchange Initiator Responder ------------ ----------- HDR, SK{[N], SA, Ni, KeyID, [KEi,] [TSi, TSr]} --> Figure 6 The initiator sends CREATE_CHILD_SA including an IKE header, optionally a notify, a new security association including the transform field for QKD, a nonce, Key ID for QKD, optionally a key exchange for Diffie-Hellman and optionally traffic selectors. <-- HDR, SK{SA, Nr, KeyID, [KEr,] [TSi, TSr]} The Responder sends CREATE_CHILD_SA which includes an IKE header, a new security association, a nonce, Key ID for QKD, optionally a key exchange for Diffie-Hellman and optionally traffic selectors. The system SHOULD use QKD to rekey IKE_SA when possible. When the initiator rekeys using a new QKD-generated key, the KeyID Payload from the initiator carries the new Key ID and the transform ID in the Transform Field for QKD in the SA Payload is set to 0. Responder repeats the same Key ID in the KeyID Payload and replies SA Payload as described in [RFC5996] Section 3.3.6. The Critical bits are ignored in this case. Both KEi and KEr MUST be omitted. Nagayama & Van Meter Expires April 30, 2015 [Page 12] Internet-Draft IKE for IPsec with QKD October 2014 Normal Message Sequence in CREATE_CHILD_SA for rekeying IKE_SA Initiator Responder | CREATE_CHILD_SA | |----------------------------------------->| | Transform Field for QKD: Transform ID=0 | | KeyID: Critical=1, Key ID=bar | | | | | | CREATE_CHILD_SA | |<-----------------------------------------| | Transform Field for QKD: Transform ID=0 | | KeyID: Critical=1, Key ID=bar | | | | | Figure 7 When the SA lifetime nears expiration and it becomes necessary to rekey, if no QKD-generated key is available the Initiator SHALL rekey using the specified fallback method, if one was specified. The initiator SHALL send the transform ID in the Transform Field for QKD in the SA Payload set to 1 and Key ID field of KeyID Payload set to null to keep the packet as long as the one of normal running. The Responder SHALL reply with null Key ID field. It replies with an SA Payload obeying [RFC5996] section 3.3. If Diffie-Hellman is permitted as a fallback method and the Perfect Forward Security(PFS) is configured to work, CREATE_CHILD_SA carries KEi and KEr. Nagayama & Van Meter Expires April 30, 2015 [Page 13] Internet-Draft IKE for IPsec with QKD October 2014 Fallback Exchanges in CREATE_CHILD_SA for rekeying IKE_SA Initiator Responder | CREATE_CHILD_SA | |----------------------------------------->| | Transform Field for QKD: Transform ID=1 | | KeyID: NULL | | | | | | CREATE_CHILD_SA | |<-----------------------------------------| | Transform Field for QKD: Transform ID=1 | | KeyID: NULL | | | | | Figure 8 3.3. Considerations for Multiple SAs IPsec can have multiple SAs between two IPsec gateways. QKD provides node-to-node keys, thus the system described in this document can also manage multiple SAs. The Initiator is free to use any QKD- generated keys for any SAs, but MUST NOT reuse any key. 4. Error Handling Error handling beyond that already described in this document is TBD. 5. Recommendations for use of QKD-generated keys From a data privacy point of view, the ideal use of QKD-generated keys would be as a one-time pad (OTP) to protect the data carried in the IPsec tunnel. However, as of 2014, QKD key generation rates are not adequate for high-speed OTP use; the QKD-generated keys instead will be used most commonly as key material for symmetric encryption of the IPsec tunnel. Thus, the upper bound on the secret lifetime of data remains the time until the chosen symmetric cipher can be broken. An eavesdropper who records encrypted packets today can store those packets, and decrypt them later by directly attacking the symmetric cipher, when it becomes technically feasible to do so. However, existing IPsec/IKE implementations actually have a lower data secrecy lifetime, due to their dependence on Diffie-Hellman key agreement. The security of Diffie-Hellman depends on the difficulty Nagayama & Van Meter Expires April 30, 2015 [Page 14] Internet-Draft IKE for IPsec with QKD October 2014 of the factoring problem, which remains uncertain; factoring may prove vulnerable either to theoretical advances in algorithms, or the deployment of large-scale quantum computers. An eavesdropper who records encrypted packets today can store those packets, and decrypt them later by discovering the key, when it becomes technically feasible to do so. QKD+IKE+IPsec offers a different point in the security space, providing secrecy under different assumptions about computational difficulty than D-H+IKE+IPsec, for all choices of IPsec tunnel encryption protocol. In summary: o QKD+IKE+IPsec depends on the availability of an authentication mechanism that is secure at the time of key negotiation. o If QKD keys are used as an OTP, there are no known computational assumptions or weaknesses. Transferred data remains secret indefinitely unless disclosed through alternate means, or a post- facto vulnerability in the QKD implementation (e.g., a weakness in the random number generator used) is discovered. o If QKD keys are used for symmetric encryption, an eavesdropper may copy and store packets but cannot decrypt them until the symmetric cipher can be broken. In contrast: o D-H+IKE+IPsec depends on the availability of an authentication mechanism that is secure at the time of key negotiation. o If the D-H keys are used for symmetric encryption, an eavesdropper may copy and store packets, and will be able to decrypt them when it becomes possible EITHER to factor large numbers (breaking the D-H key agreement) OR to break the symmetric cipher. Thus, QKD+IKE+IPsec can remove one uncertainty about the future evolution of computational security. If factoring is easier than breaking symmetric encryption, the use of QKD will extend the timeframe for maintaining the secrecy of data, even if standard, symmetric encryption is used for the bulk data encryption. Key lifetime could be matched to QKD key generation rate; the mechanism is not specified here. Nagayama & Van Meter Expires April 30, 2015 [Page 15] Internet-Draft IKE for IPsec with QKD October 2014 6. Security Considerations Because QKD's principal role is to detect eavesdropping and discard possibly compromised bits, eavesdropping is a very effective denial of service (DoS) attack. One purpose of the fallback behavior negotiation is to provide network managers with a tool for alleviating this problem. Fallback methods should be used with extreme care, and SHOULD be coupled with event notification and monitoring. One possible practice would be to define the fallback policy for an SA carrying user traffic as WAIT_QKD, and define a second, primarily dormant, SA with a more liberal fallback policy for a management station. The second SA might be used only to diagnose problems and for low-security network monitoring and management activity until the QKD connection can be restored. This document describes a form of Internet Key Exchange protocol which is not based on the difficulty of factorization. Thus, under the circumstances described in Section 5, security may be improved. The system consists of two logically separate channels: a classical channel between IPsec gateways and a quantum channel between QKD- devices. The QKD devices require a classical channel and authentication to prevent a man-in-the-middle attack. One keys are securely transferred to the IPsec gateway, those keys could be used as an alternative method for authenticating the IPsec gateways. Careful integration of the classical and quantum networks could eliminate authentication on one path by sharing the authentication information from the other; such a use is not specified here. 7. IANA Considerations The following new assignments can only be made via an Expert Review as specified in [refs.IANA]. 7.1. Transform Type Values The IANA should allocate Transform Type Values in SA Payload for the QKD upon publication of the first RFC. 7.2. Payload Type Values The IANA should allocate IKE Payload Type Values for the QKD KeyID Payload and the QKD Fallback Payload upon publication of the first RFC. Nagayama & Van Meter Expires April 30, 2015 [Page 16] Internet-Draft IKE for IPsec with QKD October 2014 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC5683] Brusilovsky, A., "Password-Authenticated Key (PAK) Diffie- Hellman Exchange", RFC 5683, February 2010. [RFC5996] Kaufman, C., "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [refs.IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, October 2008. 8.2. Informative References [BB84] Bennett, C. and G. Brassard, "Quantum cryptography: Public key distribution and coin tossing", 1984. [EPT03] Elliot, C., Pearson, D., and G. Troxel, "Quantum cryptography in practice", 2003. [SECOQC07] Alleaume, R. and et al., "SECOQC White Paper on Quantum Key Distribution and Cryptography", 2007. [UQC09] Dodson, D. and et al., "Updating Quantum Cryptography Report ver. 1", 2009. Appendix A. Implementation Considerations and Current Status As of 2009, available QKD products use single photons over dedicated optical fibers and are limited in distance. Experimental demonstrations of wireless links and multi-hop networks using trusted intermediate nodes have been conducted [EPT03]. Progress is also being made toward use of satellite links and quantum entanglement- based networks of quantum repeaters that will not require trusting intermediate nodes [SECOQC07][UQC09]. In general, because QKD relies heavily on statistical evidence to determine the presence of an eavesdropper, it requires time to create Nagayama & Van Meter Expires April 30, 2015 [Page 17] Internet-Draft IKE for IPsec with QKD October 2014 a key. Thus, the IPsec implementation should be prepared for a long delay before keys become available. Moreover, the key generation rate may vary over time, typically rising over a long period from the initiation of a connection as statistical certainty improves, then settling near a sustained value around which the rate may vary as conditions change. Authors' Addresses Shota Nagayama Keio University Graduate school of Media and Governance 5322 Endo Fujisawa, Kanagawa 252-0882 Japan Email: kurosagi@sfc.wide.ad.jp Rodney Van Meter Keio University Faculty of Environment and Information Studies 5322 Endo Fujisawa-shi, Kanagawa-ken 252-0882 Japan Email: rdv@sfc.wide.ad.jp Nagayama & Van Meter Expires April 30, 2015 [Page 18]