Internet DRAFT - draft-ghernaouti-sfaxi-ppp-qkd

draft-ghernaouti-sfaxi-ppp-qkd



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). That’s 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]