Jouni Malinen said: "This looks like an appropriate text to add. However, I would request a small clarification on the exact scope of the different EAP-MSCHAPv2 and EAP-GTC behavior. As far as EAP-FAST-MSCHAPv2 vs. EAP-MSCHAPv2 is concerned, I would expect that EAP-FAST-MSCHAPv2 is actually used both for unauthenticated (anonymous) and server-authenticated provisioning while the proposed note seemed to indicate that the different behavior is implied by the use of an anonymous tunnel. See below for suggested changes to resolve this.
I'm assuming that the implicit challenges derived from the TLS handshake are not used in the EAP-FAST authentication, i.e., normal authentication would be using something that is closer to EAP-MSCHAPv2, not EAP-FAST-MSCHAPv2. However, I think that even that use of EAP-MSCHAPv2 differs a bit from the way it is used in other protocols, e.g., as far as key derivation is concerned, but this would have been more of a comment for RFC 4851 than these two drafts that are now discussed. Anyway, since the key derivation from inner method is used also during provisioning, it would be useful to specify the exact process used to derive ISK from EAP-FAST-MSCHAPv2 (especially the order of send/recv MS-MPPE keys which seems to differ from the way this is used in PEAPv0 with cryptobinding). " Are you suggesting that the version of EAP-MSCHAPv2 described in the document differs in terms of the MSK/EMSK derivation? Or are you suggesting that further details are needed on how padding is accomplished with respect to ISK derivation? In general, ISK derivation doesn't relate to an EAP method so much as the tunneling method that utilizes the keys exported by the inner method. So if the issue is purely in the ISKs, then this doesn't really relate to EAP-FAST-MSCHAPv2 or EAP-MSCHAPv2 so much as to EAP-FAST provisioning mechanism. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
