Failed to connect to WPA3 network after update to iwd 1.16

Failed to connect to WPA3 network after update to iwd 1.16

[Alex Cepoi]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

Hi everyone,

I'm having trouble connecting to a WPA3 network after updating from 1.15 to
1.16. Can reproduce consistently (100% success rate on 1.15, 0% success
rate on 1.16).

You can see debug logs before and after in
https://gist.github.com/alexcepoi/eef301a56e5e40826a8a416cbfb684e6

Diff shows some new "SAE Hunting and Pecking" algorithm used and a "AP did
not include group number in response!" info, though not sure if related.

I'm using a Google Nest Wifi router if that helps. I'm on Gentoo Linux (
https://packages.gentoo.org/packages/net-wireless/iwd).

Any ideas?

Thanks,
Alex.

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 838 bytes --]

Re: Failed to connect to WPA3 network after update to iwd 1.16

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

Hi Alex,

> Diff shows some new "SAE Hunting and Pecking" algorithm used and a "AP did not 
> include group number in response!" info, though not sure if related.

It is.  Looks like the Nest advertises SAE H2E support and we try to use that 
but something goes wrong.  Can you capture a log with iwmon?

https://iwd.wiki.kernel.org/debugging

Regards,
-Denis

Re: Failed to connect to WPA3 network after update to iwd 1.16

[Alex Cepoi]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

Sure thing:
https://gist.github.com/alexcepoi/83511b1c128767722ec8d6b50d1f66a7

Does that help?

On Sun, 22 Aug 2021 at 19:36, Denis Kenzior <denkenz@gmail.com> wrote:

> Hi Alex,
>
> > Diff shows some new "SAE Hunting and Pecking" algorithm used and a "AP
> did not
> > include group number in response!" info, though not sure if related.
>
> It is.  Looks like the Nest advertises SAE H2E support and we try to use
> that
> but something goes wrong.  Can you capture a log with iwmon?
>
> https://iwd.wiki.kernel.org/debugging
>
> Regards,
> -Denis
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 1072 bytes --]

Re: Failed to connect to WPA3 network after update to iwd 1.16

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

Hi Alex,

On 8/22/21 6:17 PM, Alex Cepoi wrote:
> Sure thing: https://gist.github.com/alexcepoi/83511b1c128767722ec8d6b50d1f66a7 
> <https://gist.github.com/alexcepoi/83511b1c128767722ec8d6b50d1f66a7>
> 
> Does that help?
> 

I don't see H2E being attempted in this log?  I'm curious how you got the log in 
your first message on this topic?

Does iwd 1.15 still manage to connect?  Is there a firmware upgrade for the Nest 
that you can try?

Regards,
-Denis

Re: Failed to connect to WPA3 network after update to iwd 1.16

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]

Hi Alex,

> I don't see H2E being attempted in this log?  I'm curious how you got the log in 
> your first message on this topic?

Actually, nevermind.  It was pointed out to me I'm seeing ghosts here.

We'll try to give you a workaround patch to test soon.

Regards,
-Denis

Re: Failed to connect to WPA3 network after update to iwd 1.16

[James Prestwood]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

Hi Alex,

