Resumo

  • A RFC 9867 permite combinar uma PPK ao IKEv2 por IKE_INTERMEDIATE e CREATE_CHILD_SA, inclusive para criar ou renovar uma Child SA ou uma IKE SA com uma PPK nova.
  • A resposta a CREATE_CHILD_SA pode omitir a identidade PPK e ainda criar a SA pelo processamento normal. Se essa continuidade viola a política obrigatória do iniciador, ele pode excluir imediatamente a associação recém-criada.
  • Um comprovante por SA deve separar seleção, confirmação, autorização, criação, aceitação, uso e exclusão. Trata-se de proposta editorial de Daniel Kade, não de exigência da RFC ou do IETF.

“SA criada” parece uma conclusão. O par respondeu, houve derivação de material, identificadores apareceram na tabela de estado e a automação ganhou um evento de sucesso. Meses depois, o mesmo registro pode sustentar um relatório que declare concluída a proteção pós-quântica.

A RFC 9867 expõe o salto nessa conclusão. A associação pode nascer quando o respondente não implementa a extensão, não está configurado para ela, não reconhece uma identidade oferecida ou associa outro valor a uma identidade de mesmo nome. Se o uso de PPK for opcional, avançar é permitido. O sucesso da troca e a prova da contribuição criptográfica deixam de ser a mesma coisa.

Uma relação IKE, várias linhagens

O IKEv2 não cria um único túnel imutável. Ele estabelece uma IKE SA, autentica os pares, cria Child SAs e permite renovar tanto as associações filhas quanto a associação de controle. Dizer que “o túnel usa PPK” omite qual SA, em qual troca e em qual cálculo.

A RFC 8784 definiu um primeiro caminho para misturar chave pré-compartilhada ao material de sessão. Ela pressupõe o uso no estabelecimento inicial, mas não usa a PPK para proteger a própria IKE SA inicial contra o adversário quântico considerado. A RFC 9867 não substitui esse mecanismo; acrescenta outros dois.

O primeiro emprega IKE_INTERMEDIATE, troca anterior à autenticação definida pela RFC 9242. O iniciador oferece identidades PPK; o respondente pode escolher uma e devolver confirmação. A combinação ocorre antes de IKE_AUTH, podendo contribuir para a proteção da IKE SA inicial e da autenticação. Quando outras trocas intermediárias também recalculam chaves, a operação PPK deve ser a última antes da troca seguinte. A ordem integra a alegação de segurança.

O segundo caminho usa CREATE_CHILD_SA. Uma PPK nova pode contribuir ao criar ou renovar uma Child SA ou ao renovar a própria IKE SA, sem derrubar toda a relação existente. A rotação fica viável, mas a conexão passa a carregar linhagens distintas. A IKE SA antiga, as Child SAs que continuam, a nova Child SA e a IKE SA renovada não recebem legitimamente uma única etiqueta de proteção.

As múltiplas trocas da RFC 9370 e a terminologia híbrida pós-quântica da RFC 9838 são contexto importante. Uma lista de algoritmos demonstra capacidade; uma mensagem negociada demonstra um evento. Nenhuma, isoladamente, prova que a contribuição chegou às chaves de uma SA específica.

Encontrar, confirmar e autorizar

A RFC 9867 utiliza duas notificações registradas: USE_PPK_INT, valor 16445, e PPK_IDENTITY_KEY, valor 16446. O registro da IANA confirma as atribuições. Esses elementos são observáveis no protocolo, mas não são a PPK secreta e não autorizam armazená-la em logs.

A confirmação corresponde aos oito primeiros octetos da função pseudoaleatória negociada aplicada ao contexto definido. Ela detecta quando os pares selecionam uma identidade aparentemente igual, mas possuem valores PPK diferentes. É prova mais forte que a coincidência de nomes na configuração. Ainda assim, não autoriza por si só o uso da chave para a identidade do par que será autenticado.

Em IKE_INTERMEDIATE, o respondente pode escolher antes de conhecer a identidade autenticada do iniciador. Após a autenticação, a política local talvez diga que aquela PPK não é adequada para o par revelado. A RFC indica que o respondente deveria abortar, embora permita continuar quando a política local aceita. Encontrar material, confirmar igualdade, identificar o par e autorizar a associação são decisões separadas.

