diff options
Diffstat (limited to 'rfc/rfc3079.txt')
| -rw-r--r-- | rfc/rfc3079.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/rfc/rfc3079.txt b/rfc/rfc3079.txt new file mode 100644 index 00000000..4d7ba0de --- /dev/null +++ b/rfc/rfc3079.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group G. Zorn +Request for Comments: 3079 cisco Systems +Category: Informational March 2001 + + + Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + The Point-to-Point Protocol (PPP) provides a standard method for + transporting multi-protocol datagrams over point-to-point links. + + The PPP Compression Control Protocol provides a method to negotiate + and utilize compression protocols over PPP encapsulated links. + + Microsoft Point to Point Encryption (MPPE) is a means of representing + PPP packets in an encrypted form. MPPE uses the RSA RC4 algorithm to + provide data confidentiality. The length of the session key to be + used for initializing encryption tables can be negotiated. MPPE + currently supports 40-bit, 56-bit and 128-bit session keys. MPPE + session keys are changed frequently; the exact frequency depends upon + the options negotiated, but may be every packet. MPPE is negotiated + within option 18 in the Compression Control Protocol. + + This document describes the method used to derive initial MPPE + session keys from a variety of credential types. It is expected that + this memo will be updated whenever Microsoft defines a new key + derivation method for MPPE, since its primary purpose is to provide + an open, easily accessible reference for third-parties wishing to + interoperate with Microsoft products. + + MPPE itself (including the protocol used to negotiate its use, the + details of the encryption method used and the algorithm used to + change session keys during a session) is described in RFC 3078. + + + + + + + +Zorn Informational [Page 1] + +RFC 3079 MPPE Key Derivation March 2001 + + +Table of Contents + + 1. Specification of Requirements ............................... 2 + 2. Deriving Session Keys from MS-CHAP Credentials .............. 2 + 2.1. Generating 40-bit Session Keys ............................ 3 + 2.2. Generating 56-bit Session Keys ............................ 3 + 2.3. Generating 128-bit Session Keys ........................... 4 + 2.4. Key Derivation Functions .................................. 5 + 2.5. Sample Key Derivations .................................... 6 + 2.5.1. Sample 40-bit Key Derivation ............................ 6 + 2.5.2. Sample 56-bit Key Derivation ............................ 6 + 2.5.3. Sample 128-bit Key Derivation ........................... 7 + 3. Deriving Session Keys from MS-CHAP-2 Credentials ............ 7 + 3.1. Generating 40-bit Session Keys ............................ 8 + 3.2. Generating 56-bit Session Keys ............................ 9 + 3.3. Generating 128-bit Session Keys ...........................10 + 3.4. Key Derivation Functions ..................................11 + 3.5. Sample Key Derivations ....................................13 + 3.5.1. Sample 40-bit Key Derivation ............................13 + 3.5.2. Sample 56-bit Key Derivation ............................14 + 3.5.3. Sample 128-bit Key Derivation ...........................15 + 4. Deriving MPPE Session Keys from TLS Session Keys ............16 + 4.1. Generating 40-bit Session Keys ............................16 + 4.2. Generating 56-bit Session Keys ............................17 + 4.3. Generating 128-bit Session Keys ...........................17 + 5. Security Considerations .....................................18 + 5.1. MS-CHAP Credentials .......................................18 + 5.2. EAP-TLS Credentials .......................................19 + 6. References ..................................................19 + 7. Acknowledgements ............................................20 + 8. Author's Address ............................................20 + 9. Full Copyright Statement ....................................21 + +1. Specification of Requirements + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as + described in [6]. + +2. Deriving Session Keys from MS-CHAP Credentials + + The Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP-1) + [2] is a Microsoft-proprietary PPP [1] authentication protocol, + providing the functionality to which LAN-based users are accustomed + while integrating the encryption and hashing algorithms used on + Windows networks. + + + + + +Zorn Informational [Page 2] + +RFC 3079 MPPE Key Derivation March 2001 + + + The following sections detail the methods used to derive initial + session keys (40-, 56- and 128-bit) from MS-CHAP-1 credentials. + + Implementation Note + + The initial session key in both directions is derived from the + credentials of the peer that initiated the call and the challenge + used (if any) is the challenge from the first authentication. + This is true for both unilateral and bilateral authentication, as + well as for each link in a multilink bundle. In the multi-chassis + multilink case, implementations are responsible for ensuring that + the correct keys are generated on all participating machines. + +2.1. Generating 40-bit Session Keys + + MPPE uses a derivative of the peer's LAN Manager password as the 40- + bit session key used for initializing the RC4 encryption tables. + + The first step is to obfuscate the peer's password using the + LmPasswordHash() function (described in [2]). The first 8 octets of + the result are used as the basis for the session key generated in the + following way: + +/* +* PasswordHash is the basis for the session key +* SessionKey is a copy of PasswordHash and is the generative session key +* 8 is the length (in octets) of the key to be generated. +* +*/ +Get_Key(PasswordHash, SessionKey, 8) + +/* +* The effective length of the key is reduced to 40 bits by +* replacing the first three bytes as follows: +*/ +SessionKey[0] = 0xd1 ; +SessionKey[1] = 0x26 ; +SessionKey[2] = 0x9e ; + +2.2. Generating 56-bit Session Keys + + MPPE uses a derivative of the peer's LAN Manager password as the 56- + bit session key used for initializing the RC4 encryption tables. + + The first step is to obfuscate the peer's password using the + LmPasswordHash() function (described in [2]). The first 8 octets of + the result are used as the basis for the session key generated in the + following way: + + + +Zorn Informational [Page 3] + +RFC 3079 MPPE Key Derivation March 2001 + + +/* +* PasswordHash is the basis for the session key +* SessionKey is a copy of PasswordHash and is the generative session key +* 8 is the length (in octets) of the key to be generated. +* +*/ +Get_Key(PasswordHash, SessionKey, 8) + +/* +* The effective length of the key is reduced to 56 bits by +* replacing the first byte as follows: +*/ +SessionKey[0] = 0xd1 ; + +2.3. Generating 128-bit Session Keys + + MPPE uses a derivative of the peer's Windows NT password as the 128- + bit session key used for initializing encryption tables. + + The first step is to obfuscate the peer's password using + NtPasswordHash() function as described in [2]. The first 16 octets + of the result are then hashed again using the MD4 algorithm. The + first 16 octets of the second hash are used as the basis for the + session key generated in the following way: + +/* +* Challenge (as described in [9]) is sent by the PPP authenticator +* during authentication and is 8 octets long. +* NtPasswordHashHash is the basis for the session key. +* On return, InitialSessionKey contains the initial session +* key to be used. +*/ +Get_Start_Key(Challenge, NtPasswordHashHash, InitialSessionKey) + +/* +* CurrentSessionKey is a copy of InitialSessionKey +* and is the generative session key. +* Length (in octets) of the key to generate is 16. +* +*/ +Get_Key(InitialSessionKey, CurrentSessionKey, 16) + + + + + + + + + + +Zorn Informational [Page 4] + +RFC 3079 MPPE Key Derivation March 2001 + + +2.4. Key Derivation Functions + + The following procedures are used to derive the session key. + +/* + * Pads used in key derivation + */ + +SHApad1[40] = + {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; + +SHApad2[40] = + {0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2}; + +/* + * SHAInit(), SHAUpdate() and SHAFinal() functions are an + * implementation of Secure Hash Algorithm (SHA-1) [7]. These are + * available in public domain or can be licensed from + * RSA Data Security, Inc. + * + * 1) InitialSessionKey is 8 octets long for 56- and 40-bit + * session keys, 16 octets long for 128 bit session keys. + * 2) CurrentSessionKey is same as InitialSessionKey when this + * routine is called for the first time for the session. + */ + +Get_Key( +IN InitialSessionKey, +IN/OUT CurrentSessionKey +IN LengthOfDesiredKey ) +{ + SHAInit(Context) + SHAUpdate(Context, InitialSessionKey, LengthOfDesiredKey) + SHAUpdate(Context, SHAPad1, 40) + SHAUpdate(Context, CurrentSessionKey, LengthOfDesiredKey) + SHAUpdate(Context, SHAPad2, 40) + SHAFinal(Context, Digest) + memcpy(CurrentSessionKey, Digest, LengthOfDesiredKey) +} + +Get_Start_Key( +IN Challenge, + + + +Zorn Informational [Page 5] + +RFC 3079 MPPE Key Derivation March 2001 + + +IN NtPasswordHashHash, +OUT InitialSessionKey) +{ + SHAInit(Context) + SHAUpdate(Context, NtPasswordHashHash, 16) + SHAUpdate(Context, NtPasswordHashHash, 16) + SHAUpdate(Context, Challenge, 8) + SHAFinal(Context, Digest) + memcpy(InitialSessionKey, Digest, 16) +} + +2.5. Sample Key Derivations + + The following sections illustrate 40-, 56- and 128-bit key + derivations. All intermediate values are in hexadecimal. + +2.5.1. Sample 40-bit Key Derivation + + + Initial Values + Password = "clientPass" + + Step 1: LmPasswordHash(Password, PasswordHash) + PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 + + Step 2: Copy PasswordHash to SessionKey + SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 + + Step 3: GetKey(PasswordHash, SessionKey, 8) + SessionKey = d8 08 01 53 8c ec 4a 08 + + Step 4: Reduce the effective key length to 40 bits + SessionKey = d1 26 9e 53 8c ec 4a 08 + +2.5.2. Sample 56-bit Key Derivation + + Initial Values + Password = "clientPass" + + Step 1: LmPasswordHash(Password, PasswordHash) + PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 + + Step 2: Copy PasswordHash to SessionKey + SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 + + Step 3: GetKey(PasswordHash, SessionKey, 8) + SessionKey = d8 08 01 53 8c ec 4a 08 + + + + +Zorn Informational [Page 6] + +RFC 3079 MPPE Key Derivation March 2001 + + + Step 4: Reduce the effective key length to 56 bits + SessionKey = d1 08 01 53 8c ec 4a 08 + +2.5.3. Sample 128-bit Key Derivation + +Initial Values + Password = "clientPass" + Challenge = 10 2d b5 df 08 5d 30 41 + +Step 1: NtPasswordHash(Password, PasswordHash) + PasswordHash = 44 eb ba 8d 53 12 b8 d6 11 47 44 11 f5 69 89 ae + +Step 2: PasswordHashHash = MD4(PasswordHash) + PasswordHashHash = 41 c0 0c 58 4b d2 d9 1c 40 17 a2 a1 2f a5 9f 3f + +Step 3: GetStartKey(Challenge, PasswordHashHash, InitialSessionKey) + InitialSessionKey = a8 94 78 50 cf c0 ac ca d1 78 9f b6 2d dc dd b0 + +Step 4: Copy InitialSessionKey to CurrentSessionKey + CurrentSessionKey = a8 94 78 50 cf c0 ac c1 d1 78 9f b6 2d dc dd b0 + +Step 5: GetKey(InitialSessionKey, CurrentSessionKey, 16) + CurrentSessionKey = 59 d1 59 bc 09 f7 6f 1d a2 a8 6a 28 ff ec 0b 1e + +3. Deriving Session Keys from MS-CHAP-2 Credentials + + Version 2 of the Microsoft Challenge-Handshake Authentication + Protocol (MS-CHAP-2) [8] is a Microsoft-proprietary PPP + authentication protocol, providing the functionality to which LAN- + based users are accustomed while integrating the encryption and + hashing algorithms used on Windows networks. + + The following sections detail the methods used to derive initial + session keys from MS-CHAP-2 credentials. 40-, 56- and 128-bit keys + are all derived using the same algorithm from the authenticating + peer's Windows NT password. The only difference is in the length of + the keys and their effective strength: 40- and 56-bit keys are 8 + octets in length, while 128-bit keys are 16 octets long. Separate + keys are derived for the send and receive directions of the session. + + Implementation Note + + The initial session keys in both directions are derived from the + credentials of the peer that initiated the call and the challenges + used are those from the first authentication. This is true as + well for each link in a multilink bundle. In the multi-chassis + multilink case, implementations are responsible for ensuring that + the correct keys are generated on all participating machines. + + + +Zorn Informational [Page 7] + +RFC 3079 MPPE Key Derivation March 2001 + + +3.1. Generating 40-bit Session Keys + + When used in conjunction with MS-CHAP-2 authentication, the initial + MPPE session keys are derived from the peer's Windows NT password. + + The first step is to obfuscate the peer's password using + NtPasswordHash() function as described in [8]. + + NtPasswordHash(Password, PasswordHash) + + The first 16 octets of the result are then hashed again using the MD4 + algorithm. + + PasswordHashHash = md4(PasswordHash) + + The first 16 octets of this second hash are used together with the + NT- Response field from the MS-CHAP-2 Response packet [8] as the + basis for the master session key: + + GetMasterKey(PasswordHashHash, NtResponse, MasterKey) + + Once the master key has been generated, it is used to derive two 40- + bit session keys, one for sending and one for receiving: + + GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE) + GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE) + + The master session keys are never used to encrypt or decrypt data; + they are only used in the derivation of transient session keys. The + initial transient session keys are obtained by calling the function + GetNewKeyFromSHA() (described in [3]): + +GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey) +GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8, + ReceiveSessionKey) + + Next, the effective strength of both keys is reduced by setting the + first three octets to known constants: + + SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1 + SendSessionKey[1] = ReceiveSessionKey[1] = 0x26 + SendSessionKey[2] = ReceiveSessionKey[2] = 0x9e + + Finally, the RC4 tables are initialized using the new session keys: + + rc4_key(SendRC4key, 8, SendSessionKey) + rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) + + + + +Zorn Informational [Page 8] + +RFC 3079 MPPE Key Derivation March 2001 + + +3.2. Generating 56-bit Session Keys + + When used in conjunction with MS-CHAP-2 authentication, the initial + MPPE session keys are derived from the peer's Windows NT password. + + The first step is to obfuscate the peer's password using + NtPasswordHash() function as described in [8]. + + NtPasswordHash(Password, PasswordHash) + + The first 16 octets of the result are then hashed again using the MD4 + algorithm. + + PasswordHashHash = md4(PasswordHash) + + The first 16 octets of this second hash are used together with the + NT-Response field from the MS-CHAP-2 Response packet [8] as the basis + for the master session key: + + GetMasterKey(PasswordHashHash, NtResponse, MasterKey) + + Once the master key has been generated, it is used to derive two + 56-bit session keys, one for sending and one for receiving: + + GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE) + GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE) + + The master session keys are never used to encrypt or decrypt data; + they are only used in the derivation of transient session keys. The + initial transient session keys are obtained by calling the function + GetNewKeyFromSHA() (described in [3]): + +GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey) +GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8, + ReceiveSessionKey) + + Next, the effective strength of both keys is reduced by setting the + first octet to a known constant: + + SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1 + + Finally, the RC4 tables are initialized using the new session keys: + + rc4_key(SendRC4key, 8, SendSessionKey) + rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) + + + + + + +Zorn Informational [Page 9] + +RFC 3079 MPPE Key Derivation March 2001 + + +3.3. Generating 128-bit Session Keys + + When used in conjunction with MS-CHAP-2 authentication, the initial + MPPE session keys are derived from the peer's Windows NT password. + + The first step is to obfuscate the peer's password using + NtPasswordHash() function as described in [8]. + + NtPasswordHash(Password, PasswordHash) + + The first 16 octets of the result are then hashed again using the MD4 + algorithm. + + PasswordHashHash = md4(PasswordHash) + + The first 16 octets of this second hash are used together with the + NT-Response field from the MS-CHAP-2 Response packet [8] as the basis + for the master session key: + + GetMasterKey(PasswordHashHash, NtResponse, MasterKey) + + Once the master key has been generated, it is used to derive two + 128-bit master session keys, one for sending and one for receiving: + +GetAsymmetricStartKey(MasterKey, MasterSendKey, 16, TRUE, TRUE) +GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 16, FALSE, TRUE) + + The master session keys are never used to encrypt or decrypt data; + they are only used in the derivation of transient session keys. The + initial transient session keys are obtained by calling the function + GetNewKeyFromSHA() (described in [3]): + +GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey) +GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16, + ReceiveSessionKey) + + Finally, the RC4 tables are initialized using the new session keys: + + rc4_key(SendRC4key, 16, SendSessionKey) + rc4_key(ReceiveRC4key, 16, ReceiveSessionKey) + + + + + + + + + + + +Zorn Informational [Page 10] + +RFC 3079 MPPE Key Derivation March 2001 + + +3.4. Key Derivation Functions + + The following procedures are used to derive the session key. + +/* + * Pads used in key derivation + */ + +SHSpad1[40] = + {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; + +SHSpad2[40] = + {0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2}; + +/* + * "Magic" constants used in key derivations + */ + +Magic1[27] = + {0x54, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, + 0x68, 0x65, 0x20, 0x4d, 0x50, 0x50, 0x45, 0x20, 0x4d, + 0x61, 0x73, 0x74, 0x65, 0x72, 0x20, 0x4b, 0x65, 0x79}; + +Magic2[84] = + {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69, + 0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20, + 0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, + 0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20, 0x6b, 0x65, 0x79, + 0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x73, + 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, 0x69, 0x64, 0x65, + 0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, + 0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20, + 0x6b, 0x65, 0x79, 0x2e}; + +Magic3[84] = + {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69, + 0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20, + 0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, + 0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20, + 0x6b, 0x65, 0x79, 0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68, + 0x65, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, + 0x69, 0x64, 0x65, 0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, + + + +Zorn Informational [Page 11] + +RFC 3079 MPPE Key Derivation March 2001 + + + 0x20, 0x74, 0x68, 0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20, + 0x6b, 0x65, 0x79, 0x2e}; + + + GetMasterKey( + IN 16-octet PasswordHashHash, + IN 24-octet NTResponse, + OUT 16-octet MasterKey ) + { + 20-octet Digest + + ZeroMemory(Digest, sizeof(Digest)); + + /* + * SHSInit(), SHSUpdate() and SHSFinal() + * are an implementation of the Secure Hash Standard [7]. + */ + + SHSInit(Context); + SHSUpdate(Context, PasswordHashHash, 16); + SHSUpdate(Context, NTResponse, 24); + SHSUpdate(Context, Magic1, 27); + SHSFinal(Context, Digest); + + MoveMemory(MasterKey, Digest, 16); + } + + VOID + GetAsymetricStartKey( + IN 16-octet MasterKey, + OUT 8-to-16 octet SessionKey, + IN INTEGER SessionKeyLength, + IN BOOLEAN IsSend, + IN BOOLEAN IsServer ) + { + + 20-octet Digest; + + ZeroMemory(Digest, 20); + + if (IsSend) { + if (IsServer) { + s = Magic3 + } else { + s = Magic2 + } + } else { + if (IsServer) { + + + +Zorn Informational [Page 12] + +RFC 3079 MPPE Key Derivation March 2001 + + + s = Magic2 + } else { + s = Magic3 + } + } + + /* + * SHSInit(), SHSUpdate() and SHSFinal() + * are an implementation of the Secure Hash Standard [7]. + */ + + SHSInit(Context); + SHSUpdate(Context, MasterKey, 16); + SHSUpdate(Context, SHSpad1, 40); + SHSUpdate(Context, s, 84); + SHSUpdate(Context, SHSpad2, 40); + SHSFinal(Context, Digest); + + MoveMemory(SessionKey, Digest, SessionKeyLength); + } + +3.5. Sample Key Derivations + + The following sections illustrate 40-, 56- and 128-bit key + derivations. All intermediate values are in hexadecimal. + +3.5.1. Sample 40-bit Key Derivation + +Initial Values + UserName = "User" + = 55 73 65 72 + + Password = "clientPass" + = 63 00 6C 00 69 00 65 00 6E 00 + 74 00 50 00 61 00 73 00 73 00 + + AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C + 60 21 32 26 26 28 + PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E + + Challenge = D0 2E 43 86 BC E9 12 26 + + NT-Response = + 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 + 11 4A 3D 85 D6 DF + +Step 1: NtPasswordHash(Password, PasswordHash) + PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE + + + +Zorn Informational [Page 13] + +RFC 3079 MPPE Key Derivation March 2001 + + +Step 2: PasswordHashHash = MD4(PasswordHash) + PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F + +Step 3: Derive the master key (GetMasterKey()) + MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 + +Step 4: Derive the master send session key (GetAsymmetricStartKey()) + SendStartKey40 = 8B 7C DC 14 9B 99 3A 1B + +Step 5: Derive the initial send session key (GetNewKeyFromSHA()) + SendSessionKey40 = D1 26 9E C4 9F A6 2E 3E + +Sample Encrypted Message + rc4(SendSessionKey40, "test message") = 92 91 37 91 7E 58 03 D6 + 68 D7 58 98 + +3.5.2. Sample 56-bit Key Derivation + +Initial Values + UserName = "User" + = 55 73 65 72 + + Password = "clientPass" + = 63 00 6C 00 69 00 65 00 6E 00 74 00 50 + 00 61 00 73 00 73 00 + + AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C + 60 21 32 26 26 28 + PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E + + Challenge = D0 2E 43 86 BC E9 12 26 + + NT-Response = + 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 + 11 4A 3D 85 D6 DF + +Step 1: NtPasswordHash(Password, PasswordHash) + PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE + +Step 2: PasswordHashHash = MD4(PasswordHash) + PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F + +Step 3: Derive the master key (GetMasterKey()) + MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 + +Step 4: Derive the master send session key (GetAsymmetricStartKey()) + SendStartKey56 = 8B 7C DC 14 9B 99 3A 1B + + + + +Zorn Informational [Page 14] + +RFC 3079 MPPE Key Derivation March 2001 + + +Step 5: Derive the initial send session key (GetNewKeyFromSHA()) + SendSessionKey56 = D1 5C 00 C4 9F A6 2E 3E + +Sample Encrypted Message + rc4(SendSessionKey40, "test message") = 3F 10 68 33 FA 44 8D + A8 42 BC 57 58 + +3.5.3. Sample 128-bit Key Derivation + +Initial Values + UserName = "User" + = 55 73 65 72 + + Password = "clientPass" + = 63 00 6C 00 69 00 65 00 6E 00 + 74 00 50 00 61 00 73 00 73 00 + + AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C + 60 21 32 26 26 28 + + PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E + + Challenge = D0 2E 43 86 BC E9 12 26 + + NT-Response = + 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 + 11 4A 3D 85 D6 DF + +Step 1: NtPasswordHash(Password, PasswordHash) + PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE + +Step 2: PasswordHashHash = MD4(PasswordHash) + PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F + +Step 2: Derive the master key (GetMasterKey()) + MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 + +Step 3: Derive the send master session key (GetAsymmetricStartKey()) + + SendStartKey128 = 8B 7C DC 14 9B 99 3A 1B A1 18 CB 15 3F 56 DC CB + +Step 4: Derive the initial send session key (GetNewKeyFromSHA()) + SendSessionKey128 = 40 5C B2 24 7A 79 56 E6 E2 11 00 7A E2 7B 22 D4 + +Sample Encrypted Message + rc4(SendSessionKey128, "test message") = 81 84 83 17 DF 68 + 84 62 72 FB 5A BE + + + + +Zorn Informational [Page 15] + +RFC 3079 MPPE Key Derivation March 2001 + + +4. Deriving MPPE Session Keys from TLS Session Keys + + The Extensible Authentication Protocol (EAP) [10] is a PPP extension + that provides support for additional authentication methods within + PPP. Transport Level Security (TLS) [11] provides for mutual + authentication, integrity-protected ciphersuite negotiation and key + exchange between two endpoints. EAP-TLS [12] is an EAP + authentication type which allows the use of TLS within the PPP + authentication framework. The following sections describe the + methods used to derive initial session keys from TLS session keys. + 56-, 40- and 128-bit keys are derived using the same algorithm. The + only difference is in the length of the keys and their effective + strength: 56- and 40-bit keys are 8 octets in length, while 128-bit + keys are 16 octets long. Separate keys are derived for the send and + receive directions of the session. + +4.1. Generating 40-bit Session Keys + + When MPPE is used in conjunction with EAP-TLS authentication, the TLS + master secret is used as the master session key. + + The algorithm used to derive asymmetrical master session keys from + the TLS master secret is described in [12]. The master session keys + are never used to encrypt or decrypt data; they are only used in the + derivation of transient session keys. + + Implementation Note + + If the asymmetrical master keys are less than 8 octets in length, + they MUST be padded on the left with zeroes before being used to + derive the initial transient session keys. Conversely, if the + asymmetrical master keys are more than 8 octets in length, they + must be truncated to 8 octets before being used to derive the + initial transient session keys. + + The initial transient session keys are obtained by calling the + function GetNewKeyFromSHA() (described in [3]): + +GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey) +GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8, +ReceiveSessionKey) + + Next, the effective strength of both keys is reduced by setting the + first three octets to known constants: + + SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1 + SendSessionKey[1] = ReceiveSessionKey[1] = 0x26 + SendSessionKey[2] = ReceiveSessionKey[2] = 0x9E + + + +Zorn Informational [Page 16] + +RFC 3079 MPPE Key Derivation March 2001 + + + Finally, the RC4 tables are initialized using the new session keys: + + rc4_key(SendRC4key, 8, SendSessionKey) + rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) + +4.2. Generating 56-bit Session Keys + + When MPPE is used in conjunction with EAP-TLS authentication, the TLS + master secret is used as the master session key. + + The algorithm used to derive asymmetrical master session keys from + the TLS master secret is described in [12]. The master session keys + are never used to encrypt or decrypt data; they are only used in the + derivation of transient session keys. + + Implementation Note + + If the asymmetrical master keys are less than 8 octets in length, + they MUST be padded on the left with zeroes before being used to + derive the initial transient session keys. Conversely, if the + asymmetrical master keys are more than 8 octets in length, they + must be truncated to 8 octets before being used to derive the + initial transient session keys. + + The initial transient session keys are obtained by calling the + function GetNewKeyFromSHA() (described in [3]): + +GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey) +GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8, +ReceiveSessionKey) + + Next, the effective strength of both keys is reduced by setting the + initial octet to a known constant: + + SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1 + + Finally, the RC4 tables are initialized using the new session keys: + + rc4_key(SendRC4key, 8, SendSessionKey) + rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) + +4.3. Generating 128-bit Session Keys + + When MPPE is used in conjunction with EAP-TLS authentication, the TLS + master secret is used as the master session key. + + + + + + +Zorn Informational [Page 17] + +RFC 3079 MPPE Key Derivation March 2001 + + + The algorithm used to derive asymmetrical master session keys from + the TLS master secret is described in [12]. Note that the send key + on one side is the receive key on the other. + + The master session keys are never used to encrypt or decrypt data; + they are only used in the derivation of transient session keys. + + Implementation Note + + If the asymmetrical master keys are less than 16 octets in length, + they MUST be padded on the left with zeroes before being used to + derive the initial transient session keys. Conversely, if the + asymmetrical master keys are more than 16 octets in length, they + must be truncated to 16 octets before being used to derive the + initial transient session keys. + + The initial transient session keys are obtained by calling the + function GetNewKeyFromSHA() (described in [3]): + +GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey) +GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16, +ReceiveSessionKey) + + Finally, the RC4 tables are initialized using the new session keys: + + rc4_key(SendRC4key, 16, SendSessionKey) + rc4_key(ReceiveRC4key, 16, ReceiveSessionKey) + +5. Security Considerations + +5.1. MS-CHAP Credentials + + Because of the way in which 40-bit keys are derived from MS-CHAP-1 + credentials, the initial 40-bit session key will be identical in all + sessions established under the same peer credentials. For this + reason, and because RC4 with a 40-bit key length is believed to be a + relatively weak cipher, peers SHOULD NOT use 40-bit keys derived from + the LAN Manager password hash (as described above) if it can be + avoided. + + Since the MPPE session keys are derived from user passwords (in the + MS- CHAP-1 and MS-CHAP-2 cases), care should be taken to ensure the + selection of strong passwords and passwords should be changed + frequently. + + + + + + + +Zorn Informational [Page 18] + +RFC 3079 MPPE Key Derivation March 2001 + + +5.2. EAP-TLS Credentials + + The strength of the session keys is dependent upon the security of + the TLS protocol. + + The EAP server may be on a separate machine from the PPP + authenticator; if this is the case, adequate care must be taken in + the transmission of the EAP-TLS master keys to the authenticator. + +6. References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC + 1661, July 1994. + + [2] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, + October 1998. + + [3] Pall, G. and G. Zorn, "Microsoft Point-to-Point Encryption + (MPPE) RFC 3078, March 2001. + + [4] RC4 is a proprietary encryption algorithm available under + license from RSA Data Security Inc. For licensing information, + contact: + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + [5] Pall, G., "Microsoft Point-to-Point Compression (MPPC) + Protocol", RFC 2118, March 1997. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [7] "Secure Hash Standard", Federal Information Processing Standards + Publication 180-1, National Institute of Standards and + Technology, April 1995. + + [8] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, + January 2000. + + [9] Simpson, W., "PPP Challenge Handshake Authentication Protocol + (CHAP)", RFC 1994, August 1996. + + [10] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication + Protocol (EAP)", RFC 2284, March 1998. + + + + + + +Zorn Informational [Page 19] + +RFC 3079 MPPE Key Derivation March 2001 + + + [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, January 1999. + + [12] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", + RFC 2716, October 1999. + +7. Acknowledgements + + Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all + of Microsoft Corporation, significantly contributed to the design and + development of MPPE. + + Additional thanks to Robert Friend, Joe Davies, Jody Terrill, Archie + Cobbs, Mark Deuser, Vijay Baliga, Brad Robel-Forrest and Jeff Haag + for useful feedback. + + The technical portions of this memo were completed while the author + was employed by Microsoft Corporation. + +8. Author's Address + + Questions about this memo can also be directed to: + + Glen Zorn + cisco Systems + 500 108th Avenue N.E. + Suite 500 + Bellevue, Washington 98004 + USA + + Phone: +1 425 438 8218 + FAX: +1 425 438 1848 + EMail: gwz@cisco.com + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 20] + +RFC 3079 MPPE Key Derivation March 2001 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 21] + |