doc/rfc/rfc3079.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                            G. Zorn
   8 Request for Comments: 3079                                 cisco Systems
   9 Category: Informational                                       March 2001
  10
  11
  12  Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)
  13
  14 Status 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
  20 Copyright Notice
  21
  22    Copyright (C) The Internet Society (2001).  All Rights Reserved.
  23
  24 Abstract
  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
  58 Zorn                         Informational                      [Page 1]
  59 \f
  60 RFC 3079                  MPPE Key Derivation                 March 2001
  61
  62
  63 Table 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
  96 1.  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
 102 2.  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
 114 Zorn                         Informational                      [Page 2]
 115 \f
 116 RFC 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
 132 2.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 */
 148 Get_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 */
 154 SessionKey[0] = 0xd1 ;
 155 SessionKey[1] = 0x26 ;
 156 SessionKey[2] = 0x9e ;
 157
 158 2.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
 170 Zorn                         Informational                      [Page 3]
 171 \f
 172 RFC 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 */
 181 Get_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 */
 187 SessionKey[0] = 0xd1 ;
 188
 189 2.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 */
 207 Get_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 */
 215 Get_Key(InitialSessionKey, CurrentSessionKey, 16)
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Zorn                         Informational                      [Page 4]
 227 \f
 228 RFC 3079                  MPPE Key Derivation                 March 2001
 229
 230
 231 2.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
 239 SHApad1[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
 245 SHApad2[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
 263 Get_Key(
 264 IN     InitialSessionKey,
 265 IN/OUT CurrentSessionKey
 266 IN     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
 277 Get_Start_Key(
 278 IN  Challenge,
 279
 280
 281
 282 Zorn                         Informational                      [Page 5]
 283 \f
 284 RFC 3079                  MPPE Key Derivation                 March 2001
 285
 286
 287 IN  NtPasswordHashHash,
 288 OUT 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
 298 2.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
 303 2.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
 321 2.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
 338 Zorn                         Informational                      [Page 6]
 339 \f
 340 RFC 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
 346 2.5.3.  Sample 128-bit Key Derivation
 347
 348 Initial Values
 349    Password = "clientPass"
 350    Challenge = 10 2d b5 df 08 5d 30 41
 351
 352 Step 1: NtPasswordHash(Password, PasswordHash)
 353    PasswordHash = 44 eb ba 8d 53 12 b8 d6 11 47 44 11 f5 69 89 ae
 354
 355 Step 2: PasswordHashHash = MD4(PasswordHash)
 356    PasswordHashHash = 41 c0 0c 58 4b d2 d9 1c 40 17 a2 a1 2f a5 9f 3f
 357
 358 Step 3: GetStartKey(Challenge, PasswordHashHash, InitialSessionKey)
 359    InitialSessionKey = a8 94 78 50 cf c0 ac ca d1 78 9f b6 2d dc dd b0
 360
 361 Step 4: Copy InitialSessionKey to CurrentSessionKey
 362    CurrentSessionKey = a8 94 78 50 cf c0 ac c1 d1 78 9f b6 2d dc dd b0
 363
 364 Step 5: GetKey(InitialSessionKey, CurrentSessionKey, 16)
 365    CurrentSessionKey = 59 d1 59 bc 09 f7 6f 1d a2 a8 6a 28 ff ec 0b 1e
 366
 367 3.  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
 394 Zorn                         Informational                      [Page 7]
 395 \f
 396 RFC 3079                  MPPE Key Derivation                 March 2001
 397
 398
 399 3.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
 431 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
 432 GetNewKeyFromSHA(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
 450 Zorn                         Informational                      [Page 8]
 451 \f
 452 RFC 3079                  MPPE Key Derivation                 March 2001
 453
 454
 455 3.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
 487 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
 488 GetNewKeyFromSHA(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
 506 Zorn                         Informational                      [Page 9]
 507 \f
 508 RFC 3079                  MPPE Key Derivation                 March 2001
 509
 510
 511 3.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
 535 GetAsymmetricStartKey(MasterKey, MasterSendKey, 16, TRUE, TRUE)
 536 GetAsymmetricStartKey(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
 543 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey)
 544 GetNewKeyFromSHA(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
 562 Zorn                         Informational                     [Page 10]
 563 \f
 564 RFC 3079                  MPPE Key Derivation                 March 2001
 565
 566
 567 3.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
 575 SHSpad1[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
 581 SHSpad2[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
 591 Magic1[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
 596 Magic2[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
 607 Magic3[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
 618 Zorn                         Informational                     [Page 11]
 619 \f
 620 RFC 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
 674 Zorn                         Informational                     [Page 12]
 675 \f
 676 RFC 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
 700 3.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
 705 3.5.1.  Sample 40-bit Key Derivation
 706
 707 Initial 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
 725 Step 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
 730 Zorn                         Informational                     [Page 13]
 731 \f
 732 RFC 3079                  MPPE Key Derivation                 March 2001
 733
 734
 735 Step 2: PasswordHashHash = MD4(PasswordHash)
 736    PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
 737
 738 Step 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
 741 Step 4: Derive the master send session key (GetAsymmetricStartKey())
 742    SendStartKey40 = 8B 7C DC 14 9B 99 3A 1B
 743
 744 Step 5: Derive the initial send session key (GetNewKeyFromSHA())
 745    SendSessionKey40 = D1 26 9E C4 9F A6 2E 3E
 746
 747 Sample Encrypted Message
 748    rc4(SendSessionKey40, "test message") = 92 91 37 91 7E 58 03 D6
 749                                            68 D7 58 98
 750
 751 3.5.2.  Sample 56-bit Key Derivation
 752
 753 Initial 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
 771 Step 1: NtPasswordHash(Password, PasswordHash)
 772    PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
 773
 774 Step 2: PasswordHashHash = MD4(PasswordHash)
 775    PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
 776
 777 Step 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
 780 Step 4: Derive the master send session key (GetAsymmetricStartKey())
 781    SendStartKey56 = 8B 7C DC 14 9B 99 3A 1B
 782
 783
 784
 785
 786 Zorn                         Informational                     [Page 14]
 787 \f
 788 RFC 3079                  MPPE Key Derivation                 March 2001
 789
 790
 791 Step 5: Derive the initial send session key (GetNewKeyFromSHA())
 792    SendSessionKey56 = D1 5C 00 C4 9F A6 2E 3E
 793
 794 Sample Encrypted Message
 795    rc4(SendSessionKey40, "test message") = 3F 10 68 33 FA 44 8D
 796                                            A8 42 BC 57 58
 797
 798 3.5.3.  Sample 128-bit Key Derivation
 799
 800 Initial 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
 819 Step 1: NtPasswordHash(Password, PasswordHash)
 820    PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
 821
 822 Step 2: PasswordHashHash = MD4(PasswordHash)
 823    PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
 824
 825 Step 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
 828 Step 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
 832 Step 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
 835 Sample Encrypted Message
 836   rc4(SendSessionKey128, "test message") = 81 84 83 17 DF 68
 837                                            84 62 72 FB 5A BE
 838
 839
 840
 841
 842 Zorn                         Informational                     [Page 15]
 843 \f
 844 RFC 3079                  MPPE Key Derivation                 March 2001
 845
 846
 847 4.  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
 863 4.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
 885 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
 886 GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
 887 ReceiveSessionKey)
 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
 898 Zorn                         Informational                     [Page 16]
 899 \f
 900 RFC 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
 908 4.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
 930 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
 931 GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
 932 ReceiveSessionKey)
 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
 944 4.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
 954 Zorn                         Informational                     [Page 17]
 955 \f
 956 RFC 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
 978 GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey)
 979 GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16,
 980 ReceiveSessionKey)
 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
 987 5.  Security Considerations
 988
 989 5.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
1010 Zorn                         Informational                     [Page 18]
1011 \f
1012 RFC 3079                  MPPE Key Derivation                 March 2001
1013
1014
1015 5.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
1024 6.  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
1066 Zorn                         Informational                     [Page 19]
1067 \f
1068 RFC 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
1077 7.  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
1090 8.  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
1122 Zorn                         Informational                     [Page 20]
1123 \f
1124 RFC 3079                  MPPE Key Derivation                 March 2001
1125
1126
1127 9.  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
1155 Acknowledgement
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
1178 Zorn                         Informational                     [Page 21]
1179 \f