Resumo

  • Um método EAP pode autenticar o par corretamente enquanto política, atributos AAA, ação do autenticador, entrega de chaves e caminho de dados ainda produzem resultados próprios.
  • O registro defensável guarda conversa do método, resultado EAP, pacote RADIUS, decisão de autorização, associação segura, porta controlada e primeira conectividade em recibos separados.

O diagnóstico costuma parar cedo demais. O servidor aceitou o certificado e a tela mostrou sucesso; logo, conclui-se que a rede deveria funcionar. Mas um limite de sessões pode negar autorização, o ponto de acesso pode não suportar o VLAN indicado, a chave pode chegar ao autenticador errado ou a associação da camada de enlace pode nunca terminar.

A RFC 3748 definiu o Extensible Authentication Protocol no Standards Track em 2004. Bernard Aboba divide a autoria com Larry Blunk, John Vollbrecht, James Carlson e Henrik Levkowetz. Não é uma invenção solitária. O desenho coletivo distribui tarefas porque EAP é uma estrutura para métodos de autenticação, não um sistema completo de controle de acesso.

O peer responde no enlace. O authenticator inicia EAP e controla o ponto local. O EAP server encerra o método. Em modo pass-through, o servidor pode estar em um backend AAA distante enquanto o equipamento de acesso apenas encaminha mensagens que não compreende. Quem verifica a credencial pode não ser quem abre o caminho dos dados.

A própria RFC observa que um peer autenticado pode ter o acesso negado por falta de autorização, como um limite de sessões. Proxies AAA também influenciam a decisão. O resultado protegido do método informa o que suas extremidades verificaram; não transporta automaticamente serviço, VLAN, capacidade local ou estado da porta.

O recibo estreito do EAP Success

Depois que um método termina com êxito, o authenticator envia o código 3. EAP Success não contém dados adicionais, não é confirmado e não é retransmitido. Em algumas condições, uma indicação confiável da camada inferior permite que o peer conclua que um Success se perdeu. Uma captura isolada, portanto, não reconstrói a sessão inteira.

O protocolo manda descartar um Success pronto enviado imediatamente após a conexão quando o método ainda não poderia terminar. Isso impede que um autenticador falso pule a conversa. O código final só ganha sentido junto do estado do método que veio antes.

EAP Success não registra os atributos de autorização nem prova que a porta abriu, a chave foi instalada, um endereço IP foi obtido ou uma aplicação enviou dados. Cada constatação exige outra evidência.

RADIUS decide em outro campo

A RFC 3579, de Aboba e P. Calhoun, descreve EAP transportado por RADIUS. O NAS encaminha a conversa até receber Access-Accept ou Access-Reject. Sua decisão de acesso deve usar exclusivamente o tipo de pacote RADIUS, nunca o pacote EAP encapsulado.

Access-Reject com EAP Success é uma combinação contraditória que não deveria ser enviada. Se aparecer, o NAS nega acesso, embora o peer possa acreditar que se autenticou. Access-Accept com EAP Failure divide os lados na direção oposta. O NAS não deve inventar uma mensagem para esconder a divergência; ambos os resultados precisam ficar no registro.

Access-Accept encerra a fase de autenticação e pode trazer instruções de serviço, filtro, VLAN ou limite. Se o NAS conhece o serviço, mas não consegue fornecê-lo, falhar é correto. O backend pode devolver autorizações diferentes conforme a capacidade do equipamento. Uma identidade válida não promete o mesmo acesso em todos os locais.

Chave exportada não é canal instalado

A RFC 5247, assinada por Aboba, Dan Simon e P. Eronen, separa método EAP, transporte de material criptográfico e protocolo de associação segura da camada inferior. Uma Master Session Key é um resultado intermediário. O material ainda deve chegar ao autenticador autorizado e produzir chaves transitórias para o tráfego.

“MSK gerada” não identifica destinatário, escopo, sessão, derivação nem instalação. Também não prova que a associação acabou. Identidades de peer e server podem diferir entre camadas externa e interna, e o peer pode não saber antecipadamente qual backend atenderá a tentativa.

A RFC 3748 exige que a proteção posterior dos dados seja vinculada às entidades que concluíram EAP. Integridade por pacote, autenticação e antirreplay precisam usar as chaves derivadas. Sem essa ligação, dados podem ser alterados ou repetidos depois de uma autenticação correta.

Credencial válida no serviço errado

Quando as mesmas credenciais alcançam vários serviços, um NAS malicioso pode anunciar uma rede e conectar o peer a outra. A RFC 6677 chama isso de problema do NAS ou provedor mentiroso. Channel binding permite ao peer enviar, sob proteção, dados do serviço observado para comparação com a declaração e o cadastro do autenticador.

O mecanismo não faz o cliente conhecer magicamente a rede. Ele compara anúncio visto, afirmação do NAS, expectativa do backend e método que protege a troca. Sem guardar esses quatro elementos, uma autenticação forte pode esconder o contexto errado.

A RFC 5216 traça a mesma fronteira em EAP-TLS. Após validar a cadeia, a implementação ainda decide se as identidades do certificado são adequadas e autorizadas para aquele uso. Validade criptográfica alimenta a política; não a substitui.

Montar o recibo na ordem

O livro operacional começa com rede descoberta, intenção do peer, identidade do NAS e porta. Depois registra método, conversa, resultado protegido, identidades, resultado EAP externo, tipo RADIUS, atributos e decisão local. Em seguida vêm exportação e destino das chaves, associação segura, porta controlada, configuração IP, primeiro tráfego e contabilidade ou desconexão.

Assim é possível separar credencial inválida de política restritiva, Access-Accept de serviço incompatível, chave produzida de chave instalada e enlace ativo de acesso utilizável. O erro volta para a camada que de fato o controla.

Fontes