Este artículo necesita citas adicionales para su verificación . ( abril de 2015 ) |
Conjunto de protocolos de Internet |
---|
Capa de aplicación |
Capa de transporte |
Capa de Internet |
Capa de enlace |
El servicio de autenticación remota telefónica de usuario ( RADIUS ) es un protocolo de red que proporciona administración centralizada de autenticación, autorización y contabilidad ( AAA ) para los usuarios que se conectan y utilizan un servicio de red. RADIUS fue desarrollado por Livingston Enterprises en 1991 como un protocolo de autenticación y contabilidad de servidor de acceso. Más tarde se incorporó a los estándares IEEE 802 e IETF .
RADIUS es un protocolo cliente/servidor que se ejecuta en la capa de aplicación y puede utilizar TCP o UDP . Los servidores de acceso a la red , que controlan el acceso a una red, suelen contener un componente cliente RADIUS que se comunica con el servidor RADIUS. [1] RADIUS suele ser el back-end de elección para la autenticación 802.1X . [2] Un servidor RADIUS suele ser un proceso en segundo plano que se ejecuta en UNIX o Microsoft Windows . [1]
El ataque Blast-RADIUS rompe RADIUS cuando se ejecuta en un protocolo de transporte no cifrado como UDP. [3]
RADIUS es un protocolo AAA (autenticación, autorización y contabilidad) que administra el acceso a la red. RADIUS utiliza dos tipos de paquetes para administrar todo el proceso AAA: solicitud de acceso, que administra la autenticación y la autorización, y solicitud de contabilidad, que administra la contabilidad. La autenticación y la autorización se definen en RFC 2865, mientras que la contabilidad se describe en RFC 2866.
El usuario o la máquina envían una solicitud a un servidor de acceso a la red (NAS) para obtener acceso a un recurso de red en particular mediante credenciales de acceso. Las credenciales se pasan al dispositivo NAS a través del protocolo de capa de enlace , por ejemplo, el protocolo punto a punto (PPP) en el caso de muchos proveedores de acceso telefónico o DSL , o se publican en un formulario web seguro HTTPS .
A su vez, el NAS envía un mensaje de solicitud de acceso RADIUS al servidor RADIUS, solicitando autorización para otorgar acceso a través del protocolo RADIUS. [4]
Esta solicitud incluye credenciales de acceso, normalmente en forma de nombre de usuario y contraseña o certificado de seguridad proporcionado por el usuario. Además, la solicitud puede contener otra información que el NAS conoce sobre el usuario, como su dirección de red o número de teléfono, e información sobre el punto físico de conexión del usuario al NAS.
El servidor RADIUS comprueba que la información sea correcta mediante esquemas de autenticación como PAP , CHAP o EAP . Se verifica la prueba de identificación del usuario, junto con, opcionalmente, otra información relacionada con la solicitud, como la dirección de red o el número de teléfono del usuario, el estado de la cuenta y los privilegios de acceso a servicios de red específicos. Históricamente, los servidores RADIUS verificaban la información del usuario con una base de datos de archivos planos almacenada localmente. Los servidores RADIUS modernos pueden hacer esto o pueden hacer referencia a fuentes externas (comúnmente SQL , Kerberos , LDAP o servidores de Active Directory ) para verificar las credenciales del usuario.
Luego, el servidor RADIUS devuelve una de tres respuestas al NAS: 1) Rechazo de acceso, 2) Desafío de acceso o 3) Aceptación de acceso.
Cada una de estas tres respuestas RADIUS puede incluir un atributo de mensaje de respuesta que puede indicar el motivo del rechazo, el mensaje para el desafío o un mensaje de bienvenida para la aceptación. El texto del atributo se puede pasar al usuario en una página web de retorno.
Los atributos de autorización se transmiten al NAS y estipulan los términos del acceso que se concederá. Por ejemplo, los siguientes atributos de autorización pueden incluirse en una aceptación de acceso:
Cuando un cliente está configurado para utilizar RADIUS, cualquier usuario del cliente presenta información de autenticación al cliente. Esto puede ser mediante un mensaje de inicio de sesión personalizable, donde se espera que el usuario ingrese su nombre de usuario y contraseña. Como alternativa, el usuario puede utilizar un protocolo de enmarcado de enlaces, como el Protocolo punto a punto (PPP), que tiene paquetes de autenticación que transportan esta información.
Una vez que el cliente ha obtenido dicha información, puede optar por autenticarse mediante RADIUS. Para ello, el cliente crea una "Solicitud de acceso" que contiene atributos como el nombre del usuario, la contraseña del usuario, el ID del cliente y el ID del puerto al que accede el usuario. Cuando hay una contraseña, se oculta mediante un método basado en el algoritmo RSA Message Digest MD5.
La contabilidad se describe en RFC 2866.
Cuando el NAS concede acceso a la red al usuario , el NAS envía un inicio de contabilidad (un paquete de solicitud de contabilidad RADIUS que contiene un atributo Acct-Status-Type con el valor "start") al servidor RADIUS para indicar el inicio del acceso a la red del usuario. Los registros de "inicio" normalmente contienen la identificación del usuario, la dirección de red, el punto de conexión y un identificador de sesión único. [5]
Periódicamente, el NAS puede enviar registros de actualización provisional (un paquete de solicitud de contabilidad RADIUS que contiene un atributo Acct-Status-Type con el valor "interim-update") al servidor RADIUS para actualizarlo sobre el estado de una sesión activa. Los registros "provisionales" normalmente transmiten la duración de la sesión actual e información sobre el uso actual de los datos.
Finalmente, cuando se cierra el acceso a la red del usuario, el NAS emite un registro de detención de contabilidad final (un paquete de solicitud de contabilidad RADIUS que contiene un atributo Acct-Status-Type con el valor "stop") al servidor RADIUS, proporcionando información sobre el uso final en términos de tiempo, paquetes transferidos, datos transferidos, motivo de la desconexión y otra información relacionada con el acceso a la red del usuario.
Normalmente, el cliente envía paquetes de solicitud de contabilidad hasta que recibe un acuse de recibo de respuesta de contabilidad, utilizando un intervalo de reintento.
El objetivo principal de estos datos es poder facturar al usuario en consecuencia; los datos también se utilizan habitualmente para fines estadísticos y para la monitorización general de la red.
RADIUS se utiliza comúnmente para facilitar el roaming entre ISP , incluso mediante:
RADIUS facilita esto mediante el uso de reinos , que identifican dónde el servidor RADIUS debe reenviar las solicitudes AAA para su procesamiento.
Un dominio se suele añadir al nombre de usuario de un usuario y se delimita con un signo "@", similar al nombre de dominio de una dirección de correo electrónico. Esto se conoce como notación de sufijo para el dominio. Otro uso común es la notación de prefijo , que implica anteponer el dominio al nombre de usuario y usar "\" como delimitador. Los servidores RADIUS modernos permiten utilizar cualquier carácter como delimitador de dominio, aunque en la práctica se suelen utilizar "@" y "\".
Los reinos también se pueden componer utilizando notación de prefijo y sufijo, para permitir escenarios de itinerancia complicados; por ejemplo, somedomain.com\[email protected] podría ser un nombre de usuario válido con dos reinos.
Aunque los dominios suelen parecerse a los reinos, es importante señalar que, de hecho, los reinos son texto arbitrario y no necesitan contener nombres de dominio reales. Los formatos de los reinos están estandarizados en RFC 4282, que define un identificador de acceso a la red (NAI) en la forma 'usuario@reino'. En esa especificación, se requiere que la parte 'reino' sea un nombre de dominio. Sin embargo, esta práctica no siempre se sigue. RFC 7542 [6] reemplazó a RFC 4282 en mayo de 2015.
Cuando un servidor RADIUS recibe una solicitud AAA para un nombre de usuario que contiene un dominio, el servidor hará referencia a una tabla de dominios configurados. Si se conoce el dominio, el servidor enviará la solicitud mediante proxy al servidor local configurado para ese dominio. El comportamiento del servidor proxy con respecto a la eliminación del dominio de la solicitud ("eliminación") depende de la configuración en la mayoría de los servidores. Además, el servidor proxy se puede configurar para agregar, eliminar o reescribir solicitudes AAA cuando se envían mediante proxy nuevamente con el tiempo.
El encadenamiento de proxy es posible en RADIUS y los paquetes de autenticación/autorización y contabilidad generalmente se enrutan entre un dispositivo NAS y un servidor doméstico a través de una serie de proxies. Algunas de las ventajas de usar cadenas de proxy incluyen mejoras de escalabilidad, implementaciones de políticas y ajustes de capacidad. Pero en escenarios de roaming, el NAS, los proxies y el servidor doméstico podrían ser administrados típicamente por diferentes entidades administrativas. Por lo tanto, el factor de confianza entre los proxies adquiere mayor importancia en tales aplicaciones entre dominios. Además, la ausencia de seguridad de extremo a extremo en RADIUS se suma a la criticidad de la confianza entre los proxies involucrados. Las cadenas de proxy se explican en RFC 2607.
El roaming con RADIUS expone a los usuarios a diversos problemas de seguridad y privacidad. En términos más generales, algunos socios de roaming establecen un túnel seguro entre los servidores RADIUS para garantizar que las credenciales de los usuarios no puedan ser interceptadas mientras se transmiten a través de Internet. Esto es un problema, ya que el hash MD5 integrado en RADIUS se considera inseguro. [7]
RADIUS se transporta a través de UDP/IP en los puertos 1812 y 1813. [8]
A la derecha se muestra el formato de datos del paquete RADIUS . Los campos se transmiten de izquierda a derecha, comenzando por el código, el identificador, la longitud, el autenticador y los atributos.
Los códigos RADIUS asignados (decimales) incluyen los siguientes: [9]
Código | Asignación |
---|---|
1 | Solicitud de acceso |
2 | Acceso-Aceptar |
3 | Acceso-Rechazo |
4 | Contabilidad-Solicitud |
5 | Contabilidad-Respuesta |
11 | Desafío de acceso |
12 | Servidor de estado (experimental) |
13 | Estado del cliente (experimental) |
40 | Solicitud de desconexión |
41 | Desconectar-ACK |
42 | Desconectar-NAK |
43 | Solicitud de CoA |
44 | CoA-ACK |
45 | CoA-NAK |
255 | Reservado |
El campo Identificador ayuda a hacer coincidir solicitudes y respuestas.
El campo Longitud indica la longitud de todo el paquete RADIUS, incluidos los campos Código, Identificador, Longitud, Autenticador y Atributo opcional.
El autenticador se utiliza para autenticar la respuesta del servidor RADIUS y se utiliza para cifrar contraseñas; su longitud es de 16 bytes.
Los pares de valores de atributos (AVP) de RADIUS contienen datos tanto en la solicitud como en la respuesta para las transacciones de autenticación, autorización y contabilidad. La longitud del paquete RADIUS se utiliza para determinar el final de los AVP.
Tipo AVP | Asignación |
---|---|
1 | Nombre de usuario |
2 | Usuario-Contraseña |
3 | CHAP -Contraseña |
4 | Dirección IP del NAS |
5 | Puerto NAS |
6 | Tipo de servicio |
7 | Protocolo enmarcado |
8 | Dirección IP enmarcada |
9 | Máscara de red IP enmarcada |
10 | Enrutamiento enmarcado |
11 | Id. de filtro |
12 | MTU enmarcado |
13 | Compresión enmarcada |
14 | IP de inicio de sesión del host |
15 | Servicio de inicio de sesión |
16 | Puerto TCP de inicio de sesión |
18 | Responder-Mensaje |
19 | Número de devolución de llamada |
20 | Identificación de devolución de llamada |
22 | Ruta enmarcada |
23 | Red IPX enmarcada |
24 | Estado |
25 | Clase |
26 | Específico del proveedor |
27 | Tiempo de espera de sesión |
28 | Tiempo de espera inactivo |
29 | Acción de terminación |
30 | Identificación de la estación llamada |
31 | Identificación de la estación que llama |
32 | Identificador NAS |
33 | Estado proxy |
34 | Iniciar sesión en el servicio LAT |
35 | Nodo LAT de inicio de sesión |
36 | Iniciar sesión en LAT Group |
37 | Enlace AppleTalk enmarcado |
38 | Red AppleTalk enmarcada |
39 | Zona AppleTalk enmarcada |
40 | Tipo de estado de cuenta |
41 | Tiempo de retraso de la cuenta |
42 | Octetos de entrada de cuenta |
43 | Octetos de salida de la cuenta |
44 | Id. de sesión de cuenta |
45 | Cuenta Autentica |
46 | Tiempo de sesión de contabilidad |
47 | Paquetes de entrada de cuenta |
48 | Paquetes de salida de la cuenta |
49 | Causa de terminación de cuenta |
50 | Id. de cuenta multisesión |
51 | Conteo de enlaces de cuenta |
52 | Entrada de cuenta Gigawords |
53 | Salida de cuenta-Gigapalabras |
55 | Marca de tiempo del evento |
56 | VLANID de salida |
57 | Filtros de entrada |
58 | Nombre de VLAN de salida |
59 | Tabla de prioridades de usuarios |
60 | CAP -Desafío |
61 | Tipo de puerto NAS |
62 | Límite de puerto |
63 | Iniciar sesión en LAT-Port |
64 | Tipo túnel |
65 | Túnel de tipo mediano |
66 | Punto final del cliente del túnel |
67 | Punto final del servidor del túnel |
68 | Conexión de túnel de cuenta |
69 | Contraseña del túnel |
70 | Contraseña ARAP |
71 | Características de ARAP |
72 | Acceso a la zona ARAP |
73 | ARAP-Seguridad |
74 | Datos de seguridad de ARAP |
75 | Contraseña-Reintentar |
76 | Inmediato |
77 | Información de conexión |
78 | Token de configuración |
79 | Mensaje EAP |
80 | Autenticador de mensajes |
81 | ID de grupo privado de túnel |
82 | Identificación de asignación de túnel |
83 | Preferencia de túnel |
84 | ARAP-Desafío-Respuesta |
85 | Contabilidad-Intermedio-Intervalo |
86 | Paquetes perdidos en el túnel de contabilidad |
87 | Id. de puerto NAS |
88 | Piscina enmarcada |
89 | CUI |
90 | ID de autenticación del cliente del túnel |
91 | ID de autenticación del servidor de túnel |
92 | Regla de filtrado NAS |
94 | Información de la línea de origen |
95 | Dirección IPv6 de NAS |
96 | Identificación de interfaz enmarcada |
97 | Prefijo IPv6 enmarcado |
98 | Inicio de sesión en el host IPv6 |
99 | Ruta IPv6 enmarcada |
100 | Grupo de IPv6 enmarcado |
101 | Atributo de causa de error |
102 | Nombre de clave EAP |
103 | Resumen-Respuesta |
104 | Reino del Digest |
105 | Digest-Nonce |
106 | Autorización de respuesta de resumen |
107 | Resumen-Nextnonce |
108 | Método de digestión |
109 | URI de resumen |
110 | Resumen de Qop |
111 | Algoritmo de resumen |
112 | Resumen-Entidad-Cuerpo-Hash |
113 | Resumen-CNonce |
114 | Recuento de nonce de resumen |
115 | Digest-Nombre de usuario |
116 | Digest-Opaco |
117 | Parámetro de autenticación de resumen |
118 | Digest-AKA-Auts |
119 | Dominio de resumen |
120 | Digest-Ranky |
121 | Compendio-HA1 |
122 | SIP-AOR |
123 | Prefijo IPv6 delegado |
124 | Vector de características MIP6 |
125 | Prefijo de enlace de inicio MIP6 |
126 | Nombre del operador |
127 | Información de ubicación |
128 | Datos de ubicación |
129 | Reglas básicas de política de ubicación |
130 | Reglas de política de ubicación extendida |
131 | Con capacidad de ubicación |
132 | Información de ubicación solicitada |
133 | Protocolo de gestión enmarcado |
134 | Gestión-Transporte-Protección |
135 | Id. de política de gestión |
136 | Nivel de privilegio de gestión |
137 | Certificado PKM-SS |
138 | Certificado PKM-CA |
139 | Configuración de PKM |
140 | Lista de PKM Cryptosuite |
141 | PKM-SAID |
142 | Descriptor PKM-SA |
143 | Clave de autenticación PKM |
144 | Nombre del túnel DS-Lite |
145 | Identificador de nodo móvil |
146 | Selección de servicios |
147 | Dirección IPv6 de LMA de inicio de PMIP6 |
148 | Dirección IPv6 de LMA visitada por PMIP6 |
149 | Dirección IPv4 de LMA de inicio de PMIP6 |
150 | Dirección IPv4 de LMA visitada por PMIP6 |
151 | Prefijo HN de PMIP6 Home |
152 | Prefijo HN visitado por PMIP6 |
153 | Identificación de la interfaz de inicio de PMIP6 |
154 | Identificación de la interfaz visitada de PMIP6 |
155 | PMIP6-Hogar-IPv4-HoA |
156 | PMIP6-Visita IPv4-HoA |
157 | Dirección del servidor DHCP4 de inicio PMIP6 |
158 | Dirección del servidor DHCP4 visitado por PMIP6 |
159 | Dirección del servidor DHCP6 de inicio de PMIP6 |
160 | Dirección del servidor DHCP6 visitado por PMIP6 |
161 | Puerta de enlace IPv4 para el hogar PMIP6 |
162 | Puerta de enlace IPv4 visitada por PMIP6 |
163 | EAP-Capa inferior |
164 | Nombre del servicio de aceptación GSS |
165 | Nombre de host del aceptador GSS |
166 | Especificaciones del servicio GSS-Acceptor |
167 | Nombre del reino del aceptador GSS |
168 | Dirección IPv6 enmarcada |
169 | Dirección IPv6 del servidor DNS |
170 | Información de ruta IPv6 |
171 | Grupo de prefijos de IPv6 delegado |
172 | Grupo de direcciones IPv6 con estado |
173 | Configuración de IPv6-6rd |
174 | Identificación de estación llamada permitida |
175 | Identificación de par EAP |
176 | Id. del servidor EAP |
177 | Id. de dominio de movilidad |
178 | Tiempo de espera de preautorización |
179 | Nombre de id. de red |
180 | Anuncio de EAPoL |
181 | Red inalámbrica Hessid |
182 | Información del lugar de celebración de WLAN |
183 | Idioma del lugar de la WLAN |
184 | Nombre del lugar de la red WLAN |
185 | Código de motivo de WLAN |
186 | Cifrado por pares de WLAN |
187 | Cifrado de grupo WLAN |
188 | Conjunto de aplicaciones WLAN AKM |
189 | Cifrado de gestión de grupos WLAN |
190 | Banda RF WLAN |
RADIUS es extensible; muchos proveedores de hardware y software RADIUS implementan sus propias variantes utilizando atributos específicos del proveedor (VSA). Microsoft ha publicado algunos de sus VSA. [10] Las definiciones de VSA de muchas otras empresas siguen siendo exclusivas y/o ad hoc, no obstante, se pueden encontrar muchos diccionarios VSA descargando el código fuente de las implementaciones RADIUS de código abierto, por ejemplo, FreeRADIUS .
La sección 5.26 del RFC 2865 proporciona una codificación sugerida que la mayoría de los proveedores siguen:
26 (1 octeto) | Longitud (1 octeto) | Id. del proveedor (Big Endian de 4 bytes) | Tipo/atributo del proveedor (1 octeto) | Longitud del proveedor (1 octeto) = 2 + longitud de (valor) | Valor |
Algunos proveedores utilizan formatos diferentes. Por ejemplo, algunos proveedores omiten el campo "Longitud del proveedor" o utilizan 2 octetos para los campos "Tipo de proveedor" o "Longitud del proveedor".
La Sección 3.14 del RFC 8044 define el tipo de datos "vsa" que exige el formato de la Sección 5.26 del RFC 2865.
El protocolo RADIUS transmite contraseñas ofuscadas utilizando un secreto compartido y el algoritmo de hash MD5 . Como esta implementación particular proporciona solo una protección débil de las credenciales del usuario, [11] se debe utilizar protección adicional, como túneles IPsec o redes de centros de datos físicamente seguras, para proteger aún más el tráfico RADIUS entre el dispositivo NAS y el servidor RADIUS. Además, las credenciales de seguridad del usuario son la única parte protegida por el propio RADIUS, aunque otros atributos específicos del usuario, como las identificaciones de grupos de túneles o las membresías de VLAN transmitidas a través de RADIUS, también pueden considerarse información confidencial (útil para un atacante) o privada (suficiente para identificar al cliente individual). [ cita requerida ] .
El protocolo RadSec soluciona el problema de la seguridad RADIUS/UDP heredada "envolviendo" el protocolo RADIUS en TLS . Sin embargo, los paquetes dentro del transporte TLS aún utilizan MD5 para las comprobaciones de integridad de los paquetes y para ofuscar el contenido de ciertos atributos.
El ataque Blast-RADIUS rompe el protocolo RADIUS cuando se transporta mediante UDP simple al atacar MD5 dentro de RADIUS. [3] RadSec bloquea este ataque. [3] Otra mitigación recomendada es requerir atributos Message-Authenticator para todas las solicitudes y respuestas. [3] Se ha asignado CVE - 2024-3596 para el ataque Blast-RADIUS.
En 1991, a medida que más clientes de acceso telefónico utilizaban NSFNET , Merit Network envió una solicitud de propuestas para consolidar sus diversos sistemas propietarios de autenticación, autorización y contabilidad. Entre los primeros que respondieron se encontraba Livingston Enterprises y, tras una reunión, se escribió una versión preliminar de RADIUS. El primer servidor RADIUS se instaló en un sistema operativo UNIX . Livingston Enterprises fue adquirida por Lucent Technologies y, junto con Merit, se tomaron medidas para lograr la aceptación de RADIUS como protocolo en la industria. Ambas empresas ofrecieron un servidor RADIUS sin cargo. [12] En 1997, RADIUS se publicó como RFC 2058 y RFC 2059; las versiones actuales son RFC 2865 y RFC 2866. [13]
El estándar RADIUS original especificaba que RADIUS no tiene estado y debe ejecutarse sobre el Protocolo de datagramas de usuario (UDP). Para la autenticación, se previó que RADIUS debería soportar el Protocolo de autenticación de contraseña (PAP) y el Protocolo de autenticación por desafío mutuo (CHAP) sobre el Protocolo punto a punto . Las contraseñas se ocultan tomando el hash MD5 del paquete y un secreto compartido, y luego se realiza una operación XOR con ese hash y la contraseña. El RADIUS original también proporcionaba más de 50 pares de atributos y valores, con la posibilidad de que los proveedores configuraran sus propios pares. [14]
La elección del modelo de seguridad salto a salto, en lugar del cifrado de extremo a extremo , significó que si se utilizan varios servidores proxy RADIUS, cada servidor debe examinar, ejecutar lógica y transmitir todos los datos en una solicitud. Esto expone datos como contraseñas y certificados en cada salto. Los servidores RADIUS tampoco tenían la capacidad de detener el acceso a los recursos una vez que se había emitido una autorización. Los estándares posteriores, como RFC 3576 y su sucesor RFC 5176, permitieron que los servidores RADIUS cambiaran dinámicamente la autorización de un usuario o desconectaran a un usuario por completo. [15]
Actualmente existen varios servidores RADIUS comerciales y de código abierto. Las características pueden variar, pero la mayoría puede buscar usuarios en archivos de texto, servidores LDAP , diversas bases de datos, etc. Los registros de contabilidad se pueden escribir en archivos de texto, diversas bases de datos, reenviar a servidores externos, etc. SNMP se utiliza a menudo para la supervisión remota y la comprobación de la actividad de un servidor RADIUS. Los servidores proxy RADIUS se utilizan para la administración centralizada y pueden reescribir paquetes RADIUS sobre la marcha por razones de seguridad o para convertir entre dialectos de proveedores.
El protocolo Diameter fue pensado como reemplazo de RADIUS. Si bien ambos son protocolos de autenticación, autorización y contabilidad (AAA), los casos de uso para los dos protocolos han divergido desde entonces. Diameter se utiliza principalmente en el espacio 3G . RADIUS se utiliza en otros lugares. Una de las mayores barreras para que Diameter reemplace a RADIUS es que los conmutadores y puntos de acceso generalmente implementan RADIUS, pero no Diameter. Diameter usa SCTP o TCP , mientras que RADIUS generalmente usa UDP como capa de transporte . A partir de 2012, RADIUS también puede usar TCP como capa de transporte con TLS para seguridad.
El protocolo RADIUS está definido actualmente en los siguientes documentos RFC de IETF .
Solicitud de cotización | Título | Fecha de publicación | Artículo relacionado | RFC relacionadas | Nota |
---|---|---|---|---|---|
RFC 2058 | Servicio de acceso telefónico de autenticación remota de usuarios (RADIUS) | Enero de 1997 | RADIO | Obsoleto por RFC 2138 | |
RFC 2059 | Contabilidad RADIUS | Enero de 1997 | RADIO | Obsoleto por RFC 2139 | |
RFC 2138 | Servicio de acceso telefónico de autenticación remota de usuarios (RADIUS) | Abril de 1997 | RADIO | Obsoleto por RFC 2865 | |
RFC 2139 | Contabilidad RADIUS | Abril de 1997 | RADIO | Obsoleto por RFC 2866 | |
RFC 2548 | Atributos RADIUS específicos del proveedor de Microsoft | Marzo de 1999 | RADIO | ||
RFC 2607 | Encadenamiento de proxy e implementación de políticas en roaming | Junio de 1999 | |||
RFC 2618 | MIB del cliente de autenticación RADIUS | Base de información de gestión | Obsoleto por RFC 4668 | ||
RFC 2619 | MIB del servidor de autenticación RADIUS | Base de información de gestión | Obsoleto por RFC 4669 | ||
RFC 2620 | MIB del cliente de contabilidad RADIUS | Junio de 1999 | Base de información de gestión | Obsoleto por RFC 4670 | |
RFC 2621 | MIB del servidor de contabilidad RADIUS | Junio de 1999 | Base de información de gestión | Obsoleto por RFC 4671 | |
RFC 2809 | Implementación de la tunelización obligatoria L2TP a través de RADIUS | Abril de 2000 | |||
RFC 2865 | Servicio de acceso telefónico de autenticación remota de usuarios (RADIUS) | Junio de 2000 | RADIO | Actualizado por RFC 2868, RFC 3575, RFC 5080 | Este estándar describe la autenticación y autorización RADIUS entre un servidor de acceso a red (NAS) y un servidor de autenticación RADIUS compartido. Este protocolo también se utiliza para llevar información de configuración desde el servidor RADIUS al NAS. |
RFC 2866 | Contabilidad RADIUS | Junio de 2000 | RADIO | Esta norma describe cómo se transporta la información contable desde el NAS a un servidor de contabilidad RADIUS compartido. | |
RFC 2867 | Modificaciones de contabilidad RADIUS para compatibilidad con protocolo de túnel | Junio de 2000 | RADIO | Actualizaciones RFC 2866 | |
RFC 2868 | Atributos RADIUS para compatibilidad con protocolos de túnel | Junio de 2000 | Actualizaciones RFC 2865 | ||
RFC 2869 | Extensiones RADIUS | Junio de 2000 | Actualizado por RFC 3579, RFC 5080 | ||
RFC 2882 | Requisitos de los servidores de acceso a la red: Prácticas RADIUS extendidas | Julio de 2000 | |||
RFC 3162 | RADIUS y IPv6 | Agosto de 2001 | |||
RFC 3575 | Consideraciones de la IANA para RADIUS | Julio de 2003 | |||
RFC 3576 | Extensiones de autorización dinámica para RADIUS | Julio de 2003 | Obsoleto por RFC 5176 | ||
RFC 3579 | Compatibilidad de RADIUS con EAP | Septiembre de 2003 | Protocolo de autenticación extensible | Actualizaciones RFC 2869 | |
RFC 3580 | Pautas de uso de RADIUS IEEE 802.1X | Septiembre de 2003 | 802.1X | ||
RFC 4014 | Subopción de atributos RADIUS para la opción de información del agente de retransmisión DHCP | Febrero de 2005 | |||
RFC 4372 | Identidad de usuario con cargo | Enero de 2006 | |||
RFC 4590 | Extensión RADIUS para autenticación Digest | Julio de 2006 | Obsoleto por RFC 5090 | ||
RFC 4668 | MIB de cliente de autenticación RADIUS para IPv6 | Agosto de 2006 | Base de información de gestión | ||
RFC 4669 | Servidor de autenticación RADIUS MIB para IPv6 | Agosto de 2006 | Base de información de gestión | ||
RFC 4670 | MIB de cliente de contabilidad RADIUS para IPv6 | Agosto de 2006 | Base de información de gestión | ||
RFC 4671 | MIB del servidor de contabilidad RADIUS para IPv6 | Agosto de 2006 | Base de información de gestión | ||
RFC 4675 | Atributos RADIUS para LAN virtual y soporte prioritario | Septiembre de 2006 | |||
RFC 4679 | Atributos RADIUS específicos del proveedor del foro DSL | Septiembre de 2006 | |||
RFC 4818 | Atributo de prefijo IPv6 delegado de RADIUS | Abril de 2007 | |||
RFC 4849 | Atributo de regla de filtro RADIUS | Abril de 2007 | |||
RFC 5080 | Problemas comunes de implementación de RADIUS y soluciones sugeridas | Diciembre de 2007 | Actualizaciones RFC 3579 | ||
RFC 5090 | Extensión RADIUS para autenticación Digest | Febrero de 2008 | |||
RFC 5176 | Extensiones de autorización dinámica para RADIUS | Enero de 2008 | |||
RFC 5607 | Autorización RADIUS para la gestión de NAS | Julio de 2009 | |||
RFC 5997 | Uso de paquetes de servidor de estado en el protocolo RADIUS | Agosto de 2010 | Actualizaciones RFC 2866 | ||
RFC 6158 | Directrices de diseño de RADIUS | Marzo de 2011 | |||
RFC 6218 | Atributos RADIUS específicos del proveedor de Cisco para la entrega de material de codificación | Abril de 2011 | |||
RFC 6421 | Requisitos de criptoagilidad para el servicio de acceso telefónico de autenticación remota de usuarios (RADIUS) | Noviembre de 2011 | |||
RFC 6613 | RADIUS sobre TCP | Mayo de 2012 | Experimental | ||
RFC 6614 | Cifrado de seguridad de la capa de transporte (TLS) para RADIUS | Mayo de 2012 | Experimental | ||
RFC 6911 | Atributos RADIUS para redes de acceso IPv6 | Abril 2013 | Pista de estándares | ||
RFC 6929 | Extensiones del protocolo del servicio de acceso telefónico de usuario con autenticación remota (RADIUS) | Abril 2013 | Actualizaciones RFC 2865, RFC 3575, RFC 6158 | ||
RFC 7360 | Seguridad de la capa de transporte de datagramas (DTLS) como capa de transporte para RADIUS | Septiembre de 2014 | Experimental | ||
RFC 7585 | Descubrimiento dinámico de pares para RADIUS/TLS y RADIUS/DTLS basado en el identificador de acceso a la red (NAI) | Octubre de 2015 | Experimental | ||
RFC 8044 | Tipos de datos en RADIUS | Enero de 2017 | Actualizaciones: 2865, 3162, 4072, 6158, 6572, 7268 | ||
RFC 8559 | Proxy de autorización dinámica en el protocolo RADIUS | Abril 2019 | Pista de estándares |