-----Original Message-----
From: Emu <emu-boun...@ietf.org> On Behalf Of Alan DeKok
Sent: 19 July 2021 00:40
To: EMU WG <emu@ietf.org>
Subject: [Emu] Short review of draft-friel-tls-eap-dpp-01
No major notes here. There's still a lot of TBD in the document. :)
NITS:
Section 3 says:
... For
unprovisioned devices that desire to take advantage of TLS-POK, there
is no initial realm in which to construct an NAI (see [RFC4282]) so
the initial EAP Identity response SHOULD contain simply the name
"TLS-POK" in order to indicate to the Authenticator that an EAP
method that supports TLS-POK SHOULD be started.
* RFC 4282 has been deprecated by RFC 7542
* There just might be a user with name "TLS-POK", so using bare names is likely
not a good idea.
After looking at this, EAP-NOOB, and my latest document, there seem to be
some overlap with EAP identities. EAP-NOOB suggests a ".arpa" realm. It would
be good to agree on, and use, a common naming scheme.
My suggestion is to define "eap.arpa" for EAP purposes. This realm would be
defined to be handled locally at the EAP server. i.e. never proxied. And used
only for provisioning purposes.
We can then have:
* n...@eap.arpa for EAP-NOOB
* tls-...@eap.arpa for this document
* perhaps "provision...@eap.arpa for "I want a captive portal / provisioning
network". I have some updates pending to my document which discusses this
concept.
One issue we currently have today is that there's no standard way for an EAP
client to say "I want network access, but I don't really care who it's from,
and I don't really care to prove who I am". This kind of authentication-less
network access is still useful, as noted in the EAP-TLS 1.3 document. Similar
provisioning is in EAP-FAST and TEAP.
I suspect that would be useful to have full network capabilities for
provisioning. While it can be nice to push all kinds of provisioning into an
EAP method, TBH that seems like re-inventing the wheel.
[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. 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.
Instead, we could just have the EAP client go "I want access as @eap.arp" or
maybe "provision...@eap.arpa". It then gets a "captive portal" network, and
can rely on the rest of the TCP/IP stack, and the web PKI to download complex
provisioning data.
From an implementation point of view, updating EAP clients and servers is
hard. It takes a long time for changes to be written, tested, and widely
deployed. In contrast, if the client had access to a provisioning network, it
can be easier to write a simpler utility which downloads information. Among
other benefits, there is also a clear separation of roles between network
access, and configuration changes.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
