Roaming de WLAN 802.11 e roaming rápido no CUWN
Contents
Introduction
Este documento descreve os diferentes tipos de roaming sem fio e os métodos de roaming rápido seguros disponíveis para LANs sem fio (WLANs) IEEE 802.11 suportadas na Cisco Unified Wireless Network (CUWN).
O documento não fornece todas as especificações sobre como cada método funciona ou como ele é configurado. O objetivo principal deste documento é descrever as diferenças entre as várias técnicas disponíveis, suas vantagens e limitações e a troca de quadros em cada método. São fornecidos exemplos de depurações de WLAN Controller (WLC) e são usadas capturas de pacotes sem fio para analisar e explicar os eventos que ocorrem para cada método de roaming descrito.
Prerequisites
Requirements
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Fundamentos de WLAN IEEE 802.11
- Segurança de WLAN IEEE 802.11
- Conceitos básicos do IEEE 802.1X/EAP
Componentes Utilizados
As informações neste documento são baseadas no software Cisco WLAN Controller versão 7.4, mas a maioria das saídas e comportamentos de depuração descritos podem se aplicar a qualquer versão de software que suporte os métodos discutidos. As especificações de todos os métodos explicados aqui permanecem as mesmas nos códigos posteriores da Cisco WLAN Controller (até a versão 8.3 no momento em que este artigo foi atualizado).
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Informações de Apoio
Antes de fornecer uma descrição dos diferentes métodos de roaming seguro rápido disponíveis para WLANs, é importante entender como o processo de associação de WLAN funciona e como um evento de roaming regular ocorre quando não há segurança configurada no Service Set Identifier (SSID).
Quando um cliente sem fio 802.11 se conecta a um ponto de acesso (AP), antes de começar a passar o tráfego (quadros de dados sem fio), ele primeiro deve passar pelo processo básico de autenticação de Sistema aberto 802.11. Em seguida, o processo de associação deve ser concluído. Pense no processo de autenticação Open System como "conectando o cabo" no AP selecionado pelo cliente. Isso é muito importante de entender, pois é sempre o cliente sem fio que seleciona qual AP é preferido e baseia a decisão em vários fatores que variam entre os fornecedores. É por isso que o cliente inicia esse processo enviando o quadro de autenticação para o AP selecionado, como mostrado mais adiante neste documento. O AP não pode solicitar que você estabeleça uma conexão.
Quando o processo de autenticação do Sistema Aberto é concluído com êxito com uma resposta do AP ("cabo conectado"), o processo de associação essencialmente termina a negociação da Camada 2 (L2) 802.11 que estabelece o link entre o cliente e o AP. O AP atribui um ID de associação ao cliente se a conexão for bem-sucedida e o prepara para transmitir tráfego ou executar um método de segurança de nível superior se configurado no SSID. O processo de autenticação do Sistema Aberto consiste em dois quadros de gerenciamento, bem como no processo de associação. Os quadros de autenticação e associação são quadros de gerenciamento sem fio, não quadros de dados, que são basicamente os usados para o processo de conexão com o AP.
Aqui está uma captura dos quadros sem fio no ar para este processo:
O cliente sem fio começa com o quadro de autenticação e o AP responde com outro quadro de autenticação. O cliente envia o quadro de Solicitação de Associação e o AP termina em uma resposta com o quadro Resposta de Associação. Como mostrado nos pacotes DHCP, quando os processos de autenticação e associação do Open System 802.11 são passados, o cliente começa a passar quadros de dados. Nesse caso, não há nenhum método de segurança configurado no SSID, portanto, o cliente começa imediatamente a enviar quadros de dados (nesse caso, DHCP) que não estão criptografados.
Como mostrado mais adiante neste documento, se a segurança estiver habilitada no SSID, há quadros de autenticação e handshake de criptografia de nível mais alto para o método de segurança específico, logo após a Resposta da associação e antes de enviar qualquer quadro de dados de tráfego do cliente, como DHCP, Protocolo de Resolução de Endereços (ARP), e pacotes de aplicativos, que são criptografados. Os quadros de dados só podem ser enviados até que o cliente seja totalmente autenticado e as chaves de criptografia sejam negociadas, com base no método de segurança configurado.
Com base na captura anterior, aqui estão as mensagens que você vê nas saídas do comando WLC debug client quando o cliente sem fio inicia uma nova associação à 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.
Essas mensagens mostram os quadros de Solicitação de Associação e Resposta; os quadros de autenticação inicial não são registrados na WLC porque esse handshake acontece rapidamente no nível de AP no CUWN.
Que informações aparecem quando o cliente faz roaming? O cliente sempre troca quatro quadros de gerenciamento ao estabelecer uma conexão com um AP, devido ao estabelecimento de associação do cliente ou a um evento de roaming. O cliente tem apenas uma conexão estabelecida para apenas um AP por vez. A única diferença na troca de quadros entre uma nova conexão com a infraestrutura da WLAN e um evento de roaming é que os quadros da Associação de um evento de roaming são chamados quadros de reassociação, que indicam que o cliente está realmente em roaming de outro AP sem tentativas de estabelecer uma nova associação à WLAN. Esses quadros podem conter diferentes elementos usados para negociar o evento de roaming; isso depende da configuração, mas esses detalhes estão fora do escopo deste documento.
Aqui está um exemplo da troca de quadros:
Essas mensagens aparecem na saída de depuração:
*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.
Como mostrado, o cliente executa com êxito um evento de roaming depois que a Solicitação de reassociação ao novo AP é enviada e recebe a Resposta de reassociação do AP. Como o cliente já tem um endereço IP, os primeiros quadros de dados são para pacotes ARP.
Se você espera um evento de roaming, mas o cliente envia uma Solicitação de Associação em vez de uma Solicitação de Reassociação (que você pode confirmar de algumas capturas e depurações semelhantes às explicadas anteriormente neste documento), o cliente não está realmente em roaming. O cliente inicia uma nova associação à WLAN como se tivesse ocorrido uma desconexão e tenta se reconectar do zero. Isso pode acontecer por vários motivos, como quando um cliente sai das áreas de cobertura e encontra um AP com qualidade de sinal suficiente para iniciar uma associação, mas normalmente indica um problema de cliente em que o cliente não inicia um evento de roaming devido a problemas de drivers, firmware ou software.
Roaming com segurança de alto nível
Quando o SSID é configurado com segurança de nível superior L2 sobre a autenticação básica do sistema aberto 802.11, mais quadros são necessários para a associação inicial e para o roaming. Os dois métodos de segurança mais comuns padronizados e implementados para WLANs 802.11 são descritos neste documento:
- WPA/WPA2-PSK (Pre-Shared Key) - autenticação de clientes com uma chave pré-compartilhada.
- WPA/WPA2-EAP (Extensible Authentication Protocol) - autenticação de clientes com um método 802.1X/EAP para validar credenciais mais seguras através do uso de um Authentication Server, como certificados, nome de usuário e senha e tokens.
É importante saber que, embora esses dois métodos (PSK e EAP) autentiquem/validem os clientes de maneiras diferentes, ambos usam basicamente as mesmas regras WPA/WPA2 para o processo de gerenciamento de chaves. Quer a segurança seja WPA/WPA2-PSK ou WPA/WPA2-EAP, o processo conhecido como handshake 4-Way WPA/WPA2 inicia a negociação de chave entre a WLC/AP e o cliente com uma chave de sessão mestre (MSK) como o material de chave original quando o cliente é validado com o método de autenticação específico usado.
Aqui está um resumo do processo:
- Uma MSK é derivada da fase de autenticação EAP quando a segurança 802.1X/EAP é usada ou da PSK quando WPA/WPA2-PSK é usada como método de segurança.
- A partir dessa MSK, o cliente e a WLC/AP derivam a PMK (Pairwise Master Key) e a WLC/AP gera uma GMK (Group Master Key).
- Quando essas duas chaves mestras estiverem prontas, o cliente e o WLC/AP iniciam o handshake 4-Way WPA/WPA2 (ilustrado posteriormente neste documento com algumas capturas de tela e depurações) com as chaves mestras como sementes para negociação das chaves de criptografia reais.
- Essas chaves de criptografia finais são conhecidas como Pairwise Transient Key (PTK) e Group Transient Key (GTK). O PTK é derivado do PMK e usado para criptografar quadros unicast com o cliente. A chave transiente de grupo (GTK) é derivada da GMK e é usada para criptografar multicast/broadcast neste SSID/AP específico.
WPA/WPA2-PSK
Quando a WPA-PSK ou WPA2-PSK é executada através do Temporal Key Integrity Protocol (TKIP) ou do Advanced Encryption Standard (AES) para a encriptação, o cliente tem de passar pelo processo conhecido como handshake WPA de 4 vias, tanto para a associação inicial como para o roaming. Como explicado anteriormente, esse é basicamente o processo de gerenciamento principal usado para que a WPA/WPA2 derive as chaves de criptografia. No entanto, quando a PSK é executada, ela também é usada para verificar se o cliente tem uma chave pré-compartilhada válida para ingressar na WLAN. Esta captura mostra o processo de associação inicial quando WPA ou WPA2 com PSK é executado:
Como mostrado, após o processo de autenticação e associação do Open System 802.11, há quatro quadros EAPOL do handshake 4-Way da WPA, que são iniciados pelo AP com a mensagem 1, e concluídos pelo cliente com a mensagem 4. Após um handshake bem-sucedido, o cliente começa a passar quadros de dados (como o DHCP), que nesse caso são criptografados com as chaves derivadas do handshake de 4 vias (é por isso que você não pode ver o conteúdo real e o tipo de tráfego das capturas sem fio).
Essas mensagens aparecem nas saídas de depuração:
*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.
Quando em roaming, o cliente segue basicamente a mesma troca de quadros, onde o handshake 4-Way da WPA é necessário para derivar novas chaves de criptografia com o novo AP. Isso se deve a razões de segurança estabelecidas pelo padrão e ao fato de que o novo AP não conhece as chaves originais. A única diferença é que há quadros de Reassociação em vez de quadros de Associação, como mostrado nesta captura:
Você vê as mesmas mensagens nas saídas de depuração, mas o primeiro pacote do cliente é uma Reassociação em vez de uma Associação, como mostrado e explicado anteriormente.
WPA/WPA2-EAP
Quando um método 802.1X/EAP é usado para autenticar os clientes em um SSID seguro, há ainda mais quadros necessários antes que o cliente comece a passar tráfego. Esses quadros extras são usados para autenticar as credenciais do cliente, e dependendo do método EAP, pode haver entre quatro e vinte quadros. Eles vêm após a Associação/Reassociação, mas antes do handshake 4-Way da WPA/WPA2, porque a fase de autenticação deriva a MSK usada como semente para a geração final da chave de criptografia no processo de gerenciamento de chaves (handshake 4-Way).
Esta captura sem fio mostra um exemplo dos quadros trocados pelo ar entre o AP e o cliente sem fio quando a associação inicial de WPA com PEAPv0/EAP-MSCHAPv2 é executada:
Às vezes, essa troca mostra mais ou menos quadros, o que depende de vários fatores, como o método EAP, retransmissões devido a problemas, comportamento do cliente (como as duas Solicitações de Identidade neste exemplo, porque o cliente envia um EAPOL START após o AP enviar a primeira Solicitação de Identidade) ou se o cliente já trocou o certificado com o servidor. Sempre que o SSID é configurado para um método 802.1X/EAP, há mais quadros (para a autenticação) e, portanto, requer mais tempo para que o cliente comece a enviar quadros de dados.
Aqui está um resumo das mensagens de depuração:
*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.
Quando o cliente sem fio executa um roaming regular aqui (o comportamento normal, sem a implementação de um método de roaming seguro rápido), o cliente deve passar exatamente pelo mesmo processo e executar uma autenticação completa em relação ao Servidor de autenticação, como mostrado nas capturas. A única diferença é que o cliente usa uma Solicitação de Reassociação para informar ao novo AP que ele está realmente em roaming de outro AP, mas o cliente ainda precisa passar pela validação completa e pela nova geração de chave:
Como mostrado, mesmo quando há menos quadros do que na autenticação inicial (que é causada por vários fatores, como mencionado anteriormente), quando o cliente faz roaming para um novo AP, a autenticação EAP e os processos de gerenciamento de chaves WPA ainda devem ser concluídos para continuar a passar quadros de dados (mesmo que o tráfego tenha sido enviado ativamente antes do roaming). Portanto, se o cliente tiver um aplicativo ativo que seja sensível a atrasos (como aplicativos de tráfego de voz ou aplicativos sensíveis a timeouts), o usuário poderá perceber problemas ao roaming, como falhas de áudio ou desconexões de aplicativos. Isso depende do tempo que o processo leva para que o cliente continue a enviar/receber quadros de dados. Esse atraso pode ser maior, dependendo de: o ambiente de RF, a quantidade de clientes, o tempo de ida e volta entre a WLC e os LAPs e com o Servidor de Autenticação e outros motivos.
Aqui está um resumo das mensagens de depuração para este evento de roaming (basicamente as mesmas que as anteriores, portanto essas mensagens não são descritas mais adiante):
*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
É assim que a estrutura de segurança 802.1X/EAP e WPA/WPA2 funcionam. Para evitar o impacto do aplicativo/serviço nos atrasos de um evento de roaming regular, vários métodos de roaming rápidos são desenvolvidos e implementados pela indústria de WiFi para acelerar o processo de roaming quando a segurança é usada na WLAN/SSID. Os clientes enfrentam alguma latência quando continuam a transmitir tráfego enquanto se movimentam entre APs por meio da implantação de segurança de alto nível na WLAN. Isso se deve à autenticação EAP e às trocas de quadros de gerenciamento de chaves exigidas pela configuração de segurança, como explicado anteriormente.
É importante entender que o roaming rápido seguro é apenas o termo usado pelo setor em referência à implementação de um método/esquema que acelera o processo de roaming quando a segurança é configurada na WLAN. Os diferentes métodos/esquemas de roaming de segurança rápida disponíveis para WLANs e suportados pelo CUWN são explicados na próxima seção.
Roaming rápido com CCKM
O Cisco Centralized Key Management (CCKM) é o primeiro método de roaming seguro e rápido desenvolvido e implementado em WLANs corporativas, criado pela Cisco como a solução usada para reduzir os atrasos explicados até agora, quando a segurança 802.1X/EAP é usada na WLAN. Como esse é um protocolo proprietário da Cisco, ele só é suportado por dispositivos de infraestrutura de WLAN da Cisco e clientes sem fio (de vários fornecedores) compatíveis com o Cisco Compatible Extension (CCX) para CCKM.
O CCKM pode ser implementado com todos os diferentes métodos de criptografia disponíveis para WLANs, para incluir: WEP, TKIP e AES. Ele também é suportado com a maioria dos métodos de autenticação 802.1X/EAP usados para WLANs, dependendo da versão CCX suportada pelos dispositivos.
Essa captura sem fio fornece um exemplo dos quadros trocados na associação inicial quando você executa o CCKM com TKIP como criptografia, e PEAPv0/EAP-MSCHAPv2 como o método 802.1X/EAP. Essa é basicamente a mesma troca como se o WPA/TKIP com PEAPv0/EAP-MSCHAPv2 fosse executado, mas desta vez o CCKM entre o cliente e a infraestrutura é negociado para que eles usem diferentes métodos de hierarquia de chaves e cache para executar o Fast Secure Roaming quando o cliente precisar fazer o roaming:
Aqui está um resumo das mensagens de depuração (com algumas trocas EAP removidas para reduzir a saída):
*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.
Com o CCKM, a associação inicial à WLAN é semelhante à WPA/WPA2 normal, em que uma MSK (também conhecida aqui como Network Session Key (NSK)) é mutuamente derivada com o cliente e o servidor RADIUS. Essa chave mestra é enviada do servidor para a WLC após uma autenticação bem-sucedida e é armazenada em cache como base para derivação de todas as chaves subsequentes durante a vida útil da associação do cliente a esta WLAN. A partir daqui, a WLC e o cliente derivam as informações de seed que são usadas para roaming rápido seguro com base no CCKM, passando por um handshake de 4 vias semelhante ao da WPA/WPA2, para derivar as chaves de criptografia unicast (PTK) e multicast/broadcast (GTK) com o primeiro AP.
A grande diferença é percebida quando em roaming. Nesse caso, o cliente CCKM envia um único quadro de Solicitação de Reassociação ao AP/WLC (incluindo um MIC e um Número Aleatório de incremento sequencial) e fornece informações suficientes (incluindo o novo endereço MAC do AP -BSSID-) para derivar o novo PTK. Com essa solicitação de reassociação, a WLC e o novo AP também têm informações suficientes para derivar o novo PTK, portanto eles simplesmente respondem com uma resposta de reassociação. O cliente agora pode continuar a transmitir tráfego, como mostrado nesta captura:
Aqui está um resumo das depurações de WLC para este evento de roaming:
*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.
Como mostrado, o roaming seguro e rápido é executado enquanto evita os quadros de autenticação EAP e mais handshakes de quatro vias, pois as novas chaves de criptografia ainda são derivadas, mas baseadas no esquema de negociação CCKM. Isso é concluído com os quadros de reassociação de roaming e as informações previamente armazenadas em cache pelo cliente e pela WLC.
FlexConnect com CCKM
- A autenticação central é suportada. Isso inclui a troca de dados local e central. Os APs devem fazer parte do mesmo grupo FlexConnect.
- A autenticação local flexível é suportada. No modo conectado, o cache será distribuído do AP para o controlador e, em seguida, para o restante dos APs no grupo FlexConnect.
- O modo autônomo é suportado. Se o cache já estiver presente no AP (devido à distribuição anterior), o roaming rápido funcionará. A nova autenticação no modo autônomo não suporta roaming rápido seguro.
Prós com CCKM
- O CCKM é o método de roaming mais rápido e seguro, implantado principalmente em WLANs corporativas. Os clientes não precisam passar por um handshake de gerenciamento de chaves para derivar novas chaves quando ocorre uma mudança entre os APs e nunca mais precisam executar uma autenticação 802.1X/EAP completa com novos APs durante a vida útil do cliente nesta WLAN.
- O CCKM suporta todos os métodos de criptografia disponíveis no padrão 802.11 (WEP, TKIP e AES), além de alguns métodos proprietários antigos da Cisco ainda usados em clientes antigos.
Cons com CCKM
- O CCKM é um método proprietário da Cisco, que limita a implementação e o suporte à infraestrutura de WLAN da Cisco e aos clientes sem fio CCX.
- O CCX Versão 5 não é amplamente adotado, portanto, o CCKM com WPA2/AES não é suportado por muitos clientes sem fio CCX (principalmente porque a maioria deles já suporta o CCKM com WPA/TKIP, que ainda é muito seguro).
Roaming rápido com cache PMKID / cache de teclas sticky
Cache PMKID (Pairwise Master Key ID, ou Sticky Key Caching (SKC), é o primeiro método de roaming seguro rápido sugerido pelo padrão IEEE 802.11 na alteração de segurança 802.11i, na qual o principal objetivo é padronizar um alto nível de segurança para WLANs. Essa técnica de roaming de segurança rápida foi adicionada como um método opcional para dispositivos WPA2 para melhorar o roaming quando essa segurança foi implementada.
Isso é possível porque, sempre que um cliente é totalmente autenticado pelo EAP, o cliente e o Servidor de autenticação derivam um MSK, que é usado para derivar o PMK. Isso é usado como a semente do handshake 4-Way da WPA2 para derivar a chave de criptografia final unicast (PTK) usada para a sessão (até que o cliente faça roaming para outro AP ou a sessão expire); portanto, esse método evita a fase de autenticação EAP quando em roaming porque reutiliza o PMK original em cache pelo cliente e pelo AP. O cliente só precisa passar pelo handshake 4-Way da WPA2 para derivar novas chaves de criptografia.
Este método não é amplamente implantado como o método de roaming rápido seguro padrão 802.11 recomendado, principalmente devido a estes motivos:
- Este método é opcional e não é suportado por todos os dispositivos WPA2, porque a finalidade da emenda 802.11i não diz respeito ao roaming seguro rápido, e o IEEE já estava trabalhando em outra emenda para padronizar o roaming seguro rápido para WLANs (802.11r, que é abordado posteriormente neste documento).
- Este método tem uma grande limitação na sua implementação: Os clientes sem fio só podem executar o roaming seguro e rápido quando estão em roaming de volta para um AP onde eles tinham autenticado/conectado anteriormente.
Com esse método, a associação inicial a qualquer AP é exatamente como uma autenticação de primeira vez regular para a WLAN, onde toda a autenticação 802.1X/EAP contra o Servidor de autenticação e o handshake de 4 vias para geração de chaves devem ocorrer antes que o cliente possa enviar quadros de dados, como mostrado nesta captura de tela:
As depurações revelam a mesma troca de quadros de autenticação EAP que o resto dos métodos na autenticação inicial para a WLAN, com algumas saídas adicionadas em relação às principais técnicas de cache usadas aqui. Essas saídas de depuração são cortadas para mostrar principalmente as novas informações, não toda a troca de quadros EAP, porque basicamente as mesmas informações são trocadas toda vez para autenticação do cliente em relação ao Servidor de autenticação. Isso é demonstrado até agora e correlacionado aos quadros de autenticação EAP mostrados nas capturas de pacotes, de modo que a maioria das mensagens EAP são removidas das saídas de depuração para simplificar:
*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.
Com esse método, o AP e o cliente sem fio armazenam em cache os PMKs das associações seguras já estabelecidas. Portanto, se o cliente sem fio fizer roaming para um novo AP onde nunca foi associado, o cliente deverá executar uma autenticação EAP completa novamente, como mostrado nesta captura sem fio onde o cliente faz roaming para um novo AP:
No entanto, se o cliente sem fio voltar para um AP onde uma associação/autenticação anterior ocorreu, o cliente enviará um quadro de Solicitação de Reassociação que lista vários PMKIDs, que informa o AP dos PMKs armazenados em cache de todos os APs onde o cliente se autenticou anteriormente. Portanto, como o cliente está em roaming de volta para um AP que também tem um PMK em cache para esse cliente, o cliente não precisa reautenticar através do EAP para derivar um novo PMK. O cliente simplesmente passa pelo handshake 4-Way da WPA2 para derivar as novas chaves de criptografia transitórias:
Aqui está um resumo das depurações de WLC para este método de roaming seguro rápido:
*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 com cache PMKID / cache de teclas sticky
- Quando você usa esse método em uma configuração do FlexConnect, ele pode funcionar e o comportamento pode parecer semelhante ao explicado anteriormente se você usar a autenticação central de volta para a WLC (com switching central ou local); no entanto, esse método de SKC não é suportado no FlexConnect.
- Este método só é oficialmente suportado no CUWN com APs no modo Local, não no FlexConnect ou em outros modos.
Prós com cache PMKID / cache de teclas sticky
Esse método pode ser implementado localmente por APs independentes e autônomos, sem a necessidade de um dispositivo centralizado para gerenciar as chaves em cache.
Cons com cache PMKID / cache de teclas sticky
- Como mencionado anteriormente neste documento, a principal limitação desse método é que o cliente só pode executar o roaming seguro rápido quando estiver em roaming de volta para um AP onde ele foi associado/autenticado anteriormente. Se estiver em roaming para um novo AP, o cliente deve concluir novamente a autenticação EAP completa.
- O cliente sem fio e os APs devem lembrar de todos os PMKs derivados em cada nova autenticação, de modo que esse recurso é normalmente limitado a uma determinada quantidade de PMKs armazenados em cache. Como esse limite não é claramente definido pelo padrão, os fornecedores podem definir limites diferentes em suas implementações de SKC. Por exemplo, os Cisco WLAN Controllers podem armazenar em cache os PMKs de um cliente para até oito APs. Se um cliente fizer roaming para mais de oito APs por sessão, os APs mais antigos serão removidos da lista de cache para armazenar as entradas recém-armazenadas.
- Esse método é opcional e ainda não é suportado por muitos dispositivos WPA2; por conseguinte, este método não é amplamente adotado e aplicado.
- O SKC não é suportado quando você executa o roaming entre controladores, o que ocorre quando você move entre APs gerenciados por diferentes WLCs, mesmo que eles estejam no mesmo grupo de mobilidade.
Roaming rápido com cache de chave oportunista
O OKC (Opportunistic Key Caching, Cache de Chave Oportunista), também conhecido como PKC (Proactive Key Caching, Cache de Chave Pró-Ativa) (este termo é explicado em maior detalhe em uma nota a seguir), é basicamente uma melhoria do método de cache PMKID WPA2 descrito anteriormente, e é por isso também chamado de Cache PMKID Pró-Ativo/Oportunista. Portanto, é importante observar que este não é um método de roaming seguro e rápido definido pelo padrão 802.11 e não é suportado por muitos dispositivos, mas, assim como o cache PMKID, ele funciona com WPA2-EAP.
Essa técnica permite que o cliente sem fio e a infraestrutura de WLAN armazenem em cache apenas um PMK durante a vida útil da associação do cliente com esta WLAN (derivada da MSK após a autenticação 802.1X/EAP inicial com o Authentication Server), mesmo quando em roaming entre vários APs, já que todos compartilham o PMK original usado como semente em todos os handshakes WPA2 de 4 vias. Isso ainda é necessário, assim como está em SKC, para gerar novas chaves de criptografia toda vez que o cliente se reassocia aos APs. Para que os APs compartilhem esse único PMK original da sessão do cliente, todos devem estar sob algum tipo de controle administrativo, com um dispositivo centralizado que armazena em cache e distribui o PMK original para todos os APs. Isso é semelhante ao CUWN, em que a WLC executa esse trabalho para todos os LAPs sob seu controle, e usa os grupos de mobilidade para lidar com esse PMK entre várias WLCs; portanto, essa é uma limitação em ambientes AP autônomos.
Com esse método, assim como no PMKID Caching (SKC), a associação inicial a qualquer AP é uma autenticação de primeira vez regular para a WLAN, na qual você deve concluir toda a autenticação 802.1X/EAP em relação ao Authentication Server e ao handshake de 4 vias para geração de chaves antes de enviar quadros de dados. Aqui está uma captura de tela que ilustra isso:
As saídas de depuração mostram basicamente a mesma troca de quadros de autenticação EAP como o resto dos métodos descritos neste documento na autenticação inicial para a WLAN (como mostrado nas capturas), juntamente com a adição de algumas saídas que dizem respeito às principais técnicas de cache usadas pela WLC aqui. Esta saída de depuração também é cortada para mostrar apenas as informações relevantes:
*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
Com esse método, o cliente sem fio e a WLC (para todos os APs gerenciados) armazenam em cache o único PMK original da associação segura que é inicialmente estabelecida. Basicamente, toda vez que o cliente sem fio se conecta a um AP específico, um PMKID é hash com base em: o endereço MAC do cliente, o endereço MAC do AP (BSSID da WLAN) e o PMK derivado com esse AP. Portanto, como o OKC armazena em cache o mesmo PMK original para todos os APs e o cliente específico, quando esse cliente (re)se associa a outro AP, o único valor que é alterado para hash o novo PMKID é o novo endereço MAC do AP.
Quando o cliente inicia o roaming em um novo AP e envia o quadro de Solicitação de Reassociação, ele adiciona o PMKID no Elemento de Informações RSN WPA2 se quiser informar ao AP que um PMK em cache é usado para o roaming seguro rápido; como ele já sabe o endereço MAC do BSSID (AP) para onde ele faz roaming, o cliente simplesmente tem o novo PMKID usado nesta Solicitação de Reassociação. Quando o AP recebe essa solicitação do cliente, ele também tem o PMKID com os valores que já tem (o PMK em cache, o endereço MAC do cliente e seu próprio endereço MAC do AP) e responde com a Resposta de Reassociação bem-sucedida que confirma a correspondência dos PMKIDs. O PMK em cache pode ser usado como a semente que inicia um handshake 4-Way WPA2 para derivar as novas chaves de criptografia (ignorando o EAP):
Nesta captura, o quadro Solicitação de Reassociação do cliente é selecionado e expandido para que você possa ver mais detalhes do quadro. As informações de endereço MAC e também o Elemento de Informações de Rede de Segurança Robusta (RSN, conforme 802.11i - WPA2), onde são mostradas informações sobre as configurações de WPA2 usadas para essa associação (destacada é a PMKID obtida da fórmula hash).
Aqui está um resumo das depurações de WLC para este método de roaming seguro rápido com 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
Como mostrado no início das depurações, o PMKID deve ser computado após o recebimento da Solicitação de reassociação do cliente. Isso é necessário para validar o PMKID e confirmar que o PMK em cache é usado com o handshake 4-Way da WPA2 para derivar as chaves de criptografia e concluir o roaming rápido seguro. Não confunda as entradas CCKM nas depurações; isso não é usado para executar o CCKM, mas OKC, como explicado anteriormente. O CCKM aqui é simplesmente um nome usado pela WLC para essas saídas, como o nome de uma função que lida com os valores para computar o PMKID.
FlexConnect com cache de chave oportunista
- A autenticação central é suportada. Isso inclui switching de dados local e central. Se o AP fizer parte do mesmo grupo FlexConnect, o roaming rápido seguro é feito pelo AP, caso contrário, o roaming rápido seguro é feito pelo controlador.
- A autenticação local flexível é suportada. No modo conectado, o cache será distribuído do AP para o controlador e, em seguida, para o restante dos APs no grupo FlexConnect.
- O modo autônomo é suportado. Se o cache já estiver presente no AP (devido à distribuição anterior), o roaming de segurança rápida funcionará. A nova autenticação no modo autônomo não suporta roaming rápido seguro.
Prós com cache de chave oportunista
- O cliente sem fio e a infraestrutura de WLAN não precisam lembrar de vários PMKIDs, mas simplesmente armazenar em cache o único PMK original da autenticação inicial para a WLAN. Em seguida, você deve rehash o PMKID apropriado (usado na Solicitação de reassociação) exigido com cada associação segura de AP para validar o roaming seguro e rápido.
- Aqui, o cliente sem fio executa o roaming seguro e rápido para um novo AP na mesma WLAN/SSID, mesmo que nunca esteja associado a esse AP (não o caso em SKC). Desde que o cliente execute a autenticação 802.1X/EAP inicial com um AP gerenciado pela implantação centralizada que lida com o cache PMK para todos os APs para onde o cliente faz roaming, não serão necessárias mais autenticações completas para o resto da vida útil do cliente nesta WLAN.
Cons com cache de chave oportunista
- Esse método só é implantado em um ambiente centralizado onde todos os APs estão sob algum tipo de controle administrativo (como um controlador de WLAN) responsável pelo cache e compartilhamento do único PMK original da sessão do cliente. Portanto, essa é uma limitação em ambientes AP autônomos.
- As técnicas aplicadas nesse método não são sugeridas nem descritas no padrão 802.11, portanto, o suporte varia muito de um dispositivo para outro. No entanto, esse ainda é o método mais adotado enquanto se espera pelo 802.11r.
Observação sobre o termo "Cache de chave proativa"
O cache de chave proativa (ou PKC) foi conhecido como OKC (Opportunistic Key Caching) e os dois termos foram usados como sinônimos ao descrever o mesmo método explicado aqui. No entanto, esse era apenas um termo usado pelo Airspace em 2001 para um método antigo de cache de chaves, que foi então usado pelo padrão 802.11i como a base para a "Pré-autenticação" (outro método de roaming rápido e seguro brevemente explicado abaixo). O PKC não é a pré-autenticação ou OKC (Opportunistic Key Caching), mas quando você ouve ou lê sobre o PKC, a referência é basicamente o OKC, e não a pré-autenticação.
Roaming rápido e seguro com pré-autenticação
Esse método também é sugerido pelo padrão IEEE 802.11 dentro da emenda de segurança 802.11i, portanto também funciona com WPA2, mas é o único método de roaming seguro rápido que não é suportado pela infraestrutura de WLAN da Cisco. Por esta razão, é explicada apenas brevemente aqui e sem resultados.
Com a pré-autenticação, os clientes sem fio podem autenticar com vários APs de uma vez enquanto estão associados ao AP atual. Quando isso ocorre, o cliente envia os quadros de autenticação EAP para o AP atual onde está conectado, mas é destinado aos outros APs em que o cliente deseja executar a pré-autenticação (APs vizinhos que são possíveis candidatos para roaming). O AP atual envia esses quadros ao(s) AP(s) de destino pelo sistema de distribuição. O novo AP executa a autenticação completa contra o servidor RADIUS para esse cliente, de modo que um novo handshake de autenticação EAP inteiro é concluído, e esse novo AP atua como o Authenticator.
A ideia é executar a autenticação e derivar o PMK com os APs vizinhos antes que o cliente realmente faça roaming com eles, então, quando é hora de fazer roaming, o cliente já está autenticado e com um PMK já armazenado em cache para essa nova associação segura de AP para cliente, então eles só precisam executar o Handshake de 4 vias e experimentar um roaming rápido depois que o cliente envia sua solicitação de reassociação inicial.
Aqui está uma captura do beacon de um AP que mostra o campo RSN IE que anuncia o suporte para a pré-autenticação (esta é de um AP Cisco, onde é confirmado que a pré-autenticação não é suportada):
Prós-autenticação
Há um PMK para cada associação segura de AP para cliente, que pode ser considerado uma vantagem de segurança caso um AP seja comprometido e as chaves sejam roubadas (não podem ser usadas com outros APs). No entanto, essa vantagem de segurança é tratada pela infraestrutura da WLAN de maneiras diferentes em outros métodos.
Cons com pré-autenticação
- Como há um PMK por AP, os clientes têm um limite na quantidade de APs que podem ser pré-autenticados.
- Cada vez que um cliente executa a pré-autenticação com um novo AP, há uma troca de autenticação EAP completa, o que significa mais carga na rede e no Servidor de autenticação.
- A maioria dos clientes sem fio não suporta esse método, pois ele nunca foi altamente adotado (OKC foi mais adotado).
Roaming rápido e seguro com 802.11r
A técnica de roaming rápida segura baseada na emenda 802.11r (oficialmente denominada Fast BSS Transition pelo padrão 802.11 e conhecida como FT) é o primeiro método oficialmente ratificado (em 2008) pelo IEEE para o padrão 802.11 como a solução para realizar transições rápidas entre APs (Conjuntos de serviços básicos ou BSSs), que define claramente a hierarquia de chaves usada quando você lida com as chaves de cache em uma WLAN. No entanto, sua adoção tem sido lenta, principalmente devido às outras soluções já disponíveis quando transições rápidas eram realmente necessárias, como com implementações de VoWLAN quando usadas com um dos métodos explicados anteriormente neste documento. Há apenas alguns dispositivos que atualmente suportam algumas das opções de FT (até 2013).
Essa técnica é mais complexa para explicar do que os outros métodos, pois introduz novos conceitos e várias camadas de PMKs que são colocados em cache em diferentes dispositivos (cada dispositivo com uma função diferente) e oferece ainda mais opções para roaming seguro e rápido. Por conseguinte, é fornecido um breve resumo sobre este método e a forma como é implementado com cada opção disponível.
802.11r é diferente de SKC e OKC, principalmente por estes motivos:
- A mensagem de handshake (PMKID, ANonce e troca SNonce, por exemplo) acontece em quadros de autenticação 802.11 ou em quadros de ação em vez de quadros de reassociação. Ao contrário dos métodos de cache PMKID, a fase separada de handshake de 4 vias, que é transportada após a troca de mensagem (re)associação, é evitada. O handshake de chave com o novo AP começa antes que o cliente faça roaming/se associe novamente a esse novo AP.
- Ele fornece dois métodos para o handshake de roaming rápido: sobre o AR e sobre o Sistema de Distribuição (DS).
- 802.11r tem mais camadas de hierarquia de chaves.
- Como esse protocolo evita o handshake de 4 vias para o gerenciamento de chaves quando um cliente faz roaming (gera novas chaves de criptografia - PTK e GTK - sem a necessidade desse handshake), ele também pode ser aplicado para configurações WPA2 com uma PSK, e não apenas quando 802.1X/EAP é usado para a autenticação. Isso acelera ainda mais o roaming para essas configurações, onde não ocorrem trocas EAP ou handshake de 4 vias.
Com esse método, o cliente sem fio executa apenas uma autenticação inicial em relação à infraestrutura de WLAN quando uma conexão é estabelecida para o primeiro AP e executa roaming rápido e seguro enquanto faz roaming entre APs do mesmo domínio de mobilidade de FT.
Esse é um dos novos conceitos, que se refere basicamente aos APs que usam o mesmo SSID (conhecido como Conjunto de Serviços Estendidos ou ESS) e manipulam as mesmas chaves FT. Tal é semelhante aos outros métodos explicados até à data. A forma como os AP lidam com as chaves de domínio de mobilidade da FT é normalmente baseada em uma configuração centralizada, como o WLC ou os grupos de mobilidade; no entanto, esse método também pode ser implementado em ambientes AP autônomos.
Aqui está um resumo da hierarquia de chaves:
- Uma MSK ainda é derivada no suplicante do cliente e no Servidor de Autenticação da fase de autenticação 802.1X/EAP inicial (transferida do Servidor de Autenticação para o Autenticador (WLC) assim que a autenticação for bem-sucedida). Esta MSK, como nos outros métodos, é usada como a semente para a hierarquia de chaves FT. Quando você usa WPA2-PSK em vez de um método de autenticação EAP, a PSK é basicamente essa MSK.
- Uma chave mestre em emparelhamento R0 (PMK-R0) é derivada da MSK, que é a chave de primeiro nível da hierarquia de chaves FT. Os principais detentores desse PMK-R0 são a WLC e o cliente.
- Uma chave de segundo nível, chamada PMK-R1 (Pairwise Master Key R1), deriva do PMK-R0, e os principais proprietários são o cliente e os APs gerenciados pelo WLC que contém o PMK-R0.
- A terceira e última chave de nível da hierarquia de chaves FT é o PTK, que é a chave final usada para criptografar os quadros de dados unicast 802.11 (semelhante aos outros métodos que usam WPA/TKIP ou WPA2/AES). Esse PTK é derivado no FT do PMK-R1, e os principais detentores são o cliente e os APs gerenciados pelo WLC.
Transição rápida de BSS pelo ar
Com esse método, a primeira associação a qualquer AP é uma autenticação de primeira vez regular para a WLAN, na qual toda a autenticação 802.1X/EAP em relação ao Servidor de autenticação e o handshake de 4 vias para geração de chaves devem ocorrer antes do envio dos quadros de dados, como mostrado nesta captura de tela:
As principais diferenças são:
- A negociação de Gerenciamento de Chave de Autenticação é um pouco diferente da WPA/WPA2 normal, portanto, algumas informações adicionais são usadas para executar essa negociação quando ocorre a associação a uma infraestrutura de WLAN que suporta FT. Como mostrado na captura, o quadro de Solicitação de Associação do cliente é selecionado e o campo AKM do Elemento de Informações de RNS é destacado para mostrar que esse cliente deseja executar o FT acima de 802.1X/EAP.
- Também é mostrado o Mobility Domain Information Element (parte da FT), em que o campo FT Capability and Policy indica se a Transição rápida do BSS foi concluída por excesso de ar ou por excesso de DS quando o roaming rápido (indicando excesso de ar nessa captura).
- Outro elemento de informação também é adicionado (Fast BSS Transition ou FT IE, que é descrito mais adiante neste documento) com as informações necessárias para executar a sequência de autenticação da FT quando o roaming da FT.
- A geração de chave é diferente devido à hierarquia de chaves, portanto, embora o handshake 4-Way da FT pareça semelhante ao handshake 4-Way da WPA/WPA2, na verdade, é um pouco diferente no conteúdo.
As depurações mostram basicamente a mesma troca de quadros de autenticação EAP que o resto dos métodos na autenticação inicial para a WLAN (como observado nas capturas), mas algumas saídas que dizem respeito às principais técnicas de cache usadas pela WLC são adicionadas; assim, essa saída de depuração é cortada para mostrar apenas as informações relevantes:
*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.
Aqui estão as capturas e depurações de uma associação inicial à WLAN quando você executa o FT com WPA2-PSK (em vez de um método 802.1X/EAP), em que o quadro de Resposta de Associação do AP é selecionado para mostrar o Elemento de Informações de Transição do Fast BSS (destacado). Algumas das principais informações necessárias para executar o handshake de 4 vias da FT também são mostradas:
*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
Com o 802.11r, a associação inicial à WLAN é a base usada para derivar as chaves básicas usadas por essa técnica, assim como nos outros métodos de roaming de segurança rápida. As principais diferenças surgem quando o cliente começa a fazer roaming; A FT não só evita o 802.1X/EAP quando usado, como também executa um método de roaming mais eficiente que combina os quadros iniciais de Autenticação e Reassociação do Sistema Aberto 802.11 (que são sempre usados e necessários quando em roaming entre APs) para trocar informações da FT e derivar novas chaves de criptografia dinâmicas em vez do handshake de 4 vias.
A próxima captura mostra os quadros trocados quando é realizada uma transição rápida de BSS pelo ar com segurança 802.1X/EAP. O quadro Open System Authentication do cliente para o AP é selecionado para ver os elementos de informações do protocolo FT necessários para iniciar a negociação de chave FT. Isso é usado para derivar o novo PTK com o novo AP (baseado no PMK-R1). O campo que mostra o algoritmo de autenticação é destacado para mostrar que este cliente não executa uma simples Autenticação de Sistema Aberto, mas uma Transição de BSS Rápida:
Aqui estão as saídas de depuração do WLC quando este evento de roaming FT ocorre com o 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
Esta é uma captura que mostra uma transição Fast BSS Over-the-Air com segurança WPA2-PSK, na qual o quadro final de resposta de reassociação do AP ao cliente é selecionado para mostrar mais detalhes sobre esta troca FT:
Aqui estão as saídas de depuração quando esse evento de roaming FT ocorre com PSK, que são semelhantes àquelas em que o 802.1X/EAP é usado:
*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
Como mostrado na captura, depois que a Transição Fast BSS é negociada na associação inicial à WLAN, os quatro quadros que são usados e necessários para roaming (Autenticação de sistema aberto do cliente, Autenticação de sistema aberto do AP, Solicitação de reassociação e Resposta de reassociação) são basicamente usados como handshake FT de 4 vias para derivar o novo PTK (chave de criptografia unicast) e GTK (chave de criptografia multicast/broadcast) .
Isso substitui o handshake de 4 vias que normalmente ocorre depois que esses quadros são trocados, e o conteúdo da FT e a negociação de chave nesses quadros é basicamente o mesmo se você usa 802.1X/EAP ou PSK como método de segurança. Como mostrado na captura, o campo AKM é a principal diferença, o que confirma se o cliente executa FT com PSK ou 802.1X. Portanto, é importante observar que esses quatro quadros normalmente não têm esse tipo de informação de segurança para negociação de chave, mas somente quando a FT do cliente faz roaming se 802.11r for implementada e negociada entre o cliente e a infraestrutura da WLAN na associação inicial.
Transição rápida de BSS pelo DS
O 802.11r permite outra implementação da transição Fast BSS, em que o roaming FT é iniciado pelo cliente com o novo AP para o qual o cliente faz roaming over-the-DS (Sistema de Distribuição), e não Over-the-Air. Nesse caso, os quadros de ação da FT são usados para iniciar a negociação de chave em vez dos quadros de autenticação do sistema aberto.
Basicamente, assim que o cliente decide que ele pode fazer roaming para um AP melhor, o cliente envia um quadro de solicitação de ação FT para o AP original onde ele está conectado atualmente antes do roaming. O cliente indica o BSSID (endereço MAC) do AP de destino onde deseja encaminhar o tráfego. O AP original encaminha esse quadro de Solicitação de Ação de FT para o AP de destino pelo Sistema de Distribuição (normalmente a infraestrutura com fio), e o AP de destino responde ao cliente com um quadro de Resposta de Ação de FT (também pelo DS, para que possa finalmente enviá-lo pelo ar para o cliente). Quando esta troca de quadro Ação da FT for bem-sucedida, o cliente finaliza o roaming da FT; o cliente envia a solicitação de reassociação ao AP de destino (desta vez por via aérea) e recebe uma resposta de reassociação do novo AP para confirmar a derivação das chaves de roaming e final.
Em resumo, há quatro quadros para negociar a Transição Fast BSS e derivar novas chaves de criptografia, mas aqui os quadros de Autenticação do Sistema Aberto são substituídos pelos quadros de Solicitação de Ação/Resposta da FT, que são trocados com o AP de destino sobre o Sistema de Distribuição com o AP atual. Este método também é válido para ambos os métodos de segurança 802.1X/EAP e PSK, todos suportados pelos Cisco Wireless LAN Controllers; entretanto, como essa transição Over-the-DS não é suportada e implementada pela maioria dos clientes sem fio no setor de WiFi (e como as saídas de intercâmbio e depuração de quadros são basicamente as mesmas), exemplos não são fornecidos neste documento. Em vez disso, esta imagem é usada para visualizar a transição rápida do BSS sobre o DS:
FlexConnect com 802.11r
- A autenticação central é suportada. Isso inclui switching de dados local e central. Os APs devem fazer parte do mesmo grupo FlexConnect.
- A autenticação local não é suportada.
- O modo autônomo não é suportado.
Prós com 802.11r
- Este método é o primeiro que usa uma hierarquia de chaves claramente definida pelo IEEE no padrão 802.11 como uma emenda (802.11r), de modo que a implementação dessas técnicas de FT é mais compatível entre fornecedores e sem interpretações diferentes.
- O 802.11r permite várias técnicas úteis, dependendo das suas necessidades (Over-the-Air e Over-the-DS, para segurança 802.1x/EAP e para segurança PSK).
- O cliente sem fio executa o roaming seguro e rápido para um novo AP na mesma WLAN/SSID, mesmo que nunca esteja associado a esse AP e sem a necessidade de salvar vários PMKIDs.
- Este é o primeiro método de roaming rápido seguro que permite roaming mais rápido mesmo com a segurança PSK e evita o handshake de 4 vias que é necessário ao roaming entre APs com WPA/WPA2 PSK. A principal finalidade dos métodos de roaming seguro e rápido é evitar o handshake 802.1X/EAP quando esse método de segurança é implementado; no entanto, para a segurança da PSK, o evento de roaming é ainda mais acelerado com o 802.11r, evitando o handshake de 4 vias.
Cons com 802.11r
- Há alguns dispositivos clientes sem fio que realmente suportam transições de BSS rápido e, na maioria dos casos, não suportam todas as técnicas disponíveis no 802.11r.
- Devido ao fato dessas implementações serem muito jovens, não há resultados de testes suficientes em ambientes de produção real ou resultados de depuração suficientes para lidar com possíveis advertências que possam aparecer.
- Quando você configura uma WLAN/SSID para usar qualquer um dos métodos FT, somente os clientes sem fio que suportam 802.11r podem se conectar a esta WLAN/SSID. As configurações de FT não são opcionais para os clientes, portanto, os clientes sem fio que não suportam 802.11r devem se conectar a uma WLAN/SSID separada onde a FT não está configurada.
Adaptável 802.11r
- Alguns clientes herdados não podem se associar a uma WLAN/SSID que tenha 802.11r ativado mesmo para o "modo misto" (que você espera que possa ter nos mesmos clientes SSID que suportam e que não suportam 802.11r). É quando o motorista do requerente do cliente responsável pela análise do Robust Security Network Information Element (RSN IE) é antigo e desconhece os conjuntos adicionais de AKM no IE. Devido a essa limitação, os clientes não podem enviar solicitações de associação para WLANs que anunciam suporte a 802.11r e, portanto, você provavelmente precisará configurar uma WLAN/SSID para clientes 802.11r e uma WLAN/SSID separada para clientes que não suportam 802.11r.
-
Para superar isso, a infraestrutura de LAN sem fio da Cisco introduziu o recurso Adaptive 802.11r. Quando o modo FT é definido como Adaptive no nível de WLAN, a WLAN anuncia o 802.11r Mobility Domain ID em uma WLAN habilitada para 802.11i. Alguns dispositivos clientes Apple iOS10 identificam a presença de MDIE em uma WLAN 80211i/WPA2 e fazem um handshake proprietário para estabelecer uma associação de 802.11r. Quando o cliente concluir uma associação 802.11r bem-sucedida, ele poderá fazer roaming FT como em uma WLAN 802.11r normal habilitada. O FT Adaptive se aplica somente a dispositivos Apple iOS10 (e posteriores) selecionados. Todos os outros clientes continuarão a ter a associação 802.11i/WPA2 na WLAN e executarão o método FSR aplicável conforme suportado.
-
Mais documentação sobre esse novo recurso introduzido para que os dispositivos iOS10 executem 802.11r em uma WLAN/SSID onde 802.11r não está realmente habilitado (assim, outros clientes que não são 802.11r se conectarão com êxito) pode ser encontrada em Enterprise Best Practices for iOS Devices on Cisco Wireless LAN.
Conclusões
- Lembre-se de que o cliente é sempre o que decide fazer roaming para um AP específico, e o WLC/AP não pode decidir isso para o cliente. O evento de roaming é iniciado pelo cliente sem fio quando ele considera que deve ser transmitido.
- A WLC suporta uma combinação da maioria ou de todos os métodos FSR (Fast-Secure Roaming) juntos na mesma WLAN/SSID. No entanto, esteja ciente de que isso normalmente não funciona, pois depende muito do comportamento do cliente (muito diferente em diferentes dispositivos móveis) para suportar ou até mesmo entender o que a WLC tenta anunciar como suportado. Em vez de alcançar a interoperabilidade em apenas um SSID, normalmente há mais problemas do que aqueles que se espera consertar, portanto isso não é recomendado. Testes aprofundados com todos os clientes possíveis a serem usados nesta WLAN devem ser concluídos se isso for realmente necessário.
- É muito importante entender que os métodos de roaming de segurança rápida são desenvolvidos para acelerar o processo de roaming da WLAN quando você se move entre os APs se a WLAN/SSID tiver segurança habilitada. Quando não há segurança, não há nada a acelerar, pois o cliente-AP simplesmente troca os quadros de gerenciamento sem fio sempre necessários quando o roaming entre os APs é enviado antes dos quadros de dados serem enviados (Autenticação de sistema aberto do cliente, Autenticação de sistema aberto do AP, Solicitação de reassociação e Resposta de reassociação). Portanto, isso não pode se mover mais rápido. Se você encontrar problemas de roaming sem segurança, não haverá métodos de roaming rápido para melhorar o roaming, somente métodos para confirmar se a configuração e o projeto da WLAN/SSID são apropriados para as estações clientes sem fio fazerem roaming de acordo com as células de cobertura do AP.
- 802.11r/FT é implementado com WPA2-PSK para acelerar eventos de roaming com essa segurança evitando o handshake de 4 vias, como explicado na seção 802.11r.
- Todos os métodos têm suas vantagens e desvantagens, mas no final, você deve sempre verificar se as estações cliente sem fio suportam o método específico que você deseja implementar e se a infraestrutura de WLAN da Cisco suporta todos os métodos disponíveis. Assim, você deve selecionar o melhor método que é realmente suportado pelos clientes sem fio que se conectam à WLAN/SSID específica. Por exemplo, em algumas implantações, você pode criar uma WLAN/SSID com CCKM para telefones IP sem fio da Cisco (que suportam WPA2/AES com CCKM, mas não 802.11r), e depois outra WLAN/SSID com WPA2/AES via 802.11r/FT para clientes sem fio que suportam esse método de roaming seguro rápido (ou usar OKOKI C, se é isso que é suportado).
- Se os clientes sem fio não oferecerem suporte a nenhum dos métodos de roaming rápido disponíveis, talvez seja necessário aceitar o fato de que esses clientes sempre experimentarão os atrasos explicados neste documento quando estiverem em roaming entre APs em uma WLAN/SSID com segurança 802.1X/EAP (o que pode causar interrupções nos aplicativos/serviços do cliente).
- Todos os métodos, exceto SKC (WPA2 PMKID Caching), são suportados para roaming rápido seguro entre APs gerenciados por diferentes WLCs (roaming entre controladores), desde que estejam no mesmo grupo de mobilidade.
- O CUWN oferece suporte total a todos os diferentes métodos de roaming seguro rápido abordados neste artigo ao usar a autenticação 802.1X/EAP para WPA/WPA2. O CUWN não suporta roaming seguro rápido em métodos que funcionam com WPA2-RSN (CCKM, cache PMKID/SKC, OKC/PKC) quando se usa PSK (WPA2-Personal), onde os métodos de roaming rápido não são mais necessários. No entanto, o CUWN suporta o roaming rápido no caso de WPA2-FT (802.11r) com PSK, como também explicado neste artigo.
Informações Relacionadas
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)