OpenHarbors - Dynamic Tunneling of WPA over IP/L2TP

[Johannes Berg]

On Wed, 2024-06-19 at 16:53 +0200, Linus Lüssing wrote:
> 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?

Yeah I suppose so, I didn't quite have the right mental model at the
beginning here ... it might still be useful to be able to allow/deny
certain perhaps, but not what in the sense that I was thinking.

> > 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.

So let's start from that, and I'll roll in your description from below:

> 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.

Pretty much, yes. The PSK *is* the PMK in WPA 1/2 Personal, or may be
derived from the passphrase. For SAE (WPA 3) the PMK is created during
the SAE handshake.

So yeah, you have the right idea.

> 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.

Right. There can be multiple of each (pairwise/group rekeying) etc.

We get the terminology somewhat wrong in Linux, btw. The spec says:

   The PTK is partitioned into PTK-KCK, PTK-KEK, a temporal key, and a KDK.
   A KDK is derived if and only if any of the following are true: [...]

(12.7.1.3 Pairwise key hierarchy)

In Linux, we (mostly) use the term "PTK" as only the temporal key part
of the PTK.


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.

   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.
   
      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 at 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...

   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.


The most obvious concern with this would be management frame encryption
which uses the PTK (TK), IGTK, and also especially beacon protection
(BIGTK).

   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.

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 ...

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.


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.


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.


Whew. I guess I'm pretty pessimistic about this.

johannes