AW: [PATCH] Handling RSN Overriding for MLO connection

[Roman Stolz]

I understand the idea behind this. But with RSNO an AP administrator or developer has the freedom to design the RSN(O)Es rather free to handle know interop issues. So it's possible to set the RSNOE#1 without settings RSNOE#2. (Indeed, we do so, because of an interop issue with some clients)
With a robust, while simple, rule on the client side, which goes from RSNO#2 to RSNO#1 to RSN, this won't be a problem. But making this a special case, perhaps it creates a new issue.

So, the WPA3 Specification is not clear at this point and just for robustness, I would suggest to always follow the simple rule.

Regards,
Roman Stolz

-----Ursprüngliche Nachricht-----
Von: Jouni Malinen <j at w1.fi> 
Gesendet: Montag, 23. März 2026 16:17
An: Roman Stolz <r.stolz at fritz.com>
Cc: hostap at lists.infradead.org
Betreff: Re: [PATCH] Handling RSN Overriding for MLO connection

⚠️ This email originated from outside of the organization ⚠️ Do not click links or open attachments unless you recognize the sender or know the content is safe.

On Mon, Mar 23, 2026 at 11:27:41AM +0000, Roman Stolz wrote:
> Just by review I found a RSNO issue which does not comply with the WPA3 Specification 3.5. By my understanding.
> Rem.: I have no test devices to check this in real.
>
> In detail:
> According to WPA3 v3.5, chapter 14.2. a station, which will establish a multi-link connection, should observe the RSNOE#2 element for the security settings. In case it's not defined, there is no explicit behaviour defined how to proceed with processing the RSN(O)E. This means, from my understanding, the default behaviour should apply. First RSNO#2, second RSNO#1 and least RSNE. This is not reflected by the code. There is an immediate fallback from RSNO#2 to the RSNE.

That is by design. Wi-Fi 7 associations shall use the RSNO2E for RSN overriding and there is no fallback to the RSNOE. In theory, it would be possible to fall back to RSNOE by disabling EHT/MLO functionality, but that should not really be needed in practice with properly configured APs.

--
Jouni Malinen                                            PGP id EFC895FA