Have you ever get complaints from users stating “Network is too slow” ? how do you measure network throughput in your environment ? It is always good idea to benchmark your network(wired or wireless) performance. In this way when a user complaint about slowness, you can run a quick test again & compare it with your baseline performance results.

Iperf is great network performance testing tool (free :smile: )you can use to measure throughput of a given network. In this post we will see how we can use it to measure wireless network performance. We will primarily focus on wireless performance testing & will use shown topology diagram where few different type of clients connect to my converged access setup.

I have used a wired connected window PC as my iPerf server. You can simply download jperf from here. Once you download jperf-2.0.2 you can copy that onto your computer C: drive as shown below.

Once you do this you can go to “C:\jperf-2.0.2\bin” in the command prompt as shown below.

If you want to use it as “Iperf Server” you have to use “iperf -s” syntax. If you want to set it as “Iperf client” then you have to use “iperf -c <server-ip-address>” There are optional parameters you can set. You can view all of these “iperf -h” as shown below.

Prior to measure wireless performance you need to make sure your wired network won’t be a bottleneck. Sometime there may be QoS policies throttling standard UDP/TCP port numbers used in this application. So it is good idea to benchmark using wired connection first & them move to wireless performance.

In my case I have connected my laptop onto 3850-1 via 1G Ethernet & run it as Iperf client. I have used 1s interval , 1MB as TCP window size & run it for 2min (120s),sometime if you leave default TCP window size, your throughput will reduced. So test it & use a value that gives close to expected results.

When you read this test result shown in below, it tells you about bandwidth available from iperf client to iperf server (ie client upload & server download). As you can see I got ~900Mbps.

C:\jperf-2.0.2\bin>iperf -c x.x.13.31 -i 1 -t 120 -w 1M
------------------------------------------------------------
Client connecting to x.x.13.31, TCP port 5001
TCP window size: 1.00 MByte
------------------------------------------------------------
[168] local x.x.13.20 port 56898 connected with x.x.13.31 port 5001
[ ID] Interval       Transfer     Bandwidth
[168]  0.0- 1.0 sec   105 MBytes   885 Mbits/sec
[168]  1.0- 2.0 sec   105 MBytes   881 Mbits/sec
[168]  2.0- 3.0 sec   112 MBytes   939 Mbits/sec
[168]  3.0- 4.0 sec   107 MBytes   897 Mbits/sec
[168]  4.0- 5.0 sec   106 MBytes   888 Mbits/sec
[168]  5.0- 6.0 sec   109 MBytes   914 Mbits/sec
.
.
[168] 110.0-111.0 sec   108 MBytes   906 Mbits/sec
[168] 111.0-112.0 sec   111 MBytes   933 Mbits/sec
[168] 112.0-113.0 sec   109 MBytes   916 Mbits/sec
[168] 113.0-114.0 sec   111 MBytes   927 Mbits/sec
[168] 114.0-115.0 sec   108 MBytes   908 Mbits/sec
[168] 115.0-116.0 sec   111 MBytes   934 Mbits/sec
[168] 116.0-117.0 sec   111 MBytes   930 Mbits/sec
[168] 117.0-118.0 sec   111 MBytes   930 Mbits/sec
[168] 118.0-119.0 sec   111 MBytes   933 Mbits/sec
[168] 119.0-120.0 sec  76.4 MBytes   641 Mbits/sec
[168]  0.0-120.0 sec  12.6 GBytes   903 Mbits/sec

To measure the client download, you can run “iperf -s” on the PC you ran as client previously. I have used 1M as TCP window size. This time  you have to run “iperf -c x.x.13.20” command on the other PC.

C:\jperf-2.0.2\bin>iperf -s -w 1M
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 1.00 MByte
------------------------------------------------------------
[268] local x.x.13.20 port 5001 connected with x.x.13.31 port 58151
[ ID] Interval       Transfer     Bandwidth
[268]  0.0-120.0 sec  11.5 GBytes   823 Mbits/sec

You can export these data onto excel & graph it for nice representation.(you can simply hold Alt button in windows & copy only the data rate values :) ). So here is my graph look like for wired bandwidth performance.

Let’s see now how can we measure the wireless performance. In my case I have created a SSID (Open Auth simpliciy) on my 3850 MA & 3700 AP register to it. So this is the simplest without any QoS policies on it.

wlan ABC 20 ABC
 no broadcast-ssid
 client vlan 1410
 no security wpa
 no security wpa akm dot1x
 no security wpa wpa2
 no security wpa wpa2 ciphers aes
 no shutdown

My AP is running on power level 5 & DCA channel width set to 80MHz. You can verify it shown as below

3850-2#show ap dot11 5ghz summary 
AP Name            MAC Address     Slot  Admin State  Oper State  Channel             Width  TxPwr   
---------------------------------------------------------------------------------------------------
3702-1             b838.6184.c670     1  Enabled      Up          (161,157,149,153)*     80    5(*)  

Here I have connected a MacBookAir,Nexus 5 phone, Dell E6430, Dell E7440 to my AP for testing. You can get the details of client RSSI/SNR from the switch itself. I had trouble with AC-7260 driver getting this detail & this NIC/driver is giving some grievance to many of us(Here is some detail & I am using  17.0.5.8 driver version in this NIC)

3850-2#show wireless client summary                                          
Number of Local Clients : 4
MAC Address    AP Name      WLAN State              Protocol 
---------------------------------------------------------------
6067.2077.5470 3702-1        20   UP                 11n(5) <-Dell E6430   
8086.f2cd.3c5f 3702-1        20   UP                 11ac <-Dell E7440     
bcf5.acfe.eb1c 3702-1        20   UP                 11ac <-Nexus 5
8438.3540.2100 3702-1        20   UP                 11ac  <-MBA 

**** MBA ****
3850-2#sho wireless client mac-address 8438.3540.2100 detail | in Signal|Rate
Current Rate : 12.0
Supported Rates : 12.0,24.0,36.0,48.0,54.0,12.0,24.0,36.0,48.0,54.0
  Radio Signal Strength Indicator : -40 dBm
  Signal to Noise Ratio : 52 dB

**** NEXUS 5 ****
3850-2#sho wireless client mac-address bcf5.acfe.eb1c detail | in Signal|Rate
Current Rate : m7
Supported Rates : 12.0,24.0,36.0,48.0,54.0,12.0,24.0,36.0,48.0,54.0
  Radio Signal Strength Indicator : -29 dBm
  Signal to Noise Ratio : 58 dB

*** DELL E6430 (N6205) ****
3850-2#sho wireless client mac-address 6067.2077.5470 detail | in Signal|Rate
Current Rate : m15
Supported Rates : 12.0,24.0,36.0,48.0,54.0,12.0,24.0,36.0,48.0,54.0
  Radio Signal Strength Indicator : -29 dBm
  Signal to Noise Ratio : 63 dB

*** DELL 7440(AC-7260) different to all others ****
3850-2#sho wireless client mac-address 8086.f2cd.3c5f detail | in Signal|Rate
Supported Rates : 12.0,24.0,36.0,48.0,54.0,12.0,24.0,36.0,48.0,54.0
  Radio Signal Strength Indicator : Unavailable
  Signal to Noise Ratio : Unavailable

Now on your wireless client (first in MacBookAir) if you run “iperf -c x.x.13.20 -i1 -t 120 -w 1M” you can measure the wireless client upload performance. As you can see below I got average 294 Mbps for wireless upload speed for this client.

Something:~ $ iperf -c x.x.13.20 -i1 -w 1M -t 120
------------------------------------------------------------
Client connecting to x.x.13.20, TCP port 5001
TCP window size: 1.00 MByte (WARNING: requested 1.00 MByte)
------------------------------------------------------------
[  4] local 10.141.96.19 port 54005 connected with x.x.13.20 port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 1.0 sec  28.8 MBytes   241 Mbits/sec
[  4]  1.0- 2.0 sec  44.8 MBytes   375 Mbits/sec
[  4]  2.0- 3.0 sec  40.9 MBytes   343 Mbits/sec
[  4]  3.0- 4.0 sec  38.2 MBytes   321 Mbits/sec
[  4]  4.0- 5.0 sec  39.9 MBytes   334 Mbits/sec
[  4]  5.0- 6.0 sec  43.2 MBytes   363 Mbits/sec
.
.
[  4] 117.0-118.0 sec  42.9 MBytes   360 Mbits/sec
[  4] 118.0-119.0 sec  49.5 MBytes   415 Mbits/sec
[  4] 119.0-120.0 sec  42.6 MBytes   358 Mbits/sec
[  4]  0.0-120.0 sec  4.10 GBytes   294 Mbits/sec

If you run “iperf -s  -w 1M” on my MBA & run “iperf -c 10.141.96.19 -i 1 -t 120 -w 1M” command on wired PC I can measure the wireless client download performance. Here is the wireless download performance (avg 304 Mbps) for MBA

C:\jperf-2.0.2\bin>iperf -c 10.141.96.19 -i 1 -t 120 -w 1M
------------------------------------------------------------
Client connecting to 10.141.96.19, TCP port 5001
TCP window size: 1.00 MByte
------------------------------------------------------------
[168] local x.x.13.20 port 55232 connected with 10.141.96.19 port 5001
[ ID] Interval       Transfer     Bandwidth
[168]  0.0- 1.0 sec  53.3 MBytes   447 Mbits/sec
[168]  1.0- 2.0 sec  48.2 MBytes   404 Mbits/sec
[168]  2.0- 3.0 sec  48.3 MBytes   405 Mbits/sec
[168]  3.0- 4.0 sec  49.5 MBytes   415 Mbits/sec
[168]  4.0- 5.0 sec  51.6 MBytes   433 Mbits/sec
[168]  5.0- 6.0 sec  52.6 MBytes   442 Mbits/sec
[168]  6.0- 7.0 sec  53.5 MBytes   449 Mbits/sec
.
.
[168] 116.0-117.0 sec  43.3 MBytes   364 Mbits/sec
[168] 117.0-118.0 sec  40.9 MBytes   343 Mbits/sec
[168] 118.0-119.0 sec  43.8 MBytes   367 Mbits/sec
[168] 119.0-120.0 sec  11.2 MBytes  93.9 Mbits/sec
[168]  0.0-120.2 sec  4.26 GBytes   304 Mbits/sec

