Resumo

  • Cadeia, CertificateVerify e Finished demonstram fatos criptográficos definidos pelo EAP-TLS. Não criam a VLAN, não instalam a ACL e não mudam sozinhos o estado da porta controlada.
  • O arcabouço EAP prevê tanto a recusa de autorização depois da autenticação quanto a autorização que o autenticador não consegue executar por falta de serviço local.
  • A evidência operacional deve ligar certificado, resultado EAP, decisão AAA, destino das chaves, aplicação no NAS e tráfego real sem permitir que uma etapa fale em nome das seguintes.

A autenticação terminou antes da rede começar

Em um cenário construído, às 08:14:02 o equipamento cliente valida a cadeia e o nome do servidor EAP. O servidor valida o certificado do cliente. CertificateVerify confirma a posse das chaves privadas; Finished confirma que os dois lados chegaram ao mesmo transcript protegido. O painel de identidade fica verde.

Às 08:14:03, o backend combina a identidade autenticada com o NAS, a porta e o serviço solicitado. Devolve um papel e uma VLAN condicionados a esse contexto. O painel de política também fica verde.

Às 08:14:04, o switch de borda não encontra a VLAN no contexto de encaminhamento em que precisaria aplicá-la. O serviço autorizado está indisponível naquele ponto de execução. A porta controlada permanece fechada; não há DHCP, configuração IPv6 nem tráfego de aplicação.

Essa linha do tempo não relata falha de operador ou produto. Ela reúne limites expressos em RFC 5216, RFC 3748 e RFC 3579. Cada registro parcial pode estar correto. A frase “acesso concluído” é que excede a autoridade desses registros.

A prova exata produzida pelo TLS

RFC 5216 coloca TLS dentro de EAP para autenticação mútua por certificados, negociação protegida, troca de chaves e derivação de material EAP. A validação da cadeia verifica se o certificado chega a uma âncora aceita sob determinada política. CertificateVerify verifica a assinatura feita com a chave privada correspondente. Finished vincula os participantes ao estado e aos segredos do mesmo handshake.

São garantias fortes porque têm objeto definido. Um subject ou SAN pode fornecer identidade autenticada ao motor de política. Não contém o estado atual da porta, a existência da VLAN, a instalação do filtro, a integridade de cada proxy AAA ou a resposta do serviço final.

O conjunto normativo também evoluiu. RFC 8996 desaconselha TLS 1.0 e 1.1. RFC 9190 define o uso de TLS 1.3, com novo fluxo e nova hierarquia de chaves. RFC 9965 acrescenta o domínio eap.arpa ao aprovisionamento. Essas atualizações não são estatísticas de implantação nem sensores do plano de dados.

A seção de autorização da RFC 9190 vale para EAP-TLS em geral. A identidade externa de EAP-Response/Identity não é autenticada pelo método e pode ser falsificada. Autorização e contabilização devem partir de informações autenticadas do certificado, da identidade PSK ou do estado de retomada. Informações do NAS, endereço, porta e SSID podem entrar na política como dados adicionais.

Isso preserva a divisão correta: autenticação fornece um fato confiável; a política decide o que esse fato permite em um contexto atual.

Um Success não sincroniza todas as decisões

RFC 3748 diz que sincronizar o resultado de autenticação não garante sincronização de autorização. Um proxy AAA pode tomar decisão que o servidor EAP desconhece. O servidor AAA pode esperar a autenticação terminar para concluir que não deve autorizar. Pode também conceder acesso enquanto o autenticador não dispõe temporariamente do recurso necessário.

As três situações distinguem decisor, permissão e capacidade. Um contador que termina em “method success” não revela qual delas impediu a rede.

RFC 4137 formaliza as máquinas de estado do peer e do autenticador. O sinal entregue à camada inferior é a conclusão da máquina EAP. Ele não consulta tabelas de VLAN, pools de endereço ou testes de aplicação.

Possuir a chave não concede o mandato

RFC 5247 separa a derivação do MSK/EMSK, o transporte AAA para o autenticador e o protocolo de associação segura. A divisão impede que a existência da chave seja confundida com todo o sistema de autorização.

