> On Mon, Nov 28, 2022 at 05:29:24PM +0000, Otcheretianski, Andrei wrote:
> > > > + /* TODO: Support for other auth_type as well */
> > > > + if (data->auth.auth_type == WLAN_AUTH_OPEN)
> > > > + wpas_sme_ml_auth(wpa_s, data);
> > >
> > > This sounds quite problematic since IEEE P802.11be/D2.2 seems to
> > > imply that MLO require RSN to be used and that would most likely
> > > mean SAE for cases that do not use EAP or OWE.
> > >
> > WLAN_AUTH_OPEN holds for OWE as well. This "if" statement is needed to
> > prevent going into wpas_sme_ml_auth() for other auth types as it
> > doesn't know to properly skip over all the fixed parts in auth frame
> > body (for SAE for example), as defined in table 9-68 (in REVme_D1.3).
> > We have a patch that adds support for SAE, I didn't send it out
> > meanwhile as it conflicts with the PMKSA patch from Veerendranath series.
>
> It would be good to start looking at the details for SAE as well, since that really is
> the most likely item for using MLO. It is fine if there are two conflicting patches
> and it may indeed be that having those reviewed in parallel is the most efficient
> way of figuring out which approach is better for meeting the needs for various
> cases. As an example, the question on the MLD vs. link addresses in auth/assoc
> commands/events is quite relevant to the question on how to address connect
> command and SAE-offload-to-userspace ("external auth").
I cleaned up our SAE patch and will send it soon, though it doesn't cover external auth.
>
> > In any case I don't see where D2.2 states that open is not allowed.
> > See for example, 11.3.5.3:
> > " If Open System or Shared Key authentication algorithm is being used,
> > the STA or the *MLD* shall execute the procedure described in 12.3.3.2
> (Open System authentication) [...]"
>
> It is far from obvious, but there is implied language talking about beacon
> protection being mandatory and how that has been interpreted and used in
> various offline discussion. There is no clear conclusion on this yet, but for the
> time being, I've been avoiding changes that enable use of unencrypted open
> with MLO. Obviously, I can change this once there is clear consensus on the
> standards development side on how this should go, but before that happens, I'd
> rather avoid promoting something that might not be allowed in the end to limit
> risk of early deployments doing something that will result in inconvenient
> interop issues or needs for ugly workarounds in the future.
>
> > > What is the set of key management options this patch set is expected
> > > to support? I'd like to start with SAE and OWE and not allow OPEN to
> > > match the P802.11be expectations.
> >
> > We tested it internally with open, psk and owe.
> > I'll send our SAE patch as well in the next series.
>
> Thanks. By the way, PSK would be another one of those cases that there is some
> desire to not allow with MLO.. In general, following the constraints agreed for 6
> GHz might be promoted for MLO cases as well.
I will add additional checks in wpa_supplicant_ssid_bss_match() for that.
Thanks,
Andrei
>
> --
> Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
