[rt.icann.org #3528] FW: General Request for Assignments (ppp-numbers)
"Michelle Cotton via RT" <[email protected]>
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
PPPEXT Working Group: This is a follow-up to a recent request you were reviewing for IANA. The Working Group Chair requested that the group wanted to see the I-D before making a decision. Below, please find the I-D sent to IANA by the requestor. We will await your response. Thank you, Michelle Cotton IANA **************************************************************** As requested, please find the I-D about our PPP extension. It is called "Quantum Key Destribution within Point to Point Protocol (Q3P)" written by Solange Ghernaouti-Hélie and Mohamed Ali Sfaxi. > 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, we certify that any applicable > patent or other IPR claims of which we are aware have been disclosed, > or will be disclosed, and any of which we become aware will be > disclosed, in accordance with RFC 3668. > > 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: [email protected] > > > Mohamed Ali Sfaxi > HEC, > University of Lausanne > 1015 Lausanne, Switzerland. > EMail: [email protected] > > > > 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 [email protected]. > > > > > > > > > > > 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] > > _______________________________________________ Pppext mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pppext