Resumo

  • Em 24 de agosto de 2026, o IESG aprovou draft-ietf-ipsecme-ikev2-pqc-auth-12 como Proposed Standard. No fechamento das evidências, em 27 de agosto, o texto continuava sendo um Internet-Draft ativo na fila do RFC Editor, e não um RFC numerado.
  • O documento define como ML-DSA e SLH-DSA em modo puro podem usar o método Digital Signature já existente no IKEv2. Ele não comprova que um gateway selecionou esses algoritmos, entregou a autenticação volumosa pelo caminho real, verificou AUTH, estabeleceu uma IKE SA ou autorizou uma Child SA.

Dois gateways aprovados pelo inventário

Uma revisão de migração encontra dois gateways com a mesma faixa verde: “pronto para pós-quântico”. Ambos têm uma credencial ML-DSA cadastrada e uma versão de software que reconhece o algoritmo. Para o painel patrimonial, o trabalho terminou.

Na captura, as conexões divergem. Uma política local permite fallback e o AUTH efetivamente usa ECDSA. No outro gateway, a autenticação pós-quântica produz mensagens bem maiores, mas os fragmentos não chegam a ser reagrupados no percurso operacional. Nenhum dos dois túneis foi autenticado por ML-DSA.

O cenário é analítico, não um incidente atribuído a um produto. Ele separa a novidade institucional de seu efeito operacional: a aprovação do IESG torna um mecanismo comum publicável; a execução determina se alguma sessão o usou.

O estado exato da notícia

O comunicado de 24 de agosto afirma que a revisão 12 de “Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC” foi aprovada como Proposed Standard. O trabalho vem do grupo IP Security Maintenance and Extensions e acrescenta esquemas pós-quânticos ao arcabouço de assinatura já presente no IKEv2.

No dia 27, o Datatracker mostrava o documento na “RFC Ed Queue”, aguardando checagem de referências e formatação. Ele estava datado de 21 de agosto e previa expiração em 22 de fevereiro de 2027. Portanto, ainda era um Internet-Draft sujeito a ajustes editoriais. Chamar o texto de RFC publicada apagaria essa fronteira.

O documento também não solicita novas atribuições à IANA. Ele combina registros existentes: Digital Signature é o método de autenticação 14; IKEV2_FRAGMENTATION_SUPPORTED, a notificação 16430; SIGNATURE_HASH_ALGORITHMS, 16431; SUPPORTED_AUTH_METHODS, 16443; e Identity, o algoritmo de hash 5. Esses números dão vocabulário comum aos pares, não telemetria de uma conexão.

O algoritmo escolhido aparece no AUTH

IKE_SA_INIT negocia parâmetros criptográficos, troca nonces e valores de estabelecimento de chaves. IKE_AUTH transporta identidades, prova o segredo correspondente e normalmente negocia a primeira Child SA. Uma característica do primeiro estágio não substitui o resultado do segundo.

O RFC 7427 define o método genérico Digital Signature. Authentication Data começa com um AlgorithmIdentifier codificado em DER e depois carrega a assinatura. É esse identificador observado no AUTH que informa qual esquema e conjunto de parâmetros produziu a prova.

Para ML-DSA e SLH-DSA, o novo projeto escolhe o modo puro. Os dados específicos da sessão chegam ao algoritmo sem um prehash externo. Por isso, os dois pares devem incluir Identity, valor 5, em SIGNATURE_HASH_ALGORITHMS; um esquema que exige Identity não pode ser usado quando o outro lado não anunciou esse valor.

Identity 5, porém, não significa ML-DSA. Ela descreve o tratamento da entrada. Ver o valor nos dois sentidos comprova uma condição necessária. A seleção está no AlgorithmIdentifier; certificado e verificação dizem se foi aceita.

Anunciar suporte não escolhe a credencial

O projeto cita Certificate Request e SUPPORTED_AUTH_METHODS, do RFC 9593, como formas de ajudar os pares a encontrar tipos de chave compatíveis. A segunda opção pode anunciar uma lista ordenada de métodos ou esquemas.

Enviar a notificação e usar seu conteúdo são decisões opcionais. A lista evita tentativas cegas quando há várias credenciais, mas não compromete o AUTH posterior. Um gateway pode anunciar ML-DSA e usar ECDSA por política, apresentar uma cadeia não confiável ou falhar na verificação.

FIPS 204 padroniza ML-DSA e FIPS 205, SLH-DSA. RFC 9881 e RFC 9909 definem identificadores, codificações PKIX e limites de uso. Eles resolvem peças importantes da interoperabilidade, mas não provisionam chave privada, emitem certificado, escolhem raiz de confiança, garantem capacidade de HSM nem comprovam interoperabilidade entre produtos.

O inventário operacional deve ligar a conexão a um identificador de chave, impressão digital do certificado, cadeia emissora, key usage, provedor criptográfico e build de software.

O tamanho inclui o caminho na evidência

Os valores do projeto mudam a engenharia do handshake. Uma chave pública ML-DSA-44 ocupa 1.312 bytes e sua assinatura, 2.420 bytes. Até a menor assinatura SLH-DSA chega a cerca de 7.856 bytes. A cadeia de certificados aumenta o conjunto.

Por isso, pares que implementam o mecanismo precisam suportar fragmentação de mensagens IKEv2. O RFC 7383 anuncia IKEV2_FRAGMENTATION_SUPPORTED durante IKE_SA_INIT e permite fragmentar mensagens posteriores com payload Encrypted. O próprio IKE_SA_INIT não pode usar essa fragmentação.

O anúncio não prova entrega. Um firewall, NAT, balanceador ou enlace instável pode impedir o reagrupamento. Transporte confiável ou PMTU conhecida e suficiente pode tornar a fragmentação desnecessária. A prova deve registrar suporte nos dois sentidos, quantidade e tamanho dos fragmentos cifrados, retransmissões, reagrupamento e resposta final.

Estabelecimento de chaves não é assinatura

O rótulo “VPN pós-quântica” costuma fundir duas propriedades. O estabelecimento de chaves contribui para o segredo compartilhado e a confidencialidade. A assinatura autentica um par por meio de sua identidade, credencial e transcrição de sessão.

O RFC 9370 permite múltiplas trocas de chaves e declara que seu foco urgente é a confidencialidade; autenticação ficou fora do escopo. O RFC 8784 mistura uma chave pré-compartilhada adicional, mas preserva as verificações de autenticação existentes. Assim, uma sessão pode ter contribuição pós-quântica na chave e ainda usar ECDSA no AUTH.

O inverso também vale. Uma assinatura ML-DSA não revela quais grupos estabeleceram o segredo. Relatórios precisam mostrar os dois eixos.

Depois do AUTH vem a autorização

Uma assinatura verificada comprova os octetos específicos daquela sessão sob a credencial aceita. Ela não libera automaticamente todos os seletores de tráfego, redes, usuários ou aplicações. Uma IKE SA pode existir mesmo quando a primeira Child SA falha.

Uma declaração auditável conecta: revisão implementada; software e provedor; chave e cadeia; anúncios em cada direção; AlgorithmIdentifier realmente usado; fragmentos, reagrupamento e verificação; identidade da IKE SA e eventual fallback; política, seletores e tráfego protegido da Child SA. Só no fim dessa sequência “autenticado por assinatura pós-quântica” descreve um resultado real.

Fontes