On Mon, 9 Jan 2023, at 22:17, Heikki Vatiainen wrote:
> 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.
With enough string and glue I think strapping EAP-pwd directly into AD is
*technically* possible (leaning on RFC5931, Section 2.7.2 and PasswordHashHash).
The harder problem may be the absence of EAP-{pwd,EKE} methods in the drop down
menu in Win10/11. I suspect most vendors do not have the appetite to do battle
with EAPhost[1] to extend it with another EAP method.
>> 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.
It was a surprise to me.
I like your suggestion of flagging this in Appendix B as a major departure from
EAP-FAST.
I wonder if it should be highlighted also in the 'Unauthenticated Provisioning'
section too?
>> 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?
I would get behind leaving the section as is. With the "sorry folks, you cannot
use EAP-FAST-MSCHAPv2 as you did in your EAP-FAST implementation" I think this
will be fine.
Thanks
[1] https://learn.microsoft.com/en-us/windows/win32/eaphost/portal_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
