Itinérance WLAN 802.11 et Itinérance Fast-Secure sur CUWN
Contenu
Introduction
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.
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Notions de base du WLAN IEEE 802.11
- Sécurité WLAN IEEE 802.11
- Notions de base IEEE 802.1X/EAP
Components Used
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.
Informations générales
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 :
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.
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.
Itinérance avec sécurité de niveau supérieur
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 :
- WPA/WPA2-PSK (Pre-Shared Key) : authentification des clients avec une clé prépartagée.
- WPA/WPA2-EAP (Extensible Authentication Protocol) : authentification des clients avec une méthode 802.1X/EAP afin de valider des informations d'identification plus sécurisées à l'aide d'un serveur d'authentification, comme les certificats, le nom d'utilisateur et le mot de passe, et les jetons.
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 :
- Un MSK est dérivé de la phase d'authentification EAP lorsque la sécurité 802.1X/EAP est utilisée, ou du PSK lorsque WPA/WPA2-PSK est utilisé comme méthode de sécurité.
- À partir de ce MSK, le client et le WLC/AP dérivent la clé maître par paire (PMK), et le WLC/AP génère une clé maître de groupe (GMK).
- Une fois que ces deux clés principales sont prêtes, le client et le WLC/AP lancent la connexion WPA/WPA2 en 4 étapes (illustrée plus loin dans ce document avec quelques captures d'écran et débogages) avec les clés principales comme base de négociation des clés de chiffrement réelles.
- Ces clés de chiffrement finales sont connues sous le nom de PTK (Pairwise Transient Key) et GTK (Group Transient Key). Le PTK est dérivé du PMK et utilisé pour chiffrer les trames de monodiffusion avec le client. La clé transitoire de groupe (GTK) est dérivée de la clé GMK et est utilisée pour chiffrer la multidiffusion/diffusion sur ce SSID/AP spécifique.
WPA/WPA2-PSK
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).
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.
WPA/WPA2-EAP
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.
Itinérance rapide et sécurisée avec CCKM
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.
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.
FlexConnect avec CCKM
- L'authentification centrale est prise en charge. Cela inclut la commutation de données locale et centrale. Les points d'accès doivent faire partie du même groupe FlexConnect.
- L'authentification locale flexible est prise en charge. En mode connecté, le cache sera distribué du point d'accès au contrôleur, puis aux autres points d'accès du groupe FlexConnect.
- Le mode autonome est pris en charge. Si le cache est déjà présent sur le point d'accès (en raison d'une distribution précédente), l'itinérance rapide doit fonctionner. La nouvelle authentification en mode autonome ne prend pas en charge l'itinérance rapide et sécurisée.
Profils avec CCKM
- CCKM est la méthode d’itinérance la plus rapide et sécurisée, principalement déployée sur les réseaux locaux sans fil d’entreprise. Les clients n'ont pas besoin de passer par une connexion de gestion des clés pour dériver de nouvelles clés lorsqu'un déplacement entre les points d'accès a lieu, et ne sont plus jamais tenus d'exécuter une authentification 802.1X/EAP complète avec de nouveaux points d'accès pendant la durée de vie du client sur ce WLAN.
- CCKM prend en charge toutes les méthodes de cryptage disponibles dans la norme 802.11 (WEP, TKIP et AES), en plus de certaines méthodes propriétaires traditionnelles de Cisco encore utilisées sur les clients existants.
Cons avec CCKM
- CCKM est une méthode propriétaire de Cisco qui limite la mise en oeuvre et la prise en charge de l'infrastructure WLAN Cisco et des clients sans fil CCX.
- La version 5 de CCX n'est pas largement adoptée, de sorte que CCKM avec WPA2/AES n'est pas pris en charge par de nombreux clients sans fil CCX (principalement parce que la plupart d'entre eux prennent déjà en charge CCKM avec WPA/TKIP, qui est encore très sécurisé).
Itinérance rapide et sécurisée avec mise en cache PMKID/mise en cache des clés rémanentes
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 :
- Cette méthode est facultative et n'est pas prise en charge par tous les périphériques WPA2, car l'objectif de l'amendement 802.11i ne concerne pas l'itinérance à sécurité rapide, et l'IEEE travaillait déjà sur un autre amendement pour normaliser l'itinérance à sécurité rapide pour les WLAN (802.11r, qui est traité plus loin dans ce document).
- Cette méthode a de grandes limites à sa mise en oeuvre : Les clients sans fil ne peuvent effectuer l'itinérance rapide et sécurisée que lorsqu'ils reviennent vers un point d'accès où ils avaient précédemment authentifié/connecté.
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 :
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
FlexConnect avec mise en cache PMKID/mise en cache des clés rémanentes
- Lorsque vous utilisez cette méthode sur une configuration FlexConnect, elle peut fonctionner et le comportement peut sembler similaire à ce qui a été expliqué précédemment si vous utilisez l'authentification centrale de nouveau vers le WLC (avec commutation centrale ou locale); toutefois, cette méthode SKC n'est pas prise en charge sur FlexConnect.
- Cette méthode n'est officiellement prise en charge que sur CUWN avec des points d'accès en mode local, pas sur FlexConnect ou d'autres modes.
Profils avec mise en cache PMKID/mise en cache des clés rémanentes
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.
Câbles avec mise en cache PMKID/mise en cache des clés rémanentes
- Comme mentionné précédemment dans ce document, la principale limite de cette méthode est que le client ne peut effectuer l'itinérance rapide sécurisée que lorsqu'il revient vers un point d'accès où il était précédemment associé/authentifié. Si l'itinérance vers un nouveau point d'accès, le client doit terminer à nouveau l'authentification EAP complète.
- Le client sans fil et les points d'accès doivent se souvenir de tous les PMK dérivés sur chaque nouvelle authentification, de sorte que cette fonctionnalité est normalement limitée à un certain nombre de PMK qui sont mis en cache. Comme cette limite n'est pas clairement définie par la norme, les fournisseurs peuvent définir différentes limites sur leurs implémentations SKC. Par exemple, les contrôleurs WLAN Cisco peuvent actuellement mettre en cache les PMK d'un client pour un maximum de huit points d'accès. Si un client se déplace vers plus de huit points d'accès par session, les points d'accès les plus anciens sont supprimés de la liste de cache afin de stocker les entrées nouvellement mises en cache.
- Cette méthode est facultative et n'est toujours pas prise en charge par de nombreux périphériques WPA2 ; par conséquent, cette méthode n'est pas largement adoptée et déployée.
- SKC n'est pas pris en charge lorsque vous effectuez l'itinérance intercontrôleur, ce qui se produit lorsque vous vous déplacez entre les AP gérés par différents WLC, même s'ils se trouvent sur le même groupe de mobilité.
Itinérance rapide et sécurisée grâce à la mise en cache opportuniste des clés
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.
FlexConnect avec mise en cache opportuniste des clés
- L'authentification centrale est prise en charge. Cela inclut la commutation de données locale et centrale. Si le point d'accès fait partie du même groupe FlexConnect, la route à sécurité rapide est assurée par le point d'accès, sinon la route à sécurité rapide est assurée par le contrôleur.
- L'authentification locale flexible est prise en charge. En mode connecté, le cache sera distribué du point d'accès au contrôleur, puis aux autres points d'accès du groupe FlexConnect.
- Le mode autonome est pris en charge. Si le cache est déjà présent sur le point d'accès (en raison d'une distribution précédente), l'itinérance rapide sécurisée doit fonctionner. La nouvelle authentification en mode autonome ne prend pas en charge l'itinérance rapide et sécurisée.
Profils avec mise en cache de clés opportunistes
- Le client sans fil et l'infrastructure WLAN n'ont pas besoin de mémoriser plusieurs PMKID, mais mettent simplement en cache le PMK d'origine de l'authentification initiale au WLAN. Ensuite, vous devez hacher le PMKID approprié (utilisé sur la demande de réassociation) requis avec chaque association sécurisée AP afin de valider l'itinérance sécurisée rapide.
- Ici, le client sans fil effectue une itinérance rapide et sécurisée vers un nouveau point d'accès sur le même WLAN/SSID, même s'il n'est jamais associé à ce point d'accès (ce qui n'est pas le cas dans SKC). Tant que le client effectue l'authentification 802.1X/EAP initiale avec un point d'accès géré par le déploiement centralisé qui gère le cache PMK pour tous les points d'accès pour lesquels le client se déplace, alors plus aucune authentification complète n'est requise pour le reste de la durée de vie du client sur ce WLAN.
Cons avec mise en cache de clés opportunistes
- Cette méthode est uniquement déployée dans un environnement centralisé où tous les points d'accès sont sous un contrôle administratif quelconque (tel qu'un contrôleur WLAN) qui est responsable de la mise en cache et du partage de la PMK d'origine de la session client. Par conséquent, il s'agit d'une limitation sur les environnements AP autonomes.
- Les techniques appliquées dans cette méthode ne sont pas suggérées ou décrites dans la norme 802.11, de sorte que la prise en charge varie considérablement d'un périphérique à l'autre. Néanmoins, c'est encore la méthode qui a été plus adoptée en attendant la norme 802.11r.
Remarque sur le terme “ Proactive Key Caching ”
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.
Itinérance rapide et sécurisée avec préauthentification
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) :
Profils avec préauthentification
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.
Cons avec préauthentification
- Comme il y a un PMK par point d'accès, les clients ont une limite sur le nombre de points d'accès qui peuvent être pré-authentifiés.
- Chaque fois qu'un client effectue une préauthentification avec un nouveau point d'accès, il y a un échange d'authentification EAP complet, ce qui signifie une charge plus importante sur le réseau et sur le serveur d'authentification.
- La plupart des clients sans fil ne prennent pas en charge cette méthode, car celle-ci n'a jamais été très adoptée (OKC a été plus adopté).
Itinérance rapide et sécurisée avec 802.11r
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 :
- La messagerie d'échange (échange PMKID, ANonce et SNonce, par exemple) se produit dans les trames d'authentification 802.11 ou dans les trames Action au lieu des trames de réassociation. Contrairement aux méthodes de mise en cache PMKID, la phase de connexion en 4 étapes séparée, qui est transportée après l'échange de messages (re)association, est évitée. La connexion de la clé avec le nouveau point d'accès commence avant que le client ne se déplace/ne se réassocie entièrement avec ce nouveau point d'accès.
- Il fournit deux méthodes pour la connexion en itinérance rapide : sur l'AIR et sur le système de distribution (DS).
- 802.11r comporte davantage de couches de hiérarchie de clés.
- Comme ce protocole évite l'échange en 4 étapes pour la gestion des clés lorsqu'un client se déplace (génère de nouvelles clés de cryptage - PTK et GTK - sans avoir besoin de cette connexion), il peut également être appliqué aux configurations WPA2 avec un PSK, et pas seulement lorsque 802.1X/EAP est utilisé pour l'authentification. Cela accélère encore davantage l'itinérance pour ces configurations, où aucun échange EAP ou d'échange en 4 étapes n'a lieu.
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 :
- Un MSK est toujours dérivé sur le demandeur client et le serveur d'authentification à partir de la phase initiale d'authentification 802.1X/EAP (transféré du serveur d'authentification vers l'authentificateur (WLC) une fois l'authentification réussie). Cette clé MSK, comme dans les autres méthodes, est utilisée comme amorce pour la hiérarchie de clés FT. Lorsque vous utilisez WPA2-PSK au lieu d'une méthode d'authentification EAP, le PSK est essentiellement ce MSK.
- Une clé maître par paire R0 (PMK-R0) est dérivée du MSK, qui est la clé de premier niveau de la hiérarchie de clés FT. Les détenteurs de clés pour ce PMK-R0 sont le WLC et le client.
- Une clé de second niveau, appelée clé maître par paire R1 (PMK-R1), est dérivée de la PMK-R0, et les détenteurs de clé sont le client et les AP gérés par le WLC qui détient la PMK-R0.
- La troisième et dernière clé de niveau de la hiérarchie de clés FT est le PTK, qui est la clé finale utilisée pour chiffrer les trames de données de monodiffusion 802.11 (similaire aux autres méthodes qui utilisent WPA/TKIP ou WPA2/AES). Ce PTK est dérivé sur FT du PMK-R1, et les détenteurs de clé sont le client et les AP gérés par le WLC.
Transition BSS rapide en vol
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 :
- La négociation de gestion des clés d'authentification est légèrement différente de la négociation WPA/WPA2 standard. Par conséquent, des informations supplémentaires sont utilisées afin d'effectuer cette négociation lorsque l'association à une infrastructure WLAN qui prend en charge FT se produit. Comme l'illustre la capture, la trame de demande d'association du client est sélectionnée et le champ AKM de l'élément d'information RNS est mis en surbrillance afin de montrer que ce client souhaite exécuter FT sur 802.1X/EAP.
- L'élément Mobility Domain Information Element (faisant partie de FT) est également affiché, où le champ FT Capability and Policy indique si la transition Fast BSS est effectuée en vol ou en vol sur DS lors de l'itinérance rapide (en indiquant le survol dans cette capture).
- Un autre élément d'information est également ajouté (Fast BSS Transition ou FT IE, décrit plus loin dans ce document) avec les informations requises pour exécuter la séquence d'authentification FT lors de l'itinérance FT.
- La génération de clés est différente en raison de la hiérarchie de clés. Par conséquent, même si la connexion FT 4 directions ressemble à la connexion WPA/WPA2 4 directions, son contenu est légèrement différent.
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.
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.
Transition BSS rapide sur DS
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 :
FlexConnect avec 802.11r
- L'authentification centrale est prise en charge. Cela inclut la commutation de données locale et centrale. Les points d'accès doivent faire partie du même groupe FlexConnect.
- L'authentification locale n'est pas prise en charge.
- Le mode autonome n'est pas pris en charge.
Avantages avec 802.11r
- Cette méthode est la première qui utilise une hiérarchie de clés clairement définie par l'IEEE sur la norme 802.11 en tant qu'amendement (802.11r), de sorte que la mise en oeuvre de ces techniques FT est plus compatible entre les fournisseurs et sans interprétation différente.
- La norme 802.11r autorise plusieurs techniques utiles, en fonction de vos besoins (survol et survol des DS, pour la sécurité 802.1x/EAP et pour la sécurité PSK).
- Le client sans fil effectue une itinérance rapide et sécurisée vers un nouveau point d'accès sur le même WLAN/SSID, même s'il n'est jamais associé à ce point d'accès, et sans avoir à enregistrer plusieurs PMKID.
- Il s'agit de la première méthode d'itinérance rapide et sécurisée qui permet une itinérance plus rapide même avec la sécurité PSK, et évite la connexion en 4 étapes requise lors de l'itinérance entre les points d'accès avec WPA/WPA2 PSK. L'objectif principal des méthodes d'itinérance rapide et sécurisée est d'éviter la connexion 802.1X/EAP lorsque cette méthode de sécurité est implémentée ; cependant, pour la sécurité PSK, l'événement d'itinérance est encore plus accéléré avec 802.11r en évitant la connexion en 4 étapes.
Contre avec 802.11r
- Il existe quelques périphériques clients sans fil qui prennent en charge les transitions Fast BSS. Dans la plupart des cas, ils ne prennent pas en charge toutes les techniques disponibles sur la norme 802.11r.
- Du fait que ces implémentations sont très jeunes, il n'y a pas assez de résultats de test provenant d'environnements de production réelle ou assez de résultats de débogage pour répondre aux éventuelles mises en garde qui pourraient apparaître.
- Lorsque vous configurez un WLAN/SSID afin d'utiliser l'une des méthodes FT, seuls les clients sans fil prenant en charge 802.11r peuvent se connecter à ce WLAN/SSID. Les paramètres FT ne sont pas facultatifs pour les clients. Par conséquent, les clients sans fil qui ne prennent pas en charge 802.11r doivent se connecter à un WLAN/SSID distinct où FT n'est pas configuré du tout.
Adaptive 802.11r
- Certains clients hérités ne peuvent pas s'associer à un WLAN/SSID dont la norme 802.11r est activée même en mode mixte (ce que vous pouvez espérer avoir sur les mêmes clients SSID qui prennent en charge et qui ne prennent pas en charge la norme 802.11r). C'est lorsque le pilote du demandeur client qui est responsable de l'analyse de l'élément d'information de réseau de sécurité robuste (IE RSN) est vieux et ne connaît pas les suites AKM supplémentaires dans l'IE. En raison de cette limitation, les clients ne peuvent pas envoyer de demandes d'association aux WLAN qui annoncent la prise en charge de la norme 802.11r. Par conséquent, vous devrez probablement configurer un WLAN/SSID pour les clients 802.11r et un WLAN/SSID distinct pour les clients qui ne prennent pas en charge la norme 802.11r.
-
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.
Conclusions
- Gardez à l'esprit que le client est toujours celui qui décide de se déplacer vers un AP spécifique, et le WLC/AP ne peut pas décider ceci pour le client. L'événement d'itinérance est initié par le client sans fil une fois qu'il estime qu'il doit se déplacer.
- Le WLC prend en charge une combinaison de la plupart ou de la totalité des méthodes FSR (Fast-Secure Roaming) ensemble sur le même WLAN/SSID. Cependant, sachez que cela ne fonctionne normalement pas, car il dépend fortement du comportement du client (très différent sur différents périphériques mobiles) afin de prendre en charge ou même comprendre ce que le WLC tente d'annoncer comme pris en charge. Au lieu d'obtenir l'interopérabilité dans un seul SSID, il y a généralement plus de problèmes que ceux qui devraient être corrigés, ce qui n'est pas recommandé. Des tests approfondis avec tous les clients possibles à utiliser sur ce WLAN doivent être effectués si cela est vraiment nécessaire.
- Il est très important de comprendre que des méthodes d'itinérance rapide et sécurisée sont développées afin d'accélérer le processus d'itinérance WLAN lorsque vous passez d'un point d'accès à un autre si la sécurité du WLAN/SSID est activée. Quand aucune sécurité n'est en place, il n'y a rien à accélérer, car le point d'accès client échange simplement les trames de gestion sans fil qui sont toujours requises lors de l'itinérance entre les points d'accès avant l'envoi des trames de données (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). Par conséquent, cela ne peut pas aller plus vite. Si vous rencontrez des problèmes d'itinérance sans sécurité, alors il n'y a pas de méthodes d'itinérance rapide pour améliorer l'itinérance, seulement des méthodes afin de confirmer si la configuration et la conception du WLAN/SSID sont appropriées pour que les stations clientes sans fil évoluent en conséquence entre les cellules de couverture du point d'accès.
- La norme 802.11r/FT est implémentée avec WPA2-PSK afin d'accélérer les événements d'itinérance avec cette sécurité en évitant la connexion en 4 étapes, comme expliqué dans la section 802.11r.
- Toutes les méthodes ont leurs avantages et leurs inconvénients, mais en fin de compte, vous devez toujours vérifier si les stations clientes sans fil prennent en charge la méthode spécifique que vous voulez implémenter et si l'infrastructure WLAN de Cisco prend en charge toutes les méthodes disponibles. Vous devez donc sélectionner la meilleure méthode prise en charge par les clients sans fil qui se connectent au WLAN/SSID spécifique. Par exemple, dans certains déploiements, vous pouvez créer un WLAN/SSID avec CCKM pour les téléphones IP sans fil Cisco (qui prennent en charge WPA2/AES avec CCKM, mais pas 802.11r), puis un autre WLAN/SSID avec WPA2/AES via 802.11r/FT pour les clients sans fil qui prennent en charge cette méthode d'itinérance sécurisée rapide (ou utilisent OKC, si c'est ce qui est supporté).
- Si les clients sans fil ne prennent en charge aucune des méthodes d'itinérance rapide et sécurisée disponibles, vous devrez peut-être accepter le fait que ces clients expérimenteront toujours les délais expliqués dans ce document lors de l'itinérance entre les AP sur un WLAN/SSID avec la sécurité 802.1X/EAP (ce qui peut provoquer des interruptions sur les applications/services client).
- Toutes les méthodes, à l'exception de SKC (mise en cache PMKID WPA2), sont prises en charge pour l'itinérance rapide et sécurisée entre les points d'accès gérés par différents WLC (itinérance intercontrôleur), tant qu'ils se trouvent sur le même groupe de mobilité.
- CUWN prend entièrement en charge toutes les différentes méthodes d'itinérance Fast-Secure décrites dans cet article lors de l'utilisation de l'authentification 802.1X/EAP pour WPA/WPA2. CUWN ne prend pas en charge l'itinérance rapide et sécurisée sur les méthodes qui fonctionnent avec WPA2-RSN (CCKM, PMKID Caching/SKC, OKC/PKC) lors de l'utilisation de PSK (WPA2-Personal), où les méthodes d'itinérance rapide ne sont généralement pas nécessaires. Cependant, CUWN prend en charge l'itinérance Fast-Secure dans le cas de WPA2-FT (802.11r) avec PSK, comme expliqué dans cet article.
Commentaires