idnits 2.17.1 draft-ghernaouti-sfaxi-ppp-qkd-00.txt: -(294): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(322): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 352. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 21 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 13 instances of lines with control characters in the document. ** The abstract seems to contain references ([9]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6761 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '9' on line 318 looks like a reference -- Missing reference section? 'RFC1661' on line 173 looks like a reference -- Missing reference section? 'RFC1334' on line 57 looks like a reference -- Missing reference section? 'RFC1994' on line 58 looks like a reference -- Missing reference section? 'RFC1968' on line 60 looks like a reference -- Missing reference section? '1' on line 290 looks like a reference -- Missing reference section? '4' on line 300 looks like a reference -- Missing reference section? '8' on line 315 looks like a reference -- Missing reference section? '5' on line 303 looks like a reference -- Missing reference section? '11' on line 157 looks like a reference -- Missing reference section? '2' on line 294 looks like a reference -- Missing reference section? '3' on line 297 looks like a reference -- Missing reference section? '6' on line 307 looks like a reference -- Missing reference section? '7' on line 312 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Solange Ghernaouti-H�lie 2 INTERNET-DRAFT Mohamed Ali Sfaxi 3 University of Lausanne 4 Expires: April, 29 2006 October 2005 6 Quantum Key Destribution within Point 7 to Point Protocol (Q3P) 8 draft-ghernaouti-sfaxi-ppp-qkd-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 The aim of this paper is to analyse the use of quantum 37 cryptography within PPP. We propose a solution that integrates 38 quantum key distribution into PPP. 40 Terminology 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 43 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 44 "OPTIONAL" in this document are to be interpreted as described in 45 RFC 2119 [9]. 47 1. Introduction 49 The point to point protocol (PPP) [RFC1661] is a data-layer 50 protocol ensuring a reliable data exchange over a point to point 51 link. When the connection is established and configured, the PPP 52 allows the data transfer of many protocols (IP, IPX, AppleTalk�). 53 That's why; PPP is widely used in Internet environment. 55 The unique security of PPP as specified in the RFC 1661 is limited 56 to the authentication phase. The two nodes use an authentication 57 protocol such as Password Authentication Protocol (PAP) [RFC1334] 58 or Challenge Handshake Authentication Protocol (CHAP)[RFC1994]. In 59 1996, Meyer published an additional security protocol for PPP 60 called ECP (Encryption Control Protocol) [RFC1968]. This protocol 61 allows the use of the encryption in PPP frame. The ECP gives the 62 possibility to select the encryption algorithm and its parameters. 63 This ensures the confidentiality and the integrity of the PPP 64 frame. The weakness of this use resides in the way of generating 65 and exchanging the encryption key. In fact, for all the encryption 66 algorithms the secret key is assumed to be already shared between 67 the communicating parties. So to enhance security, we propose the 68 use of quantum cryptography to generate and to share the secret 69 key between the two nodes. 71 Quantum cryptography is the only method allowing the distribution 72 of a secret key between two distant parties without transmitting 73 any secret over unsecure channel [1, 4]. the emitter and the 74 receiver will be able to share an encryption key for enciphering 75 confidential data. The secrecy of this shared key is unconditional 76 [8] by the fact that the secret is generated and exchanged based 77 on physic laws (instead of mathematical functions). That�s why we 78 propose to integrate the quantum key distribution (QKD) process to 79 share secret key between two nodes. 81 2. Encryption Control Protocol (ECP) for Quantum Key Distribution 82 (QKD) 84 The Encryption Control Protocol (ECP) defines the negotiation of 85 the encryption over PPP links. After using LCP to establish and 86 configure the data link, the encryption options and mechanisms 87 could be negotiated. The ECP packets exchange mechanism is nearly 88 the same as the LCP mechanism. The ECP packets are encapsulating 89 into PPP frame (a packet per frame). The type is 0x8053 to 90 indicate the Encryption Control Protocol. Two additional messages 91 are added to the code field: the Reset-Request and Reset-Ack 92 message. These two messages are used to restart the encryption 93 negotiation. An encrypted packet is encapsulated in the PPP 94 information field where the PPP protocol field indicates type 95 0x0053 (encrypted datagram). The ECP packet is presented in 96 figure 1 98 0 1 2 3 99 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 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Type | Length | Values... 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 104 Figure 1 - The Encryption Type Configuration Option format 106 ECP packet, the type represents the encryption protocol option to 107 be negotiated (for instance type 1 is DES encryption). The number 108 of octets in the packet is contained in the length field. The 109 values field gives additional data or option needed for the 110 encryption protocol. Up to now, there are only 4 encryption 111 algorithms (type 0 = OUI, type 1 = DES, type 2 = 3DES, type 3 = 112 DES modified) that could be used [5]. 114 3. Integrating QKD in PPP: QKD-PPP (Q3P) 116 In order to exchange the encryption key, a key exchange protocol 117 is necessary. In this section, we present how to integrate QKD in 118 PPP 120 3.1 ECP-QKD format 122 To establish and configure the quantum key distribution between 123 the two nodes, it is necessary to exchange some data between 124 them. We propose a specific ECP packet format to carry QKD 125 parameters (Figure 2): 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Type | Length | Key-Length 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | TTL |T| 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 135 Figure 2 - ECP packet carrying a QKD protocol 137 Type field: 138 As in the ECP standard packet the type field gives information 139 about the option of encryption protocol negotiated. For this 140 case, we will use an unassigned number for the QKD protocol. The 141 selected QKD protocol is BB84 and the request to obtain an 142 assigned number for this protocol is on going in IANA 143 organisation [5]. 145 Length field: 146 The length is number of octets in the packet and it is more than 147 �5� octets (1 octet for the type, 1 octet for the packet length, 148 2 octets for the key length and one octet for the TTL and the T 149 field). 151 Key-length field: 152 This field indicates the length of the encryption key. It is 153 ended on 16 bits and represents the size of the key in octet. The 154 key size is comprised between 1 to 65535 octets. The size can be 155 viewed as huge but we consider the possibility to use the One 156 Time Pad function as the encryption algorithm. In this case, the 157 key size must be equal to the PPP-data size [11]. 159 TTL field: 160 This field can represent either the number of messages or the 161 amount of time (in second) during which a key could be used in 162 the encryption mechanism. When the max number of messages is 163 reached or the deadline expires, the QKD starts. 165 T field: 166 The T field specifies if the TTL field concerns the number of 167 messages or the amount of time. If the value is �1�, the TTL 168 field corresponds to the amount of time in second. If it is �0�, 169 the TTL is the number of messages per key. 171 3.2 The Q3P operating mode 173 We adapt PPP connection steps [RFC1661] to integrate QKD process 174 as shown Figure 3. The three first steps of Q3P are identical 175 with PPP (phase 1 to 3). After authenticating the two nodes, the 176 negotiation of the encryption parameters starts. In this phase, 177 the encryption algorithm with its parameters is negotiated. 178 If the two nodes do not need to use encryption, then the network 179 phase starts. Else, if an encryption key is required, a QKD phase 180 begins. For Encryption negotiation (4) the nodes negotiate the 181 key length and the TTL by sending an adequate ECP packet. After 182 that (in 5), a quantum cryptography exchange starts. At the end 183 of the quantum key distribution phase, both nodes share a secret 184 key, the encryption algorithm and the TTL of the key. This key is 185 used in the network phase (6) while sending data. The data is 186 enciphered thanks to the encryption key and the algorithm. When 187 the TTL is expired, a new QKD phase starts. The end of the 188 communication is the same as the PPP. 189 (1) (2) (3) 190 +------+ +-----------+ +--------------+ 191 | | UP | | OPENED | |SUCCESS/NONE 192 | Dead |------->| Establish |----------->| Authenticate |---+ 193 | | | | | | | 194 +------+ +-----------+ +--------------+ | 195 ^ | | | 196 | FAIL | FAIL | | 197 +<--------------+ +----------+ | 198 | | (4) | 199 | | +--------------+ | 200 | | | Encryption |<-+ 201 | | | Negotiation | 202 | | +--------------+ 203 | | | 204 | | TLL | Key needed/None 205 | | expires \|/ 206 | | +---------+ 207 | | +---->| QKD |----+ 208 | | | (5) +---------+ | 209 | | | | 210 | | | | 211 | +-----------+ | | +---------+ | 212 | DOWN | | | +-------| | | 213 +-------------| Terminate | | | Network |<-+ 214 | |<---+<-----------| | Key 215 +-----------+ CLOSING +---------+ generated/ 216 (7) (6) None 218 Figure 3 - Proposed Q3P steps and operating mode 220 The Figure 4 gives more details about Q3P operating mode. The 221 modification are little so that the adaptation of the PPP 222 operating mode is easy to realise. 224 1- Dead state (Initial state): 225 a. When detecting an Up event then go the Establish phase 226 2- Establish phase: 227 a. Configuration packets are exchanged (LCP) 228 b. When finishing configuring the link connection go to the 229 Authentication phase 230 3- Authentication phase: 231 a. If required, the peer has to authenticate himself. 232 b. If the authentication succeed or it is not required then go 233 to Encryption negotiation phase else go to terminate phase 234 4- Encryption Negotiation phase: 235 a. If required, the two nodes negotiate the encryption protocol 236 parameters and the quantum key exchange parameters (such as 237 TTL, Key length). If not required, go the Network phase 238 b. After the end of the negotiation, go to QKD phase 239 5- QKD phase: 240 a. The source and the detector share a secret key exchanged 241 using quantum cryptography 242 b. When the secret key is ready go to Network phase 243 6- Network phase: 244 a. The two node exchange data 245 b. When the encryption TTL expires go to QKD phase 246 c. If the communication is finished, go to terminate phase (a 247 close event is generated) 248 7- Terminate phase: 249 a. Terminate messages are exchange, when finish go to Dead state 251 Figure 4 : The Q3P algorithm 253 4. Conclusion 255 For some needs, it is important to have the option to secure 256 efficiently the data transmission between two adjacent nodes. 257 Using quantum cryptography in conjunction with PPP offer a higher 258 level of security. Our study points out the adaptation of 259 the PPP protocol to integrate quantum key exchange (Q3P). The 260 modifications to PPP are identified (packet format and operating 261 mode). 262 Applying quantum key exchange and one-time-pad function at OSI 263 layer 2 is not only possible but will upgrade considerably, with a 264 low cost and less effort (modification, performances,), the 265 security level of a transmission between two adjacent nodes. 267 5. Security considerations 269 Our proposition do not damage PPP security mechanism but enhance 270 if by the use of quantum key echange. 271 The unconditional security of quantum key distribution has been 272 already proven. 274 6. Authors Address 276 Solange Ghernaouti-Helie 277 HEC, 278 University of Lausanne 279 1015 Lausanne, Switzerland. 280 EMail: sgh@unil.ch 282 Mohamed Ali Sfaxi 283 HEC, 284 University of Lausanne 285 1015 Lausanne, Switzerland. 286 EMail: mohamedali.sfaxi@unil.ch 288 7 . References 290 [1] Bennet, C; Brassard, G (1984). IEEE International Conference 291 on Computers, Systems, and Signal Processing. IEEE Press, LOS 292 ALAMITOS 294 [2] Elliott, C (2002). �Building the quantum network�. New Journal 295 of Physics 4 (46.1-46.12) 297 [3] Elliott, C; Pearson, D; Troxel, G (2003). �Quantum 298 Cryptography in Practice�. 300 [4] Gisin, N; Ribordy, G; Tittel, W; Zbinden, H. (2002). �Quantum 301 Cryptography�. Reviews of Modern Physics 74 (2002). 303 [5] Ghernaouti H�elie, S; Sfaxi, M.A; Ribordy, G; Gay, O (2005). 304 �Using Quantum Key Distribution within IPSEC to secure MAN 305 communications�. MAN 2005 conference. 307 [6] Guenther, C (2003) �The Relevance of Quantum Cryptography in 308 Modern Cryptographic Systems�. GSEC Partical Requirements 309 (v1.4b). 310 http://www.giac.org/practical/GSEC/Christoph_Guenther_GSEC.pdf 312 [7] Internet Assigned Numbers Authority - IANA (2005). 313 http://www.iana.org/numbers.html 315 [8] Paterson, K.G; Piper, f; Schack, R (2004). �Why Quantum 316 Cryptography?�. http://eprint.iacr.org/2004/156.pdf 318 [9] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, Internet Engineering 320 Task Force, March 1997. 322 [10]Schneier, B (1996). �Applied Cryptography� Second Edition. New 323 York: John Wiley & Sons, 1996 325 [11]Shannon, C.E (1949). �Communication theory of secrecy 326 systems�. Bell System Technical Journal 28-4. 328 Intellectual Property Statement 330 The IETF takes no position regarding the validity or scope of any 331 Intellectual Property Rights or other rights that might be claimed 332 to pertain to the implementation or use of the technology 333 described in this document or the extent to which any license 334 under such rights might or might not be available; nor does it 335 represent that it has made any independent effort to identify any 336 such rights. 338 Information on the procedures with respect to rights in RFC 339 documents can be found in BCP 78 and BCP 79. 341 Copies of IPR disclosures made to the IETF Secretariat and any 342 assurances of licenses to be made available, or the result of an 343 attempt made to obtain a general license or permission for the use 344 of such proprietary rights by implementers or users of this 345 specification can be obtained from the IETF on-line IPR repository 346 at http://www.ietf.org/ipr. 348 The IETF invites any interested party to bring to its attention 349 any copyrights, patents or patent applications, or other 350 proprietary rights that may cover technology that may be required 351 to implement this standard. Please address the information to the 352 IETF at ietf-ipr@ietf.org. 354 Full Copyright Statement 356 Copyright (C) The Internet Society (2005). This document is 357 subject to the rights, licenses and restrictions contained in BCP 358 78, and except as set forth therein, the authors retain all their 359 rights. 361 This document and the information contained herein are provided on 362 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 363 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 364 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 365 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 366 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 367 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 368 PARTICULAR PURPOSE. 370 Acknowledgement 372 Funding for the RFC Editor function is currently provided by the 373 Internet Society.