Resumen

  • RFC 5387 permite que la autenticación sea unidireccional o se reparta entre capas, pero exige que la vinculación del canal se intercambie y compruebe en los dos extremos.
  • Un proxy puede concatenar dos asociaciones IPsec válidas. Cada tramo conserva cifrado e integridad, aunque la supuesta relación directa entre las aplicaciones sea falsa.

Dos verdades locales y una conclusión equivocada

El cliente registra una negociación IPsec exitosa. El servidor registra otra. Ambos usan algoritmos aceptables y rechazan paquetes que no pertenecen a su asociación de seguridad. Una auditoría que solo reúna esas dos capturas concluirá que la sesión estuvo protegida de extremo a extremo.

Esa conclusión no está contenida en las capturas. Un equipo situado en el camino puede terminar la primera SA y abrir una segunda. Recibe el contenido entre ambas, reenvía la conversación de la capa superior y permite que cada extremo vea un control criptográfico correcto. No ha roto el cifrado: ha elegido dónde termina.

RFC 5387 describe precisamente esa diferencia. Los extremos de una asociación de red no coinciden necesariamente con los extremos de la sesión de aplicación. Para construir un canal IPsec, cada SA debe quedar vinculada a la sesión superior y a sus participantes. Sin esa vinculación, dos controles válidos se convierten en una afirmación que ninguno de ellos demuestra.

La misma falla aparece en empresas que componen servicios. Un mensaje tiene TLS antes y después de un corredor, pero nadie prueba que mantuvo el mismo principal. Un artefacto fue firmado y luego desplegado, pero el recibo no une la firma al binario instalado. El problema no está en cada evidencia; está en la unión ausente.

Autenticar en una dirección puede ser correcto

La simetría no es un requisito universal de identidad. Un servidor público suele autenticarse ante clientes anónimos. Un sistema empresarial puede autenticar al usuario en la aplicación y al servicio en la red. Las identidades disponibles para IKE tampoco son siempre las que gobiernan el acceso de negocio.

RFC 5387 enumera modos simétricos y asimétricos de BTNS. En A-CBB, una parte puede carecer de una identidad IKE convencional mientras la otra sí se autentica. La autenticación de la capa superior también puede ser unilateral. Incluso es posible conseguir autenticación mutua sumando dos direcciones en capas distintas: cliente autenticado arriba y servidor autenticado en IKE.

Lo decisivo es no trasladar esa asimetría de política a la prueba del canal. La norma conceptual de RFC 5387 es bilateral: ambos extremos deben intercambiar y verificar los valores de vinculación. Una sola parte no puede certificar qué canal observó la otra.

La dirección de la autoridad responde a «¿quién debe probar su identidad?». La topología de la evidencia responde a «¿compartimos realmente el mismo objeto protegido?». Son preguntas diferentes y merecen controles diferentes.

La vinculación nombra la instancia

Decir «usa IPsec» identifica una familia tecnológica. No identifica el canal. Direcciones IP, certificados y nombres de protocolo pueden repetirse en muchas sesiones. Un atacante puede mantener todos esos rótulos y aun así interponer dos asociaciones.

La vinculación del canal incorpora en la autenticación superior información derivada de la creación de la pareja de SA que identifica esa instancia. RFC 5056 formaliza el principio general: los pares de aplicación deben comprobar que observan los mismos datos de canal. Si existe un proxy, la asociación inferior del cliente y la del servidor son distintas; la autenticación ligada revela la discrepancia.

RFC 5929 y RFC 9266 muestran por qué la construcción exacta del valor importa. La unicidad puede referirse a extremos, a una instancia o a un periodo. No basta con añadir al registro la palabra «binding». Hay que documentar qué valor se creó, qué propiedad distingue y cómo se comparó.

El recibo útil contiene la sesión superior, sus extremos, el identificador del canal inferior, el resultado en ambos lados y la respuesta ante ausencia o desigualdad. «Función disponible» es inventario. «Función ejecutada para esta sesión» es evidencia.

Mantener propiedades durante la vida del flujo