On Sun, 2021-08-22 at 04:47 +0100, Alex Cepoi wrote:
> Hi everyone,
> 
> I'm having trouble connecting to a WPA3 network after updating from
> 1.15 to 1.16. Can reproduce consistently (100% success rate on 1.15,
> 0% success rate on 1.16).
> 
> You can see debug logs before and after in
> https://gist.github.com/alexcepoi/eef301a56e5e40826a8a416cbfb684e6
> 
> Diff shows some new "SAE Hunting and Pecking" algorithm used and a
> "AP did not include group number in response!" info, though not sure
> if related.
> 
> I'm using a Google Nest Wifi router if that helps. I'm on Gentoo
> Linux (https://packages.gentoo.org/packages/net-wireless/iwd).

Does the router have any logging by chance? Generally consumer devices
don't give you much but worth a shot.

Thanks,
James


[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 1229 bytes --]

Re: Failed to connect to WPA3 network after update to iwd 1.16

[Alex Cepoi]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

Router firmware should automatically update, but I can’t manually check for
updates.

I can confirm the current model and software version:
Model: H2D
Software version: 13729.57.19

Nothing in the way of logs though.

iwd 1.15 works totally fine for now.

Thanks for looking into it.
Alex

On Mon, 23 Aug 2021 at 18:21, James Prestwood <prestwoj@gmail.com> wrote:

> Hi Alex,
>
> On Sun, 2021-08-22 at 04:47 +0100, Alex Cepoi wrote:
>
> Hi everyone,
>
> I'm having trouble connecting to a WPA3 network after updating from 1.15
> to 1.16. Can reproduce consistently (100% success rate on 1.15, 0% success
> rate on 1.16).
>
> You can see debug logs before and after in
> https://gist.github.com/alexcepoi/eef301a56e5e40826a8a416cbfb684e6
>
> Diff shows some new "SAE Hunting and Pecking" algorithm used and a "AP did
> not include group number in response!" info, though not sure if related.
>
> I'm using a Google Nest Wifi router if that helps. I'm on Gentoo Linux (
> https://packages.gentoo.org/packages/net-wireless/iwd).
>
>
> Does the router have any logging by chance? Generally consumer devices
> don't give you much but worth a shot.
>
> Thanks,
> James
>
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 2303 bytes --]

Re: Failed to connect to WPA3 network after update to iwd 1.16

[James Prestwood]

[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]

Hi Alex,

> 
> On Mon, 23 Aug 2021 at 18:21, James Prestwood <prestwoj@gmail.com>
> wrote:
> > Hi Alex,
> > 
> > On Sun, 2021-08-22 at 04:47 +0100, Alex Cepoi wrote:
> > > Hi everyone,
> > > 
> > > I'm having trouble connecting to a WPA3 network after updating
> > > from 1.15 to 1.16. Can reproduce consistently (100% success rate
> > > on 1.15, 0% success rate on 1.16).
> > > 
> > > You can see debug logs before and after in
> > >
> > https://gist.github.com/alexcepoi/eef301a56e5e40826a8a416cbfb684e6
> > > 
> > > Diff shows some new "SAE Hunting and Pecking" algorithm used and
> > > a "AP did not include group number in response!" info, though not
> > > sure if related.

In your case the effective difference between IWD 1.16 and 1.15 is that
we now try SAE groups in decending order. This is because higher group
numbers are more secure. BUT the only group that is required for a
device to support is group 19, which it seems your AP falls under. So
we have this situation where we try group 20, fail, then try 19, but
something else goes wrong.

We don't think IWD is behaving out of what the spec requries in this
situation (and we even test for this rejected group scenario) but there
are several red flag commits in hostapd from 2018/2019 which describe
fixing some behavior that sounds similar to this. Its difficult to know
because we don't have your AP's hostapd or kernel version to try out
ourselves.

tl;dr

We think we can 'fix' this by simply using group 19 by default (or a
config option) but thats not optimal since you really want to use the
most secure group if it is available. What we can do to verify that
your AP is to blame is try wpa_supplicant and include this option:

sae_groups=20 19

This *should* try group 20 first and behave similarly to IWD. If this
also results in the same issue we know the AP is to blame. Knowing this
will at least give us some justification for adding a config option as
a fix.

Thanks,
James


[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 2806 bytes --]

Re: Failed to connect to WPA3 network after update to iwd 1.16

[Alex Cepoi]

[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]

Hey James,

Your theory seems to be correct. Adding "sae_groups=20 19" seems to make
authentication fail.
Here's what I tried:
https://gist.github.com/alexcepoi/71f1b1fb579b26e0abaa5b7f818923be

Alex.

On Mon, 23 Aug 2021 at 21:03, James Prestwood <prestwoj@gmail.com> wrote:

> Hi Alex,
>
>
> On Mon, 23 Aug 2021 at 18:21, James Prestwood <prestwoj@gmail.com> wrote:
>
> Hi Alex,
>
> On Sun, 2021-08-22 at 04:47 +0100, Alex Cepoi wrote:
>
> Hi everyone,
>
> I'm having trouble connecting to a WPA3 network after updating from 1.15
> to 1.16. Can reproduce consistently (100% success rate on 1.15, 0% success
> rate on 1.16).
>
> You can see debug logs before and after in
> https://gist.github.com/alexcepoi/eef301a56e5e40826a8a416cbfb684e6
>
> Diff shows some new "SAE Hunting and Pecking" algorithm used and a "AP did
> not include group number in response!" info, though not sure if related.
>
>
> In your case the effective difference between IWD 1.16 and 1.15 is that we
> now try SAE groups in decending order. This is because higher group numbers
> are more secure. BUT the only group that is required for a device to
> support is group 19, which it seems your AP falls under. So we have this
> situation where we try group 20, fail, then try 19, but something else goes
> wrong.
>
> We don't think IWD is behaving out of what the spec requries in this
> situation (and we even test for this rejected group scenario) but there are
> several red flag commits in hostapd from 2018/2019 which describe fixing
> some behavior that sounds similar to this. Its difficult to know because we
> don't have your AP's hostapd or kernel version to try out ourselves.
>
> tl;dr
>
> We think we can 'fix' this by simply using group 19 by default (or a
> config option) but thats not optimal since you really want to use the most
> secure group if it is available. What we can do to verify that your AP is
> to blame is try wpa_supplicant and include this option:
>
> sae_groups=20 19
>
> This *should* try group 20 first and behave similarly to IWD. If this also
> results in the same issue we know the AP is to blame. Knowing this will at
> least give us some justification for adding a config option as a fix.
>
> Thanks,
> James
>
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 3607 bytes --]

Re: Failed to connect to WPA3 network after update to iwd 1.16

[James Prestwood]

[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]

Hi Alex,

On Mon, 2021-08-23 at 22:30 +0100, Alex Cepoi wrote:
> Hey James,
> 
> Your theory seems to be correct. Adding "sae_groups=20 19" seems to
> make authentication fail.
> Here's what I
> tried: 
> https://gist.github.com/alexcepoi/71f1b1fb579b26e0abaa5b7f818923be
> 
> Alex.

Thanks for verifying this. Looks like it is something we will have to
work around in IWD.

> 
> On Mon, 23 Aug 2021 at 21:03, James Prestwood <prestwoj@gmail.com>
> wrote:
> > Hi Alex,
> > 
> > > 
> > > On Mon, 23 Aug 2021 at 18:21, James Prestwood
> > > <prestwoj@gmail.com> wrote:
> > > > Hi Alex,
> > > > 
> > > > On Sun, 2021-08-22 at 04:47 +0100, Alex Cepoi wrote:
> > > > > Hi everyone,
> > > > > 
> > > > > I'm having trouble connecting to a WPA3 network after
> > > > > updating from 1.15 to 1.16. Can reproduce consistently (100%
> > > > > success rate on 1.15, 0% success rate on 1.16).
> > > > > 
> > > > > You can see debug logs before and after in
> > > > >
> > > >
> > >
> > https://gist.github.com/alexcepoi/eef301a56e5e40826a8a416cbfb684e6
> > > > > 
> > > > > Diff shows some new "SAE Hunting and Pecking" algorithm used
> > > > > and a "AP did not include group number in response!" info,
> > > > > though not sure if related.
> > 
> > 
> > In your case the effective difference between IWD 1.16 and 1.15 is
> > that we now try SAE groups in decending order. This is because
> > higher group numbers are more secure. BUT the only group that is
> > required for a device to support is group 19, which it seems your
> > AP falls under. So we have this situation where we try group 20,
> > fail, then try 19, but something else goes wrong.
> > 
> > We don't think IWD is behaving out of what the spec requries in
> > this situation (and we even test for this rejected group scenario)
> > but there are several red flag commits in hostapd from 2018/2019
> > which describe fixing some behavior that sounds similar to this.
> > Its difficult to know because we don't have your AP's hostapd or
> > kernel version to try out ourselves.
> > 
> > tl;dr
> > 
> > We think we can 'fix' this by simply using group 19 by default (or
> > a config option) but thats not optimal since you really want to use
> > the most secure group if it is available. What we can do to verify
> > that your AP is to blame is try wpa_supplicant and include this
> > option:
> > 
> > sae_groups=20 19
> > 
> > This *should* try group 20 first and behave similarly to IWD. If
> > this also results in the same issue we know the AP is to blame.
> > Knowing this will at least give us some justification for adding a
> > config option as a fix.
> > 
> > Thanks,
> > James
> > 


[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 4022 bytes --]

Re: Failed to connect to WPA3 network after update to iwd 1.16

[James Prestwood]

