Resumen

  • La revisión 01 establece que el iniciador autentica al respondedor tras verificar message_4_KEM; el respondedor no autentica al iniciador hasta verificar message_5_KEM.
  • El mensaje 3 puede ser confidencial y tener integridad sin autenticar al iniciador. La clave final debe esperar a la autenticación mutua, la integridad de la transcripción, la autenticidad de credenciales y la prueba de posesión.

El estado verde llega demasiado pronto

Después del tercer mensaje ya existen suficientes señales para engañar a un sistema de operaciones. Hubo un intercambio KEM efímero, el iniciador validó una credencial del respondedor, encapsuló hacia su clave estática y envió su propia credencial dentro de ciphertext protegido. El respondedor pudo decapsular y descifrar.

Sin embargo, la revisión 01 de KEM-based Authentication for EDHOC, presentada el 28 de septiembre de 2026, dice que la clave de ese mensaje no autentica al iniciador. El respondedor todavía no ha enviado el MAC con el que se autenticará; el iniciador tampoco ha enviado el suyo. La propuesta necesita dos mensajes adicionales porque el dueño de una clave KEM estática requiere primero que su peer encapsule hacia la clave pública antes de demostrar la posesión de la privada.

El Datatracker lo registra como Internet-Draft activo del grupo LAKE y muestra solo I-D Exists como estado IESG. El documento aspira a Standards Track, pero no es RFC, norma aprobada ni evidencia de implementación. Caduca el 1 de abril de 2027 si no se actualiza o avanza.

La confianza se cierra dos veces

El mensaje 1 lleva la clave KEM efímera. El respondedor encapsula hacia ella y devuelve en el mensaje 2 el ciphertext y su identificador de credencial. Antes de revelar su credencial, el iniciador debe recuperar, validar y aceptar la del respondedor conforme a política local. La validez criptográfica no basta: el documento advierte que la credencial podría ser válida pero pertenecer a un sujeto no confiable o no previsto.

En el mensaje 3, el iniciador encapsula hacia la clave KEM estática del respondedor y protege sus propios datos de credencial. El respondedor decapsula el secreto, pero eso no cierra la identidad. message_4_KEM aporta el MAC explícito del respondedor; solo después de verificarlo puede el iniciador autenticarlo y conservar PRK_out o las claves de aplicación.

La otra dirección sigue pendiente. El respondedor autentica al iniciador al verificar el MAC de message_5_KEM. El borrador reconoce que un posible error de vinculación de identidad puede permanecer oculto hasta ambas comprobaciones. Por eso los EAD deben tratarse como no protegidos y el material de clave no debe persistirse antes del final.

Una variable global authenticated perdería ese intervalo asimétrico. También confundiría la posesión de una clave con la identidad a la que se atribuye, la política que confía en ella y la acción que la aplicación permite.

Una clave poscuántica también necesita frescura

El calendario combina una contribución efímera y dos secretos derivados de claves KEM estáticas. Cada sesión debe producir encapsulaciones nuevas; ss_I, ss_R y sus ciphertexts no pueden reutilizarse. Además, el KEM debe ofrecer IND-CCA2 y vincular criptográficamente el secreto con la clave pública receptora, porque IND-CCA2 por sí solo no elimina la reencapsulación ni los unknown key shares.

RFC 9935 y FIPS 203 especifican ML-KEM, no la autoridad de una organización. SP 800-227 orienta sobre el uso seguro de KEM. RFC 9528 aporta la base EDHOC. El nuevo borrador propone el contexto de transcripción y credenciales, sin demostrar despliegue, interoperabilidad o rendimiento.

La propia sección de seguridad excluye la no repudiación: solo ofrece prueba implícita de participación. Un peer LAKE autenticado no queda autorizado por ello para cambiar una ruta, instalar software, mover fondos o accionar un dispositivo. El registro operativo debe separar método y suite, validación local de credencial, estados de mensajes 2–5, verificaciones MAC_2 y MAC_3, frescura sin secretos, transición de persistencia, autorización, petición protegida, respuesta y efecto.

La cobertura anterior de BTW sobre RFC 9668 separó el mensaje 3 combinado con OSCORE del resultado de la aplicación. Esta revisión abre una frontera previa: su mensaje 3 ni siquiera concluye la autenticación KEM.

Running-Code Primacy exige cortar los mensajes 4 y 5, repetir encapsulaciones y sustituir credenciales para observar qué estado sobrevive. Minimum Initial Specification respalda un mínimo común —finales explícitos y frescura por sesión— sin centralizar la política de confianza. Reality Layers mantiene separadas posesión, identidad, autorización y consecuencia.

Fuentes