Resumo

  • A RFC 9965 reserva eap.arpa para NAIs que pedem um caminho definido de provisionamento e conectividade limitada, ainda não autenticada.
  • Pedido, escolha do método EAP, autenticação do servidor, aplicação da rede limitada, emissão de credencial e admissão normal são registros e decisões separados.

Um dispositivo desconhecido apresenta um identificador que termina em eap.arpa. A rede pode lê-lo como pedido de ajuda para obter uma credencial; não pode lê-lo como se já fosse a credencial. Essa é a contenção central da RFC 9965, The eap.arpa. Domain and Extensible Authentication Protocol Provisioning.

O documento define o EAP Provisioning Identifier, ou EPI: um NAI cujo realm é subdomínio de eap.arpa.. O realm foi deliberadamente separado de uma organização específica. Ele não deve ser automaticamente encaminhado pela infraestrutura AAA existente nem resolvido pela descoberta dinâmica usual de pares. Isso não impede que uma organização escolha roteá-lo localmente. A sintaxe comum explica como o par pede um método de provisionamento; o operador receptor ainda decide se atende, para onde encaminha e com quais provas trabalha.

Por isso a cadeia de caracteres do realm é evidência fraca. Ela pode provar que um par emitiu determinado pedido na troca de identidade EAP. Não prova quem possui o dispositivo, que organização responde por ele, qual backend o tratou ou se algum método de autenticação terminou. Um registro que converte @method.eap.arpa em “dispositivo confiável” substitui uma mensagem observável por várias decisões que não foram observadas.

A RFC 9965 é explícita sobre o estado anterior a essas decisões. Implementações devem tratar pares que usam EPI como não confiáveis. Depois de aceito um método de provisionamento, o par deve ficar em rede limitada, como um captive portal, e essa rede não pode permitir acesso irrestrito. Uma rede segura de provisionamento permite o tráfego esperado e bloqueia todo o restante. Bloquear apenas alguns destinos considerados ruins deixa uma superfície maior e menos auditável.

Também não se pode saltar a fronteira do método. O EPI seleciona o método de provisionamento solicitado. Se o servidor EAP aceitar o pedido, o método oferecido deve corresponder ao método associado ao EPI; só então continua a máquina de estados EAP normal. A RFC 3748 define EAP como estrutura de autenticação com vários métodos e observa que até um par autenticado pode ter o acesso negado por política, limite de sessão ou outras razões. Escolher um método não é sucesso EAP nem autorização geral.

A autenticação do servidor constitui outra camada. A RFC 9965 exige que cada método sob eap.arpa. descreva como o servidor será autenticado e recomenda EAP baseado em TLS quando este oferece autenticação do servidor, integridade e confidencialidade. É uma exigência do desenho do método, não prova de que uma sessão específica validou certo certificado. A trilha de auditoria precisa guardar separadamente o EPI solicitado, a decisão local de roteamento, o método escolhido, a evidência de autenticação do servidor, a regra de rede limitada realmente aplicada, a decisão de credencial e a decisão posterior de acesso.