Resumen

  • El 24 de agosto de 2026, el IESG aprobó draft-ietf-ipsecme-ikev2-pqc-auth-12 como Proposed Standard. Al cerrar la evidencia el día 27, el texto seguía siendo un Internet-Draft activo en la cola del RFC Editor, no una RFC numerada.
  • El documento adapta el método Digital Signature de IKEv2 a ML-DSA y SLH-DSA en modo puro. La aprobación no prueba que un equipo seleccionó esos algoritmos, transportó los mensajes grandes, verificó AUTH, estableció una IKE SA o autorizó el tráfico de una Child SA.

El mismo distintivo, resultados opuestos

Una revisión de migración muestra dos pasarelas con el mismo estado: «preparada para criptografía poscuántica». Las dos tienen una credencial ML-DSA registrada y software capaz de reconocerla. El inventario las cuenta como iguales.

Los paquetes deshacen esa igualdad. En una conexión, la política permite volver a ECDSA y ese es el algoritmo que aparece en AUTH. En la otra, el material poscuántico se divide en mensajes más grandes, pero el camino operativo nunca entrega un conjunto que el par pueda reconstruir. Ninguna IKE SA queda autenticada con ML-DSA.

El ejemplo es analítico y no describe una avería comercial. Su función es fijar la pregunta que nace con la noticia: ¿qué cadena de pruebas permite afirmar que un túnel, y no solo un producto, quedó autenticado mediante una firma poscuántica?

Lo aprobado y lo que aún falta publicar

El anuncio del IESG identifica la revisión 12 de «Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC» y la aprueba como Proposed Standard. El trabajo procede del grupo IP Security Maintenance and Extensions. La propuesta no sustituye el núcleo de IKEv2; utiliza su estructura de autenticación por firma para incorporar esquemas poscuánticos.

El estado documental sigue siendo parte del hecho. El 27 de agosto, Datatracker mostraba «RFC Ed Queue» y al RFC Editor esperando la comprobación de referencias y el formato. El Internet-Draft está fechado el 21 de agosto y declara vencimiento el 22 de febrero de 2027. Todavía puede recibir cambios editoriales. Presentarlo como RFC publicada sería adelantar un resultado.

La sección de IANA tampoco pide nuevas asignaciones. La propuesta combina mecanismos ya registrados: Digital Signature como método 14, IKEV2_FRAGMENTATION_SUPPORTED como notificación 16430, SIGNATURE_HASH_ALGORITHMS como 16431, SUPPORTED_AUTH_METHODS como 16443 e Identity como función hash 5. El registro define palabras y valores comunes; no registra lo ocurrido en una sesión.

AUTH identifica la firma concreta

IKE_SA_INIT negocia parámetros criptográficos, intercambia nonces y realiza el intercambio de claves. IKE_AUTH transporta identidades y pruebas, y normalmente negocia la primera Child SA. Una mejora en el primer eje no sustituye la evidencia del segundo.

RFC 7427 define el método genérico Digital Signature. Dentro de Authentication Data coloca primero un AlgorithmIdentifier codificado en DER y después la firma. Ese identificador, leído en el AUTH real, distingue el esquema y sus parámetros.

Para ML-DSA y SLH-DSA, la nueva propuesta utiliza el modo puro. El material de sesión llega al algoritmo sin un prehash externo. Los pares que quieran usar esos esquemas deben incluir la función Identity, valor 5, en SIGNATURE_HASH_ALGORITHMS; un esquema que la necesita no puede emplearse con un par que no la anunció.

Identity 5 solo explica el tratamiento de la entrada. No dice si la firma fue ML-DSA-44 o SLH-DSA-128s. Verla en ambas direcciones es una condición previa. La selección aparece en el AlgorithmIdentifier, y la aceptación se prueba con la verificación y la credencial presentada.

Una lista de métodos no es un acuerdo

El proyecto ofrece dos ayudas para escoger un tipo de clave compatible. Certificate Request puede orientar la selección de una cadena. SUPPORTED_AUTH_METHODS, definido en RFC 9593, permite anunciar una lista ordenada de métodos o esquemas.

RFC 9593 declara opcionales tanto el envío como el uso de esa información. La lista puede evitar intentos inútiles, pero no obliga a que AUTH use uno de sus elementos. La política local, la clave disponible, el certificado, la confianza y el verificador siguen decidiendo el resultado.

Algo similar ocurre con los estándares de algoritmos. FIPS 204 especifica ML-DSA y FIPS 205 especifica SLH-DSA. RFC 9881 y RFC 9909 aportan OID, codificaciones PKIX y restricciones de uso. Son piezas de interoperabilidad, no evidencia de que una clave privada esté aprovisionada, una cadena sea aceptada, un módulo responda a tiempo o dos implementaciones hayan completado IKE_AUTH.

Por eso el inventario debe vincular nombre de clave, huella de certificado, cadena emisora, key usage, proveedor criptográfico, compilación y política de conexión.

El tamaño convierte la red en parte de la verificación

El documento da cifras que cambian la operación. La clave pública ML-DSA-44 ocupa 1.312 bytes y su firma 2.420. La firma SLH-DSA más pequeña ronda los 7.856 bytes. A ello puede sumarse una cadena de certificados.

Los pares que implementen el mecanismo deben soportar fragmentación de mensajes IKEv2. RFC 7383 anuncia esa capacidad en IKE_SA_INIT y permite fragmentar mensajes posteriores que contienen un payload Encrypted. El propio IKE_SA_INIT no puede fragmentarse así.

La capacidad no garantiza el viaje. Un cortafuegos puede tolerar IKE_SA_INIT y perder fragmentos de IKE_AUTH; un NAT puede cambiar el comportamiento; un camino con PMTU conocida o un transporte fiable puede no fragmentar. Hace falta registrar el número y tamaño de fragmentos cifrados, las retransmisiones, la reconstrucción y la respuesta que terminó el intercambio.

Clave compartida y autenticación no son la misma mejora

La expresión «VPN poscuántica» suele mezclar confidencialidad y autenticación. RFC 9370 añade intercambios de claves y afirma expresamente que su foco urgente es la confidencialidad, no la autenticación. RFC 8784 mezcla una clave precompartida adicional, pero mantiene las comprobaciones de autenticación existentes.

Así, una IKE SA puede usar un componente poscuántico o híbrido para el establecimiento de secreto y continuar firmando AUTH con ECDSA. También puede verificar ML-DSA sin que eso identifique los grupos usados en el intercambio de claves. Un informe correcto muestra ambos ejes.

De la firma al tráfico autorizado

Una firma válida prueba los octetos de esa sesión bajo la credencial aceptada. No concede automáticamente acceso a toda red ni aprueba cualquier Traffic Selector. IKEv2 incluso puede establecer la IKE SA aunque falle la primera Child SA.

La afirmación completa necesita ocho enlaces: revisión implementada, binario y proveedor, clave y cadena, anuncios en ambos sentidos, AlgorithmIdentifier observado, fragmentos y reconstrucción, verificación e identidad de la IKE SA, y por último política, selectores y tráfico de la Child SA. Solo esa secuencia convierte «preparada» en una conclusión que otro operador puede refutar o reproducir.

Fuentes