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

[Alan DeKok <[e-mail]>]

On Jan 17, 2020, at 12:33 PM, Ryan Sleevi <[e-mail]> 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.