Resumen

  • La versión 08 de draft-ietf-tcpm-tcp-ao-algs, fechada el 1 de octubre de 2026, especifica que KMAC256-KDF sigue la variante KMAC# de NIST SP 800-56C Rev. 2, con un conjunto de argumentos distinto del KMAC256 definido originalmente en SP 800-185. También explica que el contador de 32 bits, con valor uno y orden de red, señala la versión de la KDF.
  • La ecuación, los dos MAC propuestos y los vectores de prueba no nacieron en esta versión. Es una aclaración de interpretación de un Internet-Draft activo, no evidencia de un cambio de claves ya desplegado.

Un fabricante puede marcar «compatible con KMAC256» y otro responder con la misma etiqueta. Si uno interpreta una llamada a KMAC conforme a SP 800-185 y el otro aplica la variante KMAC# de SP 800-56C, la coincidencia de nombres no garantiza que ambos deriven los mismos bytes. TCP-AO compara autenticadores calculados, no promesas de una consola. Esa diferencia entre capacidad anunciada y clave efectiva es el problema que delimita la revisión reciente.

El grupo TCPM añadió en la sección 3.1.2 una identificación explícita de la variante que usa su KMAC256-KDF. La nota remite a la opción 3 de la sección 4.1 de NIST SP 800-56C Rev. 2 y contrasta sus argumentos con los del KMAC256 original de SP 800-185. Además, atribuye una función de versión al contador de 32 bits que vale uno y se codifica en orden de red. Una comparación de la versión 07 con la 08 no muestra un reemplazo de la fórmula ni de los vectores de prueba: la novedad es la referencia que evita leer la fórmula como una invocación genérica e intercambiable.

Los detalles importan. La receta del borrador coloca un salt de 132 bytes a cero, concatena el contador con la clave maestra Z y el contexto de la conexión FixedInfo, solicita 256 bits y usa la cadena de personalización ASCII KDF. El resultado es una clave de tráfico de 256 bits para el MAC KMAC256-128 de 128 bits. La alternativa HMAC-SHA256-128 utiliza HKDF-SHA256. El tamaño del autenticador —16 bytes y, al codificarse en TCP-AO, 20 de los 40 bytes disponibles para opciones TCP— es una condición técnica ya existente, no una decisión nueva de octubre.

Para un laboratorio de interoperabilidad, la pregunta útil es si dos implementaciones independientes obtienen la misma clave intermedia y el mismo MAC final con los vectores publicados, tanto cuando se cubren las opciones TCP como cuando se omiten. Esa es una propuesta editorial de aceptación, no un requisito de certificación añadido por la IETF. Si el resultado falla, conviene inspeccionar la variante, el orden de los argumentos, la representación del contador y el contexto antes de concluir que la conectividad o la clave maestra son incorrectas. La etiqueta del algoritmo por sí sola no resuelve ese diagnóstico.

Tampoco hay que extender la inferencia a la seguridad completa del enrutamiento. El proyecto exige claves maestras de al menos 256 bits y recuerda que una primitiva robusta no subsana vías de evasión creadas por la ingeniería del protocolo. No aporta cifras de adopción, no documenta una avería entre proveedores y no demuestra que las sesiones BGP existentes hayan cambiado de algoritmo. TCP-AO autentica el transporte TCP; no decide si una ruta anunciada está autorizada.

El Datatracker mantiene el documento como borrador activo de TCPM en estado I-D Exists. La cabecera menciona Standards Track, pero la ficha de estado previsto muestra (None) y no hay RFC aprobado. La decisión operativa madura será exigir resultados de derivación y pruebas compartidas antes de aprobar un cambio de política. El nombre KMAC es una pista; los bytes son la prueba.

Fuentes