On Nov 19, 2019, at 10:40 PM, Owen Friel (ofriel) <ofr...@cisco.com> wrote: > > Assuming that NAIRealm is a registered domain as per RFC 7542, and thus > public CAs can verify ownership, the goal / where we want to get to is: > > - CA may be a public CA and thus public CAs can be enabled by default in > supplicant config
I would add: only if the new checks pass. > - supplicant checks NAI Realm in the EAP identity cert matches that of the > user's realm > - supplicant verifies id-kp-eapOverLAN is set In addition to id-kp-serverAuth. We still need a way to distinguish server certificates from client certificates. > And also assuming that public CAs will not issue certs with an NAIRealm or > id-kp-eapOverLAN bit. (This is certainly true for Let's Encrypt. See below > for details.) And it could be years before public CAs do. I agree. > Does that mean there is an intermediate rollout phase where the supplicant > checks that the realm the user enters matches a dNSName in the EAP cert? It's worth checking that anyways. It can be done quickly by supplicants, and doesn't require changes to any CAs. > The rollout / upgrade issue with this is of course if we give guidance that > supplicants > (i) check that entered realm matches NAIRealm; and id-kp-eapOverLAN is set > If that fails then (ii) check that dNSName matches entered realm Yes. > at what point in time would supplicant behaviour ever change to remove the > fallback to option (ii) and checking dNSName only? I'm not sure. > As a data point on RFC 4985 and id-mod-dns-srv-name-93 (or RFC 6125 SRV-IDs): > Public CAs generally don't issue these either, so the same issue with > supplicants checking for NAIRealm or id-kp-eapOverLAN exists with > id-mod-dns-srv-name-93 w.r.t. Public CAs. I agree. TBH, even if these practices are only implemented in a roaming consortium, they will still be useful. A roaming consortium can create their own CA with their own rules. i.e. even if just Eduroam adopts this practice, then it can be used by millions, if not tens of millions of people. And making EAP easier to use is always of enormous utility. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
