On Sep 11, 2023, at 12:38 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > There is no connection here. > EAP(nobody) gets you a useable L2. > L2 makes DHCP possible. There is no link, and they are not tied.
I suspect the kind of provisioning you need is related to the kind of network access you get. The alternative would be to just define how "server unauthenticated EAP-TLS" works, and then punt the problem elsewhere. i.e. "You're on _some_ net, with _some_ kind of properties. It's up to you to figure out what to do next". > When you write this, what I am hearing: the end user has to know everything > about the network they are joining. And that's exactly what I think we are > trying to avoid. I mostly agree. The user shouldn't know. But the supplicant has to know what it wants to do. The alternative is for the supplicant to know what it's doing (signalling via EAP), and then somehow forget about that when it has network access. Or, the supplicant doesn't know it's doing provisioning, gets on the network somehow, and then the system receives a DHCP packet with a captive portal option. The system won't know why that option was received. All it can do is punt the user to the captive portal, and let the human deal with things. >> In contrast, if there's only one kind of on-boarding access, >> authorization has to be done through DHCP which has much more limited >> capabilities for that. > > There are possibly many different ways depending upon where you open the lid > of your laptop, phone, chromebook, personal IoT device. DHCP doesn't do VLANs, and VLANs are widely used in enterprise environments to isolate traffic. I think that requiring only DHCP makes certain use-cases impossible. Allowing DHCP, but also allowing something with EAP will have the widest possible usability. If we allow some kind of signalling via EAP, then we can also say what the local network should look like. e.g.: * do server unauthenticated EAP-TLS * get the domain name from the server * then use EST (RFC7030) to connect to a well-known URI for that network, and do some more work. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
