The equivalent to HTTPS with EAP would be if the ESSID was a subject name in the certificate and ESSIDs could be registered and validated. That doesn't exist today and wouldn't ever really work (or scale). The closest thing to it is server certificates for Passpoint OSU, which have their own issues and aren't feasible for most deployments.
Given the significant changes required in both EAP clients and EAP servers for TLS 1.3, I think the time is appropriate for making the server certificate requirements more strict. This is likely the last chance for a long time. tim ________________________________ From: Alan DeKok <al...@deployingradius.com> Sent: Wednesday, April 14, 2021 13:21 To: Tim Cappalli <tim.cappa...@microsoft.com> Cc: mcr+i...@sandelman.ca <mcr+i...@sandelman.ca>; emu@ietf.org <emu@ietf.org> Subject: Re: [Emu] Issue 47 Certificate identity checks On Apr 14, 2021, at 10:56 AM, Tim Cappalli <tim.cappa...@microsoft.com> wrote: > > Honestly, no information in an EAP server certificate is good enough for a > user to make a "walk up" informed decision. I'm curious how this is different from say, HTTPS. The use-cases seem pretty similar. > At least requiring an EAP-specific EKU or OID would require operating systems > to separate out the EAP trust store. I agree 100% there. > TLS Web Server Certificate should not be acceptable for EAP. Well, yes. The question is how do we get there from here. Alan DeKok.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
