idnits 2.17.1 draft-ietf-pppext-mschapv2-keys-01.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-27) 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 10 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 10 has weird spacing: '...This document...' == Line 11 has weird spacing: '...as, and its...' == Line 16 has weird spacing: '...and may be ...' == Line 17 has weird spacing: '...ference mater...' == Line 20 has weird spacing: '...To learn the...' == (45 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 (October 1998) is 9326 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 122, but not defined == Missing Reference: '40' is mentioned on line 185, but not defined == Missing Reference: '27' is mentioned on line 195, but not defined == Missing Reference: '84' is mentioned on line 211, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-pppext-mschap-v2-01 == Outdated reference: A later version (-05) exists of draft-ietf-pppext-mppe-02 Summary: 12 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Zorn 2 Internet-Draft Microsoft Corporation 3 Category: Informational October 1998 4 6 Deriving MPPE Keys From MS-CHAP V2 Credentials 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working docu- 11 ments of the Internet Engineering Task Force (IETF), its areas, and its 12 working groups. Note that other groups may also distribute working doc- 13 uments as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as ``work in progress''. 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 23 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 This memo provides information for the Internet community. This memo 26 does not specify an Internet standard of any kind. The distribution of 27 this memo is unlimited. It is filed as and expires April 15, 1999. Please send comments 29 to the PPP Extensions Working Group mailing list (ietf-ppp@merit.edu) or 30 to the author (glennz@microsoft.com). 32 2. Abstract 34 The Point-to-Point Protocol (PPP) [1] provides a standard method for 35 transporting multi-protocol datagrams over point-to-point links. 37 The PPP Compression Control Protocol [2] provides a method to negotiate 38 and utilize compression protocols over PPP encapsulated links. 40 Version 2 of the Microsoft Challenge-Handshake Authentication Protocol 41 (MS-CHAP-2) [3] is a Microsoft-proprietary PPP authentication protocol, 42 providing the functionality to which LAN-based users are accustomed 43 while integrating the encryption and hashing algorithms used on Windows 44 networks. 46 Microsoft Point to Point Encryption (MPPE) [4] is a means of 47 representing PPP packets in an encrypted form. MPPE uses the RSA RC4 48 [5] algorithm to provide data confidentiality. The length of the ses- 49 sion key to be used for initializing encryption tables can be negoti- 50 ated. MPPE currently supports 40-bit and 128-bit session keys. MPPE 51 session keys are changed frequently; the exact frequency depends upon 52 the options negotiated, but may be every packet. MPPE is negotiated 53 within option 18 [6] in the Compression Control Protocol. 55 This document describes the method used to derive the initial MPPE ses- 56 sion keys from MS-CHAP-2 credentials. The algorithm used to change ses- 57 sion keys during a session is described in [4]. 59 3. Specification of Requirements 61 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 62 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 63 described in [7]. 65 4. Deriving Session Keys from MS-CHAP-2 Credentials 67 The following sections detail the methods used to derive initial session 68 keys from MS-CHAP-2 credentials. Both 40- and 128-bit keys are derived 69 using the same algorithm from the authenticating peer's Windows NT pass- 70 word. The only difference is in the length of the keys and their effec- 71 tive strength: 40-bit keys are 8 octets in length, while 128-bit keys 72 are 16 octets long. Separate keys are derived for the send and receive 73 directions of the session. 75 Implementation Note 77 The initial session keys in both directions are derived from the cre- 78 dentials of the peer that initiated the call and the challenges used 79 are those from the first authentication. This is true as well for 80 each link in a multilink bundle. In the multi-chassis multilink 81 case, implementations are responsible for ensuring that the correct 82 keys are generated on all participating machines. 84 4.1. Generating 40-bit Session Keys 86 When used in conjunction with MS-CHAP-2 authentication, the initial MPPE 87 session keys are derived from the peer's Windows NT password. 89 The first step is to obfuscate the peer's password using NtPassword- 90 Hash() function as described in [3]. 92 NtPasswordHash(Password, PasswordHash) 94 The first 16 octets of the result are then hashed again using the MD4 95 algorithm. 97 PasswordHashHash = md4(PasswordHash) 99 The first 16 octets of this second hash are used together with the NT- 100 Response field from the MS-CHAP-2 Response packet [3] as the basis for 101 the master session key: 103 GetMasterKey(PasswordHashHash, NtResponse, MasterKey) 105 Once the master key has been generated, it is used to derive two 40-bit 106 session keys, one for sending and one for receiving: 108 GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE) 109 GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE) 111 The master session keys are never used to encrypt or decrypt data; they 112 are only used in the derivation of transient session keys. The initial 113 transient session keys are obtained by calling the function Get- 114 NewKeyFromSHA() (described in [4]): 116 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey) 117 GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8, ReceiveSessionKey) 119 Next, the effective strength of both keys is reduced by setting the 120 first three octets to known constants: 122 SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1 123 SendSessionKey[1] = ReceiveSessionKey[1] = 0x26 124 SendSessionKey[2] = ReceiveSessionKey[2] = 0x9E 126 Finally, the RC4 tables are initialized using the new session keys: 128 rc4_key(SendRC4key, 8, SendSessionKey) 129 rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) 131 4.2. Generating 128-bit Session Keys 133 When used in conjunction with MS-CHAP-2 authentication, the initial MPPE 134 session keys are derived from the peer's Windows NT password. 136 The first step is to obfuscate the peer's password using NtPassword- 137 Hash() function as described in [3]. 139 NtPasswordHash(Password, PasswordHash) 141 The first 16 octets of the result are then hashed again using the MD4 142 algorithm. 144 PasswordHashHash = md4(PasswordHash) 146 The first 16 octets of this second hash are used together with the NT- 147 Response field from the MS-CHAP-2 Response packet [3] as the basis for 148 the master session key: 150 GetMasterKey(PasswordHashHash, NtResponse, MasterKey) 152 Once the master key has been generated, it is used to derive two 128-bit 153 master session keys, one for sending and one for receiving: 155 GetAsymmetricStartKey(MasterKey, MasterSendKey, 16, TRUE, TRUE) 156 GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 16, FALSE, TRUE) 158 The master session keys are never used to encrypt or decrypt data; they 159 are only used in the derivation of transient session keys. The initial 160 transient session keys are obtained by calling the function Get- 161 NewKeyFromSHA() (described in [4]): 163 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey) 164 GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16, ReceiveSessionKey) 166 Finally, the RC4 tables are initialized using the new session keys: 168 rc4_key(SendRC4key, 16, SendSessionKey) 169 rc4_key(ReceiveRC4key, 16, ReceiveSessionKey) 171 4.3. Key Derivation Functions 173 The following procedures are used to derive the session key. 175 /* 176 * Pads used in key derivation 177 */ 179 SHSpad1[40] = 180 {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 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}; 185 SHSpad2[40] = 186 {0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 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}; 191 /* 192 * "Magic" constants used in key derivations 193 */ 195 Magic1[27] = 196 {0x54, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 197 0x68, 0x65, 0x20, 0x4D, 0x50, 0x50, 0x45, 0x20, 0x4D, 198 0x61, 0x73, 0x74, 0x65, 0x72, 0x20, 0x4B, 0x65, 0x79}; 200 Magic2[84] = 201 {0x4F, 0x6E, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6C, 0x69, 202 0x65, 0x6E, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2C, 0x20, 203 0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, 204 0x65, 0x20, 0x73, 0x65, 0x6E, 0x64, 0x20, 0x6B, 0x65, 0x79, 205 0x3B, 0x20, 0x6F, 0x6E, 0x20, 0x74, 0x68, 0x65, 0x20, 0x73, 206 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, 0x69, 0x64, 0x65, 207 0x2C, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, 208 0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20, 209 0x6B, 0x65, 0x79, 0x2E}; 211 Magic3[84] = 212 {0x4F, 0x6E, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6C, 0x69, 213 0x65, 0x6E, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2C, 0x20, 214 0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, 215 0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20, 216 0x6B, 0x65, 0x79, 0x3B, 0x20, 0x6F, 0x6E, 0x20, 0x74, 0x68, 217 0x65, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, 218 0x69, 0x64, 0x65, 0x2C, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 219 0x20, 0x74, 0x68, 0x65, 0x20, 0x73, 0x65, 0x6E, 0x64, 0x20, 220 0x6B, 0x65, 0x79, 0x2E}; 222 GetMasterKey( 223 IN 16-octet PasswordHashHash, 224 IN 24-octet NTResponse, 225 OUT 16-octet MasterKey ) 226 { 227 20-octet Digest 229 ZeroMemory(Digest, sizeof(Digest)); 231 /* 232 * SHSInit(), SHSUpdate() and SHSFinal() 233 * are an implementation of the Secure Hash Standard [8]. 234 */ 236 SHSInit(Context); 237 SHSUpdate(Context, PasswordHashHash, 16); 238 SHSUpdate(Context, NTResponse, 24); 239 SHSUpdate(Context, Magic1, 27); 240 SHSFinal(Context, Digest); 242 MoveMemory(MasterKey, Digest, 16); 243 } 245 VOID 246 GetAsymetricStartKey( 247 IN 16-octet MasterKey, 248 OUT 8-to-16 octet SessionKey, 249 IN INTEGER SessionKeyLength, 250 IN BOOLEAN IsSend, 251 IN BOOLEAN IsServer ) 252 { 254 20-octet Digest; 256 ZeroMemory(Digest, 20); 258 if (IsSend) { 259 if (IsServer) { 260 s = Magic3 261 } else { 262 s = Magic2 263 } 264 } else { 265 if (IsServer) { 266 s = Magic2 267 } else { 268 s = Magic3 269 } 270 } 272 /* 273 * SHSInit(), SHSUpdate() and SHSFinal() 274 * are an implementation of the Secure Hash Standard [8]. 275 */ 277 SHSInit(Context); 278 SHSUpdate(Context, MasterKey, 16); 279 SHSUpdate(Context, SHSpad1, 40); 280 SHSUpdate(Context, s, 84); 281 SHSUpdate(Context, SHSpad2, 40); 282 SHSFinal(Context, Digest); 284 MoveMemory(SessionKey, Digest, SessionKeyLength); 285 } 287 5. Security Considerations 289 Since the MPPE session keys are derived from user passwords, care should 290 be taken to ensure the selection of strong passwords and passwords 291 should be changed frequently. 293 6. References 295 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 296 July 1994 298 [2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, 299 June 1996 301 [3] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", draft-ietf- 302 pppext-mschap-v2-01.txt (work in progress), October 1998 304 [4] Pall, G. S., & Zorn, G., "Microsoft Point-to-Point Encryption 305 (MPPE) Protocol", draft-ietf-pppext-mppe-02.txt (work in progress), 306 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. S., "Microsoft Point-to-Point Compression (MPPC) Proto- 315 col", 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), Brad Robel- 333 Forrest (brad@watchguard.com) and Jeff Haag (jeff_haag@3com.com) for 334 useful feedback. 336 8. Chair's Address 338 The PPP Extensions Working Group can be contacted via the current chair: 340 Karl Fox 341 Ascend Communications 342 3518 Riverside Drive 343 Suite 101 344 Columbus, OH 43221 346 Phone: +1 614 326 6841 347 Email: karl@ascend.com 349 9. Author's Address 351 Questions about this memo can also be directed to: 353 Glen Zorn 354 Microsoft Corporation 355 One Microsoft Way 356 Redmond, Washington 98052 358 Phone: +1 425 703 1559 359 FAX: +1 425 936 7329 360 EMail: glennz@microsoft.com 362 10. Expiration Date 364 This memo is filed as and 365 expires on April 15, 1999. 367 Appendix A - Sample Key Derivations 368 The following sections illustrate both 40- and 128-bit key derivations. 369 All intermediate values are in hexadecimal. 371 Appendix A.1 - Sample 40-bit Key Derivation 373 Initial Values 374 UserName = "User" = 55 73 65 72 375 Password = "clientPass" = 63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00 376 AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28 377 PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E 378 Challenge = D0 2E 43 86 BC E9 12 26 379 NT-Response = 380 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF 382 Step 1: NtPasswordHash(Password, PasswordHash) 383 PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE 385 Step 2: PasswordHashHash = MD4(PasswordHash) 386 PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F 388 Step 2: Derive the master key (GetMasterKey()) 389 MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 391 Step 3: Derive the master send session key (GetAsymmetricStartKey()) 393 SendStartKey40 = 8B 7C DC 14 9B 99 3A 1B 395 Step 4: Derive the intial send session key (GetNewKeyFromSHA()) 396 SendSessionKey40 = D1 26 9E C4 9F A6 2E 3E 398 Sample Enrypted Message 399 rc4(SendSessionKey40, "test message") = 92 91 37 91 7E 58 03 D6 68 D7 58 98 401 Appendix A.2 - Sample 128-bit Key Derivation 403 Initial Values 404 UserName = "User" = 55 73 65 72 405 Password = "clientPass" = 63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00 406 AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28 407 PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E 408 Challenge = D0 2E 43 86 BC E9 12 26 409 NT-Response = 410 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF 412 Step 1: NtPasswordHash(Password, PasswordHash) 413 PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE 415 Step 2: PasswordHashHash = MD4(PasswordHash) 416 PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F 418 Step 2: Derive the master key (GetMasterKey()) 419 MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 421 Step 3: Derive the send master session key (GetAsymmetricStartKey()) 423 SendStartKey128 = 8B 7C DC 14 9B 99 3A 1B A1 18 CB 15 3F 56 DC CB 425 Step 4: Derive the intial send session key (GetNewKeyFromSHA()) 426 SendSessionKey128 = 40 5C B2 24 7A 79 56 E6 E2 11 00 7A E2 7B 22 D4 428 Sample Enrypted Message 429 rc4(SendSessionKey128, "test message") = 81 84 83 17 DF 68 84 62 72 FB 5A BE