Subject: Re: [Emu] Key derivation differences

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Feb 2009 18:50:56 -0800

Jouni Malinen said:
 
"As far as MSK derivation for an inner method being tunnel methodspecific is concerned, I do not agree with that. It should be up to theinner method specification to define how MSK is derived and tunnelmethod ISK should just use that MSK.I do not remember anymore where exactly I found this, but probablybased on the MSCHAPv2 documents and the way MS-MPPE keys are used inother methods, I ended up with EAP-MSCHAPv2    MSK = server MS-MPPE-Recv-Key | server MS-MPPE-Send-KeyThis is the order used in EAP-PEAPv0 cryptobinding derivation.In EAP-FAST, the opposite order is used:    MSK = server MS-MPPE-Send-Key | server MS-MPPE-Recv-Key"I agree with this.  Allowing tunnel methods to re-define the MSK derivation of inner EAP methods does not make sense. 
 
With respect to the composition of the MSK from the server MS-MPPE-Recv-Key and MS-MPPE-Send-Key, the formula you
cite above is correct, which is confirmed in RFC 5216, Section 2.3: 
 
   Enc-RECV-Key = MSK(0,31) = Peer to Authenticator Encryption Key                  (MS-MPPE-Recv-Key in [RFC2548]).  Also known as the                  PMK in [IEEE-802.11].   Enc-SEND-Key = MSK(32,63) = Authenticator to Peer Encryption Key                  (MS-MPPE-Send-Key in [RFC2548])
 
So yes, the EAP-FAST formula is reversed. 
 
With respect to padding, Pasi points out correctly that neither RFC 2759 nor 3079 describe how the 128-bit keys produced by MS-CHAPv2 are to be interpretted in this formula.   By IETF 74, I'm hoping to have one or more MS-CHAPv2 errata to clarify this and other issues that have come up (such as internationalization).