Fecha de emisión:

REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 1 de 18

Instrumento: Reporte

Alumno: Fecha: 04 – 03 – 18

Carrera: Grupo:

Asignatura: Seguridad de la información Unidad temática: Unidad 3: Métodos de

autenticación

Profesor:

I. Título: Reporte Unidad 3

II. Introducción

En la implementación de seguridad ya sea en una red u aplicación es necesarios

saber si esta necesitara una configuración distinta a la que comúnmente se maneja
para ello se debe tener en mente las características y ventajas de cada una de las
opciones a su vez se debe tener en cuenta la importancia de los datos. La mayoría de
las redes inalámbricas utilizan algún tipo de configuración de seguridad. Estas
configuraciones de seguridad definen la autentificación (el modo en que el
dispositivo en sí se identifica en la red) y la encriptación (el modo en que los datos
se cifran a medida que se envían por la red). Si no especifica correctamente estas
opciones cuando esté configurando su dispositivo inalámbrico, no podrá conectar
con la red inalámbrica. Por lo tanto, estas opciones deben configurarse con cuidado.
En el siguiente documento hablaremos de 3 métodos de autenticación los cuales
serán Radius, TACACS y Kerberos

III. Objetivo
Elabora un reporte con los siguientes puntos:
1. Comparación de métodos de autenticación.
2. Configuración de autenticación con RADIUS.
3. Descripción de la implementación de certificados digitales.

IV. Desarrollo
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 2 de 18

RADIUS
El protocolo RADIUS para autenticar usuarios es uno de los sistemas más antiguos usados
en Internet. El protocolo ha sido una plataforma estándar desde la era de las conexiones de
marcado a Internet. RADIUS ejecuta un programa de software en un servidor. El servidor
suele utilizarse exclusivamente para la autenticación RADIUS. Cuando un usuario intenta
conectarse a la red, un programa cliente de RADIUS dirige todos los datos de usuario al
servidor RADIUS para la autenticación. El servidor aloja los datos de autenticación del
usuario en un formato encriptado y envía una respuesta de paso o rechazo de nuevo a la
plataforma de conexión. Por tanto, la autenticación se establece o se rechaza. Si se rechaza,
el usuario simplemente intenta de nuevo. Cuando se haya establecido, la interacción
RADIUS termina. Las servicios de red adicionales que requieren autenticación son
manejados por otros protocolos, si es necesario.

Objetivos
Las funciones de un servidor RADIUS se resumen con las siglas "AAA" que significan:
Autenticación, Autorización y Anotación. Los hacedores de servidores no reciben
conexiones directas de los clientes sino que interactúan con las aplicaciones del cliente en
otros equipos de la red.

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.
Autenticación y autorización
El servidor RADIUS puede soportar varios métodos para autenticar un usuario. Cuando se
proporciona el nombre de usuario y la contraseña original dados por el usuario, puede
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 3 de 18

soportar el login PPP, PAP o de la GRIETA, de UNIX, y otros mecanismos de

autenticación.
Comúnmente, el ingreso de un usuario al sistema consiste en un pedido (Solicitud de
acceso) desde el NAS hacia el servidor RADIUS y de una correspondiente respuesta
(Aceptación de acceso o Rechazo de acceso) desde el servidor. El paquete access-request
contiene el nombre de usuario, la contraseña encriptada, la dirección IP NAS, y el puerto.

El Early Deployment del RADIUS fue hecho usando el número del puerto 1645 UDP, que
está en conflicto con el servicio del “datametrics”. Debido a este conflicto, el RFC 2865
asignó oficialmente el número del puerto 1812 para el RADIUS. La mayoría de los
dispositivos de Cisco y de las aplicaciones ofrecen el soporte para cualquier números del
conjunto de puertos. El formato del pedido proporciona asimismo información sobre el tipo
de sesión que el usuario desea iniciar. Por ejemplo, si la interrogación se presenta en el
modo de carácter, la inferencia es “tipo de servicio = EXEC-usuario,” pero si la petición se
presenta en el PPP en modo de paquete, la inferencia es “tipo de servicio = Usuario
entramado” y el “tipo de Framed =PPP.”

Cuando el servidor de RADIUS recibe el pedido de acceso del NAS, busca una base de
datos para el nombre de usuario enumerado. Si el nombre de usuario no existe en la base de
datos, se carga un perfil predeterminado o el servidor RADIUS inmediatamente envía un
mensaje Access-Reject (acceso denegado). Este mensaje de acceso rechazado puede estar
acompañado de un mensaje de texto que indique el motivo del rechazo.

