| Message ID | 20230404203823.384260-1-prestwoj@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] handshake: include additional sha256 AKMs for PMKID generation | expand |
| Context | Check | Description |
|---|---|---|
| tedd_an/pre-ci_am | fail | error: patch failed: src/handshake.c:753 error: src/handshake.c: patch does not apply hint: Use 'git am --show-current-patch' to see the failed patch |
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
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
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
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
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
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
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.
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.
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.
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.
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.
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.
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.
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
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
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
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
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
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
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
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
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
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
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;