Group key negotiation failure with D-link AP

[Duncan Grove]

Hi Jouni,

Sorry I was so long in replying! I'm mainly replying just to add a 
couple of reference points for people interested in the WPA support 
provided by different access points.

I never got around to sniffing whether the D-link AP either 1) forgets 
to send the Group Key message or 2) just sends a bogus one. Instead, I 
switched to Cisco 1200s and they work fine. I also note this reduced  
the handshake time from 3s with the D-link AP to of the order of 100ms 
or so with the Cisco. I suspect the D-link AP has a bogus WPA 
implementation.

Cheers,
Duncan

> Message: 9 Date: Tue, 3 Aug 2004 10:53:35 +0300 From: Jouni Malinen 
> <jkmaline at cc.hut.fi> Subject: Re: Group key negotiation failure with 
> D-link AP leading to unstable connectivity? To: hostap at shmoo.com 
> Message-ID: <20040803075335.GE7153 at jm.kir.nu> Content-Type: 
> text/plain; charset=us-ascii On Mon, Aug 02, 2004 at 02:13:50PM +0930, 
> Duncan Grove wrote:
>
>>> Logs from "wpa_supplicant -D hermes -c/etc/wpa_supplicant.conf -dd" show 
>>> the following behaviour:
>>> 
>>> 1) wpa_supplicant scans for an AP and associates
>>> 2) pings to AP do not flow for 3 seconds
>>> 3) 4-way handshake for pairwise key succeeds
>>> 4) pings to AP flow for 10 seconds (wpa_state=GROUP_HANDSHAKE)
>>> 5) group key negotiation times out
>>> 6) repeat from step 1
>>    
>>
>
>Based on the debug logs, it looks clear that the problem is caused by
>either client not receiving the Group Key message or AP not sending (at
>least a valid) one.
>
>Have you used a wireless sniffer to capture the packet exchange? That
>should probide useful information about the real reason for this issue.
>
>Some WPA implementations do not care about whether the Group Key
>messages are encrypted even though the standard clearly specifies that
>they must be encrypted. If the AP is sending unencrypted EAPOL-Key
>packets when pairwise keys are configured (this would happen, e.g., if
>Group Key handshake is using unencrypted packets), the client driver is
>supposed to drop the frames. Since many Windows WPA implementations do
>not verify this, number of APs (even Wi-Fi certified) may be using
>incorrect frames without vendors and most testers even realizing this..
>
>  
>
>>> After many, many hours of this broken operation the group key 
>>> negotiation finally succeeds (immediately after 
>>> wpa_driver_hermes_set_key above) and everything after that worked fine:
>>    
>>
>
>That's interesting.. Maybe there is some kind of race in which the AP
>actually ends up finally encrypting the Group Key frame. The encryption
>key is configured just before sending this frame which could explain the
>race.
>
>  
>
>>> I presume this is what is meant to happen all the time. It seems to me 
>>> like my AP is just not sending message 1 of the Group Key Handshake most 
>>> of the time and this is the source of my problem. Is this correct?
>>    
>>
>
>WPA is indeed supposed to use the Group Key exchange every time after
>4-Way (PTK) Handshake. Your AP might be sending message 1 incorrectly
>(unencrypted) in most case; wireless sniffer would tell this..
>
>  
>
>>> I have also noticed a couple of other problems that may or may not be 
>>> related:
>>> 
>>> 1) If I stop and restart wpa_supplicant, the 4-way handshake gets stuck 
>>> in a rapidly repeating cycle of steps 1 and 2.
>>    
>>
>
>I'm not completely sure what you mean with steps 1 and 2 in this
>context. This could be because of AP not clearing state properly after
>new association or the client driver not actually associating again in
>this case.
>
>  
>
>>> 2) If I power off/power on the AP, it remains in wpa_supplicants scan 
>>> list, and I need to restart wpa_supplicant.
>>    
>>
>
>This seems to work with at least Host AP driver..
>
>If you can send debug logs from wpa_supplicant that show these cases, I
>could at least add them to my to do list as targets for more examination
>at some point.
>
>  
>
>>> Oh, and I have one final question: I have been able to find lots of 
>>> dicsussion about how often a WPA rekey happens (eg every minute, every 
>>> day, every 10,000 packets, etc) but I've seen hardly anything on how 
>>> long it takes when it does (for eg if reassociating with a new AP during 
>>> roaming). Is about 3 seconds (what I got above) normal, or very slow?
>>    
>>
>
>I would call that somewhat slow. I can completely full auth + assoc +
>4-Way Handshake + Group Key handshake in well below one second even with
>full debugging enabled (probably closer to 0.1 sec without debugging).
>Anyway, this depends on the implementations and CPU speed to both the
>client and AP, so the results are likely to vary quite a bit.
>
> -- Jouni Malinen PGP id EFC895FA
>