Resumen

  • El 8 de septiembre de 2026, el Datatracker situó draft-ietf-lake-edhoc-psk en WG Consensus: Waiting for Write-Up y ese mismo día apareció la revisión 09. Sigue siendo un Internet-Draft, no un RFC ni una norma aprobada por el IESG.
  • La nueva revisión permite que un ID_CRED_PSK corresponda a más de una PSK candidata y a sus credenciales asociadas. El respondedor intenta descifrar y verificar con cada contexto hasta encontrar uno válido.
  • Dos respondedores pueden recibir el mismo identificador y aceptar con versiones distintas de la credencial si sus tablas locales no coinciden. El identificador por sí solo no reconstruye esa decisión.
  • Daniel Kade propone conservar la versión del conjunto candidato, la credencial no secreta seleccionada y el resultado de los intentos. Es una recomendación editorial, no texto del borrador.

La novedad no aumenta necesariamente el mensaje. ID_CRED_PSK sigue viajando protegido y puede adoptar la representación compacta de un kid de COSE. La pluralidad aparece al otro lado: cuando el respondedor consulta el identificador en su almacén, la respuesta puede ser una lista.

La revisión 09 precisa qué contiene cada opción. No es solo una PSK. El conjunto incluye CRED_I, CRED_R y la información necesaria para procesar EDHOC. Al recibir el mensaje 3, el respondedor selecciona el primer candidato, deriva K_3 e IV_3 y verifica CIPHERTEXT_3B mediante AEAD. Si falla, elige el siguiente. Solo cuando ninguno funciona trata el resultado como un problema de procesamiento o una posible manipulación.

Del puntero singular al conjunto local

La redacción anterior tenía otro centro de gravedad. La revisión 08 describía el identificador como medio para recuperar «la PSK correcta». Recomendaba que la identificase de forma única o estocástica, y mencionaba expresamente la ambigüedad y el coste de probar varias claves. En la diferencia oficial, esa posibilidad deja de ser solo algo que evitar y se convierte en una ruta de procesamiento definida.

La preferencia por la unicidad no desaparece. La revisión 09 sigue recomendando que el identificador determine de manera única o estocástica el contexto correspondiente. La diferencia es jurídica y operativa: MAY permite una lista. Un diseño con varios candidatos ya no puede descartarse como desviación por el mero hecho de no resolver a una sola clave.

El cambio procede del proceso de revisión. En el hilo del último llamado se propuso aclarar la recuperación de credenciales candidatas, seleccionar una primera y repetir con otra cuando fallara AEAD. El historial del Datatracker registra el 8 de septiembre la salida de Last Call, la designación del document shepherd y la subida de la revisión 09.

Ese movimiento no cierra el estándar. WG Consensus: Waiting for Write-Up prepara el expediente del grupo. La ficha del documento lo mantiene como borrador activo de LAKE, con destino propuesto de Standards Track. Faltan la evaluación del IESG, posibles cambios y, si se aprueba, la edición y publicación como RFC.

La identidad no cabe en el kid

RFC 9528 diseñó EDHOC para que una referencia compacta permita recuperar una credencial completa. RFC 9052 no promete que un kid sea único en el universo: la aplicación lo emplea para encontrar una clave. El borrador PSK añade una consecuencia importante. Si varias credenciales comparten esa entrada, el hecho autenticador es el candidato que verificó, no el texto del identificador recibido.

CRED_I y CRED_R deben expresar identidades distintas para limitar reflexión y misbinding. La PSK tiene que encajar con el algoritmo hash de la suite EDHOC seleccionada. RFC 8392 ofrece CWT o CCS como una representación posible de las afirmaciones asociadas. Por tanto, cada intento evalúa una unión entre material secreto, identidades y parámetros, no una bolsa de claves equivalentes.

Tampoco debe confundirse la búsqueda con adivinar contraseñas. El documento exige un mínimo de 128 bits de entropía y 128 bits de longitud para las PSK externas. Una contraseña o fuente de baja entropía queda fuera del modelo seguro. Las opciones han sido provisionadas; el protocolo solo resuelve cuál corresponde al mensaje.

Disponibilidad primero, trazabilidad después

Una lista candidata puede amortiguar una rotación o una recuperación. Mientras parte de una flota conserva la versión anterior y otra parte ya usa la nueva, el mismo identificador corto puede mantener la comunicación. También puede absorber diferencias temporales entre bases de provisionamiento. Son usos razonables inferidos, no despliegues demostrados por las fuentes.

El precio aparece en los registros. Supongamos que dos nodos reciben el mismo ID_CRED_PSK. Uno tiene [v3, v2]; otro, [v2, v3]. Ambos aceptan el mensaje, pero no necesariamente con el mismo candidato ni tras el mismo número de operaciones. Un evento «ID 17 autenticado» oculta la versión aceptada, el solapamiento y la divergencia entre almacenes.

No hace falta volcar secretos para corregirlo. El registro puede incluir una huella del identificador, la versión o digest del conjunto candidato, su tamaño, la versión no secreta de la credencial seleccionada, la suite y el hash, el número de intentos, el resultado, la versión de política y la hora. Para análisis público bastan agregados: latencia por rango de candidatos, agotamientos y porcentaje de éxitos posteriores al primer intento.

Durante una migración, ese último porcentaje cuenta una historia. Si crece al principio y luego cae, la flota está convergiendo. Si continúa después de la fecha de retiro, la compatibilidad temporal se ha convertido en dependencia. Una comparación de versiones entre respondedores muestra además si el plano de provisionamiento distribuyó la misma política.

El borrador no obliga a crear este recibo. Es la propuesta editorial de Daniel Kade para preservar el significado de una autenticación sin publicar la PSK ni transformar un identificador protegido en un nombre civil. La compactación del protocolo es una virtud; la compactación de la evidencia no lo es.

Fuentes