Question regarding WPA-PSK 4-way EAPOLs (wpa-supplicant 0.3.9)

[Jouni Malinen]

On Wed, Sep 28, 2005 at 03:53:10PM -0600, Eitan Bar wrote:

> 1st EAPOL from the AP (Cisco 1200) is received, and when wpa_supplicant generates the 2nd EAPOL, there
> seems to be something wrong with it (AP repeating 1st EAPOL).

I would guess that timeout on the AP side would be the main reason for
this. I would suggest verifying whether the same issue shows up with
wpa_supplicant v0.4.5 (test both with and without debugging).

> All fields in EAPOL seem ok and according to spec, but could it be that the MIC Calculated is wrong?

Unlikely.

> Is there a way or some special DBG msgs to look for?

For this, you would need to look at the AP debug log. Cisco 1200 has
quite verbose debugging, so it could explain why message 2/4 is
rejected.

> Could this be related to WME being enabled on both driver and AP ?

Should not be; the driver takes care of process the extra QoS control
field in the data frames, so the EAPOL-Key frames look exactly same as
they would without WMM.

> I've seen an earlier thread about this, but that ended with the guy disabling WME and that was it.

Hmm.. I don't remember reading this kind of report. I don't remember
whether I have explicitly tested wpa_supplicant with both WPA and WMM
enabled on Windows, but I would guess I have.

> While trying PSK association with another AP with WME disabled, I've seen that the wpa_supplicant,
> once receiving the 3rd EAPOL (from the AP) which contains the APs RSN IE (or part of it), prints a msg
> that it couldn't find an AP with this RSN IE (probably since ap_scan=2 therefore no beacon/probeRsp IE 
> are kept in memory).
> It then tries to retrieve scan_results from the driver.
> Assuming I do not wish this to happen and still have ap_scan=2, what am I missing here?

Why would you not want this to happen?

> Is this a must ? (APs IE kept for EAPOL handshake?)

Yes, supplicant needs to verify that the WPA/RSN IE in message 3/4
matches with the IE sent in Beacon/Probe Response frame in order to
detect a downgrade attack.

> Is the driver Assoc REQ RSN IE not enough?

No, this comparison is to verify AP's WPA/RSN IE which is not included
in association req/resp frames.

> Jan 01 00:24:54.583190: NDIS: ReqFixed=0x3 RespFixed=0x7 off_req=44 off_resp=102 len_req=58 len_resp=17
> Jan 01 00:24:54.583971: NDIS: association information - IE overflow
> Jan 01 00:24:54.584432: NDIS: Request IEs - hexdump(len=58): 00 07 65 69 74 61 6e 54 49 01 05 82 84 8b 96 2c 32 08 0c 12 18 24 30 48 60 6

Hmm.. Do you know why that IE overflow is being reported? Your debug log
was not verbose enough to include the full association information from
the driver (this would require -dd to get MSG_MSGDUMP level of debugging
printed out), so I cannot verify whether the data was valid. This
overflow message should only be reported if the NDIS driver returns
incorrect data (length of the assoc info is less than req/resp
offset+len). In addition, that "Request IEs" line should not be showing
up unless you have modified wpa_supplicant to ignore the overflow error.

> Jan 01 00:24:55.110847: WPA: No WPA/RSN IE for this AP known. Trying to get from scan results
> wpa_driver_get_scan_results called - not implemented and SHOULD NOT BE CALLED if ap_scan=2 !

This is an invalid comment. get_scan_results is needed to get the
WPA/RSN IE from the BSSID_LIST. In ap_scan=2 mode, this does not need to
do a scan of other APs or report any other BSSIDs that the one that the
client is currently associated with. Including this BSS in
OID_802_11_BSSID_LIST is required by the NDIS spec.

-- 
Jouni Malinen                                            PGP id EFC895FA