idnits 2.17.1 draft-ietf-pppext-encryption-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 47: '... o MUST -- the item is an absolute ...' RFC 2119 keyword, line 49: '... MUST is only used where it is ac...' RFC 2119 keyword, line 53: '... o SHOULD -- the item should be fol...' RFC 2119 keyword, line 56: '... o MAY or optional -- the item is t...' RFC 2119 keyword, line 139: '...n implementation MUST NOT transmit dat...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (Mar 1994) is 10997 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) ** Obsolete normative reference: RFC 1548 (ref. '1') (Obsoleted by RFC 1661) ** Obsolete normative reference: RFC 1717 (ref. '2') (Obsoleted by RFC 1990) ** Obsolete normative reference: RFC 1700 (ref. '4') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G.M. Meyer 3 Internet Draft Spider Systems 4 Expires Sept 17, 1995 Mar 1994 6 The PPP Encryption Control Protocol (ECP) 7 draft-ietf-pppext-encryption-03.txt 9 Status of this Memo 11 This document is a submission to the Point-to-Point Protocol Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the ietf-ppp@merit.edu mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as 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 documents 24 at any time. It is not appropriate to use Internet Drafts as 25 reference material, or to cite them other than as a ``working draft'' 26 or ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 30 Directories on ds.internic.net (US East Coast), nic.nordu.net 31 Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 33 Abstract 35 The Point-to-Point Protocol (PPP) [1] provides a standard method for 36 transporting multi-protocol datagrams over point-to-point links. PPP 37 also defines an extensible Link Control Protocol. 39 This document defines a method for negotiating data encryption over 40 PPP links. 42 Conventions 44 The following language conventions are used in the items of 45 specification in this document: 47 o MUST -- the item is an absolute requirement of the specification. 49 MUST is only used where it is actually required for interopera- 50 tion, not to try to impose a particular method on implementors 51 where not required for interoperability. 53 o SHOULD -- the item should be followed for all but exceptional cir- 54 cumstances. 56 o MAY or optional -- the item is truly optional and may be followed 57 or ignored according to the needs of the implementor. 59 The words "should" and "may" are also used, in lower case, in 60 their more ordinary senses. 62 Table of Contents 64 1. Introduction ........................................... 2 66 2. Encryption Control Protocol (ECP) ...................... 3 67 2.1 Sending Encrypted Datagrams ....................... 4 69 3. Additional Packets ..................................... 5 70 3.1 Reset-Request and Reset-Ack ....................... 5 72 4. ECP Configuration Options .............................. 6 73 4.1 Proprietary Encryption OUI ........................ 7 74 4.2 Other Encryption Types ............................ 9 76 5. Security Considerations ................................ 9 78 1. Introduction 80 In order to establish communications over a PPP link, each end of the 81 link must first send LCP packets to configure and test the data link 82 during Link Establishment phase. After the link has been esta- 83 blished, optional facilities may be negotiated as needed. 85 One such facility is data encryption. A wide variety of encryption 86 methods may be negotiated, although typically only one method is used 87 in each direction of the link. 89 A different encryption algorithm may be negotiated in each direction, 90 for speed, cost, memory or other considerations. 92 2. Encryption Control Protocol (ECP) 94 The Encryption Control Protocol (ECP) is responsible for configuring 95 and enabling data encryption algorithms on both ends of the point- 96 to-point link. 98 ECP uses the same packet exchange mechanism as the Link Control Pro- 99 tocol (LCP). ECP packets may not be exchanged until PPP has reached 100 the Network-Layer Protocol phase. ECP packets received before this 101 phase is reached should be silently discarded. 103 The Encryption Control Protocol is exactly the same as the Link Con- 104 trol Protocol [1] with the following exceptions: 106 Frame Modifications 108 The packet may utilise any modifications to the basic frame 109 format which have been negotiated during the Link Establishment 110 phase. 112 Data Link Layer Protocol Field 114 Exactly one ECP packet is encapsulated in the PPP Information 115 field, where the PPP Protocol field indicates type hex 8053 116 (Encryption Control Protocol). 118 When individual link data encryption is used in a multiple link 119 connection to a single destination [2], the PPP Protocol field 120 indicates type hex 8055 (Individual link Encryption Control 121 Protocol). 123 Code field 125 ECP uses codes 1 through 7 (Configure-Request, Configure-Ack, 126 Configure-Nak, Configure-Reject, Terminate-Request, Terminate- 127 Ack and Code-Reject), code 14 (Reset-Request) and code 15 128 (Reset-Ack). Other Codes should be treated as unrecognised and 129 should result in Code-Rejects. 131 Negotiation 133 ECP packets may not be exchanged until PPP has reached the 134 Network-Layer Protocol phase. An implementation should be 135 prepared to wait for Authentication and Link Quality Determina- 136 tion to finish before timing out waiting for a Configure-Ack or 137 other response. 139 An implementation MUST NOT transmit data until ECP negotiation 140 has completed successfully. And if ECP negotiation is not suc- 141 cessful the link MUST be brought down. 143 Configuration Option Types 145 ECP has a distinct set of Configuration Options. 147 2.1 Sending Encrypted Datagrams 149 Before any encrypted packets may be communicated, PPP must reach the 150 Network-Layer Protocol phase, and the Encryption Control Protocol 151 must reach the Opened state. 153 An encrypted packet is encapsulated in the PPP Information field, 154 where the PPP Protocol field indicates type hex 0053 (Encrypted 155 datagram). 157 When using multiple PPP links to a single destination [2], there are 158 two methods of employing data encryption. The first method is to 159 encrypt the data prior to sending it out through the multiple links. 160 The second is to treat each link as a separate connection, that may 161 or may not have encryption enabled. In the second case, the PPP Pro- 162 tocol field MUST be type hex 0055 (Individual link encrypted 163 datagram). 165 Only one primary algorithm in each direction is in use at a time, and 166 that is negotiated prior to sending the first encrypted frame. The 167 PPP Protocol field of the encrypted datagram indicates that the frame 168 is encrypted, but not the algorithm with which it was encrypted. 170 The maximum length of an encrypted packet transmitted over a PPP link 171 is the same as the maximum length of the Information field of a PPP 172 encapsulated packet. If the encryption algorithm is likely to 173 increase the size of the message beyond that, multilink should also 174 be negotiated to allow fragmentation of the frames (even if only 175 using a single link). 177 If the encryption algorithm carries history between frames, the 178 encryption algorithm must supply a way of determining if it is pass- 179 ing data reliably, or it must require the use of a reliable transport 180 such as LAPB [3]. 182 If both compression and encryption have been negotiated, compression 183 MUST be performed on the data prior to encryption. It is explicitly 184 stated here to aid interoperability. Performing them in this order 185 should maximise the effect of compression. Truly encrypted data is 186 unlikely to be compressible. 188 3. Additional Packets 190 The Packet format and basic facilities are already defined for LCP 191 [1]. 193 Up-to-date values of the ECP Code field are specified in the most 194 recent "Assigned Numbers" RFC [4]. This specification concerns the 195 following values: 197 14 Reset-Request 198 15 Reset-Ack 200 3.1 Reset-Request and Reset-Ack 202 Description 204 ECP includes Reset-Request and Reset-Ack Codes in order to provide 205 a mechanism for indicating a decryption failure in one direction 206 of a decrypted link without affecting traffic in the other direc- 207 tion. Individual algorithms need to specify a mechanism for 208 determining how to detect a decryption failure. Some algorithms 209 may not require this facility. 211 On initial detection of a decryption failure, an ECP implementa- 212 tion SHOULD transmit an ECP packet with the Code field set to 14 213 (Reset-Request). The Data field may be filled with any desired 214 data. 216 Once a Reset-Request has been sent, any encrypted packets received 217 are discarded. Further Reset-Requests MAY be sent with the same 218 Identifier, until a valid Reset-Ack is received. 220 When the link is busy, one decryption error is usually followed by 221 several more before the Reset-Ack can be received. It is undesir- 222 able to transmit Reset-Requests more frequently than the round- 223 trip-time of the link, since this will result in redundant Reset- 224 Requests and Reset-Acks being transmitted and processed. The 225 receiver MAY elect to limit transmission of Reset-Requests (to say 226 one per second) while a Reset-Ack is outstanding. 228 Upon reception of a Reset-Request, the transmitting encrypter is 229 reset to an initial state. An ECP packet MUST be transmitted with 230 the Code field set to 15 (Reset-Ack), the Identifier field copied 231 from the Reset-Request packet, and the Data field filled with any 232 desired data. 234 On receipt of a Reset-Ack, the receiving decrypter is reset to an 235 initial state. Since there may be several Reset-Acks in the pipe, 236 the decrypter MUST be reset for each Reset-Ack which matches the 237 currently expected identifier. 239 A summary of the Reset-Request and Reset-Ack packet formats is 240 shown below. The fields are transmitted from left to right. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Code | Identifier | Length | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Data ... 248 +-+-+-+-+ 250 Code 252 14 for Reset-Request; 254 15 for Reset-Ack. 256 Identifier 258 On transmission, the Identifier field MUST be changed whenever the 259 content of the Data field changes, and whenever a valid reply has 260 been received for a previous request. For retransmissions, the 261 Identifier MAY remain unchanged. 263 On reception, the Identifier field of the Reset-Request is copied 264 into the Identifier field of the Reset-Ack packet. 266 Data 268 The Data field is zero or more octets and contains uninterpreted 269 data for use by the sender. The data may consist of any binary 270 value and may be of any length from zero to the peer's established 271 MRU minus four. 273 4. ECP Configuration Options 275 ECP Configuration Options allow negotiation of encryption algorithms 276 and their parameters. ECP uses the same Configuration Option format 277 defined for LCP [1], with a separate set of Options. 279 Configuration Options, in this protocol, indicate algorithms that the 280 receiver is willing or able to use to decrypt data sent by the 281 sender. Systems may offer to accept several algorithms, and nego- 282 tiate a single one that will be used. 284 There is the possibility of not being able to agree on an encryption 285 algorithm. In that case the link MUST be brought down. 287 We expect that many vendors will want to use proprietary encryption 288 algorithms, and have made a mechanism available to negotiate these 289 without encumbering the Internet Assigned Number Authority with 290 proprietary number requests. 292 The LCP option negotiation techniques are used. If an option is 293 unrecognised, a Configure-Reject MUST be sent. If all protocols the 294 sender implements are Configure-Rejected by the receiver the link 295 MUST be brought down. 297 If an option is recognised, but not acceptable due to values in the 298 request (or optional parameters not in the request), a Configure-Nak 299 MUST be sent with the option modified appropriately. The Configure- 300 Nak MUST contain only those options that will be acceptable. A new 301 Configure-Request SHOULD be sent with only the single preferred 302 option, adjusted as specified in the Configure-Nak. 304 Up-to-date values of the ECP Option Type field are specified in the 305 most recent "Assigned Numbers" RFC [4]. Current values are assigned 306 as follows: 308 ECP Option Encryption type 310 0 OUI 312 4.1 Proprietary Encryption OUI 314 Description 316 This Configuration Option provides a way to negotiate the use of a 317 proprietary encryption protocol. 319 Vendor's encryption protocols are distinguished from each other by 320 means of an Organisationally Unique Identifier (OUI), namely the 321 first three octets of a Vendor's Ethernet address assigned by the 322 IEEE Standards Office. 324 Since the first matching encryption will be used, it is recom- 325 mended that any known OUI encryption options be transmitted first, 326 before the common options are used. 328 Before accepting this option, the implementation must verify that 329 the OUI identifies a proprietary algorithm that the implementation 330 can decrypt, and that any vendor specific negotiation values are 331 fully understood. 333 A summary of the Proprietary Encryption OUI Configuration Option 334 format is shown below. The fields are transmitted from left to 335 right. 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type | Length | OUI ... 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 OUI | Subtype | Values... 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 345 Type 347 0 349 Length 351 >= 6 353 IEEE OUI 355 The IEEE OUI is the most significant three octets of an Ethernet 356 Physical Address, assigned to the vendor by IEEE 802. This iden- 357 tifies the option as being proprietary to the indicated vendor. 358 The bits within the octet are in canonical order, and the most 359 significant octet is transmitted first. 361 Subtype 363 This field is specific to each OUI, and indicates an encryption 364 type for that OUI. There is no standardisation for this field. 365 Each OUI implements its own values. 367 Values 368 This field is zero or more octets, and contains additional data as 369 determined by the vendor's encryption protocol. 371 4.2 Other Encryption Types 373 Description 375 These Configuration Options provide a way to negotiate the use of 376 a publicly defined encryption algorithm. 378 These protocols will be made available to all interested parties, 379 but may have certain licencing restrictions associated with them. 380 For additional information, refer to the encryption protocol docu- 381 ments that define each of the encryption types. 383 A summary of the Encryption Type Configuration Option format is 384 shown below. The fields are transmitted from left to right. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type | Length | Values... 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 392 Type 394 1 to 254 396 Length 398 >= 2 400 Values 402 This field is zero or more octets, and contains additional data as 403 determined by the encryption protocol. 405 5. Security Considerations 407 Negotiation of encryption using PPP is designed to provide protection 408 against eavesdropping on that link. The strength of the protection 409 is dependent on the encryption algorithm used and the care with which 410 any 'secrets' used by the encryption algorithm is protected. 412 It must be recognised that complete security can only be obtained 413 through end-to-end security between hosts. 415 References 417 [1] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", RFC 418 1548, Computer Systems Consulting Services, December 1993. 420 [2] Sklower, K., Lloyd, B., McGregor, G. and Carr, D., "The PPP Mul- 421 tilink Protocol (MP)", RFC 1717, University of California, 422 Berkeley, November 1994. 424 [3] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July 425 1994. 427 [4] Reynolds, J., and Postel, J.; "ASSIGNED NUMBERS", RFC 1700, 428 USC/Information Sciences Institute, October 1994. 430 [5] Rand, D., "The PPP Compression Control Protocol (CCP)", work in 431 progress, Novell. 433 Acknowledgements 435 The style and approach of this proposal owes much to the work on the 436 Compression CP [5]. 438 Chair's Address 440 The working group can be contacted via the current chair: 442 Fred Baker 443 Cisco Systems 444 519 Lado Drive 445 Santa Barbara 446 California 93111 447 Email: fred@cicso.com 449 Author's Address: 451 Gerry Meyer 452 Spider Systems 453 Stanwell Street 454 Edinburgh EH6 5NG 455 Scotland, UK 457 Phone: (UK) 31 554 9424 458 Fax: (UK) 31 554 0649 459 Email: gerry@spider.co.uk