EAP-TEAP support on the radar?

classic Classic list List threaded Threaded
4 messages Options
| Threaded
Open this post in threaded view
|

EAP-TEAP support on the radar?

Graham Clinch
Hi,

I've stumbled across a few slightly obscured mentions of EAP-TEAP
support coming in the latest Windows 10 release - eg "EAP-TEAP is
supported on Windows 10 v2004 operating system and later" from:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpwl/6694fbb1-07cd-493a-93f3-dcbd025311ac#Appendix_A_25

I think this is first time a widely deployed supplicant (with apologies
to wpa_supplicant) will have TEAP support.

We would be absolutely ecstatic if we were able to use both computer and
user credentials as part of the network placement decision (in
particular for VPN sessions).

Is TEAP support on a future-plans-list for FreeRADIUS?

Graham
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: EAP-TEAP support on the radar?

Alan DeKok-2

On Jun 19, 2020, at 10:34 AM, Graham Clinch <[hidden email]> wrote:
>
> I've stumbled across a few slightly obscured mentions of EAP-TEAP support coming in the latest Windows 10 release - eg "EAP-TEAP is supported on Windows 10 v2004 operating system and later" from:
>
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpwl/6694fbb1-07cd-493a-93f3-dcbd025311ac#Appendix_A_25
>
> I think this is first time a widely deployed supplicant (with apologies to wpa_supplicant) will have TEAP support.

  Mostly.  It turns out that the TEAP RFC is incomplete, and can't really be implemented as-is.  Jouni Malinen has some updates to fix things, but I'm not sure if anyone else has implemented the same fixes.

> We would be absolutely ecstatic if we were able to use both computer and user credentials as part of the network placement decision (in particular for VPN sessions).

  Sure.

> Is TEAP support on a future-plans-list for FreeRADIUS?

  We have a lot of future plans.

  TBH the fastest way to get TEAP in is for someone to implement it.  It's 90% like EAP-FAST, so just copying that code and editing it would be a good start.

  The issue for us is that we have a long list of work items right now.  If TEAP is either contributed, *or* there's a strong demand for it, we can take a look at the list.  Otherwise, it will remain a "wishlist" item.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: EAP-TEAP support on the radar?

Joe Garcia
Alan DeKok <[hidden email]> 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,
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.  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.

JG.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: EAP-TEAP support on the radar?

Alan DeKok-2
On Jun 29, 2020, at 7:40 AM, Joe Garcia <[hidden email]> wrote:
>
> Alan DeKok <[hidden email]> 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