8.2 Controller-Level Security Suites, WPA3, OWE & Web Authentication

8.2 Controller-Level Security Suites, WPA3, OWE & Web Authentication

Core Blueprint Focus: Implementing robust enterprise wireless security requires moving beyond legacy pre-shared keys to modern standards defined by IEEE 802.11i, 802.11w, and the Wi-Fi Alliance WPA3 specifications. Understanding the cryptographic differences between WPA2 4-way handshakes and WPA3 SAE Dragonfly exchanges, configuring 192-bit CNSA enterprise modes, deploying OWE on public hotspots, and engineering Identity PSK (iPSK) on Cisco Catalyst 9800 controllers are core topics for Domain 5.0 of the WLCOR 350-101 exam.

---

1. Evolution of Wi-Fi Security & Cryptographic Vulnerabilities of WPA2

The history of wireless local area network security reflects an ongoing battle between cryptographic protocol engineering and practical computational attacks:

+---------------------------------------------------------------------------------------------------+
|                                 CHRONOLOGY OF WI-FI SECURITY STANDARDS                             |
|                                                                                                   |
|   1997: WEP              2003: WPA             2004: WPA2 (802.11i)         2018: WPA3 (WFA)      |
|   - RC4 Stream Cipher    - TKIP Temporary Fix   - CCMP (AES-128)             - SAE (Dragonfly)    |
|   - 24-bit Static IV     - 48-bit IV + Michael  - 4-Way Handshake            - GCMP-256 (192-bit) |
|   - CRC32 (Broken)       - RC4 Engine           - PMK = PBKDF2(Pass,SSID)    - OWE (Diffie-Hellm) |
|   - FMS Collision Attack - Per-Packet Mixing    - Vulnerable to Dict Attack  - Mandatory 802.11w  |
+---------------------------------------------------------------------------------------------------+

The Failure of Legacy Standards: WEP and WPA

• Wired Equivalent Privacy (WEP): Standardized in original IEEE 802.11-1997. WEP utilized the RC4 stream cipher with a 40-bit or 104-bit static key concatenated with a diminutive 24-bit Initialization Vector (IV). Because the 24-bit IV space contains only $2^{24} \approx 16.7\text{ million}$ values, an active enterprise access point reuses IVs within hours. Fluhrer, Mantin, and Shamir (FMS) demonstrated that weak IVs leak key bytes, allowing attackers to completely recover static WEP keys in under 60 seconds by capturing ~20,000 frames. Furthermore, WEP relied on CRC32 for frame integrity, which is mathematically linear and permits unauthenticated bit-flipping packet injection.
• Wi-Fi Protected Access (WPA): An interim standard created by the Wi-Fi Alliance in 2003 to salvage deployed legacy hardware. WPA introduced the Temporal Key Integrity Protocol (TKIP), expanding the IV space to 48 bits, implementing per-packet key mixing, and introducing the Michael Message Integrity Check (MIC). However, TKIP still relied on the underlying RC4 cipher, which was subsequently deprecated by IEEE 802.11-2012 due to fundamental keystream biases and Beck-Tews/Ohigashi-Nakamura attacks.

WPA2 Architecture and the 4-Way Handshake Vulnerability

WPA2, standardized in IEEE 802.11i-2004, mandated the Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP), which combines AES counter mode encryption (AES-CTR) for data confidentiality with CBC-MAC for frame integrity using 128-bit keys.

Despite CCMP's robust encryption engine, WPA2-Personal (WPA2-PSK) suffers from fundamental architectural weaknesses embedded within its key derivation and handshake mechanisms:

