CUWN의 802.11 WLAN 로밍 및 빠른 보안 로밍

다운로드 옵션

PDF (2.9 MB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (2.4 MB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (2.7 MB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2018년 8월 29일 (수)

문서 ID:116493

번역에 관하여

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 Cisco CUWN(Unified Wireless Network)에서 지원되는 IEEE 802.11 WLAN(Wireless LAN)에 사용할 수 있는 다양한 유형의 무선 로밍 및 빠른 보안 로밍 방법에 대해 설명합니다.

이 문서에서는 각 방법의 작동 방식 또는 구성 방법에 대한 세부 사항을 모두 제공하지 않습니다.이 문서의 주요 목적은 사용 가능한 다양한 기술, 그 장점과 제한 사항 및 각 방법의 프레임 교환 간의 차이점을 설명하는 것입니다.WLC(WLAN Controller) 디버그의 예가 제공되며, 무선 패킷 캡처는 설명된 각 로밍 방법에 대해 발생하는 이벤트를 분석하고 설명하는 데 사용됩니다.

사전 요구 사항

요구 사항

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

IEEE 802.11 WLAN 기본 사항
IEEE 802.11 WLAN 보안
IEEE 802.1X/EAP 기본 사항

사용되는 구성 요소

이 문서의 정보는 Cisco WLAN Controller Software Version 7.4를 기반으로 하지만, 설명된 대부분의 디버그 출력 및 동작은 설명된 방법을 지원하는 모든 소프트웨어 버전에 적용될 수 있습니다.여기에 설명된 모든 방법에 대한 세부 사항은 나중에 Cisco WLAN Controller 코드(이 문서가 업데이트될 때까지 최대 버전 8.3)에서 동일합니다.

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

배경 정보

WLAN에 사용할 수 있는 다양한 고속 보안 로밍 방법에 대한 설명을 제공하기 전에 WLAN 연결 프로세스의 작동 방식 및 SSID(Service Set Identifier)에 구성된 보안이 없을 때 일반 로밍 이벤트가 발생하는 방법을 이해하는 것이 중요합니다.

802.11 무선 클라이언트가 액세스 포인트(AP)에 연결할 때 트래픽(무선 데이터 프레임)을 전달하기 전에 먼저 기본 802.11 개방형 시스템 인증 프로세스를 통과해야 합니다.그런 다음 연결 프로세스를 완료해야 합니다.Open System 인증 프로세스를 클라이언트가 선택한 AP에서 "케이블 연결"으로 간주합니다.이는 항상 선호하는 AP를 선택하는 무선 클라이언트이며 공급업체마다 다른 여러 요소에 따라 결정을 내리기 때문에 이해하기 매우 중요합니다.이 문서의 뒷부분에 나와 있는 것처럼 클라이언트가 선택한 AP에 인증 프레임을 전송하여 이 프로세스를 시작하는 이유입니다.AP에서 연결을 설정하도록 요청할 수 없습니다.

오픈 시스템 인증 프로세스가 AP의 응답과 함께 성공적으로 완료되면("케이블 연결") 연결 프로세스는 기본적으로 클라이언트와 AP 간의 링크를 설정하는 802.11 Layer 2(L2) 협상을 완료합니다.연결에 성공하면 AP는 클라이언트에 연결 ID를 할당하고, 트래픽을 전달하거나 SSID에 구성된 경우 고급 보안 방법을 수행하기 위해 준비합니다.오픈 시스템 인증 프로세스는 연결 프로세스뿐 아니라 두 개의 관리 프레임으로 구성됩니다.인증 및 연결 프레임은 데이터 프레임이 아닌 무선 관리 프레임이며, 기본적으로 AP와의 연결 프로세스에 사용되는 프레임입니다.

다음은 이 프로세스를 위한 무선 프레임의 캡처입니다.

참고: 802.11 무선 스니핑 및 Wireshark에서 이 문서에 표시된 캡처를 위해 사용하는 필터/색상에 대해 알아보려면 Cisco Support Community 게시물(802.11 Sniffer Capture Analysis)을 방문하십시오.

무선 클라이언트는 인증 프레임으로 시작하고 AP가 다른 인증 프레임으로 응답합니다.그러면 클라이언트가 연결 요청 프레임을 전송하고 AP가 연결 응답 프레임과 함께 응답으로 끝납니다.DHCP 패킷에서 볼 수 있듯이 802.11 오픈 시스템 인증 및 연결 프로세스가 전달되면 클라이언트는 데이터 프레임을 전달하기 시작합니다.이 경우 SSID에 구성된 보안 방법이 없으므로 클라이언트가 즉시 암호화되지 않은 데이터 프레임(이 경우 DHCP)을 전송하기 시작합니다.

이 문서의 뒷부분에서 볼 수 있듯이, SSID에서 보안이 활성화된 경우 연결 응답 바로 후와 암호화된 DHCP, ARP(Address Resolution Protocol) 및 애플리케이션 패킷과 같은 클라이언트 트래픽 데이터 프레임을 전송하기 전에 특정 보안 방법에 대한 상위 레벨 인증 및 암호화 핸드셰이크 프레임이 있습니다.클라이언트가 완전히 인증되고 구성된 보안 방법에 따라 암호화 키가 협상될 때까지 데이터 프레임을 전송할 수 있습니다.

이전 캡처를 기반으로, 무선 클라이언트가 WLAN에 대한 새 연결을 시작할 때 WLC debug client 명령의 출력에 표시되는 메시지는 다음과 같습니다.

*apfMsConnTask_0: Jun 21 18:55:14.221: 00:40:96:b7:ab:5c
  Association received from mobile on BSSID 84:78:ac:f0:68:d0
!--- This is the Association Request from the wireless client
     to the selected AP.

*apfMsConnTask_0: Jun 21 18:55:14.222: 00:40:96:b7:ab:5c
  Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d0
  (status 0) ApVapId 1 Slot 0
!--- This is the Association Response from the AP to the client.

참고: 이 문서에 표시된 출력에 사용되는 WLC 디버그는 debug client 명령이며, 예제는 전체 출력이 아닌 일부 관련 메시지만 표시합니다.이 debug 명령에 대한 자세한 내용은 WLC(Wireless LAN Controller)의 디버그 클라이언트 이해 문서를 참조하십시오.

이러한 메시지는 연결 요청 및 응답 프레임을 보여 줍니다.이 핸드셰이크는 CUWN의 AP 레벨에서 신속하게 수행되므로 초기 인증 프레임이 WLC에 로깅되지 않습니다.

클라이언트가 로밍할 때 표시되는 정보는 무엇입니까?클라이언트는 AP에 대한 연결이 설정될 때 항상 4개의 관리 프레임을 교환합니다. 이는 클라이언트 연결 설정 또는 로밍 이벤트 때문입니다.클라이언트는 한 번에 하나의 AP에만 하나의 연결만 설정했습니다.WLAN 인프라에 대한 새 연결과 로밍 이벤트 간의 프레임 교환의 유일한 차이점은 로밍 이벤트의 연결 프레임을 재연결 프레임이라고 하는데, 이는 클라이언트가 WLAN에 대한 새 연결을 설정하려고 시도하지 않고 실제로 다른 AP에서 로밍되고 있음을 나타냅니다.이러한 프레임에는 로밍 이벤트를 협상하기 위해 사용되는 여러 요소가 포함될 수 있습니다.이는 설정에 따라 다르지만 이러한 세부 정보는 이 문서의 범위를 벗어납니다.

다음은 프레임 교환의 예입니다.

이러한 메시지는 디버그 출력에 표시됩니다.

*apfMsConnTask_2: Jun 21 19:02:19.709: 00:40:96:b7:ab:5c
  Reassociation received from mobile on BSSID 84:78:ac:f0:2a:90
!--- This is the Reassociation Request from the wireless client
     to the selected AP.

*apfMsConnTask_2: Jun 21 19:02:19.710: 00:40:96:b7:ab:5c
  Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:90
  (status 0) ApVapId 1 Slot 0
!--- This is the Reassociation Response from the AP to the client.

표시된 대로 클라이언트는 새 AP에 재연결 요청을 전송한 후 로밍 이벤트를 성공적으로 수행하고 AP에서 재연결 응답을 수신합니다.클라이언트에 이미 IP 주소가 있으므로 첫 번째 데이터 프레임은 ARP 패킷에 대한 것입니다.

로밍 이벤트가 예상되지만 클라이언트가 재연결 요청 대신 연결 요청을 보내는 경우(이 문서에서 앞서 설명한 것과 유사한 일부 캡처 및 디버깅에서 확인할 수 있음) 클라이언트가 실제로 로밍되지 않습니다.클라이언트는 연결이 끊긴 것처럼 WLAN에 대한 새 연결을 시작하고 처음부터 다시 연결을 시도합니다.이는 클라이언트가 커버리지 영역을 벗어난 후 연결을 시작할 수 있는 신호 품질이 충분한 AP를 찾은 경우처럼 여러 가지 이유로 발생할 수 있지만, 일반적으로 클라이언트가 드라이버, 펌웨어 또는 소프트웨어 문제로 인해 로밍 이벤트를 시작하지 않는 클라이언트 문제를 나타냅니다.

참고:무선 클라이언트 공급업체에 문의하여 문제의 원인을 확인할 수 있습니다.

고급 보안으로 로밍

기본 802.11 Open System 인증 외에 L2 상위 레벨 보안을 사용하여 SSID를 구성할 경우 초기 연결 및 로밍 시 더 많은 프레임이 필요합니다.802.11 WLAN에 대해 표준화되고 구현된 가장 일반적인 두 가지 보안 방법은 이 문서에서 설명합니다.

WPA/WPA2-PSK(사전 공유 키) - 사전 공유 키를 사용하여 클라이언트를 인증합니다.
WPA/WPA2-EAP(Extensible Authentication Protocol) - 인증서, 사용자 이름 및 비밀번호, 토큰 등의 인증 서버를 사용하여 더 안전한 자격 증명을 검증하기 위해 802.1X/EAP 방법을 사용하는 클라이언트의 인증

이 두 가지 방법(PSK 및 EAP)이 서로 다른 방식으로 클라이언트를 인증/검증하지만 두 방법 모두 기본적으로 키 관리 프로세스에 동일한 WPA/WPA2 규칙을 사용합니다.보안이 WPA/WPA2-PSK 또는 WPA/WPA2-EAP인지 여부, WPA/WPA2 4-Way 핸드셰이크라고 알려진 프로세스는 클라이언트가 사용된 특정 인증 방법으로 검증되면 WLC/AP와 마스터 세션 키(MSK)를 사용하여 클라이언트 간의 키 협상을 시작합니다.

프로세스 요약은 다음과 같습니다.

MSK는 802.1X/EAP 보안이 사용되는 경우 EAP 인증 단계에서 파생되거나 WPA/WPA2-PSK가 보안 방법으로 사용되는 경우 PSK에서 파생됩니다.
이 MSK에서 클라이언트와 WLC/AP는 PMK(Pairwise Master Key)를 파생하며 WLC/AP는 GMK(Group Master Key)를 생성합니다.
이러한 두 마스터 키가 준비되면 클라이언트와 WLC/AP는 마스터 키를 사용하여 실제 암호화 키 협상을 위한 시드로 마스터 키와 함께 WPA/WPA2 4방향 핸드셰이크(이 문서의 뒷부분에 일부 화면 캡처 및 디버그를 사용하여 표시됨)를 시작합니다.
이러한 최종 암호화 키는 PTK(Pairwise Transient Key) 및 GTK(Group Transient Key)라고 합니다. PTK는 PMK에서 파생되며 클라이언트와 유니캐스트 프레임을 암호화하는 데 사용됩니다.GTK(Group Transient Key)는 GMK에서 파생되며 이 특정 SSID/AP에서 멀티캐스트/브로드캐스트를 암호화하는 데 사용됩니다.

WPA/WPA2-PSK

암호화를 위해 WPA-PSK 또는 WPA2-PSK가 TKIP(Temporal Key Integrity Protocol) 또는 AES(Advanced Encryption Standard)를 통해 수행되는 경우 클라이언트는 초기 연결 및 로밍 시 모두 WPA 4-Way 핸드셰이크라는 프로세스를 거쳐야 합니다.앞서 설명한 것처럼, 이는 기본적으로 WPA/WPA2에서 암호화 키를 파생하기 위해 사용하는 키 관리 프로세스입니다.그러나 PSK를 수행할 때 클라이언트가 WLAN에 가입하는 데 유효한 사전 공유 키를 가지고 있는지 확인하기 위해 PSK를 사용합니다.이 캡처는 PSK를 사용하는 WPA 또는 WPA2를 수행할 때 초기 연결 프로세스를 보여 줍니다.

표시된 대로 802.11 오픈 시스템 인증 및 연결 프로세스 후에는 WPA 4-Way 핸드셰이크의 EAPOL 프레임 4개가 있습니다. AP에서 message-1을 사용하여 시작하며 클라이언트가 message-4를 사용하여 끝납니다. 성공적인 핸드셰이크 후 클라이언트는 데이터 프레임(예: DHCP)을 통과하기 시작합니다. 이 경우 4-Way 핸드셰이크에서 파생된 키로 암호화됩니다(실제 콘텐츠를 볼 수 없음) 및 무선 캡처의 트래픽 유형)

참고:EAPOL 프레임은 AP와 클라이언트 간에 모든 키 관리 프레임 및 802.1X/EAP 인증 프레임을 공중으로 전송하는 데 사용됩니다.무선 데이터 프레임으로 전송됩니다.

이러한 메시지는 디버그 출력에 표시됩니다.

*apfMsConnTask_0: Jun 21 19:30:05.172: 00:40:96:b7:ab:5c
  Association received from mobile on BSSID 84:78:ac:f0:68:d1
*apfMsConnTask_0: Jun 21 19:30:05.173: 00:40:96:b7:ab:5c
  Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d1
  (status 0) ApVapId 2 Slot 0
!--- The Association handshake is finished.

*dot1xMsgTask: Jun 21 19:30:05.178: 00:40:96:b7:ab:5c
  Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
  state INITPMK (message 1), replay counter
  00.00.00.00.00.00.00.00
!--- Message-1 of the WPA/WPA2 4-Way handshake is sent
     from the WLC/AP to the client.

*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.289: 00:40:96:b7:ab:5c
  Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.289: 00:40:96:b7:ab:5c
  Received EAPOL-key in PTK_START state (message 2)
  from mobile 00:40:96:b7:ab:5c
!--- Message-2 of the WPA/WPA2 4-Way handshake is successfully
     received from the client.

*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.290: 00:40:96:b7:ab:5c
  Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
  state PTKINITNEGOTIATING (message 3), replay counter
  00.00.00.00.00.00.00.01
!--- Message-3 of the WPA/WPA2 4-Way handshake is sent
     from the WLC/AP to the client.

*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.309: 00:40:96:b7:ab:5c
  Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.310: 00:40:96:b7:ab:5c
  Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
  from mobile 00:40:96:b7:ab:5c
!--- Message-4 (final message) of the WPA/WPA2 4-Way handshake
     is successfully received from the client, which confirms
     the installation of the derived keys. They can now be used in
     order to encrypt data frames with current AP.

로밍 시 클라이언트는 기본적으로 동일한 프레임 교환을 따릅니다. 여기서 새 AP를 사용하여 새 암호화 키를 파생하려면 WPA 4-Way 핸드셰이크가 필요합니다.이는 표준에서 설정한 보안 이유와 새 AP가 원래 키를 알지 못하기 때문입니다.유일한 차이점은 이 캡처와 같이 연결 프레임 대신 재연결 프레임이 있다는 것입니다.

디버그 출력에서는 동일한 메시지를 볼 수 있지만, 앞에서 설명한 것처럼 클라이언트의 첫 번째 패킷은 연결 대신 재연결입니다.

WPA/WPA2-EAP

802.1X/EAP 방법을 사용하여 보안 SSID에서 클라이언트를 인증하는 경우 클라이언트가 트래픽을 전달하기 전에 훨씬 더 많은 프레임이 필요합니다.이러한 추가 프레임은 클라이언트 자격 증명을 인증하는 데 사용되며 EAP 방법에 따라 4개에서 20개 사이의 프레임이 있을 수 있습니다.인증 단계는 키 관리 프로세스(4방향 핸드셰이크)에서 최종 암호화 키 생성을 위한 초기값으로 사용되는 MSK를 파생하므로, 이러한 정보는 연결/재연결 이후에 WPA/WPA2 4-Way 핸드셰이크 전에 발생합니다.

이 무선 캡처는 PEAPv0/EAP-MSCHAPv2를 사용하는 WPA를 수행할 때 AP와 무선 클라이언트 간에 AP와 무선 클라이언트 간에 통신을 통해 교환되는 프레임의 예를 보여줍니다.

경우에 따라 이 교환은 EAP 방법, 문제로 인한 재전송, 클라이언트 동작(예: 클라이언트가 AP가 첫 번째 ID 요청을 보낸 후 EAPOL START를 보내기 때문)과 같은 여러 요소에 따라 또는 그 이하의 프레임을 표시하거나 클라이언트가 이미 서버와 인증서를 교환한 경우.802.1X/EAP 방법에 대해 SSID를 구성할 때마다 더 많은 프레임(인증용)이 있기 때문에 클라이언트가 데이터 프레임을 보내기 전에 더 많은 시간이 필요합니다.

디버그 메시지에 대한 요약은 다음과 같습니다.

*apfMsConnTask_0: Jun 21 23:41:19.092: 00:40:96:b7:ab:5c
  Association received from mobile on BSSID 84:78:ac:f0:68:d8
*apfMsConnTask_0: Jun 21 23:41:19.094: 00:40:96:b7:ab:5c
  Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d8
  (status 0) ApVapId 9 Slot 0
!--- The Association handshake is finished.

*dot1xMsgTask: Jun 21 23:41:19.098: 00:40:96:b7:ab:5c
  Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
  (EAP Id 1)
!--- The EAP Identity Request is sent to the client once it is
     associated in order to begin the higher-level authentication
     process. This informs the client that an identity to start
     this type of 802.1X/EAP authentication must be provided.

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.226: 00:40:96:b7:ab:5c
  Received EAPOL START from mobile 00:40:96:b7:ab:5c
!--- The wireless client decides to start the EAP authentication
     process, and informs the AP with an EAPOL START data frame.

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.227: 00:40:96:b7:ab:5c
  Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
  (EAP Id 2)
!--- WLC/AP sends another EAP Identity Request to the client.

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.235: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.235: 00:40:96:b7:ab:5c
  Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c
!--- The client responds with an EAP Identity Response on an EAPOL
     frame.

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.301: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.301: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 3)
!--- Once the WLC/AP sends the client response to the Authentication
     Server on a RADIUS Access-Request packet, the server responds
     with a RADIUS Access-Challenge in order to officially start the
     EAP negotiation, handshake, and authentication with the client
     (sometimes with mutual authentication, dependent upon the EAP
     method). This response received by the WLC/AP is sent to the client.

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.344: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.344: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 3, EAP Type 25)
!--- The client responds with an EAP Response on an EAPOL frame, which
     is sent to the Authentication Server on a RADIUS Access-Request
     packet. The server responds with another RADIUS Access-Challenge.
     This process continues, dependent upon the EAP method (the exchange
     of certificates when used, the building of TLS tunnels, validation
     of client credentials, client validation of server identity when
     applicable). Hence, the next few messages are basically the same on
     the WLC/AP side, as this acts as a "proxy" between the client and
     the Authentication Server exchanges.

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.347: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.347: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 4)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.375: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.375: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 4, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.377: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.377: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 5)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.403: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.403: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 5, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.404: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.404: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 6)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.414: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.414: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 6, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.421: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.421: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 7)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.425: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.425: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 7, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.427: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.427: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 8)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.434: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.434: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 8, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.436: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.436: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 9)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.440: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.440: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 9, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.442: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.442: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 10)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.449: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.449: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 10, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.452: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.452: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 11)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.457: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.457: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 11, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.459: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.459: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 13)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.469: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.469: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 13, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.472: 00:40:96:b7:ab:5c
  Processing Access-Accept for mobile 00:40:96:b7:ab:5c