En RADIUS, la autenticación y la autorización están unidas. Si se encuentra el nombre de

usuario y la contraseña es correcta, el servidor RADIUS devuelve una respuesta de Acceso-
Aceptar e incluye una lista de pares de atributo-valor que describe los parámetros que
deben usarse en esta sesión. Los parámetros comunes incluyen el tipo de servicio (shell o
entramado), el tipo de protocolo, la dirección IP para asignar el usuario (estática o
dinámica), la lista de acceso a aplicar o una ruta estática para instalar en la tabla de ruteo de
NAS. La información de configuración en el servidor RADIUS define qué se instalará en el
NAS. La siguiente figura ilustra la secuencia de autenticación y autorización de RADIUS.

Contabilidad
La funciones de contabilidad del protocolo RADIUS pueden emplearse
independientemente de la autenticación o autorización de RADIUS. Las funciones de
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 4 de 18

contabilidad de RADIUS permiten que los datos sean enviados al inicio y al final de las
sesiones, indicando la cantidad de recursos (por ejemplo, tiempo, paquetes, bytes y otros)
utilizados durante la sesión. Un Proveedor de servicios de Internet (ISP) puede usar
RADIUS para el control de acceso y un software de contabilidad para satisfacer
necesidades especiales de seguridad y facturación. El puerto de contabilidad para el
RADIUS para la mayoría de los dispositivos de Cisco es 1646, pero puede también ser
1813 (debido al cambio en los puertos como se especifica en el RFC 2139 ).
Las transacciones entre el cliente y el servidor RADIUS son autenticadas mediante el uso
de un secreto compartido, que nunca se envía por la red. Además, las contraseñas del
usuario se envían cifradas entre el cliente y el servidor de RADIUS para eliminar la
posibilidad que alguien snooping en una red insegura podría determinar una contraseña de
usuario.
TACACS
El protocolo de autenticación TACACS+ fue desarrollado a partir de la experiencia Cisco
con RADIUS. Muchas de las características efectivas de RADIUS se conservaron en
TACACS+, mientras que los mecanismos más robustos fueron creados para manejar los
nuevos niveles de seguridad que demandaban las redes modernas. Una mejora clave en el
diseño TACACS+ es la encriptación completa de todos los parámetros usados en el proceso
de autenticación. RADIUS sólo encripta la contraseña, mientras que TACACS+ también
encripta el nombre de usuario y otros datos asociados. Además, RADIUS es un protocolo
de autenticación independiente, mientras que TACACS+ es escalable. Es posible aislar sólo
determinados aspectos de autenticación de TACACS+ mientras implementa otros
protocolos para capas adicionales del servicio de autenticación. Por tanto, Se suele
combinar con Kerberos para sistemas de autenticación particularmente fuertes.

TACACS + utiliza Transmission Control Protocol (TCP) Puerto 49 para la comunicación

entre el cliente TACACS + y el servidor TACACS +. Un ejemplo es un switch Cisco
autenticar y autorizar el acceso administrativo al del interruptor de IOS CLI. El interruptor
es el cliente de TACACS + y Cisco Secure ACS es el servidor.

Uno de los diferenciadores clave de TACACS + es su capacidad para separar la

autenticación, autorización y contabilidad como funciones separadas e independientes. Esta
es la razón por TACACS + se utiliza tan comúnmente para la administración del
dispositivo, a pesar de que todavía RADIUS es sin duda capaz de proporcionar AAA
administración del dispositivo.

Administración de dispositivos puede ser muy interactiva en la naturaleza, con la necesidad

de autenticarse una vez, pero autorizar muchas veces durante una sola sesión administrativa
en la línea de comandos de un dispositivo. Un router o switch puede ser necesario para
autorizar la actividad de un usuario en función de cada comando. TACACS + está diseñado
para dar cabida a ese tipo de necesidad de autorización. Como su nombre lo describe,
TACACS + fue diseñado para AAA administración de dispositivos, para autenticar y
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 5 de 18

autorizar a los usuarios en mainframe y terminales de Unix, y otros terminales o consolas.