[-- Attachment #1: Type: text/plain, Size: 2756 bytes --]

Hi Alex,

There are 4 patches on the mailing list which hopefully fix this for
you. I've also attached them as well.

Thanks,
James

On Mon, 2021-08-23 at 22:30 +0100, Alex Cepoi wrote:
> Hey James,
> 
> Your theory seems to be correct. Adding "sae_groups=20 19" seems to
> make authentication fail.
> Here's what I
> tried: 
> https://gist.github.com/alexcepoi/71f1b1fb579b26e0abaa5b7f818923be
> 
> Alex.
> 
> On Mon, 23 Aug 2021 at 21:03, James Prestwood <prestwoj@gmail.com>
> wrote:
> > Hi Alex,
> > 
> > > 
> > > On Mon, 23 Aug 2021 at 18:21, James Prestwood
> > > <prestwoj@gmail.com> wrote:
> > > > Hi Alex,
> > > > 
> > > > On Sun, 2021-08-22 at 04:47 +0100, Alex Cepoi wrote:
> > > > > Hi everyone,
> > > > > 
> > > > > I'm having trouble connecting to a WPA3 network after
> > > > > updating from 1.15 to 1.16. Can reproduce consistently (100%
> > > > > success rate on 1.15, 0% success rate on 1.16).
> > > > > 
> > > > > You can see debug logs before and after in
> > > > >
> > > >
> > >
> > https://gist.github.com/alexcepoi/eef301a56e5e40826a8a416cbfb684e6
> > > > > 
> > > > > Diff shows some new "SAE Hunting and Pecking" algorithm used
> > > > > and a "AP did not include group number in response!" info,
> > > > > though not sure if related.
> > 
> > 
> > In your case the effective difference between IWD 1.16 and 1.15 is
> > that we now try SAE groups in decending order. This is because
> > higher group numbers are more secure. BUT the only group that is
> > required for a device to support is group 19, which it seems your
> > AP falls under. So we have this situation where we try group 20,
> > fail, then try 19, but something else goes wrong.
> > 
> > We don't think IWD is behaving out of what the spec requries in
> > this situation (and we even test for this rejected group scenario)
> > but there are several red flag commits in hostapd from 2018/2019
> > which describe fixing some behavior that sounds similar to this.
> > Its difficult to know because we don't have your AP's hostapd or
> > kernel version to try out ourselves.
> > 
> > tl;dr
> > 
> > We think we can 'fix' this by simply using group 19 by default (or
> > a config option) but thats not optimal since you really want to use
> > the most secure group if it is available. What we can do to verify
> > that your AP is to blame is try wpa_supplicant and include this
> > option:
> > 
> > sae_groups=20 19
> > 
> > This *should* try group 20 first and behave similarly to IWD. If
> > this also results in the same issue we know the AP is to blame.
> > Knowing this will at least give us some justification for adding a
> > config option as a fix.
> > 
> > Thanks,
> > James
> > 


[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 3962 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0004-unit-update-test-sae-with-API-change.patch --]
[-- Type: text/x-patch, Size: 2793 bytes --]

From c122a99fbc946faa5ee3a26caa2d1966f9b7c2a1 Mon Sep 17 00:00:00 2001
From: James Prestwood <prestwoj@gmail.com>
Date: Mon, 23 Aug 2021 16:23:29 -0700
Subject: [PATCH 4/4] unit: update test-sae with API change

---
 Makefile.am     |  3 ++-
 unit/test-sae.c | 14 +++++++-------
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e6d2fc91..8b0df2aa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -521,7 +521,8 @@ unit_test_sae_SOURCES = unit/test-sae.c \
 				src/handshake.h src/handshake.c \
 				src/erp.h src/erp.c \
 				src/util.h src/util.c \
-				src/mpdu.h src/mpdu.c
+				src/mpdu.h src/mpdu.c \
+				src/scan.h
 unit_test_sae_LDADD = $(ell_ldadd)
 unit_test_sae_LDFLAGS = -Wl,-wrap,l_ecc_supported_ike_groups
 
diff --git a/unit/test-sae.c b/unit/test-sae.c
index d9ec6b31..00819eb2 100644
--- a/unit/test-sae.c
+++ b/unit/test-sae.c
@@ -171,7 +171,7 @@ static struct auth_proto *test_initialize(struct test_data *td)
 
 	memset(td->test_clogging_token, 0xde, 32);
 
-	ap = sae_sm_new(hs, test_tx_auth_func, test_tx_assoc_func, td);
+	ap = sae_sm_new(hs, NULL, test_tx_auth_func, test_tx_assoc_func, td);
 
 	td->commit_success = false;
 	auth_proto_start(ap);
@@ -423,8 +423,8 @@ static void test_bad_confirm(const void *arg)
 	handshake_state_set_passphrase(hs2, passphrase);
 	handshake_state_set_authenticator(hs2, true);
 
-	ap1 = sae_sm_new(hs1, end_to_end_tx_func, test_tx_assoc_func, td1);
-	ap2 = sae_sm_new(hs2, end_to_end_tx_func, test_tx_assoc_func, td2);
+	ap1 = sae_sm_new(hs1, NULL, end_to_end_tx_func, test_tx_assoc_func, td1);
+	ap2 = sae_sm_new(hs2, NULL, end_to_end_tx_func, test_tx_assoc_func, td2);
 
 	/* both peers send out commit */
 	ap1->start(ap1);
@@ -498,8 +498,8 @@ static void test_confirm_after_accept(const void *arg)
 	handshake_state_set_passphrase(hs2, passphrase);
 	handshake_state_set_authenticator(hs2, true);
 
-	ap1 = sae_sm_new(hs1, end_to_end_tx_func, test_tx_assoc_func, td1);
-	ap2 = sae_sm_new(hs2, end_to_end_tx_func, test_tx_assoc_func, td2);
+	ap1 = sae_sm_new(hs1, NULL, end_to_end_tx_func, test_tx_assoc_func, td1);
+	ap2 = sae_sm_new(hs2, NULL, end_to_end_tx_func, test_tx_assoc_func, td2);
 
 	/* both peers send out commit */
 	auth_proto_start(ap1);
@@ -583,8 +583,8 @@ static void test_end_to_end(const void *arg)
 	handshake_state_set_passphrase(hs2, passphrase);
 	handshake_state_set_authenticator(hs2, true);
 
-	ap1 = sae_sm_new(hs1, end_to_end_tx_func, test_tx_assoc_func, td1);
-	ap2 = sae_sm_new(hs2, end_to_end_tx_func, test_tx_assoc_func, td2);
+	ap1 = sae_sm_new(hs1, NULL, end_to_end_tx_func, test_tx_assoc_func, td1);
+	ap2 = sae_sm_new(hs2, NULL, end_to_end_tx_func, test_tx_assoc_func, td2);
 
 	/* both peers send out commit */
 	auth_proto_start(ap1);
-- 
2.31.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-sae-handle-force_default_sae_group-in-scan_bss.patch --]
[-- Type: text/x-patch, Size: 3887 bytes --]

