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

[Alan DeKok <[e-mail]>]

On Jul 28, 2021, at 12:16 PM, Dan Harkins <[e-mail]> wrote:
>   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.

  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?

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

  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.