Kerberos
El servicio Kerberos es una arquitectura cliente-servidor que proporciona seguridad a las
transacciones en las redes. El servicio ofrece una sólida autenticación de usuario y también
integridad y privacidad. La autenticación garantiza que las identidades del remitente y del
destinatario de las transacciones de la red sean verdaderas. El servicio también puede
verificar la validez de los datos que se transfieren de un lugar a otro (integridad) y cifrar los
datos durante la transmisión (privacidad). Con el servicio Kerberos, puede iniciar sesión en
otros equipos, ejecutar comandos, intercambiar datos y transferir archivos de manera
segura. Además, Kerberos proporciona servicios de autorización, que permiten a los
administradores restringir el acceso a los servicios y los equipos. Asimismo, como usuario
de Kerberos, puede regular el acceso de otras personas a su cuenta.

El servicio Kerberos es un sistema de inicio de sesión único. Esto significa que sólo debe
autenticarse con el servicio una vez por sesión, y todas las transacciones realizadas
posteriormente durante la sesión se aseguran de manera automática. Una vez que el servicio
lo autenticó, no necesita volver a autenticarse cada vez que utiliza un comando basado en
Kerberos, como ftp o rsh, o accede a datos en un sistema de archivos NFS. Por lo tanto, no
es necesario que envíe la contraseña a través de la red, donde puede ser interceptada, cada
vez que utiliza estos servicios.

El servicio Oracle Solaris Kerberos se basa en el protocolo de autenticación de red

Kerberos V5, que fue desarrollado en el Instituto Tecnológico de Massachusetts (MIT,
Massachusetts Institute of Technology). A quienes hayan utilizado el producto Kerberos V5
la versión de Oracle Solaris les resultará muy familiar. Dado que el protocolo Kerberos V5
es un estándar de facto para la seguridad de la red en la industria, la versión de Oracle
Solaris promueve la interoperabilidad con otros sistemas. En otras palabras, como el
servicio Oracle Solaris Kerberos funciona con sistemas que usan el protocolo Kerberos V5,
el servicio favorece las transacciones seguras incluso en redes heterogéneas. Además, el
servicio proporciona autenticación y seguridad tanto entre dominios como dentro de un
único dominio.

A continuación se describe someramente el protocolo. Se usaran las siguientes abreviaturas:

AS = Authentication Server
TGS = Ticket Granting Server
SS = Service Server
En resumen el funcionamiento es el siguiente: el cliente se autentica a sí mismo contra el
AS, así demuestra al TGS que está autorizado para recibir un ticket de servicio (y lo recibe)
y ya puede demostrar al SS que ha sido aprobado para hacer uso del servicio kerberizado.

En más detalle:
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 6 de 18

1. Un usuario ingresa su nombre de usuario y password en el cliente

2. El cliente genera una clave hash a partir del password y la usará como la clave
secreta del cliente.
3. El cliente envía un mensaje en texto plano al AS solicitando servicio en nombre del
usuario. Nota: ni la clave secreta ni el password son enviados, solo la petición del
servicio.
4. El AS comprueba si el cliente está en su base de datos. Si es así, el AS genera la
clave secreta utilizando la función hash con la password del cliente encontrada en su
base de datos. Entonces envía dos mensajes al cliente: Mensaje A: Client/TGS
session key cifrada usando la clave secreta del usuario Mensaje B: Ticket-Granting
Ticket (que incluye el ID de cliente, la dirección de red del cliente, el período de
validez y el Client/TGS session key) cifrado usando la clave secreta del TGS.
5. Una vez que el cliente ha recibido los mensajes, descifra el mensaje A para obtener
el client/TGS session key. Esta session key se usa para las posteriores
comunicaciones con el TGS. (El cliente no puede descifrar el mensaje B pues para
cifrar éste se ha usado la clave del TGS). En este momento el cliente ya se puede
autenticar contra el TGS.
6. Entonces el cliente envía los siguientes mensajes al TGS: Mensaje C: Compuesto
del Ticket-Granting Ticket del mensaje B y el ID del servicio solicitado. Mensaje D:
Autenticador (compuesto por el ID de cliente y una marca de tiempo), cifrado
usando el client/TGS session key.
7. Cuando recibe los mensajes anteriores, el TGS descifra el mensaje D (autenticador)
usando el client/TGS session key y envía los siguientes mensajes al cliente:
8. Mensaje E: Client-to-server ticket (que incluye el ID de cliente, la dirección de red
del cliente, el período de validez y una Client/Server session key) cifrado usando la
clave secreta del servicio. Mensaje F: Client/server session key cifrada usando el
client/TGS session key.
9. Cuando el cliente recibe los mensajes E y F, ya tiene suficiente información para
autenticarse contra el SS. El cliente se conecta al SS y envía los siguientes
mensajes: Mensaje E del paso anterior. Mensaje G: un nuevo Autenticador que
incluye el ID de cliente, una marca de tiempo y que está cifrado usando el
client/server session key.
10. El SS descifra el ticket usando su propia clave secreta y envía el siguiente mensaje
al cliente para confirmar su identidad: Mensaje H: la marca de tiempo encontrada en
el último Autenticador recibido del cliente más uno, cifrado el client/server session
key.
11. El cliente descifra la confirmación usando el client/server session key y chequea si
la marca de tiempo está correctamente actualizada. Si esto es así, el cliente confiará
en el servidor y podrá comenzar a usar el servicio que este ofrece.
12. El servidor provee del servicio al cliente.
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 7 de 18

