Resumo

  • O EAP Provisioning Identifier da RFC 9965 é um NAI público que informa o método de provisionamento desejado. Ele não autentica o dispositivo, não comprova propriedade e não promete admissão plena.
  • O par aceito continua não confiável. A rede deve permitir somente o tráfego esperado, isolar os pares e limitar tempo, bytes, serviços, tentativas e sessões simultâneas.
  • Um recibo de encerramento da via de provisionamento deve ligar o pedido à regra efetivamente aplicada e provar sua expiração ou remoção. A ideia é uma proposta editorial de Daniel Kade, não uma exigência da IETF.

O paradoxo do primeiro acesso

Uma credencial costuma ser a condição para entrar na rede. No primeiro uso, contudo, o dispositivo pode precisar da própria rede para receber essa credencial. A RFC 9965 trata desse círculo com EAP Provisioning Identifiers, ou EPIs, no realm eap.arpa.

O EPI segue o formato NAI da RFC 7542. Seu texto informa ao servidor qual mecanismo o par deseja. O registro da IANA associa @noob.eap.arpa ao EAP-NOOB e portal@tls.eap.arpa ao EAP-TLS. Assim, servidor e cliente compartilham uma linguagem antes de existir uma identidade específica do dispositivo.

Essa linguagem não é secreta. A possibilidade de gravá-la previamente em muitos produtos é justamente sua utilidade. Por isso, apresentar um EPI correto não demonstra que o aparelho foi comprado por determinada empresa, está no inventário, permanece sob o mesmo dono ou deve alcançar a rede de produção.

A RFC não tenta transformar o pedido em prova. Ela manda tratar o par que usa EPI como não confiável. A rede pode recusar o provisionamento por política ou capacidade, sem explicar todos os motivos ao equipamento. Se aceitar, deve colocar o par em uma rede limitada, nunca conceder acesso irrestrito.

O problema de governança aparece depois. Um serviço emite o certificado e registra sucesso. O controlador envia uma mudança. O painel encerra a tarefa. Ainda assim, o switch, ponto de acesso ou gateway pode conservar a ACL provisória. A credencial nova passa a existir ao lado de um caminho antigo e mais fraco.

Remover esse caminho não é manutenção opcional. O prazo faz parte do privilégio desde o começo. Quando a decisão não define uma saída verificável, o adjetivo “temporário” é apenas intenção.

O nome reservado não terceiriza a decisão

Embora se pareça com domínio, o realm eap.arpa tem função específica no NAI. A RFC 9965 distingue esse uso do nome DNS eap.arpa.. A IANA o registra entre os domínios de uso especial, mas consultas DNS devem receber NXDOMAIN e o nome não deve ser usado fora do EAP.

Logo, o EPI não deveria provocar descoberta aberta de uma autoridade remota. O servidor local decide se reconhece o pedido, se aceita o método e qual superfície mínima entregará. Uma string global cria interoperabilidade; não transfere ao mantenedor do registro a responsabilidade pelo acesso em uma porta concreta.

O protocolo também restringe desvios. EPI malformado recebe EAP Failure. Identificador desconhecido, método não suportado ou método incompatível com o EPI recebe Nak de tipo zero. Com credenciais de provisionamento, cliente e servidor não podem negociar livremente uma alternativa qualquer.

Essas regras mantêm intenção e método juntos. Elas não vinculam o aparelho a uma entidade. A IETF define o comportamento, a IANA administra a tabela, a operadora controla a borda e o proprietário institucional decide qual ativo merece cadastro. Cada poder produz evidência diferente.

A unidade que precisa ser auditada é a sessão: EPI, contexto de acesso, versão da política, regra instalada, orçamento, resultado e encerramento. Contar apenas quantas vezes o identificador apareceu diz pouco sobre o risco real.

Rede limitada exige lista positiva

Uma etiqueta “onboarding” não mostra quais pacotes passam. A RFC 9965 recomenda permitir somente o tráfego esperado e bloquear todo o restante. Uma lista de destinos proibidos deixa caminhos não imaginados; até um serviço auxiliar, como DNS, pode transportar dados se a regra for ampla.

