Resumen

  • RFC 9867 permite mezclar una PPK en IKEv2 mediante IKE_INTERMEDIATE y CREATE_CHILD_SA, incluso para crear o renovar una SA hija o una SA IKE con una PPK nueva.
  • La respuesta a CREATE_CHILD_SA puede omitir la identidad PPK y aun así crear la SA por el procedimiento ordinario. Si esa caída no cumple la política obligatoria del iniciador, este puede eliminar de inmediato lo recién creado.
  • Hace falta un recibo por SA que distinga selección, confirmación, autorización, creación, aceptación, uso y eliminación. Es una propuesta editorial de Daniel Kade, no un mandato de RFC 9867 ni del IETF.

La frase «asociación creada» parece cerrar la historia. Hubo respuesta del par, se derivaron claves, aparecieron identificadores y el sistema de operaciones obtuvo un evento que puede contar. Más tarde, ese registro puede acabar en un informe que declare terminada la migración poscuántica.

RFC 9867 demuestra que la inferencia es demasiado amplia. La misma SA puede existir cuando el respondedor no implementa la extensión, carece de configuración, no encuentra una identidad PPK coincidente o guarda otro valor bajo una identidad que parece igual. Con política opcional, seguir adelante es válido. El éxito del intercambio y la evidencia de la protección dejan de ser sinónimos.

Una sesión contiene varias genealogías

IKEv2 no genera una sola entidad criptográfica. Establece una SA IKE, autentica a los pares, crea SA hijas y permite renovar ambos tipos. Decir que «el túnel usa PPK» borra tres datos: qué asociación, qué intercambio y qué cálculo de claves.

RFC 8784 introdujo una vía para incorporar una clave precompartida al material de sesión. Parte del establecimiento inicial, pero no usa esa PPK para proteger la SA IKE inicial frente al adversario cuántico contemplado. RFC 9867 no deroga ese mecanismo; incorpora dos caminos adicionales.

El primero pasa por IKE_INTERMEDIATE, el intercambio anterior a la autenticación definido en RFC 9242. El iniciador ofrece identidades; el respondedor puede elegir una y devolver una confirmación. La mezcla ocurre antes de IKE_AUTH, de modo que contribuye a la SA IKE inicial y a la protección de la autenticación. Si otros intercambios intermedios también recalculan material, la operación PPK debe ser la última antes del siguiente intercambio. El orden es parte de la afirmación de seguridad.

El segundo utiliza CREATE_CHILD_SA. Permite aportar una PPK nueva al crear o renovar una SA hija, o al renovar la propia SA IKE, sin derribar toda la relación existente. Esa capacidad hace viable la rotación, pero multiplica las genealogías. La SA IKE antigua, las hijas que continúan y la nueva asociación no heredan una única etiqueta de «protegidas por PPK».

Los múltiples intercambios de RFC 9370 y la terminología híbrida poscuántica de RFC 9838 dan contexto. Sin embargo, un inventario de algoritmos muestra capacidad, no ejecución. Una negociación muestra un evento, no necesariamente la contribución que llegó a una SA concreta.

Coincidencia de valor no equivale a permiso

RFC 9867 emplea las notificaciones registradas USE_PPK_INT, con valor 16445, y PPK_IDENTITY_KEY, con valor 16446. El registro IANA permite comprobarlas. Son observaciones de protocolo; no son la PPK secreta ni justifican conservarla en telemetría.

La confirmación usa los primeros ocho octetos de la función seudoaleatoria negociada sobre el contexto definido. Detecta que dos pares hayan seleccionado la misma identidad mientras poseen valores distintos. Esa prueba supera una simple búsqueda de configuración. Aun así, no autoriza automáticamente el uso de la PPK para el par que después resulte autenticado.

En IKE_INTERMEDIATE, el respondedor puede escoger antes de conocer la identidad autenticada del iniciador. Cuando la autenticación la revela, su regla local podría prohibir esa PPK para ese sujeto. RFC 9867 dice que debería abortar, aunque permite continuar si la política local lo admite. Hallar material, confirmar que coincide, identificar al par y autorizar la relación son decisiones separadas.

