Resumo

  • Publicado em 1º de outubro de 2026, draft-ietf-tcpm-tcp-ao-algs-08 diz expressamente que seu KMAC256-KDF segue a variante KMAC# de NIST SP 800-56C Rev. 2. A variante usa argumentos diferentes dos do KMAC256 original de SP 800-185. O contador de 32 bits em ordem de rede, com valor um, passa a ser explicado como indicador da versão da KDF.
  • A fórmula e os vetores de teste já constavam da revisão 07. A novidade é a referência que fixa a interpretação de uma proposta em andamento, não uma alteração comprovada em chaves de produção ou a publicação de um RFC.

Em uma sessão protegida por TCP-AO, as duas pontas precisam chegar à mesma chave de tráfego. Um catálogo que diga apenas «KMAC256» não resolve essa exigência se cada lado usar uma convenção distinta para os argumentos da derivação. A sessão falha em bytes, mesmo que pareça alinhada na interface administrativa. É esse espaço entre declaração de capacidade e cálculo efetivo que o texto novo tenta fechar.

Na seção 3.1.2, o grupo TCPM relaciona o KMAC256-KDF à função de derivação de uma etapa da seção 4.1 de NIST SP 800-56C Rev. 2, opção 3. A revisão acrescenta que a função corresponde à variante KMAC# e distingue seus argumentos daqueles originalmente definidos em SP 800-185. Também explica o papel do contador de 32 bits: ele vale um, é codificado em ordem de rede e marca a versão da KDF. Comparar as revisões 07 e 08 não autoriza dizer que todos os parâmetros ou vetores foram substituídos. A redação ficou mais explícita sobre uma receita que já estava ali.

Essa receita reúne um salt de 132 bytes zerados, o contador, a chave mestra Z, o contexto da conexão em FixedInfo, saída de 256 bits e a string ASCII KDF. Uma chamada produz a chave de tráfego de 256 bits. A proposta de MAC KMAC256-128 usa essa chave para um autenticador de 128 bits; a alternativa HMAC-SHA256-128 usa HKDF-SHA256. A lista das duas alternativas, os vetores e o custo de 20 dos 40 bytes disponíveis para opções TCP quando se codifica o MAC de 16 bytes não surgiram nesta versão. São limites de implementação que contextualizam a notícia, não novos mandatos já vigentes.

Uma avaliação de interoperabilidade precisa comparar mais que as caixas de seleção dos produtos. Primeiro, derivar a chave de tráfego em implementações independentes. Depois, conferir o MAC resultante com os vetores do projeto, tanto incluindo quanto omitindo as opções TCP da cobertura. Se houver diferença, a investigação começa na variante, na ordem e codificação dos argumentos, no contexto e no tamanho solicitado. Esse roteiro de aceitação é inferência editorial; a IETF não estabeleceu aqui um programa de certificação de fornecedores.

O projeto exige chave mestra de pelo menos 256 bits e ressalta que engenharia de protocolo insegura pode contornar a força de uma primitiva. Não há dados de adoção nem relato de falha entre equipamentos no material examinado. Tampouco a revisão altera, por si, uma sessão BGP ativa. TCP-AO protege a conexão TCP que transporta mensagens de roteamento; não autoriza cada anúncio BGP e não substitui a prova de que uma troca de época de chaves foi concluída nas duas direções.

O Datatracker apresenta o texto como Internet-Draft ativo do TCPM em I-D Exists. O cabeçalho aponta para Standards Track, enquanto o campo de status pretendido na ficha está em (None); nenhuma dessas indicações equivale a aprovação. Por ora, a contribuição verificável da revisão é fazer o nome KMAC apontar para uma variante concreta. Cabe a quem opera a rede provar que as pontas produzem os mesmos bytes antes de permitir uma mudança de política de conexão.

Fontes