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").
> 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.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
