De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
In dit document worden draadloze en snel beveiligde zwerftypen beschreven die beschikbaar zijn voor IEEE 802.11 Wireless LAN's (WLAN's) op Unified Wireless Network (CUWN).
Cisco raadt kennis van de volgende onderwerpen aan:
De informatie in dit document is gebaseerd op Cisco WLAN Controller Software versie 7.4.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
De informatie in dit document is gebaseerd op Cisco WLAN Controller Software versie 7.4, maar de meeste van de beschreven foutopsporingsresultaten en gedragingen kunnen van toepassing zijn op elke softwareversie die de besproken methoden ondersteunt.
De specificaties van alle hier beschreven methoden blijven hetzelfde voor latere Cisco WLAN Controller-codes (tot versie 8.3 tegen de tijd dat dit artikel werd bijgewerkt).
In dit document worden de verschillende typen draadloze roaming en snel beveiligde zwerfmethoden beschreven die beschikbaar zijn voor draadloze LAN's (WLAN's) met IEEE 802.11 die worden ondersteund in het Cisco Unified Wireless Network (CUWN).
Het document bevat niet alle details over hoe elke methode werkt of hoe ze zijn geconfigureerd. Het belangrijkste doel van dit document is om de verschillen tussen de verschillende beschikbare technieken, hun voordelen en beperkingen, en de frames-uitwisseling op elke methode te beschrijven. Voorbeelden van WLAN Controller (WLC)-debugs worden gegeven en afbeeldingen van draadloze pakketten worden gebruikt om de gebeurtenissen te analyseren en uit te leggen die zich voordoen voor elke beschreven zwerfmethode.
Voordat een beschrijving wordt gegeven van de verschillende snelbeveiligde zwerfmethoden die beschikbaar zijn voor WLAN's, is het belangrijk om te begrijpen hoe het WLAN-associatieproces werkt en hoe een regelmatig zwerfevenement plaatsvindt wanneer er geen beveiliging is geconfigureerd op de Service Set Identifier (SSID).
Wanneer een 802.11 draadloze client verbinding maakt met een toegangspunt (AP), moet deze eerst het basisverificatieproces van het 802.11 Open Systeem doorlopen voordat het verkeer begint door te geven (draadloze gegevensframes).
Vervolgens moet het associatieproces worden afgerond. Het verificatieproces voor het open systeem is als een kabelverbinding op het toegangspunt dat de client selecteert.
Dit is een zeer belangrijk punt, omdat het altijd de draadloze client is die selecteert welke AP de voorkeur heeft en de beslissing baseert op meerdere factoren die variëren tussen leveranciers.
Daarom begint de client dit proces door het verificatieframe naar het geselecteerde toegangspunt te sturen, zoals later in dit document wordt weergegeven. Het toegangspunt kan niet vragen dat u een verbinding tot stand brengt.
Nadat het verificatieproces voor het open systeem met succes is voltooid met een antwoord van het toegangspunt ("kabel aangesloten"), wordt de 802.11 Layer 2 (L2)-onderhandeling die de koppeling tussen de client en het toegangspunt tot stand brengt, in wezen voltooid.
Het toegangspunt wijst een associatie-ID toe aan de client als de verbinding succesvol is en bereidt deze voor om verkeer door te geven of een beveiligingsmethode van een hoger niveau uit te voeren als deze op de SSID is geconfigureerd.
Het verificatieproces van het open systeem bestaat uit twee beheerframes en het associatieproces.
Authenticatie- en associatieframes zijn draadloze beheerframes, geen gegevensframes, die in principe worden gebruikt voor het verbindingsproces met het toegangspunt.
Hier is een afbeelding van de draadloze frames over-the-air voor dit proces:
Opmerking: als u meer wilt weten over 802.11 draadloos snuiven en over de filters/kleuren die op Wireshark worden gebruikt voor de afbeeldingen die in dit document worden weergegeven, gaat u naar de post van de Cisco Support Community met de naam 802.11 Sniffer Image Analysis.
De draadloze client begint met het verificatieframe en het toegangspunt antwoordt met een ander verificatieframe. De client verzendt vervolgens het frame Associatieverzoek en het toegangspunt eindigt in een antwoord met het frame Associatierespons.
Zoals blijkt uit de DHCP-pakketten, begint de client gegevensframes door te geven zodra de 802.11 Open System-verificatie- en associatieprocessen zijn doorgegeven.
In dit geval is er geen beveiligingsmethode geconfigureerd op de SSID, dus de client begint onmiddellijk gegevensframes (in dit geval DHCP) te verzenden die niet zijn gecodeerd.
Als beveiliging is ingeschakeld op de SSID, zijn er, zoals later in dit document wordt getoond, authenticatie- en coderingshandshake-frames op een hoger niveau voor de specifieke beveiligingsmethode, net na de associatierespons en voordat er gegevensframes voor clientverkeer worden verzonden, zoals DHCP, Address Resolution Protocol (ARP) en toepassingspakketten, die worden gecodeerd. Gegevensframes kunnen alleen worden verzonden totdat de client volledig is geverifieerd en de coderingssleutels zijn overeengekomen op basis van de geconfigureerde beveiligingsmethode.
Op basis van de vorige afbeelding zijn hier de berichten die u ziet in de uitvoer van de opdracht WLC-debugclient wanneer de draadloze client een nieuwe koppeling met het WLAN start:
*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.
Opmerking: Het WLC-debug dat wordt gebruikt voor de uitvoer die in dit document wordt weergegeven, is de opdracht client debuggen en de voorbeelden tonen alleen enkele relevante berichten, niet de volledige uitvoer. Raadpleeg voor meer informatie over deze foutopsporingsopdracht het document Begrijp de foutopsporingsclient op draadloze LAN-controllers (WLC's).
Deze berichten tonen de frames Associatieverzoek en Reactie; de eerste verificatieframes worden niet geregistreerd bij de WLC omdat deze handshake snel gebeurt op het AP-niveau op de CUWN.
Welke informatie wordt weergegeven wanneer de client zwerft? De klant wisselt altijd vier beheerframes uit bij het tot stand brengen van een verbinding met een toegangspunt, wat te wijten is aan de oprichting van een vereniging of een roamingevenement.
De client heeft slechts één verbinding tot stand gebracht met slechts één toegangspunt tegelijk. Het enige verschil in de frameschakeling tussen een nieuwe verbinding met de WLAN-infrastructuur en een zwervend evenement is dat de associatieframes van een zwervend evenement reassociatieframes worden genoemd, die aangeven dat de client daadwerkelijk zwerft vanaf een ander toegangspunt zonder pogingen om een nieuwe koppeling met het WLAN tot stand te brengen. Deze frames kunnen verschillende elementen bevatten die worden gebruikt om te onderhandelen over het roamingevenement; dit hangt af van de configuratie, maar die details vallen buiten het bereik van dit document.
Hier is een voorbeeld van een frame exchange:
Deze berichten worden weergegeven in de foutopsporingsuitvoer:
*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.
Zoals u ziet, voert de client een zwervend evenement uit nadat het verzoek tot herkoppeling naar het nieuwe toegangspunt is verzonden en ontvangt de reactie op de herkoppeling van het toegangspunt. Aangezien de client al een IP-adres heeft, zijn de eerste dataframes voor ARP-pakketten.
Als u een roamingevenement verwacht, maar de client verzendt een Associatieverzoek in plaats van een Herassociatieverzoek (dat u kunt bevestigen aan de hand van enkele afbeeldingen en fouten die vergelijkbaar zijn met die eerder in dit document zijn uitgelegd), dan is de client niet echt aan het roamen. De client start een nieuwe koppeling met het WLAN alsof er een verbroken verbinding is en probeert opnieuw verbinding te maken vanaf nul. Dit kan om meerdere redenen gebeuren, zoals wanneer een client zich verwijdert van de dekkingsgebieden en vervolgens een toegangspunt vindt met voldoende signaalkwaliteit om een koppeling te starten, maar het geeft normaal gesproken een clientprobleem aan waarbij de client geen roaming-evenement initieert vanwege stuurprogramma's, firmware of softwareproblemen.
Opmerking: u kunt contact opnemen met de leverancier van de draadloze client om de oorzaak van het probleem vast te stellen.
Wanneer de SSID is geconfigureerd met L2-beveiliging op een hoger niveau bovenop de elementaire 802.11 Open System-verificatie, zijn er meer frames nodig voor de eerste koppeling en bij roaming. De twee meest gangbare beveiligingsmethoden die voor 802.11 WLAN's zijn gestandaardiseerd en geïmplementeerd, worden in dit document beschreven:
Het is belangrijk om te weten dat, hoewel deze twee methoden (PSK en EAP) de clients op verschillende manieren verifiëren / valideren, beide in principe dezelfde WPA / WPA2-regels gebruiken voor het sleutelbeheerproces.
Of de beveiliging nu WPA/WPA2-PSK of WPA/WPA2-EAP is, het proces dat bekend staat als de WPA/WPA2 4-weg handshake begint de belangrijkste onderhandeling tussen de WLC/AP en de client met een Master Session Key (MSK) als het originele sleutelmateriaal zodra de client is gevalideerd met de specifieke gebruikte verificatiemethode.
Hier is een samenvatting van het proces:
Wanneer WPA-PSK of WPA2-PSK wordt uitgevoerd via het Temporal Key Integrity Protocol (TKIP) of Advanced Encryption Standard (AES) voor de codering, moet de client het proces doorlopen dat bekend staat als de WPA 4-Way handshake voor zowel de eerste associatie als bij roaming. Zoals eerder uitgelegd, is dit in principe het sleutelbeheerproces dat wordt gebruikt om WPA / WPA2 de coderingssleutels af te leiden. Wanneer PSK wordt uitgevoerd, wordt het echter ook gebruikt om te controleren of de client over een geldige vooraf gedeelde sleutel beschikt om deel te nemen aan het WLAN. Deze afbeelding toont het initiële associatieproces wanneer WPA of WPA2 met PSK wordt uitgevoerd:
Na het 802.11 Open System-verificatie- en associatieproces zijn er vier EAPOL-frames van de WPA 4-Way handshake, die door het toegangspunt worden geïnitieerd met message-1, en door de client worden afgewerkt met message-4.
Na een succesvolle handshake begint de client dataframes (zoals DHCP) door te geven, die in dit geval worden gecodeerd met de sleutels die zijn afgeleid van de 4-Way handshake (daarom kunt u de werkelijke inhoud en het type verkeer van de draadloze afbeeldingen niet zien).
Opmerking: EAPOL-frames worden gebruikt om alle belangrijke beheerframes en 802.1X/EAP-verificatieframes over-the-air tussen het toegangspunt en de client te transporteren; ze worden verzonden als draadloze gegevensframes.
Deze berichten verschijnen in de debug uitgangen:
*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.
Bij roaming volgt de client in principe dezelfde frameuitwisseling, waarbij de WPA 4-Way handshake vereist is om nieuwe coderingssleutels af te leiden met het nieuwe toegangspunt.
Dit is te wijten aan beveiligingsredenen die door de standaard zijn vastgesteld en het feit dat het nieuwe toegangspunt de oorspronkelijke sleutels niet kent. Het enige verschil is dat er reassociatieframes zijn in plaats van associatieframes, zoals in deze afbeelding wordt getoond:
U ziet dezelfde berichten in de debug-uitgangen, maar het eerste pakket van de client is een reassociatie in plaats van een associatie, zoals eerder getoond en uitgelegd.
Wanneer een 802.1X/EAP-methode wordt gebruikt om de clients op een beveiligde SSID te verifiëren, zijn er nog meer frames nodig voordat de client verkeer begint door te geven.
Deze extra frames worden gebruikt om de clientreferenties te verifiëren en afhankelijk van de EAP-methode kunnen er tussen de vier en twintig frames zijn.
Deze komen na de Associatie / Reassociation, maar vóór de WPA / WPA2 4-Way handshake, omdat de authenticatiefase de MSK afleidt die wordt gebruikt als het zaad voor de uiteindelijke coderingssleutelgeneratie in het sleutelbeheerproces (4-Way handshake).
Deze afbeelding toont een voorbeeld van de frames die via de ether worden uitgewisseld tussen het toegangspunt en de draadloze client bij de eerste koppeling wanneer WPA met PEAPv0/EAP-MSCHAPv2 wordt uitgevoerd:
Soms toont deze uitwisseling meer of minder frames, wat afhankelijk is van meerdere factoren, zoals de EAP-methode, hertransmissies als gevolg van problemen, clientgedrag (zoals de twee identiteitsverzoeken in dit voorbeeld, omdat de client een EAPOL START verzendt nadat het toegangspunt het eerste identiteitsverzoek heeft verzonden), of als de client het certificaat al heeft uitgewisseld met de server. Wanneer de SSID is geconfigureerd voor een 802.1X/EAP-methode, zijn er meer frames (voor de verificatie) en daarom duurt het langer voordat de client gegevensframes begint te verzenden.
Hier is een samenvatting van de debug berichten:
*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.
Wanneer de draadloze client hier regelmatig zwerft (het normale gedrag, zonder implementatie van een snelle, veilige zwerfmethode), moet de client exact hetzelfde proces doorlopen en een volledige verificatie uitvoeren tegen de verificatieserver, zoals wordt weergegeven in de afbeeldingen. Het enige verschil is dat de klant een Reassociation Request gebruikt om het nieuwe toegangspunt te informeren dat het daadwerkelijk vanaf een ander toegangspunt zwerft, maar dat de klant nog steeds volledige validatie en nieuwe sleutelgeneratie moet doorlopen:
Zoals blijkt, moeten, zelfs wanneer er minder frames zijn dan in de eerste verificatie (die wordt veroorzaakt door meerdere factoren, zoals eerder vermeld), wanneer de client naar een nieuw toegangspunt zwerft, de EAP-verificatie en de WPA-sleutelbeheerprocessen nog steeds worden voltooid om dataframes te blijven passeren (zelfs als verkeer actief is verzonden vóór roaming). Als de client een actieve toepassing heeft die gevoelig is voor vertragingen (zoals toepassingen voor spraakverkeer of toepassingen die gevoelig zijn voor time-outs), kan de gebruiker problemen waarnemen bij roaming, zoals audioplekken of het verbreken van de verbinding van de toepassing. Dit hangt af van hoe lang het proces duurt voordat de klant gegevensframes blijft verzenden/ontvangen. Deze vertraging kan langer zijn, afhankelijk van: de RF-omgeving, het aantal clients, de retourtijd tussen de WLC en LAP's en met de verificatieserver en andere redenen.
Hier is een samenvatting van de debug-berichten voor dit roaming-evenement (in principe hetzelfde als de vorige, dus deze berichten worden niet verder beschreven):
*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
Dit is de manier waarop 802.1X/EAP en het WPA/WPA2-beveiligingskader werken. Om te voorkomen dat de toepassing/service gevolgen heeft voor vertragingen van een regulier roamingevenement, worden meerdere snel beveiligde roamingmethoden ontwikkeld en geïmplementeerd door de WiFi-industrie om het roamingproces te versnellen wanneer beveiliging wordt gebruikt op de WLAN/SSID. De clients hebben te maken met enige latentie wanneer ze verkeer blijven doorgeven terwijl ze rondzwerven tussen toegangspunten via de implementatie van beveiliging op hoog niveau op het WLAN. Dit is te wijten aan de EAP-verificatie en sleutelbeheerframeuitwisselingen die vereist zijn voor de beveiligingsconfiguratie, zoals eerder uitgelegd.
Het is belangrijk om te begrijpen dat snel beveiligde roaming slechts de term is die door de sector wordt gebruikt met betrekking tot de implementatie van een methode / schema dat het roamingproces versnelt wanneer de beveiliging op het WLAN wordt geconfigureerd. In de volgende sectie wordt uitgelegd welke verschillende methoden/schema's voor snel beveiligde roaming beschikbaar zijn voor WLAN's en worden ondersteund door de CUWN.
Cisco Centralized Key Management (CCKM) is de eerste snelle en veilige roamingmethode die is ontwikkeld en geïmplementeerd op WLAN's voor bedrijven, ontwikkeld door Cisco als de oplossing die wordt gebruikt om de tot nu toe verklaarde vertragingen te beperken wanneer 802.1X/EAP-beveiliging wordt gebruikt op het WLAN. Aangezien dit een Cisco-protocol is, wordt het alleen ondersteund door Cisco WLAN-infrastructuurapparaten en draadloze clients (van meerdere leveranciers) die compatibel zijn met Cisco Compatible Extension (CCX) voor CCKM.
CCKM kan worden geïmplementeerd met alle verschillende coderingsmethoden die beschikbaar zijn voor WLAN's, waaronder: WEP, TKIP en AES. Het wordt ook ondersteund met de meeste 802.1X/EAP-verificatiemethoden die voor WLAN's worden gebruikt, afhankelijk van de CCX-versie die door de apparaten wordt ondersteund.
Opmerking: voor een overzicht van de inhoud van de functies die wordt ondersteund door de verschillende versies van de CCX-specificatie (inclusief ondersteunde EAP-methoden), raadpleegt u het document CCX-versies en functies en controleert u de exacte CCX-versie die wordt ondersteund door uw draadloze clients (als deze CCX-compatibel zijn), zodat u kunt bevestigen of de beveiligingsmethode die u met CCKM wilt gebruiken, kan worden geïmplementeerd.
Dit draadloze image geeft een voorbeeld van de frames die bij de eerste koppeling worden uitgewisseld wanneer u CCKM uitvoert met TKIP als codering en PEAPv0/EAP-MSCHAPv2 als 802.1X/EAP-methode. Dit is in principe dezelfde uitwisseling als wanneer WPA/TKIP met PEAPv0/EAP-MSCHAPv2 wordt uitgevoerd, maar deze keer wordt er onderhandeld over CCKM tussen de client en de infrastructuur, zodat ze verschillende sleutelhiërarchie en cachemethoden gebruiken om Fast Secure Roaming uit te voeren wanneer de client moet roamen:
Hier is een samenvatting van de foutopsporingsberichten (waarbij sommige EAP-uitwisselingen zijn verwijderd om de uitvoer te verminderen):
*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.
Met CCKM is de initiële koppeling aan het WLAN vergelijkbaar met de reguliere WPA/WPA2, waarbij een MSK (ook hier bekend als de Network Session Key (NSK)) wederzijds wordt afgeleid met de client en de RADIUS-server.
Deze primaire sleutel wordt na een succesvolle verificatie van de server naar de WLC verzonden en wordt in de cache opgeslagen als basis voor de afleiding van alle volgende sleutels voor de levensduur van de clientkoppeling met dit WLAN.
Van hieruit halen de WLC en de client de seed-informatie die wordt gebruikt voor snel beveiligde roaming op basis van CCKM, dit gaat door een 4-Way handshake vergelijkbaar met die van WPA / WPA2, om de unicast (PTK) en multicast / broadcast (GTK) -coderingssleutels af te leiden met het eerste AP.
Het grote verschil wordt opgemerkt bij roaming. In dit geval stuurt de CCKM-client één frame voor het verzoek om herkoppeling naar het AP/WLC (dat een MIC en een opeenvolgend toenemend willekeurig nummer bevat) en biedt voldoende informatie (waaronder het nieuwe AP MAC-adres -BSSID-) om de nieuwe PTK af te leiden. Met dit Reassociation Request hebben de WLC en de nieuwe AP ook voldoende informatie om de nieuwe PTK af te leiden, dus ze reageren gewoon met een Reassociation Response. De client kan nu doorgaan met het doorgeven van verkeer, zoals weergegeven in deze afbeelding:
Hier is een samenvatting van de WLC-debugs voor dit roaming-evenement:
*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.
Zoals te zien is, wordt snel beveiligd zwerven uitgevoerd terwijl de EAP-verificatieframes worden vermeden en nog meer 4-weg handshakes, omdat de nieuwe coderingssleutels nog steeds zijn afgeleid, maar gebaseerd op het CCKM-onderhandelingsschema.
Dit wordt aangevuld met de roaming reassociation frames en de informatie die eerder in de cache is opgeslagen door de klant en de WLC.
Paarsgewijs denken dat Key ID (PMKID) caching, of Sticky Key Caching (SKC), de eerste snel beveiligde roamingmethode is die wordt voorgesteld door de IEEE 802.11-standaard binnen de 802.11i-beveiligingswijziging, waarbij het belangrijkste doel is om een hoog beveiligingsniveau voor WLAN's te standaardiseren. Deze snel beveiligde roamingtechniek werd toegevoegd als een optionele methode voor WPA2-apparaten om roaming te verbeteren toen deze beveiliging werd geïmplementeerd.
Dit is mogelijk omdat, elke keer dat een client volledig EAP-geverifieerd is, de client en de verificatieserver een MSK afleiden, die wordt gebruikt om de PMK af te leiden.
Deze methode wordt gebruikt als de kiem voor de WPA2 4-Way handshake om de uiteindelijke unicast-coderingssleutel (PTK) af te leiden die voor de sessie wordt gebruikt (totdat de client naar een ander toegangspunt zwerft of de sessie verloopt); daarom voorkomt deze methode de EAP-verificatiefase bij zwerven omdat de oorspronkelijke PMK die door de client en het toegangspunt in de cache is opgeslagen, opnieuw wordt gebruikt. De client hoeft alleen de WPA2 4-Way handshake te doorlopen om nieuwe coderingssleutels af te leiden.
Deze methode wordt niet op grote schaal toegepast als de aanbevolen 802.11 standaard snelle veilige roamingmethode, voornamelijk om deze redenen:
Met deze methode is de eerste koppeling aan een toegangspunt net als een gewone eerste verificatie aan het WLAN, waarbij de volledige 802.1X/EAP-verificatie tegen de verificatieserver en de 4-voudige handshake voor het genereren van sleutels moeten plaatsvinden voordat de client gegevensframes kan verzenden, zoals wordt weergegeven in deze schermafbeelding:
De debugs onthullen dezelfde EAP-authenticatieframeuitwisseling als de rest van de methoden bij de eerste verificatie naar het WLAN, met enkele uitgangen toegevoegd met betrekking tot de belangrijkste cachingtechnieken die hier worden gebruikt.
Deze debug-uitgangen worden geknipt om voornamelijk de nieuwe informatie weer te geven, niet de volledige EAP-frameuitwisseling, omdat in principe elke keer dezelfde informatie wordt uitgewisseld voor verificatie van de client tegen de verificatieserver.
Dit is tot nu toe aangetoond en gecorreleerd met de EAP-verificatieframes die in de pakketafbeeldingen worden weergegeven, dus de meeste EAP-berichten worden voor de eenvoud uit de debug-uitgangen verwijderd:
*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.
Met deze methode worden de PMK's van de reeds bestaande beveiligde verbindingen door het toegangspunt en de draadloze client in cache opgeslagen.
Als de draadloze client zwerft naar een nieuw toegangspunt waaraan hij nooit is gekoppeld, moet de client daarom opnieuw een volledige EAP-verificatie uitvoeren, zoals wordt weergegeven in deze afbeelding waarin de client zwerft naar een nieuw toegangspunt:
Als de draadloze client echter terugzwerft naar een toegangspunt waar een eerdere koppeling/verificatie heeft plaatsgevonden, verzendt de client een frame voor een herassociatieverzoek waarin meerdere PMKID's worden vermeld. Dit frame informeert het toegangspunt over de PMK's die in de cache zijn opgeslagen van alle toegangspunten waarvoor de client eerder een verificatie heeft uitgevoerd. Aangezien de client terugzwerft naar een toegangspunt dat ook een PMK in de cache voor deze client heeft, hoeft de client zich niet opnieuw te verifiëren via EAP om een nieuwe PMK af te leiden. De client gaat gewoon door de WPA2 4-Way handshake om de nieuwe transiënte encryptiesleutels af te leiden:
Opmerking: deze afbeelding toont niet het eerste 802.11 Open System-verificatieframe van de client, maar dit is niet te wijten aan de geïmplementeerde methode, omdat dit frame altijd vereist is. De reden hiervoor is dat dit specifieke frame niet wordt afgebeeld door de adapter of de software voor draadloze pakketafbeeldingen die wordt gebruikt om de over-the-air-frames voor dit voorbeeld te snuiven, maar het wordt zo achtergelaten in het voorbeeld voor educatieve doeleinden. Houd er rekening mee dat dit mogelijk kan gebeuren wanneer u over-the-air pakketafbeeldingen uitvoert; sommige frames kunnen door de afbeelding worden gemist, maar worden daadwerkelijk uitgewisseld tussen de client en het toegangspunt. Anders begint de roaming nooit op dit voorbeeld.
Hier is een samenvatting van de WLC-debugs voor deze snelle veilige roamingmethode:
*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
Deze methode kan lokaal worden geïmplementeerd door autonome onafhankelijke AP's, zonder dat een gecentraliseerd apparaat nodig is om de sleutels in de cache te beheren.
Opportunistic Key Caching (OKC), ook bekend als Proactive Key Caching (PKC) (deze term wordt nader toegelicht in een notitie die hierna volgt), is in principe een verbetering van de eerder beschreven WPA2 PMKID-caching-methode, daarom wordt het ook Proactive / Opportunistic PMKID Caching genoemd. Daarom is het belangrijk op te merken dat dit geen snelle veilige roamingmethode is die wordt gedefinieerd door de 802.11-standaard en niet door veel apparaten wordt ondersteund, maar net als PMKID-caching werkt het met WPA2-EAP.
Met deze techniek kunnen de draadloze client en de WLAN-infrastructuur slechts één PMK cachen voor de levensduur van de clientkoppeling met dit WLAN (afgeleid van de MSK na de eerste 802.1X/EAP-verificatie met de verificatieserver), zelfs wanneer zwerven tussen meerdere AP's, omdat ze allemaal de oorspronkelijke PMK delen die wordt gebruikt als het zaad op alle WPA2 4-weg handshakes. Dit is nog steeds vereist, net als in SKC, om telkens nieuwe coderingssleutels te genereren wanneer de client opnieuw wordt gekoppeld aan de toegangspunten. Om deze ene originele PMK van de cliensessie te kunnen delen, moeten alle AP's onder een soort van administratieve controle staan, met een gecentraliseerd apparaat dat de originele PMK voor alle AP's in cache opslaat en distribueert. Dit is vergelijkbaar met de CUWN, waar de WLC deze taak uitvoert voor alle LAP's onder zijn controle en de mobiliteitsgroepen gebruikt om deze PMK tussen meerdere WLC's af te handelen; daarom is dit een beperking op autonome AP-omgevingen.
Met deze methode is, net als in PMKID Caching (SKC), de eerste koppeling aan een toegangspunt een regelmatige eerste verificatie naar het WLAN, waarbij u de volledige 802.1X/EAP-verificatie moet voltooien tegen de verificatieserver en de 4-weg handshake voor het genereren van sleutels voordat u gegevensframes kunt verzenden. Hier is een schermafbeelding die dit illustreert:
De debug-uitgangen tonen in principe dezelfde EAP-authenticatieframeuitwisseling als de rest van de methoden die in dit document worden beschreven bij de eerste verificatie naar het WLAN (zoals weergegeven in de afbeeldingen), samen met de toevoeging van enkele uitgangen die betrekking hebben op de belangrijkste cachingtechnieken die hier door de WLC worden gebruikt. Deze debug-uitvoer wordt ook gesneden om alleen de relevante informatie weer te geven:
*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
Met deze methode wordt de oorspronkelijke PMK van de beveiligde koppeling die in eerste instantie is gemaakt, in cache opgeslagen door de draadloze client en de WLC (voor alle beheerde toegangspunten). Elke keer dat de draadloze client verbinding maakt met een specifiek toegangspunt, wordt een PMKID gehasht op basis van: het MAC-adres van de client, het MAC-adres van het toegangspunt (BSSID van het WLAN) en de PMK die met dat toegangspunt is afgeleid. Aangezien OKC dezelfde oorspronkelijke PMK voor alle AP's en de specifieke client in de cache opslaat, is de enige waarde die verandert om de nieuwe PMKID te hashen het nieuwe AP MAC-adres wanneer deze client (opnieuw) aan een ander AP wordt gekoppeld.
Wanneer de client roaming initieert naar een nieuw toegangspunt en het frame voor het verzoek om herkoppeling verzendt, voegt de client de PMKID toe aan het WPA2 RSN-informatie-element als deze het toegangspunt wil informeren dat een PMK in de cache wordt gebruikt voor snel beveiligde roaming. Het weet al het MAC-adres van de BSSID (AP) voor waar het zwerft, dan hasht de client gewoon de nieuwe PMKID die wordt gebruikt op dit Reassociation Request. Wanneer het toegangspunt dit verzoek van de client ontvangt, hasht het ook de PMKID met de waarden die het al heeft (de PMK in de cache, het MAC-adres van de client en het eigen MAC-adres van het toegangspunt) en reageert het met de succesvolle Reassociation Response die bevestigt dat de PMKID's zijn gekoppeld. De PMK in de cache kan worden gebruikt als het zaad dat een WPA2 4-Way handshake start om de nieuwe encryptiesleutels af te leiden (en EAP over te slaan):
In deze afbeelding wordt het frame Reassociation Request van de client geselecteerd en uitgebreid, zodat u meer details van het frame kunt zien. De MAC-adresinformatie en ook het informatie-element Robuust Security Network (RSN, volgens 802.11i - WPA2), waar informatie over de WPA2-instellingen die voor deze koppeling worden gebruikt, wordt weergegeven (gemarkeerd is de PMKID verkregen uit de gehashte formule).
Hier is een samenvatting van WLC-debugs voor deze snelle veilige roamingmethode met 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
Zoals getoond aan het begin van de debugs, moet de PMKID worden berekend nadat het Reassociation Request van de client is ontvangen.
Dit is nodig om de PMKID te valideren en te bevestigen dat de in de cache opgeslagen PMK wordt gebruikt met de WPA2 4-Way handshake om de coderingssleutels af te leiden en de snel beveiligde roaming te voltooien.
Verwar de CCKM-vermeldingen op de debugs niet; dit wordt niet gebruikt om CCKM uit te voeren, maar OKC, zoals eerder uitgelegd.
CCKM is hier gewoon een naam die door de WLC wordt gebruikt voor die uitgangen, zoals de naam van een functie die de waarden verwerkt om de PMKID te berekenen.
Opmerking: deze installatie kan werken als de toegangspunten zich niet in dezelfde FlexConnect-groep bevinden, maar dit is geen aanbevolen of ondersteunde installatie.
Proactieve Key Caching (of PKC) staat bekend als OKC (Opportunistische Key Caching) en de twee termen worden door elkaar gebruikt wanneer ze dezelfde methode beschrijven die hier wordt uitgelegd.
Dit was echter slechts een term die in 2001 door Airspace werd gebruikt voor een oude cachingmethode voor sleutels, die vervolgens werd gebruikt door de 802.11i-standaard als basis voor "pre-authenticatie" (een andere Fast Secure Roaming-methode wordt hieronder kort uitgelegd).
PKC is geen pre-authenticatie of OKC (Opportunistic Key Caching), maar als je over PKC hoort of leest, is de verwijzing in principe naar OKC en niet naar pre-authenticatie.
Deze methode wordt ook voorgesteld door de IEEE 802.11-standaard binnen het 802.11i-beveiligingsamendement, dus het werkt ook met WPA2, maar het is de enige Fast Secure Roaming-methode die niet wordt ondersteund door Cisco WLAN-infrastructuur.
Om deze reden wordt het hier slechts kort uitgelegd en zonder uitgangen.
Met Preauthenticatie kunnen de draadloze clients met meerdere toegangspunten tegelijk worden geverifieerd terwijl ze aan het huidige toegangspunt zijn gekoppeld.
Wanneer dit gebeurt, verzendt de client de EAP-verificatieframes naar het huidige toegangspunt waarop deze is aangesloten, maar deze zijn bestemd voor het (de) andere toegangspunt(en) waar de client Preauthenticatie wil uitvoeren (naburige toegangspunten die mogelijk kandidaat zijn voor roaming). Het huidige toegangspunt verzendt deze frames naar de doeltoegangspunten via het distributiesysteem. Het nieuwe toegangspunt voert volledige verificatie uit ten opzichte van de RADIUS-server voor deze client, zodat een volledige nieuwe EAP-verificatie-handshake is voltooid en dit nieuwe toegangspunt fungeert als de verificator.
Het idee is om authenticatie uit te voeren en PMK af te leiden met de naburige AP's voordat de client daadwerkelijk naar hen zwerft, dus wanneer het tijd is om te zwerven, is de client al geverifieerd en met een PMK al in de cache voor deze nieuwe AP-naar-client beveiligde associatie, dus ze hoeven alleen de 4-weg handshake uit te voeren en een snelle zwerftocht te ervaren nadat de client zijn eerste Reassociation-verzoek heeft verzonden.
Hier is een afbeelding van een AP-baken dat het RSN IE-veld toont dat reclame maakt voor ondersteuning voor Preauthenticatie (deze afbeelding is van een Cisco AP, waar wordt bevestigd dat Preauthenticatie niet wordt ondersteund):
Er is één PMK voor elke AP-naar-client beveiligde koppeling, die kan worden beschouwd als een beveiligingsvoordeel in het geval dat een AP wordt aangetast en de sleutels worden gestolen (kan niet worden gebruikt met andere AP's). Dit beveiligingsvoordeel wordt echter op verschillende manieren door de WLAN-infrastructuur afgehandeld op andere methoden.
De snel beveiligde roamingtechniek op basis van het 802.11r-amendement (officieel Fast BSS Transition genoemd door de 802.11-standaard en bekend als FT) is de eerste methode die officieel is geratificeerd (op 2008) door de IEEE voor de 802.11-standaard als de oplossing voor het uitvoeren van snelle overgangen tussen AP's (Basic Service Sets of BSS's), die duidelijk de sleutelhiërarchie definieert die wordt gebruikt wanneer u sleutels op een WLAN verwerkt en cachet. De goedkeuring ervan verliep echter traag, voornamelijk vanwege de andere oplossingen die al beschikbaar waren toen snelle overgangen daadwerkelijk nodig waren, zoals bij VoWLAN-implementaties wanneer deze werden gebruikt met een van de methoden die eerder in dit document werden uitgelegd. Er zijn slechts een paar apparaten die momenteel een aantal van de FT-opties ondersteunen (tegen 2013).
Deze techniek is complexer uit te leggen dan de andere methoden, omdat het nieuwe concepten en meerdere lagen PMK's introduceert die op verschillende apparaten in de cache worden opgeslagen (elk apparaat met een andere rol) en biedt nog meer opties voor snel beveiligd zwerven. Daarom wordt een korte samenvatting gegeven over deze methode en de manier waarop deze wordt geïmplementeerd met elke beschikbare optie.
802.11r verschilt van SKC en OKC, voornamelijk om deze redenen:
Met deze methode voert de draadloze client slechts één initiële verificatie uit ten opzichte van de WLAN-infrastructuur wanneer een verbinding met het eerste toegangspunt tot stand wordt gebracht, en voert deze een snelle en veilige roaming uit tijdens roaming tussen toegangspunten van hetzelfde FT-mobiliteitsdomein.
Dit is een van de nieuwe concepten, die in principe verwijst naar de toegangspunten die dezelfde SSID gebruiken (bekend als een Extended Service Set of ESS) en dezelfde FT-sleutels verwerken.
Dit is vergelijkbaar met de andere methoden die tot nu toe zijn uitgelegd. De manier waarop de AP's omgaan met de FT-mobiliteitsdomeinsleutels is normaal gesproken gebaseerd op een gecentraliseerde setup, zoals de WLC of mobiliteitsgroepen; deze methode kan echter ook worden geïmplementeerd op autonome AP-omgevingen.
Hier is een samenvatting van de belangrijkste hiërarchie:
Opmerking: afhankelijk van de WLAN-leverancier en de implementatiesetups (zoals Autonomous AP's, FlexConnect of Mesh) kan de WLAN-infrastructuur de sleutels op een andere manier overdragen en verwerken. Het kan zelfs de rollen van de sleutelhouders veranderen, maar omdat dat buiten het bestek van dit document valt, zijn de voorbeelden op basis van de eerder gegeven samenvatting van de sleutelhiërarchie de volgende focus. De verschillen zijn eigenlijk niet zo relevant om het proces te begrijpen, tenzij je de infrastructuurapparaten (en hun code) echt grondig moet analyseren om een softwareprobleem te ontdekken.
Bij deze methode is de eerste koppeling aan een toegangspunt een regelmatige eerste verificatie van het WLAN, waarbij de volledige 802.1X/EAP-verificatie tegen de verificatieserver en de 4-voudige handshake voor het genereren van sleutels moeten plaatsvinden voordat gegevensframes worden verzonden, zoals wordt weergegeven in deze schermafbeelding:
De belangrijkste verschillen zijn:
De debugs tonen in principe dezelfde EAP-authenticatieframeuitwisseling als de rest van de methoden bij de eerste verificatie naar het WLAN (zoals opgemerkt in de afbeeldingen), maar sommige uitgangen die betrekking hebben op de belangrijkste cachingtechnieken die door de WLC worden gebruikt, worden toegevoegd; dus wordt deze debug-uitvoer gesneden om alleen de relevante informatie weer te geven:
*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.
Opmerking: om deze methode te debuggen en de extra 802.11r / FT-uitgangen te bereiken die hier worden weergegeven, is een extra debug ingeschakeld samen met de debug-client, die de debug ft-gebeurtenissen inschakelen.
Hier zijn de afbeeldingen en foutopsporingen van een eerste koppeling met het WLAN wanneer u FT uitvoert met WPA2-PSK (in plaats van een 802.1X/EAP-methode), waarbij het associatieresponsframe van het toegangspunt is geselecteerd om het Fast BSS Transition Information Element (gemarkeerd) weer te geven. Enkele van de belangrijkste informatie die nodig is om de FT 4-Way handshake uit te voeren wordt ook getoond:
*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
Met 802.11r is de eerste koppeling aan het WLAN de basis die wordt gebruikt om de basissleutels af te leiden die door deze techniek worden gebruikt, net als bij de andere snel beveiligde roamingmethoden.
De belangrijkste verschillen komen wanneer de client begint te zwerven; FT vermijdt niet alleen 802.1X / EAP wanneer dit wordt gebruikt, maar het voert zelfs een efficiëntere zwerfmethode uit die de initiële 802.11 Open System Authentication en Reassociation-frames combineert (die altijd worden gebruikt en vereist bij roaming tussen AP's) om FT-informatie uit te wisselen en nieuwe dynamische coderingssleutels af te leiden in plaats van de 4-Way handshake.
De volgende afbeelding toont de frames die worden uitgewisseld wanneer een Fast BSS Transition Over-the-Air met 802.1X/EAP-beveiliging wordt uitgevoerd. Het Open System Authentication-frame van de client naar het toegangspunt wordt geselecteerd om de FT-protocolinformatie-elementen te zien die nodig zijn om de FT-sleutelonderhandeling te starten. Dit wordt gebruikt om de nieuwe PTK af te leiden met de nieuwe AP (gebaseerd op de PMK-R1). Het veld met het verificatiealgoritme wordt gemarkeerd om aan te geven dat deze client geen eenvoudige Open System Authentication uitvoert, maar een Fast BSS Transition:
Hier zijn de foutopsporingsuitgangen van de WLC wanneer dit FT-roamingevenement plaatsvindt met 802.1X/EAP:
*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
Hier is een afbeelding die een Fast BSS Transition Over-the-Air met WPA2-PSK-beveiliging laat zien, waarbij het definitieve Reassociation Response-frame van het toegangspunt naar de client wordt geselecteerd om meer details over deze FT-uitwisseling te tonen:
Hier zijn de foutopsporingsuitgangen wanneer deze FT-roaminggebeurtenis plaatsvindt met PSK, die vergelijkbaar zijn met die wanneer 802.1X/EAP wordt gebruikt:
*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
Zoals in de afbeelding te zien is, worden de vier frames die worden gebruikt en vereist voor roaming (Open systeemverificatie van de client, Open systeemverificatie van het toegangspunt, Reassociation Request en Reassociation Response), zodra de Fast BSS-overgang is onderhandeld bij de eerste koppeling met het WLAN, in principe gebruikt als een FT 4-weg handshake om de nieuwe PTK (unicast-coderingssleutel) en GTK (multicast/broadcast-coderingssleutel) af te leiden.
Dit vervangt de 4-Way handshake die normaal optreedt nadat deze frames zijn uitgewisseld, en de FT-inhoud en de belangrijkste onderhandeling op deze frames is in principe hetzelfde, of u nu 802.1X / EAP of PSK gebruikt als de beveiligingsmethode. Zoals in de afbeelding te zien is, is het AKM-veld het belangrijkste verschil, wat bevestigt of de client FT met PSK of 802.1X uitvoert. Daarom is het belangrijk op te merken dat deze vier frames normaal gesproken niet over dit type beveiligingsinformatie beschikken voor belangrijke onderhandelingen, maar alleen wanneer client FT-roams uitvoeren als 802.11r wordt geïmplementeerd en onderhandeld tussen de client en de WLAN-infrastructuur bij de eerste associatie.
802.11r maakt een andere implementatie van Fast BSS Transition mogelijk, waarbij de FT-roaming door de client wordt geïnitieerd met het nieuwe AP waarvoor de client over-the-DS (distributiesysteem) zwerft en niet over-the-air. In dit geval worden FT-actieframes gebruikt om de belangrijkste onderhandeling te starten in plaats van de Open System Authentication-frames.
Kortom, zodra de client besluit dat hij naar een beter toegangspunt kan zwerven, verzendt de client een FT Action Request-frame naar het oorspronkelijke toegangspunt waar het momenteel is verbonden voordat het zwerft. De client geeft de BSSID (MAC-adres) van het doel-AP aan waar het wil roamen. Het oorspronkelijke AP stuurt dit FT Action Request-frame door naar het doel-AP via het distributiesysteem (normaal gesproken de bekabelde infrastructuur) en het doel-AP reageert op de client met een FT Action Response-frame (ook over de DS, zodat het het eindelijk over-the-air naar de client kan sturen). Zodra deze uitwisseling van FT-actieframes succesvol is, voltooit de client de FT-roaming; de client verzendt het verzoek om herkoppeling naar het doel-AP (dit keer over-the-air) en ontvangt een Reassociation-antwoord van het nieuwe AP om de afleiding van de roaming- en eindsleutels te bevestigen.
Samengevat zijn er vier frames om te onderhandelen over Fast BSS Transition en om nieuwe coderingssleutels af te leiden, maar hier worden de Open System Authentication-frames vervangen door de FT Action Request/Response-frames, die met het doel-AP over het distributiesysteem worden uitgewisseld met het huidige AP. Deze methode is ook geldig voor beide beveiligingsmethoden 802.1X/EAP en PSK, die allemaal worden ondersteund door de draadloze LAN-controllers van Cisco. Aangezien deze Over-the-DS-overgang echter niet wordt ondersteund en geïmplementeerd door de meeste draadloze clients in de WiFi-industrie (en omdat de uitvoer voor het uitwisselen van frames en debuggen in principe hetzelfde is), worden in dit document geen voorbeelden gegeven. In plaats daarvan wordt deze afbeelding gebruikt om de Fast BSS Transition Over-the-DS te visualiseren:
Om dit te overwinnen, heeft Cisco Wireless LAN-infrastructuur de Adaptive 802.11r-functie geïntroduceerd. Als de FT-modus is ingesteld op Adaptive op WLAN-niveau, wordt in WLAN-advertenties de 802.11r Mobility Domain ID weergegeven op een WLAN met 802.11i. Sommige Apple iOS10-clientapparaten identificeren de aanwezigheid van MDIE op een 80211i/WPA2 WLAN en doen een eigen handshake om een 802.11r-koppeling tot stand te brengen. Zodra de client een succesvolle 802.11r-koppeling heeft voltooid, kan deze FT-roaming uitvoeren zoals in een normaal 802.11r-WLAN. De FT Adaptive is alleen van toepassing op geselecteerde Apple iOS10- (en nieuwere) apparaten. Alle andere clients kunnen de 802.11i/WPA2-koppeling op het WLAN blijven gebruiken en de toepasselijke FSR-methode uitvoeren zoals wordt ondersteund.
Meer documentatie over deze nieuwe functie die is geïntroduceerd voor iOS10-apparaten om 802.11r uit te voeren op een WLAN/SSID waarop 802.11r niet echt is ingeschakeld (zodat andere niet-802.11r-clients met succes verbinding kunnen maken), is te vinden in Best Practices voor Cisco IOS-apparaten voor Cisco op Cisco Wireless LAN.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
2.0 |
09-Feb-2023
|
Bijgewerkt formaat en geverifieerde technische informatie. Hercertificering. |
1.0 |
02-Sep-2013
|
Eerste vrijgave |