On Jan 7, 2020, at 8:53 AM, Owen Friel (ofriel) <ofr...@cisco.com> 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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
