802.11 Frame Exchanges section account for 25% of syllabus for CWAP-403 exam. Potentially around 15 questions out of 60 in the exam can be expected from this section. This blog post focuses on the “security” component of 802.11 Frame Exchange. I will be focusing on other sections in the subsequent posts in the next week or two. Let’s begin!

Authentication

1st step required to connect to 802.11 BSS. Both authentication and association must occur in order to successfully pass wireless traffic over to the AP and further. IEEE 802.11i-2004 defines RSNA. Open System & Shared Key Authentication are Prior to RSNA (Pre-RSNA) methods. The 802.11 authentication merely establishes an initial connection between the client and the access point, basically validating or authenticating that the STA is a valid 802.11 device.

  • Open System Authentication > Allows any device to authenticate and then attempt to communicate with the AP. The STA can communicate only its Wired Equivalent Privacy(WEP) keys match the AP
  • Shared Key Authentication > Not used anymore. Requires static WEP key configured on STA and AP.

Open System authentication and association between client STA and AP occurs prior to 802.1x/EAP authentication exchange between client STA and Radius server.

WLAN Encryption Methods

  • WEP
    • Pre-RSNA
    • Weak / Vulnerable / No Protection against replay attacks
    • Open/Shared Authentication
  • TKIP (Temporal Key Integrity Protocol) (RSN)
    • Uses dynamically created encryption keys as opposed to static keys.
    • 128-bit temporal key can either be a pairwise transient key (PTK) or group temporal key (GTK) used to encrypt
    • WPA-PSK & WPA-Enterprise
    • Can be vulnerable against certain attacks.
  • CTR with CBC-MAC Protocol (CCMP) (RSN)
    • CTR – Counter mode is used for data confidentiality
    • CBC MAC(Cipher-block chaining message authentication code) is used for integrity.
    • Used with AES block cipher suite with 128 bit key
  • SAE (Simultaneous Authentication of Equals)
    • Uses SAE known as Dragonfly Key Exchange, with forward secrecy feature
    • WPA3 Personal – 128 Bit SAE, Enterprise – 192 bit SAE
    • Not Vulnerable to KRACK attacks and offline dictionary attacks.

The info that is protected by these L2 encryption methods is data found in layers of 3-7. L2 encryption methods are used to provide data privacy for 802.11 data frames. These methods encrypt MSDU payload of an 802.11 data frame.

Security Protocols WEP TKIP (WPA) CCMP (WPA2) OWE (Opportunistic Wireless Encryption)
Cipher RC4 RC4 AES AES-GCM & Elliptical Curve Cryptography
Key 40/104 bits 128 bits 128 bits 192 bits
Authentication N/A IEEE 802.1X/EAP/PSK IEEE 802.1X/EAP/PSK WPA3 Personal / Enterprise
Data integrity CRC32 MIC CCMP Secure Hash Algorithm-2 for each input
IV Length 24 bits 48 bits 48 bits 24 bits

RSNA (Robust Security Network Association)
First published & ratified as IEEE 802.11i-2004, defined stronger encryption and better authentication methods. Now part of 802.11-2007 standard. Association between two stations is referred to as RSNA which means the two radios should share dynamic encryption keys that are unique between those two radios. CCMP/AES s mandatory, TKIP RC4 is optional. All client stations have to undergo a unique RSNA process called the 4-way handshake.

FIGURE 9.12 
Key 1 
RSNA within a BSS 
Group temporal key (GTK) 
Key 2 
Key 4 
Key 3 Access Point 
4-Way Handshake 
Keyl Key 4 
Key2 Key4 
Keys 1, 2, and 3 encrypt 
unicast traffic 
Key 4 encrypts 
broadcast/multicast traffic 
Key3 Key4

The RSN information element field is found in 4 management frames: beacon, probe, association request and reassociation request frames. Client STA use the association request frame & reassociation request (in case of roaming to/from) to inform the AP about their security capabilities.

