기회주의적 무선 암호화 흐름 이해

소개

이 문서에서는 OWE 전환 흐름과 Catalyst 9800 WLC(Wireless LAN Controller)에서 작동하는 방식에 대해 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• 기본 작동을 위해 9800 WLC, 액세스 포인트(AP)를 구성하는 방법
• WLAN 및 정책 프로필 구성 방법

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• C9800-80, Cisco IOS® XE 17.12.4 및 Cisco IOS® XE 17.9.6에서 테스트됨
• AP 모델: C9136I, 로컬 및 플렉스 연결 모드에서 모두 확인됨.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

설명

• OWE(Opportunistic Wireless Encryption)는 무선 매체를 위한 암호화를 제공하는 IEEE 802.11의 확장입니다. OWE 기반 인증의 목적은 AP와 클라이언트 간의 안전하지 않은 개방형 무선 연결을 방지하는 것입니다.
• OWE는 무선 암호화를 설정하기 위해 Diffie-Hellman 알고리즘 기반 암호화를 사용합니다.
• OWE를 사용하면 클라이언트와 AP는 액세스 절차 중에 Diffie-Hellman 키 교환을 수행하고 그 결과로 생성되는 페어와이즈 암호를 4방향 핸드셰이크로 사용합니다.
• OWE를 사용하면 개방형 또는 공유 PSK 기반 네트워크가 구축된 구축에서 무선 네트워크 보안이 향상됩니다.

단계

1.        암호화/보안 없이 하나의 OPEN WLAN을 구성하고 브로드캐스트를 활성화합니다.
2.        OWE 보안 설정으로 다른 SSID를 구성하고 변환 모드 wlan-id에서 OPEN WLAN ID 번호를 매핑합니다. 이 OWE 변환 SSID에서 브로드캐스트 SSID 옵션을 비활성화합니다.
3.        OPEN WLAN "transition-mode-wlan-id" 필드에 OWE 전환 WLAN ID 번호를 매핑합니다.

Lab Repro 세부 정보

• 개방형 SSID 이름: 채무액 공개
• OWE 전환 SSID 이름: 채무 이행
• OPEN-WISE의 BSSID: 40:ce:24:dd:2e:87
• BSSID OF OWE-Transition(WISE-Transition의 BSSID): 40:ce:24:dd:2e:8f

OWE 플로우

1. 신호는 OPEN SSID에 대해 브로드캐스트될 수 있습니다. AIR PCAP에서 해당 SSID 이름으로 신호를 볼 수 있습니다.
2. 또한 AIR PCAP에서 자체 SSID 이름 대신 "Wildcard"라는 이름의 숨겨진 보안 지원 SSID를 볼 수 있습니다.
3. 클라이언트가 OPEN SSID에 대한 비콘 프레임을 수신하면 WISE가 있거나 이를 지원하는 경우 WISE 전환 SSID(OPEN SSID 대신 보안이 활성화된 SSID)로 프로브 요청 전송을 시작할 수 있습니다.
4. WISE 지원 클라이언트는 전환 SSID에서 프로브 응답을 가져올 수 있습니다.
5. 클라이언트와 AP 간에 OPEN 인증이 발생할 수 있습니다.
6. 클라이언트는 DH 키 교환 세부사항이 포함된 연결 요청을 AP에 전송하고 그 결과로 생성되는 쌍방향 암호를 4-way 핸드셰이크에 사용할 수 있습니다.
7. AP에서 연결 응답을 보낼 수 있습니다.
8. AP와 클라이언트 장치 간에 4방향 핸드셰이크가 발생할 수 있습니다.
9. 성공적인 키 관리 후에는 L2 PSK가 성공할 수 있습니다.
10. 클라이언트는 DHCP, ARP 등에서 IP를 가져올 수 있습니다.
11. 클라이언트는 RUN 상태로 전환할 수 있습니다.
12. WISE를 지원하지 않는 클라이언트 디바이스인 경우 OPEN SSID 자체에 프로브 요청을 보낼 수 있으며 RUN 상태로 갈 수 있는 것보다 직접 IP를 가져올 수 있습니다.

원래 비컨 프레임

• 여기서 AIR PCAP는 SSID "OPEN-WISE" 브로드캐스트(비콘 프레임)를 보여줍니다. 전환 SSID 세부사항이 포함되어 있으며 "OWE-Transition"이라고 합니다.

이미지-1: 개방형 SSID의 비콘 프레임

숨겨진 SSID 비콘

• WLAN 컨피그레이션에 따라 이 "OWE-Transition" SSID에 대해 "broadcasting"이 비활성화되지만 AIR PCAP에서 SSID 이름 "Wildcard"가 포함된 숨겨진 SSID 신호를 볼 수 있습니다. 그러나 해당 패킷을 선택하면 WISE-Transition 세부 정보가 포함됩니다.
• 이 패킷을 사용하여 숨겨진 SSID의 BSSID를 가져옵니다(예: "40:ce:24:dd:2e:8f"). 패킷 캡처에서 검색합니다.
• 이 패킷에서는 SSID가 "Missing"이고 전환 SSID가 "OPEN-WISE"로, BSSID가 "40:ce:24:dd:2e:87"로 표시됨을 보여 줍니다.

