Accept all users in v3.0.17 vs v.2.2.8

[Alan DeKok]

On Oct 6, 2021, at 11:55 AM, Gabriele Bellicini <g.bellicini003 at studenti.unibs.it> wrote:
> I’m writing here because of a problem I’m having trying to do a specific
> thing with FreeRADIUS 3.0.17.

  That's years out of date.  I'd suggest upgreading/

> For a university project, I need to setup a malicious access point that
> lets everyone connect to its Wi-Fi network in order to perform some traffic
> analysis.
> 
> Previously, using FreeRADIUS v2.2.8 I managed to do this by simply putting
> 
> update control {
> 
> Auth-Type := Accept
> 
> }
> 
> in the authorize section of the inner-tunnel. Everything worked fine and I
> could connect to the Wi-Fi network using any combination of username,
> password and authentication method (PEAP/TTLS for phase 1 and any other
> method in phase 2).

  It could work for TTLS + PAP.  It didn't work for PEAP.

> Recently, however, I had to switch to a Raspberry Pi 3B+ to use as access
> point. Here I downloaded the 3.0.17 version, which is the only one
> available through apt-get.

  It *is* possible to download newer versions.  There's a whole web site and everything with source.

> Configuring v3.0.17 in the same way I did with v.2.2.8, however, I get
> really weird results. Basically, using iOS (14, but I don’t think it’s a
> matter of version) I can still connect to the same Wi-Fi using any username
> and password.

  If you read the debug output, you'll see it's doing TTLS + PAP.

> If I use Android, instead, I can’t connect even using the
> correct password. A subportion of the logs I get from running in debug mode
> is this one:
> 
> (8) eap_peap: Session established. Decoding tunneled attributes
> (8) eap_peap: PEAP state send tlv success
> (8) eap_peap: Received EAP-TLV response
> (8) eap_peap: Client rejected our response. The password is probably
> incorrect

  Exactly.

> The log in its entirety is attached at the end of this post.
> 
> So FreeRADIUS sends an Access Accept, but the mobile phone rejects it.

  As it should.  Because PEAP does MS-CHAPv2 in the inner tunnel.  And MS-CHAPv2 authenticates *both* the end user, and the server.  If the server doesn't have the correct password, then it can't calculate the correct MS-CHAPv2 data.  And the end user system refuses to connect.

> Again, this only happens with Android smartphones, not with iPhones. The
> method I use, now only works for TTLS/PAP, not for PEAP or TTLS/MSCHAP.

  Exactly.

> Is there still a way to accomplish what I could do in v2.2.8 but in
> v.3.0.17? Did anybody notice a different behavior between iOS and Android
> smartphones?

  No.

  "Auth-Type Accept" didn't work for PEAP in v2, either.  This isn't a v2 versus v3 issue.  PEAP / MS_CHAPv2 simply doesn't work that way, and hasn't worked that way since the beginning of PEAP.

  Alan DeKok.