OpenHarbors - Dynamic Tunneling of WPA over IP/L2TP

[Linus Lüssing]

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

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