The RFC draft maybe long expired, but Microsoft still has EAP-MSCHAPv2 enabled by default settings. The problem is that if EAP gets negotiated (because the client supports it), EAP-MSCHAPv2 will typically be selected. A workaround would be to disable EAP negotiation on the client side to allow MSCHAPv2 to be selected and that be only if the Microsoft server is configured to allow that. It's mostly a compatibility problem for end-users, especially when using SSTP. Regards, - Eivind On Fri, Apr 3, 2020 at 8:27 AM James Carlson <carlsonj@xxxxxxxxxxxxxxx> wrote: > > On 2020-04-03 11:09, Eivind Naess wrote: > > Implementation based on the RFC: draft-kamath-pppext-eap-mschapv2-02. > > Adding support for MSCHAPv2 inside the extensible authentication protocol (EAP). > > > > Author: Thomas Omerzu <thomas@xxxxxxxxx> > > Origin: https://w3logistics.com/blog/archives/438-EAP-MSCHAPv2-for-pppd-2-4-7.html > > Bug: https://github.com/paulusmack/ppp/issues/138 > > Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/ppp/+bug/1858349 > > Pull Request: https://github.com/paulusmack/ppp/pull/139 > > Last-Update: 2020-02-24 > > Signed-off-by: Thomas Omerzu <thomas@xxxxxxxxx>. > > This all seems ok to me, but I do have one nit: that document referenced > is a long-expired Internet Draft, not an RFC. As far as I know, there > are no RFCs that cover Microsoft's foray into this area. > > -- > James Carlson 42.703N 71.076W <carlsonj@xxxxxxxxxxxxxxx> -- Cheers, - Eivind
