Resumen

  • draft-ietf-tcpm-tcp-ao-algs-08, fechado el 1 de octubre, especifica que su derivación KMAC256-KDF se ajusta a la variante KMAC# de NIST SP 800-56C Revision 2, distinta en sus argumentos de la descripción genérica de SP 800-185.
  • La prueba de aceptación debe conservar la revisión, los parámetros públicos, las codificaciones, el contexto, el resultado de los vectores y la observación del par; dos menús con la palabra KMAC256 no bastan.

Una lista de aceptación suele empezar por preguntas binarias: ¿TCP-AO está activado? ¿Ambos extremos usan KMAC256? Dos respuestas afirmativas parecen cerrar la cuestión. La revisión 08 demuestra por qué esa lista puede dar una falsa sensación de precisión.

El nuevo texto distingue la definición general de KMAC256 en NIST SP 800-185 de la variante KMAC# empleada por el método de derivación de una etapa de SP 800-56C Revision 2. El borrador afirma expresamente que KMAC256-KDF sigue esa variante. También explica que el contador fijo, el entero 1 de 32 bits en orden de red, identifica la versión del KDF.

No se trata de un aviso de vulnerabilidad. El documento sigue siendo un Internet-Draft activo del grupo TCPM, con estado previsto Standards Track y fecha de expiración en abril de 2027. El hito del grupo apunta a noviembre de 2026 para enviarlo al IESG. Eso no demuestra envío, aprobación ni despliegue. El registro IANA consultado aún muestra SHA1 y AES128; las entradas nuevas son una solicitud del borrador.

La función de derivación reúne seis decisiones públicas. El salt contiene 132 bytes cero. El contador vale 1 y tiene codificación de red. Z es la Master Key. FixedInfo incorpora el contexto de la conexión. La salida es de 256 bits. La cadena de personalización contiene los bytes ASCII de KDF. Como se piden exactamente 256 bits, basta una invocación.

Después aparece otro uso de KMAC. KMAC256-128 toma la Traffic Key de 256 bits y el mensaje TCP-AO, usa una personalización vacía y produce directamente 128 bits. No es correcto arrastrar la cadena KDF a esta segunda operación. El MAC de 16 bytes hace que toda la opción TCP-AO ocupe 20 de los 40 bytes del espacio de opciones TCP.

La dimensión de FixedInfo suele quedar oculta en una hoja de configuración. RFC 5925 combina direcciones, puertos y números de secuencia iniciales. La derivación es direccional. En un SYN sin ACK, el número inicial del destino aún desconocido se representa con cero; en los demás segmentos se emplea el par conocido. Cambiar el sentido o el orden de un campo cambia la entrada aunque los dos lados compartan la misma Master Key.

Tampoco puede leerse toda la decisión desde el cable. La opción TCP-AO muestra Kind, Length, KeyID, RNextKeyID y MAC, pero no identifica el algoritmo. Esa asociación reside en el Master Key Tuple instalado fuera de banda. Por eso un KeyID coincidente no prueba que los pares asignen a ese número la misma combinación de KDF, MAC, clave y política de cobertura.

La solución operativa propuesta por BTW es un recibo de instancia del algoritmo. No contiene secretos. Contiene la revisión exacta, los identificadores KDF y MAC, las versiones NIST, los valores públicos y sus codificaciones, el identificador controlado de la MKT, el producto y el build. Añade el hash del resultado de un vector conocido, los bytes de la opción, la validación remota, el estado TCP y la evidencia del protocolo transportado.

Esta estructura impide que una prueba reclame más de lo que observó. Reproducir un vector demuestra que un build ejecutó ese caso conocido. Ver un MAC válido demuestra que un segmento fue aceptado bajo el estado del receptor. Alcanzar Established demuestra progreso de transporte. Intercambiar un BGP OPEN, un keepalive o datos de otra aplicación demuestra una capa posterior. Cada afirmación necesita su propia evidencia.

El borrador incluye vectores IPv4 e IPv6 para KMAC, con y sin cobertura de otras opciones TCP. Son una base útil para una comparación entre implementaciones, pero no sustituyen la verificación de las MKT desplegadas. Las claves de producción tampoco deben copiarse a registros. Se puede identificar la configuración y reproducir el cálculo con claves de prueba sin aumentar la superficie de exposición.

Heng Lu ofrece una regla para decidir qué debe ser común. Minimum Initial Specification no pide una especificación imprecisa: exige compartir de manera estricta solo lo que hace posible la interoperabilidad. La variante, la función de cada argumento, la codificación, el contexto y las longitudes pertenecen a ese núcleo. La biblioteca, la API y el sistema de claves pueden seguir siendo decisiones locales.

Running-Code Primacy sitúa la evidencia más fuerte en los vectores y en los bytes que producen y aceptan los equipos. Reality Layers separa el borrador, la futura inscripción, el parámetro configurado, la derivación, el segmento autenticado, la conexión y el servicio. Esta lectura pertenece al análisis editorial de Daniel Kade; no se atribuye a los autores del borrador ni a NIST.

La limitación de la noticia también debe quedar clara. La revisión no prueba que KMAC o TCP-AO estén rotos, que dos productos actuales discrepen o que la revisión 07 fuera errónea. Una revisión temprana del Security Directorate planteó preguntas sobre utilidad, longitudes y espacio de opciones, pero el expediente público no autoriza a declarar que causó esta modificación.

La consecuencia es concreta. La organización que solo guarda el nombre conservará una etiqueta imposible de auditar. La que guarda la instancia podrá separar cinco causas que hoy suelen mezclarse: variante distinta, parámetro distinto, contexto distinto, rechazo del segmento y fallo de la aplicación. Esa diferencia convierte una casilla de formulario en control técnico.

Fuentes