Understand Opportunistic Wireless Encryption Flow

Available Languages

Download Options

PDF (2.7 MB)
View with Adobe Reader on a variety of devices
ePub (2.8 MB)
View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle) (1.8 MB)
View on Kindle device or Kindle app on multiple devices

Updated:March 21, 2025

Document ID:222885

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

This document describes OWE transition flow and how it works on the Catalyst 9800 Wireless LAN Controller (WLC).

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

How to configure the 9800 WLC, the Access Point (AP) for basic operation
How to configure WLAN and Policy Profiles.

Components Used

The information in this document is based on these software and hardware versions:

C9800-80, Cisco IOS® XE 17.12.4 and also tested in Cisco IOS® XE 17.9.6
AP model : C9136I, checked in both local and flex connect mode.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Description

OWE (Opportunistic Wireless Encryption) is an extension to IEEE 802.11 which provides encryption for the wireless medium. The purpose of OWE based authentication is to avoid open unsecured wireless connectivity between the AP’s and clients.
The OWE uses the Diffie-Hellman algorithms-based Cryptography to setup the wireless encryption.
With OWE, the client and AP perform a Diffie-Hellman key exchange during the access procedure and use the resulting pairwise secret with the 4-way handshake.
The use of OWE enhances wireless network security for deployments where Open or shared PSK based networks are deployed.

Steps

Configure one OPEN WLAN without any encryption/security and enable broadcasting.
Configure another SSID with OWE security settings and map the OPEN WLAN ID number in transition-mode-wlan-id. Disable broadcast SSID option in this OWE transition SSID.
Map the OWE transition WLAN ID number in OPEN WLAN "transition-mode-wlan-id" field.

Details of Lab Repro

Open SSID Name: OPEN-OWE
OWE Transition SSID Name: OWE-Transition
BSSID of OPEN-OWE: 40:ce:24:dd:2e:87
BSSID of OWE-Transition: 40:ce:24:dd:2e:8f

OWE FLOW

Beacons can be broadcast for OPEN SSID. You can see it by its SSID name in AIR PCAP.
We can also see the hidden security enabled SSID with the name "Wildcard" instead of its own SSID name in AIR PCAP.
Once the clients receive the beacon frame for OPEN SSID, if it has or supports OWE, then it can start sending probe request to OWE transition SSID (which is that security enabled SSID instead of OPEN SSID).
OWE supported clients can get probe response from transition SSID.
OPEN authentication can happen between client and AP.
Client can send association request to the AP with DH key exchange details and use the resulting pairwise secret for 4-way handshake.
AP can send association response.
Four-Way handshake can happen between AP and client device.
After successful key management, L2 PSK can be successful.
Client can get IP from DHCP,ARP etc,.
Client can go to RUN state.
If client devices which are not supporting OWE, then it can send probe request to OPEN SSID itself and it can directly get IP than it can go to RUN state.

Original Beacon frame

Here, AIR PCAP shows that, the SSID "OPEN-OWE" broadcasting (Beacon Frame). Which contains transition SSID details and it called "OWE-Transition".

Image-1 : Beacon Frame of OPEN SSID

Hidden SSID Beacons

As per WLAN configuration, "broadcasting" is disabled for this "OWE-Transition" SSID, however, you can see hidden SSID beacons in AIR PCAP which contain the SSID Name "Wildcard". However, if you check that packet, it contains OWE-Transition details.
Get the BSSID of hidden SSID by using the this packet, such as "40:ce:24:dd:2e:8f" and search it in packet capture.
In this packet, it shows that, SSID "Missing" and it contains its transition SSID as "OPEN-OWE" and its BSSID "40:ce:24:dd:2e:87".

Image-2 : Hidden SSID - OWE Transition

Probe Request sent from client to OWE Transition SSID

Based on the beacon frame "OPEN-OWE" SSID, the client comes to know the other SSID details which it needs to connect, in this scenario, it is "OWE-Transition". If client is able to support OWE encryption, then it can send the probe request to "OWE-Transition" SSID and get a response.
Probe request sent to OWE-Transition BSSID "40:ce:24:dd:2e:8f" and got a response. Inside this probe response packet also, you can see OPEN-OWE SSID details.

