Methoden voor 802.11 WLAN en Fast-Secure Roaming op CUWN
Inhoud
Inleiding
In dit document worden draadloze en snel beveiligde zwerftypen beschreven die beschikbaar zijn voor IEEE 802.11 Wireless LAN's (WLAN's) op Unified Wireless Network (CUWN).
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
- IEEE 802.11 WLAN Fundamentals
- IEEE 802.11 WLAN-beveiliging
- IEEE 802.1X/EAP-basisprincipes
Gebruikte componenten
De informatie in dit document is gebaseerd op Cisco WLAN Controller Software versie 7.4.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Achtergrondinformatie
De informatie in dit document is gebaseerd op Cisco WLAN Controller Software versie 7.4, maar de meeste van de beschreven foutopsporingsresultaten en gedragingen kunnen van toepassing zijn op elke softwareversie die de besproken methoden ondersteunt.
De specificaties van alle hier beschreven methoden blijven hetzelfde voor latere Cisco WLAN Controller-codes (tot versie 8.3 tegen de tijd dat dit artikel werd bijgewerkt).
In dit document worden de verschillende typen draadloze roaming en snel beveiligde zwerfmethoden beschreven die beschikbaar zijn voor draadloze LAN's (WLAN's) met IEEE 802.11 die worden ondersteund in het Cisco Unified Wireless Network (CUWN).
Het document bevat niet alle details over hoe elke methode werkt of hoe ze zijn geconfigureerd. Het belangrijkste doel van dit document is om de verschillen tussen de verschillende beschikbare technieken, hun voordelen en beperkingen, en de frames-uitwisseling op elke methode te beschrijven. Voorbeelden van WLAN Controller (WLC)-debugs worden gegeven en afbeeldingen van draadloze pakketten worden gebruikt om de gebeurtenissen te analyseren en uit te leggen die zich voordoen voor elke beschreven zwerfmethode.
Voordat een beschrijving wordt gegeven van de verschillende snelbeveiligde zwerfmethoden die beschikbaar zijn voor WLAN's, is het belangrijk om te begrijpen hoe het WLAN-associatieproces werkt en hoe een regelmatig zwerfevenement plaatsvindt wanneer er geen beveiliging is geconfigureerd op de Service Set Identifier (SSID).
Wanneer een 802.11 draadloze client verbinding maakt met een toegangspunt (AP), moet deze eerst het basisverificatieproces van het 802.11 Open Systeem doorlopen voordat het verkeer begint door te geven (draadloze gegevensframes).
Vervolgens moet het associatieproces worden afgerond. Het verificatieproces voor het open systeem is als een kabelverbinding op het toegangspunt dat de client selecteert.
Dit is een zeer belangrijk punt, omdat het altijd de draadloze client is die selecteert welke AP de voorkeur heeft en de beslissing baseert op meerdere factoren die variëren tussen leveranciers.
Daarom begint de client dit proces door het verificatieframe naar het geselecteerde toegangspunt te sturen, zoals later in dit document wordt weergegeven. Het toegangspunt kan niet vragen dat u een verbinding tot stand brengt.
Nadat het verificatieproces voor het open systeem met succes is voltooid met een antwoord van het toegangspunt ("kabel aangesloten"), wordt de 802.11 Layer 2 (L2)-onderhandeling die de koppeling tussen de client en het toegangspunt tot stand brengt, in wezen voltooid.
Het toegangspunt wijst een associatie-ID toe aan de client als de verbinding succesvol is en bereidt deze voor om verkeer door te geven of een beveiligingsmethode van een hoger niveau uit te voeren als deze op de SSID is geconfigureerd.
Het verificatieproces van het open systeem bestaat uit twee beheerframes en het associatieproces.
Authenticatie- en associatieframes zijn draadloze beheerframes, geen gegevensframes, die in principe worden gebruikt voor het verbindingsproces met het toegangspunt.
Hier is een afbeelding van de draadloze frames over-the-air voor dit proces:
De draadloze client begint met het verificatieframe en het toegangspunt antwoordt met een ander verificatieframe. De client verzendt vervolgens het frame Associatieverzoek en het toegangspunt eindigt in een antwoord met het frame Associatierespons.
Zoals blijkt uit de DHCP-pakketten, begint de client gegevensframes door te geven zodra de 802.11 Open System-verificatie- en associatieprocessen zijn doorgegeven.
In dit geval is er geen beveiligingsmethode geconfigureerd op de SSID, dus de client begint onmiddellijk gegevensframes (in dit geval DHCP) te verzenden die niet zijn gecodeerd.
Als beveiliging is ingeschakeld op de SSID, zijn er, zoals later in dit document wordt getoond, authenticatie- en coderingshandshake-frames op een hoger niveau voor de specifieke beveiligingsmethode, net na de associatierespons en voordat er gegevensframes voor clientverkeer worden verzonden, zoals DHCP, Address Resolution Protocol (ARP) en toepassingspakketten, die worden gecodeerd. Gegevensframes kunnen alleen worden verzonden totdat de client volledig is geverifieerd en de coderingssleutels zijn overeengekomen op basis van de geconfigureerde beveiligingsmethode.
Op basis van de vorige afbeelding zijn hier de berichten die u ziet in de uitvoer van de opdracht WLC-debugclient wanneer de draadloze client een nieuwe koppeling met het WLAN start:
*apfMsConnTask_0: Jun 21 18:55:14.221: 00:40:96:b7:ab:5c
Association received from mobile on BSSID 84:78:ac:f0:68:d0
!--- This is the Association Request from the wireless client
to the selected AP.
*apfMsConnTask_0: Jun 21 18:55:14.222: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d0
(status 0) ApVapId 1 Slot 0
!--- This is the Association Response from the AP to the client.
Deze berichten tonen de frames Associatieverzoek en Reactie; de eerste verificatieframes worden niet geregistreerd bij de WLC omdat deze handshake snel gebeurt op het AP-niveau op de CUWN.
Welke informatie wordt weergegeven wanneer de client zwerft? De klant wisselt altijd vier beheerframes uit bij het tot stand brengen van een verbinding met een toegangspunt, wat te wijten is aan de oprichting van een vereniging of een roamingevenement.
De client heeft slechts één verbinding tot stand gebracht met slechts één toegangspunt tegelijk. Het enige verschil in de frameschakeling tussen een nieuwe verbinding met de WLAN-infrastructuur en een zwervend evenement is dat de associatieframes van een zwervend evenement reassociatieframes worden genoemd, die aangeven dat de client daadwerkelijk zwerft vanaf een ander toegangspunt zonder pogingen om een nieuwe koppeling met het WLAN tot stand te brengen. Deze frames kunnen verschillende elementen bevatten die worden gebruikt om te onderhandelen over het roamingevenement; dit hangt af van de configuratie, maar die details vallen buiten het bereik van dit document.
Hier is een voorbeeld van een frame exchange:
Deze berichten worden weergegeven in de foutopsporingsuitvoer:
*apfMsConnTask_2: Jun 21 19:02:19.709: 00:40:96:b7:ab:5c
Reassociation received from mobile on BSSID 84:78:ac:f0:2a:90
!--- This is the Reassociation Request from the wireless client
to the selected AP.
*apfMsConnTask_2: Jun 21 19:02:19.710: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:90
(status 0) ApVapId 1 Slot 0
!--- This is the Reassociation Response from the AP to the client.
Zoals u ziet, voert de client een zwervend evenement uit nadat het verzoek tot herkoppeling naar het nieuwe toegangspunt is verzonden en ontvangt de reactie op de herkoppeling van het toegangspunt. Aangezien de client al een IP-adres heeft, zijn de eerste dataframes voor ARP-pakketten.
Als u een roamingevenement verwacht, maar de client verzendt een Associatieverzoek in plaats van een Herassociatieverzoek (dat u kunt bevestigen aan de hand van enkele afbeeldingen en fouten die vergelijkbaar zijn met die eerder in dit document zijn uitgelegd), dan is de client niet echt aan het roamen. De client start een nieuwe koppeling met het WLAN alsof er een verbroken verbinding is en probeert opnieuw verbinding te maken vanaf nul. Dit kan om meerdere redenen gebeuren, zoals wanneer een client zich verwijdert van de dekkingsgebieden en vervolgens een toegangspunt vindt met voldoende signaalkwaliteit om een koppeling te starten, maar het geeft normaal gesproken een clientprobleem aan waarbij de client geen roaming-evenement initieert vanwege stuurprogramma's, firmware of softwareproblemen.
Roaming met beveiliging op een hoger niveau
Wanneer de SSID is geconfigureerd met L2-beveiliging op een hoger niveau bovenop de elementaire 802.11 Open System-verificatie, zijn er meer frames nodig voor de eerste koppeling en bij roaming. De twee meest gangbare beveiligingsmethoden die voor 802.11 WLAN's zijn gestandaardiseerd en geïmplementeerd, worden in dit document beschreven:
- WPA/WPA2-PSK (Pre-Shared Key) - verificatie van clients met een vooraf gedeelde sleutel.
- WPA/WPA2-EAP (Extensible Authentication Protocol) - verificatie van clients met een 802.1X/EAP-methode om veiligere referenties te valideren door het gebruik van een verificatieserver, zoals certificaten, gebruikersnaam en wachtwoord en tokens.
Het is belangrijk om te weten dat, hoewel deze twee methoden (PSK en EAP) de clients op verschillende manieren verifiëren / valideren, beide in principe dezelfde WPA / WPA2-regels gebruiken voor het sleutelbeheerproces.
Of de beveiliging nu WPA/WPA2-PSK of WPA/WPA2-EAP is, het proces dat bekend staat als de WPA/WPA2 4-weg handshake begint de belangrijkste onderhandeling tussen de WLC/AP en de client met een Master Session Key (MSK) als het originele sleutelmateriaal zodra de client is gevalideerd met de specifieke gebruikte verificatiemethode.
Hier is een samenvatting van het proces:
- Een MSK is afgeleid van de EAP-verificatiefase wanneer 802.1X/EAP-beveiliging wordt gebruikt, of van de PSK wanneer WPA/WPA2-PSK als beveiligingsmethode wordt gebruikt.
- Uit deze MSK leiden de client en WLC/AP de Pairwise Master Key (PMK) af, en de WLC/AP genereert een Group Master Key (GMK).
- Zodra deze twee hoofdsleutels klaar zijn, starten de client en de WLC/AP de WPA/WPA2 4-Way handshake (die later in dit document wordt geïllustreerd met enkele schermafbeeldingen en fouten) met de hoofdsleutels als de zaden voor de onderhandeling over de daadwerkelijke coderingssleutels.
- Deze laatste encryptiesleutels staan bekend als de Pairwise Transient Key (PTK) en de Group Transient Key (GTK). De PTK is afgeleid van de PMK en wordt gebruikt om unicast-frames met de client te versleutelen. De Group Transient Key (GTK) is afgeleid van de GMK en wordt gebruikt om multicast/broadcast op deze specifieke SSID/AP te coderen.
WPA/WPA2-PSK
Wanneer WPA-PSK of WPA2-PSK wordt uitgevoerd via het Temporal Key Integrity Protocol (TKIP) of Advanced Encryption Standard (AES) voor de codering, moet de client het proces doorlopen dat bekend staat als de WPA 4-Way handshake voor zowel de eerste associatie als bij roaming. Zoals eerder uitgelegd, is dit in principe het sleutelbeheerproces dat wordt gebruikt om WPA / WPA2 de coderingssleutels af te leiden. Wanneer PSK wordt uitgevoerd, wordt het echter ook gebruikt om te controleren of de client over een geldige vooraf gedeelde sleutel beschikt om deel te nemen aan het WLAN. Deze afbeelding toont het initiële associatieproces wanneer WPA of WPA2 met PSK wordt uitgevoerd:
Na het 802.11 Open System-verificatie- en associatieproces zijn er vier EAPOL-frames van de WPA 4-Way handshake, die door het toegangspunt worden geïnitieerd met message-1, en door de client worden afgewerkt met message-4.
Na een succesvolle handshake begint de client dataframes (zoals DHCP) door te geven, die in dit geval worden gecodeerd met de sleutels die zijn afgeleid van de 4-Way handshake (daarom kunt u de werkelijke inhoud en het type verkeer van de draadloze afbeeldingen niet zien).
Deze berichten verschijnen in de debug uitgangen:
*apfMsConnTask_0: Jun 21 19:30:05.172: 00:40:96:b7:ab:5c
Association received from mobile on BSSID 84:78:ac:f0:68:d1
*apfMsConnTask_0: Jun 21 19:30:05.173: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d1
(status 0) ApVapId 2 Slot 0
!--- The Association handshake is finished.
*dot1xMsgTask: Jun 21 19:30:05.178: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
!--- Message-1 of the WPA/WPA2 4-Way handshake is sent
from the WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.289: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.289: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
!--- Message-2 of the WPA/WPA2 4-Way handshake is successfully
received from the client.
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.290: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- Message-3 of the WPA/WPA2 4-Way handshake is sent
from the WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.309: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.310: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
!--- Message-4 (final message) of the WPA/WPA2 4-Way handshake
is successfully received from the client, which confirms
the installation of the derived keys. They can now be used in
order to encrypt data frames with current AP.
Bij roaming volgt de client in principe dezelfde frameuitwisseling, waarbij de WPA 4-Way handshake vereist is om nieuwe coderingssleutels af te leiden met het nieuwe toegangspunt.
Dit is te wijten aan beveiligingsredenen die door de standaard zijn vastgesteld en het feit dat het nieuwe toegangspunt de oorspronkelijke sleutels niet kent. Het enige verschil is dat er reassociatieframes zijn in plaats van associatieframes, zoals in deze afbeelding wordt getoond:
U ziet dezelfde berichten in de debug-uitgangen, maar het eerste pakket van de client is een reassociatie in plaats van een associatie, zoals eerder getoond en uitgelegd.
WPA/WPA2-EAP
Wanneer een 802.1X/EAP-methode wordt gebruikt om de clients op een beveiligde SSID te verifiëren, zijn er nog meer frames nodig voordat de client verkeer begint door te geven.
Deze extra frames worden gebruikt om de clientreferenties te verifiëren en afhankelijk van de EAP-methode kunnen er tussen de vier en twintig frames zijn.
Deze komen na de Associatie / Reassociation, maar vóór de WPA / WPA2 4-Way handshake, omdat de authenticatiefase de MSK afleidt die wordt gebruikt als het zaad voor de uiteindelijke coderingssleutelgeneratie in het sleutelbeheerproces (4-Way handshake).
Deze afbeelding toont een voorbeeld van de frames die via de ether worden uitgewisseld tussen het toegangspunt en de draadloze client bij de eerste koppeling wanneer WPA met PEAPv0/EAP-MSCHAPv2 wordt uitgevoerd:
Soms toont deze uitwisseling meer of minder frames, wat afhankelijk is van meerdere factoren, zoals de EAP-methode, hertransmissies als gevolg van problemen, clientgedrag (zoals de twee identiteitsverzoeken in dit voorbeeld, omdat de client een EAPOL START verzendt nadat het toegangspunt het eerste identiteitsverzoek heeft verzonden), of als de client het certificaat al heeft uitgewisseld met de server. Wanneer de SSID is geconfigureerd voor een 802.1X/EAP-methode, zijn er meer frames (voor de verificatie) en daarom duurt het langer voordat de client gegevensframes begint te verzenden.
Hier is een samenvatting van de debug berichten:
*apfMsConnTask_0: Jun 21 23:41:19.092: 00:40:96:b7:ab:5c
Association received from mobile on BSSID 84:78:ac:f0:68:d8
*apfMsConnTask_0: Jun 21 23:41:19.094: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d8
(status 0) ApVapId 9 Slot 0
!--- The Association handshake is finished.
*dot1xMsgTask: Jun 21 23:41:19.098: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 1)
!--- The EAP Identity Request is sent to the client once it is
associated in order to begin the higher-level authentication
process. This informs the client that an identity to start
this type of 802.1X/EAP authentication must be provided.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.226: 00:40:96:b7:ab:5c
Received EAPOL START from mobile 00:40:96:b7:ab:5c
!--- The wireless client decides to start the EAP authentication
process, and informs the AP with an EAPOL START data frame.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.227: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
!--- WLC/AP sends another EAP Identity Request to the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.235: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.235: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c
!--- The client responds with an EAP Identity Response on an EAPOL
frame.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.301: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.301: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
!--- Once the WLC/AP sends the client response to the Authentication
Server on a RADIUS Access-Request packet, the server responds
with a RADIUS Access-Challenge in order to officially start the
EAP negotiation, handshake, and authentication with the client
(sometimes with mutual authentication, dependent upon the EAP
method). This response received by the WLC/AP is sent to the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.344: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.344: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
!--- The client responds with an EAP Response on an EAPOL frame, which
is sent to the Authentication Server on a RADIUS Access-Request
packet. The server responds with another RADIUS Access-Challenge.
This process continues, dependent upon the EAP method (the exchange
of certificates when used, the building of TLS tunnels, validation
of client credentials, client validation of server identity when
applicable). Hence, the next few messages are basically the same on
the WLC/AP side, as this acts as a "proxy" between the client and
the Authentication Server exchanges.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.347: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.347: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 4)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.375: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.375: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 4, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.377: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.377: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 5)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.403: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.403: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 5, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.404: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.404: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 6)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.414: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.414: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 6, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.421: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.421: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.425: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.425: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 7, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.427: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.427: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 8)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.434: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.434: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 8, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.436: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.436: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 9)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.440: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.440: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 9, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.442: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.442: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 10)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.449: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.449: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 10, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.452: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.452: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 11)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.457: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.457: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 11, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.459: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.459: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 13)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.469: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.469: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 13, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.472: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
!--- The authentication finishes and is successful for this client,
so the RADIUS Server sends a RADIUS Access-Accept to the WLC/AP.
This RADIUS Access-Accept comes with the special attributes
that are assigned to this client (if any are configured on the
Authentication Server for this client). This Access-Accept also
comes with the MSK derived with the client in the EAP
authentication process, so the WLC/AP installs it in order to
initiate the WPA/WPA2 4-Way handshake with the wireless client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.473: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c
(EAP Id 13)
!--- The accept/pass of the authentication is sent to the client as
an EAP-Success message.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.473: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
!--- Message-1 of the WPA/WPA2 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
!--- Message-2 of the WPA/WPA-2 4-Way handshake is successfully
received from the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- Message-3 of the WPA/WPA2 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.487: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.487: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
!--- Message-4 (final message) of the WPA/WPA2 4-Way handshake
is successfully received from the client, which confirms the
installation of the derived keys. They can now be used in
order to encrypt data frames with the current AP.
Wanneer de draadloze client hier regelmatig zwerft (het normale gedrag, zonder implementatie van een snelle, veilige zwerfmethode), moet de client exact hetzelfde proces doorlopen en een volledige verificatie uitvoeren tegen de verificatieserver, zoals wordt weergegeven in de afbeeldingen. Het enige verschil is dat de klant een Reassociation Request gebruikt om het nieuwe toegangspunt te informeren dat het daadwerkelijk vanaf een ander toegangspunt zwerft, maar dat de klant nog steeds volledige validatie en nieuwe sleutelgeneratie moet doorlopen:
Zoals blijkt, moeten, zelfs wanneer er minder frames zijn dan in de eerste verificatie (die wordt veroorzaakt door meerdere factoren, zoals eerder vermeld), wanneer de client naar een nieuw toegangspunt zwerft, de EAP-verificatie en de WPA-sleutelbeheerprocessen nog steeds worden voltooid om dataframes te blijven passeren (zelfs als verkeer actief is verzonden vóór roaming). Als de client een actieve toepassing heeft die gevoelig is voor vertragingen (zoals toepassingen voor spraakverkeer of toepassingen die gevoelig zijn voor time-outs), kan de gebruiker problemen waarnemen bij roaming, zoals audioplekken of het verbreken van de verbinding van de toepassing. Dit hangt af van hoe lang het proces duurt voordat de klant gegevensframes blijft verzenden/ontvangen. Deze vertraging kan langer zijn, afhankelijk van: de RF-omgeving, het aantal clients, de retourtijd tussen de WLC en LAP's en met de verificatieserver en andere redenen.
Hier is een samenvatting van de debug-berichten voor dit roaming-evenement (in principe hetzelfde als de vorige, dus deze berichten worden niet verder beschreven):
*apfMsConnTask_2: Jun 21 23:47:54.872: 00:40:96:b7:ab:5c
Reassociation received from mobile on BSSID 84:78:ac:f0:2a:98
*apfMsConnTask_2: Jun 21 23:47:54.874: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:98
(status 0) ApVapId 9 Slot 0
*dot1xMsgTask: Jun 21 23:47:54.879: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 1)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
Received EAPOL START from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
dot1x - moving mobile 00:40:96:b7:ab:5c intoConnectingstate
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 4)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 4, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.956: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.957: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 7, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c
(EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
Dit is de manier waarop 802.1X/EAP en het WPA/WPA2-beveiligingskader werken. Om te voorkomen dat de toepassing/service gevolgen heeft voor vertragingen van een regulier roamingevenement, worden meerdere snel beveiligde roamingmethoden ontwikkeld en geïmplementeerd door de WiFi-industrie om het roamingproces te versnellen wanneer beveiliging wordt gebruikt op de WLAN/SSID. De clients hebben te maken met enige latentie wanneer ze verkeer blijven doorgeven terwijl ze rondzwerven tussen toegangspunten via de implementatie van beveiliging op hoog niveau op het WLAN. Dit is te wijten aan de EAP-verificatie en sleutelbeheerframeuitwisselingen die vereist zijn voor de beveiligingsconfiguratie, zoals eerder uitgelegd.
Het is belangrijk om te begrijpen dat snel beveiligde roaming slechts de term is die door de sector wordt gebruikt met betrekking tot de implementatie van een methode / schema dat het roamingproces versnelt wanneer de beveiliging op het WLAN wordt geconfigureerd. In de volgende sectie wordt uitgelegd welke verschillende methoden/schema's voor snel beveiligde roaming beschikbaar zijn voor WLAN's en worden ondersteund door de CUWN.
Snel en veilig roamen met CCKM
Cisco Centralized Key Management (CCKM) is de eerste snelle en veilige roamingmethode die is ontwikkeld en geïmplementeerd op WLAN's voor bedrijven, ontwikkeld door Cisco als de oplossing die wordt gebruikt om de tot nu toe verklaarde vertragingen te beperken wanneer 802.1X/EAP-beveiliging wordt gebruikt op het WLAN. Aangezien dit een Cisco-protocol is, wordt het alleen ondersteund door Cisco WLAN-infrastructuurapparaten en draadloze clients (van meerdere leveranciers) die compatibel zijn met Cisco Compatible Extension (CCX) voor CCKM.
CCKM kan worden geïmplementeerd met alle verschillende coderingsmethoden die beschikbaar zijn voor WLAN's, waaronder: WEP, TKIP en AES. Het wordt ook ondersteund met de meeste 802.1X/EAP-verificatiemethoden die voor WLAN's worden gebruikt, afhankelijk van de CCX-versie die door de apparaten wordt ondersteund.
Dit draadloze image geeft een voorbeeld van de frames die bij de eerste koppeling worden uitgewisseld wanneer u CCKM uitvoert met TKIP als codering en PEAPv0/EAP-MSCHAPv2 als 802.1X/EAP-methode. Dit is in principe dezelfde uitwisseling als wanneer WPA/TKIP met PEAPv0/EAP-MSCHAPv2 wordt uitgevoerd, maar deze keer wordt er onderhandeld over CCKM tussen de client en de infrastructuur, zodat ze verschillende sleutelhiërarchie en cachemethoden gebruiken om Fast Secure Roaming uit te voeren wanneer de client moet roamen:
Hier is een samenvatting van de foutopsporingsberichten (waarbij sommige EAP-uitwisselingen zijn verwijderd om de uitvoer te verminderen):
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
Association received from mobile on BSSID 84:78:ac:f0:68:d3
!--- This is the Association Request from the client.
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
Processing WPA IE type 221, length 22 for mobile
00:40:96:b7:ab:5c
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
CCKM: Mobile is using CCKM
!--- The WLC/AP finds an Information Element that claims CCKM
support on the Association request that is sent from the client.
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
!--- This is the key cache index for this client, which is set temporally.
*apfMsConnTask_0: Jun 25 15:41:41.508: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d3
(status 0) ApVapId 4 Slot 0
!--- The Association Response is sent to the client.
*dot1xMsgTask: Jun 25 15:41:41.513: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 1)
!--- An EAP Identity Request is sent to the client once it is
associated in order to begin the higher-level authentication
process. This informs the client that an identity to start
this type of 802.1X/EAP authentication must be provided.
Further EAP messages are not described, as they are basically
the same as the ones previously-explained.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.536: 00:40:96:b7:ab:5c
Received EAPOL START from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.536: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.546: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.546: 00:40:96:b7:ab:5c
Received EAP Response packet with mismatching id
(currentid=2, eapid=1) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.550: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.550: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile
00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.555: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.555: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.594: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.594: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.840: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Creating a PKC PMKID Cache entry for station 00:40:96:b7:ab:5c
(RSN 0)<br/ >
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
CCKM: Create a global PMK cache entry
!--- WLC creates a global PMK cache entry for this client,
which is for CCKM in this case.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c
(EAP Id 13)
!--- The client is informed of the successful EAP authentication.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
INITPMK(message 1),replay counter 00.00.00.00.00.00.00.00
!--- Message-1 of the initial 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2) from mobile
00:40:96:b7:ab:5c
!--- Message-2 of the initial 4-Way handshake is received
successfully from the client.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
CCKM: Sending cache add
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: CCKM: Sending CCKM PMK
(Version_1) information to mobility group
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: CCKM: Sending CCKM PMK
(Version_2) information to mobility group
!--- The CCKM PMK cache entry for this client is shared with
the WLCs on the mobility group.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- Message-3 of the initial 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.866: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.866: 00:40:96:b7:ab:5c Received
EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile
00:40:96:b7:ab:5c
!--- Message-4 (final message) of this initial 4-Way handshake
is received successfully from the client, which confirms the
installation of the derived keys. They can now be used in order
to encrypt data frames with the current AP.
Met CCKM is de initiële koppeling aan het WLAN vergelijkbaar met de reguliere WPA/WPA2, waarbij een MSK (ook hier bekend als de Network Session Key (NSK)) wederzijds wordt afgeleid met de client en de RADIUS-server.
Deze primaire sleutel wordt na een succesvolle verificatie van de server naar de WLC verzonden en wordt in de cache opgeslagen als basis voor de afleiding van alle volgende sleutels voor de levensduur van de clientkoppeling met dit WLAN.
Van hieruit halen de WLC en de client de seed-informatie die wordt gebruikt voor snel beveiligde roaming op basis van CCKM, dit gaat door een 4-Way handshake vergelijkbaar met die van WPA / WPA2, om de unicast (PTK) en multicast / broadcast (GTK) -coderingssleutels af te leiden met het eerste AP.
Het grote verschil wordt opgemerkt bij roaming. In dit geval stuurt de CCKM-client één frame voor het verzoek om herkoppeling naar het AP/WLC (dat een MIC en een opeenvolgend toenemend willekeurig nummer bevat) en biedt voldoende informatie (waaronder het nieuwe AP MAC-adres -BSSID-) om de nieuwe PTK af te leiden. Met dit Reassociation Request hebben de WLC en de nieuwe AP ook voldoende informatie om de nieuwe PTK af te leiden, dus ze reageren gewoon met een Reassociation Response. De client kan nu doorgaan met het doorgeven van verkeer, zoals weergegeven in deze afbeelding:
Hier is een samenvatting van de WLC-debugs voor dit roaming-evenement:
*apfMsConnTask_2: Jun 25 15:43:33.749: 00:40:96:b7:ab:5c
CCKM: Received REASSOC REQ IE
*apfMsConnTask_2: Jun 25 15:43:33.749: 00:40:96:b7:ab:5c
Reassociation received from mobile on BSSID
84:78:ac:f0:2a:93
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
Processing WPA IE type 221, length 22 for mobile
00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
CCKM: Mobile is using CCKM
!--- The Reassociation Request is received from the client,
which provides the CCKM information needed in order to
derive the new keys with a fast-secure roam.
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
Setting active key cache index 0 ---> 8
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
CCKM: Processing REASSOC REQ IE
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
CCKM: using HMAC MD5 to compute MIC
!--- WLC computes the MIC used for this CCKM fast-roaming
exchange.
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
CCKM: Received a valid REASSOC REQ IE
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
CCKM: Initializing PMK cache entry with a new PTK
!--- The new PTK is derived.
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 0
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Creating a PKC PMKID Cache entry for station
00:40:96:b7:ab:5c (RSN 0) on BSSID 84:78:ac:f0:2a:93
!--- The new PMKID cache entry is created for this new
AP-to-client association.
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
CCKM: using HMAC MD5 to compute MIC
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Including CCKM Response IE (length 62) in Assoc Resp to mobile
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:93
(status 0) ApVapId 4 Slot 0
!--- The Reassociation Response is sent from the WLC/AP to
the client, which includes the CCKM information required
in order to confirm the new fast-roam and key derivation.
*dot1xMsgTask: Jun 25 15:43:33.757: 00:40:96:b7:ab:5c
Skipping EAP-Success to mobile 00:40:96:b7:ab:5c
!--- EAP is skipped due to the fast roaming, and CCKM does not
require further key handshakes. The client is now ready to
pass encrypted data frames on the new AP.
Zoals te zien is, wordt snel beveiligd zwerven uitgevoerd terwijl de EAP-verificatieframes worden vermeden en nog meer 4-weg handshakes, omdat de nieuwe coderingssleutels nog steeds zijn afgeleid, maar gebaseerd op het CCKM-onderhandelingsschema.
Dit wordt aangevuld met de roaming reassociation frames en de informatie die eerder in de cache is opgeslagen door de klant en de WLC.
FlexConnect met CCKM
- Centrale verificatie wordt ondersteund. Dit omvat lokale en centrale gegevenswisseling. De toegangspunten moeten deel uitmaken van dezelfde FlexConnect-groep.
- Flex Local Authentication wordt ondersteund. In de verbonden modus kan de cache worden verdeeld van het toegangspunt naar de controller en vervolgens naar de rest van de toegangspunten in de FlexConnect-groep.
- De stand-alone modus wordt ondersteund. Als de cache al aanwezig is op het toegangspunt (vanwege eerdere distributie), zal snel zwerven werken. Nieuwe verificatie in de stand-alone modus biedt geen ondersteuning voor snel beveiligd zwerven.
Voordelen van CCKM
- CCKM is de snelste en veiligste roamingmethode die meestal wordt gebruikt op zakelijke WLAN's. Cliënten hoeven geen sleutelbeheerhandshake te doorlopen om nieuwe sleutels af te leiden wanneer een verplaatsing tussen toegangspunten plaatsvindt en hoeven nooit meer een volledige 802.1X/EAP-verificatie met nieuwe toegangspunten uit te voeren tijdens de clientlevensduur op dit WLAN.
- CCKM ondersteunt alle coderingsmethoden die beschikbaar zijn binnen de 802.11-standaard (WEP, TKIP en AES), naast enkele oudere Cisco-bedrijfseigen methoden die nog steeds worden gebruikt op oudere clients.
Nadelen met CCKM
- CCKM is een bedrijfseigen methode van Cisco, die de implementatie en ondersteuning van Cisco WLAN-infrastructuur en draadloze CCX-clients beperkt.
- CCX versie 5 wordt niet op grote schaal gebruikt, dus CCKM met WPA2/AES wordt niet ondersteund door veel draadloze CCX-clients (vooral omdat de meeste van hen CCKM al ondersteunen met WPA/TKIP, wat nog steeds erg veilig is).
Snel en veilig zwerven met PMKID-caching / Sticky Key Caching
Paarsgewijs denken dat Key ID (PMKID) caching, of Sticky Key Caching (SKC), de eerste snel beveiligde roamingmethode is die wordt voorgesteld door de IEEE 802.11-standaard binnen de 802.11i-beveiligingswijziging, waarbij het belangrijkste doel is om een hoog beveiligingsniveau voor WLAN's te standaardiseren. Deze snel beveiligde roamingtechniek werd toegevoegd als een optionele methode voor WPA2-apparaten om roaming te verbeteren toen deze beveiliging werd geïmplementeerd.
Dit is mogelijk omdat, elke keer dat een client volledig EAP-geverifieerd is, de client en de verificatieserver een MSK afleiden, die wordt gebruikt om de PMK af te leiden.
Deze methode wordt gebruikt als de kiem voor de WPA2 4-Way handshake om de uiteindelijke unicast-coderingssleutel (PTK) af te leiden die voor de sessie wordt gebruikt (totdat de client naar een ander toegangspunt zwerft of de sessie verloopt); daarom voorkomt deze methode de EAP-verificatiefase bij zwerven omdat de oorspronkelijke PMK die door de client en het toegangspunt in de cache is opgeslagen, opnieuw wordt gebruikt. De client hoeft alleen de WPA2 4-Way handshake te doorlopen om nieuwe coderingssleutels af te leiden.
Deze methode wordt niet op grote schaal toegepast als de aanbevolen 802.11 standaard snelle veilige roamingmethode, voornamelijk om deze redenen:
- Deze methode is optioneel en wordt niet ondersteund door alle WPA2-apparaten, omdat het doel van het 802.11i-amendement niet betrekking heeft op snel beveiligd zwerven, en de IEEE al aan een ander amendement heeft gewerkt om snel beveiligd zwerven voor WLAN's te standaardiseren (802.11r, dat verderop in dit document wordt behandeld).
- Deze methode heeft een grote beperking voor de implementatie: draadloze clients kunnen alleen snel en veilig roaming uitvoeren wanneer ze terugzwerven naar een toegangspunt waar ze eerder waren geverifieerd/verbonden.
Met deze methode is de eerste koppeling aan een toegangspunt net als een gewone eerste verificatie aan het WLAN, waarbij de volledige 802.1X/EAP-verificatie tegen de verificatieserver en de 4-voudige handshake voor het genereren van sleutels moeten plaatsvinden voordat de client gegevensframes kan verzenden, zoals wordt weergegeven in deze schermafbeelding:
De debugs onthullen dezelfde EAP-authenticatieframeuitwisseling als de rest van de methoden bij de eerste verificatie naar het WLAN, met enkele uitgangen toegevoegd met betrekking tot de belangrijkste cachingtechnieken die hier worden gebruikt.
Deze debug-uitgangen worden geknipt om voornamelijk de nieuwe informatie weer te geven, niet de volledige EAP-frameuitwisseling, omdat in principe elke keer dezelfde informatie wordt uitgewisseld voor verificatie van de client tegen de verificatieserver.
Dit is tot nu toe aangetoond en gecorreleerd met de EAP-verificatieframes die in de pakketafbeeldingen worden weergegeven, dus de meeste EAP-berichten worden voor de eenvoud uit de debug-uitgangen verwijderd:
*apfMsConnTask_0: Jun 22 00:23:15.097: ec:85:2f:15:39:32
Association received from mobile on BSSID 84:78:ac:f0:68:d2
!--- This is the Association Request from the client.
*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32
Processing RSN IE type 48, length 20 for mobile ec:85:2f:15:39:32
!--- The WLC/AP finds an Information Element that claims PMKID
Caching support on the Association request that is sent
from the client.
*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32
Received RSN IE with 0 PMKIDs from mobile ec:85:2f:15:39:32
!--- Since this is an initial association, the Association
Request comes without any PMKID.
*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*apfMsConnTask_0: Jun 22 00:23:15.099: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d2
(status 0) ApVapId 3 Slot 0
!--- The Association Response is sent to the client.
*dot1xMsgTask: Jun 22 00:23:15.103: ec:85:2f:15:39:32
Sending EAP-Request/Identity to mobile ec:85:2f:15:39:32
(EAP Id 1)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.118: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.118: ec:85:2f:15:39:32
Received Identity Response (count=1) from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.126: ec:85:2f:15:39:32
Processing Access-Challenge for mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.126: ec:85:2f:15:39:32
Sending EAP Request from AAA to mobile ec:85:2f:15:39:32
(EAP Id 2)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.146: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.146: ec:85:2f:15:39:32
Received EAP Response from mobile ec:85:2f:15:39:32
(EAP Id 2, EAP Type 25)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Processing Access-Accept for mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Creating a PKC PMKID Cache entry for station ec:85:2f:15:39:32
(RSN 2)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Adding BSSID 84:78:ac:f0:68:d2 to PMKID cache at index 0
for station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274:
New PMKID: (16)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- WLC creates a PMK cache entry for this client, which is
used for SKC in this case, so the PMKID is computed with
the AP MAC address (BSSID 84:78:ac:f0:68:d2).
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Sending EAP-Success to mobile ec:85:2f:15:39:32
(EAP Id 12)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275:
Including PMKID in M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
WPA/WPA2 4-Way handshake.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- This is the hashed PMKID.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
!--- Message-1 of the WPA/WPA2 4-Way handshake is sent from
the WLC/AP to the client.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from mobile
ec:85:2f:15:39:32
!--- Message-2 of the WPA/WPA-2 4-Way handshake is successfully
received from the client.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32
PMK: Sending cache add
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.285: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- Message-3 of the WPA/WPA2 4-Way handshake is sent from
the WLC/AP to the client.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.291: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.291: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
!--- Message-4 (final message) of this initial WPA/WPA2 4-Way
handshake is successfully received from the client, which
confirms the installation of the derived keys. They can
now be used in order to encrypt data frames with the current AP.
Met deze methode worden de PMK's van de reeds bestaande beveiligde verbindingen door het toegangspunt en de draadloze client in cache opgeslagen.
Als de draadloze client zwerft naar een nieuw toegangspunt waaraan hij nooit is gekoppeld, moet de client daarom opnieuw een volledige EAP-verificatie uitvoeren, zoals wordt weergegeven in deze afbeelding waarin de client zwerft naar een nieuw toegangspunt:
Als de draadloze client echter terugzwerft naar een toegangspunt waar een eerdere koppeling/verificatie heeft plaatsgevonden, verzendt de client een frame voor een herassociatieverzoek waarin meerdere PMKID's worden vermeld. Dit frame informeert het toegangspunt over de PMK's die in de cache zijn opgeslagen van alle toegangspunten waarvoor de client eerder een verificatie heeft uitgevoerd. Aangezien de client terugzwerft naar een toegangspunt dat ook een PMK in de cache voor deze client heeft, hoeft de client zich niet opnieuw te verifiëren via EAP om een nieuwe PMK af te leiden. De client gaat gewoon door de WPA2 4-Way handshake om de nieuwe transiënte encryptiesleutels af te leiden:
Hier is een samenvatting van de WLC-debugs voor deze snelle veilige roamingmethode:
*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
Reassociation received from mobile on BSSID
84:78:ac:f0:68:d2
!--- This is the Reassociation Request from the client.
*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
Processing RSN IE type 48, length 38 for mobile
ec:85:2f:15:39:32
!--- The WLC/AP finds an Information Element that claims PMKID
Caching support on the Association request that is sent
from the client.
*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
Received RSN IE with 1 PMKIDs from mobile
ec:85:2f:15:39:32
!--- The Reassociation Request from the client comes with
one PMKID.
*apfMsConnTask_0: Jun 22 00:26:40.787:
Received PMKID: (16)
*apfMsConnTask_0: Jun 22 00:26:40.788:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- This is the PMKID that is received.
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Searching for PMKID in MSCB PMKID cache for mobile
ec:85:2f:15:39:32
!--- WLC searches for a matching PMKID on the database.
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d2 in
PMKID cache at index 0 of station ec:85:2f:15:39:32
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Found a valid PMKID in the MSCB PMKID cache for mobile
ec:85:2f:15:39:32
!--- The WLC validates the PMKID provided by the client,
and confirms that it has a valid PMK cache for this
client-and-AP pair.
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Setting active key cache index 1 ---> 0
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID
84:78:ac:f0:68:d2(status 0) ApVapId 3 Slot 0
!--- The Reassociation Response is sent to the client, which
validates the fast-roam with SKC.
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Initiating RSN with existing PMK to mobile
ec:85:2f:15:39:32
!--- WLC initiates a Robust Secure Network association with
this client-and-AP pair based on the cached PMK found.
Hence, EAP is avoided as per the next message.
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Skipping EAP-Success to mobile ec:85:2f:15:39:32
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d2 in
PMKID cache at index 0 of station ec:85:2f:15:39:32
*dot1xMsgTask: Jun 22 00:26:40.795: Including PMKID in M1(16)
!--- The hashed PMKID is included on the Message-1 of the
WPA/WPA2 4-Way handshake.
*dot1xMsgTask: Jun 22 00:26:40.795:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- The PMKID is hashed. The next messages are the same
WPA/WPA2 4-Way handshake messages described thus far
that are used in order to finish the encryption keys
generation/installation.
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.811: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from mobile
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
PMK: Sending cache add
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.820: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.820: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
FlexConnect met PMKID Caching / Sticky Key Caching
- Wanneer u deze methode gebruikt voor een FlexConnect-installatie, kan deze werken en kan het gedrag lijken op wat eerder werd uitgelegd als u Central Authentication gebruikt om terug te keren naar de WLC (met centrale of lokale switching); deze SKC-methode wordt echter niet ondersteund op FlexConnect.
- Deze methode wordt alleen officieel ondersteund op CUWN met toegangspunten voor de lokale modus, niet op FlexConnect of andere modi.
Voordelen van PMKID Caching / Sticky Key Caching
Deze methode kan lokaal worden geïmplementeerd door autonome onafhankelijke AP's, zonder dat een gecentraliseerd apparaat nodig is om de sleutels in de cache te beheren.
Nadelen met PMKID Caching / Sticky Key Caching
- Zoals eerder vermeld in dit document, is de belangrijkste beperking van deze methode dat de client alleen snel beveiligde roaming kan uitvoeren wanneer hij terugzwerft naar een toegangspunt waar het eerder is gekoppeld/geauthenticeerd. Als u naar een nieuw toegangspunt zwerft, moet de client de volledige EAP-verificatie opnieuw voltooien.
- De draadloze client en toegangspunten moeten alle PMK's onthouden die zijn afgeleid bij elke nieuwe verificatie, dus deze functie is normaal beperkt tot een bepaalde hoeveelheid PMK's die in de cache zijn opgeslagen. Aangezien deze limiet niet duidelijk is gedefinieerd door de standaard, kunnen de leveranciers verschillende limieten definiëren voor hun SKC-implementaties. De Cisco WLAN-controllers kunnen bijvoorbeeld de PMK's momenteel vanaf een client in cache opslaan voor maximaal acht toegangspunten. Als een client naar meer dan acht toegangspunten per sessie zwerft, worden de oudste toegangspunten uit de cachelijst verwijderd om de nieuwe items in de cache op te slaan.
- Deze methode is optioneel en wordt nog steeds niet ondersteund door veel WPA2-apparaten; daarom wordt deze methode niet op grote schaal toegepast en geïmplementeerd.
- SKC wordt niet ondersteund wanneer u intercontrollerroaming uitvoert, wat gebeurt wanneer u zich verplaatst tussen toegangspunten die door verschillende WLC's worden beheerd, zelfs als ze zich in dezelfde mobiliteitsgroep bevinden.
Snel en veilig roamen met opportunistische key caching
Opportunistic Key Caching (OKC), ook bekend als Proactive Key Caching (PKC) (deze term wordt nader toegelicht in een notitie die hierna volgt), is in principe een verbetering van de eerder beschreven WPA2 PMKID-caching-methode, daarom wordt het ook Proactive / Opportunistic PMKID Caching genoemd. Daarom is het belangrijk op te merken dat dit geen snelle veilige roamingmethode is die wordt gedefinieerd door de 802.11-standaard en niet door veel apparaten wordt ondersteund, maar net als PMKID-caching werkt het met WPA2-EAP.
Met deze techniek kunnen de draadloze client en de WLAN-infrastructuur slechts één PMK cachen voor de levensduur van de clientkoppeling met dit WLAN (afgeleid van de MSK na de eerste 802.1X/EAP-verificatie met de verificatieserver), zelfs wanneer zwerven tussen meerdere AP's, omdat ze allemaal de oorspronkelijke PMK delen die wordt gebruikt als het zaad op alle WPA2 4-weg handshakes. Dit is nog steeds vereist, net als in SKC, om telkens nieuwe coderingssleutels te genereren wanneer de client opnieuw wordt gekoppeld aan de toegangspunten. Om deze ene originele PMK van de cliensessie te kunnen delen, moeten alle AP's onder een soort van administratieve controle staan, met een gecentraliseerd apparaat dat de originele PMK voor alle AP's in cache opslaat en distribueert. Dit is vergelijkbaar met de CUWN, waar de WLC deze taak uitvoert voor alle LAP's onder zijn controle en de mobiliteitsgroepen gebruikt om deze PMK tussen meerdere WLC's af te handelen; daarom is dit een beperking op autonome AP-omgevingen.
Met deze methode is, net als in PMKID Caching (SKC), de eerste koppeling aan een toegangspunt een regelmatige eerste verificatie naar het WLAN, waarbij u de volledige 802.1X/EAP-verificatie moet voltooien tegen de verificatieserver en de 4-weg handshake voor het genereren van sleutels voordat u gegevensframes kunt verzenden. Hier is een schermafbeelding die dit illustreert:
De debug-uitgangen tonen in principe dezelfde EAP-authenticatieframeuitwisseling als de rest van de methoden die in dit document worden beschreven bij de eerste verificatie naar het WLAN (zoals weergegeven in de afbeeldingen), samen met de toevoeging van enkele uitgangen die betrekking hebben op de belangrijkste cachingtechnieken die hier door de WLC worden gebruikt. Deze debug-uitvoer wordt ook gesneden om alleen de relevante informatie weer te geven:
*apfMsConnTask_0: Jun 21 21:46:06.515: 00:40:96:b7:ab:5c
Association received from mobile on BSSID
84:78:ac:f0:68:d2
!--- This is the Association Request from the client.
*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
Processing RSN IE type 48, length 20 for mobile
00:40:96:b7:ab:5c
!--- The WLC/AP finds an Information Element that claims
PMKID Caching support on the Association request that
is sent from the client.
*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
Received RSN IE with 0 PMKIDs from mobile
00:40:96:b7:ab:5c
!--- Since this is an initial association, the Association
Request comes without any PMKID.
*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
Setting active key cache index 0 ---> 8
*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID
84:78:ac:f0:68:d2 (status 0) ApVapId 3 Slot
!--- The Association Response is sent to the client.
*dot1xMsgTask: Jun 21 21:46:06.522: 00:40:96:b7:ab:5
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 1)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.614: 00:40:96:b7:ab:5c
Received EAPOL START from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.614: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.623: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.623: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile
00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.630: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.630: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.673: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.673: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.843: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Creating a PKC PMKID Cache entry for station
00:40:96:b7:ab:5c (RSN 2)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Adding BSSID 84:78:ac:f0:68:d2 to PMKID cache at index 0
for station 00:40:96:b7:ab:5
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: New PMKID: (16)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844:
[0000] 4e a1 7f 5a 75 48 9c f9 96 e3 a8 71 25 6f 11 d0
!--- WLC creates a PMK cache entry for this client, which is
used for OKC in this case, so the PMKID is computed
with the AP MAC address (BSSID 84:78:ac:f0:68:d2).
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
PMK sent to mobility group
!--- The PMK cache entry for this client is shared with the
WLCs on the mobility group.
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c (EAP Id 13)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Found an cache entry for BSSID 84:78:ac:f0:68:d2 in PMKID
cache at index 0 of station 00:40:96:b7:ab:5
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: Including PMKID
in M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
WPA/WPA2 4-Way handshake.
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844:
[0000] 4e a1 7f 5a 75 48 9c f9 96 e3 a8 71 25 6f 11 d0
!--- This is the hashed PMKID. The next messages are the same
WPA/WPA2 4-Way handshake messages described thus far that
are used in order to finish the encryption keys
generation/installation.
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
PMK: Sending cache add
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.889: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.890: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
Met deze methode wordt de oorspronkelijke PMK van de beveiligde koppeling die in eerste instantie is gemaakt, in cache opgeslagen door de draadloze client en de WLC (voor alle beheerde toegangspunten). Elke keer dat de draadloze client verbinding maakt met een specifiek toegangspunt, wordt een PMKID gehasht op basis van: het MAC-adres van de client, het MAC-adres van het toegangspunt (BSSID van het WLAN) en de PMK die met dat toegangspunt is afgeleid. Aangezien OKC dezelfde oorspronkelijke PMK voor alle AP's en de specifieke client in de cache opslaat, is de enige waarde die verandert om de nieuwe PMKID te hashen het nieuwe AP MAC-adres wanneer deze client (opnieuw) aan een ander AP wordt gekoppeld.
Wanneer de client roaming initieert naar een nieuw toegangspunt en het frame voor het verzoek om herkoppeling verzendt, voegt de client de PMKID toe aan het WPA2 RSN-informatie-element als deze het toegangspunt wil informeren dat een PMK in de cache wordt gebruikt voor snel beveiligde roaming. Het weet al het MAC-adres van de BSSID (AP) voor waar het zwerft, dan hasht de client gewoon de nieuwe PMKID die wordt gebruikt op dit Reassociation Request. Wanneer het toegangspunt dit verzoek van de client ontvangt, hasht het ook de PMKID met de waarden die het al heeft (de PMK in de cache, het MAC-adres van de client en het eigen MAC-adres van het toegangspunt) en reageert het met de succesvolle Reassociation Response die bevestigt dat de PMKID's zijn gekoppeld. De PMK in de cache kan worden gebruikt als het zaad dat een WPA2 4-Way handshake start om de nieuwe encryptiesleutels af te leiden (en EAP over te slaan):
In deze afbeelding wordt het frame Reassociation Request van de client geselecteerd en uitgebreid, zodat u meer details van het frame kunt zien. De MAC-adresinformatie en ook het informatie-element Robuust Security Network (RSN, volgens 802.11i - WPA2), waar informatie over de WPA2-instellingen die voor deze koppeling worden gebruikt, wordt weergegeven (gemarkeerd is de PMKID verkregen uit de gehashte formule).
Hier is een samenvatting van WLC-debugs voor deze snelle veilige roamingmethode met OKC:
*apfMsConnTask_2: Jun 21 21:48:50.562: 00:40:96:b7:ab:5c
Reassociation received from mobile on BSSID
84:78:ac:f0:2a:92
!--- This is the Reassociation Request from the client.
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Processing RSN IE type 48, length 38 for mobile
00:40:96:b7:ab:5c
!--- The WLC/AP finds and Information Element that claims
PMKID Caching support on the Association request that
is sent from the client.
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Received RSN IE with 1 PMKIDs from mobile
00:40:96:b7:ab:5c
!--- The Reassociation Request from the client comes with
one PMKID.
*apfMsConnTask_2: Jun 21 21:48:50.563:
Received PMKID: (16)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Searching for PMKID in MSCB PMKID cache for mobile
00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
No valid PMKID found in the MSCB PMKID cache for mobile
00:40:96:b7:ab:5
!--- As the client has never authenticated with this new AP,
the WLC cannot find a valid PMKID to match the one provided
by the client. However, since the client performs OKC
and not SKC (as per the following messages), the WLC computes
a new PMKID based on the information gathered (the cached PMK,
the client MAC address, and the new AP MAC address).
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Trying to compute a PMKID from MSCB PMK cache for mobile
00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: Find PMK in cache: BSSID = (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 84 78 ac f0 2a 90
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: Find PMK in cache: realAA = (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 84 78 ac f0 2a 92
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: Find PMK in cache: PMKID = (16)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: AA (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 84 78 ac f0 2a 92
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: SPA (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 00 40 96 b7 ab 5c
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Adding BSSID 84:78:ac:f0:2a:92 to PMKID cache at
index 0 for station 00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 21 21:48:50.563:
New PMKID: (16)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Computed a valid PMKID from MSCB PMK cache for mobile
00:40:96:b7:ab:5c
!--- The new PMKID is computed and validated to match the
one provided by the client, which is also computed with
the same information. Hence, the fast-secure roam is
possible.
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Setting active key cache index 0 ---> 0
*apfMsConnTask_2: Jun 21 21:48:50.564: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:92
(status 0) ApVapId 3 Slot
!--- The Reassociation response is sent to the client, which
validates the fast-roam with OKC.
*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
Initiating RSN with existing PMK to mobile
00:40:96:b7:ab:5c
!--- WLC initiates a Robust Secure Network association with
this client-and AP pair with the cached PMK found.
Hence, EAP is avoided, as per the the next message.
*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
Skipping EAP-Success to mobile 00:40:96:b7:ab:5c
*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
Found an cache entry for BSSID 84:78:ac:f0:2a:92 in
PMKID cache at index 0 of station 00:40:96:b7:ab:5c
*dot1xMsgTask: Jun 21 21:48:50.570:
Including PMKID in M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
WPA/WPA2 4-Way handshake.
*dot1xMsgTask: Jun 21 21:48:50.570:
[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
!--- The PMKID is hashed. The next messages are the same
WPA/WPA2 4-Way handshake messages described thus far,
which are used in order to finish the encryption keys
generation/installation.
*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2) from mobile
00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5c
PMK: Sending cache add
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.590: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.610: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.610: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
Zoals getoond aan het begin van de debugs, moet de PMKID worden berekend nadat het Reassociation Request van de client is ontvangen.
Dit is nodig om de PMKID te valideren en te bevestigen dat de in de cache opgeslagen PMK wordt gebruikt met de WPA2 4-Way handshake om de coderingssleutels af te leiden en de snel beveiligde roaming te voltooien.
Verwar de CCKM-vermeldingen op de debugs niet; dit wordt niet gebruikt om CCKM uit te voeren, maar OKC, zoals eerder uitgelegd.
CCKM is hier gewoon een naam die door de WLC wordt gebruikt voor die uitgangen, zoals de naam van een functie die de waarden verwerkt om de PMKID te berekenen.
FlexConnect met opportunistische key caching
- Centrale verificatie wordt ondersteund. Dit geldt ook voor lokale en centrale gegevensoverdracht. Als het toegangspunt deel uitmaakt van dezelfde FlexConnect-groep, wordt snel beveiligde roam door het toegangspunt gebruikt, anders wordt snel beveiligde roam door de controller gebruikt.
- Flex Local Authentication wordt ondersteund. In de verbonden modus kan de cache worden verdeeld van het toegangspunt naar de controller en vervolgens naar de rest van de toegangspunten in de FlexConnect-groep.
- De stand-alone modus wordt ondersteund. Als de cache al aanwezig is op het toegangspunt (vanwege eerdere distributie), werkt snel beveiligde roaming. Nieuwe verificatie in de stand-alone modus biedt geen ondersteuning voor snel beveiligd zwerven.
Voordelen van Opportunistische Key Caching
- De draadloze client en de WLAN-infrastructuur hoeven niet meerdere PMKID's te onthouden, maar cachen gewoon de oorspronkelijke PMK van de eerste verificatie in het WLAN. Vervolgens moet u de juiste PMKID (gebruikt op het verzoek om herkoppeling) die vereist is bij elke beveiligde AP-koppeling opnieuw gebruiken om de snelle en veilige roaming te valideren.
- Hier voert de draadloze client snel en veilig zwerven naar een nieuw toegangspunt uit op hetzelfde WLAN/SSID, zelfs als het nooit is gekoppeld aan dat toegangspunt (niet het geval in SKC). Zolang de client de initiële 802.1X/EAP-verificatie uitvoert met één toegangspunt dat wordt beheerd door de gecentraliseerde implementatie die de PMK-cache verwerkt voor alle toegangspunten waar de client zwerft, zijn er geen volledige verificaties meer nodig voor de rest van de clientlevensduur op dit WLAN.
Nadelen van Opportunistische Key Caching
- Deze methode wordt alleen geïmplementeerd in een gecentraliseerde omgeving waar alle toegangspunten onder een soort van administratieve controle staan (zoals een WLAN-controller) die verantwoordelijk is voor het cachen en delen van de ene originele PMK van de cliensessie. Dit is een beperking voor autonome AP-omgevingen.
- De technieken die in deze methode worden toegepast, worden niet voorgesteld of beschreven op de 802.11-standaard, dus de ondersteuning varieert sterk van het ene apparaat tot het andere. Toch is dit nog steeds de methode die meer werd aangenomen tijdens het wachten op 802.11r.
Het gaat om de term ‘proactieve key caching’
Proactieve Key Caching (of PKC) staat bekend als OKC (Opportunistische Key Caching) en de twee termen worden door elkaar gebruikt wanneer ze dezelfde methode beschrijven die hier wordt uitgelegd.
Dit was echter slechts een term die in 2001 door Airspace werd gebruikt voor een oude cachingmethode voor sleutels, die vervolgens werd gebruikt door de 802.11i-standaard als basis voor "pre-authenticatie" (een andere Fast Secure Roaming-methode wordt hieronder kort uitgelegd).
PKC is geen pre-authenticatie of OKC (Opportunistic Key Caching), maar als je over PKC hoort of leest, is de verwijzing in principe naar OKC en niet naar pre-authenticatie.
Snel en veilig zwerven met pre-authenticatie
Deze methode wordt ook voorgesteld door de IEEE 802.11-standaard binnen het 802.11i-beveiligingsamendement, dus het werkt ook met WPA2, maar het is de enige Fast Secure Roaming-methode die niet wordt ondersteund door Cisco WLAN-infrastructuur.
Om deze reden wordt het hier slechts kort uitgelegd en zonder uitgangen.
Met Preauthenticatie kunnen de draadloze clients met meerdere toegangspunten tegelijk worden geverifieerd terwijl ze aan het huidige toegangspunt zijn gekoppeld.
Wanneer dit gebeurt, verzendt de client de EAP-verificatieframes naar het huidige toegangspunt waarop deze is aangesloten, maar deze zijn bestemd voor het (de) andere toegangspunt(en) waar de client Preauthenticatie wil uitvoeren (naburige toegangspunten die mogelijk kandidaat zijn voor roaming). Het huidige toegangspunt verzendt deze frames naar de doeltoegangspunten via het distributiesysteem. Het nieuwe toegangspunt voert volledige verificatie uit ten opzichte van de RADIUS-server voor deze client, zodat een volledige nieuwe EAP-verificatie-handshake is voltooid en dit nieuwe toegangspunt fungeert als de verificator.
Het idee is om authenticatie uit te voeren en PMK af te leiden met de naburige AP's voordat de client daadwerkelijk naar hen zwerft, dus wanneer het tijd is om te zwerven, is de client al geverifieerd en met een PMK al in de cache voor deze nieuwe AP-naar-client beveiligde associatie, dus ze hoeven alleen de 4-weg handshake uit te voeren en een snelle zwerftocht te ervaren nadat de client zijn eerste Reassociation-verzoek heeft verzonden.
Hier is een afbeelding van een AP-baken dat het RSN IE-veld toont dat reclame maakt voor ondersteuning voor Preauthenticatie (deze afbeelding is van een Cisco AP, waar wordt bevestigd dat Preauthenticatie niet wordt ondersteund):
Voordelen van pre-authenticatie
Er is één PMK voor elke AP-naar-client beveiligde koppeling, die kan worden beschouwd als een beveiligingsvoordeel in het geval dat een AP wordt aangetast en de sleutels worden gestolen (kan niet worden gebruikt met andere AP's). Dit beveiligingsvoordeel wordt echter op verschillende manieren door de WLAN-infrastructuur afgehandeld op andere methoden.
Nadelen met pre-authenticatie
- Omdat er één PMK per AP is, hebben de clients een limiet voor het aantal AP's dat vooraf kan worden geverifieerd.
- Telkens wanneer een client preverificatie uitvoert met een nieuw toegangspunt, vindt er een volledige EAP-verificatie-uitwisseling plaats, wat betekent dat het netwerk en de verificatieserver meer worden belast.
- De meeste draadloze clients ondersteunen deze methode niet, omdat deze methode nooit in hoge mate is overgenomen (OKC werd meer overgenomen).
Snel en veilig roamen met 802.11r
De snel beveiligde roamingtechniek op basis van het 802.11r-amendement (officieel Fast BSS Transition genoemd door de 802.11-standaard en bekend als FT) is de eerste methode die officieel is geratificeerd (op 2008) door de IEEE voor de 802.11-standaard als de oplossing voor het uitvoeren van snelle overgangen tussen AP's (Basic Service Sets of BSS's), die duidelijk de sleutelhiërarchie definieert die wordt gebruikt wanneer u sleutels op een WLAN verwerkt en cachet. De goedkeuring ervan verliep echter traag, voornamelijk vanwege de andere oplossingen die al beschikbaar waren toen snelle overgangen daadwerkelijk nodig waren, zoals bij VoWLAN-implementaties wanneer deze werden gebruikt met een van de methoden die eerder in dit document werden uitgelegd. Er zijn slechts een paar apparaten die momenteel een aantal van de FT-opties ondersteunen (tegen 2013).
Deze techniek is complexer uit te leggen dan de andere methoden, omdat het nieuwe concepten en meerdere lagen PMK's introduceert die op verschillende apparaten in de cache worden opgeslagen (elk apparaat met een andere rol) en biedt nog meer opties voor snel beveiligd zwerven. Daarom wordt een korte samenvatting gegeven over deze methode en de manier waarop deze wordt geïmplementeerd met elke beschikbare optie.
802.11r verschilt van SKC en OKC, voornamelijk om deze redenen:
- Handshake messaging (bijvoorbeeld PMKID, ANonce en SNonce-uitwisseling) vindt plaats in 802.11-verificatieframes of in Action-frames in plaats van Herassociatieframes. In tegenstelling tot PMKID caching methoden, wordt de afzonderlijke 4-Way handshake fase, die wordt uitgevoerd na de (re) associatie berichtenuitwisseling, vermeden. De belangrijkste handdruk met het nieuwe toegangspunt begint voordat de client volledig zwerft/opnieuw wordt gekoppeld aan dit nieuwe toegangspunt.
- Het biedt twee methoden voor de snelle handshake: over de AIR en over het distributiesysteem (DS).
- 802.11r heeft meer lagen van sleutelhiërarchie.
- Aangezien dit protocol de 4-weg handshake voor het sleutelbeheer vermijdt wanneer een client zwerft (genereert nieuwe coderingssleutels -PTK en GTK- zonder de noodzaak van deze handshake), kan het ook worden toegepast voor WPA2-instellingen met een PSK, en niet alleen wanneer 802.1X/EAP wordt gebruikt voor de verificatie. Dit versnelt de roaming nog meer voor deze opstellingen, waar geen EAP of 4-Way handshake uitwisselingen plaatsvinden.
Met deze methode voert de draadloze client slechts één initiële verificatie uit ten opzichte van de WLAN-infrastructuur wanneer een verbinding met het eerste toegangspunt tot stand wordt gebracht, en voert deze een snelle en veilige roaming uit tijdens roaming tussen toegangspunten van hetzelfde FT-mobiliteitsdomein.
Dit is een van de nieuwe concepten, die in principe verwijst naar de toegangspunten die dezelfde SSID gebruiken (bekend als een Extended Service Set of ESS) en dezelfde FT-sleutels verwerken.
Dit is vergelijkbaar met de andere methoden die tot nu toe zijn uitgelegd. De manier waarop de AP's omgaan met de FT-mobiliteitsdomeinsleutels is normaal gesproken gebaseerd op een gecentraliseerde setup, zoals de WLC of mobiliteitsgroepen; deze methode kan echter ook worden geïmplementeerd op autonome AP-omgevingen.
Hier is een samenvatting van de belangrijkste hiërarchie:
- Een MSK wordt nog steeds afgeleid op de client-aanvrager en de verificatieserver van de initiële 802.1X/EAP-verificatiefase (overgedragen van de verificatieserver naar de verificator (WLC) zodra de verificatie is voltooid). Deze MSK wordt, net als in de andere methoden, gebruikt als het zaad voor de FT-sleutelhiërarchie. Wanneer u WPA2-PSK gebruikt in plaats van een EAP-verificatiemethode, is de PSK in principe deze MSK.
- Een paarsgewijze hoofdsleutel R0 (PMK-R0) is afgeleid van de MSK, die de hoofdsleutel op het eerste niveau van de FT-sleutelhiërarchie is. De sleutelhouders voor deze PMK-R0 zijn de WLC en de klant.
- Een tweede niveau sleutel, genaamd een Pairwise Master Key R1 (PMK-R1), is afgeleid van de PMK-R0, en de sleutelhouders zijn de client en de AP's beheerd door de WLC die de PMK-R0 bezit.
- Het derde en laatste niveau sleutel van de FT key hiërarchie is de PTK, die de uiteindelijke sleutel gebruikt om de 802.11 unicast dataframes te versleutelen (vergelijkbaar met de andere methoden die gebruik maken van WPA / TKIP of WPA2 / AES). Deze PTK is op FT afgeleid van de PMK-R1, en de sleutelhouders zijn de klant en de AP's beheerd door de WLC.
Snelle BSS-overgang over de lucht
Bij deze methode is de eerste koppeling aan een toegangspunt een regelmatige eerste verificatie van het WLAN, waarbij de volledige 802.1X/EAP-verificatie tegen de verificatieserver en de 4-voudige handshake voor het genereren van sleutels moeten plaatsvinden voordat gegevensframes worden verzonden, zoals wordt weergegeven in deze schermafbeelding:
De belangrijkste verschillen zijn:
- De onderhandeling over het beheer van de verificatiesleutel is iets anders dan bij gewone WPA/WPA2, dus er wordt wat extra informatie gebruikt om deze onderhandeling uit te voeren wanneer de koppeling met een WLAN-infrastructuur die FT ondersteunt, plaatsvindt. Zoals in de afbeelding wordt getoond, wordt het frame Associatieverzoek van de client geselecteerd en wordt het AKM-veld van het RNS-gegevenselement gemarkeerd om aan te geven dat deze client FT over 802.1X/EAP wil uitvoeren.
- Ook wordt het Mobility Domain Information Element (onderdeel van FT) weergegeven, waarbij het veld FT Capability and Policy aangeeft of de Fast BSS Transition is voltooid over-the-air of over-the-DS bij snel zwerven (dit geeft Over-the-Air in deze afbeelding aan).
- Er wordt ook een ander informatie-element toegevoegd (Fast BSS Transition of FT IE, dat verderop in dit document wordt beschreven) met informatie die nodig is om de FT-verificatiesequentie uit te voeren wanneer FT-roaming plaatsvindt.
- De sleutelgeneratie is anders vanwege de sleutelhiërarchie, dus hoewel de FT 4-Way handshake lijkt op de WPA / WPA2 4-Way handshake, is het eigenlijk iets anders in inhoud.
De debugs tonen in principe dezelfde EAP-authenticatieframeuitwisseling als de rest van de methoden bij de eerste verificatie naar het WLAN (zoals opgemerkt in de afbeeldingen), maar sommige uitgangen die betrekking hebben op de belangrijkste cachingtechnieken die door de WLC worden gebruikt, worden toegevoegd; dus wordt deze debug-uitvoer gesneden om alleen de relevante informatie weer te geven:
*apfMsConnTask_0: Jun 27 19:25:23.426: ec:85:2f:15:39:32
Association received from mobile on BSSID
84:78:ac:f0:68:d6
!--- This is the Association request from the client.
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Marking this mobile as TGr capable.
!--- WLC recognizes that the client is 802.11r-capable.
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Processing RSN IE type 48, length 20 for mobile
ec:85:2f:15:39:32
!--- The WLC/AP finds an Information Element that claims FT
support on the Association request that is sent from the client.
*apfMsConnTask_0: Jun 27 19:25:23.427:
Sending assoc-resp station:ec:85:2f:15:39:32
AP:84:78:ac:f0:68:d0-00 thread:144be808
*apfMsConnTask_0: Jun 27 19:25:23.427:
Adding MDIE, ID is:0xaaf0
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Including FT Mobility Domain IE (length 5) in Initial
assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Sending R0KH-ID as:-84.30.6.-3
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Sending R1KH-ID as 3c:ce:73:d8:02:00
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Including FT IE (length 98) in Initial Assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d6
(status 0) ApVapId 7 Slot 0
!--- The Association Response is sent to the client once the
FT information is computed (as per the previous messages),
so this is included in the response.
*dot1xMsgTask: Jun 27 19:25:23.432: ec:85:2f:15:39:32
Sending EAP-Request/Identity to mobile ec:85:2f:15:39:32
(EAP Id 1)
!--- EAP begins, andfollowsthe same exchange explained so far.
*apfMsConnTask_0: Jun 27 19:25:23.436: ec:85:2f:15:39:32
Got action frame from this client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32
Received Identity Response (count=1) from mobile
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32
Processing Access-Challenge for mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32
Sending EAP Request from AAA to mobile ec:85:2f:15:39:32
(EAP Id 2)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32
Received EAP Response from mobile ec:85:2f:15:39:32
(EAP Id 2, EAP Type 25)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Processing Access-Accept for mobile ec:85:2f:15:39:32
!--- The client is validated/authenticated by the RADIUS Server.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Creating a PKC PMKID Cache entry for station
ec:85:2f:15:39:32 (RSN 2)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Resetting MSCB PMK Cache Entry 0 for station
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32
Adding BSSID 84:78:ac:f0:68:d6 to PMKID cache at index 0
for station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: New PMKID: (16)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628:
[0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629: ec:85:2f:15:39:32
Created PMK Cache Entry for TGr AKM:802.1x ec:85:2f:15:39:32
!--- WLC creates a PMK cache entry for this client, which is
used for FT with 802.1X in this case, so the PMKID is
computed with the AP MAC address (BSSID 84:78:ac:f0:68:d6).
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629:
ec:85:2f:15:39:32 R0KH-ID:172.30.6.253
R1KH-ID:3c:ce:73:d8:02:00 MSK Len:48 pmkValidTime:1807
!--- The R0KH-ID and R1KH-ID are defined, as well as the PMK
cache validity period.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
PMK sent to mobility group
!--- The FT PMK cache entry for this client is shared with the
WLCs on the mobility group.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Sending EAP-Success to mobile ec:85:2f:15:39:32 (EAP Id 12)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d6 in PMKID
cache at index 0 of station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: Including PMKID in
M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
initial FT 4-Way handshake.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630:
[0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.0
!--- Message-1 of the FT 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from
mobile ec:85:2f:15:39:32
!--- Message-2 of the FT 4-Way handshake is received
successfully from the client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Calculating PMKR0Name
!--- The PMKR0Name is calculated.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
DOT11R: Sending cache add
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: Adding MDIE,
ID is:0xaaf0
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Adding TIE for reassociation deadtime:20000 milliseconds
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Adding TIE for R0Key-Data valid time :1807
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.640: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- After the MDIE, TIE for reassociation deadtime, and TIE
for R0Key-Data valid time are calculated, the Message-3
of this FT 4-Way handshake is sent from the WLC/AP to the
client with this information.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
!--- Message-4 (final message) of this initial FT 4-Way handshake
is received successfully from the client, which confirms the
installation of the derived keys. They can now be used in order
to encrypt data frames with the current AP.
Hier zijn de afbeeldingen en foutopsporingen van een eerste koppeling met het WLAN wanneer u FT uitvoert met WPA2-PSK (in plaats van een 802.1X/EAP-methode), waarbij het associatieresponsframe van het toegangspunt is geselecteerd om het Fast BSS Transition Information Element (gemarkeerd) weer te geven. Enkele van de belangrijkste informatie die nodig is om de FT 4-Way handshake uit te voeren wordt ook getoond:
*apfMsConnTask_0: Jun 27 19:29:09.136: ec:85:2f:15:39:32
Association received from mobile on BSSID
84:78:ac:f0:68:d4
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Marking this mobile as TGr capable.
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Processing RSN IE type 48, length 20 for mobile
ec:85:2f:15:39:32
*apfMsConnTask_0: Jun 27 19:29:09.137: Sending assoc-resp
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:68:d0-00
thread:144be808
*apfMsConnTask_0: Jun 27 19:29:09.137: Adding MDIE,
ID is:0xaaf0
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Including FT Mobility Domain IE (length 5) in Initial
assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Sending R0KH-ID as:-84.30.6.-3
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Sending R1KH-ID as 3c:ce:73:d8:02:00
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Including FT IE (length 98) in Initial Assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:29:09.138: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d4
(status 0) ApVapId 5 Slot 0
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Creating a PKC PMKID Cache entry for station
ec:85:2f:15:39:32 (RSN 2)
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Resetting MSCB PMK Cache Entry 0 for station
ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 0
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Adding BSSID 84:78:ac:f0:68:d4 to PMKID cache at
index 0 for station ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.142: New PMKID: (16)
*dot1xMsgTask: Jun 27 19:29:09.142:
[0000] 17 4b 17 5c ed 5f c7 1d 66 39 e9 5d 3a 63 69 e7
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Creating global PMK cache for this TGr client
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Created PMK Cache Entry for TGr AKM:PSK
ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
R0KH-ID:172.30.6.253 R1KH-ID:3c:ce:73:d8:02:00
MSK Len:48 pmkValidTime:1813
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Initiating RSN PSK to mobile ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d4 in
PMKID cache at index 0 of station ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.142: Including PMKID
in M1 (16)
*dot1xMsgTask: Jun 27 19:29:09.142:
[0000] 17 4b 17 5c ed 5f c7 1d 66 39 e9 5d 3a 63 69 e7
*dot1xMsgTask: Jun 27 19:29:09.143: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
*apfMsConnTask_0: Jun 27 19:29:09.144: ec:85:2f:15:39:32
Got action frame from this client.
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.152: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from
mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Calculating PMKR0Name
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: Adding MDIE,
ID is:0xaaf0
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Adding TIE for reassociation deadtime:20000 milliseconds
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Adding TIE for R0Key-Data valid time :1813
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.154: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.163: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.163: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
Met 802.11r is de eerste koppeling aan het WLAN de basis die wordt gebruikt om de basissleutels af te leiden die door deze techniek worden gebruikt, net als bij de andere snel beveiligde roamingmethoden.
De belangrijkste verschillen komen wanneer de client begint te zwerven; FT vermijdt niet alleen 802.1X / EAP wanneer dit wordt gebruikt, maar het voert zelfs een efficiëntere zwerfmethode uit die de initiële 802.11 Open System Authentication en Reassociation-frames combineert (die altijd worden gebruikt en vereist bij roaming tussen AP's) om FT-informatie uit te wisselen en nieuwe dynamische coderingssleutels af te leiden in plaats van de 4-Way handshake.
De volgende afbeelding toont de frames die worden uitgewisseld wanneer een Fast BSS Transition Over-the-Air met 802.1X/EAP-beveiliging wordt uitgevoerd. Het Open System Authentication-frame van de client naar het toegangspunt wordt geselecteerd om de FT-protocolinformatie-elementen te zien die nodig zijn om de FT-sleutelonderhandeling te starten. Dit wordt gebruikt om de nieuwe PTK af te leiden met de nieuwe AP (gebaseerd op de PMK-R1). Het veld met het verificatiealgoritme wordt gemarkeerd om aan te geven dat deze client geen eenvoudige Open System Authentication uitvoert, maar een Fast BSS Transition:
Hier zijn de foutopsporingsuitgangen van de WLC wanneer dit FT-roamingevenement plaatsvindt met 802.1X/EAP:
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
Doing preauth for this client over the Air
!--- WLC begins FT fast-secure roaming over-the-Air with
this client and performs a type of preauthentication,
because the client asks for this with FT on the Authentication
frame that is sent to the new AP over-the-Air
(before the Reassociation Request).
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
Doing local roaming for destination address
84:78:ac:f0:2a:96
!--- WLC performs the local roaming event with the new AP to
which the client roams.
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
Got 1 AKMs in RSNIE
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
RSNIE AKM matches with PMK cache entry :0x3
!--- WLC receives one PMK from this client (known as AKM here),
which matches the PMK cache entry hold for this client.
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
Created a new preauth entry for AP:84:78:ac:f0:2a:96
*apfMsConnTask_2: Jun 27 19:25:48.751: Adding MDIE,
ID is:0xaaf0
!--- WLC creates a new preauth entry for this AP-and-Client pair,
and adds the MDIE information.
*apfMsConnTask_2: Jun 27 19:25:48.763: Processing assoc-req
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
thread:144bef38
*apfMsConnTask_2: Jun 27 19:25:48.763: ec:85:2f:15:39:32
Reassociation received from mobile on BSSID
84:78:ac:f0:2a:96
!--- Once the client receives the Authentication frame reply from the
WLC/AP, the Reassociation request is sent, which is received at
the new AP to which the client roams.
*apfMsConnTask_2: Jun 27 19:25:48.764: ec:85:2f:15:39:32
Marking this mobile as TGr capable.
*apfMsConnTask_2: Jun 27 19:25:48.764: ec:85:2f:15:39:32
Processing RSN IE type 48, length 38 for mobile
ec:85:2f:15:39:32
*apfMsConnTask_2: Jun 27 19:25:48.765: ec:85:2f:15:39:32
Roaming succeed for this client.
!--- WLC confirms that the FT fast-secure roaming is successful
for this client.
*apfMsConnTask_2: Jun 27 19:25:48.765: Sending assoc-resp
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
thread:144bef38
*apfMsConnTask_2: Jun 27 19:25:48.766: Adding MDIE,
ID is:0xaaf0
*apfMsConnTask_2: Jun 27 19:25:48.766: ec:85:2f:15:39:32
Including FT Mobility Domain IE (length 5) in
reassociation assoc Resp to mobile
*apfMsConnTask_2: Jun 27 19:25:48.766: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:96
(status 0) ApVapId 7 Slot 0
!--- The Reassociation response is sent to the client, which
includes the FT Mobility Domain IE.
*dot1xMsgTask: Jun 27 19:25:48.769: ec:85:2f:15:39:32
Finishing FT roaming for mobile ec:85:2f:15:39:32
!--- FT roaming finishes and EAP is skipped (as well as any
other key management handshake), so the client is ready
to pass encrypted data frames with the current AP.
*dot1xMsgTask: Jun 27 19:25:48.769: ec:85:2f:15:39:32
Skipping EAP-Success to mobile ec:85:2f:15:39:32
Hier is een afbeelding die een Fast BSS Transition Over-the-Air met WPA2-PSK-beveiliging laat zien, waarbij het definitieve Reassociation Response-frame van het toegangspunt naar de client wordt geselecteerd om meer details over deze FT-uitwisseling te tonen:
Hier zijn de foutopsporingsuitgangen wanneer deze FT-roaminggebeurtenis plaatsvindt met PSK, die vergelijkbaar zijn met die wanneer 802.1X/EAP wordt gebruikt:
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
Doing preauth for this client over the Air
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
Doing local roaming for destination address
84:78:ac:f0:2a:94
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
Got 1 AKMs in RSNIE
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
RSNIE AKM matches with PMK cache entry :0x4
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
Created a new preauth entry for AP:84:78:ac:f0:2a:94
*apfMsConnTask_2: Jun 27 19:29:29.854: Adding MDIE,
ID is:0xaaf0
*apfMsConnTask_2: Jun 27 19:29:29.867: Processing assoc-req
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
thread:144bef38
*apfMsConnTask_2: Jun 27 19:29:29.867: ec:85:2f:15:39:32
Reassociation received from mobile on BSSID
84:78:ac:f0:2a:94
*apfMsConnTask_2: Jun 27 19:29:29.868: ec:85:2f:15:39:32
Marking this mobile as TGr capable.
*apfMsConnTask_2: Jun 27 19:29:29.868: ec:85:2f:15:39:32
Processing RSN IE type 48, length 38 for mobile
ec:85:2f:15:39:32
*apfMsConnTask_2: Jun 27 19:29:29.869: ec:85:2f:15:39:32
Roaming succeed for this client.
*apfMsConnTask_2: Jun 27 19:29:29.869: Sending assoc-resp
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
thread:144bef38
*apfMsConnTask_2: Jun 27 19:29:29.869: Adding MDIE,
ID is:0xaaf0
*apfMsConnTask_2: Jun 27 19:29:29.869: ec:85:2f:15:39:32
Including FT Mobility Domain IE (length 5) in
reassociation assoc Resp to mobile
*apfMsConnTask_2: Jun 27 19:29:29.870: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID
84:78:ac:f0:2a:94 (status 0) ApVapId 5 Slot 0
*dot1xMsgTask: Jun 27 19:29:29.874: ec:85:2f:15:39:32
Finishing FT roaming for mobile ec:85:2f:15:39:32
Zoals in de afbeelding te zien is, worden de vier frames die worden gebruikt en vereist voor roaming (Open systeemverificatie van de client, Open systeemverificatie van het toegangspunt, Reassociation Request en Reassociation Response), zodra de Fast BSS-overgang is onderhandeld bij de eerste koppeling met het WLAN, in principe gebruikt als een FT 4-weg handshake om de nieuwe PTK (unicast-coderingssleutel) en GTK (multicast/broadcast-coderingssleutel) af te leiden.
Dit vervangt de 4-Way handshake die normaal optreedt nadat deze frames zijn uitgewisseld, en de FT-inhoud en de belangrijkste onderhandeling op deze frames is in principe hetzelfde, of u nu 802.1X / EAP of PSK gebruikt als de beveiligingsmethode. Zoals in de afbeelding te zien is, is het AKM-veld het belangrijkste verschil, wat bevestigt of de client FT met PSK of 802.1X uitvoert. Daarom is het belangrijk op te merken dat deze vier frames normaal gesproken niet over dit type beveiligingsinformatie beschikken voor belangrijke onderhandelingen, maar alleen wanneer client FT-roams uitvoeren als 802.11r wordt geïmplementeerd en onderhandeld tussen de client en de WLAN-infrastructuur bij de eerste associatie.
Snelle BSS-overgang over de DS
802.11r maakt een andere implementatie van Fast BSS Transition mogelijk, waarbij de FT-roaming door de client wordt geïnitieerd met het nieuwe AP waarvoor de client over-the-DS (distributiesysteem) zwerft en niet over-the-air. In dit geval worden FT-actieframes gebruikt om de belangrijkste onderhandeling te starten in plaats van de Open System Authentication-frames.
Kortom, zodra de client besluit dat hij naar een beter toegangspunt kan zwerven, verzendt de client een FT Action Request-frame naar het oorspronkelijke toegangspunt waar het momenteel is verbonden voordat het zwerft. De client geeft de BSSID (MAC-adres) van het doel-AP aan waar het wil roamen. Het oorspronkelijke AP stuurt dit FT Action Request-frame door naar het doel-AP via het distributiesysteem (normaal gesproken de bekabelde infrastructuur) en het doel-AP reageert op de client met een FT Action Response-frame (ook over de DS, zodat het het eindelijk over-the-air naar de client kan sturen). Zodra deze uitwisseling van FT-actieframes succesvol is, voltooit de client de FT-roaming; de client verzendt het verzoek om herkoppeling naar het doel-AP (dit keer over-the-air) en ontvangt een Reassociation-antwoord van het nieuwe AP om de afleiding van de roaming- en eindsleutels te bevestigen.
Samengevat zijn er vier frames om te onderhandelen over Fast BSS Transition en om nieuwe coderingssleutels af te leiden, maar hier worden de Open System Authentication-frames vervangen door de FT Action Request/Response-frames, die met het doel-AP over het distributiesysteem worden uitgewisseld met het huidige AP. Deze methode is ook geldig voor beide beveiligingsmethoden 802.1X/EAP en PSK, die allemaal worden ondersteund door de draadloze LAN-controllers van Cisco. Aangezien deze Over-the-DS-overgang echter niet wordt ondersteund en geïmplementeerd door de meeste draadloze clients in de WiFi-industrie (en omdat de uitvoer voor het uitwisselen van frames en debuggen in principe hetzelfde is), worden in dit document geen voorbeelden gegeven. In plaats daarvan wordt deze afbeelding gebruikt om de Fast BSS Transition Over-the-DS te visualiseren:
FlexConnect met 802.11r
- Centrale verificatie wordt ondersteund. Dit geldt ook voor lokale en centrale gegevensoverdracht. De toegangspunten moeten deel uitmaken van dezelfde FlexConnect-groep.
- Lokale verificatie wordt niet ondersteund.
- De stand-alone modus wordt niet ondersteund.
Voordelen van 802.11r
- Deze methode is de eerste die een sleutelhiërarchie gebruikt die door de IEEE duidelijk is gedefinieerd op de 802.11-standaard als een amendement (802.11r), dus de implementatie van deze FT-technieken is meer compatibel tussen leveranciers en zonder verschillende interpretaties.
- Met 802.11r kunnen meerdere technieken worden gebruikt die nuttig zijn, afhankelijk van uw behoeften (Over-the-Air en Over-the-DS, voor 802.1x/EAP-beveiliging en voor PSK-beveiliging).
- De draadloze client voert snel en veilig zwerven naar een nieuw toegangspunt uit op dezelfde WLAN/SSID, zelfs als deze nooit aan dat toegangspunt is gekoppeld en zonder dat meerdere PMKID's hoeven te worden opgeslagen.
- Dit is de eerste snelle, veilige zwerfmethode die sneller zwerven mogelijk maakt, zelfs met PSK-beveiliging, en vermijdt de 4-weg handshake die vereist is bij het zwerven tussen toegangspunten met WPA/WPA2 PSK. Het belangrijkste doel van de snel beveiligde roamingmethoden is om de 802.1X/EAP-handshake te vermijden wanneer deze beveiligingsmethode wordt geïmplementeerd; voor PSK-beveiliging wordt het roamingevenement echter nog meer versneld met 802.11r wanneer de 4-weg handshake wordt vermeden.
Nadelen van 802.11r
- Er zijn een paar draadloze clientapparaten die Fast BSS Transitions ondersteunen en in de meeste gevallen ondersteunen ze niet alle technieken die beschikbaar zijn op 802.11r.
- Vanwege het feit dat deze implementaties erg jong zijn, zijn er niet genoeg testresultaten van echte productieomgevingen of voldoende debug-resultaten om mogelijke kanttekeningen die kunnen verschijnen aan te pakken.
- Wanneer u een WLAN/SSID configureert om een van de FT-methoden te gebruiken, kunnen alleen draadloze clients die 802.11r ondersteunen verbinding maken met deze WLAN/SSID. De FT-instellingen zijn niet optioneel voor de clients, dus de draadloze clients die geen ondersteuning bieden voor 802.11r moeten verbinding maken met een apart WLAN/SSID waarin FT helemaal niet is geconfigureerd.
Adaptive 802.11r
- Sommige oudere clients kunnen niet worden gekoppeld aan een WLAN/SSID waarvoor 802.11r is ingeschakeld, zelfs niet voor de "gemengde modus" (waarvan u hoopt dat u deze kunt gebruiken voor dezelfde SSID-clients die ondersteuning bieden en die geen ondersteuning bieden voor 802.11r). Dit is wanneer de driver van de aanvrager die verantwoordelijk is voor het ontleden van het robuuste beveiligingsnetwerkinformatie-element (RSNIE) oud is en niet op de hoogte is van de extra AKM-suites in de IE. Vanwege deze beperking kunnen clients geen koppelingsverzoeken verzenden naar WLAN's die reclame maken voor 802.11r-ondersteuning. Daarom moet u één WLAN/SSID configureren voor 802.11r-clients en een afzonderlijke WLAN/SSID voor clients die geen 802.11r ondersteunen.
-
Om dit te overwinnen, heeft Cisco Wireless LAN-infrastructuur de Adaptive 802.11r-functie geïntroduceerd. Als de FT-modus is ingesteld op Adaptive op WLAN-niveau, wordt in WLAN-advertenties de 802.11r Mobility Domain ID weergegeven op een WLAN met 802.11i. Sommige Apple iOS10-clientapparaten identificeren de aanwezigheid van MDIE op een 80211i/WPA2 WLAN en doen een eigen handshake om een 802.11r-koppeling tot stand te brengen. Zodra de client een succesvolle 802.11r-koppeling heeft voltooid, kan deze FT-roaming uitvoeren zoals in een normaal 802.11r-WLAN. De FT Adaptive is alleen van toepassing op geselecteerde Apple iOS10- (en nieuwere) apparaten. Alle andere clients kunnen de 802.11i/WPA2-koppeling op het WLAN blijven gebruiken en de toepasselijke FSR-methode uitvoeren zoals wordt ondersteund.
-
Meer documentatie over deze nieuwe functie die is geïntroduceerd voor iOS10-apparaten om 802.11r uit te voeren op een WLAN/SSID waarop 802.11r niet echt is ingeschakeld (zodat andere niet-802.11r-clients met succes verbinding kunnen maken), is te vinden in Best Practices voor Cisco IOS-apparaten voor Cisco op Cisco Wireless LAN.
conclusies
- Houd er rekening mee dat de klant altijd degene is die besluit om naar een specifieke AP te roamen, en de WLC / AP kan dit niet voor de klant beslissen. Het roamingevenement wordt gestart door de draadloze client zodra deze van mening is dat deze moet roamen.
- De WLC ondersteunt een combinatie van de meeste of alle FSR-methoden (Fast-Secure Roaming) samen op dezelfde WLAN/SSID. Houd er echter rekening mee dat dit normaal gesproken niet werkt, omdat het sterk afhankelijk is van het gedrag van de klant (zeer verschillend op verschillende mobiele apparaten) om te ondersteunen of zelfs te begrijpen dat wat de WLC probeert te adverteren als ondersteund. In plaats van interoperabiliteit in slechts één SSID te bereiken, zijn er normaal gesproken meer problemen dan die naar verwachting worden opgelost, dus dit wordt niet aanbevolen. Diepgaande tests met alle mogelijke clients die op dit WLAN kunnen worden gebruikt, moeten worden voltooid als dit echt nodig is.
- Het is erg belangrijk om te begrijpen dat snel beveiligde roamingmethoden zijn ontwikkeld om het WLAN-roamingproces te versnellen wanneer u tussen toegangspunten beweegt als de WLAN/SSID-beveiliging is ingeschakeld. Als er geen beveiliging is ingesteld, hoeft dit niet te worden versneld, omdat de client-AP eenvoudig de draadloze beheerframes uitwisselt die altijd nodig zijn bij roaming tussen AP's voordat gegevensframes worden verzonden (Open systeemverificatie van de client, Open systeemverificatie van het AP, Reassociation Request en Reassociation Response). Daarom kan dit niet sneller gaan. Als u problemen ondervindt met roaming zonder beveiliging, zijn er geen snelle zwerfmethoden om roaming te verbeteren, alleen methoden om te bevestigen of de WLAN/SSID-instellingen en het ontwerp geschikt zijn voor de draadloze clientstations om dienovereenkomstig te zwerven tussen de AP-dekkingscellen.
- 802.11r/FT wordt geïmplementeerd met WPA2-PSK om roamingevenementen met deze beveiliging te versnellen en de 4-weg handshake te voorkomen, zoals uitgelegd in de sectie 802.11r.
- Alle methoden hebben hun voor- en nadelen, maar uiteindelijk moet u altijd controleren of de draadloze clientstations de specifieke methode ondersteunen die u wilt implementeren en of de Cisco WLAN-infrastructuur alle beschikbare methoden ondersteunt. U moet dus de beste methode selecteren die daadwerkelijk wordt ondersteund door de draadloze clients die verbinding maken met de specifieke WLAN/SSID. In sommige implementaties kunt u bijvoorbeeld een WLAN/SSID met CCKM maken voor draadloze IP-telefoons van Cisco (die WPA2/AES met CCKM ondersteunen, maar geen 802.11r) en vervolgens een andere WLAN/SSID met WPA2/AES via 802.11r/FT voor draadloze clients die deze Fast Secure Roaming-methode ondersteunen (of OKC gebruiken, als dit wordt ondersteund).
- Als de draadloze clients geen van de beschikbare snelle en veilige roamingmethoden ondersteunen, kunt u ermee akkoord gaan dat deze clients altijd kunnen experimenteren met de vertragingen die in dit document worden uitgelegd bij het roamen tussen toegangspunten op een WLAN/SSID met 802.1X/EAP-beveiliging (wat storingen in de clientapps/services kan veroorzaken).
- Alle methoden, behalve SKC (WPA2 PMKID Caching), worden ondersteund voor snel beveiligde roaming tussen toegangspunten die worden beheerd door verschillende WLC's (intercontroller roaming), zolang ze zich op dezelfde mobiliteitsgroep bevinden.
- CUWN ondersteunt alle verschillende Fast-Secure Roaming-methoden die in dit artikel worden behandeld wanneer 802.1X/EAP-verificatie wordt gebruikt voor WPA/WPA2. CUWN ondersteunt Fast-Secure Roaming niet op methoden die werken met WPA2-RSN (CCKM, PMKID Caching/SKC, OKC/PKC) wanneer PSK (WPA2-Personal) wordt gebruikt, waar Fast-Roaming methoden meestal niet nodig zijn. CUWN ondersteunt echter Fast-Secure Roaming in het geval van WPA2-FT (802.11r) met PSK, zoals ook uitgelegd in dit artikel.
Gerelateerde informatie
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
2.0 |
09-Feb-2023
|
Bijgewerkt formaat en geverifieerde technische informatie. Hercertificering. |
1.0 |
02-Sep-2013
|
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)