Repository : ssh://git@diktynna/doc On branches: backup-redmine/2024-02-03,main
commit 7f796baee6c64c68c16bdb54e3537577064cdffd Author: Linus Lüssing linus.luessing@c0d3.blue Date: Thu Feb 1 06:35:09 2024 +0000
doc: open-mesh/OpenHarbors
7f796baee6c64c68c16bdb54e3537577064cdffd open-mesh/OpenHarbors.textile | 160 ++++++++++++++++++++++++++++++++++++++---- 1 file changed, 148 insertions(+), 12 deletions(-)
diff --git a/open-mesh/OpenHarbors.textile b/open-mesh/OpenHarbors.textile index 9c98359c..223ca191 100644 --- a/open-mesh/OpenHarbors.textile +++ b/open-mesh/OpenHarbors.textile @@ -10,41 +10,177 @@ h3. Issues with Gluon based mesh networks
In a wireless community mesh network like "Freifunk":https://en.wikipedia.org/wiki/Freifunk involving "batman-adv":https://www.open-mesh.org/projects/batman-adv/wiki/ + "Gluon":https://github.com/freifunk-gluon/gluon/ has two issues:
-1) A user's internet traffic is typically unencrypted in the WLAN mesh cloud -2) A set of central gateways behind a VPN tunnel is used for internet traffic (which contradicts Freifunk's philosophy of decentralization, but became defacto mandatory due to for private people unclear Secondary Liability law in Germany: "''Störerhaftung''":https://de.wikipedia.org/wiki/St%C3%B6rerhaftung) +# A user's internet traffic is typically unencrypted in the WLAN mesh cloud +# A set of central gateways behind a VPN tunnel is used for internet traffic (which contradicts Freifunk's philosophy of decentralization, but became defacto mandatory due to for private people unclear Secondary Liability law in Germany: "''Störerhaftung''":https://de.wikipedia.org/wiki/St%C3%B6rerhaftung)
!OpenHarbors-diagram-freifunk-unencrypted.png!
Gluon also supports adding the following three types of WLAN encryption:
-1) "SAE":https://en.wikipedia.org/wiki/Simultaneous_Authentication_of_Equals to encrypt traffic between mesh nodes -2) "OWE":https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encryption to encrypt traffic from a user device to the direct mesh node / AP -3) A "''Private WiFi''":https://gluon.readthedocs.io/en/latest/features/private-wlan.html with WPA-Personal/preshared key encryption, simply bridged to a mesh node's WAN port +# "SAE":https://en.wikipedia.org/wiki/Simultaneous_Authentication_of_Equals to encrypt traffic between mesh nodes: "gluon-mesh-wireless-sae":https://gluon.readthedocs.io/en/latest/package/gluon-mesh-wireless-sae.html +# "OWE":https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encryption to encrypt traffic from a user device to the direct mesh node / AP: "OWE on client network":https://gluon.readthedocs.io/en/latest/releases/v2020.2.html#owe-on-client-n... +# A "''Private WiFi''":https://gluon.readthedocs.io/en/latest/features/private-wlan.html with WPA-Personal/preshared key encryption, simply bridged to a mesh node's WAN port
-While 1)+2) protects against passive snooping, it however does not protect against an active attacker in an open, public network like Freifunk. Due to the open nature of Freifunk, the SAE password would need to be published / added to the firmware (source code) to allow anyone to setup their own mesh node. Overall Freifunk even with 1)+2) would still be susceptible to Man-in-the-Middle attacks. +While 1)+2) protects against passive snooping, it however does not protect against an active attacker in an open, public network like Freifunk. Due to the open nature of Freifunk, the SAE password would need to be published / added to the firmware (source code) to allow anyone to setup their own mesh node. So overall Freifunk even with 1)+2) would still be susceptible to Man-in-the-Middle attacks.
-The issue with option 3) is that while it is secure, as the mesh node owner can configure their own, private password for it in the Gluon Config-Mode Web-GUI of their Gluon mesh router, it can't be used on foreign, other mesh nodes over the mesh network. +The issue with option 3) is that while it is secure, as the mesh node owner can configure their own, private password for it in the Gluon Config-Mode Web-GUI of their Gluon mesh router, it can't be used on foreign, other mesh nodes over the mesh network. There is no secure tunneling or provisioning/collaboration between mesh nodes for the "Private WiFi" feature in Gluon.
!OpenHarbors-diagram-freifunk.png!
h3. Issues with Passpoint/Hotspot 2.0/OpenRoaming solutions
-Industry leaders currently seem to propose and advocate for solutions based on Passpoint/Hotspot 2.0 which in turn builds upon "WPA-Enterprise":https://en.wikipedia.org/wiki/Wi-Fi_Protected_Access#Target_users_(authentic...). Potentially with "WBA OpenRoaming":https://wballiance.com/openroaming/ (Informational RFC: "here":https://datatracker.ietf.org/doc/draft-tomas-openroaming/ or similar trust/contract relations as a federation. Hotspot 2.0 was/is also a requirement for the EU "WiFi4EU":https://wifi4eu.ec.europa.eu/#/home initiative. +Industry leaders currently seem to propose and advocate for solutions based on "Passpoint/Hotspot 2.0":https://en.wikipedia.org/wiki/Wi-Fi_hotspot#Hotspot_2.0 (which in turn utilizes/builds upon "WPA-Enterprise":https://en.wikipedia.org/wiki/Wi-Fi_Protected_Access#Target_users_(authentic...)). Potentially with "WBA OpenRoaming":https://wballiance.com/openroaming/ (Informational RFC: "here":https://datatracker.ietf.org/doc/draft-tomas-openroaming/ or similar trust/contract relations as a federation. Hotspot 2.0 was/is also a requirement for the EU "WiFi4EU":https://wifi4eu.ec.europa.eu/#/home initiative/funding.
Unfortunately, WPA-Enterprise / Hotspot 2.0/Passpoint like as follows has conceptual, compatibility issues with open wireless community mesh networks, like in the following scenario:
!OpenHarbors-diagram-old-approach.png!
+With WPA-Enterprise: + * WPA payload frames are encrypted between the client device (ak. supplicant) and the AP it connects to through the Pairwise-Master-Key * The PMK is securely established via EAP between client device and a RADIUS server (ak. authentication server) * The communication between the AP and the RADIUS server might be encrypted via TLS ("RadSec":https://en.wikipedia.org/wiki/RadSec) -* However, the PMK after it was generated is then forwarded from the RADIUS server to the AP (ak. authenticator). +* However, the PMK after it was generated is then forwarded from the RADIUS server to and installed on the AP (ak. authenticator). -> the RADIUS server needs to **trust** the AP here
-Which means the WPA-Enterprise approach (and therefore also its users like Wifi4EU / Passpoint/Hotspot 2.0, or also eduroam) only works if the APs are run by *trusted administrators*. Or a *trusted, closed source* firmware/vendor. +---- + +__Which means the WPA-Enterprise approach (and therefore also its users like Wifi4EU / Passpoint/Hotspot 2.0, or also eduroam) only works if the APs are run by *trusted administrators*. Or a *trusted, closed source* firmware/vendor.__ + +---- + +The second issue with WBA OpenRoaming is that it currently requires a membership, which includes a membership fee of $3000 one-time plus $3000 yearly. Which is not affordable for a **non-commercial** community initiative like Freifunk.
h2. Solution
-1) Determine the tunnel destination from a domain suffix in the unencrypted login name the user provided -2) Tunnel the full WPA exchange over IP +# Determine the tunnel destination from a domain suffix in the unencrypted login name (ak. "identity") the user provided +# Tunnel the full WPA exchange over IP + +Or in other words, move the 802.1x authenticator from the AP to a remote host of a user's choosing: + +!OpenHarbors-diagram.png! + +h3. (Additional) Use-cases & Benefits + +This proposed, dynamic solution yields the following, additional interesting opportunities: + +# Securely connecting to the wireless mesh community's gateways. So far in a Freifunk mesh network internet traffic is typically only encrypted on the VPN tunnel between a mesh node with an internet uplink and the gateway, if at all. +# Allows anyone to set up and use alternative gateways: +## Securely connecting to your home network via this tunnel, even on untrusted/insecure community mesh networks. In a mesh network that is Freifunk / Gluon based this could even result in faster throughputs for the user, as internet traffic would not need to go over the Freifunk gateway. This could be useful for a residential community, too. +## Allows a club / organisation / residential community / group to securely share its internet connection and/or devices/services, like printers, network storage, media centers or LAN multiplayer games, over an untrusted mesh network. +## Securely connecting to your departments/organisations network via this tunnel, even on untrusted/insecure community mesh networks. For instance blue light organisations like fire, police or ambulance services? +## Securely connecting to a commercial VPN provider and use it as an alternative gateway than the ones a wireless community network provides by default. Without the need of installing and setting up an extra VPN software, as smartphones typically already support WPA Enterprise. And for the VPN providers, would need no extra contract or setup on the APs or other third party devices to be authorized, as the protocol for setting up the tunnel is intrinsic, without needing a broker / rendez-vous point. In contrast to a classic VPN or WPA Enterprise, where both sides would likely need to exchange credentials and addresses beforehand. +## Securely connecting to your commercial ISP's gateways. Also usable for mobile-to-WiFi offloading? Similar to one of WiFi Passpoints goals, but now also usable over on untrusted WiFi APs. +## Allows using eduroam on untrusted Freifunk nodes. +## Increase gateway diversity in wireless community networks like Freifunk, without legal obstacles. Currently in most Freifunk networks the few, select gateways are run by a few admins in their spare time, which contradicts Freifunk's principle of decentralization. Choosing and using alternative internet gateways in a such a Freifunk network is currently infeasible for a non-technical user here. + +Overall, in general: Allows to use an untrusted wireless community mesh network as an easy-to-use, flexible, open, mobile carrier with end-to-gateway encryption. + +h3. Implementation Milestones/Tasks + +<pre><code> +# Preparation: + +[] (Familiarizing with hostapd code, find code points to hook into) +[] Specifiy tunneling protocol: + [] packet format + [] UDP port + [] ... + +# Implementation, hostapd: + +## AP side + +Hook into/within hostapd: + +### Early initalization: + +[] enable/react on OpenHarbors ESSID if configuration option is enabled +[] setup mac80211/cfg80211 to receive encrypted WPA CCMP frames in hostapd + +### On-demand initalization + EAP handling: + +[] parse domain from unencrypted EAP-TTLS username from EAPoL frames +[] create a UDP/L2TP tunnel to parsed domain +[] associate/memorize MAC + UDP socket (address+port) +[] encapsulate EAPoL +[] EAPoL frames from client to the socket/tunnel: + [] encapsulate with our IP/UDP/L2TP header + [] forward to IP router/stack +[] EAPoL frames from the socket/tunnel to the client: + [] decapsulate/remove our IP/UDP/L2TP header + [] forward to mac80211 + +### Data forwarding: + +[] WPA CCMP frames from client to the socket/tunnel: + [] encapsulate with our IP/UDP/L2TP header to <domain> + [] forward to IP router/stack +[] WPA CCMP frames from socket/tunnel to client: + [] decapsulate/remove our IP/UDP/L2TP header + [] forward to mac80211 + +## Remote side + +### Initialization + +Option A) +* Setup/Utilize mac80211_hwsim kernel module? + +Option B) +* + + * Remote Server side, initialization / EAP handling: + * Remote Server side, data forwarding, from client: + ... + * Remote Server side, data forwarding, to client: + ... + +## Firmware Packaging/Integration + +### OpenWrt package/integration: + +AP/client side: + +[] allow building a hostapd/wpa_supplicant/wpad variant + without OpenHarbor code (size tuneability matters + on embedded) + +[] add an openharbor-client package + [] add requirement to usable hostapd/wpa_supplicant/wpad + build variants + [] integrate into OpenWrt's netifd('s mac80211.sh) + [] add documentation/description to package + [] add document/description on OpenWrt Wiki's "UCI /etc/config/wireless page":https://openwrt.org/docs/guide-user/network/wifi/basic + +Remote side: + +[] add an openharbor-server package + [] add documentation/description to package + +### Freifunk/Gluon integration + +[] add a gluon-openharbor-client package to enable OpenHarbor on + WiFi radios used by Gluon + [] add documentation/description to package + / Gluon's readthedocs, including use-cases/illustrations + for Gluon/Freifunk users +[] add a gluon-openharbor-server package + [] add Gluon Config-Mode Web-GUI integration, + usable by non-technical people: + [] to set output interface for decrypted WPA + (e.g. WAN vs. LAN ports) + [] to set a list of allowed username//password + combinations +</code></pre> + +## Optional/additional/future Milestones/Ideas
+* Kernel module / mac82011 additions for encapsulation for performance - if necessary? +* Passpoint / Hotspot 2.0 compatibility +* More EAP methods: Any other methods other than EAP-TTLS which + can provide a cleartext username and/or domain? +* Layer 2 encapsulation method, which skips the IP/UDP/L2TP headers and + uses a smaller, custom ethernet frame header + * allows login via: <username>@<mac-address-destination> + -> useful to tunnel from one mesh node to another? \ No newline at end of file