Resumen

  • El intercambio agresivo de tres mensajes del RFC 2412 podía validar las firmas y marcar el KEYID como autenticado antes de calcular el secreto compartido de Diffie-Hellman.
  • Una prueba de comunicación no demostraba por sí sola el cálculo, la vinculación correcta, la instalación bilateral de asociaciones de seguridad, el paso de paquetes ni el resultado del servicio.

En seguridad, una palabra de estado suele terminar convertida en una promesa. El RFC 2412 dejó por escrito por qué esa conversión puede ser falsa.

OAKLEY buscaba que dos partes autenticadas acordasen material secreto mediante Diffie-Hellman. Incorporaba confidencialidad directa perfecta, selección de algoritmos, grupos definidos por los participantes y compatibilidad con ISAKMP. Pero no trataba todas las etapas del acuerdo como un solo instante.

Su ejemplo agresivo enviaba identidades, nonces, grupo, opciones criptográficas y valores públicos en tres mensajes. Cada lado firmaba los elementos relevantes del intercambio. Esas firmas podían constituir una prueba de comunicación conservable y presentable ante un tercero.

La frase siguiente es la decisiva: el material de clave implícito en los exponentes de grupo no era necesario para completar el intercambio.

La implementación podía guardar su exponente privado y el valor público del otro extremo, marcar el material como uncomputed y obtenerlo más tarde. El procedimiento detallado autorizaba al iniciador a posponer (g^y)^x hasta después de enviar su última respuesta. Aun así, tras validar la firma del respondedor, marcaba el KEYID como autenticado. El respondedor hacía lo propio al verificar el último mensaje y después debía calcular g^xy y asociarlo con ese identificador.

Había ocurrido un acto criptográfico importante. No había ocurrido necesariamente el siguiente.

La diferencia aparece también en los nombres. Los dos cookies formaban el KEYID, una etiqueta reutilizable para el material de clave y, al mismo tiempo, una defensa débil contra la congestión. sKEYID era el material secreto nombrado por esa etiqueta, no transmitido por la red y derivado, en el ejemplo, a partir de g^xy, los nonces y los cookies. La etiqueta podía existir antes que su contenido. La autenticación de la etiqueta tampoco materializaba automáticamente los bits secretos.

Un sistema de explotación puede borrar esa frontera con facilidad. El registro escribe “authenticated”. El panel pinta verde. La capa superior interpreta “listo”. El operador supone una asociación instalada en ambos sentidos. El usuario supone que el tráfico está protegido. Cada conclusión puede parecer razonable y, sin embargo, ninguna está contenida en la firma anterior.

Aplazar el cálculo no era necesariamente un defecto. La exponenciación modular era costosa. Sacarla del camino crítico podía mejorar la latencia observada sin alterar los campos que recibía el otro extremo. El protocolo compartido seguía siendo el mismo aunque cada máquina eligiese el momento local de la operación.

La contrapartida era una obligación de custodia. Había que conservar el exponente correcto, el valor público del par, el grupo, los cookies, los nonces, las identidades y los algoritmos seleccionados. Luego era necesario validar, calcular, derivar y asociar sin mezclar sesiones. Un reinicio, una caducidad o una referencia reciclada podía conservar un transcript firmado mientras destruía la posibilidad de terminar la clave.

Por eso hacen falta recibos distintos. El recibo del transcript prueba una firma sobre unos campos concretos. El recibo de validación prueba que el elemento público cumple los controles aplicables. El recibo de cómputo prueba que el secreto y sus derivados se calcularon. El recibo de vinculación los une con el KEYID, las identidades y los algoritmos previstos. El recibo de instalación sitúa el estado correcto en la asociación de seguridad. El recibo de paquete muestra tráfico protegido. El resultado del servicio pertenece a otra capa.

Cada escalón puede ser verdadero mientras el siguiente continúa desconocido.

El RFC 2412 ya recomendaba rechazar ciertos valores degenerados y exigía buenas fuentes de aleatoriedad. Su errata corrige la terminología de los primos seguros y de Sophie Germain, sin alterar el permiso para diferir el cálculo. Años después, el RFC 6989 reforzó en IKEv2 la validación de valores públicos de Diffie-Hellman y dispuso que una carga KE inválida no debía usarse para crear una SA.

No cabe leer esa regla de 2013 como prueba de lo que hicieron productos anteriores. Sí permite ver con mayor nitidez el orden lógico: recibir no es validar; validar no es calcular; calcular no es instalar.

El RFC 2409 llevó ideas de ISAKMP y OAKLEY a IKEv1. En su Modo Agresivo, el último mensaje podía enviarse sin la protección de la SA, lo que permitía postergar la exponenciación hasta acabar el intercambio. Pero las claves derivadas dependían del valor compartido real. La flexibilidad de calendario no eliminaba el trabajo criptográfico.

IKEv2 reordenó después el diseño. Los RFC 4306, 5996 y 7296 representan generaciones sucesivas. El RFC 7296 calcula SKEYSEED con los nonces y el secreto efímero de Diffie-Hellman y deriva después claves con funciones diferentes. También admite que la SA IKE quede autenticada mientras la SA hija o la solicitud de configuración fracasa.

No es el mismo autómata que OAKLEY. Es otra muestra de una regla duradera: completar el plano de control no prueba que el plano de datos dependiente ya esté operativo.

La sucesión documental tampoco equivale a la sucesión del parque instalado. El RFC 2412 era Informational. IKEv1 pasó por la vía de estándares, IKEv2 lo sustituyó y el RFC 9395 terminó deprecando IKEv1 y varios algoritmos antiguos. Ningún verbo editorial desinstala software. La recomendación actual y el estado de una máquina concreta son hechos distintos.

La Primacía del Código en Ejecución de Lu Heng sirve aquí como método de lectura. El documento puede definir el sentido de una transición. Solo la implementación puede demostrar que la ejecutó. Las capas de realidad deben conservarse: mensaje recibido, firma verificada, elemento público validado, secreto calculado, claves vinculadas, SA instalada, paquete aceptado y aplicación satisfecha.

La Especificación Inicial Mínima añade el criterio de diseño. Dos implementaciones necesitaban acordar el transcript, las reglas de derivación y el significado de los parámetros. No tenían por qué sincronizar el ciclo exacto de CPU en que cada una ejecutaba la exponenciación, siempre que la libertad local no cambiara la seguridad ni la interoperabilidad compartidas.

Quien ejerce esa libertad debe mostrar su coste. Si una implementación difiere el cálculo, controla el intervalo oculto y debe conservar sus entradas, hacer visible el estado y retirar cualquier promesa superior cuando el cálculo falla. La aplicación que soporta la consecuencia no puede depender de una luz verde ambigua.

El mérito histórico de uncomputed reside en su precisión. No rebaja la prueba firmada; impide que esa prueba reclame un hecho que todavía no ocurrió.

La conversación estaba autenticada. Faltaba calcular el secreto. Faltaba vincular e instalar la asociación. Faltaba observar el paquete. Faltaba comprobar el servicio.

Una arquitectura segura sabe detenerse en el verbo correcto.

Fuentes