idnits 2.17.1 draft-nagayama-ipsecme-ipsec-with-qkd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2014) is 3466 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Security Maintenance and Extensions (ipsecme) S. Nagayama 3 Internet-Draft R. Van Meter 4 Intended status: Experimental Keio University 5 Expires: April 30, 2015 October 27, 2014 7 IKE for IPsec with QKD 8 draft-nagayama-ipsecme-ipsec-with-qkd-01.txt 10 Abstract 12 Quantum Key Distribution (QKD) is a mechanism for creating shared, 13 secret, random bits. This document describes extensions to the IKEv2 14 protocol to use random bits created via QKD as keys for IPsec. The 15 Diffie-Hellman key agreement mechanism is replaced with QKD. The use 16 of QKD-generated keys with standard IPsec will extend the lifetime of 17 privacy guarantees for IPsec-protected data: future technological 18 advances that break Diffie-Hellman key exchange will not disclose 19 data until such time as the encryption algorithm used for the IPsec 20 tunnel is broken. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 30, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Architecture and Assumptions . . . . . . . . . . . . . . . . 4 70 3. Data Formats and Information Exchange Sequences . . . . . . . 5 71 3.1. Data Formats . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1.1. QKD KeyID Payload . . . . . . . . . . . . . . . . . . 5 73 3.1.2. QKD Fallback Payload . . . . . . . . . . . . . . . . 6 74 3.1.3. Transform Field for QKD in SA Payload . . . . . . . . 8 75 3.2. Sequence . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.2.1. Initializing IKE_SA . . . . . . . . . . . . . . . . . 9 77 3.2.2. Rekeying IKE_SA . . . . . . . . . . . . . . . . . . . 11 78 3.3. Considerations for Multiple SAs . . . . . . . . . . . . . 14 79 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 14 80 5. Recommendations for use of QKD-generated keys . . . . . . . . 14 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 7.1. Transform Type Values . . . . . . . . . . . . . . . . . . 16 84 7.2. Payload Type Values . . . . . . . . . . . . . . . . . . . 16 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 87 8.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Appendix A. Implementation Considerations and Current Status . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 Quantum key distribution (QKD) [BB84] creates shared, secret, random 98 bits using quantum effects to guarantee that the probability of an 99 undetected eavesdropper learning the secret bits is vanishingly 100 small. Thus, the secret bits are a good source of cryptographic 101 keying material. In the terminology proposed by the SECOQC 102 Project[SECOQC07], a QKD network includes a "secrets plane" which 103 delivers secret key material to other subsystems. QKD requires an 104 optical path without amplification, and a bidirectional classical 105 connection with authentication. 107 IPsec is a standardized protocol suite for encrypted communication 108 [RFC4301]. IPsec can be configured to use one of a number of 109 algorithms for encryption and authentication to keep data secret and 110 to guarantee the integrity. The bulk data encryption portion of 111 IPsec requires the use of a secret key shared only between the pair 112 of IPsec gateways. Internet Key Exchange (IKE) [RFC5996] provides 113 several important functions: creation of the shared secret key, 114 management of the use of that key, and negotiation of the details of 115 the bulk data encryption method and conditions under which it is 116 applied. Standard IKE negotiates parameters for distributed Diffie- 117 Hellman calculation of the secret key, then executes that 118 calculation. The security of D-H is predicated upon the difficulty 119 of the integer factorization problem. Future development of large- 120 scale quantum computers or advances in classical factoring algorithms 121 may render the Diffie-Hellman-negotatied key vulnerable, even years 122 after the actual network exchange, if the IKE packet exchanges have 123 been recorded. Thus, the secrecy of the key itself and therefore of 124 data communicated using IPsec should be considered secure only up to 125 the advent of certain technological advances. Methods of key 126 negotiation not dependent upon the difficulty of factoring therefore 127 are desirable, and QKD is one such possibility. 129 Commercial QKD devices available as of the writing of this document 130 do not use a documented, standardized variant of IPsec and IKE. 131 Publication of this I-D as an RFC will advance interoperability among 132 different vendors when combined with the standardization of the 133 physical implementations of QKD now under development in ETSI. As of 134 the writing of this document, commercial QKD systems operate over 135 dedicated optical fiber without amplifiers. Experimental QKD systems 136 allow wavelength multiplexing of the QKD signals with classical 137 information, and have also been demonstrated through free space and 138 proposed to operate via satellite link. One key application of the 139 quantum repeater systems being actively researched worldwide is to 140 support long-distance QKD. 142 2. Architecture and Assumptions 144 This document describes modifications to IKEv2 to use keys created 145 via QKD for the Internet Key Exchange IKE_SA[RFC5996], the key 146 agreement protocol for IPsec[RFC4301] . With the exception of the 147 use of the new payloads defined below and the removal of the Diffie- 148 Hellman key agreement information, IKEv2 operates in standard 149 fashion. 151 The system design is shown in Figure 1. Each side has an IPsec 152 Gateway and a QKD Device. The IPsec Gateways are connected via an IP 153 network and the QKD Devices are connected through the QKD network. 154 The IP network and QKD network MAY share all, some, or none of the 155 physical links comprising their networks, e.g. via wavelength 156 multiplexing. Either end MAY initiate the QKD connection. 158 System Design 160 Initiator Responder 161 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 162 ! IPsec Gateway !--------! IP network !-----------! IPsec Gateway ! 163 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 164 | | 165 |local connection |local 166 | |connection 167 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 168 ! QKD Device !---------! QKD Network !------------! QKD Device ! 169 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 171 Figure 1 173 The connection between the IPsec Gateway and the QKD device, marked 174 "local connection" MUST be secret, authenticated, and reliable. This 175 MAY be achieved by incorporating both the IPsec Gateway and QKD 176 device into a single system. 178 The QKD device SHALL provide secret, shared, random bits to the IPsec 179 gateway. The bits MUST be shared with an authenticated partner only. 180 The key material SHALL be managed in such a manner that the IPsec 181 gateways can independently map a Key ID to matching key material. 182 Beyond this, the interface between the IPsec Gateway and QKD device 183 is beyond the scope of this document. 185 The technical details of the operation of the QKD network (including 186 device physics, data filtering, node addressing, authentication, 187 synchronization, etc.) are beyond the scope of this document. The 188 QKD channel operates independently from the IP network that connects 189 the IPsec gateways. QKD requires an authenticated classical channel 190 which is not part of the IPsec connection; this channel can be 191 unencrypted. The key name (Key ID) is chosen by the QKD subsystem. 192 It is the QKD subsystem's responsibility to ensure that key names are 193 unambiguous, e.g. that key names are not reused within a time frame 194 that can cause confusion. 196 3. Data Formats and Information Exchange Sequences 198 IKE must exchange two parameters to use QKD: an identifier indicating 199 which QKD-generated key is to be used (KeyID) and the choice of 200 fallback methods. One Key ID represents one unit of shared random 201 bits, large enough for use as bulk data encryption key. Fallback 202 methods are used when the QKD system key generation underruns. 203 Additionally, the system should be able to choose the key exchange 204 algorithm from an approved list including e.g. QKD, Diffie-Hellman 205 key exchange and password-authenticated key [RFC5683]. 207 3.1. Data Formats 209 There are three added data formats: QKD KeyID Payload, QKD Fallback 210 Payload and Transform Field for QKD in the SA Payload. 212 3.1.1. QKD KeyID Payload 214 Figure 2 defines the payload for the QKD KeyID. 216 QKD KeyID Payload 218 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 ! Next Payload !C! RESERVED ! Payload Length ! 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 ! version !F! flags ! QKD Device ID ! 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 ! Key ID Length ! ! 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 227 ! Key ID (variable length) ! 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 2 232 The Next Payload field of the previous header MUST be set to the QKD 233 KeyID Payload number (see Section 7). The first 32 bits of the 234 payload are the Generic Payload Header. To avoid a man-in-the-middle 235 attack downgrading the negotiated security level, the Critical bit 236 must be set to 1. The responder MUST reply with an error message 237 when it it is incapable of using QKD (see Section 4). 239 o Version (one octet) specifies the format and semantics of this 240 message. The current version is 1. 242 o The "F" field contains the Running Mode configuration. IPsec with 243 QKD has two modes, normal and fallback. Table 1 shows the modes 244 and mode values. This field MUST be 0 for initiating IPsec. 246 o Flags holds flag bits; this field MUST be zero. 248 o QKD Device ID contains an ID number for the QKD device. Each 249 IPsec Gateway may be equipped with more than one QKD device. This 250 field carries an ID number to determine which QKD device should be 251 used. The Device ID plus the Key ID MUST uniquely identify the 252 key. 254 o Key ID Length defines the length of Key ID field. 256 o Key ID (variable length) is used to communicate which key to use 257 for the encryption. 259 Runnning mode values for the "F" field 261 +------------------+------------+ 262 | Running Mode | Mode Value | 263 +------------------+------------+ 264 | normal running | 0 | 265 | | | 266 | fallback running | 1 | 267 +------------------+------------+ 269 Table 1 271 3.1.2. QKD Fallback Payload 273 The Next Payload field of the previous header MUST be set to the QKD 274 Fallback Payload number (see Section 7). The first 32 bits of the 275 payload are the Generic Payload Header. 277 QKD Fallback Payload 279 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 ! Next Payload !C! RESERVED ! Payload Length ! 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 ! version ! FLAGS ! Fallback ! 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 3 289 o Version (one octet) specifies the format and semantics of this 290 message. The current version is 1. 292 o Flags holds flag bits; this field MUST be zero. 294 o The Fallback field contains the configuration of fallback methods. 295 There are three fallback methods, listed in Table 2. 297 Fallback methods 299 +-----------------+--------------+ 300 | Fallback method | Method Value | 301 +-----------------+--------------+ 302 | WAIT_QKD | 1 | 303 | | | 304 | DIFFIE-HELLMAN | 2 | 305 | | | 306 | CONTINUE | 3 | 307 +-----------------+--------------+ 309 Table 2 311 The Fallback methods are as follows: 313 WAIT_QKD indicating that IKE MUST wait for the QKD device to deliver 314 a new key. When the IPsec tunnel key lifetime expires and no new 315 QKD-generated key is available, the system MUST stop encrypting 316 packets and forwarding them across the network; the tunnel should 317 be considered to be down. 319 CONTINUE indicating that IPsec MAY continue to use the most recent 320 key until a new key becomes available. 322 DIFFIE-HELLMAN indicating that IKE SHALL generate a new key in the 323 existing IKE_SA using Diffie-Hellman. 325 The Fallback Payload is encrypted, relying on the security of the 326 IKE_SA, which is guaranteed by QKD. 328 3.1.3. Transform Field for QKD in SA Payload 330 Figure 4 defines the Transform Field for QKD included in the SA 331 Payload. 333 Transform Field for QKD 335 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 ! 0(last) or 3 ! RESERVED ! 8 (Transform Length) ! 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 !(TransformType)! RESERVED ! 0 or 1 (Transform ID) ! 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 4 345 The SA Payload carries proposals for all parameters, including the 346 method for generating keys, in the Transform Fields. QKD must be 347 proposed here like other key sharing algorithms. 349 o Transform Length must be fixed at 8 since QKD does not need the 350 Transform Attributes field. 352 o Transform Type field MUST be set to the number for QKD (see 353 Section 7) 355 o Transform ID field contains the method for using QKD. Table 3 356 shows the modes and the values. Direct use means using QKD- 357 generated key as encrypt key. In password-authenticated key mode, 358 the QKD-generated key is used for D-H. See [RFC5683] for details. 360 The use modes of QKD and values for Transform ID field 362 +----------------------------+------------+ 363 | Use Mode | Mode Value | 364 +----------------------------+------------+ 365 | Direct use | 0 | 366 | | | 367 | Password-authenticated key | 1 | 368 +----------------------------+------------+ 370 Table 3 372 3.2. Sequence 374 To use QKD-generated keys, the Initiator and Responder must agree on 375 a Key ID to use. This key will be used to encrypt the IKE_AUTH 376 exchange, and does not change the IKE Sequence. Other parameters, 377 defining the Fallback method, must be exchanged in IKE_AUTH, in the 378 encrypted connection. 380 Standard IKEv2 exchanges key data for Diffie-Hellman in IKE_SA_INIT 381 in a synchronous fashion. The principle difficulty in using QKD- 382 generated secret bits as keys for IPsec tunnels is coordinating the 383 activity of the QKD secrets plane with IKE, because the QKD device 384 must operate continuously and independently to monitor its path and 385 create secret bits, as discussed in Appendix A. 387 3.2.1. Initializing IKE_SA 389 When the initiator wishes to use QKD-generated keys, it MUST wait 390 until the QKD device delivers one or more valid keys, shared with the 391 responder, before sending the IKE_SA_INIT message. The initiator 392 chooses a key and sends a proposal including the SA Payload including 393 the Transform Field for QKD and the KeyID Payload in IKE_SA_INIT. 394 The responder replies with an SA Payload as described in [RFC5996] 395 section 3.3 and echos the Key ID. QKD fallback methods are exchanged 396 in IKE_AUTH. The manner of choosing fallback methods follows IKE's 397 algorithm to share configuration in [RFC5996] 398 Section 2.7."Cryptographic Algorithm Negotiation". 400 The key negotation process is described below. Payload names in this 401 document are to be interpreted as described in [RFC5996]. 403 The IKE_SA_INIT with QKD 405 Initiator Responder 406 ----------- ----------- 407 HDR, SAi1, KEi, Ni KeyID --> 409 HDR is the IKE Header. SAi1 is a payload which states the parameters 410 and the cryptographic algorithms the initiator supports for the 411 IKE_SA, including the Transform Field for QKD. KeyID is the QKD 412 KeyID Payload described in Section 3.1.1. The NoKey bit MUST be 0 in 413 IKE_SA_INIT. The KEi and Ni Payloads that are cantained in standard 414 IKEv2 MUST be omitted because they are for Diffie-Hellman, and are 415 not used with QKD. 417 <-- HDR, SAr1, KEr, Nr, KeyID 419 Responder echos Key ID in its KeyID Payload. 421 The IKE_AUTH with QKD exchange 423 Initiator Responder 424 ----------- ----------- 425 HDR, SK{IDi, [CERT,] [CERTREQ,] [IDr,] 426 QKDfallback, AUTH, SAi2, TSi, TSr} --> 428 The notation SK{...} means that payloads between {} are encrypted by 429 the SA whose key is chosen in IKE_SA_INIT. QKDfallback Payload is 430 the QKD Fallback Payload, containing the initiator's proposed 431 fallback method. IDi, AUTH, SAi2, TSi, TSr are payloads which state 432 the initiator's identification, authentication and CHILD_SA's 433 parameters and traffic selectors of initiator and responder. 435 <-- HDR, SK{IDr, [CERT,] QKDfallback 436 AUTH, SAr2, TSi, TSr} 438 Responder replies with its acceptance of fallback methods in its QKD 439 fallback Payload. If the Responder does not agree with the 440 Initiator's requested fallback method, it MUST respond with an error 441 message and abort the IKE negotiation, as discussed in Section 4. 443 Exchanges in initializing IKE_SA 445 Initiator Responder 446 | IKE_SA_INIT | 447 |----------------------------------------->| 448 | Transform Field for QKD: Transform ID=0 | 449 | KeyID: Critical=1, Key ID=foo | 450 | | 451 | | 452 | IKE_SA_INIT | 453 |<-----------------------------------------| 454 | Transform Field for QKD: Transform ID=0 | 455 | KeyID: Critical=1, Key ID=foo | 456 | | 457 | | 458 | IKE_AUTH | 459 |----------------------------------------->| 460 | Fallback: Critical=1, | 461 | Fallback=[WAIT|DH|CONTINUE] | 462 | | 463 | | 464 | IKE_AUTH | 465 |<-----------------------------------------| 466 | Fallback: Critical=1, | 467 | Fallback=[WAIT|DH|CONTINUE] | 468 | | 469 | | 471 Figure 5 473 During initialization, IKE_SA cannot use a fallback method. The key 474 must be generated by QKD. Thus, the Critical bit is set to 1. If 475 the system underruns in key generation, it MUST wait for the QKD 476 device to generate a new key. 478 3.2.2. Rekeying IKE_SA 480 In IKE two ways are defined to rekey an IKE_SA: repeating the 481 original initiation sequence by exchanging IKE_SA_INIT and IKE_AUTH, 482 and using the CREATE_CHILD_SA exchange. Because IKE_SA_INIT is 483 exchanged without encryption, if the Initiator wishes to specify 484 fallback behavior, it MUST create a child SA, rather than re- 485 initialize. 487 The CREATE_CHILD_SA with QKD Exchange 489 Initiator Responder 490 ------------ ----------- 491 HDR, SK{[N], SA, Ni, KeyID, 492 [KEi,] [TSi, TSr]} --> 494 Figure 6 496 The initiator sends CREATE_CHILD_SA including an IKE header, 497 optionally a notify, a new security association including the 498 transform field for QKD, a nonce, Key ID for QKD, optionally a key 499 exchange for Diffie-Hellman and optionally traffic selectors. 501 <-- HDR, SK{SA, Nr, KeyID, 502 [KEr,] [TSi, TSr]} 504 The Responder sends CREATE_CHILD_SA which includes an IKE header, a 505 new security association, a nonce, Key ID for QKD, optionally a key 506 exchange for Diffie-Hellman and optionally traffic selectors. 508 The system SHOULD use QKD to rekey IKE_SA when possible. When the 509 initiator rekeys using a new QKD-generated key, the KeyID Payload 510 from the initiator carries the new Key ID and the transform ID in the 511 Transform Field for QKD in the SA Payload is set to 0. Responder 512 repeats the same Key ID in the KeyID Payload and replies SA Payload 513 as described in [RFC5996] Section 3.3.6. The Critical bits are 514 ignored in this case. Both KEi and KEr MUST be omitted. 516 Normal Message Sequence in CREATE_CHILD_SA for rekeying IKE_SA 518 Initiator Responder 519 | CREATE_CHILD_SA | 520 |----------------------------------------->| 521 | Transform Field for QKD: Transform ID=0 | 522 | KeyID: Critical=1, Key ID=bar | 523 | | 524 | | 525 | CREATE_CHILD_SA | 526 |<-----------------------------------------| 527 | Transform Field for QKD: Transform ID=0 | 528 | KeyID: Critical=1, Key ID=bar | 529 | | 530 | | 532 Figure 7 534 When the SA lifetime nears expiration and it becomes necessary to 535 rekey, if no QKD-generated key is available the Initiator SHALL rekey 536 using the specified fallback method, if one was specified. The 537 initiator SHALL send the transform ID in the Transform Field for QKD 538 in the SA Payload set to 1 and Key ID field of KeyID Payload set to 539 null to keep the packet as long as the one of normal running. The 540 Responder SHALL reply with null Key ID field. It replies with an SA 541 Payload obeying [RFC5996] section 3.3. If Diffie-Hellman is 542 permitted as a fallback method and the Perfect Forward Security(PFS) 543 is configured to work, CREATE_CHILD_SA carries KEi and KEr. 545 Fallback Exchanges in CREATE_CHILD_SA for rekeying IKE_SA 547 Initiator Responder 548 | CREATE_CHILD_SA | 549 |----------------------------------------->| 550 | Transform Field for QKD: Transform ID=1 | 551 | KeyID: NULL | 552 | | 553 | | 554 | CREATE_CHILD_SA | 555 |<-----------------------------------------| 556 | Transform Field for QKD: Transform ID=1 | 557 | KeyID: NULL | 558 | | 559 | | 561 Figure 8 563 3.3. Considerations for Multiple SAs 565 IPsec can have multiple SAs between two IPsec gateways. QKD provides 566 node-to-node keys, thus the system described in this document can 567 also manage multiple SAs. The Initiator is free to use any QKD- 568 generated keys for any SAs, but MUST NOT reuse any key. 570 4. Error Handling 572 Error handling beyond that already described in this document is TBD. 574 5. Recommendations for use of QKD-generated keys 576 From a data privacy point of view, the ideal use of QKD-generated 577 keys would be as a one-time pad (OTP) to protect the data carried in 578 the IPsec tunnel. However, as of 2014, QKD key generation rates are 579 not adequate for high-speed OTP use; the QKD-generated keys instead 580 will be used most commonly as key material for symmetric encryption 581 of the IPsec tunnel. Thus, the upper bound on the secret lifetime of 582 data remains the time until the chosen symmetric cipher can be 583 broken. An eavesdropper who records encrypted packets today can 584 store those packets, and decrypt them later by directly attacking the 585 symmetric cipher, when it becomes technically feasible to do so. 587 However, existing IPsec/IKE implementations actually have a lower 588 data secrecy lifetime, due to their dependence on Diffie-Hellman key 589 agreement. The security of Diffie-Hellman depends on the difficulty 590 of the factoring problem, which remains uncertain; factoring may 591 prove vulnerable either to theoretical advances in algorithms, or the 592 deployment of large-scale quantum computers. An eavesdropper who 593 records encrypted packets today can store those packets, and decrypt 594 them later by discovering the key, when it becomes technically 595 feasible to do so. 597 QKD+IKE+IPsec offers a different point in the security space, 598 providing secrecy under different assumptions about computational 599 difficulty than D-H+IKE+IPsec, for all choices of IPsec tunnel 600 encryption protocol. 602 In summary: 604 o QKD+IKE+IPsec depends on the availability of an authentication 605 mechanism that is secure at the time of key negotiation. 607 o If QKD keys are used as an OTP, there are no known computational 608 assumptions or weaknesses. Transferred data remains secret 609 indefinitely unless disclosed through alternate means, or a post- 610 facto vulnerability in the QKD implementation (e.g., a weakness in 611 the random number generator used) is discovered. 613 o If QKD keys are used for symmetric encryption, an eavesdropper may 614 copy and store packets but cannot decrypt them until the symmetric 615 cipher can be broken. 617 In contrast: 619 o D-H+IKE+IPsec depends on the availability of an authentication 620 mechanism that is secure at the time of key negotiation. 622 o If the D-H keys are used for symmetric encryption, an eavesdropper 623 may copy and store packets, and will be able to decrypt them when 624 it becomes possible EITHER to factor large numbers (breaking the 625 D-H key agreement) OR to break the symmetric cipher. 627 Thus, QKD+IKE+IPsec can remove one uncertainty about the future 628 evolution of computational security. If factoring is easier than 629 breaking symmetric encryption, the use of QKD will extend the 630 timeframe for maintaining the secrecy of data, even if standard, 631 symmetric encryption is used for the bulk data encryption. 633 Key lifetime could be matched to QKD key generation rate; the 634 mechanism is not specified here. 636 6. Security Considerations 638 Because QKD's principal role is to detect eavesdropping and discard 639 possibly compromised bits, eavesdropping is a very effective denial 640 of service (DoS) attack. One purpose of the fallback behavior 641 negotiation is to provide network managers with a tool for 642 alleviating this problem. Fallback methods should be used with 643 extreme care, and SHOULD be coupled with event notification and 644 monitoring. 646 One possible practice would be to define the fallback policy for an 647 SA carrying user traffic as WAIT_QKD, and define a second, primarily 648 dormant, SA with a more liberal fallback policy for a management 649 station. The second SA might be used only to diagnose problems and 650 for low-security network monitoring and management activity until the 651 QKD connection can be restored. 653 This document describes a form of Internet Key Exchange protocol 654 which is not based on the difficulty of factorization. Thus, under 655 the circumstances described in Section 5, security may be improved. 657 The system consists of two logically separate channels: a classical 658 channel between IPsec gateways and a quantum channel between QKD- 659 devices. The QKD devices require a classical channel and 660 authentication to prevent a man-in-the-middle attack. One keys are 661 securely transferred to the IPsec gateway, those keys could be used 662 as an alternative method for authenticating the IPsec gateways. 663 Careful integration of the classical and quantum networks could 664 eliminate authentication on one path by sharing the authentication 665 information from the other; such a use is not specified here. 667 7. IANA Considerations 669 The following new assignments can only be made via an Expert Review 670 as specified in [refs.IANA]. 672 7.1. Transform Type Values 674 The IANA should allocate Transform Type Values in SA Payload for the 675 QKD upon publication of the first RFC. 677 7.2. Payload Type Values 679 The IANA should allocate IKE Payload Type Values for the QKD KeyID 680 Payload and the QKD Fallback Payload upon publication of the first 681 RFC. 683 8. References 685 8.1. Normative References 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, March 1997. 690 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 691 Internet Protocol", RFC 4301, December 2005. 693 [RFC5683] Brusilovsky, A., "Password-Authenticated Key (PAK) Diffie- 694 Hellman Exchange", RFC 5683, February 2010. 696 [RFC5996] Kaufman, C., "Internet Key Exchange Protocol Version 2 697 (IKEv2)", RFC 5996, September 2010. 699 [refs.IANA] 700 Narten, T. and H. Alvestrand, "Guidelines for Writing an 701 IANA Considerations Section in RFCs", RFC 5226, October 702 2008. 704 8.2. Informative References 706 [BB84] Bennett, C. and G. Brassard, "Quantum cryptography: Public 707 key distribution and coin tossing", 1984. 709 [EPT03] Elliot, C., Pearson, D., and G. Troxel, "Quantum 710 cryptography in practice", 2003. 712 [SECOQC07] 713 Alleaume, R. and et al., "SECOQC White Paper on Quantum 714 Key Distribution and Cryptography", 2007. 716 [UQC09] Dodson, D. and et al., "Updating Quantum Cryptography 717 Report ver. 1", 2009. 719 Appendix A. Implementation Considerations and Current Status 721 As of 2009, available QKD products use single photons over dedicated 722 optical fibers and are limited in distance. Experimental 723 demonstrations of wireless links and multi-hop networks using trusted 724 intermediate nodes have been conducted [EPT03]. Progress is also 725 being made toward use of satellite links and quantum entanglement- 726 based networks of quantum repeaters that will not require trusting 727 intermediate nodes [SECOQC07][UQC09]. 729 In general, because QKD relies heavily on statistical evidence to 730 determine the presence of an eavesdropper, it requires time to create 731 a key. Thus, the IPsec implementation should be prepared for a long 732 delay before keys become available. Moreover, the key generation 733 rate may vary over time, typically rising over a long period from the 734 initiation of a connection as statistical certainty improves, then 735 settling near a sustained value around which the rate may vary as 736 conditions change. 738 Authors' Addresses 740 Shota Nagayama 741 Keio University 742 Graduate school of Media and Governance 743 5322 Endo 744 Fujisawa, Kanagawa 252-0882 745 Japan 747 Email: kurosagi@sfc.wide.ad.jp 749 Rodney Van Meter 750 Keio University 751 Faculty of Environment and Information Studies 752 5322 Endo 753 Fujisawa-shi, Kanagawa-ken 252-0882 754 Japan 756 Email: rdv@sfc.wide.ad.jp