Re: [Emu] Short review of draft-friel-tls-eap-dpp-01

["Owen Friel (ofriel)" <[e-mail]>]

-----Original Message-----
From: Emu <[e-mail]> On Behalf Of Alan DeKok
Sent: 19 July 2021 00:40
To: EMU WG <[e-mail]>
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:

* [e-mail] for EAP-NOOB

* [e-mail] for this document

* perhaps "[e-mail] 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 "[e-mail]".  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
[e-mail]
https://www.ietf.org/mailman/listinfo/emu