[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: EAP-TEAP support on the radar?
From:       Alan DeKok <aland () deployingradius ! com>
Date:       2020-06-29 11:56:08
Message-ID: 63BFF505-4A62-4670-9373-8E690C371D93 () deployingradius ! com
[Download RAW message or body]

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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


[prev in list] [next in list] [prev in thread] [next in thread]