On Apr 14, 2021, at 1:29 PM, Tim Cappalli <tim.cappa...@microsoft.com> wrote: > > 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.
Configuring known ESSIDs is good, but I'm not sure how they're relevant for security. At a high level, if the certificates are OK, then TLS protects you from whatever is going on in the underlying transport layer. Having "known SSIDs" only matters for subsequent traffic flow, I think. At that point, channel bindings (RFC 6677) become more useful. > 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. I strongly suspect that there's no consensus here, and this really isn't the document to do it in. The issues are much larger than for just EAP-TLS. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