FIGURE 9.18 
Association 
Client STA 
Reassociation 
Client station RSN security capabilities 
Association request frame 
RSN information element: 
Client STA security capabilities 
1) CCMP/AES encryption 
2) 802.1X authentication 
Association response frame 
Success! - Welcome to the BSS! 
Access Point 
Original AP 
Roaming Client STA 
Reassociation request frame 
RSN information element: 
New AP 
Client STA security capabilities 
1) CCMP/AES encryption 
2) 802.1X authentication 
Reassociation response frame 
Success! - Welcome to the new BSS!

RSN information element – AES(CCMP) used in the below frame example.

v Tag: RSN Information 
Tag Number: RSN Information (48) 
Tag length: 20 
RSN Version: 1 
Group Cipher Suite: (leee 802.11) AES (CCM) 
Pairwise Cipher Suite Count: 1 
Pairwise Cipher Suite List (leee 802.11) AES (CCM) 
Auth Key Management (AOI) Suite Count: 1 
Auth Key Management (AKM) List (leee 802.11) WPA 
RSN Capabilities: 
— RSN Pre—Auth capabilities: Transmitter does not support pre—authentication 
0. — RSN No Pairwise capabilities: Transmitter can support WEP default key 0 simultaneously with Pairwise key 
..ø. 
10.. = RSN PTKSA Replay 
10 = RSN GTKSA Replay 
. 0.. = Management Frame 
= Management Frame 
= Joint Multi—band 
= PeerKey Enabled: 
Counter capabilities: 4 replay counters per PTKSA/GTKSA/STAKeySA (Ox2) 
Counter capabilities: 4 replay counters per PTKSA/GTKSA/STAKeySA (Ox2) 
Protection Required: False 
Protection Capable: False 
RSNA: False 
False

802.1X

The 802.1X standard is port-based access control standard which provides an authorization framework that allows or disallows traffic to pass through port thereby granting access to the network resources.  802.1X can be implemented in either wireless/wired environments. The L2 protocol called EAP (Extensible Authentication Protocol) is used and consists of 3 major components of this framework.

  • Supplicant > Client STA
  • Authenticator > AP or WLAN Controller.
  • Authentication Server > Usually Radius(NPS), ISE (Cisco)
FIGURE 9.23 
comparison-autonomous access point and WLAN controller 
Autonomous AP 
(authenticator) 
Client station 
(supplicant) 
RADIUS server 
(authentication server) 
Network resources 
802. IX—Autonomous AP 
Lightweight 
Client station 
(supplicant) 
WLAN controller 
(authenticator) 
RADIUS server 
(authentication server) 
Network resources 
802. IX—WLAN Controller

EAP

Defined in IETF RFC 2284 and ratified in the IETF RFC 3748, provides support to many authentication methods.

  • L2 Protocol
  • Two way authentication also called as mutual authentication.
  • EAP messages are encapsulated in EAP over LAN (EAPOL)
  • Five major types of EAPOL messages as shown below
TABLE 9.1 
Packet type 
0000 0000 
0000 0001 
0000 0010 
0000 0011 
0000 0100 
EAPOL messages 
Name 
EAP-Packet 
EAPOL-Start 
EAPOL-Logoff 
EAPOL-Key 
EAPOL- Encapsulated - 
ASF-Alert 
Description 
This is an encapsulated EAP frame. The majority 
of EAP frames are EAP-Packet frames. 
This is an optional frame that the supplicant 
can use to start the EAP process. 
This frame terminates an EAP session and 
shuts down the virtual ports. Hackers some- 
times use this frame for DOS attacks. 
This frame is used to exchange dynamic keying 
information. For example, it is used during the 
4-Way Handshake. 
This frame is used to send alerts, such as 
SNMP traps to the virtual ports.
FIGURE 9.27 
Supplicant 
Generic EAP exchange 
Authentication 
Authenticator 
1 802.11 association 
2 EAPoL-start 
EAP-requesVidentity 
4 EAP-response/identity (username) 
EAP-challenge-request 
8 EAP-challenge-response 
EAP-success 
server 
Controlled and 
Access 
uncontrolled 
blocked 
ports blocked 
3 
7 
11 
5 
9 
Uncontrolled port opens 
RADIUS-access-request 
RADIUS-access-challenge 
RADIUS-access-request 
RADIUS-access-accept 
Access 
granted 
6 
10 
Dynamic encryption keys created 
12 
4-Way Handshake 
13 Controlled port opens

