Alan DeKok <[email protected]> wrote: > EAP implementations are limited to exchanging ~64K of data before > supplicant and/or server gives up. If there is a need to exchange more > data than this, it's impossible. Configuration data tends to grow over > time, because of a tendency to just use the existing system, even > though it isn't really intended for that use. People tend to (ab)use > existing systems in surprising ways, too.
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.
> This method also has a cost. Administrators now have to set up
> additional services in order to do provisioning. This may not always
> be possible. As Eliot pointed out, there are also security issues with
> exposing additional servers (EST, etc.) to unauthenticated users.
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)
I can live with it being trivially encrypted via EAP-TLS with a "well-known"
username/password like we do with the "ietf" network at meetings.
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.
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.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
