idnits 2.17.1 draft-ietf-pppext-mschapv2-keys-00.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-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 -- 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 Introduction section. ** 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 8 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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...' == (44 more instances...) -- 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 9348 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: '0' is mentioned on line 123, but not defined == Missing Reference: '40' is mentioned on line 186, but not defined == Missing Reference: '27' is mentioned on line 196, but not defined == Missing Reference: '84' is mentioned on line 212, but not defined == Outdated reference: A later version (-05) exists of draft-ietf-pppext-mppe-02 Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Microsoft Corporation 4 Category: Informational September 1998 5 7 Deriving MPPE Keys From MS-CHAP V2 Credentials 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 and expires March 24, 1999. Please send comments 30 to the PPP Extensions Working Group mailing list (ietf-ppp@merit.edu) or 31 to the author (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 Version 2 of the Microsoft Challenge-Handshake Authentication Protocol 42 (MS-CHAP-2) [3] is a Microsoft-proprietary PPP authentication protocol, 43 providing the functionality to which LAN-based users are accustomed 44 while integrating the encryption and hashing algorithms used on Windows 45 networks. 47 Microsoft Point to Point Encryption (MPPE) [4] is a means of 48 representing PPP packets in an encrypted form. MPPE uses the RSA RC4 49 [5] algorithm to provide data confidentiality. The length of the ses- 50 sion key to be used for initializing encryption tables can be negoti- 51 ated. MPPE currently supports 40-bit and 128-bit session keys. MPPE 52 session keys are changed frequently; the exact frequency depends upon 53 the options negotiated, but may be every packet. MPPE is negotiated 54 within option 18 [6] in the Compression Control Protocol. 56 This document describes the method used to derive the initial MPPE ses- 57 sion keys from MS-CHAP-2 credentials. The algorithm used to change ses- 58 sion keys during a session is described in [4]. 60 3. Specification of Requirements 62 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 63 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 64 described in [7]. 66 4. Deriving Session Keys from MS-CHAP-2 Credentials 68 The following sections detail the methods used to derive initial session 69 keys from MS-CHAP-2 credentials. Both 40- and 128-bit keys are derived 70 using the same algorithm from the authenticating peer's Windows NT pass- 71 word. The only difference is in the length of the keys and their effec- 72 tive strength: 40-bit keys are 8 octets in length, while 128-bit keys 73 are 16 octets long. Separate keys are derived for the send and receive 74 directions of the session. 76 Implementation Note 78 The initial session keys in both directions are derived from the cre- 79 dentials of the peer that initiated the call and the challenges used 80 are those from the first authentication. This is true as well for 81 each link in a multilink bundle. In the multi-chassis multilink 82 case, implementations are responsible for ensuring that the correct 83 keys are generated on all participating machines. 85 4.1. Generating 40-bit Session Keys 87 When used in conjunction with MS-CHAP-2 authentication, the initial MPPE 88 session keys are derived from the peer's Windows NT password. 90 The first step is to obfuscate the peer's password using NtPassword- 91 Hash() function as described in [3]. 93 NtPasswordHash(Password, PasswordHash) 95 The first 16 octets of the result are then hashed again using the MD4 96 algorithm. 98 PasswordHashHash = md4(PasswordHash) 100 The first 16 octets of this second hash are used together with the NT- 101 Response field from the MS-CHAP-2 Response packet [3] as the basis for 102 the master session key: 104 GetMasterKey(PasswordHashHash, NtResponse, MasterKey) 106 Once the master key has been generated, it is used to derive two 40-bit 107 session keys, one for sending and one for receiving: 109 GetAsymmetricStartKey(MasterKey, SendKey, 8, TRUE, TRUE) 110 GetAsymmetricStartKey(MasterKey, ReceiveKey, 8, FALSE, TRUE) 112 The master session keys are never used to encrypt or decrypt data; they 113 are only used in the derivation of transient session keys. The initial 114 transient session keys are obtained by calling the function Get- 115 NewKeyFromSHA() (described in [4]): 117 GetNewKeyFromSHA(SendKey, SendKey, 8, SendSessionKey) 118 GetNewKeyFromSHA(ReceiveKey, ReceiveKey, 8, ReceiveSessionKey) 120 Next, the effective strength of both keys is reduced by setting the 121 first three octets to known constants: 123 SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1 124 SendSessionKey[1] = ReceiveSessionKey[1] = 0x26 125 SendSessionKey[2] = ReceiveSessionKey[2] = 0x9E 127 Finally, the RC4 tables are initialized using the new session keys: 129 rc4_key(SendRC4key, 8, SendSessionKey) 130 rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) 132 4.2. Generating 128-bit Session Keys 134 When used in conjunction with MS-CHAP-2 authentication, the initial MPPE 135 session keys are derived from the peer's Windows NT password. 137 The first step is to obfuscate the peer's password using NtPassword- 138 Hash() function as described in [3]. 140 NtPasswordHash(Password, PasswordHash) 142 The first 16 octets of the result are then hashed again using the MD4 143 algorithm. 145 PasswordHashHash = md4(PasswordHash) 147 The first 16 octets of this second hash are used together with the NT- 148 Response field from the MS-CHAP-2 Response packet [3] as the basis for 149 the master session key: 151 GetMasterKey(PasswordHashHash, NtResponse, MasterKey) 153 Once the master key has been generated, it is used to derive two 128-bit 154 master session keys, one for sending and one for receiving: 156 GetAsymmetricStartKey(MasterKey, MasterSendKey, 16, TRUE, TRUE) 157 GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 16, FALSE, TRUE) 159 The master session keys are never used to encrypt or decrypt data; they 160 are only used in the derivation of transient session keys. The initial 161 transient session keys are obtained by calling the function Get- 162 NewKeyFromSHA() (described in [4]): 164 GetNewKeyFromSHA(SendKey, SendKey, 16, SendSessionKey) 165 GetNewKeyFromSHA(ReceiveKey, ReceiveKey, 16, ReceiveSessionKey) 167 Finally, the RC4 tables are initialized using the new session keys: 169 rc4_key(SendRC4key, 16, SendKey) 170 rc4_key(ReceiveRC4key, 16, ReceiveKey) 172 4.3. Key Derivation Functions 174 The following procedures are used to derive the session key. 176 /* 177 * Pads used in key derivation 178 */ 180 SHSpad1[40] = 181 {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 182 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 183 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 184 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; 186 SHSpad2[40] = 187 {0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 188 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 189 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 190 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2}; 192 /* 193 * "Magic" constants used in key derivations 194 */ 196 Magic1[27] = 197 {0x54, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 198 0x68, 0x65, 0x20, 0x4D, 0x50, 0x50, 0x45, 0x20, 0x4D, 199 0x61, 0x73, 0x74, 0x65, 0x72, 0x20, 0x4B, 0x65, 0x79}; 201 Magic2[84] = 202 {0x4F, 0x6E, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6C, 0x69, 203 0x65, 0x6E, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2C, 0x20, 204 0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, 205 0x65, 0x20, 0x73, 0x65, 0x6E, 0x64, 0x20, 0x6B, 0x65, 0x79, 206 0x3B, 0x20, 0x6F, 0x6E, 0x20, 0x74, 0x68, 0x65, 0x20, 0x73, 207 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, 0x69, 0x64, 0x65, 208 0x2C, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, 209 0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20, 210 0x6B, 0x65, 0x79, 0x2E}; 212 Magic3[84] = 213 {0x4F, 0x6E, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6C, 0x69, 214 0x65, 0x6E, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2C, 0x20, 215 0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, 216 0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20, 217 0x6B, 0x65, 0x79, 0x3B, 0x20, 0x6F, 0x6E, 0x20, 0x74, 0x68, 218 0x65, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, 219 0x69, 0x64, 0x65, 0x2C, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 220 0x20, 0x74, 0x68, 0x65, 0x20, 0x73, 0x65, 0x6E, 0x64, 0x20, 221 0x6B, 0x65, 0x79, 0x2E}; 223 GetMasterKey( 224 IN 16-octet PasswordHashHash, 225 IN 24-octet NTResponse, 226 OUT 16-octet MasterKey ) 227 { 228 20-octet Digest 230 ZeroMemory(Digest, sizeof(Digest)); 232 /* 233 * SHSInit(), SHSUpdate() and SHSFinal() 234 * are an implementation of the Secure Hash Standard [8]. 235 */ 237 SHSInit(Context); 238 SHSUpdate(Context, PasswordHashHash, 16); 239 SHSUpdate(Context, NTResponse, 24); 240 SHSUpdate(Context, Magic1, 27); 241 SHSFinal(Context, Digest); 243 MoveMemory(MasterKey, Digest, 16); 244 } 246 VOID 247 GetAsymetricStartKey( 248 IN 16-octet MasterKey, 249 OUT 8-to-16 octet SessionKey, 250 IN INTEGER SessionKeyLength, 251 IN BOOLEAN IsSend, 252 IN BOOLEAN IsServer ) 253 { 255 20-octet Digest; 257 ZeroMemory(Digest, 20); 259 if (IsSend) { 260 if (IsServer) { 261 s = Magic3 262 } else { 263 s = Magic2 264 } 265 } else { 266 if (IsServer) { 267 s = Magic2 268 } else { 269 s = Magic3 270 } 271 } 273 /* 274 * SHSInit(), SHSUpdate() and SHSFinal() 275 * are an implementation of the Secure Hash Standard [8]. 276 */ 278 SHSInit(Context); 279 SHSUpdate(Context, MasterKey, 16); 280 SHSUpdate(Context, SHSpad1, 40); 281 SHSUpdate(Context, s, 84); 282 SHSUpdate(Context, SHSpad2, 40); 283 SHSFinal(Context, Digest); 285 MoveMemory(SessionKey, Digest, SessionKeyLength); 286 } 288 5. Security Considerations 290 Since the MPPE session keys are derived from user passwords, care should 291 be taken to ensure the selection of strong passwords and passwords 292 should be changed frequently. 294 6. References 296 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 297 July 1994 299 [2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, 300 June 1996 302 [3] Zorn, G. & Cobb, S., "Microsoft PPP CHAP Extensions", draft-ietf- 303 pppext-mschap-00.txt (work in progress), March 1998 305 [4] Pall, G. S., & Zorn, G., "Microsoft Point-to-Point Encryption 306 (MPPE) Protocol", draft-ietf-pppext-mppe-02.txt, July 1998 308 [5] RC4 is a proprietary encryption algorithm available under license 309 from RSA Data Security Inc. For licensing information, contact: 310 RSA Data Security, Inc. 311 100 Marine Parkway 312 Redwood City, CA 94065-1031 314 [6] Pall, G., "Microsoft Point-to-Point Compression (MPPC) Protocol", 315 RFC 2118, March 1997 317 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 318 Levels", BCP 14, RFC 2119, March 1997 320 [8] "Secure Hash Standard", Federal Information Processing Standards 321 Publication 180-1, National Institute of Standards and Technology, 322 April 1995 324 7. Acknowledgements 326 Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all of 327 Microsoft Corporation, significantly contributed to the design and 328 development of MPPE. 330 Additional thanks to Robert Friend (rfriend@hifn.com), Joe Davies 331 (josephd@microsoft.com), Jody Terrill (jodyt@extendsys.com), Archie 332 Cobbs (archie@whistle.com), Mark Deuser (deuser@us.ibm.com), and Jeff 333 Haag (jeff_haag@3com.com) for useful feedback. 335 8. Chair's Address 337 The PPP Extensions Working Group can be contacted via the current chair: 339 Karl Fox 340 Ascend Communications 341 3518 Riverside Drive 342 Suite 101 343 Columbus, OH 43221 345 Phone: +1 614 326 6841 346 Email: karl@ascend.com 348 9. Author's Address 350 Questions about this memo can also be directed to: 352 Glen Zorn 353 Microsoft Corporation 354 One Microsoft Way 355 Redmond, Washington 98052 357 Phone: +1 425 703 1559 358 FAX: +1 425 936 7329 359 EMail: glennz@microsoft.com 361 10. Expiration Date 363 This memo is filed as and 364 expires on March 24, 1999. 366 Appendix A - Sample Key Derivations 367 The following sections illustrate both 40- and 128-bit key derivations. 368 All intermediate values are in hexadecimal. 370 Appendix A.1 - Sample 40-bit Key Derivation 372 Initial Values 373 UserName = "User" = 55 73 65 72 374 Password = "clientPass" = 63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00 375 AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28 376 PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E 377 Challenge = D0 2E 43 86 BC E9 12 26 378 NT-Response = 379 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF 381 Step 1: NtPasswordHash(Password, PasswordHash) 382 PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE 384 Step 2: PasswordHashHash = MD4(PasswordHash) 385 PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F 387 Step 2: Derive the master key (GetMasterKey()) 388 MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 390 Step 3: Derive the master send session key (GetAsymmetricStartKey()) 392 SendStartKey40 = 8B 7C DC 14 9B 99 3A 1B 394 Step 4: Derive the intial send session key (GetNewKeyFromSHA()) 395 SendSessionKey40 = D1 26 93 C4 9F A6 2E 3E 397 Sample Enrypted Message 398 rc4(SendSessionKey40, "test message") = 88 97 6D 0C 4D 08 4E 86 B3 53 2B 21 400 Appendix A.2 - Sample 128-bit Key Derivation 402 Initial Values 403 UserName = "User" = 55 73 65 72 404 Password = "clientPass" = 63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00 405 AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28 406 PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E 407 Challenge = D0 2E 43 86 BC E9 12 26 408 NT-Response = 409 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF 411 Step 1: NtPasswordHash(Password, PasswordHash) 412 PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE 414 Step 2: PasswordHashHash = MD4(PasswordHash) 415 PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F 417 Step 2: Derive the master key (GetMasterKey()) 418 MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 420 Step 3: Derive the send master session key (GetAsymmetricStartKey()) 422 SendStartKey128 = 8B 7C DC 14 9B 99 3A 1B A1 18 CB 15 3F 56 DC CB 424 Step 4: Derive the intial send session key (GetNewKeyFromSHA()) 425 SendSessionKey128 = 40 5C B2 24 7A 79 56 E6 E2 11 00 7A E2 7B 22 D4 427 Sample Enrypted Message 428 rc4(SendSessionKey128, "test message") = 81 84 83 17 DF 68 84 62 72 FB 5A BE