Ventajas de RADIUS, TACACS y KERVEROS

UDP y TCP
RADIUS utiliza UDP mientras que TACACS+ utiliza TCP. El TCP ofrece varias ventajas
en comparación con el UDP. TCP ofrece un transporte orientado por conexión, mientras
que UDP ofrece el mejor esfuerzo para entregar. RADIUS necesita variables programables
adicionales tales como los intentos de retransmisión y tiempos de espera para compensar el
transporte de producto de un esfuerzo razonable, pero carece del nivel de soporte incluido
que ofrece un transporte TCP:
 El uso del TCP proporciona un reconocimiento independiente acerca de que se ha
recibido una solicitud, dentro (aproximadamente) del trayecto de ida y vuelta (RTT),
independientemente de la carga que soporte el mecanismo de autenticación de segundo
plano y de su velocidad (un reconocimiento de TCP).
 TCP proporciona una indicación inmediata de un servidor caído o que no funciona a
través de un reinicio (RST). Puede determinar cuando un servidor falla y vuelve a estar
en servicio si utiliza las conexiones TCP de larga duración. UDP no puede indicar la
diferencia entre un servidor desactivado, uno lento y uno inexistente.
 Mediante las señales de mantenimiento de TCP, las caídas del servidor pueden ser
detectadas fuera de banda con peticiones actuales. Se pueden mantener conexiones a
servidores múltiples simultáneamente, y sólo debe enviar mensajes a los que están
activos y en funcionamiento.
 TCP permite mayor ampliación y se adapta a las redes en crecimiento y congestionadas.
Cifrado de Paquetes
RADIUS sólo cifra la contraseña en el paquete de solicitud de acceso, del cliente al
servidor. El resto del paquete no está cifrado. Otra información, tal como el nombre de
usuario, los servicios autorizados, y la cuenta, pueden capturarse a través de una tercera
parte.
TACACS+ cifra todo el cuerpo del paquete pero deja un encabezado estándar de
TACACS+. Dentro del encabezado se encuentra un campo que indica si el cuerpo se ha
cifrado o no. Para facilitar el debugging, resulta útil que el cuerpo de los paquetes no esté
cifrado. Sin embargo, durante el funcionamiento normal, el cuerpo del paquete se cifra
completamente para lograr comunicaciones más seguras.
Autenticación y autorización
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 8 de 18

RADIUS combina autenticación y autorización. Los paquetes access-accept enviados por el

servidor de RADIUS al cliente contienen la información de autorización. Esto dificulta la
tarea de desacoplar la autenticación y autorización.
TACACS+ usa la arquitectura AAA, la que separa a AAA. Esto permite soluciones de
autenticación separada que pueden todavía usar TACACS+ para autorización y conteo. Por
ejemplo, con TACACS+, es posible utilizar la autenticación de Kerberos y la autorización
TACACS+ y el conteo. Después de que un NAS se autentique en un servidor de Kerberos,
solicita la información de autorización de un servidor TACACS+ sin tener que volver a
autenticarse. El NAS le informa al servidor TACACS+ que se ha autenticado de manera
exitosa en un servidor Kerberos y luego el servidor le proporciona información de
autorización.
Durante una sesión, si se requiere una verificación de autorización adicional, el servidor de
acceso verifica con un servidor TACACS+ para determinar si el usuario tiene permiso para
utilizar un comando determinado. Esto permite un mayor control de los comandos que
pueden ejecutarse en el servidor de acceso mientras se desconecta del mecanismo de
autenticación.
Soporte multiprotocolo
RADIUS no admite estos protocolos:
 Protocolo AppleTalk Remote Access (ARA)
 Protocolo NetBIOS Frame Protocol Control
 Novell Asynchronous Services Interface (NASI)
 Conexión X.25 PAD
