Resumen

  • RFC 2403 y RFC 2404 colocan los primeros 96 bits de un HMAC calculado en ESP o AH, aunque difieren la salida completa y las claves requeridas.
  • Las reglas posteriores para ESP/AH separaron los algoritmos: RFC 8221 clasifica HMAC-MD5-96 como MUST NOT y HMAC-SHA1-96 como MUST-. La longitud común de la etiqueta nunca aseguró una evaluación de seguridad común.

Un campo, dos construcciones

En noviembre de 1998, RFC 2403 y RFC 2404 especificaron transformaciones de autenticación con clave para Encapsulating Security Payload (ESP) y Authentication Header (AH) de IPsec. Una combinó HMAC con MD5; la otra, con SHA-1. Ambas buscaban autenticar el origen y preservar la integridad cuando el secreto solo lo conocían las partes comunicantes. Por sí sola, ninguna ofrecía confidencialidad.

El número visible en el paquete era el mismo: 96 bits. La salida HMAC-MD5 completa de RFC 2403 tiene 128 bits; la de HMAC-SHA-1 de RFC 2404, 160. En ambas transformaciones, el emisor guarda los primeros 96 bits en el campo de autenticación. El receptor calcula el HMAC completo y compara esos mismos 96 bits. Esa elección coincidía con la longitud predeterminada del autenticador AH y daba a construcciones distintas una huella común en el cable. No convertía los resúmenes completos en hashes de 96 bits.

También diferían las reglas de clave: RFC 2403 exige una clave HMAC de 128 bits; RFC 2404 exige una de 160. Así, una misma longitud de campo convivía con distintas longitudes de salida y de clave fija. La identidad de la transformación negociada y la gestión de claves seguían importando; contar solo los bits visibles no describía todo el mecanismo.

La resistencia a colisiones no responde toda la pregunta sobre HMAC

Los textos de 1998 no equiparaban una colisión en el hash sin clave con la ruptura inmediata de HMAC. RFC 2403 señaló que HMAC dependía en menor medida de la resistencia fuerte a colisiones de MD5 que las firmas basadas en MD5 y que, en ese momento, no se conocían ataques prácticos contra HMAC-MD5-96. RFC 2404 formuló una evaluación paralela, propia de su época, para HMAC-SHA-1-96. No eran garantías para el futuro.

La evolución de las reglas de implementación muestra cómo cambió la evaluación sin convertir la longitud de la etiqueta en criterio decisivo. En 2005, RFC 4305 fijó HMAC-SHA1-96 como MUST y HMAC-MD5-96 como MAY. En 2007, RFC 4835 mantuvo esa diferencia y anotó que las debilidades de colisión conocidas entonces no debían afectar al uso de esos hashes con HMAC. En 2014, RFC 7321 mencionó resultados teóricos contra HMAC-MD5, pero no veía una vulnerabilidad práctica y no consideraba urgente retirarlo de protocolos existentes; seguía considerando seguro HMAC-SHA-1 pese a la debilidad de colisión de SHA-1.

RFC 8221, publicada en 2017, trazó una línea más marcada para los requisitos de implementación ESP/AH: HMAC-MD5-96 pasó a MUST NOT; HMAC-SHA1-96 bajó de MUST a MUST-. La prohibición citó la vulnerabilidad conocida de MD5 ante colisiones, mientras que la degradación de SHA-1 se atribuyó a una tendencia general de la industria a dejar de usarlo. No afirmaba que el campo de 96 bits hubiese cambiado ni que RFC 2404 definiera ahora otra etiqueta.

Una tabla de estatus no es una traza de tráfico

Más tarde, RFC 9395 actualizó RFC 8221 y modificó un registro de transformaciones IKEv2, donde figura una entrada AUTH_HMAC_MD5_96 marcada DEPRECATED. Ese registro no es la tabla de requisitos de implementación ESP/AH de RFC 8221. Un nombre aparentemente idéntico puede aparecer en contextos IPsec cercanos: cada estatus debe leerse junto con su protocolo y el alcance del documento.

Estos documentos registran parámetros de protocolo y recomendaciones fechadas. No cuentan equipos desplegados, no identifican la última asociación de seguridad negociada con HMAC-MD5 ni fijan una fecha universal de retirada. Un operador tendría que distinguir el protocolo seleccionado, el identificador de transformación, las capacidades de los pares, la asociación instalada y el tráfico observado. La etiqueta de 96 bits es solo una parte de esa evidencia.

Fuentes