Resumen

  • El borrador UCL de OPSAWG permite User-Access-Group-ID en Access-Request solo como indicación de preferencia: el servidor no tiene obligación de aceptarla. En Access-Accept, el atributo forma parte de la decisión usada para aplicar control de acceso.
  • Guardar ambos mensajes como una única propiedad grupo borra quién propuso y quién autorizó. Aun la autorización correcta necesita mapeo, ACL, calendario, instalación por PEP y observación del tráfico.

El registro original decía Access-Request. El cliente había incluido User-Access-Group-ID para indicar que prefería entrar en el grupo de respuesta a incidentes. El servidor autenticó al usuario, pero no devolvió ese grupo en Access-Accept.

La plataforma de datos no conservó esa diferencia. Su esquema tenía una columna group_id, una marca temporal y el nombre de usuario. La primera aparición ganó. Un proceso posterior leyó el grupo como autorización vigente y abrió una ruta administrativa.

No fue un fallo criptográfico ni una colisión de identidad. Fue una compresión semántica: el mismo atributo podía viajar en dos tipos de mensaje con autoridad distinta y el sistema eliminó precisamente el dato que distinguía una preferencia de una decisión.

La revisión 15 de A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control define el atributo y el modelo que lo acompaña. Es un documento activo del grupo OPSAWG, destinado a Proposed Standard. Datatracker lo sitúa en la cola del RFC Editor y en revisión final; la revisión de IANA está completada con acciones pendientes. La revisión 15 fue publicada el 2 de abril de 2026 y expira el 4 de octubre. Todavía no es un RFC.

El proyecto también extiende el modelo YANG de ACL de RFC 8519. Añade grupos de usuarios, dispositivos o aplicaciones, referencias a grupos de origen y destino y un horario efectivo para cada ACE. El objetivo es razonable: aplicar políticas a una identidad de grupo aunque cambien las direcciones y coordenadas de transporte.

Pero un dato más estable no crea por sí mismo una autoridad más amplia.

La posición del atributo forma parte del significado

User-Access-Group-ID puede aparecer cero o más veces en Access-Request. Allí es una sugerencia al servidor, una preferencia que puede ignorarse. Puede aparecer cero o más veces en Access-Accept. Si hay varias instancias, el usuario pertenece a varios grupos.

El atributo no debe aparecer en Access-Reject ni Access-Challenge. Tampoco en CoA-ACK o CoA-NACK. Puede aparecer en CoA-Request y Accounting-Request. Esta matriz no es un detalle de transporte que pueda descartarse después de analizar el paquete; es la gramática de autoridad del atributo.

Una base de eventos debería conservar como mínimo emisor, receptor, tipo de mensaje, identificador de intercambio, sesión, instancia del atributo, valor, resultado de autenticación y relación con la respuesta. requested_group y accepted_group no son dos nombres para el mismo campo. Uno expresa una propuesta; el otro registra una decisión situada.

La ausencia también debe tratarse con cuidado. Si el servidor no devuelve el grupo solicitado, no significa necesariamente que haya emitido una denegación explícita de toda pertenencia. Significa que ese Access-Accept no autorizó el valor mediante este atributo. La política local puede tener otras fuentes; esas fuentes deben declararse, no imaginarse.

El sistema del incidente falló porque quería una vista cómoda. Al consolidar mensajes, eligió la última o primera cadena no vacía. Esa regla parece neutral, pero entrega al solicitante la capacidad práctica de rellenar el campo que otro componente interpreta como autorización. La interfaz debe preservar el conflicto y exigir una fuente decisoria reconocida.

Varios grupos no equivalen a un único veredicto

El borrador permite más de una instancia en Access-Accept. Eso representa pertenencia múltiple. Un médico puede pertenecer a personal-clinico y equipo-investigacion; un operador puede ser empleado y respuesta-incidentes; una aplicación puede recibir grupos diferentes por función.

