Resumen

  • El servidor de autorización de ACE permite que un Cliente solicite acceso a un recurso de membresía; el KDC todavía debe validar el Join y entregar el material definido por el perfil de aplicación.
  • Token emitido, miembro registrado, versión instalada y comunicación efectiva son afirmaciones distintas; ninguna debe heredarse automáticamente de la anterior.

La palabra «autorizado» suele viajar demasiado lejos. Un sistema la emite al aprobar una política y otro la reutiliza para afirmar que un dispositivo pertenece al grupo, posee las claves vigentes y puede comunicarse. RFC 9594 impide leer así el proceso.

Su arquitectura contiene dos fases. Primero, el Cliente obtiene del Authorization Server un token que le permite acceder a uno o varios recursos de membresía en el KDC. Después, fuera de esa decisión inicial, el KDC realiza la distribución efectiva de claves. El Cliente no se convierte en miembro por llevar un token; se convierte en miembro cuando el intercambio Join termina con éxito.

La política decide quién puede llamar

El Authorization Server evalúa el grupo y los roles solicitados. El Cliente transfiere el token al KDC, normalmente mediante /authz-info, y establece la asociación segura exigida por el perfil de transporte ACE. RFC 9202 y RFC 9203 ofrecen, respectivamente, perfiles basados en DTLS y OSCORE.

Ese trabajo prepara el acceso. El Join ocurre al enviar una solicitud a /ace-group/GROUPNAME. El KDC contrasta grupo, alcance y roles con el token almacenado, verifica los elementos que correspondan al perfil y decide si crea la membresía. La respuesta exitosa incorpora al Cliente al conjunto actual y devuelve el material de grupo, además de información individual, credenciales, políticas o pruebas cuando sean aplicables.

Por tanto, el token no certifica recepción, canal vigente, solicitud Join, aceptación, asignación de nombre, prueba de posesión ni instalación local. Es evidencia de una decisión concreta tomada por la autoridad que la observó. Convertirlo en una membresía completa no simplifica el sistema: elimina los fallos que todavía pueden ocurrir.

La ruta permanece; el estado gira

GROUPNAME identifica un recurso de membresía y permanece invariante una vez establecido. El nombre del nodo y NODENAME también son estables y deben ser únicos entre los miembros actuales. Estos identificadores permiten administrar el grupo sin cambiar las rutas con cada renovación.

La criptografía tiene otro ritmo. El parámetro num identifica la versión del material de claves vigente. Los identificadores de grupo, el material individual, las credenciales y las políticas se interpretan dentro del perfil y de esa versión. Dos Clientes pueden nombrar el mismo grupo y, temporalmente, no disponer del mismo estado utilizable.

El erratum 8239 del RFC Editor corrige un ejemplo de recuperación de credenciales que omitía el num obligatorio. El erratum 8864 aclara filtros de credenciales mal formados. Ambos figuraban como reportados durante esta investigación. No demuestran una vulnerabilidad de producto, pero recuerdan una regla de prueba: una credencial sin la versión con la que debe usarse no basta para reconstruir el estado.

El perfil de aplicación es parte de la afirmación

RFC 9594 no congela una única tecnología de seguridad grupal. Define recursos del KDC, operaciones comunes, mapas CBOR, códigos de error, el tipo application/ace-groupcomm+cbor y registros extensibles. Luego obliga al perfil de aplicación a concretar lo que falta.

El perfil debe describir tipos y formatos de claves, identificadores, credenciales, métodos de prueba de posesión, políticas, protección del rekeying, recursos soportados y capacidades del Cliente. El valor de ace_groupcomm_profile permite identificar esa especialización. No la ejecuta.

Por eso una auditoría no debería aceptar «soporta RFC 9594» como descripción suficiente. Debe preguntar qué perfil, qué parámetros, qué operaciones primarias y secundarias, qué material se instala y qué comprobaciones se realizan. La especificación inicial mínima es valiosa porque separa lo común de lo especializado; pierde su disciplina cuando una etiqueta oculta esa separación.

El nuevo número no llega a todos a la vez

El KDC renueva material cuando expira y puede hacerlo periódicamente. Según las políticas o el perfil, una entrada puede exigir seguridad hacia atrás y una salida o expulsión puede exigir seguridad hacia delante. El KDC incrementa NUM y distribuye NUM+1 mediante uno o varios mensajes.

RFC 9594 reconoce la desalineación temporal. Algunos miembros reciben la nueva versión antes que otros. La finalización del rekeying permite borrar el material antiguo y conservar el nuevo, pero un cambio en la base de datos del KDC no prueba por sí solo la instalación colectiva.

El artículo previo sobre RFC 9838 conserva su tesis específica sobre la secuencia KEK–TEK necesaria para la exclusión. Aquí no se repite. El punto propio de RFC 9594 es que la interfaz general separa número asignado, distribución y activación local. Cualquier tablero que pase directamente de NUM+1 en el KDC a «grupo convergido» omite la parte distribuida del problema.

El Dispatcher no gobierna la membresía

El Dispatcher entrega mensajes uno-a-muchos. Puede ser implícito en multicast o explícito como broker o relé. Cuando es explícito, el RFC lo compara con un intermediario no confiable en ruta: ve mensajes protegidos, pero no posee el material de claves y no lee el contenido claro.

Esa posición no lo convierte en autoridad. Puede observar un reenvío sin verificar el plaintext, alcanzar destinos que conservan versiones distintas o perder una entrega aunque la membresía sea correcta. La pregunta de si un mensaje protegido produjo una acción pertenece al límite ya estudiado para RFC 10020. La pregunta de este informe es anterior: ¿qué prueba el salto desde permiso hasta miembro y desde miembro hasta estado instalado?

Auditar transiciones sin auditar secretos

Conserve el identificador o hash del token, emisor, audiencia, alcance, roles y vencimiento; transferencia al KDC; perfil de transporte; identidad de la asociación; solicitud Join; grupo; nombre de nodo; perfil de aplicación; num; validaciones de credenciales y posesión; resultado de instalación; versiones de políticas; inicio y fin de rekeying; recuperación; y último uso confirmado. No registre las claves.

La custodia debe seguir a la observación. El AS responde por su decisión, el KDC por la admisión y distribución, el Cliente por la instalación, el Dispatcher por el transporte y la aplicación por el efecto. Esta cadena aplica las capas de realidad de Lu Heng: el documento más solemne no crea automáticamente el estado de ejecución que viene después.

Fuentes