Resumen

  • Una CoA-Request o Disconnect-Request autenticada demuestra que un salto RADIUS aceptado envió el mensaje. No demuestra que pueda actuar por ese tenant, que los selectores identifiquen una sola sesión actual ni que el NAS pueda realizar el cambio.
  • La evidencia útil enlaza acceso y accounting originales con proxy, realm, NAS, clave de sesión, atributos solicitados, identidad de reenvío, ACK o NAK, estado instalado y tráfico. RADIUS/1.1 protege mejor el transporte, pero no decide esos enlaces.

El nombre de usuario no resuelve el caso

El escenario inicial es una prueba operativa, no un incidente real. Una persona mantiene un portátil conectado en la oficina y un teléfono en una red visitada. Ambos registros contienen el mismo User-Name; sus Acct-Session-Id, NAS, puntos de acceso y políticas son distintos.

Un motor de riesgo quiere limitar el portátil y manda una CoA-Request válida con el nombre y un filtro. Si el receptor aplica el cambio a las dos sesiones, convierte una búsqueda ambigua en autoridad múltiple. Si elige la más reciente, inventa una preferencia que no llegó en el mensaje. El resultado seguro es rechazar la ambigüedad y conservar la diferencia entre un remitente reconocido y un objeto autorizado.

RFC 5176 define por separado al Dynamic Authorization Client que origina, al Dynamic Authorization Server que recibe, al NAS que presta el servicio y a la sesión como instancia de ese servicio. Un usuario puede sostener varias sesiones a la vez. Por eso una dirección de cliente RADIUS no es una persona, un NAS no es una sesión y una identidad de cuenta no es una conexión única.

CoA y Disconnect tampoco son sustitutos. La primera modifica autorizaciones; la segunda termina la sesión y descarta contexto. Desconectar cuando falla un filtro amplía una decisión reversible hasta convertirla en interrupción y borra datos necesarios para explicar el fallo.

La cardinalidad es una decisión de seguridad

La identificación puede combinar Acct-Session-Id, puerto NAS, direcciones asignadas y datos de las estaciones. User-Name o Chargeable-User-Identity ayudan a evitar acciones sobre otra persona, pero no prometen unicidad global.

El sistema debe calcular cuántas sesiones vivas coinciden con el conjunto completo: cero, una o varias. Session Context Not Found y Multiple Session Selection Unsupported no son errores cosméticos; impiden que una búsqueda incompleta termine en una mutación arbitraria.

La procedencia del identificador es igualmente necesaria. Hay que conservar qué NAS lo emitió, para qué tenant o realm, en qué época comenzó y qué atributos de asignación lo acompañaban. Un reinicio o una reutilización pueden dar el mismo valor a otro contexto. La unión con accounting no es un paso auxiliar: determina quién recibe la acción.

Autenticar el salto no autoriza al tenant

En RADIUS histórico, la dirección UDP de origen selecciona el secreto compartido. Un Authenticator correcto vincula el paquete con una relación configurada en ese salto. No prueba quién aprobó la operación, qué clientes puede gobernar el emisor ni si un proxy anterior alteró el contenido antes de proteger el salto siguiente.

RFC 5176 reconoce el peligro cuando varios proveedores comparten un NAS: uno podría cambiar o cerrar sesiones ajenas. Secretos por cliente, filtros de red y comprobación de ruta inversa reducen la exposición. La regla local todavía debe aceptar explícitamente emisor, realm, NAS, tenant, sesión y tipo de cambio.

RFC 8559 organiza el regreso de CoA en roaming mediante Operator-Name y el Operator-NAS-Identifier opaco de la red visitada. La petición se dirige al realm del operador que alberga la sesión, no al realm del nombre del usuario. La red visitada traduce su token al NAS interno y elimina señales reservadas a proxies antes del tramo final.

La cadena sigue siendo hop-by-hop. Cada proxy puede ver y modificar lo que procesa. La auditoría debe registrar los intermediarios y la delegación de cada tramo, sin fingir una firma inmutable desde el administrador remoto hasta el NAS.

