Resumen

  • El grupo LAKE del IETF abrió el 8 de septiembre de 2026 la última llamada de grupo de trabajo para draft-ietf-lake-authz-08; termina el día 22.
  • En el flujo normal de ELA, el dispositivo U envía ID_CRED_I al autenticador V en el mensaje 3. V lo reenvía al servidor W y solo después devuelve a U el voucher en el mensaje 4.
  • El propio borrador advierte que U revela su identidad a un V autenticado antes de saber si la autorización culminará. Como mitigación, permite utilizar una identidad exclusiva para la incorporación.
  • Daniel Kade propone registrar por separado la autenticación, la decisión de W y la eliminación de la identidad provisional. No es una exigencia del borrador.

La convocatoria pública pide apoyo, objeciones razonadas y soluciones antes del 22 de septiembre. El historial de Datatracker confirma que el 8 de septiembre el texto pasó de documento de trabajo a In WG Last Call. La ficha del documento mantiene la revisión 08 como borrador activo con destino Proposed Standard. Ni el inicio de la consulta ni unas muestras de apoyo equivalen a aprobación del IESG o publicación como RFC.

ELA significa Lightweight Authorization using EDHOC. Su diseño intenta ahorrar viajes en el tramo más estrecho. El dispositivo U y el autenticador de dominio V ejecutan EDHOC, mientras el servidor de inscripción W aporta por la red menos restringida la información que permite decidir la entrada. La autenticación y la autorización se solapan en vez de formar dos ceremonias consecutivas.

Hay tres autoridades, no una. La revisión 08 parte de que U ya tiene la clave pública y la ubicación de W. V y W confían mediante una relación implícita, como la PKI web. U y V pueden carecer de relación previa. ELA usa los dos vínculos existentes para constituir el tercero.

Lo que ya sabe V cuando pregunta a W

U recibe en el mensaje 2 la credencial con la que V prueba su clave. En el mensaje 3, U incorpora ID_CRED_I, que identifica su propia credencial, junto con datos externos de autorización. Estos incluyen la ubicación de W y material efímero con el que se protegerá el voucher.

V no decide aislado. Construye una petición para W con el identificador de U, la suite criptográfica, H_12 como huella de los dos primeros mensajes, el material efímero y un indicador sobre si necesita que W devuelva la credencial completa de U. W vincula H_12 al identificador, busca la política de incorporación y la aplica. Puede negar el acceso o devolver la credencial y un voucher.

El voucher habla a U sobre V: afirma que W ha autorizado al autenticador. Está ligado a la sesión actual, a ID_CRED_I y a la credencial de V. Si lleva un alcance opaco, U y W lo entienden, mientras V solo lo transporta. El resultado llega en el mensaje 4. RFC 9528 define ese mensaje como opcional en EDHOC normal; ELA lo vuelve obligatorio porque contiene el voucher.

El borrador solo da por autorizados a U y V para interactuar después de procesar el cuarto mensaje. Antes, U ya había autenticado la clave de V, pero todavía no había recibido la autorización que W concede a V. Y su propio identificador ya había cruzado tanto V como W. La secuencia demuestra por qué «autenticado» y «autorizado» no son etiquetas intercambiables.

La protección frente a terceros no borra la revelación al interlocutor

EDHOC ofrece protección de identidad, secreto hacia adelante y autenticación mutua. Nada de lo anterior sostiene que el identificador circule a la vista de cualquiera. V debe estar autenticado y los canales están protegidos. La observación más precisa aparece en las consideraciones de seguridad de ELA: U revela su identidad a ese V autenticado antes de conocer el desenlace de la autorización.

El texto permite que U presente una identidad solo válida durante la incorporación y adopte otra para las comunicaciones operativas bajo el canal ya creado. No es un detalle cosmético. Reduce lo que puede vincularse si W deniega la entrada o si el dispositivo acudió al autenticador equivocado. Sin embargo, el borrador no fija la política de conservación de V y W ni define el registro que demuestre que la identidad provisional dejó de usarse.

La palabra voucher no debe ocultar las diferencias entre estándares. RFC 8366 especifica un artefacto firmado por el fabricante para asignar un dispositivo a un propietario y fijar una credencial de dominio. ELA adopta una función semejante en formato más compacto, no ese mismo artefacto. RFC 8995 describe BRSKI y separa roles, auditoría y privacidad entre dispositivo, registrador y servicio del fabricante. RFC 9031 ofrece otro caso de incorporación en redes restringidas. Son antecedentes institucionales; el orden concreto procede de ELA.

Un rechazo contiene más que un fallo

W puede reconocer ID_CRED_I y aun así prohibir la incorporación. La política podría limitar identidades, ventanas horarias o autenticadores aceptables. La interfaz devuelve HTTP 403 o CoAP 4.03. Además, W puede cifrar para U una indicación accionable—por ejemplo, otro V que convenga intentar—y V la reenvía dentro de un error EDHOC Access denied.

Para operaciones, esa ruta no debería quedar reducida a «conexión fallida». Hay una diferencia entre política denegada, credencial de U ausente, voucher inválido, servidor W lento y autenticador incorrecto. También hay una diferencia entre un intento que nunca divulgó una identidad y otro en el que W ya la evaluó. Sin la etapa exacta, las métricas no sirven para seguridad ni para privacidad.

Las actas de LAKE en IETF 126 registran que el diseño conserva claves efímeras distintas para EDHOC y ELA, que hubo algunas señales favorables a la consulta y que las presidencias seguirían adelante. El grupo LAKE debe ahora juzgar la propuesta común. Cada operador tendrá que gobernar la memoria local que queda fuera del protocolo.

Un recibo limitado por diseño

Un recibo de incorporación puede explicar el proceso sin conservar el identificador bruto. Bastan un asa unidireccional por intento, la huella de la credencial de V, la versión del ancla y del punto de conexión de W, H_12, la versión de política, la clase de identidad usada y un resultado acotado: voucher aceptado, política denegada, redirección, fallo de verificación o expiración.

Cuando el dispositivo sustituya su identidad de incorporación por la operativa, el sistema debería atestiguar el cambio sin crear un mapa exportable entre ambas. El plazo de retención y el resultado de la eliminación son parte del control. No lo son la credencial completa, el secreto del voucher ni una clave que permita seguir al equipo entre dominios.

Este recibo es una propuesta editorial de Daniel Kade. ELA deja la política de autorización fuera de alcance y no impone esta estructura. Precisamente por eso el despliegue necesita evitar que la brevedad de la red se convierta en ambigüedad del registro.

Fuentes