Implementações e comportamento da fragmentação EAP

Introduction

Este documento descreve como entender e solucionar problemas de sessões do Extensible Authentication Protocol (EAP). Essas questões são discutidas:

• Comportamento dos servidores de Autenticação, Autorização e Contabilidade (AAA - Authentication, Authorization, and Accounting) quando eles retornam o Certificado do Servidor para a sessão EAP-TLS (Extensible Authentication Protocol-Transport Layer Security)
• Comportamento dos requerentes quando eles devolvem o certificado do cliente para a sessão EAP-TLS
• Interoperabilidade quando o Microsoft Windows Native Supplicant e o Cisco AnyConnect Network Access Manager (NAM) são usados
• Fragmentação em IP, RADIUS e EAP-TLS e processo de remontagem executados por dispositivos de acesso à rede
• O atributo RADIUS Framed-Maximum Transmission Unit (MTU)
• Comportamento dos servidores AAA quando executam fragmentação de pacotes EAP-TLS

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Protocolos EAP e EAP-TLS
• Configuração do Cisco Identity Services Engine (ISE)
• Configuração CLI de switches Cisco Catalyst

É necessário ter um bom entendimento do EAP e do EAP-TLS para entender este artigo.

Cadeia de certificados devolvida pelo servidor

O servidor AAA (Access Control Server (ACS) e ISE) sempre retorna a cadeia completa do pacote EAP-TLS com o Server Hello e o Server Certificate:

O certificado de identidade do ISE (Common Name (CN)=lise.example.com) é devolvido junto com a Certificate Authority (CA) que assinou o CN=win2012,dc=example,dc=com. O comportamento é o mesmo para ACS e ISE.

Cadeia de certificados devolvida pelo requerente

Requerente Nativo do Microsoft Windows

O suplicante nativo do Microsoft Windows 7 configurado para usar EAP-TLS, com ou sem a "seleção de certificado simples", não envia a cadeia completa do certificado do cliente. Esse comportamento ocorre mesmo quando o certificado do cliente é assinado por uma CA (cadeia diferente) diferente do certificado do servidor.

Este exemplo está relacionado ao Certificado e Saudação do Servidor apresentado na captura de tela anterior.Para esse cenário, o certificado do ISE é assinado pela CA com o uso de um nome de assunto, CN=win2012,dc=example,dc=com. Mas o certificado de usuário instalado no repositório da Microsoft é assinado por uma CA diferente, CN=CA,C=PL,S=Cisco CA,L=Cisco CA, O=Cisco CA.

Como resultado, o requerente do Microsoft Windows responde somente com o certificado do cliente. A CA que assina (CN=CA,S=PL,S=Cisco CA, L=Cisco CA, O=Cisco CA) não está anexada.

Por causa desse comportamento, os servidores AAA podem encontrar problemas quando validam certificados de cliente. O exemplo está relacionado ao Microsoft Windows 7 SP1 Professional.

Solução

Uma cadeia de certificados completa deve ser instalada no armazenamento de certificados do ACS e do ISE (todos os certificados de cliente de assinatura CA e sub CA).

Problemas com validação de certificado podem ser facilmente detectados no ACS ou no ISE. As informações sobre o certificado não confiável são apresentadas e os relatórios do ISE:

12514 EAP-TLS failed SSL/TLS handshake because of an unknown CA in the client
certificates chain

Problemas com validação de certificado no requerente não são facilmente detectáveis. Geralmente, o servidor AAA responde que "Endpoint abondoned EAP session":

NAM do AnyConnect

O AnyConnect NAM não tem essa limitação. No mesmo cenário, ele anexa a cadeia completa do certificado do cliente (a CA correta está anexada):

Microsoft Windows Native Supplicant junto com AnyConnect NAM

Quando os dois serviços estão ativos, o AnyConnect NAM tem precedência. Mesmo quando o serviço NAM não é executado, ele ainda ganha na API do Microsoft Windows e encaminha os pacotes EAP, o que pode causar problemas para o suplicante nativo do Microsoft Windows. Aqui está um exemplo de tal falha.

Você ativa o rastreamento no Microsoft Windows com este comando:

C:\netsh ras set tracing * enable

Os vestígios (c:\windows\trace\svchost_RASTLS.LOG) mostram:

[2916] 09-14 21:29:11:254: >> Received Request (Code: 1) packet: Id: 55, Length:
6, Type: 13, TLS blob length: 0. Flags: S
[2916] 09-14 21:29:11:254: << Sending Response (Code: 2) packet: Id: 55, Length:
105, Type: 13, TLS blob length: 95. Flags: L
[1804] 09-14 21:29:11:301: >> Received Request (Code: 1) packet: Id: 56, Length:
1012, Type: 13, TLS blob length: 2342. Flags: LM
[1804] 09-14 21:29:11:301: << Sending Response (Code: 2) packet: Id: 56, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[1804] 09-14 21:29:11:348: >> Received Request (Code: 1) packet: Id: 57, Length:
1008, Type: 13, TLS blob length: 0. Flags: M
[1804] 09-14 21:29:11:348: << Sending Response (Code: 2) packet: Id: 57, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[1804] 09-14 21:29:11:363: >> Received Request (Code: 1) packet: Id: 58, Length:
344, Type: 13, TLS blob length: 0. Flags: 
[1804] 09-14 21:29:11:363: << Sending Response (Code: 2) packet: Id: 58, Length:
1492, Type: 13, TLS blob length: 1819. Flags: LM
[3084] 09-14 21:31:11:203: >> Received Request (Code: 1) packet: Id: 122, Length:
6, Type: 13, TLS blob length: 0. Flags: S
[3084] 09-14 21:31:11:218: << Sending Response (Code: 2) packet: Id: 122, Length:
105, Type: 13, TLS blob length: 95. Flags: L
[3420] 09-14 21:31:11:249: >> Received Request (Code: 1) packet: Id: 123, Length:
1012, Type: 13, TLS blob length: 2342. Flags: LM
[3420] 09-14 21:31:11:249: << Sending Response (Code: 2) packet: Id: 123, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[3420] 09-14 21:31:11:281: >> Received Request (Code: 1) packet: Id: 124, Length:
1008, Type: 13, TLS blob length: 0. Flags: M
[3420] 09-14 21:31:11:281: << Sending Response (Code: 2) packet: Id: 124, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[3420] 09-14 21:31:11:281: >> Received Request (Code: 1) packet: Id: 125, Length:
344, Type: 13, TLS blob length: 0. Flags: 
[3420] 09-14 21:31:11:296: << Sending Response (Code: 2) packet: Id: 125, Length:
1492, Type: 13, TLS blob length: 1819. Flags: LM

O último pacote é um Certificado do Cliente (fragmento 1 EAP-TLS com tamanho EAP 1492) enviado pelo suplicante Nativo do Microsoft Windows. Infelizmente, o Wireshark não mostra esse pacote:

E esse pacote não é realmente enviado (o último foi o terceiro fragmento do certificado do servidor de transporte EAP-TLS). Ele foi consumido pelo módulo AnyConnect NAM que se conecta à API do Microsoft Windows.

Por isso, não é aconselhável usar o AnyConnect junto com o suplicante nativo do Microsoft Windows. Quando você usa qualquer serviço do AnyConnect, recomenda-se usar o NAM também (quando os serviços 802.1x são necessários), não o Microsoft Windows Native Supplicant.

Fragmentação

A fragmentação pode ocorrer em várias camadas:

• IP
• Pares de valor de atributo RADIUS (AVP)
• EAP-TLS

Os switches Cisco IOS^® são muito inteligentes. Eles podem entender os formatos EAP e EAP-TLS. Embora o switch não seja capaz de descriptografar o túnel TLS, ele é responsável pela fragmentação e pela montagem e remontagem dos pacotes EAP quando o encapsulamento é em Extensible Authentication Protocol over LAN (EAPoL) ou RADIUS.

O protocolo EAP não suporta fragmentação. Aqui está um trecho do RFC 3748 (EAP):

"A fragmentação não é suportada no próprio PEA; no entanto, os métodos EAP individuais podem suportar isto."

EAP-TLS é um exemplo desses. Aqui está um trecho do RFC 5216 (EAP-TLS), seção 2.1.5 (fragmentação):

"Quando um peer EAP-TLS recebe um pacote EAP-Request com o bit M definido, ele DEVE responder com uma Resposta EAP com EAP-Type=EAP-TLS e sem dados. Isso serve como um fragmento ACK. O servidor EAP DEVE aguardar até receber a Resposta EAP antes de enviar outro fragmento."

A última frase descreve um recurso muito importante dos servidores AAA. Eles devem esperar pelo ACK antes de enviar outro fragmento EAP. Uma regra semelhante é usada para o requerente:

"O peer EAP DEVE aguardar até receber a solicitação EAP antes de enviar outro fragmento."

Fragmentação na Camada IP

A fragmentação só pode ocorrer entre o Network Access Device (NAD) e o servidor AAA (IP/UDP/RADIUS usado como transporte). Essa situação ocorre quando o NAD (switch Cisco IOS) tenta enviar a solicitação RADIUS que contém o payload EAP, que é maior que o MTU da interface:

