Resumo

  • A Quick Mode derivava material fresco com Ni e Nr. Sem KE adicional, esse material ainda dependia da exponenciação da fase 1; com KE, um novo Diffie-Hellman podia fornecer PFS às chaves da fase 2.
  • PFS, autenticação do transcript e instalação eram propriedades diferentes. HASH(3) fechava a troca para o respondedor, mas não gerava um quarto recibo para o iniciador nem incluía o resultado das SA em dois kernels.

Um sistema pode ter chaves com sigilo futuro perfeito e ainda não ter um túnel utilizável. A frase parece contraditória apenas quando “chave”, “SA instalada” e “serviço” são tratados como o mesmo objeto.

A RFC 2409 não os tratou assim. IKE foi formado sobre o framework ISAKMP da RFC 2408 e o vocabulário IPsec da RFC 2407, combinando técnicas de Oakley e SKEME. O protocolo organizou autenticação, troca de chaves e negociação sem prometer que cada efeito local viajaria no fio.

A fase 1 estabelecia uma SA ISAKMP autenticada e bidirecional. Main Mode tinha implementação obrigatória; Aggressive Mode era recomendado. As duas alternativas geravam material autenticado a partir de Diffie-Hellman efêmero, mas tinham diferenças de sequência e proteção de identidade.

A fase 2 usava Quick Mode. Ela não era uma troca completa independente: dependia da fase 1. Sob a SA ISAKMP existente, negociava SA para IPsec ou outro serviço que precisasse de chaves e parâmetros.

O reaproveitamento reduzia custo, mas exigia separar pai e filhos. O par de cookies identificava a SA ISAKMP. Um Message ID identificava uma Quick Mode específica. A combinação do último bloco CBC da fase 1 com esse Message ID criava o IV inicial da troca filha.

Várias Quick Modes podiam correr ao mesmo tempo. Cada uma tinha cadeia IV independente e estado próprio. O fato de compartilharem autenticação de fase 1 não as tornava a mesma negociação, nem garantia que todas chegariam ao plano de dados.

O primeiro pacote de Quick Mode levava HASH(1), a proposta SA e Ni. Podia incluir KE e identidades clientes. Tudo depois do cabeçalho ISAKMP era cifrado pela SA da fase 1.

HASH(1) autenticava o Message ID e o restante integral da mensagem. O respondedor obtinha evidência de que alguém com o estado autenticado enviou aquela proposta, aquele nonce e aquelas identidades opcionais.

Uma proposta autenticada continuava sujeita à política local. O respondedor podia recusá-la ou escolher uma transformação oferecida. O hash não escrevia a decisão no kernel e não provava que a combinação caberia em hardware ou software.

O segundo pacote trazia HASH(2), a seleção e Nr. A função colocava Ni antes do restante da resposta. A RFC chamou essa inclusão de prova de vivacidade: o respondedor demonstrava que tinha processado o desafio atual.

Depois de verificar a resposta, o iniciador sabia que o outro detentor da fase 1 viu Ni, escolheu parâmetros e criou Nr. As duas partes podiam calcular o mesmo material se entendessem a proposta da mesma forma.

O terceiro pacote continha HASH(3). Seu cálculo juntava um octeto zero, o Message ID e os dois nonces. O respondedor verificava que o iniciador recebeu Nr e ainda conseguia operar no contexto autenticado.

Quem recebia a prova final era o respondedor. O iniciador a enviava e não recebia uma quarta mensagem de Quick Mode confirmando o recebimento. O fechamento criptográfico básico tinha, portanto, uma última aresta observada apenas de um lado.

Isso é uma inferência limitada da sequência definida, não uma alegação de que o protocolo prometia confirmação bilateral de instalação. Retransmissões, tráfego protegido e mecanismos adjacentes podiam fornecer novas observações. Eles não estavam dentro de HASH(3).

O Commit e o CONNECTED da RFC 2408 tratavam sincronização por outro caminho, também sujeito à perda da última mensagem. Essa adjacência ajuda a entender o problema, mas não substitui o recorte deste artigo: três hashes, derivação de fase 2 e a falta de recibo bilateral de instalação.

Sem KE na Quick Mode, KEYMAT era derivado de SKEYID_d, protocol, SPI, Ni e Nr. As chaves eram frescas por causa dos nonces. Repetir uma negociação antiga não deveria criar SA novas válidas.

Mesmo assim, o segredo da fase 2 continuava relacionado à exponenciação da fase 1. A RFC dizia que essa modalidade não fornecia PFS para as chaves geradas. Frescor não é sinônimo de independência histórica.

Com uma carga KE, as partes faziam outra exponenciação Diffie-Hellman e adicionavam o novo segredo compartilhado ao KEYMAT. Isso fornecia PFS à fase 2. Usar KE era opcional, mas as implementações tinham de suportá-lo.

