Resumen

  • El Identifier de RADIUS sólo ayuda a localizar una petición pendiente. La respuesta debe validar además un Response Authenticator calculado con el Request Authenticator de 16 octetos de esa petición y el secreto del salto.
  • Reenviar sin cambios al mismo servidor conserva Identifier, Request Authenticator y puerto de origen. El servidor reconoce el duplicado y repite la respuesta guardada; cambiar cualquier atributo crea una petición nueva.

Una conversación podía contener muchas transacciones

RADIUS nació para que un equipo de acceso consultara a un servidor antes de prestar servicio a un usuario. Su primer RFC, RFC 2058, apareció en enero de 1997; RFC 2138 lo sustituyó en abril, y RFC 2865 consolidó el protocolo clásico en 2000.

El encabezado reservó un solo octeto al Identifier. Con 256 valores no era posible fabricar una etiqueta eterna para cada autenticación, y tampoco hacía falta. El cliente necesitaba distinguir las peticiones que seguían esperando una respuesta en un contexto de dirección y puerto concreto.

RFC 5080 lo expresa como disciplina de reutilización: un cliente no vuelve a usar el Identifier para la misma dirección y puerto de origen hasta recibir una respuesta válida o agotar la petición. Conviene repartir valores con una política de menos recientemente usado. El número no adquiere significado fuera de esa ventana.

Por eso una conversación de Challenge puede conservar State y, al mismo tiempo, producir una serie de transacciones distintas. State conserva contexto de aplicación; el Identifier sólo nombra provisionalmente una pregunta en vuelo.

La parte larga no era un segundo número decorativo

Todo Access-Request lleva un Request Authenticator de 16 octetos. Debe cambiar cuando se estrena Identifier y debería ser impredecible y único durante la vida del secreto compartido. Una repetición bajo el mismo secreto puede devolver utilidad a una respuesta capturada; una secuencia predecible facilita preparar una respuesta falsa para una petición futura.

Access-Accept, Access-Reject y Access-Challenge copian el Identifier recibido. Sin embargo, su Response Authenticator incorpora el Code, el Identifier, la longitud, los atributos de respuesta, el Request Authenticator original y el secreto compartido.

El cliente no acepta una respuesta por coincidir el octeto. Primero localiza una petición todavía pendiente y después recalcula el autenticador con los 16 octetos de esa pregunta exacta. Si el paquete pertenece a un uso anterior del mismo Identifier, la comprobación falla.

El mecanismo repartió la autoridad entre elementos pequeños. El Identifier reduce la búsqueda; el Request Authenticator vincula pregunta y respuesta; el secreto autentica al vecino de ese salto; la tabla de pendientes determina si la pregunta sigue abierta. Convertir cualquiera de ellos en una identidad aislada destruye la composición.

Un segundo datagrama no era necesariamente un segundo intento

RADIUS clásico usó UDP. La decisión tenía que llegar pronto: esperar varios minutos a que un transporte fiable entregara datos antiguos no ayudaba al usuario. El cliente guardaba la petición por encima del transporte, manejaba temporizadores y podía volver a enviarla o consultar un servidor alternativo.

Para el mismo servidor, una retransmisión con atributos idénticos debe mantener Identifier, Request Authenticator y puerto de origen. La continuidad en la red representa una continuidad lógica: no se pide una decisión nueva, se intenta entregar otra vez la misma pregunta.

Modificar un atributo rompe esa identidad. Una respuesta de contraseña distinta, un Event-Timestamp añadido o un servicio solicitado diferente exige nuevos valores. No importa que el operador lo llame “reintento del mismo usuario”. El servidor recibe otra afirmación y puede llegar legítimamente a otra conclusión.

La norma impide que la intención supuesta reemplace los bytes observables. Esa precisión sería esencial al tratar duplicados.

La caché evitaba repetir efectos, no sólo cálculos

RFC 5080 obliga a los servidores a detectar Access-Request duplicados y guardar temporalmente el Access-Accept, Access-Reject o Access-Challenge ya emitido. Si vuelve el mismo paquete después de responder, el servidor reenvía la respuesta original sin procesar de nuevo la autenticación. Si el duplicado llega mientras la primera petición sigue en curso, se descarta en silencio.

No es una optimización cosmética. La evaluación puede consultar un directorio, incrementar contadores, registrar un acceso, consumir un valor de un solo uso o activar trabajo costoso. Repetirla porque se perdió una respuesta convierte un fallo de transporte en un segundo efecto.

La entrada de caché se reconoce por dirección y puerto de origen, socket receptor, Identifier y Request Authenticator. Suele conservarse entre cinco y treinta segundos. Un paquete que coincide en los cuatro primeros elementos pero cambia los 16 octetos invalida la entrada antigua: no es el duplicado que aparenta ser.

La respuesta guardada tampoco se transforma en una decisión permanente. Sólo cubre el intervalo durante el que un cliente razonable aún podría estar reenviando aquella pregunta.

Cambiar la petición cerraba el turno de la respuesta anterior

Una petición puede seguir ejecutándose en el primer servidor cuando el cliente decide formular otra con atributos distintos. La respuesta antigua, si llega, puede validar perfectamente contra el Request Authenticator anterior. Aun así, ya no responde a la transacción corriente.

El cliente procesa la primera respuesta válida para una petición que continúa pendiente. Cuando la petición se cierra, las respuestas posteriores son no solicitadas y se eliminan. Validez criptográfica sin vigencia transaccional no basta.

Access-Challenge vuelve visible el límite. El NAS presenta el mensaje al usuario, recoge otra contestación y envía un Access-Request nuevo. Usa Identifier y Request Authenticator nuevos e incluye State cuando el servidor lo proporcionó. Así puede mantenerse el hilo de autenticación sin confundir los turnos.

Si servidores alternativos conservan políticas o datos diferentes, pueden emitir respuestas incompatibles. La primera válida cierra la petición en el cliente; RADIUS no exime al operador de sincronizar reglas, usuarios y State.

La aceptación todavía dependía del ejecutor local

Un Access-Accept auténtico no garantiza que el NAS pueda aplicar sus atributos. RFC 2865 ordena tratar como rechazo una respuesta que pida un servicio imposible de suministrar.

Esta disposición coloca la ejecución donde existe la capacidad. El servidor expresa una decisión; el equipo de acceso conoce su puerto, protocolo, VLAN, ruta y estado real. El Response Authenticator demuestra, según la construcción histórica, qué vecino respondió a qué pregunta. No prueba que el servicio se materializara.

Tampoco autentica por sí solo a la persona. PAP, CHAP, EAP u otro método y la política del servidor sostienen esa afirmación. El paquete no convierte una comprobación de salto en identidad humana, intención o derecho contractual.

El proxy hacía de frontera, no de tubo transparente

Al reenviar RADIUS, un proxy verifica el Response Authenticator del servidor remoto con el secreto de ese salto. Después elimina su último Proxy-State, recupera el Identifier esperado por el cliente anterior y firma una respuesta nueva con el secreto compartido hacia arriba.

La prueba termina y vuelve a empezar en cada vecino. El NAS no recibe una firma de extremo a extremo del servidor de origen. Proxy-State permite regresar por la cadena y debe permanecer opaco para quien no lo creó, pero no concede acceso.

Un registro que sólo guarde “42, Accept” no puede decir qué salto decidió, qué pregunta seguía pendiente o si se reutilizó el número. La evidencia útil incluye extremos y sockets, huella protegida del Request Authenticator, intervalo, forma de la petición, acción de caché, recorrido de proxy y efecto local. Las credenciales y el secreto no deben exponerse para conseguir esa observabilidad.

La fiabilidad podía convertirse en congestión coordinada

RFC 5080 documentó clientes con intervalos fijos de un segundo o menos y sin retroceso. Tras una avería común, miles de NAS podían iniciar y retransmitir al mismo compás, saturando el servicio que necesitaban para recuperarse.

La recomendación combina plazo inicial, crecimiento exponencial, variación aleatoria y límites de intervalo, cantidad y duración. La variación rompe la sincronización y no necesita calidad criptográfica. La impredecibilidad del Request Authenticator sí responde a ataques. Usar el mismo generador débil para ambos por llamarlos “aleatorios” sería un error de diseño.

Durante una sobrecarga, priorizar peticiones con State válido ayuda a terminar conversaciones ya iniciadas. Un proxy puede atender respuestas antes que nuevas solicitudes. Son decisiones para reducir trabajo perdido, no declaraciones sobre quién merece la red.

TLS cambió después la ubicación de la confianza

RFC 6614 llevó RADIUS a TLS sobre TCP en 2012, pero mantuvo dentro del túnel los cálculos MD5 del paquete y el secreto fijo radsec. La protección del transporte convivió con la maquinaria clásica.

RFC 9765, en 2025, define RADIUS/1.1 para una conexión que lo negocia explícitamente mediante ALPN y TLS 1.3 o posterior. En ese salto desaparecen el secreto RADIUS y los cálculos MD5; el espacio de 16 octetos se convierte en Token opaco y sustituye la función de correlación del Identifier.

Ese es el límite con el artículo ya publicado sobre RADIUS/1.1. El perfil no cambia RADIUS/UDP ni actualiza una cadena completa porque uno de sus saltos lo use. Para esta historia demuestra algo más estrecho: mover autenticidad y confidencialidad al transporte no elimina la necesidad de identificar con precisión una pregunta pendiente.

La lección no es rehabilitar MD5

El Response Authenticator clásico pertenece a su época y no convierte MD5 en una elección moderna. No acredita la corrección de la política, el compromiso de la contabilidad, la honestidad de todos los proxies ni la entrega de tráfico. Los RFC prueban la semántica especificada, no la conformidad de un producto o la cuota de despliegue actual.

Su enseñanza durable está en el alcance de la evidencia. Un nombre pequeño sirve mientras duración, contexto y comprobación permanezcan unidos. El problema comienza cuando un archivo conserva los ocho bits y pierde todo lo que les permitía significar algo.