RSN-IE mismatch and WPA2 preauth

[Jouni Malinen]

On Mon, Jan 24, 2005 at 12:20:45PM -0500, Zimmermann, Christopher Brian (Chris) wrote:

> The problem I am seeing is that the capabilities field in the RSN-IE for
> each is different.  The Gateway AP (00:e0:b8:76:27:16 ) sets the
> capabilities field to 0x003D, and the Broadcom AP (00:10:18:90:20:78 )
> sets it to 0x0001.  
> 
> This causes a pre-authenticated AP to fail at message 3/4.

Hmm.. That's odd. This shouldn't really have anything to do with
preauthentication since RSN IE should be updated when the new AP is
selected.

Do you allow wpa_supplicant to configure WPA/RSN IE or is the driver
generating these and your driver interface code is then using
EVENT_ASSOCINFO event? I have mainly tested with drivers that take the
IEs from wpa_supplicant and haven't seen this kind of issues before. Nor
have I heard of this from tests with drivers that take care of RSN IE
generation.

> Log snippets:
> 
> I associate to the Broadcom AP
> WPA: Key negotiation completed with 00:10:18:90:20:78 [PTK=CCMP
> GTK=CCMP]
> 
> I pre-authenticate to the Gateway AP
> RSN: pre-authentication with 00:e0:b8:76:27:16 completed successfully
> 
> I turn off the radio on the Broadcom AP to force pre-auth to the
> gateway...
> WPA: IE in 3/4 msg does not match with IE in Beacon/ProbeResp
> (src=00:e0:b8:76:27:16)
> WPA: RSN IE in Beacon/ProbeResp - hexdump(len=22): 30 14 01 00 00 0f ac
> 04 01 00 00 0f ac 04 01 00 00 0f ac 01 01 00
> WPA: RSN IE in 3/4 msg - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00
> 00 0f ac 04 01 00 00 0f ac 01 3d 00
> 
> It appears that wpa_supplicant does not keep the probe-rsp RSN-IE around
> for multiple APs, just the one it originally associates to.  At a quick
> inspection: 

Only one IE is needed, but that IE should be the one for the AP that the
client is currently associationg with, i.e., not the original AP.. I
would need to see the full debug log, i.e., including the original
association and the re-association to determine where the IE was not
updated properly.

> wpa_supplicant_set_suites() is called with a valid bss (scan result
> information)  From the scope of wpa_supplicant_associate().  When this
> happens, the bss->rsn_ie is stored into the wpa_s->ap_rsn_ie element.
> It seems to me this bug would exhibit itself even under normal roaming,
> not just under pre-authentication.  

If you are using EVENT_ASSOCINFO, do you generate that for the roaming
case? The driver will need to tell wpa_supplicant about the used IE in
that case..

> Should the ap_rsn_ie's be kept around, at least in the struct
> rsn_pmksa_candidate, and then copied into the wpa_s element under the
> scope of EVENT_ASSOCINFO reporting to wpa_supplicant_event()?  

The correct RSN IE should be available at the (re-)association time and
I don't see need for storing this information in struct
rsn_pmksa_candidate. My current guess would be that your driver
interface does not update wpa_supplicant about the RSN IE when roaming
to another AP. If that is not the case, we can take a closer look at
whether something would need to be stored in candidate list.

-- 
Jouni Malinen                                            PGP id EFC895FA