On Thu, Jun 20, 2024 at 10:01:14AM +0200, Johannes Berg wrote: > [...] > So from reading between the lines, I'm interpreting your suggestions as > that you want to effectively have the "AP" be mostly a medium/radio > interface. The "AP" wouldn't have any of these keys, it would simply > forward frames to the actual AP SME/MLME that lives elsewhere. Initially I thought of keeping any Wifi radio related state, any management and action frames, retries etc. on the WiFi AP. And only forwarding the encrypted payload frames to the remote authenticator. And the EAPoL exchange, to allow the remote authenticator to get the keys to decrypt and encrypt the payload. For that any potential RADIUS client would also be moved from WiFi AP to the remote authenticator. But yeah, MFP would not quite make it that easy... as the PTK is used for both payload frames and indvidually addresses management frames / action frames. > > Note: This description conflict with your (other) goal, namely that the > identity would be in the EAP frames. You'd already have to do > authentication/association to even get to the EAP frames, but if the > SME/MLME is remote, then you can't have that. There are changes in 11bi > to already encrypt the association request frame, but I suppose we can > limit this to what's currently deployed. I wanted to snoop the EAP "Identity Response", which follows after the Association Response and EAP "Identity Request" but would come before the EAP-TTLS/EAP-TLS/EAP-PEAP/... and would have had the outer login username in cleartext. Hm, you mean with an upcoming 11bi the EAP "Identity Response" would be encrypted, too? That would indeed make things more tricky... Any idea what key that would use then? Initially due to this WBA OpenRoaming RFC here https://www.ietf.org/archive/id/draft-tomas-openroaming-02.html#name-privacy-policies which requires at least an "anonymous@realm" instead of just an "anonymous" as identity I also thought I would be able to keep relying on this. But if at WBA OpenRoaming / Passpoint the AP is still the authenticator, of course it could receive these encrypted frames and decrypt them anyway. > Sub-Note: Given latency constraints, I don't think you can get around > this either. I was thinking e.g. you could make a hidden network and > respond to any SSID of the form "OH@domain", so the association request > already goes to the remote SME/MLME, but then you need better than say > 20ms roundtrip time to reliably be able to associate... For Ack's I understand the low latency limits, as with 1 Gbit/s transfer speeds buffers very quickly get saturated. But is there such a low latency limit for authentication/association, too? > > In any case, what I'm saying is that you're not strictly able to layer > it this way, so you have to have split responsibility for SME/MLME tasks > between local and remote. This gets tricky if you consider what the PTK > (KEK/KCK/TK) are used for. > > > Note 2: I suspect another unstated assumption is that you really want > the local AP to *not* have the keys at all, so that > 1. it can have plausible deniability on the contents of the traffic, > lest it be subjected to some kind of rules again about scanning or > whatnot? Though I realize that's not the case today in Freifunk, > where the traffic will be transported to some place in an > encrypted tunnel, but is re-encrypted for that tunnel, of course. > 2. For things such as eduroam/company networks they will not want the > AP to even be able to see the traffic... > So probably need to clarify this. Right, I at least don't want the AP to have keys to encrypt/decrypt payload data. 1) I would like to prevent an easy to compromise, exposed AP to get access to the LAN ressources which a client wants to access (university/company/hospital/hotel/gov. setting) -> either through social engineering as described in my previous mail; but a supply chain attack on mass-produced, overseas shipped WiFi APs might also be an attack scenario maybe, some "locally produced" server where an authenticator would reside, locked in a server room would be easier to protect? 2) I would like to have an easy option to prevent the destination IP to be publically visible which a client wants to access while browsing in a community mesh network. 3) I would like to have an easy option to diversify the number of internet gateways/exits in a Freifunk mesh network and make them easily and securely selectable by the user. -> also to maybe relieve current, kind of central gateway admins in our community mesh networks 4) I would like to be able to provide eduroam on a Freifunk node 5) I would like to be able to provide Passpoint on a Freifunk node (eventually) and Wifi4EU on/with Freifunk nodes (which currently requires Passpoint) 6) I would like to have an alternative to WBA OpenRoaming, one that does not require membership fees. And which does not require either trusted node admins and/or closed source/secret firmwares. ... and many more points and use-cases :-). And it seemed to me that this idea/feature could kill multiple birds with one stone. Right now I don't care that much if the AP has management related keys / keys for DoS protection. To me privacy/spying protection seems more important than DoS protection (in most scenarios)? Especially as Wi-Fi can still be just jammed anyway? And don't care much if this DoS protection would become void in a wireless community mesh network setting with fully untrusted nodes, as we don't have that now either (though it might be interesting to maybe combine MFP on no-fwd-11s with Babel's HMAC or BMX's equivalent authentication option at some point, they allow building subgraphs / alternative, trusted routes in the mesh between a subset of mutually trusting nodes/node owners). > > > The most obvious concern with this would be management frame encryption > which uses the PTK (TK), IGTK, and also especially beacon protection > (BIGTK). If it weren't for the standard I wouldn't care that much about IGTK or BIGTK secrecy. But right, 802.11ax-2021 says: "12.12.2 Security constraints in the 6 GHz band ... The STA shall use management frame protection (MFPR=1) when using RSN." And 802.11-2020 says this...: "12.5.3.4.2 CCM recipient processing CCM recipient processing uses the same parameters as CCM originator processing. A CCMP protected individually addressed robust Management frame or PV1 Management frame shall use the same TK as a Data frame or PV1 Data frame. ... 12.5.5.4.2 GCM recipient processing GCM recipient processing uses the same parameters as GCM originator processing. A GCMP protected individually addressed robust Management frame shall use the same TK as a Data frame." It's a bit unfortunate, that it was decided to generate a new key for protected, group addressed management frames and beacons... but then reuse the payload key for individually addressed frames... they nearly did the right(tm) thing for this to work :D. Wouldn't have been that much of a hassle to require a newly generated key for individually addressed, protected management frames, too? > > If you leave out beacon protection, you leave out EHT/MLO/Wi-Fi 7. > Perhaps one way would be for the AP to actually provide the BIGTK to all > the remotes so they can distribute that key in the 4-way-HS and their 2- > way-HS updates, but then of course everyone has the BIGTK and the > protection becomes a fig-leaf only done for spec compliance, since > someone can always connect to their own network that just gives them the > BIGTK back. But in a way, that's already true today, anyone who can > connect to the network can interfere with it at that level since they > get the BIGTK. > > For the IGTK it's interesting because you _could_ have each backend have > their own IGTK, and then they could deauth all the clients that were > using their network, but not any others (that are using MFP); in any > case, actual IGTK use is pretty rare. > > > > 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. > > I think if you really want something like eduroam or companies to use > it, you might need to consider it. Not having MFP also limits you to 2.4 > and 5 GHz, since 6 GHz (though by WFA, not IEEE?) requires having WPA3 > with MFP. The MFP requirement for 6 GHz is in the IEEE 802.11ax-2021, as stated above. > > However, MFP really requires the PTK/TK, since (already today) important > things such as the BlockAck action frames are encrypted. You probably > don't want/can't push that to the backend, since it would need more than > one round-trip between backend/AP just to respond to the action frame... > I suppose in theory you could have a mode where you give the PTK/TK to > the AP but use it only for management frame SW decryption in mac80211 or > so, but then see above ... Hm, I don't think we would have gained much then if the PTK/TK were going back to the AP. Two more potential approaches I was trying to look up in 802.11-2020: A) Negotiating multiple sets of keys between the STA and AS through the Key ID. Which seems to have been specified for a fast transition to a new, fresh PTK. The key ID has two bits, so could in theory address 4 simultaneously installed keys. Currently only 0 and 1 are allowed though. Then we could send the PTK with one key ID to the AP to use for MFP. And the remote authenticator would use the other one for unicast payload. Though issues with that are probably: I'm not sure if an STA could then accidentally use / tricked into using the AP-PTK instead of the remote authenticator PTK for unicast payload frames. Also requires the Extended Key ID to be set to be able to use Key ID 1. Which is disabled by default in wpa_supplicant (and on many other supplicants / client devices?) => extended_key_id=0. Also requires hardware support on Linux, signalled by NL80211_EXT_FEATURE_EXT_KEY_ID. Only iwlwifi seems to set this right now on Linux? For the AP side we (maybe?) might be able to hack around this by using key ID 0 for MFP on the AP? But still we wouldn't be able to patch all supplicants... B) Abuse Nontransparent multi-band RSNA? This feature is new to me and I'm probably misunderstanding a lot about it :D. So likely it wouldn't work like this at all... But the general thought was: Could one create one auxilliary, overlapping channel, maybe if we operate on channel n with >=40MHz and BSSID X, use an overlapping channel n+4 @20Mhz, with another BSSID Y to enforce a nontransparent "multi-band" RSNA with a new, different set of keys? Could one then send a protected Block-Ack on channel n+4 with its key and with transmitter address Y "out-of-band" for X, by adding the optional "Multi-band" element to the Block-Ack with an "STA MAC Address" field set to X? And the receiver would interpret the protected Block-Ack as if it had received it on channel n, from X, except using the keys from channel n+4/Y? > > But let's say we limit this to WiFi6 (no 6E/6 GHz), and turn off MFP. > > So as for data frames ... > > > 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? > > Maybe? But some things get lost when you do that. Off the top of my > head, obviously performance features such as > - 802.3 conversion offload (ath*) > - wireless/ethernet bridge (mt*) > > Other than that, you'll not be able to use A-MSDU, since you'll need to > assume some latency between the AP and the backend, and encryption needs > to be done _after_ building A-MSDUs, but you want to be able to change > A-MSDU sizes quickly to react to changing link conditions. Agreed that A-MPDUs would make more sense in this tunneled over internet scenario. We don't have the Wifi ARQs between the AP and remote authenticator, there'd extra packet loss and it would be nice to not have to retransmit all frames that were lost in bulk in an A-MSDU. Might be nicer to TCP's congestion control, too. Also would allow to avoid IP fragmentation when also using things like ICMP/DHCP/radvd etc. to signal a lower MTU to hosts, to have one IP/L2TP packet per frame. With A-MSDUs we wouldn't be able to avoid IP fragmentation? - Or did you have something more fundamental in mind why A-MSDUs would not work at all, instead of "just" having performance issues? > > > With all that said, maybe whatever remains is even possible? I think you > could probably implement it mostly in userspace on the AP side, since we > drop frames we cannot decrypt to monitor: > > if (rx->key) { > ... > } else { > return RX_DROP_MONITOR; > } > > so you will see them on a cooked monitor interface that's added. Ah, that would be another way. Will need to think about / check what would be easier to start with, for a prototype. What I originally had in mind, was to add an explicit setting to cfg80211 and code to mac80211 which would then reencapsulate the CCMP data for instance in a small, custom ethernet frame header. To avoid userspace copying for the fast path for these payload frames. And then output that on the wlan0 device. And then bridge wlan0 with the according L2TP device (or a network device directly for a non-routed, layer 2 mode, without the dynamic destination retrieval for the local university/company setting, for less header overhead.) > > > Overall, also note that this locks you down into whatever wifi did a > while ago (WiFi6). Pretty much all features beyond that require MFP and > even if you ignore the "AP can access all traffic" part, you'll have > more and more things becoming encrypted for privacy and security > reasons, so the keys become more and more fundamental to the low-level > operation. Right, seems like it would need more lobbying/awareness at IEEE for these use-cases and the privacy/security improvements this could bring for payload data and network access. > > > Whew. I guess I'm pretty pessimistic about this. On the other hand I'm wondering if maybe that could be a good reason and motivation to work on this now, when it's still somehow prototypable. The longer one would wait, the more tricky and impossible it would become, it seems :D. > > johannes Regards, Linus _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
