On Wed, Feb 11, 2009 at 10:05:57PM -0500, Hao Zhou (hzhou) wrote: > To clarify, EAP-FAST-MSCHAPv2 is only being used during anonymous > provisioning mode, in other cases, the normal EAP-MSCHAPv2 is being > used. This is mentioned in draft-cam-winget-eap-fast-provisioning > Section 3.2.3 and reflects current implementations. The design is to > specifically minimize the risk associated with an anonymous tunnel, > which does not apply to an authenticated tunnel.
Thanks. Apparently, I looked at my implementation bit too quickly and assumed it was using the implicit challenges for both provision cases, but you are correct, the draft does indeed state this only for anonymous provisioning and I now confirmed that that was also what my implementation was doing. In other words, the changes I asked for the note for draft-cam-winget-eap-fast-provisioning for the topic of when to use EAP-MSCHAPv2 vs. EAP-FAST-MSCHAPv2 should not be made and only the change request for draft-zhou-emu-fast-gtc would be suitable. > As for the ISK derivation from EAP-MSCHAPv2, a further clarification is > probably helpful. As discussed, EAP-MSCHAPv2 documentation doesn't > really describe how MSK is generated, only referencing RFC3079. RFC3079 > only describes how two 128-bit keys are generated, but leaves out how > these two keys are combined to form the MSK. This leaves it to be > defined in a tunnel method specific way. It seems that EAP-FAST may have > defined a combining algorithm different with the other method. I agree for the part that MSK derivation for EAP-MSCHAPv2 is not very well defined and it did require going through multiple documents to figure out the order. As far as MSK derivation for an inner method being tunnel method specific is concerned, I do not agree with that. It should be up to the inner method specification to define how MSK is derived and tunnel method ISK should just use that MSK. I do not remember anymore where exactly I found this, but probably based on the MSCHAPv2 documents and the way MS-MPPE keys are used in other methods, I ended up with EAP-MSCHAPv2 MSK = server MS-MPPE-Recv-Key | server MS-MPPE-Send-Key This 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 > Here is what we propose to add to draft-cam-winget-eap-fast-provisioning > Section 3.2.3 to clarify the issue. > > "The inner session key (ISK) generation for EAP-FAST-MSCHAPv2 and > EAP-MSCHAPv2 used inside EAP-FAST MUST follow the steps below. Two 128 > bit master keys MasterSendKey and MasterReceiveKey are generated > according to the RFC3079. They are combined to form the ISK, with > MasterSendKey taking the first 16 octets and MasterReceiveKey taking the > last 16 octets. " Taken into account that MasterSendKey in RFC 3079 is defined as the server MS-MPPE-Send-Key, this matches with the order I described above and including this note in the draft would indeed be a helpful clarification. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu