Itinérance du 802.11 WLAN et itinérance Rapide-sécurisée sur CUWN
Contenu
Introduction
Ce document décrit les différents types de l'itinérance Sans fil et de méthodes rapide-sécurisées d'itinérance disponibles pour les réseaux locaux Sans fil d'IEEE 802.11 (WLAN) pris en charge sur le réseau sans fil unifié Cisco (CUWN).
Le document ne fournit pas toutes les particularités au sujet de la façon dont chaque méthode fonctionne ou de la façon dont ils sont configurés. Le but principal de ce document est de décrire les différences entre les diverses techniques disponibles, leurs avantages et limites, et le trame-échange sur chaque méthode. Les exemples du contrôleur WLAN (WLC) met au point sont fournis, et des captures Sans fil de paquet sont utilisées afin d'analyser et expliquer les événements qui se produisent pour chaque méthode d'itinérance décrite.
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Principes fondamentaux de l'IEEE 802.11 WLAN
- Sécurité WLAN d'IEEE 802.11
- Fondements d'IEEE 802.1X/EAP
Composants utilisés
Les informations dans ce document sont basées sur la version 7.4 de logiciel contrôleur de WLAN Cisco, mais la plupart des sorties de débogage et des comportements décrits pourraient s'appliquer à n'importe quelle version de logiciel qui prend en charge les méthodes discutées. Les particularités de toutes les méthodes expliquées ici demeurent les mêmes sur des codes postérieurs de contrôleur de WLAN Cisco (jusqu'à la version 8.3 avant que cet article ait été mis à jour).
Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.
Informations générales
Avant qu'une description des différentes méthodes rapide-sécurisées d'itinérance disponibles pour des WLAN soit donnée, il est important de comprendre comment les travaux par processus d'association WLAN, et comment un événement régulier d'itinérance se produit quand il n'y a aucune Sécurité configurée sur l'Identifiant SSID (Service Set Identifier).
Quand un client sans fil de 802.11 se connecte à un Point d'accès (AP), avant qu'il commence à passer le trafic (trames de données Sans fil), il d'abord doit passer le procédé d'authentification Système ouvert de base de 802.11. Puis, le processus d'association doit être terminé. Pensez au procédé d'authentification Système ouvert en tant que « connecter le câble » sur AP que le client sélectionne. C'est très important pour comprendre, parce que c'est toujours le client sans fil qui sélectionne quel AP est préféré, et base la décision sur les plusieurs facteurs qui varient entre les constructeurs. C'est pourquoi le client commence ce processus en envoyant la trame d'authentification à AP sélectionné, comme affiché plus tard dans ce document. AP ne peut pas demander que vous établissez une connexion.
Une fois que le procédé d'authentification Système ouvert est terminé avec succès avec une réponse d'AP (« câble connecté »), le processus d'association termine essentiellement la négociation de la couche 2 de 802.11 (L2) qui établit le lien entre le client et l'AP. AP assigne un ID d'association au client si la connexion est réussie, et le prépare afin de passer le trafic ou exécuter une méthode de plus haut niveau de Sécurité si configuré sur le SSID. Le procédé d'authentification Système ouvert se compose de deux trames de Gestion aussi bien que du processus d'association. Les trames d'authentification et d'association sont les trames Sans fil de Gestion, pas les trames de données, qui sont fondamentalement celles utilisées pour la procédure de connexion avec AP.
Voici une capture des trames Sans fil au-dessus du - aérez pour ce processus :
Le client sans fil commence par la trame d'authentification, et AP répond avec une autre trame d'authentification. Le client envoie alors la trame de demande d'association, et AP termine dans une réponse avec la trame de réponse d'association. Comme affiché des paquets DHCP, une fois que les procédés d'authentification Système ouvert et d'association de 802.11 sont passés, le client commence à passer des trames de données. Dans ce cas, il n'y a aucune méthode de Sécurité configurée sur le SSID, ainsi le client commence immédiatement à envoyer les trames de données (dans ce cas DHCP) qui ne sont pas chiffrées.
Comme affiché plus tard dans ce document, si la Sécurité est activée sur le SSID, il y a les trames de plus haut niveau de prise de contact d'authentification et de cryptage pour la méthode spécifique de Sécurité, juste après la réponse d'association et avant d'envoyer toutes les trames de données de trafic de client, telles que le DHCP, le Protocole ARP (Address Resolution Protocol), et les paquets d'applications, qui sont chiffrés. Des trames de données peuvent seulement être envoyées jusqu'à ce que le client soit entièrement authentifié, et les clés de chiffrement sont négociées, basé sur la méthode de Sécurité configurée.
Basés sur la capture précédente, sont les messages que vous voyez dans les sorties du WLC mettez au point l'ordre de client quand 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 initiales d'authentification ne sont pas connectées au WLC parce que cette prise de contact se produit rapidement au niveau du AP sur le CUWN.
Quelles informations apparaissent quand le client erre ? Le client permute toujours quatre trames de Gestion sur l'établissement d'une connexion à AP, qui est dû à l'établissement de client de l'association, ou à un événement d'itinérance. Le client fait établir seulement une connexion à seulement un AP à la fois. La seule différence dans l'échange de trame 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 s'appellent les trames de Reassociation, qui indiquent que le client erre réellement d'un autre AP sans des tentatives d'établir une nouvelle association au WLAN. Ces trames peuvent contenir les différents éléments qui sont utilisés afin de négocier l'événement d'itinérance ; ceci dépend de l'installation, mais ces détails sont hors de portée de ce document.
Voici un exemple de l'échange de trame :
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 affiché, le client exécute avec succès un événement d'itinérance après que la demande de rassociation à nouvel AP soit envoyée, et reçoit la réponse de rassociation d'AP. Puisque le client a déjà une adresse IP, les premières trames de données sont pour des paquets d'ARP.
Si vous vous attendez à un événement d'itinérance, mais le client envoie une demande d'association au lieu d'une demande de rassociation (que vous pouvez confirmer de quelques captures et mettez au point semblable à ceux expliqué plus tôt dans ce document), alors le client n'erre pas vraiment. Le client commence une nouvelle association au WLAN comme si une déconnexion a eu lieu, et aux essais pour rebrancher le à partir de zéro. Ceci peut se produire pour de plusieurs raisons, comme quand un client s'éloigne des zones de couverture et puis trouve AP avec assez de qualité du signal pour commencer une association, mais elle indique normalement une question de client où le client n'initie pas un événement d'itinérance dû aux gestionnaires, au micrologiciel, ou aux problèmes logiciels.
Errer avec la Sécurité de plus haut niveau
Quand le SSID est configuré avec la Sécurité L2 de plus haut niveau sur l'authentification Système ouvert de base de 802.11, alors plus de trames sont exigées pour l'association initiale et en errant. Les deux méthodes plus-communes de Sécurité normalisées et appliquées pour le 802.11 WLAN sont décrites dans ce document :
- WPA/WPA2-PSK (clé pré-partagée) - 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 plus qualifications sécurisées par l'utilisation d'un serveur d'authentification, telle que des Certificats, le nom d'utilisateur et mot de passe, et des jetons.
Il est important de savoir que, quoique ces deux méthodes (PSK et EAP) authentifient/valident les clients dans différentes manières, chacun des deux utilisent fondamentalement les mêmes règles WPA/WPA2 pour le processus de gestion des clés. Si la Sécurité est WPA/WPA2-PSK ou WPA/WPA2-EAP, le processus connu sous le nom de prise de contact WPA/WPA2 4-Way commence la négociation principale entre le WLC/AP et le client par une clé de session principale (MSK) comme élément 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 quand la Sécurité 802.1X/EAP est utilisée, ou du PSK quand WPA/WPA2-PSK est utilisé comme méthode de Sécurité.
- De ce MSK, le client et les WLC/AP dérivent le Pairwise Master Key (PMK), et le WLC/AP génère une clé principale de groupe (GMK).
- Une fois que ces deux clés principales sont prêtes, le client et les WLC/AP initient la prise de contact WPA/WPA2 4-Way (qui est illustrée plus tard dans ce document avec quelques captures d'écran et met au point) avec les clés principales comme graines pour la négociation des clés de chiffrement réelles.
- Ces clés de chiffrement finales sont connues comme Pairwise Transient Key (PTK) et Group Transient Key (GTK). Le PTK est dérivé du PMK et utilisé afin de chiffrer des trames de monodiffusion avec le client. Le Group Transient Key (GTK) est dérivé du GMK, et est utilisé afin de chiffrer la Multidiffusion/émission sur cette particularité SSID/AP.
WPA/WPA2-PSK
Quand le WPA-PSK ou le WPA2-PSK est exécuté par l'intermédiaire du Protocole TKIP (Temporal Key Integrity Protocol) ou du Norme AES (Advanced Encryption Standard) pour le cryptage, le client doit passer par le processus connu sous le nom de prise de contact WPA 4-Way pour chacun des deux l'association initiale et également en errant. Comme précédemment expliqué, c'est fondamentalement le processus de gestion des clés utilisé pour que WPA/WPA2 dérive les clés de chiffrement. Cependant, quand PSK est exécuté, on l'utilise également afin de vérifier que le client a une clé pré-partagée valide pour joindre le WLAN. Cette capture affiche le processus initial d'association quand le WPA ou le WPA2 avec PSK est exécuté :
Comme affiché, après l'authentification Système ouvert de 802.11 et le processus d'association, il y a quatre trames EAPOL de la prise de contact WPA 4-Way, qui sont initiés par AP avec message-1, et terminés par le client avec message-4. Après une prise de contact réussie, le client commence à passer les trames de données (telles que le DHCP), qui dans ce cas sont chiffrées avec les clés dérivées de la prise de contact 4-Way (c'est pourquoi vous ne pouvez pas voir le contenu et le type de trafic réels des captures de radio).
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 errant, le client suit fondamentalement le même échange de trame, où la prise de contact WPA 4-Way est exigée afin de dériver de nouvelles clés de chiffrement avec nouvel AP. C'est dû aux raisons de sécurité établies par la norme, et au fait que nouvel AP ne connaît pas les clés d'origine. La seule différence est qu'il y a des trames de rassociation au lieu des trames d'association, suivant les indications de cette capture :
Vous voyez les mêmes messages dans les sorties de débogage, mais le premier paquet du client est une rassociation au lieu d'une association, comme affiché et expliqué précédemment.
WPA/WPA2-EAP
Quand une méthode 802.1X/EAP est utilisée afin d'authentifier les clients sur un SSID sécurisé, il y a bien plus de trames exigées avant que le client commence à passer le trafic. Ces trames supplémentaires sont utilisées afin d'authentifier les qualifications de client, et la personne à charge sur la méthode d'EAP, là pourrait être entre quatre et vingt trames. Ceux-ci sont livré après l'association/rassociation, mais avant la prise de contact WPA/WPA2 4-Way, parce que la phase d'authentification dérive le MSK utilisé comme graine pour la génération finale de clé de chiffrement dans le processus de gestion des clés (prise de contact 4-Way).
Cette capture Sans fil affiche un exemple des trames permutées au-dessus de l'air entre AP et le client sans fil sur l'association initiale quand le WPA avec PEAPv0/EAP-MSCHAPv2 est exécuté :
Parfois cet échange affiche plus ou moins de trames, qui dépend de plusieurs facteurs, tels que la méthode d'EAP, des retransmissions dues aux problèmes, comportement de client (tel que les deux demandes d'identité dans cet exemple, parce que le client envoie un DÉBUT EAPOL après qu'AP envoie la première demande d'identité), ou si le client permutait déjà le certificat avec le serveur. Toutes les 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, elle a besoin de 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.
Quand le client sans fil exécute errer régulier ici (le comportement normal, sans implémentation d'une méthode rapide-sécurisée d'itinérance), le client doit passer par le précis le même processus et exécuter une pleine authentification contre le serveur d'authentification, suivant les indications des captures. La seule différence est que le client emploie une demande de rassociation afin d'informer nouvel AP qu'il erre réellement d'un autre AP, mais le client doit encore passer par la pleine validation et la nouvelle génération de clés :
Comme affiché, même lorsqu'il y a moins de trames que dans l'authentification initiale (ce qui est provoqué par par de plusieurs facteurs, comme indiqué précédemment), quand le client erre à nouvel AP, l'authentification EAP et les processus de gestion de clé WPA doivent encore être terminés afin de continuer à passer des trames de données (même si le trafic a été activement envoyé avant d'errer). Par conséquent, si le client a une application active que qui est sensible aux retards (tels que des applications du trafic vocal, ou applications qui sont sensibles aux délais d'attente), puis l'utilisateur peut percevoir des problèmes en errant, comme des lacunes ou des débranchements sonores d'application. Ceci dépend de combien de temps le processus rentre la commande pour que le client continue aux trames de données émetteuses-réceptrices. Ce retard pourrait être plus long, dépendant au moment : l'environnement rf, la quantité de clients, le Round-Trip Time entre le WLC et les recouvrements 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 (fondamentalement les mêmes que le précédent, ainsi ces messages ne sont pas décrits plus loin) :
*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 la manière dont 802.1X/EAP et la structure de sécurité WPA/WPA2 fonctionnent. Afin d'empêcher l'application/entretenez l'incidence sur des retards à partir d'un événement régulier d'itinérance, de plusieurs méthodes rapide-sécurisées d'itinérance sont développées et appliquées par le secteur de WiFi afin d'accélérer le processus d'itinérance quand la Sécurité est utilisée sur le WLAN/SSID. Les clients font face à de la latence quand ils continuent à passer le trafic tout en errant autour entre les aps par l'intermédiaire du déploiement de la Sécurité de haut niveau sur le WLAN. C'est dû aux échanges de trame d'authentification EAP et de gestion des clés exigés par la configuration de la sécurité, comme précédemment expliqué.
Il est important de comprendre que l'itinérance rapide-sécurisée est juste le terme utilisé par le secteur en référence à l'implémentation d'une méthode/de schéma qui accélère le processus d'itinérance quand la Sécurité est configurée sur le WLAN. Les différents méthodes/schémas rapide-sécurisés d'itinérance qui sont disponibles pour des WLAN, et sont pris en charge par le CUWN, sont expliqués dans la section suivante.
Itinérance Rapide-sécurisée avec CCKM
Le Cisco Centralized Key Management (CCKM) est la première méthode rapide-sécurisée d'itinérance développée et appliquée sur des WLAN d'entreprise, créés par Cisco comme la solution l'a utilisé afin d'atténuer les retards expliqués jusqu'ici, quand la Sécurité 802.1X/EAP est utilisée sur le WLAN. Car c'est un protocole propriétaire de Cisco, il est seulement pris en charge par des périphériques d'infrastructure et des clients sans fil de WLAN Cisco (de plusieurs constructeurs) qui sont Cisco Compatible Extension (CCX) - compatibles pour CCKM.
CCKM peut être mis en application avec toutes les différentes méthodes de cryptage disponibles pour des WLAN, pour inclure : WEP, TKIP, et AES. Il est également pris en charge avec la plupart des méthodes d'authentification 802.1X/EAP utilisées pour des WLAN, dépendant sur la version CCX prise en charge par les périphériques.
Cette capture Sans fil fournit un exemple des trames permutées sur l'association initiale quand vous exécutez CCKM avec le TKIP comme cryptage, et le PEAPv0/EAP-MSCHAPv2 comme méthode 802.1X/EAP. C'est fondamentalement le même échange comme si WPA/TKIP avec PEAPv0/EAP-MSCHAPv2 est exécuté, mais cette fois CCKM entre le client et l'infrastructure est négociée de sorte qu'ils emploient différentes méthodes principales de hiérarchie et de cache afin d'exécuter l'itinérance sécurisée rapide quand le client doit errer :
Voici un résumé des messages de débogage (avec un certain EAP permute retiré 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 semblable au militaire de carrière WPA/WPA2, où un MSK (également connu ici comme clé de session NETWORK (NSK)) est mutuellement dérivé avec le client et le serveur de RADIUS. Cette clé principale est envoyée du serveur au WLC après une authentification réussie, et est cachée comme base pour la dérivation de toutes les clés ultérieures pour la vie de l'association de client avec ce WLAN. D'ici, les WLC et le client dérivent les informations de graine qui sont utilisées pour l'itinérance rapide-sécurisée basée sur CCKM, allant par une prise de contact 4-Way semblable à celle de WPA/WPA2, afin de dériver les clés de chiffrement de l'unicast (PTK) et de la Multidiffusion/émission (GTK) avec le premier AP.
La grande différence est notée en errant. Dans ce cas, le client CCKM envoie une trame simple de demande de rassociation à l'AP/WLC (MIC y compris et nombre aléatoire séquentiellement de incrémentation), et fournit assez d'informations (nouvelle adresse MAC y compris AP - BSSID-) afin de dériver le nouveau PTK. Avec cette demande de rassociation, les WLC et le nouvel AP ont également assez d'informations afin de dériver le nouveau PTK, ainsi ils répondent simplement avec une réponse de rassociation. Le client peut maintenant continuer à passer le trafic, suivant les indications de cette capture :
Voici un résumé du WLC met au point 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.
En tant qu'itinérance affichée et rapide-sécurisée est exécuté tout en évitant les trames d'authentification EAP et bien plus de prises de contact 4-Way, parce que les nouvelles clés de chiffrement sont encore dérivées, mais est basé sur le schéma de négociation CCKM. Ceci est terminé avec les trames de rassociation d'itinérance et les informations précédent-cachées par le client et le WLC.
FlexConnect avec CCKM
- L'authentification centrale est prise en charge. Ceci inclut des données locales et centrales swtiching. Les aps doivent faire partie du même groupe de FlexConnect.
- L'authentification locale de flexible est prise en charge. En mode connecté, le cache sera distribué d'AP au contrôleur et puis au reste des aps dans le groupe de FlexConnect.
- Le mode autonome est pris en charge. Si le cache est déjà présent sur AP (dû à la distribution précédente), rapide errez fonctionnera. La nouvelle authentification en mode autonome ne prend en charge pas l'itinérance rapide-sécurisée.
Avantages avec CCKM
- CCKM est la méthode d'itinérance rapide-sécurisée la plus rapide en grande partie déployée sur des WLAN d'entreprise. Les clients n'ont pas besoin d'aller au-dessus d'une prise de contact de gestion des clés afin de dériver de nouvelles clés quand un mouvement entre les aps a lieu, et jamais sont de nouveau priés d'exécuter une pleine authentification 802.1X/EAP avec de nouveaux aps pendant la vie de client sur ce WLAN.
- CCKM prend en charge toutes les méthodes de cryptage disponibles dans la norme de 802.11 (WEP, TKIP, et AES), en plus de quelques méthodes de propriété industrielle existantes de Cisco toujours utilisées sur les clients existants.
Inconvénients avec CCKM
- CCKM est une méthode de propriété industrielle de Cisco, qui limite l'implémentation et le support à l'infrastructure et à CCX de WLAN Cisco des clients sans fil.
- CCX la version 5 n'est pas largement adoptée, ainsi CCKM avec WPA2/AES n'est pas pris en charge par beaucoup de clients CCX Sans fil (principalement parce que la plupart d'entre eux déjà support CCKM avec WPA/TKIP, qui est toujours très sécurisé).
Itinérance Rapide-sécurisée avec la mise en cache PMKID/Key Caching Rémanent
La mise en cache de l'ID de Pairwise Master Key (PMKID), ou le Key Caching Rémanent (SKC), est la première méthode rapide-sécurisée d'itinérance suggérée par la norme d'IEEE 802.11 dans l'amendement de la Sécurité 802.11i, où le but principal est de normaliser un haut niveau de sécurité pour des WLAN. Cette technique rapide-sécurisée d'itinérance a été ajoutée pendant qu'une méthode facultative pour les périphériques WPA2 afin d'améliorer l'itinérance quand cette Sécurité a été mise en application.
C'est possible parce que, chaque fois qu'un client Eap-est entièrement authentifié, le client et le serveur d'authentification dérivent un MSK, qui est utilisé afin de dériver le PMK. Ceci est utilisé comme la graine pour la prise de contact WPA2 4-Way afin de dériver la clé de chiffrement finale d'unicast (PTK) qui est utilisée pour la session (jusqu'à ce que le client erre à un autre AP ou la session expire) ; par conséquent, cette méthode empêche la phase d'authentification EAP en errant parce qu'elle réutilise l'original PMK caché par le client et l'AP. Le client seulement doit passer par la prise de contact WPA2 4-Way afin de dériver de nouvelles clés de chiffrement.
Cette méthode n'est pas largement déployée comme méthode rapide-sécurisée standard recommandée d'itinérance de 802.11 principalement due à ces raisons :
- Cette méthode est facultative et n'est pas prise en charge par tous les périphériques WPA2, parce que le but de l'amendement 802.11i ne concerne pas l'itinérance rapide-sécurisée, et l'IEEE fonctionnait déjà sur un autre amendement pour normaliser l'itinérance rapide-sécurisée pour WLAN (802.11r, qui est couvert plus tard dans ce document).
- Cette méthode a une grande limite sur son implémentation : Les clients sans fil peuvent seulement exécuter l'itinérance rapide-sécurisée en errant de nouveau à AP où ils avaient précédemment authentifié/s'étaient connectés.
Avec cette méthode, l'association initiale à n'importe quel AP est juste comme une authentification pour la première fois régulière au WLAN, où l'authentification 802.1X/EAP entière contre le serveur d'authentification et la prise de contact 4-Way pour la génération de clés doit se produire avant que le client puisse envoyer des trames de données, suivant les indications de cette capture d'écran :
Met au point indiquent le même échange de trame d'authentification EAP que le reste des méthodes sur l'authentification initiale au WLAN, avec quelques sorties ajoutées en vue de les techniques principales de mise en cache utilisées ici. Ces sorties de débogage ne sont réduites afin d'afficher principalement les nouvelles informations, pas l'échange entier de trame d'EAP, parce que fondamentalement les mêmes informations sont permutées chaque fois pour l'authentification du client contre le serveur d'authentification. Ceci est expliqué jusqu'ici, et corrélé avec les trames d'authentification EAP affichées dans les captures de paquet, ainsi la plupart des messages d'EAP sont retirées des sorties de débogage pour la 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, AP et le client sans fil cachent le PMKs des associations sécurisées déjà établies. Par conséquent, si le client sans fil erre à nouvel AP où il n'a jamais associé, le client doit exécuter une pleine authentification EAP de nouveau, suivant les indications de cette capture Sans fil où le client erre à nouvel AP :
Cependant, si le client sans fil erre de nouveau à AP où une association/authentification précédentes a eu lieu, puis le client envoie une trame de demande de rassociation qui répertorie plusieurs PMKIDs, qui informe AP du PMKs caché de tous les aps où le client a précédemment authentifié. Par conséquent, puisque le client erre de nouveau à AP qui a également un PMK caché pour ce client, puis le client n'a pas besoin d'authentifier à nouveau par l'EAP afin de dériver un nouveau PMK. Le client passe simplement par la prise de contact WPA2 4-Way afin de dériver les nouvelles clés de chiffrement passagères :
Voici un résumé du WLC met au point pour cette méthode rapide-sécurisée d'itinérance :
*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 la mise en cache PMKID/Key Caching Rémanent
- Quand vous utilisez cette méthode sur une installation de FlexConnect, elle pourrait fonctionner et le comportement pourrait sembler semblable à ce qui a été précédemment expliqué si vous utilisez l'authentification centrale de nouveau au WLC (avec la commutation centrale ou locale) ; cependant, cette méthode SKC n'est pas prise en charge sur FlexConnect.
- Cette méthode seulement est officiellement prise en charge sur CUWN avec le mode local aps, pas sur FlexConnect ou d'autres modes.
Avantages avec la mise en cache PMKID/Key Caching Rémanent
Cette méthode peut être appliquée localement par l'autonome-indépendant aps, sans nécessité d'un périphérique centralisé de gérer les clés cachées.
Inconvénients avec la mise en cache PMKID/Key Caching Rémanent
- Comme mentionné plus tôt dans ce document, la limite principale de cette méthode est que le client peut seulement exécuter l'itinérance rapide-sécurisée en errant de nouveau à AP où elle a précédemment associé/authentifié. Si errant à nouvel AP, le client doit se terminer la pleine authentification EAP de nouveau.
- Le client sans fil et les aps doivent se souvenir tout les PMKs dérivé sur chaque nouvelle authentification, ainsi cette caractéristique est normalement limitée à un PMKs qui sont cachés. Puisque cette limite n'est pas bien définie par la norme, les constructeurs peuvent définir différentes limites sur leurs réalisations SKC. Par exemple, les contrôleurs de WLAN Cisco peuvent actuellement cacher le PMKs d'un client pour jusqu'à huit aps. Si un client erre à plus de huit aps par session, les aps les plus anciens sont retirés de la liste de cache afin d'enregistrer les entrées nouveau-cachées.
- Cette méthode est facultative et n'est pas toujours prise en charge par beaucoup de périphériques WPA2 ; donc, cette méthode n'est pas largement adoptée et est déployée.
- SKC n'est pas pris en charge quand vous exécutez l'itinérance d'intercontroller, qui se produit quand vous vous déplacez entre les aps gérés par WLCs différent, même si ils sont sur le même groupe de mobilité.
Itinérance Rapide-sécurisée avec le Key Caching opportuniste
Key Caching opportuniste (OKC), également connu sous le nom de Key Caching proactif (PKC) (ce terme est expliqué plus en détail dans une note qui suit), est fondamentalement une amélioration de la méthode de mise en cache WPA2 PMKID décrite précédemment, qui est pourquoi c'est également nommé Proactive/mise en cache opportuniste PMKID. Par conséquent, il est important de noter que ce n'est pas une méthode rapide-sécurisée d'itinérance définie par le 802.11 standard et n'est pas prise en charge par beaucoup de périphériques, mais juste comme la mise en cache PMKID, cela fonctionne avec WPA2-EAP.
Cette technique permet au client sans fil et à l'infrastructure WLAN pour cacher seulement un PMK pour la vie de l'association de client avec ce WLAN (dérivé du MSK après que l'authentification d'initiale 802.1X/EAP avec le serveur d'authentification), même lorsqu'errant entre le multiple aps, car ils tous partagent l'original PMK qui est utilisé comme graine sur toutes les prises de contact WPA2 4-way. Ceci est encore exigé, juste comme il est dans SKC, afin de générer de nouvelles clés de chiffrement chaque fois que le client rassocie aux aps. Pour que les aps partagent ce PMK un d'origine de la session de client, ils doivent tout être sous un certain tri de contrôle administratif, avec un périphérique centralisé qui cache et distribue l'original PMK pour tous les aps. C'est semblable au CUWN, où le WLC effectue ce travail pour tous les recouvrements sous son contrôle, et utilise les Groupes de mobilité afin de manipuler ce PMK entre plusieurs WLCs ; donc, c'est une limite sur les environnements autonomes AP.
Avec cette méthode, juste comme dans la mise en cache PMKID (SKC), l'association initiale à n'importe quel AP est une authentification pour la première fois régulière au WLAN, où vous devez se terminer l'authentification 802.1X/EAP entière contre le serveur d'authentification et la prise de contact 4-Way pour la génération de clés avant que vous puissiez envoyer des trames de données. Voici une capture d'écran qui illustre ceci :
Les sorties de débogage affichent fondamentalement le même échange de trame d'authentification EAP que le reste des méthodes décrites dans ce document sur l'authentification initiale au WLAN (suivant les indications des captures), avec l'ajout de quelques sorties qui concernent les techniques principales de mise en cache utilisées par le WLC ici. Cette sortie de débogage est également réduite afin d'afficher seulement 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 les WLC (pour tous les aps gérés) cachent l'un PMK d'origine de l'association sécurisée qui est au commencement établie. Fondamentalement, chaque fois que le client sans fil se connecte à une particularité AP, un PMKID est haché a basé en fonction : l'adresse MAC de client, l'adresse MAC AP (BSSID du WLAN), et le PMK ont dérivé avec cet AP. Par conséquent, puisqu'OKC cache le même original PMK pour tous les aps et le client spécifique, quand ce client (au sujet de) s'associe à un autre AP, la seule valeur que les modifications afin de hacher le nouveau PMKID est la nouvelle adresse MAC AP.
Quand le client initie l'itinérance à nouvel AP et envoie la trame de demande de rassociation, elle ajoute le PMKID sur l'élément d'information WPA2 RSN si elle veut informer AP qu'un PMK caché est utilisé pour l'itinérance rapide-sécurisée ; pendant qu'il connaît déjà l'adresse MAC du BSSID (AP) pour où il erre, puis le client hache simplement le nouveau PMKID qui est utilisé sur cette demande de rassociation. Quand AP reçoit cette demande du client, il hache également le PMKID avec les valeurs qu'il a déjà (le PMK caché, l'adresse MAC de client, et sa propre adresse MAC AP), et répond avec la réponse réussie de rassociation qui confirme le PMKIDs a apparié. Le PMK caché peut être utilisé comme graine qui commence une prise de contact WPA2 4-Way afin de dériver les nouvelles clés de chiffrement (ignorant l'EAP) :
Dans cette capture, la trame de demande de rassociation du client est sélectionnée et développée de sorte que vous puissiez voir plus de détails de la trame. Les informations d'adresse MAC et également l'élément d'information du réseau de sécurité robuste (RSN, selon 802.11i – WPA2), où des informations sur les configurations WPA2 utilisées pour cette association sont affichées (mis en valeur sont le PMKID obtenu de la formule hachée).
Voici un résumé de WLC met au point pour cette méthode rapide-sécurisée d'itinérance 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 affiché au début du met au point, le PMKID doit être calculé après que la demande de rassociation du client soit reçue. C'est nécessaire afin de valider le PMKID et le confirmer que le PMK caché est utilisé avec la prise de contact WPA2 4-Way pour dériver les clés de chiffrement et pour terminer l'itinérance rapide-sécurisée. Ne confondez pas les entrées CCKM sur met au point ; ceci n'est pas utilisé afin d'exécuter CCKM, mais OKC, comme précédemment expliqué. CCKM ici est simplement un nom utilisé par le WLC pour ces sorties, telles que le nom d'une fonction qui manipule les valeurs afin de calculer le PMKID.
FlexConnect avec le Key Caching opportuniste
- L'authentification centrale est prise en charge. Ceci inclut le commutateur de données local et central. Si AP fait partie du même groupe de FlexConnect, rapide-sécurisé errez est par AP, autrement rapide-sécurisé errent est par le contrôleur.
- L'authentification locale de flexible est prise en charge. En mode connecté, le cache sera distribué d'AP au contrôleur et puis au reste des aps dans le groupe de FlexConnect.
- Le mode autonome est pris en charge. Si le cache est déjà présent sur AP (dû à la distribution précédente), rapide-sécurisé errez fonctionnera. La nouvelle authentification en mode autonome ne prend en charge pas l'itinérance rapide-sécurisée.
Avantages avec le Key Caching opportuniste
- Le client sans fil et l'infrastructure WLAN n'ont pas besoin de se souvenir plusieurs PMKIDs, mais cachent simplement l'un PMK d'origine de l'authentification initiale au WLAN. Alors vous devez réchauffé le PMKID approprié (utilisé sur la demande de rassociation) prié avec chaque association sécurisée AP afin de valider l'itinérance rapide-sécurisée.
- Ici, le client sans fil exécute l'itinérance rapide-sécurisée à nouvel AP sur le même WLAN/SSID, même si il n'a jamais associé avec cet AP (pas le cas dans SKC). Tant que le client exécute l'authentification de l'initiale 802.1X/EAP avec un AP géré par le déploiement centralisé qui manipule le cache PMK pour tous les aps pour où le client erre, puis plus de pleines authentifications ne sont exigées pour le reste de la vie de client sur ce WLAN.
Inconvénients avec le Key Caching opportuniste
- Cette méthode est seulement déployée sur un environnement centralisé où tous les aps sont sous un certain tri du contrôle administratif (tel qu'un contrôleur WLAN) qui est responsable de cacher et de partager l'un PMK d'origine de la session de client. Par conséquent, c'est une limite sur les environnements autonomes AP.
- Les techniques qui sont appliquées dans cette méthode ne sont pas suggérées ou sont décrites sur la norme de 802.11, ainsi le support varie considérablement d'un périphérique à l'autre. Néanmoins, c'est toujours la méthode qui était plus adoptée tout en attendant 802.11r.
Note au sujet du terme « Key Caching proactif »
Le Key Caching proactif (ou les PKC) a été connu comme OKC (Key Caching opportuniste), et deux termes ont été utilisés l'un pour l'autre en décrivant la même méthode expliquée ici. Cependant, c'était juste un terme qui a été utilisé par cubage en 2001 pour une vieille méthode principale de mise en cache, qui a été alors utilisée par la norme 802.11i comme base pour le « Préauthentification » (une autre méthode sécurisée rapide d'itinérance brièvement expliquée ci-dessous). PKC n'est pas Préauthentification ou OKC (Key Caching opportuniste), mais quand vous entendez ou avez connaissance de PKC, la référence est fondamentalement à OKC, et pas au Préauthentification.
Itinérance Rapide-sécurisée avec le Préauthentification
Cette méthode est également suggérée par la norme d'IEEE 802.11 dans l'amendement de la Sécurité 802.11i, ainsi cela fonctionne également avec le WPA2, mais il est le seul jeûnent la méthode sécurisée d'itinérance qui n'est pas prise en charge par des infrastructures de WLAN Cisco. Pour cette raison, il est expliqué seulement brièvement ici et sans sorties.
Avec le Préauthentification, les clients sans fil peuvent authentifier avec le multiple aps à la fois tandis qu'associés avec le courant AP. Quand ceci se produit, le client envoie les trames d'authentification EAP au courant AP où il est connecté, mais il est destiné à l'autre AP où le client veut exécuter le Préauthentification (voisin aps qui sont les candidats possibles pour errer). Le courant AP envoie ces trames à la cible AP au-dessus du système de distribution. Nouvel AP exécute la pleine authentification contre le serveur de RADIUS pour ce client, ainsi une nouvelle prise de contact entière d'authentification EAP est terminée, et ce nouvel AP agit en tant qu'authentificateur.
L'idée est d'exécuter l'authentification et de dériver PMK avec le voisin aps avant que le client erre réellement à eux, ainsi quand il est temps d'errer, le client est déjà authentifié et avec un PMK déjà caché pour cette association sécurisée de nouveau AP-à-client, ainsi ils doivent seulement exécuter la prise de contact 4-Way et éprouver un rapide errez après que le client envoie sa demande initiale de rassociation.
Voici une capture de la balise d'AP qui affiche le champ IE RSN qui annonce le support pour le Préauthentification (celui-ci est de Cisco AP, où on le confirme que le Préauthentification n'est pas pris en charge) :
Avantages avec le Préauthentification
Il y a un PMK pour chaque association sécurisée d'AP-à-client, qui pourrait être considérée un avantage en matière de sécurité au cas où AP serait compromis et les clés deviennent dérobées (ne peut pas être utilisé avec d'autres aps). Cependant, cet avantage en matière de sécurité est manipulé par l'infrastructure WLAN dans différentes manières sur d'autres méthodes.
Inconvénients avec le Préauthentification
- Puisqu'il y a un PMK par AP, les clients ont une limite sur la quantité d'aps qui peuvent pré-être authentifiés.
- Chaque fois qu'un client exécute le Préauthentification avec nouvel AP, il y a un échange complet d'authentification EAP, qui signifie plus de chargement sur le réseau et sur le serveur d'authentification.
- La plupart des clients sans fil ne prennent en charge pas cette méthode, comme ceci jamais a été fortement adopté (OKC était plus adopté).
Itinérance Rapide-sécurisée avec 802.11r
La technique rapide-sécurisée d'itinérance basée sur l'amendement 802.11r (officiellement nommé transition rapide BSS par la norme de 802.11, et connu sous le nom de pi) est la première méthode officiellement ratifiée (2008) par l'IEEE pour la norme de 802.11 car la solution pour exécuter des transitions rapides entre les aps (des ensembles des services de base ou les BSS), qui définit clairement la hiérarchie principale qui est utilisée quand vous manipulez et cachez des clés sur un WLAN. Cependant, son adoption a été lente, principalement en raison des autres solutions déjà disponibles quand des transitions rapides ont été exigées réellement, comme avec des réalisations VoWLAN une fois utilisée avec une des méthodes précédemment expliquées dans ce document. Il y a seulement quelques périphériques qui prennent en charge actuellement certaines des options pi (par 2013).
Cette technique est plus complexe pour expliquer que les autres méthodes, pendant qu'elle introduit de nouveaux concepts et plusieurs couches de PMKs qui sont cachées sur les différents périphériques (chaque périphérique avec un rôle différent), et fournit bien plus d'options pour l'itinérance rapide-sécurisée. Par conséquent, un résumé rapide est fourni au sujet de cette méthode et de la manière qu'elle est mise en application avec chaque option disponible.
802.11r est différent de SKC et d'OKC, principalement pour ces raisons :
- La Messagerie de prise de contact (échange PMKID, d'ANonce, et de SNonce, par exemple) se produit dans des trames d'authentification de 802.11 ou dans des vidéotex au lieu des trames de rassociation. À la différence des méthodes de mise en cache PMKID, la phase distincte de la prise de contact 4-Way, qui est portée après que (au sujet de) l'échange de message d'association, est évitée. La prise de contact principale avec nouvel AP commence avant que le client entièrement erre/rassocie à ce nouvel AP.
- Il fournit deux méthodes pour la prise de contact de rapide-itinérance : au-dessus de l'AIR, et au-dessus du système de distribution (DS).
- 802.11r a plus de couches de hiérarchie principale.
- Pendant que ce protocole évite la prise de contact 4-Way pour la gestion des clés quand un client erre (génère de nouvelles clés de chiffrement - PTK et GTK- sans besoin de cette prise de contact), il peut également être appliqué pour les installations WPA2 avec un PSK, et non seulement quand 802.1X/EAP est utilisé pour l'authentification. Ceci accélère errer encore plus pour ces installations, où échange d'EAP ou de prise de contact 4-Way ne se produit pas.
Avec cette méthode, le client sans fil exécute juste une authentification initiale contre l'infrastructure WLAN quand une connexion est établie au premier AP, et exécute l'itinérance rapide-sécurisée tout en errant entre les aps du même domaine de mobilité pi.
C'est l'un des nouveaux concepts, qui se rapporte fondamentalement aux aps qui utilisent le même SSID (connu sous le nom de service étendu réglé ou éventail de services étendus) et manipulent les mêmes clés pi. C'est semblable aux autres méthodes expliquées jusqu'ici. La manière que les aps manipulent les clés de domaine de mobilité pi est normalement basée sur une installation centralisée, telle que le WLC ou les Groupes de mobilité ; cependant, cette méthode peut également être appliquée sur les environnements autonomes AP.
Voici un résumé de la hiérarchie principale :
- Un MSK est encore dérivé sur le suppliant de client et le serveur d'authentification de la phase d'authentification de l'initiale 802.1X/EAP (transférée du serveur d'authentification vers l'authentificateur (WLC) une fois que l'authentification est réussie). Ce MSK, comme dans les autres méthodes, est utilisé comme graine pour la hiérarchie de clé pi. Quand vous utilisez WPA2-PSK au lieu d'une méthode d'authentification EAP, le PSK est fondamentalement ce MSK.
- Un R0 de Pairwise Master Key (PMK-R0) est dérivé du MSK, qui est la clé de premier niveau de la hiérarchie de clé pi. Les titulaires principaux pour ce PMK-R0 sont les WLC et le client.
- Une clé de second niveau, appelée un Pairwise Master Key R1 (PMK-R1), est dérivée du PMK-R0, et les titulaires principaux sont le client et les aps gérés par le WLC qui tient le PMK-R0.
- La clé du troisième et final niveau de la hiérarchie de clé pi est le PTK, qui est la clé finale utilisée afin de chiffrer les trames de données d'unicast de 802.11 (semblables aux autres méthodes qui utilisent WPA/TKIP ou WPA2/AES). Ce PTK est dérivé sur le pi du PMK-R1, et les titulaires principaux sont le client et les aps gérés par le WLC.
Transition rapide BSS au-dessus de - Air
Avec cette méthode, la première association à n'importe quel AP est une authentification pour la première fois régulière au WLAN, où l'authentification 802.1X/EAP entière contre le serveur d'authentification et la prise de contact 4-Way pour la génération de clés doit se produire avant que des trames de données soient envoyées, suivant les indications de cette capture d'écran :
Les principales différences sont :
- La négociation de gestion des clés d'authentification est légèrement différente que le militaire de carrière WPA/WPA2, ainsi quelques informations supplémentaires sont utilisées afin d'exécuter cette négociation quand l'association à une infrastructure WLAN qui prend en charge le pi se produit. Suivant les indications de la capture, la trame de demande d'association du client est sélectionnée et le champ AKM de l'élément d'information de RNS est mis en valeur afin de prouver que ce client veut exécuter le pi au-dessus de 802.1X/EAP.
- Également affiché est l'élément d'information de domaines de mobilité (une partie de pi), où la capacité pi et champ de stratégie indique si la transition rapide BSS est terminée au-dessus - aérez ou au-dessus du - du DS quand itinérance rapide (indiquant au-dessus du - aérez dans cette capture).
- Un autre élément d'information est également ajouté (l'IE rapide de transition ou pi BSS, qui est décrit plus tard dans ce document) avec les informations qui sont exigées afin d'exécuter l'ordre d'authentification pi quand itinérance pi.
- La génération de clés est différent due à la hiérarchie principale, ainsi quoique la prise de contact pi 4-Way semble semblable à la prise de contact WPA/WPA2 4-Way, elle est réellement légèrement différente dans le contenu.
Met au point l'exposition fondamentalement le même échange de trame d'authentification EAP que le reste des méthodes sur l'authentification initiale au WLAN (comme noté des captures), mais quelques sorties qui concernent les techniques principales de mise en cache utilisées par le WLC sont ajoutées ; ainsi, cette sortie de débogage est réduite afin d'afficher seulement 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.
Être les captures et voici met au point d'une première association au WLAN quand vous exécutez le pi avec WPA2-PSK (au lieu d'une méthode 802.1X/EAP), où la trame de réponse d'association d'AP est sélectionnée afin d'afficher l'élément d'information rapide de transition BSS (mis en valeur). Une partie de l'information principale requise afin d'exécuter la prise de contact pi 4-Way est également affichée :
*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 802.11r, l'association initiale au WLAN est la base utilisée afin de dériver les clés de base utilisées par cette technique, juste comme dans les autres méthodes rapide-sécurisées d'itinérance. Les principales différences été livré quand le client commence à errer ; Le pi évite non seulement 802.1X/EAP quand ceci est utilisé, mais il exécute réellement une méthode plus efficace d'itinérance qui combine les trames initiales d'authentification Système ouvert et de rassociation de 802.11 (qui sont toujours utilisées et exigées en errant entre les aps) afin de permuter les informations pi et dériver de nouvelles clés de chiffrement dynamique au lieu de la prise de contact 4-Way.
La prochaine capture affiche les trames permutées quand une transition rapide BSS au-dessus de - de l'air avec la Sécurité 802.1X/EAP est exécuté. La trame d'authentification Système ouvert du client à AP est sélectionnée afin de voir les éléments d'information de protocole pi qui sont exigés pour commencer la négociation de clé pi. Ceci est utilisé afin de dériver le nouveau PTK avec nouvel AP (basé sur le PMK-R1). Le champ qui affiche l'algorithme d'authentification est mis en valeur afin de prouver que ce client n'exécute pas une authentification Système ouvert simple, mais une transition rapide BSS :
Voici les sorties de débogage du WLC quand cet événement d'itinérance pi 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 affiche une transition rapide BSS au-dessus de - aèrent avec la Sécurité WPA2-PSK, où la trame de réponse finale de rassociation d'AP au client est sélectionnée afin d'afficher plus de détails au sujet de cet échange pi :
Voici les sorties de débogage quand cet événement d'itinérance pi se produit avec PSK, qui sont semblables à ceux quand 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
Suivant les indications de la capture, une fois la transition rapide BSS est négociée sur l'association initiale au WLAN, les quatre trames qui sont utilisées et requis pour errer (authentification Système ouvert du client, authentification Système ouvert d'AP, demande de rassociation, et réponse de rassociation) sont fondamentalement utilisés pendant qu'une prise de contact pi 4-Way afin de dériver le nouveau PTK (clé de chiffrement d'unicast) et GTK (clé de chiffrement de Multidiffusion/émission).
Ceci remplace la prise de contact 4-Way qui se produit normalement après que ces trames soient permutées, et la négociation de contenu et de clé pi sur ces trames est fondamentalement identique si vous utilisez 802.1X/EAP ou PSK comme méthode de Sécurité. Suivant les indications de la capture, le champ AKM est la principale différence, qui confirme si le client exécute le pi avec PSK ou 802.1X. Par conséquent, il est important de noter que ces quatre trames normalement n'ont pas ce type d'informations relatives à la sécurité pour la négociation principale, mais seulement quand le client pi erre si 802.11r est mis en application et négocié entre le client et l'infrastructure WLAN sur l'association initiale.
Transition rapide BSS au-dessus de - DS
802.11r permet une autre implémentation de transition Fast BSS, où l'itinérance pi est initiée par le client avec nouvel AP pour lequel le client erre au-dessus - DS (système de distribution), et pas au-dessus de - de l'air. Dans ce cas, des vidéotex pi sont utilisés afin d'entamer la négociation principale au lieu des trames d'authentification Système ouvert.
Fondamentalement, une fois que le client décide il pourrait errer à meilleur AP, le client envoie une trame de demande d'intervention pi à l'original AP où il est actuellement connecté avant d'errer. Le client indique que le BSSID (adresse MAC) de la cible AP où elle veut au pi errez. L'original AP en avant cette trame de demande d'intervention pi à la cible AP au-dessus du système de distribution (normalement l'infrastructure câblée), et la cible AP répond au client avec une trame de réponse d'action pi (aussi au-dessus du DS, ainsi de lui peut finalement l'envoyer au-dessus du - aérez au client). Une fois que cet échange de vidéotex pi est réussi, le client termine l'itinérance pi ; le client envoie la demande de rassociation à la cible AP (cette fois au-dessus - de l'air), et reçoit une réponse de rassociation de nouvel AP afin de confirmer l'itinérance et la dérivation de clés de finale.
En résumé, il y a quatre trames pour négocier la transition rapide BSS et pour dériver de nouvelles clés de chiffrement, mais ici les trames d'authentification Système ouvert sont substituées avec les trames de demande/réponse d'action pi, qui sont permutées avec la cible AP au-dessus du système de distribution avec le courant AP. Cette méthode est également valide pour les méthodes 802.1X/EAP de Sécurité et le PSK, tout pris en charge par les contrôleurs LAN de radio de Cisco ; cependant, depuis ceci au-dessus du - La transition DS n'est pas prise en charge et mis en application par la plupart des clients sans fil dans le secteur de WiFi (et puisque l'échange et les sorties de débogage de trame sont fondamentalement identique), des exemples ne sont pas fournis dans ce document. Au lieu de cela, cette image est utilisée afin de visualiser la transition rapide BSS au-dessus - du DS :
FlexConnect avec 802.11r
- L'authentification centrale est prise en charge. Ceci inclut le commutateur de données local et central. Les aps doivent faire partie du même groupe de 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 le premier ce des utilisations une hiérarchie principale bien définie par l'IEEE sur la norme de 802.11 comme amendement (802.11r), ainsi l'implémentation de ces techniques pi sont plus compatible entre les constructeurs et sans différentes traductions.
- 802.11r permet les plusieurs techniques qui sont utiles, dépendantes de vos besoins (au-dessus - aérez et au-dessus du - du DS, pour Sécurité 802.1x/EAP et pour la Sécurité PSK).
- Le client sans fil exécute l'itinérance rapide-sécurisée à nouvel AP sur le même WLAN/SSID, même si il n'a jamais associé avec cet AP, et sans nécessité de sauvegarder plusieurs PMKIDs.
- C'est la première méthode rapide-sécurisée d'itinérance qui permet une itinérance plus rapide même avec la Sécurité PSK, et évite la prise de contact 4-Way qui est exigée en errant entre les aps avec WPA/WPA2 PSK. Le but principal des méthodes rapide-sécurisées d'itinérance est d'éviter la prise de contact 802.1X/EAP quand cette méthode de Sécurité est appliquée ; cependant, parce que Sécurité PSK l'événement d'itinérance est accéléré bien plus avec 802.11r en évitant la prise de contact 4-Way.
Inconvénients avec 802.11r
- Il y a quelques périphériques de client sans fil qui prennent en charge réellement des transitions rapides BSS, et dans la plupart des cas, elles ne prennent en charge pas toutes les techniques disponibles sur 802.11r.
- En raison du fait que ces réalisations sont très jeunes, il n'y a pas assez de résultats de test des environnements de vrai-production ou assez mettent au point des résultats afin d'adresser les mises en garde possibles qui pourraient apparaître.
- Quand vous configurez un WLAN/SSID afin d'utiliser des méthodes l'unes des pi, alors seulement les clients sans fil qui prennent en charge 802.11r peuvent se connecter à ce WLAN/SSID. Les configurations pi ne sont pas facultatives pour les clients, ainsi ces clients sans fil qui ne prennent en charge pas 802.11r doivent se connecter à un WLAN/SSID distinct où le pi n'est pas configuré du tout.
Adaptatif 802.11r
- Quelques clients existants ne peuvent pas s'associer avec un WLAN/SSID qui a 802.11r activé même pour le « mode mixte » (que vous espérez que vous pouvez avoir sur les mêmes clients SSID qui les prennent en charge et qui ne prennent en charge pas 802.11r). C'est quand le gestionnaire du suppliant de client qui est responsable d'analyser l'élément d'information réseau de sécurité robuste (IE RSN) se rend vieux et non compte des suites supplémentaires AKM dans l'IE. En raison de cette limite, les clients ne peuvent pas envoyer des demandes d'association aux WLAN qui annoncent le support 802.11r, et 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 en charge pas 802.11r.
-
Afin de surmonter ceci, l'infrastructure LAN Sans fil de Cisco a introduit la caractéristique de l'adaptatif 802.11r. Quand le mode pi est placé à l'adaptatif au niveau WLAN, le WLAN annonce l'ID de domaine de la mobilité 802.11r sur un 802.11i-enabled WLAN. Quelques périphériques de client d'Apple iOS10 identifient la présence de MDIE sur un 80211i/WPA2 WLAN et font une prise de contact de propriété industrielle afin d'établir l'association 802.11r. Une fois que le client se termine l'association 802.11r réussie, il pourra faire l'itinérance pi comme dans un WLAN activé par 802.11r normal. L'adaptatif pi est seulement les périphériques sélectionnés applicables d'Apple iOS10 (et plus tard). Tous autres clients continueront à avoir l'association 802.11i/WPA2 sur le WLAN, et exécutent la méthode applicable FSR comme prise en charge.
-
Plus de documentation au sujet de cette nouvelle fonctionnalité introduite pour que les périphériques iOS10 exécutent 802.11r sur un WLAN/SSID où 802.11r n'est pas vraiment activé (ainsi d'autres clients non-802.11r se connecteront avec succès), peut être trouvée dans des pratiques recommandées d'entreprise pour des périphériques IOS sur le RÉSEAU LOCAL de radio de Cisco.
Conclusions
- Maintenez dans l'esprit que le client est toujours celui qui décide d'errer à une particularité AP, 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 le considère erre.
- Le WLC prend en charge une combinaison des la plupart ou toutes les méthodes FSR (itinérance Rapide-sécurisée) ensemble sur le même WLAN/SSID. Cependant, rendez-vous compte que ceci normalement ne fonctionne pas, car il dépend fortement du comportement de client (très différent à travers différents périphériques mobiles) afin de prendre en charge ou même comprendre cela que le WLC tente d'annoncer comme pris en charge. Au lieu de réaliser l'Interopérabilité dans juste un SSID, il y a normalement plus de questions que celles qui sont attendues pour être réparées, ainsi ceci n'est pas recommandé. Le test profond avec tous les clients possibles à utiliser sur ce WLAN devrait être terminé si c'est vraiment nécessaire.
- Il est très important de comprendre que des méthodes rapide-sécurisées d'itinérance sont développées afin d'accélérer le processus d'itinérance WLAN quand vous vous déplacez entre les aps si le WLAN/SSID a la sécurité activée. Quand aucune Sécurité n'est en place, il n'y a rien à accélérer, car client-AP permute simplement les trames Sans fil de Gestion qui sont toujours exigées en errant entre les aps avant que des trames de données soient envoyées (authentification Système ouvert du client, authentification Système ouvert d'AP, demande de rassociation, et réponse de rassociation). Par conséquent, ceci ne peut pas déplacer plus rapide. Si vous rencontrez des questions d'itinérance sans Sécurité, alors il n'y a aucune méthode de rapide-itinérance pour améliorer l'itinérance, seulement des méthodes afin de confirmer s'il est appropriée pour que les stations de client sans fil errent l'installation et la conception WLAN/SSID en conséquence entre les cellules de couverture AP.
- 802.11r/FT est mis en application avec WPA2-PSK afin d'accélérer des événements d'itinérance avec cette Sécurité en évitant la prise de contact 4-Way, comme expliqué dans la section 802.11r.
- Toutes les méthodes ont leurs avantages et inconvénients, mais à la fin, vous devez toujours vérifier si les stations de client sans fil prennent en charge la méthode spécifique que vous voulez appliquer, et si l'infrastructure de WLAN Cisco prend en charge toutes les méthodes disponibles. Ainsi, vous devez sélectionner la meilleure méthode qui est prise en charge réellement par les clients sans fil qui se connectent à la particularité WLAN/SSID. Par exemple, dans quelques déploiements vous pourriez créer un WLAN/SSID avec CCKM pour les Téléphones IP Sans fil de Cisco (qui prenez en charge WPA2/AES avec CCKM, mais pas 802.11r), et puis un WLAN/SSID différent avec WPA2/AES par l'intermédiaire de 802.11r/FT pour les clients sans fil qui prennent en charge cette méthode sécurisée rapide d'itinérance (ou utilisez OKC, si c'est ce qui est pris en charge).
- Si les clients sans fil ne prennent en charge pas des méthodes rapide-sécurisées l'unes des d'itinérance disponibles, alors vous pourriez devoir recevoir le fait que ces clients expérimenteront toujours les retards expliqués dans ce document quand errant entre les aps sur un WLAN/SSID avec la Sécurité 802.1X/EAP (qui peut entraîner des interruptions sur les app de client/services).
- Toutes les méthodes, excepté SKC (mise en cache WPA2 PMKID), sont prises en charge pour l'itinérance rapide-sécurisée entre les aps gérés par WLCs différent (itinérance d'intercontroller), tant que elles sont sur le même groupe de mobilité.
- CUWN approuve pleinement toutes les différentes méthodes Rapide-sécurisées d'itinérance couvertes en cet article en utilisant l'authentification 802.1X/EAP pour WPA/WPA2. CUWN ne prend en charge pas l'itinérance Rapide-sécurisée sur les méthodes qui fonctionnent avec WPA2-RSN (CCKM, PMKID Caching/SKC, OKC/PKC) en utilisant PSK (WPA2-Personal), où les méthodes de Rapide-itinérance ne sont en grande partie pas nécessaires. Cependant, CUWN prend en charge l'itinérance Rapide-sécurisée dans le cas de WPA2-FT (802.11r) avec PSK comme également expliqué en cet article.
Informations connexes
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)