On Jan 17, 2020, at 12:33 PM, Ryan Sleevi <[email protected]> wrote: > Does your RADIUS endpoint support and use OCSP stapling and disable WiFi if > the certificate is expired? No? Then it's a potential violation of this > CP/CPS.
I'm not sure how a RADIUS server will disable WiFi. They are entirely separate systems. > And in Section 16: > Customer will only use a TLS/SSL Certificate on the servers accessible at > the domain names listed in the issued Certificate > > Remind me how an EAP-TLS/RADIUS server is accessible at that domain name? The RADIUS server has a domain name, which is commonly used in the certificate. If that is insufficient for the CAs purposes, then we should also acknowledge that the revocation requirement likely also applies to SMTP, XMPP, DNS over TLS, and IMAP. i.e. *all* non-WWW protocols which use TLS. We should not single-out EAP / RADIUS as mis-using the certificates in this manner. The mis-use of these certificates in other protocols is orders of magnitude larger than the EAP / RADIUS problem. > There's two parts of discussion from the thread: > 1) What do extant clients do, today, in the verification of certificates used > in EAP-TLS EAP supplicants follow RFC 5216 Section 5.3. > 2) What should future clients do, 'tomorrow', to make this easier to use and > secure, ideally by default. > Much of the answer was around #2, which is "Don't try to glom on to something > existing, you need to build your own thing", True. > as well as "Some of the answers in #1 are problematic and you should try and > discourage them" There were *allegations* of problems. > To connect it back to the discussion: The discussion about revocation, and > what a CA's CP/CPS says is or isn't allowed for a usage, matters, because > browsers require CAs promptly revoke those certificates in 24 hours/5 days > for situations when they specify bad requirements. Can problematic CAs fix > their CP/CPS to allow this? Yes. But you've still got a host of other > expectations/requirements that can and will diverge, over time. If I was mean, I would write scripts to troll the net for mis-use of certificates in SMTP, XMPP, IMAP, VPNs, etc. Then, make the script auto-submit notices to the relevant CAs. That process is simple to do, and by the above rules, would require the CAs to revoke the relevant certs. i.e. certs which affect a high percentage of daily internet traffic. If that scenario were to play out, I suspect that CAs would very quickly stop revoking the relevant certs. A straight-forward approach to enforcing the rules would be over-ruled by simple practicalities: Turning off big chunks of the Internet is a non-starter. As Michael Richardson pointed out, then solution here is likely to fix the rules, not the protocols. > In the specific context of thinking about "#2" - what a touch-free future > looks like - having it use the same root store as Web browsers is the > anti-pattern, because the requirements are different. And therefore we need a different root store for *each* of EAP, RADIUS, SMTP, XMPP, IMAP, DNS over TLS, VPNs, etc. Note that we need *different* stores for EAP and RADIUS, because RADIUS server are reachable on port 2083 as RADIUS over TLS, *and* they implement TLS over EAP, which in turn carried over RADIUS. Different use-cases, different root stores. There may be significant push-back against that many root stores. > There's no doubt the status quo is "Everything is manually configured" and > "It's inconsistent what is validated". The goal is to get to #2, "It just > works" > > - Define your requirements (the certificate profile) > - Define your policies (what do you expect CAs to verify, and how do they > verify) > - Provide a way to distinguish "new certificates" from "The old and manual > cruft" - for example, an explicit EKU > - Pick your poison.... er, CAs... for the new root store (e.g. as WiFi > Alliance has done, or Wireless Power Consortium has done, or plenty of > vendors have done) > - Have CAs issue certificates with both EKUs (old and new) in the leaf. It's > a SEQUENCE for a reason. > - Have supplicants configured that > - If new EKU is present, look in built-in store > - If old EKU is present, require manual configuration > > This gets you half-way to #2: things can just work if you pick one of the > new-CAs with new-EKUs, and otherwise require manual configuration for old-EKUs That's good, but insufficient. There is a lot more verification that EAP supplicants need to do before automatically trusting a root CA. I suspect that most CAs already know that their customers mis-use certs for non-WWW purposes. EAP / RADIUS is just a minor (almost insignificant) part of this problem. I also suspect most CAs operate based on the hope that no one notices, and then requires them to revoke many, many, certificates. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