O documento afirma que prova de posse de material de chave não necessariamente prova autorização para possuí-lo. Uma troca local pode demonstrar que peer e NAS compartilham o material correto, sem demonstrar que o backend autorizou aquele NAS a recebê-lo para aquele peer e serviço.

RFC 4962 exige autorização do peer e do autenticador. RFC 4017 lista autenticação mútua, força da chave e autorização como requisitos distintos. RFC 5295 limita por uso e domínio as raízes derivadas do EMSK. Segredo não é sinônimo de permissão irrestrita.

O Access-Accept depende de quem o recebe

Em uma implantação RADIUS comum, o NAS apenas transporta EAP entre peer e backend. RFC 3579 define Access-Accept e Access-Reject como resultados próprios. Reject exige negar acesso; Accept encerra a fase e pode trazer papel, VLAN, filtro ou limite de sessão.

Mas um NAS incapaz de oferecer o serviço pedido deve tratar o Accept correspondente como Reject. RFC 3580 também adverte sobre combinações conflitantes entre o tipo RADIUS e um EAP Success ou Failure encapsulado. O controle de acesso segue a decisão RADIUS, não uma palavra isolada dentro dela.

O backend comprova o que decidiu enviar. Só a borda comprova que reconheceu os atributos, encontrou a VLAN, instalou a ACL, concluiu a associação e abriu a porta. Mesmo assim, uma porta aberta não comprova endereço, resolução, rota ou aplicação.

O contexto não vem dentro do certificado

RFC 6677 trata do NAS ou provedor que conta uma história ao peer e outra à infraestrutura AAA. Channel binding permite comparar percepções sobre SSID, rede e propriedades relevantes por um canal protegido.

A necessidade do mecanismo revela o limite do certificado: ele não autentica automaticamente o ponto físico, o provedor visitado ou o serviço anunciado. Essas informações têm produtores e regras de atualização próprios. Mesmo quando a comparação passa, ainda falta observar o tráfego entregue.

RFC 7542 disciplina os NAI; RFC 9427 atualiza métodos EAP baseados em TLS para TLS 1.3. Eles melhoram a ligação entre provas, não eliminam as etapas.

Retomada não preserva todo privilégio

RFC 9190 trata uma retomada TLS 1.3 aceita como autenticada e vinculada a uma autenticação anterior. Também determina cautela para que a nova sessão não receba mais privilégio do que o originalmente pretendido.

Enquanto o ticket ainda é válido, o certificado pode ser revogado, o papel do dispositivo pode mudar, a política do SSID pode ser alterada e a VLAN pode deixar de existir. Validade, revogação, ticket, autorização, porta e serviço seguem relógios independentes.

OCSP stapling e a verificação de revogação ajudam o cliente que ainda não tem Internet antes do EAP. Esse bootstrap cuidadoso não comprova o resultado depois da autenticação.

Um recibo para cada fronteira

O recibo PKI registra âncora, hashes da cadeia, nome, validade e revogação. O recibo TLS registra versão, suíte, CertificateVerify e Finished sem expor segredos. O recibo EAP registra método, resultado protegido e identificadores seguros das chaves.

AAA registra identidade, NAS, contexto, política, Accept/Reject e atributos. O transporte registra destinatário e escopo. O NAS registra interpretação, VLAN/papel, ACL, associação e estado da porta. O serviço registra endereço, vizinhança, DNS, rota e primeira troca útil.

Estados negativos são válidos: “certificado certo, autorização negada”; “Accept recebido, serviço ausente”; “porta aberta, aplicação falhou”. Apagá-los sob um sucesso agregado destrói a explicação operacional.

Fontes

  1. RFC 5216
  2. RFC 5216 no Datatracker
  3. Estado da RFC 5216
  4. Histórico da RFC 5216
  5. Errata da RFC 5216
  6. RFC 9190
  7. RFC 3748
  8. RFC 5247
  9. RFC 4017
  10. RFC 6677
  11. RFC 8996
  12. RFC 9965
  13. RFC 7542
  14. RFC 3579
  15. RFC 3580
  16. RFC 4137
  17. RFC 4962
  18. RFC 5295
  19. RFC 9427
  20. Heng Lu — Running-Code Primacy
  21. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption