On Mon, 10 Nov 2025 at 16:47, Michael Richardson <[email protected]> wrote:
> > Heikki Vatiainen <[email protected]> wrote: > > > certificate is not used. Should this variant of EAP-TLS have its own > > EAP type? > > As we discussed at the mic, I'm not convinced it's needed, and I'm > concerned > that it requires much more effort to deploy. > After reading the other messages in this email thread, I no longer think it's a good idea to have a new EAP type: - it requires more to deploy, as you've mentioned above, and as Alan wrote a new EAP type would require more code than using an existing type - if e.g., TEAP were to have server-unauthenticated mode, would it need a new EAP type? I don't think so - EAP-FAST has server-unauthenticated mode and it has worked just fine with all modes using the same EAP type (EAP-FAST) - enabling client-unauthenticated and/or server-unauthenticated mode for an EAP type is simply a configuration option with possible signalling with eap.arpa identity or other means > > The Wi-Fi Alliance and hostapd specifications and implementations, > > discussed earlier on the list, appear to use an EAP type that is > > different from EAP-TLS type. > > Which method is this? > I'd say these two hostap git links show best what the currently available server-unauthenticated EAP-TLS variants are: 1. UNAUTH-TLS vendor specific EAP type - this method includes only server authentication https://git.w1.fi/cgit/hostap/commit/?id=065d2895b4693e8c923580dbfa31123297c8bb7d 2. HS 2.0R2: Add WFA server-only EAP-TLS peer method I think this is the method that is referenced by https://www.ietf.org/archive/id/draft-ietf-emu-eap-arpa-10.html#section-1.1.1-3 https://w1.fi/cgit/hostap/commit/?id=8e5fdfabf69a7692d1a0d04f00fa10 3e9ff72010 -- Heikki Vatiainen [email protected]
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