TACACS+ ofrece soporte multiprotocolo.
Administración del router
RADIUS no permite a los usuarios controlar qué comandos pueden y no pueden ejecutarse
en un router. Por lo tanto, RADIUS no es tan útil como para la administración del router ni
tan flexible para los servicios de terminal.
TACACS+ proporciona dos métodos para controlar la autorización de los comandos del
router por usuario o por grupo. El primer método es asignarle niveles de privilegio a los
comandos y hacer que el router verifique con el servidor TACACS+ si el usuario está
autorizado o no en ese nivel de privilegio específico. El segundo método es especificar
explícitamente los comandos permitidos en el servidor TACACS+, por usuario o por grupo.
Interoperabilidad
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 9 de 18

Debido a las diversas interpretaciones de la Solicitud de Comentarios de RADIUS (RFC),

el cumplimiento con RADIUS RFC no garantiza la interoperabilidad. Aunque varios
vendedores implementan clientes RADIUS, esto no significa que sean interoperables. Cisco
implementa la mayoría de los atributos de RADIUS y agrega constantemente más. Si los
clientes utilizan solamente los atributos de RADIUS estándar en sus servidores, pueden
interoperar entre varios vendedores siempre que estos vendedores implementen los mismos
atributos. Sin embargo, muchos proveedores implementan extensiones que son atributos de
propietario. Si un cliente utiliza uno de estos atributos extendidos específicos del
proveedor, la interoperabilidad no es posible.
Tráfico
Debido a las diferencias previamente mencionadas entre TACACS+ y RADIUS, la
cantidad de tráfico generada entre el cliente y el servidor difiere. Estos ejemplos ilustran el
tráfico entre el cliente y el servidor para TACACS+ y RADIUS cuando se usan para la
administración del router con autenticación, autorización de exec, autorización de
comandos (la cual RADIUS no puede llevar a cabo), contabilización de exec y
contabilización de comandos (la cual RADIUS no puede llevar a cabo).
Ejemplo de tráfico de TACACS+
En este ejemplo se asume que la autenticación del inicio de sesión, la autorización exec, la
autorización de comandos, el exec iniciar-detener y los comandos fueron implementados
con TACACS cuando un usuario se conecta mediante Telnet a un router, ejecuta un
comando y sale del router (no están disponibles otros servicios de administración):
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 10 de 18

Ejemplo deTráfico de RADIUS

En este ejemplo se asume que las cuentas de autenticación de usuario, la autorización exec
y el exec iniciar-detener fueron implementadas con RADIUS cuando un usuario se conecta
mediante Telnet a un router ejecuta un comando y sale del router (no están disponibles
otros servicios de administración):
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 11 de 18

KERBEROS
Protección por contraseña
La principal innovación del protocolo Kerberos es que las contraseñas de los usuarios no
tienen que ser transmitidos a través de una red, ya sea en texto o en virtud de cifrado. El
protocolo se basa en cambio en las claves secretas que se transmiten en un sistema de
codificación que no puede ser interceptado. Si se compromete la seguridad de una red,
todavía es posible para los delincuentes para interpretar el contenido de la red de
comunicación. Servicios de autenticación y público objetivo de la fijación.

Autenticación de cliente / servidor

En Kerberos, el cliente y el servidor deben autenticarse mutuamente. Comunicación para si
cada lado no es capaz de autenticar la otra parte.

Client / Server Ticket Certificación

Además de vale de autenticación mutua pasado desde el servidor al cliente, y viceversa, que
su fecha e incluir información de duración. Por consiguiente, la duración de la
autenticación es limitada. La duración de una aplicación de usuario puede ser modificado
por el dibujo, pero el límite es generalmente lo suficientemente bajo para asegurar que los
ataques de repetición (y ataques de fuerza bruta) no son factibles. Si lo hace, que la
duración es menor que teóricamente posible en cualquier momento a la fisuración de
cifrado, la comunicación permanece completamente seguro.

La durabilidad y la reutilización
Autenticación mediante el protocolo Kerberos son duraderos y reutilizables. Una vez que
un usuario se autentica mediante el protocolo de autenticación es reutilizable para la
duración de su billete. En otras palabras, usted puede permanecer autenticado por el
protocolo Kerberos sin tener que volver a introducir un nombre de usuario y contraseña a
través de la red (hasta la autentificación caduca).
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 12 de 18

Sesión de servicio de generación de claves

Dado que el modelo de Kerberos utiliza una metodología de cifrado de clave doble, la clave
de sesión que también se traduce servicio proporciona una conexión especial entre el
cliente y el servicio es completamente seguro. Este secreto especial conexión puede ser
utilizado como una clave de cifrado para la conversación cliente / servicio que añade
seguridad a las comunicaciones basado en Kerberos.

