[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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)

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 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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   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.


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   "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

   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

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

    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
   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
   University of Lausanne
   1015 Lausanne, Switzerland.
   EMail: sgh@unil.ch

   Mohamed Ali Sfaxi
   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

   [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

   [7] Internet Assigned Numbers Authority - IANA (2005).

   [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

   This document and the information contained herein are provided on


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Ghernaouti and Sfaxi                                         [Page 8]