[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: We are resending this message as we have not yet seen a response. Thank you for your assistance. Michelle Cotton IANA > [michelle.cotton - Mon Oct 10 11:44:50 2005]: > > 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