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 - supplicant checks NAI Realm in the EAP identity cert matches that of the user's realm - supplicant verifies id-kp-eapOverLAN is set 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. 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? 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 at what point in time would supplicant behaviour ever change to remove the fallback to option (ii) and checking dNSName only? 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. Owen P.S.: Let's Encrypt implementation is at: https://github.com/letsencrypt/boulder You can see the only allowed KeyUsage and ExtKeyUsage bits here: https://github.com/letsencrypt/boulder/blob/master/cmd/gen-ca/main.go#L318 https://github.com/letsencrypt/boulder/blob/master/cmd/cert-checker/main.go#L303 -----Original Message----- From: Emu <emu-boun...@ietf.org> On Behalf Of Alan DeKok Sent: 18 November 2019 14:18 To: EMU WG <emu@ietf.org> Subject: [Emu] Best practices for supplicants and authenticators After the meeting earlier today, I made some notes on best practices for supplicants and authenticators. I think it would be useful to have an official WG document which gives guidance. 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 If the supplicants did ship with root CAs enabled, then because of the lack of validation in (c), the supplicants would hand over user credentials to any authenticator who has a properly signed certificate. This is wrong, and is why all of the root CAs are disabled. It would be useful to simplify the user experience when working with EAP-TLS. It would also be useful to reduce security issues. This is where a new document is needed. I believe that the standards exist to support these goals. However, there's a lack of guidance around using these standard. It would be good to document current practices, and then give guidance on how to upgrade to better practices. I'll start off describing the end goal, and then discuss how we can get there. The goal is to have certificates which contain the id-kp-eapOverLAN OID (RFC 4334), and either the NAIRealm OID (RFC 7585), or a similar one dedicated to TLS-based EAP authentication. Supplicants can use these fields to verify that the certificate is both intended to be used for TLS-based EAP authentication, and that the certificate is for a given realm. The end user experience *should* be something like: * connect to a system which uses 802.1X authentication (SSID, wired, etc) * prompt the user for full credentials (user id + realm / password) * validate that the server certificate has the id-kp-eapOverLAN OID set, AND that the NAIRealm OID matches the user's realm * validate the certificate chain If those validation steps succeed, then the supplicant could send the users credentials over the EAP method. I think that this extra validation means that supplicants can trust known root CAs by default. Which makes the user experience much better. Since the certificates do not currently contain these fields, and supplicants don't check them, we need an upgrade path. The first step is to suggest that admins generate certificates with the above fields. This likely means that certificate authorities will be asked to sign certs with the NAIRealm OID, which they might not do. This limitation is less of a problem in a roaming federation like Eduroam, where they are their own CA. The next step is to suggest that supplicant vendors upgrade their systems to allow the id-kp-eapOverLAN OID, *or* the id-kp-serverAuth in server certificates. That is a simple change, and shouldn't have any negative affects. Supplicants can also be upgraded to check the NAIRealm. If the field does not match the users realm, then the certificate should be rejected. If the field does match, then the supplicant should validate the certificate chain. This validation should also include trusting known root CAs by default. We should also recommend that supplicant vendors check the id-mod-dns-srv-name-88 and id-mod-dns-srv-name-93 fields of server certificates. If the domain names there do not match the realm given by the user, then the user should be warned, and the certificate rejected. If accepted, I think that such practices would tremendously simplify the use of TLS-based EAP methods for both users and administrators. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