Normas de internet
El protocolo Kerberos se basa totalmente en estándares abiertos de Internet, y no se limita a
los códigos de los mecanismos de propiedad o de autenticación. Esto permite a los
desarrolladores confían en cualquier número de implementaciones de referencia a través del
transporte público y abierto y libre. Además, las implementaciones comerciales de bajo
costo se pueden adquirir o desarrollar de forma independiente.

Ubicuidad
Tal vez la mayor fortaleza de Kerberos " unión hace la fuerza". Porque Kerberos se ha
vuelto tan generalizado y la confianza de los mejores desarrolladores, expertos en seguridad
y criptógrafos, las nuevas deficiencias y las violaciones son susceptibles de ser
identificadas y superar de inmediato. A diferencia de un sistema de propiedad inusual, no
hay suficiente inversión en Kerberos que su seguridad ha alcanzado una masa crítica que
sería casi imposible de superar.
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 13 de 18

Configurar la Autenticación de Servidor RADIUS

RADIUS (Servicio de Usuario de Marcado por Autenticación Remota) autentica los
usuarios locales y remotos en una red empresarial. RADIUS es un sistema cliente/servidor
que guarda en una base de datos central los datos de autenticación de los usuarios,
servidores de acceso remoto, puertas de enlace de VPN y otros recursos.
Clave de Autenticación
Los mensajes de autenticación hacia y desde el servidor RADIUS usan una clave de
autenticación, no una contraseña. Esta clave de autenticación, o secreto compartido, debe
ser la misma en el cliente y servidor RADIUS. Sin esa clave, no puede haber comunicación
entre cliente y servidor.
Métodos de Autenticación RADIUS
Para autenticación por web y Mobile VPN with IPSec o SSL, RADIUS soporta solamente
la autenticación PAP (Protocolo de Autenticación por Contraseña).
Para autenticación con L2TP, RADIUS admite sólo MSCHAPv2 (Protocolo de
Autenticación por Desafío Mutuo de Microsoft versión 2).
Para autenticación con los métodos de autenticación WPA Enterprise y WPA2 Enterprise,
RADIUS admite el marco EAP (Protocolo de Autenticación Extensible).
Antes de Empezar
Antes de configurar su Firebox para usar su servidor de autenticación RADIUS, debe tener
esta información:
 Servidor RADIUS principal — Dirección IP y puerto RADIUS
 Servidor RADIUS secundario (opcional) — Dirección IP y puerto RADIUS
 Secreto compartido — Contraseña que distingue mayúsculas de minúsculas, que es
igual en el dispositivo y en el servidor RADIUS
 Métodos de autenticación — Configure su servidor RADIUS para permitir el
método de autenticación que usa su dispositivo: PAP, MS CHAP v2, WPA
Enterprise, WPA2 Enterprise o WPA/WPA2 Enterprise

Para usar la Autenticación por Servidor RADIUS con su Dispositivo

Para usar la autenticación por servidor RADIUS con su Firebox, debe:
 Agregar la dirección IP de Firebox al servidor RADIUS, tal como se describe en la
documentación de su proveedor de RADIUS.
 Activar y especificar el servidor RADIUS en la configuración de su Firebox.
 Agregar nombres de usuario o nombres de grupo RADIUS a sus políticas.
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 14 de 18

Para activar y especificar el (los) servidor(es) RADIUS desde Fireware