From 24eff8edac829439eb4fbaf283b91f93cd673e1c Mon Sep 17 00:00:00 2001
From: James Prestwood <prestwoj@gmail.com>
Date: Mon, 23 Aug 2021 16:19:17 -0700
Subject: [PATCH 3/4] sae: handle force_default_sae_group in scan_bss

Now a scan_bss object is passed to sae_sm_new in order to detect if
the BSS's vendor OUI matches ones in which SAE group negotiation is
broken. When an AP like this is found SAE will use group 19
unconditionally, and fail if group 19 does not work. Other groups
could be tried upon failure but per the spec group 19 must be supported
so there isn't much use in trying other, optional groups.

Note: the check on 'bss' was added in order to make unit testing
easier to integrate as including scan.c in unit tests opens up a
can of worms.
---
 src/netdev.c |  2 +-
 src/sae.c    | 27 +++++++++++++++++++++++++++
 src/sae.h    |  2 ++
 3 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/src/netdev.c b/src/netdev.c
index d886efad..87b9c3f0 100644
--- a/src/netdev.c
+++ b/src/netdev.c
@@ -3470,7 +3470,7 @@ static void netdev_connect_common(struct netdev *netdev,
 	switch (hs->akm_suite) {
 	case IE_RSN_AKM_SUITE_SAE_SHA256:
 	case IE_RSN_AKM_SUITE_FT_OVER_SAE_SHA256:
-		netdev->ap = sae_sm_new(hs, netdev_sae_tx_authenticate,
+		netdev->ap = sae_sm_new(hs, bss, netdev_sae_tx_authenticate,
 						netdev_sae_tx_associate,
 						netdev);
 
diff --git a/src/sae.c b/src/sae.c
index 5099473c..5b2c74fc 100644
--- a/src/sae.c
+++ b/src/sae.c
@@ -34,6 +34,7 @@
 #include "src/mpdu.h"
 #include "src/auth-proto.h"
 #include "src/sae.h"
+#include "src/scan.h"
 
 /* SHA-512 is the highest supported hashing function as of 802.11-2020 */
 #define SAE_MAX_HASH_LEN 64
@@ -83,6 +84,8 @@ struct sae_sm {
 	sae_tx_associate_func_t tx_assoc;
 	void *user_data;
 	enum crypto_sae sae_type;
+
+	bool force_default_group : 1;
 };
 
 static enum mmpdu_status_code sae_status_code(struct sae_sm *sm)
@@ -139,6 +142,24 @@ static int sae_choose_next_group(struct sae_sm *sm)
 	const unsigned int *ecc_groups = l_ecc_supported_ike_groups();
 	bool reset = sm->group_retry >= 0;
 
+	/*
+	 * If this is a buggy AP in which group negotiation is broken use the
+	 * default group 19 and fail if this is a retry.
+	 */
+	if (sm->sae_type == CRYPTO_SAE_LOOPING && sm->force_default_group) {
+		if (sm->group_retry != -1) {
+			l_warn("Forced default group but was rejected!");
+			return -ENOENT;
+		}
+
+		l_debug("Forcing default SAE group 19");
+
+		sm->group_retry++;
+		sm->group = 19;
+
+		goto get_curve;
+	}
+
 	do {
 		sm->group_retry++;
 
@@ -151,6 +172,8 @@ static int sae_choose_next_group(struct sae_sm *sm)
 		sae_reset_state(sm);
 
 	sm->group = ecc_groups[sm->group_retry];
+
+get_curve:
 	sm->curve = l_ecc_curve_from_ike_group(sm->group);
 
 	return 0;
@@ -1317,6 +1340,7 @@ static void sae_free(struct auth_proto *ap)
 }
 
 struct auth_proto *sae_sm_new(struct handshake_state *hs,
+				struct scan_bss *bss,
 				sae_tx_authenticate_func_t tx_auth,
 				sae_tx_associate_func_t tx_assoc,
 				void *user_data)
@@ -1351,5 +1375,8 @@ struct auth_proto *sae_sm_new(struct handshake_state *hs,
 		sm->sae_type = CRYPTO_SAE_LOOPING;
 	}
 
+	if (bss && bss->force_default_sae_group)
+		sm->force_default_group = true;
+
 	return &sm->ap;
 }
diff --git a/src/sae.h b/src/sae.h
index 668d084f..d8f9f2d7 100644
--- a/src/sae.h
+++ b/src/sae.h
@@ -23,6 +23,7 @@
 struct auth_proto;
 struct sae_sm;
 struct handshake_state;
+struct scan_bss;
 
 typedef void (*sae_tx_authenticate_func_t)(const uint8_t *data, size_t len,
 						void *user_data);
@@ -31,6 +32,7 @@ typedef void (*sae_tx_associate_func_t)(void *user_data);
 bool sae_sm_is_h2e(struct auth_proto *ap);
 
 struct auth_proto *sae_sm_new(struct handshake_state *hs,
+				struct scan_bss *bss,
 				sae_tx_authenticate_func_t tx_auth,
 				sae_tx_associate_func_t tx_assoc,
 				void *user_data);
-- 
2.31.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0002-scan-set-force_default_sae_group-if-OUI-matches.patch --]
[-- Type: text/x-patch, Size: 1003 bytes --]

From bee488088cef46f40cbf34073f45f29d04946687 Mon Sep 17 00:00:00 2001
From: James Prestwood <prestwoj@gmail.com>
Date: Mon, 23 Aug 2021 16:16:06 -0700
Subject: [PATCH 2/4] scan: set force_default_sae_group if OUI matches

---
 src/scan.c | 4 +++-
 src/scan.h | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/scan.c b/src/scan.c
index 3faa6eb4..16bd2a87 100644
--- a/src/scan.c
+++ b/src/scan.c
@@ -924,7 +924,9 @@ static bool scan_parse_vendor_specific(struct scan_bss *bss, const void *data,
 			return false;
 
 		bss->hs20_capable = true;
-	} else
+	} else if (is_ie_default_sae_group_oui(data, len))
+		bss->force_default_sae_group = true;
+	else
 		return false;
 
 	return true;