RFC 5387 define el canal IPsec como un flujo cuya identidad de par y calidad de protección permanecen constantes. El connection latch asocia esas propiedades a la conexión. RFC 5660 desarrolló después el mecanismo como vigilancia de cambios en SPD y SAD que serían adversos para la aplicación.

El latch incluye tipo de protección, modo, calidad criptográfica, identidad local e identidad del par. Cuando una renovación de claves reemplaza una SA, la continuidad no se presume por compartir direcciones o puertos. La transición debe conservar las propiedades aceptadas o romper el canal y avisar a la capa superior.

Este punto evita una trampa operativa frecuente: tratar toda sustitución exitosa como heredera del permiso anterior. Un certificado nuevo, un agente nuevo o un operador nuevo puede ejecutar el mismo rol y, sin embargo, necesitar una nueva decisión. La continuidad es una propiedad demostrada, no una apariencia administrativa.

Para sesiones superiores sucesivas, RFC 5387 también distingue tareas. Puede ser necesario conservar el latch entre sesiones para impedir suplantación intersesión, mientras la autenticación vinculada debe ejecutarse en cada nueva sesión. Cachear una relación y verificar un acto no son lo mismo.

El fracaso tardío tiene un coste

En IPsec con autenticación IKE plena, el intermediario debería ser rechazado durante la creación de la SA. En CBB, IKE sin autenticación puede completar la negociación. La detección llega cuando la autenticación superior incorpora la vinculación y obtiene un valor diferente.

Un fallo en ese punto protege la decisión final, pero no borra el intervalo anterior. El sistema ya gastó recursos y quizá entregó material de autenticación. RFC 5387 advierte que ciertos intercambios basados en contraseña pueden exponer datos útiles para un ataque fuera de línea, aunque la sesión termine después.

Por eso la métrica no es solo «ataque detectado». Debe incluir tiempo hasta la detección, estado asignado, bytes enviados, secretos expuestos y privilegios concedidos. Los límites de consumo antes de autenticación y el diseño del método superior forman parte de la seguridad del canal.

Una interfaz que muestra un único estado verde pierde esta secuencia. Conviene separar SA creada, canal vinculado y principal autorizado. El orden es evidencia.

Prueba de aceptación con un proxy real

Primero se conectan cliente y servidor directamente. Cada extremo guarda su valor de vinculación, identidad de par, calidad de protección y resultado de autenticación. La comparación debe demostrar un mismo canal.

Después se introduce un proxy que negocia dos SA robustas y retransmite sin alterar el protocolo superior. No se degradan algoritmos ni se falsifican paquetes. La prueba busca una topología incorrecta con controles locales correctos. La autenticación ligada debe fallar.

Se repite con autenticación de servidor, de cliente, bilateral y repartida entre capas. El resultado de identidad varía según la política; la comparación de binding sigue ocurriendo en ambos extremos. Luego se renueva la SA en una sesión larga. Una renovación compatible debe producir un recibo de transición; un cambio de par o de calidad debe romper el latch antes de aceptar más datos.

El informe registra también el camino negativo: quién detectó la diferencia, qué estado destruyó, qué error recibió la aplicación y cuánto sucedió antes. Si el operador no puede distinguir un fallo de vinculación de una contraseña incorrecta, su capacidad de respuesta es incompleta.

La autoridad no aparece en el intermediario

La lectura institucional de RFC 5387 es austera. Un componente que mantiene un control local no recibe por ello autoridad para declarar una relación global. El proxy puede operar dos asociaciones impecables; no puede convertirlas en consentimiento de los extremos.

Cada unión crítica necesita un recibo propio. Debe nombrar el objeto a ambos lados, preservar las propiedades relevantes y fallar cuando la transición carece de prueba. Esto vale para canales, cadenas de suministro, delegaciones automatizadas y registros de infraestructura.

La claridad resulta incómoda porque impide usar una marca de seguridad como sustituto de la relación que realmente importa. Pero esa incomodidad protege a los principales: conserva la asimetría que eligieron y niega al intermediario el poder de inventar la composición.

Fuentes