Resumen

  • RFC 5926 exigía que toda implementación plenamente conforme incluyera HMAC-SHA-1-96, AES-128-CMAC-96 y sus KDF correspondientes.
  • Ambos métodos entregaban etiquetas de 96 bits, combinando una base común con una alternativa de migración.

La agilidad sin acuerdo fracasa

TCP-AO no autentica con una promesa genérica de «criptografía fuerte». El emisor deriva una clave de tráfico específica de la conexión y calcula un MAC mediante un algoritmo concreto. El receptor debe repetir la misma derivación y el mismo cálculo. Si el par es distinto, la etiqueta no es otra forma válida de interpretar la prueba: no puede verificarse.

Por eso RFC 5926 unió la libertad de elección a un mínimo obligatorio. Una implementación conforme debía incluir HMAC-SHA-1-96, AES-128-CMAC-96, KDF_HMAC_SHA1 y KDF_AES_128_CMAC. No significaba usar las dos suites a la vez ni negociar algoritmos dentro de TCP. Significaba que sistemas independientes compartían elecciones definidas que podían configurarse de forma compatible.

El nombre del MAC tampoco completaba el contrato. La KDF recibe la Master_Key configurada, el Context de la conexión y la longitud solicitada, y produce la Traffic_Key usada en los segmentos TCP. Cada MAC de RFC 5926 identifica su KDF; una KDF puede servir a más de un MAC, pero la derivación de la clave no podía quedar sin especificar.

Dos primitivas y poco espacio en la opción

HMAC-SHA-1-96 utiliza una clave de tráfico de 160 bits y parte de la salida de HMAC-SHA1. AES-128-CMAC-96 utiliza una clave de 128 bits y AES-CMAC. En ambos casos, el valor transportado por la opción TCP-AO se trunca a 96 bits. La longitud equilibraba autenticación y espacio limitado de la opción; no convertía las primitivas subyacentes en primitivas de 96 bits.

En 2010 se recomendaba HMAC-SHA1 como valor predeterminado de interfaz porque tenía amplia implementación. AES-128-CMAC también era obligatorio como alternativa distinta y camino de migración. Esa explicación pertenece al contexto histórico de publicación, no a una recomendación actual.

La KDF de AES-CMAC admitía claves maestras de longitud variable: si la entrada no tenía exactamente 16 octetos, derivaba una clave de 128 bits. Esa comodidad no transformaba una clave débil o predecible en una clave segura.

Lo que resolvía la base — y lo que no

Los cuatro componentes obligatorios daban a los programas conformes un terreno común. No corregían una configuración incompatible. Los pares todavía necesitaban los mismos algoritmos y el mismo material secreto, mientras que el modelo de claves manuales dejaba esa coordinación fuera del intercambio TCP.

El RFC ofrecía una interfaz para futuros MAC y KDF, incluido un objetivo sobre cantidad de mensajes y probabilidad de colisión. Era un límite de extensibilidad, no una negociación automática en la red.

Fuentes