NDIS driver / changing RSN IEs

[Jouni Malinen]

On Mon, Oct 31, 2005 at 01:52:50PM -0500, Bryan Kadzban wrote:

> At times, when we reset the radios on these APs (for instance, when the
> AP restarts, or when we change a setting on the relevant SSID / virtual
> BSSID), the "RSN capabilities" field in the RSN IE in the beacons and
> probe responses will change.  I've seen these APs go from advertising 1
> PTKSA counter/1 GTKSA counter to 4 of each, and sometimes they go from 4
> to 1.  It's (so far) always either 4 or 1, though, and the PTKSA counter
> count is always the same as the GTKSA counter count.

This sounds like enabling/disabling WMM which uses four separate TX
queues.

> I believe it is legal (according to 802.11i) for an AP to change its RSN
> IE like this, as long as it can inform clients of the new IE.  But I'm
> not sure; maybe it is invalid.

This is indeed allowed behavior and the main problem is in getting the
client to update its WPA/RSN IE from Beacon/ProbeRsp frames.

> How can I either clear the stored AP RSN IE, or update it with the
> current probe response / beacon frames' contents?  Is it possible at all
> using the control interface?  Or is it possible with NDIS somehow?

wpa_supplicant should ask the driver for the IE after each association.
I haven't tested this, but if this is not the case, wpa_supplicant
should be fixed to do this. However, this is not enough, since also the
NDIS driver has to update its BSSID list to include the latest WPA/RSN
IE.


On Mon, Oct 31, 2005 at 04:40:09PM -0500, Bryan Kadzban wrote:

> So the problem is still there, but the problem isn't that set_ap_rsn_ie
> doesn't get called.  The problem is that the scan results table is out
> of date, and it returns the wrong IE.

OK, this is nice to hear (well, from wpa_supplicant view point at least
;-).

> I have tried doing a "wpa_cli scan" while the supplicant is in this
> state (to update the scan results table), but that refuses to ever
> reconnect to the current AP, for some reason.  I believe it's an issue
> with the NDIS driver in use (Linksys's driver for their WMP54GS> cards),
> but I don't know that for sure.

Hmm.. "wpa_cli scan" should not break association; NDIS spec requires
that scan request can be issued at any time.. Do you mean that the
driver refuses to reconnect to the AP or that wpa_supplicant does not
allow the authentication after this?

The problem here seems to be in getting the driver to update its BSSID
table. Some drivers are known to cache results for a while and I've seen
some drivers not updating this data for a long while. It may be possible
to change some parameters in the registry to start timing out BSSID data
more quickly with some drivers. Likewise, I've seen at least some
vendors improving on this area over time, so updating to the latest
driver may also help with this.

> (So the log I attached isn't worth much.  I could attach another log if
> needed, but it'll take some doing to get it below the message-size
> threshold that this list has.)

You can send longer logs directly to my email address, if needed. NDIS
driver not updating BSSID data is not really a supplicant issue, so that
is somewhat less interesting for me, but if the "wpa_cli scan" is
triggering wpa_supplicant to do something incorrectly, that should be
fixed.


On Thu, Nov 03, 2005 at 07:06:18AM -0500, Bryan Kadzban wrote:

> I've since tried a couple things.  Using ap_scan=1 instead of 2 makes
> scanning not kill the connection at least -- although after some
> consideration, I think scanning every few minutes is probably not a
> great way to fix this issue.

WPA2 (and even roaming in general) actually assumes that drivers are
doing periodic background scanning.. However, this should not require
manual trigger. 

> Since the changing value is always the RSN capabilities field, and
> always the number of PTKSA/GTKSA replay counters, I changed the code to
> zero out those replay counter bits in both IEs just before it does its
> memcmp.  (I actually made a copy first, because I'm not sure what else
> those pointers are used for.)  This does work -- the client does come
> back after an AP restart changes that value.

Those replay counters are not really used for anything in the
supplicant.

> Does this have any security implication?  I don't think so (especially
> since I left the rest of the capabilities field as-is), but I don't know
> for sure; maybe someone else here does?

Doing this kind of masking of the IEs is against the standard, but I
don't see it causing any security problems, so it should be fine as a
workaround for the driver not updating BSSID data.

> It's also only a temporary workaround, I think, until we can fix our APs
> to not change that IE.  But still, I'm not sure what the implications
> are security wise.  (I don't really completely understand what those
> replay counters do -- just watch for reused IVs?  then why would you
> need more than one per PTKSA?)

The APs are allowed to change WPA/RSN IE. Though, I have to admit it is
somewhat surprising thing to do if you did not change configuration
(disabled/enabled WMM) at that point.

WPA/RSN IE is just used to advertise how many replay counters are
supported. WMM needs four (i.e., one for each TX queue). I would assume
that most drivers ignore these values completely and use separate replay
counters regardless of what is being advertised.

The proper fix for the issue would be to fix the NDIS driver to update
its BSSID data to match with the latest Beacon/ProbeRsp frames received
from the AP.

-- 
Jouni Malinen                                            PGP id EFC895FA