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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
