Resumo

  • draft-ietf-emu-eap-ppt-04 elimina os 128 octetos que a revisão anterior derivava do exportador TLS externo e agora declara que EAP-PPT não produz MSK nem EMSK.
  • O token Privacy Pass é uma credencial ao portador transmitida dentro do túnel. O terminador vê o token e calcula o mesmo valor exportado; esses bytes não provam que terminador e portador são a mesma parte.

O exportador criptográfico cumpriu sua função e devolveu 128 octetos. O defeito estava na interpretação posterior: o resultado parecia autorizar uma afirmação que suas entradas não sustentavam.

A revisão 03 de Extensible Authentication Protocol (EAP) Using Privacy Pass Token derivava o valor do túnel TLS externo sob o rótulo EXPORTER_EAP_PPT_Key_Material. O contexto incluía o tipo EAP e o token resgatado. A implementação poderia reportar a saída como Master Session Key e Extended Master Session Key de EAP-PPT.

Datada de 30 de setembro, a revisão 04 apaga essa construção. O texto agora diz que EAP-PPT não gera MSK ou EMSK e não deve entregar material de chave ao método de túnel. A mudança não enfraquece o protocolo; impede que bytes de aparência convincente representem uma ligação entre portador e sessão que nunca foi estabelecida.

Um token ao portador não acrescenta segredo exclusivo

EAP-PPT é um método EAP interno. O peer obtém um token Privacy Pass fora de banda com um emissor, entra num túnel TLS com servidor autenticado por outro método EAP e envia o token ao servidor EAP-PPT para resgate.

No tipo publicamente verificável, o servidor usa a chave pública do emissor. No tipo verificável em privado, usa material compartilhado entre emissor e servidor EAP-PPT. Nenhum dos dois cria novo segredo compartilhado entre peer e servidor. O peer demonstra posse ao transmitir uma credencial transferível; o servidor verifica sua validade.

O exportador TLS pertence à sessão externa. Qualquer parte que termine o túnel consegue calcular a mesma saída. Como o token circula pelo interior desse túnel, o terminador também conhece o token usado no contexto. Incluí-lo distingue uma derivação de outra, mas não introduz uma entrada desconhecida por quem termina a sessão.

O valor pode ser novo, específico da sessão, corretamente rotulado e ter 128 octetos. Ainda assim não responde à pergunta decisiva: qual segredo exclusivo do peer interno contribuiu para ele? Nenhum. Comprimento e aleatoriedade aparente não substituem uma contribuição independente.

O TLS externo não comprova o peer interno

A diferença se torna perigosa em TEAP. Seu Crypto-Binding TLV pode combinar material do túnel com material de um método interno. Se EAP-PPT reporta como chave interna um valor produzido apenas pelo mesmo túnel e por um token visível ao terminador, o cálculo final parece unir duas provas independentes, embora uma só parte possua todas as entradas.

A revisão 04 explicita essa falha. Reportar o valor antigo permitiria que um método de túnel calculasse um Crypto-Binding TLV sem oferecer a garantia de que EAP-PPT foi criptograficamente vinculado ao túnel. A sequência de mensagens aparentaria dois contribuidores; a estrutura real teria apenas um.

O limite corrigido é direto. EAP-PPT autoriza o peer por meio do resgate do token, mas não fornece chaves para o enlace. Esse material vem do método EAP externo. Se uma plataforma ainda exibe MSK ou uma chave do tipo exporter para EAP-PPT, não encontrou proteção adicional: reintroduziu a ambiguidade removida.

Um método interno sem chave muda a defesa contra relay

Sem binding criptográfico interno, a validação do certificado do servidor vira a primeira linha contra relay. Se um atacante convencer o peer a aceitar seu túnel TLS, poderá retransmitir a troca EAP-PPT a um serviço legítimo, observar o token ao portador e resgatá-lo para obter acesso próprio.