1. Deterministic, Static PMK Derivation: Under WPA2-PSK, the Pairwise Master Key (PMK) is derived deterministically from the pre-shared passphrase and SSID using Password-Based Key Derivation Function 2 (PBKDF2): $\text{PMK} = \text{PBKDF2}\Big(\text{HMAC-SHA1}, \; \text{Passphrase}, \; \text{SSID}, \; 4096, \; 256\Big)$ Because the passphrase and SSID are static, the resulting 256-bit PMK is completely identical across every device connecting to that SSID.
2. Passive Eavesdropping & Offline Dictionary Attacks: During the 802.11 4-Way Handshake, the Access Point and client exchange public pseudorandom nonces (ANonce from the AP in Message 1; SNonce from the client in Message 2) to derive the Pairwise Transient Key (PTK): $\text{PTK} = \text{PRF-512}\Big(\text{PMK}, \; \text{"Pairwise key expansion"}, \; \text{Min/Max(MACs)}, \; \text{Min/Max(Nonces)}\Big)$ In Message 2, the client transmits a Message Integrity Code (MIC) calculated over the frame using the Key Confirmation Key (KCK) extracted from the PTK.
   • The Exploit: An attacker operating a passive packet capture tool captures a single 4-Way Handshake (either organically or by injecting spoofed 802.11 deauthentication frames to force a reconnect). Because all inputs (MAC addresses, nonces, and MIC) are public except the passphrase, the attacker takes candidate passwords from wordlists or rainbow tables, computes candidate PMKs and PTKs offline, and checks whether the candidate KCK matches the captured MIC. With modern GPU clusters executing billions of HMAC-SHA1 operations per second, standard dictionary passphrases are cracked in minutes—without sending a single frame to the target AP.
3. Absence of Perfect Forward Secrecy (PFS): If an adversary records encrypted wireless RF captures over weeks or months, and subsequently discovers the corporate WPA2 passphrase (via social engineering, insider compromise, or decommissioned hardware), the adversary can retroactively decrypt every single captured session in the archive.
4. Key Reinstallation Attacks (KRACK, 2017): Mathy Vanhoef demonstrated that replaying Message 3 of the WPA2 4-Way Handshake tricks the client into reinstalling an already-in-use PTK, resetting the transmit packet number (nonce) and replay counter to zero. This keystream reuse enables attackers to decrypt frames, replay captured traffic, and forge TCP payloads.

---

2. WPA3-Personal & Simultaneous Authentication of Equals (SAE)

To remediate the architectural vulnerabilities of WPA2-PSK, the Wi-Fi Alliance introduced WPA3-Personal in 2018. WPA3-Personal completely replaces the legacy PSK exchange with Simultaneous Authentication of Equals (SAE), an implementation of the Dragonfly Key Exchange protocol standardized in RFC 7664.

The SAE Dragonfly Handshake Mechanics

SAE is a Password-Authenticated Key Exchange (PAKE) based on zero-knowledge proofs and discrete logarithm cryptography (operating over elliptic curves, such as NIST P-256 / secp256r1):

+---------------------------------------------------------------------------------------------------+
|                                 WPA3 SAE DRAGONFLY HANDSHAKE FLOW                                 |
|                                                                                                   |
|    [ Client (Station) ]                                                [ Access Point ]           |
|             |                                                                 |                   |
|             | <=============== 1. 802.11 Probe / Beacon (AKM 8) =============> |                   |
|             |                                                                 |                   |
|             | ------- 2. SAE Commit (Scalar_A, Element_A) ------------------> |                   |
|             | <------ 3. SAE Commit (Scalar_B, Element_B) ------------------- |                   |
|             |                                                                 |                   |
|             | [ Derives Ephemeral Secret ss ]               [ Derives Ephemeral Secret ss ]       |
|             | [ Calculates Key Confirmation Key ]           [ Calculates Key Confirmation Key ]   |
|             |                                                                 |                   |
|             | ------- 4. SAE Confirm (Send-Confirm Token_A) ----------------> |                   |
|             | <------ 5. SAE Confirm (Send-Confirm Token_B) ----------------- |                   |
|             |                                                                 |                   |
|             | [ Derives Session PMK ]                               [ Derives Session PMK ]       |
|             |                                                                 |                   |
|             | <=============== 6. Standard 802.11 4-Way Handshake ============> |                   |
|             |                   (Installs Dynamic PTK)                        |                   |
+---------------------------------------------------------------------------------------------------+

1. Password-Element (PWE) Derivation: Before exchanging frames, both the client and AP map the shared passphrase and SSID onto a point on an elliptic curve using the Hash-to-Curve (H2C) algorithm or the legacy hunting-and-pecking algorithm, establishing the Password-Element ($PWE$).
2. The Commit Phase: Each party generates a cryptographically random private scalar ($r$) and private mask ($m$). Each party computes a public scalar ($s = (r + m) \pmod q$) and a public element ($E = -m \times PWE$). The client and AP exchange their public scalars and public elements inside 802.11 Authentication frames with Authentication Algorithm set to SAE (value 3).
   • Zero-Knowledge Property: An eavesdropper intercepting the Commit frames learns nothing about the passphrase or the $PWE$. The scalar and element are mathematically masked and cannot be reversed without knowing the ephemeral random values.
