Network Working Group Solange Ghernaouti-Hélie
INTERNET-DRAFT Mohamed Ali Sfaxi
University of Lausanne
Expires: April, 29 2006 October 2005
Quantum Key Destribution within Point
to Point Protocol (Q3P)
draft-ghernaouti-sfaxi-ppp-qkd-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The aim of this paper is to analyse the use of quantum
cryptography within PPP. We propose a solution that integrates
quantum key distribution into PPP.
Terminology
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
RFC 2119 [9].
Ghernaouti and Sfaxi [Page 1]
INTERNET-DRAFT Expires: April, 29 2006
1. Introduction
The point to point protocol (PPP) [RFC1661] is a data-layer
protocol ensuring a reliable data exchange over a point to point
link. When the connection is established and configured, the PPP
allows the data transfer of many protocols (IP, IPX, AppleTalk
).
That's why; PPP is widely used in Internet environment.
The unique security of PPP as specified in the RFC 1661 is limited
to the authentication phase. The two nodes use an authentication
protocol such as Password Authentication Protocol (PAP) [RFC1334]
or Challenge Handshake Authentication Protocol (CHAP)[RFC1994]. In
1996, Meyer published an additional security protocol for PPP
called ECP (Encryption Control Protocol) [RFC1968]. This protocol
allows the use of the encryption in PPP frame. The ECP gives the
possibility to select the encryption algorithm and its parameters.
This ensures the confidentiality and the integrity of the PPP
frame. The weakness of this use resides in the way of generating
and exchanging the encryption key. In fact, for all the encryption
algorithms the secret key is assumed to be already shared between
the communicating parties. So to enhance security, we propose the
use of quantum cryptography to generate and to share the secret
key between the two nodes.
Quantum cryptography is the only method allowing the distribution
of a secret key between two distant parties without transmitting
any secret over unsecure channel [1, 4]. the emitter and the
receiver will be able to share an encryption key for enciphering
confidential data. The secrecy of this shared key is unconditional
[8] by the fact that the secret is generated and exchanged based
on physic laws (instead of mathematical functions). Thats why we
propose to integrate the quantum key distribution (QKD) process to
share secret key between two nodes.
2. Encryption Control Protocol (ECP) for Quantum Key Distribution
(QKD)
The Encryption Control Protocol (ECP) defines the negotiation of
the encryption over PPP links. After using LCP to establish and
configure the data link, the encryption options and mechanisms
could be negotiated. The ECP packets exchange mechanism is nearly
the same as the LCP mechanism. The ECP packets are encapsulating
into PPP frame (a packet per frame). The type is 0x8053 to
indicate the Encryption Control Protocol. Two additional messages
are added to the code field: the Reset-Request and Reset-Ack
message. These two messages are used to restart the encryption
negotiation. An encrypted packet is encapsulated in the PPP
information field where the PPP protocol field indicates type
0x0053 (encrypted datagram). The ECP packet is presented in
figure 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Values...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 1 - The Encryption Type Configuration Option format
Ghernaouti and Sfaxi [Page 2]
INTERNET-DRAFT Expires: April, 29 2006
ECP packet, the type represents the encryption protocol option to
be negotiated (for instance type 1 is DES encryption). The number
of octets in the packet is contained in the length field. The
values field gives additional data or option needed for the
encryption protocol. Up to now, there are only 4 encryption
algorithms (type 0 = OUI, type 1 = DES, type 2 = 3DES, type 3 =
DES modified) that could be used [5].
3. Integrating QKD in PPP: QKD-PPP (Q3P)
In order to exchange the encryption key, a key exchange protocol
is necessary. In this section, we present how to integrate QKD in
PPP
3.1 ECP-QKD format
To establish and configure the quantum key distribution between
the two nodes, it is necessary to exchange some data between
them. We propose a specific ECP packet format to carry QKD
parameters (Figure 2):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Key-Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2 - ECP packet carrying a QKD protocol
Type field:
As in the ECP standard packet the type field gives information
about the option of encryption protocol negotiated. For this
case, we will use an unassigned number for the QKD protocol. The
selected QKD protocol is BB84 and the request to obtain an
assigned number for this protocol is on going in IANA
organisation [5].
Length field:
The length is number of octets in the packet and it is more than
5 octets (1 octet for the type, 1 octet for the packet length,
2 octets for the key length and one octet for the TTL and the T
field).
Key-length field:
This field indicates the length of the encryption key. It is
ended on 16 bits and represents the size of the key in octet. The
key size is comprised between 1 to 65535 octets. The size can be
viewed as huge but we consider the possibility to use the One
Time Pad function as the encryption algorithm. In this case, the
key size must be equal to the PPP-data size [11].
Ghernaouti and Sfaxi [Page 3]
INTERNET-DRAFT Expires: April, 29 2006
TTL field:
This field can represent either the number of messages or the
amount of time (in second) during which a key could be used in
the encryption mechanism. When the max number of messages is
reached or the deadline expires, the QKD starts.
T field:
The T field specifies if the TTL field concerns the number of
messages or the amount of time. If the value is 1, the TTL
field corresponds to the amount of time in second. If it is 0,
the TTL is the number of messages per key.
3.2 The Q3P operating mode
We adapt PPP connection steps [RFC1661] to integrate QKD process
as shown Figure 3. The three first steps of Q3P are identical
with PPP (phase 1 to 3). After authenticating the two nodes, the
negotiation of the encryption parameters starts. In this phase,
the encryption algorithm with its parameters is negotiated.
If the two nodes do not need to use encryption, then the network
phase starts. Else, if an encryption key is required, a QKD phase
begins. For Encryption negotiation (4) the nodes negotiate the
key length and the TTL by sending an adequate ECP packet. After
that (in 5), a quantum cryptography exchange starts. At the end
of the quantum key distribution phase, both nodes share a secret
key, the encryption algorithm and the TTL of the key. This key is
used in the network phase (6) while sending data. The data is
enciphered thanks to the encryption key and the algorithm. When
the TTL is expired, a new QKD phase starts. The end of the
communication is the same as the PPP.
(1) (2) (3)
+------+ +-----------+ +--------------+
| | UP | | OPENED | |SUCCESS/NONE
| Dead |------->| Establish |----------->| Authenticate |---+
| | | | | | |
+------+ +-----------+ +--------------+ |
^ | | |
| FAIL | FAIL | |
+<--------------+ +----------+ |
| | (4) |
| | +--------------+ |
| | | Encryption |<-+
| | | Negotiation |
| | +--------------+
| | |
| | TLL | Key needed/None
| | expires \|/
| | +---------+
| | +---->| QKD |----+
| | | (5) +---------+ |
| | | |
| | | |
| +-----------+ | | +---------+ |
| DOWN | | | +-------| | |
+-------------| Terminate | | | Network |<-+
| |<---+<-----------| | Key
+-----------+ CLOSING +---------+ generated/
(7) (6) None
Figure 3 - Proposed Q3P steps and operating mode
Ghernaouti and Sfaxi [Page 4]
INTERNET-DRAFT Expires: April, 29 2006
The Figure 4 gives more details about Q3P operating mode. The
modification are little so that the adaptation of the PPP
operating mode is easy to realise.
1- Dead state (Initial state):
a. When detecting an Up event then go the Establish phase
2- Establish phase:
a. Configuration packets are exchanged (LCP)
b. When finishing configuring the link connection go to the
Authentication phase
3- Authentication phase:
a. If required, the peer has to authenticate himself.
b. If the authentication succeed or it is not required then go
to Encryption negotiation phase else go to terminate phase
4- Encryption Negotiation phase:
a. If required, the two nodes negotiate the encryption protocol
parameters and the quantum key exchange parameters (such as
TTL, Key length). If not required, go the Network phase
b. After the end of the negotiation, go to QKD phase
5- QKD phase:
a. The source and the detector share a secret key exchanged
using quantum cryptography
b. When the secret key is ready go to Network phase
6- Network phase:
a. The two node exchange data
b. When the encryption TTL expires go to QKD phase
c. If the communication is finished, go to terminate phase (a
close event is generated)
7- Terminate phase:
a. Terminate messages are exchange, when finish go to Dead state
Figure 4 : The Q3P algorithm
4. Conclusion
For some needs, it is important to have the option to secure
efficiently the data transmission between two adjacent nodes.
Using quantum cryptography in conjunction with PPP offer a higher
level of security. Our study points out the adaptation of
the PPP protocol to integrate quantum key exchange (Q3P). The
modifications to PPP are identified (packet format and operating
mode).
Applying quantum key exchange and one-time-pad function at OSI
layer 2 is not only possible but will upgrade considerably, with a
low cost and less effort (modification, performances,), the
security level of a transmission between two adjacent nodes.
5. Security considerations
Our proposition do not damage PPP security mechanism but enhance
if by the use of quantum key echange.
The unconditional security of quantum key distribution has been
already proven.
Ghernaouti and Sfaxi [Page 5]
INTERNET-DRAFT Expires: April, 29 2006
6. Authors Address
Solange Ghernaouti-Helie
HEC,
University of Lausanne
1015 Lausanne, Switzerland.
EMail: sgh@unil.ch
Mohamed Ali Sfaxi
HEC,
University of Lausanne
1015 Lausanne, Switzerland.
EMail: mohamedali.sfaxi@unil.ch
7 . References
[1] Bennet, C; Brassard, G (1984). IEEE International Conference
on Computers, Systems, and Signal Processing. IEEE Press, LOS
ALAMITOS
[2] Elliott, C (2002). Building the quantum network. New Journal
of Physics 4 (46.1-46.12)
[3] Elliott, C; Pearson, D; Troxel, G (2003). Quantum
Cryptography in Practice.
[4] Gisin, N; Ribordy, G; Tittel, W; Zbinden, H. (2002). Quantum
Cryptography. Reviews of Modern Physics 74 (2002).
[5] Ghernaouti H´elie, S; Sfaxi, M.A; Ribordy, G; Gay, O (2005).
Using Quantum Key Distribution within IPSEC to secure MAN
communications. MAN 2005 conference.
[6] Guenther, C (2003) The Relevance of Quantum Cryptography in
Modern Cryptographic Systems. GSEC Partical Requirements
(v1.4b).
http://www.giac.org/practical/GSEC/Christoph_Guenther_GSEC.pdf
[7] Internet Assigned Numbers Authority - IANA (2005).
http://www.iana.org/numbers.html
[8] Paterson, K.G; Piper, f; Schack, R (2004). Why Quantum
Cryptography?. http://eprint.iacr.org/2004/156.pdf
Ghernaouti and Sfaxi [Page 6]
INTERNET-DRAFT Expires: April, 29 2006
[9] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Internet Engineering
Task Force, March 1997.
[10]Schneier, B (1996). Applied Cryptography Second Edition. New
York: John Wiley & Sons, 1996
[11]Shannon, C.E (1949). Communication theory of secrecy
systems. Bell System Technical Journal 28-4.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Ghernaouti and Sfaxi [Page 7]
INTERNET-DRAFT Expires: April, 29 2006
Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ghernaouti and Sfaxi [Page 8]