Por isso o draft exige validação rigorosa e específica da rede do certificado do servidor EAP. O peer deve conferir a identidade esperada, rejeitar falhas em vez de pedir uma exceção ao usuário e não confiar no primeiro uso. Quando origin_info é preenchido e comparado à identidade do certificado, ele restringe a substituição do challenge. Não cria chave interna.

A posição dos servidores também integra o modelo. Colocar EAP e EAP-PPT no mesmo servidor remove uma separação explorável dentro do provedor. Dividir servidores de Phase 1 e Phase 2 não é recomendado sem relação explícita e protocolo protegido entre eles. Trata-se de uma fronteira de confiança, não apenas de arquitetura operacional.

Channel binding pode mostrar divergência entre a rede que o peer pensa ter acessado e o authenticator conhecido pelo servidor. Tokens curtos limitam a janela de perda; detecção de gasto duplo pode revelar relay depois do fato. São controles úteis, mas não transformam a saída eliminada em prova de continuidade do portador.

O token pode ser gasto antes do veredito de contexto

A revisão 04 também define uma ordem que métricas genéricas de sucesso podem esconder. Após o resgate do token, o servidor EAP-PPT pode enviar EAP-Request/PPT-Channel-Binding antes de EAP Success. Pode omitir a solicitação quando um método EAP anterior já forneceu informação apropriada.

Ao receber essa mensagem, o peer sabe que o token foi aceito e está gasto. Eventos posteriores não revertem a condição. Uma resposta malformada, um valor de contexto inválido, erro EAP ou falha de acesso não tornam o token reutilizável. Regras de nova tentativa anteriores ao resgate deixam de valer.

“Token gasto” é, portanto, um recibo estreito. Prova resgate bem-sucedido, não channel binding aprovado, EAP Success, instalação de chaves externas, decisão RADIUS/NAS ou tráfego funcional.

Contar gasto como conexão funde várias decisões. Interpretar EAP Success como prova de que a mesma entidade portava o token e terminava o túnel repetiria na telemetria o excesso que a revisão 04 acabou de retirar do cronograma de chaves.

A revisão 04 muda mais do que a codificação

A nova versão troca o corpo JSON por TLVs no estilo TEAP e carrega estruturas Privacy Pass diretamente, sem strings base64url. Adiciona um TLV No-Suitable-Token, regras para comprimento, duplicidade, consumo completo e um nível de aninhamento, política M-bit para TLVs desconhecidos e vetores de teste em nível de octeto.

O código de erro 9 separa mensagem malformada sem resgate de falha de validação de um token bem formado. A distinção importa porque determina se a credencial pode ser reutilizada. O texto amplia ainda a análise de relay e esclarece recomendações para tipos públicos, privados e federados.

Precisão no fio não comprova adoção. O documento é um Internet-Draft ativo do grupo EMU, com intenção de Proposed Standard. Datatracker permanece em I-D Exists, sem diretor de área responsável, shepherd ou telechat. Não é RFC; o conjunto congelado não prova implementação, interoperabilidade, desempenho nem implantação.

A operação precisa unir recibos diferentes

Uma implantação auditável preserva separadamente a rede configurada e o nome esperado do servidor EAP; certificado validado, âncora e endpoint TLS real; challenge e origin_info; tipo de token, chave do emissor e digest do challenge; resultado e horário do resgate; origem e veredito do channel binding; EAP Success ou Failure; chaves externas; decisão RADIUS/NAS; e acesso de rede observado.

O certificado responde qual servidor o peer aceitou. O resgate responde se a credencial validou. O channel binding compara o contexto visto pelas partes. O resultado EAP encerra uma etapa. A política do NAS e o tráfego mostram se acesso útil realmente ocorreu. Um único campo “autenticado” não carrega essas relações causais.

A lição não diminui especificações. A revisão 04 é importante justamente porque se recusa a emprestar autoridade indevida a uma saída persuasiva. A operação real deve preservar as junções que os 128 octetos jamais poderiam demonstrar.

Fontes