O registro deve alcançar o mecanismo de enforcement. Qual Filter-Id, VLAN, ACL, papel dinâmico ou objeto do controlador foi instalado? Em qual ponto? Qual revisão? Quais destinos, portas e protocolos ficaram liberados? Serviços de horário, resolução ou validação de certificados foram incluídos por qual necessidade? Sem essas respostas, “limitado” não é um estado reproduzível.

A RFC sugere limites que atuam sobre recursos distintos:

  • O provisionamento normal deveria durar segundos ou dezenas de segundos. Uma longa permanência pode indicar problema.
  • A quantidade de dados deve ter teto, pois a tarefa não exige grandes transferências na maioria dos casos.
  • O conjunto de serviços acessíveis precisa ser pequeno.
  • As tentativas devem sofrer limitação de taxa, com bloqueio para comportamento abusivo.
  • O total de pares em provisionamento simultâneo deve ter capacidade definida.
  • Pares no ambiente limitado não podem conversar entre si.

O tempo reduz permanência; bytes reduzem uso como transporte; a lista positiva reduz alcance; taxa e concorrência protegem a infraestrutura compartilhada; isolamento impede ataques laterais dentro da própria zona provisória. Nenhum substitui os demais.

Uma sessão de poucos segundos com saída geral continua ampla. Uma política precisa sem prazo vira rota permanente. Um limite de vinte dispositivos não protege um do outro. A prova útil confirma que todas as restrições relevantes valeram no mesmo intervalo.

A citação ao Filter-Id do RADIUS é um exemplo operacional. Outras arquiteturas podem usar segmentação ou funções próprias do controlador. Em qualquer caso, o nome precisa apontar para conteúdo e versão. Reutilizar “onboarding” após ampliar a allowlist destrói a capacidade de interpretar registros antigos.

Também é preciso impedir a extensão por repetição. Se um par reinicia uma sessão assim que o TTL termina, dez sessões curtas podem produzir uma permanência longa. A limitação de tentativas deve reunir eventos pelo contexto de acesso disponível sem fingir que esse contexto é uma identidade estável.

A assimetria necessária

“Provisionamento não autenticado” descreve a ausência de autenticação do par, não uma conversa entre duas fontes anônimas. Todo método em eap.arpa deve definir como o servidor será autenticado, no EAP ou mais tarde por um protocolo protegido, como HTTPS. O par deve tratar a rede local como não confiável.

No portal@tls.eap.arpa, o EAP-TLS pode oferecer acesso com o par não autenticado, mas precisa autenticar o servidor, por exemplo por certificado. Um PSK público não produziria essa garantia. A rede pode arriscar receber pouco tráfego de um desconhecido; o dispositivo não deve aceitar sua futura identidade de um desconhecido.

A RFC 8952 ajuda a separar funções. Um serviço fornece a URI da API, a API descreve o estado cativo, um portal atende condições e o Enforcement Device controla o tráfego. A aplicação que entrega credenciais e o equipamento que remove a restrição podem divergir.

O cliente também pode guardar uma visão antiga da sessão. Seu prazo ou cota percebidos podem não coincidir com os contadores da rede. Por isso, o encerramento precisa de confirmação do componente que efetivamente bloqueia ou permite pacotes, e não apenas do portal.

Emitir não é admitir

O resultado pode ser certificado, referência de chave, configuração ou uma etapa fora de banda do EAP-NOOB. Pode também ser método recusado, falha na autenticação do servidor, timeout, cota excedida, fila cheia ou decisão local negativa.

Colocar tudo sob “concluído” apaga a diferença entre produzir um artefato e autorizar seu uso. Uma credencial pode apontar para o registro errado, nascer revogada, valer para outro serviço ou falhar no próximo EAP. A emissão não determina o papel de rede.

A transição mais limpa encerra a sessão EPI e inicia uma autenticação normal com a credencial nova. A política atual avalia então a identidade autenticada e decide o acesso. A experiência pode ser contínua, mas existem duas fontes de autoridade: a exceção de arranque e a autorização regular.

