Protocolos

Radius

La comunicación entre un servidor de acceso de red (NAS) y el servidor RADIUS se basa en el protocolo de datagrama de usuario (UPD). Generalmente, el protocolo RADIUS se considera un Servicio sin conexión. Los problemas relacionados con la disponibilidad de los servidores, la retransmisión y los tiempos de espera son tratados por los dispositivos activados por RADIUS en lugar del protocolo de transmisión. El RADIUS es un protocolo cliente/servidor. El cliente RADIUS es típicamente un NAS y el servidor de RADIUS es generalmente un proceso de daemon que se ejecuta en UNIX o una máquina del Windows NT. El cliente pasa la información del usuario a los servidores RADIUS designados y a los actos en la respuesta se vuelve que. Los servidores de RADIUS reciben las peticiones de conexión del usuario, autentican al usuario, y después devuelven la información de la configuración necesaria para que el cliente entregue el servicio al usuario. Un servidor RADIUS puede funcionar como cliente proxy para otros servidores RADIUS u otro tipo de servidores de autenticación. Esta figura muestra la interacción entre un usuario de marcación de entrada y el servidor y cliente RADIUS.

1. El usuario inicia la autenticación PPP al NAS. 
2. NAS le pedirá que ingrese el nombre de usuario y la contraseña (en caso de Protocolo de autenticación de contraseña [PAP]) o la integración (en caso de Protocolo de confirmación de aceptación de la contraseña [CHAP]). 
3. Contestaciones del usuario.
4. El cliente RADIUS envía el nombre de usuario y la contraseña encriptada al servidor de RADIUS.
5. El servidor RADIUS responde con Aceptar, Rechazar o Impugnar. 6. El cliente RADIUS actúa dependiendo de los servicios y de los parámetros de servicios agrupados con Aceptar o Rechazar. 

UDP y TCP

RADIUS utiliza UDP mientras TACACS+ utiliza TCP. TCP ofrece algunas ventajas frente a UDP. TCP ofrece una comunicación orientada a conexión, mientras que UDP ofrece mejor esfuerzo en la entrega. RADIUS requiere además de variables programables, como el número de intentos en la re-transmisión o el tiempo de espera para compensar la entrega, pero carece del nivel de built-in soportado con lo que ofrece el transporte TCP:

- TCP proporciona el uso de un identificador para las peticiones que sean recibidas, dentro (aproximadamente) de los Tiempos de Ida y Vuelta (RTT) en la red, independientemente de la carga y del lento mecanismo de autenticación de respaldo (un reconocimiento TCP) podría ser.

- TPC proporciona una marca inmediata cuando se rompe o no está corriendo la comunicación, gracias a un servidor de restablecimiento (RST). Puedes determinar cuando se rompió la comunicación y retorno el servicio si usas conexiones TCP long-lived. UDP no puede mostrar las diferencias entre estar caido, sufrir lentitud o que no exista servidor.

- Usando los TCP Keepalives, las caidas de servidores pueden ser detectadas out-of-band con peticiones reales. Conexiones a múltiples servidores pueden ser mantenidas simultáneamente, y solamente necesitas enviar mensajes a los que se sabe que tienen que estar arriba y corriendo.

- TCP es más escalable y adaptable al crecimiento, así como la conguestión, de las redes.

Encriptacion de paquetes

RADIUS encripta solamente la contraseña en el paquete de respuesta al acceso (access-request), desde el cliente hasta el servidor. El resto de paquetes está sin encriptar. Otra información, como el nombre de usuario, los servicios autorizados, y la contabilidad pueden ser capturados por un tercero.

TACACS+ encripta el cuerpo entero del paquete pero salvando la cabecera standar TACACS+. Dentro de la cabecera hay un campo donde se indica si el cuerpo está encriptado o no. Para propositos de depuración, es más util tener el cuerpo de los paquetes sin encriptar. Sin embargo, durante el normal funcionamiento, el cuerpo del mensaje es enteramente cifrado para más seguridad en las comunicaciones.

Autenticacion y Autorizacion

RADIUS combina autenticación y autorización. Los paquetes de acceso aceptado (access-accept) que son enviados por el servidor RADIUS al cliente, contienen información de autorización. Esto hace dificil desasociar autenticación y autorización.

TACACS+ usa la arquitectura AAA, que separa AAA. Esto perpite separar soluciones de autenticación, permitiendo seguir utilizando TACACS+ para la autorización y la contabilidad. Por ejemplo, con TACACS+, es posible utilizar autenticación Kerberos y autorización y contabilidad TACACS+. Después un NAS de autenticación sobre el servidor Kerberos, este solicita peticiones de autorización del servidor TACACS+ sin tener que volver a autenticarse. El NAS informa al servidor TACACS+ que se ha autenticado satisfactoriamente en un servidor Kerberos, y luego el servidor proporcionará la información de autorización.

Durante una sesión, si adicionalmente la autorización de control es necesaria, los accesos al servidor se comprueban con un servidor TACACS+ para determinar si se le conceden permisos para ejecutar un comando en particular. Esto proporciona mejor control sobre los comandos que pueden ser ejecutados en un servidor de acceso mientras es separado con mecanismos de autenticación.

Soporte multiprotocolo

RADIUS no soporta los siguientes protocolos:

- Protocolo de Acceso Remoto AppleTalk (ARA)

- Protocolo de Control de Tramas NetBIOS.

- Interfaz de Servicios Asíncronos de Novell (NASI)

- Conexiónes X.25 con PAD

TACACS+ ofrece soporte multiprotocolo.

Administracion de routers

RADIUS no permite al usuario el control de comando que pueden ser ejecutados en un router y cuales no. Por lo tanto, RADIUS no es tan util para la gestión de router o flexible para servicios de terminal.

TACACS+ proporciona dos métodos de control de autorización de los comandos de un router, uno por usuarios (per-user) o por grupos (per-groups). El primer método asigna niveles de privilegio a los comandos y el router tiene que verificar con el servidor TACACS+ si el usuario está o nó autorizado en el nivel de privilegios especificado. El segundo método es para especificar explícitamente en el servidor TACACS+, por usuario o por grupo, los comandos que están permitidos.

Interoperatibilidad

Debido a distintas interpretaciones de la RADIUS Request For Comments (RFCs), el cumplimiento de la RADIUS RFCs no garantiza la interoperatibilidad. Cisco implementa la mayoría de los atributos de RADIUS y coherentemente añade más. Si el cliente usa solo los atributos de la norma RADIUS en sus servidores, ellos podrán interoperar con varios proveedores siempre y cuando dichos proveedores implementen los mismos atributos. Sin embargo, muchos de los proveedores implementan extensiones de atributos propietarios. Si un cliente usa uno de esos atributos extendidos específicos del proveedor, la interoperatibilidad no está asegurada.