On Jan 7, 2020, at 9:54 AM, Ryan Sleevi <ryan-i...@sleevi.com> 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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