El dato no explica, por sí solo, cómo se resuelven reglas contradictorias. Una ACE puede permitir; otra puede denegar. Una regla puede estar programada; otra ser permanente. Un PEP puede evaluar orden, prioridad o coincidencia de modo específico. El resultado exige la ACL completa y su semántica, no una lista de etiquetas.

Reducir varias pertenencias a grupo_primario es tentador para análisis y facturación. También puede destruir la explicación de una decisión. El registro de aplicación debe conservar el conjunto autorizado, la revisión de política que lo consumió, las reglas candidatas, la precedencia utilizada y la regla que produjo el resultado.

Esto importa especialmente durante un cambio. User-Access-Group-ID puede viajar en una CoA-Request. Un servidor puede retirar un grupo y añadir otro mientras la sesión continúa. El NAS, el controlador y los PEP no cambian en un solo instante lógico. La plataforma necesita una transición con estados parciales, no la edición silenciosa de una propiedad actual.

Del grupo al paquete hay una traducción

El borrador describe dos formas principales de despliegue. Un controlador puede mantener el mapeo dinámico entre Group ID y campos IP o de transporte, como el cinco-tupla, y programar ACL convencionales en los PEP. Alternativamente, el PEP puede entender el grupo y asociar los paquetes a un identificador de origen o destino.

En el primer caso, una decisión de grupo correcta puede convertirse en una regla obsoleta. El usuario cambia de dirección, la aplicación migra o NAPT altera las coordenadas. Si la actualización llega a un PEP y no a otro, ambos pueden declarar que tienen la ACL esperada mientras protegen sujetos diferentes.

En el segundo caso, la clasificación local requiere capacidades de hardware o software y puede afectar el rendimiento. Además, la cadena Group ID no tiene que ser idéntica a la etiqueta presente en el paquete. El documento deja fuera de alcance la correspondencia entre cadena y campo de encapsulación. Por ello, capturar una etiqueta no basta sin conocer la tabla que la interpretaba.

La sección de consistencia exige una preparación adecuada y atención especial cuando conviven mecanismos distintos, RADIUS incluido. Es una obligación operacional, no una garantía automática del modelo.

Una cadena de evidencia debería unir la decisión AAA con una versión de mapeo. Esa versión debería enumerar su fuente, vigencia, tipo de grupo y coordenadas resultantes. Después vendrían la revisión de ACL, el conjunto previsto de PEP, la instalación individual y una lectura posterior. Solo entonces las observaciones de paquetes pueden probar qué regla intervino.

El calendario también autoriza y desautoriza

El módulo YANG añade un horario efectivo a una ACE. Puede ser un período o una recurrencia basada en RFC 9922. Sin horario, la ACE se aplica inmediatamente y siempre.

Esto permite accesos temporales sin clonar políticas enteras. También significa que una autorización válida a las 10:00 puede ser inválida a las 18:00, aunque el Group ID y la ACL no cambien. Para reconstruir una decisión hay que conocer zona horaria, reglas de recurrencia, excepciones, salud del reloj y estado activo en el PEP.

Dos dispositivos con la misma configuración textual pueden activar en momentos distintos por desfase, datos de zona o demora de commit. El control central no debería declarar convergencia solo porque ambos almacenan el mismo documento. Debe observar qué versión está activa y con qué tiempo.

La seguridad del horario va en ambas direcciones. El borrador advierte que una escritura no autorizada puede causar interrupción o indisponibilidad. También señala que leer las ventanas puede ayudar a un atacante a elegir cuándo actuar. Un informe público no necesita revelar el calendario completo para demostrar que existe una verificación interna.

Accounting no es un testigo omnisciente

El atributo puede incluirse en Accounting-Request. El NAS puede usarlo para reconocer que recibió el valor y que está aplicando la política. Esta función es útil para unir autorización, sesión y contabilidad.

Su formulación no convierte al NAS en observador de todos los PEP. Una red puede tener un firewall adicional, una pasarela de servicio y controles en el tejido. El NAS sabe lo que recibió y lo que afirma aplicar en su ámbito. No necesariamente conoce la revisión de mapeo activa en cada dispositivo ni el resultado de una conexión después de abandonar su interfaz.