3. The Confirm Phase: Both parties combine their private random scalar with the peer's public scalar and element to derive an identical ephemeral shared secret ($ss$). From this shared secret, they derive the Key Confirmation Key (KCK). Both parties exchange SAE Confirm frames containing a verification hash (Send-Confirm) over the exchange history. Successful verification proves that both entities possess the identical password.
4. Dynamic PMK Generation & 4-Way Handshake: The shared secret $ss$ is hashed to derive the unique Pairwise Master Key (PMK) for this specific connection. The AP and client then execute the standard 802.11 4-Way Handshake to install the CCMP/GCMP Pairwise Transient Key (PTK).

Key Cryptographic Advantages of WPA3-Personal SAE

• Defeat of Offline Dictionary Attacks: Because the Commit and Confirm exchanges do not expose a static hash or deterministic signature of the passphrase, an attacker cannot verify candidate passwords offline. Every single password guess requires an active, online SAE exchange with the controller/AP. Administrators can easily detect and mitigate online attacks by configuring authentication rate-limiting and client blacklisting.
• Perfect Forward Secrecy (PFS): Because the PMK is derived from ephemeral random scalars generated uniquely for each individual session, compromising the network passphrase in the future does not permit decryption of historically recorded wireless traffic.
• Side-Channel Timing Resistance (Hash-to-Curve): Early implementations of the Dragonfly hunting-and-pecking algorithm leaked timing information (Dragonblood vulnerability). WPA3 revisions enforce Hash-to-Curve (H2C), guaranteeing constant-time cryptographic execution regardless of passphrase structure.
• Mandatory 802.11w Protected Management Frames (PMF): WPA3 mandates PMF, protecting negotiated robust management frames such as deauthentication, disassociation, and specified action frames against forgery.

SAE Transition Mode (Mixed Mode) Considerations

To ease migration from legacy WPA2 to WPA3, the Wi-Fi Alliance defined SAE Transition Mode:

• A single WLAN/SSID advertises support for both WPA2-PSK (AKM suite 2: 00-0F-AC:2) and WPA3-SAE (AKM suite 8: 00-0F-AC:8).
• Management Frame Protection is configured as Optional (security pmf optional), allowing legacy non-PMF clients to connect.
• Security Warning for the Blueprint: SAE Transition Mode exposes the network to downgrade attacks. A malicious actor deploying a rogue AP can broadcast the corporate SSID advertising only AKM 2 (WPA2-PSK). Dual-mode clients encountering the rogue AP fall back to legacy WPA2, allowing the attacker to capture the 4-Way Handshake and perform offline dictionary cracking. For true security, mission-critical SSIDs must be configured for pure WPA3-SAE (security pmf mandatory and AKM 8 only).

---

3. WPA3-Enterprise: 128-Bit vs. 192-Bit CNSA / Suite B Modes

WPA3-Enterprise enhances 802.1X network access control by mandating 802.11w Protected Management Frames and standardizing high-grade cryptographic suites across two distinct deployment profiles:

1. WPA3-Enterprise 128-Bit Mode

• Data Payload Encryption: CCMP-128 (AES Counter Mode CBC-MAC 128-bit) or GCMP-128.
• Authentication & Key Management: Standard EAP methods (EAP-TLS, PEAP-MSCHAPv2, TEAP) utilizing RSA 2048-bit+ or ECC certificates with AKM Suite 1 (00-0F-AC:1).
• Protected Management Frames: Strictly mandatory (security pmf mandatory) utilizing Broadcast Integrity Protocol CMAC-128 (BIP-CMAC-128).
• Target Deployment: Standard enterprise corporate campus networks balancing broad client operating system compatibility with modern management frame protection.

2. WPA3-Enterprise 192-Bit Mode (CNSA / Suite B)

For defense, intelligence, critical infrastructure, and high-security government environments, WPA3 defines the 192-bit Security Mode, strictly aligned with the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) suite (formerly known as Suite B):