Image-3 : Probe Request

Probe Response sent from AP to Client

Client received probe response for the SSID “OWE-Transition” however it has its original SSID details “OPEN-OWE” in WiFi Alliance.

Image-4 : Probe Response

OPEN authentication

After getting probe response, OPEN authentication can happen between Client and AP to check the clients wifi details/capabilities, before association.

Image-5 : OPEN Authentication after successful Probe

Association Request from client to AP

In this packet, notice the client can be attaching Diffie-Hellman parameter value for encryption.

Image-6 : Association Request

In RA trace, you can start seeing the client logs from Association phase,

2025/01/21 15:21:57.391071821 {wncd_x_R0-0}{1}: [client-orch-sm] [21675]: (note): MAC: ee13.e8a8.cd5b  Association received. BSSID 40ce.24dd.2e8f, WLAN OWE-Transition, Slot 1 AP 40ce.24dd.2e80, APA023.9F66.1B3C, Site tag default-site-tag, Policy tag default-policy-tag, Policy profile OWE-Policy, Switching Central, Socket delay 0ms
2025/01/21 15:21:57.391117645 {wncd_x_R0-0}{1}: [client-orch-sm] [21675]: (debug): MAC: ee13.e8a8.cd5b  Received Dot11 association request. Processing started,SSID: OWE-Transition, Policy profile: OWE-Policy, AP Name: APA023.9F66.1B3C, Ap Mac Address: 40ce.24dd.2e80BSSID MAC0000.0000.0000wlan ID: 36RSSI: -42, SNR: 49

Association Response sent from AP to Client

Image-7 : Association Response

2025/01/21 15:21:57.391334260 {wncd_x_R0-0}{1}: [client-orch-state] [21675]: (note): MAC: ee13.e8a8.cd5b  Client state transition: S_CO_INIT -> S_CO_ASSOCIATING
2025/01/21 15:21:57.392296819 {wncd_x_R0-0}{1}: [dot11] [21675]: (note): MAC: ee13.e8a8.cd5b  Association success. AID 1, Roaming = False, WGB = False, 11r = False, 11w = True Fast roam = False

Key Exchange

4-way handshake can happen between AP and client device.

Key-1 send by AP

Key-2 send by client

Key-3 send by AP

Key-4 send by client

Image-8 : 4-Way Handshake

2025/01/21 15:21:57.392538716 {wncd_x_R0-0}{1}: [client-orch-sm] [21675]: (debug): MAC: ee13.e8a8.cd5b  Starting L2 authentication. Bssid in state machine:40ce.24dd.2e8f  Bssid in request is:40ce.24dd.2e8f
2025/01/21 15:21:57.392557538 {wncd_x_R0-0}{1}: [client-orch-state] [21675]: (note): MAC: ee13.e8a8.cd5b  Client state transition: S_CO_ASSOCIATING -> S_CO_L2_AUTH_IN_PROGRESS
2025/01/21 15:21:57.392640494 {wncd_x_R0-0}{1}: [client-auth] [21675]: (note): MAC: ee13.e8a8.cd5b  L2 Authentication initiated. method PSK, Policy VLAN 1417, AAA override = 0, NAC = 0
2025/01/21 15:21:57.394830551 {wncd_x_R0-0}{1}: [client-auth] [21675]: (info): MAC: ee13.e8a8.cd5b  Client auth-interface state transition: S_AUTHIF_AWAIT_PSK_AUTH_START_RESP -> S_AUTHIF_PSK_AUTH_PENDING
2025/01/21 15:21:57.395171903 {wncd_x_R0-0}{1}: [client-auth] [21675]: (info): MAC: ee13.e8a8.cd5b  Client auth-interface state transition: S_AUTHIF_PSK_AUTH_PENDING -> S_AUTHIF_ADD_MOBILE_ACK_WAIT_KM
2025/01/21 15:21:57.420590731 {wncd_x_R0-0}{1}: [client-auth] [21675]: (info): MAC: ee13.e8a8.cd5b  Client auth-interface state transition: S_AUTHIF_ADD_MOBILE_ACK_WAIT_KM -> S_AUTHIF_PSK_AUTH_KEY_XCHNG_PENDING

