802.11 WLAN que vagueia e que vagueia Rápido-seguro em CUWN
Índice
Introdução
Este original descreve os tipos diferentes de vaguear do Sem fio e de métodos vagueando rápido-seguros disponíveis para o Sem fio LAN do IEEE 802.11 (WLAN) apoiado na rede de Cisco Unified Wireless (CUWN).
O original não fornece todos os específicos sobre como cada método trabalha ou como são configurados. O propósito principal deste original é descrever as diferenças entre as várias técnicas disponíveis, suas vantagens e limitações, e a quadro-troca em cada método. Os exemplos do controlador de WLAN (WLC) debugam são fornecidos, e as capturas de pacote de informação sem fio são usadas a fim analisar e explicar os eventos que ocorrem para cada método vagueando descrito.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Fundamentos do IEEE 802.11 WLAN
- Segurança de WLAN do IEEE 802.11
- Princípios da IEEE 802.1X/EAP
Componentes Utilizados
A informação neste documento é baseada na versão de software 7.4 do controlador de WLAN de Cisco, mas a maioria dos resultados do debug e dos comportamentos descritos puderam aplicar-se a toda a versão de software que apoiar os métodos discutidos. Os específicos de todos os métodos explicados aqui permanecem os mesmos em uns códigos mais atrasados do controlador de WLAN de Cisco (até a versão 8.3 antes que este artigo for atualizado).
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Informações de Apoio
Antes que uma descrição dos métodos vagueando rápido-seguros diferentes disponíveis para WLAN esteja dada, é importante compreender como os trabalhos de processo de associação WLAN, e como um evento vagueando regular ocorre quando não houver nenhuma Segurança configurada no Service Set Identifier (SSID).
Quando um cliente Wireless do 802.11 conectar a um Access Point (AP), antes que começar a passar o tráfego (frames de dados sem fio), primeiramente deve passar o processo de autenticação básico do sistema aberto do 802.11. Então, o processo de associação deve ser terminado. Pense do processo de autenticação do sistema aberto como a “conexão do cabo” no AP que o cliente seleciona. Isto é muito importante de compreender, porque é sempre o cliente Wireless que seleciona que AP é preferido, e baseia a decisão nos fatores múltiplos que variam entre vendedores. Eis porque o cliente começa este processo enviando o quadro da autenticação ao AP selecionado, como mostrado mais tarde neste original. O AP não pode pedir que você estabelece uma conexão.
Uma vez que o processo de autenticação do sistema aberto está terminado com sucesso com uma resposta do AP (“cabo conectado”), o processo de associação termina essencialmente a negociação da camada 2 do 802.11 (L2) que estabelece a relação entre o cliente e o AP. O AP atribui uma identificação da associação ao cliente se a conexão é bem sucedida, e prepara-à fim passar o tráfego ou executar um método de mais alto nível da Segurança se configurado no SSID. O processo de autenticação do sistema aberto consiste em dois quadros do Gerenciamento assim como no processo de associação. Os quadros da autenticação e da associação são quadros sem fio do Gerenciamento, não os frames de dados, que são basicamente esses usados para o processo da conexão com o AP.
Está aqui uma captação dos wireless frame sobre - areje para este processo:
O cliente Wireless começa com o quadro da autenticação, e o AP responde com um outro quadro da autenticação. O cliente envia então o quadro do pedido da associação, e o AP termina em uma resposta com o frame de resposta da associação. Como mostrado dos pacotes DHCP, uma vez que a autenticação e os processos de associação do sistema aberto do 802.11 são passados, o cliente começa a passar frames de dados. Neste caso, não há nenhum método da Segurança configurado no SSID, assim que o cliente começa imediatamente a enviar os frames de dados (neste caso DHCP) que não são cifrados.
Como mostrado mais tarde neste original, se a Segurança é permitida no SSID, há uns quadros de mais alto nível do aperto de mão da autenticação e da criptografia para o método específico da Segurança, imediatamente depois da resposta da associação e antes de enviar algum quadro de dados de tráfego do cliente, tal como o DHCP, o Address Resolution Protocol (ARP), e os pacotes dos aplicativos, que são cifrados. Os frames de dados podem somente ser enviados até que o cliente esteja autenticado inteiramente, e as chaves de criptografia estão negociadas, com base no método da Segurança configurado.
São baseadas na captação precedente, aqui as mensagens que você vê nas saídas do WLC debuga o comando client quando o cliente Wireless começa uma associação nova ao 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.
Estas mensagens mostram o pedido e os frames de resposta da associação; os quadros iniciais da autenticação não são registrados no WLC porque este aperto de mão acontece rapidamente no AP-nível no CUWN.
Que informação aparece quando o cliente vagueia? O cliente troca sempre quatro quadros do Gerenciamento em cima do estabelecimento de uma conexão a um AP, que seja devido ao estabelecimento do cliente da associação, ou a um evento vagueando. O cliente tem somente uma conexão estabelecida a somente um AP de cada vez. A única diferença na troca do quadro entre uma nova conexão à infraestrutura WLAN e um evento vagueando é que os quadros da associação de um evento vagueando estão chamados os quadros de Reassociação, que indicam que o cliente está vagueando realmente de um outro AP sem tentativas de estabelecer uma associação nova ao WLAN. Estes quadros podem conter os elementos diferentes que são usados a fim negociar o evento vagueando; isto depende da instalação, mas aqueles detalhes são fora do âmbito deste original.
Está aqui um exemplo da troca do quadro:
Estas mensagens aparecem no resultado do debug:
*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 sucesso um evento vagueando depois que o pedido da reassociação ao AP novo é enviado, e recebe a resposta da reassociação do AP. Desde que o cliente já tem um IP address, os primeiros frames de dados são para pacotes ARP.
Se você espera um evento vagueando, mas o cliente envia um pedido da associação em vez de um pedido da reassociação (que você pode confirmar de algumas captações e debuga similar àquelas explicado mais cedo neste original), a seguir o cliente não está vagueando realmente. O cliente começa uma associação nova ao WLAN como se uma desconexão ocorreu, e às tentativas a reconectar a partir do zero. Isto pode acontecer para razões múltiplas, como quando um cliente se move longe das áreas de cobertura e se encontra então um AP com bastante qualidade de sinal para começar uma associação, mas indica normalmente um problema de cliente onde o cliente não inicie um evento vagueando devido aos direcionadores, ao firmware, ou às questões de software.
Vaguear com Segurança de mais alto nível
Quando o SSID é configurado com Segurança L2 de mais alto nível sobre a autenticação básica do sistema aberto do 802.11, a seguir mais quadros estão exigidos para a associação inicial e ao vaguear. Os dois métodos mais-comuns da Segurança estandardizados e executados para o 802.11 WLAN são descritos neste original:
- WPA/WPA2-PSK (chave pré-compartilhada) - autenticação dos clientes com uma Preshared-chave.
- WPA/WPA2-EAP (protocolo extensible authentication) - autenticação dos clientes com um método 802.1X/EAP a fim validar credenciais mais seguras com o uso de um Authentication Server, tal como Certificados, nome de usuário e senha, e tokens.
É importante saber que, mesmo que estes dois métodos (PSK e EAP) autentiquem/validem os clientes em maneiras diferentes, ambos usa basicamente as mesmas regras WPA/WPA2 para o processo do gerenciamento chave. Se a Segurança é WPA/WPA2-PSK ou WPA/WPA2-EAP, o processo conhecido como o aperto de mão WPA/WPA2 4-Way começa a negociação chave entre o WLC/AP e o cliente com uma chave de sessão mestra (MSK) como o material chave original uma vez que o cliente é validado com o método de autenticação específico usado.
Está aqui um sumário do processo:
- Um MSK é derivado da fase da autenticação de EAP quando a Segurança 802.1X/EAP é usada, ou do PSK quando WPA/WPA2-PSK é usado como o método da Segurança.
- Deste MSK, o cliente e os WLC/AP derivam por pares o chave mestre (PMK), e o WLC/AP gerencie um chave mestre do grupo (GMK).
- Uma vez que estes dois chaves mestres estão prontos, o cliente e os WLC/AP iniciam o aperto de mão WPA/WPA2 4-Way (que é ilustrado mais tarde neste original com algumas capturas de tela e debuga) com os chaves mestres como as sementes para a negociação das chaves de criptografia reais.
- Aquelas chaves de criptografia finais são sabidas como a chave por pares transiente (PTK) e a chave transiente do grupo (GTK). O PTK é derivado do PMK e usado a fim cifrar frames de unicast com o cliente. A chave transiente do grupo (GTK) é derivada do GMK, e usada a fim cifrar o Multicast/transmissão neste SSID/AP específico.
WPA/WPA2-PSK
Quando o WPA-PSK ou WPA2-PSK são executados através do Temporal Key Integrity Protocol (TKIP) ou do Advanced Encryption Standard (AES) para a criptografia, o cliente deve atravessar o processo conhecido como o aperto de mão WPA 4-Way para a associação inicial e igualmente ao vaguear. Como explicado previamente, este é basicamente o processo do gerenciamento chave usado para que WPA/WPA2 derive as chaves de criptografia. Contudo, quando o PSK é executado, igualmente usa-se a fim verificar que o cliente tem uma chave pré-compartilhada válida para se juntar ao WLAN. Esta captação mostra o processo de associação inicial quando o WPA ou o WPA2 com PSK são executados:
Como mostrado, após a autenticação e o processo de associação do sistema aberto do 802.11, há quatro quadros EAPOL do aperto de mão WPA 4-Way, que são iniciados pelo AP com message-1, e terminados pelo cliente com message-4. Após um aperto de mão bem sucedido, o cliente começa a passar os frames de dados (tais como o DHCP), que são cifrados neste caso com as chaves derivadas do aperto de mão 4-Way (eis porque você não pode ver o índice e o tipo de tráfego reais das captações do Sem fio).
Estas mensagens aparecem nos resultados do debug:
*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.
Ao vaguear, o cliente segue basicamente a mesma troca do quadro, onde o aperto de mão WPA 4-Way é exigido a fim derivar chaves de criptografia novas com o AP novo. Isto é devido aos motivos de segurança estabelecidos pelo padrão, e ao fato de que o AP novo não conhece as chaves originais. A única diferença é que há uns quadros da reassociação em vez dos quadros da associação, segundo as indicações desta captação:
Você vê as mesmas mensagens nos resultados do debug, mas o primeiro pacote do cliente é uma reassociação em vez de uma associação, como mostrado e explicado previamente.
WPA/WPA2-EAP
Quando um método 802.1X/EAP é usado a fim autenticar os clientes em um SSID seguro, há ainda mais quadros exigidos antes que o cliente comece a passar o tráfego. Estes quadros extra são usados a fim autenticar as credenciais do cliente, e o dependente em cima do método de EAP, lá pôde estar entre quatro e vinte quadros. Estes vêm após a associação/reassociação, mas antes do aperto de mão WPA/WPA2 4-Way, porque a fase de autenticação deriva o MSK usado como a semente para a geração de chave de criptografia final no processo do gerenciamento chave (aperto de mão 4-Way).
Esta captação sem fio mostra um exemplo dos quadros trocados sobre o ar entre o AP e o cliente Wireless em cima da associação inicial quando o WPA com PEAPv0/EAP-MSCHAPv2 é executado:
Às vezes esta troca mostra mais ou menos quadros, que depende dos fatores múltiplos, tais como o método de EAP, as retransmissões devido aos problemas, comportamento do cliente (tal como os dois pedidos da identidade neste exemplo, porque o cliente envia um COMEÇO EAPOL depois que o AP envia o primeiro pedido da identidade), ou se o cliente já trocou o certificado com o server. Sempre que o SSID é configurado para um método 802.1X/EAP, há mais quadros (para a autenticação), e daqui, exige mais tempo antes que o cliente comece a enviar frames de dados.
Está aqui um sumário das mensagens debugar:
*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 Wireless executar um regular que vagueia aqui (o comportamento normal, sem aplicação de um método vagueando rápido-seguro), o cliente deve atravessar o exato o mesmo processo e executar uma autenticação completa contra o Authentication Server, segundo as indicações das captações. A única diferença é que o cliente usa um pedido da reassociação a fim informar o AP novo que está vagueando realmente de um outro AP, mas o cliente ainda tem que atravessar a validação completa e a geração chave nova:
Como mostrado, mesmo quando há menos quadros do que na autenticação inicial (que é causado por fatores múltiplos, como mencionado antes), quando o cliente vagueia a um AP novo, a autenticação de EAP e os processos do gerenciamento chave WPA devem ainda ser terminados a fim continuar a passar frames de dados (mesmo se o tráfego foi enviado ativamente antes de vaguear). Consequentemente, se o cliente tem um aplicativo que ativo que seja sensível aos atrasos (tais como aplicativos do tráfego de voz, ou aplicativos que são sensíveis aos intervalos), a seguir o usuário pode perceber problemas ao vaguear, como diferenças ou disconexões audio do aplicativo. Isto depende de quanto tempo o processo recolhe a ordem para que o cliente continue a enviar/recebe frames de dados. Este atraso pôde ser mais longo, dependente de: o ambiente RF, a quantidade de clientes, o Round-Trip Time entre o WLC e os regaços e com o Authentication Server, e outras razões.
Estão aqui um sumário das mensagens debugar para este evento vagueando (basicamente o mesmo que precedentes, assim que estas mensagens não é descrito mais):
*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
Esta é a maneira que 802.1X/EAP e a estrutura da Segurança WPA/WPA2 trabalham. A fim impedir o aplicativo/preste serviços de manutenção ao impacto em atrasos de um evento vagueando regular, os métodos vagueando rápido-seguros múltiplos estão desenvolvidos e executados pela indústria de WiFi a fim acelerar o processo vagueando quando a Segurança é usada no WLAN/SSID. Os clientes enfrentam alguma latência quando continuam a passar o tráfego ao vaguear ao redor entre APs através do desenvolvimento da Segurança de nível elevado no WLAN. Isto é devido às trocas do quadro da autenticação de EAP e do gerenciamento chave exigidas pela instalação de segurança, como explicado previamente.
É importante compreender que vaguear rápido-seguro é apenas o termo usado pela indústria na referência à aplicação de um método/esquema que acelere o processo vagueando quando a Segurança é configurada no WLAN. Os métodos/esquemas vagueando rápido-seguros diferentes que estão disponíveis para WLAN, e são apoiados pelo CUWN, são explicados na próxima seção.
Vaguear Rápido-seguro com CCKM
Cisco centralizou o gerenciamento chave (CCKM) é o primeiro método vagueando rápido-seguro desenvolvido e executado na empresa WLAN, criada por Cisco como a solução se usou a fim abrandar os atrasos explicados até aqui, quando a Segurança 802.1X/EAP é usada no WLAN. Porque este é um protocolo de proprietário de Cisco, é apoiado somente por dispositivos de infraestrutura e por clientes Wireless de Cisco WLAN (dos fornecedores múltiplos) que é a extensão compatível de Cisco (CCX) - compatível para o CCKM.
O CCKM pode ser executado com todos os métodos de criptografia diferentes disponíveis para WLAN, para incluir: WEP, TKIP, e AES. É apoiado igualmente com os a maioria dos métodos de autenticação 802.1X/EAP usados para WLAN, dependente da versão CCX apoiada pelos dispositivos.
Esta captação sem fio fornece um exemplo dos quadros trocados em cima da associação inicial quando você executa o CCKM com o TKIP como a criptografia, e do PEAPv0/EAP-MSCHAPv2 como o método 802.1X/EAP. Esta é basicamente a mesma troca como se WPA/TKIP com PEAPv0/EAP-MSCHAPv2 é executado, mas esta vez CCKM entre o cliente e a infraestrutura está negociada de modo que use a hierarquia chave diferente e ponha em esconderijo métodos a fim executar rapidamente vaguear seguro quando o cliente deve vaguear:
Está aqui um sumário das mensagens debugar (com algum EAP troca removido a fim 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 CCKM, a associação inicial ao WLAN é similar ao WPA/WPA2 regular, onde um MSK (igualmente conhecido aqui como a chave de sessão de rede (NSK)) é derivado mutuamente com o cliente e o servidor Radius. Este chave mestre é enviado do server ao WLC após uma autenticação bem sucedida, e posto em esconderijo como a base para a derivação de todas as chaves subsequentes para a vida da associação do cliente com este WLAN. De aqui, os WLC e o cliente derivam a informação da semente que é usada para vaguear rápido-seguro baseado no CCKM, atravessando um aperto de mão 4-Way similar àquele de WPA/WPA2, a fim derivar o unicast (PTK) e chaves de criptografia do Multicast/transmissão (GTK) com o primeiro AP.
A diferença grande é observada ao vaguear. Neste caso, o cliente CCKM envia um único quadro do pedido da reassociação ao AP/WLC (incluindo um MIC e um número aleatório sequencialmente de incremento), e fornece bastante informação (que inclui o MAC address novo AP - BSSID-) a fim derivar o PTK novo. Com este pedido da reassociação, os WLC e o AP novo igualmente têm bastante informação a fim derivar o PTK novo, assim que respondem simplesmente com uma resposta da reassociação. O cliente pode agora continuar a passar o tráfego, segundo as indicações desta captação:
Está aqui um sumário do WLC debuga para este evento vagueando:
*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, vaguear rápido-seguro é executado ao evitar os quadros da autenticação de EAP e ainda mais apertos de mão 4-Way, porque as chaves de criptografia novas são derivadas ainda, mas baseado no esquema da negociação CCKM. Isto é terminado com os quadros vagueando da reassociação e a informação precedente-postos em esconderijo pelo cliente e pelo WLC.
FlexConnect com CCKM
- A autenticação central é apoiada. Isto inclui os dados locais e centrais que swtiching. Os APs devem ser parte do mesmo grupo de FlexConnect.
- A autenticação local do cabo flexível é apoiada. No modo conectado, o esconderijo será distribuído do AP ao controlador e então ao resto dos APs no grupo de FlexConnect.
- O modo autônomo é apoiado. Se o esconderijo está já atual no AP (devido à distribuição precedente), rápido vagueie trabalhará. A autenticação nova no modo autônomo não apoia vaguear rápido-seguro.
Profissionais com CCKM
- O CCKM é o método vagueando rápido-seguro o mais rápido distribuído na maior parte na empresa WLAN. Os clientes não precisam de ir sobre um aperto de mão do gerenciamento chave a fim derivar chaves novas quando um movimento entre APs ocorre, e nunca são exigidos outra vez para executar uma autenticação 802.1X/EAP completa com os APs novos durante a vida do cliente neste WLAN.
- O CCKM apoia todos os métodos de criptografia disponíveis dentro do padrão do 802.11 (WEP, TKIP, e AES), além do que alguns métodos proprietários de Cisco do legado ainda usados em clientes do legado.
Contra com CCKM
- O CCKM é um método proprietário de Cisco, que limite a aplicação e o apoio à infraestrutura de Cisco WLAN e aos clientes Wireless CCX.
- A versão 5 CCX não é adotada extensamente, assim que o CCKM com WPA2/AES não é apoiado por muitos clientes Wireless CCX (principalmente porque a maioria deles já apoio CCKM com WPA/TKIP, que é ainda muito seguro).
Vaguear Rápido-seguro com o PMKID que põe em esconderijo/pôr em esconderijo chave pegajoso
Por pares a identificação do chave mestre (PMKID) que põem em esconderijo, ou a chave pegajosa que põe em esconderijo (SKC), são o primeiro método vagueando rápido-seguro sugerido pelo padrão do IEEE 802.11 dentro da alteração da Segurança 802.11i, onde o propósito principal é estandardizar um alto nível de segurança para WLAN. Esta técnica vagueando rápido-segura foi adicionada enquanto um método opcional para os dispositivos WPA2 a fim melhorar vaguear quando esta Segurança foi executada.
Isto é possível porque, cada vez que um cliente EAP-são autenticados inteiramente, o cliente e o Authentication Server deriva um MSK, que seja usado a fim derivar o PMK. Isto é usado como a semente para o aperto de mão WPA2 4-Way a fim derivar a chave de criptografia final do unicast (PTK) que está usada para a sessão (até que o cliente vagueia a um outro AP ou a sessão expira); daqui, este método impede a fase da autenticação de EAP ao vaguear porque reutilizes o PMK original posto em esconderijo pelo cliente e pelo AP. O cliente somente tem que atravessar o aperto de mão WPA2 4-Way a fim derivar chaves de criptografia novas.
Este método não é distribuído extensamente como o método vagueando rápido-seguro padrão recomendado do 802.11 principalmente devido a estas razões:
- Este método é opcional e não é apoiado por todos os dispositivos WPA2, porque a finalidade da alteração 802.11i não se refere a vaguear rápido-seguro, e a IEEE já estava trabalhando em uma outra alteração para estandardizar vaguear rápido-seguro para WLAN (802.11r, que é coberto mais tarde neste original).
- Este método tem uma limitação grande em sua aplicação: Os clientes Wireless podem somente executar vaguear rápido-seguro ao vaguear de volta a um AP onde previamente autentiquem/conectem.
Com este método, a associação inicial a todo o AP é apenas como uma autenticação principiante regular ao WLAN, onde a autenticação 802.1X/EAP inteira contra o Authentication Server e o aperto de mão 4-Way para a geração chave devem acontecer antes que o cliente possa enviar frames de dados, segundo as indicações desta captura de tela:
Debuga revelam a mesma troca do quadro da autenticação de EAP que o resto dos métodos em cima da autenticação inicial ao WLAN, com algumas saídas adicionadas com respeito à chave que põe em esconderijo as técnicas usadas aqui. Estes resultados do debug são cortados a fim mostrar principalmente a informação nova, não a troca inteira do quadro EAP, porque a mesma informação é trocada basicamente todas as vezes pela autenticação do cliente contra o Authentication Server. Isto é demonstrado até aqui, e correlacionado com os quadros da autenticação de EAP mostrados nas capturas de pacote de informação, a maioria dos mensagens EAP são removidos assim dos resultados do debug para a simplicidade:
*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 este método, o AP e o cliente Wireless põem em esconderijo os PMK das associações seguras já estabelecidas. Consequentemente, se o cliente Wireless vagueia a um AP novo onde nunca associe, o cliente deve executar uma autenticação de EAP completa outra vez, segundo as indicações desta captação sem fio onde o cliente vagueia a um AP novo:
Contudo, se o cliente Wireless vagueia de volta a um AP onde uma associação/autenticação precedentes ocorra, a seguir o cliente envia um quadro do pedido da reassociação que aliste PMKIDs múltiplo, que informa o AP dos PMK postos em esconderijo de todos os APs onde o cliente tem autenticado previamente. Consequentemente, desde que o cliente está vagueando de volta a um AP que igualmente tenha um PMK posto em esconderijo para este cliente, a seguir o cliente não precisa de reauthenticate com o EAP a fim derivar um PMK novo. O cliente atravessa simplesmente o aperto de mão WPA2 4-Way a fim derivar as chaves de criptografia transientes novas:
Está aqui um sumário do WLC debuga para este método vagueando rápido-seguro:
*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 o PMKID que põe em esconderijo/pôr em esconderijo chave pegajoso
- Quando você usa este método em uma instalação de FlexConnect, poderia trabalhar e o comportamento pôde parecer similar ao que foi explicado previamente se você usa a autenticação central de volta ao WLC (com a central ou o switching local); contudo, este método SKC não é apoiado em FlexConnect.
- Este método é apoiado somente oficialmente em CUWN com modo local APs, não em FlexConnect ou em outros modos.
Profissionais com o PMKID que põe em esconderijo/pôr em esconderijo chave pegajoso
Este método pode ser executado localmente por APs autônomo-independentes, sem a necessidade de um dispositivo centralizado de controlar as chaves postas em esconderijo.
Contra com o PMKID que põe em esconderijo/pôr em esconderijo chave pegajoso
- Como mencionado mais cedo neste original, a limitação principal deste método é que o cliente pode somente executar vaguear rápido-seguro ao vaguear de volta a um AP onde associe previamente/autenticado. Se vagueando a um AP novo, o cliente deve terminar a autenticação de EAP completa outra vez.
- O cliente Wireless e os APs devem recordar todos os PMK derivados em cada autenticação nova, assim que esta característica é limitada normalmente a uma certa quantidade de PMK que são postos em esconderijo. Desde que este limite não é definido claramente pelo padrão, os vendedores podem definir limites diferentes em suas aplicações SKC. Por exemplo, os controladores de WLAN de Cisco podem atualmente pôr em esconderijo os PMK de um cliente para até oito APs. Se um cliente vagueia a mais de oito APs pela sessão, os APs os mais velhos estão removidos da lista do esconderijo a fim armazenar as entradas novo-postas em esconderijo.
- Este método é opcional e não é apoiado ainda por muitos dispositivos WPA2; consequentemente, este método não é adotado e é distribuído extensamente.
- SKC não é apoiado quando você executa o intercontroller que vagueia, que ocorre quando você se move entre os APs controlados por WLCs diferente, mesmo se está no mesmo grupo da mobilidade.
Vaguear Rápido-seguro com pôr em esconderijo chave oportunista
Chave oportunista que põe em esconderijo (OKC), igualmente conhecida como pôr em esconderijo dinâmico da chave (PKC) (este termo é explicado em maiores detalhes em uma nota que siga), é basicamente um realce do WPA2 PMKID que põe em esconderijo o método descrito previamente, que é porque é nomeado igualmente Dinâmico/pôr em esconderijo oportunista PMKID. Daqui, é importante notar que este não é um método vagueando rápido-seguro definido pelo padrão do 802.11 e não está apoiado por muitos dispositivos, mas apenas como PMKID que põe em esconderijo, trabalha com WPA2-EAP.
Esta técnica permite que o cliente Wireless e a infraestrutura WLAN ponham em esconderijo somente um PMK para a vida da associação do cliente com este WLAN (derivado do MSK após a autenticação 802.1X/EAP inicial com o Authentication Server), mesmo quando vagueando entre APs múltiplos, porque todos compartilham do PMK original que é usado como a semente em todos os apertos de mão WPA2 4-way. Isto é exigido ainda, apenas porque está em SKC, a fim gerar chaves de criptografia novas cada vez que o cliente reassocia com os APs. Para que os APs compartilhem deste PMK um original da sessão cliente, devem todos estar sob algum meio controle administrativo, com um dispositivo centralizado que ponha em esconderijo e distribua o PMK original para todos os APs. Isto é similar ao CUWN, onde o WLC executa este trabalho para todos os regaços sob seu controle, e usa os Grupos de mobilidade a fim segurar este PMK entre WLCs múltiplo; consequentemente, esta é uma limitação em ambientes autônomos AP.
Com este método, apenas como em PMKID que põe em esconderijo (SKC), a associação inicial a todo o AP é uma autenticação principiante regular ao WLAN, onde você deve terminar a autenticação 802.1X/EAP inteira contra o Authentication Server e o aperto de mão 4-Way para a geração chave antes que você possa enviar frames de dados. Está aqui uma captura de tela que ilustre esta:
Os resultados do debug mostram basicamente a mesma troca do quadro da autenticação de EAP que o resto dos métodos descritos neste original em cima da autenticação inicial ao WLAN (segundo as indicações das captações), junto com a adição de algumas saídas que se referem à chave que põe em esconderijo as técnicas usadas pelo WLC aqui. Este resultado do debug é cortado igualmente a fim mostrar somente a informação relevante:
*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 este método, o cliente Wireless e os WLC (para todos os APs controlados) põem em esconderijo o um PMK original da associação segura que é estabelecida inicialmente. Basicamente, cada vez que o cliente Wireless conecta a um AP específico, um PMKID é picado baseou sobre: o endereço MAC de cliente, o MAC address AP (BSSID do WLAN), e o PMK derivado com esse AP. Consequentemente, desde que OKC põe em esconderijo o mesmo PMK original para todos os APs e o cliente específico, quando este cliente (com referência a) associar a um outro AP, o único valor que as mudanças a fim picar o PMKID novo são o MAC address novo AP.
Quando o cliente inicia vaguear a um AP novo e envia o quadro do pedido da reassociação, adiciona o PMKID no elemento de informação WPA2 RSN se quer informar o AP que um PMK posto em esconderijo está usado para vaguear rápido-seguro; enquanto já conhece o MAC address do BSSID (AP) para onde vagueia, a seguir o cliente pica simplesmente o PMKID novo que é usado neste pedido da reassociação. Quando o AP recebe este pedido do cliente, igualmente pica o PMKID com os valores que já tem (o PMK posto em esconderijo, o endereço MAC de cliente, e seu próprio MAC address AP), e responde com a resposta bem sucedida da reassociação que confirma o PMKIDs combinou. O PMK posto em esconderijo pode ser usado como a semente que começa um aperto de mão WPA2 4-Way a fim derivar as chaves de criptografia novas (EAP de salto):
Nesta captação, o quadro do pedido da reassociação do cliente é selecionado e expandido de modo que você possa ver mais detalhes do quadro. A informação do MAC address e igualmente o elemento de informação da rede da segurança robusta (RSN, conforme 802.11i – WPA2), onde a informação sobre os ajustes WPA2 usados para esta associação é mostrada (destacado são o PMKID obtido da fórmula picada).
Está aqui um sumário de WLC debuga para este método vagueando rápido-seguro 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 do debuga, o PMKID deve ser computado depois que o pedido da reassociação do cliente é recebido. Isto é precisado a fim validar o PMKID e confirmar que o PMK posto em esconderijo está usado com o aperto de mão WPA2 4-Way para derivar as chaves de criptografia e para terminar vaguear rápido-seguro. Não confunda as entradas CCKM no debuga; isto não é usado a fim executar o CCKM, mas o OKC, como explicado previamente. O CCKM aqui é simplesmente um nome usado pelo WLC para aquelas saídas, tais como o nome de uma função que segure os valores a fim computar o PMKID.
FlexConnect com pôr em esconderijo chave oportunista
- A autenticação central é apoiada. Isto inclui o interruptor local e central dos dados. Se o AP é parte do mesmo grupo de FlexConnect, rápido-seguro vagueie é pelo AP, mais rápido-seguro vagueiam é pelo controlador.
- A autenticação local do cabo flexível é apoiada. No modo conectado, o esconderijo será distribuído do AP ao controlador e então ao resto dos APs no grupo de FlexConnect.
- O modo autônomo é apoiado. Se o esconderijo está já atual no AP (devido à distribuição precedente), rápido-seguro vagueie trabalhará. A autenticação nova no modo autônomo não apoia vaguear rápido-seguro.
Profissionais com pôr em esconderijo chave oportunista
- O cliente Wireless e a infraestrutura WLAN não precisam de recordar PMKIDs múltiplo, mas põem em esconderijo simplesmente o um PMK original da autenticação inicial ao WLAN. Então você deve repetir o PMKID apropriado (usado no pedido da reassociação) exigido com cada associação segura AP a fim validar vaguear rápido-seguro.
- Aqui, o cliente Wireless executa vaguear rápido-seguro a um AP novo no mesmo WLAN/SSID, mesmo se nunca associou com esse AP (não o caso em SKC). Enquanto o cliente executa a autenticação 802.1X/EAP inicial com o um AP controlado pelo desenvolvimento centralizado que segura o esconderijo PMK para todos os APs para onde o cliente vagueia, a seguir não mais autenticação completa é exigida para o resto da vida do cliente neste WLAN.
Contra com pôr em esconderijo chave oportunista
- Este método é distribuído somente em um ambiente centralizado onde todos os APs estejam sob algum meio controle administrativo (tal como um controlador de WLAN) que é responsável para pôr em esconderijo e compartilhar do um PMK original da sessão cliente. Consequentemente, esta é uma limitação em ambientes autônomos AP.
- As técnicas que são aplicadas neste método não são sugeridas nem são descritas no padrão do 802.11, assim que no apoio variam extensamente de um dispositivo a outro. Não obstante, este é ainda o método que era mais adotado ao esperar 802.11r.
Note sobre o termo “pôr em esconderijo dinâmico da chave”
Pôr em esconderijo dinâmico da chave (ou PKC) foram sabidos como OKC (chave oportunista que põe em esconderijo), e os dois termos foram usados permutavelmente ao descrever o mesmo método explicado aqui. Contudo, este era apenas um termo que fosse usado pelo espaço aéreo em 2001 para um método pondo em esconderijo chave velho, que fosse usado então pelo padrão 802.11i como a base para “Pré-autenticação” (um outro método vagueando seguro rápido explicado momentaneamente abaixo). PKC não é Pré-autenticação ou OKC (chave oportunista que põe em esconderijo), mas quando você se ouve ou se lê sobre PKC, a referência é basicamente a OKC, e não a Pré-autenticação.
Vaguear Rápido-seguro com Pré-autenticação
Este método é sugerido igualmente pelo padrão do IEEE 802.11 dentro da alteração da Segurança 802.11i, assim que igualmente trabalha com WPA2, mas é o único método vagueando seguro rápido que não é apoiado por infra-estruturas de Cisco WLAN. Por este motivo, é explicado somente momentaneamente aqui e sem saídas.
Com Pré-autenticação, os clientes Wireless podem autenticar com APs múltiplos em um momento quando associados com o AP atual. Quando isto ocorre, o cliente envia os quadros da autenticação de EAP ao AP atual onde é conectado, mas é destinado ao outro AP onde o cliente quer executar Pré-autenticação (vizinho APs que é candidatos possíveis para vaguear). O AP atual envia estes quadros ao alvo AP sobre o sistema de distribuição. O AP novo executa a autenticação completa contra o servidor Radius para este cliente, assim que um aperto de mão novo inteiro da autenticação de EAP é terminado, e este AP novo atua como o autenticador.
A ideia é executar a autenticação e derivar o PMK com o vizinho APs antes que o cliente lhes vagueie realmente, assim que quando é hora de vaguear, o cliente está autenticado já e com um PMK já posto em esconderijo para esta associação segura do AP-à-cliente novo, assim que precisam somente de executar o aperto de mão 4-Way e para experimentar um rápido vagueie depois que o cliente envia seu pedido inicial da reassociação.
Está aqui uma captação da baliza de um AP que mostra o campo IE RSN que anuncia o apoio para Pré-autenticação (este é de Cisco AP, onde se confirma que Pré-autenticação não está apoiado):
Profissionais com Pré-autenticação
Há um PMK para cada associação segura do AP-à-cliente, que poderia ser considerada umas vantagens de segurança caso que um AP é comprometido e as chaves se tornam roubadas (não pode ser usado com outros APs). Contudo, estas vantagens de segurança são seguradas pela infraestrutura WLAN em maneiras diferentes em outros métodos.
Contra com Pré-autenticação
- Porque há um PMK pelo AP, os clientes têm um limite na quantidade de APs que podem PRE-ser autenticados.
- Cada vez que um cliente executa Pré-autenticação com um AP novo, há uma troca completa da autenticação de EAP, que signifique mais carga na rede e no Authentication Server.
- A maioria de clientes Wireless não apoiam este método, como este nunca foi adotado altamente (OKC era mais adotado).
Vaguear Rápido-seguro com 802.11r
A técnica vagueando rápido-segura baseada na alteração 802.11r (nomeada oficialmente transição de Rápido BSS pelo padrão do 802.11, e conhecida como o FT) é o primeiro método ratificado oficialmente (em 2008) pela IEEE para o padrão do 802.11 como a solução para executar transições rápidas entre APs (grupos ou BSSs do serviço básico), que define claramente a hierarquia chave que é usada quando você segura e põe em esconderijo chaves em um WLAN. Contudo, sua adoção foi lenta, principalmente devido às outras soluções já disponíveis quando as transições rápidas foram exigidas realmente, como com aplicações de VoWLAN quando usada com um dos métodos explicados previamente neste original. Há somente alguns dispositivos que apoiam atualmente algumas das opções FT (por 2013).
Esta técnica é mais complexa explicar do que os outros métodos, enquanto introduz novos conceitos e camadas múltiplas de PMK que estão postos em esconderijo nos dispositivos diferentes (cada dispositivo com um papel diferente), e fornece ainda mais opções para vaguear rápido-seguro. Consequentemente, um sumário breve é fornecido sobre este método e a maneira que é executado com cada opção disponível.
802.11r é diferente de SKC e de OKC, primeiramente devido a estas razões:
- A Mensagem do aperto de mão (troca PMKID, de ANonce, e de SNonce, por exemplo) acontece em quadros da autenticação do 802.11 ou em quadros de ação em vez dos quadros da reassociação. Ao contrário de PMKID que põe em esconderijo métodos, a fase separada do aperto de mão 4-Way, que é levada depois que (com referência a) a troca da mensagem da associação, é evitada. O aperto de mão chave com o AP novo começa antes que o cliente inteiramente vagueie/reassocie com este AP novo.
- Fornece dois métodos para o aperto de mão rápido-vagueando: sobre o AR, e sobre o sistema de distribuição (DS).
- 802.11r tem mais camadas da hierarquia chave.
- Enquanto este protocolo evita o aperto de mão 4-Way para o gerenciamento chave quando um cliente vagueia (gerencie chaves de criptografia novas - PTK e GTK- sem a necessidade deste aperto de mão), pode igualmente ser aplicado para as instalações WPA2 com um PSK, e não somente quando 802.1X/EAP é usado para a autenticação. Isto acelera vaguear ainda mais para estas instalações, onde nenhuma troca do aperto de mão EAP ou 4-Way ocorre.
Com este método, o cliente Wireless executa apenas uma autenticação inicial contra a infraestrutura WLAN quando uma conexão é estabelecida ao primeiro AP, e executa vaguear rápido-seguro ao vaguear entre APs do mesmo domínio da mobilidade FT.
Este é um dos novos conceitos, que refere basicamente os APs que usam o mesmo SSID (conhecido como um serviço extendido ajustado ou ESS) e seguram as mesmas chaves FT. Isto é similar aos outros métodos explicados até aqui. A maneira que os APs seguram as chaves do domínio da mobilidade FT é baseada normalmente em uma instalação centralizada, tal como o WLC ou os Grupos de mobilidade; contudo, este método pode igualmente ser executado em ambientes autônomos AP.
Está aqui um sumário da hierarquia chave:
- Um MSK é derivado ainda no suplicante do cliente e no Authentication Server da fase de autenticação 802.1X/EAP inicial (transferida do Authentication Server ao autenticador (WLC) uma vez que a autenticação é bem sucedida). Este MSK, como nos outros métodos, é usado como a semente para a hierarquia da chave FT. Quando você usa WPA2-PSK em vez de um método de autenticação de EAP, o PSK é basicamente este MSK.
- Um R0 do chave mestre (PMK-R0) é derivado por pares do MSK, que é a chave do primeiro nível da hierarquia da chave FT. Os suportes chaves para este PMK-R0 são os WLC e o cliente.
- Uma chave do nível secundário, chamada por pares um chave mestre R1 (PMK-R1), é derivada do PMK-R0, e os suportes chaves são o cliente e os APs controlados pelo WLC que guarda o PMK-R0.
- A chave do terço e do nível final da hierarquia da chave FT é o PTK, que é a chave final usada a fim cifrar os frames de dados do unicast do 802.11 (similares aos outros métodos que usam WPA/TKIP ou WPA2/AES). Este PTK é derivado no FT do PMK-R1, e os suportes chaves são o cliente e os APs controlados pelo WLC.
Transição rápida BSS sobre - Ar
Com este método, a primeira associação a todo o AP é uma autenticação principiante regular ao WLAN, onde a autenticação 802.1X/EAP inteira contra o Authentication Server e o aperto de mão 4-Way para a geração chave devem ocorrer antes que os frames de dados estejam enviados, segundo as indicações desta captura de tela:
Os principais diferença são:
- A negociação do Gerenciamento de chave de autenticação é levemente diferente do que WPA/WPA2 regular, assim que alguma informação extra está usada a fim executar esta negociação quando a associação a uma infraestrutura WLAN que apoie o FT ocorre. Segundo as indicações da captação, o quadro do pedido da associação do cliente é selecionado e o campo AKM do elemento de informação de RNS é destacado a fim mostrar que este cliente quer executar o FT sobre 802.1X/EAP.
- Igualmente é mostrado o elemento de informação de domínio da mobilidade (parte de FT), onde a capacidade FT e campo da política indica se a transição rápida BSS está terminada sobre - areje ou sobre - o DS quando vaguear rápido (que indica sobre - areje nesta captação).
- Um outro elemento de informação é adicionado igualmente (o IE rápido da transição ou FT BSS, que é descrito mais tarde neste original) com informação que é exigida a fim executar a sequência da autenticação FT quando FT que vagueia.
- A geração chave é diferente devido à hierarquia chave, assim que mesmo que o aperto de mão FT 4-Way olhe similar ao aperto de mão WPA/WPA2 4-Way, é realmente levemente diferente no índice.
Debuga a mostra basicamente a mesma troca do quadro da autenticação de EAP que o resto dos métodos em cima da autenticação inicial ao WLAN (como observado das captações), mas algumas saídas que se referem à chave que põe em esconderijo as técnicas usadas pelo WLC são adicionadas; assim, este resultado do debug é cortado a fim mostrar somente a informação relevante:
*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 captações e debugam de uma associação inicial ao WLAN quando você executa o FT com o WPA2-PSK (em vez de um método 802.1X/EAP), onde o frame de resposta da associação do AP está selecionado a fim mostrar o elemento de informação rápido da transição BSS (destacado). Alguma da informação chave necessária a fim executar o aperto de mão FT 4-Way é mostrada igualmente:
*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 802.11r, a associação inicial ao WLAN é a base usada a fim derivar as chaves baixas usadas por esta técnica, apenas como nos outros métodos vagueando rápido-seguros. Os principais diferença vêm quando o cliente começa a vaguear; O FT evita não somente 802.1X/EAP quando este é usado, mas executa realmente um método vagueando dos mais eficiente que combine os quadros iniciais da autenticação e da reassociação do sistema aberto do 802.11 (que sempre são usados e exigidos ao vaguear entre APs) a fim trocar a informação FT e derivar chaves de criptografia dinâmicas novas no lugar do aperto de mão 4-Way.
A captação seguinte mostra os quadros trocados quando uma transição rápida BSS sobre - o ar com Segurança 802.1X/EAP é executado. O quadro da autenticação do sistema aberto do cliente ao AP é selecionado a fim considerar os elementos de informação de protocolo FT que são exigidos para começar a negociação da chave FT. Isto é usado a fim derivar o PTK novo com o AP novo (baseado no PMK-R1). O campo que mostra o algoritmo de autenticação é destacado a fim mostrar que este cliente não executa uma autenticação do sistema aberto simples, mas uma transição rápida BSS:
Estão aqui os resultados do debug do WLC quando este evento vagueando FT ocorre com 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
Está aqui uma captação que mostre uma transição rápida BSS sobre - areja com Segurança WPA2-PSK, onde o frame de resposta final da reassociação do AP ao cliente é selecionado a fim mostrar mais detalhes sobre esta troca FT:
Estão aqui os resultados do debug quando este evento vagueando FT ocorre com PSK, que são similares a esses quando 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
Segundo as indicações da captação, uma vez que a transição rápida BSS é negociada em cima da associação inicial ao WLAN, os quatro quadros que estão usados e exigido para vaguear (autenticação do sistema aberto do cliente, autenticação do sistema aberto do AP, pedido da reassociação, e resposta da reassociação) estão usados basicamente enquanto um aperto de mão FT 4-Way a fim derivar o PTK novo (chave de criptografia do unicast) e GTK (chave de criptografia do Multicast/transmissão).
Isto substitui para o aperto de mão 4-Way que ocorre normalmente depois que estes quadros são trocados, e a negociação do índice e da chave FT nestes quadros é basicamente a mesma se você usa 802.1X/EAP ou PSK como o método da Segurança. Segundo as indicações da captação, o campo AKM é o principal diferença, que confirma se o cliente executa o FT com o PSK ou o 802.1X. Consequentemente, é importante notar que estes quatro quadros normalmente não têm este tipo de informação de segurança para a negociação chave, mas somente quando o cliente FT vagueia se 802.11r está executado e negociado entre o cliente e a infraestrutura WLAN em cima da associação inicial.
Transição rápida BSS sobre - DS
802.11r permite uma outra aplicação da transição rápida BSS, onde o FT que vagueia é iniciado pelo cliente com o AP novo para que o cliente vagueia sobre - DS (sistema de distribuição), e não sobre - o ar. Neste caso, os quadros de ação FT são usados a fim iniciar a negociação chave em vez dos quadros da autenticação do sistema aberto.
Basicamente, uma vez que o cliente decide pôde vaguear a um AP melhor, o cliente envia um quadro da requisição de ação FT ao AP original onde é conectada atualmente antes de vaguear. O cliente indica que o BSSID (MAC address) do alvo AP onde quer ao FT vagueie. O AP original para a frente este quadro da requisição de ação FT ao alvo AP sobre o sistema de distribuição (normalmente a infraestrutura ligada com fio), e o alvo AP respondem ao cliente com um frame de resposta de ação FT (também sobre o DS, assim que ele pode finalmente o enviar sobre - areje ao cliente). Uma vez que esta troca do quadro de ação FT é bem sucedida, o cliente termina o FT que vagueia; o cliente envia o pedido da reassociação ao alvo AP (esta vez sobre - o ar), e recebe uma resposta da reassociação do AP novo a fim confirmar a derivação das chaves vaguear e de final.
Em resumo, há quatro quadros para negociar a transição rápida BSS e para derivar chaves de criptografia novas, mas os quadros da autenticação do sistema aberto são substituídos aqui com a requisição de ação/frames de resposta FT, que são trocados com o alvo AP sobre o sistema de distribuição com o AP atual. Este método é igualmente válido para os métodos 802.1X/EAP da Segurança e o PSK, apoiado toda pelos controladores de LAN do Cisco Wireless; contudo, desde isto sobre - A transição DS não é apoiada e executado pela maioria dos clientes Wireless na indústria de WiFi (e desde que a troca e os resultados do debug do quadro são basicamente a mesma), os exemplos não são fornecidos neste original. Em lugar de, esta imagem é usada a fim visualizar a transição rápida BSS sobre - o DS:
FlexConnect com 802.11r
- A autenticação central é apoiada. Isto inclui o interruptor local e central dos dados. Os APs devem ser parte do mesmo grupo de FlexConnect.
- A autenticação local não é apoiada.
- O modo autônomo não é apoiado.
Profissionais com 802.11r
- Este método é o primeiro esse usos uma hierarquia chave definida claramente pela IEEE no padrão do 802.11 como uma alteração (802.11r), assim que a aplicação destas técnicas FT é mais compatível entre vendedores e sem interpretações diferentes.
- 802.11r permite as técnicas múltiplas que são úteis, dependentes de suas necessidades (sobre - areje e sobre - o DS, para a Segurança 802.1x/EAP e para a Segurança PSK).
- O cliente Wireless executa vaguear rápido-seguro a um AP novo no mesmo WLAN/SSID, mesmo se nunca associou com esse AP, e sem a necessidade de salvar PMKIDs múltiplo.
- Este é o primeiro método vagueando rápido-seguro que reserva mais rapidamente vaguear mesmo com Segurança PSK, e evita o aperto de mão 4-Way que é exigido ao vaguear entre APs com WPA/WPA2 PSK. O propósito principal dos métodos vagueando rápido-seguros é evitar o aperto de mão 802.1X/EAP quando este método da Segurança é executado; contudo, porque Segurança PSK o evento vagueando é acelerado ainda mais com o 802.11r evitando o aperto de mão 4-Way.
Contra com 802.11r
- Há alguns dispositivos do cliente Wireless que apoiam realmente transições rápidas BSS, e na maioria dos casos, não apoiam todas as técnicas disponíveis em 802.11r.
- Devido ao fato de que estas aplicações são muito novas, não há bastante resultados de teste dos ambientes da real-produção ou bastante debugam resultados a fim endereçar as advertências possíveis que puderam aparecer.
- Quando você configura um WLAN/SSID a fim usar alguns dos métodos FT, a seguir somente os clientes Wireless que apoiam 802.11r podem conectar a este WLAN/SSID. Os ajustes FT não são opcionais para os clientes, assim aqueles clientes Wireless que não apoiam 802.11r devem conectar com um WLAN/SSID separado onde o FT não seja configurado de todo.
802.11r adaptável
- Alguns clientes do legado não podem associar com um WLAN/SSID que tenha 802.11r permitido mesmo para “o modo misturado” (que você espera que você pode ter nos mesmos clientes SSID que apoiam e que não apoiam 802.11r). Isto é quando o direcionador do suplicante do cliente que é responsável para analisar gramaticalmente o elemento de informação de rede da segurança robusta (IE RSN) está idoso e não ciente das séries adicionais AKM no IE. Devido a esta limitação, os clientes não podem enviar pedidos da associação aos WLAN que anunciam o apoio 802.11r, e daqui, você precisará provavelmente de configurar um WLAN/SSID para os clientes 802.11r e um WLAN/SSID separado para os clientes que não apoiam 802.11r.
-
A fim superar isto, o infra-estruturo de LAN do Cisco Wireless introduziu a característica 802.11r adaptável. Quando o modo FT é ajustado a adaptável a nível WLAN, o WLAN anuncia a identificação do domínio da mobilidade 802.11r em um 802.11i-enabled WLAN. Alguns dispositivos do cliente de Apple iOS10 identificam a presença de MDIE em um 80211i/WPA2 WLAN e fazem um aperto de mão proprietário a fim estabelecer a associação 802.11r. Uma vez que o cliente termina a associação 802.11r bem sucedida, poderá fazer o FT que vagueia como em um WLAN permitido 802.11r normal. O FT adaptável é somente dispositivos selecionados aplicáveis de Apple iOS10 (e mais tarde). Todos clientes restantes continuarão a ter a associação 802.11i/WPA2 no WLAN, e executam o método aplicável FSR como apoiado.
-
Mais documentação sobre estes novos recursos introduzidos para que os dispositivos iOS10 executem 802.11r em um WLAN/SSID onde 802.11r não seja permitido verdadeiramente (assim que outros clientes non-802.11r conectarão com sucesso), pode ser encontrada em melhores prática da empresa para dispositivos iOS no Cisco Wireless LAN.
Conclusões
- Mantenha na mente que o cliente é sempre esse que decide vaguear a um AP específico, e o WLC/AP não pode decidir este para o cliente. O evento vagueando está iniciado pelo cliente Wireless uma vez que o considerar vagueia.
- O WLC apoia uma combinação da maioria ou de todos os métodos FSR (vaguear Rápido-seguro) junto no mesmo WLAN/SSID. Contudo, esteja ciente que isto normalmente não trabalha, porque depende altamente do comportamento do cliente (muito diferente através dos dispositivos móvéis diferentes) a fim apoiar ou mesmo compreender isso que o WLC tenta anunciar como apoiado. Em vez de conseguir a Interoperabilidade em apenas um SSID, há normalmente mais edições do que essas que são esperadas ser fixadas, assim que esta não é recomendada. Os testes profundos com todos os clientes possíveis a ser usados neste WLAN devem ser terminados se este é precisado realmente.
- É muito importante compreender que os métodos vagueando rápido-seguros estão desenvolvidos a fim acelerar o processo vagueando WLAN quando você se move entre APs se o WLAN/SSID tem a Segurança permitida. Quando nenhuma Segurança é no lugar, não há nada acelerar, porque o cliente-AP troca simplesmente os quadros sem fio do Gerenciamento que estão exigidos sempre ao vaguear entre APs antes que os frames de dados estejam enviados (autenticação do sistema aberto do cliente, autenticação do sistema aberto do AP, pedido da reassociação, e resposta da reassociação). Consequentemente, isto não pode mover-se mais rapidamente. Se você encontra edições vagueando sem Segurança, a seguir não há nenhum método rápido-vagueando para melhorar vaguear, simplesmente métodos a fim confirmar se a instalação e o projeto WLAN/SSID são apropriados para que as estações do cliente Wireless vagueiem em conformidade entre as pilhas da cobertura AP.
- 802.11r/FT é executado com WPA2-PSK a fim acelerar eventos vagueando com esta Segurança evitando o aperto de mão 4-Way, como explicado dentro da seção 802.11r.
- Todos os métodos têm suas vantagens e desvantagem, mas na extremidade, você deve sempre verificar se as estações do cliente Wireless apoiam o método específico que você quer executar, e se a infraestrutura de Cisco WLAN apoia todos os métodos disponíveis. Assim, você deve selecionar o melhor método que é apoiado realmente pelos clientes Wireless que conectam ao WLAN/SSID específico. Por exemplo, em algumas disposições você pôde criar um WLAN/SSID com o CCKM para Telefones IP do Cisco Wireless (que apoie WPA2/AES com CCKM, mas não 802.11r), e então um outro WLAN/SSID com o WPA2/AES através de 802.11r/FT para os clientes Wireless que apoiam este método vagueando seguro rápido (ou use OKC, se este é o que está apoiado).
- Se os clientes Wireless não apoiam alguns dos métodos vagueando rápido-seguros disponíveis, a seguir você pôde precisar de aceitar o fato de que aqueles clientes experimentarão sempre os atrasos explicados neste original ao vaguear entre APs em um WLAN/SSID com a Segurança 802.1X/EAP (que pode causar rompimentos nos apps/serviços do cliente).
- Todos os métodos, exceto SKC (WPA2 PMKID que põe em esconderijo), são apoiados para vaguear rápido-seguro entre os APs controlados por WLCs diferente (intercontroller que vagueia), enquanto estão no mesmo grupo da mobilidade.
- CUWN apoia inteiramente todos os métodos vagueando Rápido-seguros diferentes cobertos neste artigo ao usar a autenticação 802.1X/EAP para WPA/WPA2. CUWN não apoia vaguear Rápido-seguro nos métodos que trabalham com WPA2-RSN (CCKM, PMKID Caching/SKC, OKC/PKC) ao usar PSK (WPA2-Personal), onde os métodos Rápido-vagueando não são precisados na maior parte. Contudo, CUWN apoia vaguear Rápido-seguro no caso de WPA2-FT (802.11r) com PSK como igualmente explicado neste artigo.
Informações Relacionadas
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)