Resumo

  • A RFC 5422 recomenda não liberar a rede ao fim do modo sem autenticação do servidor; no modo autenticado, o servidor pode autorizar o acesso segundo sua política.
  • O reconhecimento do Tunnel PAC registra o resultado declarado pelo par ao processá-lo e armazená-lo; não comprova a autenticação posterior nem a autorização.

O primeiro objetivo não é liberar a rede

Um dispositivo pode chegar sem segredo compartilhado, raiz confiável do servidor ou Protected Access Credential. A RFC 5422 descreve como o EAP-FAST pode provisionar esse material pela própria conexão. A pergunta de gestão é simples: concluir essa etapa também autoriza o dispositivo a usar os recursos da rede? O protocolo preserva uma decisão entre os dois momentos.

O EAP-FAST combina uma fase TLS inicial com uma fase EAP interna. A RFC 5422 separa o modo de provisionamento com servidor autenticado daquele sem essa autenticação inicial. No primeiro, o par verifica o servidor durante o handshake TLS e precisa ter material de confiança antes de começar. No segundo, o túnel TLS anônimo baseado em Diffie–Hellman permite iniciar o processo sem essa configuração, mas não informa quem é o servidor na fase 1.

Isso não elimina a autenticação. No modo anônimo, as duas partes precisam concluir dentro do túnel um método EAP com autenticação mútua e derivação de chaves. O par também verifica o Crypto-Binding TLV para vincular a troca interna à integridade do canal TLS e reduzir a possibilidade de um intermediário ativo. Na versão de 2009, as implementações desse modo precisavam oferecer suporte ao EAP-FAST-MSCHAPv2 como método de autenticação interno. O vínculo entre as fases é parte do resultado; não basta observar um sucesso isolado da autenticação interna. (RFC 5422 §§2, 3.2–3.2.3, 6.1.2; RFC 4851)

Depois da autenticação interna e do Crypto-Binding, o servidor pode fornecer um Tunnel PAC — com PAC-Key e PAC-Opaque — ou raízes confiáveis do servidor. O Tunnel PAC ajuda a estabelecer um túnel EAP-FAST futuro; ele não é uma autorização para acessar a rede.

Para um Tunnel PAC recém-provisionado, o par envia PAC-Acknowledgement indicando o resultado do processamento e do armazenamento. Esse reconhecimento não se aplica aos outros tipos de PAC. O servidor recebe a declaração do par; não recebe, com isso, prova de que uma autenticação posterior funcionou, de que a política de acesso aprovou a sessão ou de que a aplicação recebeu tráfego. (RFC 5422 §§3.2, 4.1.4, 4.2.5)

A regra da RFC 5422 é explícita: ao fim do modo Server-Unauthenticated Provisioning, o acesso à rede NÃO DEVERIA ser liberado porque aquela conversa serve apenas ao provisionamento. A política do par pode encerrar a sessão e iniciar uma nova troca EAP-FAST com as informações provisionadas. No modo Server-Authenticated, o servidor PODE conceder acesso após o provisionamento bem-sucedido. Não há um único significado operacional para “provisionamento concluído”. (RFC 5422 §3.5)

Os modos distribuem risco e custo de formas diferentes. A autenticação do servidor protege melhor contra intermediários, mas exige confiança previamente instalada. O modo anônimo reduz atrito e pode permitir configuração sem intervenção, mas a RFC 5422 descreve maior exposição das trocas de senha a ataques de dicionário offline. Ela também recomenda controles para tentativas online e incentiva limitar onde ou quando o modo anônimo pode ser usado. Essas são condições de projeto de um documento Informativo de 2009, não medidas sobre a adoção atual. (RFC 5422 §§6.1–6.3)

O registro operacional deve separar: modo de provisionamento; autenticação interna e Crypto-Binding; tipo e validade da credencial; confirmação do Tunnel PAC; autenticação seguinte que usa o material; decisão final de acesso. Se provisionamento e controle de acesso pertencem a equipes diferentes, elas precisam de um identificador comum e de um responsável pela ausência da segunda troca. Um primeiro resultado positivo não substitui a evidência que falta.

Um resultado interno bem-sucedido ainda pode terminar em recusa

A seção 3.5 deixa a autorização a cargo da política do servidor mesmo quando o provisionamento termina. No modo Server-Authenticated, o servidor pode liberar o acesso depois de autenticar o par e entregar um Tunnel PAC. No modo Server-Unauthenticated, a recomendação é não conceder acesso ao fim da conversa, que existe apenas para provisionar. O fato de ambos entregarem credenciais não torna seus resultados de autorização equivalentes.

Um Result TLV positivo tampouco resolve a decisão. A autenticação interna pode concluir com sucesso e, ainda assim, o servidor considerar que a política de acesso não foi satisfeita e encerrar com EAP Failure. Se a troca não deve abrir a rede, a RFC 5422 determina que o servidor não conceda acesso nem entregue chaves de sessão ao Network Access Server. Um painel que conte somente o sucesso interno pode exibir um dispositivo como liberado quando o servidor corretamente o manteve fora. O registro deve acompanhar o resultado EAP final e a entrega de chaves, além do primeiro marcador positivo. (RFC 5422 §3.5; RFC 4851 §4.2.2)

O reconhecimento cobre apenas uma etapa da credencial

Um Tunnel PAC tem componentes diferentes. O PAC-Key é um segredo de 32 octetos usado para estabelecer o túnel de fase 1. O PAC-Opaque, específico do servidor que o emitiu, retorna ao servidor durante uma autenticação posterior. O PAC-Info pode identificar a autoridade e incluir uma validade. A RFC 4851 exige a proteção do PAC-Key; a RFC 5422 atribui ao par e ao servidor o armazenamento seguro do estado que lhes cabe. A entrega cria obrigações posteriores de guarda, caducidade e renovação.

O PAC-Acknowledgement é mais restrito: o par o envia para um Tunnel PAC recém-provisionado e informa o resultado de processamento e armazenamento. O resultado só pode ser sucesso ou falha. Sucesso significa que o par relatou esse resultado naquele momento; não prova que um túnel futuro será estabelecido, que o segredo continuará protegido ou que a rede autorizará o dispositivo. A autenticação EAP-FAST seguinte testa o material em outro contexto. Mesmo esse teste não é um comprovante de que a aplicação recebeu tráfego. (RFC 5422 §§4.2.2–4.2.5, 6.8; RFC 4851 §3.2.2)

Uma recusa também pode interromper a conectividade

Separar as decisões tem um custo de disponibilidade. A RFC 5422 observa que um EAP Failure após a recusa pode provocar a desassociação completa de um dispositivo 802.11. Par ou servidor podem tentar uma renegociação TLS para usar as novas credenciais numa autenticação subsequente sem reiniciar todo o processo, mas qualquer lado pode rejeitar a solicitação. A política normal só se aplica depois que essa autenticação funciona. Por isso, o operador deve medir quem retorna, quem é negado e se a recuperação exigiu reinício ou renegociação.

Sem isso, uma recusa correta parece defeito de provisionamento, ou uma contagem de provisionamentos bem-sucedidos esconde quem nunca entrou. (RFC 5422 §3.5)

Fontes