Resumo

  • O sucesso de um método EAP e a exportação do MSK não encerram a prova da sessão em RFC 9820. O autenticador envia o Step 7 protegido por OSCORE; o peer o verifica e devolve o Step 8 2.04 Changed, também protegido, para confirmar bilateralmente o contexto derivado.
  • Um contexto comum não autoriza todos os recursos. Admissão inicial, política da aplicação, duração, reautenticação, substituição de geração e exclusão forçada são decisões diferentes, tomadas e concluídas por atores diferentes.
  • O recibo mínimo liga gerações de recursos CoAP, resultado EAP, linhagem não secreta de derivação, negociação, Recipient IDs, verificações 7/8, política efetiva, acknowledgements de exclusão e tráfego observado, sem registrar o MSK.

O firewall acreditou numa palavra maior que o evento

No cenário hipotético, o sistema de identidade publicou um fato legítimo: o método EAP chegou a sucesso no autenticador. Um automatismo traduziu esse fato para “dispositivo admitido” e depois para “rede de aplicação liberada”. A primeira seta ainda precisava da confirmação protegida; a segunda precisava de política de recurso. Nenhuma constava do recibo.

RFC 9820 especifica EAP sobre CoAP para ambientes restritos. O dispositivo IoT desempenha o papel de EAP peer e, ao mesmo tempo, hospeda o serviço como CoAP server. O Controller é o EAP authenticator e envia pedidos como CoAP client. Um backend AAA pode participar em modo pass-through.

Esses papéis impedem descrições vagas. “O cliente foi autenticado” não identifica se cliente significa função CoAP, equipamento, peer EAP ou organização responsável. Uma evidência séria preserva o papel protocolar, a instância, o principal da política e a aplicação que decide o efeito.

A página do RFC Editor e o registro no Datatracker classificam RFC 9820 como Standards Track do IETF, publicado em setembro de 2025 a partir do grupo ACE. Isso estabelece autoridade documental. Não comprova implementação, conformidade, implantação, admissão ou resultado em um produto.

O endereço de cada Step faz parte do transcript

O intercâmbio não usa um único recurso permanente. O peer cria um recurso CoAP para o passo seguinte e remove o anterior. Location-Path ou Location-Query aponta para o próximo destino aceitável.

Assim, uma geração antiga não volta a ser atual porque um pacote atrasado reapareceu. O Step 0 duplicado durante autenticação ativa deve ser descartado. Um trigger velho que chega sem sessão pode parecer um novo início ao authenticator, enquanto o peer informa que o recurso esperado não existe.

RFC 7252 define pedidos, respostas e confiabilidade de CoAP. RFC 4137 descreve as máquinas EAP. RFC 9820 compõe as duas ordens; um painel operacional não pode substituí-las por um status único.

O recibo deve nomear peer e authenticator em seus papéis, geração atual, geração eliminada, IDs de pedido e resposta, transição EAP, resultado CoAP, relógio e observação de transporte. Se uma repetição cair em outra geração, é preciso dizer se foi descartada, rejeitada ou interpretada como nova tentativa.

O MSK no autenticador é o começo de outra prova

No Step 7, o método EAP bem-sucedido entrega ao autenticador o MSK, a mensagem EAP Success e informações como Session-Lifetime. RFC 5247 organiza o EAP Key Management Framework. RFC 9820 exige um método capaz de exportar MSK e EMSK de pelo menos 64 octetos.

Ter o MSK em um lado não demonstra que ambos instalaram a mesma proteção. RFC 9820 deriva OSCORE Master Secret e Master Salt do MSK, do transcript da negociação de cipher suite e de context strings definidos. Recipient IDs determinam os sentidos de envio e recepção. RFC 5869 define HKDF; RFC 8613 define OSCORE.

O autenticador envia EAP Success em um POST protegido por OSCORE. O peer obtém seu MSK, deriva o contexto e precisa verificar o pedido. Step 7 não é uma embalagem colocada depois da decisão. Ele testa se a conclusão local do autenticador pode atravessar para o outro endpoint sob a proteção derivada.

O registro deve guardar fingerprint do transcript, método e suite, Recipient IDs, geração de derivação, versões executadas e resultado de verificação. Guardar o próprio MSK para facilitar auditoria criaria uma cópia do segredo onde não deveria existir.

A resposta do peer é uma testemunha independente

Depois de verificar o Step 7, o peer devolve 2.04 Changed protegido. Ao verificar o Step 8, o autenticador obtém evidência de que o peer derivou o mesmo Master Secret e conseguiu usar o contexto correspondente.

Há cinco marcos, não um: resultado do método; exportação; derivação local; verificação do Step 7; verificação do Step 8. Perder a última resposta não apaga os anteriores, mas impede afirmar que a confirmação bilateral terminou.

A negociação criptográfica participa da derivação. Uma mudança no transcript produz contextos incompatíveis, detectados nas mensagens protegidas. Os registros IANA CoRE Parameters e IANA EAP Parameters definem codepoints, não provam o que endpoints reais negociaram ou executaram.

Uma métrica madura mostra separadamente quantos métodos terminaram, quantos peers verificaram Step 7 e quantos authenticators verificaram Step 8. A diferença entre os números é estado operacional que precisa de tratamento, e não ruído a ser escondido.

Proteger um pedido não concede o recurso

Após Step 8, a última recurso CoAP-EAP precisa usar OSCORE. O contexto também pode proteger outros recursos se a política de aplicação permitir. A expressão condicional preserva a autoridade do dono do recurso.

