Protocolos del servicio de autenticación de red

El servicio de autenticación de red utiliza el protocolo Kerberos junto con las API de servicios de seguridad genéricos (GSS) de autenticación para prestar servicios de autenticación y seguridad.

En los siguientes apartados se proporciona una descripción general de estos protocolos y se explica cómo se utilizan en el iSeries. Para facilitar una información más completa sobre estos estándares, se han proporcionado enlaces que llevan a las correspondientes peticiones de comentarios (RFC) y a otras fuentes de información externas.

AAA

La sigla AAA puede traducirse en español como Autenticación, Autorización y Auditoría (originalmente, Authentication, Authorization y Accounting). Cuando hablamos de AAA (triple A), no nos estamos basando en un solo protocolo o en algunos en especial, sino en una familia de protocolos que proveen los servicios anteriormente mencionados. Si le adicionamos el concepto de Auditoría, tendríamos lo que a veces se conoce como AAAA, o cuádruple A. Para comprender mejor estos sistemas de autenticación, debemos recordar primero los conceptos que representan.

Autenticación

La autenticación es el proceso por el que una entidad demuestra que es quien dice ser, probando así su identidad frente a un sistema u otra entidad. En general, una entidad es un cliente, y la otra es un servidor ante el cual se requiere autenticación. Al presentar alguno de los factores de autenticación ya conocidos ―algo que uno tiene (por ejemplo, un token), algo que uno sabe (por ejemplo, unpassword) y algo que uno es (por ejemplo, una huella dactilar)­―, se logra que el sistema valide al usuario en cuestión.
En algunos casos, también puede darse el requisito de la presentación de dos de los tres tipos de factores, para obtener lo que se denomina autenticación Two Factors. Vale la pena destacar que, en muchos casos, no es indispensable enviar por la red las credenciales de autenticación (usuario y contraseña, por ejemplo), sino que se cuenta con mecanismos que ofrecen mayor seguridad, como los sistemas de Challenge-Response (desafío-respuesta), utilizados ampliamente en redes inalámbricas. Estos se basan en el envío de información por parte del servidor, que el cliente procesa para, luego, devolver una respuesta única posible, cuya verificación reflejará el hecho de que el cliente conocía la forma de resolver el desafío. Así se valida que es quien decía ser.
El segundo elemento de los sistemas de triple A es la autorización, que se refiere a que, una vez que el usuario fue autenticado, pueda acceder a determinados recursos basado en los privilegios específicos que el sistema le provee.
Existen diversos métodos para garantizar los privilegios correspondientes a las diferentes entidades, desde sistemas mandatorios, hasta sistemas discrecionales o basados en roles, reglas y contextos. En esta instancia, un usuario de un sistema o red pasará a tener acceso a los diferentes recursos, como ancho de banda, carpetas y archivos, servicios y aplicaciones, y más.

Accounting

Finalmente, tenemos el concepto de accounting, que como bien decíamos, no se refiere a contabilidad en el sentido de lo que uno podría imaginarse (contadores realizando tareas de liquidación de sueldos o temas impositivos), ni a auditoría en el sentido de listas de verificación de cumplimiento de tareas realizada por un auditor. En este caso se refiere a la capacidad de un sistema de registrar eventos, normalmente soportada por los sistemas de logs, que no son más que registros secuenciales que permiten determinar las acciones realizadas por una entidad activa en una red (usuario, servicio, proceso, etcétera).
Por lo general, esta información se utiliza luego para la correcta administración de los recursos, la planificación de la capacidad y, también, para la recopilación de información en caso de incidentes que la requieran.
Existen diversos protocolos bien conocidos que implementan estos conceptos, entre los cuales mencionaremos los más utilizados: RADIUS, DIAMETER, TACACS y su sucesor, TACACS+.

RADIUS

RADIUS es el acrónimo en inglés de Remote Authentication Dial-In User Server, y es quizás el más conocido. Utiliza el puerto UDP 1812 UDP y funciona como cliente-servidor. Su éxito residió, probablemente, en su implementación en proveedores de acceso a Internet (ISP), que fueron los que primero debieron incluir una instancia de autenticación remota a través de la red para validar las conexiones de sus clientes.Estas conexiones pueden ser tanto inalámbricas como por medio de cablemódems, líneas ADSL o accesos dial-up. RADIUS recibe la información de credenciales de acceso por medio del protocoloPPP a través de un servidor conocido como Network Access Server, que redirige el pedido a un servidor RADIUS con el propio protocolo RADIUS. Este comprueba que la información sea correcta mediante otros mecanismos de autenticación (PAP, CHAP o EAP) y, en caso de ser aceptada, autoriza al cliente a acceder al sistema y le provee los recursos necesarios, como una dirección IP. RADIUS permite manejar sesiones, lo cual es útil para la medición de tiempo para facturación, como en hoteles o ISPs.

