Binding on VLAN ID and PMKSA?
Last Post: September 11, 2007:
-
We have a Guest VLAN and a Production VLAN in our wireless network. Visitors are logging into Guest VLAN that they can only go to the Internet. Internal users are logging into Production VLAN that they can get to internal resources.
Incidents happened when a guest user dropped off from the Guest VLAN and requested association to the Production VLAN (using Production VLAN?¡é?€??s SSID). This guest user was put right into the Production VLAN without any 802.1x handshaking or authentication process. According to Engineer Support from the vendor, PKM cache is turned on in the AP. When the user dropped off, he can get in the same AP without any authentication check. Furthermore, PMK cache can not be turned off, because it?¡é?€??s part of 802.11i specification.
Does anyone know about those are true? If this is true, how other people implement VLANs in their APs? -
Something sounds fishy here. I bet the engineering support guy is just protecting his product by feeding you a line. They probably have some bug in their code that needs to be fixed. PMK caching would have nothing to do with this problem.
-
Ben,
Can you explain how re-association occurred? If both AP and Station have PMK cached, do they issue 802.1x request? Isn't 4-way handshake after 802.1x EAP authentication process? Which element in 802.11i binds with VLAN ID?
According to 802.11i spec (8.4.6.2)
If a non-AP STA in an ESS has determined it has a valid PMKSA with an AP to which it is about to
(re)associate, it includes the PMKID for the PMKSA in the RSN information element in the (Re)Association
Request. Upon receipt of a (Re)Association Request with one or more PMKIDs, an AP checks whether its
Authenticator has retained a PMK for the PMKIDs and whether the PMK is still valid. If so, it asserts possession of that PMK by beginning the 4-Way Handshake after association has completed; otherwise it begins a full IEEE 802.1X authentication after association has completed.
- 1