Resumo

  • A RFC 5926 exigia que toda implementação plenamente conforme oferecesse HMAC-SHA-1-96, AES-128-CMAC-96 e seus KDFs correspondentes.
  • As duas construções geravam tags de 96 bits, criando uma base comum e uma alternativa de migração.

Agilidade sem acordo é falha

O TCP-AO não autentica com a promessa abstrata de usar “criptografia forte”. O emissor deriva uma Traffic_Key específica da conexão e calcula um MAC com um algoritmo determinado. O receptor precisa repetir a mesma derivação e o mesmo cálculo. Se o par for diferente, a tag recebida não é outra interpretação válida da prova: ela simplesmente não pode ser verificada.

Por isso, a RFC 5926 combinou escolha com um piso obrigatório. Uma implementação conforme precisava incluir HMAC-SHA-1-96, AES-128-CMAC-96, KDF_HMAC_SHA1 e KDF_AES_128_CMAC. Isso não significava usar as duas suites ao mesmo tempo, nem introduzia negociação dentro da troca TCP. Significava que sistemas independentes compartilhavam opções definidas que podiam ser configuradas de modo compatível.

O nome do MAC não completava o contrato. A KDF recebe a Master_Key configurada, o Context específico da conexão e o tamanho solicitado, produzindo a Traffic_Key usada nos segmentos TCP. Cada MAC definido pela RFC identifica sua KDF; uma KDF pode atender a mais de um MAC, mas a derivação da chave de tráfego não podia ficar indefinida.

Duas primitivas, pouco espaço na opção

HMAC-SHA-1-96 usa uma chave de tráfego de 160 bits e parte da saída do HMAC-SHA1. AES-128-CMAC-96 usa uma chave de 128 bits e AES-CMAC. Nos dois casos, o valor levado pela opção TCP-AO é truncado para 96 bits. Esse tamanho equilibra autenticação e o espaço limitado da opção TCP; não transforma as primitivas subjacentes em primitivas de 96 bits.

Em 2010, HMAC-SHA1 era recomendado como padrão de interface por ser amplamente implementado. AES-128-CMAC também era obrigatório como alternativa distinta e caminho de migração. Essa justificativa pertence ao contexto histórico de publicação, não constitui recomendação atual.

A KDF do AES-CMAC aceita chaves mestras de tamanho variável: quando a entrada não tem exatamente 16 octetos, deriva uma chave de 128 bits. Essa conveniência não torna segura uma chave fraca ou previsível.

O que a base resolveu — e o que não resolveu

Os quatro componentes obrigatórios davam aos softwares conformes um ponto de encontro. Eles não corrigiam configurações incompatíveis. Os pares ainda precisavam compartilhar as mesmas escolhas e o mesmo material secreto, enquanto o modelo de chaves manuais deixava essa coordenação fora da troca TCP.

A RFC também criou uma interface para MACs e KDFs futuros, incluindo uma meta sobre quantidade de mensagens e probabilidade de colisão. Isso é um limite de extensibilidade, não uma negociação automática na rede.

Fontes