OpenHarbors - Dynamic Tunneling of WPA over IP/L2TP

[Linus Lüssing]

Hi Johannes,

Thanks for your valuable feedback!

On Wed, Jun 19, 2024 at 11:28:03AM +0200, Johannes Berg wrote:
> On Wed, 2024-06-19 at 11:03 +0200, Linus Lüssing wrote:
> > 
> > If a user uses user123 at my-home.net they'd be forwarded to
> > my-home.net. If customer333 at vpn-provider.org then to
> > vpn-provider.org. These domains wouldn't need to be added to a
> > config on the AP due to being determined/parsed on-demand from EAPoL.
> 
> This seems ... problematic, to say the least? Who knows they won't
> authenticate to pretend at evil-provider.org? Might want to have an allow-
> list or so somewhere? That sort of defeats the purpose though, but seems
> somewhat needed?

You mean an allow-list for the allowed, remote providers to forward to?
Can't we accept any destination, just like an AP typically does
not care about a classic VPN's destination?

Or do you mean a Man-in-the-Middle attack, where someone would
like to authenticate to user123 at my-home.net, but an evil MitM is
redirecting that to pretend at evil-provider.org? That should be
covered by the user checking the presented server's
certificate in EAP-TTLS for instance, shouldn't it?

> 
> > 2) Get hostapd + Linux kernel to emit WPA CCMP frames encapsulated
> > in an ethernet frame on the Wifi interface.
> > 3) Get hostapd to use a wifi AP interface per STA for this, similar
> > to WDS mode.
> 
> You forgot to mention the part where you _don't_ want the wireless side
> to actually have the keys and decrypt the packet, I think? But that's
> ... tricky, hardware often requires the keys to do a proper connection
> in the first place,

Right, that was the idea. From the ath9k code I was aware of the
nohwcrypt module parameter. And I was hoping that other, popular wifi
drivers for APs, specifically ones used at
Freifunk, would have something similar. Which would be
ath9k/ath10k/ath11k and mt76 I think. For ath10k I also see
nohwcrypt and for ath11k I see a crypto_mode=1 for software
encryption. For mt76 I see some "fall back to sw encryption"
comments, so generally should be usable with software encryption -
just a module parameter / proper interface would be needed to enforce it?

> and once you have management frame encryption you
> also really need it.

Hm, ok, good point, management frame protection is something I
forgot to consider indeed. Typically we don't have MFP on Freifunk
nodes at the moment. I'm now wondering if they could also be tunneled if
MFP were enabled. But then I guess the remote authenticator would
need to have a lot more state synced from the AP.

> But then hardware will decrypt your data frames
> too.
> 
> > 2) Get hostapd to create a special mac80211_hwsim virtual wifi
> > interface based on received EAPoL, use it to receive and decrypt the
> > WPA CCMP frames from the Linux kernel's WPA encryption/decryption
> > code, have hostapd install the PMK to it.
> 
> You're confusing the key architecture and how it all works in Linux
> enough that I don't even know how to comment on this.

Ok, let me correct my previous statement. A PMK is derived either
from the PSK when using WPA Personal. Or as a result from
EAP exchange between the client/supplicant and the RADIUS server with
WPA Enterprise. The RADIUS server installs/forwards the PMK to the
AP/authenticator. The AP/authenticator and client/supplicant will
then generate the PTK for unicast packets and GTK for broadcast packets
from it through the 4-way handshake. The PTK and GTK is what hostapd will
provide to the Linux kernel, which will either use them itself for
en-/decryption in software or which the Linux kernel will
install/forward to the hardware. Is that more correct/precise?

Regards, Linus