Web UI en su configuración:
1. Seleccione Autenticación > Servidores.
Aparece la página Servidores de Autenticación.
2. De la lista Servidor, seleccione RADIUS.
Aparecen las configuraciones del servidor RADIUS.
3. Seleccione la casilla de selección Habilitar Servidor RADIUS.
4. En el cuadro de texto de Dirección IP, ingrese la dirección IP del servidor
RADIUS.
5. En el cuadro de texto Puerto, asegúrese de que aparezca el número de puerto que
RADIUS utiliza para la autenticación.
El número de puerto predeterminado es 1812. Los servidores RADIUS más
antiguos pueden usar puerto 1645.
6. En el cuadro de texto Contraseña, ingrese el secreto compartido entre el dispositivo
y el servidor RADIUS.
El secreto compartido distingue mayúsculas de minúsculas, y debe ser igual en el
dispositivo y en el servidor RADIUS. El secreto compartido no puede incluir solo
caracteres de espacio.
7. En el cuadro de texto Confirmar, ingrese nuevamente el secreto compartido.
8. Ingrese o seleccione el valor de Tiempo de Espera.
El valor de tiempo de espera es el período de tiempo que el dispositivo espera la
respuesta del servidor de autenticación antes de intentar establecer una nueva
conexión.
9. En el cuadro de texto Reintentos, ingrese o seleccione el número de veces que el
dispositivo intenta conectarse al servidor de autenticación (el tiempo de espera se
especifica arriba) antes de reportar una conexión fallida para un intento de
autenticación.
10. En el cuadro de texto Atributo de Grupo, ingrese un valor de atributo. El atributo
grupo predeterminado es FilterID, que es el atributo RADIUS 11.
El valor del atributo Grupo es usado para definir el atributo que lleva la información
de grupo de usuarios. Debe configurar el servidor RADIUS para que incluya la
cadena Filter ID en el mensaje de autenticación de usuario que envía al dispositivo.
Por ejemplo, engineerGroup o financeGroup. Esa información luego es utilizada
para control de acceso. El dispositivo hace coincidir la cadena FilterID con el
nombre de grupo configurado en las políticas del dispositivo.
11. En el cuadro de texto Tiempo Muerto, ingrese el período de tiempo a partir del
cual un servidor inactivo está marcado como activo nuevamente.
Seleccione Minutos u Horasen la lista desplegable para cambiar la duración.
Después que un servidor de autenticación no haya respondido por un período de
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 15 de 18

tiempo, éste queda marcado como inactivo. Los intentos de autenticación

adicionales no tratarán de utilizar este servidor hasta que vuelva a marcarse como
activo.
12. Para agregar un servidor RADIUS de respaldo, en la sección Configuración del
Servidor Secundario, seleccione la casilla de selección Habilitar Servidor
RADIUS Secundario.
14. Repita los pasos 4 a 11 para configurar el servidor de respaldo. Asegúrese de que el
secreto compartido sea el mismo en el servidor RADIUS principal y de respaldo.
Para obtener más información
15. Haga clic en Guardar.
Para activar y especificar el (los) servidor(es) RADIUS desde Policy
Manager en su configuración:
1. Haga clic en
O bien, seleccione Configurar > Autenticación > Servidores de Autenticación.
Aparece el cuadro de diálogo Servidores de Autenticación.
2. Seleccione la pestaña RADIUS.
3. Seleccione la casilla de selección Habilitar servidor RADIUS.
4. En el cuadro de texto Dirección IP, ingrese la dirección IP del servidor RADIUS.
5. En el cuadro de texto Puerto, asegúrese de que aparezca el número de puerto que
RADIUS utiliza para la autenticación.
El número de puerto predeterminado es 1812. Los servidores RADIUS más
antiguos pueden usar puerto 1645.
6. En el cuadro de texto Secreto, ingrese el secreto compartido entre el dispositivo y el
servidor RADIUS.
El secreto compartido distingue mayúsculas de minúsculas, y debe ser igual en el
dispositivo y en el servidor RADIUS. El secreto compartido no puede incluir solo
caracteres de espacio.
7. En el cuadro de texto Confirmar Secreto, ingrese nuevamente el secreto
compartido.
8. Ingrese o seleccione el valor de Tiempo de Espera.
El valor de tiempo de espera es el período de tiempo que el dispositivo espera la
respuesta del servidor de autenticación antes de intentar establecer una nueva
conexión.
9. En el cuadro de texto Reintentos, ingrese o seleccione el número de veces que el
dispositivo intenta conectarse al servidor de autenticación (el tiempo de espera se
especifica arriba) antes de reportar una conexión fallida para un intento de
autenticación.
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 16 de 18

10. En el cuadro de texto Atributo de Grupo, ingrese o seleccione un valor de atributo.

