On Mar 26, 2022, at 12:01 PM, Michael Richardson <[email protected]> wrote: > 64K is plenty to run RFC8995. Probably we can get away with a total of less > than 10K exchanged in the worst case situations, with 2K being more typical.
That's good, but I still have concerns with the process of using EAP for, well, almost everything. Anonymous / unauthenticated EAP-TLS exists. I'd like to know why that's unacceptable for provisioning general-purpose devices. For example, see any number of device management products. These products download large amounts of configuration, and even applications to end-user devices. This process is part of provisioning the device, and can't be done via tunnelling that data in EAP. So if we're not using EAP for most of that complex provisioning, why not just use the same methods for all of it? > Specifically, my original notion was to have an SSID called "ONBOARDING", > which was unencrypted. (I would run on DHCPv4, which makes smartphones give > up and go away. IPv6-LL only) Similar things are done in the 3G/4G/5G space. But either via other standards bodies, or vendor-specific means. i.e. people are laying additional things on top of EAP, because (a) they can, and (b) the IETF won't. The result is that there is a "grab bag" of solutions, instead of a unified approach. > The cost is that it has to be setup and available across a potentially large > enterprise situation. At the small scale of one or two home routers, it's > just not a problem. I'm not clear how a large enterprise causes any issues. For my proposal, just put records into DNS, and various data into web pages. Anyone with corporate credentials can then get on the secure WiFi network. > We will have to give up on WPA-PSK for the home, because RCM (Madinas) just > can't cope with maintaining policies for different devices when the devices > all have the same PSK. I agree. It's 2022... why is it difficult to get onto a friends WiFi network, securely, and easily? The answer I see is that the products are a collection of things from different standards bodies, who often don't communicate well with each other. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