A maioria das versões do Cisco IOS não são inteligentes o suficiente e não tentam montar pacotes EAP recebidos via EAPoL e combiná-los em um pacote RADIUS que pode se ajustar à MTU da interface física para o servidor AAA.

Os servidores AAA são mais inteligentes (conforme apresentado nas próximas seções).

Fragmentação em RADIUS

Não se trata, na verdade, de qualquer tipo de fragmentação. De acordo com o RFC 2865, um único atributo RADIUS pode ter até 253 bytes de dados.Por causa disso, o payload EAP é sempre transmitido em vários atributos RADIUS de mensagem EAP:

Esses atributos EAP-Message são remontados e interpretados pelo Wireshark (o atributo "Último segmento" revela o payload de todo o pacote EAP). O cabeçalho Length no pacote EAP é igual a 1.012 e quatro RADIUS AVPs são necessários para transportá-lo.

Fragmentação em EAP-TLS

Na mesma captura de tela, você pode ver que:

• O comprimento do pacote EAP é 1.012
• O comprimento EAP-TLS é 2.342

Isso sugere que é o primeiro fragmento EAP-TLS e que o requerente deve esperar mais, o que pode ser confirmado se você examinar as flags EAP-TLS:

Esse tipo de fragmentação ocorre com mais frequência em:

• Desafio de acesso RADIUS enviado pelo servidor AAA, que transporta o EAP-Request com o certificado de servidor SSL (Secure Sockets Layer) com toda a cadeia.
• RADIUS Access-Request enviado pelo NAD, que transporta EAP-Response com o certificado de cliente SSL com toda a cadeia.

Confirmação de fragmento EAP-TLS

Como explicado anteriormente, cada fragmento EAP-TLS deve ser confirmado antes que fragmentos subsequentes sejam enviados.

Aqui está um exemplo (capturas de pacote para EAPoL entre o requerente e o NAD):

Os quadros EAPoL e o servidor AAA devolvem o certificado do servidor:

• Esse certificado é enviado em um fragmento EAP-TLS (pacote 8).
• O requerente reconhece esse fragmento (pacote 9).
• O segundo fragmento EAP-TLS é encaminhado pelo NAD (pacote 10).
• O requerente reconhece esse fragmento (pacote 11).
• O terceiro fragmento EAP-TLS é encaminhado pelo NAD (pacote 12).
• O requerente não precisa de o reconhecer; em vez disso, ele continua com o certificado do cliente que começa no pacote 13.

Aqui estão os detalhes do pacote 12:

Você pode ver que os pacotes reagrupados do Wireshark 8, 10 e 12. O tamanho dos fragmentos EAP é 1.002, 1.002 e 338, o que leva o tamanho total da mensagem EAP-TLS para 2342 (o comprimento total da mensagem EAP-TLS é anunciado em cada fragmento). Isso pode ser confirmado se você examinar pacotes RADIUS (entre o servidor NAD e o servidor AAA):

Os pacotes RADIUS 4, 6 e 8 transportam esses três fragmentos EAP-TLS. Os dois primeiros fragmentos são reconhecidos. O Wireshark pode apresentar as informações sobre os fragmentos EAP-TLS (tamanho: 1.002 + 1.002 + 338 = 2.342).

Esse cenário e exemplo foram fáceis. O switch Cisco IOS não precisou alterar o tamanho do fragmento EAP-TLS.

Fragmentos EAP-TLS remontados com tamanho diferente

Considere o que acontece quando o NAD MTU em direção ao servidor AAA é de 9.000 bytes (quadro jumbo) e o servidor AAA também é conectado ao uso da interface que suporta quadros jumbo. A maioria dos suplicantes típicos está conectada ao uso de um link de 1 Gbit com um MTU de 1.500.

Em tal cenário, o switch Cisco IOS executa o assembly e a remontagem "assimétricos" EAP-TLS e altera os tamanhos dos fragmentos EAP-TLS. Aqui está um exemplo de uma mensagem EAP grande enviada pelo servidor AAA (Certificado de Servidor SSL):

1. O servidor AAA deve enviar uma mensagem EAP-TLS com um certificado de servidor SSL. O tamanho total desse pacote EAP é 3.000. Depois de ser encapsulado em RADIUS Access-Challenge/UDP/IP, ainda é menor que o MTU da interface do servidor AAA. Um único pacote IP é enviado com 12 atributos RADIUS EAP-Message. Não há fragmentação de IP nem EAP-TLS.
   
   
2. O switch Cisco IOS recebe um pacote desse tipo, o desencapsula e decide que o EAP precisa ser enviado via EAPoL ao requerente. Como o EAPoL não oferece suporte à fragmentação, o switch deve executar a fragmentação EAP-TLS.
   
   
3. O switch Cisco IOS prepara o primeiro fragmento EAP-TLS que pode se ajustar ao MTU da interface em direção ao suplicante (1.500).
   
   
4. Este fragmento é confirmado pelo requerente.
   
   
5. Outro fragmento EAP-TLS é enviado após o recebimento da confirmação.
   
   
6. Este fragmento é confirmado pelo requerente.
   
   
7. O último fragmento EAP-TLS é enviado pelo switch.

