On Tue, Jan 7, 2020 at 11:44 AM Alan DeKok <al...@deployingradius.com> wrote:
> 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. > I'm sure "practical" will be seen as subjective, but here's some examples: Operational: - Customers of CAs having trouble when their CA has to perform timely revocation of their certificates - Migration off SHA-1 - Migration off 1024-bit RSA - CAs being shut down or exiting the business due to non-compliance with browser requirements Security: - Cross-protocol considerations due to key reuse seems like a meaningful security issue that's being dismissed. > 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. > No. But it results in prompt revocation of that certificate if anyone demonstrates it being used like that, the same as no one can prevent you from embedding a private key in software, but doing so gets it swiftly revoked. [1] [1] https://www.theregister.co.uk/2019/12/05/atlassian_zero_day_bug/ > 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. > There's no short-term or medium-term solution that can rely on 'accepting' or 'specifying' the use of id-kp-serverAuth, which was the original proposal as a "recommend". Any of those uses are inherently broken and unsafe and just time bombs waiting to go off. > 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. > That doesn't match Owen's original message, so while I'm glad there's an acknowledgement here of differences, that doesn't seem to match the discussion to date. > 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. > Update software? I'm glad there's agreement it's bad/wrong to use, but it seems the only path forward is going to be to breaking, not recommending for using public (TLS) CAs with id-kp-serverAuth. Attempting to specify some interoperable behaviour in the interim, before things are broken, for how folks can keep using id-kp-serverAuth, seems to be the problem. Just accepting that things need to be broken seems like it easily allows moving into the discussion about NAIRealm and manual configuration. I know that's easy to say when it's individual vendors who have to deal with the fallout and that's why I suggested there's a spectrum of responses for how that's phased out. But explicitly moving towards that goal, and not trying to live in the interim with id-kp-serverAuth, seems the best path forward.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