DIAMETER

Más adelante se creó DIAMETER, basado en el mismo concepto que RADIUS y tomando muchas de sus funcionalidades e ideas. De hecho, así como RADIUS equivale a la palabra radio en inglés (en referencia a la mitad del diámetro de un círculo), el nombre DIAMETER hace evidente referencia a “el doble del radio”, es decir, “el doble de RADIUS”.
Está pensado para trabajar tanto de modo local como en el llamado estado de alerta, sondeo y captura (AAA roaming), con lo cual puede ofrecer servicios dinámicos y flexibles. DIAMETER no es retrocompatible, pero ofrece un método de actualización para quienes parten de RADIUS. Algunas de sus diferencias son: usa TCP en vez de UDP, puede usar IPSEC o TLS, es peer-to-peer en vez de cliente-servidor, permite negociar capacidades, y tiene notificación de errores.
El último es TACACS, acrónimo de Terminal Access Controller Access Control System, creado por Cisco y usado, normalmente, en sistemas UNIX y descrito en el RFC 1492. Posteriormente surgióTACACS+, que pese a su nombre similar, es muy diferente y no es compatible con este último.

Más sobre RADIUS

Livingston Enterprises desarrolló el protocolo RADIUS para sus productos de la serie PortMaster de servidores NAS. Dada su popularidad, se publicó como RFC 2138 y RFC 2139 al poco tiempo. Hoy en día, existen muchas implementaciones de servidores RADIUS, incluyendo algunas de código abierto. También se implementan servidores proxy RADIUS para administración centralizada, que permiten rescribir paquetes al vuelo, ya sea por temas seguridad o por intercompatibilidad entre fabricantes. En la actualidad, lo definen principalmente el RFC 2865 para autentificación y autorización, y el RFC 2866 para accounting.

KERBEROS

El protocolo Kerberos proporciona autenticación de tercer interlocutor, en la que un usuario demuestra su identidad ante un servidor centralizado, llamado servidor Kerberos o centro de distribución de claves (KDC), el cual expide tickets para el usuario. Luego, el usuario puede utilizar los tickets para demostrar su identidad en la red. El ticket evita la necesidad de iniciar múltiples sesiones en los distintos sistemas. Las interfaces de programación de aplicaciones (API) del servicio de autenticación de red soportadas por el iSeries tienen su originen en el Massachusetts Institute of Technology y se han convertido en el estándar de hecho para utilizar el protocolo Kerberos.

Supuestos del entorno de seguridad

El protocolo Kerberos presupone todos los intercambios de datos se producen en un entorno en el que los paquetes se pueden insertar, cambiar o interceptar a voluntad. Utilice Kerberos como una capa de un plan de seguridad global. A pesar de que el protocolo Kerberos le permite autenticar a los usuarios y las aplicaciones en la red, debe tener en cuenta ciertas limitaciones al definir sus objetivos de seguridad de la red:

• El protocolo Kerberos no protege contra los ataques de denegación de servicio. Existen lugares en estos protocolos donde un intruso puede impedir que una aplicación participe en los pasos de autenticación correctos. Es preferible dejar la detección y la solución de estos ataques en manos de administradores y usuarios humanos.

• El hecho de compartir claves o el robo de las claves puede permitir ataques de imitación. Si de algún modo los intrusos logran robar la clave de un sujeto principal, podrán hacerse pasar por dicho usuario o servicio. Para minimizar esta amenaza, prohíba a los usuarios compartir sus claves e incluya esta política en sus normas de seguridad.

• El protocolo Kerberos no protege contra las vulnerabilidades típicas de las contraseñas, como la de adivinar una contraseña. Si un usuario elige una contraseña sencilla, un pirata podría montar con éxito un ataque de diccionario fuera de línea intentando repetidamente descifrar mensajes que se han cifrado bajo una clave derivada a partir de la contraseña del usuario.

TACACS

En estos apartados se comparan varias características de TACACS+ y de RADIUS.

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.

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.

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.