Esse cenário revela que:

• Em algumas circunstâncias, o NAD deve criar fragmentos EAP-TLS.
• O NAD é responsável por enviar/reconhecer esses fragmentos.

A mesma situação pode ocorrer para um suplicante conectado através de um link que suporta quadros jumbo enquanto o servidor AAA tem um MTU menor (então o switch Cisco IOS cria fragmentos EAP-TLS quando envia o pacote EAP para o servidor AAA).

Atributo RADIUS Framed-MTU

Para RADIUS, há um atributo Framed-MTU definido em RFC 2865:

"Este Atributo indica a Unidade Máxima de Transmissão a ser configurada para o usuário, quando não é negociada por algum outro meio (como PPP). ELE PODE ser usado em pacotes Access-Accept. ELE PODE ser usado em um pacote de solicitação de acesso como dica pelo NAS para o servidor de que ele preferiria esse valor, mas o servidor não é obrigado a honrar a dica."

O ISE não honra a dica. O valor do Framed-MTU enviado pelo NAD na Solicitação de Acesso não tem nenhum impacto na fragmentação executada pelo ISE.

Vários switches modernos do Cisco IOS não permitem alterações na MTU da interface Ethernet, exceto para configurações de quadros jumbo ativadas globalmente no switch. A configuração de quadros jumbo afeta o valor do atributo Framed-MTU enviado na RADIUS Access-Request. Por exemplo, você define:

Switch(config)#system mtu jumbo 9000

Isso força o switch a enviar Framed-MTU = 9000 em todas as solicitações de acesso RADIUS. O mesmo para o sistema MTU sem jumbo frames:

Switch(config)#system mtu 1600

Isso força o switch a enviar Framed-MTU = 1600 em todas as solicitações de acesso RADIUS.

Observe que os modernos switches Cisco IOS não permitem que você diminua o valor de MTU do sistema para menos de 1.500.

Servidores AAA e comportamento do requerente quando você envia fragmentos EAP

ISE

O ISE sempre tenta enviar fragmentos EAP-TLS (geralmente o Servidor Hello com Certificado) com 1.002 bytes de comprimento (embora o último fragmento seja geralmente menor). Ele não honra o RADIUS Framed-MTU. Não é possível reconfigurá-lo para enviar fragmentos EAP-TLS maiores.

Microsoft Network Policy Server (NPS)

É possível configurar o tamanho dos fragmentos EAP-TLS se você configurar o atributo Framed-MTU localmente no NPS.

Embora o artigo Configure the EAP Payload Size on Microsoft NPS mencione que o valor padrão de um MTU enquadrado para o servidor NPS RADIUS é 1.500, o laboratório Cisco Technical Assistance Center (TAC) mostrou que ele envia 2.000 com as configurações padrão (confirmado em um Microsoft Windows 2012 Datacenter).

É testado que a definição de Framed-MTU localmente conforme o guia mencionado anteriormente é respeitada pelo NPS, e fragmenta as mensagens EAP em fragmentos de um tamanho definido em Framed-MTU. Mas o atributo Framed-MTU recebido na solicitação de acesso não é usado (o mesmo que no ISE/ACS).

A definição desse valor é uma solução alternativa válida para corrigir problemas na topologia como esta:

Requerente [MTU 1500] — [MTU 9000]Switch [MTU 9000] — [MTU 9000]NPS

Atualmente, os switches não permitem definir a MTU por porta; para switches 6880, esse recurso é adicionado com o bug da Cisco ID CSCuo26327 - 802.1x EAP-TLS que não funciona em portas de host FEX.

AnyConnect

O AnyConnect envia fragmentos EAP-TLS (geralmente certificado do cliente) com 1.486 bytes de comprimento. Para esse tamanho de valor, o quadro Ethernet é de 1.500 bytes. O último fragmento geralmente é menor.

Requerente Nativo do Microsoft Windows

O Microsoft Windows envia fragmentos EAP-TLS (geralmente certificado do cliente) com 1.486 ou 1.482 bytes de comprimento. Para esse tamanho de valor, o quadro Ethernet é de 1.500 bytes. O último fragmento geralmente é menor.

Informações Relacionadas

• Configurando a autenticação baseada em porta IEEE 802.1x
• Suporte Técnico e Documentação - Cisco Systems