For any Android device you can install iperf application from Play Store for free :smile: & then you can run these iperf client server commands. Here is a snapshot of Nexus 5 phone running as iperf client. For iOS device you have to pay ;(

Like this I have run this performance testing for all those clients mentioned & export that data onto excel. So here is the result I got for 3 clients who supports 802.11ac. As expected, MBA gave me the best performance out of these 3 devices.As you can see below I got less than 100Mbps (less than 1/3 of equivalent MBA) download speed for Intel AC7260 (though it is two spacial stream client). Even Nexus 5 (single SS clinet) performed much better in downloads. You may surprised :shock: by this result, but such is the way of life with this Intel 7260 driver.

Just to compare, I have done the test with Intel N6205 (802.11n) & compare the result with Intel N7260(802.11ac 2 SS). As you can see below you will get marginal differences between those two.

Hope this is useful to you as well. When next time you get a slowness  complaint, always measure network performance like this.

PS: There are lots of commercial apps available if you willing to pay for these type of testing. I have given you a simpler method & cost you nothing, but you have to do some manual work.

 related posts

1. 802.11ac with Cisco 3700AP

In this post we will see how to decrypt WPA2-PSK traffic using wireshark. This is useful when you study (my case for CWSP studies) different security protocols used in wireless.Here is the basic topology for this post.

Before start capturing you should know which channel your AP is operating. Since my AP is managed by WLC 4400, I can simply get that info from CLI. Otherwise you can simply use application like InSSIDer to see which channel given SSID is operating. I am using 5GHz & therefore get 802.11a summary here (If you want sniff 2.4GHz, then you can issue command with 802.11b)

(4402-3) >show ap config 802.11a summary
AP Name                SubBand RadioMAC            Status     Channel   PwLvl   SlotId 
--------------------   ------- ------------------  --------   -------   ------  ------ 
LAP1                      -    64:a0:e7:af:47:40   ENABLED    36        1       1

Simply what you have to do is take a “wireless packet capture” on CH 36 as my AP operate in that channel. I have used BackTrack with USB adapter to take this packet capture (Refer this youtube video for how to do it). It is just simple 2-3 line configuration required to set up a USB adapter as monitor interface for wireshark.

root@bt:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:21:9b:62:d0:4a  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:21 Memory:fe9e0000-fea00000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:66 errors:0 dropped:0 overruns:0 frame:0
          TX packets:66 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4665 (4.6 KB)  TX bytes:4665 (4.6 KB)

root@bt:~# ifconfig wlan2 up
root@bt:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:21:9b:62:d0:4a  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:21 Memory:fe9e0000-fea00000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:66 errors:0 dropped:0 overruns:0 frame:0
          TX packets:66 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4665 (4.6 KB)  TX bytes:4665 (4.6 KB)

wlan2     Link encap:Ethernet  HWaddr 00:20:a6:ca:6b:b4  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@bt:~# iwconfig wlan2 channel 36
root@bt:~# iwconfig
wlan2     IEEE 802.11abgn  ESSID:off/any  
          Mode:Managed  Frequency:5.18 GHz  Access Point: Not-Associated   
          Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          
lo        no wireless extensions.

eth0      no wireless extensions.

root@bt:~# airmon-ng start wlan2
Found 1 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID    Name
1158    dhclient3
Interface    Chipset        Driver

wlan2        Atheros AR9170    carl9170 - [phy2]
                (monitor mode enabled on mon0)

Once you do this you can open wireshark application & select the interface named “mon0” for wireless packet capturing.

Here is my packet capture (WPA2-PSK-Final) You can open this in wireshark to test this out by yourself. Now if you analyze this you would see “4-way handshake (EAPOL-Messages 1 to 4)” messages exchanged after Open Authentication phase finished (Auth Request, Auth Response, Association Request, Association Response). Once 4 way handshake is completed, both client & AP having required key for data encryption. So that point onwards all your data frames (not management frames, null frames) are encrypted using CCMP/AES.As you can see below, data frames are encrypted & you cannot see what traffic it is. I have taken frame 103 for example.Before we go & decrypt these messages, it is very important to understand that you have to properly capture  “4-way handshake messages” in your sniffer in order to decrypt using wireshark. If you are not capture M1-M4 messages successfully, wireshark will not be able to derive all the keys to decrypt rest of that data. Here is one example where all the frames has not been captured properly in 4-way handshake process (This happened when I was using same USB adapter with Fluke WiFi Analyzer)Now you have to go to “Edit -> Preferences -> Protocol -> IEEE 802.11” & need to “Enable Decryption” checkbox. Then click on Edit “Decryption Keys” section & add your PSK by click “New“.  You have to select Key-type as “wpa-pwd” when you enter the PSK in plaintext.

If you enter the 256bit encrypted key then you have to select Key-type as “wpa-psk“.If you want to get the 256bit key (PSK) from your passphrase, you can use this page. It use the following formula to do this conversion

PSK=PBKDF2(PassPhrase, SSID,SSIDLength,4096,256)

Here is 256bit PSK derived from above

I have used simple plaintext password (ie wpa-pwd key type) in below. You can simply enter the plaintext password only (without SSID name).In this case wireshark try to use last seen SSID, It is always good practice to use <password:SSID>.

I have used my configured PSK “Cisco123Cisco123” & specify my SSID as “TEST1“. Refer this document for more details of this settings.

Then you need to hit “Apply“

As you can see below, now you will able to see the traffic inside these data frames. Here is the same frame (103) which you saw earlier in encrypted format, but now wireshark able to decrypt it.Now if you look further you will see the client is getting IP through DHCP (DORA-Discover, Offer, Request, ACK) & then register to a CME (SKINNY protocol) & then establish a voice call (RTP) details. Now you can analyses these packets in detail

This trick may be useful to you when you do wireless troubleshooting on your PSK networks.

References
1. 802.11 Sniffer Capture Analysis – WPA/WPA2 with PSK or EAP
2. 802.11 Sniffer Capture Analysis -Wireshark filtering
3. 802.11 Sniffer Capture Analysis – Management Frames and Open Auth
4. 802.11 Sniffer Capture Analysis – Physical Layer
5. 802.11 WLAN Roaming and Fast-Secure Roaming on CUWN (DOC116493)

Related Posts

1. Free Wireless Packets Capture
2. Wireshark captures in 3850

Did you ever wanted to find out inventory details of the SFP plugged into WLC ports ? Typically “show inventory” is what we need. But in AireOS, that command only give the Chassis serial Number as shown below.

(5508-1) >show inventory 
Burned-in MAC Address............................ 64:00:F1:F5:B0:80
Power Supply 1................................... Present, OK
Power Supply 2................................... Present, OK
Maximum number of APs supported.................. 250
NAME: "Chassis"    , DESCR: "Cisco 5500 Series Wireless LAN Controller"
PID: AIR-CT5508-K9,  VID: V02,  SN: FCW1519L0B1

This CSC forum thread give a very useful CLI command (debug fastpath cfgtool –dump.sfp)  you can run on AireOS WLC to get that information.

Here is a sample output

(5508-WC01) >debug fastpath cfgtool --dump.sfp
(5508-WC01) >FP0.
Port SFP Vendor       Transceiver Type    OUI PartNumber       Rev  SerialNumber     DateCode Auth
   1 CISCO-OEM        (0x02)1000BaseLX        GLC-LH-SM-CRB    2.0  ZZ120607419      120607   ok      
   2 CISCO-OEM        (0x02)1000BaseLX        GLC-LH-SM-CRB    2.0  ZZ120607423      120607   ok      
   3 CISCO-OEM        (0x02)1000BaseLX        GLC-LH-SM-CRB    2.0  ZZ120607425      120607   ok      
   4 CISCO-OEM        (0x02)1000BaseLX        GLC-LH-SM-CRB    2.0  ZZ120607424      120607   ok      
   5 CISCO-EQUIV      (0x02)1000BaseLX        GLC-LH-SM-CRB    2.0  ZZ121008094      121008   ok      
   6 CISCO-EQUIV      (0x02)1000BaseLX        GLC-LH-SM-CRB    2.0  ZZ121008093      121008   ok      
   7 CISCO-EQUIV      (0x02)1000BaseLX        GLC-LH-SM-CRB    2.0  ZZ121008095      121008   ok      
   8 CISCO-EQUIV      (0x02)1000BaseLX        GLC-LH-SM-CRB    2.0  ZZ121008096      121008   ok      
FP0.

Here is another example

(5508-WC02) >debug fastpath cfgtool --dump.sfp
(5508-WC02) >FP0.
Port SFP Vendor       Transceiver Type    OUI PartNumber       Rev  SerialNumber     DateCode Auth
   1 CISCO-FINISAR    (0x02)1000BaseLX        FTLF1318P2BCL-C3 A    FNS15400WH6      110927   ok      
   2 CISCO-FINISAR    (0x02)1000BaseLX        FTLF1318P2BCL-C3 A    FNS15400PCE      110926   ok      
   3 CISCO-FINISAR    (0x02)1000BaseLX        FTLF1318P2BCL-C3 A    FNS15400B2U      110925   ok      
   4 CISCO-FINISAR    (0x02)1000BaseLX        FTLF1318P2BCL-C3 A    FNS15400QRR      110926   ok      
   5 CISCO-FINISAR    (0x02)1000BaseLX        S210             11.0 S21010121511     101215   ok      
   6 CISCO-FINISAR    (0x02)1000BaseLX        S210             11.0 S21010121576     101215   ok      
   7 CISCO-FINISAR    (0x02)1000BaseLX        S210             11.0 S21010121580     101215   ok      
   8 CISCO-FINISAR    (0x02)1000BaseLX        S210             11.0 S21010121571     101215   ok      
FP0.

Just to make it complete, if it is any IOS WLC platform you can run “show inventory raw” command you can get that information. Here is an example form a 5760.

5760-1#show inventory raw | in SFP-
NAME: "TenGigabitEthernet1/0/3", DESCR: "SFP-10GBase-LR"
PID: SFP-10G-LR         , VID: V02  , SN: ONT151702VS    
NAME: "TenGigabitEthernet1/0/4", DESCR: "SFP-10GBase-LR"
PID: SFP-10G-LR         , VID: V02  , SN: ONT151702VE    
NAME: "TenGigabitEthernet1/0/5", DESCR: "SFP-10GBase-LR"
PID: SFP-10G-LR         , VID: V02  , SN: FNS16150BWF    
NAME: "TenGigabitEthernet1/0/6", DESCR: "SFP-10GBase-LR"
PID: SFP-10G-LR         , VID: V02  , SN: FNS170701E6

Here is similar output from 3850

3850-1#show inventory raw | in SFP-
NAME: "TenGigabitEthernet1/1/3", DESCR: "SFP-10GBase-LR"
PID: SFP-10G-LR         , VID: V01  , SN: SLK02742740BH  
NAME: "TenGigabitEthernet2/1/3", DESCR: "SFP-10GBase-LR"
PID: SFP-10G-LR         , VID: V02  , SN: FNS17420M9K 

This may be a useful command to remember if anyone asked this info from you.

In this post we will go through 4-Way Handshake process. This is described in Chapter 5 of CWSP Official Study Guide. Page 194 of this book shows the RSN key hierarchy.

MSK-Master Session Key ( or AAA Key):
Key information that is jointly negotiated between the Supplicant & Authentication Server. This key information is transported via a secure channel from Authenticating Server to Authenticator.

PMK-Pairwise Master Key:
PMK is derived from MSK seeding material. PMK is first 256bits (0-255) of MSK. It can be derived from an EAP method or directly from a PresharedKey(PSK).

GMK-Group Master Key:
GMK is randomly created on Authenticator & refresh it in configured time interval to reduce the risk of GMK being compromised.

PTK-Pairwise Transient Key:
A value derived from PMK,Authenicator nonce(Anonce),Supplicant nonce(Snonce), Authenticator Address, Supplicant Address. This is used to encrypt all unicast transmission between client & an AP. PTK consist of 5 different keys

1. KCK-Key Confirmation Key-used to provide data integrity during 4 -Way Handshake & Group Key Handshake.
2. KEK – Key Encryption Key- used by EAPOL-Key frames to provide data privacy during 4-Way Handshake & Group Key Handshake.
3. Temporal Key – used to encrypt & decrypt MSDU of 802.11 data frames between supplicant & authenticator
4. Temporal MIC-1
5. Temporal MIC-2

GTK-Group Temporal Key:
GTK is used to encrypt all broadcast/multicast transmission between an AP & multiple client statsions. GTK is derived on Authenticator & sending to supplicant during 4-Way Handshake (M3)

4-Way handshake utilizing EAPOL-Key frames initiated by the Authenticator to do the following.
1. Confirm that live peer holds PMK
2. Confirm that PMK is current.
3. Derive a fresh PTK from PMK & Install the pairwise encryption & integrity keys into 802.11
4. Transport the GTK & GTK sequence number from Authenticator to Supplicant & install them in Supplicant & AP(if not already installed)
5. Confirm cipher suite selection.

If it is PSK,  4 way handshak starts immediately after Open System Authentication & Association state finish as you can see below.

If it is 802.1X/EAP, then 4 way handshake starts when EAP Authentication finished.

Below figure shows the steps involved in 4-Way handshake process. This CWNP video explain well this process & have a look on it before go into details.

Here is the details about each step.

Message 1 (M1)
* Authenticator sends EAPOL-Key frame containing an ANonce(Authenticator nonce) to supplicant.
* With this information, supplicant have all  necessary input to generate PTK using pseudo-random function(PRF)

Message 2 (M2)
* Supplicant sends an EAPOL-Key frame containing SNonce to the Authenticator.
* Now authenticator has all the inputs to create PTK.
* Supplicant also sent RSN IE capabilities to Authenticator & MIC
* Authenticator derive PTK & validate the MIC as well.

Message 3 (M3)
* If necessary, Authenticator will derive GTK from GMK.
* Authenticator sends EAPOL-Key frame containing ANonce, RSN-IE & a MIC.
* GTK will be delivered (encrypted with PTK) to supplicant.
* Message to supplicant to install temporal keys.

Message 4 (M4)
* Supplicant sends final EAPOL-Key frame to authenticator to confirm temporal keys have been installed.

From this point onwards data frame MSDU will be encrypted using PTK or GTK (depending upon unicast or multicast/broadcast frame)

References
1. WPA2-PSK-Final -Sample Packet Capture (Frame 93-99 shows M1-M4 EAPOL-key frames)
2. CWSP Official Study Guide
3. http://www.my80211.com/cwsp-george-stefanick/
4. 802.11i AKM CWNP- White Paper

Related Post

1. CWSP – L2 Encryption Method:WEP
2. CWSP – L2 Encryption Method:CCMP
3. CWSP – L2 Encryption Method:TKIP
4. CWSP – RSN Information Element
5.
6.

In IEEE 802.11-2007 standard define 3 encryption methods that operate at layer 2 of OSI model (WEP, TKIP, CCMP). These used to encrypt upper layer information of 802.11 data frames what has MSDU payload. They all use symmetric algorithms where WEP,TKIP use RC4 cipher while CCMP use AES cipher.

Here is the details about CCMP  (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol)

*  AES is a block cipher based on Rijndael algorithm.
*  Algorithm allows for a selection of block sizes & key sizes (128,192 & 256 bits for each), when NIST adopted for AES, it specified only 128 bit block size.
* IEEE 802.11-2007 standard restricts both the key size & block length to 128 bits.
* To make use of a block cipher a method used to convert messages to blocks referred as block cipher’s “mode of operation“
* CCMP uses a mode called “CCM-Counter Mode + CBC-MAC” which itself based on “Counter Mode-CTR“
* Counter mode encrypt the value of an arbitrary value called the “counter” & then XOR the result with the data to produce ciphertext.
* Counter is generally incremented by 1 for each successive block processed.
* Counter might start at an arbitrary value & might increment by some other value or pattern (not same as shown above)
* Receiving party who wants to decrypt the message must know the starting value of counter & rules for advancing it.
* In counter mode, decryption is exactly same process as encryption because XOR the same value twice takes you back to the original value (so easy to implement)
* Encryption can be done completely in parallel as counter values are known at the start.
* Basic counter mode does not provide any message authentication, only encryption.(so RSN, additional capability must be added)
* CCM uses counter mode in conjunction with message authentication method called “cipher block chaining - CBC“.
* CBC is used to produce a message integrity code(MIC)
* MIC is called message authentication code by cryptographic community leading to CBC-MAC (in IEEE 802.11-2007 standard it is CBC-MIC to avoid confusion with MAC)
* In CBC-MIC, take the 1st block & encrypt it using AES, XOR the result with 2nd block & then encrypt the result  & XOR the result with next block & encrypt it .. so on.
* If one or more bits were changed, computed MIC is different ( provide msg authenticity)
* MSDU will be fragmented into MPDU & assign its own 802.11 header.
* Each MPDU is processed by the CCMP algorithm to generate a new encrypted MPDU.
* Only data part is encrypted, not the header. But MIC provide data integrity for both MSDU data & portions of MAC header of the MPDU.

* CCMP header prepend encrypted data & transmitted in clear text. It has two purpose
1.  48 bit Packet Number (PN) provides replay protection & enable receiver to derive vlaue of the “nonce” used for encryption.
2.  In the case of multicast, it tells the receiver which group key has been used.

* CCMP header is very similar to TKIP header & it was intentionally done in that way to simplify the implementation of TKIP & CCMP mixed environment.
* Out of 8 byte CCMP header, 6 used for PN, 1 reserved & remaining byte contain key ID values (2 bits for key id)
* The bit next to the Key-ID is set to 1 (Ext IV in TKIP) to indicate that the frame format is RSN rather than earlier WEP format.
* In CCMP first block of CBC-MAC is not directly taking from MPDU, but formed in special way using “nonce” value.

* 104 bit “nonce” is formed using Packet Number(PN), Transmitter Address (TA) & priority bits in QoS.
* “flag” field has a fixed value of 01011001 and indicates that the MIC is 64 bits.
* “Dlen” indicate length of the plain text data.
* Additional Authentication Data (AAD) is constructed from portion of MPDU header

* 128 bit counter value is constructed using “nonce” & “Flag” & “Ctr” field
* CCMP  encryption & data integrity process is like below

1. 48 bit PN crated & incrementing with each MPDU
2. AAD created using MPDU header
3. Nonce is created using PN, TA & QoS filed.
4. 8 byte CCMP header is constructed
5. CCM which use AES block cipher used to created integrity check (8 byte-MIC) & encrypt upper layer data
6. Original MAC header is append to CCMP header.
7. FCS is calculated over all the fields of the header & entire frame body.

References
1. CWSP Official Study Guide
2. Real 802.11 Security: Wi-Fi Protected Access and 802.11i

Related Posts

1. CWSP – L2 Encryption Method:WEP
2. CWSP – L2 Encryption Method:TKIP
3. CWSP – 4 Way Handshake
4. CWSP – RSN Information Element
5.
6.

Here is my study notes from CWSP-Official Study Guide – Chapter 2.

There two legacy (Pre-RSNA) authentication methods.

1. Open System Authentication
2. Shared Key Authentication.

In Open System Authentication there are 4 frames exchanged between client & AP.Here is a wireless packet capture showing these frame exchange (I have configured an Open SSID called “ABC” & then join the client to that while capturing on the AP channel)

As you can see above, client starts the process by sending “Authentication Request” frame to Access Point (frame 1246 in the above). Note that it is a management frame with subtype 11  [You can filter these in wireshark with (wlan.fc.type == 0)&&(wlan.fc.type_subtype == 0x0b) ] going from client to AP. Authentication Algorithm is “Open System” & Sequence Number is “1” indicating it is the “Authentication Request” frame.

Then AP respond with Authentication Response (frame 1248). As you can see below it has sequence number “2” indicating it is a response frame.

Then Client Station sends “Association Request-Management frame subtype 0″ frame specifying its client capability. You can filter those in wireshark using (wlan.fc.type == 0)&&(wlan.fc.type_subtype == 0x00) filter.

Then AP  responds with “Association Response- Managemet frame with subtype 1″. You can see status code “successful” & association ID has been given. Association response frame can be filtered using (wlan.fc.type == 0)&&(wlan.fc.type_subtype == 0x01) in wireshark.

Now lets see how “Shared Key Authentication” works. Shared Key Authentication uses WEP(Wireless Equivlanet Privacy) to authenticate client stations & that require a static WEP key configured on both AP & Client. Here is the frame exchange in this “Shared Key Authentication” mechanism.

Below shows a sample wireless capture during “shared key authentication”

As you can see this time we will have 4 authentication frames. First client send the “Authentication Request” to the AP. You can see the “SEQ No is 1” for this frame & Authentication algorithm is “Shared Key“.

Then AP sends a cleartext challenge to the client station in an authentication response. You will notice the SEQ number is “2” & challenge Text is included.The client station then encrypt the cleartext challenge and sends it back to the AP in the body of another authentication request frame. You will see the WEP header information with encrypted data.

By using the WEP key in wireshark you should be able to decrypt this message. Then you will see something like this. As you can see, it is the Sequence number 3 where AP send cleartext was encrypted using WEP.

Once AP get the WEP encrypted authentication message 3, AP decrypt station response & compare it with the cleartext challenge.If they match AP will respond by sending forth & final authentication frame to the station.

From this point onwards, all the data frame will be encrypted using same WEP key used for authentication.

WEP encryption process steps as below.

* 24 bit cleartext IV(Initialization Vector) is randomly generated & combined with static secret key.
* key length is 40bits in 64bit WEP & key length would be 104bits in 128bit WEP.
* IV & Key with RC4 pseudo-random algorithm generate a keystream.
* Resulted key stream are then combined with plaintext data bits using XOR process.
* End result is the WEP ciphertext.
* WEP also run CRC on plaintext data & append as 32 bit ICV(Integrity Check Value) to the end  of plain text data.
* WEP add 8 byte (4-IV, 4-ICV) encryption overhead resulting max MSDU from 2304 to 2312 bytes.

As you can see below WEP initialization vector (IV) include the WEP KEY ID details where receiving device can identify which key has been used for encryption.(so it can properly decrypt traffic). Also note that MSDU & ICV information will be go as encrypted text.

Since WEP has following drawbacks it has been deprecated from using. (TKIP developed to address these issues)
1. IV Collision Attack – 24bit IV it is possible IV collisions occur & an attacker can recover WEP key easily.
2. Weak Key attack -
3. Reinjection Attack – Tools exist that implement a packet injection attack to accelearate the collection of weak IV on a network with little traffic.
4. Bit-Flipping Attack – ICV data integrity check is considered weak.

 Related Posts

1. CWSP – L2 Encryption Method:CCMP
2. CWSP – L2 Encryption Method:TKIP
3. CWSP – 4 Way Handshake
4. CWSP – RSN Information Element
5.
6.

RSN-IE (Robust Security Network Information Element) is an optional field of variable length that can be found in 802.11 management frames.RSN element has an element ID of 48 & present in below different management frames

1. Beacon frames.(send by AP)
2. Probe Response frames.(send by AP)
3. Association Request frames.(send by Client)
4. Reassociation Request frames (Send by client)

All 802.11 radios will use one cipher (pairwise) suit for unicast encryption  & another cipher(group) for encrypting multicast/broadcast traffic. Below are the different cipher suite values.

00-0F-AC-04 (CCMP) is the default
00-0F-AC-02 (TKIP) is optional.
00-0F-AC-01 (WEP-40)
00-0F-AC-05 (WEP-104)

When station supports several ciphers, it always chooses the stronges one first (ie CCMP, TKIP, WEP-104, WEP-40)

RSN-IE also used to indicate what authentication methods are supported. The Authentication Key Management (AKM) suite indicate whether the station support 802.1X or PSK authentication. Below are the two AKM suite values depend on the Authentication method used.

00-0F-AC-01 (802.1X)
00-0F-AC-02 (PSK)

Here is the structure of RSN element.

Below shows sample wireless frame captures of those 4 different type of frames where RSN-IE field exists.

Here is a beacon frame.You can filter Beacon frames in wireshark using (wlan.fc.type == 0)&&(wlan.fc.type_subtype == 0x08) filter. As you can see below both Group & Pairwise cipher is CCM-AES (00-0F-AC-04) & AKM suite is PSK (00-0F-AC-02)

Here is a Probe Response frame. You can filter Probe Response frames using (wlan.fc.type == 0)&&(wlan.fc.type_subtype == 0x05) wireshark filter.

Here is a Association Request frame.You can filter Association Request frames using (wlan.fc.type == 0)&&(wlan.fc.type_subtype == 0x00) wireshark filter.

Here is a Reassociation Reuest frame. You can filter these frames using (wlan.fc.type == 0)&&(wlan.fc.type_subtype == 0x02) wireshark filter. As you can see it uses AKM suite of 00-0F-AC-01 (802.1X) & CCM-AES (00-0F-AC-04) encryption ciphers.

When you have multiple cipher suites (for mixed client support) Group Cipher should be always lowest denominator.(ie if CCMP, TKIP & WEP ciphers, group cipher should be WEP)

References.
1. http://www.my80211.com/8021x/2010/7/4/george-stefanick-cwsp-journey-chapter-5-rsn-post2-742010.html
2. CWSP-Official Study Guide (page 184-188)

Related Posts

1. CWSP – L2 Encryption Method:CCMP
2. CWSP – L2 Encryption Method:TKIP
3. CWSP – 4 Way Handshake
4. CWSP – Legacy 802.11 Security
5.
6.

The Extensible Authentication Protocol (EAP) as defined in IETF RFC 2284 provides support for many authentication methods.EAP was originally adopted for use with PPP, since been redefined in IETF RFC 3748 for use with 802.1X port base access control.

There are 4 different type of EAP packets & identify by the “Code” octet of EAP header.

Code=1  Request
Code=2 Response
Code=3 Success
Code=4 Failure

Most of the time EAP messages are encapsulated in EAP over LAN(EAPOL) frames. There are 5 different major types of EAPOL messages

1. Type 0 – EAP Packets (encapsulated EAP frame)
2. Type 1 – EAPOL-Start (optional frame that supplicant can use to start EAP Proces)
3. Type 2 – EAPOL-Logoff (this frame terminate an EAP session & shut virtuall ports)
4. Type 3 – EAPOL-Key (used to exchange dynamic keying info,eg 4way-handshake)
5. Type 4 – EAPOL-Encapsulated-ASF-Alert (used to send alerts such as SNMP traps to virtual ports)

Below shows the generic EAP frame exchange (Page 140 of Official CWSP Study Guide)

Authenticator maintains two virtual ports (uncontrolled & control port). When open “uncontrolled port” allows EAP authentication traffic to pass through. The control port blocks all other traffic until the supplicant has authenticated.When control port is open, upper layer (3-7) traffic can pass through.  Here is the flow of frame exchange.

1. Supplicant associate with BSS, both controlled & uncontrolled ports are blocked on the authenticator.
2. Supplicant initiate the EAP process by sending EAPOL-Start frame (optional frame & may or may not be used by different type of EAP)
3. Authenticator send EAP-Request frame.
4. Supplicant send EAP-Response frame with identity in clear text. Then uncontrolled port open to allow EAP traffic through.
5. Authenticator encapsulate EAP response frame in RADIUS packet & forwards it to authentication server(AS).
6. AS looks at supplicant’s name & check again user database & then send a password challenge.
7. Authenticator send the password challenge to the supplicant in a EAP frame.
8. Supplicant send EAP-challenge response by hashing password using hash algorithm (like MS-CHAPv2)
9. Authenticator forwards the challenge response in a RADIUS packet to AS.
10. AS runs an identical hash & see if response is correct. AS will send “Success” or “Failure”
11. Authenticator forwards AS message to supplicant in “EAP-Success” frame or “EAP-Failure” frame.
12. 4-Way handshake (if EAP-Success) between Authenticator & Supplicant occurs
13. Once 4 way-handshake is completed, the controlled port is unblocked & supplicant is authorized to use network resources.

Here is a snapshot of a wireless frame capture when EAP authentication in uesd. You will see the EAP-Request(frame 113), EAP-Response (frame 115), EAP-Success (fram 157) which are type -0 EAP packets. Also you can see type-2 EAPOL-Key messages (frame 159,161,163 & 165)

Here is some more details on different type of EAP packets in the above capture.

EAP-Request (frame 113 in the above).Note that Type 0 EAP packet type is “0” &  Code is 1 (ie EAP-Request)

Here is an EAP-Response frame(115 in the above).Note that Type 0 EAP packet type is “0” &  Code is 2 indicating it is a EAP-Reseponse frame. Also note the Identity is sent as cleartext (user1 in this capture).

Here is the “EAP-Success” frame(no 157). Note that EAP packet type 0 indicating it is normal EAP frame & Code is set to 3 indicating it is a EAPOL-Success frame.

Here is an “EAPOL-Key” exchange frame (no 159). Note that EAP packet type 3 indicating it is a EAPOL-Key exchange frame.
There are many different types of EAP authentication methods & some of them are  less secure compare to others.As you saw abouve, supplicant identity sending as cleartext is security risk & some EAP methods use encrypted tunnel to make it more secure. Here are the different type

1. EAP-MD5 (weak)
2. EAP-LEAP (weak)
3. EAP-PEAP (2 phase tunneled)
4. EAP-TTLS (2 phase tunneled)
5. EAP-TLS (2 phase tunneled)
6. EAP-FAST (2 phase tunneled)

Here is a quick comparison of these EAP methods (page 157 of CWSP Study Guide)

Reference
1. CWSP Official Study Guide- CH4.

Related Post

1. CWSP- EAP LEAP
2. CWSP- EAP PEAP
3. CWSP- EAP FAST
4. CWSP- EAP TLS
5. CWSP- EAP TTLS
6. CWSP- EAP MD5

EAP-LEAP (Lightweight Extensible Authentication Protocol) is Cisco proprietary authentication method. Below diagram shows the EAP-LEAP authentication process. (page 143 of CWSP Official Study Guide)
Here is a wireless frame capture of a client doing LEAP authentication. Here is the frame number mapping with above process diagram.

Step 2-Establish Datalink (frame no 76,84,88,90)
Step 3-EAPOL Start (optional frame & not in this capture)
Step 4a- EAP Identity Request (frame 92)
Step 4b- EAP Identify Response (frame 94)
Step 5a – LEAP Server Challenge (frame 100)
Step 5b – LEAP Server Challenge Response (frame 102)
Step 7 – EAP Success (frame 104)
Step 8 -LEAP Client Challenge (frame 107)
Step 10 – LEAP Client Challenge Response (frame 109)
Step 11-14 – 4 Way Handshake (frame 111,113,115,117)

Here is the EAP-Identity Request frame (step 4a) details. You can see the code type is 1 (for a Request frame)
Here is the Identity Response frame (step 4b). As you can see the supplicant identity (user1) is send in cleartext. Code value is 2 indicating a EAP response frame.
Here is the LEAP Server Challenge(step 5a). It is an EAP-Request (code=1) frame with server challenge in it.
Here is the Server Challenge Response send by supplicant. Challenge hash is calculated using password & MS-CHAPv2 algorithm.
Here is the EAP-Success (step 7) frame. You can see the code=3 (ie EAP Success )
Here is the LEAP Client Challenge (step 8) frame which is EAP-Request (code=1) type frame send by Supplicant to Authenticating Server(AS).
Here is the Client Challenge Response coming from AS. This point onwards Supplicant & AS will do the 4-Way Handshake.
LEAP is considered as weak protocol & easily can be cracked. As you can see below once you have LEAP-Server Challenge & LEAP-Server Challenge Response , you can easily use offline dictionary attack tool to get the password. Here is using ALEAP availabe in BackTrack how you can get the supplicant password. As you can see below in my case, I have used Challenge & Challenge Response info in frame 100 & 102 to derive the key using this ASLEAP.

56:85:b1:1c:ad:cf:1f:36 <- EAP Request Challenge in frame 100
bc:52:74:47:e3:d2:5a:b8:f3:3b:7b:c5:ad:98:e7:5b:51:85:5e:e7:b9:94:e2:a4 <- EAP Response challenge in frame 102

root@bt:~# asleap -C 56:85:b1:1c:ad:cf:1f:36 -R bc:52:74:47:e3:d2:5a:b8:f3:3b:7b:c5:ad:98:e7:5b:51:85:5e:e7:b9:94:e2:a4 -W /pentest/passwords/wordlists/rockyou.txt 
asleap 2.2 - actively recover LEAP/PPTP passwords. <jwright@hasborg.com>
Using wordlist mode with "/pentest/passwords/wordlists/rockyou.txt".
    hash bytes:        215d
        NT hash:           f2e787d376cbf6d6dd3600132e9c215d
    password:          Cisco123

Other EAP methods (PEAP, TLS, FAST) developed to send the supplicant identity in an inner TLS tunnel which is more secure.

Reference
1. EAP-LEAP-7921 (sample packet capture used for this post)
2. CWSP Official Study Guide – Chapter 4

Related Posts

1. CWSP- EAP Basics
2. CWSP- EAP PEAP
3. CWSP- EAP FAST
4. CWSP- EAP TLS
5. CWSP- EAP TTLS
6. CWSP- EAP MD5

EAP-PEAP (Protected Extensible Authentication Protocol), creates an encrypted TLS tunnel withing which the supplicant’s inner identity is validated. Sometime it is referred as EAP within EAP. There are 3 major versions of PEAP.

1. EAP-PEAPv0(EAP-MSCHAPv2)
2. EAP-PEAPv0(EAP-TLS)
3. EAP-PEAPv1(EAP-GTC)

PEAPv0 & PEAPv1 both refer to the outer authentication method and are the mechanism that create the secure TLS tunnel to protect subsequent authentication transaction. The EAP protocol enclosed within parenthesis (ie MSCHAPv2, TLS & GTC) is the inner EAP protocol.

Below shows the EAP-MSCHAPv2 process.
PEAP Phase1
1. Authenticator sends an EAP frame requesting identity of the supplicant.
2. Supplicant responds with EAP Response frame with clear text outer identity(not the real username)
3. Authenticator forwards outer identity response to Authenticating Server.
4. AS sends the server certificate down to the supplicant & Supplicant validate server-side certificate.
5. An encrypted point-to-point TLS tunnel is created between Supplicant  & AS.

PEAP Phase2
1. AS requests the real identity of the supplicant.
2. The supplicant respond with the inner identity, which is real username.
3. AS sends an EAP request with challenge
4. Supplicant sends an EAP response with hashed challenge response.
5. AS send an EAP request with EAP-MSCHAPv2 success.
6. Supplicant sends an EAP response with ACK.

Once Phase 2 completed, TLS tunnel will be torn down & AS send RADIUS Acceess Accept msg where Authenticator send it to Supplicant as “EAP-Success” (or EAP-Failure). Then 4-Way Handshake EAPOL-Key exhange (M1-M4) occures.

Here is the Identity Request frame (step 4a)
Here is the Identity Response frame (step 4b). This is sending the outer Identity & may not be the real username (in my case Supplicant – 7921 phone use the real username)
Here is the Start-PEAP (an EAP Reuest type) message (step 6).
Server certificate validation (step 7) include multiple frame exchange as shown in the below.(image source)Here is the response to “PEAP-Start” frame which  is “Client Hello“.
This shows Server Hello, Certificate, Server Hello Done frames coming from AS. There may be multiple fragments as this is a large packet (due to cert size)
Then Client Key exchange frame goes from Supplicant to AS.
Here is Change Cipher Spec frame.

Here is the  last frame (step 8) in Phase 1 send by the Supplicant to ensure TLS tunnel can establish since this time on.Since that point onwards all packets are TLS encrypted. Here is the first frame exchange in Phase 2 which is Identify Request for real username (step 9).Here is the EAP-Response/Identity Response frame (step 10) send by the supplicantThen AS will send EAP-MSCHAPv2 challenge inside the TLS tunnel to supplicant as EAP-Request frame.(step 11)

Here is the EAP-Response/Challenge from Supplicant (step 12)
Then AS validate client & send EAP-Request/EAP-MSCHAPv2-Success inside TLS (step 13).
Then Supplicant send EAP-Response/EAP-MSCHAPv2-ACK (Step 14).

So now AS sending the RADIUS accept to Authenticator & then Authenticator send that as “EAP-Success” frame to the Supplicant (step 17). This completes the Phase 2 of PEAP process.

Once PEAP authentication completes, it starts EAPOL-Key exchange (4 Way handshake frame 159,161,163,165)

References
1. EAP-PEAP-7921 (sample packet capture)
2. CWSP Official Study Guide – Chapter 4

Related Posts

1. CWSP- EAP Basics
2. CWSP- EAP LEAP
3. CWSP- EAP FAST
4. CWSP- EAP TLS
5. CWSP- EAP TTLS
6. CWSP- EAP MD5

EAP-TLS (EAP-Transport Layer Security) is defined in RFC 5216 & considered as most secure EAP methods used in WLAN. EAP-TLS is required to use client-side certificates in addition to server-side certificate. However maintain a client-side certificates is challenging (maintain PKI infrastructue & manage client certs).

Here is the EAP-TLS process. (page 152 of CWSP Study Guide)As you can see above, there is no tunnel establishes for inner authentication to take place like any other EAP methods (PEAP, FAST,TTLS). There is an optional privacy mode available where TLS handshake established prior to client identity is passed (not implemented by vendors).

Here is a packet capture of a supplicant using EAP-TLS for authentication. Supplicant is having MAC 00:20:a6:ca:6b:b4

Here is the details of the EAP-TLS frame exchange. Like any other EAP methods first two frames are “Identity Request (step 4a)” & “Identity Response (step 4b)” excluding optional EAPOL start frame.Here is the EAP-Identity Response frame (4b) send by Supplicant. Note that outer identity is go as cleartext.

Then AS will send “EAP-TLS  start” frame to supplicant as shown below. Note that type 13 identify “TLS” & code 1 identify as “Request” frame.Then Supplicant start validating the server certificate process (step 5a) with a “Client Hello” frame. Below shows the detail steps involved in Server & Client Certificate validation.(image source)

Here is the Client Hello frame.Then AS sending certificate with Server-Hello, Certificate, Certificate Request, Server-Hello-Complete. As you can see server certs will use fragmented frames as of the size of cert.(in my example 3 fragmented frames 55,57 & 59).Once Server Hello Done, AS start the client certificate verification (step 5b). Supplicant sent client certificate,client key exchange, Cert Verification, Change Cipher spec (again there are more than fragments in my capture-62,66).Here is the change cipher spec (frame 68) send by Authenticating Server.Here is the EAP-Response frame send by Supplicant to complete the Client Certificate (step 5b) process.Finally AS will send RADIUS Accept (or Reject) where inturn Authenticator convert it to EAP-Success(or Failure) frame (step 7). Here is my EAP Success frame (Code 3).This point, 4-Way Handshake starts (step 8-11 & frames 74,76,78,80).

Reference
1. EAP-TLS sample packet capture.
2. CWSP Official Study Guide – Chapter 4

 Related Posts

1. CWSP- EAP Basics
2. CWSP- EAP PEAP
3. CWSP- EAP FAST
4. CWSP- EAP LEAP
5. CWSP- EAP TTLS
6. CWSP- EAP MD5

EAP-FAST (Flexible Authentication via Secure Tunneling) initially developed by Cisco. Later in 2007, IETF ratified this in RFC 4851. Cisco developed this as replacement for LEAP. EAP-FAST provide both mutual authentication & tunnelled authentication without using standard based X.509 digital certificate to create TLS tunnels, instead use PACs (Protected Access Credentials)

A PAC can consist of 3 components
1. Shared Secret – PAC key
2. Opaque Element – PAC-Opaque
3. Other Information – PAC Info

Below shows the EAP-FAST process diagram (page 155-CWSP Official Study Guide) which consist of 3 phases.

1. Phase 0 – Used for automatic PAC provisioning.
2. Phase 1 – Supplicant send outer identity. AS & Supplicant negotiate using symmetric key from PAC shared secret. Result of this phase is TLS tunnel.
3. Phase 2 – Supplicant validated within TLS tunnel. It supports several inner authentication methods, commonly use EAP-GTC when username & password used as client identity info.

Here is a EAP-FAST authentication frame capture (Supplicant MAC 00:1b:d4:58:e6:1a)

EAP-FAST Phase-1 process start with Authenticator sends an “Identity Request” frame to supplicant (step 4a).Then supplicant respond with “Identity Response” with outer identity detail in cleartext (step 4b). In here Supplicant use “anonymous” as Identity which is not real username.Then Authenticating Server send the EAP-FAST start message. (step 6). Note that EAP type is 43 which is EAP-FAST.Below diagram(source) shows the details packet flow of rest of phase 1 (step 7 & 8 of process diagram).

Then supplicant start sending client PAC (Protected Access Credential) information starting with Client Hello.

Then AS will send “Server Hello” to Supplicant.
Then Supplicant send “Change Cipher Spec” frame to AS to complete the TLS tunnels establishment part (step 8).That point onwards all EAP frame exchange will be TLS encrypted. Phase 2 start with Identity Request & Identity Response where real username is send inside TLS tunnel.  Here are those 2 frames.

Then two more EAP-Request & Response frame exchange in optional PAC refresh.
EAP-FAST phase 2 is ends with Successful result communicate to Supplicant & Supplicant send ACK for within TLS tunnel. Here are those two frames in my capture.Once the above frame exchanged, TLS tunnel torn down & RADIUS Accept is coming from AS. Then Authenticator will pass it to Supplicant as normal EAP-Success frame (step 13)Then 4-Way Handshake takes place (step 14-17).

Note that when using Automatic PAC provisioning, it is subject to man in the middle attack where supplicant simply trust anyone who provide PAC. If you install PAC manually on client side you can overcome this, but it becomes administrative burden.

Reference
1. EAP-FAST-7921 sample packet capture.
2. CWSP Official Study Guide – Chapter 4

Related Posts

1. CWSP- EAP Basics
2. CWSP- EAP PEAP
3. CWSP- EAP LEAP
4. CWSP- EAP TLS
5. CWSP- EAP TTLS
6. CWSP- EAP MD5

In this post we will see how a basic 802.11 roam works using Cisco WLC & two APs. My WLC is 4402 & running on 7.0.116.0 code.

I have configured a SSID called TEST1 with 802.1X security. Here is WLAN security settings

(4402-3) >show wlan 1
WLAN Identifier.................................. 1
Profile Name..................................... TEST1
Network Name (SSID).............................. TEST1
Status........................................... Enabled
.
.
Radius Servers
   Authentication................................ 192.168.100.2 1812
   Accounting.................................... 192.168.100.2 1813
Security
   802.11 Authentication:........................ Open System
   Static WEP Keys............................... Disabled
   802.1X........................................ Disabled
   Wi-Fi Protected Access (WPA/WPA2)............. Enabled
      WPA (SSN IE)............................... Disabled
      WPA2 (RSN IE).............................. Enabled
         TKIP Cipher............................. Disabled
         AES Cipher.............................. Enabled
      Auth Key Management
         802.1x.................................. Enabled
         PSK..................................... Disabled
         CCKM.................................... Disabled
         FT(802.11r)............................. Disabled
         FT-PSK(802.11r)......................... Disabled
FT Reassociation Timeout......................... 20
FT Over-The-Air mode............................. Enabled
FT Over-The-Ds mode.............................. Enabled
CCKM tsf Tolerance............................... 1000
.

I have statically configure the LAP1 & LAP2 channels &  TX-Power Level(to min) in order to have better control over roaming in my lab setup & allowing me to capture packets over the air on those channels (36,40).

config 802.11a disable LAP2
config 802.11a channel ap LAP2 40
config 802.11a txPower ap LAP2 7
config 802.11a enable LAP2

config 802.11a disable LAP1
config 802.11a channel ap LAP1 36
config 802.11a txPower ap LAP1 7
config 802.11a enable LAP1

You can verify your configuration using “show ap config 802.11a summary” CLI command.

(4402-3) >show ap config 802.11a summary 
AP Name                SubBand RadioMAC            Status     Channel   PwLvl   SlotId 
--------------------   ------- ------------------  --------   -------   ------  ------ 
LAP2                      -    2c:3f:38:2a:b1:20   ENABLED    40        7       1         
LAP1                      -    64:a0:e7:af:47:40   ENABLED    36        7       1

Here is the packet flow when client associates to the wireless network. 7921 has associated to LAP2. After open system authentication, it is going through EAP-LEAP authentication process & then followed by 4-Way Handshake prior to user traffic start passing through. As you can see in this frame capture it took 116ms (time taken from frame 365 to 400) for the complete process.

Now, if I move my 7921 towards LAP1 you can see it is decided join to LAP1 (Based on the RSSI, SNR,etc received by client- Note that roaming decision is purely made by client & AP/WLC have no control). In here as well you can see it took around 119ms (frame 455-489) to complete the roam process. During this process most of time taken for the EAP process (~90ms  from frame 463-481)

As you can see in the above, Roaming process start by 7921 sending a “Reassociation Request” frame to LAP1. Here is the detail of that frame. Note that there are two fieds (PMKID Count,PMKList) in this Reassociation Request frame that will be used if any Fast Secure Roaming method in used (not in our case here) to indicate the target AP that client was already in the network with secure association.Then AP responds with “Reassociation Response” frame indicating client can join the new AP (LAP1).Then Client & AP needs to derive the keys for data encryption (PTK) & hence client must re-authenticate to generate the seeding material for 4-Way Handshake which resulting encryption keys (PTK)

As you saw above, every time client roam to new AP, client has to go through the full 802.1X EAP authentication process & then 4 way handshake. Since this EAP Authencation process takes considerable amount of time (vary ~100ms -700ms) for certain applications (like voice) it is not ideal a client roam takes that much time.

Therefore 802.11-2007 standard defines two fast secure roaming mechanisms applicable to legacy Autonomous APs.

1. Preauthentication.
2. PMK Caching.

Most WLAN vendors offer a fast secure roaming solution called OKC-Opportunistic Key Caching which is an enhancement of PMK caching.(Note that OKC is not part of 802.11-2007 standard)

Cisco has offered proprietary version of fast-secure roaming called Cisco Centralized Key Management (CCKM). To support CCKM, supplicant should fall under Cisco licensed CCX program. You can check the nature of roam when you enable CCKM on this SSID.Security

   802.11 Authentication:........................ Open System
   Static WEP Keys............................... Disabled
   802.1X........................................ Disabled
   Wi-Fi Protected Access (WPA/WPA2)............. Enabled
      WPA (SSN IE)............................... Disabled
      WPA2 (RSN IE).............................. Enabled
         TKIP Cipher............................. Disabled
         AES Cipher.............................. Enabled
      Auth Key Management
         802.1x.................................. Enabled
         PSK..................................... Disabled
         CCKM.................................... Enabled
         FT(802.11r)............................. Disabled
         FT-PSK(802.11r)......................... Disabled

As you can see below this time supplicant continue to pass traffic as soon as AP send “Reassociation Response” frame. There is no authentication or 4-way handshake require to takes place. You can see the entire client roam occurs within 7ms in this case.

In 2008, IEEE came up with 802.11r which standardize the fast roaming. This method is called Fast BSS Transition (FT).  There are two FT methods

1. Over the Air Fast BSS Transition.
2. Over the DS Fast BSS Transition.

We will discuss each of these Fast Secure Roaming mechanisms in future posts.

Referennce
1. 802.11 WLAN Roaming and Fast-Secure Roaming on CUWN <-Best Cisco Document I found describing this topic in detail
2. CWSP-Official Study Guide- Chapter 7
3.7921-Association-LAP2 (Original Association packet capture)
4.7921-Roaming to-LAP1 (Reassociation or Roaming packet capture)
5.7921-CCKM-Roaming to-LAP1 (Roaming with CCKM packet capture)

IEEE 802.11r-2008 is also known as “fast basic service set transition -FT” is defined for allow fast secure roaming.802.11r mechanism introduce multiple layer of PMKs that are cached in different devices and assign different roles (key holder roles) to different devices as listed below.

WLAN Controller : PMK-R0 key holder (R0KH)
Access Point       : PMK-R1 key holder (R1KH)
Client Station     : PMK-S0 key holder (S0KH)
Client Station     : PMK-S1 key holder (S1KH)

802.11r defines a three-level key hierarcy
1. Pairwise Master Key R0(PMK-R0) : The first level key of the FT key hierarchy. This key is derived from master session key (MSK)
2. Pairwise Master key R1(PMK-R1) : The second level key of the FT key hierarchy.
3. Pairwise Transit Key (PTK)           : The third-level key of the FT key hierarchy. The PTK is the final key used to encrypt 802.11 data frames.

In 802.11r, various levels of FT keys are derived & stored in different WLAN devices. 802.1X/EAP creates the master session key (MSK) & then MSK is used to create first-level master key (PMK-R0). PMK-R0 is cached on the WLAN controller.So WLAN controller is key holder for first-level key

The second level key, PMK-R1 is derived from PMK-R0 & sent from WLAN controller to the controller managed APs.So PMK-R1 keys are cached on the APs & APs ar the key holders for PMK-R1.

PMK-R1 is used to derive PTKs, which are used to encrypt data. Below diagram summarized the key hierarchy of WLAN controller infrastructure  (page 266- CWSP Official Study Guide)

There are various level of FT keys derived and stored on the client stations. 802.1X/EAP creates MSK & then MSK is used to create first level of master key (PMK-R0). The PMK-R0 is cached on the supplicant/client station. So client station is the key holder for first-level key.

Using PMK-R0, client station will derives the second-level key PMK-R1. PMK-R1 is cached on the client station. So supplicants are key holder for the PMK-R1. PMK-R1 is used to derive PTKs, which are used to encrypt data.

Below diagram (Page 267 -CWSP Offical Study Guide) shows the Supplicant FT key hierarchy.

If client traffic encrypt/decrypt at the controller level (instead of AP level) then WLC functions as both the PMK-R0 key holder (R0KH) & PMK-R1 key holder (R1KH).

References
1. CWSP Official Study Guide
2. CWNP-RSN Fast BSS Transition (FT) white paper.

Related Posts

1. CWSP-802.11 Roaming Basics
2. CWSP-802.11r FT initial Association
3. CWSP-802.11r Over-the-Air-FT
4. CWSP-802.11r Over-the-DS-FT

In this post we will see how 802.11r supported client first associate to an SSID configured for 802.11r FT support. I have used 3850 (running on IOS-XE 3.6) as my WLC. Not all wireless clients support 802.11r, so you have to select a client supporting this standard. Most of the Apple idevices support 802.11r & you can find the complete list from this link. So here is my topology for this post.You can configure your 3850 as mobility controller & configure two AP connected switch ports as same access vlan as wireless management (vlan 20 in this example)

interface Vlan20
 ip address 192.168.20.1 255.255.255.0
!
wireless mobility controller
wireless management interface Vlan20
!
interface GigabitEthernet1/0/1
 description LAP-1
 switchport access vlan 20
 switchport mode access
interface GigabitEthernet1/0/2
 description LAP-2
 switchport access vlan 20
 switchport mode access

I have configured my ACSv5.2 as RADIUS server

aaa new-model
dot1x system-auth-control
aaa group server radius RAD-GRP
 server name ACS
aaa authentication dot1x MRN-DOT1X group RAD-GRP
aaa authorization network MRN-AUTH group RAD-GRP
aaa accounting network MRN-DOT1X start-stop group RAD-GRP
aaa server radius dynamic-author
 client 192.168.100.2 server-key Cisco123
 auth-type any
aaa session-id common
radius server ACS
 address ipv4 192.168.100.2 auth-port 1812 acct-port 1813
 key Cisco123

Here is the SSID configuration. In default settings SSID will be created with WPA2/AES as encryption cipher & 802.1X as authentication suite.So you just simiply need to specify the client vlan & point it to predefined authentication list.Since I have used wlan-id >16, so I have to use AP Group to advertise the SSID.

wlan MRN-EAP 22 MRN-EAP
 client vlan 22
 security dot1x authentication-list MRN-DOT1X
 no shutdown
!
ap group APG1
wlan MRN-EAP
vlan 22
!
3850-1#ap name LAP1 ap-groupname APG1
Changing the AP's group name will cause the AP to reboot.
Are you sure you want to continue? (y/n)[y]: y

Now if you do “show wlan id 22” you will see all the settings of this WLAN.

3850-1#show wlan id 22
WLAN Profile Name     : MRN-EAP
================================================
Identifier                                     : 22
Network Name (SSID)                            : MRN-EAP
Status                                         : Enabled
Broadcast SSID                                 : Enabled
.
Security
    802.11 Authentication                      : Open System
    Static WEP Keys                            : Disabled
    802.1X                                     : Disabled
    Wi-Fi Protected Access (WPA/WPA2)          : Enabled
        WPA (SSN IE)                           : Disabled
        WPA2 (RSN IE)                          : Enabled
            TKIP Cipher                        : Disabled
            AES Cipher                         : Enabled
        Auth Key Management
            802.1x                             : Enabled
            PSK                                : Disabled
            CCKM                               : Disabled
            FT dot1x                           : Disabled
            FT PSK                             : Disabled
            PMF dot1x                          : Disabled
            PMF PSK                            : Disabled
    FT Support                                 : Disabled
        FT Reassociation Timeout               : 20
        FT Over-The-DS mode                    : Enabled
    PMF Support                                : Disabled
        PMF Association Comeback Timeout       : 1
        PMF SA Query Time                      : 200
    CKIP                                       : Disabled
    IP Security                                : Disabled
    L2TP                                       : Disabled
    Web Based Authentication                   : Disabled
    Conditional Web Redirect                   : Disabled
    Splash-Page Web Redirect                   : Disabled
    Auto Anchor                                : Disabled
    Sticky Anchoring                           : Enabled

As you can see above, FT+802.1X is disabled, FT support is disabled, FT-Over-the-DS mode enable. So you have to enable this on wlan (Go here for reference IOS-XE 3.6 Config Guide).

wlan MRN-EAP 22 MRN-EAP
 shutdown
 security wpa akm ft dot1x
 security ft
 no shutdown

If you have GUI preference of these settings you can do that as well (see below snapshot).I have set the AP channel & power level as shown below in order to take packet captures easily.

3850-1#show ap dot11 5ghz summary 
AP Name            MAC Address     Slot  Admin State  Oper State  Channel             Width  TxPwr   
---------------------------------------------------------------------------------------------------
LAP2               2c3f.382a.b120     1  Enabled      Up          40                     20    7( )  
LAP1               64a0.e7af.4740     1  Enabled      Up          36                     20    7( )

Now if you capture wireless frame on channel 36 while iPhone5 is associate to LAP1 you will see something like this (Filtered Beacon & ACK frames for simplistic view)If you look it at a glance, it is very similar to the normal EAP authentication process (Open system auth -> EAP Auth -> 4-Way Handshake). But if you look deep into this packet capture you will see some interesting detail specific to 802.11r.

Here is a detail view of a Beacon Frame send by AP. As you can see in included additional information element (Mobility Domain Information Element -MDIE) which is used to indicate the existence of a mobility domain as well as the FT transition supported. This IE has following fields (size in bytes shown within bracket)

Element ID(1) – Element ID 54 for Mobility Domain IE
Length(1)
MDID(2) Mobility Domain Identifier-identify group of AP constitute mobility domain
FT Capability(1)
FT-over-DS bit – If set to 1 then FT-over-DS, if it is 0 then FT-over-the-air
Resource Request protocol capability.

Also you can see there are two AKM suits in the RSN-IE. 00-0F-AC-1 (802.1X/EAP) & 00-0F-AC-3 (FT over 802.1X).

In our case you can verify MDID value from controller itself as shown below (value 0xac34).

3850-1#show wireless mobility summary 
Mobility Controller Summary:
Mobility Role                                   : Mobility Controller
Mobility Protocol Port                          : 16666
Mobility Group Name                             : default
Mobility Oracle Configured Mode                 : Disabled
Mobility Oracle IP Address                      : 0.0.0.0
DTLS Mode                                       : Enabled
Mobility Domain ID for 802.11r                  : 0xac34
Mobility Keepalive Interval                     : 10
Mobility Keepalive Count                        : 3
Mobility Control Message DSCP Value             : 48
Mobility Domain Member Count                    : 1

When the Supplicant send the “Association Request” frame that also include RSN-IE & MDIE as shown below. As you can see in RSN-IE it only listed FT over 802.1X as supported AKM suite.When AP send “Association Response” frame that has an another information element (ID=55) called FTIE - Fast BSS Transistion Information Element. This includes Element ID, Length, MIC, MIC control, ANonce, SNonce & optional information like R0KH-ID, R1KH-ID. These information needed to perform the FT authentication sequence during a fast BSS transition.
Next Supplicant & AS will do the  /802.1X process to create the MSK that is used for FT key hierarchy. As you can see below initial mobility association frame exchange is similar to normal 802.1X. Only difference is FT 4-Way Handshake messages have additional infromation like MDIE, FTIE. Below figure (page 269 of CWSP official Study Guide) show the FT Initial mobility domain association.Here is the detail view of EAPOL-Key M1 which send by Authenticator to Supplicant that include ANonce.

Here is the detail view of EAPOL-Key M2 which comprise of SNonce, RSNIE,MDIE & FTIE.

Here is the detail view of EAPOL-Key M3. This include ANonce,MIC, RSNIE, MDIE, GTK, FTIE.At the end of M2, PTK is derived & hence M3 will be encrypted using PTK (that’s why you cannot see RSNIE,MDIE,GTK,FTIE here)

Here is the detail view of EAPOL-Key M4

After the initial association there are two method defined for client station to roam from original AP to a target AP.
1. Over-the-Air Fast BSS Transition
2. Over-the-DS Fast BSS Transition.

In a future post we will look at details of these two methods.

References
1. FT-over-DS-Association (frame capture used in this post)
2. CWSP Official Study Guide – Chapter 7

Related Posts

1. CWSP-802.11 Roaming Basics
2. CWSP-802.11r Key Hierarchy
3. CWSP-802.11r Over-the-Air-FT
4. CWSP-802.11r Over-the-DS-FT
5. CWSP-4 Way Handshake
6. CWSP- RSN IE

In this post we will see how 802.11r Over-the-Air Fast BSS Transition works. We will use same topology & base configuration used for the previous post.

First I have to disable “Over-the-DS” feature on the WLAN to force FT transition “Over-the-Air” as shown below.

wlan MRN-EAP 22 MRN-EAP
 client vlan 22
 security wpa akm ft dot1x
 security dot1x authentication-list MRN-DOT1X
 security ft
 no security ft over-the-ds
 no shutdown

When the client associate to LAP1, it will go through  FT initial mobility domain association process (described in 802.11r FT association post). Here is the snapshot of that frame capture.In “Over-the-Air Fast BSS Transition” client will communicate with Target AP (LAP2 in my case) over the air. So you can capture these frame exchange if you sniff CH40 as LAP2 is set to that channel. So here is my capture looks like. As you can see in the time stamp (from frame 88 to frame 95) roaming complete within 14ms.As you can see in the above, you can see only 4 frames like in Open System Authentication & even not includes any 4-Way Handshake messages :shock: . These are 4 frames exchange when this roam occurs,

1. Authentication Request
2. Authentication Response
3. Re-association Request
4. Re-association Response

Without 4-Way Handshake messages how client & AP derive PTK to encrypt traffic ? If you look at the detail of the above frames you will find the answer. In Over-the-Air Fast BSS Transition, these 4 frames include 4-Way Handshake information. This will effectively combines the initial Open System Authentication & Re-association frames with 4-Way Handshake frames. (so 4 less frames required to complete a roam).

Now let’s go into detail of each of these frames. First we will look at the “Beacon frame” to see “Over-the-Air” FT support advertising. As you can see below in RSN-IE its advertising 802.1X & FT over 802.1X capability & in MDIE “Over-the-DS” bit set to “0” indicating it is supporting “Over-the-Air” Fast BSS Transition.So let’s go to “Authentication Request” frame detail initiated by the client (iPhone5 in this case). As you can see, this frame contain RSNIE, MDIE, FTIE information elements. RSNIE includes PMKID count & PMKID list. FTIE includes SNonce, R0KH-ID.Then target AP(LAP2) sends the “Authentication Response” frame to client. This frame also contain RSNIE, MDIE & FTIE. In FTIE includes ANonce, SNonce,R1KH-ID & R0KH-ID.Then client sends the “Re-association Request” frame. This also contain RSNIE,MDIE & FTIE. FTIE includes MIC,Anonce, SNonce, R1KH-ID, R0KH-ID.

Finally AP sends “Re-association Response” frame. This frame contain RSNIE, MDIE,FTIE & GTK information.

Below diagram (page 270 of CWSP Official Study Guide) show the frame exchange of “Over-thee-air fast BSS transition” which described above.In the next post how “Over-the-DS fast BSS Transition” works.

References
1. Over-the-Air-FT (frame capture used for this post)
2. CWSP Official Study Guide – Chapter 7

Related Posts

1. CWSP-802.11 Roaming Basics
2. CWSP-802.11r Key Hierarchy
3. CWSP-802.11r FT Association
4. CWSP-802.11r Over-the-DS-FT
5. CWSP-4 Way Handshake
6. CWSP- RSN IE

In this post we will see how “Over-the-DS Fast BSS Transition” works. We will use the same topology as shown below. Originally Client is associated to LAP2 & then roam to LAP1.One thing you have to understand is the two APs communicate with each other over the DS (distribution system)  & hence called it “Over-the-DS fast BSS transition“. So you have to capture that communication over the wire. At this time I have enabled “Over-the-DS FT” support on the WLAN.

3850-1#show wlan id 22
WLAN Profile Name     : MRN-EAP
================================================
Identifier                                     : 22
Network Name (SSID)                            : MRN-EAP
Status                                         : Enabled
Broadcast SSID                                 : Enabled
.
802.1x authentication list name                : MRN-DOT1X
Security
    802.11 Authentication                      : Open System
    Static WEP Keys                            : Disabled
    802.1X                                     : Disabled
    Wi-Fi Protected Access (WPA/WPA2)          : Enabled
        WPA (SSN IE)                           : Disabled
        WPA2 (RSN IE)                          : Enabled
            TKIP Cipher                        : Disabled
            AES Cipher                         : Enabled
        Auth Key Management
            802.1x                             : Enabled
            PSK                                : Disabled
            CCKM                               : Disabled
            FT dot1x                           : Enabled
            FT PSK                             : Disabled
            PMF dot1x                          : Disabled
            PMF PSK                            : Disabled
    FT Support                                 : Enabled
        FT Reassociation Timeout               : 20
        FT Over-The-DS mode                    : Enabled
    PMF Support                                : Disabled
        PMF Association Comeback Timeout       : 1
        PMF SA Query Time                      : 200

I have simply configure a monitor session on my 3850 to capture this “Over-the-DS” communication & at the same time sniffing on CH36 (where LAP1-target AP) operates. Here is the 3850 monitor session configs where G1/0/2 is LAP2 connected switchport & G1/0/3 is connected to PC running wireshark monitoring PC’s Ethernet NIC.

3850-1#
monitor session 1 source interface Gi1/0/2
monitor session 1 destination interface Gi1/0/3

Here is the “Over-the-DS” capture looks like. As you can see below there are two action  frames [ you can filter it in wireshark suing (wlan.fc.type == 0)&&(wlan.fc.type_subtype == 0x0d) display filter). Here is the FT Action Request frame sent by the STA address (04f7.e4ea.5b66) to the target AP address of LAP1’s BSSID (64a0.e7af.474e) under fixed parameters. You can see in the original 802.11 wireless headers source address is the client MAC & destination address is LAP2’s BSSID (2c3f.382a.b12e). In other words this FT Action Request frame is going to target AP via the original AP.

LAP2 (192.168.20.166) will encapsulate original wireless frame onto CAPWAP & send to WLC management address (192.168.20.1) as CAPWAP Data frame (Dst Port UDP 5247).

You can see RSNIE, MDIE & FTIE information elements in this frame. MDIE has “FT over DS” bit set to 1 indicating it is using “Fast BSS transition over DS” mechanism. FTIE include SNonce, R0KH-ID as well.

In response to FT Action Request frame, Target AP (LAP1 in this case) send a FT Action Response frame. Here is that frame. You can see in this frame as well STA address (04f7.e4ea.5b66), Target AP Address (64a0.e7af.474e), action code “FT Response” with status code “Successful“.

In the 802.11 wireless header, source address is 2c3f.382a.b12e which is LAP2 & destination address is 04f7.e4ea.5b66 indicating response is coming via original AP (LAP2).

In this frame as well you can see RSNIE, MDIE & FTIE information. In FTIE you can see ANonce, SNonce, R1KH-ID & R0KH-ID

Now here is the wireless sniff on CH36 looks like (target AP operating frequency). As you can see there are “Re-association Request” & “Re-association Response” frames (#437 & 439). Timing wise you can see the  FT occur within 88ms (time from FT Action Request frame to Re-association Response frame). Here is the detail view of “Re-association Request” frame. This frame sends by client (04f7.e4ea.5b66) to target AP,LAP1 (with BSSID:64a0.e7af.474e). This is an over the air communication. As you can see it list the current AP(2c3f.382a.b12e)  which is LAP2. FTIE includes MIC, SNonce, ANonce, R1KH-ID, R0KH-ID information.Then Target AP send the “Re-association Response” frame with status code “Successful” Here is the detail view of “Re-association Response” frame. FTIE includes ANonce, SNonce, R1KH-ID, R0KH-ID & GTK for broadcast/multicast encryption.Here is the summary view of Over-the-DS Fast BSS Transistion frame exchange that we described earlier.(page 271 of CWSP Official Study Guide)References
1. LAP2-LAP1-Over-DS (Over the DS wired frame capture)
2. iphone5-EAP-FT-over-DS-ch36 (Over the air CH36 wireless frame capture)
3. CWSP Official Study Guide – Chapter 7

Related Posts

1. CWSP-802.11 Roaming Basics
2. CWSP-802.11r Key Hierarchy
3. CWSP-802.11r FT Association
4. CWSP-802.11r Over-the-Air-FT
5. CWSP-4 Way Handshake
6. CWSP- RSN IE

As you already aware Cisco has released WLC 8.0 software which is a major upgrade in recent years. People were talking about this code version for a long period of time ( I remember even in CL-2012 some of them talking about this code) though it did not come out until late August 2014. As this Cisco mobility Blog (The Summer Blockbuster-WLC 8.0) describes it has lots of new features.

So what are those new features ? If you read WLC 8.0 release notes you will find most of them listed there. Here is some of the key highlights (not the full list)

1. Supported AP & Scale features
* Cisco Aironet 1040, 1130**, 1140, 1240**, 1250, 1260, 1600, 2600, 2700, 3500, 3500p, 3600, 3700, 602-OEAP, 702, 702W, AP801, and AP802 Series indoor access points
* Cisco Aironet 1520 (1522, 1524), 1530, 1550 (1552) Series outdoor access points

(5508-1) >show ap summary 
Number of APs.................................... 2
Global AP User Name.............................. Not Configured
Global AP Dot1x User Name........................ Not Configured
AP Name             Slots  AP Model              Ethernet MAC       Location          Country  IP Address       Clients
------------------  -----  --------------------  -----------------  ----------------  -------  ---------------  -------
3502-1               2     AIR-CAP3502I-N-K9     cc:ef:48:72:0f:c3    Rasika-Testing  AU       x.x.13.10    0   
1131-1               2     AIR-LAP1131AG-N-K9    c4:7d:4f:ac:e4:26  default location  AU       x.x.13.15    0

(5508-1) >show system ?            
dmesg          Displays dmesg logs
interfaces     Displays information about the configured network interfaces
interrupts     Displays the number of interrupts
iostat         Displays CPU and input/output statistics for devices
ipv6           Displays system ipv6 information
meminfo        Displays system memory information
neighbours     Displays the IPv6 Neighbor Cache
netstat        Display system network stats
process        Displays process related information
route          Displays system routing table
slabs          Displays memory usage on slab level
slabtop        Displays the slab usage
timers         Display system timer info
top            Displays the cpu usage
vmstat         Displays system virtual memory statistics

(5508-1) >config ap led-state flash ?               
<seconds>      The duration of LED flashing in seconds <1-3600>               
indefinite     Indefinite flashing of the LED               
disable        Stop flashing the LED
               
(5508-1) >config ap led-state flash 10 3502-1

(5508-1) >config network webcolor ?              
default        Enables default web color theme.
red            Enables red web color theme.               
(5508-1) >config network webcolor red

Day 3 (Thu, 2 Oct) – WLC new features:  vWLC scale enhancements, CAPWAP data keepalive, PPoE on Flex, wired guest support on 2500, RADIUS accounting VSAs, HTTPS support for WebAuth, ease of management enhancements, local profiling OUI update list, 802.11v support, 802.11r enhancement, DHCP relay enhancement, IPv6 support on WLCs and APs.

PMK Caching & Preauthentication are two different methods defined in IEEE 802.11-2007 to allow fast secure roaming.

PMK Caching:
In PMK Caching AP & client station maintain PMKSA for a period of time while a client station roams to a target AP & establishes a new PMKSA.Below shows the PMK caching packet flow (page 258 of CWSP Official Study Guide)As shown in the above figure, when client associate with an original AP and create an original PMK#1. The client will roam to target AP and create new PMK#2. However the original AP & the client station will both cache PMK#1.

Whenever client station is roam-back to the original AP, the client station will send a re association request frame that lists multiple PMKIDs in the RSNIE. Since AP also having chache PMK for given PMKID of that client, both can skip the 802.1X/EAP  authentication & proceed with 4-Way Handshake. So roaming would occur relatively fast.

This method is sometimes known as “fast secure roam-back” because client station is able to roam-back to original AP & skip the 802.1X/EAP Process.Drawback of this method is there are no way to make a roam fast, if client station is associate to a new AP.

Preauthentication:
A client station can use “preauthentication” to establish a new PMKSA with an AP prior to roaming to a new target AP. Preauthentication allows a client station to initiate a new 802.1X/EAP with AS while associated with the original AP. Below shows the “Preauthentication” frame exchange (page 259 of CWSP Offical Study Guide)As shown int the above, in Preauthentication, client initiate a new 802.1X/EAP with AS while associated with the original AP.Client station do this via the original AP over Distribution System (DS), however Authenticator will be the Target AP. Once the client has preauthenticated,  a new PMK#2 is created & chached on both client station & the target AP. If the client station decides to roam to target AP, the client does not need to reauthenticate & create new PMK as preauthenticated cached PMK already exists. So both can do 4-Way Handshake without EAP authentication process. Typically if AP support “preauthentication” it would advertise it via RSNIE in the beacon frames.

Drawback of “preauthentication” is not scaling well as it requires all APs to create PMKSAs with all clients that might roam to each AP.Every single client need to preauthenticate with every single AP in advance (cause load on AS as well)

Since both these PMK Caching & Preauthentication mechanisms are not scaling well, IEEE 802.11r-2008 ratification developed. Prior to that most of WLAN vendors implemented a preview of 802.11r called “Opportunistic Key Caching“

Related Posts

1. CWSP- PMKSA
2. CWSP- Opportunistic Key Caching-OKC

IEEE  802.11k-2008 defines Radio Resource Management (RRM) mechanism that enable 802.11k capable client’s radio to better understand the RF environment that they exist which will help clients to have better roaming. In this post we will enable this 802.11k support on a wlan configured on Cisco 3850 WLC (IOS-XE 3.6E) & see how it works. Here is the topology for this post where I have 3 APs registered to my WLC.

I have set the CH of these AP & set the power level to lower value as this is a lab setup. I have shown how to do this using CLI for LAP4 as an example.

3850-1#ap name LAP4 dot11 5ghz shutdown
3850-1#ap name LAP4 dot11 5ghz txpower 6
3850-1#ap name LAP4 no dot11 5ghz shutdown
3850-1#ap name LAP4 dot11 5ghz channel 44      
3850-1#ap name LAP4 dot11 5ghz channel width 20
3850-1#ap name LAP4 no dot11 5ghz shutdown

3850-1#show ap dot11 5ghz summary 
AP Name            MAC Address     Slot  Admin State  Oper State  Channel             Width  TxPwr   
---------------------------------------------------------------------------------------------------
LAP4               0024.9788.48e0     1  Enabled      Up          44                     20    6( )  
LAP2               2c3f.382a.b120     1  Enabled      Up          40                     20    7( )  
LAP1               64a0.e7af.4740     1  Enabled      Up          36                     20    7( )

Here is the SSID configuration on my 3850. It is simple 802.1X/EAP SSID. I have not shown all other configuration like AAA, etc.

wlan MRN-EAP 22 MRN-EAP
 client vlan 22
 security dot1x authentication-list MRN-DOT1X
 no shutdown

When you configure an SSID like above, there are certain default settings applied to it. You can view all these using “show run all” command as shown below. As you can see below 802.11k or AP assisted roaming is disabled by default.

3850-1#sh run all | sec wlan MRN-EAP
wlan MRN-EAP 22 MRN-EAP
 accounting-list 
 no assisted-roaming dual-list
 no assisted-roaming neighbor-list
 broadcast-ssid
 ccx aironet-iesupport
 channel-scan defer-priority 4
 channel-scan defer-priority 5
 channel-scan defer-priority 6
 channel-scan defer-time 100
 chd
 client association limit ap 0
 client association limit radio 0
 client association limit 0
 client vlan 22
 no device-classification
 dtim dot11 24ghz 1
 dtim dot11 5ghz 1
 exclusionlist
 exclusionlist timeout 60
 ip access-group web 
 ip access-group 
 ip dhcp server 0.0.0.0
 ipv6 traffic-filter web none
 ipv6 traffic-filter none
 mac-filtering 
 mfp client
 mfp infrastructure-protection
 mobility anchor sticky
 no profiling local http
 no profiling radius http
 radio all
 security wpa
 security wpa akm dot1x
 no security wpa wpa1
 security wpa wpa2
 security wpa wpa2 ciphers aes
 security dot1x authentication-list MRN-DOT1X
 security dot1x encryption 104
 security ft over-the-ds
 security ft reassociation-timeout 20
 security pmf association-comeback 1
 security pmf saquery-retry-time 200
 security static-wep-key authentication open
 security tkip hold-down 60
 security web-auth authentication-list 
 security web-auth parameter-map 
 service-policy client input unknown
 service-policy client output unknown
 service-policy input unknown
 service-policy output unknown
 service-policy type control subscriber 
 session-timeout 1800
 wmm allowed
 shutdown

Let’s enable assisted roaming & see how it works. I have simply enable this for 802.11k compliant clients.  You can configure cisco WLC to provide some predictive neighbor report even clients are not 802.11k capable. You can refer this config guide for more detail.

3850-1(config)#wlan MRN-EAP
3850-1(config-wlan)#shut
3850-1(config-wlan)#assisted-roaming ?
  dual-list      Configures dual band 802.11k neighbor list a WLAN
  neighbor-list  Configures 802.11k neighbor list support on the WLAN
  prediction     Configures assisted-roaming Prediction optimization on the
                 WLAN

3850-1(config-wlan)#assisted-roaming neighbor-list 
3850-1(config-wlan)#no shut

In my case client associated to LAP4 & here is the wireless frame capture on CH44.  (Beacon & ACK frame filtered for simplistic view). As you can see below you can see additonal “Action” frames compare to normal 802.1X/EAP frame exchange.Here is a Beacon Frame send by AP. As you can see it has “Radio Measurement or RM” capability enabled.If client is 802.11k compliant, then it will include its RM capability in Association Request frame. In Association Response frames coming from AP also included this RM capability.802.11k capable client will dynamically request Neighbor Report from the current AP. This will help to find a potential target AP to roam. As you can see below iPhone5 (04:f7:e4:ea:5b:66) send below Neighbor Report Request to currently connected LAP4 (BSSID-0024.9788.48ee)So current AP respond with the Neighbor Report Response. As you can see below it included both LAP1(64a0.e7af.474e) & LAP2 (2c3f.382a.b12e) AP information like channel they operate, BSSID capability. In this way client is already aware the potential neighbor AP where it can roam.Still client station will make the roaming decision, but definetely neighbor report provided by AP assisting client to make that decision, hence called “AP Assisted Roaming“

References
1. iphone5-80211k (packet capture used for this post)
2. CWSP-Official Study Guide -Chapter 7

Related Posts