[PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[James Prestwood]

The 802.11 spec defines what AKMs should use sha256 to derive the
PMKID. Hostapd commit b6d3fd05e3 changed the PMKID derivation in
accordance with 802.11-2020 which then breaks PMKID validation in
IWD. This breaks FT-PSK/8021x AKMs in IWD if the AP uses this
hostapd version.

Updating IWD to use sha256 in these cases will now break backwards
compatibility with *older* APs, but this will be worked around in
future commits.
---
 src/handshake.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/handshake.c b/src/handshake.c
index 734e997c..e4c856bb 100644
--- a/src/handshake.c
+++ b/src/handshake.c
@@ -753,10 +753,23 @@ bool handshake_state_get_pmkid(struct handshake_state *s, uint8_t *out_pmkid)
 	 * preauthentication, the AKM has not yet been negotiated. In this
 	 * case, the HMAC-SHA1-128 based derivation is used for the PMKID
 	 * calculation."
+	 *
+	 * 802.11-2020 Table 9-151 defines the hashing algorithm to use
+	 * for various AKM's. SHA256 should be used for the following
+	 * AKM's (for this API context):
+	 *
+	 * 00-0F-AC:3 (FT-8021X)
+	 * 00-0F-AC:4 (FT-PSK)
+	 * 00-0F-AC:5 (8021X-SHA256)
+	 * 00-0F-AC:6 (PSK-SHA256)
+	 *
+	 * (Note SAE/FILS were left out as they generate their own PMKID)
 	 */
 
 	if (s->akm_suite & (IE_RSN_AKM_SUITE_8021X_SHA256 |
-			IE_RSN_AKM_SUITE_PSK_SHA256))
+			IE_RSN_AKM_SUITE_PSK_SHA256 |
+			IE_RSN_AKM_SUITE_FT_OVER_8021X |
+			IE_RSN_AKM_SUITE_FT_USING_PSK))
 		use_sha256 = true;
 	else
 		use_sha256 = false;
-- 
2.25.1

[PATCH 2/2] eapol: warn rather than reject invalid PMKID (for EAP)

[James Prestwood]

A recent hostapd change b6d3fd05e3 modified the PMKID derivation
which breaks EAPoL if the FT-8021x AKM is used and the AP sends
the PMKID KDE in message 1. This is because if the PMKID does not
validate it kicks off EAP again to renegotiate a PMK, but ultimately
the PMKID generation doesn't change so we end up in a loop until the
handshake timeout.

The validation of the PMKID isn't really required since IWD doesn't
support PMKSA, but we do it anyways if the KDE is included (why not
right?). But now with this interoperability issue we have to work
around APs incorrectly deriving the PMKID since its been in hostapd
for quite some time and a guarantee there are APs in production with
this issue.

For FT-PSK there is no changes required since IWD already ignores
a mismatch (see comment about zero/random PMKID). For FT-8021x
IWD will now first check if EAP has been exchanged and in that
case ignore the mismatch and print a warning.
---
 src/eapol.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/eapol.c b/src/eapol.c
