On Jan 7, 2020, at 12:33 PM, 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
How is that specific to the use of TLS (id-kp-serverAuth) certificates? Any use of TLS certificates by EAP would be subject to the same issues. > Security: > - Cross-protocol considerations due to key reuse seems like a meaningful > security issue that's being dismissed. Who is dismissing it? > 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 No, it doesn't. *Everyone* has been doing this with EAP for a very long time. i.e. getting a certificate using id-kp-serverAuth from a root CA, and then using that certificate for EAP. I have never heard of such a certificate being revoked. > 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. It's been 15+ years. There has been no such issue. I think it's acceptable to recommend people continue existing practice, where such practice has been shown to be (a) workable, and (b) has no known issues. > 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? To do *what*? A concrete proposal would help here. > 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. Please call Microsoft and Apple, and tell them you're going to forbid their 15 year workflow for EAP. Then, tell them that you *want* their systems to break, and that it's for security reasons. I suspect that request won't go over well. We just cannot break existing systems without a clear and present security problem. And none has been demonstrated here. > 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 think it's OK to *document* existing behaviour. Behaviour that has been demonstrated in to be interoperable with billions of devices. > 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. I welcome concrete proposals to move forward. The discussion here seems to recommend against using id-kp-eapOverLAN and NAIRealm. Which means we *don't* have a way forward. In the absence of a solution, it's best to document existing practice. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
