Alan DeKok <al...@deployingradius.com> wrote:
> On Aug 12, 2025, at 10:06 AM, Q Misell <q=40as207960....@dmarc.ietf.org>
wrote:
>> This draft seems to only be for EAP-TLS, but uses the eap.arpa domain,
>> not tls.eap.arpa. Should this be changed?
> Yes.
Q> Secondly, for the 'laptop in coffee shop' example, which I see as the
Q> most useful use for something like this, the draft seems a little
Q>lacking. After I've connected to the local coffee shop WiFi with this
Q>protocol, what do I (as a device) do next? Is a captive portal API
Q>mandatory?
> This draft is for onboarding, not for captive portal. The eap.arpa
> document defines "por...@tls.eap.arpa <mailto:por...@tls.eap.arpa>" for
> captive portal use. i.e. the unauthenticated coffee shop / airport
> WiFi.
Should it though?
To my mind there is a continuity between laptops with full user interfaces
and browsers, but which have no credentials issued, and lightbulbs that have
no interfaces, browsers or users attached.
The laptop might need to visit a portal in order to get a credential that it
will then use with EAP-TLS.
Or a laptop that *has* credentials, but has failed the end-point assessment
(remote attestation), that is now on the captive portal network, on which
there is still access to a firmware update server.
For enterprises, the extra SSID has a high cost, and so amortizing that
across multiple uses makes sense to me. Yes, the different NAIs can all lead
to the same SSID, but that implies more knowledge/intention than maybe
devices need to have.
Q> What do I do with the output of EAP-TLS i.e. the verified domain name
Q> of the server?
> The domain name of the server is typically not verified, so it doesn't
> matter. If it can be verified, it could perhaps be related to the
> actual onboarding protocol used? But I'm just talking out loud here.
When Q writes "output of EAP-TLS", I think they mean the MSK.
The MSK is used just like any other EAP-TLS: it results in a per-node L2 key.
It's as secure as any other, accomodating randomized/changing MAC addresses,
etc.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
