idnits 2.17.1 draft-ietf-pppext-encryption-04.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-26) 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 46: '... o MUST -- the item is an absolute ...' RFC 2119 keyword, line 48: '... MUST is only used where it is ac...' RFC 2119 keyword, line 52: '... o SHOULD -- the item should be fol...' RFC 2119 keyword, line 55: '... o MAY or optional -- the item is t...' RFC 2119 keyword, line 139: '...n implementation MUST NOT transmit dat...' (22 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 (May 1994) is 10939 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' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G.M. Meyer 2 Internet Draft Spider Systems 3 Expires Nov 30, 1995 May 1994 5 The PPP Encryption Control Protocol (ECP) 6 draft-ietf-pppext-encryption-04.txt 8 Status of this Memo 10 This document is a submission to the Point-to-Point Protocol Working 11 Group of the Internet Engineering Task Force (IETF). Comments should 12 be submitted to the ietf-ppp@merit.edu mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months, and may be updated, replaced, or obsoleted by other documents 23 at any time. It is not appropriate to use Internet Drafts as 24 reference material, or to cite them other than as a ``working draft'' 25 or ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net 30 Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 Abstract 34 The Point-to-Point Protocol (PPP) [1] provides a standard method for 35 transporting multi-protocol datagrams over point-to-point links. PPP 36 also defines an extensible Link Control Protocol. 38 This document defines a method for negotiating data encryption over 39 PPP links. 41 Conventions 43 The following language conventions are used in the items of 44 specification in this document: 46 o MUST -- the item is an absolute requirement of the specification. 48 MUST is only used where it is actually required for interopera- 49 tion, not to try to impose a particular method on implementors 50 where not required for interoperability. 52 o SHOULD -- the item should be followed for all but exceptional cir- 53 cumstances. 55 o MAY or optional -- the item is truly optional and may be followed 56 or ignored according to the needs of the implementor. 58 The words "should" and "may" are also used, in lower case, in 59 their more ordinary senses. 61 Table of Contents 63 1. Introduction ........................................... 2 65 2. Encryption Control Protocol (ECP) ...................... 3 66 2.1 Sending Encrypted Datagrams ....................... 4 68 3. Additional Packets ..................................... 5 69 3.1 Reset-Request and Reset-Ack ....................... 5 71 4. ECP Configuration Options .............................. 7 72 4.1 Proprietary Encryption OUI ........................ 7 73 4.2 Publicly Available Encryption Types ............... 9 74 4.3 Negotiating an Encryption Algorithm ............... 9 76 5. Security Considerations ................................ 10 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 83 established, 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 99 Protocol (LCP). ECP packets may not be exchanged until PPP has 100 reached the Network-Layer Protocol phase. ECP packets received 101 before this phase is reached should be silently discarded. 103 The Encryption Control Protocol is exactly the same as LCP [1] with 104 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 (decimal) codes 1 through 7 (Configure-Request, 126 Configure-Ack, Configure-Nak, Configure-Reject, Terminate- 127 Request, Terminate-Ack and Code-Reject); And may also use code 128 14 (Reset-Request) and code 15 (Reset-Ack). Other codes should 129 be treated as unrecognised and 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 136 Determination to finish before timing out waiting for a 137 Configure-Ack or other response. 139 An implementation MUST NOT transmit data until ECP negotiation 140 has completed successfully. If ECP negotiation is not 141 successful the link SHOULD 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: 160 o The first method is to encrypt the data prior to sending it out 161 through the multiple links. 163 The PPP Protocol field MUST indicate type hex 0053. 165 o The second is to treat each link as a separate connection, that 166 may or may not have encryption enabled. 168 On links which have negotiated encryption, the PPP Protocol field 169 MUST be type hex 0055 (Individual link encrypted datagram). 171 Only one encryption algorithm in each direction is in use at a time, 172 and that is negotiated prior to sending the first encrypted frame. 173 The PPP Protocol field of the encrypted datagram indicates that the 174 frame is encrypted, but not the algorithm with which it was 175 encrypted. 177 The maximum length of an encrypted packet transmitted over a PPP link 178 is the same as the maximum length of the Information field of a PPP 179 encapsulated packet. If the encryption algorithm is likely to 180 increase the size of the message beyond that, multilink should also 181 be negotiated to allow fragmentation of the frames (even if only 182 using a single link). 184 If the encryption algorithm carries history between frames, the 185 encryption algorithm must supply a way of determining if it is 186 passing data reliably, or it must require the use of a reliable 187 transport such as LAPB [3]. 189 Compression may also be negotiated using the Compression Control 190 Protocol [5]. To ensure interoperability, plain text MUST be: 192 o First compressed. 194 o Then encrypted. 196 This order has been chosen since it should result in smaller output 197 and more secure encryption. 199 3. Additional Packets 201 The Packet format and basic facilities are already defined for LCP 202 [1]. 204 Up-to-date values of the ECP Code field are specified in the most 205 recent "Assigned Numbers" RFC [4]. This specification concerns the 206 following values: 208 14 Reset-Request 209 15 Reset-Ack 211 3.1 Reset-Request and Reset-Ack 213 Description 215 ECP includes Reset-Request and Reset-Ack Codes in order to provide 216 a mechanism for indicating a decryption failure in one direction 217 of a decrypted link without affecting traffic in the other 218 direction. Some encryption algorithms may not require this 219 mechanism. 221 Individual algorithms need to specify a mechanism for determining 222 how to detect a decryption failure. On initial detection of a 223 decryption failure, an ECP implementation SHOULD transmit an ECP 224 packet with the Code field set to 14 (Reset-Request). The Data 225 field may be filled with any desired data. 227 Once a Reset-Request has been sent, any encrypted packets received 228 are discarded. Further Reset-Requests MAY be sent with the same 229 Identifier, until a valid Reset-Ack is received. 231 When the link is busy, one decryption error is usually followed by 232 several more before the Reset-Ack can be received. It is 233 undesirable to transmit Reset-Requests more frequently than the 234 round-trip-time of the link, since this will result in redundant 235 Reset-Requests and Reset-Acks being transmitted and processed. 236 The receiver MAY elect to limit transmission of Reset-Requests (to 237 say one per second) while a Reset-Ack is outstanding. 239 Upon reception of a Reset-Request, the transmitting encrypter is 240 reset to an initial state. An ECP packet MUST be transmitted with 241 the Code field set to 15 (Reset-Ack), the Identifier field copied 242 from the Reset-Request packet, and the Data field filled with any 243 desired data. 245 On receipt of a Reset-Ack, the receiving decrypter is reset to an 246 initial state. Since there may be several Reset-Acks in the pipe, 247 the decrypter MUST be reset for each Reset-Ack which matches the 248 currently expected identifier. 250 A summary of the Reset-Request and Reset-Ack packet formats is 251 shown below. The fields are transmitted from left to right. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Code | Identifier | Length | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Data ... 259 +-+-+-+-+ 261 Code 263 14 for Reset-Request; 265 15 for Reset-Ack. 267 Identifier 269 On transmission, the Identifier field MUST be changed whenever the 270 content of the Data field changes, and whenever a valid reply has 271 been received for a previous request. For retransmissions, the 272 Identifier SHOULD remain unchanged. 274 On reception, the Identifier field of the Reset-Request is copied 275 into the Identifier field of the Reset-Ack packet. 277 Data 279 The Data field is zero or more octets and contains uninterpreted 280 data for use by the sender. The data may consist of any binary 281 value and may be of any length from zero to the peer's established 282 MRU minus four. 284 4. ECP Configuration Options 286 ECP Configuration Options allow negotiation of encryption algorithms 287 and their parameters. ECP uses the same Configuration Option format 288 defined for LCP [1], with a separate set of Options. 290 Configuration Options, in this protocol, indicate algorithms that the 291 receiver is willing or able to use to decrypt data sent by the 292 sender. Systems may offer to accept several algorithms, and 293 negotiate a single one that will be used. 295 Up-to-date values of the ECP Option Type field are specified in the 296 most recent "Assigned Numbers" RFC [4]. Current values are assigned 297 as follows: 299 ECP Option Encryption type 301 0 OUI 302 1 DESE 304 All compliant ECP implementations SHOULD implement ECP option 1 - the 305 PPP DES Encryption Protocol (DESE) [6]. 307 Vendors who want to use proprietary encryption MAY use the OUI 308 mechanism to negotiate these without recourse to requesting an 309 assigned option number from the Internet Assigned Number Authority. 311 4.1 Proprietary Encryption OUI 313 Description 315 This Configuration Option provides a way to negotiate the use of a 316 proprietary encryption protocol. 318 Vendor's encryption protocols are distinguished from each other by 319 means of an Organisationally Unique Identifier (OUI), namely the 320 first three octets of a Vendor's Ethernet address assigned by IEEE 321 802. 323 Since the first matching encryption will be used, it is 324 recommended that any known OUI encryption options be transmitted 325 first, before the common options are used. 327 Before accepting this option, the implementation must verify that 328 the OUI identifies a proprietary algorithm that the implementation 329 can decrypt, and that any vendor specific negotiation values are 330 fully understood. 332 A summary of the Proprietary Encryption OUI Configuration Option 333 format is shown below. The fields are transmitted from left to 334 right. 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | OUI ... 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 OUI | Subtype | Values... 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 344 Type 346 0 348 Length 350 >= 6 352 IEEE OUI 354 The IEEE OUI is the most significant three octets of an Ethernet 355 Physical Address, assigned to the vendor by IEEE 802. This 356 identifies the option as being proprietary to the indicated 357 vendor. The bits within the octet are in canonical order, and the 358 most significant octet is transmitted first. 360 Subtype 362 This field is specific to each OUI, and indicates an encryption 363 type for that OUI. There is no standardisation for this field. 364 Each OUI implements its own values. 366 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 Publicly Available 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 should be made available to interested parties, 379 but may have certain licencing or export restrictions associated 380 with them. For additional information, refer to the encryption 381 protocol documents 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 4.3 Negotiating an Encryption Algorithm 407 ECP uses LCP option negotiation techniques to negotiate encryption 408 algorithms. In contrast with most other LCP or NCP negotiation of 409 multiple options, ECP negotiation is expected to converge on a single 410 mutually agreeable option (encryption algorithm) - or none. 411 Encryption SHOULD be negotiated in both directions, but the 412 algorithms MAY be different. 414 An implementation willing to decrypt using a particular encryption 415 algorithm (or one of a set of algorithms) offers the algorithm(s) as 416 an option (or options) in an ECP Configure-Request - call this end 417 the Decrypter; call the peer the Encrypter. 419 A Decrypter supporting more than one encryption algorithm may send a 420 Configure-Request containing either: 422 o an ordered list of options, with the most-preferred encryption 423 algorithm coming first. 425 o Or may just offer its preferred (not already Rejected) option. 427 An Encrypter wishing to accept the first option (of several) MAY 428 Configure-Ack ALL Options to indicate complete acceptance of the 429 first-listed, preferred, algorithm. 431 Otherwise, if the Encrypter does not recognise - or is unwilling to 432 support - an option it MUST send a Configure-Reject for that option. 433 Where more than one option is offered, the Encrypter SHOULD 434 Configure-Reject all but a single preferred option. 436 If the Encrypter Configure-Rejects all offered ECP options - and the 437 Decrypter has no further (non-rejected) options it can offer in a 438 Configure-Request - the Encrypter SHOULD take the link down. 440 If the Encrypter recognises an option, but it is not acceptable due 441 to values in the request (or optional parameters not in the request), 442 it MUST send a Configure-Nak with the option modified appropriately. 443 The Configure-Nak MUST contain only those options that will be 444 acceptable. The Decrypter SHOULD send a new Configure-Request with 445 only the single preferred option, adjusted as specified in the 446 Configure-Nak. 448 5. Security Considerations 450 Negotiation of encryption using PPP is designed to provide protection 451 against eavesdropping on that link. The strength of the protection 452 is dependent on the encryption algorithm used and the care with which 453 any 'secret' used by the encryption algorithm is protected. 455 It must be recognised that complete security can only be obtained 456 through end-to-end security between hosts. 458 References 460 [1] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", RFC 461 1548, Computer Systems Consulting Services, December 1993. 463 [2] Sklower, K., Lloyd, B., McGregor, G. and Carr, D., "The PPP 464 Multilink Protocol (MP)", RFC 1717, University of California, 465 Berkeley, November 1994. 467 [3] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July 468 1994. 470 [4] Reynolds, J., and Postel, J.; "ASSIGNED NUMBERS", RFC 1700, 471 USC/Information Sciences Institute, October 1994. 473 [5] Rand, D., "The PPP Compression Control Protocol (CCP)", work in 474 progress, Novell. 476 [6] Sklower, K., and Meyer, G. "The PPP DES Encryption Protocol 477 (DESE)", work in progress, University of California, Berkeley. 479 Acknowledgements 481 The style and approach of this proposal owes much to the work on the 482 Compression CP [5]. 484 Chair's Address 486 The working group can be contacted via the current chair: 488 Fred Baker 489 Cisco Systems 490 519 Lado Drive 491 Santa Barbara 492 California 93111 493 Email: fred@cisco.com 495 Author's Address: 497 Gerry Meyer 498 Spider Systems 499 Stanwell Street 500 Edinburgh EH6 5NG 501 Scotland, UK 503 Phone: (UK) 131 554 9424 504 Fax: (UK) 131 554 0649 505 Email: gerry@spider.co.uk