Problem in 4-Way Handshake

[Jouni Malinen]

On Tue, Apr 08, 2008 at 04:59:54PM +0800, Jack Yip wrote:

> I am porting the supplicant to my device to communicate with a CISCO server through EAP-FAST.
> I am now in the final state, but I have problem on the 4-way handshake.

It looks like you were able to get through the earlier Diffie-Hellman
issue.. Did you need to fix something in the TLS or crypto library code
to make it work on your target platform? If yes, was it a generic fix
that should be included in wpa_supplicant?

> After I have sent the msg 2/4, I found that somehow the program back to the msg 1/4.

This would likely mean that the AP did not like the msg 2/4 for some
reason and you may find that from the AP debug log.

> And I have diff the msg of the windows version, I found that in the msg 2/4,
>  
> windows version has 26 byte:
> WPA: WPA IE for msg 2/4 - hexdump(len=26): dd 18 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 01 3c 00
>  
> but in my debug msg, I got 24 bytes:
> WPA: WPA IE for msg 2/4 - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 0
> 1 00 00 50 f2 02 01 00 00 50 f2 01
>  
> I think this is abnormal, but do you know where goes wrong? Or which function can I look into it?

This is fine. WPA IE has variable length and the value that is used here
depends on what the driver decides to use during association. Unless the
AP is complaining about WPA IE mismatch, I would look for the problem
somewhere else.

One reason for AP to reject the message 2/4 is if the MIC is invalid.
This could be caused either by mismatch in the MSK derivation (from
EAP-FAST) or something going wrong with PMK to PTK derivation or MIC
calculation. Since you have access to the AP debug log, I would suggest
using that to figure out what the exact reason as the first step here.

-- 
Jouni Malinen                                            PGP id EFC895FA