Resumen

  • Un proxy podía añadir un solo Proxy-State propio detrás de los anteriores. Al recibir la respuesta, retiraba el suyo y dejaba que los demás regresaran a quienes los habían creado.
  • Los valores ajenos debían conservarse sin interpretar su contenido privado. La regla fijaba su orden relativo, no una posición obligatoria al final del paquete.
  • Devolver correctamente un estado no demostraba que toda la cadena fuera fiable. Las políticas locales, la autenticación entre vecinos y la protección de cada transporte tenían límites diferentes.

El trabajo empezaba antes de devolver la respuesta

Imaginemos dos intermediarios entre un equipo de acceso y el servidor encargado de resolver una petición. Cada uno añade un Proxy-State. Cuando la respuesta vuelve, el segundo intermediario no elimina todas las marcas para «limpiar» el paquete. Retira únicamente la suya. La del primero todavía tiene un destinatario y una función pendientes.

El RFC 2865, publicado en junio de 2000, describe una operación más precisa que copiar una respuesta hacia atrás. El proxy comprueba el autenticador de la respuesta recibida de su vecino remoto. Si no es válido, descarta el paquete. Si lo es, retira el último Proxy-State cuando él había añadido uno, restablece el Identifier correspondiente a la petición anterior y calcula el autenticador para el siguiente tramo de regreso.

Ese último valor es el suyo porque al incorporarlo tuvo que situarlo después de los Proxy-State que ya existían. Los demás no le pertenecen. No necesita conocer su formato privado para dejarlos en el orden correcto y permitir que sus autores los recuperen.

La escena es un ejemplo de las reglas, no la reconstrucción de una incidencia real. Su utilidad consiste en mostrar tres operaciones que suelen confundirse: comprobar al vecino, terminar el trabajo propio y preservar el trabajo ajeno. Ninguna exige que el proxy se convierta en intérprete de todos los estados de la cadena.

Una función que cambiaba según el lado

RADIUS servía para que un servidor de acceso a la red consultara decisiones de autenticación y autorización. En ese intercambio, el cliente RADIUS era el equipo de acceso, no directamente la persona que intentaba conectarse. Un servidor que recibía la petición podía resolverla o reenviarla, por ejemplo según el dominio de autenticación configurado.

Al reenviar, el mismo sistema actuaba como servidor frente al equipo anterior y como cliente frente al posterior. Podía ser destino final para unos dominios y proxy para otros. Varios proxies podían formar una cadena, aunque la especificación advertía de la necesidad de evitar bucles. La existencia de Proxy-State no proporcionaba por sí sola una ruta correcta ni una protección automática contra esos bucles.

El documento informativo RFC 2607, de junio de 1999, examinó esta arquitectura en servicios de itinerancia. Separar el lugar de acceso del lugar donde se conocía al usuario permitía cooperar a distintas organizaciones. También simplificaba relaciones de claves y facilitaba ajustes de capacidades, políticas y contabilidad.

El documento no escondía el precio. Las suposiciones sobre proxies fiables dentro de un dominio administrativo no se trasladaban sin más a entidades independientes. Su advertencia sobre la falta de idoneidad de la solución de entonces para un despliegue amplio en Internet debe leerse junto a su descripción de usos existentes. Una práctica extendida en aquella fecha no era una garantía general de seguridad.

Lo compartido era una obligación, no el significado

Proxy-State ya estaba definido en el RFC 2138, de abril de 1997. El texto de 2000 detalló el comportamiento de los proxies y aclaró la conservación de atributos. No fue la invención repentina de una marca en un protocolo que antes careciera de ella.

La regla permitía añadir como máximo un Proxy-State propio por petición reenviada. No obligaba a añadirlo siempre. Los valores que otros servidores habían incluido debían tratarse como datos opacos: su contenido no podía determinar el funcionamiento del protocolo en el intermediario que los recibía.

El servidor final devolvía los valores recibidos, sin cambios y en el mismo orden, tanto en Access-Accept como en Access-Reject o Access-Challenge. La obligación de devolver no dependía de conceder acceso. Una negativa también tenía que recorrer correctamente el camino de respuesta; una petición de más pruebas tampoco autorizaba a perder el estado de los intermediarios.

Esa simetría no hacía pública la semántica privada de cada valor. La especificación dejaba su uso concreto a la implementación. Un proxy sabía qué debía conservar y cuál podía retirar sin necesitar una definición común de todos los datos que sus vecinos habían decidido guardar allí.

«Después» no quería decir «al final de todo»

El orden era importante, pero había que medirlo en el conjunto adecuado. Los atributos de un mismo tipo conservaban su secuencia. Los de tipos diferentes no tenían que mantener una posición fija entre sí. Tampoco podía exigirse que todas las apariciones del mismo tipo fueran contiguas.

Por ello, entre dos Proxy-State podía aparecer otro atributo. Después del último Proxy-State podía haber un atributo distinto. La imagen de una pila resulta útil para explicar quién retira primero su propia marca, siempre que no se convierta en una supuesta exigencia de reservar un bloque compacto al final del paquete.

