Resumen

  • Ni y Nr hicieron fresca la derivación de Quick Mode y entraron en sus pruebas de vivacidad. HASH(1), HASH(2) y HASH(3) autenticaron una secuencia de tres mensajes bajo el estado de la fase 1.
  • La frescura de una clave no era un recibo de instalación. El tercer mensaje llegaba al respondedor y no recibía un cuarto acuse; además, ninguna función hash incluía el éxito de una SAD, un selector activo, un contador IPsec o un resultado de aplicación.

Los dos nonces de Quick Mode tenían una tarea concreta: impedir que una repetición de mensajes viejos fabricara asociaciones de seguridad nuevas y aportar material fresco a las claves. Eran números vivos dentro de una negociación, no sensores del sistema operativo.

RFC 2409 definió IKE al combinar el marco ISAKMP con técnicas de Oakley y SKEME. La separación era deliberada. RFC 2408 había descrito cómo transportar cargas útiles, mantener estado y administrar SA sin elegir un único intercambio criptográfico. RFC 2407 había dado significado IPsec a propuestas y transformaciones. IKE convirtió esas piezas en conversaciones ejecutables.

La fase 1 establecía una asociación ISAKMP autenticada y bidireccional. Main Mode debía implementarse; Aggressive Mode era recomendado. Quick Mode solo pertenecía a la fase 2 y aprovechaba la relación ya autenticada para negociar SA de otros protocolos.

Esa reutilización ahorraba coste. Un intercambio Diffie-Hellman y una autenticación de pares podían sostener varias negociaciones posteriores. Pero el ahorro también exigía conservar qué prueba pertenecía al padre y cuál al hijo.

La pareja de cookies identificaba la asociación ISAKMP. El Message ID identificaba una instancia de Quick Mode. El primer vector de inicialización de esa instancia se derivaba del último bloque CBC de la fase 1 y del Message ID. Así podían avanzar varias negociaciones de fase 2 sin compartir una cadena IV.

Encontrar la instancia correcta no autenticaba el mensaje. Por eso el Message ID entraba en los hashes. La correlación quedaba unida criptográficamente al transcript, pero seguía siendo correlación. No decidía quién estaba autorizado a abrir un flujo ni si el resultado había llegado al plano de datos.

El iniciador enviaba primero HASH(1), una carga SA y Ni. Podía añadir una carga KE y las identidades clientes. Todo lo posterior a la cabecera ISAKMP viajaba cifrado bajo la SA de fase 1.

HASH(1) cubría el Message ID y el mensaje completo después del hash, con sus cabeceras de payload y sin el relleno criptográfico. El respondedor podía atribuir la oferta exacta a alguien que conocía el estado autenticado de fase 1.

Ese resultado no obligaba a aceptar la oferta. La política del respondedor seguía escogiendo. Tampoco mostraba que existiera ya una SA de AH o ESP. Una propuesta autenticada seguía siendo una propuesta.

El segundo mensaje devolvía HASH(2), la selección SA y Nr. El cálculo añadía Ni antes del resto de la respuesta. Esa presencia era una prueba de vivacidad: la respuesta no era una grabación aislada de la pregunta actual.

Al verificarla, el iniciador sabía que el otro poseedor del estado de fase 1 había recibido su desafío, había elegido parámetros y había creado un nonce propio. Los dos lados ya tenían Ni y Nr para derivar material de clave.

El tercer mensaje llevaba HASH(3). Su entrada era un octeto cero seguido del Message ID y de los dos nonces. El respondedor podía verificar que el iniciador había recibido Nr y seguía controlando el contexto autenticado necesario para producir el valor.

La prueba final beneficiaba al respondedor porque era quien la recibía. El iniciador no obtenía en el Quick Mode básico un cuarto mensaje que acreditara la recepción o validación de HASH(3). El transcript se cerraba con información desigual sobre el último salto.

La asimetría no implica que RFC 2409 prometiera un acuse que olvidó entregar. Es una lectura de los tres mensajes definidos. La especificación resolvía una negociación criptográfica; no intentaba convertirse en un registro distribuido de todas las acciones locales posteriores.

RFC 2408 ofrecía el bit Commit y CONNECTED para otra sincronización, con su propio riesgo de pérdida final. Esa ruta complementaria demuestra que la preparación operacional necesitaba señales adicionales. No convierte HASH(3) en una confirmación de kernel.

La derivación de KEYMAT marcaba un segundo límite. Sin KE en Quick Mode, la función tomaba SKEYID_d, el protocolo, el SPI y los dos nonces. El resultado era fresco respecto de Ni y Nr, pero no tenía PFS independiente de la exponenciación de fase 1.

Con KE, los pares hacían otro Diffie-Hellman y añadían el secreto efímero a la derivación. Entonces las claves nuevas sí podían obtener PFS. El uso era opcional, aunque el soporte debía existir.