2025/01/21 15:21:57.420706435 {wncd_x_R0-0}{1}: [client-keymgmt] [21675]: (info): MAC: ee13.e8a8.cd5b  EAP key M1 Sent successfully

2025/01/21 15:21:57.420775720 {wncd_x_R0-0}{1}: [client-keymgmt] [21675]: (info): MAC: ee13.e8a8.cd5b  Client key-mgmt state transition: S_INITPMK -> S_PTK_START

2025/01/21 15:21:57.426548998 {wncd_x_R0-0}{1}: [client-keymgmt] [21675]: (info): MAC: ee13.e8a8.cd5b   M2 Status: EAP key M2 validation success

2025/01/21 15:21:57.426725965 {wncd_x_R0-0}{1}: [client-keymgmt] [21675]: (info): MAC: ee13.e8a8.cd5b  EAP key M3 Sent successfully

2025/01/21 15:21:57.426727805 {wncd_x_R0-0}{1}: [client-keymgmt] [21675]: (info): MAC: ee13.e8a8.cd5b  Client key-mgmt state transition: S_PTK_START -> S_PTKINITNEGOTIATING

2025/01/21 15:21:57.434078994 {wncd_x_R0-0}{1}: [client-keymgmt] [21675]: (info): MAC: ee13.e8a8.cd5b  M4 Status: EAP key M4 validation is successful

2025/01/21 15:21:57.434099154 {wncd_x_R0-0}{1}: [client-keymgmt] [21675]: (note): MAC: ee13.e8a8.cd5b  EAP Key management successful. AKM:OWE Cipher:CCMP WPA Version: WPA3

L2 Authentication Successful

2025/01/21 15:21:57.434111288 {wncd_x_R0-0}{1}: [client-keymgmt] [21675]: (info): MAC: ee13.e8a8.cd5b  Client key-mgmt state transition: S_PTKINITNEGOTIATING -> S_PTKINITDONE
2025/01/21 15:21:57.434250308 {wncd_x_R0-0}{1}: [client-auth] [21675]: (note): MAC: ee13.e8a8.cd5b  L2 PSK Authentication Success. EAP type: NA, Resolved VLAN: 1417, Audit Session id: 0000000000001BBA88469FD1
2025/01/21 15:21:57.434286035 {wncd_x_R0-0}{1}: [client-auth] [21675]: (info): MAC: ee13.e8a8.cd5b  Client auth-interface state transition: S_AUTHIF_PSK_AUTH_KEY_XCHNG_PENDING -> S_AUTHIF_PSK_AUTH_DONE
2025/01/21 15:21:57.434308953 {wncd_x_R0-0}{1}: [client-orch-sm] [21675]: (debug): MAC: ee13.e8a8.cd5b  L2 Authentication of station is successful., L3 Authentication : 0

IP Learning State

