idnits 2.17.1 draft-ietf-pppext-encryption-02.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 (Feb 1995) is 10660 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 Aug 10, 1995 Feb 1995 6 The PPP Encryption Control Protocol (ECP) 7 draft-ietf-pppext-encryption-02.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 Since the first matching encryption will be used, it is recom- 320 mended that any known OUI encryption options be transmitted first, 321 before the common options are used. 323 Before accepting this option, the implementation must verify that 324 the Organisation Unique Identifier identifies a proprietary algo- 325 rithm that the implementation can decrypt, and that any vendor 326 specific negotiation values are fully understood. 328 A summary of the Proprietary Encryption OUI Configuration Option 329 format is shown below. The fields are transmitted from left to 330 right. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Type | Length | OUI ... 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 OUI | Subtype | Values... 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 340 Type 342 0 344 Length 346 >= 6 348 IEEE OUI 350 The vendor's IEEE Organisation Unique Identifier (OUI), which is 351 the most significant three octets of an Ethernet Physical Address, 352 assigned to the vendor by IEEE 802. This identifies the option as 353 being proprietary to the indicated vendor. The bits within the 354 octet are in canonical order, and the most significant octet is 355 transmitted first. 357 Subtype 359 This field is specific to each OUI, and indicates an encryption 360 type for that OUI. There is no standardisation for this field. 361 Each OUI implements its own values. 363 Values 364 This field is zero or more octets, and contains additional data as 365 determined by the vendor's encryption protocol. 367 4.2 Other Encryption Types 369 Description 371 These Configuration Options provide a way to negotiate the use of 372 a publicly defined encryption algorithm. 374 These protocols will be made available to all interested parties, 375 but may have certain licencing restrictions associated with them. 376 For additional information, refer to the encryption protocol docu- 377 ments that define each of the encryption types. 379 A summary of the Encryption Type Configuration Option format is 380 shown below. The fields are transmitted from left to right. 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Type | Length | Values... 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 388 Type 390 1 to 254 392 Length 394 >= 2 396 Values 398 This field is zero or more octets, and contains additional data as 399 determined by the encryption protocol. 401 5. Security Considerations 403 Negotiation of encryption using PPP is designed to provide protection 404 against eavesdropping on that link. The strength of the protection 405 is dependent on the encryption algorithm used and the care with which 406 any 'secrets' used by the encryption algorithm is protected. 408 It must be recognised that complete security can only be obtained 409 through end-to-end security between hosts. 411 References 413 [1] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", RFC 414 1548, Computer Systems Consulting Services, December 1993. 416 [2] Sklower, K., Lloyd, B., McGregor, G. and Carr, D., "The PPP Mul- 417 tilink Protocol (MP)", RFC 1717, University of California, 418 Berkeley, November 1994. 420 [3] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July 421 1994. 423 [4] Reynolds, J., and Postel, J.; "ASSIGNED NUMBERS", RFC 1700, 424 USC/Information Sciences Institute, October 1994. 426 [5] Rand, D., "The PPP Compression Control Protocol (CCP)", work in 427 progress, Novell. 429 Acknowledgements 431 The style and approach of this proposal owes much to the work on the 432 Compression CP [5]. 434 Chair's Address 436 The working group can be contacted via the current chair: 438 Fred Baker 439 Cisco Systems 440 519 Lado Drive 441 Santa Barbara 442 California 93111 443 Email: fred@cicso.com 445 Author's Address: 447 Gerry Meyer 448 Spider Systems 449 Stanwell Street 450 Edinburgh EH6 5NG 451 Scotland, UK 453 Phone: (UK) 31 554 9424 454 Fax: (UK) 31 554 0649 455 Email: gerry@spider.co.uk