Thanks for the detailed reply Ryan. See line. > -----Original Message-----
> > If an EAP server operator wants to use a public CA identity cert on their EAP > server, what recommendations should we give to EAP clients so that the > supplicant code can handle public or private CA issued EAP server identity in > a > secure a fashion as possible? > > Define “public CA” first, and it’ll be clearer that the question is really > supplicant-specific. > > That is, most definitions for “public CAs” come down to “I don’t want to think > about / analyze the security or validation practices of the CA, I want my > supplicant / software / hardware vendor to do it for me, against some criteria > the vendor is responsible for, and hope it all works out”. To the extent TLS > uses ‘public CAs’, it either boils down to the OS or browser vendors reaching > rough (independent) consensus on who is worth trusting, or the vendor > going along with everyone else’s decisions for cost (too expensive for the > vendor to evaluate) or compatibility (everyone else trusts them and it’d > break things if the vendor doesn’t) reasons. [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. > > Is the supplicant market likely to reach that consensus? It seems unlikely, > unless and until you define the “thing everyone can and wants and needs to > validate”, and that thing is either globally unique (like DNS) or sufficiently > domain specific (e.g. Passpoint) that vendors can agree. > [ofriel] I think the supplicants running on the main OSes would be happy to delegate the question of whether a CA is a ‘public CA’ to the OS. For manufacturers of things/embedded devices/etc. then its currently very much at the manufacturers discretion, and consensus here would be unlikely. > If at some point in the future, public CAs are willing to issue certs with > some > or all of the above fields, then what is the migration plan, what do we tell > EAP > clients to do now, and how to they migrate their verification logic? > > This statement similarly requires untangling. There are “public CAs” as “The > set of keys/certificates used for authenticating particular services” and > “public CAs” as the set of organizations that own/operate those keys. > > The case of the former is extremely unlikely, as the industry is actively > moving away from that approach to PKI, by trying to ensure separate keys > for separate use cases or authentication realms, of which EAP would surely > be. [ofriel] And by this you mean that a root CA will have e.g. one intermediate with EKUs of id-kp-serverAuth/id-kp-clientAuth, and a different intermediate with an EKU for id-kp-emailProtection, right? The logical extension here for EAP is yet another intermediate with an EKU for id-kp-eapOverLAN. The case of the latter is already available from said organizations as part > of “managed CA” or “private CA” offerings, which are operated by that public > CA organization, but that’s effectively greenfield because you aren’t having > to interoperate with any extant keys or certificate profiles. > [ofriel] Right, but from a supplicant perspective (or in general for any client running on any OS e.g. Browser on Windows), there is zero difference between an operator who deploys and runs their own private CA, or takes a contract out with a public CA organization and gets them to run a managed/private CA on their behalf. > The ideal experience would be along these lines for a client with real user > interactions: > - client connects to an EAP server > - client prompts user for userId + realm and password > - client verifies server cert has id-kp-eapOverLAN set > > What assurance is this to provide? [ofriel] To assure that the cert is for the intended purpose – 802.1X/EAP server auth. Just like other TLS/Browser clients checks for id-kp-serverAuth > > - NAIRealm in cert matches user’s realm > > This only works iff the NAIs are globally unique (e.g. map to DNS), which > imposes requirements on NAIs that aren’t present in RFC 7542, and > seemingly intentionally, compared to 4282. > > - verify the cert signing chain > > The reality today is that if the server cert is issued by a public CA, then > all that > client can really check is: > - id-kp-serverAuth is set > - dNSName in cert matches user’s realm > - verify the cert signing chain > > We would like to document some recommendations for EAP clients and EAP > operators so that public CAs could be used, and recommend checks for public > vs. private CA issued EAP server certs. > > If you mean the same set of CAs and keys used for TLS by common operating > systems and browsers, it bears highlighting again: industry is moving away > from that. Which is to say that contracts and requirements for PKIs used “by > default” by browsers and operating systems are being explicit about the > need to segment purpose and use case and not use such certificates for such > purposes. > [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? > Already, TLS and e-mail, the two dominant uses of PKI in such systems, are > required to be distinguished at their intermediate level. Browsers are looking > to explicitly only trust the TLS-Web side of the PKI, and making sure that the > TLS-Web PKI side is highly agile. Other cases, such as restricted use server > to > server PKI or industry bespoke cases (such as financial services or system > networking) are being restricted to PKIs that aren’t federated-by-default. > > For example, X9 recently revived their PKI WG, to define PKI requirements > appropriate for financial services customers (like ATM to bank), because > financial services struggle to move at the same speed as modern software, > for understandable reasons. The use of domain/purpose-specific PKIs is > something we can and should be embracing more of. [ofriel] Sure, I’m not saying that id-kp-eapOverLAN is a bad idea or that supplicants should never look for it. But how do we get to the point where we could actually enforce that, given that today operators do try to use EAP with Web/TLS certs. > > It seems like logic should be something like: > > - recommend EAP operators with private CA issued certs on their EAP servers > set id-kp-eapOverLAN and NAIRealm set > - recommend EAP operators using public CAs get EAP server certs with id-kp- > serverAuth and dNSName set > - recommend clients enable trust in public CAs > > This is why I started with trying to define what “public CAs” are. If you mean > the extant CAs trusted by browsers and operating systems, both this > recommendation and the one proceeding it may not be good > recommendations or long-term viable practices. [ofriel] Yes, I mean extant CAs trusted by Browsers and OSes. Yes the recommendations as written above would mean using a cert with a EKU for one purpose, for a different purpose, but that is the unfortunate reality. Do we ignore the problem and say ‘Don’t do this’ or do we try to document some compromise recommendations for both supplicants and CAs, with a roadmap of how to evolve? > > That’s not to say you couldn’t, but it means your EAP services and servers > need to be prepared to be as agile as the Web ecosystem is and modern > operating systems are converging on. The ability to support or be beholden > to “legacy” - whether algorithms, profiles, or trust in particular > organizations - > is something that industry is recognizing does not align with user needs. This > means adopting practices like automation, being able to quantify > compatibility risks, and being able to move quickly as expectations change, in > response to ecosystem challenges. > [ofriel] I hope that this problem is easier to tackle for supplicants running on the major OSes. For things/embedded devices, this is a far harder problem to solve for sure. > Maybe that’s fine for EAP, but I’m willing to suspect that it because updates > may involve physically replacing client hardware or physically installing > firmware, you really don’t want EAP needing to be beholden to those agility > needs of the Web and OSes. And, again, that’s perfectly OK, it just means > defining a PKI and set of procedures that is appropriate for that use case, > and > convincing industry to adopt it as an “out of the box” configuration. Or, > alternatively, embracing private PKI. > [ofriel] Maybe an approach to take is to have one set of recommendations for supplicant clients on major OSes where they can delegate, and possibly piggy back on top of, similar OS functionality for Web/TLS; and have a different looser set of recommendations for thing manufacturers. Or possibly frame the requirements as ‘requirements the supplicant should enforce’ vs. ‘requirements the supplicant should delegate to the OS (e.g. is this a public CA?)’. > - recommend clients implement different cert verification logic depending on > whether the EAP server cert is issued by a public CA or private CA > > Why is this good? > > To the extent browsers or OSes make this distinction, it’s largely based on > simply phasing rollouts of new requirements, with the goal to eventually > require consistent and uniform treatment to ensure simpler code with > consistent and uniform security properties. Having a long-term segmentation > of requirements, or even encouraging them without a clear vision back to > harmonization, is definitely an anti-pattern here. [ofriel] Completely agree. Which is why I stated below “as a longer term goal see if public CAs will issue id-kp-eapOverLAN and NAIRealm” > - for public CA certs, client checks that id-kp-serverAuth is set *and* > dNSName matches user realm. If either check fails, reject. > - for private CA certs, client checks that id-kp-serverAuth or id-kp- > eapOverLAN is set *and* NAIRealm matches user realm.. If either check fails, > reject. > > - as a longer term goal see if public CAs will issue id-kp-eapOverLAN and > NAIRealm. Although of course if some were to start doing this, then there is > a migration challenge, and clients cannot make a hard check for these values > against all public CAs. This doesn’t really seem practical in the near term > at all. > > The effect of the separate EKU, which is actually quite desirable, is that it > functionally makes it difficult for CAs to issue these certificates from > intermediated that lack this EKU or any EKU. Further, CAs subject to > browser/OS vendor oversight are consistently required to segment out their > EKUs at the intermediate level, and required to always specify EKUs. > > The end result is that, to achieve this long term goal, you’ve effectively > required the establishment of a new PKI - just at the intermediate level > rather than the root. And as many of the public CAs can tell you, having > recently encountered challenges regarding non-TLS intermediates from roots > that are subject to browser/OS oversight, it’s often easier to use separate > roots as well. > > Again, I think that’s desirable, to define an entirely new PKI with zero > overlap > with the server auth/TLS PKI used by OSes/browsers, but that does change > your recommendations and design a bit :) The short term recommendation > becomes “don’t use public CAs”, and that seems easier to explain and easier > to evolve the technical requirements, until the time that such a new, EAP- > specific public PKI can be introduced. > [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. Its not clear to me where the correct forum is to even document these recommendations, or who needs to be involved. > In my mind, this is no different from organizations that want TLS certificates > for their servers named “webmail” (not globally unique) or > “mail_01.company.example” (not preferred name form / LDH). The answer is > “use private CAs, don’t use public CAs” > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
