On Thu, 2024-07-04 at 15:02 +0200, Linus Lüssing wrote:
> 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.
Right.
> 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?
No, the EAP frames would be tunnelled in authentication frames, and then
the association request is encrypted as other management frames. You'd
also get the GTK/IGTK/BIGTK in it, instead of doing the 4-way-HS, IIRC.
> > 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?
Well, it's not _that_ low latency - I mean for ACK you're looking at
having *SIFS* time to respond (a few microseconds!), but assoc response
you'd have to respond within an implementation defined time - mac80211
currently uses at least 100ms so it's pretty long, but I'd normally say
you should have it within ~30ms.
My home internet to my server is ~20ms, but imagine I was travelling to
say Australia; pinging to Australia from here has an RTT of ~300ms, well
above any of the the association timeouts. And that's on an idle
connection. It'd probably not be much fun to use such a connection
anyway, but this is an extreme case.
> > 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.
Right. I just don't see that it's very much feasible with MFP, and MFP
is required starting from WiFi 6E, and it's not going away; if anything,
it's going to get _more_ important.
> 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?
Jammed, sure, but MFP also goes hand in hand with privacy to fight
tracking (same MAC address, or even with address randomization element
fingerprinting which is one thing 11bi is meant to address, etc.)
> 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).
To some extent it becomes void anyway because anyone can connect and
then has the GTK/IGTK/BIGTK.
> 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?
There are (often hardware) resources necessary for this, so yes? There's
also no _need_ since the PN space can be the same, just need a different
RX PN check for management frames.
GTK/IGTK/BIGTK are fundamentally different, though I agree that maybe
IGTK could have been used for beacon protection, though I think that
wouldn't work too well in practice because of how beacons are
transmitted at a fixed time etc., you'd be _required_ to implement that
completely in hardware (perhaps in conjunction with low-level firmware.)
> 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.
I believe you're referring to "extended key ID" and pretty much nobody
implements that. We have some (minimal) support in the stack for it on
Linux but I'm not sure any driver (other than the ones just using
software crypto) has it.
> 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.
Not sure what you mean, but any code that even implements extended key
ID support will always use the same key for TX, never split that between
key IDs for management and data. And being able to split on TX would be
another non-standard extension (on RX it's expected, but not on TX) that
even fewer implementations would support.
> 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...
I'm surprised iwlwifi even sets that ... oops, not sure we should.
> 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?
I have no idea what you're talking about, but I guess nobody implements
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?
If you build a large A-MSDU, say close to 12k and then your link rate
goes down (e.g. because the person moved away from the AP), you might
not be able to transmit it at all due to duration constraints (without
rebuilding the A-MSDU). This means you can't react to changing link
conditions without going to the backend and requesting a rebuild of the
data frame or losing the whole thing.
> > 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.
Sure, but that's an optimisation, don't need that for a PoC.
> > 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.
Well, I don't think a *PoC* will become significantly more tricky over
time, given that we'll still support WiFi6 and below for basically ever?
I don't think this changes much for a PoC, and you could always use old
hardware too; people still use ath9k for some things :)
The thing I'm pessimistic about is making this a long-lived project and
product rather than a PoC.
johannes
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
