Re: [Emu] EAP/EMU recommendations for client cert validation logic
On Dec 17, 2019, at 1:51 PM, Michael Richardson 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
Re: [Emu] EAP/EMU recommendations for client cert validation logic
Owen Friel (ofriel) wrote: > “Background: > a) the current practice in TLS-based EAP methods is to use certificates with > "id-kp-serverAuth" OID set for Extended Key Usage. > b) many supplicants check for this OID, and refuse to perform authentication > if it is missing > c) supplicants do not check DNS names or any other field in the certificates > d) as a result of this lack of verification, supplicants ship with all known > CAs disabled for TLS-based EAP methods” > The key consideration is that RFCs that recommend cert fields for EAP servers > that clients should check for are not currently issued by public CAs, and in > some instances (e.g. SSID) ownership can often not be proven by CAs. > For example: > https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EKU > https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID > https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm > 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? > 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? I think that this is a really big if. So, I want to change the question, which I think can make this problem a lot easier to get traction on. } 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? > 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 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. > 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? > - 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. > Note that for an IoT device, there is some work to do to define how to e.g. > extend the RFC8366 so that it can specify the dNSName that devices should > check for when verifying EAP identity where they EAP server uses a public CA. > Some related options are outlined in > https://tools.ietf.org/html/draft-friel-anima-brski-cloud-01. Owen and I have wrangled about the topic of how exactly the pinning is done. The above document does not really outline the problem space in my opinion, focusing on other dimensions of the process. The requirements that Owen has expressed to me are: 1) 8366bis must be able to pin CA + DN/SAN, such that the operator can rotate their public key without invalidating the voucher. (possibly including changing public key algorithm) 2) 8366bis must be able to pin (?-public key), such that the operator can switch (public) CAs without invalidating the voucher. There might be a (3) that I can't think of right now.
[Emu] EAP/EMU recommendations for client cert validation logic
Hi, At ACME meeting at IETF106, the last discussion of the week was around EMU looking for recommendations for EAP client/peer/supplicant cert verification logic when the client is verifying the cert that the EAP server presents. Minutes here: https://datatracker.ietf.org/doc/minutes-106-acme/ The recommendation was to ask lamps. This was also discussed on EMU mailer recently.. Quoting some additional background that Alan gave on EMU mailer: "Background: a) the current practice in TLS-based EAP methods is to use certificates with "id-kp-serverAuth" OID set for Extended Key Usage. b) many supplicants check for this OID, and refuse to perform authentication if it is missing c) supplicants do not check DNS names or any other field in the certificates d) as a result of this lack of verification, supplicants ship with all known CAs disabled for TLS-based EAP methods" The key consideration is that RFCs that recommend cert fields for EAP servers that clients should check for are not currently issued by public CAs, and in some instances (e.g. SSID) ownership can often not be proven by CAs. For example: https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EKU https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm 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? 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? 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 - NAIRealm in cert matches user's realm - 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. 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 - 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. Note that for an IoT device, there is some work to do to define how to e.g. extend the RFC8366 so that it can specify the dNSName that devices should check for when verifying EAP identity where they EAP server uses a public CA. Some related options are outlined in https://tools.ietf.org/html/draft-friel-anima-brski-cloud-01. Comments/thoughts? Regards, Owen ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
