[PATCHv2] EAP-TEAP: like EAP-FAST, reverse the order of the MS-MPPE keys

[Jouni Malinen]

On Tue, Jul 05, 2022 at 09:18:37AM +0100, Alexander Clouter wrote:
> This gets us working with FreeRADIUS (which works for Win11).

What is this protocol change based on? Just the fact that it happens to
be implemented in this manner in FreeRADIUS and Windows 11? I was hoping
that TEAP would get rid of the inconvenient undocumented mess and
differences in EAP-FAST, including this specific case of interpreting
MSK differently for one of the possible inner methods. I would use PEAP
cryptobinding as a counter example of how this should be implemented in
TEAP instead of following FAST here..

RFC 7170 does not seem to document any exceptions for MSK use from inner
methods in Section 5.2 and as far as I can tell, the way
wpa_supplicant/hostapd derive MSK from EAP-MSCHAPv2 matches RFC 3079
Section 3.3 and Microsoft's [MS-CHAP].pdf (well, ignoring the part about
32 bytes of extra zeros which are truncated away for TEAP IMSK). And
PEAPv0 with cryptobinding interoperates using MSK as derived here when
testing against Windows implementation. So why would PEAP and TEAP use
a different definition of the inner method MSK?

IMHO, this is not really an acceptable way of defining an EAP method. At
minimum, an errata entry would need to be filed against RFC 7170 if the
goal here is to make it match what some vendors have implemented in
deployed software components. Furthermore, I would still not recommend
anyone to deploy TEAP before an updated RFC (or at least a draft aiming
to become such an RFC) has been published with all the errata issues
resolved.

> +		if (msk_len == 32 &&
> +		    phase2_vendor == EAP_VENDOR_IETF &&
> +		    phase2_method == EAP_TYPE_MSCHAPV2) {
> +			/*
> +			 * EAP-TEAP uses reverse order for MS-MPPE keys when deriving
> +			 * MSK from EAP-MSCHAPv2. Swap the keys here to get the correct
> +			 * IMSK for EAP-TEAP cryptobinding.
> +			 */

That comment needs to reference a proper definition for that claimed
reverse order. Alas, I have not been able to find such a definition.

-- 
Jouni Malinen                                            PGP id EFC895FA