El atributo grupo predeterminado es FilterID, que es el atributo RADIUS 11.
El valor del atributo Grupo es usado para definir el atributo que lleva la información
de grupo de usuarios. Debe configurar el servidor RADIUS para que incluya la
cadena Filter ID en el mensaje de autenticación de usuario que envía al dispositivo.
Por ejemplo, engineerGroup o financeGroup. Esa información luego es utilizada
para control de acceso. El dispositivo hace coincidir la cadena FilterID con el
nombre de grupo configurado en las políticas del dispositivo.
11. En el cuadro de texto Tiempo Muerto, ingrese o seleccione el período de tiempo a
partir del cual un servidor inactivo esté marcado como activo nuevamente.
Seleccione Minutos u Horas en la lista desplegable para cambiar la duración.
Después que un servidor de autenticación no haya respondido por un período de
tiempo, éste queda marcado como inactivo. Los intentos de autenticación
adicionales no tratarán de utilizar este servidor hasta que vuelva a marcarse como
activo.
12. Para agregar un servidor RADIUS de respaldo, seleccione la
pestaña Configuración del Servidor de Respaldo y seleccione la casilla de
selección Habilitar un servidor RADIUS de Respaldo.
14. Repita los pasos 4 a 11 para configurar el servidor de respaldo. Asegúrese de que el
secreto compartido sea el mismo en el servidor RADIUS principal y de respaldo.
Para obtener más información.
15. Haga clic en Aceptar.
15. Guardar el Archivo de Configuración.
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 17 de 18

CERTIFICACIONES DIGITALES
El Certificado Digital es el único medio que permite garantizar técnica y legalmente la
identidad de una persona en Internet. Se trata de un requisito indispensable para que las
instituciones puedan ofrecer servicios seguros a través de Internet. Además:
El certificado digital permite la firma electrónica de documentos El receptor de un
documento firmado puede tener la seguridad de que éste es el original y no ha sido
manipulado y el autor de la firma electrónica no podrá negar la autoría de esta firma.
El certificado digital permitecifrar las comunicaciones. Solamente el destinatario de la
información podrá acceder al contenido de la misma.
En definitiva, la principal ventaja es que disponer de un certificado le ahorrará tiempo y
dinero al realizar trámites administrativos en Internet, a cualquier hora y desde cualquier
lugar.
Un Certificado Digital consta de una pareja de claves criptográficas, una pública y una
privada, creadas con un algoritmo matemático, de forma que aquello que se cifra con
una de las claves sólo se puede descifrar con su clave pareja.
El titular del certificado debe mantener bajo su poder la clave privada, ya que si ésta es
sustraída, el sustractor podría suplantar la identidad del titular en la red. En este caso el
titular debe revocar el certificado lo antes posible, igual que se anula una tarjeta de crédito
sustraída.
La clave pública forma parte de lo que se denomina Certificado Digital en sí, que es un
documento digital que contiene la clave pública junto con los datos del titular, todo ello
firmado electrónicamente por una Autoridad de Certificación, que es una tercera entidad
de confianza que asegura que la clave pública se corresponde con los datos del titular.
La Firma Electrónica sólo puede realizarse con la clave privada. Puedes encontrar más
información sobre el proceso de firma digital en la sección “¿Qué es una firma digital?”
La Autoridad de Certificación se encarga de emitir los certificados para los titulares tras
comprobar su identidad.
El formato de los Certificados Digitales está definido por el estándar internacional ITU-T
X.509. De esta forma, los certificados pueden ser leídos o escritos por cualquier aplicación
que cumpla con el mencionado estándar.
 Fecha de emisión:
REPORTE 10/01/2013
Sistema de Gestión de la Calidad Revisión: 01
Página 18 de 18

ENTIDADES CERTIFICADORAS
La Entidad de Certificación, es aquella organización privada, que tiene como
función evaluar la conformidad y certificar el cumplimiento de una norma de
referencia, ya sea del producto, del servicio, o del sistema de gestión de una
organización. En particular, es la responsable de la auditoría realizada a las
organizaciones interesadas en obtener una certificación de su sistema de gestión de
la calidad según ISO 9001:2008, su sistema de gestión ambiental según ISO
14001:2004, etc. Estas entidades deben ser independiente de la organización que
audita, y no haber realizado otros trabajos para ella, como por ejemplo, consultoría
para implementar el sistema que se certifica.

V. Resultados
El proceso de autenticación es un componente crítico en la actividad de la
computadora. Los usuarios no pueden realizar muchas funciones en una red de
computadoras o en Internet sin autenticarse antes en el servidor. Acceder a una
computadora individual o a un sitio web requiere un protocolo de autenticación
confiable para ejecutar un proceso de fondo para establecer la verificación del
usuario. Una variedad de protocolos están en uso activo por parte de muchos
servidores por el mundo.
VI. Conclusiones
La información en este documento nos ayuda a entender que la mayoría de las redes
inalámbricas utilizan algún tipo de configuración de seguridad. Estas
configuraciones de seguridad definen la autentificación (el modo en que el
dispositivo en si se identifica en la red) y la encriptación (el modo en que los datos
se cifran a medida que se envían por la red)
VII. Bibliografía