IPsec Maintenance and Extensions S. Nagayama
Internet-Draft R. Van Meter
Intended status: Experimental Keio University
Expires: April 22, 2010 October 19, 2009
IKE for IPsec with QKD
draft-nagayama-ipsecme-ipsec-with-qkd-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice
Copyright (c) 2009 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
Nagayama & Van Meter Expires April 22, 2010 [Page 1]
Internet-Draft IKE for IPsec with QKD October 2009
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Nagayama & Van Meter Expires April 22, 2010 [Page 2]
Internet-Draft IKE for IPsec with QKD October 2009
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.
Table of Contents
1. Quantum Key Distribution . . . . . . . . . . . . . . . . . . . 4
2. Architecture and Assumptions . . . . . . . . . . . . . . . . . 5
3. Data Formats and Information Exchange Sequences . . . . . . . 7
3.1. Data Formats . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. QKD Key ID Payload . . . . . . . . . . . . . . . . . . 7
3.1.2. QKD Fallback 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 . . . . . . . . . . . . . 13
4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Recommendations for use of QKD-generated keys . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. Payload Type Values . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Implementation Considerations and Current Status . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Nagayama & Van Meter Expires April 22, 2010 [Page 3]
Internet-Draft IKE for IPsec with QKD October 2009
1. Quantum Key Distribution
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].
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.
Nagayama & Van Meter Expires April 22, 2010 [Page 4]
Internet-Draft IKE for IPsec with QKD October 2009
2. Architecture and Assumptions
This document describes modifications to IKEv2 to use keys created
via QKD for the Internet Key Exchange IKE_SA[RFC4306], 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 system 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 22, 2010 [Page 5]
Internet-Draft IKE for IPsec with QKD October 2009
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.
Nagayama & Van Meter Expires April 22, 2010 [Page 6]
Internet-Draft IKE for IPsec with QKD October 2009
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.
3.1. Data Formats
3.1.1. QKD Key ID Payload
Figure 2 defines the payload for the QKD Key ID.
QKD Key ID 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 !N! flags ! reserved !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
The Next Payload field of the previous header MUST be set to the QKD
Key ID 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).
o Key ID (four octets) is used to communicate which key to use for
the encryption.
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 N is the NoKey bit. 0 means that the KeyID field is valid. 1 means
that the KeyID field is not valid, and the responder SHALL resort
to the Fallback method, if one is specified in a Fallback Payload.
This bit MUST be 0 for IKE_SA_INIT.
Nagayama & Van Meter Expires April 22, 2010 [Page 7]
Internet-Draft IKE for IPsec with QKD October 2009
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.
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 Fallback field contains the configure of fallback methods. There
are three fallback methods, listed in Table 1.
Fallback methods
+-----------------+--------------+
| Fallback method | Method Value |
+-----------------+--------------+
| WAIT_QKD | 1 |
| | |
| DIFFIE-HELLMAN | 2 |
| | |
| CONTINUE | 3 |
+-----------------+--------------+
Table 1
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, the system
MUST stop encrypting packets and forwarding them across the
network; the tunnel should be considered to be down.
Nagayama & Van Meter Expires April 22, 2010 [Page 8]
Internet-Draft IKE for IPsec with QKD October 2009
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 as defined in [RFC4718].
The Fallback payload is encrypted, relying on the security of the
IKE_SA, which is guaranteed by QKD.
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 the Key ID in IKE_SA_INIT. The responder
echos the Key ID. QKD fallback methods are exchanged in IKE_AUTH.
The way to choose fallback methods follows IKE's algorithm to share
configuration in [RFC4306] 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 [RFC4306].
The IKE_SA_INIT with QKD
Initiator Responder
----------- -----------
HDR, SAi1, KeyID -->
HDR and SAi1 are the IKE Header and a payload which states the
cryptographic algorithms the initiator supports for the IKE_SA.
KeyID is the QKD Key ID Payload described in Section 3.1.1. The
Nagayama & Van Meter Expires April 22, 2010 [Page 9]
Internet-Draft IKE for IPsec with QKD October 2009
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, KeyID
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 22, 2010 [Page 10]
Internet-Draft IKE for IPsec with QKD October 2009
Normal Exchanges in initializing IKE_SA
Initiator Responder
| IKE_SA_INIT |
|----------------------------------------->|
| Critical=1, Key ID=foo, No key=0 |
| |
| |
| IKE_SA_INIT |
|<-----------------------------------------|
| Critical=1, Key ID=foo, No key=0 |
| |
| |
| IKE_AUTH |
|----------------------------------------->|
| Critical=1 |
| Fallback=[WAIT|DH|CONTINUE] |
| |
| |
| IKE_AUTH |
|<-----------------------------------------|
| Critical=1 |
| Fallback=[WAIT|DH|CONTINUE] |
| |
| |
Figure 4
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 22, 2010 [Page 11]
Internet-Draft IKE for IPsec with QKD October 2009
The CREATE_CHILD_SA with QKD Exchange
Initiator Responder
------------ -----------
HDR, SK{[N], SA, Ni, KeyID,
[KEi,] [TSi, TSr]} -->
Figure 5
The initiator sends CREATE_CHILD_SA including an IKE header,
optionally a notify, a new security association, 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 No key bit is set
to 0. Responder repeats the Key ID and sets the No key bit set to 0.
The Critical bits are ignored in this case. Both KEi and KEr MUST be
omitted.
Normal Message Sequence in CREATE_CHILD_SA for rekeying IKE_SA
Initiator Responder
| CREATE_CHILD_SA |
|----------------------------------------->|
| Critical=1 |
| Key ID=foo, No key=0 |
| |
| |
| CREATE_CHILD_SA |
|<-----------------------------------------|
| Critical=1 |
| Key ID=foo, No key=0 |
| |
| |
Nagayama & Van Meter Expires April 22, 2010 [Page 12]
Internet-Draft IKE for IPsec with QKD October 2009
Figure 6
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 Fallback Payload with the No key bit set to
1. The initiator SHALL send the Key ID Payload with the KeyID field
set to 0 and the NoKey bit set to 1. The Responder SHALL reply with
the same Key ID and Fallback payloads. 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.
Fallback Exchanges in CREATE_CHILD_SA for rekeying IKE_SA
Initiator Responder
| CREATE_CHILD_SA |
|----------------------------------------->|
| Critical=1 |
| Key ID=NULL, No key=1 |
| |
| |
| CREATE_CHILD_SA |
|<-----------------------------------------|
| Critical=1 |
| Key ID=NULL, No key=1 |
| |
| |
Figure 7
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.
Nagayama & Van Meter Expires April 22, 2010 [Page 13]
Internet-Draft IKE for IPsec with QKD October 2009
4. Error Handling
Error handling beyond that already described in this document is TBD.
Nagayama & Van Meter Expires April 22, 2010 [Page 14]
Internet-Draft IKE for IPsec with QKD October 2009
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 2009, 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
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, transferred data remains secret
forever (or until disclosed through alternate means).
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
Nagayama & Van Meter Expires April 22, 2010 [Page 15]
Internet-Draft IKE for IPsec with QKD October 2009
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 22, 2010 [Page 16]
Internet-Draft IKE for IPsec with QKD October 2009
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.
Nagayama & Van Meter Expires April 22, 2010 [Page 17]
Internet-Draft IKE for IPsec with QKD October 2009
7. IANA Considerations
The following new assignments can only be made via a Standards Action
as specified in [refs.IANA].
7.1. Payload Type Values
The IANA should allocate IKE Payload Type Values for the QKD Key ID
Payload and the QKD Fallback Payload upon publication of the first
RFC.
Nagayama & Van Meter Expires April 22, 2010 [Page 18]
Internet-Draft IKE for IPsec with QKD October 2009
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.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
[refs.IANA]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434,
October 1998.
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.
Nagayama & Van Meter Expires April 22, 2010 [Page 19]
Internet-Draft IKE for IPsec with QKD October 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
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.
Nagayama & Van Meter Expires April 22, 2010 [Page 20]
Internet-Draft IKE for IPsec with QKD October 2009
Authors' Addresses
Shota Nagayama
Keio University
Faculty of Policy Management
5322 Endo
Fujisawa, Kanagawa 252-8520
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-8520
Japan
Email: rdv@sfc.wide.ad.jp
Nagayama & Van Meter Expires April 22, 2010 [Page 21]