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

[Alan DeKok]

On Nov 27, 2022, at 7:59 AM, Jouni Malinen <j at w1.fi> wrote:
> What is this protocol change based on? Just the fact that it happens to
> be implemented in this manner in FreeRADIUS and Windows 11?

  We started working on the TEAP implementation in FreeRADIUS recently.  So it doesn't really matter what it does.  What matters is that Windows 10/11 behaves in a certain way, and Cisco ISE (among others) works with Windows.

  So we can do whatever the RFC says, and not interoperate with the dominant players.  Or, we can ignore the broken standard, and just write working code.

  As co-chair of EMU during the TEAP debacle, I can't help but feel partially responsible.  We should have pushed harder for implementations, in order to catch issues like this.  But that ship has sailed.

> 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.

  People are deploying TEAP today.  The choices are interoperate, or don't interoperate.  The reasons behind those choices don't matter.

  At this point, it's likely time to write RFC7170-bis.  It would use the same TEAP version number, and simply document how things actually work.  Any theoretical issues of "better" protocol design would have to wait for TEAPv2.

  Alan DeKok.