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

From: Alan DeKok <[email-masked]>
Date: Sun, 18 Jul 2021 12:39:36 -0400

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:

* [email-masked] for EAP-NOOB

* [email-masked] for this document

* perhaps "[email-masked] 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.

  Instead, we could just have the EAP client go "I want access as @eap.arp" or maybe "[email-masked]".  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.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 27 Jul 2021 17:23:17 +0000

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Alan DeKok
Sent: 19 July 2021 00:40
To: EMU WG <[email-masked]>
Subject: [Emu] Short review of draft-friel-tls-eap-dpp-01

NITS:

  Section 3 says:

  ... For

  We can then have:

[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.

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Tue, 27 Jul 2021 13:50:47 -0400

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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 28 Jul 2021 08:06:32 -0400

>> 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 "[email-masked]".  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.

---

From: Dan Harkins <[email-masked]>
Date: Wed, 28 Jul 2021 09:16:03 -0700

Hi Alan,

>    That presumes everyone uses TEAP, all of the time.  This is likely to not be the case for a while, if ever.

   Well that's what we're trying to address. Making something more useful
is a goal and the fact that currently that thing isn't quite as useful as
it could/should be shouldn't be a reason not to make it more useful.

>    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 t…

   I think you're reading a bit too much into "provisioning mode" here. 
There
was never an intention in TEAP to allow for the PKCS10/PKCS7 exchange to be
done after an anonymous Phase 1. The anonymous Phase 1 was used to get a
tunnel up in order to facilitate an exchange would would make the TEAP 
connection
be mutually authenticated. The text in 3.8.3 implies that Phase 2 always 
follows
an unauthenticated Phase 1 and Phase 2 MUST be mutually authenticated.

   An RA (which is what the server is acting as on behalf of a CA) needs to
authenticate the user before it passes the CSR off, that's (part of) the
service it's providing. Otherwise we'd end up with Kevin Mitnick getting
a certificate in the name of "[email-masked]". That would not
be a trustworthy CA and it's certificates would be useless garbage.

   So the "this topic" you're alluding to is not really what 3.8.3 was 
talking
about.

>    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.

   *That* use case can't get any simpler. The 10,000 students can enter 
their
username/password on their 10,000 laptops. That's not what DPP or TLS-pok is
dealing with. It's 10,000 sensors with no practical user interface. Eduroam
doesn't work for 10,000 sensors with no practical user interface.

>    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.…

   So when I go to that URL it has some requirements for simple deployment.
"All that's required is that the client system have... 3. a username...
4. a password".

   Again, trying to put a username/password on 10,000 sensors that have no
user interface and assuring that the RADIUS server to which these 10,000
sensors will be authenticating using Eduroam have all the right info is the
pain-in-the-ass we're trying to address.

   I don't think you're trying to solve the same problem we are.

>    The spec doesn't require (or use) DPP bootstrapping.

   It uses the key extracted from a DPP bootstrapping process so I think
you're doing a semantic exercise here-- a distinction with no difference.

>    I think both of the above are useful.  Using EAP as a generic transport layer for provisioning seems like a poor choice.

   Nowhere do we propose to use EAP as a generic transport layer for 
provisioning.

   Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

---

From: Dan Harkins <[email-masked]>
Date: Wed, 28 Jul 2021 09:26:45 -0700

>    Mashing everything into EAP seems just... wrong.

   Assuming everything can be assigned a username and a password is what 
is wrong.
If you're concerned about *standard* EAP methods being used in 
*standard* ways
then think about what we're proposing:

   1. No change to RFC 7170
   2. No change to RFC 8773
   3. No change to RFC 7250
   4. a new name assignment from a name registry created by an I-D (soon 
to be RFC)

So what we're proposing is using an EAP method in a way in it was 
defined and using
TLS to authenticate it using tools which were defined to authenticate 
TLS. We're just
proposing to use those tools in a new way.

   Dan.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 28 Jul 2021 15:32:14 -0400

On Jul 28, 2021, at 12:16 PM, Dan Harkins <[email-masked]> wrote:
>   I think you're reading a bit too much into "provisioning mode" here. There
> tunnel up in order to facilitate an exchange would would make the TEAP connection
> be mutually authenticated. The text in 3.8.3 implies that Phase 2 always follows

  OK.   7170 is a little unclear on that.

>   So the "this topic" you're alluding to is not really what 3.8.3 was talking
> about.

  Sure.  So there's still some need for bootstrapping, then?

>   *That* use case can't get any simpler. The 10,000 students can enter their

  I agree.

  My document is about users, and therefore the use-cases talk about users.  But the real goal is provisioning.  The  "username / password" exchange happens after provisioning.  It could (with no loss of generality) use another method, such as client certificates.

>   I don't think you're trying to solve the same problem we are.

  Pretty much.  I suspect there may be some overlap, and I'd like to see if there's some possible synergy.

>   Nowhere do we propose to use EAP as a generic transport layer for provisioning.

  TEAP / FAST are getting close.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 28 Jul 2021 15:34:48 -0400

On Jul 28, 2021, at 12:26 PM, Dan Harkins <[email-masked]> wrote:
>   Assuming everything can be assigned a username and a password is what is wrong.

  Yes.  That was intended to be just an example, though.

> If you're concerned about *standard* EAP methods being used in *standard* ways
>   4. a new name assignment from a name registry created by an I-D (soon to be RFC)

  That's good.

  One of the goals of my draft was minimal changes to existing systems.  For example, the TEAP RFC is ~7 years old, and based on 3-4 years of work before that.  Yet it was only recently that people started implementing it, and discovered serious issues.

> So what we're proposing is using an EAP method in a way in it was defined and using
> TLS to authenticate it using tools which were defined to authenticate TLS. We're just

  Yup.

  Alan DeKok.