Alexander Clouter <alex+i...@coremem.com> wrote:
>>> On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote:
>>>> My understanding here is that the EAP server and client will not
>>>> authenticate each other in EAP-TLS, and all the authentication will
>>>> be done in the " captive portal ". So why recommend EAP-TLS as a
>>>> provisioning method? Just send the identifier "por...@eap.arpa" and
>>>> then jump to a " captive portal ". Is that OK?
>>>
>>> So for OOB provisioning (ie. get an IP to access a captive portal)
>>> the conversation would be:
>>>
>>> >>> EAP-Identity Request <<< EAP-Identity Response[por...@eap.arpa]
>>> >>> EAP-Success
>>>
>>> Sounds sensible.
>>
>> I don't think it's that straight forward. For Enterprise-WiFi we
>> still need cryptographic keys for the WiFi 4-way handshake, so
>> establishing a TLS-Tunnel is needed to derive the WPA keys.
> Nice catch.
Doing this is significantly better than either unencrypted wifi (w/portal),
or encrypted WPA-PSK wifi.
So yes, we always want to run EAP-TLS to generate keys.
This document is related to
https://datatracker.ietf.org/doc/draft-richardson-emu-eap-onboarding/, (which
I'll repost on Saturday), but modularizes the work into smaller pieces.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