+---------------------------------------------------------------------------------------------------+
|                             CNSA / SUITE B 192-BIT CRYPTOGRAPHIC STACK                            |
|                                                                                                   |
|  [ Layer 2 Payload Encryption ] ---------> GCMP-256 (Galois/Counter Mode, 256-bit AES)             |
|  [ EAP Authentication Protocol ] --------> EAP-TLS (RFC 5216) with TLS 1.2 / TLS 1.3              |
|  [ Key Exchange Algorithm ] -------------> ECDHE over NIST Elliptic Curve P-384                   |
|  [ Digital Signatures / Identity ] -------> ECDSA with NIST Curve P-384 (X.509 Certificate)       |
|  [ Hash Algorithm & HMAC ] --------------> SHA-384 (Secure Hash Algorithm 384-bit)                |
|  [ Management Frame Protection ] --------> BIP-GMAC-256 (Broadcast Integrity Protocol)           |
|  [ Authentication Key Management ] ------> AKM Suite 12 (00-0F-AC:12)                            |
+---------------------------------------------------------------------------------------------------+

1. Data Frame Encryption: Galois/Counter Mode Protocol 256 (GCMP-256): Replaces 128-bit CCMP with 256-bit AES in Galois/Counter Mode. GCMP provides both authenticated encryption and data confidentiality. Because GCMP relies on Galois field multiplication ($GF(2^{128})$), it can be parallelized in hardware, delivering vastly superior throughput across multi-gigabit Wi-Fi 6/6E/7 APs compared to legacy serial CBC-MAC.
2. EAP-TLS Key Exchange: ECDHE P-384: Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) utilizing the NIST P-384 curve establishes the session keys during the EAP-TLS exchange, guaranteeing perfect forward secrecy.
3. Digital Certificates: ECDSA P-384: Both the Cisco ISE RADIUS server certificate and the client identity certificate must use the Elliptic Curve Digital Signature Algorithm (ECDSA) with public keys on the NIST P-384 curve, signed by an intermediate CA utilizing SHA-384. RSA certificates (even 2048-bit or 4096-bit) are strictly rejected in 192-bit mode.
4. Hashing & Key Derivation: SHA-384: The Key Derivation Function (KDF) uses HMAC-SHA-384 to derive the 384-bit Master Session Key (MSK), from which the 256-bit Pairwise Transient Key (PTK) and Key Confirmation Key (KCK) are generated.
5. Protected Management Frames: BIP-GMAC-256: BIP-GMAC-256 protects broadcast and multicast robust management frames covered by PMF. PMF also protects negotiated unicast robust frames such as deauthentication and disassociation; ordinary beacon and probe-response bodies are not generally protected by 802.11w, and PMF cannot prevent RF jamming or every denial-of-service technique.

Comparison: WPA3-Enterprise 128-Bit vs. 192-Bit CNSA

---

4. Opportunistic Wireless Encryption (OWE, RFC 8110)

For decades, public hotspots in airports, cafes, hotels, and municipal stadiums deployed Open Authentication (no security). On an open Wi-Fi network, every 802.11 data frame is transmitted in plaintext over the air, allowing any passive observer with an antenna to capture unencrypted HTTP payloads, DNS queries, session cookies, and cleartext metadata.

OWE Protocol Mechanics (Wi-Fi Enhanced Open)

To eliminate cleartext over-the-air snooping without imposing cumbersome user credentials, the Wi-Fi Alliance created Wi-Fi Enhanced Open, standardized by the IETF in RFC 8110 as Opportunistic Wireless Encryption (OWE):

• No Passwords, Pure Encryption: OWE provides pairwise encryption without authentication. Users do not enter a password, click a pre-shared key dialog, or install certificates. The device connects just as seamlessly as an open network, but all over-the-air data is encrypted with 128-bit or 256-bit AES.
• Diffie-Hellman Key Exchange in Association Frames: OWE embeds an ephemeral Diffie-Hellman key exchange directly within standard IEEE 802.11 management frames:

+---------------------------------------------------------------------------------------------------+
|                                    OWE KEY EXCHANGE WORKFLOW                                      |
|                                                                                                   |
|    [ Client Station ]                                                  [ Catalyst 9800 AP ]       |
|            |                                                                    |                 |
|            | ----- 1. 802.11 Open Authentication Request ---------------------> |                 |
|            | <---- 2. 802.11 Open Authentication Response -------------------- |                 |
|            |                                                                    |                 |
|            | ----- 3. 802.11 Association Request -----------------------------> |                 |
|            |       - AKM Suite 18 (00-0F-AC:18)                                 |                 |
|            |       - OWE DH Parameter Element (Group 19, Client Public Key)     |                 |
|            |                                                                    |                 |
|            | <---- 4. 802.11 Association Response ---------------------------- |                 |
|            |       - Status Code: Successful (0)                                |                 |
|            |       - OWE DH Parameter Element (Group 19, AP Public Key)         |                 |
|            |                                                                    |                 |
|            | [ Derives Shared Secret ss ]                       [ Derives Shared Secret ss ]      |
|            | [ Calculates Pairwise Master Key ]                 [ Calculates Pairwise Master Key ]|
|            |                                                                    |                 |
|            | <==== 5. Standard 802.11 4-Way Handshake ========================> |                 |
|            |       (Installs PTK - Data Encrypted with AES-CCMP)                |                 |
+---------------------------------------------------------------------------------------------------+

1. The client sends a standard 802.11 Open Authentication Request and receives an Open Authentication Response.
2. In the 802.11 Association Request, the client includes the OWE Diffie-Hellman Parameter Information Element (IE) with its public key for a supported group and AKM suite 18 (00-0F-AC:18). Group 19 is common, but it is not the only way to describe all compliant implementations.
3. The AP responds with an Association Response containing its public key for the negotiated group.
4. Both parties combine their private random scalar with the peer's public key to derive an identical shared secret ($ss$). The shared secret is passed through a Hash-based Key Derivation Function (HKDF) with the client/AP MAC addresses to derive the Pairwise Master Key (PMK).
5. The AP and client execute the 4-Way Handshake, install the PTK, and encrypt all subsequent unicast data frames with AES-CCMP.

• Mandatory Protected Management Frames: PMF is strictly mandatory under OWE (security pmf mandatory), safeguarding management traffic against spoofed deauthentication frames.

OWE Transition Mode

Because legacy client devices do not support OWE (AKM 18) and fail to associate when PMF is mandatory, network architects deploy OWE Transition Mode for public venues:

• Dual BSSID Pairing: The Catalyst 9800 controller is configured with two distinct WLAN profiles that are bound together:
  1. Broadcast Open WLAN (Legacy BSSID): An open, unencrypted WLAN that broadcasts its SSID (e.g., "Airport-Free-WiFi"). It contains an OWE Transition Mode Information Element advertising the BSSID and SSID of the paired hidden OWE WLAN.
  2. Hidden OWE WLAN (Enhanced Open BSSID): Configured with OWE AKM 18 and mandatory PMF, broadcasting with a hidden SSID.
• Client Behavior:
  • Legacy Clients: Inspect the beacon of Airport-Free-WiFi, ignore the OWE transition element (which they do not understand), and connect to the unencrypted open network.
  • OWE-Capable Clients: Inspect the beacon of Airport-Free-WiFi, parse the OWE transition element, suppress connection to the open BSSID, and automatically associate to the hidden encrypted OWE BSSID.

---

5. Identity Pre-Shared Key (iPSK) & Web Authentication Frameworks

While 802.1X provides optimal security for enterprise corporate endpoints, organizations frequently support thousands of specialized headless IoT devices (e.g., Zebra barcode scanners, factory automated guided vehicles, smart displays) that do not support 802.1X and cannot easily be reconfigured when a shared network passphrase is changed.

The Operational Failure of Group PSK

Deploying a traditional Group Pre-Shared Key across enterprise IoT fleets creates severe operational hazards:

• Single Key Compromise: If a single IoT sensor is stolen or its configuration extracted, the entire network key is compromised.
• Zero Forward Secrecy & Group Eavesdropping: Any user or device possessing the group PSK can capture the 4-Way Handshake of any other device and decrypt all of its traffic in real time.
• Operational Gridlock: Changing the passphrase requires physically touching or remotely re-provisioning hundreds or thousands of devices simultaneously, resulting in massive operational downtime.

Identity PSK (iPSK) Architecture