A automação tende a condensá-las. O cofre diz “encontrada”; a confirmação diz “mesmo valor”; a autenticação diz “este par”; apenas a política diz “permitido”. Um único indicador verde apaga a ordem e o dono de cada decisão.

Criada antes de ser rejeitada

O caso mais claro aparece em CREATE_CHILD_SA. O iniciador solicita uma PPK nova. Se o respondente não dá suporte, não tem configuração, não acha identidade compatível ou encontra valor diferente, sua resposta omite PPK_IDENTITY_KEY. Mesmo assim, o IKEv2 normal ainda pode gerar a nova SA.

Se a PPK era opcional, a associação pode ser aceita e usada. Se era obrigatória, a mesma associação não satisfaz a regra e o iniciador pode excluí-la logo depois. Ambos os pares podem estar seguindo o padrão, mas um contador de criação classifica o objeto transitório como proteção concluída.

Três momentos precisam ficar separados: criação, avaliação da ausência de evidência e aceitação ou exclusão. O plano de dados também importa. Algum pacote passou durante o intervalo? Um mecanismo de failover instalou a SA? O par remoto continuou acreditando que ela existia depois da remoção local? A norma define a troca; o operador deve produzir a prova de sua alegação operacional.

“Obrigatória” exige escopo. A regra pode valer para um par, uma classe de tráfego, uma renovação ou uma fase. Ela não decorre automaticamente de o software suportar PPK. O fallback opcional, por sua vez, pode ser escolha consciente de interoperabilidade. A falha de governança é relatá-lo como se o estado mais forte estivesse comprovado.

Comprovante da transição, nunca da chave

O comprovante de combinação da PPK proposto aqui é um controle editorial. Não é campo da RFC 9867, extensão de protocolo nem mandato de coleta, e jamais deve conter a PPK.

Para cada SA criada ou renovada, o registro identifica o tipo de troca e a linhagem da IKE SA pai. Ele distingue RFC 8784 das rotas da RFC 9867. Pode guardar uma identidade não secreta ou impressão que minimize dados, os estados oferecida e selecionada, o resultado da confirmação e o momento em que a identidade autenticada ficou disponível. A política obrigatória ou opcional observável, sua versão, o responsável e a exceção acompanham o evento.

Em seguida vem a ordem de derivação. Se várias trocas intermediárias alteraram o material, a PPK foi a última operação exigida? SPI e identificadores vinculam o comprovante à associação, mas não fingem provar o cálculo. Criada, instalada, aceita, primeiro pacote, último pacote e excluída permanecem estados distintos, com motivo do fallback, reversão e data de revisão.

O limite de observabilidade deve estar escrito. Uma captura pode mostrar notificações e tráfego sem enxergar o cronograma privado de chaves. A implementação pode atestar a contribuição sem revelar o segredo. Uma afirmação entre fornecedores depende de confiança delimitada. O comprovante identifica qual componente observou cada fato e marca o que é inferência.

Encerrar a alegação no limite da SA

A motivação pós-quântica não sustenta slogans. A RFC 9867 explica que primitivas simétricas não são atualmente consideradas afetadas da mesma forma que mecanismos de chave pública por um computador quântico criptograficamente relevante. Misturar PPK forte antes da autenticação acrescenta uma via de proteção. Isso não afirma que tal computador exista, não prevê data nem certifica produto como seguro.

“Nova” também precisa significar diferente. Reutilizar a PPK anterior não traz finalidade à rota de renovação fresca. Entropia, custódia, distribuição e reação a comprometimento seguem como deveres operacionais que uma troca bem-sucedida não comprova.

Um relatório confiável contará associações e resultados exatos: RFC 8784, IKE_INTERMEDIATE, renovação com PPK fresca, fallback opcional, falha de confirmação ou criação seguida de exclusão obrigatória. Essa variedade não é sujeira estatística; é o mapa das decisões.

O protocolo permite avançar entre capacidades desiguais porque a rede precisa continuar operando. A governança deve preservar de que modo avançou. A RFC 9867 oferece transição flexível, mas não transforma “criada” em evidência que não foi coletada.

Fontes