Una sesión única puede recibir una orden imposible

Después de identificar el objetivo, el NAS debe evaluar cada atributo. Un filtro, VLAN, rate limit o acción de proveedor puede no existir en ese dispositivo, no ser aplicable al acceso o estar prohibido para ese tenant. RFC 5176 exige que el receptor final rechace el conjunto si no puede cumplirlo, en vez de afirmar un éxito parcial.

Un atributo específico de proveedor no debe ser selector y acción al mismo tiempo. La pregunta «¿a quién?» tiene que cerrarse antes de «¿qué cambia?». Algunas modificaciones necesitan renegociación de capas inferiores; que el controlador pueda codificarlas no da esa capacidad al software desplegado.

El código en ejecución delimita la compatibilidad real. Un catálogo central puede documentar una función observada, pero no declarar que todos los NAS la poseen.

Reintentar no crea una segunda voluntad

Sobre UDP, una retransmisión sin cambios al mismo servidor mantiene puerto de origen, Identifier y Request Authenticator. Si cambian los atributos, nace otra identidad de petición. El receptor necesita recordar duplicados durante el intervalo de aceptación.

Sin protección IPsec contra replay, Event-Timestamp limita la frescura. No se actualiza al retransmitir. La ventana temporal y la memoria de duplicados deben coincidir; de otro modo, una petición antigua todavía fresca puede ejecutarse de nuevo después de olvidar su primera aplicación.

El timestamp no representa una aprobación humana ni confirma que el contexto actual sea el original. Una respuesta guardada también puede producir dos ACK para una sola ejecución. Las métricas deben separar primera petición, retry, duplicado suprimido, respuesta de cache y decisión posterior independiente.

RADIUS/1.1 no selecciona usuarios

RFC 9765 usa ALPN radius/1.1 y requiere TLS 1.3 o posterior. Una negociación correcta entrega a TLS autenticación de conexión, integridad y confidencialidad. Los cálculos históricos de Request y Response Authenticator dejan de usarse, y Message-Authenticator pierde esa función en este modo.

Un Token de cuatro octetos relaciona petición y respuesta. Cada paquete nuevo en la conexión obtiene otro valor; una retransmisión DTLS idéntica conserva el suyo. La deduplicación se limita a la conexión.

La mejora elimina una dependencia criptográfica histórica, pero mantiene los códigos CoA y Disconnect y el sentido de la mayoría de los atributos. No decide el tenant, la cardinalidad ni el efecto. Conviene mantener un registro de transporte —certificado, ALPN, TLS, conexión y Token— y otro de autorización —realm, NAS, sesión, acción, decisión y resultado—.

La respuesta debe llegar hasta el estado ejecutado

CoA-ACK es la afirmación del NAS de que cambió la autorización. CoA-NAK y Error-Cause clasifican el rechazo. Después hay que verificar filtro o VLAN instalados, rate policy, continuidad de accounting y tráfico representativo.

ACK sin cambio es un defecto de enforcement. Cambio sin respuesta es un defecto de observación del transporte. NAK con mutación parcial es un defecto de atomicidad. Una alarma genérica pierde esa diferencia.

La cadena mínima conserva el evento de acceso, accounting, inventario vivo, remitente y proxies, fingerprint de la petición, Identifier o Token, timestamp, cardinalidad, capacidad local, respuesta, estado instalado, paquetes y reversión acotada.

Ensayar dos sesiones deliberadamente parecidas

Crear dos sesiones simultáneas que compartan un identificador atractivo y mantengan distintos Acct-Session-Id y contextos NAS. Una CoA estrecha debe cambiar exactamente una y dejar la otra intacta. Luego retirar el dato distintivo: la petición debe ser rechazada, no resuelta por orden de base o por antigüedad.

Repetir el paquete no debe repetir el efecto. Probar además timestamp vencido, realm no autorizado, NAS erróneo y acción no soportada. El rollback restaura el estado anterior con el mismo alcance; Disconnect solo es reversión si la decisión aprobada era terminar la sesión.

Fuentes