이미지-2: 숨겨진 SSID - OWE 전환

클라이언트에서 WISE 전환 SSID로 전송된 프로브 요청

• 비콘 프레임 "OPEN-WISE" SSID를 기반으로 클라이언트는 연결해야 하는 다른 SSID 세부사항을 알게 됩니다. 이 시나리오에서 "WISE-Transition"입니다. 클라이언트가 WISE 암호화를 지원할 수 있는 경우 프로브 요청을 "WISE-Transition" SSID로 전송하고 응답을 받을 수 있습니다.
• 프로브 요청이 WISE-Transition BSSID "40:ce:24:dd:2e:8f"로 전송되었으며 응답을 받았습니다. 이 프로브 응답 패킷 내에서도 OPEN-WISE SSID 세부사항을 볼 수 있습니다.

이미지-3: 프로브 요청

AP에서 클라이언트로 전송된 프로브 응답

• 클라이언트는 SSID "OWE-Transition"에 대한 프로브 응답을 받았지만 WiFi Alliance에 원래 SSID 세부사항 "OPEN-OWE"가 있습니다.

이미지-4: 프로브 응답

OPEN 인증

• 프로브 응답을 받은 후 연결 전에 클라이언트와 AP 간에 OPEN 인증을 수행하여 클라이언트 wifi 세부사항/기능을 확인할 수 있습니다.

이미지-5: Probe 성공 후 OPEN 인증

클라이언트에서 AP로의 연결 요청

• 이 패킷에서는 클라이언트가 암호화를 위해 Diffie-Hellman 매개변수 값을 연결할 수 있습니다.

이미지-6: 연결 요청

• RA 추적에서는 Association(연결) 단계에서 클라이언트 로그를 볼 수 있습니다.

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

AP에서 클라이언트로 보낸 연결 응답

이미지-7: 연결 응답

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

키 교환

AP와 클라이언트 장치 간에 4-way 핸드셰이크가 발생할 수 있습니다.

Key-1 send by AP(AP에 의한 키-1 전송)

Key-2 클라이언트에서 전송

Key-3 send by AP(AP에 의한 키-3 전송)

Key-4 클라이언트에서 전송

이미지-8: 4-Way 핸드셰이크

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 인증 성공

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 학습 상태

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

클라이언트 실행 상태

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

WISE 암호화가 지원되지 않는 클라이언트

• 비콘 프레임 자체를 검토하면 클라이언트는 이 암호화 방법을 지원할 수 있는지 여부를 알게 됩니다. 지원되지 않는 경우, SSID "OPEN-WISE"를 열기 위해 프로브 요청을 보내고 일반적인 개방형 인증을 수행하여 IP 주소를 가져온 다음 RUN 상태로 전환할 수 있습니다.

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

빠른 전환 정보

• OPEN 인증 또는 Webauth(CWA/LWA/EWA)에서만 OWE를 구성할 수 있습니다.
• FT는 OWE 변환에서 지원되지 않습니다.
• FT를 활성화하면 다음과 같은 오류 메시지가 표시됩니다.

이미지-9: Owne Transition SSID에서 FT를 활성화하는 경우 오류 메시지

WISE는 PSK/dot1x에서 지원되지 않습니다.

이러한 조합에서는 OWE를 활성화할 수 없습니다.

1. 802.1x 또는 FT+802.1x

2. PSK 또는 FT+PSK 또는 PSK-SHA256

3. SAE 또는 FT+SAE

4. 802.1x-SHA256 또는 FT+802.1x-SHA256

이러한 방법 중 하나를 활성화하려고 하면

이미지-10: WISE SSID에서 다른 인증 방법을 활성화하는 동안 오류 메시지를 받습니다.

이미지-11: AKM을 활성화하는 동안 오류 메시지 표시

• Cisco IOS® XE 17.9.6 IOS 버전에서는 "WPA2+WPA3"을 선택하면 AKM에서 "OWE" 옵션을 볼 수 있지만 이 조합에서는 OWE를 사용할 수 없다는 오류 메시지가 표시됩니다.
  
  이미지-12: WPA2+WPA3을 선택할 때 오류 메시지 표시

• Cisco IOS® XE 17.12.4 버전에서는 "WPA2+WPA3"을 선택하면 AKM에서 "OWE" 옵션을 사용할 수 없습니다.
  
  이미지-13: 오류 메시지 - AKM에서 WISE 옵션을 가져오지 않음

문제 해결

1. WLAN, OPEN SSID 및 OWE Transition SSID 모두에서 컨피그레이션을 확인하려면 전환 WLAN ID가 매핑되어야 합니다.
2. Broadcasting 옵션은 WISE 전환 SSID에서 비활성화해야 하며 OPEN SSID에서만 활성화해야 합니다.
3. 이 문서에 설명된 지원되는 인증/암호화/FT 방법을 확인하십시오.
4. WLC 쪽에서 컨피그레이션이 괜찮은 경우, 에서는 필요한 로그와 출력을 수집하여 문제를 좁혀 주십시오.

