On Tue, Nov 29, 2022 at 2:35 PM Alan DeKok <al...@deployingradius.com> wrote:
> 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. > > [Joe] speaking as a participant, I'd be happy to assist with a revision. I think it is needed. Most of the current errata are tracked here - https://github.com/emu-wg/teap-errata/pulls. I think the target would be to obsolete 7170 with a revision that just fixes the errata and makes any needed clarifications. We can also work on posting the Errata, but the revised document would be more effective at getting these issues fixed. > 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 >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
