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@xxxxxxxxxxx they'd be forwarded to > > my-home.net. If customer333@xxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxx? 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@xxxxxxxxxxx, but an evil MitM is redirecting that to pretend@xxxxxxxxxxxxxxxxx? 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