La automatización suele comprimirlas. El almacén dice «encontrada»; la confirmación dice «mismo valor»; la autenticación dice «este par»; la política decide «permitido». Una sola marca verde elimina al propietario de cada decisión.

La asociación creada antes de ser rechazada

El ejemplo más nítido aparece en CREATE_CHILD_SA. El iniciador solicita una PPK nueva. Si el respondedor no puede utilizarla, omite PPK_IDENTITY_KEY, pero el flujo IKEv2 normal todavía puede crear la SA. Si la PPK era opcional, el iniciador puede aceptar y utilizarla. Si era obligatoria, puede eliminarla de inmediato.

El contador de creación registra éxito en ambos casos. Uno es una caída aceptada; el otro, un estado transitorio rechazado por política. Resultan relevantes la hora de creación, el instante de evaluación y la aceptación o eliminación. También importa si algún paquete cruzó la SA antes del borrado, si una ruta de respaldo la instaló o si el par remoto siguió tratándola como activa.

La palabra «obligatoria» necesita alcance y propietario. Puede aplicarse a un par, un tipo de tráfico, una fase o solo a una renovación. No se deduce de que el producto tenga soporte. Y la caída opcional puede ser una decisión deliberada para conservar interoperabilidad. El fallo de gobernanza consiste en presentar esa decisión como si demostrara el estado fuerte.

Un recibo de transición que no guarda la clave

El recibo de mezcla de PPK propuesto aquí es un instrumento editorial. No es un campo de RFC 9867, una obligación del IETF ni una razón para almacenar la PPK.

Para cada SA nueva o renovada, debe registrar el tipo de intercambio y la genealogía de la SA IKE padre. Ha de distinguir RFC 8784 de las dos vías de RFC 9867. Puede conservar una identidad no secreta o una huella diseñada para minimizar datos, los estados ofrecido y seleccionado, el resultado de confirmación y el momento en que quedó disponible la identidad autenticada. Debe adjuntar la regla obligatoria u opcional de cada lado en la medida observable, su versión y su responsable.

Después viene el orden de derivación. Si hubo varias operaciones intermedias, ¿fue la PPK la última recalculación exigida? Los identificadores atan el recibo a la SA, sin fingir que los identificadores prueban el cálculo. Creada, instalada, aceptada, observada en uso y eliminada son casillas distintas. La causa de la caída, la excepción, la reversión y la próxima revisión completan la historia.

Existe un límite de observabilidad. Una captura puede mostrar notificaciones y tráfico, pero no todo el estado privado de una implementación. El proceso local puede atestiguar la mezcla sin revelar el secreto. Las afirmaciones entre proveedores exigen confianza acotada. El recibo debe nombrar la fuente de cada observación y marcar toda inferencia.

Medir la migración asociación por asociación

La motivación poscuántica exige cautela. RFC 9867 señala que las primitivas simétricas no se consideran hoy afectadas del mismo modo que los mecanismos de clave pública por un ordenador cuántico criptográficamente relevante. No afirma que tal máquina exista, no fija una fecha y no certifica ningún producto como seguro.

Una PPK «nueva» también debe ser diferente. Reutilizar la anterior no aporta sentido a un mecanismo de rotación fresca. Su entropía, custodia, distribución y respuesta a compromiso pertenecen a la operación, y el intercambio exitoso no los certifica.

Un informe útil contará asociaciones y desenlaces exactos: uso de RFC 8784, mezcla en IKE_INTERMEDIATE, renovación con PPK fresca, caída opcional, fallo de confirmación o creación seguida de borrado por política obligatoria. Esa variedad no es ruido que deba homogeneizarse. Es el mapa real de decisiones.

El protocolo permite avanzar entre capacidades desiguales porque la red debe funcionar. La gobernanza tiene que preservar cómo avanzó. RFC 9867 ofrece una transición flexible; no convierte «creada» en prueba criptográfica.

Fuentes