El intruso conocía la dirección; la regla anónima no podía entregársela

Resumen

• RFC 5386 permitía verificar una firma IKEv2 con la clave pública que el propio par entregaba, pero esa prueba no vinculaba la clave a un nombre o una dirección mediante una autoridad externa.
• Un par que coincidía con una entrada PAD no-BTNS y no superaba su autenticación debía ser rechazado; no podía reaparecer como anónimo bajo la entrada comodín.
• La autorización anónima exigía una entrada BTNS situada al final, selectores sin solapamiento y una regla SPD marcada expresamente con BTNS_OK.

Una dirección afirmada no era una dirección concedida

El ejemplo de RFC 5386 parte de una pasarela con relaciones conocidas y una vía abierta a pares BTNS. Un atacante puede conocer la dirección de un host legítimo y usarla en su intento de crear una asociación. La información necesaria para formular la afirmación es pública o fácil de observar. Lo difícil es demostrar que la relación autorizada le pertenece.

La Peer Authorization Database resuelve primero esa competencia. Busca la identidad declarada entre las entradas ordinarias. Si el atacante coincide con el socio conocido, debe satisfacer el método de autenticación de esa entrada. Un fallo no significa «pruebe como desconocido». Significa rechazo.

Si ninguna entrada conocida corresponde, el sistema puede representar localmente al par mediante la clave pública presentada y consultar las reglas BTNS. Este segundo recorrido no borra el primero. Solo recibe los casos que quedaron fuera de las relaciones nombradas.

La diferencia protege algo más que un nombre. La entrada PAD también delimita qué identidades puede proponer el par para sus Child SAs. La regla comodín debe tener restricciones que no se solapen con las entradas ordinarias. Así, una clave desconocida puede recibir el servicio anónimo previsto sin convertirse en la pasarela, el host o la red de otra entidad.

La firma cerró un intercambio, no un registro de propiedad

BTNS seguía usando criptografía. El par incluía una clave pública desnuda en el payload CERT y firmaba el intercambio IKEv2 con la clave privada correspondiente. Una verificación correcta enlazaba esa clave al intercambio y mostraba control sobre la clave privada.

No aparecía una autoridad que dijera «esta clave pertenece a la organización X». RFC 5386 añadió por ello un tipo local PUBLICKEY: su identidad era la propia clave. El tipo no viajaba por la red. Era una forma interna de hacer que la PAD pudiera decidir sobre una prueba más estrecha.

Ese diseño evita dos exageraciones. No es correcto decir que no se autenticó nada: la firma y la continuidad de la SA son hechos criptográficos. Tampoco es correcto atribuir un nombre externo, una titularidad de dirección o un privilegio de aplicación que ninguna fuente verificó.

RFC 7670 amplió años después el soporte IKEv2 para claves públicas brutas mediante SubjectPublicKeyInfo y exige validación fuera de banda cuando se busca autenticidad de propietario. RFC 7619 creó NULL Authentication e ID_NULL, donde el protocolo mantiene la unión criptográfica del intercambio sin certificar identidad. Son desarrollos diferentes, pero conservan la misma obligación editorial: especificar qué cosa concreta quedó probada.

El segundo control ocurría al negociar tráfico

La primera decisión responde quién puede establecer una IKE SA bajo cierto régimen. La Child SA plantea otra pregunta: qué tráfico puede representar ese par. Una implementación que comprueba la clave pero acepta cualquier selector convierte una autorización anónima limitada en secuestro de rutas o identidades.

RFC 5386 describe una segunda consulta a la PAD durante la negociación. Los selectores afirmados por el par BTNS se comparan con las identidades reservadas por entradas no-BTNS. La entrada comodín debe ser no superpuesta no solo de nombre, sino en las identidades de Child SA que permite.

El control produce tres resultados separados: el par desconocido fue elegible para BTNS; el selector solicitado estaba dentro de su ámbito; la SPD local permitía BTNS para ese tráfico. Solo la conjunción autoriza la SA hija. Un registro que conserva únicamente «IKE_SUCCESS» no puede demostrar ninguno de los límites.

