idnits 2.17.1 draft-ietf-pppext-encryption-01.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-03-29) 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 138: '...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 (Dec 1994) is 10697 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. -------------------------------------------------------------------------------- 1 Network Working Group G.M. Meyer 2 Internet Draft Spider Systems 3 Expires Jun 17, 1995 Dec 1994 5 The PPP Encryption Control Protocol (ECP) 6 draft-ietf-pppext-encryption-01.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 .............................. 6 72 4.1 Proprietary Encryption OUI ........................ 7 73 4.2 Other Encryption Types ............................ 9 75 5. Security Considerations ................................ 9 77 1. Introduction 79 In order to establish communications over a PPP link, each end of the 80 link must first send LCP packets to configure and test the data link 81 during Link Establishment phase. After the link has been esta- 82 blished, optional facilities may be negotiated as needed. 84 One such facility is data encryption. A wide variety of encryption 85 methods may be negotiated, although typically only one method is used 86 in each direction of the link. 88 A different encryption algorithm may be negotiated in each direction, 89 for speed, cost, memory or other considerations. 91 2. Encryption Control Protocol (ECP) 93 The Encryption Control Protocol (ECP) is responsible for configuring 94 and enabling data encryption algorithms on both ends of the point- 95 to-point link. 97 ECP uses the same packet exchange mechanism as the Link Control Pro- 98 tocol (LCP). ECP packets may not be exchanged until PPP has reached 99 the Network-Layer Protocol phase. ECP packets received before this 100 phase is reached should be silently discarded. 102 The Encryption Control Protocol is exactly the same as the Link Con- 103 trol Protocol [1] with the following exceptions: 105 Frame Modifications 107 The packet may utilise any modifications to the basic frame 108 format which have been negotiated during the Link Establishment 109 phase. 111 Data Link Layer Protocol Field 113 Exactly one ECP packet is encapsulated in the PPP Information 114 field, where the PPP Protocol field indicates type hex 8053 115 (Encryption Control Protocol). 117 When individual link data encryption is used in a multiple link 118 connection to a single destination [2], the PPP Protocol field 119 indicates type hex 8055 (Individual link Encryption Control 120 Protocol). 122 Code field 124 ECP uses codes 1 through 7 (Configure-Request, Configure-Ack, 125 Configure-Nak, Configure-Reject, Terminate-Request, Terminate- 126 Ack and Code-Reject), code 14 (Reset-Request) and code 15 127 (Reset-Ack). Other Codes should be treated as unrecognised and 128 should result in Code-Rejects. 130 Negotiation 132 ECP packets may not be exchanged until PPP has reached the 133 Network-Layer Protocol phase. An implementation should be 134 prepared to wait for Authentication and Link Quality Determina- 135 tion to finish before timing out waiting for a Configure-Ack or 136 other response. 138 An implementation MUST NOT transmit data until ECP negotiation 139 has completed successfully. And if ECP negotiation is not suc- 140 cessful the link MUST be brought down. 142 Configuration Option Types 144 ECP has a distinct set of Configuration Options. 146 2.1 Sending Encrypted Datagrams 148 Before any encrypted packets may be communicated, PPP must reach the 149 Network-Layer Protocol phase, and the Encryption Control Protocol 150 must reach the Opened state. 152 An encrypted packet is encapsulated in the PPP Information field, 153 where the PPP Protocol field indicates type hex 0053 (Encrypted 154 datagram). 156 When using multiple PPP links to a single destination [2], there are 157 two methods of employing data encryption. The first method is to 158 encrypt the data prior to sending it out through the multiple links. 159 The second is to treat each link as a separate connection, that may 160 or may not have encryption enabled. In the second case, the PPP Pro- 161 tocol field MUST be type hex 0055 (Individual link encrypted 162 datagram). 164 Only one primary algorithm in each direction is in use at a time, and 165 that is negotiated prior to sending the first encrypted frame. The 166 PPP Protocol field of the encrypted datagram indicates that the frame 167 is encrypted, but not the algorithm with which it was encrypted. 169 The maximum length of an encrypted packet transmitted over a PPP link 170 is the same as the maximum length of the Information field of a PPP 171 encapsulated packet. If the encryption algorithm is likely to 172 increase the size of the message beyond that, multilink should also 173 be negotiated to allow fragmentation of the frames (even if only 174 using a single link). 176 If the encryption algorithm carries history between frames, the 177 encryption algorithm must supply a way of determining if it is pass- 178 ing data reliably, or it must require the use of a reliable transport 179 such as LAPB [3]. 181 If both compression and encryption have been negotiated, compression 182 MUST be performed on the data prior to encryption. It is explicitly 183 stated here to aid interoperability. Performing them in this order 184 should maximise the effect of compression. Truly encrypted data is 185 unlikely to be compressible. 187 3. Additional Packets 189 The Packet format and basic facilities are already defined for LCP 190 [1]. 192 Up-to-date values of the ECP Code field are specified in the most 193 recent "Assigned Numbers" RFC [4]. This specification concerns the 194 following values: 196 14 Reset-Request 197 15 Reset-Ack 199 3.1 Reset-Request and Reset-Ack 201 Description 203 ECP includes Reset-Request and Reset-Ack Codes in order to provide 204 a mechanism for indicating a decryption failure in one direction 205 of a decrypted link without affecting traffic in the other direc- 206 tion. Individual algorithms need to specify a mechanism for 207 determining how to detect a decryption failure. Some algorithms 208 may not require this facility. 210 On initial detection of a decryption failure, an ECP implementa- 211 tion SHOULD transmit an ECP packet with the Code field set to 14 212 (Reset-Request). The Data field may be filled with any desired 213 data. 215 Once a Reset-Request has been sent, any decrypted packets received 216 are discarded. Further Reset-Requests MAY be sent with the same 217 Identifier, until a valid Reset-Ack is received. 219 When the link is busy, one decryption error is usually followed by 220 several more before the Reset-Ack can be received. It is undesir- 221 able to transmit Reset-Requests more frequently than the round- 222 trip-time of the link, since this will result in redundant Reset- 223 Requests and Reset-Acks being transmitted and processed. The 224 receiver MAY elect to limit transmission of Reset-Requests (to say 225 one per second) while a Reset-Ack is outstanding. 227 Upon reception of a Reset-Request, the transmitting encrypter is 228 reset to an initial state. An ECP packet MUST be transmitted with 229 the Code field set to 15 (Reset-Ack), the Identifier field copied 230 from the Reset-Request packet, and the Data field filled with any 231 desired data. 233 On receipt of a Reset-Ack, the receiving decrypter is reset to an 234 initial state. Since there may be several Reset-Acks in the pipe, 235 the decrypter MUST be reset for each Reset-Ack which matches the 236 currently expected identifier. 238 A summary of the Reset-Request and Reset-Ack packet formats is 239 shown below. The fields are transmitted from left to right. 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Code | Identifier | Length | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Data ... 247 +-+-+-+-+ 249 Code 251 14 for Reset-Request; 253 15 for Reset-Ack. 255 Identifier 257 On transmission, the Identifier field MUST be changed whenever the 258 content of the Data field changes, and whenever a valid reply has 259 been received for a previous request. For retransmissions, the 260 Identifier MAY remain unchanged. 262 On reception, the Identifier field of the Reset-Request is copied 263 into the Identifier field of the Reset-Ack packet. 265 Data 267 The Data field is zero or more octets and contains uninterpreted 268 data for use by the sender. The data may consist of any binary 269 value and may be of any length from zero to the peer's established 270 MRU minus four. 272 4. ECP Configuration Options 274 ECP Configuration Options allow negotiation of encryption algorithms 275 and their parameters. ECP uses the same Configuration Option format 276 defined for LCP [1], with a separate set of Options. 278 Configuration Options, in this protocol, indicate algorithms that the 279 receiver is willing or able to use to decrypt data sent by the 280 sender. Systems may offer to accept several algorithms, and nego- 281 tiate a single one that will be used. 283 There is the possibility of not being able to agree on an encryption 284 algorithm. In that case the link MUST be brought down. 286 We expect that many vendors will want to use proprietary encryption 287 algorithms, and have made a mechanism available to negotiate these 288 without encumbering the Internet Assigned Number Authority with 289 proprietary number requests. 291 The LCP option negotiation techniques are used. If an option is 292 unrecognised, a Configure-Reject MUST be sent. If all protocols the 293 sender implements are Configure-Rejected by the receiver the link 294 MUST be brought down. 296 If an option is recognised, but not acceptable due to values in the 297 request (or optional parameters not in the request), a Configure-Nak 298 MUST be sent with the option modified appropriately. The Configure- 299 Nak MUST contain only those options that will be acceptable. A new 300 Configure-Request SHOULD be sent with only the single preferred 301 option, adjusted as specified in the Configure-Nak. 303 Up-to-date values of the ECP Option Type field are specified in the 304 most recent "Assigned Numbers" RFC [4]. Current values are assigned 305 as follows: 307 ECP Option Encryption type 309 0 OUI 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 Since the first matching encryption will be used, it is recom- 319 mended that any known OUI encryption options be transmitted first, 320 before the common options are used. 322 Before accepting this option, the implementation must verify that 323 the Organisation Unique Identifier identifies a proprietary algo- 324 rithm that the implementation can decrypt, and that any vendor 325 specific negotiation values are fully understood. 327 A summary of the Proprietary Encryption OUI Configuration Option 328 format is shown below. The fields are transmitted from left to 329 right. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type | Length | OUI ... 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 OUI | Subtype | Values... 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 339 Type 341 0 343 Length 345 >= 6 347 IEEE OUI 349 The vendor's IEEE Organisation Unique Identifier (OUI), which is 350 the most significant three octets of an Ethernet Physical Address, 351 assigned to the vendor by IEEE 802. This identifies the option as 352 being proprietary to the indicated vendor. The bits within the 353 octet are in canonical order, and the most significant octet is 354 transmitted first. 356 Subtype 358 This field is specific to each OUI, and indicates an encryption 359 type for that OUI. There is no standardisation for this field. 360 Each OUI implements its own values. 362 Values 363 This field is zero or more octets, and contains additional data as 364 determined by the vendor's encryption protocol. 366 4.2 Other Encryption Types 368 Description 370 These Configuration Options provide a way to negotiate the use of 371 a publicly defined encryption algorithm. 373 These protocols will be made available to all interested parties, 374 but may have certain licencing restrictions associated with them. 375 For additional information, refer to the encryption protocol docu- 376 ments that define each of the encryption types. 378 A summary of the Encryption Type Configuration Option format is 379 shown below. The fields are transmitted from left to right. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Type | Length | Values... 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 387 Type 389 1 to 254 391 Length 393 >= 2 395 Values 397 This field is zero or more octets, and contains additional data as 398 determined by the encryption protocol. 400 5. Security Considerations 402 Negotiation of encryption using PPP is designed to provide protection 403 against eavesdropping on that link. The strength of the protection 404 is dependent on the encryption algorithm used and the care with which 405 any 'secrets' used by the encryption algorithm is protected. 407 It must be recognised that complete security can only be obtained 408 through end-to-end security between hosts. 410 References 412 [1] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", RFC 413 1548, Computer Systems Consulting Services, December 1993. 415 [2] Sklower, K., Lloyd, B., McGregor, G. and Carr, D., "The PPP Mul- 416 tilink Protocol (MP)", RFC 1717, University of California, 417 Berkeley, November 1994. 419 [3] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July 420 1994. 422 [4] Reynolds, J., and Postel, J.; "ASSIGNED NUMBERS", RFC 1700, 423 USC/Information Sciences Institute, October 1994. 425 [5] Rand, D., "The PPP Compression Control Protocol (CCP)", work in 426 progress, Novell. 428 Acknowledgements 430 The style and approach of this proposal owes much to the work on the 431 Compression CP [5]. 433 Chair's Address 435 The working group can be contacted via the current chair: 437 Fred Baker 438 Cisco Systems 439 519 Lado Drive 440 Santa Barbara 441 California 93111 442 Email: fred@cicso.com 444 Author's Address: 446 Gerry Meyer 447 Spider Systems 448 Stanwell Street 449 Edinburgh EH6 5NG 450 Scotland, UK 452 Phone: (UK) 31 554 9424 453 Fax: (UK) 31 554 0649 454 Email: gerry@spider.co.uk