RA 추적 및 EPC(임베디드 패킷 캡처)

WLC GUI에 로그인 -> 문제 해결 -> Radioactive Trace(방사능 추적) -> Add client wifi MAC address(클라이언트 wifi MAC 주소 추가) -> Click that clients(해당 클라이언트) 확인란 -> Start(시작) 

WLC GUI에 로그인 -> 문제 해결 -> 패킷 캡처 -> 새 파일 이름 추가 -> 업링크 인터페이스 및 WMI VLAN/Interface -> Start(시작)를 선택합니다.

클라이언트 컴퓨터에서: 가능하면 wireshark 애플리케이션을 설치하고 WiFi 인터페이스를 선택하여 패킷 캡처를 수집할 수 있습니다.

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

항공 모함

MAC 랩톱을 사용하거나 AP 중 하나를 스니퍼 모드로 구성하여 수집할 수 있습니다. 이 링크를 참조하십시오.

MAC 노트북 컴퓨터에서:

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

스니퍼 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

한 랩톱(wireshark 서버)을 스위치 포트에 연결하고 wireshark 애플리케이션이 설치되어 있어야 하며 이 wireshark 서버는 WLC WMI 인터페이스에 연결할 수 있어야 합니다. WLC와 wireshark 서버 사이에 프로토콜이 있는 경우 방화벽에서 "5555 또는 5000 또는 5556"을 허용해야 합니다.

wireshark가 설치된 PC에 "gscaler"가 설치되어 있는지 확인하고, "꺼주십시오", Windows Defender와 같은 방화벽이나 그 안에 있는 것이 있으면 비활성화하고 PCAP를 수집해 보십시오.

로밍

클라이언트가 한 AP에서 다른 AP로 로밍할 때 다음 단계를 수행해야 합니다.

• 다시 연결/연결을 전송해야 함 - 클라이언트 요청에 따라 다릅니다.
• 연결 요청에서 DH(Diffie-Helman) 세부 정보를 전송해야 합니다.
• 클라이언트는 이 PMK가 클라이언트와 AP 모두에서 생성됨을 기반으로 AP로부터 연결 응답에서 DH 세부사항을 가져올 수 있습니다.
• AP와 클라이언트 간에 4-Way 핸드셰이크가 발생할 수 있습니다.
• OWE에서는 FT를 활성화할 수 없으므로 802.11r을 사용할 수 없습니다.
• 클라이언트가 로밍할 때마다 DH 교환 후 4방향 핸드셰이크를 해야 합니다.
• 자체 PMKID를 사용하는 클라이언트와 AP는 각 AP 및 클라이언트마다 고유합니다.
• 클라이언트가 동일한 AP에 연결하는 경우 동일한 PMKID를 사용할 수 없습니다. 어떤 시나리오에서는 클라이언트가 AP보다 삭제되어 새 PMKID를 생성할 수 있지만 클라이언트는 4방향 핸드셰이크에 동일한 PMKID를 사용합니다.

예:

클라이언트가 동일한 AP에 연결된 경우 Association-Request 및 Association-Response 모두에서 동일한 PMKID를 볼 수 있습니다. 연결 응답에서 동일한 PMKID를 사용하는 경우 DH 세부사항을 볼 수 없습니다.

이미지-14: 동일한 PMKID 사용

이미지-15: 동일한 PMKID와의 연결 응답

테스트를 위해 WLC에서 이 클라이언트를 수동으로 삭제하고 동일한 AP에 다시 연결했습니다. 이때 클라이언트는 동일한 PMKID를 전송하지만 AP는 연결 응답으로 DH 세부 정보를 전송합니다.

이미지-16: 삭제 후 클라이언트가 DH 세부사항이 포함된 동일한 PMKID를 전송했습니다.

이미지-17: AP는 DH 값을 사용하여 새 PMKID를 생성합니다.

이 예에서는 다음을 수행합니다. AP와 클라이언트 모두 4-Way 핸드셰이크를 수행하는 동안 동일한 PMKID를 사용하며 "M1 및 M2" 메시지를 체크인합니다.

이미지- 18: 동일한 PMKID를 사용하는 AP 및 클라이언트

이 예에서는 다음을 수행합니다. 동일한 PMKID를 사용하지만 클라이언트가 삭제된 후 생성된 다른 PMKID를 사용하는 AP를 사용하는 클라이언트는 "M1 및 M2" 메시지를 확인합니다.

이미지-19: 다른 PMKID를 사용하는 AP 및 클라이언트

내부 RA 추적에서:

이 예에서는 다음을 수행합니다. 클라이언트가 연결 요청에서 DH 매개변수를 보냈고 AP가 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

그 후 동일한 클라이언트가 동일한 AP에 연결되었지만 AP에서 새 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