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

[Alan DeKok <[e-mail]>]

On Jan 7, 2020, at 9:54 AM, Ryan Sleevi <[e-mail]> wrote:
> At the high-level, I will say that using TLS (id-kp-serverAuth) certificates, from the intersection of CAs that are commonly trusted by operating systems and browsers, is bad. It will create security issues, will create interoperability issues, and will not help users.

  It's been accepted practice in all EAP implementations for ~15 years.  Are there practical issues you're aware of?  Because I can't recall seeing any.

  Any security issues are limited.  If a site administrator has access to the public / private keys for a web server, it's possible to re-use those certs for EAP.  This re-use cannot be prevented.

> The set of CAs that are trusted for TLS on a given device, platform, or application are intrinsically tied to purpose (TLS) and the library used to implement that TLS and PKI behaviour. They are not separable, and trying to do so is a problem, not a solution. This is perhaps most obvious as vendors like Apple have tightly integrated PKI policy requirements (such as Certificate Transparency) with the capability of their TLS libraries; for several macOS/iOS releases, any application using a TLS library other than Apple's CFNetwork would be unable to successfully verify a number of certificates from CAs Apple trusted for TLS.
> 
> EAP is not TLS, and your use case here is not TLS (clearly), so don't mess with TLS, or you will break, eventually. The best I can do is try to explicitly break you sooner, than later, so that I can deal with the fallout sooner than later, and not when there's a critical issue in the TLS ecosystem needing rapid resolution.

  I'm not sure what your point is here.  I agree this usage is wrong, but the goal is to *fix* it.  The goal isn't to "bless" the existing usage.

  The goal is to figure out what *should* supplicants do.

> At a high-level, you're still fundamentally proposing a new root store. I realize that may not be obvious, given the suggestion of intermediates with id-kp-eapOverLAN, but that's still fundamentally what's being suggested, because you still need to define a certificate profile (such as the EKU), expected policies such as how that information is validated, and a process for ensuring that validation is performed. I think that's a laudable goal, and perhaps worth pursuing, but it's important to stress that in defining a new root store, there's no reason to reuse anything extant. The fact that operating systems may trust some organizations for other purposes (TLS or S/MIME) should by no means be dispositive towards whatever you're doing. Where to best propose certificate profiles or certificate policies for that root store, I don't know, and that clearly requires a lot more implementor experience and consensus to end up with something like the CA/Browser Forum that is useful for TLS.

  EAP supplicant implementations largely do this already.  So there's no "proposal" of a new root store.  There's a statement that there *is* a different root store.

  i.e. implementations default to not trusting CAs for EAP.  The trust has to be explicitly enabled by an admin, or by the user.  This means that there's a store of CAs *only* for EAP.

  Everyone knows that it's wrong to use id-kp-serverAuth for EAP.   The way forward is to figure out how to fix it.

  Alan DeKok.