Methoden für 802.11-WLAN und Fast-Secure Roaming auf dem CUWN ermitteln
Inhalt
Einleitung
In diesem Dokument werden die Wireless-Roaming-Typen und die schnellsicheren Roaming-Typen beschrieben, die für IEEE 802.11 Wireless LANs (WLANs) im Unified Wireless Network (CUWN) verfügbar sind.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- IEEE 802.11 WLAN-Grundlagen
- IEEE 802.11: WLAN-Sicherheit
- IEEE 802.1x/EAP - Grundlagen
Verwendete Komponenten
Die in diesem Dokument enthaltenen Informationen basieren auf der Cisco WLAN Controller-Software Version 7.4.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
Die Informationen in diesem Dokument basieren auf der Cisco WLAN Controller Software Version 7.4. Die meisten der beschriebenen Debug-Ausgaben und -Verhaltensweisen können jedoch auf jede Softwareversion angewendet werden, die die beschriebenen Methoden unterstützt. Die Details aller hier beschriebenen Methoden bleiben auf späteren Cisco WLAN Controller-Codes gleich (bis zur Version 8.3 bis zum Zeitpunkt der Aktualisierung dieses Artikels).
In diesem Dokument werden die verschiedenen Wireless-Roaming- und Fast-Secure-Roaming-Methoden beschrieben, die für IEEE 802.11 Wireless LANs (WLANs) verfügbar sind, die vom Cisco Unified Wireless Network (CUWN) unterstützt werden.
Das Dokument enthält nicht alle Details zur Funktionsweise der einzelnen Methoden oder zu ihrer Konfiguration. Der Hauptzweck dieses Dokuments besteht darin, die Unterschiede zwischen den verschiedenen verfügbaren Techniken, ihre Vorteile und Einschränkungen sowie den Austausch von Frames für jede Methode zu beschreiben. Es werden Beispiele für WLAN Controller (WLC)-Fehlerbehebungen bereitgestellt, und Wireless-Paket-Images werden verwendet, um die Ereignisse zu analysieren und zu erläutern, die bei den einzelnen beschriebenen Roaming-Methoden auftreten.
Bevor eine Beschreibung der verschiedenen für WLANs verfügbaren schnellsicheren Roaming-Methoden gegeben wird, ist es wichtig zu verstehen, wie der WLAN-Zuordnungsprozess funktioniert und wie ein reguläres Roaming-Ereignis auftritt, wenn für den Service Set Identifier (SSID) keine Sicherheit konfiguriert ist.
Wenn ein 802.11-Wireless-Client eine Verbindung zu einem Access Point (AP) herstellt, muss er zunächst den grundlegenden 802.11-Authentifizierungsprozess des offenen Systems durchlaufen, bevor er Datenverkehr (Wireless-Datenframes) weiterleitet. Dann muss der Zuordnungsprozess abgeschlossen sein. Der Open System-Authentifizierungsprozess ähnelt einer Kabelverbindung am AP, die der Client auswählt. Dies ist ein sehr wichtiger Punkt, da immer der Wireless-Client den bevorzugten Access Point auswählt und die Entscheidung auf unterschiedliche Faktoren stützt, die von Anbieter zu Anbieter variieren. Aus diesem Grund beginnt der Client diesen Prozess, indem er den Authentifizierungsrahmen an den ausgewählten Access Point sendet, wie weiter unten in diesem Dokument gezeigt. Der Access Point kann nicht verlangen, dass Sie eine Verbindung herstellen.
Sobald der Authentifizierungsprozess des offenen Systems erfolgreich mit einer Antwort des Access Points abgeschlossen wurde ("über Kabel verbunden"), schließt der Zuordnungsprozess im Wesentlichen die 802.11 Layer 2 (L2)-Aushandlung ab, die die Verbindung zwischen dem Client und dem Access Point herstellt. Der WAP weist dem Client bei erfolgreicher Verbindung eine Zuordnungs-ID zu und bereitet diese vor, um Datenverkehr weiterzuleiten oder eine übergeordnete Sicherheitsmethode auszuführen, falls diese für die SSID konfiguriert wurde. Der Authentifizierungsprozess des offenen Systems besteht aus zwei Management-Frames sowie dem Assoziierungsprozess. Authentifizierungs- und Zuordnungs-Frames sind Wireless-Management-Frames, keine Daten-Frames, die im Wesentlichen für den Verbindungsprozess mit dem Access Point verwendet werden.
Hier ist ein Bild der drahtlosen Frames über die Luft für diesen Prozess:
Der Wireless-Client beginnt mit dem Authentifizierungsframe, und der WAP antwortet mit einem weiteren Authentifizierungsframe. Der Client sendet dann den Zuordnungsanforderungsrahmen, und der Zugangspunkt wird in einer Antwort mit dem Zuordnungsanantwortrahmen beendet. Wie aus den DHCP-Paketen ersichtlich, beginnt der Client nach der Übergabe der 802.11 Open System-Authentifizierungs- und -Zuordnungsprozesse, Daten-Frames zu übergeben. In diesem Fall ist keine Sicherheitsmethode auf der SSID konfiguriert, sodass der Client sofort beginnt, nicht verschlüsselte Datenframes (in diesem Fall DHCP) zu senden.
Wenn die Sicherheit auf der SSID aktiviert ist, werden, wie weiter unten in diesem Dokument gezeigt, für die spezifische Sicherheitsmethode Authentifizierungs- und Verschlüsselungs-Handshake-Frames auf höherer Ebene bereitgestellt, unmittelbar nach der Zuordnungsantwort und vor dem Senden von Client-Datenverkehr-Frames, wie DHCP, Address Resolution Protocol (ARP) und verschlüsselte Anwendungspakete. Daten-Frames können nur gesendet werden, bis der Client vollständig authentifiziert ist und die Verschlüsselungsschlüssel entsprechend der konfigurierten Sicherheitsmethode ausgehandelt wurden.
Basierend auf dem vorherigen Bild sind hier die Meldungen aufgeführt, die Sie in den Ausgaben des WLC-Debug-Client-Befehls sehen, wenn der Wireless-Client eine neue Verbindung zum WLAN beginnt:
*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.
Diese Meldungen zeigen die Zuordnungsanforderung und Antwort-Frames an. Die anfänglichen Authentifizierungs-Frames werden nicht am WLC protokolliert, da dieser Handshake schnell auf AP-Ebene im CUWN stattfindet.
Welche Informationen werden beim Roaming des Clients angezeigt? Der Client tauscht beim Herstellen einer Verbindung zu einem AP immer vier Management-Frames aus, was entweder auf den Client-Aufbau einer Verbindung oder auf ein Roaming-Ereignis zurückzuführen ist. Der Client hat jeweils nur eine Verbindung mit nur einem WAP hergestellt. Der einzige Unterschied beim Frame-Austausch zwischen einer neuen Verbindung zur WLAN-Infrastruktur und einem Roaming-Ereignis besteht darin, dass die Zuordnungs-Frames eines Roaming-Ereignisses Reassoziations-Frames genannt werden, die anzeigen, dass der Client tatsächlich von einem anderen WAP Roaming durchführt, ohne dass versucht wird, eine neue Verbindung zum WLAN herzustellen. Diese Frames können verschiedene Elemente enthalten, die zum Aushandeln des Roaming-Ereignisses verwendet werden. Dies hängt von der Konfiguration ab, diese Details werden jedoch nicht in diesem Dokument behandelt.
Hier ein Beispiel für den Frame-Austausch:
Diese Meldungen werden in der Debug-Ausgabe angezeigt:
*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.
Wie dargestellt, führt der Client erfolgreich ein Roaming-Ereignis aus, nachdem die Neuzuordnungsanforderung an den neuen WAP gesendet wurde, und empfängt die Neuzuordnungsanwort vom WAP. Da der Client bereits über eine IP-Adresse verfügt, sind die ersten Daten-Frames für ARP-Pakete.
Wenn Sie ein Roaming-Ereignis erwarten, aber der Client eine Zuordnungsanforderung anstelle einer Neuzuordnungsanforderung sendet (die Sie anhand einiger Bilder und Debugs bestätigen können, die den zuvor in diesem Dokument beschriebenen ähneln), dann ist der Client kein wirkliches Roaming. Der Client beginnt eine neue Verbindung mit dem WLAN, als ob eine Trennung stattgefunden hätte, und versucht, die Verbindung von Grund auf wiederherzustellen. Dies kann aus mehreren Gründen geschehen, z. B. wenn ein Client sich von den Abdeckungsbereichen entfernt und dann einen Access Point mit ausreichender Signalqualität findet, um eine Verbindung herzustellen. Normalerweise weist dies jedoch auf ein Client-Problem hin, bei dem der Client aufgrund von Treibern, Firmware oder Softwareproblemen kein Roaming-Ereignis initiiert.
Roaming mit umfassender Sicherheit
Wenn die SSID zusätzlich zur grundlegenden 802.11-Authentifizierung des offenen Systems mit L2-Sicherheit konfiguriert wird, sind für die ursprüngliche Zuordnung und beim Roaming mehr Frames erforderlich. Die beiden gebräuchlichsten Sicherheitsmethoden, die für 802.11-WLANs standardisiert und implementiert werden, werden in diesem Dokument beschrieben:
- WPA/WPA2-PSK (Pre-Shared Key) - Authentifizierung von Clients mit einem Preshared Key.
- WPA/WPA2-EAP (Extensible Authentication Protocol) - Authentifizierung von Clients mit einer 802.1X/EAP-Methode, um sicherere Anmeldeinformationen durch die Verwendung eines Authentifizierungsservers wie Zertifikate, Benutzername und Kennwort und Token zu validieren.
Es ist wichtig zu wissen, dass diese beiden Methoden (PSK und EAP) die Clients zwar auf unterschiedliche Weise authentifizieren/validieren, aber beide im Wesentlichen die gleichen WPA/WPA2-Regeln für den Schlüsselverwaltungsprozess verwenden. Unabhängig davon, ob es sich um WPA/WPA2-PSK oder WPA/WPA2-EAP handelt, beginnt der als WPA/WPA2-4-Way-Handshake bekannte Prozess die Schlüsselverhandlung zwischen dem WLC/AP und dem Client mit einem Master Session Key (MSK) als ursprünglichem Schlüsselmaterial, sobald der Client mit der spezifischen verwendeten Authentifizierungsmethode validiert wurde.
Im Folgenden finden Sie eine Zusammenfassung des Prozesses:
- Ein MSK wird aus der EAP-Authentifizierungsphase abgeleitet, wenn 802.1X/EAP-Sicherheit verwendet wird, oder aus dem PSK, wenn WPA/WPA2-PSK als Sicherheitsmethode verwendet wird.
- Von diesem MSK leiten der Client und WLC/AP den Pairwise Master Key (PMK) ab, und der WLC/AP generiert einen Group Master Key (GMK).
- Sobald diese beiden Hauptschlüssel bereit sind, initiieren der Client und der WLC/AP den 4-Wege-Handshake von WPA/WPA2 (der später in diesem Dokument mit einigen Screenshots und Debugs veranschaulicht wird) mit den Hauptschlüsseln als Grundlage für die Aushandlung der eigentlichen Verschlüsselungsschlüssel.
- Diese endgültigen Verschlüsselungsschlüssel werden als Pairwise Transient Key (PTK) und Group Transient Key (GTK) bezeichnet. Die PTK wird aus der PMK abgeleitet und zur Verschlüsselung von Unicast-Frames mit dem Client verwendet. Der Group Transient Key (GTK) wird aus dem GMK abgeleitet und zur Verschlüsselung von Multicast/Broadcast für diese spezifische SSID/diesen AP verwendet.
WPA/WPA2-PSK
Wenn WPA-PSK oder WPA2-PSK über TKIP (Temporal Key Integrity Protocol) oder AES (Advanced Encryption Standard) für die Verschlüsselung ausgeführt wird, muss der Client den als WPA 4-Way Handshake bekannten Prozess sowohl für die ursprüngliche Zuordnung als auch beim Roaming durchlaufen. Wie zuvor erläutert, ist dies im Wesentlichen der Schlüsselverwaltungsprozess, der verwendet wird, damit WPA/WPA2 die Verschlüsselungsschlüssel ableiten kann. Wenn jedoch PSK ausgeführt wird, wird es auch verwendet, um zu überprüfen, ob der Client über einen gültigen vorinstallierten Schlüssel verfügt, um dem WLAN beizutreten. Dieses Bild zeigt den anfänglichen Zuordnungsprozess, wenn WPA oder WPA2 mit PSK ausgeführt wird:
Wie gezeigt, gibt es nach dem 802.11 Open System Authentifizierungs- und Zuordnungsprozess vier EAPOL-Frames vom 4-Wege-WPA-Handshake, die vom WAP mit message-1 initiiert und vom Client mit message-4 beendet werden. Nach einem erfolgreichen Handshake beginnt der Client, Datenframes (wie DHCP) zu übergeben, die in diesem Fall mit den vom 4-Wege-Handshake abgeleiteten Schlüsseln verschlüsselt werden (deshalb können Sie den tatsächlichen Inhalt und die Art des Verkehrs von den Wireless-Bildern nicht sehen).
Diese Meldungen werden in den Debug-Ausgaben angezeigt:
*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.
Beim Roaming verfolgt der Client im Grunde den gleichen Frame Exchange, bei dem der WPA 4-Wege Handshake erforderlich ist, um neue Verschlüsselungsschlüssel mit dem neuen AP abzuleiten. Dies liegt an den vom Standard festgelegten Sicherheitsgründen und daran, dass der neue Access Point die ursprünglichen Schlüssel nicht kennt. Der einzige Unterschied besteht darin, dass anstelle von Zuordnungsrahmen Neuzuordnungsrahmen vorhanden sind, wie in diesem Bild gezeigt:
Sie sehen die gleichen Meldungen in den Debug-Ausgaben, aber das erste Paket vom Client ist eine Neuzuordnung anstelle einer Zuordnung, wie zuvor gezeigt und erläutert.
WPA/WPA2-EAP
Wenn eine 802.1X/EAP-Methode verwendet wird, um die Clients auf einer sicheren SSID zu authentifizieren, sind noch mehr Frames erforderlich, bevor der Client beginnt, Datenverkehr zu übertragen. Diese zusätzlichen Frames werden zur Authentifizierung der Client-Anmeldeinformationen verwendet. Je nach EAP-Methode können zwischen vier und zwanzig Frames liegen. Diese kommen nach der Zuordnung/Neuzuordnung, aber vor dem 4-Wege-Handshake von WPA/WPA2, da die Authentifizierungsphase das MSK ableitet, das als Seed für die endgültige Verschlüsselungsschlüsselgenerierung im Schlüsselverwaltungsprozess verwendet wird (4-Wege-Handshake).
Dieses Bild zeigt ein Beispiel für die Frames, die bei der anfänglichen Zuordnung zwischen dem Access Point und dem Wireless-Client per Funk ausgetauscht werden, wenn WPA mit PEAPv0/EAP-MSCHAPv2 ausgeführt wird:
Manchmal zeigt dieser Austausch mehr oder weniger Frames, was von mehreren Faktoren abhängt, wie der EAP-Methode, Neuübertragungen aufgrund von Problemen, Client-Verhalten (wie die beiden Identitätsanforderungen in diesem Beispiel, weil der Client einen EAPOL START sendet, nachdem der WAP die erste Identitätsanforderung sendet), oder wenn der Client das Zertifikat bereits mit dem Server ausgetauscht hat. Wenn die SSID für eine 802.1X/EAP-Methode konfiguriert wird, gibt es mehr Frames (für die Authentifizierung), und daher dauert es länger, bis der Client beginnt, Datenframes zu senden.
Hier eine Zusammenfassung der Debug-Meldungen:
*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.
Wenn der Wireless-Client hier ein reguläres Roaming durchführt (das normale Verhalten, ohne dass eine schnelle Roaming-Methode implementiert wird), muss der Client den gleichen Prozess durchlaufen und eine vollständige Authentifizierung gegenüber dem Authentifizierungsserver durchführen, wie in den Bildern gezeigt. Der einzige Unterschied besteht darin, dass der Client eine Neuzuordnungsanforderung verwendet, um den neuen WAP darüber zu informieren, dass er tatsächlich von einem anderen WAP aus Roaming nutzt. Der Client muss jedoch noch eine vollständige Validierung und die Generierung eines neuen Schlüssels durchlaufen:
Wie gezeigt, müssen auch bei weniger Frames als bei der ursprünglichen Authentifizierung (die durch mehrere Faktoren verursacht wird, wie bereits erwähnt), wenn der Client zu einem neuen AP roamt, die EAP-Authentifizierung und die WPA-Schlüsselverwaltungsprozesse noch abgeschlossen sein, um weiterhin Datenframes weiterzuleiten (auch wenn der Datenverkehr vor dem Roaming aktiv gesendet wurde). Wenn der Client daher über eine aktive Anwendung verfügt, die empfindlich auf Verzögerungen reagiert (z. B. Anwendungen für Sprachdatenverkehr oder Anwendungen, die empfindlich auf Zeitüberschreitungen reagieren), kann der Benutzer Probleme beim Roaming erkennen, z. B. Audiolücken oder Anwendungsunterbrechungen. Dies hängt davon ab, wie lange der Prozess dauert, bis der Client weiterhin Datenframes sendet/empfängt. Diese Verzögerung kann länger sein und hängt von der Funkumgebung, der Anzahl der Clients, der Round-Trip-Zeit zwischen dem WLC und den LAPs sowie mit dem Authentifizierungsserver und anderen Gründen ab.
Im Folgenden finden Sie eine Zusammenfassung der Debug-Meldungen für dieses Roaming-Ereignis (im Wesentlichen identisch mit den vorherigen Meldungen, sodass diese nicht weiter beschrieben werden):
*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 intoConnectingstate
*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
So funktionieren 802.1X/EAP und das WPA/WPA2-Sicherheits-Framework. Um die Auswirkungen von Anwendungen/Diensten auf Verzögerungen durch ein reguläres Roaming-Ereignis zu vermeiden, werden von der WiFi-Branche mehrere schnellsichere Roaming-Methoden entwickelt und implementiert, um den Roaming-Prozess zu beschleunigen, wenn auf dem WLAN/SSID Sicherheit verwendet wird. Die Clients müssen mit einer gewissen Latenz rechnen, wenn sie beim Roaming zwischen den APs weiterhin Datenverkehr weiterleiten, indem sie im WLAN ein hohes Maß an Sicherheit implementieren. Dies ist auf die EAP-Authentifizierung und den Schlüsselmanagement-Frame-Austausch zurückzuführen, die für die Sicherheitseinrichtung erforderlich sind, wie zuvor erläutert.
Es ist wichtig zu verstehen, dass schnelles sicheres Roaming nur der Begriff ist, der von der Branche für die Implementierung einer Methode/eines Schemas verwendet wird, die/das den Roaming-Prozess beschleunigt, wenn die Sicherheit im WLAN konfiguriert ist. Im nächsten Abschnitt werden die verschiedenen, für WLANs verfügbaren und vom CUWN unterstützten Methoden und Schemata für schnelles und sicheres Roaming erläutert.
Schnelles und sicheres Roaming mit CCKM
Cisco Centralized Key Management (CCKM) ist die erste schnelle und sichere Roaming-Methode, die in Unternehmens-WLANs entwickelt und implementiert wurde. Sie wurde von Cisco als Lösung entwickelt, um die bislang erläuterten Verzögerungen zu reduzieren, wenn 802.1X/EAP-Sicherheit im WLAN verwendet wird. Da es sich um ein proprietäres Protokoll von Cisco handelt, wird es nur von Cisco WLAN-Infrastrukturgeräten und Wireless-Clients (von verschiedenen Anbietern) unterstützt, die mit Cisco Compatible Extension (CCX) kompatibel für CCKM sind.
CCKM kann mit allen verfügbaren Verschlüsselungsmethoden für WLANs implementiert werden, darunter WEP, TKIP und AES. Sie wird auch von den meisten für WLANs verwendeten 802.1X/EAP-Authentifizierungsmethoden unterstützt, je nach der von den Geräten unterstützten CCX-Version.
Dieses Wireless-Image bietet ein Beispiel für die Frames, die bei der ersten Zuordnung ausgetauscht werden, wenn Sie CCKM mit TKIP als Verschlüsselung und PEAPv0/EAP-MSCHAPv2 als 802.1X/EAP-Methode durchführen. Dies ist im Wesentlichen der gleiche Austausch, als ob WPA/TKIP mit PEAPv0/EAP-MSCHAPv2 ausgeführt wird, aber diesmal wird CCKM zwischen dem Client und der Infrastruktur ausgehandelt, sodass sie unterschiedliche Schlüsselhierarchie- und Cache-Methoden verwenden, um Fast Secure Roaming auszuführen, wenn der Client Roaming ausführen muss:
Hier eine Zusammenfassung der Debug-Meldungen (mit einigen EAP-Austauschen entfernt, um die Ausgabe zu reduzieren):
*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.
Bei CCKM ähnelt die anfängliche Zuordnung zum WLAN der regulären WPA/WPA2, bei der ein MSK (auch als Network Session Key (NSK) bezeichnet) gemeinsam mit dem Client und dem RADIUS-Server abgeleitet wird. Dieser Primärschlüssel wird nach erfolgreicher Authentifizierung vom Server an den WLC gesendet und als Grundlage für die Ableitung aller nachfolgenden Schlüssel für die Lebensdauer der Client-Verknüpfung mit diesem WLAN zwischengespeichert. Von hier aus leiten der WLC und der Client die Seed-Informationen ab, die für ein schnelles und sicheres Roaming auf der Basis von CCKM verwendet werden. Dies erfolgt ähnlich wie bei WPA/WPA2 über einen 4-Wege-Handshake, um die Unicast- (PTK) und Multicast-/Broadcast- (GTK) Verschlüsselungsschlüssel mit dem ersten AP abzuleiten.
Der große Unterschied wird beim Roaming bemerkt. In diesem Fall sendet der CCKM-Client einen einzelnen Frame für eine Neuzuordnungsanforderung an den AP/WLC (der ein MIC und eine sequenziell inkrementierende Zufallszahl enthält) und stellt genügend Informationen bereit (einschließlich der neuen AP-MAC-Adresse -BSSID-), um die neue PTK abzuleiten. Mit dieser Reassoziationsanforderung verfügen der WLC und der neue AP auch über genügend Informationen, um die neue PTK abzuleiten, sodass sie einfach mit einer Reassoziationsantwort antworten. Der Client kann nun weiterhin Datenverkehr weiterleiten, wie in diesem Bild gezeigt:
Nachfolgend finden Sie eine Zusammenfassung der WLC-Fehlerbehebungen für dieses Roaming-Ereignis:
*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.
Wie gezeigt, wird schnelles sicheres Roaming durchgeführt, während die EAP-Authentifizierungs-Frames vermieden werden und noch mehr 4-Wege-Handshakes, da die neuen Verschlüsselungsschlüssel immer noch abgeleitet werden, aber auf dem CCKM-Verhandlungsschema basieren. Dies wird durch die Roaming-Reassoziations-Frames und die zuvor vom Client und vom WLC zwischengespeicherten Informationen ergänzt.
FlexConnect mit CCKM
- Die zentrale Authentifizierung wird unterstützt. Dies umfasst das lokale und zentrale Daten-Switching. Die APs müssen Teil derselben FlexConnect-Gruppe sein.
- Flex Local Authentication wird unterstützt. Im verbundenen Modus kann der Cache vom Access Point zum Controller und dann zu den übrigen Access Points der FlexConnect-Gruppe verteilt werden.
- Der Standalone-Modus wird unterstützt. Wenn der Cache (aufgrund vorheriger Verteilung) bereits auf dem Access Point vorhanden ist, wird schnelles Roaming funktionieren. Die neue Authentifizierung im Standalone-Modus unterstützt kein schnelles sicheres Roaming.
Vorteile mit CCKM
- CCKM ist die schnellste und sicherste Roaming-Methode, die hauptsächlich in Unternehmens-WLANs eingesetzt wird. Clients müssen bei einem Wechsel zwischen den APs keinen Schlüsselmanagement-Handshake überspringen, um neue Schlüssel abzuleiten. Sie müssen während der Client-Lebensdauer in diesem WLAN nie wieder eine vollständige 802.1X/EAP-Authentifizierung mit neuen APs durchführen.
- CCKM unterstützt alle im 802.11-Standard verfügbaren Verschlüsselungsmethoden (WEP, TKIP und AES), zusätzlich zu einigen proprietären, von Cisco noch auf Legacy-Clients verwendeten Methoden.
Nachteile von CCKM
- CCKM ist eine proprietäre Methode von Cisco, die die Implementierung und den Support auf die Cisco WLAN-Infrastruktur und CCX Wireless Clients beschränkt.
- CCX-Version 5 wird nur in geringem Umfang eingesetzt, daher wird CCKM mit WPA2/AES von vielen CCX-Wireless-Clients nicht unterstützt (vor allem, weil die meisten von ihnen bereits CCKM mit WPA/TKIP unterstützen, was immer noch sehr sicher ist).
Schnelles und sicheres Roaming mit PMKID-Caching/Sticky Key-Caching
Pairwise betrachtet das PMKID-Caching (Key ID Caching) oder Sticky Key Caching (SKC) als die erste vom IEEE 802.11-Standard vorgeschlagene schnellsichere Roaming-Methode im Rahmen der 802.11i-Sicherheitsänderung, deren Hauptzweck die Standardisierung eines hohen Sicherheitsniveaus für WLANs ist. Diese Technik für schnelles und sicheres Roaming wurde als optionale Methode für WPA2-Geräte hinzugefügt, um das Roaming zu verbessern, als diese Sicherheit implementiert wurde.
Dies ist möglich, da Client und Authentifizierungsserver jedes Mal, wenn ein Client vollständig EAP-authentifiziert ist, ein MSK ableiten, das zur Ableitung des PMK verwendet wird. Dieser wird als Seed für den 4-Wege-WPA2-Handshake verwendet, um den endgültigen Unicast-Verschlüsselungsschlüssel (PTK) abzuleiten, der für die Sitzung verwendet wird (bis der Client zu einem anderen WAP wechselt oder die Sitzung abläuft). Daher verhindert diese Methode die EAP-Authentifizierungsphase beim Roaming, da sie den ursprünglichen PMK, der vom Client und dem WAP zwischengespeichert wurde, wiederverwendet. Der Client muss nur den 4-Wege-Handshake von WPA2 durchlaufen, um neue Verschlüsselungsschlüssel abzuleiten.
Diese Methode wird als die empfohlene schnelle sichere 802.11-Roaming-Standardmethode aus den folgenden Gründen nur selten eingesetzt:
- Diese Methode ist optional und wird nicht von allen WPA2-Geräten unterstützt, da der Zweck der 802.11i-Änderung nicht das schnelle sichere Roaming betrifft. Die IEEE hat bereits an einer anderen Änderung gearbeitet, um das schnelle sichere Roaming für WLANs zu standardisieren (802.11r, auf die später in diesem Dokument eingegangen wird).
- Diese Methode hat eine große Einschränkung bei ihrer Implementierung: Wireless-Clients können nur dann ein schnelles Roaming durchführen, wenn sie zu einem Access Point zurückkehren, bei dem sie sich zuvor authentifiziert/verbunden hatten.
Bei dieser Methode ist die anfängliche Zuordnung zu einem WAP wie eine reguläre Erstauthentifizierung mit dem WLAN, bei der die gesamte 802.1X/EAP-Authentifizierung gegenüber dem Authentifizierungsserver und der 4-Wege-Handshake zur Schlüsselgenerierung erfolgen muss, bevor der Client Datenframes senden kann, wie in diesem Screenimage gezeigt:
Die Debugs zeigen den gleichen EAP-Authentifizierungs-Frame-Austausch wie die anderen Methoden bei der Erstauthentifizierung im WLAN, wobei einige Ausgaben in Bezug auf die hier verwendeten Schlüssel-Caching-Techniken hinzugefügt wurden. Diese Debug-Ausgaben werden ausgeschnitten, um hauptsächlich die neuen Informationen anzuzeigen, nicht den gesamten EAP-Frame-Austausch, da im Grunde jedes Mal die gleichen Informationen zur Authentifizierung des Clients gegenüber dem Authentifizierungsserver ausgetauscht werden. Dies wird bisher gezeigt und korreliert mit den in den Paketbildern gezeigten EAP-Authentifizierungsframes, sodass die meisten EAP-Nachrichten aus Gründen der Einfachheit von den Debug-Ausgängen entfernt werden:
*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.
Bei diesem Verfahren zwischenspeichern der WAP und der WLAN-Client die PMKs der bereits aufgebauten sicheren Verknüpfungen. Wenn der Wireless-Client also zu einem neuen Access Point wechselt, mit dem er noch nie verbunden war, muss der Client erneut eine vollständige EAP-Authentifizierung durchführen, wie in diesem Bild dargestellt. Dabei wechselt der Client zu einem neuen Access Point:
Wenn der Wireless-Client jedoch zu einem Access Point zurückkehrt, an dem zuvor eine Zuordnung bzw. Authentifizierung stattgefunden hat, sendet der Client einen Frame für eine Neuzuordnungsanforderung, in dem mehrere PMKIDs aufgelistet sind. Dieser informiert den Access Point über die PMKs, die von allen Access Points, an denen der Client zuvor authentifiziert wurde, zwischengespeichert wurden. Da der Client also zu einem WAP zurückkehrt, der auch über einen PMK verfügt, der für diesen Client zwischengespeichert ist, muss der Client sich nicht erneut über EAP authentifizieren, um einen neuen PMK abzuleiten. Der Client leitet die neuen transienten Verschlüsselungsschlüssel einfach über den 4-Wege-WPA2-Handshake ab:
Im Folgenden finden Sie eine Zusammenfassung der WLC-Fehlerbehebungen für diese hochsichere Roaming-Methode:
*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
FlexConnect mit PMKID-Caching/Sticky Key-Caching
- Wenn Sie diese Methode in einer FlexConnect-Konfiguration verwenden, könnte sie funktionieren, und das Verhalten kann ähnlich wie zuvor beschrieben aussehen, wenn Sie die zentrale Authentifizierung für den WLC verwenden (entweder mit zentralem oder lokalem Switching). Diese SKC-Methode wird jedoch auf FlexConnect nicht unterstützt.
- Diese Methode wird nur offiziell auf CUWN mit APs im lokalen Modus unterstützt, nicht auf FlexConnect oder anderen Modi.
Profis mit PMKID Caching / Sticky Key Caching
Diese Methode kann lokal durch autonome unabhängige Zugangspunkte implementiert werden, ohne dass ein zentralisiertes Gerät zur Verwaltung der zwischengespeicherten Schlüssel erforderlich ist.
Nachteile mit PMKID-Zwischenspeicherung/Zwischenspeicherung von Kurztasten
- Wie bereits in diesem Dokument erwähnt, besteht die wichtigste Einschränkung dieses Verfahrens darin, dass der Client beim Roaming zu einem Access Point, dem er zuvor zugeordnet/authentifiziert wurde, nur ein schnelles Roaming durchführen kann. Wenn das Roaming zu einem neuen Access Point erfolgt, muss der Client die vollständige EAP-Authentifizierung erneut durchführen.
- Der Wireless-Client und die APs müssen sich alle PMKs merken, die bei jeder neuen Authentifizierung abgeleitet werden. Daher ist diese Funktion normalerweise auf eine bestimmte Anzahl von PMKs beschränkt, die zwischengespeichert werden. Da dieser Grenzwert im Standard nicht klar definiert ist, können die Anbieter verschiedene Grenzwerte für ihre SKC-Implementierungen definieren. Beispielsweise können die Cisco WLAN Controller derzeit die PMKs eines Clients für bis zu acht APs zwischenspeichern. Wenn ein Client zu mehr als acht APs pro Sitzung wechselt, werden die ältesten APs aus der Cache-Liste entfernt, um die neu zwischengespeicherten Einträge zu speichern.
- Diese Methode ist optional und wird von vielen WPA2-Geräten immer noch nicht unterstützt. Daher wird sie nur selten verwendet und bereitgestellt.
- SKC wird nicht unterstützt, wenn Sie das Roaming zwischen Controllern durchführen, d. h. wenn Sie zwischen APs wechseln, die von verschiedenen WLCs verwaltet werden, selbst wenn diese derselben Mobilitätsgruppe angehören.
Schnelles und sicheres Roaming mit opportunistischem Schlüssel-Caching
Opportunistic Key Caching (OKC), auch bekannt als Proactive Key Caching (PKC) (dieser Begriff wird in einem nächsten Hinweis näher erläutert), ist grundsätzlich eine Erweiterung der zuvor beschriebenen WPA2 PMKID Caching-Methode, weshalb sie auch als Proactive/Opportunistic PMKID Caching bezeichnet wird. Es ist daher wichtig zu beachten, dass es sich hierbei nicht um eine durch den 802.11-Standard definierte schnelle Roaming-Methode handelt, die von vielen Geräten nicht unterstützt wird. Wie beim PMKID-Caching funktioniert sie jedoch mit WPA2-EAP.
Diese Technik ermöglicht es dem WLAN-Client und der WLAN-Infrastruktur, nur einen PMK für die Lebensdauer der Client-Verbindung mit diesem WLAN (abgeleitet vom MSK nach der anfänglichen 802.1X/EAP-Authentifizierung mit dem Authentifizierungsserver) zwischenzuspeichern, selbst wenn das Roaming zwischen mehreren APs erfolgt, da alle den ursprünglichen PMK teilen, der als Seed für alle 4-Wege-WPA2-Handshakes verwendet wird. Dies ist weiterhin erforderlich, genau wie in SKC, um bei jeder Neuzuordnung des Clients zu den APs neue Verschlüsselungsschlüssel zu generieren. Damit die APs diesen ursprünglichen PMK aus der Client-Sitzung gemeinsam nutzen können, müssen sie alle unter einer administrativen Kontrolle stehen und über ein zentrales Gerät verfügen, das den ursprünglichen PMK zwischenspeichert und für alle APs verteilt. Dies ähnelt dem CUWN, bei dem der WLC diese Aufgabe für alle ihm unterstehenden LAPs ausführt und die Mobilitätsgruppen verwendet, um diese PMK zwischen mehreren WLCs zu verwalten. Dies stellt daher eine Beschränkung für autonome AP-Umgebungen dar.
Wie beim PMKID-Caching (SKC) ist bei dieser Methode die Erstzuordnung zu einem AP eine reguläre Erstauthentifizierung zum WLAN, bei der Sie die gesamte 802.1X/EAP-Authentifizierung gegen den Authentifizierungsserver und den 4-Wege-Handshake zur Schlüsselgenerierung abschließen müssen, bevor Sie Datenframes senden können. Das folgende Screenbild veranschaulicht dies:
Die Debug-Ausgaben zeigen im Wesentlichen den gleichen EAP-Authentifizierungs-Frame-Austausch wie die anderen in diesem Dokument beschriebenen Methoden bei der Erstauthentifizierung im WLAN (wie in den Bildern gezeigt), zusammen mit der Hinzufügung einiger Ausgaben, die die Schlüssel-Caching-Techniken betreffen, die vom WLC hier verwendet werden. Diese Debug-Ausgabe wird ebenfalls ausgeschnitten, um nur die relevanten Informationen anzuzeigen:
*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
Bei dieser Methode zwischenspeichern der Wireless-Client und der WLC (für alle verwalteten APs) den ursprünglichen PMK der ursprünglich eingerichteten sicheren Verbindung. Grundsätzlich wird bei jeder Verbindung des Wireless-Clients mit einem bestimmten WAP eine PMKID gehasht, die auf der Client-MAC-Adresse, der WAP-MAC-Adresse (BSSID des WLAN) und der mit diesem WAP abgeleiteten PMK basiert. Da OKC daher für alle Zugangspunkte und den jeweiligen Client denselben ursprünglichen PMK zwischenspeichert, ist bei einer (erneuten) Zuordnung dieses Clients zu einem anderen Zugangspunkt der einzige Wert, der sich ändert, um die neue PMKID zu hash, die neue AP-MAC-Adresse.
Wenn der Client das Roaming zu einem neuen WAP initiiert und den Frame der Neuzuordnungsanforderung sendet, fügt er die PMKID zum WPA2 RSN-Informationselement hinzu, wenn er den WAP darüber informieren möchte, dass ein zwischengespeicherter PMK für das schnelle sichere Roaming verwendet wird. Er kennt bereits die MAC-Adresse des BSSID (AP), wohin er roamt, dann hasht der Client einfach die neue PMKID, die für diese Neuzuordnungsanforderung verwendet wird. Wenn der WAP diese Anforderung vom Client empfängt, hasht er auch die PMKID mit den Werten, über die er bereits verfügt (die zwischengespeicherte PMK, die Client-MAC-Adresse und seine eigene WAP-MAC-Adresse), und antwortet mit der erfolgreichen Antwort zur erneuten Zuordnung, die bestätigt, dass die PMKIDs zugeordnet wurden. Der zwischengespeicherte PMK kann als Seed verwendet werden, der einen 4-Wege-WPA2-Handshake startet, um die neuen Verschlüsselungsschlüssel abzuleiten (und EAP zu überspringen):
In diesem Bild wird der Frame für die Neuzuordnungsanforderung vom Client ausgewählt und erweitert, sodass Sie weitere Details des Frames sehen können. Die MAC-Adressinformationen sowie das Robust Security Network (RSN, gemäß 802.11i - WPA2) Information Element, in dem Informationen über die WPA2-Einstellungen angezeigt werden, die für diese Zuordnung verwendet werden (hervorgehoben ist die PMKID, die aus der Hashformel erhalten wird).
Nachfolgend finden Sie eine Zusammenfassung der WLC-Debugs für diese hochsichere Roaming-Methode mit OKC:
*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
Wie zu Beginn der Debugs gezeigt, muss die PMKID berechnet werden, nachdem die Neuzuordnungsanforderung vom Client empfangen wurde. Dies ist erforderlich, um die PMKID zu validieren und zu bestätigen, dass der zwischengespeicherte PMK mit dem 4-Wege-WPA2-Handshake verwendet wird, um die Verschlüsselungsschlüssel abzuleiten und das schnelle sichere Roaming zu beenden. Verwechseln Sie nicht die CCKM-Einträge auf den Debugs; dies wird nicht verwendet, um CCKM auszuführen, sondern OKC, wie zuvor erläutert. CCKM ist hier einfach ein Name, der vom WLC für diese Ausgaben verwendet wird, z. B. der Name einer Funktion, die die Werte verarbeitet, um die PMKID zu berechnen.
FlexConnect mit opportunistischem Key-Caching
- Die zentrale Authentifizierung wird unterstützt. Dies umfasst das lokale und zentrale Daten-Switching. Wenn der AP zur gleichen FlexConnect-Gruppe gehört, erfolgt das schnelle sichere Roaming durch den AP, ansonsten erfolgt das schnelle sichere Roaming durch den Controller.
- Flex Local Authentication wird unterstützt. Im verbundenen Modus kann der Cache vom Access Point zum Controller und dann zu den übrigen Access Points der FlexConnect-Gruppe verteilt werden.
- Der Standalone-Modus wird unterstützt. Wenn der Cache (aufgrund früherer Verteilung) bereits auf dem Access Point vorhanden ist, muss das schnelle Roaming funktionieren. Die neue Authentifizierung im Standalone-Modus unterstützt kein schnelles sicheres Roaming.
Vorteile mit opportunistischem Schlüssel-Caching
- Der WLAN-Client und die WLAN-Infrastruktur müssen sich nicht mehrere PMKIDs merken, sondern lediglich die ursprüngliche PMK aus der ursprünglichen Authentifizierung in das WLAN zwischenspeichern. Anschließend müssen Sie die richtige PMKID (für die Anforderung zur erneuten Zuordnung) neu erstellen, die für jede sichere AP-Zuordnung erforderlich ist, um das schnelle Roaming zu validieren.
- Hier führt der Wireless-Client ein schnelles und sicheres Roaming zu einem neuen WAP im selben WLAN/SSID durch, selbst wenn er nie mit diesem WAP verbunden war (nicht der Fall bei SKC). Solange der Client die anfängliche 802.1X/EAP-Authentifizierung mit einem von der zentralisierten Bereitstellung verwalteten WAP durchführt, der den PMK-Cache für alle WAPs verwaltet, für die der Client Roaming durchführt, sind für die restliche Lebensdauer des Clients in diesem WLAN keine vollständigen Authentifizierungen mehr erforderlich.
Nachteile: Opportunistisches Schlüssel-Caching
- Diese Methode wird nur in einer zentralisierten Umgebung bereitgestellt, in der alle Access Points einer Art administrativen Kontrolle (z. B. einem WLAN-Controller) unterliegen, die für das Caching und die gemeinsame Nutzung des ursprünglichen PMK aus der Client-Sitzung zuständig ist. Dies stellt daher eine Beschränkung für autonome AP-Umgebungen dar.
- Die Techniken, die bei diesem Verfahren angewendet werden, werden nicht auf dem 802.11-Standard vorgeschlagen oder beschrieben, sodass die Unterstützung von Gerät zu Gerät stark variiert. Dennoch ist dies immer noch die Methode, die mehr während der Wartezeit auf 802.11r angenommen wurde.
Hinweis zum Begriff "proaktives Schlüssel-Caching"
Proaktives Schlüssel-Caching (oder PKC) wurde als OKC (Opportunistisches Schlüssel-Caching) bezeichnet. Beide Begriffe werden synonym verwendet, wenn sie dieselbe, hier erläuterte Methode beschreiben. Allerdings war dies nur ein Begriff, der von Airspace im Jahr 2001 für eine alte Schlüssel-Caching-Methode verwendet wurde, die dann vom 802.11i-Standard als Grundlage für die "Vorauthentifizierung" (eine weitere Fast Secure Roaming-Methode, die im Folgenden kurz erläutert wird) verwendet wurde. PKC ist nicht Preauthentication oder OKC (Opportunistic Key Caching), aber wenn Sie PKC hören oder lesen, wird im Grunde auf OKC verwiesen, und nicht auf Preauthentication.
Schnelles und sicheres Roaming mit Vorauthentifizierung
Diese Methode wird auch vom IEEE 802.11-Standard im Rahmen der 802.11i-Sicherheitsänderung empfohlen. Sie funktioniert also auch mit WPA2, ist jedoch die einzige Fast Secure Roaming-Methode, die von der Cisco WLAN-Infrastruktur nicht unterstützt wird. Aus diesem Grund wird sie hier nur kurz und ohne Ausgänge erläutert.
Mit der Vorauthentifizierung können sich die Wireless-Clients mit mehreren WAPs gleichzeitig authentifizieren, während sie mit dem aktuellen WAP verbunden sind. In diesem Fall sendet der Client die EAP-Authentifizierungs-Frames an den aktuellen WAP, mit dem er verbunden ist. Er ist jedoch für die anderen WAPs bestimmt, bei denen der Client die Vorauthentifizierung durchführen möchte (benachbarte WAPs, die möglicherweise für Roaming infrage kommen). Der aktuelle WAP sendet diese Frames über das Verteilungssystem an die Ziel-WAPs. Der neue WAP führt für diesen Client eine vollständige Authentifizierung gegenüber dem RADIUS-Server durch, sodass ein kompletter neuer EAP-Authentifizierungshandshake abgeschlossen ist und dieser neue WAP als Authentifizierer fungiert.
Die Idee besteht darin, eine Authentifizierung durchzuführen und PMK mit den benachbarten APs abzurufen, bevor der Client tatsächlich zu ihnen roamt. Wenn es also an der Zeit ist, zu roamen, ist der Client bereits authentifiziert und mit einem PMK, der bereits für diese neue sichere AP-to-Client-Verbindung zwischengespeichert ist, sodass sie nur den 4-Wege-Handshake durchführen müssen und einen schnellen Roam erleben, nachdem der Client seine anfängliche Neuzuordnungsanforderung gesendet hat.
Das folgende Bild zeigt ein AP-Beacon mit dem RSN IE-Feld, das die Unterstützung für die Vorauthentifizierung ankündigt (diese ist von einem Cisco AP, bei dem bestätigt wird, dass die Vorauthentifizierung nicht unterstützt wird):
Vorteile mit Vorauthentifizierung
Für jede sichere Zuordnung zwischen APs und Clients gibt es einen PMK. Dies könnte als Sicherheitsvorteil angesehen werden, wenn ein AP kompromittiert wird und die Schlüssel gestohlen werden (kann nicht mit anderen APs verwendet werden). Dieser Sicherheitsvorteil wird jedoch von der WLAN-Infrastruktur auf verschiedene Weise und mit anderen Methoden genutzt.
Nachteile: Vorauthentifizierung
- Da es einen PMK pro AP gibt, können die Clients nur eine begrenzte Anzahl von APs vorauthentifizieren.
- Jedes Mal, wenn ein Client eine Vorauthentifizierung mit einem neuen WAP durchführt, findet ein vollständiger EAP-Authentifizierungsaustausch statt, was eine höhere Auslastung des Netzwerks und des Authentifizierungsservers bedeutet.
- Die meisten Wireless-Clients unterstützen diese Methode nicht, da sie nie sehr häufig eingesetzt wurde (OKC wurde eher eingesetzt).
Schnelles und sicheres Roaming mit 802.11r
Die auf dem 802.11r-Zusatz (offiziell Fast BSS Transition durch den 802.11-Standard und FT) basierende Fast-Secure-Roaming-Technik ist die erste offiziell (2008) vom IEEE für den 802.11-Standard als Lösung zur Durchführung schneller Übergänge zwischen APs ratifizierte Methode (Basic Service Sets oder BSSs), die die Schlüsselhierarchie klar definiert, die beim Verarbeiten und Zwischenspeichern von Schlüsseln in einem WLAN verwendet wird. Die Einführung erfolgte jedoch nur langsam, was vor allem auf die anderen Lösungen zurückzuführen ist, die bereits zur Verfügung standen, wenn tatsächlich schnelle Übergänge erforderlich waren, z. B. bei VoWLAN-Implementierungen, wenn sie mit einer der zuvor in diesem Dokument beschriebenen Methoden verwendet wurden. Derzeit unterstützen nur wenige Geräte einige der FT-Optionen (bis 2013).
Diese Methode ist komplexer zu erklären als die anderen Methoden, da sie neue Konzepte und mehrere Ebenen von PMKs einführt, die auf verschiedenen Geräten zwischengespeichert werden (jedes Gerät mit einer anderen Rolle), und noch mehr Optionen für schnelles und sicheres Roaming bietet. Daher wird eine kurze Zusammenfassung über diese Methode und die Art ihrer Implementierung mit jeder verfügbaren Option bereitgestellt.
802.11r unterscheidet sich von SKC und OKC vor allem aus den folgenden Gründen:
- Handshake-Messaging (z. B. PMKID-, ANonce- und SNonce-Austausch) erfolgt in Authentifizierungs-Frames des Standards 802.11 oder in Action-Frames anstelle von Reassociation-Frames. Im Gegensatz zu PMKID-Caching-Verfahren wird die separate 4-Wege-Handshake-Phase, die nach dem (Re)Zuordnungs-Nachrichtenaustausch durchgeführt wird, vermieden. Der Schlüsselhandshake mit dem neuen Access Point beginnt, bevor der Client das Roaming bzw. die Neuzuordnung mit diesem neuen Access Point vollständig durchführt.
- Sie bietet zwei Methoden für den schnellen Roaming-Handshake: über den AIR und über das Distribution System (DS).
- 802.11r verfügt über mehr Ebenen der Schlüsselhierarchie.
- Da dieses Protokoll den 4-Wege-Handshake für die Schlüsselverwaltung beim Roaming eines Clients vermeidet (erzeugt neue Verschlüsselungsschlüssel - PTK und GTK - ohne diesen Handshake), kann es auch für WPA2-Einrichtungen mit einem PSK angewendet werden, und nicht nur, wenn 802.1X/EAP für die Authentifizierung verwendet wird. Dies beschleunigt das Roaming noch mehr für diese Konfigurationen, bei denen kein EAP- oder 4-Wege-Handshake-Austausch stattfindet.
Bei diesem Verfahren führt der WLAN-Client beim Herstellen einer Verbindung mit dem ersten WAP nur eine erste Authentifizierung gegenüber der WLAN-Infrastruktur durch und führt beim Roaming zwischen WAPs derselben FT-Mobilitätsdomäne ein schnelles und sicheres Roaming durch.
Dies ist eines der neuen Konzepte, das sich im Wesentlichen auf die APs bezieht, die die gleiche SSID (Extended Service Set oder ESS) verwenden und die gleichen FT-Schlüssel verarbeiten. Dies ist vergleichbar mit den anderen bisher erläuterten Verfahren. Die Art und Weise, wie die APs die FT-Mobilitätsdomänenschlüssel handhaben, basiert normalerweise auf einer zentralisierten Einrichtung, wie dem WLC oder Mobilitätsgruppen; diese Methode kann jedoch auch in autonomen AP-Umgebungen implementiert werden.
Hier eine Zusammenfassung der Haupthierarchie:
- Ein MSK wird auf der Client-Komponente und dem Authentifizierungsserver weiterhin von der anfänglichen 802.1X/EAP-Authentifizierungsphase abgeleitet (vom Authentifizierungsserver an den Authentifizierer (WLC) übertragen, sobald die Authentifizierung erfolgreich ist). Diese MSK wird wie bei den anderen Methoden als Ausgangspunkt für die FT-Schlüsselhierarchie verwendet. Wenn Sie WPA2-PSK anstelle einer EAP-Authentifizierungsmethode verwenden, ist der PSK im Grunde dieser MSK.
- Ein Pairwise Master Key R0 (PMK-R0) wird aus dem MSK abgeleitet, dem First-Level-Key der FT-Schlüsselhierarchie. Die Schlüsselhalter für diese PMK-R0 sind der WLC und der Client.
- Aus dem PMK-R0 wird ein Schlüssel der zweiten Ebene abgeleitet, der als Pairwise Master Key R1 (PMK-R1) bezeichnet wird. Die Schlüsselhalter sind der Client und die APs, die vom WLC verwaltet werden, der den PMK-R0 enthält.
- Der dritte und letzte Schlüssel der FT-Schlüsselhierarchie ist der PTK. Dies ist der letzte Schlüssel, der zur Verschlüsselung der 802.11-Unicast-Datenframes verwendet wird (ähnlich den anderen Methoden, die WPA/TKIP oder WPA2/AES verwenden). Diese PTK wird auf FT von der PMK-R1 abgeleitet, und die Schlüsselhalter sind der Client und die APs, die vom WLC verwaltet werden.
Schnelle drahtlose BSS-Umstellung
Bei dieser Methode ist die erste Zuordnung zu einem WAP eine reguläre Erstauthentifizierung im WLAN, wobei die gesamte 802.1X/EAP-Authentifizierung gegenüber dem Authentifizierungsserver und der 4-Wege-Handshake zur Schlüsselgenerierung erfolgen muss, bevor Datenframes gesendet werden, wie in diesem Screenimage gezeigt:
Die Hauptunterschiede sind:
- Die Aushandlung für das Authentifizierungsschlüsselmanagement unterscheidet sich geringfügig von der Aushandlung für das reguläre WPA/WPA2, sodass zusätzliche Informationen verwendet werden, um diese Aushandlung durchzuführen, wenn die Zuordnung zu einer WLAN-Infrastruktur erfolgt, die FT unterstützt. Wie im Bild gezeigt, wird der Zuordnungsanforderungsrahmen vom Client ausgewählt, und das AKM-Feld des RNS-Informationselements wird hervorgehoben, um zu zeigen, dass dieser Client FT über 802.1X/EAP ausführen möchte.
- Ebenfalls abgebildet ist das Mobility Domain Information Element (Teil von FT), bei dem das Feld "FT Capability and Policy" angibt, ob der schnelle BSS-Übergang beim schnellen Roaming Over-the-Air oder Over-the-DS abgeschlossen ist (in diesem Bild "Over-the-Air").
- Ein weiteres Informationselement (Fast BSS Transition oder FT IE, das später in diesem Dokument beschrieben wird) wird mit Informationen ergänzt, die erforderlich sind, um die FT-Authentifizierungssequenz beim FT-Roaming durchzuführen.
- Die Schlüsselgenerierung unterscheidet sich aufgrund der Schlüsselhierarchie. Obwohl der FT 4-Way-Handshake ähnlich aussieht wie der WPA/WPA2 4-Way-Handshake, ist er inhaltlich tatsächlich etwas anders.
Die Debugs zeigen im Wesentlichen den gleichen EAP-Authentifizierungs-Frame-Austausch wie die übrigen Methoden bei der Erstauthentifizierung im WLAN (wie aus den Bildern hervorgeht), aber einige Ausgaben, die die Schlüsselcaching-Techniken betreffen, die vom WLC verwendet werden, werden hinzugefügt; daher wird diese Debug-Ausgabe ausgeschnitten, um nur die relevanten Informationen anzuzeigen:
*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, andfollowsthe 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.
Hier sehen Sie die Bilder und Fehlerbehebungen einer anfänglichen Verknüpfung mit dem WLAN, wenn Sie FT mit WPA2-PSK (anstelle einer 802.1X/EAP-Methode) durchführen. Dabei wird der Zuordnungsantwortrahmen vom WAP ausgewählt, um das Fast BSS Transition Information Element (hervorgehoben) anzuzeigen. Einige der wichtigsten Informationen, die für den FT 4-Way-Handshake erforderlich sind, werden ebenfalls angezeigt:
*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
Bei 802.11r ist die anfängliche Zuordnung zum WLAN die Grundlage, auf der die bei dieser Technik verwendeten Basisschlüssel abgeleitet werden, genau wie bei den anderen schnellsicheren Roaming-Methoden. Die Hauptunterschiede entstehen, wenn der Client Roaming beginnt; FT vermeidet nicht nur 802.1X/EAP, wenn dies verwendet wird, sondern es führt tatsächlich eine effizientere Roaming-Methode durch, die die ursprünglichen 802.11 Open System Authentication und Reassociation Frames (die immer verwendet werden und erforderlich sind, wenn Roaming zwischen APs) kombiniert, um FT-Informationen auszutauschen und neue dynamische Verschlüsselungsschlüssel anstelle des 4-Way-Handshake abzuleiten 1.
Das nächste Bild zeigt die Frames, die bei einem schnellen BSS-Übergang über das Internet mit 802.1X/EAP-Sicherheit ausgetauscht werden. Der Frame der offenen Systemauthentifizierung vom Client zum Access Point wird ausgewählt, damit die FT-Protokoll-Informationselemente angezeigt werden, die zum Starten der FT-Schlüsselaushandlung erforderlich sind. Diese wird verwendet, um die neue PTK mit dem neuen AP abzuleiten (basierend auf der PMK-R1). Das Feld, das den Authentifizierungsalgorithmus anzeigt, ist hervorgehoben, um anzuzeigen, dass dieser Client keine einfache Open System Authentication, sondern einen Fast BSS Transition durchführt:
Nachfolgend sind die Debug-Ausgaben des WLC aufgeführt, wenn dieses FT-Roaming-Ereignis bei 802.1X/EAP auftritt:
*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
Das folgende Bild zeigt einen schnellen drahtlosen BSS-Übergang mit WPA2-PSK-Sicherheit, bei dem der endgültige Frame für die Antwort auf die Neuzuordnung vom Access Point zum Client ausgewählt wird, um weitere Details zu diesem FT-Austausch anzuzeigen:
Hier sind die Debug-Ausgaben, wenn dieses FT-Roaming-Ereignis mit PSK auftritt, die den Ausgaben bei Verwendung von 802.1X/EAP ähneln:
*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
Wie in der Abbildung dargestellt, werden nach der Aushandlung des Fast BSS Transition bei der ersten Zuordnung zum WLAN die vier Frames, die für das Roaming verwendet werden und benötigt werden (Open System Authentication vom Client, Open System Authentication vom AP, Reassociation Request und Reassociation Response) im Wesentlichen als FT 4-Way Handshake verwendet, um den neuen PTK (Unicast Encryption Key) und GTK (Multicast/Broadcast Encryption Key) abzuleiten.
Dies ersetzt den 4-Wege-Handshake, der normalerweise auftritt, nachdem diese Frames ausgetauscht wurden, und die FT-Inhalte und Schlüsselaushandlung bei diesen Frames ist grundsätzlich gleich, ob Sie 802.1X/EAP oder PSK als Sicherheitsmethode verwenden. Wie im Bild gezeigt, ist das AKM-Feld der Hauptunterschied, der bestätigt, ob der Client FT mit PSK oder 802.1X durchführt. Daher ist es wichtig zu beachten, dass diese vier Frames normalerweise nicht über diese Art von Sicherheitsinformationen für die Schlüsselaushandlung verfügen, sondern nur, wenn der Client-FT Roaming durchführt, wenn 802.11r implementiert ist und zwischen dem Client und der WLAN-Infrastruktur bei der ersten Zuordnung ausgehandelt wird.
Schneller BSS-Übergang über den DS
802.11r ermöglicht eine weitere Implementierung von Fast BSS Transition, bei der das FT-Roaming vom Client mit dem neuen AP initiiert wird, für den der Client über den DS (Distribution System) und nicht über das Funk roamt. In diesem Fall werden FT Action-Frames verwendet, um die Schlüsselaushandlung anstelle der Open System Authentication-Frames zu initiieren.
Sobald der Client beschließt, zu einem besseren Access Point wechseln zu können, sendet er einen FT Action Request Frame an den ursprünglichen Access Point, mit dem er derzeit verbunden ist, bevor er zum Roaming wechselt. Der Client gibt die BSSID (MAC-Adresse) des Ziel-AP an, in dem er Roaming betreiben möchte. Der ursprüngliche WAP leitet diesen FT Action Request Frame über das Verteilersystem (in der Regel die verkabelte Infrastruktur) an den Ziel-WAP weiter, und der Ziel-WAP antwortet dem Client mit einem FT Action Response Frame (auch über den DS, sodass er ihn schließlich drahtlos an den Client senden kann). Sobald dieser FT Action-Frame-Austausch erfolgreich war, beendet der Client das FT-Roaming; der Client sendet die Neuzuordnungsanforderung an den Ziel-AP (diesmal drahtlos) und erhält eine Neuzuordnungsanwort vom neuen AP, um die Ableitung des Roaming- und des endgültigen Schlüssels zu bestätigen.
Zusammenfassend gibt es vier Frames, die den schnellen BSS-Übergang aushandeln und neue Verschlüsselungsschlüssel ableiten, aber hier werden die Open System Authentication Frames durch die FT Action Request/Response Frames ersetzt, die mit dem Ziel-AP über das Distribution System mit dem aktuellen AP ausgetauscht werden. Dieses Verfahren gilt auch für die beiden Sicherheitsmethoden 802.1X/EAP und PSK, die alle von den Cisco Wireless LAN Controllern unterstützt werden. Da dieser Over-the-DS Übergang jedoch von den meisten Wireless Clients in der WiFi-Branche nicht unterstützt und implementiert wird (und da der Frame-Austausch und die Debug-Ausgaben im Wesentlichen gleich sind), werden in diesem Dokument keine Beispiele angegeben. Stattdessen wird dieses Bild verwendet, um den schnellen BSS-Übergang über den DS zu veranschaulichen:
FlexConnect mit 802.11r
- Die zentrale Authentifizierung wird unterstützt. Dies umfasst das lokale und zentrale Daten-Switching. Die APs müssen Teil derselben FlexConnect-Gruppe sein.
- Die lokale Authentifizierung wird nicht unterstützt.
- Der Standalone-Modus wird nicht unterstützt.
Vorteile mit 802.11r
- Diese Methode ist die erste, die eine Schlüsselhierarchie verwendet, die vom IEEE auf dem 802.11-Standard als Ergänzung (802.11r) klar definiert ist, sodass die Implementierung dieser FT-Techniken zwischen den Anbietern kompatibler ist und keine unterschiedlichen Interpretationen aufweist.
- 802.11r ermöglicht verschiedene Techniken, die je nach Ihren Anforderungen hilfreich sind (Over-the-Air und Over-the-DS, für 802.1x/EAP-Sicherheit und für PSK-Sicherheit).
- Der Wireless-Client führt ein schnelles und sicheres Roaming zu einem neuen WAP im selben WLAN/SSID durch, selbst wenn er nie mit diesem WAP verbunden war und ohne mehrere PMKIDs speichern zu müssen.
- Dies ist die erste schnellsichere Roaming-Methode, die auch bei PSK-Sicherheit ein schnelleres Roaming ermöglicht und den beim Roaming zwischen APs mit WPA/WPA2-PSK erforderlichen 4-Wege-Handshake vermeidet. Der Hauptzweck der Fast-Secure-Roaming-Methoden besteht darin, den 802.1X/EAP-Handshake bei der Implementierung dieser Sicherheitsmethode zu vermeiden; für die PSK-Sicherheit wird das Roaming-Ereignis jedoch mit 802.11r noch weiter beschleunigt, wenn der 4-Wege-Handshake vermieden wird.
Nachteile von 802.11r
- Es gibt einige Wireless-Client-Geräte, die Fast BSS Transitions unterstützen, und in den meisten Fällen unterstützen sie nicht alle auf 802.11r verfügbaren Techniken.
- Da diese Implementierungen noch sehr jung sind, gibt es weder genügend Testergebnisse aus realen Produktionsumgebungen noch genügend Debugging-Ergebnisse, um mögliche Probleme zu beheben.
- Wenn Sie eine WLAN/SSID konfigurieren, um eine der FT-Methoden zu verwenden, können nur Wireless-Clients, die 802.11r unterstützen, eine Verbindung zu dieser WLAN/SSID herstellen. Die FT-Einstellungen sind für die Clients nicht optional. Daher müssen sich Wireless-Clients, die 802.11r nicht unterstützen, mit einer separaten WLAN/SSID verbinden, wenn FT überhaupt nicht konfiguriert ist.
Adaptives 802.11r
- Einige ältere Clients können keine Verbindung zu einer WLAN/SSID herstellen, bei der 802.11r aktiviert ist, selbst im "gemischten Modus" (den Sie hoffentlich auf denselben SSID-Clients haben können, die 802.11r unterstützen und nicht unterstützen). In diesem Fall ist der Treiber der Client-Komponente, die für das Parsen des Robust Security Network Information Element (RSN IE) zuständig ist, alt und kennt die zusätzlichen AKM-Suites im IE nicht. Aufgrund dieser Einschränkung können Clients keine Zuordnungsanforderungen an WLANs senden, die 802.11r-Unterstützung ankündigen. Daher müssen Sie eine WLAN/SSID für 802.11r-Clients und eine separate WLAN/SSID für Clients, die 802.11r nicht unterstützen, konfigurieren.
-
Um dieses Problem zu lösen, hat die Cisco Wireless LAN-Infrastruktur die Funktion Adaptive 802.11r eingeführt. Wenn der FT-Modus auf WLAN-Ebene auf "Adaptive" festgelegt ist, meldet das WLAN die 802.11r-Mobilitätsdomänen-ID in einem 802.11i-fähigen WLAN. Einige Apple iOS10-Client-Geräte identifizieren das Vorhandensein von MDIE in einem 80211i/WPA2-WLAN und führen einen proprietären Handshake aus, um eine 802.11r-Zuordnung herzustellen. Sobald der Client die erfolgreiche 802.11r-Zuordnung abgeschlossen hat, kann er das FT-Roaming wie in einem normalen 802.11r-fähigen WLAN ausführen. Der FT Adaptive Service gilt nur für ausgewählte Apple iOS10-Geräte (oder höher). Alle anderen Clients können weiterhin eine 802.11i/WPA2-Zuordnung im WLAN aufweisen und die entsprechende FSR-Methode wie unterstützt ausführen.
-
Weitere Dokumentation zu dieser neuen Funktion, die für iOS10-Geräte eingeführt wurde, um 802.11r in einem WLAN/SSID auszuführen, in dem 802.11r nicht wirklich aktiviert ist (sodass andere Clients, die nicht 802.11r sind, sich erfolgreich verbinden können), finden Sie unter Best Practices für Cisco IOS-Geräte im Cisco Wireless LAN.
Schlussfolgerungen
- Beachten Sie, dass der Client immer derjenige ist, der sich für das Roaming zu einem bestimmten AP entscheidet, und der WLC/AP kann dies für den Client nicht entscheiden. Das Roaming-Ereignis wird vom Wireless-Client initiiert, sobald er es als Roaming betrachtet.
- Der WLC unterstützt eine Kombination der meisten oder aller FSR-Methoden (Fast-Secure Roaming) zusammen auf demselben WLAN/SSID. Beachten Sie jedoch, dass dies normalerweise nicht funktioniert, da es stark vom Clientverhalten abhängt (sehr unterschiedlich bei verschiedenen Mobilgeräten), um das zu unterstützen oder sogar zu verstehen, was der WLC als unterstützt ankündigen möchte. Anstatt die Interoperabilität mit nur einer SSID zu erreichen, gibt es normalerweise mehr Probleme als die, die voraussichtlich behoben werden. Daher wird davon abgeraten. Es sind intensive Tests mit allen möglichen Clients, die in diesem WLAN verwendet werden können, durchzuführen, wenn dies wirklich erforderlich ist.
- Es ist sehr wichtig zu verstehen, dass schnelle sichere Roaming-Methoden entwickelt werden, um den WLAN-Roaming-Prozess zu beschleunigen, wenn Sie zwischen APs wechseln, wenn die Sicherheit für WLAN/SSID aktiviert ist. Wenn keine Sicherheit vorhanden ist, gibt es nichts zu beschleunigen, da der Client-AP lediglich die Wireless-Management-Frames austauscht, die beim Roaming zwischen APs vor dem Senden von Daten-Frames immer erforderlich sind (Open System Authentication vom Client, Open System Authentication vom AP, Reassoziationsanforderung und Reassoziationsantwort). Daher kann dies nicht schneller gehen. Wenn Roaming-Probleme ohne Sicherheit auftreten, gibt es keine schnellen Roaming-Methoden zur Verbesserung des Roaming, sondern nur Methoden, um zu bestätigen, ob die Einrichtung und das Design von WLAN/SSID für die drahtlosen Client-Stationen geeignet sind, entsprechend zwischen den WAP-Abdeckungszellen zu roamen.
- 802.11r/FT wird mit WPA2-PSK implementiert, um Roaming-Ereignisse mit dieser Sicherheit zu beschleunigen und den 4-Wege-Handshake zu vermeiden, wie im Abschnitt 802.11r erläutert.
- Alle Methoden haben ihre Vor- und Nachteile, aber am Ende müssen Sie immer überprüfen, ob die Wireless-Client-Stationen die gewünschte Methode unterstützen und ob die Cisco WLAN-Infrastruktur alle verfügbaren Methoden unterstützt. Daher müssen Sie die Methode auswählen, die von den Wireless-Clients, die eine Verbindung mit dem jeweiligen WLAN/SSID herstellen, am besten unterstützt wird. In einigen Bereitstellungen können Sie z. B. eine WLAN/SSID mit CCKM für Cisco Wireless IP-Telefone erstellen (die WPA2/AES mit CCKM, jedoch nicht 802.11r unterstützen), und dann eine weitere WLAN/SSID mit WPA2/AES über 802.11r/FT für Wireless-Clients, die diese Fast Secure Roaming-Methode unterstützen (oder OKC , wenn dies unterstützt wird).
- Wenn die Wireless-Clients keine der verfügbaren hochsicheren Roaming-Methoden unterstützen, müssen Sie akzeptieren, dass diese Clients beim Roaming zwischen APs in einem WLAN/SSID mit 802.1X/EAP-Sicherheit (die zu Unterbrechungen der Client-Anwendungen/Dienste führen kann) immer die in diesem Dokument beschriebenen Verzögerungen ausprobieren können.
- Alle Methoden mit Ausnahme von SKC (WPA2 PMKID-Caching) werden für schnelles Roaming zwischen APs unterstützt, die von verschiedenen WLCs verwaltet werden (Intercontroller-Roaming), sofern sie derselben Mobilitätsgruppe angehören.
- CUWN unterstützt alle in diesem Artikel behandelten Fast-Secure Roaming-Methoden, wenn die 802.1X/EAP-Authentifizierung für WPA/WPA2 verwendet wird. Bei Methoden, die mit WPA2-RSN (CCKM, PMKID Caching/SKC, OKC/PKC) arbeiten, wenn PSK (WPA2-Personal) verwendet wird, wobei Fast-Roaming-Methoden meist nicht benötigt werden, bietet CUWN keine Unterstützung für schnelles Roaming. CUWN unterstützt jedoch Fast-Secure Roaming bei WPA2-FT (802.11r) mit PSK, wie auch in diesem Artikel erläutert.
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
09-Feb-2023 |
Aktualisiertes Format und verifizierte technische Informationen. Rezertifizierung. |
1.0 |
02-Sep-2013 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)