Failure due to bad EAPOL-Key descriptor version(3)
Fri Nov 14 12:39:01 PST 2014
On 11/14/2014 11:33 AM, Jouni Malinen wrote:
> On Fri, Nov 14, 2014 at 10:34:06AM -0800, Ben Greear wrote:
>> I reproduced the same general issue using hostapd as AP.
> Could you please send me a hostapd configuration file that you used to
> reproduce this? I could not get hostapd to misbehave in the same way
> without modifying the implementation..
Well, embarrassingly enough, I cannot reproduce the problem now.
I was certain I saw the error in the logs on my test rig, and
enabling SHA256 methods resolved the problem but I
cannot explain why I cannot reproduce it now.
My hostapd conf should have looked like this, though not certain
if I had iee80211w set to 1 or 2.
# Enable HT modes if you want 300Mbps+ throughput.
### TX queue parameters
# Error emulation settings.
>> 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.
> SHA1 is certainly supposed to work with PMF.
>> 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...
> There is certainly some interop issues in this area. So far, I've only
> seen signs pointing towards AP misbehavior, but I do not have verbose
> log or capture file to confirm my assumptions. Anyway, I expect this
> commit to address most, if not all, of these issues:
I'll pull that into my build, and if possible, will test that out
where we originally found the problem in the field...
If allowed, I'll grab a pkt capture of that system as well.
>>> 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?
> It is not broken as far as the IEEE 802.11 standard is concerned, i.e.,
> that is an allowed combination and it is supposed to work (and I just
> added a hwsim test case to confirm that this works and will continue to
> work in the future). That said, there is not much point in using
> SHA1-based AKM with PMF required since all PMF capable devices will be
> able to support SHA256-based AKM. In other words, I'd use SHA1-based AKM
> with PMF only in case PMF is set as optional on the AP.
Ok, thanks for all the help and wisdom.
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the Hostap