Sistemas que mudam o papel no mesmo enlace precisam preservar a mesma divisão lógica. Devem registrar a referência protegida da credencial, a identidade resultante, a política consultada, a regra plena instalada e a remoção da regra limitada. Se a troca falhar no meio, o padrão seguro é permanecer no estado mais estreito.

Essa cadeia não repete o artigo anterior sobre a RFC 9966. Uma prova TLS-POK pode mostrar conhecimento de uma chave Bootstrap específica, sem demonstrar como ela foi obtida ou quem a guarda legitimamente. Aqui, o objeto é o estado de rede aberto pelo EPI público. Provar chave não apaga ACL; apagar ACL não prova custódia.

Recibo de encerramento da via

Um recibo local e compacto pode conectar sete grupos:

  1. Pedido: EPI, método EAP, horário, autenticador ou NAS, interface e identificador efêmero de sessão, com a ressalva de que o EPI não autentica o par.
  2. Decisão: aceite ou recusa, revisão da política, capacidade disponível, categoria do motivo e serviço responsável.
  3. Enforcement: filtro, segmento, papel ou ACL realmente aplicado; versão; pontos de execução; allowlist; padrão de negação; isolamento entre pares.
  4. Orçamentos: início, expiração rígida, teto de bytes, serviços, contador de tentativas, estado do rate limit e ocupação da fila simultânea.
  5. Autenticação do servidor: método, referência de certificado ou âncora, resultado da validação e qualquer exceção estritamente delimitada.
  6. Resultado: sucesso ou classe exata de falha; referência protegida e vida prevista da credencial, sem material secreto.
  7. Fechamento: momento e motivo da remoção ou expiração, observação do ponto de aplicação, tratamento de fluxos residuais, eventual sessão autenticada e reconciliação de estados órfãos.

A camada pública pode divulgar distribuições de duração, versões de política, classes de falha e exceções não resolvidas. Identificadores, certificados, portas e detalhes da allowlist permanecem sob acesso controlado. Hashes podem vincular o resumo ao registro privado, mas não provam que a decisão de origem era legítima.

“Recibo de encerramento” é um termo editorial proposto por Daniel Kade. Não é campo da RFC 9965, certificado de conformidade ou objeto da API de artigos. O propósito é dar forma verificável a uma responsabilidade que permanece local.

Expirar no controlador não basta

O TTL pode chegar a zero na base do controlador e a ACL continuar no switch. Uma ordem de remoção pode ser aceita, mas não aplicada, ou atingir uma geração anterior. No sentido oposto, o equipamento pode fechar a via e o orquestrador continuar exibindo sessão ativa.

O recibo deve guardar o prazo planejado, o evento no plano de controle e a observação no plano de dados. O intervalo entre eles é informação operacional. “Expiração automática” e “remoção confirmada” também não são sinônimos.

A falha precisa terminar de modo estreito. Portal indisponível não justifica Internet aberta. Serviço de certificados lento não autoriza extensão silenciosa. Uma configuração inválida não permite que o par espere para sempre. O estado limitado deve terminar de forma previsível, independentemente do resultado.

Uma revisão robusta compara política pretendida, estado aplicado durante a sessão e estado residual. Uma diferença não deve desaparecer em um indicador verde agregado. Ela é o caso a investigar.

Essa comparação segue o Policy Mirror de Heng Lu: a regra escrita mostra onde a autoridade deveria estar; a configuração em execução mostra quem consegue exercer poder. Governança exige observar ambas e registrar o momento em que a exceção deixa de existir.

Limites e fontes

As fontes demonstram arquitetura de padrões, registros e riscos declarados. Elas não medem adoção, não identificam implantação de uma operadora e não relatam incidente. Mecanismos, prazos e fronteiras de privacidade variam por ambiente.

O recibo não é identidade do equipamento, autorização legal, perfil de diretório ou credencial de rede. Ele preserva uma afirmação menor: houve acesso provisório sob limites conhecidos e esse acesso terminou antes que uma nova autenticação decidisse o próximo estado.