In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
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.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
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.
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:
Hinweis: Wenn Sie mehr über 802.11-Wireless-Sniffing und über die Filter/Farben erfahren möchten, die in Wireshark für die in diesem Dokument enthaltenen Bilder verwendet werden, besuchen Sie den Beitrag der Cisco Support Community mit dem Titel 802.11 Sniffer image Analysis (Sniffer-Bildanalyse).
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.
Hinweis: Das WLC-Debugging für die in diesem Dokument dargestellten Ausgaben ist der Debug-Client-Befehl, und die Beispiele zeigen nur einige relevante Meldungen, nicht die gesamte Ausgabe. Weitere Informationen zu diesem Debug-Befehl finden Sie im Dokument Understand the Debug Client on Wireless LAN Controllers (WLCs).
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.
Hinweis: Sie können sich an den Hersteller des Wireless-Clients wenden, um die Ursache des Problems zu ermitteln.
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:
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:
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).
Hinweis: EAPOL-Frames werden verwendet, um alle wichtigen Management-Frames und 802.1X/EAP-Authentifizierungsframes drahtlos zwischen dem AP und dem Client zu übertragen. Sie werden als Wireless-Datenframes übertragen.
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.
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 intoConnecting
state
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 4)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 4, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.956: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.957: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 7, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c
(EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
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.
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.
Hinweis: Einen Überblick über die von den verschiedenen Versionen der CCX-Spezifikation unterstützten Funktionen (einschließlich unterstützter EAP-Methoden) finden Sie im Dokument "CCX-Versionen und -Funktionen" und überprüfen Sie die genaue CCX-Version, die von Ihren Wireless-Clients unterstützt wird (sofern diese CCX-kompatibel sind), damit Sie überprüfen können, ob die gewünschte Sicherheitsmethode mit CCKM implementiert werden kann.
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.
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:
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:
Hinweis: Dieses Bild zeigt nicht den ersten 802.11 Open System Authentifizierungsframe vom Client, aber dies liegt nicht an der implementierten Methode, da dieser Frame immer erforderlich ist. Der Grund dafür ist, dass dieser spezielle Frame nicht von dem Adapter oder der Wireless-Paket-Image-Software abgebildet wird, die verwendet wird, um die Over-the-Air-Frames für dieses Beispiel zu erschnüffeln, sondern dass er für Unterrichtszwecke so auf dem Beispiel belassen wird. Beachten Sie, dass dies bei der Übertragung von Paket-Images möglich ist. Manche Frames können vom Image verpasst werden, werden jedoch zwischen dem Client und dem Access Point ausgetauscht. Andernfalls wird das Roaming in diesem Beispiel nie gestartet.
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
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.
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.
Hinweis: Diese Konfiguration funktioniert, wenn die Access Points nicht derselben FlexConnect-Gruppe angehören. Dies wird jedoch nicht empfohlen oder unterstützt.
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.
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):
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.
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:
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:
Hinweis: Je nach WLAN-Anbieter und den Implementierungseinrichtungen (z. B. autonome APs, FlexConnect oder Mesh) kann die WLAN-Infrastruktur die Schlüssel auf andere Weise übertragen und verarbeiten. Es kann sogar die Rollen der Schlüsselhalter ändern, da dies jedoch nicht im Rahmen dieses Dokuments enthalten ist, stehen die Beispiele, die auf der zuvor angegebenen Zusammenfassung der Schlüsselhierarchie basieren, im Mittelpunkt. Die Unterschiede sind für das Verständnis des Prozesses nicht relevant, es sei denn, Sie müssen die Infrastrukturgeräte (und ihren Code) eingehend analysieren, um ein Softwareproblem zu erkennen.
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 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, andfollows
the same exchange explained so far.
*apfMsConnTask_0: Jun 27 19:25:23.436: ec:85:2f:15:39:32
Got action frame from this client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32
Received Identity Response (count=1) from mobile
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32
Processing Access-Challenge for mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32
Sending EAP Request from AAA to mobile ec:85:2f:15:39:32
(EAP Id 2)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32
Received EAP Response from mobile ec:85:2f:15:39:32
(EAP Id 2, EAP Type 25)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Processing Access-Accept for mobile ec:85:2f:15:39:32
!--- The client is validated/authenticated by the RADIUS Server.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Creating a PKC PMKID Cache entry for station
ec:85:2f:15:39:32 (RSN 2)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Resetting MSCB PMK Cache Entry 0 for station
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32
Adding BSSID 84:78:ac:f0:68:d6 to PMKID cache at index 0
for station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: New PMKID: (16)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628:
[0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629: ec:85:2f:15:39:32
Created PMK Cache Entry for TGr AKM:802.1x ec:85:2f:15:39:32
!--- WLC creates a PMK cache entry for this client, which is
used for FT with 802.1X in this case, so the PMKID is
computed with the AP MAC address (BSSID 84:78:ac:f0:68:d6).
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629:
ec:85:2f:15:39:32 R0KH-ID:172.30.6.253
R1KH-ID:3c:ce:73:d8:02:00 MSK Len:48 pmkValidTime:1807
!--- The R0KH-ID and R1KH-ID are defined, as well as the PMK
cache validity period.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
PMK sent to mobility group
!--- The FT PMK cache entry for this client is shared with the
WLCs on the mobility group.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Sending EAP-Success to mobile ec:85:2f:15:39:32 (EAP Id 12)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d6 in PMKID
cache at index 0 of station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: Including PMKID in
M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
initial FT 4-Way handshake.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630:
[0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.0
!--- Message-1 of the FT 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from
mobile ec:85:2f:15:39:32
!--- Message-2 of the FT 4-Way handshake is received
successfully from the client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Calculating PMKR0Name
!--- The PMKR0Name is calculated.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
DOT11R: Sending cache add
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: Adding MDIE,
ID is:0xaaf0
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Adding TIE for reassociation deadtime:20000 milliseconds
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Adding TIE for R0Key-Data valid time :1807
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.640: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- After the MDIE, TIE for reassociation deadtime, and TIE
for R0Key-Data valid time are calculated, the Message-3
of this FT 4-Way handshake is sent from the WLC/AP to the
client with this information.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
!--- Message-4 (final message) of this initial FT 4-Way handshake
is received successfully from the client, which confirms the
installation of the derived keys. They can now be used in order
to encrypt data frames with the current AP.
Hinweis: Um diese Methode zu debuggen und die hier gezeigten zusätzlichen 802.11r/FT-Ausgaben zu erreichen, wird zusammen mit dem Debug-Client ein zusätzliches Debug aktiviert, das Aktivieren von Debug-FT-Ereignissen.
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.
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:
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.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
2.0 |
09-Feb-2023 |
Aktualisiertes Format und verifizierte technische Informationen. Rezertifizierung. |
1.0 |
02-Sep-2013 |
Erstveröffentlichung |