PFS describe lo que una futura compromisión puede revelar sobre claves pasadas. No describe si el kernel aceptó una entrada, si los selectores capturan el flujo correcto o si la ruta lleva paquetes a la interfaz prevista. La propiedad criptográfica y la propiedad operacional viven en capas distintas.

Los nonces tampoco prueban la instalación. Ni demuestra que el iniciador aportó un desafío fresco; Nr, que el respondedor hizo lo mismo. Ambos entran en el material candidato. Ninguno contiene el retorno de una llamada al kernel.

Las identidades clientes opcionales aportaban política. IDci y IDcr podían indicar los extremos de tráfico por los que negociaban los pares IKE. Si estaban presentes, debían ser coherentes para todas las SA del conjunto.

El sujeto autenticado en fase 1 podía ser una pasarela; el sujeto autorizado en fase 2 podía ser una pareja de subredes, hosts o protocolos. Que una pasarela demostrara su identidad no le daba derecho universal sobre todos los selectores. La política local mantenía la decisión.

El respondedor podía elegir una transformación aceptable y autenticarla en HASH(2). El iniciador podía aceptarla al enviar HASH(3). Aun así, una instalación podía fallar por memoria, límites de hardware, conflictos de selectores, conversión de duración, programación de interfaces o reglas locales más tardías.

Ninguno de esos resultados se incorporaba retrospectivamente a los hashes. La matemática protegía el transcript que recibió. No podía incluir hechos que aún no habían ocurrido o que pertenecían a un componente diferente.

Las reglas de IV mostraban la misma prudencia temporal. El primer IV de Quick Mode se derivaba de fase 1 y del Message ID. Los siguientes usaban el último bloque cifrado del mensaje anterior dentro de esa instancia.

Una implementación no debía avanzar el IV solo porque llegaran bytes. Primero tenía que descifrar, comprobar la cordura básica y decidir que el mensaje hacía avanzar la máquina de estados. Una retransmisión válida no debía alterar otra vez el estado.

Esa regla separaba recepción, descifrado, validación y progreso. La instalación añadía otro paso. El primer paquete protegido añadía otro. El primer resultado útil añadía uno más. Llamarlos a todos «túnel arriba» impedía localizar fallos.

El transporte UDP hacía visible el problema del último mensaje. HASH(3) podía perderse. El iniciador podía repetirlo al no observar tráfico u otra respuesta indirecta. El respondedor tenía que reconocer que el mensaje repetido ya no era una nueva autorización ni una segunda instalación.

Un recibo operativo necesita dos perspectivas. Desde el iniciador: HASH(2) verificado, HASH(3) emitido, SA saliente e interna instaladas, paquetes enviados y recibidos. Desde el respondedor: HASH(3) verificado, SA complementarias instaladas y contadores compatibles. Una sola fila no contiene ambos lados.

La lente de capas de realidad de Lu Heng ordena las pruebas. Message ID es correlación. Los hashes son autenticación del transcript. Los nonces son frescura y derivación. La selección es decisión negociada. La política es autoridad local. La SAD/SPD es estado ejecutable. Los contadores son tratamiento de paquetes. El servicio es resultado.

El problema de agencia surge cuando el daemon habla por el kernel o por la aplicación. La autoridad de credenciales responde por la identidad. El equipo de seguridad responde por el permiso. IKE responde por el intercambio. El kernel o el acelerador responden por la instalación. Operaciones y el dueño del servicio responden por el efecto.

La especificación mínima común no debía imponer una única arquitectura de kernel o política. Su trabajo era hacer interoperables los mensajes y cálculos. La libertad local era útil, pero dejaba al operador la obligación de producir recibos locales comparables.

La primacía del código en ejecución exige guardar la cadena: cookies, identidad y credential de fase 1, Message ID, Ni, Nr, KE, propuestas, SPIs, resultados de cada hash, revisión de política, solicitud y confirmación de instalación, SA ejecutables, selectores, contadores, veredictos de paquete y prueba de aplicación.

Con la cadena completa, una discrepancia deja de ser misteriosa. Si falta HASH(3) en el respondedor, el cierre criptográfico no llegó. Si los daemons están de acuerdo pero falta una entrada local, falló la instalación. Si hay contadores en ambos lados pero el servicio no funciona, el problema queda después de IPsec.

RFC 2409 apareció en noviembre de 1998. RFC 4109 actualizó más tarde los requisitos de algoritmos de IKEv1. RFC 4306 reemplazó la familia 2407/2408/2409 con IKEv2; RFC 7296 acabó como Internet Standard de IKEv2. En 2023 IKEv1 pasó a Historic y RFC 9395 lo deprecó y cerró registros relacionados.

Dos nonces podían refrescar claves. Tres hashes podían autenticar un transcript. Ninguna de esas piezas, sola, podía certificar que dos sistemas habían instalado y usado el resultado.

Fuentes