Hello, On Sun, 27 Nov 2022, at 12:59, Jouni Malinen wrote: >> This gets us working with FreeRADIUS (which works for Win11). > > What is this protocol change based on? We both know the TEAP RFC is a tirefire and you know the answer to this question. I have no idea why you are asking it? > Just the fact that it happens to be implemented in this manner in FreeRADIUS and Windows 11? No. This is how it is implemented in Windows 10/11 and I suspect it also is for Cisco ISE and Microsoft NPS as they claim to talk to Windows 10/11. I do not have the source code, influence or energy to make Microsoft change their implementation on a bazillion devices in a non-backwards compatible breaking manner[1]. Do you? I too can ask questions I know the answer to! :) Instead I opted to first work on making FreeRADIUS interop with Windows 10/11 (using hostapd as a useful reference) and once I had that working for EAP-TLS/EAP-MSCHAPv2 and chaining[2] I looked to work out how to get hostapd working with Win11; fortunately for me you had 99.9% of this figured out and written out. As the implementation in hostapd is marked "might make your pants explode[3]" and as MS do not care about interoperability I figured there was a chance you would be receptive this as the next best thing. Now we know what Windows does, we have a few more options available to us. > 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.. Whether we like it or not, we are forced to have the TEAP 'specification' massaged into what is deployed and not what RFC7170 states, albeit in a manner that is unfortunately open to wide varying interpretation. > 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. TEAP has its roots in FAST rather than PEAP so I do not understand why this is relevant; though if you squint and drink heavily enough I suppose FAST could start to look a bit like PEAP. > So why would PEAP and TEAP use a different definition of the inner method MSK? I don't know. TEAP is based on FAST which does flip the keying material. It works when I flip the keys, when tracing[3] Windows it concurs. At the moment it does not work, irregardless of what the RFC leads you to believe. > 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. Okay, why are you telling me this? If you Google stalk me you will find I am a nobody. I have no idea what MS are actually doing other than measuring things empirically. What do you want me to do? I suppose being (seemingly) the only person to have done any TEAP interop I might be able to fix up the RFC...but does that really block making hostapd talk to Win10/11 today? > 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. I assume you are being ironic here as obviously MS did not get your memo on this :) There is a (stalled) effort to try this: https://github.com/emu-wg/teap-errata Whilst this is all in my head, and I find myself following the IETF more and more, I am happy to try to get some errata sorted out, and maybe we can get a RFC7170bis. Being frank though I would prefer to not peruse this if I am going to end up fighting with the hostapd author on what should be implemented as opposed on what is actually deployed and within our ability to change. Do not get me wrong, I love a good fight, but if it is on something we have zero influence on, I'll rather put that energy into something else. :) >> + 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. Well it was cut'n'pasted from your FAST implementation which had no reference either... Until you know how everything talks to one another, I think cementing that into an RFC errata is a little premature. As of this morning (you're welcome...) FR/hostapd/Win10/Win11 look like they can talk to one another, maybe we can start this process? Regards Alex [1] they will not even do session tickets for TLSv1.3 as they do not see the point so I am not going to even ask them to do this [2] though chaining with wpa_supplicant/eapol_test needed a fix https://github.com/corememltd/hostap/commit/70023b5e93327a385b7de2c9a6548f1f646b0686 [3] https://gist.github.com/jimdigriz/327ef6afa808a1b291d12d68857dec05 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