!--- The authentication finishes and is successful for this client,
     so the RADIUS Server sends a RADIUS Access-Accept to the WLC/AP.
     This RADIUS Access-Accept comes with the special attributes
     that are assigned to this client (if any are configured on the
     Authentication Server for this client). This Access-Accept also
     comes with the MSK derived with the client in the EAP
     authentication process, so the WLC/AP installs it in order to
     initiate the WPA/WPA2 4-Way handshake with the wireless client.

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.473: 00:40:96:b7:ab:5c
  Sending EAP-Success to mobile 00:40:96:b7:ab:5c
  (EAP Id 13)
!--- The accept/pass of the authentication is sent to the client as
     an EAP-Success message.

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.473: 00:40:96:b7:ab:5c
  Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
  state INITPMK (message 1), replay counter
  00.00.00.00.00.00.00.00
!--- Message-1 of the WPA/WPA2 4-Way handshake is sent from the
     WLC/AP to the client.

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c
  Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c
  Received EAPOL-key in PTK_START state (message 2)
  from mobile 00:40:96:b7:ab:5c
!--- Message-2 of the WPA/WPA-2 4-Way handshake is successfully
     received from the client.

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c
  Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
  state PTKINITNEGOTIATING (message 3), replay counter
  00.00.00.00.00.00.00.01
!--- Message-3 of the WPA/WPA2 4-Way handshake is sent from the
     WLC/AP to the client.

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.487: 00:40:96:b7:ab:5c
  Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.487: 00:40:96:b7:ab:5c
  Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
  from mobile 00:40:96:b7:ab:5c
!--- Message-4 (final message) of the WPA/WPA2 4-Way handshake
     is successfully received from the client, which confirms the
     installation of the derived keys. They can now be used in
     order to encrypt data frames with the current AP.

무선 클라이언트가 여기에서 일반 로밍(빠른 보안 로밍 방법을 구현하지 않고 정상적인 동작)을 수행할 경우 클라이언트는 동일한 프로세스를 거치고 캡처와 같이 인증 서버에 대해 전체 인증을 수행해야 합니다.유일한 차이점은 클라이언트가 다른 AP에서 실제로 로밍되고 있음을 새 AP에 알리기 위해 재연결 요청을 사용하지만 클라이언트는 완전한 검증 및 새로운 키 생성을 거쳐야 한다는 것입니다.

표시된 것처럼 초기 인증보다 프레임 수가 적더라도(앞에서 언급한 대로 여러 요인으로 인해 발생) 클라이언트가 새 AP로 로밍할 때 데이터 프레임을 계속 전달하려면(로밍 전에 트래픽이 적극적으로 전송된 경우에도) EAP 인증 및 WPA 키 관리 프로세스를 계속 완료해야 합니다. 따라서 클라이언트에 지연에 민감한 활성 애플리케이션(예: 음성 트래픽 애플리케이션 또는 시간 초과에 민감한 애플리케이션)이 있는 경우 사용자는 오디오 간격이나 애플리케이션 연결 끊김 등의 로밍 시 문제를 인식할 수 있습니다.이는 클라이언트가 데이터 프레임을 계속 전송/수신하기 위해 프로세스가 얼마나 소요되는지에 따라 달라집니다.이 지연은 다음에 따라 더 길어질 수 있습니다.RF 환경, 클라이언트 양, WLC와 LAP 간의 왕복 시간, 인증 서버와의 왕복 시간 및 기타 이유.

다음은 이 로밍 이벤트에 대한 디버그 메시지의 요약입니다(기본적으로 이전 메시지와 동일하므로 이러한 메시지는 더 이상 설명하지 않음).

*apfMsConnTask_2: Jun 21 23:47:54.872: 00:40:96:b7:ab:5c
  Reassociation received from mobile on BSSID 84:78:ac:f0:2a:98

*apfMsConnTask_2: Jun 21 23:47:54.874: 00:40:96:b7:ab:5c
  Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:98
  (status 0) ApVapId 9 Slot 0

*dot1xMsgTask: Jun 21 23:47:54.879: 00:40:96:b7:ab:5c
  Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
  (EAP Id 1)

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
  Received EAPOL START from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
  dot1x - moving mobile 00:40:96:b7:ab:5c into Connecting state

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
  Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
  (EAP Id 2)

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c
  Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 3)

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 3, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 4)

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 4, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.956: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.957: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 7)

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 7, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
  Processing Access-Accept for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
  Sending EAP-Success to mobile 00:40:96:b7:ab:5c
  (EAP Id 7)

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
  Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
  state INITPMK (message 1), replay counter
  00.00.00.00.00.00.00.00

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
  Received EAPOL-Key from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
  Received EAPOL-key in PTK_START state (message 2)
  from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
  Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
  state PTKINITNEGOTIATING (message 3), replay counter
  00.00.00.00.00.00.00.01

*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c
  Received EAPOL-Key from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c
  Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
  from mobile 00:40:96:b7:ab:5c

이는 802.1X/EAP와 WPA/WPA2 보안 프레임워크가 작동하는 방식입니다.정기적인 로밍 이벤트의 지연에 대한 애플리케이션/서비스가 영향을 받지 않도록 WLAN/SSID에서 보안을 사용할 때 로밍 프로세스를 가속화하기 위해 WiFi 업계에서 여러 개의 고속 보안 로밍 방법을 개발하고 구현합니다.클라이언트는 WLAN에 높은 수준의 보안을 구축함으로써 AP 간에 로밍하는 동안 트래픽을 계속 전달할 때 약간의 레이턴시가 발생합니다.이는 앞서 설명한 대로 보안 설정에 필요한 EAP 인증 및 키 관리 프레임 교환 때문입니다.

빠른 보안 로밍은 WLAN에 보안을 구성할 때 로밍 프로세스를 가속화하는 방법/체계 구현과 관련하여 업계에서 사용하는 용어임을 이해하는 것이 중요합니다. WLAN에 사용할 수 있고 CUWN에서 지원하는 다양한 고속 보안 로밍 방법/체계에 대해 다음 섹션에서 설명합니다.

CCKM을 통한 빠른 보안 로밍

Cisco CCKM(Centralized Key Management)은 802.1X/EAP 보안이 WLAN에서 사용될 때 지금까지 설명한 지연을 완화하기 위해 사용된 솔루션으로 Cisco에서 생성한 엔터프라이즈 WLAN에 개발 및 구현된 최초의 고속 보안 로밍 방법입니다.이는 Cisco 전용 프로토콜이므로 CCKM용 Cisco CCX(Compatible Extension)와 호환되는 Cisco WLAN 인프라 디바이스 및 무선 클라이언트(여러 공급업체의 클라이언트)에서만 지원됩니다.

CCKM은 다음과 같이 WLAN에 사용할 수 있는 다양한 암호화 방법과 함께 구현할 수 있습니다.WEP, TKIP 및 AES.WLAN에 사용되는 대부분의 802.1X/EAP 인증 방법에서도 지원되며, 이는 디바이스에서 지원하는 CCX 버전에 따라 다릅니다.

참고:CCX 사양의 다른 버전에서 지원되는 기능 내용(지원되는 EAP 방법 포함)에 대한 개요는 CCX 버전 및 기능 문서를 참조하고 무선 클라이언트가 지원하는 정확한 CCX 버전(CCX와 호환되는 경우)을 확인하여 CCKM에서 사용하려는 보안 방법을 구현할 수 있는지 확인할 수 있습니다.

이 무선 캡처는 암호화로 TKIP를 사용하여 CCKM을 수행할 때 초기 연결 시 교환되는 프레임 및 802.1X/EAP 방법으로 PEAPv0/EAP-MSCHAPv2를 수행할 때 교환되는 프레임의 예를 제공합니다.이것은 기본적으로 PEAPv0/EAP-MSCHAPv2를 사용하는 WPA/TKIP가 수행되는 것과 동일한 교환이지만, 이번에는 클라이언트와 인프라 간의 CCKM이 협상되어 클라이언트가 로밍해야 하는 경우 빠른 보안 로밍을 수행하기 위해 서로 다른 키 계층 구조와 캐시 방법을 사용하도록 합니다.

디버그 메시지의 요약입니다(출력을 줄이기 위해 일부 EAP 교환이 제거됨).

*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
  Association received from mobile on BSSID 84:78:ac:f0:68:d3
!--- This is the Association Request from the client.

*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
  Processing WPA IE type 221, length 22 for mobile
  00:40:96:b7:ab:5c
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
  CCKM: Mobile is using CCKM
!--- The WLC/AP finds an Information Element that claims CCKM
      support on the Association request that is sent from the client.

*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
  Setting active key cache index 8 ---> 8
!--- This is the key cache index for this client, which is set temporally.

*apfMsConnTask_0: Jun 25 15:41:41.508: 00:40:96:b7:ab:5c
  Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d3
  (status 0) ApVapId 4 Slot 0
!--- The Association Response is sent to the client.

*dot1xMsgTask: Jun 25 15:41:41.513: 00:40:96:b7:ab:5c
  Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
  (EAP Id 1)
!--- An EAP Identity Request is sent to the client once it is
     associated in order to begin the higher-level authentication
     process. This informs the client that an identity to start
     this type of 802.1X/EAP authentication must be provided.
     Further EAP messages are not described, as they are basically
     the same as the ones previously-explained.

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.536: 00:40:96:b7:ab:5c
  Received EAPOL START from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.536: 00:40:96:b7:ab:5c
  Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
  (EAP Id 2)

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.546: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.546: 00:40:96:b7:ab:5c
  Received EAP Response packet with mismatching id 
  (currentid=2, eapid=1) from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.550: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.550: 00:40:96:b7:ab:5c
  Received Identity Response (count=2) from mobile
  00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.555: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.555: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 3)

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.594: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.594: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 3, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.840: 00:40:96:b7:ab:5c
  Processing Access-Accept for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
  Creating a PKC PMKID Cache entry for station 00:40:96:b7:ab:5c
  (RSN 0)<br/ >
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
  Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
  Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
  CCKM: Create a global PMK cache entry
!--- WLC creates a global PMK cache entry for this client,
     which is for CCKM in this case.

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
  Sending EAP-Success to mobile 00:40:96:b7:ab:5c
  (EAP Id 13)
!--- The client is informed of the successful EAP authentication.

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
  Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
  INITPMK(message 1),replay counter 00.00.00.00.00.00.00.00
!--- Message-1 of the initial 4-Way handshake is sent from the
     WLC/AP to the client.

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
  Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
  Received EAPOL-key in PTK_START state (message 2) from mobile
  00:40:96:b7:ab:5c
!--- Message-2 of the initial 4-Way handshake is received
     successfully from the client.

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
  CCKM: Sending cache add
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: CCKM: Sending CCKM PMK
  (Version_1) information to mobility group
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: CCKM: Sending CCKM PMK
  (Version_2) information to mobility group
!--- The CCKM PMK cache entry for this client is shared with
     the WLCs on the mobility group.

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
  Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
  state PTKINITNEGOTIATING (message 3), replay counter
  00.00.00.00.00.00.00.01
!--- Message-3 of the initial 4-Way handshake is sent from the
     WLC/AP to the client.

*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.866: 00:40:96:b7:ab:5c
  Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.866: 00:40:96:b7:ab:5c Received
  EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile
  00:40:96:b7:ab:5c
!--- Message-4 (final message) of this initial 4-Way handshake
     is received successfully from the client, which confirms the
     installation of the derived keys. They can now be used in order
     to encrypt data frames with the current AP.

CCKM에서 WLAN에 대한 초기 연결은 일반 WPA/WPA2와 비슷하며, 여기서 MSK(Network Session Key(NSK)라고도 함)는 클라이언트 및 RADIUS 서버와 함께 파생됩니다.이 마스터 키는 성공적인 인증 후 서버에서 WLC로 전송되며 이 WLAN과의 클라이언트 연결 수명 동안 모든 후속 키를 파생하기 위한 기반으로 캐시됩니다.여기에서 WLC와 클라이언트는 첫 번째 AP를 사용하여 유니캐스트(PTK) 및 GTK(멀티캐스트/브로드캐스트) 암호화 키를 파생시키기 위해 CCKM을 기반으로 빠른 보안 로밍에 사용되는 시드 정보를 얻습니다.

로밍할 때 큰 차이가 감지됩니다.이 경우 CCKM 클라이언트는 AP/WLC에 단일 재연결 요청 프레임을 전송하며(MIC 및 순차적으로 증가하는 난수 포함), 새 PTK를 파생하기 위해 충분한 정보(새 AP MAC 주소 -BSSID-포함)를 제공합니다.이 재연결 요청을 통해 WLC와 새 AP는 새 PTK를 도출할 수 있는 충분한 정보를 확보하여 재연결 응답으로 응답합니다.이제 클라이언트는 이 캡처와 같이 트래픽을 계속 전달할 수 있습니다.

이 로밍 이벤트에 대한 WLC 디버그의 요약은 다음과 같습니다.

*apfMsConnTask_2: Jun 25 15:43:33.749: 00:40:96:b7:ab:5c
  CCKM: Received REASSOC REQ IE
*apfMsConnTask_2: Jun 25 15:43:33.749: 00:40:96:b7:ab:5c
  Reassociation received from mobile on BSSID
  84:78:ac:f0:2a:93
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
  Processing WPA IE type 221, length 22 for mobile
  00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
  CCKM: Mobile is using CCKM
!--- The Reassociation Request is received from the client,
     which provides the CCKM information needed in order to
     derive the new keys with a fast-secure roam.

*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
  Setting active key cache index 0 ---> 8

*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
  CCKM: Processing REASSOC REQ IE

*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
  CCKM: using HMAC MD5 to compute MIC
!--- WLC computes the MIC used for this CCKM fast-roaming
     exchange.

*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
  CCKM: Received a valid REASSOC REQ IE

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
  CCKM: Initializing PMK cache entry with a new PTK
!--- The new PTK is derived.

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
  Setting active key cache index 8 ---> 8

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
  Setting active key cache index 8 ---> 8

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
  Setting active key cache index 8 ---> 0

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
  Creating a PKC PMKID Cache entry for station
  00:40:96:b7:ab:5c (RSN 0) on BSSID 84:78:ac:f0:2a:93
!--- The new PMKID cache entry is created for this new
     AP-to-client association.

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
  CCKM: using HMAC MD5 to compute MIC
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
  Including CCKM Response IE (length 62) in Assoc Resp to mobile
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
  Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:93
  (status 0) ApVapId 4 Slot 0
!--- The Reassociation Response is sent from the WLC/AP to
     the client, which includes the CCKM information required
     in order to confirm the new fast-roam and key derivation.

*dot1xMsgTask: Jun 25 15:43:33.757: 00:40:96:b7:ab:5c
  Skipping EAP-Success to mobile 00:40:96:b7:ab:5c
!--- EAP is skipped due to the fast roaming, and CCKM does not
     require further key handshakes. The client is now ready to
     pass encrypted data frames on the new AP.

표시된 것처럼, EAP 인증 프레임 및 4방향 핸드쉐이크를 피하면서 빠른 보안 로밍이 수행됩니다. 새 암호화 키는 아직 파생되지만 CCKM 협상 체계에 따라 다릅니다.이 작업은 로밍 재연결 프레임과 클라이언트 및 WLC에 의해 이전에 캐시된 정보로 완료됩니다.

CCKM을 사용한 FlexConnect

중앙 인증이 지원됩니다.여기에는 로컬 및 중앙 데이터 스위칭이 포함됩니다.AP는 동일한 FlexConnect 그룹에 속해야 합니다.
Flex Local Authentication이 지원됩니다.연결된 모드에서는 캐시가 AP에서 컨트롤러로 분배된 다음 FlexConnect 그룹의 나머지 AP로 분배됩니다.
독립형 모드가 지원됩니다.이전 배포 때문에 AP에 캐시가 이미 있는 경우 빠른 로밍이 작동합니다.독립형 모드의 새 인증은 빠른 보안 로밍을 지원하지 않습니다.

CCKM의 장점

CCKM은 대부분 엔터프라이즈 WLAN에 구축된 가장 빠른 보안 로밍 방법입니다. AP 간에 이동할 때 새 키를 파생하기 위해 클라이언트가 키 관리 핸드셰이크를 통과할 필요가 없으며 이 WLAN에서 클라이언트 수명 동안 새 AP를 사용하여 전체 802.1X/EAP 인증을 다시 수행할 필요가 없습니다.
CCKM은 802.11 표준(WEP, TKIP 및 AES) 내에서 사용 가능한 모든 암호화 방법 및 기존 클라이언트에 여전히 사용되는 일부 기존 Cisco 소유 방법을 지원합니다.

CCKM과의 단점

CCKM은 Cisco의 독점적 방법으로, Cisco WLAN 인프라 및 CCX 무선 클라이언트로 구현 및 지원을 제한합니다.
CCX 버전 5는 널리 채택되지 않으므로 WPA2/AES를 사용하는 CCKM은 많은 CCX 무선 클라이언트에서 지원되지 않습니다(주로 대부분의 CCKM에서 여전히 매우 안전한 WPA/TKIP를 이미 지원하므로).

PMKID 캐싱/고정 키 캐싱을 사용한 빠른 보안 로밍

PMKID(Pairwise Master Key ID) 캐싱 또는 SKC(Sticky Key Caching)은 802.11i 보안 수정 수정 내에서 IEEE 802.11 표준에서 제안하는 첫 번째 빠른 보안 로밍 방법입니다. 이 방법은 WLAN에 대한 높은 수준의 보안을 표준화하는 것입니다.이 보안 구현 시 로밍을 개선하기 위해 WPA2 장치의 선택적 방법으로 이 빠른 보안 로밍 기술을 추가했습니다.

클라이언트가 완전히 EAP로 인증될 때마다 클라이언트 및 인증 서버는 PMK를 파생시키는 데 사용되는 MSK를 파생하기 때문에 이 작업이 가능합니다.클라이언트가 다른 AP로 로밍하거나 세션이 만료될 때까지 세션에 사용되는 최종 PTK(유니캐스트 암호화 키)를 파생하기 위해 WPA2 4방향 핸드셰이크의 시드로 사용됩니다.따라서 이 방법은 클라이언트 및 AP에 의해 캐시된 원래 PMK를 다시 사용하므로 로밍 시 EAP 인증 단계를 방지합니다.클라이언트는 새 암호화 키를 파생시키기 위해 WPA2 4-Way 핸드셰이크를 통과해야 합니다.

이 방법은 주로 다음과 같은 이유로 인해 권장되는 802.11 표준 고속 보안 로밍 방법으로 널리 구축되지 않습니다.

802.11i 수정안의 목적은 빠른 보안 로밍과 무관하며, IEEE는 이미 WLAN에 대해 빠른 보안 로밍을 표준화하기 위해 다른 수정(이 문서의 뒷부분에 나와 있는 802.11r)을 준비하고 있으므로 이 방법은 선택 사항이며 모든 WPA2 장치에서 지원되지 않습니다.
이 방법은 구현에 큰 제한이 있습니다.무선 클라이언트는 이전에 인증/연결한 AP로 다시 로밍 시 빠른 보안 로밍만 수행할 수 있습니다.

이 방법을 사용하면 모든 AP에 대한 초기 연결은 WLAN에 대한 일반적인 최초 인증과 유사합니다. 인증 서버에 대한 전체 802.1X/EAP 인증 및 키 생성을 위한 4방향 핸드셰이크가 클라이언트 데이터 프레임을 전송하기 전에 발생해야 합니다. 이 화면 캡처는 다음과 같습니다.

디버그는 WLAN에 대한 초기 인증 시 나머지 방법과 동일한 EAP 인증 프레임 교환을 표시하는데, 여기에 사용된 키 캐싱 기술과 관련하여 일부 출력이 추가됩니다.이러한 디버그 출력은 전체 EAP 프레임 교환이 아니라 주로 새로운 정보를 표시하기 위해 잘립니다. 기본적으로 인증 서버에 대한 클라이언트 인증을 위해 매번 동일한 정보가 교환되기 때문입니다.지금까지 이 데모에서는 패킷 캡처에 표시된 EAP 인증 프레임과 상관관계가 있으므로, 간소화를 위해 대부분의 EAP 메시지가 디버그 출력에서 제거됩니다.

