On Jul 27, 2021, at 1:50 PM, Alan DeKok <al...@deployingradius.com> wrote: >> We are trying to avoid wheel reinvention. The novel bit here is the mutual >> authentication in the TLS stack based on the already defined Wi-Fi Alliance >> DPP bootstrap key.
The novel bit in the EAP-DPP draft, yes. My leaning is more and more towards just using EAP for authentication, and doing provisioning via standard networking protocols. For example, the Wi-Fi Alliance Passpoint R3 defines unauthenticated EAP. It's essentially EAP-TLS, but using the extended EAP types with the Wifi Alliance enterprise number. This requirement means that all supplicants and servers have to be updated to support this method. Multiple that by more standards bodies, vendors, IETF working groups, and we end up with a massive amount of EAP types. All trying to get similar things done. This is already happening. Or, we define unauthenticated EAP as using "f...@eap.arpa". The supplicants need to be updated once to support that. Different use-cases can just request different methods via changing the username portion. And once they have network access, run separate utilities to do their magic provisioning. Mashing everything into EAP seems just... wrong. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