RFC 7619 repite el riesgo con pares NULL detrás de NAT: un par malicioso podría solicitar el selector de un servidor DNS usado por el otro extremo y desviar tráfico. El texto recomienda aislar y restringir a los pares no autenticados. El problema no desaparece porque el cifrado posterior sea correcto.

La SPD exigía una autorización visible

RFC 5386 añadió el indicador BTNS_OK a las entradas de la Security Policy Database. El tráfico de un par BTNS solo podía corresponder a reglas con ese indicador. La capacidad del sistema no equivalía a permiso de uso universal.

Un operador podía abrir un servicio NFSv4 a pares sin identidad de red y mantener el resto bajo relaciones autenticadas. También podía dejar tráfico diferente en bypass, aunque esa decisión no recibía protección IPsec. Lo esencial era que cada rama conservara su significado.

RFC 5386 no definió un algoritmo de fallback a IP sin proteger cuando IKE fallaba. Tratar BTNS como el peldaño medio de una escalera certificado–anónimo–claro inventaría una política distinta. RFC 5387 fue explícito: BTNS debía sustituir a la ausencia de seguridad, no a una seguridad más fuerte.

Por eso el rechazo merece persistencia. Si una identidad conocida falla y el flujo termina, el sistema ha protegido la jerarquía. Si el observador borra los fracasos y muestra solo el túnel que finalmente apareció, puede ocultar exactamente el descenso que debía impedir.

La continuidad duraba lo que duraba la SA

RFC 5387 llamó «continuidad de asociación» a la garantía débil. Una vez creada una SA sin intermediario, IPsec podía proteger integridad, confidencialidad y anti-replay durante su vida. El emisor seguía siendo el mismo par no autenticado asociado a esa SA.

La garantía no convertía al par en una persona nombrada ni cruzaba automáticamente un rekey. Un atacante activo seguía pudiendo intervenir en el establecimiento inicial. Durante una renovación, la falta de unión entre sesiones podía permitir que el atacante ocupara la nueva asociación.

Connection latching enlaza flujos de capa superior con una sucesión de SAs. Channel binding incorpora una característica del canal en la autenticación de la capa superior. Juntos pueden descubrir que un intermediario concatenó dos asociaciones. RFC 5386 los menciona, pero no especifica la solución completa.

En Channel-Bound BTNS, la detección puede llegar después de que IKE haya tenido éxito. El sistema ya creó estado y quizá expuso mensajes de autenticación superiores. RFC 5387 advierte contra mecanismos que revelen material sensible o atacable fuera de línea. Una futura denegación no deshace una exposición previa.

Un control de orden es un control de autoridad

La tabla PAD puede contener todas las entradas correctas y aun ser insegura si el motor continúa tras un fallo o evalúa primero el comodín. El orden es parte del programa. Cambiarlo altera quién tiene la última palabra sobre una identidad.

Una revisión útil no se limita a comparar archivos. Debe ejecutar casos. Un socio válido entra por la regla fuerte. Una clave desconocida entra solo por el servicio anónimo. Un atacante que afirma la identidad del socio pero no presenta su credencial termina rechazado. Después, el atacante anónimo solicita la dirección del socio y vuelve a ser rechazado por la comprobación de selectores.

También hay que apuntar a una regla SPD sin BTNS_OK. La SA no debe extenderse a ese tráfico. Estas pruebas muestran el camino y el veto, no solo la presencia de configuración.

Frontera de evidencia

Los documentos oficiales prueban el diseño y sus advertencias, no la implementación actual de un producto, la adopción de BTNS o un incidente. El contexto original de clave RSA de RFC 4306 cambió con RFC 7296 y RFC 7670. Una afirmación sobre sistemas vivos necesita versión, compilación, configuración, trazas y observación de paquetes.

La lectura de Lu Heng separa identidad declarada, posesión de clave, autoridad de política, asociación instalada, paquete protegido y efecto de aplicación. En este caso, la mayor claridad proviene de mantener el «no» en su lugar. El sistema sabía que la identidad reclamada no había superado su prueba. La regla anónima no tenía autoridad para convertir ese conocimiento en permiso.