2025/01/21 15:21:57.434789679 {wncd_x_R0-0}{1}: [client-orch-sm] [21675]: (note): MAC: ee13.e8a8.cd5b  Mobility discovery triggered. Client mode: Local
2025/01/21 15:21:57.436611026 {wncd_x_R0-0}{1}: [client-orch-state] [21675]: (note): MAC: ee13.e8a8.cd5b  Client state transition: S_CO_MOBILITY_DISCOVERY_IN_PROGRESS -> S_CO_DPATH_PLUMB_IN_PROGRESS
2025/01/21 15:21:57.437239513 {wncd_x_R0-0}{1}: [client-orch-state] [21675]: (note): MAC: ee13.e8a8.cd5b  Client state transition: S_CO_DPATH_PLUMB_IN_PROGRESS -> S_CO_IP_LEARN_IN_PROGRESS
2025/01/21 15:21:57.437508189 {wncd_x_R0-0}{1}: [client-iplearn] [21675]: (info): MAC: ee13.e8a8.cd5b  IP-learn state transition: S_IPLEARN_INIT -> S_IPLEARN_IN_PROGRESS
2025/01/21 15:21:57.534166453 {wncd_x_R0-0}{1}: [sisf-packet] [21675]: (info): TX: DHCPv4 from interface capwap_90000016 on vlan 1417 Src MAC: ee13.e8a8.cd5b Dst MAC: ffff.ffff.ffff src_ip: 0.0.0.0, dst_ip: 255.255.255.255, BOOTPREQUEST, SISF_DHCPREQUEST, giaddr: 0.0.0.0, yiaddr: 0.0.0.0, CMAC: ee13.e8a8.cd5b
2025/01/21 15:21:57.535325325 {wncd_x_R0-0}{1}: [client-iplearn] [21675]: (note): MAC: ee13.e8a8.cd5b  Client IP learn successful. Method: DHCP IP: 10.107.81.254
2025/01/21 15:21:57.535874658 {wncd_x_R0-0}{1}: [sisf-packet] [21675]: (info): TX: DHCPv4 from interface Tw0/0/1 on vlan 1417 Src MAC: 4cec.0fde.a4c1 Dst MAC: ee13.e8a8.cd5b src_ip: 10.107.81.1, dst_ip: 10.107.81.254, BOOTPREPLY, SISF_DHCPACK, giaddr: 0.0.0.0, yiaddr: 10.107.81.254, CMAC: ee13.e8a8.cd5b
2025/01/21 15:21:57.536500021 {wncd_x_R0-0}{1}: [client-orch-sm] [21675]: (debug): MAC: ee13.e8a8.cd5b  Received ip learn response. method: IPLEARN_METHOD_DHCP

Client in RUN state

2025/01/21 15:21:57.537017277 {wncd_x_R0-0}{1}: [client-orch-state] [21675]: (note): MAC: ee13.e8a8.cd5b  Client state transition: S_CO_IP_LEARN_IN_PROGRESS -> S_CO_RUN

Clients which are not supported for OWE encryption

By reviewing a beacon frame itself, the clients come to know, whether they are able to support this encryption method or not. If it is not supported, then it can just send a probe request to open SSID “OPEN-OWE” and can do a normal open authentication, get IP address, then it can go the RUN state.

2025/01/16 15:36:06.178370757 {wncd_x_R0-2}{1}: [client-orch-sm] [17332]: (note): MAC: d037.4587.8f35  Association received. BSSID 6cd6.e301.bbae, WLAN OPEN-OWE, Slot 1 AP 6cd6.e301.bba0, ap01, Site tag default-site-tag, Policy tag Laki-Policy-Tag, Policy profile OWE-Policy, Switching Central, Socket delay 0ms
2025/01/16 15:36:06.209288788 {wncd_x_R0-2}{1}: [dot11] [17332]: (note): MAC: d037.4587.8f35  Association success. AID 1, Roaming = False, WGB = False, 11r = False, 11w = False Fast roam = False
2025/01/16 15:36:06.248651191 {wncd_x_R0-2}{1}: [client-auth] [17332]: (note): MAC: d037.4587.8f35  Open L2 Authentication Success. EAP type: NA, Resolved VLAN: 1417, Audit Session id: 000000000000000B696B83DE
2025/01/16 15:36:06.248751507 {wncd_x_R0-2}{1}: [client-orch-state] [17332]: (note): MAC: d037.4587.8f35  Client state transition: S_CO_L2_AUTH_IN_PROGRESS -> S_CO_MOBILITY_DISCOVERY_IN_PROGRESS
2025/01/16 15:36:06.281808554 {wncd_x_R0-2}{1}: [client-orch-state] [17332]: (note): MAC: d037.4587.8f35  Client state transition: S_CO_MOBILITY_DISCOVERY_IN_PROGRESS -> S_CO_DPATH_PLUMB_IN_PROGRESS
2025/01/16 15:36:06.303307756 {wncd_x_R0-2}{1}: [client-orch-state] [17332]: (note): MAC: d037.4587.8f35  Client state transition: S_CO_DPATH_PLUMB_IN_PROGRESS -> S_CO_IP_LEARN_IN_PROGRESS
2025/01/16 15:36:10.305041414 {wncd_x_R0-2}{1}: [client-iplearn] [17332]: (note): MAC: d037.4587.8f35  Client IP learn successful. Method: ARP IP: 10.106.241.167
2025/01/16 15:36:10.305777492 {wncd_x_R0-2}{1}: [client-orch-state] [17332]: (note): MAC: d037.4587.8f35  Client state transition: S_CO_IP_LEARN_IN_PROGRESS -> S_CO_RUN

