Based on interoperability testing, it looks like implementations followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170:
http://lists.infradead.org/pipermail/hostap/2022-July/040639.html http://lists.infradead.org/pipermail/hostap/2022-November/041060.html I think this issue is larger than an errata. We now have shipping code (Windows 10, Windows 11, and Cisco ISE at least) which don't follow RFC 7170. But which do interoperate with each other. Hostap / wpa_supplicant follows 7170, but doesn't interoperate with Windows. FreeRADIUS is currently being updated to support TEAP. For reasons of interoperability, we'd probably choose to follow Windows. The question is what to do next? I would suggest that at this point, shipping code is more important than theoretical specifications. The implementors have shipped interoparable versions, and shipped millions of devices with a particular implementation. So our choices are: 1) declare the implementations broken, and update 7170 with minor tweaks for what "should" happen. New implementations will do ??? and current implementations will do ??? 2) declare 7170 irretrievably broken, and write 7170bis which defines TEAP version 2. That document can define TEAP behavior as ??? 3) declare 7170 irretrievably broken, and write 7170bis which documents how TEAP version 1 operates in practice. My preference would be (3). I'd also prefer to get agreement in EMU that this is the way forward, so we can ship FreeRADIUS with a "correct" implementation. I would very much prefer to not add to the mess by shipping code which fails to follow RFC 7170 and which also fails to follow existing implementations. If the WG agrees, I'd be OK acting as editor for RFC 7170bis. The goal would be to change as little as possible of the text. Just fix the errata, and add a note saying "ignore 7170, as it's wrong". 99% of the text is OK, and can be left as-is. This issue is getting timely, as there is now strong customer demand for TEAP in Q1 / Q2 2023. So it would be good to get consensus before going down any particular path. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
