On Jun 29, 2020, at 7:40 AM, Joe Garcia <joe27256@gmail.com> wrote:
Alan DeKok <aland@deployingradius.com> wrote:
It turns out that the TEAP RFC is incomplete, and can't really be implemented as-is.
I was wondering about that, that RFC looks like yet another attempt by Cisco to get their pet design accepted as "the standard" instead of whatever it is that's been in universal use by the industry for years,
I was the chair of the EAP working group when TEAP was being standardized. It wasn't just Cisco, there were a few companies behind it. But... TEAP is largely EAP-FAST with a few minor changes.
they have a history of doing this in other WGs as well. In this case, for example, the introduction carefully worms its way around having to justify why TEAP even exists, it states "they all are either vendor-specific or informational, and the industry calls for a Standards Track tunnel-based EAP method" and then carefully omits to mention the Standards Track EAP-TLS that already exists.
EAP-TLS doesn't carry data inside of the tunnel.
In fact the abstract for TEAP could just as well be describing EAP-TTLS. So I can see why there'd be no rush to implement it.
I was pushing for people to standardize on TTLS. It is *much* simpler than TEAP. But, the corporate overlords won. Alan DeKok.