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).
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