La contabilidad debe conservarse como afirmación con procedencia. Un auditor puede contrastarla con confirmaciones del controlador, hashes de lectura, contadores de reglas y pruebas del servicio. Si los datos discrepan, la discrepancia es el hallazgo; no debe resolverse eligiendo automáticamente la fuente más cómoda.

Incluso un contador de regla tiene alcance limitado. Demuestra que algunos paquetes coincidieron con una regla. No demuestra que todos los flujos legítimos atravesaran el camino correcto ni que una vía alternativa no eludiera el control. Las pruebas negativas y positivas deben usar puntos de observación declarados.

Un borrador maduro sigue siendo evidencia documental

Datatracker registra cero errores y cero advertencias en la validación YANG. La transición de revisión 14 a 15 incluye mejoras editoriales, aclaraciones y actualización de la referencia de pautas YANG a RFC 9907. Es buena señal sobre la calidad documental.

No es una prueba de interoperabilidad ni de implantación. El borrador no mide latencia de propagación, pérdida por reclasificación o consistencia entre fabricantes. Las opciones de despliegue y sus implicaciones se describen, pero la evaluación del compromiso entre flexibilidad, complejidad y rendimiento queda fuera de alcance.

NETCONF y RESTCONF deben usar transporte seguro y autenticación mutua. NACM permite restringir operaciones. Estas protecciones evitan que cualquiera modifique listas de grupos, coincidencias o calendarios. No dicen si un usuario autenticado aplicó la revisión adecuada a todos los equipos necesarios.

El transporte de RADIUS plantea otra capa. El texto presupone una relación de confianza entre cliente y servidor y menciona IPsec o TLS. El trabajo actual de RADEXT sobre prácticas inseguras y RadSec es relevante, pero también está sujeto a su propio estado documental. Proteger el mensaje impide ciertas alteraciones; no amplía la autoridad semántica de un hint.

El contrato mínimo que faltó

El incidente se habría detenido con una regla pequeña: ninguna ocurrencia de User-Access-Group-ID puede producir una autorización si el registro no identifica el tipo de paquete y la fuente decisoria. Esa regla no exige rediseñar RADIUS. Exige no destruir su significado durante la ingestión.

El contrato completo puede seguir siendo compacto. Identidad y sesión autenticadas. Grupo solicitado, grupos aceptados y autoridad. Versión del mapeo. Revisión de ACL y calendario. Conjunto de PEP y capacidad de cada uno. Estado de distribución, validación, instalación, activación y lectura. Observación del paquete y resultado del servicio. Incertidumbre y divergencias.

La Minimum Initial Specification de Heng Lu ofrece una disciplina adecuada: estandarizar el handoff indispensable y dejar el resto a la decisión local. No hace falta imponer un algoritmo universal de conflictos para impedir que una sugerencia se disfrace de autorización.

La separación de capas de realidad explica el error. El atributo en la solicitud es lenguaje simbólico del cliente. La respuesta del servidor es una decisión de control. El mapeo y la ACL son estado ejecutable. El paquete permitido o rechazado es realidad observada. Copiar la misma cadena entre capas no transfiere automáticamente la autoridad.

Running-Code Primacy exige pruebas incómodas. Solicitar un grupo que el servidor omite. Devolver varios grupos con reglas opuestas. Cambiar la pertenencia mediante CoA mientras un PEP está aislado. Migrar una aplicación antes de actualizar el cinco-tupla. Atravesar una frontera horaria con relojes divergentes. El sistema seguro conserva los estados parciales y rechaza la certeza inventada.

La plataforma inicial quería simplificar el análisis. Acabó concediendo al Access-Request una autoridad que el protocolo no le daba. La lección no es añadir otra etiqueta verde. Es conservar quién dijo qué, en qué mensaje, bajo qué decisión, cómo se proyectó en cada PEP y qué vio finalmente el tráfico.

Sources