index 3d7d33e0..43f65b85 100644
--- a/src/eapol.c
+++ b/src/eapol.c
@@ -1237,11 +1237,17 @@ static void eapol_handle_ptk_1_of_4(struct eapol_sm *sm,
 			/*
 			 * If the AP has a different PMKSA from ours and we
 			 * have means to create a new PMKSA through EAP then
-			 * try that, otherwise give up.
+			 * try that, otherwise give up. If EAP has already been
+			 * exchanged its likely the AP is using an outdated
+			 * derivation, in this case continue with a warning.
 			 */
 			if (sm->eap) {
-				__send_eapol_start(sm, unencrypted);
-				return;
+				if (!sm->eap_exchanged) {
+					__send_eapol_start(sm, unencrypted);
+					return;
+				}
+
+				l_warn("AP may be using old PMKID derivation!");
 			}
 
 			/*
-- 
2.25.1

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[Denis Kenzior]

Hi James,

On 4/4/23 15:38, James Prestwood wrote:
> The 802.11 spec defines what AKMs should use sha256 to derive the
> PMKID. Hostapd commit b6d3fd05e3 changed the PMKID derivation in
> accordance with 802.11-2020 which then breaks PMKID validation in
> IWD. This breaks FT-PSK/8021x AKMs in IWD if the AP uses this
> hostapd version.
> 
> Updating IWD to use sha256 in these cases will now break backwards
> compatibility with *older* APs, but this will be worked around in
> future commits.
> ---
>   src/handshake.c | 15 ++++++++++++++-
>   1 file changed, 14 insertions(+), 1 deletion(-)
> 

<snip>

>   	if (s->akm_suite & (IE_RSN_AKM_SUITE_8021X_SHA256 |
> -			IE_RSN_AKM_SUITE_PSK_SHA256))
> +			IE_RSN_AKM_SUITE_PSK_SHA256 |
> +			IE_RSN_AKM_SUITE_FT_OVER_8021X |
> +			IE_RSN_AKM_SUITE_FT_USING_PSK))

I don't see that the hostapd commit is actually adding FT_USING_PSK to use 
sha256 generation? Only FT_OVER_8021X?  Is this a bug on their side?

However, one consequence of this is that preauthentication is likely broken for 
FT-over-8021x networks?  Do we even test this case?

Regards,
-Denis

Re: [PATCH 2/2] eapol: warn rather than reject invalid PMKID (for EAP)

[Denis Kenzior]

Hi James,

On 4/4/23 15:38, James Prestwood wrote:
> A recent hostapd change b6d3fd05e3 modified the PMKID derivation
> which breaks EAPoL if the FT-8021x AKM is used and the AP sends
> the PMKID KDE in message 1. This is because if the PMKID does not
> validate it kicks off EAP again to renegotiate a PMK, but ultimately
> the PMKID generation doesn't change so we end up in a loop until the
> handshake timeout.
> 
> The validation of the PMKID isn't really required since IWD doesn't
> support PMKSA, but we do it anyways if the KDE is included (why not
> right?). But now with this interoperability issue we have to work
> around APs incorrectly deriving the PMKID since its been in hostapd
> for quite some time and a guarantee there are APs in production with
> this issue.
> 
> For FT-PSK there is no changes required since IWD already ignores
> a mismatch (see comment about zero/random PMKID). For FT-8021x
> IWD will now first check if EAP has been exchanged and in that
> case ignore the mismatch and print a warning.
> ---
>   src/eapol.c | 12 +++++++++---
>   1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/src/eapol.c b/src/eapol.c
> index 3d7d33e0..43f65b85 100644
> --- a/src/eapol.c
> +++ b/src/eapol.c
> @@ -1237,11 +1237,17 @@ static void eapol_handle_ptk_1_of_4(struct eapol_sm *sm,
>   			/*
>   			 * If the AP has a different PMKSA from ours and we
>   			 * have means to create a new PMKSA through EAP then
> -			 * try that, otherwise give up.
> +			 * try that, otherwise give up. If EAP has already been
> +			 * exchanged its likely the AP is using an outdated
> +			 * derivation, in this case continue with a warning.
>   			 */
>   			if (sm->eap) {
> -				__send_eapol_start(sm, unencrypted);
> -				return;
> +				if (!sm->eap_exchanged) {
> +					__send_eapol_start(sm, unencrypted);
> +					return;
> +				}
> +
> +				l_warn("AP may be using old PMKID derivation!");

Ugh.  Why not just detect that this is an FT-8021X AKM and compare both the 
'proper' and the 'compatibility' PMKIDs?

>   			}
>   
>   			/*

Regards,
-Denis

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[Denis Kenzior]

Hi James,

>   	if (s->akm_suite & (IE_RSN_AKM_SUITE_8021X_SHA256 |
> -			IE_RSN_AKM_SUITE_PSK_SHA256))
> +			IE_RSN_AKM_SUITE_PSK_SHA256 |
> +			IE_RSN_AKM_SUITE_FT_OVER_8021X |
> +			IE_RSN_AKM_SUITE_FT_USING_PSK))
>   		use_sha256 = true;
>   	else
>   		use_sha256 = false;

Oh and we probably should extended this and crypto_derive_pmkid to use sha384.

Regards,
-Denis

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[James Prestwood]

Hi Denis,

On 4/9/23 10:21 AM, Denis Kenzior wrote:
> Hi James,
> 
> On 4/4/23 15:38, James Prestwood wrote:
>> The 802.11 spec defines what AKMs should use sha256 to derive the
>> PMKID. Hostapd commit b6d3fd05e3 changed the PMKID derivation in
>> accordance with 802.11-2020 which then breaks PMKID validation in
>> IWD. This breaks FT-PSK/8021x AKMs in IWD if the AP uses this
>> hostapd version.
>>
>> Updating IWD to use sha256 in these cases will now break backwards
>> compatibility with *older* APs, but this will be worked around in
>> future commits.
>> ---
>>   src/handshake.c | 15 ++++++++++++++-
>>   1 file changed, 14 insertions(+), 1 deletion(-)
>>
> 
> <snip>
> 
>>       if (s->akm_suite & (IE_RSN_AKM_SUITE_8021X_SHA256 |
>> -            IE_RSN_AKM_SUITE_PSK_SHA256))
>> +            IE_RSN_AKM_SUITE_PSK_SHA256 |
>> +            IE_RSN_AKM_SUITE_FT_OVER_8021X |
>> +            IE_RSN_AKM_SUITE_FT_USING_PSK))
> 
> I don't see that the hostapd commit is actually adding FT_USING_PSK to 
> use sha256 generation? Only FT_OVER_8021X?  Is this a bug on their side?

Ugh, yep looks like its a bug on their side, at least according to 
12.7.1.6.3. There is another API rsn_pmkid(), which also doesn't include 
FT_USING_PSK, but references the 2016 spec (which is ambiguous).

Hostapd/wpa_supplicant get around this by not checking the PMKID KDE 
unless enabled... :/

So I think like you mentioned in patch 2 we just need to try both ways, 
at least for these AKMs in question. So my idea would be to add these 
AKMs to handshake_state_get_pmkid() (plus SHA384), then introduce 
handshake_state_check_pmkid() which will try both (for use in eapol). 
Sound good?

> 
> However, one consequence of this is that preauthentication is likely 
> broken for FT-over-8021x networks?  Do we even test this case?

I don't think we have this problem, 802.11 disallows preauthentication 
for FT networks:

"A STA shall not use preauthentication within the same mobility domain 
if an AKM suite type for which the Authentication type column indicates 
FT authentication"

Thanks,
James

> 
> Regards,
> -Denis

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[Denis Kenzior]

Hi James,

>> However, one consequence of this is that preauthentication is likely broken 
>> for FT-over-8021x networks?  Do we even test this case?
> 
> I don't think we have this problem, 802.11 disallows preauthentication for FT 
> networks:
> 
> "A STA shall not use preauthentication within the same mobility domain if an AKM 
> suite type for which the Authentication type column indicates FT authentication"

I'm not sure I concur with this interpretation.

The AP can advertise both FT+8021x and 8021x.  STA can preauthenticate to such 
an AP.  It can then connect to this AP using PMKSA caching, potentially 
selecting FT+8021X as the AKM for the initial association.  Table 9-151 even 
hints at this: "0 (open) for FT Initial Mobility Domain Association over IEEE 
Std 802.1X or PMKSA caching".

What you quote is a requirement on the STA side not to use preauthentication if 
the _current_ association is not an 'initial mobility domain association'.  In 
other words, if we used FT to get to the current AP, we can't use 
preauthentication within the same mobility domain.  This makes sense:  Why would 
we use preauthentication if FT is available.

Besides, there's still the case of IE_RSN_AKM_SUITE_8021X_SHA256 (and the 
SUITE_B ones which we haven't enabled yet).  That needs to use SHA1 in the case 
of preauthentication as well.

Regards,
-Denis

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[James Prestwood]

On 4/16/23 9:37 AM, Denis Kenzior wrote:
> Hi James,
> 
>>> However, one consequence of this is that preauthentication is likely 
>>> broken for FT-over-8021x networks?  Do we even test this case?
>>
>> I don't think we have this problem, 802.11 disallows preauthentication 
>> for FT networks:
>>
>> "A STA shall not use preauthentication within the same mobility domain 
>> if an AKM suite type for which the Authentication type column 
>> indicates FT authentication"
> 
> I'm not sure I concur with this interpretation.
> 
> The AP can advertise both FT+8021x and 8021x.  STA can preauthenticate 
> to such an AP.  It can then connect to this AP using PMKSA caching, 
> potentially selecting FT+8021X as the AKM for the initial association.  
> Table 9-151 even hints at this: "0 (open) for FT Initial Mobility Domain 
> Association over IEEE Std 802.1X or PMKSA caching".

Yes I suppose then preauth + FT is broken, or at least incompatible 
depending on hostapd version... but fixing this is somewhat impossible 
right? We don't really have the opportunity to try both derivations 
since we don't know what the AP used (unlike eapol where we have the 
PMKID KDE to reference).

> 
> What you quote is a requirement on the STA side not to use 
> preauthentication if the _current_ association is not an 'initial 
> mobility domain association'.  In other words, if we used FT to get to 
> the current AP, we can't use preauthentication within the same mobility 
> domain.  This makes sense:  Why would we use preauthentication if FT is 
> available.
> 
> Besides, there's still the case of IE_RSN_AKM_SUITE_8021X_SHA256 (and 
> the SUITE_B ones which we haven't enabled yet).  That needs to use SHA1 
> in the case of preauthentication as well. >
> Regards,
> -Denis

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[Denis Kenzior]

Hi James,

>> The AP can advertise both FT+8021x and 8021x.  STA can preauthenticate to such 
>> an AP.  It can then connect to this AP using PMKSA caching, potentially 
>> selecting FT+8021X as the AKM for the initial association. Table 9-151 even 
>> hints at this: "0 (open) for FT Initial Mobility Domain Association over IEEE 
>> Std 802.1X or PMKSA caching".
> 
> Yes I suppose then preauth + FT is broken, or at least incompatible depending on 
> hostapd version... but fixing this is somewhat impossible right? We don't really 
> have the opportunity to try both derivations since we don't know what the AP 
> used (unlike eapol where we have the PMKID KDE to reference).

The spec is somewhat contradictory, but I think Preauthentication should still 
work in this case.  We should not be re-computing the PMKID when we attempt 
preauthentication, unless the PMKID is not recognized by the AP.  But this can 
happen regardless.

Here's some relevant quotes:

12.6.10.2:
"The result of preauthentication may be a PMKSA, if the IEEE 802.1X 
authentication completes successfully. The AKM shall be set to 00-0F-AC:1 in the 
PMKSA that results from preauthentication. If preauthentication produces a 
PMKSA, then, when the Supplicant’s STA associates with the preauthenticated AP, 
the Supplicant may use the PMKSA with the 4-way handshake."

12.6.10.3:
"When the PMKSA was not created using preauthentication, the AKM indicated in 
the RSNE by the STA in the (re)association request shall be identical to the AKM 
used to establish the cached PMKSA in the first place."

12.7.1.3:
"When the PMKID is calculated for the PMKSA as part of preauthentication, the 
AKM has not yet been negotiated. In this case, the HMAC-SHA-1 based derivation 
is used for the PMKID calculation."

The three quotes above hint at PMKSA being established via pre-authentication 
with the PMKID being calculated via the legacy plain 802.1X/SHA1 derivation. 
Which means that we are be able to pre-authenticate, and then use the derived 
PMK at the new AP, even if we pick a different AKM than plain 802.1X.

The 'pick a different AKM' part is a bit unclear though.  Since there's another 
passage which is contradictory to the three above:
"Upon receipt of a (Re)Association Request frame with one or more PMKIDs 
following Open System authentication or (only in the case of a DMG AP) if IEEE 
802.11 authentication was not performed, an AP checks whether its Authenticator 
has cached a PMKSA for the PMKIDs and whether the AKM in the cached PMKSA 
matches the AKM in the (Re)Association Request; and if so, it shall assert 
possession of that PMKSA by beginning the 4-way handshake after association has 
completed and shall include the PMKID in message 1 (see 12.7.6.2). If the 
Authenticator does not have a PMKSA for the PMKIDs in the (re)association 
request or the AKM does not match, its behavior depends on how the PMKSA was 
established."

Do note however that nl80211 doesn't include the AKM in the PMKSA cache.  Who 
knows what hostapd does?  Probably some testing is required as to how exactly 
they interpret this.

But the spec clearly intends pre-authentication to use SHA1 for PMKID 
derivation, so we should make sure we do that, at least.

Regards,
-Denis

RE: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[Johnson, Bryce]

Hi Denis and James and all,

Sorry if formatting is messed up.  Outlook apparently doesn't do plain text emails very well anymore...

>
>>> The AP can advertise both FT+8021x and 8021x.  STA can preauthenticate to such
>>> an AP.  It can then connect to this AP using PMKSA caching, potentially
>>> selecting FT+8021X as the AKM for the initial association. Table 9-151 even
>>> hints at this: "0 (open) for FT Initial Mobility Domain Association over IEEE
>>> Std 802.1X or PMKSA caching".
>>
>> Yes I suppose then preauth + FT is broken, or at least incompatible depending on
>> hostapd version... but fixing this is somewhat impossible right? We don't really
>> have the opportunity to try both derivations since we don't know what the AP
>> used (unlike eapol where we have the PMKID KDE to reference).
>
>The spec is somewhat contradictory, but I think Preauthentication should still
>work in this case.  We should not be re-computing the PMKID when we attempt
>preauthentication, unless the PMKID is not recognized by the AP.  But this can
>happen regardless.
>

We were going wifi certification for a product and using IWD 2.4 and had a failure that looked like it might be related to this.  (SAE-5.2.1 - SAE-5.2.3 tests).  It was related to reassocation and the "STAUT transmits an Authentication frame with the Authentication Algorithm Number field set to 0" and our device returning a 2 (for SAE) instead of a 0.  It looks like with this patch it might be resolved?  I'm going to update our IWD to 2.8 and have them retest.  I can provide more details over DM if anyone was interested, I know the wifi alliance is pretty protective over their test plans so I didn't want to drop all the information to a public mailing list.

Bryce

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[James Prestwood]

Hi Bryce,

On 9/5/23 9:33 AM, Johnson, Bryce wrote:
> Hi Denis and James and all,
> 
> Sorry if formatting is messed up.  Outlook apparently doesn't do plain text emails very well anymore...
> 
>>
>>>> The AP can advertise both FT+8021x and 8021x.  STA can preauthenticate to such
>>>> an AP.  It can then connect to this AP using PMKSA caching, potentially
>>>> selecting FT+8021X as the AKM for the initial association. Table 9-151 even
>>>> hints at this: "0 (open) for FT Initial Mobility Domain Association over IEEE
>>>> Std 802.1X or PMKSA caching".
>>>
>>> Yes I suppose then preauth + FT is broken, or at least incompatible depending on
>>> hostapd version... but fixing this is somewhat impossible right? We don't really
>>> have the opportunity to try both derivations since we don't know what the AP
>>> used (unlike eapol where we have the PMKID KDE to reference).
>>
>> The spec is somewhat contradictory, but I think Preauthentication should still
>> work in this case.  We should not be re-computing the PMKID when we attempt
>> preauthentication, unless the PMKID is not recognized by the AP.  But this can
>> happen regardless.
>>
> 
> We were going wifi certification for a product and using IWD 2.4 and had a failure that looked like it might be related to this.  (SAE-5.2.1 - SAE-5.2.3 tests).  It was related to reassocation and the "STAUT transmits an Authentication frame with the Authentication Algorithm Number field set to 0" and our device returning a 2 (for SAE) instead of a 0.  It looks like with this patch it might be resolved?  I'm going to update our IWD to 2.8 and have them retest.  I can provide more details over DM if anyone was interested, I know the wifi alliance is pretty protective over their test plans so I didn't want to drop all the information to a public mailing list.

The patch you mentioned doesn't modify the auth algorithm at all, just 
how the PMKID is derived. Without seeing the test or knowing what its 
testing its hard to say, but for reference:

An auth algorithm of 0 is "Open System", 2 is "Fast BSS Transition", and 
4 is SAE. But do note that if the network enables FT then a roam between 
BSS will use an auth algorithm of 2 (FT) during the FT auth exchange.

Since the failure is because the field to set to 2 its likely something 
to do with FT.

I don't have my WFA account anymore since switching jobs, but I'm happy 
to take a look at the specific test if its something that can be shared 
externally.

> 
> Bryce
> 
> P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.
> 
> This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[James Prestwood]

All,

On 9/5/23 9:52 AM, James Prestwood wrote:
> Hi Bryce,
> 
> On 9/5/23 9:33 AM, Johnson, Bryce wrote:
>> Hi Denis and James and all,
>>
>> Sorry if formatting is messed up.  Outlook apparently doesn't do plain 
>> text emails very well anymore...
>>
>>>
>>>>> The AP can advertise both FT+8021x and 8021x.  STA can 
>>>>> preauthenticate to such
>>>>> an AP.  It can then connect to this AP using PMKSA caching, 
>>>>> potentially
>>>>> selecting FT+8021X as the AKM for the initial association. Table 
>>>>> 9-151 even
>>>>> hints at this: "0 (open) for FT Initial Mobility Domain Association 
>>>>> over IEEE
>>>>> Std 802.1X or PMKSA caching".
>>>>
>>>> Yes I suppose then preauth + FT is broken, or at least incompatible 
>>>> depending on
>>>> hostapd version... but fixing this is somewhat impossible right? We 
>>>> don't really
>>>> have the opportunity to try both derivations since we don't know 
>>>> what the AP
>>>> used (unlike eapol where we have the PMKID KDE to reference).
>>>
>>> The spec is somewhat contradictory, but I think Preauthentication 
>>> should still
>>> work in this case.  We should not be re-computing the PMKID when we 
>>> attempt
>>> preauthentication, unless the PMKID is not recognized by the AP.  But 
>>> this can
>>> happen regardless.
>>>
>>
>> We were going wifi certification for a product and using IWD 2.4 and 
>> had a failure that looked like it might be related to this.  
>> (SAE-5.2.1 - SAE-5.2.3 tests).  It was related to reassocation and the 
>> "STAUT transmits an Authentication frame with the Authentication 
>> Algorithm Number field set to 0" and our device returning a 2 (for 
>> SAE) instead of a 0.  It looks like with this patch it might be 
>> resolved?  I'm going to update our IWD to 2.8 and have them retest.  I 
>> can provide more details over DM if anyone was interested, I know the 
>> wifi alliance is pretty protective over their test plans so I didn't 
>> want to drop all the information to a public mailing list.
> 
> The patch you mentioned doesn't modify the auth algorithm at all, just 
> how the PMKID is derived. Without seeing the test or knowing what its 
> testing its hard to say, but for reference:
> 
> An auth algorithm of 0 is "Open System", 2 is "Fast BSS Transition", and 
> 4 is SAE. But do note that if the network enables FT then a roam between 
> BSS will use an auth algorithm of 2 (FT) during the FT auth exchange.
> 
> Since the failure is because the field to set to 2 its likely something 
> to do with FT.
> 
> I don't have my WFA account anymore since switching jobs, but I'm happy 
> to take a look at the specific test if its something that can be shared 
> externally.

In case it helps anyone else, the issue was that the test was expecting 
the PMKSA procedure to be used which IWD does not support. When using 
PMKSA (even with SAE) the Open System (0) auth algorithm is expected to 
be used when reassociating. IWD was doing a full initial association and 
using the SAE (4) auth algorithm (it must have been a mistake by the 
person administering the test that said it was using FT (2))

> 
>>
>> Bryce
>>
>> P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.
>>
>> This e-mail (including any attachments) is confidential and may be 
>> legally privileged. If you are not an intended recipient or an 
>> authorized representative of an intended recipient, you are prohibited 
>> from using, copying or distributing the information in this e-mail or 
>> its attachments. If you have received this e-mail in error, please 
>> notify the sender immediately by return e-mail and delete all copies 
>> of this message and any attachments. Thank you.

RE: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[Johnson, Bryce]

Hi James and all,

>
>In case it helps anyone else, the issue was that the test was expecting
>the PMKSA procedure to be used which IWD does not support. When using
>PMKSA (even with SAE) the Open System (0) auth algorithm is expected to
>be used when reassociating. IWD was doing a full initial association and
>using the SAE (4) auth algorithm (it must have been a mistake by the
>person administering the test that said it was using FT (2))
>

Talking with the test person, they tried with both PMKDA caching enabled and disabled.  In the disable case it should deauthenticate the device and cause it to reassociate.  But reading though the test case it still is checking the Authentication Algorithm is set to 0 on both cases (even in the disabled PMKSA case), which doesn't seem correct.  It should repeat what it did on the initial authentication.  I have to email wifi alliance and get clarification.

Bryce

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[James Prestwood]

Hi Bryce,

On 9/7/23 1:40 PM, Johnson, Bryce wrote:
> Hi James and all,
> 
>>
>> In case it helps anyone else, the issue was that the test was expecting
>> the PMKSA procedure to be used which IWD does not support. When using
>> PMKSA (even with SAE) the Open System (0) auth algorithm is expected to
>> be used when reassociating. IWD was doing a full initial association and
>> using the SAE (4) auth algorithm (it must have been a mistake by the
>> person administering the test that said it was using FT (2))
>>
> 
> Talking with the test person, they tried with both PMKDA caching enabled and disabled.  In the disable case it should deauthenticate the device and cause it to reassociate.  But reading though the test case it still is checking the Authentication Algorithm is set to 0 on both cases (even in the disabled PMKSA case), which doesn't seem correct.  It should repeat what it did on the initial authentication.  I have to email wifi alliance and get clarification.

Yes without PMKSA support the client device/IWD will never "reassociate" 
after being deauthenticated so your right checking for the auth alg == 0 
is not correct.

After being disconnected IWD will do a full initial association, which 
for SAE means auth alg == 4.

> 
> Bryce
> 
> P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.
> 
> This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

RE: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[Johnson, Bryce]

Hi James,

>Yes without PMKSA support the client device/IWD will never "reassociate"
>after being deauthenticated so your right checking for the auth alg == 0
>is not correct.
>
>After being disconnected IWD will do a full initial association, which
>for SAE means auth alg == 4.

Just looking through the wireshark logs, just to double check you mean the Authentication Algorithm in the Authentication message (0x000b).  I am seeing that as Authentication Algorithm: Simultaneous Authentication of Equals (SAE) (3)  (0x03 00).  So Auth Alg of 3?  Or am I referencing the wrong thing?

Also as a side note while looking at the logs. Relating to your other message with Group ID, this device happens to be using group 20.  But since this is at the wifi cert lab, they are probably specifically testing for that.

Bryce

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[James Prestwood]

On 9/8/23 7:01 AM, Johnson, Bryce wrote:
> Hi James,
> 
>> Yes without PMKSA support the client device/IWD will never "reassociate"
>> after being deauthenticated so your right checking for the auth alg == 0
>> is not correct.
>>
>> After being disconnected IWD will do a full initial association, which
>> for SAE means auth alg == 4.
> 
> Just looking through the wireshark logs, just to double check you mean the Authentication Algorithm in the Authentication message (0x000b).  I am seeing that as Authentication Algorithm: Simultaneous Authentication of Equals (SAE) (3)  (0x03 00).  So Auth Alg of 3?  Or am I referencing the wrong thing?

Yes sorry SAE is 3, I was mixing up what the kernel's enum value for SAE is.

> 
> Also as a side note while looking at the logs. Relating to your other message with Group ID, this device happens to be using group 20.  But since this is at the wifi cert lab, they are probably specifically testing for that.

IWD tries group 20 first, then falls back to group 19 if the AP rejects 
it. I wouldn't be surprised if this causes the cert lab confusion though 
since its different behavior than wpa_supplicant. Their tests were 
likely developed to match wpa_supplicant behavior, unfortunately.

> 
> Bryce
> 
> P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.
> 
> This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[Bryce Johnson]

Hi James and all,
Switched to my gmail account that works with the mailing list better...

> >
> >> Yes without PMKSA support the client device/IWD will never "reassociate"
> >> after being deauthenticated so your right checking for the auth alg == 0
> >> is not correct.
> >>
> >> After being disconnected IWD will do a full initial association, which
> >> for SAE means auth alg == 4.
> >
> > Just looking through the wireshark logs, just to double check you mean the Authentication Algorithm in the Authentication message (0x000b).  I am seeing that as Authentication Algorithm: Simultaneous Authentication of Equals (SAE) (3)  (0x03 00).  So Auth Alg of 3?  Or am I referencing the wrong thing?
>
> Yes sorry SAE is 3, I was mixing up what the kernel's enum value for SAE is.
>

Still having issues with wifi certification around the PMKSA caching.
After finally convincing the person at the wifi alliance support
person where the spec didn't say PMKSA caching disabled needed to be
in open mode I got this back:

"Thank you for sharing the PMKSA_caching information from the IEEE
Spec. It appears that it only describes the correct behavior of the
DUT with PMKSA caching but does not provide any information about
PMKSA caching for WPA3 SAE-H2E.

However, according to Security R3 MRD v1.3 (May 2020), PMKSA Caching
is mandatory for all devices, which means your device must have the
PMKSA caching function. You can find more details in section 6.3.1,
'SAE Hash-to-Element,' of the Security R3 MRD v1.3.pdf document, which
can be downloaded from the following link"

Those lines are here:
6.3.1 SAE Hash-to-Element
• Support for the SAE Hash-to-Element (H2E) technique defined in
802.11 REVmd D3.0, including support for Rejected Groups, and back
compatibility with the SAE Hunting-and-Pecking technique
▪ H2E support is required for all mandatory and optional SAE-based
WPA3 features that are supported by the device
o Note: PMKSA Caching is mandatory for all devices; FT-SAE is optional
• Support for BSS Membership Selector indication for H2E-only SAE, as
defined in 802.11 REVmd D3.0
• New MAC/PHY/Bands shall only support the SAE H2E method.

I can provide a copy to the PDF if someone was interested.

Honestly the wifi alliance has been pretty frustrating to work with
and takes 1-3 days to get anything back from them.  Depending on the
followup response, for this product it looks like I might have to
revert back to wpa_supplicant and deal with some of the issues with
using that.  I got spoiled with IWD ease of use (and it seemed to work
better in some situations).

Products must be getting certificated using IWD right?  Did I just
come across the wrong support person?

Bryce

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[James Prestwood]

Hi Bryce,

On 9/26/23 8:16 AM, Bryce Johnson wrote:
> Hi James and all,
> Switched to my gmail account that works with the mailing list better...
> 
>>>
>>>> Yes without PMKSA support the client device/IWD will never "reassociate"
>>>> after being deauthenticated so your right checking for the auth alg == 0
>>>> is not correct.
>>>>
>>>> After being disconnected IWD will do a full initial association, which
>>>> for SAE means auth alg == 4.
>>>
>>> Just looking through the wireshark logs, just to double check you mean the Authentication Algorithm in the Authentication message (0x000b).  I am seeing that as Authentication Algorithm: Simultaneous Authentication of Equals (SAE) (3)  (0x03 00).  So Auth Alg of 3?  Or am I referencing the wrong thing?
>>
>> Yes sorry SAE is 3, I was mixing up what the kernel's enum value for SAE is.
>>
> 
> Still having issues with wifi certification around the PMKSA caching.
> After finally convincing the person at the wifi alliance support
> person where the spec didn't say PMKSA caching disabled needed to be
> in open mode I got this back:
> 
> "Thank you for sharing the PMKSA_caching information from the IEEE
> Spec. It appears that it only describes the correct behavior of the
> DUT with PMKSA caching but does not provide any information about
> PMKSA caching for WPA3 SAE-H2E.
> 
> However, according to Security R3 MRD v1.3 (May 2020), PMKSA Caching
> is mandatory for all devices, which means your device must have the
> PMKSA caching function. You can find more details in section 6.3.1,
> 'SAE Hash-to-Element,' of the Security R3 MRD v1.3.pdf document, which
> can be downloaded from the following link"
> 
> Those lines are here:
> 6.3.1 SAE Hash-to-Element
> • Support for the SAE Hash-to-Element (H2E) technique defined in
> 802.11 REVmd D3.0, including support for Rejected Groups, and back
> compatibility with the SAE Hunting-and-Pecking technique
> ▪ H2E support is required for all mandatory and optional SAE-based
> WPA3 features that are supported by the device
> o Note: PMKSA Caching is mandatory for all devices; FT-SAE is optional
> • Support for BSS Membership Selector indication for H2E-only SAE, as
> defined in 802.11 REVmd D3.0

Apparently WFA does require PMKSA for their own certification then. Not 
sure why exactly they require this. Without PMKSA the device has to do a 
full authentication when reassociationg so its not like its adding 
security in any way, its more of a convenience for faster reassociations 
(as I understand it at least). Its also WPA-Enterprise specific and many 
consumer devices only support WPA-Personal, so its odd they'd require 
this across the board. Maybe ask them this? (unless your device is 
intended to support WPA-Enterprise). Maybe they can disregard that 
requirement if the device is WPA-Personal only?

> • New MAC/PHY/Bands shall only support the SAE H2E method.
> 
> I can provide a copy to the PDF if someone was interested.
> 
> Honestly the wifi alliance has been pretty frustrating to work with
> and takes 1-3 days to get anything back from them.  Depending on the
> followup response, for this product it looks like I might have to
> revert back to wpa_supplicant and deal with some of the issues with
> using that.  I got spoiled with IWD ease of use (and it seemed to work
> better in some situations).
> 
> Products must be getting certificated using IWD right?  Did I just
> come across the wrong support person?

I'm not sure about this. I know companies are definitely using IWD, 
whether or not they are getting it certified for a consumer device is 
another question.

I think, unfortunately (unless they change their requirements), your 
stuck using wpa_supplicant at this time if WFA requires PMKSA. 
Implementing PMKSA is on the IWD TODO but its not something that has 
been a priority.

I will say, now knowing the WFA requires it, I think its even more 
valuable to implement as making IWD "certifiable" is only going to help 
the project. If I can make time for it, or prioritize it, I will.

Thanks,
James

> 
> Bryce

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[Bryce Johnson]

On Tue, Sep 26, 2023 at 9:52 AM James Prestwood <prestwoj@gmail.com> wrote:
>
> Hi Bryce,
>
> On 9/26/23 8:16 AM, Bryce Johnson wrote:
> > Hi James and all,
> > Switched to my gmail account that works with the mailing list better...
> >
> >>>
> >>>> Yes without PMKSA support the client device/IWD will never "reassociate"
> >>>> after being deauthenticated so your right checking for the auth alg == 0
> >>>> is not correct.
> >>>>
> >>>> After being disconnected IWD will do a full initial association, which
> >>>> for SAE means auth alg == 4.
> >>>
> >>> Just looking through the wireshark logs, just to double check you mean the Authentication Algorithm in the Authentication message (0x000b).  I am seeing that as Authentication Algorithm: Simultaneous Authentication of Equals (SAE) (3)  (0x03 00).  So Auth Alg of 3?  Or am I referencing the wrong thing?
> >>
> >> Yes sorry SAE is 3, I was mixing up what the kernel's enum value for SAE is.
> >>
> >
> > Still having issues with wifi certification around the PMKSA caching.
> > After finally convincing the person at the wifi alliance support
> > person where the spec didn't say PMKSA caching disabled needed to be
> > in open mode I got this back:
> >
> > "Thank you for sharing the PMKSA_caching information from the IEEE
> > Spec. It appears that it only describes the correct behavior of the
> > DUT with PMKSA caching but does not provide any information about
> > PMKSA caching for WPA3 SAE-H2E.
> >
> > However, according to Security R3 MRD v1.3 (May 2020), PMKSA Caching
> > is mandatory for all devices, which means your device must have the
> > PMKSA caching function. You can find more details in section 6.3.1,
> > 'SAE Hash-to-Element,' of the Security R3 MRD v1.3.pdf document, which
> > can be downloaded from the following link"
> >
> > Those lines are here:
> > 6.3.1 SAE Hash-to-Element
> > • Support for the SAE Hash-to-Element (H2E) technique defined in
> > 802.11 REVmd D3.0, including support for Rejected Groups, and back
> > compatibility with the SAE Hunting-and-Pecking technique
> > ▪ H2E support is required for all mandatory and optional SAE-based
> > WPA3 features that are supported by the device
> > o Note: PMKSA Caching is mandatory for all devices; FT-SAE is optional
> > • Support for BSS Membership Selector indication for H2E-only SAE, as
> > defined in 802.11 REVmd D3.0
>
> Apparently WFA does require PMKSA for their own certification then. Not
> sure why exactly they require this. Without PMKSA the device has to do a
> full authentication when reassociationg so its not like its adding
> security in any way, its more of a convenience for faster reassociations
> (as I understand it at least). Its also WPA-Enterprise specific and many
> consumer devices only support WPA-Personal, so its odd they'd require
> this across the board. Maybe ask them this? (unless your device is
> intended to support WPA-Enterprise). Maybe they can disregard that
> requirement if the device is WPA-Personal only?

Yeah from what I can tell it is just to save time reassoicating.

We are just doing WPA-Personal (not just enterprise) but it looks like
it for WPA3-Personal as well and not just WPA3-Enterprise

Here were the previous lines to that:

6 Requirements
 6.1 Prerequisites
  6.1.1 Prerequisite certifications for WPA3-Personal or
WPA3-Enterprise Certification are listed below:
   • Certification of supported physical layers: Wi-Fi CERTIFIED a, b,
g, n, ac or 6 (includes WPA2 Personal certification)
     o Or any other PHY program once such becomes available.
    • Protected Management Frames
    • WPA2-Enterprise certification, for devices obtaining
WPA3-Enterprise certification
  6.1.2 Prerequisite certifications for Wi-Fi Enhanced Open are listed below:
   • Certification of supported physical layers: Wi-Fi CERTIFIED a, b,
g, n, ac or 6
    o Or any other PHY program once such becomes available.
   • Protected Management Frames
 6.2 Out-of-the-Box Requirements
   An AP and STA that implements Operating Channel Validation shall
enable it out of box.
   An AP and STA that implements Beacon Protection shall enable it out of box.
   A STA that implements client privacy shall enable it out of box.
 6.3 Mandatory Features
  In addition to the original WPA3-Personal mandatory requirements,
the following requirements are mandatory for the:
   6.3.1 SAE Hash-to-Element
    etc..

>
> > • New MAC/PHY/Bands shall only support the SAE H2E method.
> >
> > I can provide a copy to the PDF if someone was interested.
> >
> > Honestly the wifi alliance has been pretty frustrating to work with
> > and takes 1-3 days to get anything back from them.  Depending on the
> > followup response, for this product it looks like I might have to
> > revert back to wpa_supplicant and deal with some of the issues with
> > using that.  I got spoiled with IWD ease of use (and it seemed to work
> > better in some situations).
> >
> > Products must be getting certificated using IWD right?  Did I just
> > come across the wrong support person?
>
> I'm not sure about this. I know companies are definitely using IWD,
> whether or not they are getting it certified for a consumer device is
> another question.

Yeah I see a lot of companies don't go through the effort to get it
certified, but it is a requirement for our projects.  We had
previously done a similar product with wpa_supplicant.

>
> I think, unfortunately (unless they change their requirements), your
> stuck using wpa_supplicant at this time if WFA requires PMKSA.
> Implementing PMKSA is on the IWD TODO but its not something that has
> been a priority.
>
> I will say, now knowing the WFA requires it, I think its even more
> valuable to implement as making IWD "certifiable" is only going to help
> the project. If I can make time for it, or prioritize it, I will.

Understandable.  It would be nice if the WFA would be proactive and
let the developers know instead of updating the spec and waiting for
tests to fail...

>
> Thanks,
> James
>
> >
> > Bryce

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[James Prestwood]

Hi Bryce,

On 9/26/23 9:54 AM, Bryce Johnson wrote:
> On Tue, Sep 26, 2023 at 9:52 AM James Prestwood <prestwoj@gmail.com> wrote:
>>
>> Hi Bryce,
>>
>> On 9/26/23 8:16 AM, Bryce Johnson wrote:
>>> Hi James and all,
>>> Switched to my gmail account that works with the mailing list better...
>>>
>>>>>
>>>>>> Yes without PMKSA support the client device/IWD will never "reassociate"
>>>>>> after being deauthenticated so your right checking for the auth alg == 0
>>>>>> is not correct.
>>>>>>
>>>>>> After being disconnected IWD will do a full initial association, which
>>>>>> for SAE means auth alg == 4.
>>>>>
>>>>> Just looking through the wireshark logs, just to double check you mean the Authentication Algorithm in the Authentication message (0x000b).  I am seeing that as Authentication Algorithm: Simultaneous Authentication of Equals (SAE) (3)  (0x03 00).  So Auth Alg of 3?  Or am I referencing the wrong thing?
>>>>
>>>> Yes sorry SAE is 3, I was mixing up what the kernel's enum value for SAE is.
>>>>
>>>
>>> Still having issues with wifi certification around the PMKSA caching.
>>> After finally convincing the person at the wifi alliance support
>>> person where the spec didn't say PMKSA caching disabled needed to be
>>> in open mode I got this back:
>>>
>>> "Thank you for sharing the PMKSA_caching information from the IEEE
>>> Spec. It appears that it only describes the correct behavior of the
>>> DUT with PMKSA caching but does not provide any information about
>>> PMKSA caching for WPA3 SAE-H2E.
>>>
>>> However, according to Security R3 MRD v1.3 (May 2020), PMKSA Caching
>>> is mandatory for all devices, which means your device must have the
>>> PMKSA caching function. You can find more details in section 6.3.1,
>>> 'SAE Hash-to-Element,' of the Security R3 MRD v1.3.pdf document, which
>>> can be downloaded from the following link"
>>>
>>> Those lines are here:
>>> 6.3.1 SAE Hash-to-Element
>>> • Support for the SAE Hash-to-Element (H2E) technique defined in
>>> 802.11 REVmd D3.0, including support for Rejected Groups, and back
>>> compatibility with the SAE Hunting-and-Pecking technique
>>> ▪ H2E support is required for all mandatory and optional SAE-based
>>> WPA3 features that are supported by the device
>>> o Note: PMKSA Caching is mandatory for all devices; FT-SAE is optional
>>> • Support for BSS Membership Selector indication for H2E-only SAE, as
>>> defined in 802.11 REVmd D3.0
>>
>> Apparently WFA does require PMKSA for their own certification then. Not
>> sure why exactly they require this. Without PMKSA the device has to do a
>> full authentication when reassociationg so its not like its adding
>> security in any way, its more of a convenience for faster reassociations
>> (as I understand it at least). Its also WPA-Enterprise specific and many
>> consumer devices only support WPA-Personal, so its odd they'd require
>> this across the board. Maybe ask them this? (unless your device is
>> intended to support WPA-Enterprise). Maybe they can disregard that
>> requirement if the device is WPA-Personal only?
> 
> Yeah from what I can tell it is just to save time reassoicating.
> 
> We are just doing WPA-Personal (not just enterprise) but it looks like
> it for WPA3-Personal as well and not just WPA3-Enterprise

Its been a while since I looked at this and your right, both personal 
and enterprise can cache the PMK. Sorry for the confusion.

> 
> Here were the previous lines to that:
> 
> 6 Requirements
>   6.1 Prerequisites
>    6.1.1 Prerequisite certifications for WPA3-Personal or
> WPA3-Enterprise Certification are listed below:
>     • Certification of supported physical layers: Wi-Fi CERTIFIED a, b,
> g, n, ac or 6 (includes WPA2 Personal certification)
>       o Or any other PHY program once such becomes available.
>      • Protected Management Frames
>      • WPA2-Enterprise certification, for devices obtaining
> WPA3-Enterprise certification
>    6.1.2 Prerequisite certifications for Wi-Fi Enhanced Open are listed below:
>     • Certification of supported physical layers: Wi-Fi CERTIFIED a, b,
> g, n, ac or 6
>      o Or any other PHY program once such becomes available.
>     • Protected Management Frames
>   6.2 Out-of-the-Box Requirements
>     An AP and STA that implements Operating Channel Validation shall
> enable it out of box.
>     An AP and STA that implements Beacon Protection shall enable it out of box.
>     A STA that implements client privacy shall enable it out of box.
>   6.3 Mandatory Features
>    In addition to the original WPA3-Personal mandatory requirements,
> the following requirements are mandatory for the:
>     6.3.1 SAE Hash-to-Element
>      etc..
> 
>>
>>> • New MAC/PHY/Bands shall only support the SAE H2E method.
>>>
>>> I can provide a copy to the PDF if someone was interested.
>>>
>>> Honestly the wifi alliance has been pretty frustrating to work with
>>> and takes 1-3 days to get anything back from them.  Depending on the
>>> followup response, for this product it looks like I might have to
>>> revert back to wpa_supplicant and deal with some of the issues with
>>> using that.  I got spoiled with IWD ease of use (and it seemed to work
>>> better in some situations).
>>>
>>> Products must be getting certificated using IWD right?  Did I just
>>> come across the wrong support person?
>>
>> I'm not sure about this. I know companies are definitely using IWD,
>> whether or not they are getting it certified for a consumer device is
>> another question.
> 
> Yeah I see a lot of companies don't go through the effort to get it
> certified, but it is a requirement for our projects.  We had
> previously done a similar product with wpa_supplicant.
> 
>>
>> I think, unfortunately (unless they change their requirements), your
>> stuck using wpa_supplicant at this time if WFA requires PMKSA.
>> Implementing PMKSA is on the IWD TODO but its not something that has
>> been a priority.
>>
>> I will say, now knowing the WFA requires it, I think its even more
>> valuable to implement as making IWD "certifiable" is only going to help
>> the project. If I can make time for it, or prioritize it, I will.
> 
> Understandable.  It would be nice if the WFA would be proactive and
> let the developers know instead of updating the spec and waiting for
> tests to fail...
> 
>>
>> Thanks,
>> James
>>
>>>
>>> Bryce

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[Denis Kenzior]

Hi Bryce,

> Still having issues with wifi certification around the PMKSA caching.
> After finally convincing the person at the wifi alliance support
> person where the spec didn't say PMKSA caching disabled needed to be
> in open mode I got this back:

Which test spec is being used here?  I assume something like "Wi-Fi CERTIFIED 
WPA3 Test Plan v3.4.pdf"?

> 
> "Thank you for sharing the PMKSA_caching information from the IEEE
> Spec. It appears that it only describes the correct behavior of the
> DUT with PMKSA caching but does not provide any information about
> PMKSA caching for WPA3 SAE-H2E.
> 
> However, according to Security R3 MRD v1.3 (May 2020), PMKSA Caching
> is mandatory for all devices, which means your device must have the
> PMKSA caching function. You can find more details in section 6.3.1,
> 'SAE Hash-to-Element,' of the Security R3 MRD v1.3.pdf document, which
> can be downloaded from the following link"
> 
> Those lines are here:
> 6.3.1 SAE Hash-to-Element
> • Support for the SAE Hash-to-Element (H2E) technique defined in
> 802.11 REVmd D3.0, including support for Rejected Groups, and back
> compatibility with the SAE Hunting-and-Pecking technique
> ▪ H2E support is required for all mandatory and optional SAE-based
> WPA3 features that are supported by the device
> o Note: PMKSA Caching is mandatory for all devices; FT-SAE is optional

Indeed.  Funny that the Test Plan above does consider PMKSA optional:

"If the STAUT cannot support PMKSA
caching when the disconnect is
triggered on the STAUT, trigger the AP
to deauthenticate the STAUT."

> • Support for BSS Membership Selector indication for H2E-only SAE, as
> defined in 802.11 REVmd D3.0
> • New MAC/PHY/Bands shall only support the SAE H2E method.
> 
> I can provide a copy to the PDF if someone was interested.
> 

I'm not quite sure what benefit there is in supporting PMKSA for WPA3-Personal. 
Maybe lessening the CPU load on the AP?  The number of messages exchanged will 
be identical if I recall correctly.

> Honestly the wifi alliance has been pretty frustrating to work with
> and takes 1-3 days to get anything back from them.  Depending on the
> followup response, for this product it looks like I might have to
> revert back to wpa_supplicant and deal with some of the issues with
> using that.  I got spoiled with IWD ease of use (and it seemed to work
> better in some situations).
> 
> Products must be getting certificated using IWD right?  Did I just
> come across the wrong support person?

You're the first I've heard about.  If anyone else is going through the 
certification process, I'd certainly love to hear about it.

Regards,
-Denis

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[Bryce Johnson]

On Tue, Sep 26, 2023 at 1:18 PM Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi Bryce,
>
> > Still having issues with wifi certification around the PMKSA caching.
> > After finally convincing the person at the wifi alliance support
> > person where the spec didn't say PMKSA caching disabled needed to be
> > in open mode I got this back:
>
> Which test spec is being used here?  I assume something like "Wi-Fi CERTIFIED
> WPA3 Test Plan v3.4.pdf"?
>

Yes, that was the exact test plan I was referencing as well.

> >
> > "Thank you for sharing the PMKSA_caching information from the IEEE
> > Spec. It appears that it only describes the correct behavior of the
> > DUT with PMKSA caching but does not provide any information about
> > PMKSA caching for WPA3 SAE-H2E.
> >
> > However, according to Security R3 MRD v1.3 (May 2020), PMKSA Caching
> > is mandatory for all devices, which means your device must have the
> > PMKSA caching function. You can find more details in section 6.3.1,
> > 'SAE Hash-to-Element,' of the Security R3 MRD v1.3.pdf document, which
> > can be downloaded from the following link"
> >
> > Those lines are here:
> > 6.3.1 SAE Hash-to-Element
> > • Support for the SAE Hash-to-Element (H2E) technique defined in
> > 802.11 REVmd D3.0, including support for Rejected Groups, and back
> > compatibility with the SAE Hunting-and-Pecking technique
> > ▪ H2E support is required for all mandatory and optional SAE-based
> > WPA3 features that are supported by the device
> > o Note: PMKSA Caching is mandatory for all devices; FT-SAE is optional
>
> Indeed.  Funny that the Test Plan above does consider PMKSA optional:
>
> "If the STAUT cannot support PMKSA
> caching when the disconnect is
> triggered on the STAUT, trigger the AP
> to deauthenticate the STAUT."
>
Yes, we went back and forth on that for a couple weeks with me point
that out and the WFA support guy saying it doesn't matter the Auth
Algorithm should be set to 0 in both cases. Then he agreed that it
might be unclear and said well this other spec "Security R3 MRD v1.3
(May 2020)" says it is required now.

> > • Support for BSS Membership Selector indication for H2E-only SAE, as
> > defined in 802.11 REVmd D3.0
> > • New MAC/PHY/Bands shall only support the SAE H2E method.
> >
> > I can provide a copy to the PDF if someone was interested.
> >
>
> I'm not quite sure what benefit there is in supporting PMKSA for WPA3-Personal.
> Maybe lessening the CPU load on the AP?  The number of messages exchanged will
> be identical if I recall correctly.

I am just learning this now, so might be wrong.  But looks like it
would it then skip the 4 initial SAE initial handshake messages?

>
> > Honestly the wifi alliance has been pretty frustrating to work with
> > and takes 1-3 days to get anything back from them.  Depending on the
> > followup response, for this product it looks like I might have to
> > revert back to wpa_supplicant and deal with some of the issues with
> > using that.  I got spoiled with IWD ease of use (and it seemed to work
> > better in some situations).
> >
> > Products must be getting certificated using IWD right?  Did I just
> > come across the wrong support person?
>
> You're the first I've heard about.  If anyone else is going through the
> certification process, I'd certainly love to hear about it.
>

Me as well, I'd rather not switch back to wpa_supplicant so any
workarounds would be great!

> Regards,
> -Denis

Bryce

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[James Prestwood]

Hi Bryce,

>>>
>>
>> I'm not quite sure what benefit there is in supporting PMKSA for WPA3-Personal.
>> Maybe lessening the CPU load on the AP?  The number of messages exchanged will
>> be identical if I recall correctly.
> 
> I am just learning this now, so might be wrong.  But looks like it
> would it then skip the 4 initial SAE initial handshake messages?

I believe yes, it can skip SAE entirely using Open Authentication:

12.6.10.3
"If a STA in an infrastructure BSS has determined it has a valid PMKSA 
with an AP to which it is about to (re)associate, it performs Open 
System authentication to the AP"

So in that regard its faster, your saving 2 messages essentially (since 
open auth still requires a request/reply).

But this all gets beat by FT anyways since you can skip the 4-way 
handshake. I think this was all considered when we decided whether or 
not to implement PMKSA, it just didn't seem worth it since FT exists and 
is superior.

> 
>>
>>> Honestly the wifi alliance has been pretty frustrating to work with
>>> and takes 1-3 days to get anything back from them.  Depending on the
>>> followup response, for this product it looks like I might have to
>>> revert back to wpa_supplicant and deal with some of the issues with
>>> using that.  I got spoiled with IWD ease of use (and it seemed to work
>>> better in some situations).
>>>
>>> Products must be getting certificated using IWD right?  Did I just
>>> come across the wrong support person?
>>
>> You're the first I've heard about.  If anyone else is going through the
>> certification process, I'd certainly love to hear about it.
>>
> 
> Me as well, I'd rather not switch back to wpa_supplicant so any
> workarounds would be great!
> 
>> Regards,
>> -Denis
> 
> Bryce

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[Denis Kenzior]

Hi Bryce,

>> Which test spec is being used here?  I assume something like "Wi-Fi CERTIFIED
>> WPA3 Test Plan v3.4.pdf"?
>>
> 
> Yes, that was the exact test plan I was referencing as well.
> 

Ok excellent.

>>
>> I'm not quite sure what benefit there is in supporting PMKSA for WPA3-Personal.
>> Maybe lessening the CPU load on the AP?  The number of messages exchanged will
>> be identical if I recall correctly.
> 
> I am just learning this now, so might be wrong.  But looks like it
> would it then skip the 4 initial SAE initial handshake messages?
> 

I don't have the spec in front of me, but from memory: sort of.  SAE handshake 
uses Authenticate/Associate frames as transport.  So 4 messages (2 round-trips) 
is the bare minimum for the SAE handshake to establish the PMK.  Then 4 messages 
(2 round trips) for the 4-way handshake.

With PMK caching, you can skip the SAE handshake, but you still need to exchange 
Re-Associate frames.  So 1 round trip + 4 messages for the 4-way handshake. 
That's the best case.  Worst case is the AP doesn't have your PMK info and you 
have to fall back to SAE handshake.

For WPA2-Personal there's almost no point in doing PMK caching.  For 
WPA3-Personal one can skip the expensive computational step.  For 
WPA-Enterprise, one can skip EAP entirely and go straight to 4-way handshake 
step, which is a much bigger win; but then FT is a much better alternative 
there.  This is why we never prioritized PMK caching, but I do kind of see the 
benefits for WPA3-Personal.

>>
>> You're the first I've heard about.  If anyone else is going through the
>> certification process, I'd certainly love to hear about it.
>>
> 
> Me as well, I'd rather not switch back to wpa_supplicant so any
> workarounds would be great!

Oh, I forgot to ask you, is this the only obstacle you're facing or are there 
other tests that are failing?  Strictly speaking we already use PMK caching for 
802.1X preauthentication.  It probably wouldn't be too hard to add this for 
WPA3/2-Personal.

Regards,
-Denis

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[Denis Kenzior]

Hi James,

> I believe yes, it can skip SAE entirely using Open Authentication:
> 
> 12.6.10.3
> "If a STA in an infrastructure BSS has determined it has a valid PMKSA with an 
> AP to which it is about to (re)associate, it performs Open System authentication 
> to the AP"
> 
> So in that regard its faster, your saving 2 messages essentially (since open 
> auth still requires a request/reply).

My memory is fuzzy here now.  Aren't we skipping Authenticate frames and go 
straight to Reassociate?  Or is the kernel still sending an Authenticate frame 
as a result of netdev_reassociate?

> 
> But this all gets beat by FT anyways since you can skip the 4-way handshake. I 
> think this was all considered when we decided whether or not to implement PMKSA, 
> it just didn't seem worth it since FT exists and is superior.
> 

Agreed, but WPA3-Personal is less likely to support FT.  Also this is 
potentially beneficial for non-roaming scenarios.  I.e. just reconnect after 
sleep, etc.

Regards,
-Denis

Re: [PATCH 1/2] handshake: include additional sha256 AKMs for PMKID generation

[James Prestwood]

Hi Denis,

On 9/27/23 9:47 AM, Denis Kenzior wrote:
> Hi James,
> 
>> I believe yes, it can skip SAE entirely using Open Authentication:
>>
>> 12.6.10.3
>> "If a STA in an infrastructure BSS has determined it has a valid PMKSA 
>> with an AP to which it is about to (re)associate, it performs Open 
>> System authentication to the AP"
>>
>> So in that regard its faster, your saving 2 messages essentially 
>> (since open auth still requires a request/reply).
> 
> My memory is fuzzy here now.  Aren't we skipping Authenticate frames and 
> go straight to Reassociate?  Or is the kernel still sending an 
> Authenticate frame as a result of netdev_reassociate?

Whether or not the kernel sends an auth is a separate question, as we've 
seen it erroneously do before :) But it appears the spec still expects 
an auth frame request/reply:

"Upon receipt of a (Re)Association Request frame with one or more PMKIDs 
following Open System authentication or (only in the case of a DMG AP) 
if IEEE 802.11 authentication was not performed, an AP checks whether 
its Authenticator has cached a PMKSA for the PMKIDs and whether the AKM 
in the cached PMKSA matches the AKM in the (Re)Association Request"

> 
>>
>> But this all gets beat by FT anyways since you can skip the 4-way 
>> handshake. I think this was all considered when we decided whether or 
>> not to implement PMKSA, it just didn't seem worth it since FT exists 
>> and is superior.
>>
> 
> Agreed, but WPA3-Personal is less likely to support FT.  Also this is 
> potentially beneficial for non-roaming scenarios.  I.e. just reconnect 
> after sleep, etc.
> 
> Regards,
> -Denis