On Dec 17, 2019, at 1:51 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > } If at some point in the future, there is one or more well-known trust > } anchors that (IoT?) devices can build in, and these CAs are willing to issue > } certs with some or all of the above fields, can we design a transition > } process from one-touch provisioned private CAs to a common DN+extension > } based common anchor?
I hope so. My $0.02 is that configuration belongs in a machine-readable format, not in fields in a GUI. i.e. fields in a cert. Once we have a machine-readable format, transition plans become simpler, because we have a better handle on what systems are doing. >> The ideal experience would be along these lines for a client with real user >> interactions: > > 1> - client connects to an EAP server > 2> - client prompts user for userId + realm and password > 3> - client verifies server cert has id-kp-eapOverLAN set > 4> - NAIRealm in cert matches user’s realm > 5> - verify the cert signing chain > > <2> and <3> seem in the wrong order. > If the certificate has NAIRealm, why would we need to ask the user for the > realm? Wouldn't we instead ask them: "What is your userID in REALM FOO" The server certificate is presented before the user credentials are sent (PEAP / TTLS). So the client can automatically derive the NAIRealm. The issue is that users are slow. It's bad to have the EAP session hang while the user enters "name / password" in a GUI. That's the only real reason why name / password is requested before the EAP session starts. >> The reality today is that if the server cert is issued by a public CA, then >> all that client can really check is: > > 1> - id-kp-serverAuth is set > 2> - dNSName in cert matches user’s realm > 3> - verify the cert signing chain > > I think that <3> happens first, and the connection is dropped if it does not > validate. Maybe you aren't expressing an order here at all. The only reason to order these checks is cost. i.e. simple checks should run first, before complex checks. >> 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 >> - recommend clients implement different cert verification logic depending on >> whether the EAP server cert is issued by a public CA or private CA > > Would setting dNSNAME on private CA issued certs reduce complexity? No. The DNS names at at least the realm names (example.com), but they could be more (radius.example.com). There's no good way to automatically derive the NAIrealm from a DNS name. Given both, you can check if they're compatible. But that's it. >> - 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. > > Trust NAIRealm extension only if id-kp-eapOverLAN is set. > having implemented the dNSNAME code path, it seems like there is no point in > implementing the other path. The NAIRealm tells you exactly which Realm you're using. The DNSName path doesn't. The NAIRealm can be used to skip the step where the user is prompted for the realm. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
