Resumo

  • No exemplo agressivo de três mensagens do RFC 2412, as assinaturas podiam ser validadas e o KEYID podia ser marcado como autenticado enquanto o segredo Diffie–Hellman permanecia uncomputed.
  • Prova de comunicação, cálculo de chave, vínculo de identidade, instalação bilateral, pacote protegido e resultado do serviço eram recibos diferentes.

Uma sessão pode dizer a verdade e ainda assim induzir o operador ao erro. Basta que a palavra verdadeira seja ampla demais.

O RFC 2412, publicado em novembro de 1998 como Informational, descreveu o OAKLEY. O protocolo usava Diffie–Hellman para permitir que duas partes autenticadas chegassem a material secreto, com opções de sigilo futuro, escolha de algoritmos, grupos definidos pelos participantes, atualização e incorporação de chaves externas. O documento não era um padrão da Internet e não dizia que sua troca, sozinha, instalava o estado que AH ou ESP usariam.

No exemplo agressivo, o iniciador enviava cookie, grupo, valor público g^x, ofertas de algoritmo, identidades e nonce, além de uma assinatura. O respondente acrescentava seu cookie, g^y, escolhas, outro nonce e sua assinatura. Uma terceira mensagem assinada encerrava o diálogo.

Essas assinaturas, dizia o texto, podiam oferecer uma prova de comunicação capaz de ser guardada e mostrada posteriormente. Logo depois vinha a limitação: o material implícito nos expoentes de grupo não era necessário para concluir o intercâmbio.

A implementação podia guardar x e g^y, marcar o material como uncomputed e calculá-lo mais tarde.

O roteiro de processamento não deixava a separação apenas no plano conceitual. O iniciador validava a assinatura do respondente, anexava g^y ao estado e podia calcular (g^y)^x = g^xy. Mas esse cálculo podia esperar até depois do envio da resposta final. Mesmo assim, o KEYID era marcado como autenticado. O respondente, ao validar a última assinatura, marcava a chave autenticada e então deveria calcular g^xy e associá-lo ao KEYID.

O protocolo tinha concluído uma autenticação. A máquina ainda podia dever uma exponenciação.

O próprio KEYID demonstrava que nome e conteúdo eram diferentes. Os dois cookies tinham função fraca de validação de endereço e defesa contra congestionamento, mas também formavam o nome reutilizável do material de chave. sKEYID era o segredo indicado por esse nome, nunca transmitido, derivado no exemplo a partir de g^xy, dos nonces e dos cookies. Um nome podia ser conhecido e autenticado antes que os bytes secretos existissem.

Em produção, a distinção tende a desaparecer atrás de um único campo. O log registra “authenticated”; o painel mostra verde; a aplicação entende “pronto”; o operador presume SAs recíprocas e tráfego protegido. Cada passo toma emprestada a evidência do estágio seguinte.

Adiar o cálculo não era necessariamente imprudente. Exponenciação modular tinha custo alto. Retirá-la do caminho crítico da mensagem final podia reduzir a latência percebida ou distribuir o uso de CPU. O par continuava recebendo os mesmos campos assinados. O contrato de rede não precisava determinar o instante interno exato de cada operação.

A economia imediata, porém, criava uma obrigação de custódia. Era preciso reter o expoente privado certo, o valor público do par, o grupo escolhido, os cookies, os nonces, as identidades e os algoritmos. Em seguida, validar a entrada, calcular o segredo, derivar o material e ligá-lo à sessão certa. Reinício, expiração, reutilização de referência ou perda de estado podiam preservar o transcript assinado e destruir a possibilidade de completar a chave.

Por isso a cadeia de provas precisa de vários recibos. O recibo do transcript confirma uma assinatura sobre campos determinados. O recibo de validação confirma que o elemento público passou nos testes aplicáveis. O recibo de cálculo confirma a produção de g^xy e de seus derivados. O recibo de vínculo une esse material ao KEYID, às identidades e aos algoritmos corretos. O recibo de instalação demonstra a SA local. O recibo do outro extremo demonstra o estado recíproco. Pacotes e resultado da aplicação vêm depois.

Nenhum recibo deve falar em nome do próximo.

O RFC 2412 já recomendava rejeitar certos valores degenerados e exigia boa aleatoriedade para cookies, nonces e expoentes. Sua errata pública corrige a terminologia sobre primos seguros e primos de Sophie Germain, sem alterar a possibilidade de cálculo adiado.

O RFC 6989, anos depois, tornou mais explícitos os testes de valores públicos Diffie–Hellman em IKEv2, inclusive para grupos com subgrupos pequenos. Um payload KE inválido deveria ser descartado e não poderia participar da criação da SA. Isso não comprova quais verificações uma implementação anterior realizava. Apenas reafirma a ordem: receber não é validar, validar não é calcular e calcular não é instalar.

O RFC 2409 levou elementos de ISAKMP e OAKLEY ao IKEv1. O Modo Agressivo também podia deixar a mensagem final sem proteção da SA e postergar a exponenciação até o fim da troca. Ainda assim, a derivação dependia do valor compartilhado real. Um rótulo de conclusão não fabricava material criptográfico.

As gerações de IKEv2 reorganizaram o processo nos RFCs 4306, 5996 e 7296. No RFC 7296, SKEYSEED é calculado com os nonces e o segredo Diffie–Hellman efêmero, antes da derivação de chaves distintas. O texto ainda diferencia a autenticação bem-sucedida da SA IKE de uma SA filha ou solicitação de configuração que pode falhar.

Não é a mesma máquina de estados do OAKLEY. É outra demonstração de que a conclusão do plano de controle não prova o funcionamento de tudo que depende dele.

Também é preciso separar o histórico documental do inventário real. O RFC 2412 era Informational. O IKEv1 entrou na trilha de padrões; o IKEv2 o substituiu; os requisitos algorítmicos mudaram; o RFC 9395 desaconselhou IKEv1 e algoritmos antigos. Uma publicação altera a orientação. Não remove código de todos os equipamentos em atividade.

A Primazia do Código em Execução, na formulação de Lu Heng, oferece uma disciplina para a leitura. A especificação define o significado pretendido da transição; a implementação em execução produz a evidência de que ela ocorreu. As camadas de realidade devem permanecer visíveis: mensagem, assinatura, validação, cálculo, vínculo, instalação, pacote e serviço.

A Especificação Inicial Mínima mostra onde deixar liberdade. Interoperabilidade exigia transcript, derivação e semântica comuns. Não exigia que cada processador executasse a exponenciação no mesmo ponto, desde que a escolha local preservasse segurança e compatibilidade.

Liberdade local, no entanto, vem com responsabilidade local. Quem escolhe o adiamento controla o intervalo oculto entre “autenticado” e “calculado”. Deve guardar as entradas, expor o estado e retirar toda promessa posterior se o cálculo falhar. A aplicação que sofre a consequência não pode depender de uma luz verde sem definição.

Uncomputed é uma palavra historicamente valiosa porque nomeia uma ausência sem negar a prova já obtida. A assinatura era válida. A próxima realidade ainda não existia.

O intercâmbio foi autenticado. O segredo ainda precisava ser calculado. A SA precisava ser ligada e instalada. O pacote precisava passar. O serviço precisava responder.

Sistemas confiáveis não condensam esses verbos em um só.

Fontes