So again, if NAIRealm is not bound to an organization’s public domain name, how does a public CA prove ownership of an NAIRealm? How is this different than ESSID?
I don’t see how this improves assurance of a server identity. tim From: Emu <emu-boun...@ietf.org> Date: Monday, November 18, 2019 at 9:18 AM 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