*apfMsConnTask_0: Jun 22 00:23:15.097: ec:85:2f:15:39:32
  Association received from mobile on BSSID 84:78:ac:f0:68:d2
!--- This is the Association Request from the client.

*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32
  Processing RSN IE type 48, length 20 for mobile ec:85:2f:15:39:32
!--- The WLC/AP finds an Information Element that claims PMKID 
     Caching support on the Association request that is sent
     from the client.

*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32
  Received RSN IE with 0 PMKIDs from mobile ec:85:2f:15:39:32
!--- Since this is an initial association, the Association
     Request comes without any PMKID.

*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32
  Setting active key cache index 8 ---> 8

*apfMsConnTask_0: Jun 22 00:23:15.099: ec:85:2f:15:39:32
  Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d2
  (status 0) ApVapId 3 Slot 0
!--- The Association Response is sent to the client.

*dot1xMsgTask: Jun 22 00:23:15.103: ec:85:2f:15:39:32
  Sending EAP-Request/Identity to mobile ec:85:2f:15:39:32
  (EAP Id 1)

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.118: ec:85:2f:15:39:32
  Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.118: ec:85:2f:15:39:32
  Received Identity Response (count=1) from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.126: ec:85:2f:15:39:32
  Processing Access-Challenge for mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.126: ec:85:2f:15:39:32
  Sending EAP Request from AAA to mobile ec:85:2f:15:39:32
  (EAP Id 2)

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.146: ec:85:2f:15:39:32
  Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.146: ec:85:2f:15:39:32
  Received EAP Response from mobile ec:85:2f:15:39:32
  (EAP Id 2, EAP Type 25)

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
  Processing Access-Accept for mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
  Creating a PKC PMKID Cache entry for station ec:85:2f:15:39:32
  (RSN 2)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
  Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
  Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
  Adding BSSID 84:78:ac:f0:68:d2 to PMKID cache at index 0
  for station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274:
  New PMKID: (16)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274:
  [0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- WLC creates a PMK cache entry for this client, which is
     used for SKC in this case, so the PMKID is computed with
     the AP MAC address (BSSID 84:78:ac:f0:68:d2).

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
  Sending EAP-Success to mobile ec:85:2f:15:39:32
  (EAP Id 12)

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275:
  Including PMKID in M1  (16)
!--- The hashed PMKID is included on the Message-1 of the
     WPA/WPA2 4-Way handshake.

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275:
  [0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- This is the hashed PMKID.

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275: ec:85:2f:15:39:32
  Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32
  state INITPMK (message 1), replay counter
  00.00.00.00.00.00.00.00
!--- Message-1 of the WPA/WPA2 4-Way handshake is sent from
     the WLC/AP to the client.

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32
  Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32
  Received EAPOL-key in PTK_START state (message 2) from mobile
  ec:85:2f:15:39:32
!--- Message-2 of the WPA/WPA-2 4-Way handshake is successfully
     received from the client.

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32
  PMK: Sending cache add

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.285: ec:85:2f:15:39:32
  Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32
  state PTKINITNEGOTIATING (message 3), replay counter
  00.00.00.00.00.00.00.01
!--- Message-3 of the WPA/WPA2 4-Way handshake is sent from
     the WLC/AP to the client.

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.291: ec:85:2f:15:39:32
  Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.291: ec:85:2f:15:39:32
  Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
  from mobile ec:85:2f:15:39:32
!--- Message-4 (final message) of this initial WPA/WPA2 4-Way
     handshake is successfully received from the client, which
     confirms the installation of the derived keys. They can
     now be used in order to encrypt data frames with the current AP.

이 방법으로 AP 및 무선 클라이언트는 이미 설정된 보안 연결의 PMK를 캐시합니다.따라서 무선 클라이언트가 연결되지 않은 새 AP로 로밍하는 경우, 클라이언트가 새 AP로 로밍하는 이 무선 캡처에 표시된 대로 클라이언트가 전체 EAP 인증을 다시 수행해야 합니다.

그러나 무선 클라이언트가 이전 연결/인증이 발생한 AP로 다시 로밍하면 클라이언트는 여러 PMKID를 나열하는 재연결 요청 프레임을 보냅니다. 이 프레임은 클라이언트가 이전에 인증된 모든 AP에서 캐시된 PMK를 AP에 알립니다.따라서 클라이언트가 이 클라이언트에 대해 캐싱된 PMK도 있는 AP로 다시 로밍되므로, 새 PMK를 파생하기 위해 클라이언트가 EAP를 통해 다시 인증할 필요가 없습니다.클라이언트는 WPA2 4-Way 핸드셰이크를 통해 새로운 임시 암호화 키를 파생합니다.

참고:이 캡처는 클라이언트의 첫 번째 802.11 Open System 인증 프레임을 표시하지 않지만 이 프레임이 항상 필요하므로 구현된 방법 때문이 아닙니다.이유는 이 특정 프레임이 이 예제의 무선 프레임을 스니핑하기 위해 사용되는 어댑터 또는 무선 패킷 캡처 소프트웨어에 의해 캡처되지 않기 때문입니다. 그러나 교육적인 목적으로 이 예제에서 그대로 유지됩니다.무선 패킷 캡처를 수행할 때 이러한 문제가 발생할 수 있다는 점에 유의하십시오.일부 프레임은 캡처에서 누락될 수 있지만 실제로 클라이언트와 AP 간에 교환됩니다.그렇지 않으면 이 예에서는 로밍이 시작되지 않습니다.

다음은 이 빠른 보안 로밍 방법에 대한 WLC 디버그의 요약입니다.

*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
  Reassociation received from mobile on BSSID
  84:78:ac:f0:68:d2
!--- This is the Reassociation Request from the client.

*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
  Processing RSN IE type 48, length 38 for mobile
  ec:85:2f:15:39:32
!--- The WLC/AP finds an Information Element that claims PMKID 
     Caching support on the Association request that is sent
     from the client.

*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
  Received RSN IE with 1 PMKIDs from mobile
  ec:85:2f:15:39:32
!--- The Reassociation Request from the client comes with
     one PMKID.

*apfMsConnTask_0: Jun 22 00:26:40.787:
  Received PMKID:  (16)
*apfMsConnTask_0: Jun 22 00:26:40.788:
  [0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- This is the PMKID that is received.

*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
  Searching for PMKID in MSCB PMKID cache for mobile
  ec:85:2f:15:39:32
!--- WLC searches for a matching PMKID on the database.

*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
  Found an cache entry for BSSID 84:78:ac:f0:68:d2 in
  PMKID cache at index 0 of station ec:85:2f:15:39:32

*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
  Found a valid PMKID in the MSCB PMKID cache for mobile
  ec:85:2f:15:39:32
!--- The WLC validates the PMKID provided by the client,
     and confirms that it has a valid PMK cache for this
     client-and-AP pair.

*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
  Setting active key cache index 1 ---> 0

*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
  Sending Assoc Response to station on BSSID
  84:78:ac:f0:68:d2(status 0) ApVapId 3 Slot 0
!--- The Reassociation Response is sent to the client, which
     validates the fast-roam with SKC.

*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
  Initiating RSN with existing PMK to mobile
  ec:85:2f:15:39:32
!--- WLC initiates a Robust Secure Network association with
     this client-and-AP pair based on the cached PMK found.
     Hence, EAP is avoided as per the next message.

*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
  Skipping EAP-Success to mobile ec:85:2f:15:39:32

*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
  Found an cache entry for BSSID 84:78:ac:f0:68:d2 in
  PMKID cache at index 0 of station ec:85:2f:15:39:32

*dot1xMsgTask: Jun 22 00:26:40.795: Including PMKID in M1(16)
!--- The hashed PMKID is included on the Message-1 of the
     WPA/WPA2 4-Way handshake.

*dot1xMsgTask: Jun 22 00:26:40.795:
  [0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- The PMKID is hashed. The next messages are the same
     WPA/WPA2 4-Way handshake messages described thus far
     that are used in order to finish the encryption keys
     generation/installation.

*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
  Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
  INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00

*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.811: ec:85:2f:15:39:32
  Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
  Received EAPOL-key in PTK_START state (message 2) from mobile
  ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
  PMK: Sending cache add

*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
  Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state 
  PTKINITNEGOTIATING (message 3), replay counter 
  00.00.00.00.00.00.00.01

*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.820: ec:85:2f:15:39:32
  Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.820: ec:85:2f:15:39:32
  Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
  from mobile ec:85:2f:15:39:32

PMKID 캐싱/고정 키 캐싱을 사용하는 FlexConnect

FlexConnect 설정에서 이 방법을 사용할 경우 이 방법이 작동할 수 있으며 중앙 인증을 다시 WLC에 사용할 경우(중앙 또는 로컬 스위칭 사용) 이전에 설명한 것과 유사한 동작이 발생할 수 있습니다.그러나 이 SKC 방법은 FlexConnect에서 지원되지 않습니다.
이 방법은 FlexConnect 또는 기타 모드가 아닌 로컬 모드 AP가 있는 CUWN에서만 공식적으로 지원됩니다.

PMKID 캐싱/고정 키 캐싱의 장점

이 방법은 캐시된 키를 관리하기 위해 중앙 집중식 디바이스가 필요 없이 자율 독립 AP에 의해 로컬로 구현할 수 있습니다.

PMKID 캐싱/고정 키 캐싱과 단점

이 문서의 앞부분에서 언급한 대로, 이 방법의 주요 제한은 클라이언트가 이전에 연결/인증된 AP로 다시 로밍할 때 빠른 보안 로밍만 수행할 수 있다는 것입니다.새 AP로 로밍하는 경우 클라이언트는 전체 EAP 인증을 다시 완료해야 합니다.
무선 클라이언트 및 AP는 모든 새 인증에서 파생된 모든 PMK를 기억해야 하므로 이 기능은 일반적으로 캐시되는 특정 양의 PMK로 제한됩니다.이 제한은 표준에서 명확히 정의되지 않으므로 공급업체는 SKC 구현에 대해 다른 제한을 정의할 수 있습니다.예를 들어 Cisco WLAN 컨트롤러는 현재 최대 8개의 AP에 대해 클라이언트에서 PMK를 캐시할 수 있습니다.클라이언트가 세션당 8개 이상의 AP로 로밍하는 경우, 새로 캐시된 엔트리를 저장하기 위해 가장 오래된 AP가 캐시 목록에서 제거됩니다.
이 방법은 선택 사항이며 많은 WPA2 장치에서 여전히 지원되지 않습니다.따라서 이 방법은 널리 채택되고 구축되지 않습니다.
SKC는 컨트롤러 간 로밍을 수행할 때 지원되지 않습니다. 이는 서로 다른 WLC에서 관리하는 AP 간에 이동할 때 발생합니다(동일한 모빌리티 그룹에 있는 경우에도).

기회주의적 키 캐싱을 사용한 빠른 보안 로밍

PKC(Proactive Key Caching)라고도 하는 OKC(Opportunistic Key Caching)는 앞에서 설명한 WPA2 PMKID 캐싱 방법의 개선 사항이며, 따라서 Proactive/Optical PMKID 캐싱이라고도 합니다.따라서 802.11 표준에 의해 정의된 고속 보안 로밍 방법은 아니며 많은 디바이스에서 지원되지 않지만 PMKID 캐싱과 마찬가지로 WPA2-EAP에서 작동합니다.

이 기술을 사용하면 무선 클라이언트와 WLAN 인프라에서 이 WLAN과의 클라이언트 연결 수명(인증 서버와의 초기 802.1X/EAP 인증 이후 MSK에서 파생됨)에 대해 하나의 PMK만 캐시할 수 있습니다. 이는 모든 WPA2 4방향 핸드쉐이크에 대한 시드로 사용되는 원래 PMK를 공유하는 경우에도 마찬가지입니다.클라이언트가 AP와 다시 연결할 때마다 새 암호화 키를 생성하려면 SKC에서와 마찬가지로 이 기능도 필요합니다.AP가 클라이언트 세션에서 이 원래 PMK를 공유하려면 모든 AP에 대해 원래 PMK를 캐시하고 분배하는 중앙 집중식 디바이스를 사용하여 모든 AP를 일종의 관리 제어에 있어야 합니다.이는 CUWN과 유사합니다. WLC는 제어 대상인 모든 LAP에 대해 이 작업을 수행하고 여러 WLC 간에 이 PMK를 처리하기 위해 모빌리티 그룹을 사용합니다.따라서 이는 자동 AP 환경의 한계입니다.

이 방법을 사용하면 PMKID 캐싱(SKC)에서와 마찬가지로 모든 AP에 대한 초기 연결은 WLAN에 대한 정기적인 첫 번째 인증입니다. 이 경우 데이터 프레임을 전송하기 전에 인증 서버에 대해 전체 802.1X/EAP 인증을 완료하고 키 생성을 위한 4방향 핸드셰이크를 완료해야 합니다.다음은 이러한 내용을 보여 주는 화면 캡처입니다.

디버그 출력은 기본적으로 WLAN에 대한 초기 인증 시 이 문서에 설명된 방법 중 나머지 방법과 동일한 EAP 인증 프레임 교환을 보여주며, 여기에는 WLC에서 사용하는 키 캐싱 기술에 관련된 일부 출력 추가가 포함됩니다.관련 정보만 표시하도록 이 디버그 출력도 잘립니다.

*apfMsConnTask_0: Jun 21 21:46:06.515: 00:40:96:b7:ab:5c
  Association received from mobile on BSSID
  84:78:ac:f0:68:d2
!--- This is the Association Request from the client.

*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
  Processing RSN IE type 48, length 20 for mobile
  00:40:96:b7:ab:5c
!--- The WLC/AP finds an Information Element that claims 
     PMKID Caching support on the Association request that 
     is sent from the client. 

*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
  Received RSN IE with 0 PMKIDs from mobile
  00:40:96:b7:ab:5c
!--- Since this is an initial association, the Association
     Request comes without any PMKID.

*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
  Setting active key cache index 0 ---> 8

*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
  Sending Assoc Response to station on BSSID
  84:78:ac:f0:68:d2 (status 0) ApVapId 3 Slot 
!--- The Association Response is sent to the client.

*dot1xMsgTask: Jun 21 21:46:06.522: 00:40:96:b7:ab:5
  Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
  (EAP Id 1)

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.614: 00:40:96:b7:ab:5c
  Received EAPOL START from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.614: 00:40:96:b7:ab:5c
  Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
  (EAP Id 2)

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.623: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.623: 00:40:96:b7:ab:5c
  Received Identity Response (count=2) from mobile
  00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.630: 00:40:96:b7:ab:5c
  Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.630: 00:40:96:b7:ab:5c
  Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
  (EAP Id 3)

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.673: 00:40:96:b7:ab:5c
  Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.673: 00:40:96:b7:ab:5c
  Received EAP Response from mobile 00:40:96:b7:ab:5c
  (EAP Id 3, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.843: 00:40:96:b7:ab:5c
  Processing Access-Accept for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
  Creating a PKC PMKID Cache entry for station
  00:40:96:b7:ab:5c (RSN 2)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
  Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
  Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
  Adding BSSID 84:78:ac:f0:68:d2 to PMKID cache at index 0
  for station 00:40:96:b7:ab:5
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: New PMKID: (16)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844:
  [0000] 4e a1 7f 5a 75 48 9c f9 96 e3 a8 71 25 6f 11 d0
!--- WLC creates a PMK cache entry for this client, which is
     used for OKC in this case, so the PMKID is computed
     with the AP MAC address (BSSID 84:78:ac:f0:68:d2).

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
  PMK sent to mobility group
!--- The PMK cache entry for this client is shared with the
     WLCs on the mobility group.

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
  Sending EAP-Success to mobile 00:40:96:b7:ab:5c (EAP Id 13)

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
  Found an cache entry for BSSID 84:78:ac:f0:68:d2 in PMKID
  cache at index 0 of station 00:40:96:b7:ab:5

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: Including PMKID
  in M1  (16)
!--- The hashed PMKID is included on the Message-1 of the
     WPA/WPA2 4-Way handshake.

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844:
  [0000] 4e a1 7f 5a 75 48 9c f9 96 e3 a8 71 25 6f 11 d0
!--- This is the hashed PMKID. The next messages are the same
     WPA/WPA2 4-Way handshake messages described thus far that
     are used in order to finish the encryption keys
     generation/installation.

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
  Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
  INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
  Received EAPOL-Key from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
  Received EAPOL-key in PTK_START state (message 2)
  from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
  PMK: Sending cache add

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
  Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
  PTKINITNEGOTIATING (message 3), replay counter
  00.00.00.00.00.00.00.01

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.889: 00:40:96:b7:ab:5c
  Received EAPOL-Key from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.890: 00:40:96:b7:ab:5c
  Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
  from mobile 00:40:96:b7:ab:5c

이 방법을 사용하면 무선 클라이언트와 WLC(모든 관리되는 AP의 경우)가 처음에 설정된 보안 연결의 원래 PMK 하나를 캐시합니다.기본적으로 무선 클라이언트가 특정 AP에 연결할 때마다 PMKID는 다음을 기반으로 해시됩니다.클라이언트 MAC 주소, AP MAC 주소(WLAN의 BSSID) 및 해당 AP로 파생된 PMK입니다.따라서 OKC는 모든 AP 및 특정 클라이언트에 대해 동일한 원래 PMK를 캐시하므로 이 클라이언트(re)가 다른 AP에 연결되면 새 PMKID를 해시하기 위해 변경되는 유일한 값은 새 AP MAC 주소입니다.

클라이언트가 새 AP로 로밍을 시작하고 재연결 요청 프레임을 보내면 캐시된 PMK가 빠른 보안 로밍에 사용됨을 AP에 알리려는 경우 WPA2 RSN 정보 요소에 PMKID를 추가합니다.AP(BSSID)의 MAC 주소를 이미 알고 있기 때문에 클라이언트는 이 재연결 요청에서 사용되는 새 PMKID를 단순히 해시합니다.AP는 클라이언트로부터 이 요청을 받으면 이미 있는 값(캐시된 PMK, 클라이언트 MAC 주소 및 자체 AP MAC 주소)으로 PMKID를 해시하고 PMKID가 일치하는지 확인하는 성공적인 재연결 응답으로 응답합니다.캐시된 PMK는 새 암호화 키를 파생시키기 위해 WPA2 4-Way 핸드셰이크를 시작하는 시드로 사용할 수 있습니다(EAP 생략).

이 캡처에서는 프레임의 자세한 내용을 볼 수 있도록 클라이언트에서 [재연결 요청] 프레임을 선택하고 확장합니다.MAC 주소 정보 및 802.11i - WPA2(Robust Security Network) 정보 요소이며, 이 연결에 사용된 WPA2 설정에 대한 정보가 표시됩니다(강조 표시된 것은 해시된 수식에서 얻은 PMKID).

다음은 OKC를 사용하는 이 빠른 보안 로밍 방법에 대한 WLC 디버그의 요약입니다.

*apfMsConnTask_2: Jun 21 21:48:50.562: 00:40:96:b7:ab:5c
  Reassociation received from mobile on BSSID
  84:78:ac:f0:2a:92
!--- This is the Reassociation Request from the client.

*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
  Processing RSN IE type 48, length 38 for mobile
  00:40:96:b7:ab:5c
!--- The WLC/AP finds and Information Element that claims 
     PMKID Caching support on the Association request that
     is sent from the client. 

*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
  Received RSN IE with 1 PMKIDs from mobile
  00:40:96:b7:ab:5c
!--- The Reassociation Request from the client comes with
     one PMKID.

*apfMsConnTask_2: Jun 21 21:48:50.563:
  Received PMKID:  (16)

*apfMsConnTask_2: Jun 21 21:48:50.563:
  [0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9

*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
  Searching for PMKID in MSCB PMKID cache for mobile
  00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
  No valid PMKID found in the MSCB PMKID cache for mobile
  00:40:96:b7:ab:5
!--- As the client has never authenticated with this new AP,
     the WLC cannot find a valid PMKID to match the one provided
     by the client. However, since the client performs OKC
     and not SKC (as per the following messages), the WLC computes
     a new PMKID based on the information gathered (the cached PMK,
     the client MAC address, and the new AP MAC address).

*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
  Trying to compute a PMKID from MSCB PMK cache for mobile
  00:40:96:b7:ab:5c

*apfMsConnTask_2: Jun 21 21:48:50.563:
  CCKM: Find PMK in cache: BSSID =  (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
  [0000] 84 78 ac f0 2a 90
*apfMsConnTask_2: Jun 21 21:48:50.563:
  CCKM: Find PMK in cache: realAA =  (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
  [0000] 84 78 ac f0 2a 92
*apfMsConnTask_2: Jun 21 21:48:50.563:
  CCKM: Find PMK in cache: PMKID =  (16)
*apfMsConnTask_2: Jun 21 21:48:50.563:
  [0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
*apfMsConnTask_2: Jun 21 21:48:50.563:
  CCKM: AA (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
  [0000] 84 78 ac f0 2a 92
*apfMsConnTask_2: Jun 21 21:48:50.563:
  CCKM: SPA (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
  [0000] 00 40 96 b7 ab 5c
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
  Adding BSSID 84:78:ac:f0:2a:92 to PMKID cache at
  index 0 for station 00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 21 21:48:50.563:
  New PMKID: (16)
*apfMsConnTask_2: Jun 21 21:48:50.563:
  [0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
  Computed a valid PMKID from MSCB PMK cache for mobile
  00:40:96:b7:ab:5c
!--- The new PMKID is computed and validated to match the
     one provided by the client, which is also computed with
     the same information. Hence, the fast-secure roam is
     possible.

*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
  Setting active key cache index 0 ---> 0

*apfMsConnTask_2: Jun 21 21:48:50.564: 00:40:96:b7:ab:5c
  Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:92
  (status 0) ApVapId 3 Slot 
!--- The Reassociation response is sent to the client, which
     validates the fast-roam with OKC.

*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
  Initiating RSN with existing PMK to mobile
  00:40:96:b7:ab:5c
!--- WLC initiates a Robust Secure Network association with
     this client-and AP pair with the cached PMK found.
     Hence, EAP is avoided, as per the the next message.

*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
  Skipping EAP-Success to mobile 00:40:96:b7:ab:5c

*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
  Found an cache entry for BSSID 84:78:ac:f0:2a:92 in
  PMKID cache at index 0 of station 00:40:96:b7:ab:5c

*dot1xMsgTask: Jun 21 21:48:50.570:
  Including PMKID in M1  (16)
!--- The hashed PMKID is included on the Message-1 of the
     WPA/WPA2 4-Way handshake.

*dot1xMsgTask: Jun 21 21:48:50.570:
  [0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
!--- The PMKID is hashed. The next messages are the same
     WPA/WPA2 4-Way handshake messages described thus far,
     which are used in order to finish the encryption keys
     generation/installation.

*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
  Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
  INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00

*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5
  Received EAPOL-Key from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5c
  Received EAPOL-key in PTK_START state (message 2) from mobile
  00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5c
  PMK: Sending cache add

*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.590: 00:40:96:b7:ab:5c
  Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
  PTKINITNEGOTIATING (message 3), replay counter
  00.00.00.00.00.00.00.01

*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.610: 00:40:96:b7:ab:5c
  Received EAPOL-Key from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.610: 00:40:96:b7:ab:5c
  Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
  from mobile 00:40:96:b7:ab:5c

디버그의 시작 부분에 표시된 것처럼 클라이언트에서 재연결 요청을 받은 후 PMKID를 계산해야 합니다.PMKID를 확인하고 캐시된 PMK가 WPA2 4-Way 핸드셰이크에서 암호화 키를 파생하고 빠른 보안 로밍을 완료하기 위해 사용되는지 확인하기 위해 필요합니다.디버그의 CCKM 항목을 혼동하지 마십시오.이는 이전에 설명한 대로 CCKM을 수행하는 데 사용되지 않습니다.CCKM은 PMKID를 계산하기 위해 값을 처리하는 함수 이름과 같이 WLC에서 해당 출력에 사용하는 이름입니다.

기회주의적 키 캐싱을 사용한 FlexConnect

중앙 인증이 지원됩니다.여기에는 로컬 및 중앙 데이터 스위칭이 포함됩니다.AP가 동일한 FlexConnect 그룹의 일부인 경우 빠른 보안 로밍이 AP에 의해 이루어지며 그렇지 않은 경우 컨트롤러에서 빠른 보안 로밍이 수행됩니다.

참고:이 설정은 AP가 동일한 FlexConnect 그룹에 있지 않지만 권장 설정 또는 지원되는 설정이 아닌 경우에 사용할 수 있습니다.
Flex Local Authentication이 지원됩니다.연결된 모드에서는 캐시가 AP에서 컨트롤러로 분배된 다음 FlexConnect 그룹의 나머지 AP로 분배됩니다.
독립형 모드가 지원됩니다. 이전에 배포했기 때문에 AP에 캐시가 이미 있는 경우 빠른 보안 로밍이 작동합니다.독립형 모드의 새 인증은 빠른 보안 로밍을 지원하지 않습니다.

기회주의적 키 캐싱의 장점

무선 클라이언트 및 WLAN 인프라는 여러 PMKID를 기억할 필요는 없지만 초기 인증에서 WLAN에 원래 PMK를 캐시하면 됩니다.그런 다음 각 AP 보안 연결에서 필요한 적절한 PMKID(재연결 요청에서 사용)를 재검색해야 빠른 보안 로밍이 확인됩니다.
여기서 무선 클라이언트는 동일한 WLAN/SSID의 새 AP에 대해 빠른 보안 로밍을 수행합니다(SKC의 경우에는 아님). 클라이언트가 클라이언트가 클라이언트가 로밍하는 모든 AP에 대해 PMK 캐시를 처리하는 중앙 집중식 구축에서 관리되는 하나의 AP로 초기 802.1X/EAP 인증을 수행하는 한 이 WLAN의 나머지 클라이언트 수명에 대해 더 이상 전체 인증이 필요하지 않습니다.

기회주의적 키 캐싱의 단점

이 방법은 모든 AP가 클라이언트 세션에서 원래 PMK를 캐싱하고 공유하는 일종의 관리 제어(예: WLAN 컨트롤러)를 담당하는 중앙 환경에만 구축됩니다.따라서 이는 자동 AP 환경에 대한 제한 사항입니다.
이 방법에 적용되는 기술은 802.11 표준에서 제안하거나 기술하지 않으므로, 지원 내용은 한 장치에서 다른 장치로 광범위하게 다릅니다.그럼에도 불구하고, 이것은 여전히 802.11r을 기다리면서 더 많이 채택된 방법입니다.

"Proactive Key Caching(사전 대응적 키 캐싱)"이라는 용어에 대한 참고 사항

PKC(Proactive Key Caching)는 OKC(Opportistic Key Caching)라고 알려져 있으며, 여기에서 설명한 것과 동일한 방법을 설명할 때 두 용어는 동일한 방식으로 사용되었습니다.그러나 이 용어는 2001년 영공에서 이전 키 캐싱 방법으로 사용되었던 용어였으며, 이 용어는 802.11i 표준에서 "사전 인증"의 기준으로 사용되었습니다(아래에 간략하게 설명한 또 다른 고속 보안 로밍 방법).PKC는 Preauthentication 또는 OKC(Opportunistic Key Caching)가 아니지만 PKC에 대해 듣거나 읽으면 기본적으로 OKC에 대한 참조이며 Preauthentication에 대한 참조는 아닙니다.

사전 인증을 통한 빠른 보안 로밍

이 방법은 802.11i 보안 수정 버전 내의 IEEE 802.11 표준에서도 제안되므로 WPA2에서도 작동하지만 Cisco WLAN 인프라에서 지원하지 않는 유일한 고속 보안 로밍 방법입니다.이러한 이유로 이 설명은 여기에서 간단하게 설명되며 출력 없이 제공됩니다.

사전 인증을 사용하면 무선 클라이언트가 현재 AP와 연결되어 있는 동안 한 번에 여러 AP로 인증할 수 있습니다.이 경우 클라이언트는 EAP 인증 프레임을 연결된 현재 AP로 전송하지만 클라이언트가 사전 인증을 수행하려는 다른 AP로 이동됩니다(로밍 가능한 인접 AP). 현재 AP는 디스트리뷰션 시스템을 통해 이러한 프레임을 대상 AP로 전송합니다.새 AP는 이 클라이언트에 대한 RADIUS 서버에 대해 전체 인증을 수행하므로 전체 새 EAP 인증 핸드셰이크가 완료되고 이 새 AP가 인증자 역할을 합니다.

클라이언트가 실제로 로밍하기 전에 인증을 수행하고 인접 AP와 PMK를 도출하는 것이 좋습니다. 따라서 로밍할 시간이 되면 클라이언트가 이미 인증되고 이 새로운 AP-클라이언트 보안 연결을 위해 이미 캐시된 PMK가 있으므로 클라이언트는 4방향 핸드셰이크를 수행하고 클라이언트가 초기 재연결 요청을 보낸 후 빠른 로밍만 수행할 수 있습니다.

다음은 사전 인증 지원을 광고하는 RSN IE 필드를 보여 주는 AP의 신호에서 캡처한 것입니다(이 필드는 Cisco AP에서 가져온 것이며, 여기서 사전 인증이 지원되지 않는 것으로 확인됨).

사전 인증 시 장점

각 AP-클라이언트 보안 연결에는 하나의 PMK가 있는데, 이는 AP가 손상되고 키가 도난될 경우(다른 AP와 함께 사용할 수 없음) 보안 장점으로 간주될 수 있습니다. 그러나 이러한 보안 이점은 WLAN 인프라에서 다른 방법으로 처리됩니다.

사전 인증과 단점

AP당 하나의 PMK가 있으므로, 클라이언트는 사전 인증할 수 있는 AP의 양에 제한이 있습니다.
클라이언트가 새 AP를 사용하여 사전 인증을 수행할 때마다 전체 EAP 인증 교환이 있습니다. 즉, 네트워크 및 인증 서버에 더 많은 부하를 의미합니다.
대부분의 무선 클라이언트는 이 방법을 지원하지 않습니다. 이 방법이 널리 채택되지 않았기 때문입니다(OKC가 더 채택됨).

802.11r로 빠른 보안 로밍

802.11r 수정(802.11 표준에서 공식적으로 Fast BSS Transition으로 명명되었으며 FT라고 함)을 기반으로 하는 빠른 보안 로밍 기술은 802.11 표준이 802.11 표준으로 IEEE가 8002.1 표준으로 공식 승인하여 AP(Basic Service Set 또는 BSS) 간 빠른 전환을 수행하는 첫 번째 방법입니다. WLAN에서 키를 처리하고 캐시할 때 사용되는 키 계층 구조를 명확하게 정의합니다.그러나 이 문서의 도입 속도가 느리다는 것은, 이 문서에서 앞서 설명한 방법 중 하나와 함께 사용할 경우 VoWLAN 구현과 같이 빠른 전환이 실제로 필요할 때 이미 사용 가능한 다른 솔루션이 있기 때문입니다.현재 일부 FT 옵션을 지원하는 장치는 몇 개 뿐입니다(2013년까지).

이 기술은 새로운 개념과 여러 PMK의 여러 레이어를 도입하여 서로 다른 장치(각 장치가 다른 역할)에 캐시하고 빠른 보안 로밍을 위한 더 많은 옵션을 제공하므로 다른 방법보다 설명하기 쉽습니다.따라서 이 방법 및 구현 방법에 대해 사용 가능한 각 옵션과 함께 간단한 요약이 제공됩니다.

802.11r은 SKC 및 OKC와 다릅니다. 그 이유는 다음과 같습니다.

핸드셰이크 메시징(예: PMKID, ANonce 및 SNonce 교환)은 802.11 인증 프레임 또는 재연결 프레임 대신 작업 프레임에서 발생합니다.PMKID 캐싱 메서드와 달리, 연결 메시지 교환 후에 전달되는 별도의 4방향 핸드셰이크 단계는 피됩니다.새 AP와의 키 핸드셰이크는 클라이언트가 이 새 AP와 완전히 로람/재연결되기 전에 시작됩니다.
빠른 로밍 핸드셰이크를 위한 두 가지 방법을 제공합니다.IP를 통해 IPvCenter를 구축할 수 있습니다
802.11r은 키 계층 구조가 더 많습니다.
이 프로토콜은 클라이언트가 로밍할 때 키 관리에 대한 4방향 핸드셰이크를 방지하므로(이 핸드셰이크가 필요 없이 새 암호화 키 -PTK 및 GTK 생성), PSK가 있는 WPA2 설정에 적용할 수 있으며, 인증에 802.1X/EAP를 사용할 경우에만 적용할 수 있습니다.이렇게 하면 EAP 또는 4-Way 핸드셰이크 교환이 발생하지 않는 이러한 설정에 대한 로밍이 훨씬 더 빨라집니다.

이 방법을 사용하면 무선 클라이언트는 첫 번째 AP에 연결할 때 WLAN 인프라에 대해 하나의 초기 인증만 수행하고 동일한 FT 모빌리티 도메인의 AP 간에 로밍하는 동안 빠른 보안 로밍을 수행합니다.

이는 기본적으로 동일한 SSID(Extended Service Set 또는 ESS라고 함)를 사용하고 동일한 FT 키를 처리하는 AP를 참조하는 새로운 개념 중 하나입니다.이것은 지금까지 설명한 다른 방법과 비슷합니다.AP가 FT 모빌리티 도메인 키를 처리하는 방법은 일반적으로 WLC 또는 모빌리티 그룹과 같은 중앙 집중식 설정을 기반으로 합니다.그러나 이 방법은 자동 AP 환경에서도 구현할 수 있습니다.

다음은 주요 계층 구조의 요약입니다.

MSK는 클라이언트 신청자 및 인증 서버에서 초기 802.1X/EAP 인증 단계(인증이 성공하면 인증 서버에서 인증자(WLC)로 전송)에서 계속 파생됩니다. 다른 방법과 마찬가지로 이 MSK는 FT 키 계층 구조의 시드로 사용됩니다.EAP 인증 방법 대신 WPA2-PSK를 사용하는 경우 기본적으로 PSK는 이 MSK입니다.
Pairwise 마스터 키 R0(PMK-R0)은 FT 키 계층 구조의 첫 번째 수준 키인 MSK에서 파생됩니다.이 PMK-R0의 주요 보유자는 WLC와 클라이언트입니다.
PMK-R1(Pairwise Master Key R1)이라고 하는 두 번째 레벨 키는 PMK-R0에서 파생되며 주요 보유자는 PMK-R0을 포함하는 WLC에서 관리하는 클라이언트 및 AP입니다.
FT 키 계층 구조의 세 번째 및 마지막 수준 키는 PTK입니다. PTK는 802.11 유니캐스트 데이터 프레임을 암호화하는 데 사용되는 최종 키(WPA/TKIP 또는 WPA2/AES를 사용하는 다른 방법과 유사)입니다. 이 PTK는 PMK-R1에서 FT에서 파생되며, 주요 보유자는 클라이언트 및 WLC에서 관리하는 AP입니다.

참고:WLAN 벤더 및 구현 설정(예: 자동 AP, FlexConnect 또는 Mesh)에 따라 WLAN 인프라가 다른 방식으로 키를 전송하고 처리할 수 있습니다.주요 보유자의 역할을 변경할 수도 있지만, 이 문서의 범위를 벗어났기 때문에 앞에서 설명한 주요 계층 구조 요약을 기반으로 한 예가 다음 포커스입니다.소프트웨어 문제를 발견하기 위해 실제로 인프라 디바이스(및 해당 코드)를 심층적으로 분석해야 하는 경우가 아니라면, 이러한 차이점은 프로세스를 이해하는 것과 관련이 없습니다.

Fast BSS Transition Over-the-Air

이 방법을 사용하면 AP에 대한 첫 번째 연결은 WLAN에 대한 일반 첫 번째 인증입니다. 이 경우, 이 화면 캡처에 표시된 것처럼, 데이터 프레임을 전송하기 전에 인증 서버에 대한 전체 802.1X/EAP 인증 및 키 생성을 위한 4방향 핸드셰이크가 발생해야 합니다.

주요 차이점은 다음과 같습니다.

인증 키 관리 협상은 일반 WPA/WPA2와 약간 다르므로 FT를 지원하는 WLAN 인프라에 연결이 발생할 때 이 협상을 수행하기 위해 일부 추가 정보가 사용됩니다.캡처에 표시된 것처럼, 클라이언트에서 연결 요청 프레임을 선택하고 RNS 정보 요소의 AKM 필드가 강조 표시되어 이 클라이언트가 802.1X/EAP를 통해 FT를 수행하려는 것을 보여줍니다.
또한 FT의 일부인 Mobility Domain Information Element(Mobility Domain Information Element)도 표시됩니다. 여기서 FT Capability and Policy(FT 기능 및 정책) 필드는 빠른 로밍 시 Fast BSS Transition이 Over-the-Air 또는 Over-the-DS에 완료되었는지 여부를 나타냅니다(이 캡처에서 Over-the-Air를 나타냅니다).
FT 로밍 시 FT 인증 시퀀스를 수행하는 데 필요한 정보와 함께 Fast BSS Transition 또는 FT IE도 추가됩니다(이 문서의 뒷부분에서 설명).
키 생성이 키 계층 구조에 따라 다르므로 FT 4-Way 핸드셰이크는 WPA/WPA2 4-Way 핸드셰이크와 비슷하지만 실제로는 콘텐츠가 약간 다릅니다.

디버그는 기본적으로 WLAN에 대한 초기 인증 시 나머지 방법과 동일한 EAP 인증 프레임 교환을 표시하지만(캡처에서 알 수 있듯이), WLC에서 사용하는 키 캐싱 기술과 관련된 일부 출력이 추가됩니다.따라서 관련 정보만 표시하도록 이 디버그 출력이 잘립니다.

*apfMsConnTask_0: Jun 27 19:25:23.426: ec:85:2f:15:39:32
  Association received from mobile on BSSID
  84:78:ac:f0:68:d6
!--- This is the Association request from the client.

*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
  Marking this mobile as TGr capable.
!--- WLC recognizes that the client is 802.11r-capable.

*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
  Processing RSN IE type 48, length 20 for mobile
  ec:85:2f:15:39:32
!--- The WLC/AP finds an Information Element that claims FT
     support on the Association request that is sent from the client. 

*apfMsConnTask_0: Jun 27 19:25:23.427:
  Sending assoc-resp station:ec:85:2f:15:39:32
  AP:84:78:ac:f0:68:d0-00 thread:144be808
*apfMsConnTask_0: Jun 27 19:25:23.427:
  Adding MDIE, ID is:0xaaf0
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
  Including FT Mobility Domain IE (length 5) in Initial
  assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
  Sending R0KH-ID as:-84.30.6.-3
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
  Sending R1KH-ID as 3c:ce:73:d8:02:00
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
  Including FT IE (length 98) in Initial Assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
  Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d6
  (status 0) ApVapId 7 Slot 0
!--- The Association Response is sent to the client once the
     FT information is computed (as per the previous messages),
     so this is included in the response.

*dot1xMsgTask: Jun 27 19:25:23.432: ec:85:2f:15:39:32
  Sending EAP-Request/Identity to mobile ec:85:2f:15:39:32
  (EAP Id 1)
!--- EAP begins, and follows the same exchange explained so far.

*apfMsConnTask_0: Jun 27 19:25:23.436: ec:85:2f:15:39:32
  Got action frame from this client.

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32
  Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32
  Received Identity Response (count=1) from mobile
  ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32
  Processing Access-Challenge for mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32
  Sending EAP Request from AAA to mobile ec:85:2f:15:39:32
  (EAP Id 2)

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32
  Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32
  Received EAP Response from mobile ec:85:2f:15:39:32
  (EAP Id 2, EAP Type 25)

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
  Processing Access-Accept for mobile ec:85:2f:15:39:32
!--- The client is validated/authenticated by the RADIUS Server.

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
  Creating a PKC PMKID Cache entry for station
  ec:85:2f:15:39:32 (RSN 2)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
  Resetting MSCB PMK Cache Entry 0 for station
  ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
  Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32
  Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32
  Adding BSSID 84:78:ac:f0:68:d6 to PMKID cache at index 0
  for station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: New PMKID: (16)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628:
  [0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629: ec:85:2f:15:39:32
  Created PMK Cache Entry for TGr AKM:802.1x ec:85:2f:15:39:32
!--- WLC creates a PMK cache entry for this client, which is
     used for FT with 802.1X in this case, so the PMKID is
     computed with the AP MAC address (BSSID 84:78:ac:f0:68:d6).

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629:
  ec:85:2f:15:39:32   R0KH-ID:172.30.6.253
  R1KH-ID:3c:ce:73:d8:02:00  MSK Len:48 pmkValidTime:1807
!--- The R0KH-ID and R1KH-ID are defined, as well as the PMK
     cache validity period.

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
  PMK sent to mobility group
!--- The FT PMK cache entry for this client is shared with the
     WLCs on the mobility group.

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
  Sending EAP-Success to mobile ec:85:2f:15:39:32 (EAP Id 12)

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
  Found an cache entry for BSSID 84:78:ac:f0:68:d6 in PMKID
  cache at index 0 of station ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: Including PMKID in
  M1  (16)
!--- The hashed PMKID is included on the Message-1 of the
     initial FT 4-Way handshake.

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630:
  [0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
  Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
  INITPMK (message 1), replay counter 00.00.00.00.00.00.00.0
!--- Message-1 of the FT 4-Way handshake is sent from the
     WLC/AP to the client.

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
  Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
  Received EAPOL-key in PTK_START state (message 2) from
  mobile ec:85:2f:15:39:32
!--- Message-2 of the FT 4-Way handshake is received
     successfully from the client.

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
  Calculating PMKR0Name
!--- The PMKR0Name is calculated.

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
  DOT11R: Sending cache add

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: Adding MDIE,
  ID is:0xaaf0
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
  Adding TIE for reassociation deadtime:20000 milliseconds
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
  Adding TIE for R0Key-Data valid time :1807
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.640: ec:85:2f:15:39:32
  Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
  PTKINITNEGOTIATING (message 3), replay counter
  00.00.00.00.00.00.00.01
!--- After the MDIE, TIE for reassociation deadtime, and TIE
     for R0Key-Data valid time are calculated, the Message-3
     of this FT 4-Way handshake is sent from the WLC/AP to the
     client with this information.

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32
  Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32
  Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
  from mobile ec:85:2f:15:39:32
!--- Message-4 (final message) of this initial FT 4-Way handshake
     is received successfully from the client, which confirms the
     installation of the derived keys. They can now be used in order
     to encrypt data frames with the current AP.

참고:이 메서드를 디버깅하고 여기에 표시된 추가 802.11r/FT 출력에 도달하기 위해 디버그 클라이언트와 함께 추가 디버그가 활성화되며 이는 디버그 ft 이벤트가 활성화됩니다.

다음은 802.1X/EAP 방법 대신 WPA2-PSK를 사용하여 FT를 수행할 때 WLAN에 대한 초기 연결의 캡처 및 디버깅입니다. 여기서 AP의 연결 응답 프레임이 Fast BSS Transition Information Element(강조 표시됨)를 표시하기 위해 선택됩니다. FT 4-Way 핸드셰이크를 수행하기 위해 필요한 일부 주요 정보도 표시됩니다.

*apfMsConnTask_0: Jun 27 19:29:09.136: ec:85:2f:15:39:32
  Association received from mobile on BSSID
  84:78:ac:f0:68:d4

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
  Marking this mobile as TGr capable.

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
  Processing RSN IE type 48, length 20 for mobile
  ec:85:2f:15:39:32

*apfMsConnTask_0: Jun 27 19:29:09.137: Sending assoc-resp
  station:ec:85:2f:15:39:32 AP:84:78:ac:f0:68:d0-00
  thread:144be808

*apfMsConnTask_0: Jun 27 19:29:09.137: Adding MDIE,
  ID is:0xaaf0

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
  Including FT Mobility Domain IE (length 5) in Initial
  assoc Resp to mobile

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
  Sending R0KH-ID as:-84.30.6.-3

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
  Sending R1KH-ID as 3c:ce:73:d8:02:00

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
  Including FT IE (length 98) in Initial Assoc Resp to mobile

*apfMsConnTask_0: Jun 27 19:29:09.138: ec:85:2f:15:39:32
  Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d4
  (status 0) ApVapId 5 Slot 0

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
  Creating a PKC PMKID Cache entry for station
  ec:85:2f:15:39:32 (RSN 2)

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
  Resetting MSCB PMK Cache Entry 0 for station
  ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
  Setting active key cache index 8 ---> 8

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
  Setting active key cache index 8 ---> 0

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
  Adding BSSID 84:78:ac:f0:68:d4 to PMKID cache at
  index 0 for station ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.142: New PMKID: (16)

*dot1xMsgTask: Jun 27 19:29:09.142:
  [0000] 17 4b 17 5c ed 5f c7 1d 66 39 e9 5d 3a 63 69 e7

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
  Creating global PMK cache for this TGr client

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
  Created PMK Cache Entry for TGr AKM:PSK
  ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
  R0KH-ID:172.30.6.253   R1KH-ID:3c:ce:73:d8:02:00
  MSK Len:48 pmkValidTime:1813

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
  Initiating RSN PSK to mobile ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
  Found an cache entry for BSSID 84:78:ac:f0:68:d4 in
  PMKID cache at index 0 of station ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.142: Including PMKID
  in M1  (16)

*dot1xMsgTask: Jun 27 19:29:09.142:
  [0000] 17 4b 17 5c ed 5f c7 1d 66 39 e9 5d 3a 63 69 e7

*dot1xMsgTask: Jun 27 19:29:09.143: ec:85:2f:15:39:32
  Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32
  state INITPMK (message 1), replay counter
  00.00.00.00.00.00.00.00

*apfMsConnTask_0: Jun 27 19:29:09.144: ec:85:2f:15:39:32
  Got action frame from this client.

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.152: ec:85:2f:15:39:32
  Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
  Received EAPOL-key in PTK_START state (message 2) from
  mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
  Calculating PMKR0Name

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: Adding MDIE,
  ID is:0xaaf0

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
  Adding TIE for reassociation deadtime:20000 milliseconds

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
  Adding TIE for R0Key-Data valid time :1813

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.154: ec:85:2f:15:39:32
  Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
  PTKINITNEGOTIATING (message 3), replay counter
  00.00.00.00.00.00.00.01

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.163: ec:85:2f:15:39:32
  Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.163: ec:85:2f:15:39:32
  Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
  from mobile ec:85:2f:15:39:32

802.11r에서는 다른 빠른 보안 로밍 방법과 마찬가지로 이 기법에 사용되는 기본 키를 파생하기 위해 WLAN에 대한 초기 연결이 사용됩니다.주된 차이점은 클라이언트가 로밍하기 시작할 때 발생합니다.FT는 802.1X/EAP를 사용하는 경우 이를 방지할 뿐만 아니라, FT 정보를 교환하고 4방향 핸드셰이크 대신 새로운 동적 암호화 키를 파생시키기 위해 초기 802.11 개방형 시스템 인증 및 재연결 프레임(AP 간에 로밍할 때 항상 사용 및 필요)을 결합하는 보다 효율적인 로밍 방법을 실제로 수행합니다.

다음 캡처는 802.1X/EAP 보안이 포함된 Fast BSS Transition Over-the-Air가 수행될 때 교환되는 프레임을 보여줍니다.FT 키 협상을 시작하는 데 필요한 FT 프로토콜 정보 요소를 보려면 클라이언트에서 AP로 시스템 인증 열기 프레임이 선택됩니다.이는 새 AP를 사용하여 새 PTK를 파생시키는 데 사용됩니다(PMK-R1 기반). 이 클라이언트가 간단한 Open System Authentication(오픈 시스템 인증)을 수행하지 않고 Fast BSS Transition(고속 BSS 전환)을 수행함을 나타내기 위해 인증 알고리즘을 표시하는 필드가 강조 표시됩니다.

다음은 802.1X/EAP에서 이 FT 로밍 이벤트가 발생할 때 WLC의 디버그 출력입니다.

*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
  Doing preauth for this client over the Air
!--- WLC begins FT fast-secure roaming over-the-Air with
     this client and performs a type of preauthentication,
     because the client asks for this with FT on the Authentication
     frame that is sent to the new AP over-the-Air
     (before the Reassociation Request).

*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
  Doing local roaming for destination address
  84:78:ac:f0:2a:96
!--- WLC performs the local roaming event with the new AP to
     which the client roams.

*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
  Got 1 AKMs in RSNIE
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
  RSNIE AKM matches with PMK cache entry :0x3
!--- WLC receives one PMK from this client (known as AKM here),
     which matches the PMK cache entry hold for this client.

*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
  Created a new preauth entry for AP:84:78:ac:f0:2a:96
*apfMsConnTask_2: Jun 27 19:25:48.751: Adding MDIE,
  ID is:0xaaf0
!--- WLC creates a new preauth entry for this AP-and-Client pair,
     and adds the MDIE information.

*apfMsConnTask_2: Jun 27 19:25:48.763: Processing assoc-req
  station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
  thread:144bef38
*apfMsConnTask_2: Jun 27 19:25:48.763: ec:85:2f:15:39:32
  Reassociation received from mobile on BSSID
  84:78:ac:f0:2a:96
!--- Once the client receives the Authentication frame reply from the
     WLC/AP, the Reassociation request is sent, which is received at
     the new AP to which the client roams.

*apfMsConnTask_2: Jun 27 19:25:48.764: ec:85:2f:15:39:32
  Marking this mobile as TGr capable.

*apfMsConnTask_2: Jun 27 19:25:48.764: ec:85:2f:15:39:32
  Processing RSN IE type 48, length 38 for mobile
  ec:85:2f:15:39:32

*apfMsConnTask_2: Jun 27 19:25:48.765: ec:85:2f:15:39:32
  Roaming succeed for this client.
!--- WLC confirms that the FT fast-secure roaming is successful
     for this client.

*apfMsConnTask_2: Jun 27 19:25:48.765: Sending assoc-resp
  station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
  thread:144bef38
*apfMsConnTask_2: Jun 27 19:25:48.766: Adding MDIE,
  ID is:0xaaf0
*apfMsConnTask_2: Jun 27 19:25:48.766: ec:85:2f:15:39:32
  Including FT Mobility Domain IE (length 5) in
  reassociation assoc Resp to mobile
*apfMsConnTask_2: Jun 27 19:25:48.766: ec:85:2f:15:39:32
  Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:96
  (status 0) ApVapId 7 Slot 0
!--- The Reassociation response is sent to the client, which
     includes the FT Mobility Domain IE.

*dot1xMsgTask: Jun 27 19:25:48.769: ec:85:2f:15:39:32
  Finishing FT roaming for mobile ec:85:2f:15:39:32
!--- FT roaming finishes and EAP is skipped (as well as any
     other key management handshake), so the client is ready
     to pass encrypted data frames with the current AP.

*dot1xMsgTask: Jun 27 19:25:48.769: ec:85:2f:15:39:32
  Skipping EAP-Success to mobile ec:85:2f:15:39:32

다음은 WPA2-PSK 보안이 포함된 Fast BSS Transition Over-the-Air를 보여 주는 캡처입니다. 이 FT Exchange에 대한 자세한 내용을 표시하기 위해 AP에서 클라이언트로 최종 Reassociation Response 프레임을 선택합니다.

다음은 802.1X/EAP를 사용할 때와 비슷한 PSK에서 이 FT 로밍 이벤트가 발생할 때의 디버그 출력입니다.

*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
  Doing preauth for this client over the Air

*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
  Doing local roaming for destination address
  84:78:ac:f0:2a:94

*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
  Got 1 AKMs in RSNIE

*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
  RSNIE AKM matches with PMK cache entry :0x4

*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
  Created a new preauth entry for AP:84:78:ac:f0:2a:94

*apfMsConnTask_2: Jun 27 19:29:29.854: Adding MDIE,
  ID is:0xaaf0

*apfMsConnTask_2: Jun 27 19:29:29.867: Processing assoc-req
  station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
  thread:144bef38

*apfMsConnTask_2: Jun 27 19:29:29.867: ec:85:2f:15:39:32
  Reassociation received from mobile on BSSID
  84:78:ac:f0:2a:94

*apfMsConnTask_2: Jun 27 19:29:29.868: ec:85:2f:15:39:32
  Marking this mobile as TGr capable.

*apfMsConnTask_2: Jun 27 19:29:29.868: ec:85:2f:15:39:32
  Processing RSN IE type 48, length 38 for mobile
  ec:85:2f:15:39:32

*apfMsConnTask_2: Jun 27 19:29:29.869: ec:85:2f:15:39:32
  Roaming succeed for this client.

*apfMsConnTask_2: Jun 27 19:29:29.869: Sending assoc-resp
  station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
  thread:144bef38

*apfMsConnTask_2: Jun 27 19:29:29.869: Adding MDIE,
  ID is:0xaaf0

*apfMsConnTask_2: Jun 27 19:29:29.869: ec:85:2f:15:39:32
  Including FT Mobility Domain IE (length 5) in
  reassociation assoc Resp to mobile

*apfMsConnTask_2: Jun 27 19:29:29.870: ec:85:2f:15:39:32
  Sending Assoc Response to station on BSSID
  84:78:ac:f0:2a:94 (status 0) ApVapId 5 Slot 0

*dot1xMsgTask: Jun 27 19:29:29.874: ec:85:2f:15:39:32
  Finishing FT roaming for mobile ec:85:2f:15:39:32

캡처에 나와 있는 것처럼, Fast BSS 전환이 WLAN과의 초기 연결 시 협상되면 로밍에 사용되는 4개의 프레임(클라이언트에서 열린 시스템 인증, AP에서 열린 시스템 인증, 재연결 요청 및 재연결 응답)이 기본적으로 새 PTK(유니캐스트 암호화 키) 및 GTK(멀티캐스트/브로드캐스트 암호화 키)를 파생하기 위해 FT 4-Way 핸드셰이크로 사용됩니다.

이러한 프레임은 일반적으로 교환된 후 발생하는 4방향 핸드셰이크를 대체합니다. 이러한 프레임의 FT 콘텐츠 및 키 협상은 기본적으로 보안 방법으로 802.1X/EAP 또는 PSK를 사용하든 동일합니다.캡처에서 볼 수 있듯이 AKM 필드는 클라이언트가 PSK 또는 802.1X로 FT를 수행하는지 확인하는 주요 차이점입니다.따라서 이러한 4개 프레임에는 일반적으로 키 협상을 위한 이러한 유형의 보안 정보가 없지만, 802.11r이 구현되고 초기 연결 시 클라이언트와 WLAN 인프라 간에 협상된 경우 클라이언트 FT가 로밍할 때만 이 유형의 보안 정보를 가지고 있다는 점에 유의해야 합니다.

Fast BSS Transition Over-the-DS

802.11r을 사용하면 Fast BSS Transition을 다른 방식으로 구현할 수 있습니다. 이 경우 클라이언트가 Over-the-DS(Distribution System)가 아닌 Over-the-DS(Distribution System)를 로밍하는 새 AP를 통해 FT 로밍이 시작됩니다.이 경우 열린 시스템 인증 프레임 대신 키 협상을 시작하는 데 FT 작업 프레임이 사용됩니다.

기본적으로 클라이언트가 더 나은 AP로 로밍할 수 있다고 판단하면 클라이언트는 로밍하기 전에 현재 연결되어 있는 원래 AP에 FT 작업 요청 프레임을 보냅니다.클라이언트는 FT 로밍을 원하는 대상 AP의 BSSID(MAC 주소)를 나타냅니다.원래 AP는 이 FT 작업 요청 프레임을 배포 시스템(일반적으로 유선 인프라)을 통해 대상 AP로 전달하며, 대상 AP는 FT 작업 응답 프레임(DS를 통해서도)을 사용하여 클라이언트에 응답합니다. 따라서 최종 AP는 IP 작업 응답 프레임을 통해 클라이언트에 응답합니다. 이 FT 작업 프레임 교환이 성공하면 클라이언트는 FT 로밍을 완료합니다.클라이언트는 재연결 요청을 대상 AP에(이번에는 공중을 통해) 보내고 새 AP로부터 재연결 응답을 수신하여 로밍 및 최종 키 파생을 확인합니다.

요약하면, Fast BSS 전환을 협상하고 새 암호화 키를 파생시키는 네 개의 프레임이 있지만, 여기에서 Open System 인증 프레임은 현재 AP와 배포 시스템을 통해 대상 AP와 교환되는 FT 작업 요청/응답 프레임으로 대체됩니다.이 방법은 Cisco Wireless LAN Controller에서 모두 지원하는 보안 방법 802.1X/EAP 및 PSK에도 모두 유효합니다.그러나 이 Over-the-DS 전환은 WiFi 업계의 대부분의 무선 클라이언트에서 지원 및 구현되지 않으므로(프레임 교환 및 디버그 출력은 기본적으로 동일함), 이 문서에서는 예제가 제공되지 않습니다.대신 이 이미지를 사용하여 DS를 통한 고속 BSS 전환을 시각화합니다.

802.11r을 사용한 FlexConnect

중앙 인증이 지원됩니다.여기에는 로컬 및 중앙 데이터 스위칭이 포함됩니다.AP는 동일한 FlexConnect 그룹에 속해야 합니다.
로컬 인증은 지원되지 않습니다.
독립형 모드는 지원되지 않습니다.

802.11r의 장점

이 방법은 802.11 표준에서 IEEE가 802.11r로 명확하게 정의한 키 계층을 수정(802.11r)으로 사용하는 첫 번째 방법이므로 이러한 FT 기법의 구현은 공급업체 간에 더 호환되며 다른 해석도 없습니다.
802.11r은 사용자의 필요에 따라 유용한 여러 기술을 허용합니다(802.1x/EAP 보안 및 PSK 보안).
무선 클라이언트는 동일한 WLAN/SSID의 새 AP에 대해 빠른 보안 로밍을 수행합니다. 이 AP와 연결되지 않은 경우에도 여러 PMKID를 저장할 필요가 없습니다.
이것은 PSK 보안에서도 더 빠른 로밍을 허용하고 WPA/WPA2 PSK를 사용하여 AP 간에 로밍할 때 필요한 4방향 핸드셰이크를 방지하는 최초의 빠른 보안 로밍 방법입니다.빠른 보안 로밍 방법의 주요 목적은 이 보안 방법이 구현될 때 802.1X/EAP 핸드셰이크를 피하는 것입니다.그러나 PSK 보안의 경우, 4-Way 핸드셰이크를 피하여 802.11r로 로밍 이벤트가 훨씬 더 빨라집니다.

802.11r과 단점

Fast BSS 전환을 실제로 지원하는 몇 가지 무선 클라이언트 디바이스가 있으며, 대부분의 경우 802.11r에서 제공되는 모든 기술을 지원하지 않습니다.
이러한 구현이 매우 어려기 때문에 실제 생산 환경에서 얻은 테스트 결과가 충분하지 않거나 디버그 결과가 부족하여 발생할 수 있는 위험을 해결할 수 없습니다.
FT 방법을 사용하도록 WLAN/SSID를 구성할 때 802.11r을 지원하는 무선 클라이언트만 이 WLAN/SSID에 연결할 수 있습니다.FT 설정은 클라이언트에 대해 선택 사항이 아니므로 802.11r을 지원하지 않는 무선 클라이언트는 FT가 전혀 구성되지 않은 별도의 WLAN/SSID에 연결해야 합니다.

적응형 802.11r

일부 레거시 클라이언트는 "혼합 모드"에도 802.11r이 활성화된 WLAN/SSID와 연결할 수 없습니다(802.11r을 지원하지 않는 동일한 SSID 클라이언트에 이(가) 사용 가능하기를 바랍니다). 이는 RSN IE(Strong Security Network Information Element)를 구문 분석하는 클라이언트 신청자의 드라이버가 오래되었으며 IE의 추가 AKM 제품군을 인식하지 못하는 경우입니다.이러한 제한 때문에 클라이언트가 802.11r 지원을 광고하는 WLAN에 연결 요청을 보낼 수 없으므로 802.11r 클라이언트에 대해 하나의 WLAN/SSID를 구성하고 802.11r을 지원하지 않는 클라이언트에 대해서는 별도의 WLAN/SSID를 구성해야 할 수 있습니다.
이를 극복하기 위해 Cisco Wireless LAN Infrastructure는 Adaptive 802.11r 기능을 도입했습니다.WLAN 레벨에서 FT 모드가 Adaptive로 설정된 경우 WLAN은 802.11i 지원 WLAN에서 802.11r 모빌리티 도메인 ID를 알립니다.일부 Apple iOS10 클라이언트 장치는 80211i/WPA2 WLAN에 MDIE가 있는지 확인하고 802.11r 연결을 설정하기 위해 전용 핸드셰이크를 수행합니다.클라이언트가 성공적으로 802.11r 연결을 완료하면 일반 802.11r 지원 WLAN과 마찬가지로 FT 로밍을 수행할 수 있습니다.FT Adaptive는 선택한 Apple iOS10 이상 장치에만 적용됩니다.다른 모든 클라이언트는 WLAN에서 802.11i/WPA2 연결을 계속 유지하고 지원되는 대로 해당 FSR 방법을 수행합니다.
802.11r이 제대로 활성화되지 않은 WLAN/SSID에서 802.11r을 수행하기 위해 iOS10 디바이스에 도입된 이 새로운 기능에 대한 자세한 설명서는 Cisco Wireless LAN의 iOS 장치에 대한 엔터프라이즈 모범 사례에서 확인할 수 있습니다.

결론

클라이언트는 항상 특정 AP로 로밍하기로 결정하며, WLC/AP는 클라이언트에 대해 이를 결정할 수 없습니다.로밍 이벤트는 로밍해야 한다고 간주되면 무선 클라이언트에서 시작됩니다.
WLC는 동일한 WLAN/SSID에서 대부분의 또는 모든 FSR(Fast-Secure Roaming) 방법을 함께 지원합니다.그러나 WLC가 어떤 WLC가 지원 대상으로 광고를 시도하는지 지원하거나 이해하려는 경우 클라이언트 동작(서로 다른 모바일 디바이스 간에 매우 다름)에 따라 달라지므로 이 기능은 정상적으로 작동하지 않습니다.하나의 SSID에서 상호운용성을 달성하는 대신 일반적으로 해결해야 할 문제보다 더 많은 문제가 있으므로 이는 권장되지 않습니다.이 WLAN에서 사용할 수 있는 모든 클라이언트에 대한 심층 테스트를 수행해야 하는 경우 이 작업을 완료해야 합니다.
WLAN/SSID에 보안이 설정된 경우 AP 간에 이동할 때 WLAN 로밍 프로세스를 가속화하기 위해 빠른 보안 로밍 방법을 개발하는 것을 이해하는 것이 중요합니다.보안이 설정되지 않은 경우, 클라이언트-AP는 데이터 프레임을 전송하기 전에 AP 간에 로밍할 때 항상 필요한 무선 관리 프레임을 교환하므로 가속화할 필요가 없습니다(클라이언트에서 시스템 인증 열기, AP에서 시스템 인증 열기, AP에서 재연결 요청 및 재연결 응답). 따라서 더 빨리 움직일 수는 없습니다.보안 없이 로밍 문제가 발생하는 경우, 로밍 개선을 위한 빠른 로밍 방법이 없는 경우, WLAN/SSID 설정 및 설계가 AP 커버리지 셀 간에 로밍하는 무선 클라이언트 스테이션에 적합한지 확인하는 방법만 가능합니다.
802.11r/FT는 802.11r 섹션에 설명된 대로 4방향 핸드셰이크를 피하여 이 보안으로 로밍 이벤트를 가속화하기 위해 WPA2-PSK와 함께 구현됩니다.
모든 방법에는 장점과 단점이 있지만, 결국 무선 클라이언트 스테이션에서 구현할 특정 방법을 지원하는지, Cisco WLAN 인프라가 사용 가능한 모든 방법을 지원하는지 확인해야 합니다.따라서 특정 WLAN/SSID에 연결하는 무선 클라이언트가 실제로 지원하는 최상의 방법을 선택해야 합니다.예를 들어, 일부 구축에서는 Cisco 무선 IP Phone용 CCKM을 사용하여 WLAN/SSID를 생성하고(CCKM의 WPA2/AES를 지원하지만 802.11r은 지원하지 않음), 802.11r/AES를 지원하는 무선 클라이언트에 대해 802.11r/FT를 사용하여 WLAN/SSID를 만들 수 있습니다(또는 OK가 PC를 사용하는 경우). 지원).
무선 클라이언트가 사용 가능한 빠른 보안 로밍 방법을 지원하지 않는 경우, 802.1X/EAP 보안을 사용하는 WLAN/SSID의 AP 간에 로밍 시 해당 클라이언트가 항상 이 문서에 설명된 지연을 실험한다는 사실을 받아들여야 합니다(클라이언트 앱/서비스에 지장을 줄 수 있음).
SKC(WPA2 PMKID 캐싱)를 제외한 모든 방법은 서로 다른 WLC에서 관리하는 AP(인터컨트롤러 로밍) 간 빠른 보안 로밍(동일한 모빌리티 그룹에 있는 경우)에 지원됩니다.
CUWN은 WPA/WPA2에 802.1X/EAP 인증을 사용할 때 이 문서에서 다루는 모든 다양한 고속 보안 로밍 방법을 완벽하게 지원합니다. CUWN은 PSK(PSK2-Fast Personal)를 사용할 때 WPA2-RSN(CCKM, PMKID Caching/SKC, OKC/PKC)와 함께 작동하는 방식에서는 빠른 보안 로밍 기능을 지원하지 않습니다. 로밍 방법은 대부분 필요하지 않습니다.그러나 이 문서에서 설명한 대로 PSK를 사용하는 WPA2-FT(802.11r)의 경우 CUWN은 빠른 보안 로밍을 지원합니다.