Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

[Alan DeKok <[e-mail]>]

On Jan 19, 2020, at 12:12 PM, Ryan Sleevi <[e-mail]> wrote:
> 
> >  What matters is that the product the user ends up with has the CAs preconfigured for EAP.  The internal corporate structure is (to me) irrelevant.
> 
> Don’t conflate technical requirements with corporate structure. You’re insisting on a precise technical requirement, and I’m explaining to you why you’re using the term wrong, and in a way that meaningfully detracts and profoundly conflates things. There’s a tremendous amount of difference in cost and engineering between the two approaches, and so it’s important to be clear the requirement - which is the less expensive one.

  I fully understand that applications can easily ship root CAs.  We can therefore agree that the root CAs MUST be distributed with the software.

  But, precisely *zero* end users download their supplicant software.  The supplicant software comes with the OS.  Which means that the root CAs must be distributed with the OS. 

  While, there are commercial supplicant products, these products are overwhelmingly used by the enterprise, on computers owned by the enterprise, and managed by the enterprise systems.  They have zero impact on the average user.

  So whatever "product" the end-user buys already has the supplicant software pre-installed.  Which means distributed with the OS.  There isn't even an option I've seen in iOS or Android to replace the supplicant software.  It's possible to download a supplicant *configuration* for one SSID, but that isn't standardized (see XML format below).   And when you're downloading the supplicant configuration, it's just a manual configuration with fewer steps.  There's no *automatic* way to trust an EAP / RADIUS server and get on the net.

  This is really the main point of disagreement.  Your position is that it's easy, and it's just not.

  The same goes for root CAs.  While it's superficially true that someone can start "Billy Bobs Tackle Shop & CA", no one has any reason to *use* that CA.  Saying "you can start a CA" and by implication have people *use* it, is no more realistic than me saying "you write software, Bill Gates wrote software, there's nothing preventing you from being as rich as he is."

  It's theoretically true, but false in practice.

  In practice, an SDO like the Wifi Alliance, 3G / 4G  / 5G groups can demand their members put root CAs into devices.  That can even demand that the CAs follow certain policies.

  I have no such power.  So it's unhelpful to say "just start your own CA!"

>   There have been attempts to simplify supplicant configuration with a standard XML format.  The vendors expressed zero interest.  And that's a *lot* easier to do than adding a new root store.
> 
> I’m not sure how this is relevant?

  It demonstrates that vendors have shown little interest in making WiFi easier to use for their end users.  This decision is likely to have an impact on these efforts.

> It seems we’re in agreement that the status quo is manual configuration, it seems we’re in agreement that there’s no technical or procedural reason to use the set of publicly trusted CAs for TLS (it doesn’t get you automatic recognition, it does increase your risk surface), and it seems we’re in agreement that defining a unified store is a lot of work with an unclear value proposition that justifies that work.
> Going back to the original mail, there’s nothing to be gained from trying to repurpose extant stores, and best practice remains manual configuration. If folks want more than that, they need to define what they want and how it’s validated, and figure out what CAs do that. All of this was part of that first reply, so are we just in agreement?

  We are in agreement on most of that.  We are in disagreement that people can just use other CAs.

  Let's use a concrete example.  Right now, when I add a new IMAP server to my phone / laptop, the process is largely this:

* choose IMAP configuration
* add host name of IMAP server
* maybe get a certificate pop-up if the CA being used isn't already trusted, OR a pop-up saying it's trusted
* add user name
* add password

  Lo and behold, it works.  Note that I did *not* download any software.  The only things I need are (a) already on my computer, and (b) in my brain.

  The workflow I want to see for WiFi is this:

* select an SSID
* maybe get a certificate pop-up if the CA being used isn't already trusted, OR a pop-up saying it's trusted
* add user name
* add password

  With your proposed work flow, this is just impossible.  It's really just manual configuration with fewer steps.  It still requires extra software / configuration / whatever to be downloaded.  And that's the situation I'm trying to avoid.

  Alan DeKok.