On Jul 27, 2021, at 1:23 PM, Owen Friel (ofriel) <ofr...@cisco.com> wrote: > [ofriel] the goal here is to push the provisioning info (e.g. CA roots, peer > identity certs) inside TEAP using existing TEAP mechanisms e.g. Trusted > Server Root, PKCS#7 TLVs.
That presumes everyone uses TEAP, all of the time. This is likely to not be the case for a while, if ever. TEAP also has the issue of bootstrapping. RFC 7170 Section 3.8.3 described an unauthenticated provisioning mode, but suggests that Phase 2 still has mutual authentication. It's not clear how the parties can identify each other in that case. The document appears to be silent on the topic. This draft solves that issue, among others. For example, what about the use-case of Eduroam? 10,000 students show up to a university which uses a private CA. Assuming that all of the devices support TEAP, they are still unable to perform "mutual authentication, and TEAP becomes ToFU. Similarly, DPP may work, but that requires creation and distribution of new keys In contrast, the user work flow here is "connect to Eduroam, log in with your username and password". It really can't get simpler than that. The first stage of this proposal requires no changes to existing supplicants. A simple client-side utility can perform the requisite actions, and configure the supplicant. Running code is available: https://networkradius.github.io/automatic-eap/ The core of the work is a ~300 line Python script. OS vendors could ship this today. Network administrators could add a few records to DNS/WWW. Getting EAP connectivity then becomes trivial. It requires minimal coordination, and minimal new software. > 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 spec doesn't require (or use) DPP bootstrapping. This draft is different from a number of related issues in that it solves a different problem, and in a different way: * it leverages web PKI to bootstrap TLS-based EAP methods * it does provisioning over standard internet protocols, instead of extending the supplicant. I think both of the above are useful. Using EAP as a generic transport layer for provisioning seems like a poor choice. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