Quando KE aparecia, o grupo Diffie-Hellman precisava ser consistente em todos os transforms de todas as propostas relevantes. Se identidades clientes aparecessem, elas também tinham de valer para todas as SA negociadas no conjunto.

PFS fala do passado diante de um comprometimento futuro. Se uma credencial ou segredo posterior vazar, o atacante não deveria recuperar automaticamente chaves anteriores. A propriedade não fala sobre o presente operacional da SA.

Uma entrada SAD pode falhar mesmo com KEYMAT perfeito. Pode haver falta de memória, conflito de seletor, limite de equipamento, transformação não programável, erro de driver, vida útil inválida ou mudança de política. Nada disso altera retroativamente a qualidade criptográfica da chave.

Da mesma forma, uma SA instalada pode nunca transportar um pacote. A rota pode estar errada, o fluxo pode não combinar com os seletores, uma direção pode faltar, o peer pode ter instalado parâmetros diferentes ou a aplicação pode estar indisponível.

As identidades IDci e IDcr mostravam que autorização era outra decisão. A fase 1 podia autenticar gateways; as identidades de fase 2 podiam descrever hosts, sub-redes ou protocolos atendidos. A identidade do negociador e o sujeito do tráfego não eram necessariamente iguais.

O hash podia vincular esses campos ao transcript. Não podia conceder ao gateway permissão universal. A política local ainda precisava dizer se aquele peer autenticado podia estabelecer aquela relação de clientes.

O respondedor autenticava sua escolha em HASH(2). O iniciador mostrava que viu a escolha em HASH(3). Nenhuma função recebia como entrada “retorno da chamada de instalação” ou “contador do primeiro pacote”. O transcript só podia proteger fatos representados nele.

As regras de IV reforçavam a disciplina. O primeiro IV da Quick Mode vinha da fase 1 e do Message ID. Os seguintes vinham do último bloco cifrado da mensagem anterior naquela troca.

Uma implementação não deveria atualizar o IV em execução ao simples receber de um ciphertext. Primeiro precisava decifrar, fazer verificações básicas e concluir que a mensagem realmente avançava a máquina de estados. Uma retransmissão válida não era um novo avanço.

Receber, decifrar, validar e avançar eram quatro eventos. Derivar, instalar e processar pacotes eram mais três. Observar a aplicação era outro. Uma única marca “VPN ativa” não continha todos eles.

O uso de UDP tornava a última mensagem vulnerável à perda. O iniciador podia reenviar HASH(3) se não visse tráfego ou outro sinal. O respondedor precisava reconhecer repetição e evitar duplicar efeitos locais.

O melhor registro é bilateral. No iniciador: HASH(2) validado, HASH(3) enviado, chaves derivadas, SA de entrada e saída instaladas, contadores. No respondedor: HASH(3) recebido e validado, instalações complementares, seletores e contadores. Só a correlação aproxima os dois mundos.

A lente de camadas de realidade de Lu Heng impede que uma prova tome emprestada a autoridade de outra. Message ID é correlação. HASH é transcript autenticado. Nonce e Diffie-Hellman são derivação. Política é autorização. SAD/SPD são estado executável. Contador é processamento. Aplicação é resultado.

O problema de agência aparece porque equipes diferentes controlam essas camadas. A autoridade de credenciais liga identidades. O dono da política autoriza seletores. O daemon IKE negocia. O kernel ou acelerador instala. Operações observa pacotes. O dono do serviço mede utilidade.

Uma especificação mínima comum não deveria substituir todos esses agentes. Ela precisava fixar cálculos e formatos suficientes para interoperabilidade. A decisão local e a diversidade de implementação continuavam válidas, acompanhadas da obrigação de registrar evidência local.

A primazia do código em execução exige juntar: cookies, credential e autenticação de fase 1, Message ID, Ni, Nr, KE, propostas, SPIs, verificação de hashes, versão de política, identificador de derivação, pedido e resposta de instalação, SA de runtime, seletores, contadores e teste de aplicação.

Essa cadeia dá diagnóstico. Se o respondedor não tem HASH(3), falta fechamento do transcript naquele lado. Se os daemons fecharam e um kernel não tem SA, falta instalação. Se as SA contam pacotes e o serviço falha, o problema está depois do IPsec.

A RFC 2409 saiu em novembro de 1998. A RFC 4109 atualizou requisitos algorítmicos de IKEv1. A RFC 4306 substituiu a família 2407/2408/2409 por IKEv2. A RFC 7296 tornou-se o Internet Standard de IKEv2. Em 2023, IKEv1 passou a Historic, e a RFC 9395 o depreciou e fechou registros relacionados.

A história da PFS ajuda justamente porque mostra o limite de uma garantia forte. Uma chave pode estar bem protegida contra o futuro e ainda faltar no kernel de hoje. A instalação exige seu próprio recibo.

Fontes