Resumen

  • El borrador de julio ofrecía una variante de cuatro mensajes: colocaba ID_CRED_I en texto claro en el primero y reconocía que el iniciador perdía protección de identidad. Esa sección ya no está en la revisión 01 del 28 de septiembre.
  • El texto vigente propone cinco mensajes obligatorios. El quinto permite al respondedor verificar la autenticación del iniciador antes de derivar claves de aplicación.
  • La propuesta de valor de método «5» no equivale a una asignación de IANA ni a una suite poscuántica. El método basado en KEM solo brinda esa propiedad al instanciarse con un KEM poscuántico adecuado.

La diferencia entre dos versiones del mismo Internet-Draft no es una teoría sobre todos los protocolos posibles. Es un cambio visible en la oferta que examina el grupo LAKE. La sección 6.3 de la versión 00 explicaba que el iniciador podía colocar el identificador de su credencial directamente en message_1. El respondedor obtenía antes la información para autenticarlo y se podía prescindir del quinto mensaje. El propio texto decía que la reducción a cuatro sacrificaba la protección de la identidad del iniciador. No consta que esa opción se hubiese implantado ni que causara una exposición real.

La versión 01, fechada el 28 de septiembre, suprime esa variante y enumera message_1, message_2, message_3, message_4_KEM y message_5_KEM como obligatorios. El flujo de cinco mensajes no nació esta semana: ya era la propuesta principal de julio. Lo nuevo es que la alternativa corta dejó de figurar en el documento. Tampoco puede atribuirse a los autores una motivación concreta solo por la supresión, ni concluir que cualquier diseño de cuatro mensajes sea imposible.

La secuencia más larga tiene una lógica de posesión de claves. Con una clave KEM estática, quien la controla necesita recibir primero un texto encapsulado para esa clave antes de demostrar que posee la parte privada. Según la revisión, esa dependencia puede añadir hasta un viaje de ida y vuelta. En su diagrama, el cuarto mensaje transporta la confirmación del respondedor y el quinto la del iniciador. El iniciador puede derivar claves de aplicación después de recibir el cuarto y construir el quinto. El respondedor llega a ese punto después de verificar el quinto.

Un informe que marque «autenticado» al recibir el cuarto en ambos extremos adelantaría indebidamente la conclusión del respondedor.

Hay otra decisión que antecede al último mensaje. Antes de enviar su propia credencial cifrada en el tercero, el iniciador debe validar y aceptar la del respondedor conforme a su política local. Esta regla ya aparecía en la versión 00. La validez criptográfica de una credencial no implica que pertenezca al destinatario que el operador quería. El cifrado del identificador, la aceptación del par y la autenticación mutua completa son controles distintos; ninguno se sustituye por contar paquetes.

También cambió lo que el borrador pide registrar. La versión 00 proponía números para algoritmos ML-KEM en COSE, suites de EDHOC y un tipo de método. La sección 7 de la versión 01 conserva solo una propuesta de tipo de método, con «5» expresamente sugerido, y cita trabajos separados sobre KEM poscuánticos y suites LAKE. Es una separación de textos, no la prueba de que IANA ya registró un método o que las otras especificaciones terminaron su trámite. La propia revisión aclara que el método no fija un KEM: sin un KEM poscuántico seleccionado, su nombre no garantiza resistencia cuántica.

Una prueba responsable en dispositivos limitados necesitaría mirar qué credencial se revela y a quién, qué suite se negocia de verdad, cuándo cada extremo acepta la sesión y qué ocurre si falta el último mensaje. Son preguntas de evaluación de Daniel Kade, no nuevos mandatos de la IETF. La revisión es un borrador activo, sin datos de adopción, latencia medida ni incidente de seguridad documentado.

Fuentes