idnits 2.17.1 draft-ietf-pppext-mppe-02.txt: ** The Abstract section seems to be numbered 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-25) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. 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 117 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2118, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...This document...' == Line 12 has weird spacing: '...as, and its...' == Line 17 has weird spacing: '...and may be ...' == Line 18 has weird spacing: '...ference mater...' == Line 21 has weird spacing: '...To learn the...' == (112 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2118, updated by this document, for RFC5378 checks: 1997-02-20) -- 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 (September 1998) is 9354 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '20' is mentioned on line 323, but not defined ** Obsolete normative reference: RFC 1510 (ref. '8') (Obsoleted by RFC 4120, RFC 6649) == Outdated reference: A later version (-06) exists of draft-ietf-tls-protocol-05 Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. S. Pall 2 Internet-Draft Microsoft Corporation 3 Category: Informational G. Zorn 4 Updates: RFC 2118 Microsoft Corporation 5 September 1998 7 Microsoft Point-To-Point Encryption (MPPE) Protocol 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working doc- 14 uments as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 This memo provides information for the Internet community. This memo 27 does not specify an Internet standard of any kind. The distribution of 28 this memo is unlimited. It is filed as 29 and expires March 24, 1999. Please send comments to the PPP Extensions 30 Working Group mailing list (ietf-ppp@merit.edu) or to the authors (gur- 31 deep@microsoft.com and glennz@microsoft.com). 33 2. Abstract 35 The Point-to-Point Protocol (PPP) [1] provides a standard method for 36 transporting multi-protocol datagrams over point-to-point links. 38 The PPP Compression Control Protocol [2] provides a method to negotiate 39 and utilize compression protocols over PPP encapsulated links. 41 This document describes the use of the Microsoft Point to Point Encryp- 42 tion (MPPE) to enhance the confidentiality of encrypted PPP-encapsulated 43 packets. 45 3. Introduction 47 The Microsoft Point to Point Encryption scheme is a means of represent- 48 ing Point to Point Protocol (PPP) packets in an encrypted form. 50 MPPE uses the RSA RC4 [3] algorithm to provide data confidentiality. 51 The length of the session key to be used for initializing encryption 52 tables can be negotiated. MPPE currently supports 40-bit and 128-bit 53 session keys. 55 MPPE session keys are changed frequently; the exact frequency depends 56 upon the options negotiated, but may be every packet. 58 MPPE is negotiated within option 18 [4] in the Compression Control Pro- 59 tocol. 61 4. Specification of Requirements 63 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 64 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 65 described in [5]. 67 5. Configuration Option Format 69 Description 71 The CCP Configuration Option negotiates the use of MPPE on the link. 72 By default (i.e., if the negotiation of MPPE is not attempted), no 73 encryption is used. If, however, MPPE negotiation is attempted and 74 fails, the link SHOULD be terminated. 76 A summary of the CCP Configuration Option format is shown below. The 77 fields are transmitted from left to right. 79 0 1 2 3 80 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 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 | Type | Length | Supported Bits | 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 | Supported Bits | 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 Type 89 18 91 Length 93 6 95 Supported Bits 97 This field is 4 octets, most significant octet first. 99 3 2 1 100 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | |H| |S|L|D| |C| 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 The 'C' bit is used by MPPC [4] and is not discussed further in this 106 memo. The 'D' bit is obsolete; although some older peers may attempt 107 to negotiate this option, it SHOULD NOT be accepted. If the 'L' bit 108 is set (corresponding to a value of 0x20 in the least significant 109 octet), this indicates the desire of the sender to negotiate the use 110 of 40-bit session keys. If the 'S' bit is set (corresponding to a 111 value of 0x40 in the least significant octet), this indicates the 112 desire of the sender to negotiate the use of 128-bit session keys. 113 If the 'H' bit is set (corresponding to a value of 0x01 in the most 114 significant octet), this indicates that the sender wishes to negoti- 115 ate the use of stateless mode, in which the session key is changed 116 after the transmission of each packet (see section 10, below). In 117 the following discussion, the 'S' and 'L' bits are sometimes referred 118 to collectively as "encryption options". 120 All other bits are reserved and MUST be set to 0. 122 5.1. Option Negotiation 124 MPPE options are negotiated as described in [2]. In particular, the 125 negotiation initiator SHOULD request all of the options it supports. 126 The responder SHOULD NAK with a single encryption option (note that 127 stateless mode may always be negotiated, independent of and in addition 128 to an encryption option). If the responder supports more than one 129 encryption option in the set requested by the initiator, the option 130 selected SHOULD be the "strongest" option offered. Informally, the 131 strength of the MPPE encryption options may be characterized as follows: 133 STRONGEST 134 128-bit encryption ('S' bit set) 135 40-bit encryption ('L' bit set) 136 WEAKEST 138 This characterization takes into account the generally accepted strength 139 of the cipher. 141 The initiator SHOULD then either send another request containing the 142 same option(s) as the responder's NAK or cancel the negotiation, drop- 143 ping the connection. 145 6. MPPE Packets 147 Before any MPPE packets are transmitted, PPP MUST reach the Network- 148 Layer Protocol phase and the CCP Control Protocol MUST reach the Opened 149 state. 151 Exactly one MPPE datagram is encapsulated in the PPP Information field. 152 The PPP Protocol field indicates type 0x00FD for all encrypted data- 153 grams. 155 The maximum length of the MPPE datagram transmitted over a PPP link is 156 the same as the maximum length of the Information field of a PPP encap- 157 sulated packet. 159 Only packets with PPP Protocol numbers in the range 0x0021 to 0x00FA are 160 encrypted. Other packets are not passed thru the MPPE processor and are 161 sent with their original PPP Protocol numbers. 163 Padding 165 It is recommended that padding not be used with MPPE. If the 166 sender uses padding it MUST negotiate the Self-Describing-Padding 167 Configuration option during LCP phase and use self-describing 168 pads. 170 Reliability and Sequencing 172 The MPPE scheme does not require a reliable link. Instead, it 173 relies on a 12-bit coherency count in each packet to keep the 174 encryption tables synchronized. If stateless mode has not been 175 negotiated and the coherency count in the received packet does not 176 match the expected count, the receiver MUST send a CCP Reset- 177 Request packet to cause the resynchronization of the RC4 tables. 179 MPPE expects packets to be delivered in sequence. 181 MPPE MAY be used over a reliable link, as described in "PPP Reli- 182 able Transmision" [6], but this typically just adds unnecessary 183 overhead since only the coherency count is required. 185 Data Expansion 187 The MPPE scheme does not expand or compress data. The number of 188 octets input to and output from the MPPE processor are the same. 190 6.1. Packet Format 192 A summary of the MPPE packet format is shown below. The fields are 193 transmitted from left to right. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | PPP Protocol |A|B|C|D| Coherency Count | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Encrypted Data... 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 PPP Protocol 205 The PPP Protocol field is described in the Point-to-Point Protocol 206 Encapsulation [1]. 208 When MPPE is successfully negotiated by the PPP Compression Control 209 Protocol, the value of this field is 0x00FD. This value MAY be com- 210 pressed when Protocol-Field-Compression is negotiated. 212 Bit A 214 This bit indicates that the encryption tables were initialized before 215 this packet was generated. The receiver MUST re-initialize its 216 tables with the current session key before decrypting this packet. 217 This bit is referred to as the FLUSHED bit in this document. If the 218 stateless option has been negotiated, this bit MUST be set on every 219 encrypted packet. Note that MPPC and MPPE both recognize the FLUSHED 220 bit; therefore, if the stateless option is negotiated, it applies to 221 both MPPC and MPPE. 223 Bit B 225 This bit does not have any significance in MPPE. 227 Bit C 229 This bit does not have any significance in MPPE. 231 Bit D 232 This bit set to 1 indicates that the packet is encrypted. This bit 233 set to 0 means that this packet is not encrypted. 235 Coherency Count 237 The coherency count is used to assure that the packets are sent in 238 proper order and that no packet has been dropped. It is a monotoni- 239 cally increasing counter which incremented by 1 for each packet sent. 240 When the counter reaches 4095 (0x0FFF), it is reset to 0. 242 Encrypted Data 244 The encrypted data begins with the protocol field. For example, in 245 case of an IP packet (0x0021 followed by an IP header), the MPPE pro- 246 cessor will first encrypt the protocol field and then encrypt the IP 247 header. 249 If the packet contains header compression, the MPPE processor is 250 applied AFTER header compression is performed and MUST be applied to 251 the compressed header as well. For example, if a packet contained 252 the protocol type 0x002D (for a compressed TCP/IP header), the MPPE 253 processor would first encrypt 0x002D and then it would encrypt the 254 compressed Van-Jacobsen TCP/IP header. 256 Implementation Note 258 If both MPPE and MPPC are negotiated on the same link, the MPPE pro- 259 cessor MUST be invoked after the MPPC processor by the sender and the 260 MPPE processor MUST be invoked before the MPPC processor by the 261 receiver. 263 7. Initial Session Keys 265 In the current implementation, initial session keys are derived from 266 peer credentials; however, other derivation methods are possible. For 267 example, some authentication methods (such as Kerberos [8] and TLS [9]) 268 produce session keys as side effects of authentication; these keys may 269 be used by MPPE in the future. For this reason, the techniques used to 270 derive initial MPPE session keys are described in seperate documents. 272 8. Initializing RC4 Using a Session Key 274 Once an initial session key has been derived, the RC4 context is ini- 275 tialized as follows: 277 rc4_key(RC4Key, Length_Of_Key, H') 279 9. Encrypting Data 281 Once initialized, data is encrypted using the following function and 282 transmitted with the CCP and MPPE headers. 284 EncryptedData = rc4(RC4Key, Length_Of_Data, Data) 286 10. Changing Keys 288 10.1. Stateless Mode Key Changes 290 If stateless encryption has been negotiated, the session key changes 291 every time the coherency count changes; i.e., on every packet. In 292 stateless mode, the sender MUST change its key before encrypting and 293 transmitting each packet and the receiver MUST change its key after 294 receiving, but before decrypting, each packet (see "Synchronization", 295 below). 297 10.2. Stateful Mode Key Changes 299 If stateful encryption has been negotiated, the sender MUST change its 300 key before encrypting and transmitting any packet in which the low order 301 octet of the coherency count equals 0xFF (the "flag" packet), and the 302 receiver MUST change its key after receiving, but before decrypting, a 303 "flag" packet (see "Synchronization", below). 305 10.3. The MPPE Key Change Algorithm 307 The following method is used to change keys: 309 /* 310 * SessionKeyLength is 8 for 40-bit keys, 16 for 128-bit keys. 311 * 312 * SessionKey is the same as StartKey in the first call for 313 * a given session. 314 */ 316 void 317 GetNewKeyFromSHA( 318 IN unsigned char *StartKey, 319 IN unsigned char *SessionKey, 320 IN unsigned long SessionKeyLength 321 OUT unsigned char *InterimKey ) 322 { 323 unsigned char Digest[20]; 324 ZeroMemory(Digest, 20); 326 /* 327 * SHAInit(), SHAUpdate() and SHAFinal() 328 * are an implementation of the Secure 329 * Hash Algorithm [7] 330 */ 332 SHAInit(Context); 333 SHAUpdate(Context, StartKey, SessionKeyLength); 334 SHAUpdate(Context, SHApad1, 40); 335 SHAUpdate(Context, SessionKey, SessionKeyLength); 336 SHAUpdate(Context, SHApad2, 40); 337 SHAFinal(Context, Digest); 339 MoveMemory(InterimKey, Digest, SessionKeyLength); 340 } 342 The RC4 tables are re-initialized using the newly created interim key: 344 rc4_key(RC4Key, Length_Of_Key, InterimKey) 346 Finally, the interim key is encrypted using the new tables to produce a 347 new session key: 349 SessionKey = rc4(RC4Key, Length_Of_Key, InterimKey) 351 For 40-bit session keys the first three octets of the new session key 352 are now set to 0xD1, 0x26 and 0x9E respectively. 354 Finally, the RC4 tables are re-initialized using the new session key: 356 rc4_key(RC4Key, Length_Of_Key, SessionKey) 358 11. Synchronization 360 Packets may be lost during transfer. The following sections describe 361 synchronization for both the stateless and stateful cases. 363 11.1. Stateless Synchronization 365 If stateless encryption has been negotiated and the coherency count in 366 the received packet (C1) is greater than the coherency count in the last 367 packet previously received (C2), the receiver MUST perform N = C1 - C2 368 key changes before decrypting the packet, in order to ensure that its 369 session key is synchronized with the session key of the sender. Nor- 370 mally, the value of N will be 1; however, if intervening packets have 371 been lost, N may be greater than 1. For example, if C1 = 5 and C2 = 02 372 then N = 3 key changes are required. Since the FLUSHED bit is set on 373 every packet if stateless encryption was negotiated, the transmission of 374 CCP Reset-Request packets is not required for synchronization. 376 11.2. Stateful Synchronization 378 If stateful encryption has been negotiated, the sender MUST change its 379 key before encrypting and transmitting any packet in which the low order 380 octet of the coherency count equals 0xFF (the "flag" packet), and the 381 receiver MUST change its key after receiving, but before decrypting, a 382 "flag" packet. However, the "flag" packet may be lost. If this hap- 383 pens, the low order octet of the coherency count in the received packet 384 will be less than that in the last packet previously received. In this 385 case, the receiver MUST perform a key change before decrypting the newly 386 received packet, (since the sender will have changed its key before 387 transmitting the packet), then send a CCP Reset-Request packet (see 388 below). It is possible that 256 or more consecutive packets could be 389 lost; the receiver SHOULD detect this condition and perform the number 390 of key changes necessary to resynchronize with the sender. 392 If packet loss is detected while using stateful encryption, the receiver 393 MUST drop the packet and send a CCP Reset-Request packet without data. 394 After transmitting the CCP Reset-Request packet, the receiver SHOULD 395 silently discard all packets until a packet is received with the FLUSHED 396 bit set. On receiving a packet with the FLUSHED bit set, the receiver 397 MUST set its coherency count to the one received in that packet and re- 398 initialize its RC4 tables using the current session key: 400 rc4_key(RC4Key, Length_Of_Key, SessionKey) 402 When the sender receives a CCP Reset-Request packet, it MUST re-initial- 403 ize its own RC4 tables using the same method and set the FLUSHED bit in 404 the next packet sent. Thus synchronization is achieved without a CCP 405 Reset-Ack packet. 407 12. Security Considerations 409 Because of the way that the RC4 tables are reinitialized during stateful 410 synchronization, it is possible that two packets may be encrypted using 411 the same key. For this reason, the stateful mode SHOULD NOT be used in 412 lossy network environments (e.g., layer two tunnels on the Internet). 414 Since the MPPE negotiation is not integrity protected, an active 415 attacker could alter the strength of the keys used by modifying the Sup- 416 ported Bits field of the CCP Configuration Option packet. The effects 417 of this attack can be minimized through appropriate peer configuration, 418 however. 420 Peers MUST NOT transmit user data until the MPPE negotiation is com- 421 plete. 423 It is possible that an active attacker could modify the coherency count 424 of a packet, causing the peers to lose synchronization. 426 An active denial-of-service attack could be mounted by methodically 427 inverting the value of the 'D' bit in the MPPE packet header. 429 13. References 431 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 432 July 1994 434 [2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, 435 June 1996 437 [3] RC4 is a proprietary encryption algorithm available under license 438 from RSA Data Security Inc. For licensing information, contact: 439 RSA Data Security, Inc. 440 100 Marine Parkway 441 Redwood City, CA 94065-1031 443 [4] Pall, G., "Microsoft Point-to-Point Compression (MPPC) Protocol", 444 RFC 2118, March 1997 446 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 447 Levels", BCP 14, RFC 2119, March 1997 449 [6] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994 451 [7] "Secure Hash Standard", Federal Information Processing Standards 452 Publication 180-1, National Institute of Standards and Technology, 453 April 1995 455 [8] Kohl, J. and Neuman, C., "The Kerberos Network Authentication Sys- 456 tem (V5)", RFC 1510, September 1993 458 [9] Dierks, T. and Allen, C., "The TLS Protocol Version 1.0", draft- 459 ietf-tls-protocol-05.txt (work in progress), November 1997 461 14. Acknowledgements 463 Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all of 464 Microsoft Corporation, significantly contributed to the design and 465 development of MPPE. 467 Additional thanks to Robert Friend (rfriend@hifn.com), Joe Davies 468 (josephd@microsoft.com), Jody Terrill (jodyt@extendsys.com), Archie 469 Cobbs (archie@whistle.com), Mark Deuser (deuser@us.ibm.com), and Jeff 470 Haag (jeff_haag@3com.com) for useful feedback. 472 15. Chair's Address 474 The PPP Extensions Working Group can be contacted via the current chair: 476 Karl Fox 477 Ascend Communications 478 3518 Riverside Drive 479 Suite 101 480 Columbus, OH 43221 482 Phone: +1 614 326 6841 483 Email: karl@ascend.com 485 16. Authors' Addresses 487 Questions about this memo ican also be directed to: 489 Gurdeep Singh Pall 490 Microsoft Corporation 491 One Microsoft Way 492 Redmond, Washington 98052 494 Phone: +1 425 882 8080 495 FAX: +1 425 936 7329 496 EMail: gurdeep@microsoft.com 498 Glen Zorn 499 Microsoft Corporation 500 One Microsoft Way 501 Redmond, Washington 98052 503 Phone: +1 425 703 1559 504 FAX: +1 425 936 7329 505 EMail: glennz@microsoft.com 507 17. Expiration Date 509 This memo is filed as and expires on 510 March 24, 1999.