On Mon, 9 Jan 2023 at 09:43, Alexander Clouter <alex+i...@coremem.com> wrote:
Section 3.8.3 - Server Unauthenticated Provisioning Mode > > "Phase 2 EAP methods used in Server Unauthenticated Provisioning Mode MUST > provide mutual authentication, provide key generation, and be resistant to > dictionary attack. Example inner methods include EAP-pwd and EAP-EKE." > > As EAP-FAST-MSCHAPv2 is not resistant to dictionary attack[2] we need to > tell people this. > I agree. I also noticed this significant change compared to EAP-FAST. It's not mentioned in RFC 7170 Appendix B that lists the major changes compared to EAP-FAST: https://www.rfc-editor.org/rfc/rfc7170#appendix-B I'd say this is a major change because EAP-FAST-MSCHAPV2 can be directly integrated with Windows AD but EAP-pwd and EAP-EKE can not. This is not to bring back EAP-FAST-MSCHAPv2 but simply a note that Server Unauthenticated Provisioning Mode is not as easy to use than in EAP-FAST. In practice, as anyone seen anything other than EAP-FAST-MSCHAPv2 actually > be used for this? Win10/11 does not; and EAP-AKA/EAP-SIM is not exactly > available to non-telcos, right? The other methods supported you would have > the server (inner) identity available (ie. EAP-TLS) which opens the > question why you would not also know the outer server identity. > Can't comment on what's used with TEAP but this is likely a surprise to those who think they can quicly port EAP-FAST's Server Unauthenticated Provisioning Mode to TEAP. > No idea what to do here. > Is it known how widely Unauthenticated mode is used? Can this be left as it is for this round of TEAP update? -- Heikki Vatiainen h...@radiatorsoftware.com
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
