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

It seems to me that RFC 4334 offers a way for an enterprise to assert that the certificate is intended to be used with a particular SSID.  This seems better than a self-signed certificate with just a domain name.

I understand that CA/B Forum does not allow these extensions and attributes, but as already highlighted in thi discussion, these certificates are not part of the Web PKI.

Russ

> On Jan 19, 2020, at 10:07 AM, Alan DeKok <aland@deployingradius.com> wrote:
> 
> On Jan 18, 2020, at 6:30 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
>> Great. Let’s focus on one problem at a time to make sure it’s easier to follow along. Earlier in the thread you seemed fixated on the first problem, so it’s unclear when/where/how shifted to the second.
> 
>  Perhaps less "fixated" than "trying to achieve a common understanding.
> 
>  It's best to understand the current situation before designing any solution.
> 
>> The alternative is the application ships it’s own root store. Which applications have been doing for 20+ years and which modern OSes make even easier.
> 
>  The question here is *what* root store?  It's easy for browsers to ship root stores.  The WWW root stores are well known. 
> 
>  What root store is already widely known, and trusted for EAP?
> 
>> Not really? CAs are plenty happy to sell whatever folks want. Look at stuff like the drone PKI being developed.
> 
>  CAs are in *theory* happy to sell things.  In practice, it's difficult to get non-WWW certificates.
> 
>> I already gave that answer several times. Define your profile and policies, pick (different) roots, and ship them in your software. It’s mistaken to suggest that you HAVE to use the same roots as the OS.
> 
>  I think you're operating from a WWW perspective.  That use-case is very different from EAP.  In WWW, 99% of the TLS-enabled traffic is from the server to the client.  The client doesn't know what the information is, and doesn't really care.  Even secret information like passwords sent to a web server are generated by / on that web server.  So a client can verify (a) the password was created for a proven server using a trusted CA, and next time (b) prove it's the same server, so it's OK to send over the password.
> 
>  EAP is completely different.  I have *my* password.  It's secret, and I made it.  I want to be sure that I give it *only* to the site which is authorized.  This means that I don't really care that a root CA is trusted.  That root CA might sign certificates for 1000 companies.  I want to have my password only to one company; the correct one.  I want the client supplicant to *not* hand my password to the other ones.  I have no DNS to leverage, either.
> 
>  To put it another way, in WWW, the server has data that the client wants.  In EAP, the client has data (passwords) that the server wants.  The trust models are very different.
> 
>  The goal then is to get to the point where a supplicant can verify that the server cert is signed by a trusted CA, *and* that it's the server cert that the client wants.
> 
>  Shipping a trusted root CA on the supplicant OS is the *only* way to do this.
> 
>> No, there doesn’t. That’s an unreasonable demand, because it’s insisting that advocates of the problem don’t want to actually do the work involved in developing a solution for the problem. There’s absolutely no reason to require that it be shipped as part of the OS. Plenty of PKIs exist without requiring that, and modern OSes make it easier.
> 
>  See above.
> 
>  This isn't just "ship a root CA with an EAP / RADIUS server".  That's a trivial problem to solve.  If you want to use a RADIUS server, it may be OK to trust the CAs included with that product.  The same goes for browsers.
> 
>  But what are the poor end users going to do with their EAP supplicants?  Pretty much *zero* of them have ever downloaded a supplicant "application".  So that route is completely off of the table.
> 
>  Instead the supplicant is shipped with the OS. Therefore, any root CAs needed by the supplicant MUST be included with the OS.
> 
>  It really is that simple.
> 
>  In conclusion, we need a new PKI, and the root CAs must be included with OS distributions.  But the OS vendors won't do that until we define the requirements, solution, and transition path.
> 
>  Alan DeKok.
> 
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu