idnits 2.17.1 draft-ietf-pppext-encryption-00.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-19) 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 135: '...n implementation MUST NOT transmit dat...' (9 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 (Nov 1994) is 10748 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1340 (ref. '4') (Obsoleted by RFC 1700) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 4 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 May 7, 1995 Nov 1994 6 The PPP Encryption Control Protocol (ECP) 7 draft-ietf-pppext-encryption-00.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. ECP Configuration Options .............................. 5 70 3.1 Proprietary Encryption OUI ........................ 6 71 3.2 Other Encryption Types ............................ 7 73 4. Security Considerations ................................ 7 75 1. Introduction 77 In order to establish communications over a PPP link, each end of the 78 link must first send LCP packets to configure and test the data link 79 during Link Establishment phase. After the link has been esta- 80 blished, optional facilities may be negotiated as needed. 82 One such facility is data encryption. A wide variety of encryption 83 methods may be negotiated, although typically only one method is used 84 in each direction of the link. 86 A different encryption algorithm may be negotiated in each direction, 87 for speed, cost, memory or other considerations. 89 2. Encryption Control Protocol (ECP) 91 The Encryption Control Protocol (ECP) is responsible for configuring 92 and enabling data encryption algorithms on both ends of the point- 93 to-point link. 95 ECP uses the same packet exchange mechanism as the Link Control Pro- 96 tocol (LCP). ECP packets may not be exchanged until PPP has reached 97 the Network-Layer Protocol phase. ECP packets received before this 98 phase is reached should be silently discarded. 100 The Encryption Control Protocol is exactly the same as the Link Con- 101 trol Protocol [1] with the following exceptions: 103 Frame Modifications 105 The packet may utilise any modifications to the basic frame 106 format which have been negotiated during the Link Establishment 107 phase. 109 Data Link Layer Protocol Field 111 Exactly one CCP packet is encapsulated in the PPP Information 112 field, where the PPP Protocol field indicates type hex 113 (Encryption Control Protocol). 115 When individual link data encryption is used in a multiple link 116 connection to a single destination [2], the PPP Protocol field 117 indicates type hex (Individual link Encryption Control 118 Protocol). 120 Code field 122 ECP uses codes 1 through 7 (Configure-Request, Configure-Ack, 123 Configure-Nak, Configure-Reject, Terminate-Request, Terminate- 124 Ack and Code-Reject). Other Codes should be treated as 125 unrecognised and should result in Code-Rejects. 127 Negotiation 129 ECP packets may not be exchanged until PPP has reached the 130 Network-Layer Protocol phase. An implementation should be 131 prepared to wait for Authentication and Link Quality Determina- 132 tion to finish before timing out waiting for a Configure-Ack or 133 other response. 135 An implementation MUST NOT transmit data until ECP negotiation 136 has completed successfully. And if ECP negotiation is not 137 successful the link MUST be brought down. 139 Configuration Option Types 141 ECP has a distinct set of Configuration Options. 143 2.1 Sending Encrypted Datagrams 145 Before any encrypted packets may be communicated, PPP must reach the 146 Network-Layer Protocol phase, and the Encryption Control Protocol 147 must reach the Opened state. 149 An encrypted packet is encapsulated in the PPP Information field, 150 where the PPP Protocol field indicates type hex (Encrypted 151 datagram). 153 When using multiple PPP links to a single destination [2], there are 154 two methods of employing data encryption. The first method is to 155 encrypt the data prior to sending it out through the multiple links. 156 The second is to treat each link as a separate connection, that may 157 or may not have encryption enabled. In the second case, the PPP Pro- 158 tocol field MUST be type hex (Individual link encrypted 159 datagram). 161 Only one primary algorithm in each direction is in use at a time, and 162 that is negotiated prior to sending the first encrypted frame. The 163 PPP Protocol field of the encrypted datagram indicates that the frame 164 is encrypted, but not the algorithm with which it was encrypted. 166 The maximum length of an encrypted packet transmitted over a PPP link 167 is the same as the maximum length of the Information field of a PPP 168 encapsulated packet. If the encryption algorithm is likely to 169 increase the size of the message beyond that, multilink should also 170 be negotiated to allow fragmentation of the frames (even if only 171 using a single link). 173 If the encryption algorithm carries history between frames, the 174 encryption algorithm must supply a way of determining if it is pass- 175 ing data reliably, or it must require the use of a reliable transport 176 such as LAPB [3]. 178 If both compression and encryption have been negotiated, compression 179 MUST be performed on the data prior to encryption. It is explicitly 180 stated here to aid interoperability. Performing them in this order 181 should maximise the effect of compression. Truly encrypted data is 182 unlikely to be compressible. 184 3. ECP Configuration Options 186 ECP Configuration Options allow negotiation of encryption algorithms 187 and their parameters. ECP uses the same Configuration Option format 188 defined for LCP [1], with a separate set of Options. 190 Configuration Options, in this protocol, indicate algorithms that the 191 receiver is willing or able to use to decrypt data sent by the 192 sender. Systems may offer to accept several algorithms, and nego- 193 tiate a single one that will be used. 195 There is the possibility of not being able to agree on an encryption 196 algorithm. In that case the link MUST be brought down. 198 We expect that many vendors will want to use proprietary encryption 199 algorithms, and have made a mechanism available to negotiate these 200 without encumbering the Internet Assigned Number Authority with 201 proprietary number requests. 203 The LCP option negotiation techniques are used. If an option is 204 unrecognised, a Configure-Reject MUST be sent. If all protocols the 205 sender implements are Configure-Rejected by the receiver the link 206 MUST be brought down. 208 If an option is recognised, but not acceptable due to values in the 209 request (or optional parameters not in the request), a Configure-NAK 210 MUST be sent with the option modified appropriately. The Configure- 211 NAK MUST contain only those options that will be acceptable. A new 212 Configure-Request SHOULD be sent with only the single preferred 213 option, adjusted as specified in the Configure-Nak. 215 Up-to-date values of the ECP Option Type field are specified in the 216 most recent "Assigned Numbers" RFC [4]. Current values are assigned 217 as follows: 219 CCP Option Encryption type 221 0 OUI 223 3.1 Proprietary Encryption OUI 225 Description 226 This Configuration Option provides a way to negotiate the use of a 227 proprietary encryption protocol. 229 Since the first matching encryption will be used, it is recom- 230 mended that any known OUI encryption options be transmitted first, 231 before the common options are used. 233 Before accepting this option, the implementation must verify that 234 the Organisation Unique Identifier identifies a proprietary algo- 235 rithm that the implementation can decrypt, and that any vendor 236 specific negotiation values are fully understood. 238 A summary of the Proprietary Encryption OUI Configuration Option 239 format is shown below. The fields are transmitted from left to 240 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 | Type | Length | OUI ... 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 OUI | Subtype | Values... 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 250 Type 252 0 254 Length 256 >= 6 258 IEEE OUI 260 The vendor's IEEE Organisation Unique Identifier (OUI), which is 261 the most significant three octets of an Ethernet Physical Address, 262 assigned to the vendor by IEEE 802. This identifies the option as 263 being proprietary to the indicated vendor. The bits within the 264 octet are in canonical order, and the most significant octet is 265 transmitted first. 267 Subtype 269 This field is specific to each OUI, and indicates an encryption 270 type for that OUI. There is no standardisation for this field. 271 Each OUI implements its own values. 273 Values 274 This field is zero or more octets, and contains additional data as 275 determined by the vendor's encryption protocol. 277 3.2 Other Encryption Types 279 Description 281 These Configuration Options provide a way to negotiate the use of 282 a publicly defined encryption algorithm. 284 These protocols will be made available to all interested parties, 285 but may have certain licencing restrictions associated with them. 286 For additional information, refer to the encryption protocol docu- 287 ments that define each of the encryption types. 289 A summary of the Encryption Type Configuration Option format is 290 shown below. The fields are transmitted from left to right. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | Values... 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 298 Type 300 1 to 254 302 Length 304 >= 2 306 Values 308 This field is zero or more octets, and contains additional data as 309 determined by the encryption protocol. 311 4. Security Considerations 313 Negotiation of encryption using PPP is designed to provide protection 314 against eavesdropping on that link. The strength of the protection 315 is dependent on the encryption algorithm used and the care with which 316 any 'secrets' used by the encryption algorithm is protected. 318 It must be recognised that complete security can only be obtained 319 through end-to-end security between hosts. 321 References 323 [1] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", RFC 324 1548, December 1993. 326 [2] Sklower, K., Lloyd, B., McGregor, G. and Carr, D., "The PPP Mul- 327 tilink Protocol (MP)", work in progress, University of Califor- 328 nia, Berkeley. 330 [3] Rand, D., "PPP Reliable Transmission", RFC 1663, 332 [4] Reynolds, J., and Postel, J.; "Assigned Numbers", STD 2, RFC 333 1340, USC/Information Sciences Institute, July 1992. 335 [5] Rand, D., "The PPP Compression Control Protocol (CCP)", work in 336 progress. 338 Acknowledgements 340 The style and approach of this proposal owes much to the work on the 341 Compression CP [5]. 343 Chair's Address 345 The working group can be contacted via the current chair: 347 Fred Baker 348 Cisco Systems 349 519 Lado Drive 350 Santa Barbara 351 California 93111 352 EMail: fred@cicso.com 354 Author's Address: 356 Gerry Meyer 357 Spider Systems 358 Stanwell Street 359 Edinburgh EH6 5NG 360 Scotland, UK 362 Phone: (UK) 31 554 9424 363 Fax: (UK) 31 554 0649 364 Email: gerry@spider.co.uk