EAP-TEAP support on the radar?

[Alan DeKok]

On Jun 29, 2020, at 7:40 AM, Joe Garcia <joe27256 at gmail.com> wrote:
> 
> Alan DeKok <aland at 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.