EAP Protocols

The stronger and more commonly deployed methods of EAP use TLS (Transport Layer Security) or TLS-tunneled authentication. EAP-MD5 and EAP-LEAP have only 1 supplicant identity making them weaker EAP types. EAP-TLS uses 2 supplicant identities – outer and inner identity. The outer identity is effectively a bogus username and can be seen clear text, and then inner identity is the true identity protected with TLS tunnel.  Table describes all the protocols with their characteristics.

802.1X EAP Types Feature / Benefit MD5 Message Digest 5 TLS Transport Level Security TTLS Tunneled Transport Level Security PEAP (WIDELY USED) Protected Transport Level Security FAST Flexible Authentication via Secure Tunneling LEAP Lightweight Extensible Authentication Protocol
Client-side certificate required no yes no no no (PAC) no
Server-side certificate required no yes yes yes no (PAC) no
WEP key management no yes yes yes yes yes
Rogue AP detection no no no no yes yes
Provider MS MS Funk Software MS Cisco Cisco
Authentication Attributes One way Mutual Mutual Mutual Mutual Mutual
Deployment Difficulty Easy Difficult (because of client certificate deployment) Moderate Moderate Moderate Moderate
Wi-Fi Security Poor Very High High High High High when strong passwords are used.

4-Way Handshake

802.11-2007 standard requires EAPOL-Key frames be used to exchange cryptographic information between STA supplicants and the authenticator, which is usually an AP. EAPOL key frames are used for the implementation of three different frames exchanges: 4-way handshake, group key exchange & peerkey handshake. 4 way handshake is the final process used to generate pairwise transient keys (PMK / GTK) for the encryption of unicast transmissions and the group temporal key for encryption of broadcast/multicast transmissions.

The 4-way handshake uses pseudorandom functions, it hashes various inputs to derive a value (PRF). The PMK is one of the inputs combined with other inputs to create the pairwise transient key (PMK). Some of the other inputs used by the PRF are called nonces. A nonce is a random numerical value that is generated one time only. In the case of 4-way handshake, a nonce is associated with the  PMK. Two nonces are created in 4-way handshake – authenticator nonce (anonce), supplicant nonce (snonce).