Fast Transition Information

We are able to configure OWE only in OPEN authentication or in Webauth (CWA/LWA/EWA).
FT is not supported in OWE transition.
If you enable FT, you get this error message,

Error Message when you enable FT in OWE Transition SSID Image-9 : Error Message when we enable FT in OWE Transition SSID

OWE is not supported with PSK/dot1x

We are not able to enable OWE in these combinations,

1. 802.1x or FT+802.1x

2. PSK or FT+PSK or PSK-SHA256

3. SAE or FT+SAE

4. 802.1x-SHA256 or FT+802.1x-SHA256

If you try to enable any one of the these methods, you can get the error message,

Image-10: Error Message getting while enabling other authentication methods in OWE SSID

Image-11: Error Message while enabling AKM

In Cisco IOS® XE 17.9.6 IOS version, you can see "OWE" option under AKM when you select "WPA2+WPA3" however you can get the error message, you are not able to use OWE with this combination.

Image-12: Error message when we choose WPA2+WPA3

In Cisco IOS® XE 17.12.4 version, when you choose "WPA2+WPA3", you cannot get the option "OWE" in AKM,

Image-13 : Error Message - Not getting OWE option in AKM

Troubleshooting

Check the configurations in both the WLANs, in OPEN SSID and in OWE transition SSID must have transition WLAN ID mapped.
Broadcasting option must be disabled in OWE transition SSID, it must be enabled only in OPEN SSID.
Check the supported authentication/encryption/FT methods described in this article.
If the configurations are fine from WLC end, than please collect the required logs and outputs to narrow down the issue,

RA Trace and EPC (Embeded PAcket Capture)

Login to WLC GUI -> Troubleshooting -> Radioactive Trace -> Add client wifi MAC address -> Click that clients checkbox -> Start

Login to WLC GUI -> Troubleshooting -> Packet Capture -> Add new file name -> Choose the uplink interface and WMI VLAN/Interface -> Start.

From Client Machine: If possible, you can install wireshark application and collect the packet capture by choosing WiFi interface.

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/213949-wireless-debugging-and-log-collection-on.html#anc12

AIR PCAP

You can collect it by using MAC laptop or configuring one of the AP in to sniffer mode, please refer these links,

From MAC laptop:

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-mobility/217042-collect-packet-captures-over-the-air-on.html

From Sniffer AP:

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/217057-configure-access-point-in-sniffer-mode-o.html

Connect one laptop (wireshark server) to the switch port and it must have wireshark application installed in it, this wireshark server must have reachability to WLC WMI interface. Need to allow the protocol "5555 or 5000 or 5556" in firewall if it presents in between your WLC and wireshark server.

Check is there any "gscaler" installed in that PC where wireshark installed, if it is than please "turn off" and try, if it is any firewall like windows defender or anything present in it, please disable those and try to collect PCAP.

Roaming

When client roams from one AP to another, it needs to do these steps,

