1
2
3
4
5
6
7Network Working Group                                            G. Zorn
8Request for Comments: 3079                                 cisco Systems
9Category: Informational                                       March 2001
10
11
12 Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)
13
14Status of this Memo
15
16   This memo provides information for the Internet community.  It does
17   not specify an Internet standard of any kind.  Distribution of this
18   memo is unlimited.
19
20Copyright Notice
21
22   Copyright (C) The Internet Society (2001).  All Rights Reserved.
23
24Abstract
25
26   The Point-to-Point Protocol (PPP) provides a standard method for
27   transporting multi-protocol datagrams over point-to-point links.
28
29   The PPP Compression Control Protocol provides a method to negotiate
30   and utilize compression protocols over PPP encapsulated links.
31
32   Microsoft Point to Point Encryption (MPPE) is a means of representing
33   PPP packets in an encrypted form.  MPPE uses the RSA RC4 algorithm to
34   provide data confidentiality.  The length of the session key to be
35   used for initializing encryption tables can be negotiated.  MPPE
36   currently supports 40-bit, 56-bit and 128-bit session keys.  MPPE
37   session keys are changed frequently; the exact frequency depends upon
38   the options negotiated, but may be every packet.  MPPE is negotiated
39   within option 18 in the Compression Control Protocol.
40
41   This document describes the method used to derive initial MPPE
42   session keys from a variety of credential types.  It is expected that
43   this memo will be updated whenever Microsoft defines a new key
44   derivation method for MPPE, since its primary purpose is to provide
45   an open, easily accessible reference for third-parties wishing to
46   interoperate with Microsoft products.
47
48   MPPE itself (including the protocol used to negotiate its use, the
49   details of the encryption method used and the algorithm used to
50   change session keys during a session) is described in RFC 3078.
51
52
53
54
55
56
57
58Zorn                         Informational                      [Page 1]
59
60RFC 3079                  MPPE Key Derivation                 March 2001
61
62
63Table of Contents
64
65   1.  Specification of Requirements ............................... 2
66   2.  Deriving Session Keys from MS-CHAP Credentials .............. 2
67   2.1.  Generating 40-bit Session Keys ............................ 3
68   2.2.  Generating 56-bit Session Keys ............................ 3
69   2.3.  Generating 128-bit Session Keys ........................... 4
70   2.4.  Key Derivation Functions .................................. 5
71   2.5.  Sample Key Derivations .................................... 6
72   2.5.1.  Sample 40-bit Key Derivation ............................ 6
73   2.5.2.  Sample 56-bit Key Derivation ............................ 6
74   2.5.3.  Sample 128-bit Key Derivation ........................... 7
75   3.  Deriving Session Keys from MS-CHAP-2 Credentials ............ 7
76   3.1.  Generating 40-bit Session Keys ............................ 8
77   3.2.  Generating 56-bit Session Keys ............................ 9
78   3.3.  Generating 128-bit Session Keys ...........................10
79   3.4.  Key Derivation Functions ..................................11
80   3.5.  Sample Key Derivations ....................................13
81   3.5.1.  Sample 40-bit Key Derivation ............................13
82   3.5.2.  Sample 56-bit Key Derivation ............................14
83   3.5.3.  Sample 128-bit Key Derivation ...........................15
84   4.  Deriving MPPE Session Keys from TLS Session Keys ............16
85   4.1.  Generating 40-bit Session Keys ............................16
86   4.2.  Generating 56-bit Session Keys ............................17
87   4.3.  Generating 128-bit Session Keys ...........................17
88   5.  Security Considerations .....................................18
89   5.1.  MS-CHAP Credentials .......................................18
90   5.2.  EAP-TLS Credentials .......................................19
91   6.  References ..................................................19
92   7.  Acknowledgements ............................................20
93   8.  Author's Address ............................................20
94   9.  Full Copyright Statement ....................................21
95
961.  Specification of Requirements
97
98   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
99   "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
100   described in [6].
101
1022.  Deriving Session Keys from MS-CHAP Credentials
103
104   The Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP-1)
105   [2] is a Microsoft-proprietary PPP [1] authentication protocol,
106   providing the functionality to which LAN-based users are accustomed
107   while integrating the encryption and hashing algorithms used on
108   Windows networks.
109
110
111
112
113
114Zorn                         Informational                      [Page 2]
115
116RFC 3079                  MPPE Key Derivation                 March 2001
117
118
119   The following sections detail the methods used to derive initial
120   session keys (40-, 56- and 128-bit) from MS-CHAP-1 credentials.
121
122   Implementation Note
123
124      The initial session key in both directions is derived from the
125      credentials of the peer that initiated the call and the challenge
126      used (if any) is the challenge from the first authentication.
127      This is true for both unilateral and bilateral authentication, as
128      well as for each link in a multilink bundle.  In the multi-chassis
129      multilink case, implementations are responsible for ensuring that
130      the correct keys are generated on all participating machines.
131
1322.1.  Generating 40-bit Session Keys
133
134   MPPE uses a derivative of the peer's LAN Manager password as the 40-
135   bit session key used for initializing the RC4 encryption tables.
136
137   The first step is to obfuscate the peer's password using the
138   LmPasswordHash() function (described in [2]).  The first 8 octets of
139   the result are used as the basis for the session key generated in the
140   following way:
141
142/*
143* PasswordHash is the basis for the session key
144* SessionKey is a copy of PasswordHash and is the generative session key
145* 8 is the length (in octets) of the key to be generated.
146*
147*/
148Get_Key(PasswordHash, SessionKey, 8)
149
150/*
151* The effective length of the key is reduced to 40 bits by
152* replacing the first three bytes as follows:
153*/
154SessionKey[0] = 0xd1 ;
155SessionKey[1] = 0x26 ;
156SessionKey[2] = 0x9e ;
157
1582.2.  Generating 56-bit Session Keys
159
160   MPPE uses a derivative of the peer's LAN Manager password as the 56-
161   bit session key used for initializing the RC4 encryption tables.
162
163   The first step is to obfuscate the peer's password using the
164   LmPasswordHash() function (described in [2]).  The first 8 octets of
165   the result are used as the basis for the session key generated in the
166   following way:
167
168
169
170Zorn                         Informational                      [Page 3]
171
172RFC 3079                  MPPE Key Derivation                 March 2001
173
174
175/*
176* PasswordHash is the basis for the session key
177* SessionKey is a copy of PasswordHash and is the generative session key
178* 8 is the length (in octets) of the key to be generated.
179*
180*/
181Get_Key(PasswordHash, SessionKey, 8)
182
183/*
184* The effective length of the key is reduced to 56 bits by
185* replacing the first byte as follows:
186*/
187SessionKey[0] = 0xd1 ;
188
1892.3.  Generating 128-bit Session Keys
190
191   MPPE uses a derivative of the peer's Windows NT password as the 128-
192   bit session key used for initializing encryption tables.
193
194   The first step is to obfuscate the peer's password using
195   NtPasswordHash() function as described in [2].  The first 16 octets
196   of the result are then hashed again using the MD4 algorithm.  The
197   first 16 octets of the second hash are used as the basis for the
198   session key generated in the following way:
199
200/*
201* Challenge (as described in [9]) is sent by the PPP authenticator
202* during authentication and is 8 octets long.
203* NtPasswordHashHash is the basis for the session key.
204* On return, InitialSessionKey contains the initial session
205* key to be used.
206*/
207Get_Start_Key(Challenge, NtPasswordHashHash, InitialSessionKey)
208
209/*
210* CurrentSessionKey is a copy of InitialSessionKey
211* and is the generative session key.
212* Length (in octets) of the key to generate is 16.
213*
214*/
215Get_Key(InitialSessionKey, CurrentSessionKey, 16)
216
217
218
219
220
221
222
223
224
225
226Zorn                         Informational                      [Page 4]
227
228RFC 3079                  MPPE Key Derivation                 March 2001
229
230
2312.4.  Key Derivation Functions
232
233   The following procedures are used to derive the session key.
234
235/*
236 * Pads used in key derivation
237 */
238
239SHApad1[40] =
240   {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
241    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
242    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
243    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
244
245SHApad2[40] =
246   {0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
247    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
248    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
249    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2};
250
251/*
252 * SHAInit(), SHAUpdate() and SHAFinal() functions are an
253 * implementation of Secure Hash Algorithm (SHA-1) [7]. These are
254 * available in public domain or can be licensed from
255 * RSA Data Security, Inc.
256 *
257 * 1) InitialSessionKey is 8 octets long for 56- and 40-bit
258 *    session keys, 16 octets long for 128 bit session keys.
259 * 2) CurrentSessionKey is same as InitialSessionKey when this
260 *    routine is called for the first time for the session.
261 */
262
263Get_Key(
264IN     InitialSessionKey,
265IN/OUT CurrentSessionKey
266IN     LengthOfDesiredKey )
267{
268   SHAInit(Context)
269   SHAUpdate(Context, InitialSessionKey, LengthOfDesiredKey)
270   SHAUpdate(Context, SHAPad1, 40)
271   SHAUpdate(Context, CurrentSessionKey, LengthOfDesiredKey)
272   SHAUpdate(Context, SHAPad2, 40)
273   SHAFinal(Context, Digest)
274   memcpy(CurrentSessionKey, Digest, LengthOfDesiredKey)
275}
276
277Get_Start_Key(
278IN  Challenge,
279
280
281
282Zorn                         Informational                      [Page 5]
283
284RFC 3079                  MPPE Key Derivation                 March 2001
285
286
287IN  NtPasswordHashHash,
288OUT InitialSessionKey)
289{
290   SHAInit(Context)
291   SHAUpdate(Context, NtPasswordHashHash, 16)
292   SHAUpdate(Context, NtPasswordHashHash, 16)
293   SHAUpdate(Context, Challenge, 8)
294   SHAFinal(Context, Digest)
295   memcpy(InitialSessionKey, Digest, 16)
296}
297
2982.5.  Sample Key Derivations
299
300   The following sections illustrate 40-, 56- and 128-bit key
301   derivations.  All intermediate values are in hexadecimal.
302
3032.5.1.  Sample 40-bit Key Derivation
304
305
306   Initial Values
307      Password = "clientPass"
308
309   Step 1: LmPasswordHash(Password, PasswordHash)
310      PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
311
312   Step 2: Copy PasswordHash to SessionKey
313      SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
314
315   Step 3: GetKey(PasswordHash, SessionKey, 8)
316      SessionKey = d8 08 01 53 8c ec 4a 08
317
318   Step 4: Reduce the effective key length to 40 bits
319      SessionKey = d1 26 9e 53 8c ec 4a 08
320
3212.5.2.  Sample 56-bit Key Derivation
322
323   Initial Values
324      Password = "clientPass"
325
326   Step 1: LmPasswordHash(Password, PasswordHash)
327      PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
328
329   Step 2: Copy PasswordHash to SessionKey
330      SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
331
332   Step 3: GetKey(PasswordHash, SessionKey, 8)
333      SessionKey = d8 08 01 53 8c ec 4a 08
334
335
336
337
338Zorn                         Informational                      [Page 6]
339
340RFC 3079                  MPPE Key Derivation                 March 2001
341
342
343   Step 4: Reduce the effective key length to 56 bits
344      SessionKey = d1 08 01 53 8c ec 4a 08
345
3462.5.3.  Sample 128-bit Key Derivation
347
348Initial Values
349   Password = "clientPass"
350   Challenge = 10 2d b5 df 08 5d 30 41
351
352Step 1: NtPasswordHash(Password, PasswordHash)
353   PasswordHash = 44 eb ba 8d 53 12 b8 d6 11 47 44 11 f5 69 89 ae
354
355Step 2: PasswordHashHash = MD4(PasswordHash)
356   PasswordHashHash = 41 c0 0c 58 4b d2 d9 1c 40 17 a2 a1 2f a5 9f 3f
357
358Step 3: GetStartKey(Challenge, PasswordHashHash, InitialSessionKey)
359   InitialSessionKey = a8 94 78 50 cf c0 ac ca d1 78 9f b6 2d dc dd b0
360
361Step 4: Copy InitialSessionKey to CurrentSessionKey
362   CurrentSessionKey = a8 94 78 50 cf c0 ac c1 d1 78 9f b6 2d dc dd b0
363
364Step 5: GetKey(InitialSessionKey, CurrentSessionKey, 16)
365   CurrentSessionKey = 59 d1 59 bc 09 f7 6f 1d a2 a8 6a 28 ff ec 0b 1e
366
3673.  Deriving Session Keys from MS-CHAP-2 Credentials
368
369   Version 2 of the Microsoft Challenge-Handshake Authentication
370   Protocol (MS-CHAP-2) [8] is a Microsoft-proprietary PPP
371   authentication protocol, providing the functionality to which LAN-
372   based users are accustomed while integrating the encryption and
373   hashing algorithms used on Windows networks.
374
375   The following sections detail the methods used to derive initial
376   session keys from MS-CHAP-2 credentials.  40-, 56- and 128-bit keys
377   are all derived using the same algorithm from the authenticating
378   peer's Windows NT password.  The only difference is in the length of
379   the keys and their effective strength: 40- and 56-bit keys are 8
380   octets in length, while 128-bit keys are 16 octets long.  Separate
381   keys are derived for the send and receive directions of the session.
382
383   Implementation Note
384
385      The initial session keys in both directions are derived from the
386      credentials of the peer that initiated the call and the challenges
387      used are those from the first authentication.  This is true as
388      well for each link in a multilink bundle.  In the multi-chassis
389      multilink case, implementations are responsible for ensuring that
390      the correct keys are generated on all participating machines.
391
392
393
394Zorn                         Informational                      [Page 7]
395
396RFC 3079                  MPPE Key Derivation                 March 2001
397
398
3993.1.  Generating 40-bit Session Keys
400
401   When used in conjunction with MS-CHAP-2 authentication, the initial
402   MPPE session keys are derived from the peer's Windows NT password.
403
404   The first step is to obfuscate the peer's password using
405   NtPasswordHash() function as described in [8].
406
407      NtPasswordHash(Password, PasswordHash)
408
409   The first 16 octets of the result are then hashed again using the MD4
410   algorithm.
411
412      PasswordHashHash = md4(PasswordHash)
413
414   The first 16 octets of this second hash are used together with the
415   NT- Response field from the MS-CHAP-2 Response packet [8] as the
416   basis for the master session key:
417
418      GetMasterKey(PasswordHashHash, NtResponse, MasterKey)
419
420   Once the master key has been generated, it is used to derive two 40-
421   bit session keys, one for sending and one for receiving:
422
423      GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE)
424      GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE)
425
426   The master session keys are never used to encrypt or decrypt data;
427   they are only used in the derivation of transient session keys.  The
428   initial transient session keys are obtained by calling the function
429   GetNewKeyFromSHA() (described in [3]):
430
431GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
432GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
433                                               ReceiveSessionKey)
434
435   Next, the effective strength of both keys is reduced by setting the
436   first three octets to known constants:
437
438      SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1
439      SendSessionKey[1] = ReceiveSessionKey[1] = 0x26
440      SendSessionKey[2] = ReceiveSessionKey[2] = 0x9e
441
442   Finally, the RC4 tables are initialized using the new session keys:
443
444      rc4_key(SendRC4key, 8, SendSessionKey)
445      rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
446
447
448
449
450Zorn                         Informational                      [Page 8]
451
452RFC 3079                  MPPE Key Derivation                 March 2001
453
454
4553.2.  Generating 56-bit Session Keys
456
457   When used in conjunction with MS-CHAP-2 authentication, the initial
458   MPPE session keys are derived from the peer's Windows NT password.
459
460   The first step is to obfuscate the peer's password using
461   NtPasswordHash() function as described in [8].
462
463      NtPasswordHash(Password, PasswordHash)
464
465   The first 16 octets of the result are then hashed again using the MD4
466   algorithm.
467
468      PasswordHashHash = md4(PasswordHash)
469
470   The first 16 octets of this second hash are used together with the
471   NT-Response field from the MS-CHAP-2 Response packet [8] as the basis
472   for the master session key:
473
474      GetMasterKey(PasswordHashHash, NtResponse, MasterKey)
475
476   Once the master key has been generated, it is used to derive two
477   56-bit session keys, one for sending and one for receiving:
478
479      GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE)
480      GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE)
481
482   The master session keys are never used to encrypt or decrypt data;
483   they are only used in the derivation of transient session keys.  The
484   initial transient session keys are obtained by calling the function
485   GetNewKeyFromSHA() (described in [3]):
486
487GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
488GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
489                                               ReceiveSessionKey)
490
491   Next, the effective strength of both keys is reduced by setting the
492   first octet to a known constant:
493
494      SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1
495
496   Finally, the RC4 tables are initialized using the new session keys:
497
498      rc4_key(SendRC4key, 8, SendSessionKey)
499      rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
500
501
502
503
504
505
506Zorn                         Informational                      [Page 9]
507
508RFC 3079                  MPPE Key Derivation                 March 2001
509
510
5113.3.  Generating 128-bit Session Keys
512
513   When used in conjunction with MS-CHAP-2 authentication, the initial
514   MPPE session keys are derived from the peer's Windows NT password.
515
516   The first step is to obfuscate the peer's password using
517   NtPasswordHash() function as described in [8].
518
519      NtPasswordHash(Password, PasswordHash)
520
521   The first 16 octets of the result are then hashed again using the MD4
522   algorithm.
523
524      PasswordHashHash = md4(PasswordHash)
525
526   The first 16 octets of this second hash are used together with the
527   NT-Response field from the MS-CHAP-2 Response packet [8] as the basis
528   for the master session key:
529
530      GetMasterKey(PasswordHashHash, NtResponse, MasterKey)
531
532   Once the master key has been generated, it is used to derive two
533   128-bit master session keys, one for sending and one for receiving:
534
535GetAsymmetricStartKey(MasterKey, MasterSendKey, 16, TRUE, TRUE)
536GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 16, FALSE, TRUE)
537
538   The master session keys are never used to encrypt or decrypt data;
539   they are only used in the derivation of transient session keys.  The
540   initial transient session keys are obtained by calling the function
541   GetNewKeyFromSHA() (described in [3]):
542
543GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey)
544GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16,
545                                                ReceiveSessionKey)
546
547   Finally, the RC4 tables are initialized using the new session keys:
548
549      rc4_key(SendRC4key, 16, SendSessionKey)
550      rc4_key(ReceiveRC4key, 16, ReceiveSessionKey)
551
552
553
554
555
556
557
558
559
560
561
562Zorn                         Informational                     [Page 10]
563
564RFC 3079                  MPPE Key Derivation                 March 2001
565
566
5673.4.  Key Derivation Functions
568
569   The following procedures are used to derive the session key.
570
571/*
572 * Pads used in key derivation
573 */
574
575SHSpad1[40] =
576   {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
577    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
578    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
579    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
580
581SHSpad2[40] =
582   {0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
583    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
584    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
585    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2};
586
587/*
588 * "Magic" constants used in key derivations
589 */
590
591Magic1[27] =
592   {0x54, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74,
593    0x68, 0x65, 0x20, 0x4d, 0x50, 0x50, 0x45, 0x20, 0x4d,
594    0x61, 0x73, 0x74, 0x65, 0x72, 0x20, 0x4b, 0x65, 0x79};
595
596Magic2[84] =
597   {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69,
598    0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20,
599    0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68,
600    0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20, 0x6b, 0x65, 0x79,
601    0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x73,
602    0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, 0x69, 0x64, 0x65,
603    0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68,
604    0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20,
605    0x6b, 0x65, 0x79, 0x2e};
606
607Magic3[84] =
608   {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69,
609    0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20,
610    0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68,
611    0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20,
612    0x6b, 0x65, 0x79, 0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68,
613    0x65, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73,
614    0x69, 0x64, 0x65, 0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73,
615
616
617
618Zorn                         Informational                     [Page 11]
619
620RFC 3079                  MPPE Key Derivation                 March 2001
621
622
623    0x20, 0x74, 0x68, 0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20,
624    0x6b, 0x65, 0x79, 0x2e};
625
626
627   GetMasterKey(
628   IN  16-octet  PasswordHashHash,
629   IN  24-octet  NTResponse,
630   OUT 16-octet  MasterKey )
631   {
632      20-octet Digest
633
634      ZeroMemory(Digest, sizeof(Digest));
635
636      /*
637       * SHSInit(), SHSUpdate() and SHSFinal()
638       * are an implementation of the Secure Hash Standard [7].
639       */
640
641      SHSInit(Context);
642      SHSUpdate(Context, PasswordHashHash, 16);
643      SHSUpdate(Context, NTResponse, 24);
644      SHSUpdate(Context, Magic1, 27);
645      SHSFinal(Context, Digest);
646
647      MoveMemory(MasterKey, Digest, 16);
648   }
649
650   VOID
651   GetAsymetricStartKey(
652   IN   16-octet      MasterKey,
653   OUT  8-to-16 octet SessionKey,
654   IN   INTEGER       SessionKeyLength,
655   IN   BOOLEAN       IsSend,
656   IN   BOOLEAN       IsServer )
657   {
658
659      20-octet Digest;
660
661      ZeroMemory(Digest, 20);
662
663      if (IsSend) {
664         if (IsServer) {
665            s = Magic3
666         } else {
667            s = Magic2
668         }
669      } else {
670         if (IsServer) {
671
672
673
674Zorn                         Informational                     [Page 12]
675
676RFC 3079                  MPPE Key Derivation                 March 2001
677
678
679            s = Magic2
680         } else {
681            s = Magic3
682         }
683      }
684
685      /*
686       * SHSInit(), SHSUpdate() and SHSFinal()
687       * are an implementation of the Secure Hash Standard [7].
688       */
689
690      SHSInit(Context);
691      SHSUpdate(Context, MasterKey, 16);
692      SHSUpdate(Context, SHSpad1, 40);
693      SHSUpdate(Context, s, 84);
694      SHSUpdate(Context, SHSpad2, 40);
695      SHSFinal(Context, Digest);
696
697      MoveMemory(SessionKey, Digest, SessionKeyLength);
698   }
699
7003.5.  Sample Key Derivations
701
702   The following sections illustrate 40-, 56- and 128-bit key
703   derivations. All intermediate values are in hexadecimal.
704
7053.5.1.  Sample 40-bit Key Derivation
706
707Initial Values
708   UserName = "User"
709            =  55 73 65 72
710
711   Password = "clientPass"
712            = 63 00 6C 00 69 00 65 00 6E 00
713              74 00 50 00 61 00 73 00 73 00
714
715   AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C
716                            60 21 32 26 26 28
717   PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
718
719   Challenge = D0 2E 43 86 BC E9 12 26
720
721   NT-Response =
722   82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33
723   11 4A 3D 85 D6 DF
724
725Step 1: NtPasswordHash(Password, PasswordHash)
726   PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
727
728
729
730Zorn                         Informational                     [Page 13]
731
732RFC 3079                  MPPE Key Derivation                 March 2001
733
734
735Step 2: PasswordHashHash = MD4(PasswordHash)
736   PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
737
738Step 3: Derive the master key (GetMasterKey())
739   MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31
740
741Step 4: Derive the master send session key (GetAsymmetricStartKey())
742   SendStartKey40 = 8B 7C DC 14 9B 99 3A 1B
743
744Step 5: Derive the initial send session key (GetNewKeyFromSHA())
745   SendSessionKey40 = D1 26 9E C4 9F A6 2E 3E
746
747Sample Encrypted Message
748   rc4(SendSessionKey40, "test message") = 92 91 37 91 7E 58 03 D6
749                                           68 D7 58 98
750
7513.5.2.  Sample 56-bit Key Derivation
752
753Initial Values
754   UserName = "User"
755            =  55 73 65 72
756
757   Password = "clientPass"
758            = 63 00 6C 00 69 00 65 00 6E 00 74 00 50
759              00 61 00 73 00 73 00
760
761   AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C
762                            60 21 32 26 26 28
763   PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
764
765   Challenge = D0 2E 43 86 BC E9 12 26
766
767   NT-Response =
768   82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33
769   11 4A 3D 85 D6 DF
770
771Step 1: NtPasswordHash(Password, PasswordHash)
772   PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
773
774Step 2: PasswordHashHash = MD4(PasswordHash)
775   PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
776
777Step 3: Derive the master key (GetMasterKey())
778   MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31
779
780Step 4: Derive the master send session key (GetAsymmetricStartKey())
781   SendStartKey56 = 8B 7C DC 14 9B 99 3A 1B
782
783
784
785
786Zorn                         Informational                     [Page 14]
787
788RFC 3079                  MPPE Key Derivation                 March 2001
789
790
791Step 5: Derive the initial send session key (GetNewKeyFromSHA())
792   SendSessionKey56 = D1 5C 00 C4 9F A6 2E 3E
793
794Sample Encrypted Message
795   rc4(SendSessionKey40, "test message") = 3F 10 68 33 FA 44 8D
796                                           A8 42 BC 57 58
797
7983.5.3.  Sample 128-bit Key Derivation
799
800Initial Values
801   UserName = "User"
802            =  55 73 65 72
803
804   Password = "clientPass"
805            = 63 00 6C 00 69 00 65 00 6E 00
806              74 00 50 00 61 00 73 00 73 00
807
808   AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C
809                            60 21 32 26 26 28
810
811   PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
812
813   Challenge = D0 2E 43 86 BC E9 12 26
814
815   NT-Response =
816   82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33
817   11 4A 3D 85 D6 DF
818
819Step 1: NtPasswordHash(Password, PasswordHash)
820   PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
821
822Step 2: PasswordHashHash = MD4(PasswordHash)
823   PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
824
825Step 2: Derive the master key (GetMasterKey())
826   MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31
827
828Step 3: Derive the send master session key (GetAsymmetricStartKey())
829
830   SendStartKey128 = 8B 7C DC 14 9B 99 3A 1B A1 18 CB 15 3F 56 DC CB
831
832Step 4: Derive the initial send session key (GetNewKeyFromSHA())
833   SendSessionKey128 = 40 5C B2 24 7A 79 56 E6 E2 11 00 7A E2 7B 22 D4
834
835Sample Encrypted Message
836  rc4(SendSessionKey128, "test message") = 81 84 83 17 DF 68
837                                           84 62 72 FB 5A BE
838
839
840
841
842Zorn                         Informational                     [Page 15]
843
844RFC 3079                  MPPE Key Derivation                 March 2001
845
846
8474.  Deriving MPPE Session Keys from TLS Session Keys
848
849   The Extensible Authentication Protocol (EAP) [10] is a PPP extension
850   that provides support  for  additional  authentication methods within
851   PPP.  Transport  Level  Security  (TLS) [11] provides for mutual
852   authentication, integrity-protected ciphersuite negotiation and key
853   exchange between two  endpoints.  EAP-TLS [12] is an EAP
854   authentication type which allows the use of TLS within the PPP
855   authentication framework.  The following sections describe the
856   methods used to derive initial session keys from TLS session keys.
857   56-, 40- and 128-bit keys are derived using the same algorithm.  The
858   only difference is in the length of the keys and their effective
859   strength: 56- and 40-bit keys are 8 octets in length, while 128-bit
860   keys are 16 octets long.  Separate keys are derived for the send and
861   receive directions of the session.
862
8634.1.  Generating 40-bit Session Keys
864
865   When MPPE is used in conjunction with EAP-TLS authentication, the TLS
866   master secret is used as the master session key.
867
868   The algorithm used to derive asymmetrical master session keys from
869   the TLS master secret is described in [12].  The master session keys
870   are never used to encrypt or decrypt data; they are only used in the
871   derivation of transient session keys.
872
873   Implementation Note
874
875      If the asymmetrical master keys are less than 8 octets in length,
876      they MUST be padded on the left with zeroes before being used to
877      derive the initial transient session keys.  Conversely, if the
878      asymmetrical master keys are more than 8 octets in length, they
879      must be truncated to 8 octets before being used to derive the
880      initial transient session keys.
881
882   The initial transient session keys are obtained by calling the
883   function GetNewKeyFromSHA() (described in [3]):
884
885GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
886GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
887ReceiveSessionKey)
888
889   Next, the effective strength of both keys is reduced by setting the
890   first three octets to known constants:
891
892      SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1
893      SendSessionKey[1] = ReceiveSessionKey[1] = 0x26
894      SendSessionKey[2] = ReceiveSessionKey[2] = 0x9E
895
896
897
898Zorn                         Informational                     [Page 16]
899
900RFC 3079                  MPPE Key Derivation                 March 2001
901
902
903   Finally, the RC4 tables are initialized using the new session keys:
904
905      rc4_key(SendRC4key, 8, SendSessionKey)
906      rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
907
9084.2.  Generating 56-bit Session Keys
909
910   When MPPE is used in conjunction with EAP-TLS authentication, the TLS
911   master secret is used as the master session key.
912
913   The algorithm used to derive asymmetrical master session keys from
914   the TLS master secret is described in [12].  The master session keys
915   are never used to encrypt or decrypt data; they are only used in the
916   derivation of transient session keys.
917
918   Implementation Note
919
920      If the asymmetrical master keys are less than 8 octets in length,
921      they MUST be padded on the left with zeroes before being used to
922      derive the initial transient session keys.  Conversely, if the
923      asymmetrical master keys are more than 8 octets in length, they
924      must be truncated to 8 octets before being used to derive the
925      initial transient session keys.
926
927   The initial transient session keys are obtained by calling the
928   function GetNewKeyFromSHA() (described in [3]):
929
930GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
931GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
932ReceiveSessionKey)
933
934   Next, the effective strength of both keys is reduced by setting the
935   initial octet to a known constant:
936
937      SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1
938
939   Finally, the RC4 tables are initialized using the new session keys:
940
941      rc4_key(SendRC4key, 8, SendSessionKey)
942      rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
943
9444.3.  Generating 128-bit Session Keys
945
946   When MPPE is used in conjunction with EAP-TLS authentication, the TLS
947   master secret is used as the master session key.
948
949
950
951
952
953
954Zorn                         Informational                     [Page 17]
955
956RFC 3079                  MPPE Key Derivation                 March 2001
957
958
959   The algorithm used to derive asymmetrical master session keys from
960   the TLS master secret is described in [12].  Note that the send key
961   on one side is the receive key on the other.
962
963   The master session keys are never used to encrypt or decrypt data;
964   they are only used in the derivation of transient session keys.
965
966   Implementation Note
967
968      If the asymmetrical master keys are less than 16 octets in length,
969      they MUST be padded on the left with zeroes before being used to
970      derive the initial transient session keys.  Conversely, if the
971      asymmetrical master keys are more than 16 octets in length, they
972      must be truncated to 16 octets before being used to derive the
973      initial transient session keys.
974
975   The initial transient session keys are obtained by calling the
976   function GetNewKeyFromSHA() (described in [3]):
977
978GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey)
979GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16,
980ReceiveSessionKey)
981
982   Finally, the RC4 tables are initialized using the new session keys:
983
984      rc4_key(SendRC4key, 16, SendSessionKey)
985      rc4_key(ReceiveRC4key, 16, ReceiveSessionKey)
986
9875.  Security Considerations
988
9895.1.  MS-CHAP Credentials
990
991   Because of the way in which 40-bit keys are derived from MS-CHAP-1
992   credentials, the initial 40-bit session key will be identical in all
993   sessions established under the same peer credentials.  For this
994   reason, and because RC4 with a 40-bit key length is believed to be a
995   relatively weak cipher, peers SHOULD NOT use 40-bit keys derived from
996   the LAN Manager password hash (as described above) if it can be
997   avoided.
998
999   Since the MPPE session keys are derived from user passwords (in the
1000   MS- CHAP-1 and MS-CHAP-2 cases), care should be taken to ensure the
1001   selection of strong passwords and passwords should be changed
1002   frequently.
1003
1004
1005
1006
1007
1008
1009
1010Zorn                         Informational                     [Page 18]
1011
1012RFC 3079                  MPPE Key Derivation                 March 2001
1013
1014
10155.2.  EAP-TLS Credentials
1016
1017   The strength of the session keys is dependent upon the security of
1018   the TLS protocol.
1019
1020   The EAP server may be on a separate machine from the PPP
1021   authenticator; if this is the case, adequate care must be taken in
1022   the transmission of the EAP-TLS master keys to the authenticator.
1023
10246.  References
1025
1026   [1]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1027        1661, July 1994.
1028
1029   [2]  Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433,
1030        October 1998.
1031
1032   [3]  Pall, G. and G. Zorn, "Microsoft Point-to-Point Encryption
1033        (MPPE) RFC 3078, March 2001.
1034
1035   [4]  RC4 is a proprietary encryption algorithm available under
1036        license from RSA Data Security Inc.  For licensing information,
1037        contact:
1038               RSA Data Security, Inc.
1039               100 Marine Parkway
1040               Redwood City, CA 94065-1031
1041
1042   [5]  Pall, G., "Microsoft Point-to-Point Compression (MPPC)
1043        Protocol", RFC 2118, March 1997.
1044
1045   [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
1046        Levels", BCP 14, RFC 2119, March 1997.
1047
1048   [7]  "Secure Hash Standard", Federal Information Processing Standards
1049        Publication 180-1, National Institute of Standards and
1050        Technology, April 1995.
1051
1052   [8]  Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759,
1053        January 2000.
1054
1055   [9]  Simpson, W., "PPP Challenge Handshake Authentication Protocol
1056        (CHAP)", RFC 1994, August 1996.
1057
1058   [10] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
1059        Protocol (EAP)", RFC 2284, March 1998.
1060
1061
1062
1063
1064
1065
1066Zorn                         Informational                     [Page 19]
1067
1068RFC 3079                  MPPE Key Derivation                 March 2001
1069
1070
1071   [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
1072        2246, January 1999.
1073
1074   [12] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
1075        RFC 2716, October 1999.
1076
10777.  Acknowledgements
1078
1079   Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all
1080   of Microsoft Corporation, significantly contributed to the design and
1081   development of MPPE.
1082
1083   Additional thanks to Robert Friend, Joe Davies, Jody Terrill, Archie
1084   Cobbs, Mark Deuser, Vijay Baliga, Brad Robel-Forrest and Jeff Haag
1085   for useful feedback.
1086
1087   The technical portions of this memo were completed while the author
1088   was employed by Microsoft Corporation.
1089
10908.  Author's Address
1091
1092   Questions about this memo can also be directed to:
1093
1094   Glen Zorn
1095   cisco Systems
1096   500 108th Avenue N.E.
1097   Suite 500
1098   Bellevue, Washington 98004
1099   USA
1100
1101   Phone: +1 425 438 8218
1102   FAX:   +1 425 438 1848
1103   EMail: gwz@cisco.com
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122Zorn                         Informational                     [Page 20]
1123
1124RFC 3079                  MPPE Key Derivation                 March 2001
1125
1126
11279.  Full Copyright Statement
1128
1129   Copyright (C) The Internet Society (2001).  All Rights Reserved.
1130
1131   This document and translations of it may be copied and furnished to
1132   others, and derivative works that comment on or otherwise explain it
1133   or assist in its implementation may be prepared, copied, published
1134   and distributed, in whole or in part, without restriction of any
1135   kind, provided that the above copyright notice and this paragraph are
1136   included on all such copies and derivative works.  However, this
1137   document itself may not be modified in any way, such as by removing
1138   the copyright notice or references to the Internet Society or other
1139   Internet organizations, except as needed for the purpose of
1140   developing Internet standards in which case the procedures for
1141   copyrights defined in the Internet Standards process must be
1142   followed, or as required to translate it into languages other than
1143   English.
1144
1145   The limited permissions granted above are perpetual and will not be
1146   revoked by the Internet Society or its successors or assigns.
1147
1148   This document and the information contained herein is provided on an
1149   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1150   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1151   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1152   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1153   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1154
1155Acknowledgement
1156
1157   Funding for the RFC Editor function is currently provided by the
1158   Internet Society.
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178Zorn                         Informational                     [Page 21]
1179
1180