Identity Pre-Shared Key (iPSK) on the Cisco Catalyst 9800 WLC paired with Cisco ISE resolves group PSK vulnerabilities by providing unique, per-device or per-group pre-shared keys on a single broadcast SSID:

+---------------------------------------------------------------------------------------------------+
|                                     IDENTITY PSK (iPSK) FLOW                                      |
|                                                                                                   |
|    [ IoT Endpoint ]                 [ Catalyst 9800 WLC ]                     [ Cisco ISE ]       |
|           |                                   |                                     |             |
|           | ----- 1. 802.11 Association ----> |                                     |             |
|           |       (Client MAC: AABB.CCDD.0001)|                                     |             |
|           |                                   | --- 2. RADIUS Access-Request -----> |             |
|           |                                   |    (Calling-Station-Id = MAC)       |             |
|           |                                   |                                     |             |
|           |                                   | <--- 3. RADIUS Access-Accept ------ |             |
|           |                                   |    cisco-av-pair="psk-mode=ascii"   |             |
|           |                                   |    cisco-av-pair="psk=UniqueKey99"  |             |
|           |                                   |    Tunnel-Private-Group-ID = 30     |             |
|           |                                   |                                     |             |
|           |                                   | [ Computes Unique Endpoint PMK ]    |             |
|           |                                   |                                     |             |
|           | <==== 4. Standard 802.11 4-Way Handshake =============================> |             |
|           |       (Completed using UniqueKey99 / Placed in VLAN 30)                 |             |
+---------------------------------------------------------------------------------------------------+

1. The IoT endpoint associates to the SSID using its locally configured pre-shared key.
2. The Catalyst 9800 WLC detects MAC filtering enabled on the WLAN and transmits a RADIUS Access-Request to Cisco ISE containing the endpoint's MAC address in the Calling-Station-Id attribute.
3. Cisco ISE evaluates its endpoint identity database, matches the device profile (e.g., "Medical-Infusion-Pumps"), and returns a RADIUS Access-Accept payload containing custom Cisco AV-Pairs:
   • cisco-av-pair = "psk-mode=ascii" (or hex)
   • cisco-av-pair = "psk=SecretKeyForDevice123!"
   • Tunnel-Private-Group-ID = "30" (Dynamic VLAN segmentation)
   • cisco-av-pair = "cts:security-group-tag=0005-00" (Micro-segmentation SGT)
4. The Catalyst 9800 receives the returned pre-shared key and calculates the Pairwise Master Key (PMK) specific to that client. The WLC and endpoint execute the standard 802.11 4-Way Handshake. If the key configured on the endpoint matches the unique key returned by ISE, the handshake succeeds.

• Administrative Isolation: If an individual device is compromised or retired, an administrator revokes its MAC entry in Cisco ISE. Only that single device loses access; no other endpoint on the network is affected.

Web Authentication: Local WebAuth (LWA) vs. Central WebAuth (CWA)

Web Authentication is a Layer 3 security mechanism that intercepts client HTTP/HTTPS traffic and redirects the user's web browser to a login portal before granting network authorization:

• Local Web Authentication (LWA):
  • The Catalyst 9800 WLC hosts the web login portal locally on its internal web server (or proxies authentication to a simple external web page).
  • The WLC intercepts TCP port 80/443 traffic, displays an internal login form, validates credentials locally or against RADIUS, and adjusts the client state.
  • Limitations: High CPU load on the WLC during large concurrent login spikes; severe SSL certificate warning issues on the WLC virtual IP interface; limited portal customization; no dynamic posture integration.
• Central Web Authentication (CWA):
  • The modern enterprise standard for guest access, BYOD onboarding, and device registration utilizing Cisco ISE.
  • The Redirection Architecture: When a client associates, Cisco ISE returns a dynamic authorization profile with two critical attributes:
    1. cisco-av-pair = "url-redirect=https://ise.domain.com:8443/portal/gateway?sessionId=..."
    2. cisco-av-pair = "url-redirect-acl=ACL_WEBAUTH_REDIRECT"
  • The Redirect ACL explicitly permits DNS (UDP 53), DHCP (UDP 67/68), and bidirectional communication to Cisco ISE nodes, while denying (intercepting) general web traffic (TCP 80/443).
  • When the client attempts to browse the internet, the Catalyst 9800 intercepts the HTTP request and returns an HTTP 302 Redirect pointing to the ISE Guest/BYOD portal with the client's MAC address and session ID appended to the URL.
  • Once the user authenticates, Cisco ISE issues an RFC 5176 RADIUS Change of Authorization (CoA-Reauth) to the Catalyst 9800. The WLC updates the client's session state, removes the redirect ACL, and applies the production authorized policy profile without dropping the client's RF connection.

