Failure due to bad EAPOL-Key descriptor version(3)

[Ben Greear]

On 11/14/2014 10:14 AM, Jouni Malinen wrote:
> On Wed, Nov 05, 2014 at 08:43:24PM -0800, Ben Greear wrote:
> 
>> Any idea what might be the cause of this failure to connect?  I don't know much
>> about the setup of the AP at this point.
> 
> It would be useful if you would be able to get a wireless capture log
> from such a failure case or at least some information about the AP in
> question. Based on the OUI, this seems to be a Huawei AP. I've received
> a similar report recently with another AP vendor as well, so it looks
> likely that there are some interoperability issues in this area.

I reproduced the same general issue using hostapd as AP.

I have since fixed my tool to enforce only the SHA256 are enabled when .11w is enabled,
but if you tell supplicant and hostapd to enable .11w, but also give
them an option to use SHA128 and SHA256, then it appears supplicant and/or hostapd
will not properly choose the SHA256 variants.

I'm busy today, but can work on some example config files to reproduce
this problem if you need me too...

It is still possible I have just completely broken config files,
but I suspect that is not the full problem since I too saw some bug reports
on the web that looked similar...

>> sta101: SME: Trying to authenticate with 10:51:72:54:5a:90 (SSID='pmftest' freq=5180 MHz)
>> 1415248099.342285: sta101: Trying to associate with 10:51:72:54:5a:90 (SSID='pmftest' freq=5180 MHz)
>> 1415248099.354882: sta101: Associated with 10:51:72:54:5a:90
>> 1415248099.360457: sta101: WPA: CCMP is used, but EAPOL-Key descriptor version (3) is not 2
> 
> Based on the SSID, I'd assume this is an AP misbehavior (selecting
> incorrect EAPOL-Key descriptor version) in case the station tries to
> negotiate PMF.
> 
>> network={
>>     ieee80211w=2
>>     proto=RSN
>>     key_mgmt=WPA-PSK
> 
> Please note that this would be a pretty strange configuration for PMF.
> When PMF is required (ieee80211w=2), a SHA256-based AKM (WPA-PSK-SHA256)
> should be used. With that AKM, EAPOL-Key descriptor version should
> indeed be 3, but this configuration is forcing the station to use
> SHA1-based AKM and that AKM would use descriptor version 2.

If it is totally broken config, should supplicant just fail to start
with a big error explaining the issue in this case?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com