idnits 2.17.1 draft-ietf-pppext-mschapv1-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-16) 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 is 1 instance of too long lines in the document, the longest one being 3 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...' == (38 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 9345 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 101, but not defined == Missing Reference: '40' is mentioned on line 147, but not defined == Outdated reference: A later version (-05) exists of draft-ietf-pppext-mppe-02 Summary: 12 errors (**), 0 flaws (~~), 10 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 September 1998 4 6 Deriving MPPE Keys From MS-CHAP V1 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 March 24, 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 The Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) [3] 41 is a Microsoft-proprietary PPP authentication protocol, providing the 42 functionality to which LAN-based users are accustomed while integrating 43 the encryption and hashing algorithms used on Windows networks. 45 Microsoft Point to Point Encryption (MPPE) [4] is a means of represent- 46 ing PPP packets in an encrypted form. MPPE uses the RSA RC4 [5] 47 algorithm to provide data confidentiality. The length of the session 48 key to be used for initializing encryption tables can be negotiated. 49 MPPE currently supports 40-bit and 128-bit session keys. MPPE session 50 keys are changed frequently; the exact frequency depends upon the 51 options negotiated, but may be every packet. MPPE is negotiated within 52 option 18 [6] in the Compression Control Protocol. 54 This document describes the method used to derive the initial MPPE ses- 55 sion keys from MS-CHAP credentials. The algorithm used to change ses- 56 sion keys during a session is described in [4]. 58 3. Specification of Requirements 60 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 61 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 62 described in [7]. 64 4. Deriving Session Keys from MS-CHAP Credentials 66 The following sections detail the methods used to derive initial session 67 keys (both 40- and 128-bit) from MS-CHAP credentials. 69 Implementation Note 71 The initial session key in both directions is derived from the cre- 72 dentials of the peer that initiated the call and the challenge used 73 (if any) is the challenge from the first authentication. This is 74 true for both unilateral and bilateral authentication, as well as for 75 each link in a multilink bundle. In the multi-chassis multilink 76 case, implementations are responsible for ensuring that the correct 77 keys are generated on all participating machines. 79 4.1. Generating 40-bit Session Keys 81 MPPE uses a derivative of the peer's LAN Manager password as the 40-bit 82 session key used for initializing the RC4 encryption tables. 84 The first step is to obfuscate the peer's password using the LmPassword- 85 Hash() function (described in [3]). The first 8 octets of the result 86 are used as the basis for the session key generated in the following 87 way: 89 /* 90 * PasswordHash is the basis for the session key 91 * SessionKey is a copy of PasswordHash and is the generative session key 92 * 8 is the length (in octets) of the key to be generated. 93 * 94 */ 95 Get_Key(PasswordHash, SessionKey, 8) 97 /* 98 * The effective length of the key is reduced to 40 bits by 99 * replacing the first three bytes as follows: 100 */ 101 SessionKey[0] = 0xD1 ; 102 SessionKey[1] = 0x26 ; 103 SessionKey[2] = 0x9E ; 105 4.2. Generating 128-bit Session Keys 107 MPPE uses a derivative of the peer's Windows NT password as the 128-bit 108 session key used for initializing encryption tables. 110 The first step is to obfuscate the peer's password using NtPassword- 111 Hash() function as described in [3]. The first 16 octets of the result 112 are then hashed again using the MD4 algorithm. The first 16 octets of 113 the second hash are used as the basis for the session key generated in 114 the following way: 116 /* 117 * Challenge (as described in [7]) is sent by the PPP authenticator 118 * during authentication and is 8 octets long. 119 * NtPasswordHashHash is the basis for the session key. 120 * On return, InitialSessionKey contains the initial session 121 * key to be used. 122 */ 123 Get_Start_Key(Challenge, NtPasswordHashHash, InitialSessionKey) 125 /* 126 * CurrentSessionKey is a copy of InitialSessionKey 127 * and is the generative session key. 128 * Length (in octets) of the key to generate is 16. 129 * 130 */ 131 Get_Key(InitialSessionKey, CurrentSessionKey, 16) 133 4.3. Key Derivation Functions 135 The following procedures are used to derive the session key. 137 /* 138 * Pads used in key derivation 139 */ 141 SHApad1[40] = 142 {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 143 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 144 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 145 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; 147 SHApad2[40] = 148 {0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 149 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 150 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 151 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2}; 153 /* 154 * SHAInit(), SHAUpdate() and SHAFinal() functions are an 155 * implementation of Secure Hash Algorithm (SHA-1) [8]. These are 156 * available in public domain or can be licensed from 157 * RSA Data Security, Inc. 158 * 159 * 1) InitialSessionKey is 8 octets long for 40 bit session keys, 160 * 16 octets long for 128 bit session keys. 161 * 2) CurrentSessionKey is same as InitialSessionKey when this 162 * routine is called for the first time for the session. 163 */ 165 Get_Key( 166 IN InitialSessionKey, 167 IN/OUT CurrentSessionKey 168 IN LengthOfDesiredKey ) 169 { 170 SHAInit(Context) 171 SHAUpdate(Context, InitialSessionKey, LengthOfDesiredKey) 172 SHAUpdate(Context, SHAPad1, 40) 173 SHAUpdate(Context, CurrentSessionKey, LengthOfDesiredKey) 174 SHAUpdate(Context, SHAPad2, 40) 175 SHAFinal(Context, Digest) 176 memcpy(CurrentSessionKey, Digest, LengthOfDesiredKey) 177 } 179 Get_Start_Key( 180 IN Challenge, 181 IN NtPasswordHashHash, 182 OUT InitialSessionKey) 183 { 184 SHAInit(Context) 185 SHAUpdate(Context, NtPasswordHashHash, 16) 186 SHAUpdate(Context, NtPasswordHashHash, 16) 187 SHAUpdate(Context, Challenge, 8) 188 SHAFinal(Context, Digest) 189 memcpy(InitialSessionKey, Digest, 16) 190 } 192 5. Security Considerations 194 Because of the way in which 40-bit keys are derived, the initial 40-bit 195 session key will be identical in all sessions established under the same 196 peer credentials. For this reason, and because RC4 with a 40-bit key 197 length is believed to be a relatively weak cipher, peers SHOULD NOT use 198 40-bit keys derived from the LAN Manager password hash (as described 199 above) if it can be avoided. 201 6. References 203 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 204 July 1994 206 [2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, 207 June 1996 209 [3] Zorn, G. & Cobb, S., "Microsoft PPP CHAP Extensions", draft-ietf- 210 pppext-mschap-00.txt (work in progress), March 1998 212 [4] Pall, G. S., & Zorn, G., "Microsoft Point-to-Point Encryption 213 (MPPE) Protocol", draft-ietf-pppext-mppe-02.txt, September 1998 215 [5] RC4 is a proprietary encryption algorithm available under license 216 from RSA Data Security Inc. For licensing information, contact: 217 RSA Data Security, Inc. 218 100 Marine Parkway 219 Redwood City, CA 94065-1031 221 [6] Pall, G., "Microsoft Point-to-Point Compression (MPPC) Protocol", 222 RFC 2118, March 1997 224 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 225 Levels", BCP 14, RFC 2119, March 1997 227 [8] "Secure Hash Standard", Federal Information Processing Standards 228 Publication 180-1, National Institute of Standards and Technology, 229 April 1995 231 7. Acknowledgements 233 Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all of 234 Microsoft Corporation, significantly contributed to the design and 235 development of MPPE. 237 Additional thanks to Robert Friend (rfriend@hifn.com), Joe Davies 238 (josephd@microsoft.com), Jody Terrill (jodyt@extendsys.com), Archie 239 Cobbs (archie@whistle.com), Mark Deuser (deuser@us.ibm.com), and Jeff 240 Haag (jeff_haag@3com.com) for useful feedback. 242 8. Chair's Address 244 The PPP Extensions Working Group can be contacted via the current chair: 246 Karl Fox 247 Ascend Communications 248 3518 Riverside Drive 249 Suite 101 250 Columbus, OH 43221 252 Phone: +1 614 326 6841 253 Email: karl@ascend.com 255 9. Author's Address 257 Questions about this memo can also be directed to: 259 Glen Zorn 260 Microsoft Corporation 261 One Microsoft Way 262 Redmond, Washington 98052 264 Phone: +1 425 703 1559 265 FAX: +1 425 936 7329 266 EMail: glennz@microsoft.com 268 10. Expiration Date 270 This memo is filed as and 271 expires on March 24, 1999. 273 Appendix A - Sample Key Derivations 274 The following sections illustrate both 40- and 128-bit key derivations. 275 All intermediate values are in hexadecimal. 277 Appendix A.1 - Sample 40-bit Key Derivation 279 Initial Values 280 Password = "clientPass" 282 Step 1: LmPasswordHash(Password, PasswordHash) 283 PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 285 Step 2: Copy PasswordHash to SessionKey 286 SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 288 Step 3: GetKey(PasswordHash, SessionKey, 8) 289 SessionKey = d8 08 01 53 8c ec 4a 08 291 Step 4: Reduce the effective key length to 40 bits 292 SessionKey = d1 26 9e 53 8c ec 4a 08 294 Appendix A.2 - Sample 128-bit Key Derivation 296 Initial Values 297 Password = "clientPass" 298 Challenge = 10 2d b5 df 08 5d 30 41 300 Step 1: NtPasswordHash(Password, PasswordHash) 301 PasswordHash = 44 eb ba 8d 53 12 b8 d6 11 47 44 11 f5 69 89 ae 303 Step 2: PasswordHashHash = MD4(PasswordHash) 304 PasswordHashHash = 41 c0 0c 58 4b d2 d9 1c 40 17 a2 a1 2f a5 9f 3f 306 Step 2: GetStartKey(Challenge, PasswordHashHash, InitialSessionKey) 307 InitialSessionKey = a8 94 78 50 cf c0 ac ca d1 78 9f b6 2d dc dd b0 309 Step 3: Copy InitialSessionKey to CurrentSessionKey 310 CurrentSessionKey = a8 94 78 50 cf c0 ac ca d1 78 9f b6 2d dc dd b0 312 Step 4: GetKey(InitialSessionKey, CurrentSessionKey, 16) 313 CurrentSessionKey = 59 d1 59 bc 09 f7 6f 1d a2 a8 6a 28 ff ec 0b 1e