---

6. Enterprise Wireless Security Protocols Comparison Matrix

The following matrix summarizes the architectural differences between enterprise wireless security standards:

---

7. CLI Configuration Snippet: Catalyst 9800 WLAN Security Architectures

The following production configurations illustrate how to implement WPA3-Personal SAE, WPA3-Enterprise 192-Bit (CNSA), Opportunistic Wireless Encryption (OWE) Transition Mode, and Identity PSK (iPSK) on Cisco Catalyst 9800 Series Wireless LAN Controllers running Cisco IOS-XE:

! =========================================================================
! 1. WPA3-PERSONAL (PURE SAE) & SAE TRANSITION MODE CONFIGURATION
! =========================================================================
! Pure WPA3-Personal SAE (Mandatory PMF, AKM 8 only)
wlan Corp-WPA3-SAE 10 Corp-WPA3-SAE
 security wpa psk set-key ascii 0 DragonflySecretPass2026!
 security wpa akm sae
 security pmf mandatory
 no shutdown

! WPA3-Personal SAE Transition Mode (WPA2-PSK + WPA3-SAE Coexistence)
wlan Corp-WPA3-Mixed 11 Corp-WPA3-Mixed
 security wpa psk set-key ascii 0 MixedModePassphrase2026!
 security wpa akm psk
 security wpa akm sae
 security pmf optional
 no shutdown

! =========================================================================
! 2. WPA3-ENTERPRISE 192-BIT (CNSA / SUITE B) CONFIGURATION
! =========================================================================
! Configure the AAA RADIUS Server Group
aaa group server radius ISE-CNSA-GROUP
 server name ISE-NODE-01
 server name ISE-NODE-02

! Configure 192-Bit Enterprise WLAN Profile
wlan Corp-CNSA-192bit 20 Corp-CNSA-192bit
 security wpa akm suiteb-192
 security wpa wpa2 ciphers gcmp-256
 security pmf mandatory
 security dot1x authentication-list ISE-CNSA-GROUP
 no shutdown

! =========================================================================
! 3. OPPORTUNISTIC WIRELESS ENCRYPTION (OWE) TRANSITION MODE
! =========================================================================
! Step 3A: Create the Hidden OWE WLAN Profile (Pairing Target)
wlan Public-OWE-Secure 30 Public-OWE-Secure
 security wpa akm owe
 security wpa wpa2 ciphers aes
 security pmf mandatory
 no broadcast-ssid
 no shutdown

! Step 3B: Create the Broadcast Open WLAN paired to the Hidden OWE WLAN
wlan Public-Open-Guest 31 Public-Open-Guest
 no security wpa
 owe transition-mode-wlan Public-OWE-Secure
 broadcast-ssid
 no shutdown

! =========================================================================
! 4. IDENTITY PRE-SHARED KEY (iPSK) WLAN CONFIGURATION
! =========================================================================
wlan IoT-iPSK-Fleet 40 IoT-iPSK-Fleet
 security wpa psk set-key ascii 0 FallbackDefaultKey2026!
 security wpa akm psk
 security pmf optional
 no security dot1x
 mac-filtering ISE-RADIUS-GROUP
 aaa-override
 no shutdown

! =========================================================================
! 5. CENTRALIZED REDIRECTION & DYNAMIC AUTHORIZATION (CoA) PREREQUISITES
! =========================================================================
! Enable RFC 5176 Change of Authorization on Catalyst 9800
aaa server radius dynamic-author
 client 10.10.20.50 server-key CiscoISEKey2026!
 auth-type any

! Define Redirect ACL for Central Web Authentication (CWA)
ip access-list extended ACL_WEBAUTH_REDIRECT
 deny udp any any eq domain
 deny udp any any eq bootps
 deny ip any host 10.10.20.50
 permit tcp any any eq www
 permit tcp any any eq 443