La diferencia parece de implementación, pero tiene efectos de interoperabilidad. Un receptor que solo acepta su orden favorito rechaza variaciones que la regla común permite. El acuerdo no pretendía que todos ordenaran el paquete como un único producto, sino que preservaran las relaciones cuyo orden sí tenía significado.

El estado podía quedarse a mitad de camino

La especificación también permitía no reenviar los Proxy-State anteriores. Un proxy podía conservarlos localmente y adjuntarlos de nuevo a la respuesta antes de devolverla a su cliente. Lo que no podía hacer era omitirlos hacia delante y olvidarse de restaurarlos hacia atrás.

Esta alternativa impide tratar el atributo como una prueba completa del itinerario. Que una marca vuelva no demuestra que haya llegado al servidor final. Que falte en una captura del siguiente enlace tampoco prueba por sí solo una pérdida. La comprobación debe atender al compromiso entre el proxy y su cliente, no a una idea imaginaria de que todos los bytes recorren necesariamente todos los tramos.

La elección trasladaba trabajo. Si el proxy retenía valores, tenía que recordar cuáles devolver. Si los enviaba más lejos, dependía de su retorno según el procedimiento. La norma dejaba espacio para ambas soluciones sin prescribir el almacén interno de ninguna de ellas.

Tres nombres para tres vidas distintas

El registro de atributos de IANA identifica State con el número 24, Class con el 25 y Proxy-State con el 33. Compartir un formato de atributo y cierta opacidad no los convierte en un único identificador universal.

State puede acompañar un desafío de autenticación y regresar en la petición siguiente. Class puede salir en una aceptación y continuar en la contabilidad; la especificación base recomienda conservarlo allí cuando se utiliza ese servicio. Proxy-State, en cambio, corresponde al retorno de un intermediario y es retirado por su autor.

El RFC 5080, de diciembre de 2007, precisa que una autenticación nueva o reiniciada no debe reutilizar el State de la anterior. La coincidencia de usuario y puerto no basta para afirmar que sigue siendo la misma conversación. Tratar todos los campos como «el estado de este usuario» puede mantener una asociación después de que su contexto haya terminado.

En la contabilidad, el documento informativo RFC 2866, de junio de 2000, exige haber recibido y registrado una petición antes de responder con Accounting-Response. No es un simple aviso de llegada a la interfaz de red. Pero un proxy que asume almacenamiento y reenvío puede confirmar bajo una responsabilidad distinta de la de uno que espera la respuesta del destino remoto. No debe ampliarse una confirmación concreta hasta convertirla en prueba de que todas las organizaciones ya poseen el mismo registro.

La opacidad no era una cerradura

Proxy-State contiene una secuencia de octetos cuyo formato concreto es privado. El atributo tiene tipo y longitud; la longitud delimita el dato. Una cadena binaria puede incluir ceros, y no debe truncarse como un texto terminado en cero. Tampoco cabe normalizar su escritura, quitar espacios o modificar mayúsculas como si se tratara de una etiqueta para lectores humanos.

Conservar sin interpretar no equivale a ocultar criptográficamente. Un intermediario puede ver datos que, según las reglas, no debe utilizar como instrucciones propias. El protocolo limita el significado que se comparte; eso no garantiza confidencialidad ni impide físicamente todas las acciones maliciosas.

La misma cautela vale para las políticas. El RFC 2865 permite modificar algunos atributos para aplicar decisiones locales, pero protege los Proxy-State, State y Class existentes. No declara inmutable todo el mensaje. El RFC 2607, además, distinguía entre las decisiones permitidas y lo que un proxy malicioso podía hacer al manipular respuestas. Una prohibición y un mecanismo que impide infringirla son cosas diferentes.

Cambiar el transporte no eliminó al intermediario

El RFC 6614, experimental y publicado en mayo de 2012, añadió transporte sobre TLS sin eliminar el tratamiento de mensajes por los proxies. El RFC 9765, también experimental, definió en abril de 2025 RADIUS/1.1 para conexiones TLS y DTLS, retirando en ese perfil los antiguos mecanismos de paquete basados en MD5 y secretos compartidos.

Se trata de evolución histórica, no de una recomendación de utilizar hoy la autenticación antigua. Tampoco demuestra que todas las instalaciones hayan adoptado el perfil nuevo. Un proxy puede negociar de forma independiente la conexión de cada lado. El tramo protegido no certifica automáticamente la protección del siguiente ni la conservación de cada decisión tomada antes.

La lección de Proxy-State es más limitada y, por ello, más útil. Los participantes podían compartir obligaciones exactas sobre datos cuyo significado seguía siendo local. Retirar la marca propia, devolver la ajena y no atribuirse su interpretación hacía posible cooperar sin fingir que todos los intermediarios eran una sola máquina o una sola autoridad.