Resumen

  • En ELA, W decide si U puede incorporarse mediante V; V demuestra ante W el control del mismo CRED_V presentado a U, y el vale queda ligado a H_12, ID_CRED_I y esa credencial.
  • U entrega una identidad de incorporación a un V autenticado antes de saber si W aprobará el proceso. Un rechazo impide continuar, pero no determina la retención, correlación o eliminación de esa identidad.
  • Un recibo de liberación de identidad puede documentar propósito, receptores, plazo, tratamiento de la denegación y activación de una identidad operativa distinta. Es una propuesta de Daniel Kade, no parte del borrador.

Tres participantes y una decisión tardía

El borrador draft-ietf-lake-authz-08 describe Lightweight Authorization using EDHOC. El 8 de septiembre de 2026 pasó a última llamada del grupo de trabajo LAKE; la revisión 08 había sido publicada el 6 de julio. Sigue siendo un Internet-Draft con estándar propuesto como destino, no un RFC aprobado.

Su diseño responde a una limitación real. El dispositivo U llega a un dominio cuyo autenticador es V, pero la confianza previa de U reside en un servidor de incorporación W. U conoce la clave pública estática PK_W y la ubicación LOC_W. W puede pertenecer al fabricante o a otra entidad fiable; V puede ser un proveedor de servicio u otro controlador de red.

U inicia EDHOC y utiliza ID_CRED_I de forma que W pueda reconocerlo sin ambigüedad. V recibe esa identidad y la lleva a W mediante una sesión protegida. Al mismo tiempo, V usa ante W el mismo CRED_V mostrado a U y demuestra su posesión o vínculo criptográfico. W consulta una política local —cuya definición queda fuera del borrador— y decide si U puede incorporarse por medio de V.

Si el resultado es favorable, U recibe un vale: la afirmación de W de que ha autorizado a V. El artefacto se vincula con la transcripción mediante H_12, con U mediante ID_CRED_I y con V mediante CRED_V; también puede contener un alcance opaco. Sin intercambio satisfactorio con W no se continúa, y llegar al mensaje_4 señala que U y V están autorizados a interactuar.

La economía de mensajes es importante para enlaces restringidos. La autorización avanza en paralelo a la autenticación. Pero esa eficiencia fija el orden de la revelación: V aprende la identidad antes de que U conozca la decisión de W.

Autenticado no significa autorizado para conservar

Las consideraciones de seguridad no ocultan el coste. EDHOC protege la identidad del iniciador ante observadores pasivos y pares no autenticados según su modelo. ELA la revela deliberadamente a un V autenticado antes de confirmar la autorización.

Autenticar a V responde quién controla una clave. Autorizar a V responde si W permite esta relación con U en esta sesión. Ninguna respuesta concede automáticamente a la organización que opera V un derecho ilimitado sobre los datos recibidos. Tampoco prueba que la política de W sea legítima, vigente o corregible.

La vinculación de sesión impide trasladar un vale a otro intercambio. No fija cuánto dura un registro de acceso. La identidad inequívoca ayuda a W a localizar una política. No prohíbe que se una el intento con un expediente de fabricante. Un mensaje de error cifrado puede indicar autenticadores alternativos y seguir ligado a H_12; no acredita que el primer V haya borrado la identidad.

Estas lagunas no demuestran abuso alguno. Las fuentes no describen una implantación concreta ni una práctica de datos. Señalan una división de trabajo: el protocolo define autenticación y autorización; las instituciones deben definir finalidad, conservación y recurso.

La identidad temporal puede convertirse en historial

ELA permite que U use una identidad sólo para incorporación y otra distinta durante la operación. Es una mitigación valiosa. Limita la posibilidad de enlazar el tráfico normal con la credencial presentada al entrar.

Sin embargo, es una posibilidad, no una obligación. El texto no prescribe rotación por dominio, caducidad ni eliminación. Una identidad “sólo de incorporación” puede repetirse en redes distintas, permanecer en registros de denegaciones o quedar asociada a la cuenta operativa. Su etiqueta funcional no limita su vida material.

Por eso hacen falta dos cierres. Antes de revelar ID_CRED_I, el dispositivo necesita una promesa verificable sobre la clase de V, el W consultado, el propósito y los destinatarios. Después de una aprobación necesita constancia de que la identidad operativa se activó y la anterior dejó de otorgar capacidad. Tras una denegación necesita una disposición: borrado, token limitado para frenar abusos o cuarentena auditada hasta una fecha.

La minimización no exige publicar el identificador. Huellas criptográficas, referencias seudónimas a la sesión, versiones de política y clases de motivo pueden sostener una auditoría sin construir otra base de seguimiento.

Un recibo distinto del vale

El recibo de liberación de identidad no compite con el vale. El vale demuestra el resultado de W; el recibo conserva las condiciones bajo las que se entregó información para obtenerlo.

Primero registra la configuración de confianza: versión del ancla de U, identidad y ubicación de W, huella de CRED_V, clase y regla de rotación de la identidad de incorporación, y referencia protegida a H_12. Después fija la política: identificador y versión, dominio solicitado, propósito, receptores permitidos, fecha límite y regla de transferencia ulterior.

La sección de resultado separa aprobación, denegación, espera y error. Si hubo vale, guarda alcance y expiración. Si hubo rechazo, nombra una categoría de causa y la acción requerida sobre los datos. Si hubo éxito, fecha el cambio a la identidad operativa. Un canal de corrección permite revisar una política desactualizada sin reescribir el intento original.

No es necesario añadir mensajes al enlace limitado. V o W pueden custodiar el recibo y entregar a U una referencia compacta. Su función es impedir que “sesión abortada” se convierta en sinónimo administrativo de “dato eliminado”.

La disponibilidad también decide sobre identidad

W debe estar disponible durante el proceso. Esa presencia permite una autorización actual, pero crea dependencia. Si W no responde, denegar conserva el modelo y bloquea el alta; esperar crea una cola de solicitudes con identidad; admitir sin consulta cambia el fundamento de confianza.

Cada alternativa tiene un dueño y una duración que conviene declarar. Una recuperación no debería volcar silenciosamente intentos antiguos a una política nueva. Una caché de autorización no debería sobrevivir sin indicar su versión. Un cambio de LOC_W o PK_W no debería parecer simple mantenimiento cuando altera el destinatario o la raíz de decisión.

La fortaleza de ELA consiste en atar participantes y transcripción. Su límite legítimo consiste en no fingir que ese lazo es una ley de protección de datos. RFC 9528 deja a las aplicaciones la confianza en credenciales; BRSKI y los vales de RFC 8366 también separan el artefacto firmado del gobierno de las anclas y del dominio.

El vale puede decir a U que W autorizó a V. No puede decir que la revelación previa tuvo la finalidad correcta, que un rechazo no dejó rastro o que la identidad operativa será independiente en la práctica. Para eso hace falta un compromiso institucional observable.

Fuentes