Network Working Group Gurdeep Singh Pall Internet Draft Microsoft Corporation expires in six months Dec 1996 Microsoft Point-To-Point Encryption (MPPE) Protocol draft-ietf-pppext-mppe-00.txt Status of this Memo This document is a submission to the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Pall expires in six months [Page i] DRAFT MPPE Dec 1996 Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Microsoft Point to Point Encryption protocol (also referred to as MPPE in this document) for encrypting PPP encapsulated packets. Pall expires in six months [Page ii] DRAFT MPPE Dec 1996 1. Introduction The Microsoft Point to Point Encryption scheme is a means of representing arbitrary Point to Point Protocol (PPP) packets in a encrypted form. MPPE uses RSA RC4 [3] scheme for encryption. The length of the session key to be used for initializing encryption tables can be negotiated. MPPE currently supports 40 bit and 128 bit session keys. MPPE algorithm changes the session keys after transmitting 256 packets. MPPE is negotiated within option 18 [4] in the Compression Control Protocol. 1.1. Licensing RSA RC4 licenses can be obtained from: RSA Data Security, Inc. 10 Twin Dolphin Drive Redwood City, CA 94065 Phone: (415) 595-8782 1.2. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. Pall expires in six months [Page 1] DRAFT MPPE Dec 1996 SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications MUST be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 2. Configuration Option Format Description The CCP Configuration Option negotiates the use of MPPE on the link. By default or ultimate disagreement, no encryption is used. A summary of the CCP Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Supported Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supported Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 18 Length 6 Supported Bits This field is 4 octets, most significant octet first. Value of 0x20 in the least significant octet indicates a desire of the sender to negotiate 40 bit session key encryption. Value of 0x40 in the least significant octet indicates a desire of the sender to negotiate 128 bit session key encryption. All other bits MUST be set to 0. Pall expires in six months [Page 2] DRAFT MPPE Dec 1996 3. MPPE Packets Before any MPPE packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the CCP Control Protocol must reach the Opened state. Exactly one MPPE datagram is encapsulated in the PPP Information field. The PPP Protocol field indicates type hex 00FD for all encrypted datagrams. The maximum length of the MPPE datagram transmitted over a PPP link is the same as the maximum length of the Information field of a PPP encapsulated packet. Only packets with PPP Protocol numbers in the range hex 0021 to hex 00FA are encrypted. Other packets are not passed thru the MPPE processor and are sent with their original PPP Protocol numbers. Padding It is recommended that padding not be used with MPPE. If the sender must use padding it MUST negotiate the Self-Describing-Padding Configuration option during LCP phase and use self-describing pads. Reliability and Sequencing The MPPE scheme does not require a reliable link. Instead, it relies on a 12 bit coherency count in each packet to keep the encryption tables synchronized. If the receiver recognizes that the coherency count received in the packet does not match the count it is expecting, it sends a CCP Reset-Request packet to resynchronize the tables. MPPE expects the packets to be delivered in sequence. MPPE MAY be used over a reliable link, as described in "PPP Reliable Transmision" [5], but this typically just adds unnecessary overhead since only the coherency count is required. Data Expansion MPPE scheme does not expand on compress data. The number of bytes input into and output from the MPPE processor are the same. Pall expires in six months [Page 3] DRAFT MPPE Dec 1996 3.1. Packet Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PPP Protocol |A|B|C|D| Coherency Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Compressed Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PPP Protocol The PPP Protocol field is described in the Point-to-Point Protocol Encapsulation [1]. When MPPE is successfully negotiated by the PPP Compression Control Protocol, the value is hex 00FD. This value MAY be compressed when Protocol-Field-Compression is negotiated. Bit A This bit indicates that the encryption tables were initialized before this packet was generated. The receiver must re-initialize its tables with the current session key before decrypting this packet. This bit is referred to as the FLUSHED bit in this document. Bit B This bit does not have any significance in MPPE. Bit C This bit does not have any significance in MPPE. Bit D This bit set to 1 indicates that the packet is encrypted. This bit set to 0 means that this packet is not encrypted. Coherency Count The coherency count is used to assure that the packets are sent in proper order and that no packet has been dropped. This count starts at 0 and is always increased by 1 and NEVER decreases or goes back. When all bits are 1, the count returns to 0. Pall expires in six months [Page 4] DRAFT MPPE Dec 1996 Encrypted Data The encrypted data begins with the protocol field. For example, in case of an IP packet (0021 followed by an IP header), the MPPE processor will first encrypt the 0021 protocol field and then encrypt the IP header. If the packet contains header compression, the MPPE processor is applied AFTER header compression is preformed and MUST be applied to the encrypted header as well. For example, if a packet contained the protocol 002d for a compressed TCP/IP header, the MPPE processor would first encrypt 002d and then it would encrypt the compressed Van-Jacobsen TCP/IP header. Implementation Note Since MPPE and MPPC can be negotiated at the same time, MPPE processor must be invoked after the MPPC processor by the sender and MPPE processor must be invoked before the MPPC processor by the receiver. Pall expires in six months [Page 5] DRAFT MPPE Dec 1996 4. Session Keys 4.1 Generating 40 bit Session Keys MPPE uses a derivative of the user's credentials as the 40 bit session key used for initializing encryption tables. The first step is to obfuscate the user's password using LmPasswordHash() function as described in [6]. The first 8 bytes of the result, say H, are used as the basis for the session key generated in the following way: /* * H is the basis for the session key * H' is a copy of H and is the generative session key * 64 is the length of the key to generate. * */ Get_Key (H, H', 8) /* * The result of Get_Key() stored in H' is then salted as follows: * */ H'[0] = 0xD1 ; H'[1] = 0x26 ; H'[2] = 0x9E ; 4.2 Generating 128 bit Session Keys MPPE uses a derivative of the user's credentials as the 128 bit session key used for initializing encryption tables. The first step is to obfuscate the user's password using NtPasswordHash() function as described in [6]. The first 16 bytes of the result are hashed again using the same MD4 algorithm. The first 16 bytes of the second hash, say H, are used as the basis for the session key generated in the following way: /* * Challenge as described in [6] is sent by the PPP peer during * authentication and is 8 bytes long. * H is the basis for the session key. On return, H contains the * start key to be used. */ Get_Start_Key(Challenge, H) /* * H' is a copy of H and is the generative session key. * length of the key to generate is 16. * */ Get_Key (H, H', 16) Pall expires in six months [Page 6] DRAFT MPPE Dec 1996 4.3 Initializing RC4 using Session Key Once H' is derived the RC4 context is initialized as follows: /* * rc4_key() library can be licensed from RSA Data Security, Inc. */ rc4_key (RC4Key, Length_Of_Key, H') 4.4 Encrypting Data Once initialized, data is encrypted using the following function and transmitted with CCP and MPPE header. /* * rc4() can be licensed from RSA Data Security, Inc. */ EcryptedData = rc4 (RC4Key, Length_Of_Data, Data) 4.5 Changing Keys Every time the low order octet of the sequence number equals 0xFF the session keys used for encrypting data are changed in the following way: /* * H is the original key. * H' is current key. * Length_Of_Key: 8 for 40 bit keys and 16 for 128 bit session keys. * * On return H' is changed to the new key. */ Get_Key (H, H', Length_Of_Key) Tables are re-initialized using RC4 function: /* * rc4() can be licensed from RSA Data Security, Inc. */ rc4_key (RC4Key, Length_Of_Key, H') H' is encrypted using the new tables to produce a new H': /* * rc4() can be licensed from RSA Data Security, Inc. */ H' = rc4 (RC4Key, Length_Of_Key, H') For 40 bit session keys the first three bytes of H' are set to 0xD1, 0x26 and 0x9E respectively. Pall expires in six months [Page 7] DRAFT MPPE Dec 1996 Finally, tables are re-initialized using RC4 function: /* * rc4() can be licensed from RSA Data Security, Inc. */ rc4_key (RC4Key, Length_Of_Key, H') 4.6 Synchronization Packets may be lost during transfer. If the decryptor maintained coherency count does not match the coherency count received in the encrypted packet, the decryptor drops the packet and sends a CCP Reset-Request packet. On receiving this packet the encryptor re-initializes the RSA RC4 tables using RC4 function: /* * H' is the current session key * rc4() can be licensed from RSA Data Security, Inc. */ rc4_key (RC4Key, Length_Of_Key, H') The next packet sent by the encryptor will have the FLUSHED bit set. The decryptor on receiving a packet with its FLUSHED bit sets its coherency count to the one received in that packet and re-initializes its own tables using the same function. Thus synchronization is achieved without a CCP Reset-Ack packet. Security Considerations Security issues are not discussed in this memo. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994. [2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, Novell, June 1996. [3] RC4 is an encryption algorithm available from RSA Data Security Inc. RC4 is a trademark of RSA Data Security, Inc. [4] Pall, G., "Microsoft Point-to-Point Compression (MPPC) Protocol", RFC ????, Microsoft, July 1996. [5] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July 1994. [6] Cobb, S., "Microsoft PPP CHAP Extensions", RFC ????, Microsoft, December 1995. [7] "Secure Hash Standard", National Institute of Standards and Technology, U.S. Department Of Commerce, April 1995 Also known as: 59 Fed Reg 35317 (1994). Pall expires in six months [Page 8] DRAFT MPPE Dec 1996 Acknowledgments Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all of Microsoft Corporation, made significant contributions towards the design and development of MPPE. Chair's Address The working group can be contacted via the current chair: Karl F. Fox Ascend Communications 3518 Riverside Dr., Suite 101 Columbus, Ohio 43221 (614) 451-1883 EMail: karl@ascend.Com Author's Address Questions about this memo can also be directed to: Gurdeep Singh Pall 1, Microsoft Way, Redmond, WA 98052 (206) 882-8080 Email: gurdeep@microsoft.com Pall expires in six months [Page 9] DRAFT MPPE Dec 1996 Appendix A The following procedures are used to derive the session key: /* * Pads used in key derivation */ SHApad1[40] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; SHApad2[40] = {0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2}; /* * SHAInit(), SHAUpdate() and SHAFinal() functions are an * implementation of Secure Hash Algorithm (SHA-1) [7]. These are * available in public domain or can be licensed from * RSA Data Security, Inc. * * 1) H is 8 bytes long for 40 bit session keys. * 2) H is 16 bytes long for 128 bit session keys. * 3) H' is same as H when this routine is called for the first time * for the session. * 4) The generated key is returned in H'. This is the "current" key. */ Get_Key (H, H', Length_Of_Desired_Key) { SHAInit(Context) SHAUpdate(Context, H, Length_Of_Desired_Key) SHAUpdate(Context, SHAPad1, 40) SHAUpdate(Context, H', Length_Of_Desired_Key) SHAUpdate(Context, SHAPad2, 40) SHAFinal(Context, Digest) memcpy (H', Digest, Lenght_Of_Desired_Key) } Get_Start_Key (Challenge, H) { SHAInit(Context) SHAUpdate(Context, H, 16) SHAUpdate(Context, Challenge, 24) SHAFinal(Context, Digest) memcpy(H, Digest, 16) } Pall expires in six months [Page 10] DRAFT MPPE Dec 1996 Table of Contents 1. Introduction .......................................... 1 1.1 Licensing ....................................... 1 1.2. Specification of Requirements ................... 1 2. Configuration Option Format ........................... 2 3. MPPE Packets .......................................... 3 3.1 Packet Format.................................... 4 4. Session Keys ............................................. 6 4.1 Generating 40 bit Session Keys ............. 6 4.2 Generating 128 bit Session Keys ............. 6 4.3 Initializing RC4 using Session Key ............. 6 4.4 Encrypting Data ................................ 7 4.5 Changing Keys .................................. 7 4.6 Synchronization ................................. 8 SECURITY CONSIDERATIONS ...................................... 8 REFERENCES ................................................... 8 ACKNOWLEDGEMENTS ............................................. 9 CHAIR'S ADDRESS ........................................... 9 AUTHORS' ADDRESS ............................................. 9 APPENDIX ..................................................... 10