idnits 2.17.1 draft-ietf-pppext-mppe-keys-03.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages 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 20 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2], [4], [5], [6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 52 has weird spacing: '... 56-bit and 1...' == Line 678 has weird spacing: '...support for ...' == Line 681 has weird spacing: '...een two endpo...' == 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). -- 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 2000) is 8587 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 755, but not defined == Missing Reference: '40' is mentioned on line 462, but not defined == Missing Reference: '27' is mentioned on line 472, but not defined == Missing Reference: '84' is mentioned on line 488, but not defined ** Obsolete normative reference: RFC 2284 (ref. '11') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2246 (ref. '12') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2716 (ref. '13') (Obsoleted by RFC 5216) Summary: 13 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 cisco Systems 4 Category: Informational October 2000 5 7 Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE) 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 To view the list of Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 This memo provides information for the Internet community. This memo 30 does not specify an Internet standard of any kind. The distribution of 31 this memo is unlimited. It is filed as and expires May 3, 2001. Please send comments to the PPP 33 Extensions Working Group mailing list (ietf-ppp@merit.edu) or to the 34 author (gwz@cisco.com). 36 2. Copyright Statement 38 Copyright (C) The Internet Society (2000). All Rights Reserved. 40 3. Abstract 42 The Point-to-Point Protocol (PPP) [1] provides a standard method for 43 transporting multi-protocol datagrams over point-to-point links. 45 The PPP Compression Control Protocol [2] provides a method to negotiate 46 and utilize compression protocols over PPP encapsulated links. 48 Microsoft Point to Point Encryption (MPPE) [4] is a means of 49 representing PPP packets in an encrypted form. MPPE uses the RSA RC4 50 [5] algorithm to provide data confidentiality. The length of the 51 session key to be used for initializing encryption tables can be 52 negotiated. MPPE currently supports 40-bit, 56-bit and 128-bit session 53 keys. MPPE session keys are changed frequently; the exact frequency 54 depends upon the options negotiated, but may be every packet. MPPE is 55 negotiated within option 18 [6] in the Compression Control Protocol. 57 This document describes the method used to derive initial MPPE session 58 keys from a variety of credential types. It is expected that this memo 59 will be updated whenever Microsoft defines a new key derivation method 60 for MPPE, since its primary purpose is to provide an open, easily 61 accessible reference for third-parties wishing to interoperate with 62 Microsoft products. 64 The algorithm used to change session keys during a session is described 65 in [4]. 67 4. Specification of Requirements 69 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 70 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 71 described in [7]. 73 5. Deriving Session Keys from MS-CHAP Credentials 75 The Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP-1) 76 [3] is a Microsoft-proprietary PPP authentication protocol, providing 77 the functionality to which LAN-based users are accustomed while 78 integrating the encryption and hashing algorithms used on Windows 79 networks. 81 The following sections detail the methods used to derive initial session 82 keys (40-, 56- and 128-bit) from MS-CHAP-1 credentials. 84 Implementation Note 86 The initial session key in both directions is derived from the 87 credentials of the peer that initiated the call and the challenge 88 used (if any) is the challenge from the first authentication. This 89 is true for both unilateral and bilateral authentication, as well 90 as for each link in a multilink bundle. In the multi-chassis 91 multilink case, implementations are responsible for ensuring that 92 the correct keys are generated on all participating machines. 94 5.1. Generating 40-bit Session Keys 96 MPPE uses a derivative of the peer's LAN Manager password as the 40-bit 97 session key used for initializing the RC4 encryption tables. 99 The first step is to obfuscate the peer's password using the 100 LmPasswordHash() function (described in [3]). The first 8 octets of the 101 result are used as the basis for the session key generated in the 102 following way: 104 /* 105 * PasswordHash is the basis for the session key 106 * SessionKey is a copy of PasswordHash and is the generative session key 107 * 8 is the length (in octets) of the key to be generated. 108 * 109 */ 110 Get_Key(PasswordHash, SessionKey, 8) 112 /* 113 * The effective length of the key is reduced to 40 bits by 114 * replacing the first three bytes as follows: 115 */ 116 SessionKey[0] = 0xd1 ; 117 SessionKey[1] = 0x26 ; 118 SessionKey[2] = 0x9e ; 120 5.2. Generating 56-bit Session Keys 122 MPPE uses a derivative of the peer's LAN Manager password as the 56-bit 123 session key used for initializing the RC4 encryption tables. 125 The first step is to obfuscate the peer's password using the 126 LmPasswordHash() function (described in [3]). The first 8 octets of the 127 result are used as the basis for the session key generated in the 128 following way: 130 /* 131 * PasswordHash is the basis for the session key 132 * SessionKey is a copy of PasswordHash and is the generative session key 133 * 8 is the length (in octets) of the key to be generated. 134 * 135 */ 136 Get_Key(PasswordHash, SessionKey, 8) 138 /* 139 * The effective length of the key is reduced to 56 bits by 140 * replacing the first byte as follows: 142 */ 143 SessionKey[0] = 0xd1 ; 145 5.3. Generating 128-bit Session Keys 147 MPPE uses a derivative of the peer's Windows NT password as the 128-bit 148 session key used for initializing encryption tables. 150 The first step is to obfuscate the peer's password using 151 NtPasswordHash() function as described in [3]. The first 16 octets of 152 the result are then hashed again using the MD4 algorithm. The first 16 153 octets of the second hash are used as the basis for the session key 154 generated in the following way: 156 /* 157 * Challenge (as described in [10]) is sent by the PPP authenticator 158 * during authentication and is 8 octets long. 159 * NtPasswordHashHash is the basis for the session key. 160 * On return, InitialSessionKey contains the initial session 161 * key to be used. 162 */ 163 Get_Start_Key(Challenge, NtPasswordHashHash, InitialSessionKey) 165 /* 166 * CurrentSessionKey is a copy of InitialSessionKey 167 * and is the generative session key. 168 * Length (in octets) of the key to generate is 16. 169 * 170 */ 171 Get_Key(InitialSessionKey, CurrentSessionKey, 16) 173 5.4. Key Derivation Functions 175 The following procedures are used to derive the session key. 177 /* 178 * Pads used in key derivation 179 */ 181 SHApad1[40] = 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, 185 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; 187 SHApad2[40] = 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, 191 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2}; 193 /* 194 * SHAInit(), SHAUpdate() and SHAFinal() functions are an 195 * implementation of Secure Hash Algorithm (SHA-1) [8]. These are 196 * available in public domain or can be licensed from 197 * RSA Data Security, Inc. 198 * 199 * 1) InitialSessionKey is 8 octets long for 56- and 40-bit 200 * session keys, 16 octets long for 128 bit session keys. 201 * 2) CurrentSessionKey is same as InitialSessionKey when this 202 * routine is called for the first time for the session. 203 */ 205 Get_Key( 206 IN InitialSessionKey, 207 IN/OUT CurrentSessionKey 208 IN LengthOfDesiredKey ) 209 { 210 SHAInit(Context) 211 SHAUpdate(Context, InitialSessionKey, LengthOfDesiredKey) 212 SHAUpdate(Context, SHAPad1, 40) 213 SHAUpdate(Context, CurrentSessionKey, LengthOfDesiredKey) 214 SHAUpdate(Context, SHAPad2, 40) 215 SHAFinal(Context, Digest) 216 memcpy(CurrentSessionKey, Digest, LengthOfDesiredKey) 217 } 219 Get_Start_Key( 220 IN Challenge, 221 IN NtPasswordHashHash, 222 OUT InitialSessionKey) 223 { 224 SHAInit(Context) 225 SHAUpdate(Context, NtPasswordHashHash, 16) 226 SHAUpdate(Context, NtPasswordHashHash, 16) 227 SHAUpdate(Context, Challenge, 8) 228 SHAFinal(Context, Digest) 229 memcpy(InitialSessionKey, Digest, 16) 230 } 231 5.5. Sample Key Derivations 233 The following sections illustrate 40-, 56- and 128-bit key derivations. 234 All intermediate values are in hexadecimal. 236 5.5.1. Sample 40-bit Key Derivation 238 Initial Values 239 Password = "clientPass" 241 Step 1: LmPasswordHash(Password, PasswordHash) 242 PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 244 Step 2: Copy PasswordHash to SessionKey 245 SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 247 Step 3: GetKey(PasswordHash, SessionKey, 8) 248 SessionKey = d8 08 01 53 8c ec 4a 08 250 Step 4: Reduce the effective key length to 40 bits 251 SessionKey = d1 26 9e 53 8c ec 4a 08 253 5.5.2. Sample 56-bit Key Derivation 255 Initial Values 256 Password = "clientPass" 258 Step 1: LmPasswordHash(Password, PasswordHash) 259 PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 261 Step 2: Copy PasswordHash to SessionKey 262 SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 264 Step 3: GetKey(PasswordHash, SessionKey, 8) 265 SessionKey = d8 08 01 53 8c ec 4a 08 267 Step 4: Reduce the effective key length to 56 bits 268 SessionKey = d1 08 01 53 8c ec 4a 08 270 5.5.3. Sample 128-bit Key Derivation 272 Initial Values 273 Password = "clientPass" 274 Challenge = 10 2d b5 df 08 5d 30 41 276 Step 1: NtPasswordHash(Password, PasswordHash) 277 PasswordHash = 44 eb ba 8d 53 12 b8 d6 11 47 44 11 f5 69 89 ae 279 Step 2: PasswordHashHash = MD4(PasswordHash) 280 PasswordHashHash = 41 c0 0c 58 4b d2 d9 1c 40 17 a2 a1 2f a5 9f 3f 282 Step 3: GetStartKey(Challenge, PasswordHashHash, InitialSessionKey) 283 InitialSessionKey = a8 94 78 50 cf c0 ac ca d1 78 9f b6 2d dc dd b0 285 Step 4: Copy InitialSessionKey to CurrentSessionKey 286 CurrentSessionKey = a8 94 78 50 cf c0 ac c1 d1 78 9f b6 2d dc dd b0 288 Step 5: GetKey(InitialSessionKey, CurrentSessionKey, 16) 289 CurrentSessionKey = 59 d1 59 bc 09 f7 6f 1d a2 a8 6a 28 ff ec 0b 1e 291 6. Deriving Session Keys from MS-CHAP-2 Credentials 293 Version 2 of the Microsoft Challenge-Handshake Authentication Protocol 294 (MS-CHAP-2) [9] is a Microsoft-proprietary PPP authentication protocol, 295 providing the functionality to which LAN-based users are accustomed 296 while integrating the encryption and hashing algorithms used on Windows 297 networks. 299 The following sections detail the methods used to derive initial session 300 keys from MS-CHAP-2 credentials. 40-, 56- and 128-bit keys are all 301 derived using the same algorithm from the authenticating peer's Windows 302 NT password. The only difference is in the length of the keys and their 303 effective strength: 40- and 56-bit keys are 8 octets in length, while 304 128-bit keys are 16 octets long. Separate keys are derived for the send 305 and receive directions of the session. 307 Implementation Note 309 The initial session keys in both directions are derived from the 310 credentials of the peer that initiated the call and the challenges 311 used are those from the first authentication. This is true as well 312 for each link in a multilink bundle. In the multi-chassis 313 multilink case, implementations are responsible for ensuring that 314 the correct keys are generated on all participating machines. 316 6.1. Generating 40-bit Session Keys 318 When used in conjunction with MS-CHAP-2 authentication, the initial MPPE 319 session keys are derived from the peer's Windows NT password. 321 The first step is to obfuscate the peer's password using 322 NtPasswordHash() function as described in [9]. 324 NtPasswordHash(Password, PasswordHash) 326 The first 16 octets of the result are then hashed again using the MD4 327 algorithm. 329 PasswordHashHash = md4(PasswordHash) 331 The first 16 octets of this second hash are used together with the NT- 332 Response field from the MS-CHAP-2 Response packet [9] as the basis for 333 the master session key: 335 GetMasterKey(PasswordHashHash, NtResponse, MasterKey) 337 Once the master key has been generated, it is used to derive two 40-bit 338 session keys, one for sending and one for receiving: 340 GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE) 341 GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE) 343 The master session keys are never used to encrypt or decrypt data; they 344 are only used in the derivation of transient session keys. The initial 345 transient session keys are obtained by calling the function 346 GetNewKeyFromSHA() (described in [4]): 348 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey) 349 GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8, ReceiveSessionKey) 351 Next, the effective strength of both keys is reduced by setting the 352 first three octets to known constants: 354 SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1 355 SendSessionKey[1] = ReceiveSessionKey[1] = 0x26 356 SendSessionKey[2] = ReceiveSessionKey[2] = 0x9e 358 Finally, the RC4 tables are initialized using the new session keys: 360 rc4_key(SendRC4key, 8, SendSessionKey) 361 rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) 363 6.2. Generating 56-bit Session Keys 365 When used in conjunction with MS-CHAP-2 authentication, the initial MPPE 366 session keys are derived from the peer's Windows NT password. 368 The first step is to obfuscate the peer's password using 369 NtPasswordHash() function as described in [9]. 371 NtPasswordHash(Password, PasswordHash) 373 The first 16 octets of the result are then hashed again using the MD4 374 algorithm. 376 PasswordHashHash = md4(PasswordHash) 378 The first 16 octets of this second hash are used together with the NT- 379 Response field from the MS-CHAP-2 Response packet [9] as the basis for 380 the master session key: 382 GetMasterKey(PasswordHashHash, NtResponse, MasterKey) 384 Once the master key has been generated, it is used to derive two 56-bit 385 session keys, one for sending and one for receiving: 387 GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE) 388 GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE) 390 The master session keys are never used to encrypt or decrypt data; they 391 are only used in the derivation of transient session keys. The initial 392 transient session keys are obtained by calling the function 393 GetNewKeyFromSHA() (described in [4]): 395 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey) 396 GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8, ReceiveSessionKey) 398 Next, the effective strength of both keys is reduced by setting the 399 first octet to a known constant: 401 SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1 403 Finally, the RC4 tables are initialized using the new session keys: 405 rc4_key(SendRC4key, 8, SendSessionKey) 406 rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) 408 6.3. Generating 128-bit Session Keys 410 When used in conjunction with MS-CHAP-2 authentication, the initial MPPE 411 session keys are derived from the peer's Windows NT password. 413 The first step is to obfuscate the peer's password using 414 NtPasswordHash() function as described in [9]. 416 NtPasswordHash(Password, PasswordHash) 418 The first 16 octets of the result are then hashed again using the MD4 419 algorithm. 421 PasswordHashHash = md4(PasswordHash) 423 The first 16 octets of this second hash are used together with the NT- 424 Response field from the MS-CHAP-2 Response packet [9] as the basis for 425 the master session key: 427 GetMasterKey(PasswordHashHash, NtResponse, MasterKey) 429 Once the master key has been generated, it is used to derive two 128-bit 430 master session keys, one for sending and one for receiving: 432 GetAsymmetricStartKey(MasterKey, MasterSendKey, 16, TRUE, TRUE) 433 GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 16, FALSE, TRUE) 435 The master session keys are never used to encrypt or decrypt data; they 436 are only used in the derivation of transient session keys. The initial 437 transient session keys are obtained by calling the function 438 GetNewKeyFromSHA() (described in [4]): 440 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey) 441 GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16, ReceiveSessionKey) 443 Finally, the RC4 tables are initialized using the new session keys: 445 rc4_key(SendRC4key, 16, SendSessionKey) 446 rc4_key(ReceiveRC4key, 16, ReceiveSessionKey) 448 6.4. Key Derivation Functions 450 The following procedures are used to derive the session key. 452 /* 453 * Pads used in key derivation 454 */ 456 SHSpad1[40] = 457 {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 458 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 459 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 460 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; 462 SHSpad2[40] = 463 {0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 464 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 465 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 466 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2}; 468 /* 469 * "Magic" constants used in key derivations 470 */ 472 Magic1[27] = 473 {0x54, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 474 0x68, 0x65, 0x20, 0x4d, 0x50, 0x50, 0x45, 0x20, 0x4d, 475 0x61, 0x73, 0x74, 0x65, 0x72, 0x20, 0x4b, 0x65, 0x79}; 477 Magic2[84] = 478 {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69, 479 0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20, 480 0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, 481 0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20, 0x6b, 0x65, 0x79, 482 0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x73, 483 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, 0x69, 0x64, 0x65, 484 0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, 485 0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20, 486 0x6b, 0x65, 0x79, 0x2e}; 488 Magic3[84] = 489 {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69, 490 0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20, 491 0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, 492 0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20, 493 0x6b, 0x65, 0x79, 0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68, 494 0x65, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, 495 0x69, 0x64, 0x65, 0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 496 0x20, 0x74, 0x68, 0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20, 497 0x6b, 0x65, 0x79, 0x2e}; 499 GetMasterKey( 500 IN 16-octet PasswordHashHash, 501 IN 24-octet NTResponse, 502 OUT 16-octet MasterKey ) 503 { 504 20-octet Digest 506 ZeroMemory(Digest, sizeof(Digest)); 508 /* 509 * SHSInit(), SHSUpdate() and SHSFinal() 510 * are an implementation of the Secure Hash Standard [8]. 511 */ 513 SHSInit(Context); 514 SHSUpdate(Context, PasswordHashHash, 16); 515 SHSUpdate(Context, NTResponse, 24); 516 SHSUpdate(Context, Magic1, 27); 517 SHSFinal(Context, Digest); 519 MoveMemory(MasterKey, Digest, 16); 520 } 522 VOID 523 GetAsymetricStartKey( 524 IN 16-octet MasterKey, 525 OUT 8-to-16 octet SessionKey, 526 IN INTEGER SessionKeyLength, 527 IN BOOLEAN IsSend, 528 IN BOOLEAN IsServer ) 529 { 531 20-octet Digest; 533 ZeroMemory(Digest, 20); 535 if (IsSend) { 536 if (IsServer) { 537 s = Magic3 538 } else { 539 s = Magic2 540 } 541 } else { 542 if (IsServer) { 543 s = Magic2 544 } else { 545 s = Magic3 546 } 547 } 549 /* 550 * SHSInit(), SHSUpdate() and SHSFinal() 551 * are an implementation of the Secure Hash Standard [8]. 552 */ 554 SHSInit(Context); 555 SHSUpdate(Context, MasterKey, 16); 556 SHSUpdate(Context, SHSpad1, 40); 557 SHSUpdate(Context, s, 84); 558 SHSUpdate(Context, SHSpad2, 40); 559 SHSFinal(Context, Digest); 561 MoveMemory(SessionKey, Digest, SessionKeyLength); 562 } 564 6.5. Sample Key Derivations 566 The following sections illustrate 40-, 56- and 128-bit key derivations. 567 All intermediate values are in hexadecimal. 569 6.5.1. Sample 40-bit Key Derivation 571 Initial Values 572 UserName = "User" 573 = 55 73 65 72 575 Password = "clientPass" 576 = 63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00 578 AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28 579 PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E 581 Challenge = D0 2E 43 86 BC E9 12 26 583 NT-Response = 584 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF 586 Step 1: NtPasswordHash(Password, PasswordHash) 587 PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE 589 Step 2: PasswordHashHash = MD4(PasswordHash) 590 PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F 592 Step 3: Derive the master key (GetMasterKey()) 593 MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 595 Step 4: Derive the master send session key (GetAsymmetricStartKey()) 596 SendStartKey40 = 8B 7C DC 14 9B 99 3A 1B 598 Step 5: Derive the intial send session key (GetNewKeyFromSHA()) 599 SendSessionKey40 = D1 26 9E C4 9F A6 2E 3E 601 Sample Encrypted Message 602 rc4(SendSessionKey40, "test message") = 92 91 37 91 7E 58 03 D6 68 D7 58 98 604 6.5.2. Sample 56-bit Key Derivation 606 Initial Values 607 UserName = "User" 608 = 55 73 65 72 610 Password = "clientPass" 611 = 63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00 613 AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28 614 PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E 616 Challenge = D0 2E 43 86 BC E9 12 26 618 NT-Response = 619 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF 621 Step 1: NtPasswordHash(Password, PasswordHash) 622 PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE 624 Step 2: PasswordHashHash = MD4(PasswordHash) 625 PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F 627 Step 3: Derive the master key (GetMasterKey()) 628 MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 630 Step 4: Derive the master send session key (GetAsymmetricStartKey()) 631 SendStartKey56 = 8B 7C DC 14 9B 99 3A 1B 633 Step 5: Derive the intial send session key (GetNewKeyFromSHA()) 634 SendSessionKey56 = D1 5C 00 C4 9F A6 2E 3E 636 Sample Encrypted Message 637 rc4(SendSessionKey40, "test message") = 3F 10 68 33 FA 44 8D A8 42 BC 57 58 639 6.5.3. Sample 128-bit Key Derivation 641 Initial Values 642 UserName = "User" 643 = 55 73 65 72 645 Password = "clientPass" 646 = 63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00 648 AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28 650 PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E 651 Challenge = D0 2E 43 86 BC E9 12 26 653 NT-Response = 654 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF 656 Step 1: NtPasswordHash(Password, PasswordHash) 657 PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE 659 Step 2: PasswordHashHash = MD4(PasswordHash) 660 PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F 662 Step 2: Derive the master key (GetMasterKey()) 663 MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 665 Step 3: Derive the send master session key (GetAsymmetricStartKey()) 667 SendStartKey128 = 8B 7C DC 14 9B 99 3A 1B A1 18 CB 15 3F 56 DC CB 669 Step 4: Derive the intial send session key (GetNewKeyFromSHA()) 670 SendSessionKey128 = 40 5C B2 24 7A 79 56 E6 E2 11 00 7A E2 7B 22 D4 672 Sample Encrypted Message 673 rc4(SendSessionKey128, "test message") = 81 84 83 17 DF 68 84 62 72 FB 5A BE 675 7. Deriving MPPE Session Keys from TLS Session Keys 677 The Extensible Authentication Protocol (EAP) [11] is a PPP extension 678 that provides support for additional authentication methods within 679 PPP. Transport Level Security (TLS) [12] provides for mutual 680 authentication, integrity-protected ciphersuite negotiation and key 681 exchange between two endpoints. EAP-TLS [13] is an EAP authentication 682 type which allows the use of TLS within the PPP authentication 683 framework. The following sections describe the methods used to derive 684 initial session keys from TLS session keys. 56-, 40- and 128-bit keys 685 are derived using the same algorithm. The only difference is in the 686 length of the keys and their effective strength: 56- and 40-bit keys are 687 8 octets in length, while 128-bit keys are 16 octets long. Separate 688 keys are derived for the send and receive directions of the session. 690 7.1. Generating 40-bit Session Keys 692 When MPPE is used in conjunction with EAP-TLS authentication, the TLS 693 master secret is used as the master session key. 695 The algorithm used to derive asymmetrical master session keys from the 696 TLS master secret is described in [13]. The master session keys are 697 never used to encrypt or decrypt data; they are only used in the 698 derivation of transient session keys. 700 Implementation Note 702 If the asymmetrical master keys are less than 8 octets in length, 703 they MUST be padded on the left with zeroes before being used to 704 derive the initial transient session keys. Conversely, if the 705 asymmetrical master keys are more than 8 octets in length, they 706 must be truncated to 8 octets before being used to derive the 707 initial transient session keys. 709 The initial transient session keys are obtained by calling the function 710 GetNewKeyFromSHA() (described in [4]): 712 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey) 713 GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8, ReceiveSessionKey) 715 Next, the effective strength of both keys is reduced by setting the 716 first three octets to known constants: 718 SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1 719 SendSessionKey[1] = ReceiveSessionKey[1] = 0x26 720 SendSessionKey[2] = ReceiveSessionKey[2] = 0x9E 722 Finally, the RC4 tables are initialized using the new session keys: 724 rc4_key(SendRC4key, 8, SendSessionKey) 725 rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) 727 7.2. Generating 56-bit Session Keys 729 When MPPE is used in conjunction with EAP-TLS authentication, the TLS 730 master secret is used as the master session key. 732 The algorithm used to derive asymmetrical master session keys from the 733 TLS master secret is described in [13]. The master session keys are 734 never used to encrypt or decrypt data; they are only used in the 735 derivation of transient session keys. 737 Implementation Note 739 If the asymmetrical master keys are less than 8 octets in length, 740 they MUST be padded on the left with zeroes before being used to 741 derive the initial transient session keys. Conversely, if the 742 asymmetrical master keys are more than 8 octets in length, they 743 must be truncated to 8 octets before being used to derive the 744 initial transient session keys. 746 The initial transient session keys are obtained by calling the function 747 GetNewKeyFromSHA() (described in [4]): 749 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey) 750 GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8, ReceiveSessionKey) 752 Next, the effective strength of both keys is reduced by setting the 753 initial octet to a known constant: 755 SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1 757 Finally, the RC4 tables are initialized using the new session keys: 759 rc4_key(SendRC4key, 8, SendSessionKey) 760 rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) 762 7.3. Generating 128-bit Session Keys 764 When MPPE is used in conjunction with EAP-TLS authentication, the TLS 765 master secret is used as the master session key. 767 The algorithm used to derive asymmetrical master session keys from the 768 TLS master secret is described in [13]. Note that the send key on one 769 side is the receive key on the other. 771 The master session keys are never used to encrypt or decrypt data; they 772 are only used in the derivation of transient session keys. 774 Implementation Note 776 If the asymmetrical master keys are less than 16 octets in length, 777 they MUST be padded on the left with zeroes before being used to 778 derive the initial transient session keys. Conversely, if the 779 asymmetrical master keys are more than 16 octets in length, they 780 must be truncated to 16 octets before being used to derive the 781 initial transient session keys. 783 The initial transient session keys are obtained by calling the function 784 GetNewKeyFromSHA() (described in [4]): 786 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey) 787 GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16, ReceiveSessionKey) 789 Finally, the RC4 tables are initialized using the new session keys: 791 rc4_key(SendRC4key, 16, SendSessionKey) 792 rc4_key(ReceiveRC4key, 16, ReceiveSessionKey) 794 8. Security Considerations 796 8.1. MS-CHAP Credentials 798 Because of the way in which 40-bit keys are derived from MS-CHAP-1 799 credentials, the initial 40-bit session key will be identical in all 800 sessions established under the same peer credentials. For this reason, 801 and because RC4 with a 40-bit key length is believed to be a relatively 802 weak cipher, peers SHOULD NOT use 40-bit keys derived from the LAN 803 Manager password hash (as described above) if it can be avoided. 805 Since the MPPE session keys are derived from user passwords (in the MS- 806 CHAP-1 and MS-CHAP-2 cases), care should be taken to ensure the 807 selection of strong passwords and passwords should be changed 808 frequently. 810 8.2. EAP-TLS Credentials 812 The strength of the session keys is dependent upon the security of the 813 TLS protocol. 815 The EAP server may be on a separate machine from the PPP authenticator; 816 if this is the case, adequate care must be taken in the transmission of 817 the EAP-TLS master keys to the authenticator. 819 9. References 821 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 822 July 1994 824 [2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, 825 June 1996 827 [3] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, 828 October 1998 830 [4] Pall, G. and G. Zorn, "Microsoft Point-to-Point Encryption (MPPE) 831 Protocol", draft-ietf-pppext-mppe-05.txt (work in progress), 832 October 1999 834 [5] RC4 is a proprietary encryption algorithm available under license 835 from RSA Data Security Inc. For licensing information, contact: 837 RSA Data Security, Inc. 838 100 Marine Parkway 839 Redwood City, CA 94065-1031 841 [6] Pall, G., "Microsoft Point-to-Point Compression (MPPC) Protocol", 842 RFC 2118, March 1997 844 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 845 Levels", BCP 14, RFC 2119, March 1997 847 [8] "Secure Hash Standard", Federal Information Processing Standards 848 Publication 180-1, National Institute of Standards and Technology, 849 April 1995 851 [9] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, 852 January 2000 854 [10] Simpson, W., "PPP Challenge Handshake Authentication Protocol 855 (CHAP)", RFC 1994, August 1996 857 [11] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication 858 Protocol (EAP)", RFC 2284, March 1998 860 [12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 861 January 1999 863 [13] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 864 2716, October 1999 866 10. Acknowledgements 868 Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all of 869 Microsoft Corporation, significantly contributed to the design and 870 development of MPPE. 872 Additional thanks to Robert Friend, Joe Davies, Jody Terrill, Archie 873 Cobbs, Mark Deuser, Vijay Baliga, Brad Robel-Forrest and Jeff Haag for 874 useful feedback. 876 The technical portions of this memo were completed while the author was 877 employed by Microsoft Corporation. 879 11. Author's Address 881 Questions about this memo can also be directed to: 883 Glen Zorn 884 cisco Systems 885 500 108th Avenue N.E. 886 Suite 500 887 Bellevue, Washington 98004 888 USA 890 Phone: +1 425 438 8218 891 FAX: +1 425 438 1848 892 EMail: gwz@cisco.com 894 12. Full Copyright Statement 896 Copyright (C) The Internet Society (2000). All Rights Reserved. This 897 document and translations of it may be copied and furnished to others, 898 and derivative works that comment on or otherwise explain it or assist 899 in its implementation may be prepared, copied, published and 900 distributed, in whole or in part, without restriction of any kind, 901 provided that the above copyright notice and this paragraph are included 902 on all such copies and derivative works. However, this document itself 903 may not be modified in any way, such as by removing the copyright notice 904 or references to the Internet Society or other Internet organizations, 905 except as needed for the purpose of developing Internet standards in 906 which case the procedures for copyrights defined in the Internet 907 Standards process must be followed, or as required to translate it into 908 languages other than English. The limited permissions granted above are 909 perpetual and will not be revoked by the Internet Society or its 910 successors or assigns. This document and the information contained 911 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 912 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 913 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 914 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 915 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 917 13. Expiration Date 919 This memo is filed as and expires 920 on May 3, 2001.