diff --git a/src/scan.h b/src/scan.h
index 81c84bae..8a57c2b3 100644
--- a/src/scan.h
+++ b/src/scan.h
@@ -83,6 +83,7 @@ struct scan_bss {
 	bool vht_capable : 1;
 	bool anqp_capable : 1;
 	bool hs20_capable : 1;
+	bool force_default_sae_group : 1;
 };
 
 struct scan_parameters {
-- 
2.31.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: 0001-ie-add-is_ie_default_sae_group_oui.patch --]
[-- Type: text/x-patch, Size: 1693 bytes --]

From 000a210230e3288ee21a3cd98991240df3176a35 Mon Sep 17 00:00:00 2001
From: James Prestwood <prestwoj@gmail.com>
Date: Mon, 23 Aug 2021 16:30:45 -0700
Subject: [PATCH 1/4] ie: add is_ie_default_sae_group_oui

Start an OUI list of vendors who have buggy SAE group negotiation
---
 src/ie.c | 25 +++++++++++++++++++++++++
 src/ie.h |  2 ++
 2 files changed, 27 insertions(+)

diff --git a/src/ie.c b/src/ie.c
index a73d5bbc..3bf3b5f0 100644
--- a/src/ie.c
+++ b/src/ie.c
@@ -1363,6 +1363,31 @@ bool is_ie_wpa_ie(const uint8_t *data, uint8_t len)
 	return false;
 }
 
