> For the current EAP-TLS based methods, the "service" of putting on the > harness and hooking you in is not provided. And that is exactly what I want to > achieve with the TLS part of EAP-FIDO. The users shoulnd't see any of the > certificate check parameters, it should be implicit and that is where we > improve the security of the EAP-TLS based method (Details: > see last paragraph of this mail)
Playing Devil's Advocate and going a bit OT: this is an excellent goal, so why stop at EAP-FIDO? We could define a similar validation logic for the existing TLS-based methods to obtain the same benefit. For example: * The value of the EAP-Identity/Response NAI realm is a well-formed FQDN * The phase 1 server certificate is issued by the WebPKI * The phase 1 server certificate's name takes a value that corresponds to the NAI realm The supplicant trusts the server if the certificate is valid and the realm matches (hand-wave) the certificate name. I think this is the moral equivalent of section 4.2.5 with Option B in Appendix B. The same validation logic could be used in phase 1 of the existing tunnel methods, and the inner method (e.g. EAP-FIDO) executed in phase 2 as usual. It makes no sense to update the existing methods, but perhaps it could be offered as guidance for existing named methods (and referenced in new methods where it makes sense). WPA3-Enterprise already defines requirements for server certificate validation by supplicants, and Windows 11 applies the same validation logic for all native EAP methods and lower layers, so there is precedent (I believe the main difference between Windows 11 and the approach outlined above is that Windows 11 does not require validation of the server name (although this can be configured), instead requiring CA pinning). Josh _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
