WPA2 - Received RSN IE with 0 PMKIDs from mobile

[idata]

Hello All,

I have a problem with roaming between Access Points Our setup uses RSA Tokens over Radius.

Client can connect properly, but when he roams to another AP, then the reauthentication is required again. To me it seems, that Intel PROSet client doesn't cache PMKIDs properly in RSN IE.

This is what I see in my logs on WLC:

.....

*Dec 20 09:59:10.968: 00:27:10:e0:43:00 Received EAP Response from mobile 00:27:10:e0:43:00 (EAP Id 8, EAP Type 25)

*Dec 20 09:59:10.968: 00:27:10:e0:43:00 Entering Backend Auth Response state for mobile 00:27:10:e0:43:00

*Dec 20 09:59:13.263: 00:27:10:e0:43:00 Processing Access-Challenge for mobile 00:27:10:e0:43:00

*Dec 20 09:59:13.263: 00:27:10:e0:43:00 Entering Backend Auth Req state (id=9) for mobile 00:27:10:e0:43:00

*Dec 20 09:59:13.263: 00:27:10:e0:43:00 Sending EAP Request from AAA to mobile 00:27:10:e0:43:00 (EAP Id 9)

*Dec 20 09:59:13.267: 00:27:10:e0:43:00 Received EAPOL EAPPKT from mobile 00:27:10:e0:43:00

*Dec 20 09:59:13.267: 00:27:10:e0:43:00 Received EAP Response from mobile 00:27:10:e0:43:00 (EAP Id 9, EAP Type 25)

*Dec 20 09:59:13.267: 00:27:10:e0:43:00 Entering Backend Auth Response state for mobile 00:27:10:e0:43:00

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Processing Access-Accept for mobile 00:27:10:e0:43:00

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Clearing Address 10.154.3.231 on mobile

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Applying site-specific override for station 00:27:10:e0:43:00 - vapId 11, site 'office', interface 'dummy'

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 0.0.0.0 8021X_REQD (3) Changing ACL 'dummy' (ACL ID 3) ===> 'dummy' (ACL ID 3) --- (caller apf_policy.c:1343)

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Inserting AAA Override struct for mobile

MAC: 00:27:10:e0:43:00, source 4

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 0.0.0.0 8021X_REQD (3) Changing ACL 'dummy' (ACL ID 3) ===> 'office' (ACL ID 2) --- (caller apf_policy.c:1343)

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Applying IPv6 Interface Policy for station 00:27:10:e0:43:00 - vlan 560, interface id 8, interface 'office'

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Setting re-auth timeout to 0 seconds, got from WLAN config.

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Station 00:27:10:e0:43:00 setting dot1x reauth timeout = 0

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Stopping reauth timeout for 00:27:10:e0:43:00

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Setting user timeout to 43200 seconds, got from AAA

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Session Timeout is 43200 - starting session timer for the mobile

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Stopping re-auth timeout timer

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Creating a PKC PMKID Cache entry for station 00:27:10:e0:43:00 (RSN 2)

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Adding BSSID 00:27:0d:8c:43:c1 to PMKID cache for station 00:27:10:e0:43:00

*Dec 20 09:59:13.307: New PMKID: (16)

*Dec 20 09:59:13.307: [0000] f8 42 91 7b ed 3b 9e 10 d1 5a b7 eb 3d eb 3c 77

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Disabling re-auth since PMK lifetime can take care of same.

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 CCKM: Create a global PMK cache entry

*Dec 20 09:59:13.307: 00:27:10:e0:43:00 Sending EAP-Success to mobile 00:27:10:e0:43:00 (EAP Id 9)

*Dec 20 09:59:13.308: Including PMKID in M1 (16)

*Dec 20 09:59:13.308: [0000] f8 42 91 7b ed 3b 9e 10 d1 5a b7 eb 3d eb 3c 77

*Dec 20 09:59:13.308: 00:27:10:e0:43:00 Starting key exchange to mobile 00:27:10:e0:43:00, data packets will be dropped

*Dec 20 09:59:13.308: 00:27:10:e0:43:00 Sending EAPOL-Key Message to mobile 00:27:10:e0:43:00

state INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00

*Dec 20 09:59:13.308: 00:27:10:e0:43:00 Entering Backend Auth Success state (id=9) for mobile 00:27:10:e0:43:00

....

(czc-hat-mohe-01) >show pmk-cache all

PMK-CCKM Cache

EntryType Station Lifetime VLAN Override IP Override------ -------------- -------- ------------------ ---------------CCKM 00:27:10:e0:43:00 43175 office 0.0.0.0

So PMKID is included, but when clients moves to another AP, the logs looks like these:

*Dec 20 09:59:15.069: 00:27:10:e0:43:00 DHCP successfully bridged packet to STA

*Dec 20 10:00:47.941: 00:27:10:e0:43:00 Reassociation received from mobile on AP 00:24:14:8b:dd:80*Dec 20 10:00:47.941: 00:27:10:e0:43:00 Applying site-specific IPv6 override for station 00:27:10:e0:43:00 - vapId 11, site 'office', interface 'dummy'*Dec 20 10:00:47.941: 00:27:10:e0:43:00 Applying IPv6 Interface Policy for station 00:27:10:e0:43:00 - vlan 4094, interface id 11, interface 'dummy'*Dec 20 10:00:47.941: 00:27:10:e0:43:00 Applying site-specific override for station 00:27:10:e0:43:00 - vapId 11, site 'office', interface 'dummy'*Dec 20 10:00:47.941: 00:27:10:e0:43:00 10.154.3.231 RUN (20) Changing ACL 'dummy' (ACL ID 3) ===> 'dummy' (ACL ID 3) --- (caller apf_policy.c:1343)*Dec 20 10:00:47.942: 00:27:10:e0:43:00 STA - rates (8): 130 132 139 150 12 18 24 36 48 72 96 108 0 0 0 0*Dec 20 10:00:47.942: 00:27:10:e0:43:00 STA - rates (12): 130 132 139 150 12 18 24 36 48 72 96 108 0 0 0 0*Dec 20 10:00:47.942: 00:27:10:e0:43:00 Processing RSN IE type 48, length 18 for mobile 00:27:10:e0:43:00*Dec 20 10:00:47.942: 00:27:10:e0:43:00 CCKM: Mobile is using CCKM*Dec 20 10:00:47.942: 00:27:10:e0:43:00 Received RSN IE with 0 PMKIDs from mobile 00:27:10:e0:43:00

I've tested also supplicant from Juniper and there it works fine.

My version of Intel PROSet is latest 13.4

Any ideas?

Regards

Karel

[idata]

I'm having this exact same problem. According to Cisco, Intel Proset does not support PKC. Juniper does (which you and I have both tested) but that does not help me much as we're not going to pay for a wifi client.

Any one know if Intel is going to support PKC?

[idata]

Thanks god for you, I started to thought that I'm only one on whole planet ...

No idea ... I've opened a ticket at Intel side, filled a form and since that time no answer regarding this issue.

My latest findings was also that Juniper Odyssey Client has the same problem on Windows 7 as this is not natively supported by Microsoft (or at leasts this was the answer from Juniper support and they cannot do much about it).

Regards

Karel