[PATCH 09/13] SME: Accept authentication frame from an MLD AP

[Jouni Malinen]

On Mon, Nov 28, 2022 at 04:50:15PM +0000, Otcheretianski, Andrei wrote:
> > > The underline driver is expected to translate the link addresses to
> > > MLD addresses when processing an authentication frame from a MLD AP.
> > > Thus, accept authentication frame when the peer matches the expected
> > > MLD address.

> > Where is that behavior defined? Is this design here implying that the
> > Authentication are send to/from userspace with different header address
> > field values that are used in the actual frame over air?
> 
> This is the current mac80211's behavior. We had several conversations with Johannes about all the addressing stuff - though I don't think it is clearly documented anywhere.
> Indeed the addressing over the air is different from the frame header.
> Here is the mac80211 patch that does the translation on rx, for example:
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?id=42fb9148c078004d07b4c39bd7b1086b6165780c

This assumes that encryption/decryption is always based on the MLD
addresses.. One might hope that to be the case, but it is not that clear
yet, so unless P802.11be gets extended to make this obvious, there is
some risk in this design.

> > Which component is
> > enforcing the authentication, association, and initial EAPOL-Key 4-way
> > handshake to be using the same link?
> 
> Prior to 4-way handshake completion there's only one active link, so there are no other options.
> Both for auth and assoc commands there's link_id parameters, to select a specific link for authentication/association.
> wpa_supplicant ensures that the same link_id is used for auth and assoc.
> For control port tx, it is possible to add link id as well, though it's not needed for station mode, as the drivers shouldn't enable any other link prior authorization.

There may be need to verify that EAPOL-Key msg 1/4 and 3/4 are exchanged
on the same channel/link, so it would be good to have that available for
the rekeying cases for both AP and STA sides.

> > What happens with association frames? Does this have any impact on how
> > the protection for those, e.g., with FILS, works since that needs to use the
> > actual link addresses for deriving KeyAuth? What if something similar would
> > be needed in Authentication frames?
> 
> I'm not familiar with FILS enough and we didn't try to enable it with MLD.
> I tried to look up in the ieee802.11be/D.2.2, and I don't see any changes with respect to FILS. For example 12.11.2.6.3 (in REVme) should be updated at least to include per link MLO GTK etc.
> Maybe the addressing for FILS should be updated in the spec as well?
> In any case nl80211 reports link_id for the received mgmt. frames, so link addresses should be known to wpa_supplicant, if needed.

FILS encodes STA-MAC and AP-BSSID into Key-Auth derivation. I'd guess
this would be modified to use MLD addresses in P802.11be. In addition to
that, FILS encrypts parts of the Association Request/Response frames and
AAD for that includes the BSSID/STA Mac address which would map to link
addresses and might or might not be mapped to MLD addresses since this
case a bit special (only the association step and verifying that the
addresses used to transmit the frame were correct). It would probably be
fine to use MLD addresses in FILS AAD case as well, but clearly that has
not yet been done in P802.11be (which seems to point towards no one
having really thought much about FILS in this context so far).

If the link addresses used for Authentication and (Re)Association
Request/Response frames is made available to use space somehow in RX
path, that should be sufficient for most of these needs. The main
exception to that would be the very first Authentication frame, so there
is some risk for corner cases or unknown/future definitions of
Authentication frame use. This may be acceptable, but the constraint and
expected use of addresses in nl80211 commands for MLO should be clearly
spelled out in nl80211.h.

-- 
Jouni Malinen                                            PGP id EFC895FA