Wism 4.1.185.0 and WCS 802.1x dynamic wep "rekey"

[bobtodd01]

I have been trying to find the command that can verify that wep keys are being dynamicly changed.

All the docs imply 802.1x does dyn wep but what command can I type on the wism cli to see that the kay has changed??

We are getting alarms from AirMagnet (which could be bugs) indicating that the keys are not changing.

I looked at show advanced eap and I also looked at some debug commands.

Can somebody point me at the correct command to somehow verify that a key is changing?

Thanks

Bob Todd

[wififofum]

Bob,

Great question. What have you seen in the 802.1x debugs? What is the exact wording of the AirMagnet alarm? What are the AAA retry/timeout settings and WLAN Session Timeout, User Idle Timeout? You are using LEAP? What driver versions?

Thanks for your feedback,

--Bruce Johnson

[bobtodd01]

Hi Bruce,

I haven't looked at the debugs because it looked like I might have to turn on a global debug which I was concerned about bringing down the wism. That was why I was asking for advice as to which debug to try and what cli comamnd might provide me the info I needed.

So any help on which cli commands or which debug commands to use is what I am after.

The AirMagnet alarm is: 802.1x rekey timeout too long.By monitoring the WLAN 802.1x authentication and encryption transaction, the system detected that AP 00:19:56:CC:D9:20 (Name: xxxx ; SSID : yyyy) does not rotate encryption keys. After monitoring the AP traffic on its channel for 4600 minutes, the system has not seen a single rekey message. The current threshold for raising this alarm is 60 minute(s). It is important for WLAN 802.1x configuration to include a reasonable encryption rekey timeout. A stale encryption key makes your encryption static and as vulnerable as static WEP key encryption. A rekey mechanism should be applied to unicast and/or multicast/broadcast streams that do not implement WEP key hashing algorithm such as TKIP (Temporal Key Integrity Protocol).

[wififofum]

Yes this might require a 802.11 packet debug which would be a bad thing. You should be able to debug a client via

debug mac addr

debug dot1x events enable

debug pem state enable

I hear you: the keys should be rotated as expected. I have seen some issues on the past with the Broadcast key being rotated as expected, but normally this is a show-stopper, and prevents acquiring a DHCP address.

I am seeing some issues of this kind as well, its like the 802.1x session timers aren't always in sync. Are you able to manually reauthenticate successfully? Are youusing PEAP or LEAP?

Have you tried using the WLC client troubleshooting feature available in 4.1? This is a GUI version of some of the client debug commands above.

Thanks for the info - keep us posted.

Regards,

--Bruce Johnson

[bobtodd01]

Sorry I fogot the protocol - We are using eap-ttls (not tls).

I don't see the problem as it is occuring. I am only getting the alarm from airmagnet.

I have looked at the client debugging feature but since we have no client complaining and I don't really know when or if it is happening.

I do know the mac-address of the client and the time from the AirMagnet alarm. What I was hoping was that I could somehow (cli command) look a client session???/history and see if the key did change and how many times it changed.

If there is a bug an it occurs once in a while I can "sort" of disregard or raise the threshold for the alarm (perhaps). BUT I really want to find out how bad the issue is. If I knew what command I could use to view key changes??? I could do some testing my self and verify my session had x # of successful key changes.... at least I would "feel" somewhat better!!

Bob

[wififofum]

Hey Bob,

You are going to need client data. Run a MAC-and-802.1x filtered trace using yourself as a client in AM for the duration of the WLAN Session Timeout.

What about the RADIUS server - can you get any logs showing re-authentications or trace level info? Doesn't TTLS use certificates? Are you looking for a block-cipher change?

Is there any chance AM is generating a false positive? Can you attach a print screen of the AM alert?

--Bruce

[bobtodd01]

Hi Bruce,

I can turn debugging on for the Radius server. That would involve large logs and sending them to our Radius vendor (InterlinkNetworks). Thats certainly doable but again - I'm not sure that I can pin down a session fast enough to trace it.

I used to look at re-authentication debugs from that access points in the past before we had lwaps.

ttls does use certificates on the radius server not in the client.

Finally - there is a very good chance that AM is generating a false positive. As for the print screen - the alarm description was from air magnet and was the one that I sent in the last email.

I will attach and AM screen shot of the alarm... but there is no real useful data there.

I think what I will do is set up a forensic trace of the alarm in AM and attack it that way unless you have other words of wisdom??

Thanks

Bob

[wififofum]

Thanks Bob,

What's the current WLAN Session Timeout - should be 1800 seconds by default. it looks like the AM alarm is indicating 1400? Check if its got a default threshold trigger for this.

You could decrease the WLAN Session Timeout value - briefly service impacting - to increase the probability of catching the reauth in a trace. You are not using AAA Override under the WLAN, correct? Otherwise if you have a Sesison Timeout there it would take precedence. The debug aaa events command should show what's being exchanged, and a show client detail should reveal what timeout the controller thinks the client is using.

[bobtodd01]

AAA Policy Override.............................. Disabled

Session Timeout.................................. 1800 seconds

I looked at AM and its threshold is 60 minutes... in fact the alarm indicates more...ALARM: After monitoring the AP traffic on its channel for 131 minutes, the system has not seen a single rekey message. The current threshold for raising this alarm is 60 minute(s).

show client detail did show 1800

I did a debug of aaa events and a do see authentications going through without accounting. I assume those are authentication rekeys?

I will also talk to AM about this... but you have provided me with enough to learn more.

Too bad show client detail didn't show whether there was a rekey!!

Thanks for your help Bruce... I think I learned quite a bit more than I knew.

Bob

[wififofum · Accepted solution]

Please rate helpful posts.