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.
Dit document beschrijft draadloze en snel beveiligde roamingtypen 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 Software voor Cisco WLAN-controller, 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 de softwareversie 7.4 van Cisco WLAN-controllers, maar de meeste van de beschreven debug-uitgangen en -gedrag kunnen van toepassing zijn op elke softwareversie die de besproken methoden ondersteunt. De specificaties van alle methoden die hier worden uitgelegd, blijven hetzelfde bij latere codes van Cisco WLAN-controllers (tot versie 8.3 tegen de tijd dat dit artikel is bijgewerkt).
Dit document beschrijft de verschillende typen draadloze roaming- en snel beveiligde roamingmethoden die beschikbaar zijn voor IEEE 802.11 draadloze LAN’s (WLAN’s) die worden ondersteund op het Cisco Unified Wireless Network (CUWN).
Het document bevat niet alle details over de manier waarop elke methode werkt of hoe deze zijn geconfigureerd. Het belangrijkste doel van dit document is om de verschillen te beschrijven tussen de verschillende beschikbare technieken, hun voordelen en beperkingen, en de frames-uitwisseling op elke methode. Er worden voorbeelden van WLAN-controllers (WLC) geboden en draadloze pakketafbeeldingen worden gebruikt om de gebeurtenissen te analyseren en uit te leggen die voor elke beschreven zwervende methode optreden.
Alvorens een beschrijving van de verschillende snel-veilige het zwerven methodes beschikbaar voor WLANs wordt gegeven, is het belangrijk om te begrijpen hoe het WLAN associatieproces werkt, en hoe een regelmatige het zwerven gebeurtenis voorkomt wanneer er geen veiligheid die op het Vastgestelde Herkenningsteken van de Dienst (SSID) wordt gevormd is.
Wanneer een 802.11 draadloze client verbinding maakt met een access point (AP), moet deze eerst het 802.11 Open System-verificatieproces doorstaan voordat er verkeer (draadloze datakaders) wordt doorgegeven. Vervolgens moet het associatieproces worden voltooid. Het verificatieproces voor het Open System is vergelijkbaar met een kabelverbinding op het toegangspunt dat door de client wordt geselecteerd. Dit is een heel belangrijk punt, omdat het altijd de draadloze client is die selecteert welke AP wordt geprefereerd, en de beslissing baseert op meerdere factoren die variëren tussen leveranciers. Daarom begint de client met dit proces door het verificatiekader naar het geselecteerde toegangspunt te verzenden, zoals later in dit document wordt getoond. Het toegangspunt kan niet vragen of u een verbinding wilt maken.
Zodra het Open System-verificatieproces met succes is voltooid met een respons van het AP ("met kabel verbonden"), voltooit het associatieproces in wezen de 802.11 Layer 2 (L2)-onderhandeling die de koppeling tussen de client en het AP tot stand brengt. AP wijst een vereniging-ID toe aan de client als de verbinding succesvol is, en bereidt deze voor om verkeer over te gaan of om een beveiligingsmethode op een hoger niveau uit te voeren indien geconfigureerd op de SSID. Het verificatieproces van het Open System bestaat uit twee beheerframes en het associatieproces. Verificatie- en associatiekaders zijn draadloze beheerframes, geen gegevenskaders, die in principe de frames zijn die worden gebruikt voor het verbindingsproces met het AP.
Hier is een afbeelding van de draadloze frames via de lucht voor dit proces:
Opmerking: als u meer wilt weten over 802.11 draadloze snuffelen en over de filters/kleuren die op Wireshark worden gebruikt voor de afbeeldingen die in dit document worden weergegeven, gaat u naar de Cisco Support Community-post met de naam 802.11 Sniffer image Analysis.
De draadloze client begint met het verificatiekader en de AP antwoordt met een ander verificatiekader. De client verstuurt vervolgens het Associatie-verzoekframe en de AP eindigt in een antwoord met het Associatie-responsframe. Zoals wordt getoond in de DHCP-pakketten, begint de client, zodra de 802.11 Open System-verificatie- en associatieprocessen zijn doorgegeven, gegevenskaders te verzenden. In dit geval is er geen beveiligingsmethode geconfigureerd op de SSID, zodat de client onmiddellijk begint met het verzenden van gegevenskaders (in dit geval DHCP) die niet zijn versleuteld.
Zoals later in dit document wordt getoond, als de beveiliging op de SSID is ingeschakeld, zijn er hogere handshake-frames voor verificatie en codering voor de specifieke beveiligingsmethode, net nadat de Association Response en voorafgaand aan het verzenden van datakaders van clientverkeer zijn verzonden, zoals DHCP, Address Resolution Protocol (ARP) en applicatiepakketten, die zijn versleuteld. De kaders van gegevens kunnen slechts worden verzonden tot de cliënt volledig voor authentiek wordt verklaard, en de encryptiesleutels worden besproken, gebaseerd op de gevormde veiligheidsmethode.
Gebaseerd op het vorige beeld, zijn hier de berichten die u in de output van WLC ziet debug cliëntbevel wanneer de draadloze cliënt met een nieuwe vereniging aan WLAN begint:
*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: de WLC debug gebruikt voor de outputs in dit document is de debug client opdracht, en de voorbeelden tonen alleen enkele relevante berichten, niet de gehele output. Voor meer informatie over deze debug-opdracht raadpleegt u het document Understand the Debug Client on Wireless LAN Controllers (WLC’s).
Deze berichten tonen de Associatie Vraag- en Reactieframes; de eerste Verificatieframes worden niet vastgelegd bij de WLC omdat deze handdruk snel gebeurt op het AP-niveau op de CUWN.
Welke informatie verschijnt wanneer de klant zwerft? De klant ruilt altijd vier beheerframes bij het instellen van een verbinding met een AP, die te wijten is aan hetzij de vestiging van de klant van vereniging, of een roaming-gebeurtenis. De client heeft slechts één verbinding met slechts één toegangspunt tegelijk. Het enige verschil in de kaderuitwisseling tussen een nieuwe verbinding aan de WLAN-infrastructuur en een zwervende gebeurtenis is dat de associatieframes van een zwervende gebeurtenis Reassociation-frames worden genoemd, wat aangeeft dat de client eigenlijk zwerft van een andere AP zonder pogingen om een nieuwe associatie met het WLAN te creëren. Deze frames kunnen verschillende elementen bevatten die worden gebruikt om te onderhandelen over de roaminggebeurtenis; dit hangt af van de installatie, maar die details vallen buiten het bereik van dit document.
Hier is een voorbeeld van de frameuitwisseling:
Deze berichten verschijnen in de debug uitvoer:
*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 getoond, voert de client met succes een zwervende gebeurtenis uit nadat het Reassociation-verzoek naar het nieuwe toegangspunt is verzonden, en ontvangt de Reassociation Response van het toegangspunt. Aangezien de client al een IP-adres heeft, zijn de eerste gegevenskaders bestemd voor ARP-pakketten.
Als u een roamende gebeurtenis verwacht, maar de client stuurt een associatie-verzoek in plaats van een reassociatie-verzoek (dat u kunt bevestigen op basis van sommige afbeeldingen en debugs zoals eerder uitgelegd in dit document), dan zwerft de client niet echt. De client begint een nieuwe verbinding met het WLAN alsof er een verbinding wordt verbroken en probeert opnieuw verbinding te maken vanuit het niets. Dit kan om meerdere redenen gebeuren, zoals wanneer een client zich van de dekkingsgebieden verwijdert en vervolgens een AP vindt met voldoende signaalkwaliteit om een associatie te starten, maar het duidt normaal gesproken op een clientprobleem waarbij de client geen roamende gebeurtenis start vanwege stuurprogramma's, firmware of software problemen.
Opmerking: u kunt contact opnemen met de verkoper van de draadloze client om de oorzaak van het probleem vast te stellen.
Wanneer de SSID is geconfigureerd met L2 hogere beveiligingsniveau bovenop basis 802.11 Open System-verificatie, zijn meer frames nodig voor de eerste associatie en bij roaming. De twee meest gebruikelijke beveiligingsmethoden die zijn gestandaardiseerd en geïmplementeerd voor 802.11 WLAN’s worden in dit document beschreven:
Het is belangrijk om te weten dat, hoewel deze twee methoden (PSK en EAP) de clients op verschillende manieren authenticeren/valideren, beide in wezen 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-Way-handdruk begint met de belangrijkste onderhandeling tussen de WLC/AP en de client met een Master Session Key (MSK) als het oorspronkelijke sleutelmateriaal zodra de client is gevalideerd met de specifieke gebruikte verificatiemethode.
Hier volgt een samenvatting van het proces:
Wanneer WPA-PSK of WPA2-PSK wordt uitgevoerd via TKIP (Temporal Key Integrity Protocol) of Advanced Encryption Standard (AES) voor de codering, moet de client het proces doorlopen dat bekend staat als de WPA 4-Way handdruk voor zowel de eerste associatie als tijdens het zwerven. Zoals eerder uitgelegd, is dit in principe het sleutelbeheerproces dat wordt gebruikt om WPA/WPA2 de coderingssleutels te laten afleiden. Wanneer echter PSK wordt uitgevoerd, wordt deze ook gebruikt om te verifiëren dat de client een geldige vooraf gedeelde sleutel heeft om zich aan te sluiten bij het WLAN. Dit beeld toont het eerste associatieproces wanneer WPA of WPA2 met PSK wordt uitgevoerd:
Zoals getoond, na het 802.11 Open System authenticatie en associatieproces, zijn er vier EAPOL frames van de WPA 4-Way handshake, die worden geïnitieerd door de AP met bericht-1, en geëindigd door de client met bericht-4. Na een succesvolle handdruk, begint de client gegevenskaders (zoals DHCP) door te geven, die in dit geval zijn versleuteld met de toetsen die zijn afgeleid van de 4-voudige handdruk (daarom kunt u de werkelijke inhoud en het type verkeer niet zien van de draadloze afbeeldingen).
Opmerking: EAPOL-frames worden gebruikt om alle belangrijke beheerframes en 802.1X/EAP-verificatiekaders via de ether tussen het toegangspunt en de client te transporteren; ze worden verzonden als draadloze gegevenskaders.
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.
Tijdens het zwerven, volgt de client in principe dezelfde frameruiling, waar de WPA 4-Way handshake nodig is om nieuwe coderingssleutels af te leiden met de nieuwe AP. Dit komt door veiligheidsredenen die in de standaard zijn vastgelegd en door het feit dat het nieuwe toegangspunt de oorspronkelijke sleutels niet kent. Het enige verschil is dat er Reassociation-frames zijn in plaats van Association-frames, zoals in deze afbeelding wordt getoond:
U ziet dezelfde berichten in de debug-uitgangen, maar het eerste pakket van de client is een Reassociation in plaats van een Association, zoals eerder getoond en uitgelegd.
Wanneer een 802.1X/EAP-methode wordt gebruikt voor de verificatie van de clients op een beveiligde SSID, zijn er nog meer frames nodig voordat de client verkeer begint te passeren. Deze extra frames worden gebruikt om de aanmeldingsgegevens voor de client te verifiëren. Afhankelijk van de EAP-methode kunnen er tussen vier en twintig frames zijn. Deze komen na de Association/Reassociation, maar vóór de WPA/WPA2 4-Way handshake, omdat de authenticatiefase de MSK afleidt die als zaad voor de definitieve encryptie sleutelgeneratie in het sleutelbeheerproces wordt gebruikt (4-Way handdruk).
Deze afbeelding toont een voorbeeld van de frames die via de ether tussen het toegangspunt en de draadloze client zijn uitgewisseld bij de eerste koppeling wanneer WPA met PEAPv0/EAP-MSCHAPv2 wordt uitgevoerd:
Soms toont deze uitwisseling min of meer frames, die afhankelijk zijn van meerdere factoren, zoals de EAP-methode, heruitzendingen door problemen, cliëntgedrag (zoals de twee Identity Requirements in dit voorbeeld, omdat de client een EAPOL START verstuurt nadat de AP de eerste Identity Query verstuurt), of als de client het certificaat al met de server heeft uitgewisseld. Wanneer de SSID is geconfigureerd voor een 802.1X/EAP-methode, zijn er meer frames (voor de verificatie) en is er dus meer tijd nodig voordat de client begint met het verzenden van gegevenskaders.
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 snel beveiligde zwervende methode), moet de client precies hetzelfde proces doorlopen en een volledige verificatie uitvoeren tegen de verificatieserver, zoals in de afbeeldingen wordt getoond. Het enige verschil is dat de client een Reassociation-verzoek gebruikt om het nieuwe AP te informeren dat het eigenlijk zwerft van een andere AP, maar de client moet nog steeds door volledige validatie en nieuwe sleutelgeneratie:
Zoals aangetoond, zelfs wanneer er minder frames zijn dan bij de eerste verificatie (die wordt veroorzaakt door meerdere factoren, zoals eerder vermeld), moeten, wanneer de client naar een nieuwe AP zwerft, de EAP-verificatie en de WPA-sleutelbeheerprocessen nog worden voltooid om door te kunnen gaan met het doorgeven van datakaders (zelfs als er actief verkeer werd verzonden voor het zwerven). Daarom, als de client een actieve toepassing heeft die gevoelig is voor vertragingen (zoals spraak-verkeer applicaties, of applicaties die gevoelig zijn voor onderbrekingen), dan kan de gebruiker problemen waarnemen bij het zwerven, zoals audio gaps of applicaties verbreken. Dit is afhankelijk van hoe lang het proces duurt voordat de client doorgaat met het verzenden/ontvangen van datakaders. Deze vertraging kan langer zijn, afhankelijk van: de RF-omgeving, de hoeveelheid clients, de round-trip tijd tussen de WLC en LAP's en met de verificatieserver, en andere redenen.
Hier is een samenvatting van de debug berichten voor deze roaming gebeurtenis (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-beveiligingsframework werken. Om te voorkomen dat de toepassing/service-impact op vertragingen van een reguliere roaminggebeurtenis, worden meerdere snel beveiligde roamingmethoden ontwikkeld en geïmplementeerd door de WiFi-industrie om het roamingproces te versnellen wanneer de beveiliging wordt gebruikt op de WLAN/SSID. De clients hebben te maken met enige latentie wanneer ze tijdens het zwerven tussen AP’s via de implementatie van high-level security op het WLAN verkeer blijven doorvoeren. Dit komt door de EAP-verificatie en de uitwisseling van sleutelbeheerframes die vereist zijn voor de beveiligingsinstellingen, zoals eerder is uitgelegd.
Het is belangrijk om te begrijpen dat snel beveiligde roaming slechts de term is die door de industrie wordt gebruikt in verwijzing naar de implementatie van een methode/schema die het roaming proces versnelt wanneer de beveiliging is geconfigureerd op het WLAN. De verschillende snelbeveiligde roamingmethoden/-schema’s die beschikbaar zijn voor WLAN’s en worden ondersteund door de CUWN, worden in de volgende sectie uitgelegd.
Cisco Centralized Key Management (CCKM) is de eerste snel beveiligde roamingmethode die is ontwikkeld en geïmplementeerd op WLAN’s van ondernemingen. Deze methode is door Cisco gecreëerd 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 merkgebonden protocol van Cisco is, wordt het alleen ondersteund door Cisco WLAN-infrastructuurapparaten en draadloze clients (van meerdere leveranciers) die Cisco Compatible Extension (CCX)-compatibel zijn voor CCKM.
CCKM kan worden geïmplementeerd met alle verschillende coderingsmethoden die beschikbaar zijn voor WLAN’s, zoals WEP, TKIP en AES. Het wordt ook ondersteund met de meeste 802.1X/EAP-verificatiemethoden die worden gebruikt voor WLAN’s, afhankelijk van de CCX-versie die door de apparaten wordt ondersteund.
Opmerking: voor een overzicht van de functieinhoud die wordt ondersteund door de verschillende versies van de CCX-specificatie (die EAP-methoden omvat die worden ondersteund), verwijzen we naar het document CCX versies en functies en controleren we de exacte CCX-versie die wordt ondersteund door uw draadloze clients (indien deze CCX-compatibel zijn), zodat u kunt bevestigen of de beveiligingsmethode die u met CCKM wilt gebruiken, kan worden geïmplementeerd.
Dit draadloze beeld geeft een voorbeeld van de frames die bij de eerste koppeling zijn uitgewisseld wanneer u CCKM uitvoert met TKIP als codering en PEAPv0/EAP-MSCHAPv2 als de 802.1X/EAP-methode. Dit is in principe dezelfde uitwisseling als wanneer WPA/TKIP met PEAPv0/EAP-MSCHAPv2 wordt uitgevoerd, maar deze keer wordt CCKM tussen de client en de infrastructuur besproken, zodat ze verschillende sleutelhiërarchie en cachemethoden gebruiken om Fast Secure Roaming uit te voeren wanneer de client moet zwerven:
Hier volgt een samenvatting van de debug-berichten (sommige EAP-uitwisselingen zijn verwijderd om de uitvoer te beperken):
*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 aanvankelijke koppeling aan het WLAN vergelijkbaar met de reguliere WPA/WPA2, waarbij een MSK (ook bekend als de Network Session Key (NSK)) wederzijds wordt afgeleid met de client en de RADIUS-server. Deze primaire sleutel wordt verzonden van de server naar de WLC na een succesvolle authenticatie, en wordt gecached als basis voor afleiding van alle volgende sleutels voor het leven van de client associatie met dit WLAN. Van hieruit halen de WLC en de client de zaadinformatie af die wordt gebruikt voor snel beveiligde roaming op basis van CCKM, dit gaat door een 4-weg handdruk vergelijkbaar met die van WPA/WPA2, om de unicast (PTK) en multicast/broadcast (GTK) encryptie sleutels af te leiden met de eerste AP.
Het grote verschil wordt opgemerkt bij roaming. In dit geval stuurt de CCKM-client één Reassociation-aanvraagframe naar de AP/WLC (dat een MIC en een sequentieel stijgend willekeurig nummer omvat), en biedt voldoende informatie (dat het nieuwe AP MAC-adres -BSSID- omvat) om de nieuwe PTK af te leiden. Met dit Reassociation-verzoek hebben de WLC en de nieuwe AP ook genoeg 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 in deze afbeelding wordt getoond:
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 getoond, wordt snel-beveiligde roaming uitgevoerd terwijl de EAP-verificatieframes worden vermeden en nog meer 4-way handshakes, omdat de nieuwe encryptie sleutels nog steeds worden afgeleid, maar gebaseerd op het CCKM-onderhandelingsschema. Dit wordt voltooid met de zwervende Reassociation frames en de informatie die eerder door de client en de WLC is gecached.
Pairwise think Key ID (PMKID) caching, of Sticky Key Caching (SKC), is de eerste snel beveiligde roamingmethode die wordt voorgesteld door de IEEE 802.11-standaard binnen het 802.11i-beveiligingsamendement, waar het belangrijkste doel is om een hoog beveiligingsniveau voor WLAN’s te standaardiseren. Deze snelle beveiligde zwervende techniek werd toegevoegd als een optionele methode voor WPA2-apparaten om zwerven te verbeteren wanneer deze beveiliging is geïmplementeerd.
Dit is mogelijk omdat, elke keer dat een client volledig EAP-geauthenticeerd is, de client en de verificatieserver een MSK afleiden, die wordt gebruikt om de PMK af te leiden. Dit wordt gebruikt als het zaad voor de WPA2 4-Way handshake om de definitieve unicast encryptie sleutel (PTK) af te leiden die wordt gebruikt voor de sessie (tot de client naar een andere AP zwerft of de sessie verloopt); vandaar, voorkomt deze methode de EAP-verificatiefase bij zwerven omdat het de oorspronkelijke PMK gebruikt die door de client en de AP wordt gecachet. 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-standaardmethode voor snel beveiligde roaming, voornamelijk om de volgende redenen:
Met deze methode is de eerste koppeling naar elke AP net als een gewone verificatie van de eerste keer naar het WLAN, waar de gehele 802.1X/EAP-verificatie tegen de verificatieserver en de 4-voudige handdruk voor de sleutelgeneratie moeten gebeuren voordat de client in staat is om gegevenskaders te verzenden, zoals in dit schermbeeld wordt getoond:
De debugs onthullen dezelfde EAP authenticatie frame uitwisseling als de rest van de methoden op de eerste verificatie aan het WLAN, met enkele uitgangen toegevoegd met betrekking tot de belangrijkste caching technieken hier gebruikt. Deze debug-uitgangen worden afgekapt om voornamelijk de nieuwe informatie te tonen, niet de gehele EAP-frameuitwisseling, omdat in principe dezelfde informatie elke keer wordt uitgewisseld voor verificatie van de client tegen de verificatieserver. Dit is tot nu toe aangetoond en is gecorreleerd met de EAP-verificatiekaders in de pakketafbeeldingen. De meeste EAP-berichten worden dus 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, de AP en draadloze client cache de PMK's van de beveiligde associaties die al zijn ingesteld. Als de draadloze client daarom zwerft naar een nieuw toegangspunt waar het nog nooit is gekoppeld, moet de client opnieuw een volledige EAP-verificatie uitvoeren, zoals wordt getoond in dit beeld waar de client zwerft naar een nieuw toegangspunt:
Echter, als de draadloze client terugzwerft naar een AP waar een eerdere associatie/authenticatie heeft plaatsgevonden, dan stuurt de client een Reassociation request frame dat meerdere PMKID's opsomt, die de AP informeert over de PMK's die gecachet zijn vanaf alle AP's waar de client eerder geverifieerd heeft. Aangezien de client terugzwerft naar een toegangspunt dat ook een PMK heeft gecachet voor deze client, hoeft de client daarom niet opnieuw te worden geverifieerd via EAP om een nieuwe PMK af te leiden. De client gaat simpelweg door de WPA2 4-Way handshake om de nieuwe tijdelijke coderingssleutels af te leiden:
Opmerking: Deze afbeelding toont het eerste 802.11 Open System-verificatiekader van de client niet, 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 weergegeven door de adapter of de software voor het draadloze pakketbeeld die wordt gebruikt om de frames in de lucht bij dit voorbeeld op te sporen, maar dat het als dit in het voorbeeld blijft staan voor educatieve doeleinden. Houd er rekening mee dat dit kan gebeuren wanneer u over-the-air pakketafbeeldingen uitvoert. Sommige frames kunnen door de afbeelding gemist worden, maar worden in feite uitgewisseld tussen de client en het toegangspunt. Anders begint het zwerven nooit op dit voorbeeld.
Hier is een samenvatting van de WLC debugs voor deze fast-secure roaming methode:
*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
Reassociation received from mobile on BSSID
84:78:ac:f0:68:d2
!--- This is the Reassociation Request from the client.
*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
Processing RSN IE type 48, length 38 for mobile
ec:85:2f:15:39:32
!--- The WLC/AP finds an Information Element that claims PMKID
Caching support on the Association request that is sent
from the client.
*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
Received RSN IE with 1 PMKIDs from mobile
ec:85:2f:15:39:32
!--- The Reassociation Request from the client comes with
one PMKID.
*apfMsConnTask_0: Jun 22 00:26:40.787:
Received PMKID: (16)
*apfMsConnTask_0: Jun 22 00:26:40.788:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- This is the PMKID that is received.
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Searching for PMKID in MSCB PMKID cache for mobile
ec:85:2f:15:39:32
!--- WLC searches for a matching PMKID on the database.
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d2 in
PMKID cache at index 0 of station ec:85:2f:15:39:32
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Found a valid PMKID in the MSCB PMKID cache for mobile
ec:85:2f:15:39:32
!--- The WLC validates the PMKID provided by the client,
and confirms that it has a valid PMK cache for this
client-and-AP pair.
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Setting active key cache index 1 ---> 0
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID
84:78:ac:f0:68:d2(status 0) ApVapId 3 Slot 0
!--- The Reassociation Response is sent to the client, which
validates the fast-roam with SKC.
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Initiating RSN with existing PMK to mobile
ec:85:2f:15:39:32
!--- WLC initiates a Robust Secure Network association with
this client-and-AP pair based on the cached PMK found.
Hence, EAP is avoided as per the next message.
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Skipping EAP-Success to mobile ec:85:2f:15:39:32
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d2 in
PMKID cache at index 0 of station ec:85:2f:15:39:32
*dot1xMsgTask: Jun 22 00:26:40.795: Including PMKID in M1(16)
!--- The hashed PMKID is included on the Message-1 of the
WPA/WPA2 4-Way handshake.
*dot1xMsgTask: Jun 22 00:26:40.795:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- The PMKID is hashed. The next messages are the same
WPA/WPA2 4-Way handshake messages described thus far
that are used in order to finish the encryption keys
generation/installation.
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.811: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from mobile
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
PMK: Sending cache add
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.820: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.820: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
Deze methode kan lokaal worden geïmplementeerd door autonome, onafhankelijke AP's, zonder dat er een gecentraliseerd apparaat nodig is om de gecachede sleutels te beheren.
Opportunistische Key Caching (OKC), ook bekend als Proactive Key Caching (PKC) (deze term wordt in meer detail uitgelegd in een notitie die hierna komt), is in feite een uitbreiding van de eerder beschreven WPA2 PMKID-caching methode, wat de reden is dat het ook Proactive/Opportunistic PMKID Caching wordt genoemd. Daarom is het belangrijk om op te merken dat dit geen snel beveiligde roamingmethode is die is gedefinieerd door de 802.11-standaard en niet wordt ondersteund door veel apparaten, maar net als PMKID-caching werkt het met WPA2-EAP.
Deze techniek stelt de draadloze client en de WLAN-infrastructuur in staat om slechts één PMK in het cachegeheugen op te slaan gedurende de levensduur van de clientassociatie met dit WLAN (afgeleid van de MSK na de initiële 802.1X/EAP-verificatie met de verificatieserver), zelfs bij roaming tussen meerdere AP’s, aangezien ze allemaal de oorspronkelijke PMK delen die als zaad wordt gebruikt op alle 4-voudige handgrepen van WPA2. Dit is nog steeds nodig, net zoals het in SKC is, om nieuwe coderingssleutels te genereren telkens wanneer de client zich opnieuw bij de AP’s voegt. Als de AP's deze oorspronkelijke PMK van de clientsessie willen delen, moeten ze allemaal onder een soort administratieve controle staan, met een gecentraliseerd apparaat dat de oorspronkelijke PMK voor alle AP's opslaat en verdeelt. 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 te verwerken; daarom is dit een beperking op autonome AP-omgevingen.
Met deze methode, net als in PMKID Caching (SKC), is de aanvankelijke associatie met elk AP een regelmatige eerste-keer verificatie naar het WLAN, waar u de volledige 802.1X/EAP-verificatie moet voltooien tegen de verificatieserver en de 4-voudige handdruk voor sleutelgeneratie voordat u gegevenskaders kunt verzenden. Dit is een afbeelding van een scherm dat dit illustreert:
De debug-uitgangen tonen in principe dezelfde EAP-verificatiekaderuitwisseling als de rest van de methoden die in dit document worden beschreven bij de eerste verificatie van het WLAN (zoals in de afbeeldingen wordt getoond), samen met de toevoeging van enkele uitgangen die betrekking hebben op de belangrijkste cachetechnieken die hier door de WLC worden gebruikt. Dit debug uitvoer wordt ook gesneden om alleen de relevante informatie te tonen:
*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, de draadloze client en de WLC (voor alle beheerde AP's) cachegeheugen de enige oorspronkelijke PMK van de beveiligde associatie die in eerste instantie is opgericht. Elke keer dat een draadloze client verbinding maakt met een specifieke AP, wordt een PMKID gehakt op basis van: het client-MAC-adres, het AP MAC-adres (BSSID van het WLAN) en de PMK die is afgeleid van die AP. Daarom, aangezien OKC dezelfde originele PMK voor alle APs en de specifieke client caches, wanneer deze client (opnieuw) associeert met een andere AP, is de enige waarde die verandert om de nieuwe PMKID te hakken het nieuwe AP MAC-adres.
Wanneer de client het zwerven op een nieuwe AP initieert en het Reassociation-verzoekframe verstuurt, voegt het de PMKID toe op het WPA2 RSN Information Element als het de AP wil informeren dat een gecachede PMK wordt gebruikt voor snel-veilig zwerven. Het kent al het MAC-adres van de BSSID (AP) voor waar het zwerft, dan de client gewoon hasht de nieuwe PMKID die wordt gebruikt op dit Reassociation-verzoek. Wanneer de AP dit verzoek van de client ontvangt, hasht het ook de PMKID met de waarden die het al heeft (het gecachede PMK, het client-MAC-adres en zijn eigen AP MAC-adres), en reageert met de succesvolle Reassociation Response die bevestigt dat de PMKID's overeenkwamen. De gecachede PMK 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 Reassociatie-aanvraagkader van de client geselecteerd en uitgebreid, zodat u meer details van het frame kunt zien. De MAC-adresinformatie en ook het informatie-element van het robuuste beveiligingsnetwerk (RSN, zoals in 802.11i - WPA2), waar informatie over de WPA2-instellingen die voor deze koppeling worden gebruikt wordt weergegeven (gemarkeerd is de PMKID die wordt verkregen met de gehakte formule).
Hier is een samenvatting van WLC debugs voor deze snel-beveiligde roaming methode 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 de Reassociation-aanvraag van de client is ontvangen. Dit is nodig om de PMKID te valideren en te bevestigen dat de gecachede PMK wordt gebruikt met de WPA2 4-Way handshake om de encryptiesleutels af te leiden en het snel-beveiligde zwerven te voltooien. Verwar de CCKM-vermeldingen niet met de debugs; dit wordt niet gebruikt om CCKM uit te voeren, maar OKC, zoals eerder uitgelegd. CCKM hier is simpelweg 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 instelling kan werken als de toegangspunten niet tot dezelfde FlexConnect-groep behoren, maar dit is geen aanbevolen of ondersteunde instelling.
Proactieve Key Caching (of PKC) is bekend als OKC (Opportunistische Key Caching), en de twee termen worden onderling verwisselbaar gebruikt wanneer ze dezelfde hier uiteengezette methode beschrijven. Dit was echter slechts een term die in 2001 door Airspace werd gebruikt voor een oude key caching methode, die vervolgens werd gebruikt door de 802.11i standaard als basis voor "pre-authenticatie" (een andere Fast Secure Roaming methode, hieronder kort uitgelegd). PKC is geen preauthenticatie of OKC (Opportunistische Key Caching), maar wanneer u hoort of leest over PKC, is de verwijzing in principe naar OKC, en niet naar Preauthenticatie.
Deze methode wordt ook gesuggereerd 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. Daarom wordt het hier slechts kort en zonder output toegelicht.
Met Verificatie vooraf kunnen de draadloze clients met meerdere AP's tegelijk worden geverifieerd terwijl ze gekoppeld zijn aan het huidige AP. Wanneer dit gebeurt, stuurt de client de EAP-verificatiekaders naar het huidige toegangspunt waar de verbinding is gemaakt, maar het is bestemd voor de andere toegangspunt(en) waar de client de verificatie vooraf wil uitvoeren (naburige toegangspunten die mogelijke kandidaten voor zwerven zijn). Het huidige toegangspunt verzendt deze frames naar de doel-toegangspunt(en) via het distributiesysteem. Het nieuwe AP voert volledige verificatie uit tegen de RADIUS-server voor deze client, zodat een volledige nieuwe EAP-verificatie handshake is voltooid en dit nieuwe AP fungeert als de Authenticator.
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, de client is al geauthenticeerd en met een PMK al gecachet voor deze nieuwe veilige vereniging van AP-to-client, zodat ze alleen de 4-Way Handshake moeten uitvoeren en een snel zwerven ervaren nadat de client zijn eerste Reassociation-verzoek verstuurt.
Hier is een afbeelding van een AP-beacon die het RSN IE-veld toont dat ondersteuning voor verificatie vooraf adverteert (dit veld is afkomstig van een Cisco AP, waar is bevestigd dat verificatie vooraf niet wordt ondersteund):
Er is één PMK voor elke AP-to-client beveiligde associatie, die kan worden beschouwd als een veiligheidsvoordeel als een AP is gecompromitteerd en de sleutels worden gestolen (kan niet worden gebruikt met andere AP's). Dit beveiligingsvoordeel wordt echter op verschillende manieren op andere methoden door de WLAN-infrastructuur verwerkt.
De Fast-Secure roaming techniek gebaseerd op de 802.11r-wijziging (officieel Fast BSS Transition genoemd door de 802.11-standaard, bekend als FT) is de eerste methode die officieel is geratificeerd (op 2008) door de IEEE voor de 802.11-standaard als de oplossing om snelle overgangen tussen AP's (Basic Service Sets of BSS's) uit te voeren, die duidelijk de sleutelhiërarchie definieert die wordt gebruikt wanneer u sleutels en cachesleutels op een WLAN behandelt. De adoptie is echter traag geweest, vooral door de andere oplossingen die al beschikbaar waren toen er eigenlijk snelle overgangen nodig waren, zoals met VoWLAN-implementaties bij gebruik met een van de methoden die eerder in dit document zijn uitgelegd. Er zijn slechts een paar apparaten die momenteel een aantal van de FT-opties ondersteunen (tegen 2013).
Deze techniek is complexer om te verklaren dan de andere methoden, aangezien het nieuwe concepten en meerdere lagen PMKs introduceert die op verschillende apparaten (elk apparaat met een andere rol) worden gecached, en biedt zelfs nog meer opties voor snel-veilig zwerven. Daarom wordt een korte samenvatting gegeven over deze methode en de manier waarop deze wordt toegepast met elke beschikbare optie.
802.11r verschilt van SKC en OKC, voornamelijk om de volgende redenen:
Met deze methode voert de draadloze client slechts één initiële verificatie uit tegen de WLAN-infrastructuur wanneer een verbinding met het eerste toegangspunt tot stand wordt gebracht, en voert de client snel beveiligde roaming uit tussen toegangspunten van hetzelfde FT-mobiliteitsdomein.
Dit is een van de nieuwe concepten, die in principe verwijst naar de AP's die dezelfde SSID (bekend als Extended Service Set of ESS) gebruiken en dezelfde FT-toetsen afhandelen. Dit is vergelijkbaar met de andere methoden die tot nu toe zijn toegelicht. De manier waarop de AP’s omgaan met de FT-mobiliteitsdomeinsleutels is normaal gesproken gebaseerd op een gecentraliseerde instelling, 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 implementatiestations (zoals Autonomous APs, 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 aangezien dat buiten het bereik 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 echt nodig hebt om de infrastructuur apparaten (en hun code) grondig te analyseren om een software probleem te ontdekken.
Met deze methode is de eerste koppeling naar een AP een regelmatige eerste-keer verificatie naar het WLAN, waar de gehele 802.1X/EAP-verificatie tegen de verificatieserver en de 4-voudige handdruk voor de sleutelgeneratie moeten plaatsvinden voordat gegevensframes worden verzonden, zoals in deze afbeelding op het scherm wordt getoond:
De belangrijkste verschillen zijn:
De debugs tonen in principe dezelfde EAP authenticatie frame uitwisseling als de rest van de methoden op de eerste authenticatie aan het WLAN (zoals opgemerkt van de beelden), maar sommige outputs die betrekking hebben op de belangrijkste caching technieken die worden gebruikt door de WLC worden toegevoegd; dus deze debug uitvoer wordt gesneden om alleen de relevante informatie te tonen:
*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 getoond, wordt een extra debug ingeschakeld samen met de debug client, die de debug ft-gebeurtenissen inschakelen is.
Hier zijn de afbeeldingen en debugs van een eerste koppeling naar het WLAN wanneer u FT met WPA2-PSK uitvoert (in plaats van een 802.1X/EAP-methode), waar het Association Response frame van het AP is geselecteerd om het Fast BSS Transition Information Element (gemarkeerd) te tonen. 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 verbinding met 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 voert in feite een efficiëntere zwervende methode uit die de initiële 802.11 Open System-verificatie- en reassociatieframes (die altijd worden gebruikt en vereist bij zwerven tussen AP's) combineert 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 zijn uitgewisseld wanneer een Fast BSS Transition Over-the-Air met 802.1X/EAP-beveiliging wordt uitgevoerd. Het kader voor Open Systeemverificatie van client tot AP is geselecteerd om de FT-protocol informatie-elementen te zien die nodig zijn om te beginnen met de FT-toetsonderhandeling. Dit wordt gebruikt om de nieuwe PTK met de nieuwe AP af te leiden (gebaseerd op de PMK-R1). Het veld dat het verificatiealgoritme toont, wordt gemarkeerd om aan te tonen dat deze client geen eenvoudige Open System-verificatie uitvoert, maar een Fast BSS-overgang:
Hier zijn de debug-uitgangen van de WLC wanneer deze FT roaming-gebeurtenis 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 snelle BSS Transition Over-the-Air met WPA2-PSK-beveiliging toont, waar het uiteindelijke Reassociation Response frame van de AP op de client is geselecteerd om meer details over deze FT-uitwisseling te tonen:
Hier zijn de debug-uitgangen wanneer deze FT roaming-gebeurtenis plaatsvindt met PSK, die vergelijkbaar zijn met de uitgangen 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 wordt getoond, worden de vier frames die worden gebruikt en nodig zijn voor zwerven (Open Systeemverificatie van de client, Open Systeemverificatie van de AP, Reassociation Verzoek, en Reassociation Response), zodra de Fast BSS Transition wordt onderhandeld op de eerste verbinding met het WLAN, in principe gebruikt als een FT 4-way handshake om de nieuwe PTK (unicast encryptie sleutel) en GTK (multicast/broadcast encryptie sleutel) af te leiden.
Dit vervangt de 4-voudige handdruk die normaal optreedt nadat deze frames zijn uitgewisseld, en de FT-inhoud en de belangrijkste onderhandeling over deze frames is in principe hetzelfde of u 802.1X/EAP of PSK gebruikt als de beveiligingsmethode. Zoals in de afbeelding wordt getoond, is het AKM-veld het belangrijkste verschil, dat bevestigt als de client FT met PSK of 802.1X uitvoert. Daarom is het belangrijk om op te merken dat deze vier frames normaal gesproken niet dit type beveiligingsinformatie voor belangrijke onderhandeling hebben, maar alleen wanneer client-FT roamt als 802.11r is geïmplementeerd en onderhandeld tussen de client en de WLAN-infrastructuur bij eerste koppeling.
802.11r staat een andere implementatie van Fast BSS Transition toe, waarbij de FT roaming wordt geïnitieerd door de client met de nieuwe AP waarvoor de client over-the-DS (distributiesysteem) zwerft, en niet over-the-Air. In dit geval worden FT Action frames gebruikt om de belangrijkste onderhandeling te starten in plaats van de Open System Verification frames.
Wanneer de client besluit dat hij naar een betere AP kan zwerven, stuurt de client een FT Action request frame naar de oorspronkelijke AP waar hij op dit moment verbonden is voordat hij zwerft. De client geeft de BSSID (MAC-adres) van de doel-AP aan waar het wil roamen. De oorspronkelijke AP stuurt dit FT Action request frame door naar de doel-AP via het distributiesysteem (normaal de bekabelde infrastructuur), en de doel-AP reageert op de client met een FT Action Response frame (ook via de DS, zodat het eindelijk over-the-air naar de client kan sturen). Zodra deze FT Action frame exchange succesvol is, voltooit de client de FT roaming; de client stuurt het Reassociation-verzoek naar de doel-AP (dit keer via de lucht) en ontvangt een Reassociation Response van de nieuwe AP om de roaming en de uiteindelijke afleiding van de sleutels te bevestigen.
Samengevat zijn er vier frames om Fast BSS Transition te onderhandelen en nieuwe coderingssleutels af te leiden, maar hier worden de Open System-verificatieframes gesubstitueerd door de FT Action request/response-frames, die via het distributiesysteem met het huidige AP worden uitgewisseld. Deze methode is ook geldig voor zowel de beveiligingsmethoden 802.1X/EAP en PSK, die allemaal worden ondersteund door de Cisco draadloze LAN-controllers. Aangezien deze overstap over-the-DS echter niet wordt ondersteund en geïmplementeerd door de meeste draadloze clients in de WiFi-industrie (en omdat de uitgangen voor frameuitwisseling en debug in principe hetzelfde zijn), 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, introduceerde Cisco draadloze LAN-infrastructuur de Adaptieve 802.11r-functie. Wanneer de FT-modus is ingesteld op Adaptief op WLAN-niveau, adverteert WLAN met 802.11r Mobility Domain ID op een 802.11i-enabled WLAN. Sommige Apple iOS10-clientapparaten identificeren de aanwezigheid van MDIE op een 80211i/WPA2 WLAN en voeren een bedrijfseigen handdruk om 802.11r-associatie tot stand te brengen. Zodra de client een succesvolle 802.11r-associatie heeft voltooid, kan FT-roaming worden uitgevoerd zoals in een normaal 802.11r-enabled WLAN. De FT Adaptive is alleen van toepassing op geselecteerde Apple iOS10 (en hoger) apparaten. Alle andere clients kunnen 802.11i/WPA2-associatie blijven gebruiken op het WLAN en de toepasselijke FSR-methode uitvoeren zoals ondersteund.
Meer documentatie over deze nieuwe functie die is geïntroduceerd voor iOS10-apparaten om 802.11r uit te voeren op een WLAN/SSID waar 802.11r niet echt is ingeschakeld (zodat andere clients die geen 802.11r zijn, met succes verbinding kunnen maken), is te vinden in Enterprise Best Practices voor Cisco IOS-apparaten 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 |