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

[Alan DeKok]

On Jul 27, 2021, at 1:23 PM, Owen Friel (ofriel)  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

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

[Owen Friel (ofriel)]

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