OpenHarbors - Dynamic Tunneling of WPA over IP/L2TP

[Alan DeKok]

On Jun 19, 2024, at 4:22 PM, Linus Lüssing <linus.luessing at c0d3.blue> wrote:
> I don't think that RADIUS does this, this does not work for us with Freifunk.
> Just like we can't offer eduroam on a Freifunk mesh node / AP
> right now either:

  I would strongly suggest not inventing your own protocols.  That is a path which is likely to end in frustration.

> The final RADIUS Accept message from the RADIUS server, no matter
> if using it with or without TLS, will as the final step of its EAP
> exchange send the pairwise-master-key to the AP. WPA encryption is between the
> client/supplicant and the AP/authenticator only. The RADIUS TLS
> encryption is a separate encryption channel and only between the
> AP/authenticator and remote RADIUS server. It's not
> end-to-end-encrypting payload between the client/authenticator and a
> remote host.

  That's how the protocols work.  You're not going to get "end to end" encryption of EAP. 

  The supplicant to AP link is open: use a TLS-based EAP method if you care about security / privacy.

  The AP to RADIUS server link can be secured with IPSec, or with RADIUS/TLS.

> This whole exchange therefore requires the AP/authenticator to be
> run by a trusted operator. At Freifunk most of our nodes are run
> by people that do not know each other. The AP/authenticator would
> be able to Man-in-the-middle attack there.

  You can't stop MITM attacks when the systems lack mutual trust.  It's impossible.

  What you can do is to ship client certificates on each AP, then run RADIUS/TLS between the APs and a RADIUS server that you host.  This server can then either authenticate users, or perhaps forward the RADIUS packets.

  But any party to the RADIUS conversation will see all RADIUS traffic.  The solution there (again) is to use a TLS-based EAP method.  For those methods, user identity, passwords, etc. are hidden from all parties.

> That was the main idea of this proposal, to create
> end-to-end-encryption between a client/supplicant and a remote
> host. Without needing an extra VPN software on the client device.

  You can't encrypt the supplicant to AP connection without re-implementing all of the supplicant software / Wi-Fi state machine, and all of the AP state machine. 

  i.e. it doesn't make sense to say "I don't want to put a VPN on the supplicant, but I do want to encrypt suppliant traffic which is not currently encrypted".

  That's called a VPN.

  Alan DeKok.