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

[Alan DeKok <[e-mail]>]

On Jan 7, 2020, at 8:53 AM, Owen Friel (ofriel) <[e-mail]> wrote:
> [ofriel] That’s pretty much it. For supplicants running on standard OSes (Windows, MacOS, iOS, Android), they could use logic similar to Chromium (which you must be familiar with seeing as you helped write it: https://github.com/chromium/chromium/commit/36f20e46515ab61df4ae4af9655b647bf9a0ea5a#diff-fa455b6e65ab2ae19d64635ada88077e ) to ask the OS if a presented EAP cert is one issued by a public CA. This does mean that the supplicant is asking about Web TLS certs that Browsers trust. However, there are ample examples and support cases opened by operators who are trying to do exactly that – get a web PKI cert from a public TLS/Browser CA and deploy it on an EAP server. Is this recommended? Not really. Is it using a Web/TLS cert for a purpose its not strictly intended for? Yes. Does this happen in real deployments? Absolutely. How prevalent is it? I do not have that data.

  So far as I know, every EAP supplicant checks for the id-kp-serverAuth OID.  So yes, *all* EAP supplicants check that the certificate presented by the EAP server is valid for TLS web servers.

  That seems wrong.  But it's what people do.

> [ofriel] I agree that ideally  Web/TLS Browser certs should not really be used by operators as their EAP server identity certs, however, this does actually happen today. In an ideal world, it would be great if some of the large commercial (or free e.g. LetsEncrypt) public Web/TLS CAs had an intermediate signing CA with id-kp-eapOverLAN. But today, and for the foreseeable future, what can we advise supplicants to do if we know that some operators will put Web/TLS identity certs from public CAs on their EAP servers?

  Not "some", but "all".

> [ofriel] Getting public CAs to manage a new PKI root (if that’s easier than just a new intermediate) with id-kp-eapOverLAN is a really really long road. And we know that some operators do use public Web/TLS certs as EAP identity certs. Which means that we cannot recommend supplicants enforce a check for id-kp-eapOverLAN.
> 
> So it looks like there are three choices:
> 1.	Completely ignore id-kp-eapOverLAN for ever.
> 2.	Get supplicants to check id-kp-eapOverLAN if its not a public CA (and use Chromium style public CA detection). Rollout of this would need to be carefully managed too so that existing private CA operators who do not set id-kp-eapOverLAN do not break.
> 3.	Do nothing until  sufficient numbers of public CAs support id-kp-eapOverLAN (in like 2035..?), then change supplicants to always check for id-kp-eapOverLAN.

  I think there should be continued discussion about what is the end goal, and how we can get there.  Once those issues are defined, then it's simpler to fix the supplicants.

> Its not clear to me where the correct forum is to even document these recommendations, or who needs to be involved.

  The Wi-Fi alliance is already moving ahead with a similar approach.

https://www.wi-fi.org/download.php?file=/sites/default/files/private/WPA3_Specification_v2.0.pdf

  See Section 5, page 10.

  A shorter description is here:

http://lists.freeradius.org/pipermail/freeradius-users/2019-December/097080.html

  Alan DeKok.