Need to send re-association/association - Depends on the client request.
Need to send DH (Diffie-Helman) details in association request.
Client can get DH details in association response from AP, based on this PMK gets generated in both client and AP.
4-Way handshake can happen between AP and client.
In OWE, you are unable to enable FT, so 802.11r is not possible.
Each time, when client roams, it needs to do 4-way handshake after DH exchange in association.
Client and AP using its own PMKID, it is unique for each APs and clients.
If client connects to the same AP, than it can use the same PMKID. In some scenario, if the client got deleted than AP can generate a new PMKID however the client uses the same PMKID for 4-way handshake.

Example:

If client connects to the same AP, then you can see same PMKID in both Association-Request and Association-Response. In Association response, you cannot see DH details if it uses the same PMKID.

Image-14: Using Same PMKID

Image-15: Association Response with same PMKID

For testing, deleted this client manually from WLC and it got associated again to the same AP, at this time, the client sends a same PMKID however AP sends DH details in association response.

Image-16: After deleting, Client sent same PMKID with DH details

Image-17: AP uses DH values to generate its new PMKID

In this example: Both AP and client uses the same PMKID while doing 4-Way handshake, check in "M1 and in M2" messages.

Image- 18: AP and Client using the same PMKID

In this example: Client using the same PMKID but AP using different PMKID which it generated after client got deleted, check "M1 and M2" messages.

Image-19: AP and Client using different PMKID

From Internal RA Trace:

In this example: Client sent DH parameters in association-request and AP processed than generated the PMK.

2025/01/21 15:18:50.157081690 {wncd_x_R0-0}{1}: [dot11-validate] [21675]: (debug): MAC: ee13.e8a8.cd5b  In case of DH parameter IE received.
2025/01/21 15:18:50.157082294 {wncd_x_R0-0}{1}: [dot11-validate] [21675]: (debug): MAC: ee13.e8a8.cd5b  Dot11 ie process received DH param element.
2025/01/21 15:18:50.157523328 {wncd_x_R0-0}{1}: [dot11-validate] [21675]: (debug): MAC: ee13.e8a8.cd5b  OWE: prk:
2025/01/21 15:18:50.157531792 {wncd_x_R0-0}{1}: [dot11-validate] [21675]: (debug): MAC: ee13.e8a8.cd5b  OWE: PMK:
2025/01/21 15:18:50.157532236 {wncd_x_R0-0}{1}: [dot11-validate] [21675]: (debug): MAC: ee13.e8a8.cd5b  OWE: PMKID:
2025/01/21 15:18:50.157532538 {wncd_x_R0-0}{1}: [dot11-validate] [21675]: (debug): MAC: ee13.e8a8.cd5b  Dot11 IE validate DH parameter element.IE ID = 255 , Len = 35
2025/01/21 15:18:50.157841380 {wncd_x_R0-0}{1}: [dot11-frame] [21675]: (debug): MAC: ee13.e8a8.cd5b  OWE :DH parameter element encoding sucessful

After this, the same client connecting to the same AP, at this time, AP did not generated new PMKID,

2025/01/21 15:21:57.391898613 {wncd_x_R0-0}{1}: [dot11-validate] [21675]: (debug): MAC: ee13.e8a8.cd5b  In case of DH parameter IE received.
2025/01/21 15:21:57.391903915 {wncd_x_R0-0}{1}: [dot11-validate] [21675]: (debug): MAC: ee13.e8a8.cd5b  Dot11 ie process received DH param element.
2025/01/21 15:21:57.391906073 {wncd_x_R0-0}{1}: [dot11-validate] [21675]: (debug): MAC: ee13.e8a8.cd5b  Dot11 ie validate DH param element. PMKID found so skipping DH processing.
2025/01/21 15:21:57.391906329 {wncd_x_R0-0}{1}: [dot11-validate] [21675]: (debug): MAC: ee13.e8a8.cd5b  Dot11 IE validate DH parameter element.IE ID = 255 , Len = 35

Revision History

Revision	Publish Date	Comments
1.0	21-Mar-2025	Initial Release

Contributed by Cisco Engineers

Lakshmi R
Technical Consulting Engineer

Was this Document Helpful?

Feedback

Contact Cisco

Open a Support Case
(Requires a Cisco Service Contract)