On Wed, Feb 11, 2009 at 03:56:08PM -0800, Bernard Aboba wrote: > You are saying that in addition to the interoperability issues described in > Tim's note with respect to the EAP-FAST-MSCHAPv2, that this document > also does not conform to the key derivation specified in EAP MS-CHAPv2, > and that as a result it can't interoperate with existing implementations of > EAP MS-CHAPv2, for regular non-provisioning uses?
I'm not sure I would go as far as saying it does not conform to a specification taken into account the unclear situation on how MSK derivation for EAP-MSCHAPv2 is defined. More exact statement would be that EAP-FAST ISK and PEAPv0/cryptobinding ISK derivations use different order of MS-MPPE-Send-Key and MS-MPPE-Recv-Key in the EAP-MSCHAPv2 MSK. In other words, implementations that try to use the same EAP-MSCHAPv2 implementation (including the rules for MSK derivation) would not interoperate with both deployed EAP-FAST and EAP-PEAPv0/cryptobinding implementations. Depending on the Send/Recv key order in the MSK, one of the tunnel methods using the MSK from EAP-MSCHAPv2 would need to swap the keys. In my particular case, I ended up implementing EAP-FAST first and found the issue when trying to interoperate with EAP-PEAPv0 cryptobinding after that. As far as which use is correct is concerned, it is not exactly trivial thing to figure out, but my current interpretation of various specifications related to MS-MPPE keys is that the order used in PEAPv0 cryptobinding would match with the order used in other methods. Anyway, having a single document describing EAP-MSCHAPv2, including MSK derivation, would be a useful thing to have for anyone who wants to implement these things. The use of MS-MPPE Send/Recv keys that are different for server and peer side instead of defining the same derivation of full MSK for both server and peer make it very easy to get this wrong. I ended up having to figure this out by testing against deployed implementations and getting surprised that the same code does not work with both uses. Anyway, like I mentioned before, this EAP-MSCHAPv2 MSK difference is not strictly speaking an issue that would be specific to draft-cam-winget-eap-fast-provisioning; it would have been useful to describe it in RFC 4851. Anyway, it looks like the authors are willing to include the additional description in draft-cam-winget-eap-fast-provisioning and for the goal of describing a deployed protocol and allowing vendors to implement it in interoperable way, it is useful to get this described somewhere and this draft looks like the best place to do so at this point. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