+/*
+ * List of vendor OUIs which require the default SAE group to be used
+ */
+static uint8_t use_default_sae_group_ouis[][3] = {
+	{ 0xf4, 0xf5, 0xe8 },
+};
+
+bool is_ie_default_sae_group_oui(const void *data, uint16_t len)
+{
+	unsigned int i = 0;
+
+	if (len < 3)
+		return false;
+
+	while (i < L_ARRAY_SIZE(use_default_sae_group_ouis)) {
+		if (!memcmp(use_default_sae_group_ouis[i], data, 3))
+			return true;
+
+		i++;
+	}
+
+	return false;
+}
+
+
 int ie_parse_wpa(struct ie_tlv_iter *iter, struct ie_rsn_info *out_info)
 {
 	const uint8_t *data = iter->data;
diff --git a/src/ie.h b/src/ie.h
index 25b56302..7c4f987d 100644
--- a/src/ie.h
+++ b/src/ie.h
@@ -524,6 +524,8 @@ int ie_parse_wpa_from_data(const uint8_t *data, size_t len,
 						struct ie_rsn_info *info);
 bool is_ie_wfa_ie(const uint8_t *data, uint8_t len, uint8_t oi_type);
 bool is_ie_wpa_ie(const uint8_t *data, uint8_t len);
+bool is_ie_default_sae_group_oui(const void *data, uint16_t len);
+
 bool ie_build_wpa(const struct ie_rsn_info *info, uint8_t *to);
 
 int ie_parse_bss_load(struct ie_tlv_iter *iter, uint16_t *out_sta_count,
-- 
2.31.1

Re: Failed to connect to WPA3 network after update to iwd 1.16

[Alex Cepoi]

[-- Attachment #1: Type: text/plain, Size: 2819 bytes --]

Hey James,

Thanks for quick fix. I can confirm that the patches with a locally built
iwd work fine for me ("Forcing default SAE group 19").

I'm assuming these will end up in iwd 1.18 once merged?

Alex.

On Tue, 24 Aug 2021 at 19:39, James Prestwood <prestwoj@gmail.com> wrote:

> Hi Alex,
>
> There are 4 patches on the mailing list which hopefully fix this for you.
> I've also attached them as well.
>
> Thanks,
> James
>
> On Mon, 2021-08-23 at 22:30 +0100, Alex Cepoi wrote:
>
> Hey James,
>
> Your theory seems to be correct. Adding "sae_groups=20 19" seems to make
> authentication fail.
> Here's what I tried:
> https://gist.github.com/alexcepoi/71f1b1fb579b26e0abaa5b7f818923be
>
> Alex.
>
> On Mon, 23 Aug 2021 at 21:03, James Prestwood <prestwoj@gmail.com> wrote:
>
> Hi Alex,
>
>
> On Mon, 23 Aug 2021 at 18:21, James Prestwood <prestwoj@gmail.com> wrote:
>
> Hi Alex,
>
> On Sun, 2021-08-22 at 04:47 +0100, Alex Cepoi wrote:
>
> Hi everyone,
>
> I'm having trouble connecting to a WPA3 network after updating from 1.15
> to 1.16. Can reproduce consistently (100% success rate on 1.15, 0% success
> rate on 1.16).
>
> You can see debug logs before and after in
> https://gist.github.com/alexcepoi/eef301a56e5e40826a8a416cbfb684e6
>
> Diff shows some new "SAE Hunting and Pecking" algorithm used and a "AP did
> not include group number in response!" info, though not sure if related.
>
>
> In your case the effective difference between IWD 1.16 and 1.15 is that we
> now try SAE groups in decending order. This is because higher group numbers
> are more secure. BUT the only group that is required for a device to
> support is group 19, which it seems your AP falls under. So we have this
> situation where we try group 20, fail, then try 19, but something else goes
> wrong.
>
> We don't think IWD is behaving out of what the spec requries in this
> situation (and we even test for this rejected group scenario) but there are
> several red flag commits in hostapd from 2018/2019 which describe fixing
> some behavior that sounds similar to this. Its difficult to know because we
> don't have your AP's hostapd or kernel version to try out ourselves.
>
> tl;dr
>
> We think we can 'fix' this by simply using group 19 by default (or a
> config option) but thats not optimal since you really want to use the most
> secure group if it is available. What we can do to verify that your AP is
> to blame is try wpa_supplicant and include this option:
>
> sae_groups=20 19
>
> This *should* try group 20 first and behave similarly to IWD. If this also
> results in the same issue we know the AP is to blame. Knowing this will at
> least give us some justification for adding a config option as a fix.
>
> Thanks,
> James
>
>
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 4711 bytes --]

Re: Failed to connect to WPA3 network after update to iwd 1.16

[James Prestwood]

[-- Attachment #1: Type: text/plain, Size: 3529 bytes --]

On Tue, 2021-08-24 at 20:03 +0100, Alex Cepoi wrote:
> Hey James,
> 
> Thanks for quick fix. I can confirm that the patches with a locally
> built iwd work fine for me ("Forcing default SAE group 19").
> 
> I'm assuming these will end up in iwd 1.18 once merged?

Yep they will and thank you for testing these out.

> 
> Alex.
> 
> On Tue, 24 Aug 2021 at 19:39, James Prestwood <prestwoj@gmail.com>
> wrote:
> > Hi Alex,
> > 
> > There are 4 patches on the mailing list which hopefully fix this
> > for you. I've also attached them as well.
> > 
> > Thanks,
> > James
> > 
> > On Mon, 2021-08-23 at 22:30 +0100, Alex Cepoi wrote:
> > > Hey James,
> > > 
> > > Your theory seems to be correct. Adding "sae_groups=20 19" seems
> > > to make authentication fail.
> > > Here's what I
> > > tried: 
> > >
> > https://gist.github.com/alexcepoi/71f1b1fb579b26e0abaa5b7f818923be
> > > 
> > > Alex.
> > > 
> > > On Mon, 23 Aug 2021 at 21:03, James Prestwood
> > > <prestwoj@gmail.com> wrote:
> > > > Hi Alex,
> > > > 
> > > > > 
> > > > > On Mon, 23 Aug 2021 at 18:21, James Prestwood
> > > > > <prestwoj@gmail.com> wrote:
> > > > > > Hi Alex,
> > > > > > 
> > > > > > On Sun, 2021-08-22 at 04:47 +0100, Alex Cepoi wrote:
> > > > > > > Hi everyone,
> > > > > > > 
> > > > > > > I'm having trouble connecting to a WPA3 network after
> > > > > > > updating from 1.15 to 1.16. Can reproduce consistently
> > > > > > > (100% success rate on 1.15, 0% success rate on 1.16).
> > > > > > > 
> > > > > > > You can see debug logs before and after in
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://gist.github.com/alexcepoi/eef301a56e5e40826a8a416cbfb684e6
> > > > > > > 
> > > > > > > Diff shows some new "SAE Hunting and Pecking" algorithm
> > > > > > > used and a "AP did not include group number in response!"
> > > > > > > info, though not sure if related.
> > > > 
> > > > 
> > > > In your case the effective difference between IWD 1.16 and 1.15
> > > > is that we now try SAE groups in decending order. This is
> > > > because higher group numbers are more secure. BUT the only
> > > > group that is required for a device to support is group 19,
> > > > which it seems your AP falls under. So we have this situation
> > > > where we try group 20, fail, then try 19, but something else
> > > > goes wrong.
> > > > 
> > > > We don't think IWD is behaving out of what the spec requries in
> > > > this situation (and we even test for this rejected group
> > > > scenario) but there are several red flag commits in hostapd
> > > > from 2018/2019 which describe fixing some behavior that sounds
> > > > similar to this. Its difficult to know because we don't have
> > > > your AP's hostapd or kernel version to try out ourselves.
> > > > 
> > > > tl;dr
> > > > 
> > > > We think we can 'fix' this by simply using group 19 by default
> > > > (or a config option) but thats not optimal since you really
> > > > want to use the most secure group if it is available. What we
> > > > can do to verify that your AP is to blame is try wpa_supplicant
> > > > and include this option:
> > > > 
> > > > sae_groups=20 19
> > > > 
> > > > This *should* try group 20 first and behave similarly to IWD.
> > > > If this also results in the same issue we know the AP is to
> > > > blame. Knowing this will at least give us some justification
> > > > for adding a config option as a fix.
> > > > 
> > > > Thanks,
> > > > James
> > > > 
> > 
> > 


[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 5026 bytes --]