Autenticação conclui algo sobre o peer. Confirmação conclui algo sobre posse compatível de proteção. Autorização decide se esse peer pode fazer essa operação agora. Resultado é o efeito que realmente ocorreu. O mesmo identificador pode ligar essas camadas; não pode torná-las equivalentes.

Na arquitetura com AAA, a organização responsável pelo peer pode fornecer autorização via RADIUS ou Diameter. Em modo standalone, a informação vive no authenticator. Depois do bootstrap pode existir controle mais fino. RFC 9200 define OAuth para ACE, mas um token ou referência de padrão não substitui o recibo da decisão aplicada.

O Controller que conhece o MSK não passa a possuir a política da organização. O AAA que envia atributo não demonstra enforcement. Uma mensagem OSCORE válida pode chegar a um recurso fora do conjunto permitido. Por isso a trilha precisa unir policy version, principal, decisão, pedido e efeito.

Durante a autenticação, o tráfego IP desprotegido deve se limitar ao necessário para CoAP-EAP. Abrir uma rede inteira ao ver EAP Success apaga a fronteira entre transporte de autenticação e acesso de aplicação.

Renovar cria uma janela com duas gerações

Quando Session-Lifetime não é informado, RFC 9820 usa oito horas por default conforme a recomendação de RFC 5247. O número não é um objetivo universal nem prova da configuração executada.

Durante a reautenticação, o estado atual e um novo candidato coexistem. O estado antigo é substituído quando a nova autenticação termina com sucesso completo. Se a tentativa falha, ele pode continuar até expirar ou outra tentativa vencer.

Início não é ativação. Registrar apenas a geração mais recente elimina a capacidade de explicar qual contexto autorizou um pedido. É necessário marcar início, método, Step 7, Step 8, decisão de policy, activation, último uso antigo, retirement e expiry.

Se duas gerações aceitam tráfego, a política precisa dizer se o overlap foi planejado e que operações irreversíveis são proibidas nessa janela. A configuração desejada não supera o código em execução que continua validando o contexto anterior.

Exclusão local não equivale a retirada global

Na remoção forçada, o authenticator envia DELETE protegido ao último recurso de estado; o peer responde 2.02 Deleted, também protegido. Se a resposta não chega até EXCHANGE_LIFETIME, o autenticador apaga seu estado local.

O timeout resolve consumo local de recursos, não demonstra que o peer recebeu o DELETE. Uma partição pode deixar o Controller sem sessão, o peer com contexto, a aplicação com cache e a rede encaminhando novas tentativas.

O recibo inclui decisão e principal, razão, geração, DELETE transmitido, recepção remota quando conhecida, resultado no peer, resposta protegida, verificação, timeout, limpeza local, invalidação downstream, recusas posteriores e cessação observada. “Removido” sem ator e camada é uma conclusão grande demais.

A confiança antecede a autenticação que o painel mostra

RFC 9820 não define discovery do authenticator ou intermediary. Encontrar um serviço não prova que seja a autoridade pretendida. RFC 6677 oferece EAP channel binding e lower-layer identifiers que podem revelar divergências, mas a sessão concreta precisa registrar configuração e resultado.

O peer pode confiar no authenticator com MSK porque seu AAA server confiou nesse authenticator. Trata-se de delegação delimitada no framework de chaves, não de uma qualidade permanente chamada “Controller confiável”.

Step 0 forjado também pode consumir estado. O RFC recomenda rate limiting e pouco estado até EAP-Response/Identity. Contadores mostram que o limite foi aplicado; não atestam a identidade de cada origem.

O laboratório deve produzir desacordo de propósito

O teste mínimo reúne peer, authenticator, AAA pass-through, duas aplicações com policies diferentes e um observador de pacotes. Executa o caminho feliz e depois altera o transcript, perde Step 7, perde Step 8, reproduz geração antiga, duplica Step 0, falha reautenticação, mede overlap, nega o segundo recurso e faz DELETE com e sem acknowledgement.

Para cada caso, compara estado EAP, recurso CoAP, verificação OSCORE, policy e efeito observado. O ensaio fracassa se resumir tudo em success ou failure.

O caso mais útil mantém o contexto criptográfico correto e nega um recurso. Ele prova que a autorização não é um remendo para criptografia falha: é uma decisão legítima que permanece necessária mesmo quando a criptografia funciona.

O limite do que as fontes demonstram

RFC 9820 não identifica implantação, fabricante ou operador. Não publica consumo de energia, latência, perda, contagens de admissão, ataques observados ou resultados de conformance. Seus cenários são explicativos.

O histórico no Datatracker, os documentos que citam RFC 9820 e as referências do RFC registram relações documentais. A busca de errata informa estado editorial, não o risco de uma instalação.

RFC 3748 define EAP de forma ampla. A existência do framework não permite inferir identidade, autorização ou resultado de um equipamento específico.

Fontes

  1. IETF Datatracker: RFC 9820
  2. Histórico de RFC 9820
  3. Documentos que citam RFC 9820
  4. Referências de RFC 9820
  5. Heng Lu: especificação inicial mínima
  6. Heng Lu: camadas de realidade
  7. Heng Lu: primazia do código em execução
  8. IANA CoRE Parameters
  9. IANA EAP Parameters
  10. Errata de RFC 9820
  11. RFC Editor: RFC 9820
  12. RFC 3748
  13. RFC 4137
  14. RFC 5247
  15. RFC 5869
  16. RFC 6677
  17. RFC 7252
  18. RFC 8613
  19. RFC 9200
  20. RFC 9820