Resumo

  • O Internet-Draft do grupo EMU, datado de 30 de setembro, afirma na versão 04 que EAP-PPT não deriva MSK nem EMSK e não deve comunicar material de chave desse método ao túnel EAP que o carrega. A versão 03 previa 128 octetos de um exportador TLS, divididos em dois blocos de 64. O texto continua em I-D Exists; não é RFC nem prova de implantação.
  • Verificar um token Privacy Pass permite tomar uma decisão de autorização, mas não cria um segredo compartilhado entre o par e o servidor EAP-PPT. O ponto que termina o TLS já consegue calcular o valor exportado. Chamá-lo de chave independente do método interno poderia sugerir uma vinculação criptográfica que o token não forneceu.

Uma auditoria de acesso pode apresentar três marcas verdes: certificado aceito, token resgatado e chave entregue ao autenticador. Elas não representam a mesma demonstração. A proposta EAP-PPT transporta um token Privacy Pass dentro de um túnel TLS autenticado pelo servidor. Quem decide aceitar o token é o servidor EAP-PPT; quem fornece a chave de enlace é o método EAP baseado no túnel. A revisão 04 torna essa divisão explícita depois de uma versão que misturava as duas origens.

A seção 6.6 da versão anterior especificava a derivação. O exportador da sessão TLS externa produziria 128 octetos, com o tipo EAP e o token no contexto; metade receberia o nome de Master Session Key e a outra metade, Extended Master Session Key. A seção 5.7 do texto novo remove a construção e estabelece que nenhuma das duas chaves é produzida pelo EAP-PPT. A proibição de reportar material de chave interno não elimina a proteção do túnel. Impede que um valor dele seja registrado como contribuição independente do token.

O motivo está em quem conhece cada segredo. Uma modalidade de token é verificada com a chave pública do emissor. Outra usa material compartilhado entre emissor e servidor EAP-PPT. O par que apresenta o token não participa desse segredo compartilhado. Sua posse é demonstrada ao transmitir uma credencial ao portador; não há, nesse ato, uma negociação de chave nova com o servidor. Já o terminador TLS dispõe da sessão necessária para calcular o exportador. A existência de bytes calculáveis não responde à pergunta sobre qual identidade ou vínculo eles provam.

O quadro de alegações de segurança da revisão 04 registra Key derivation: No e Cryptographic binding: No para EAP-PPT, mas Channel binding: Yes. Essa última verificação compara informações da rede vistas pelo par com informações do lado do servidor; não substitui o segredo inexistente do método interno. Também seria incorreto concluir que todo o acesso é sem chaves: o túnel continua responsável pela autenticação do servidor e pela entrega da chave de enlace. A mudança delimita apenas o que o token pode reivindicar.

O novo cenário de retransmissão da seção 9.4 mostra por que a diferença tem efeito prático. Se o par aceitar o certificado de um atacante, poderá entregar o token por um túnel com ele; o atacante pode então encaminhar a troca interna ao servidor verdadeiro e gastar o token em seu próprio acesso. O rascunho aponta como defesa primária a validação rigorosa do certificado contra âncoras de confiança específicas daquela rede e a identidade esperada do servidor. Não recomenda confiança no primeiro uso nem exceção aprovada pelo usuário após uma falha.

Servidores colocados juntos, vinculação de canal, vida curta e detecção de gasto duplo podem reduzir as consequências, sem transformar uma credencial ao portador em prova criptográfica de posse do túnel.

A mesma revisão troca JSON por TLV e detalha análise de mensagens e erros. São alterações técnicas reais, mas não um relato de incidente ou de falha de produto. O fato noticioso delimitado é a retirada de uma alegação de chave que o próprio terminador do túnel podia satisfazer. O nome dado a uma chave não pode servir como atalho para demonstrar a origem da autorização.

Fontes