PEAP/MSCHAPv2 with FreeRADIUS vs NPS

[Alan DeKok]

On Jul 13, 2021, at 9:57 AM, Joe Garcia <joe27256 at gmail.com> wrote:
> The client?  A no-name embedded one used with SCADA devices that have
> to be controlled from central servers.  If it was up to me they'd just
> be FreeRADIUS, but unfortunately some have to be NPS since there's
> lots of different vendors involved.

  Arg.

> Already done that, we've taken Wireshark captures, the eapol_test and
> FreeRADIUS logs, and diagnostics from the client, and made things
> identical to what eapol_test sends (as far as we can tell, there may
> be stuff inside the PEAP tunnel that we can't see and aren't not aware
> of).

  Can you send them to me offline?  Ideally also with some test certs / private keys, so that I can decode the packet traces and see what's up.

> We've really tried everything we can think of, so it may be a case of
> someone seeing this and remembering some obscure magic they used to
> get it to work.

  I don't recall seeing any of this before.

> What wpa_supplicant does is ignore the message and re-send the
> Identity Response it's just sent, which continues the negotiation.

  Ah.  That's reasonable, I guess.  But sending a crappy EAP type is still stupid.

> This is one of the bits that reverse-engineering the flow from
> eapol_test/wpa_supplicant helped with.  So for anyone else who's faced
> with this, when doing PEAP/MSCHAPv2 with NPS, when you're expecting to
> get the MSCHAPv2 Challenge if instead you get an EAP vendor-specific
> undocumented Microsoft blob back, re-send the Identity Response a
> second time and then you'll get the MSCHAPv2 Challenge you should have
> got the first time.

  That just depresses me.

  Alan DeKok.