PTK = PRF (PMK + anonce + snonce + aa(Authenticator Mac)+ spa (Supplicant Mac).

M1 – Message 1

  • Authenticator sends EAPOL-Key frame containing “anonce” to supplicant
  • With this info,  supplicant have all the necessary input to generate PTK using PRF

M2 – Message 2

  • Supplicant sends an EAPOL-Key frame containing “snonce” to the authenticator
  • Authenticator has all the inputs to create PTK
  • Supplicant also sends RSN IE capabilities to Authenticator & MIC (message integrity code)

M3 – Message 3

  • If necessary, Authenticator will derive GTK from GMK
  • Authenticator sends EAPOL-key frame containing “anonce”, RSN-IE and a MIC.
  • GTP (encrypted with PTK) delivered to the supplicant.
  • Message to supplicant to install temporal keys.

M4 – Message 4

  • Supplicant sends final EAPOL-key frame to authenticator to confirm temporal keys have been installed.

Group Key Handshake

The 802.11-2007 standard also defines a two-frame handshake that is used to distribute a new group temporal key to client STA that have already obtained a PTK and GTK in a pervious 4-way handshake. The GKH is used only to issue a new group temporal key to client STA that have previously formed security associations. Effectively GKH is identical to M3/M4 in 4 way handshake.

Fast BSS Transition (FT)

Published in 2008, 802.11r – technical name for standardized fast secure roaming. An Amendment to improve handoff from one AP to another. The handoff is the same with or without 11r, the device is what ultimately decides when and where to roam.  802.11r are often discussed in context with WLAN controller architecture. Mobility domain is a group of AP that belong to the same ESS where the client STA can roam in a fast and secure manner. FT BSS transitions can happen over-the-air or over-the-DS (Distribution System).

FIGURE 9.33 
Fast BSS transition information element 
Element ID 
Length 
Octets: 
MIC 
Control 
2 
MIC 
16 
ANonce 
32 
SNonce 
32 
Optional 
Parameter(s) 
Variable

FT over-the-air (AP to AP, Same Controller)

  1. Client associates with AP1 and requests to roam to AP2
  2. Client sends a FT authentication request to AP2 and receive FT authentication response from AP2.
  3. Client sends FT reassociation request to AP2 and receives FT re-association response from AP2.
  4. Client completes the roaming from AP1 > AP2

FT over-the-air (AP-CONTROLLER|CONTROLLER-AP)(Inter-Controller)

  1. Step 1 & 2 similar to above steps.
  2. WLC1 ends PMK and mobility message to WLC-2 about the roaming client that uses mobility infrastructure.
  3. Client completes the roaming from AP1 > AP2
Tag: Mobility Domain 
Tag Number: Mobility Domain (54) 
Tag length: 3 
Mobility Domain Identifier: øxcd64 
FT Capability and Policy: exøø 
ø = Fast BSS Transition over DS: exø 
= Resource Request Protocol Capability: 
v Tag: Fast BSS Transition 
Tag Number: Fast BSS Transition (55) 
Tag length: 88 
MIC control: øxeeøø 
øxe 
eøøø eøøø 
= Element Count: e 
MIC: eøøøooøøøøeeøøøeoøøøooøøøøooøøøe 
ANonce: øeoøøøøooøøøooøøøooøøøøooøøøooøøøooøøøøooøøøooøøm 
SNonce: cc1f8ga18b7615afa146b8249a7311283587dd66ca57eeeg„. 
Subelement ID: PMK—Rø key holder identifier (ROKH—ID) (3) 
Length: 4 
PMK-RO key holder identifier (ROKH-ID): cea814øa

FT over-the-DS (AP to AP, Same Controller)

  1. Client Associates to AP1 and requests to roam to AP2
  2. Client sends a FT authentication request to AP1 and receives a FT authentication response from AP1
  3. The controller sends the pre-authentication info to AP2 as the AP are member of same controller.
  4. Client sends a FT re-association request to AP2 and receives a FT re-association response from AP2.
  5. Client completes its roaming

FT over-the-DS (AP to AP, Different Controller)

  1. Step 1 and 2 are similar to above steps.
  2. WLC-1 sends PMK and mobility message to WLC-2 about the roaming client
  3. Client completes its roam from AP1 to AP2.
Tag: Mobility Domain 
Tag Number: Mobility Domain (54) 
Tag length: 3 
Mobility Domain Identifier: øxcd64 
FT Capability and Policy: Oxø1 
Fast BSS Transition over DS: Oxl 
Resource Request Protocol Capability: 
Tag: Fast BSS Transition 
Tag Number: Fast BSS Transition (55) 
Tag length: 88 
MIC control: øxeeøø 
øxo 
eøøø eøøø 
= Element Count: e 
MIC: eøøøooøøøøooøøøooøøøooøøøøooøøøo 
ANonce: øeoøøøøooøøøooøøøooøøøøooøøøooøøøooøøøøooøøøooøø„. 
SNonce: f71ebøf1ef1b8725392f92f2979186ed912676cb6cb5cb53-. 
Subelement 
Length: 4 
PMK-RØ key 
ID: PM-Re key holder identifier (ROKH-ID) (3) 
holder identifier (ROKH—ID): cea814øa

Recommended Readings

Leave a Reply

Your email address will not be published. Required fields are marked *