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

[Ben Greear]

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.

interface=vap1
driver=nl80211
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
dump_file=/home/lanforge/wifi/hostapd_vap1.dump
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ssid=vap1-ssid-ben
bssid=04:f0:21:03:38:99
country_code=US
ieee80211d=1
ieee80211h=0
ieee80211w=1
hw_mode=a
ieee80211n=1
ieee80211ac=1
beacon_int=240
dtim_period=2
max_num_sta=2007
rts_threshold=2347
fragm_threshold=2346
preamble=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
# Enable HT modes if you want 300Mbps+ throughput.
#ht_capab=[HT20][HT40-][HT40+][GF][SHORT-GI-20][SHORT-GI-40]
#         [TX-STBC][RX-STBC123][MAX-AMSDU-7935][DSSS_CCK-40][PSMP][LSIG-TXOP-PROT]
ht_capab=[HT20][HT40+][SHORT-GI-40][SHORT-GI-20]
vht_capab=[MAX-MPDU-11454][RXLDPC][TX-STBC-2BY1][RX-STBC-1][MAX-A-MPDU-LEN-EXP0][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][SHORT-GI-80]
wmm_enabled=1
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0
### TX queue parameters
tx_queue_data3_aifs=7
tx_queue_data3_cwmin=15
tx_queue_data3_cwmax=1023
tx_queue_data3_burst=0
tx_queue_data2_aifs=3
tx_queue_data2_cwmin=15
tx_queue_data2_cwmax=63
tx_queue_data2_burst=0
tx_queue_data1_aifs=1
tx_queue_data1_cwmin=7
tx_queue_data1_cwmax=15
tx_queue_data1_burst=3.0
tx_queue_data0_aifs=1
tx_queue_data0_cwmin=3
tx_queue_data0_cwmax=7
tx_queue_data0_burst=1.5
vht_oper_centr_freq_seg0_idx=42
vht_oper_chwidth=1
channel=36
ieee8021x=0
eapol_key_index_workaround=0
eap_server=0
own_ip_addr=127.0.0.1
wpa=2
wpa_pairwise=TKIP CCMP
wpa_passphrase=vap1-passwd

# Error emulation settings.
ignore_probe_probability=0.000000
ignore_auth_probability=0.000000
ignore_assoc_probability=0.000000
ignore_reassoc_probability=0.000000
corrupt_gtk_rekey_mic_probability=0.000000


>> 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:
> http://w1.fi/cgit/hostap/commit/?id=9f6a7cddc42811883d6035032854089475f2fc65

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.

>>>> 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?
> 
> 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.

Thanks,
Ben



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