Pour les partenaires
Vous êtes déjà partenaire?
ConnexionAvez-vous un compte?
Dans la documentation de ce produit, les auteurs s‘efforcent d‘utiliser un langage exempt de préjugés. Aux fins de cet ensemble de documents, l’expression « sans préjugés » est définie comme un langage sans discrimination fondée sur l’âge, le handicap, le sexe, l’identité raciale, l’identité ethnique, l’orientation sexuelle, la situation socio-économique et l’intersectionnalité. Des exceptions peuvent être présentes dans la documentation en raison de la langue codée en dur dans les interfaces utilisateur du logiciel du produit, de la langue utilisée en fonction de la documentation de l’appel d’offres ou de la langue utilisée par un produit tiers référencé. En savoir plus sur la façon dont Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit les différents types de méthodes d'itinérance sans fil et d'itinérance rapide disponibles pour les LAN sans fil (WLAN) IEEE 802.11 pris en charge sur le réseau sans fil unifié Cisco (CUWN).
Le document ne fournit pas tous les détails sur le fonctionnement de chaque méthode ni sur la façon dont elles sont configurées. Ce document a pour principal objectif de décrire les différences entre les différentes techniques disponibles, leurs avantages et leurs limites, et l'échange de trames sur chaque méthode. Des exemples de débogages WLC (WLAN Controller) sont fournis et des captures de paquets sans fil sont utilisées afin d'analyser et d'expliquer les événements qui se produisent pour chaque méthode d'itinérance décrite.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations de ce document sont basées sur le logiciel Cisco WLAN Controller Version 7.4, mais la plupart des sorties et des comportements de débogage décrits peuvent s'appliquer à toute version logicielle prenant en charge les méthodes décrites. Toutes les méthodes décrites ici restent identiques sur les codes ultérieurs du contrôleur WLAN de Cisco (jusqu'à la version 8.3 au moment de la mise à jour de cet article).
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Avant de décrire les différentes méthodes d'itinérance rapide et sécurisée disponibles pour les WLAN, il est important de comprendre comment fonctionne le processus d'association WLAN et comment un événement d'itinérance régulier se produit lorsqu'aucune sécurité n'est configurée sur le SSID (Service Set Identifier).
Lorsqu'un client sans fil 802.11 se connecte à un point d'accès (AP), avant de commencer à transmettre le trafic (trames de données sans fil), il doit d'abord passer le processus d'authentification de base 802.11 Open System. Ensuite, le processus d'association doit être terminé. Considérez le processus d'authentification Open System comme la connexion du câble sur l'AP sélectionné par le client. Il est très important de le comprendre, car c'est toujours le client sans fil qui sélectionne le point d'accès préféré et qui base la décision sur plusieurs facteurs qui varient d'un fournisseur à l'autre. C'est pourquoi le client commence ce processus en envoyant la trame d'authentification au point d'accès sélectionné, comme indiqué plus loin dans ce document. Le point d'accès ne peut pas vous demander d'établir une connexion.
Une fois le processus d'authentification Open System terminé avec succès avec une réponse du point d'accès (« câble connecté »), le processus d'association termine essentiellement la négociation de couche 2 (L2) 802.11 qui établit la liaison entre le client et le point d'accès. Le point d'accès attribue un ID d'association au client si la connexion réussit, et le prépare afin de transmettre le trafic ou d'exécuter une méthode de sécurité de niveau supérieur si elle est configurée sur le SSID. Le processus d'authentification Open System se compose de deux trames de gestion ainsi que du processus d'association. Les trames d'authentification et d'association sont des trames de gestion sans fil, et non des trames de données, qui sont essentiellement celles utilisées pour le processus de connexion avec l'AP.
Voici une capture des trames sans fil en direct pour ce processus :
Remarque : si vous souhaitez en savoir plus sur la détection 802.11 sans fil et sur les filtres/couleurs utilisés sur Wireshark pour les captures qui figurent dans ce document, consultez le billet de la communauté d'assistance Cisco intitulé Analyse de capture de renifleur 802.11.
Le client sans fil commence par la trame d'authentification, et le point d'accès répond par une autre trame d'authentification. Le client envoie ensuite la trame de demande d'association, et le point d'accès termine en réponse avec la trame de réponse d'association. Comme le montrent les paquets DHCP, une fois que les processus d'authentification et d'association du système ouvert 802.11 sont passés, le client commence à transmettre des trames de données. Dans ce cas, aucune méthode de sécurité n'est configurée sur le SSID, de sorte que le client commence immédiatement à envoyer des trames de données (dans ce cas DHCP) qui ne sont pas chiffrées.
Comme indiqué plus loin dans ce document, si la sécurité est activée sur le SSID, il existe des trames d'authentification et de chiffrement de niveau supérieur pour la méthode de sécurité spécifique, juste après la réponse d'association et avant d'envoyer des trames de données de trafic client, telles que DHCP, ARP (Address Resolution Protocol) et des paquets d'applications, qui sont chiffrées. Les trames de données ne peuvent être envoyées que lorsque le client est entièrement authentifié et que les clés de chiffrement sont négociées, en fonction de la méthode de sécurité configurée.
D'après la capture précédente, voici les messages que vous voyez dans les sorties de la commande debug client WLC lorsque le client sans fil commence une nouvelle association au WLAN :
*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.
Remarque : le débogage du WLC utilisé pour les sorties indiquées dans ce document est la commande debug client, et les exemples montrent seulement quelques messages pertinents, pas la sortie entière. Pour plus de détails sur cette commande debug, référez-vous au document Présentation du client de débogage sur les contrôleurs de réseau local sans fil (WLC).
Ces messages affichent les trames de demande et de réponse d'association ; les trames d'authentification initiales ne sont pas enregistrées sur le WLC, car cette connexion se produit rapidement au niveau de l'AP sur le CUWN.
Quelles informations s'affichent lorsque le client se déplace ? Le client échange toujours quatre trames de gestion lors de l'établissement d'une connexion à un point d'accès, ce qui est dû soit à l'établissement d'association du client, soit à un événement d'itinérance. Une seule connexion est établie pour le client à un seul point d’accès à la fois. La seule différence dans l'échange de trames entre une nouvelle connexion à l'infrastructure WLAN et un événement d'itinérance est que les trames d'association d'un événement d'itinérance sont appelées trames de réassociation, ce qui indique que le client est en fait en itinérance depuis un autre AP sans aucune tentative d'établir une nouvelle association au WLAN. Ces trames peuvent contenir différents éléments utilisés pour négocier l'événement d'itinérance ; cela dépend de la configuration, mais ces détails ne sont pas compris dans ce document.
Voici un exemple d'échange de trames :
Ces messages apparaissent dans la sortie de débogage :
*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.
Comme indiqué, le client effectue un événement d'itinérance après l'envoi de la demande de réassociation au nouveau point d'accès et reçoit la réponse de réassociation du point d'accès. Puisque le client a déjà une adresse IP, les premières trames de données sont destinées aux paquets ARP.
Si vous attendez un événement itinérant, mais que le client envoie une demande d'association au lieu d'une demande de réassociation (que vous pouvez confirmer à partir de certaines captures et débogages similaires à ceux expliqués précédemment dans ce document), alors le client n'est pas vraiment en itinérance. Le client commence une nouvelle association au WLAN comme si une déconnexion s'était produite et tente de se reconnecter à partir de zéro. Cela peut se produire pour plusieurs raisons, par exemple lorsqu'un client quitte les zones de couverture et trouve ensuite un point d'accès avec une qualité de signal suffisante pour démarrer une association, mais cela indique normalement un problème client où le client ne déclenche pas d'événement d'itinérance en raison de problèmes de pilotes, de micrologiciels ou de logiciels.
Note: Vous pouvez vérifier auprès du fournisseur du client sans fil afin de déterminer la cause du problème.
Lorsque le SSID est configuré avec une sécurité de niveau supérieur de L2 en plus de l'authentification de base 802.11 Open System, il faut alors plus de trames pour l'association initiale et pour l'itinérance. Les deux méthodes de sécurité les plus courantes, normalisées et mises en oeuvre pour les WLAN 802.11, sont décrites dans ce document :
Il est important de savoir que, même si ces deux méthodes (PSK et EAP) authentifient/valident les clients de différentes manières, les deux utilisent essentiellement les mêmes règles WPA/WPA2 pour le processus de gestion des clés. Que la sécurité soit WPA/WPA2-PSK ou WPA/WPA2-EAP, le processus appelé connexion WPA/WPA2 en 4 étapes commence la négociation de clé entre le WLC/AP et le client avec une clé de session principale (MSK) comme matériau de clé d'origine une fois que le client est validé avec la méthode d'authentification spécifique utilisée.
Voici un résumé du processus :
Lorsque WPA-PSK ou WPA2-PSK est exécuté via TKIP (Temporal Key Integrity Protocol) ou AES (Advanced Encryption Standard) pour le chiffrement, le client doit passer par le processus appelé connexion WPA en 4 étapes pour l'association initiale et également lors de l'itinérance. Comme expliqué précédemment, il s'agit essentiellement du processus de gestion des clés utilisé pour que WPA/WPA2 dérive les clés de chiffrement. Cependant, lorsque PSK est exécuté, il est également utilisé afin de vérifier que le client dispose d'une clé pré-partagée valide pour rejoindre le WLAN. Cette capture montre le processus d'association initial lorsque WPA ou WPA2 avec PSK est exécuté :
Comme indiqué, après le processus d'authentification et d'association du système ouvert 802.11, il y a quatre trames EAPOL de la connexion WPA en 4 étapes, qui sont initiées par l'AP avec message-1, et terminées par le client avec message-4. Après une connexion réussie, le client commence à transmettre des trames de données (telles que DHCP), qui dans ce cas sont chiffrées avec les clés dérivées de la connexion en 4 étapes (c'est pourquoi vous ne pouvez pas voir le contenu réel et le type de trafic des captures sans fil).
Note: Les trames EAPOL sont utilisées afin de transporter toutes les trames de gestion clés et les trames d'authentification 802.1X/EAP en direct entre le point d'accès et le client ; elles sont transmises sous forme de trames de données sans fil.
Ces messages apparaissent dans les sorties de débogage :
*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.
En itinérance, le client suit essentiellement le même échange de trames, où la connexion WPA en 4 étapes est requise pour dériver de nouvelles clés de chiffrement avec le nouveau point d'accès. Ceci est dû à des raisons de sécurité établies par la norme, et le fait que le nouveau point d'accès ne connaît pas les clés d'origine. La seule différence est qu'il existe des trames de réassociation au lieu des trames d'association, comme illustré dans cette capture :
Vous voyez les mêmes messages dans les sorties de débogage, mais le premier paquet du client est une réassociation au lieu d'une association, comme indiqué et expliqué précédemment.
Lorsqu'une méthode 802.1X/EAP est utilisée pour authentifier les clients sur un SSID sécurisé, il y a encore plus de trames nécessaires avant que le client ne commence à transmettre le trafic. Ces trames supplémentaires sont utilisées afin d'authentifier les informations d'identification du client, et selon la méthode EAP, il peut y avoir entre quatre et vingt trames. Celles-ci viennent après l'association/réassociation, mais avant la connexion WPA/WPA2 en 4 étapes, parce que la phase d'authentification dérive le MSK utilisé comme amorce pour la génération finale de clé de chiffrement dans le processus de gestion des clés (connexion en 4 étapes).
Cette capture sans fil présente un exemple des trames échangées sur l'air entre le point d'accès et le client sans fil lors de l'association initiale lorsque WPA avec PEAPv0/EAP-MSCHAPv2 est effectué :
Parfois, cet échange montre plus ou moins de trames, qui dépendent de plusieurs facteurs, tels que la méthode EAP, les retransmissions en raison de problèmes, le comportement du client (comme les deux demandes d'identité dans cet exemple, parce que le client envoie un START EAPOL après que le point d'accès envoie la première demande d'identité), ou si le client a déjà échangé le certificat avec le serveur. Chaque fois que le SSID est configuré pour une méthode 802.1X/EAP, il y a plus de trames (pour l'authentification) et par conséquent, il faut plus de temps avant que le client commence à envoyer des trames de données.
Voici un résumé des messages de débogage :
*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.
Lorsque le client sans fil effectue une itinérance régulière ici (comportement normal, sans mise en oeuvre d'une méthode d'itinérance rapide et sécurisée), le client doit passer par le même processus et effectuer une authentification complète sur le serveur d'authentification, comme indiqué dans les captures. La seule différence est que le client utilise une requête de réassociation afin d'informer le nouveau point d'accès qu'il est en fait en itinérance à partir d'un autre point d'accès, mais le client doit encore passer par la validation complète et la nouvelle génération de clés :
Comme indiqué, même lorsqu'il y a moins de trames que dans l'authentification initiale (qui est causée par plusieurs facteurs, comme mentionné précédemment), lorsque le client se déplace vers un nouveau point d'accès, l'authentification EAP et les processus de gestion des clés WPA doivent toujours être effectués afin de continuer à transmettre des trames de données (même si le trafic a été activement envoyé avant l'itinérance). Par conséquent, si le client dispose d'une application active sensible aux retards (tels que les applications de trafic vocal ou les applications sensibles aux délais d'attente), l'utilisateur peut percevoir des problèmes d'itinérance, tels que les interruptions audio ou les déconnexions d'applications. Cela dépend du temps nécessaire au processus pour que le client continue à envoyer/recevoir des trames de données. Ce délai peut être plus long, en fonction des éléments suivants : l'environnement RF, la quantité de clients, le temps aller-retour entre le WLC et les LAP et avec le serveur d'authentification, et d'autres raisons.
Voici un résumé des messages de débogage pour cet événement d'itinérance (essentiellement les mêmes que les précédents, de sorte que ces messages ne sont pas décrits plus en détail) :
*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 into Connecting state
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 4)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 4, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.956: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.957: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 7, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c
(EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
C'est ainsi que fonctionnent le 802.1X/EAP et le cadre de sécurité WPA/WPA2. Afin d'éviter l'impact des applications/services sur les retards d'un événement d'itinérance régulier, plusieurs méthodes d'itinérance rapide et sécurisée sont développées et mises en oeuvre par l'industrie WiFi afin d'accélérer le processus d'itinérance lorsque la sécurité est utilisée sur le WLAN/SSID. Les clients sont confrontés à une certaine latence lorsqu'ils continuent à acheminer le trafic tout en circulant entre les points d'accès via le déploiement d'une sécurité de haut niveau sur le WLAN. Ceci est dû à l'authentification EAP et aux échanges de trames de gestion des clés requis par la configuration de sécurité, comme expliqué précédemment.
Il est important de comprendre que l'itinérance rapide et sécurisée n'est que le terme utilisé par le secteur en référence à la mise en oeuvre d'une méthode/d'un schéma qui accélère le processus d'itinérance lorsque la sécurité est configurée sur le WLAN. Les différentes méthodes/schémas d'itinérance à sécurité rapide disponibles pour les réseaux locaux sans fil et pris en charge par le CUWN sont expliqués dans la section suivante.
Cisco Centralized Key Management (CCKM) est la première méthode d'itinérance rapide et sécurisée développée et mise en oeuvre sur les WLAN d'entreprise, créée par Cisco comme solution utilisée pour réduire les retards expliqués jusqu'à présent, lorsque la sécurité 802.1X/EAP est utilisée sur le WLAN. Comme il s'agit d'un protocole propriétaire de Cisco, il est uniquement pris en charge par les périphériques d'infrastructure WLAN Cisco et les clients sans fil (provenant de plusieurs fournisseurs) compatibles Cisco Compatible Extension (CCX) pour CCKM.
CCKM peut être mis en oeuvre avec toutes les différentes méthodes de cryptage disponibles pour les WLAN, notamment : WEP, TKIP et AES. Il est également pris en charge avec la plupart des méthodes d'authentification 802.1X/EAP utilisées pour les WLAN, selon la version CCX prise en charge par les périphériques.
Note: Pour obtenir une vue d'ensemble du contenu des fonctionnalités pris en charge par les différentes versions de la spécification CCX (y compris les méthodes EAP prises en charge), reportez-vous au document CCX Versions and Features et vérifiez la version CCX exacte prise en charge par vos clients sans fil (s'ils sont compatibles CCX), afin de vérifier si la méthode de sécurité que vous souhaitez utiliser avec CCKM peut être implémentée.
Cette capture sans fil fournit un exemple des trames échangées lors de l'association initiale lorsque vous exécutez CCKM avec TKIP comme chiffrement, et PEAPv0/EAP-MSCHAPv2 comme méthode 802.1X/EAP. Il s'agit essentiellement du même échange que si WPA/TKIP avec PEAPv0/EAP-MSCHAPv2 est effectué, mais cette fois, CCKM entre le client et l'infrastructure est négocié de sorte qu'ils utilisent différentes hiérarchies de clés et méthodes de cache afin d'effectuer l'itinérance sécurisée rapide lorsque le client doit effectuer une itinérance :
Voici un résumé des messages de débogage (avec quelques échanges EAP supprimés afin de réduire la sortie) :
*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.
Avec CCKM, l'association initiale au WLAN est similaire au WPA/WPA2 normal, où un MSK (également appelé NSK (Network Session Key)) est mutuellement dérivé avec le client et le serveur RADIUS. Cette clé principale est envoyée du serveur au WLC après une authentification réussie, et est mise en cache comme base de dérivation de toutes les clés suivantes pour la durée de vie de l'association du client avec ce WLAN. À partir de là, le WLC et le client dérivent les informations de départ qui sont utilisées pour l'itinérance rapide et sécurisée basée sur CCKM, passant par une connexion en 4 étapes similaire à celle de WPA/WPA2, afin de dériver les clés de cryptage de monodiffusion (PTK) et de multidiffusion (GTK) avec le premier AP.
La grande différence est remarquée lors de l'itinérance. Dans ce cas, le client CCKM envoie une trame de demande de réassociation unique à l'AP/WLC (y compris une MIC et un nombre aléatoire croissant de manière séquentielle), et fournit suffisamment d'informations (y compris la nouvelle adresse MAC de l'AP -BSSID-) afin de dériver le nouveau PTK. Avec cette requête de réassociation, le WLC et le nouveau point d'accès ont également assez d'informations pour dériver le nouveau PTK, donc ils répondent simplement avec une réponse de réassociation. Le client peut maintenant continuer à transmettre le trafic, comme illustré dans cette capture :
Voici un résumé des débogages WLC pour cet événement d'itinérance :
*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.
Comme indiqué, l'itinérance rapide et sécurisée est effectuée tout en évitant les trames d'authentification EAP et encore plus les échanges en 4 étapes, car les nouvelles clés de chiffrement sont toujours dérivées, mais basées sur le schéma de négociation CCKM. Ceci est complété avec les trames de réassociation d'itinérance et les informations précédemment mises en cache par le client et le WLC.
La mise en cache PMKID (Master Key ID) par paire, ou Sticky Key Caching (SKC), est la première méthode d'itinérance rapide et sécurisée suggérée par la norme IEEE 802.11 dans la modification de sécurité 802.11i, où l'objectif principal est de standardiser un niveau élevé de sécurité pour les WLAN. Cette technique d'itinérance rapide a été ajoutée en tant que méthode facultative pour les périphériques WPA2 afin d'améliorer l'itinérance lorsque cette sécurité a été implémentée.
Cela est possible car, chaque fois qu'un client est entièrement authentifié par EAP, le client et le serveur d'authentification dérivent un MSK, qui est utilisé pour dériver le PMK. Ceci est utilisé comme amorçage pour la connexion WPA2 en 4 étapes afin de dériver la clé de chiffrement monodiffusion finale (PTK) utilisée pour la session (jusqu'à ce que le client se déplace vers un autre point d'accès ou que la session expire); par conséquent, cette méthode empêche la phase d'authentification EAP lors de l'itinérance car elle réutilise le PMK d'origine mis en cache par le client et le point d'accès. Le client doit uniquement passer par la connexion WPA2 en 4 étapes pour dériver de nouvelles clés de chiffrement.
Cette méthode n'est pas largement déployée, car la méthode d'itinérance 802.11 standard à sécurité rapide recommandée est principalement due aux raisons suivantes :
Avec cette méthode, l'association initiale à n'importe quel point d'accès est comme une première authentification régulière au WLAN, où l'authentification 802.1X/EAP entière par rapport au serveur d'authentification et la connexion en 4 étapes pour la génération de clé doivent avoir lieu avant que le client ne puisse envoyer des trames de données, comme illustré dans cette capture d'écran :
Les débogages révèlent le même échange de trames d'authentification EAP que les autres méthodes lors de l'authentification initiale au WLAN, avec quelques sorties ajoutées en ce qui concerne les techniques de mise en cache des clés utilisées ici. Ces sorties de débogage sont coupées afin d'afficher principalement les nouvelles informations, pas l'échange de trame EAP entier, parce que fondamentalement les mêmes informations sont échangées à chaque fois pour l'authentification du client contre le serveur d'authentification. Ceci est démontré jusqu'à présent et corrélé avec les trames d'authentification EAP affichées dans les captures de paquets, de sorte que la plupart des messages EAP sont supprimés des sorties de débogage pour plus de simplicité :
*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.
Avec cette méthode, le point d'accès et le client sans fil mettent en cache les PMK des associations sécurisées déjà établies. Par conséquent, si le client sans fil se déplace vers un nouveau point d'accès où il n'a jamais été associé, le client doit effectuer une nouvelle authentification EAP complète, comme indiqué dans cette capture sans fil où le client se déplace vers un nouveau point d'accès :
Cependant, si le client sans fil revient vers un point d'accès où une association/authentification précédente a eu lieu, alors le client envoie une trame de demande de réassociation qui liste plusieurs PMKID, qui informe le point d'accès des PMK mis en cache à partir de tous les points d'accès où le client a précédemment authentifié. Par conséquent, puisque le client revient en itinérance à un point d'accès qui a également un PMK mis en cache pour ce client, alors le client n'a pas besoin de se réauthentifier via EAP pour dériver un nouveau PMK. Le client passe simplement par la connexion WPA2 en 4 étapes afin de dériver les nouvelles clés de chiffrement transitoires :
Note: Cette capture ne montre pas la première trame d'authentification 802.11 Open System du client, mais cela n'est pas dû à la méthode mise en oeuvre, car cette trame est toujours requise. La raison est que cette trame spécifique n'est pas capturée par la carte ou le logiciel de capture de paquets sans fil utilisé pour détecter les trames en direct pour cet exemple, mais elle est laissée comme ceci dans l'exemple à des fins éducatives. Sachez que cela peut se produire lorsque vous effectuez des captures de paquets en direct ; certaines trames peuvent être manquées par la capture, mais sont en fait échangées entre le client et le point d'accès. Sinon, l'itinérance ne commence jamais sur cet exemple.
Voici un résumé des débogages WLC pour cette méthode d'itinérance rapide et sécurisée :
*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
Cette méthode peut être implémentée localement par des AP autonomes, sans qu'un périphérique centralisé soit nécessaire pour gérer les clés mises en cache.
La mise en cache de clé opportuniste (OKC), également appelée mise en cache de clé proactive (PKC) (ce terme est expliqué en détail dans une note qui suit), est essentiellement une amélioration de la méthode de mise en cache PMKID WPA2 décrite précédemment, ce qui explique pourquoi elle est également appelée mise en cache PMKID proactive/opportuniste. Par conséquent, il est important de noter qu'il ne s'agit pas d'une méthode d'itinérance rapide et sécurisée définie par la norme 802.11 et n'est pas prise en charge par de nombreux périphériques, mais tout comme la mise en cache de PMKID, elle fonctionne avec WPA2-EAP.
Cette technique permet au client sans fil et à l'infrastructure WLAN de ne mettre en cache qu'un seul PMK pendant la durée de vie de l'association client avec ce WLAN (dérivé du MSK après l'authentification 802.1X/EAP initiale avec le serveur d'authentification), même en itinérance entre plusieurs AP, car ils partagent tous le PMK d'origine qui est utilisé comme amorce sur toutes les connexions WPA2 en 4 étapes. Ceci est toujours nécessaire, tout comme dans SKC, afin de générer de nouvelles clés de chiffrement chaque fois que le client s'associe aux points d'accès. Pour que les AP partagent cette PMK d'origine à partir de la session client, ils doivent tous être sous un contrôle administratif quelconque, avec un périphérique centralisé qui met en cache et distribue la PMK d'origine pour tous les AP. Ceci est similaire au CUWN, où le WLC effectue ce travail pour tous les LAP sous son contrôle, et utilise les groupes de mobilité afin de gérer ce PMK entre plusieurs WLC ; par conséquent, il s'agit d'une limitation sur les environnements AP autonomes.
Avec cette méthode, tout comme dans la mise en cache PMKID (SKC), l'association initiale à n'importe quel point d'accès est une authentification initiale régulière au WLAN, où vous devez terminer l'authentification 802.1X/EAP complète par rapport au serveur d'authentification et la connexion en 4 étapes pour la génération de clés avant de pouvoir envoyer des trames de données. Voici une capture d'écran qui illustre ceci :
Les sorties de débogage montrent essentiellement le même échange de trames d'authentification EAP que les autres méthodes décrites dans ce document lors de l'authentification initiale au WLAN (comme indiqué dans les captures), ainsi que l'ajout de certaines sorties qui concernent les techniques de mise en cache des clés utilisées par le WLC ici. Cette sortie de débogage est également coupée afin d'afficher uniquement les informations pertinentes :
*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
Avec cette méthode, le client sans fil et le WLC (pour tous les AP gérés) mettent en cache le PMK d'origine de l'association sécurisée initialement établie. En principe, chaque fois que le client sans fil se connecte à un point d'accès spécifique, un PMKID est haché en fonction des éléments suivants : l'adresse MAC du client, l'adresse MAC de l'AP (BSSID du WLAN) et le PMK dérivé avec ce point d'accès. Par conséquent, étant donné qu'OKC met en cache le même PMK d'origine pour tous les AP et le client spécifique, lorsque ce client (re)s'associe à un autre AP, la seule valeur qui change afin de hacher le nouveau PMKID est la nouvelle adresse MAC AP.
Lorsque le client initie l'itinérance à un nouveau point d'accès et envoie la trame de demande de réassociation, il ajoute le PMKID sur l'élément d'information RSN WPA2 s'il veut informer le point d'accès qu'un PMK mis en cache est utilisé pour l'itinérance rapide et sécurisée ; comme il connaît déjà l'adresse MAC du BSSID (AP) pour l'endroit où il se déplace, alors le client hache simplement le nouveau PMKID qui est utilisé sur cette demande de réassociation. Lorsque le point d'accès reçoit cette requête du client, il hache également le PMKID avec les valeurs qu'il a déjà (le PMK mis en cache, l'adresse MAC du client et sa propre adresse MAC AP), et répond avec la réponse de réassociation qui confirme les PMKID correspondants. Le PMK mis en cache peut être utilisé comme amorce qui démarre une connexion WPA2 en 4 étapes afin de dériver les nouvelles clés de cryptage (ignorant EAP) :
Dans cette capture, la trame Demande de réassociation du client est sélectionnée et développée pour que vous puissiez voir plus de détails sur la trame. Les informations d'adresse MAC et également l'élément d'information Robust Security Network (RSN, conformément à la norme 802.11i - WPA2), dans lequel sont affichées des informations sur les paramètres WPA2 utilisés pour cette association (mis en surbrillance, le PMKID obtenu à partir de la formule hachée).
Voici un résumé des débogages WLC pour cette méthode d'itinérance sécurisée rapide avec 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
Comme indiqué au début des débogages, le PMKID doit être calculé après réception de la demande de réassociation du client. Ceci est nécessaire pour valider l'PMKID et confirmer que le PMK mis en cache est utilisé avec la connexion WPA2 en 4 étapes pour dériver les clés de cryptage et terminer l'itinérance rapide et sécurisée. Ne confondez pas les entrées CCKM sur les débogages ; ceci n'est pas utilisé pour exécuter CCKM, mais OKC, comme expliqué précédemment. CCKM est simplement un nom utilisé par le WLC pour ces sorties, tel que le nom d'une fonction qui gère les valeurs afin de calculer le PMKID.
Note: Cette configuration peut fonctionner si les points d'accès ne sont pas sur le même groupe FlexConnect, mais il ne s'agit pas d'une configuration recommandée ou prise en charge.
La mise en cache proactive des clés (ou PKC) a été appelée mise en cache opportuniste des clés (OKC) et les deux termes ont été utilisés de manière interchangeable pour décrire la même méthode expliquée ici. Cependant, il ne s’agissait que d’un terme utilisé par Airspace en 2001 pour une ancienne méthode de mise en cache des clés, qui a ensuite été utilisée par la norme 802.11i comme base de “ Preauthentication ” (une autre méthode d’itinérance sécurisée rapide expliquée brièvement ci-dessous). PKC n'est pas Preauthentication ou OKC (Opportunistic Key Caching), mais lorsque vous entendez ou lisez des informations sur PKC, la référence est essentiellement à OKC, et non à Preauthentication.
Cette méthode est également suggérée par la norme IEEE 802.11 dans la modification de sécurité 802.11i. Elle fonctionne donc également avec WPA2, mais c'est la seule méthode d'itinérance rapide sécurisée qui n'est pas prise en charge par l'infrastructure WLAN de Cisco. Pour cette raison, il n'est expliqué que brièvement ici et sans résultats.
Avec la préauthentification, les clients sans fil peuvent s'authentifier avec plusieurs points d'accès à la fois tout en étant associés au point d'accès actuel. Lorsque cela se produit, le client envoie les trames d'authentification EAP au point d'accès actuel où il est connecté, mais il est destiné aux autres points d'accès où le client veut effectuer la préauthentification (points d'accès voisins qui sont des candidats possibles pour l'itinérance). Le point d'accès actuel envoie ces trames aux points d'accès cibles via le système de distribution. Le nouveau point d'accès effectue une authentification complète sur le serveur RADIUS pour ce client, de sorte qu'une nouvelle connexion d'authentification EAP complète est terminée et que ce nouveau point d'accès agit en tant qu'authentificateur.
L'idée est d'effectuer l'authentification et de dériver PMK avec les AP voisins avant que le client ne les fasse circuler, donc quand il est temps de se déplacer, le client est déjà authentifié et avec un PMK déjà mis en cache pour cette nouvelle association sécurisée AP-client, ils n'ont besoin d'effectuer la connexion en 4 étapes et d'expérimenter une itinérance rapide après que le client a envoyé sa demande de réassociation initiale.
Voici une capture de la balise d'un point d'accès qui montre le champ IE RSN qui annonce la prise en charge de la préauthentification (celle-ci provient d'un point d'accès Cisco, où il est confirmé que la préauthentification n'est pas prise en charge) :
Il y a un PMK pour chaque association sécurisée AP-client, qui pourrait être considéré comme un avantage de sécurité en cas de compromission d'un AP et de vol des clés (ne peut pas être utilisé avec d'autres AP). Cependant, cet avantage en matière de sécurité est géré par l’infrastructure WLAN de différentes manières selon d’autres méthodes.
La technique d'itinérance rapide basée sur l'amendement 802.11r (officiellement nommé Fast BSS Transition par la norme 802.11, et appelé FT) est la première méthode officiellement ratifiée (en 2008) par l'IEEE pour la norme 802.11 comme solution pour effectuer des transitions rapides entre les points d'accès (AP) Basic Service Sets ou BSS), qui définit clairement la hiérarchie des clés utilisée lors de la gestion et de la mise en cache des clés sur un WLAN. Cependant, son adoption a été lente, principalement en raison d'autres solutions déjà disponibles lorsque des transitions rapides étaient réellement nécessaires, comme avec les mises en oeuvre VoWLAN lorsqu'elles étaient utilisées avec l'une des méthodes expliquées précédemment dans ce document. Seuls quelques périphériques prennent actuellement en charge certaines des options FT (d'ici 2013).
Cette technique est plus complexe à expliquer que les autres méthodes, car elle introduit de nouveaux concepts et plusieurs couches de PMK qui sont mises en cache sur différents périphériques (chaque périphérique ayant un rôle différent) et offre encore plus d'options pour l'itinérance rapide et sécurisée. Par conséquent, un bref résumé est fourni sur cette méthode et la façon dont elle est mise en oeuvre avec chaque option disponible.
La norme 802.11r est différente de SKC et OKC, principalement pour les raisons suivantes :
Avec cette méthode, le client sans fil effectue une seule authentification initiale sur l'infrastructure WLAN lorsqu'une connexion est établie au premier point d'accès, et effectue une itinérance rapide et sécurisée entre les points d'accès du même domaine de mobilité FT.
Il s'agit de l'un des nouveaux concepts, qui fait référence aux points d'accès qui utilisent le même SSID (connu sous le nom de Extended Service Set ou ESS) et gèrent les mêmes clés FT. Cette méthode est similaire aux autres méthodes expliquées jusqu'à présent. La manière dont les points d'accès gèrent les clés de domaine de mobilité FT est normalement basée sur une configuration centralisée, telle que le WLC ou les groupes de mobilité ; cependant, cette méthode peut également être implémentée sur des environnements AP autonomes.
Voici un résumé de la hiérarchie des clés :
Note: En fonction du fournisseur de réseau local sans fil et des configurations de mise en oeuvre (par exemple, les points d'accès autonomes, FlexConnect ou Mesh), l'infrastructure de réseau local sans fil peut transférer et gérer les clés d'une manière différente. Il peut même modifier les rôles des détenteurs de clés, mais comme cela ne relève pas de ce document, les exemples basés sur le résumé de la hiérarchie des clés fourni précédemment sont les suivants. En fait, les différences ne sont pas si pertinentes pour comprendre le processus, à moins que vous n'ayez réellement besoin d'analyser en profondeur les périphériques d'infrastructure (et leur code) afin de découvrir un problème logiciel.
Avec cette méthode, la première association à n'importe quel point d'accès est une première authentification régulière au WLAN, où l'authentification 802.1X/EAP entière par rapport au serveur d'authentification et la connexion en 4 étapes pour la génération de clé doivent se produire avant l'envoi des trames de données, comme illustré dans cette capture d'écran :
Les principales différences sont les suivantes :
Les débogages montrent essentiellement le même échange de trames d'authentification EAP que les autres méthodes lors de l'authentification initiale vers le WLAN (comme noté dans les captures), mais certaines sorties qui concernent les techniques de mise en cache des clés utilisées par le WLC sont ajoutées ; ainsi, cette sortie de débogage est coupée afin d'afficher uniquement les informations pertinentes :
*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, and follows the same exchange explained so far.
*apfMsConnTask_0: Jun 27 19:25:23.436: ec:85:2f:15:39:32
Got action frame from this client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32
Received Identity Response (count=1) from mobile
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32
Processing Access-Challenge for mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32
Sending EAP Request from AAA to mobile ec:85:2f:15:39:32
(EAP Id 2)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32
Received EAP Response from mobile ec:85:2f:15:39:32
(EAP Id 2, EAP Type 25)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Processing Access-Accept for mobile ec:85:2f:15:39:32
!--- The client is validated/authenticated by the RADIUS Server.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Creating a PKC PMKID Cache entry for station
ec:85:2f:15:39:32 (RSN 2)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Resetting MSCB PMK Cache Entry 0 for station
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32
Adding BSSID 84:78:ac:f0:68:d6 to PMKID cache at index 0
for station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: New PMKID: (16)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628:
[0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629: ec:85:2f:15:39:32
Created PMK Cache Entry for TGr AKM:802.1x ec:85:2f:15:39:32
!--- WLC creates a PMK cache entry for this client, which is
used for FT with 802.1X in this case, so the PMKID is
computed with the AP MAC address (BSSID 84:78:ac:f0:68:d6).
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629:
ec:85:2f:15:39:32 R0KH-ID:172.30.6.253
R1KH-ID:3c:ce:73:d8:02:00 MSK Len:48 pmkValidTime:1807
!--- The R0KH-ID and R1KH-ID are defined, as well as the PMK
cache validity period.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
PMK sent to mobility group
!--- The FT PMK cache entry for this client is shared with the
WLCs on the mobility group.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Sending EAP-Success to mobile ec:85:2f:15:39:32 (EAP Id 12)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d6 in PMKID
cache at index 0 of station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: Including PMKID in
M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
initial FT 4-Way handshake.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630:
[0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.0
!--- Message-1 of the FT 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from
mobile ec:85:2f:15:39:32
!--- Message-2 of the FT 4-Way handshake is received
successfully from the client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Calculating PMKR0Name
!--- The PMKR0Name is calculated.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
DOT11R: Sending cache add
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: Adding MDIE,
ID is:0xaaf0
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Adding TIE for reassociation deadtime:20000 milliseconds
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Adding TIE for R0Key-Data valid time :1807
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.640: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- After the MDIE, TIE for reassociation deadtime, and TIE
for R0Key-Data valid time are calculated, the Message-3
of this FT 4-Way handshake is sent from the WLC/AP to the
client with this information.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
!--- Message-4 (final message) of this initial FT 4-Way handshake
is received successfully from the client, which confirms the
installation of the derived keys. They can now be used in order
to encrypt data frames with the current AP.
Note: Afin de déboguer cette méthode et d'atteindre les sorties 802.11r/FT supplémentaires indiquées ici, un débogage supplémentaire est activé avec le client debug, qui est l'activation des événements debug ft.
Voici les captures et les débogages d'une association initiale au WLAN lorsque vous exécutez FT avec WPA2-PSK (au lieu d'une méthode 802.1X/EAP), où la trame de réponse d'association du point d'accès est sélectionnée afin d'afficher l'élément d'information de transition BSS rapide (mis en surbrillance). Certaines des informations clés nécessaires pour effectuer la connexion FT en 4 étapes sont également affichées :
*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
Avec la norme 802.11r, l’association initiale au WLAN est la base utilisée pour dériver les clés de base utilisées par cette technique, tout comme dans les autres méthodes d’itinérance rapide et sécurisée. Les principales différences surviennent lorsque le client commence à se déplacer ; FT n'évite pas seulement 802.1X/EAP lorsque ceci est utilisé, mais il exécute en fait une méthode d'itinérance plus efficace qui combine les trames d'authentification et de réassociation système ouvert 802.11 initiales (qui sont toujours utilisées et requises lors de l'itinérance entre les AP) afin d'échanger des informations FT et de dériver de nouvelles clés de cryptage dynamique au lieu de la connexion en 4 étapes.
La capture suivante montre les trames échangées lorsqu'une transition BSS rapide en vol avec sécurité 802.1X/EAP est effectuée. La trame Open System Authentication du client au point d'accès est sélectionnée afin de voir les éléments d'information du protocole FT nécessaires pour commencer la négociation de clé FT. Ceci est utilisé afin de dériver le nouveau PTK avec le nouveau AP (basé sur le PMK-R1). Le champ qui montre l'algorithme d'authentification est mis en surbrillance afin de montrer que ce client n'effectue pas une authentification système ouverte simple, mais une transition BSS rapide :
Voici les sorties de débogage du WLC lorsque cet événement d'itinérance FT se produit avec 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
Voici une capture qui montre une transition BSS rapide en direct avec la sécurité WPA2-PSK, où la trame de réponse de réassociation finale du point d'accès au client est sélectionnée afin d'afficher plus de détails sur cet échange FT :
Voici les sorties de débogage lorsque cet événement d'itinérance FT se produit avec PSK, qui sont similaires à celles lorsque 802.1X/EAP est utilisé :
*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
Comme l'illustre la capture, une fois que la transition BSS rapide est négociée lors de l'association initiale au WLAN, les quatre trames utilisées et requises pour l'itinérance (Authentification système ouverte du client, Authentification système ouverte du point d'accès, Demande de réassociation et Réponse de réassociation) sont essentiellement utilisées comme une connexion FT en 4 étapes afin de dériver le nouveau PTK (clé de chiffrement monodiffusion) et GTK (clé de chiffrement multidiffusion).
Cela remplace la connexion en 4 étapes qui se produit normalement après l'échange de ces trames, et le contenu FT et la négociation de clé sur ces trames sont fondamentalement identiques, que vous utilisiez 802.1X/EAP ou PSK comme méthode de sécurité. Comme le montre la capture, le champ AKM est la principale différence, ce qui confirme si le client exécute FT avec PSK ou 802.1X. Par conséquent, il est important de noter que ces quatre trames n'ont normalement pas ce type d'informations de sécurité pour la négociation de clé, mais seulement lorsque le FT client est en itinérance si la norme 802.11r est mise en oeuvre et négociée entre le client et l'infrastructure WLAN lors de l'association initiale.
La norme 802.11r permet une autre mise en oeuvre de la transition BSS rapide, où l'itinérance FT est initiée par le client avec le nouveau point d'accès pour lequel le client navigue sur le DS (système de distribution), et non en direct. Dans ce cas, les trames FT Action sont utilisées afin d'initier la négociation de clé au lieu des trames Open System Authentication.
En gros, une fois que le client décide qu'il peut se déplacer vers un meilleur AP, le client envoie une trame de demande d'action FT au point d'accès d'origine où il est actuellement connecté avant l'itinérance. Le client indique le BSSID (adresse MAC) du point d'accès cible où il souhaite effectuer une itinérance FT. Le point d'accès d'origine transfère cette trame de demande d'action FT au point d'accès cible sur le système de distribution (normalement l'infrastructure câblée), et le point d'accès cible répond au client avec une trame de réponse d'action FT (également sur le DS, afin qu'il puisse enfin l'envoyer en direct au client). Une fois que l'échange de trames FT Action est réussi, le client termine l'itinérance FT ; le client envoie la requête de réassociation au point d'accès cible (cette fois en direct), et reçoit une réponse de réassociation du nouveau point d'accès afin de confirmer l'itinérance et la dérivation des clés finales.
En résumé, il y a quatre trames pour négocier la transition BSS rapide et dériver de nouvelles clés de chiffrement, mais ici les trames d'authentification système ouvert sont remplacées par les trames de requête/réponse d'action FT, qui sont échangées avec le point d'accès cible sur le système de distribution avec le point d'accès actuel. Cette méthode est également valable pour les deux méthodes de sécurité 802.1X/EAP et PSK, toutes prises en charge par les contrôleurs de réseau local sans fil Cisco ; toutefois, comme cette transition Over-the-DS n'est pas prise en charge et mise en oeuvre par la plupart des clients sans fil du secteur WiFi (et que les sorties d'échange de trames et de débogage sont essentiellement les mêmes), des exemples ne sont pas fournis dans ce document. À la place, cette image est utilisée afin de visualiser la transition Fast BSS sur le DS :
Afin de remédier à cette situation, l'infrastructure LAN sans fil de Cisco a introduit la fonctionnalité Adaptive 802.11r. Lorsque le mode FT est défini sur Adaptive au niveau WLAN, le WLAN annonce l'ID de domaine de mobilité 802.11r sur un WLAN compatible 802.11i. Certains périphériques clients Apple iOS10 identifient la présence de MDIE sur un WLAN 80211i/WPA2 et effectuent une connexion propriétaire afin d'établir une association 802.11r. Une fois que le client a réussi l'association 802.11r, il sera en mesure d'effectuer l'itinérance FT comme dans un WLAN normal compatible 802.11r. FT Adaptive s'applique uniquement aux appareils Apple iOS10 (et versions ultérieures) sélectionnés. Tous les autres clients continueront d'avoir une association 802.11i/WPA2 sur le WLAN, et appliqueront la méthode FSR applicable comme prise en charge.
Vous trouverez plus de documentation sur cette nouvelle fonctionnalité introduite pour les périphériques iOS10 pour exécuter la norme 802.11r sur un WLAN/SSID où la norme 802.11r n'est pas réellement activée (d'autres clients non-802.11r se connecteront donc correctement) dans les meilleures pratiques d'entreprise pour les périphériques iOS sur le LAN sans fil Cisco.