On Oct 31, 2023, at 6:28 AM, josh.howl...@gmail.com wrote: > 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).
I think that's a pretty reasonable suggestion. It works for the web, email, and pretty much every other TLS-based protocol. Why not EAP? I would only add to that that any such method should be limited to just sending a clear-text password. There's no reason to continue allowing MS-CHAP and CHAP. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
