La Autententicación y Sus Protocolos

Escuela Colombiana de Ingeniería Julio Garavito
SYPI Semestre II 2005

Notas del profesor Fascículo No 6
La autenticación
La autenticidad es una de las 4 categorías principales de riesgos y amenazas existentes para la
seguridad de la información en nuestros días. Dada la gran cantidad de usuarios en servidores,
sitios web y en general en los grandes sistemas y redes, los riesgos de suplantación de
personalidad, repudio de transaccionalidad, perdida de identidad, violación de autoría y demás
son de aparición diaria en los ambientes del manejo de la información. Por esta razón los
hombres y mujeres de la tecnología tanto en las empresas dedicadas a la seguridad como en
los entes gubernamentales e instituciones no gubernamentales que conformas comunidades
virtuales de seguridad el tema ha impulsado al fabricación, diseño e implementación de
mecanismos de protección que permitan identificar al usuario realmente sin menoscabo de las
funciones clásicas de control de acceso seguro y manejo de la administración de este tema.
Este último factor (la administración del control de acceso y l autenticidad) se ha convertido
en un elemento decisorio es el manejo de la seguridad. Los métodos deben tratar de ser
sencillos y fáciles de administrar pues en grandes redes y sistemas de 10000 y mas usuarios si
el método no es fácil la administración es inalcanzable.
Que es un sistema o protocolo de autenticación y control de acceso
Es un método basado en procesos operaciones y algoritmos de encripción o no encripción que

tienen 2 objetivos fundamentales:
Controlar el acceso a un software, servidor, aplicación o sistema informático en red o

sin ella.
Verificar que el usuario que desee el acceso a un software, servidor, aplicación o
sistema informático en red o sin ella sea quien realmente clama ser o posa de ser.
Protocolos de autenticación y control de acceso

Un protocolo de autenticación es el intercambio programado de mensajes entre un objeto
usuario y un objeto servidor teniendo como finalidad la autenticación, autorización de uso de
recursos informáticos a los que tiene derecho y contabilización del uso de los mismos (en
Ingles AAA) para propósitos de rendimiento o facturación.
Definamos algunos conceptos importantes del anterior marco de referencia.
Objeto usuario es un elementos representativo del mundo real del usuario que accede a un
sistema y como tal puede ser:
Una identidad (generalmente un elemento o ente real (una persona usuario) o virtual (una
identidad de usuario ficticia de un sistema operativos que entrega una funcionalidad especial
al mismo: usuario del servidor de correo, usuario de administración de archivos, usuario de
manejo de redes etc.)
Autor: Ingeniero Jaime Hernando Rubio Rincón página 1

Una entidad la cual es un ente grupal que asocia un conjunto definido de usuarios
personas, o asocia identidades virtuales para intercambio de información efectiva a identidades
reales o a usuarios virtuales.
Usuario persona finalmente es un ser humano accediendo un sistema.
Todo ellos objetos usuarios a final son implementados en la informática mediante objetos de
programación orientada a objetos y como tal clases, métodos, atributos y mensaje son
inherentes a todo y cada uno de sus tipos.
Los protocolos de autenticación, autorización y contabilización son la herramienta tecnológica

fundamental para la organización de las políticas de seguridad ISO17799 ( Control de
Acceso).
Este curso tratará someramente los más importantes protocolos de autenticación a

saber: PAP, CHAP, TACACS+, SECURE/KEY, RADIUS y KERBEROS
Un amplio rango de tecnologías de seguridad existen hoy en día dentro de la estructura de

seguridad en la red corporativa las cuales proveen soluciones acceso seguro a la red y
mecanismos de transporte seguro de los datos. Muchas de ellas se sobreponen y son
redundantes en el catalogo de soluciones tecnológicas para asegurar identidad, control de
acceso e integridad así como una muy alta funcionalidad.
Nota Comentario [JHRR1]: A

través del curso SYPI los términos,
Autenticación es un proceso de validación de una reclamada identidad de un usuario final o autenticación, autorización, y
dispositivo (PC cliente, servidores, enrutadores, firewalls y demás) control de acceso están
completamente incorporados en el
Autorización es el proceso de garantizar acceso a usuarios o grupos de ellos, o a un sistema concepto identidad. Aunque hay
especifico a los recursos de la red. una diferente concepción en cada
término ellos pertenecen todos a
Control de acceso es limitar el flujo de información en la red a únicamente la persona o un individuo usuario de la red , sea
sistema autorizado a este acceso. este una persona o un dispositivo.
Cada persona o dispositivo es una
En la mayoría de los casos hablaremos de autorización y control de acceso como palabras identidad distinta que tienen
símiles pero que juntas conforman o tienen como consecuencia una exitosa autenticación habilidades separadas dentro de la
red y se le permite el acceso a los
Este panfleto describirá tecnologías de seguridad comúnmente usadas para establecer recursos basados en lo que ellos
identidad (autenticación y control de acceso) las cuales a su ves como consecuencia nos son. Es necesario aclarar que en el
mas puro sentido, el concepto
proveen además algún grado de protección contra amenazas de integridad, confidencialidad y identidad pertenece solo al área de
disponibilidad de los datos autenticación pero en muchos
casos es mas sensato discutir
Integridad de los datos asegura que ellos (los datos) no han sido alterados destruidos y identidad, autorización y control
reemplazados excepto por la gente que explícitamente se les ha identificado como autorizados de acceso al mismo tiempo.
para acceder a ellos
Confidencialidad asegura que solo la “entidad identificada” a la que se le ha permitido ver
los datos, los ve en un formato de uso. Asimismo la “identidad identificada” se supone que si
se le ha permitido el acceso es porque no va a dañar la disponibilidad de uso de los recursos
informáticos dado el grado de confianza que se le ha conferido al darle una autorización de
acceso. Intentamos desarrollar un entendimiento básico de como se puede implementar en
redes corporativas este tipo de métodos, identificar sus debilidades y fortalezas y sus
mecanismos de manejo.

Primero describamos las tecnologías usadas para establecer la identidad de una máquina
computadora cliente o servidora, un usuario final o ambos.
Autenticación es un elemento extremadamente crítico debido a que todos sus elementos están
basados en lo que la persona es, lo que la identifica o lo que la distingue. En muchas redes
corporativas ud. no puede garantizar el acceso a una parte específica de la red antes de
establecer quien esta tratando de ganar el acceso a los recursos restringidos. Que tan seguro es
el método de autenticación? Todo depende de la tecnología que se haya usada. Nosotros
podemos categorizar los métodos en aquellos donde el control es local y en aquellos donde se
provee verificación de autenticación por medio de terceros confiables o servidores control de
acceso (SCA).
Una de la debilidades potenciales en algunos métodos es que “Ud cree”; es decir se basan en
una confianza por defecto.. La fortaleza de la verificación en autenticación es el factor
limitante en la fortaleza de la identificación Cuando usamos un tercero para autenticar a un
usuario final o dispositivo pregúntese así mismo “Cual es la probabilidad de que el tercero
que estoy usando para mi verificación de autenticidad este comprometido en su seguridad?
Las tecnologías discutidas en esta sección incluyen variantes del método de contraseñas
seguras que proporcionan varios grados de seguridad y se ofrece por la mayoría de los
proveedores hoy. Muchos protocolos autorizarán alguna forma de establecimiento de conexión
después de que la autenticación se verifica con éxito. En ambientes de llamada telefónica
conmutada un enlace de par-a-par a nivel de la conexión se establece; a veces, los
mecanismos de control de acceso adicionales pueden emplearse a los niveles más altos de la
pila de protocolos, como permitir el acceso a los servidores con cierta dirección IP que sirve a
aplicaciones específicas. Nosotros miraremos protocolos diferentes a que a menudo usan un
proceso de autenticación inicial y después viene la concesión de la autorización y el control
de acceso. Nota. Comentario [JHRR2]: Pudiera
n usarse los certificados Digitales
como un método de autenticación
Asegurabilidad. Es la función de autoprotección y contraataque que poseen algunos
protocolos de autenticación. Ej: Kerberos
Las Contraseñas seguras

Aunque se usan a menudo las contraseñas como la prueba para autenticar a un usuario o
dispositivo, las contraseñas pueden ser fácilmente violadas si ellas son fáciles suponer, si ellas
no se cambian bastante a menudo, y si ellas se transmiten en texto transparente sobre una red.
Para hacer las contraseñas mas seguras se requieren los métodos más robustos se ofrecen tales
como encriptar la contraseña o modificar la encriptación para que el valor encriptado cambie
con el tiempo, o cada ves que se use.
Esto sucede con la mayoría de esquemas de contraseña de uso por una ves; siendo el método
más común el protocolo S/Key y los esquemas de autenticación por contraseña token.
Protocolo de contraseña S/Key

El método S/Key One-Time Password System, liberado por Bellcore y definido en el IETF
RFC 1760, es un esquema de generación de contraseña por una vez basado en los algoritmos
de encripción MD4 y MD5. El protocolo de S/Key esta diseña con un contador de ataque
repetidos para detectar cuando un usuario está intentando entrar en/a un sistema. Un ataque de
repetición en el contexto del login es cuando alguien ha escuchado o detectado una conexión

de la red para hacer ID y contraseña a los login de un usuario legítimo y los usa más tarde l
para ganar el acceso a la red.
El funcionamiento del protocolo de S/Key es client/server: el cliente es típicamente un PC, y
el servidor es alguna versión de UNIX. Inicialmente, deben configurarse el cliente y el
servidor con la misma “frase contraseña” y una cuenta de la iteración. La cuenta de iteración
especifica cuantas veces se le aplicara la función hash a una entrada dada. El cliente inicia el
intercambio S/Key enviando un paquete de la inicialización; el servidor responde con un
número secuencial y una semilla, como se muestra en Figura 1 a continuación:
Figure 1: El Intercambio de S/Key Inicial
El cliente calcula la contraseña a usar por unas ves, un proceso que involucra tres pasos
distintos, así:
un paso preparatorio,
un paso de generación, y
una función de salida (vea Figura 2.)
Expliquemos esta secuencia:
1. en el paso preparatorio, el cliente entra una frase contraseña secreta. Esta frase del paso se
encadena con la semilla que se recibió desde el servidor en texto transparente y la pasa al paso
de generación.
2. el paso de generación aplica la función hash segura múltiples veces, mientras produce un
bloque de 64 bits para la función de salida.
3. la función de salida toma la contraseña concatenada y con la función hash aplicada
múltiples veces del bloque de 64 bits y la despliega en una forma (ventana) leíble.
La última fase es para que el cliente apruebe y envié la contraseña de uso único dónde puede
verificarse (vea Figura 3).

Figura 2: Computando la contraseña S/Key para uso de solo una vez .
El servidor Unix tiene un archivo (en la aplicación de referencia, / el etc/skeykeys)

conteniendo, para cada uno de los usuarios la contraseña de uso único inicial, extraída del
último login exitoso.
. Para verificar un esfuerzo de la autenticación, el servidor de autenticación pasa la contraseña
de uso único recibida una vez, a través de la función de hash segura. Si el resultado de este
funcionamiento empareja la contraseña de uso único anterior guardada, la autenticación tiene
el éxito y la contraseña de uso único aceptada se guarda para en la siguiente iteración de
acceso.

Figure 3: Verificando la Contraseña de S/Key
..
Debido a que el número de veces que se aplica la función hash es ejecutada por el cliente
disminuye en 1 en cada generación se asegura una única sucesión de contraseñas generadas.
Sin embargo, en algún punto, el usuario debe reinicializar el sistema para evitar que en
algún momento no pueda dar login otra ves. El sistema se reinicializa usando el comando
keyinit, qué permite el cambio de la frase de contraseña de uso único inicialmente generada,
el contador de iteraciones y la semilla. Cuando se calcula la contraseña secreta S/Key en el
lado cliente la frase contraseña debe ser de más de 8 caracteres alfanuméricos. El USO DE
SEMILLA NO SECRETA permite al usuario usar la misma frase contraseña en cualquier
maquina usando diferentes semillas y reciclar la frase cambiando las semillas. Comentario [JHRR3]: Mucha
s implementaciones requieren el
uso de un procedimiento de cut
Nota and paste para entrar la contraseña
Razones de Interoperabilidad requieren que todo el sistema de S/Key servidores y las de uso único o también una forma
manual de entrada En escenarios
calculadoras usan el mismo diccionario. manuales la contraseña única es
S/Key es una alternativa a las contraseñas simples. Existe en formato libre así como las convertida a una secuencia de 6
palabras cortas ( 1 a 4 letras) del
aplicaciones comerciales. Ingles. Cada palabra es escogida
de un diccionario de 2,048
palabras; a 11 bits por palabra,
Esquemas de autenticación Token Password todas las contraseñas de uso único
pueden codificarse.

El Sistemas de autenticación por Token generalmente requieren el uso de una tarjeta
electrónica especial (llamada tarjeta inteligente o token card), aunque algunas
implementaciones se hacen usando software para aliviar el problema e perdida de los token.
Este tipo de mecanismo de autenticación esta basado en una de alternativas de esquema:
challenge-response y time-synchronous authentication. Normalmente antes que ser
considerado un protocolo de autenticación es un artilugio de tecnología que puede ser
compatible con otros
El esquema challenge-response se muestra en la Figura 4. Las siguientes etapas se cruzan
para llevar a cabo el intercambio de autenticación:
1 El usuario accede a un servidor de autenticación el cual emite un requerimiento

por un ID de usuario
2 El usuario provee el ID al servidor, el cual entonces emite un challenge (reto)---(un
número aleatorio que aparece en la pantalla del usuario.
3 El usuario entra el número de reto en el token o smart card, un dispositivo del
tamaño de una tarjeta de crédito pero activo e inteligente, el cual entonces en cripta el
número de reto w con la clave de encripción del usuario y despliega una respuesta.
4 El usuario digita esta respuesta y la envía al servidor de autenticación. Mientras el
usuario obtiene una respuesta desde el token, el SCA calcula cual debe ser la respuesta
apropiada basado en su base de datos de claves.
5 Cuando el SCA recibe la respuesta del usuario, la compara con la que ha calculado.
Si las 2 respuestas coinciden, el usuario le es garantizado el acceso a la red. Si no
coinciden se niega el acceso.
El esquema de autenticación “time-synchronous” se muestra en la Figura 5. En este esquema

un algoritmo propietario ejecutado en el token y en SCA genera números idénticos que
cambia segundo a segundo.
El usuario que accede a una SCA, se le requiere un código de acceso. El usuario entra un
“personal identification number (PIN)” en la tarjeta token, resultando un número de dígitos
desplegado en ese momento en el token. Esos digitos son una contraseña de uso único y se
envían al SCA. EL servidor compara la entrada con la secuencia generada en el, si coincide
garantiza el acceso si no deniega el acceso.
ESPACIO DEJADO INTENCIONALMENTE EN BLANCO

Figura 4: Autenticación por token de respuesta al reto
Password Authentication Protocol PAP
El método Password Authentication Protocol (PAP) provee una manera simple para que un
usuario establezca su identidad a un autenticador en un intercambio de 2 vías.
Protocolo de autenticación por reto

El Challenge-Handshake Authentication Protocol (CHAP) es muy usado como herramienta de
verificación de identidad de un host o de un usuario final usando un intercambio de 3
mensaje. CHAP normalmente se ejecuta al inicio de una conexión y puede repetirse en
cualquier momento de ella. La siguiente secuencia de proceso se lleva a cabo:

1 Después de establecida la conexión, el autenticador envía un mensaje de reto al
usuario. El reto consiste de un identificador (ID), un número aleatorio, y ya sea el
nombre del servidor o del dispositivo remoto pidiendo accedo.
2 El receptor usuario calcula un valor usando una función hash de una vía; al
entrada a la función es secreta.
3 El usuario entonces envía la respuesta al reto, la cual consiste de:
Una versión encriptada del ID, una contraseña secreta (el valor hash calculado en el
paso anterior),el número aleatorio, el nombre del servidor o del dispositivo
remoto.
4 Cuando el autenticador recibe la respuesta al reto, verifica el secreto mediante la
búsqueda del nombre en la respuesta y realizando la misma operación de encripción.
El autenticador chequea la respuesta contra sus cálculo usando el mismo hash.
5 Si el valor coincide el autenticador reconoce al remoto y envía un mensaje exitoso
de acceso estableciendo la conexión
Figura 5: Autenticación CHAP

Las contraseñas secretas deben ser idénticas en el lado remoto y en el local, generadas e
intercambiadas fuera de línea de una manera segura, secreta y nunca transmitida. Si la
respuesta no es apropiada el dispositivo remoto no puede conectarse al dispositivo local.
CHAP provee protección contra ataques “playback” mediante el uso de cambios
incrementales en el identificador y el valor de la variable de reto. El uso de retos repetidos se
entiende como recurso para limitar el tiempo de exposición a ataques simples. El SCA
controla la frecuencia de cambio y el tiempo de los retos.
Nota Comentario [JHRR4]: Típica
mente MD5 se usa como la
función hash de una via. Se
Protocolos que usan mecanismos de Autenticación requiere que los secretos
compartidos se almacenen en
Muchos protocolos requieren la comprobación de la autenticación antes de proporcionar formato de texto plano. Microsoft
autorización y derechos de acceso al usuario o dispositivo. TACACS+, RADIUS, Kerberos, tienen una variable de CHAP (MS-
CHAP) en la cual la contraseña se
DCE, y FORTEZZA son ejemplos de tales protocolos. almacena encriptada en ambos
TACACS+ y RADIUS se usan casi siempre en ambientes de control de acceso por línea lados, por tanto pude tomar ventaja
del concepto de bases de datos
telefónica conmutada para proporcionar una base de datos de la autenticación escalable y que irreversiblemente encriptadas.
puede incorporar una variedad de métodos de la autenticación.
Kerberos es un protocolo usado en algunos ambientes del campus para verificar primero que
los usuarios y los servicios que ellos usan realmente son quién dice ser y lo que ellos exigen
esta autorizado antes de conceder los privilegios de acceso. Para completar el panorama hay
que mencionar protocolos como (Ambiente de la Informática Distribuida) (DCE) y
autenticación de FORTEZZA. Estos últimos mecanismos no son muy usados.
..
El Protocolo TACACS+ “Terminal Access Controller Access Control System”
El protocolo de autenticación TACACS+ es la última generación de TACACS. TACACS es
un acceso basado en simple UDP originalmente desarrollado por BBN para la red MILNET.
Cisco lo ha reforzado (extendido)TACACS varios veces, y la aplicación de Cisco, basado en
el TACACS original, es llamada XTACACS. Las diferencias fundamentales entre TACACS,
XTACACS, y TACACS+ son :
TACACS+ es un protocolo cliente/servidor; el cliente de TACACS+ es típicamente un RAS y

el servidor de TACACS+ normalmente es un proceso daemon que corre en algún UNIX o
servidor Microsoft Windows. Una característica fundamental de TACACS+ es la separación
que hace de autenticación, autorización, y contabilidad.
La Autenticación de TACACS+
TACACS+ permite que el contenido del intercambio de autenticación sea de longitud

arbitraria y por tanto pudiera usar mecanismos de autenticación diferentes a los originales del
protocolo tales como PPP, CHAP, EAP, token chap, y Kerberos). La autenticación no es
obligatoria; es una opción configurada en sitio
Algunos los sitios no lo requieren en absoluto; otros sólo lo requieren con toda la seguridad
para el acceso a servicios.

La autenticación de TACACS+ tiene tres tipos de paquete:
START que siempre se envía por el cliente inicialmente

CONTINUE que siempre se envía por el cliente l
REPLY que siempre se envía por el servidor
La autenticación empieza con el cliente que envía un mensaje de START al servidor.
El mensaje describe el tipo de autenticación a ser usada (por ejemplo, CHAP, contraseña de
cleartext simple, PAP, CHAP), y puede contener el nombre de usuario y algunos datos de la
autenticación. El paquete de START sólo se envía como el primer mensaje en una sesión de
autenticación TACACS+ , o como el paquete que sigue inmediatamente después de un
reinicio.
Un reinicio puede pedirse por el servidor en un paquete de REPLY. Un paquete de START
siempre tiene un número de secuencia igual a 1
En la contestación a un paquete de START, el servidor envía un REPLY. El mensaje de
REPLY indica si la autenticación está terminada, o si debe continuar. Si el REPLY indica
que la esa autenticación debe continuar, el mensaje también indica qué nueva información se
necesita. El cliente consigue esa información y la responde con un mensaje CONTINUE. Este
proceso se repite hasta toda la información para autenticación recoge, y el proceso de
autenticación concluye.
Diferencia entre las diferentes modalidades de TACACS
TACACS: Combina procesos de autenticación y autorización

XTACACS: Separa autenticación, autorización y contabilización
TACACS+: Es los mismo que XTACACS pero con atributos extendidos y
contabilidad mas importante
TACACS+ usa TCP para su transporte. El demonio del servidor usualmente escucha en el
puerto 49, el puerto asignado para el LOGIN del TACACS. Este puerto era de naturaleza
reservada en la asignación de números de los RFC de UDP y TCP. TACACS también usa el
puerto 49.
.
Autorización TACACS+
Autorización es la acción de determinar lo que se le permite hace a cada usuario

Generalmente autenticación precede a autorización, pero no obligatoriamente no se requiere
ese orden. Un requerimiento de autorización puede indicar que el usuario no esta autenticado
(es decir, nosotros no sabemos quién es el usuario). En este caso, es al agente de autorización
quien le compete determinar si a un usuario no autenticado se le permite acceso a los
servicios en cuestión.
Cuando la autenticación se completa (si la autenticación se usa), el cliente puede empezar el
proceso de autorización, si la autorización se requiere. Una sesión de la autorización se define
como un solo par de mensajes: un mensaje de REQUEST seguido por un RESPONSE El

mensaje REQUEST de autorización contiene un juego fijo de campos que describen y
procesan la autenticidad del usuario, y un juego no constante de argumentos que describen los
servicios y opciones para la autorización que se pide.
Nota: Comentario [JHRR5]: En

TACACS+, la autorización no
proporciona meramente un sí o un
Aquí son algunos ejemplos de cuando la autorización se realizaría no --- también puede personalizar
el servicio para un usuario en
particular.
Cuando un usuario hace login y quiere iniciar un shell; cuando un usuario empieza PPP y
quiere usar IP encima de PPP con una dirección de IP particular. En los servidores TACACS+
un daemon podrían responder a estas demandas permitiendo el servicio, o poniendo una
restricción de tiempo en el login al shell, o requiriendo listas de acceso IP en la conexión del
PPP.
.Contabilidad TACACS+
La contabilidad es típicamente la tercera acción después de la autenticación y autorización. La

contabilidad es la acción de grabar lo que un usuario está haciendo o ha hecho. La
contabilidad en TACACS+ puede servir a dos propósitos:
Puede usarse para responder por el pago de los servicios que usó, como en un ambiente de
facturación.
Puede usarse como una herramienta de intervención para los servicios de seguridad. Es
decir como una herramienta de detección de uso no correcto o violatorio de la normas del
servicio
Con este fin, TACACS+ soporta tres tipos de registros de contabilidad:
Los registros START que indican que un servicio está a punto de empezar.
Los registros STOP que indican que un servicio simplemente ha terminado.
Los registros UPDATE son avisos del intermedio que indican que un servicio todavía está
realizándose.
Los registros TACACS+ de contabilidad contienen toda la información usada en los archivos
de la autorización y también contienen la información de contabilidad específica como
tiempos de inicio y parada de un (cuando es apropiado) y la información del uso del mismo.
.
Transacciones TACACS+
Las transacciones entre el cliente de TACACS+ y el servidor de TACACS+ se autentican a

través del uso de una contraseña secreta compartida que nunca se envía sobre la red.
Típicamente, la contraseña secreta se configura en ambas entidades. TACACS+ encripta todo
el tráfico entre el cliente de TACACS+ y el servidor daemon TACACS+ .
La Figura 6 muestra la interacción entre un usuario dial-en el y el cliente de TACACS+ y
servidor.

.
Figure 6: Un intercambio TACACS+
El usuario inicia una autenticación sobre PPP al RAS

El RAS le pide al usuario nombre de usuario y contraseña
El usuario replica con su contraseña y nombre de usuario
EL cliente TACACS+ que generalmente es el mismo RAS envía en un paquete
encriptado con la información del usuario al servidor TACACS+
EL SCA TACACS+ responde con la autenticación o la negación
EL servidor TACACS+ y el RAS intercambian mensajes de autorización
Si la autorización fue positiva el RAS deja entrar al usuario.
EL protocolo RADIUS
El protocolo Remote Address Dial-In User Service (RADIUS) fue desarrollado por Livingston
Enterprises, Inc., como un protocolo de servicio para TCP/IP con funcionalidad de
autenticación de acceso a servidores y contabilidad de uso de recursos. En Junio de 1996, la
especificación del protocolo e RADIUS fue enviada al IETF. La especificación es ahora una
norma en 2 partes: “The RADIUS specification (RFC 2058) y “RADIUS accounting standard
(RFC 2059)”. RADIUS usa UDP como su protocolo de transporte. Generalmente, el
protocolo se considera un servicio sin conexión. Los temas de disponibilidad del servicio,
retransmisión y timeouts son manejados por el habilitador del servicio RADIUS que por el
mismo protocolo RADIUS. El cliente RADIUS es típicamente un NAS; el servidor RADIUS
es un proceso daemon corriendo en Linux o WNT. El cliente responde por pasar información
del usuario al servidor designado de RADIUS y este activa una respuesta que se devuelva al
cliente.
Los servidores RADIUS responden por requerimientos de conexión, autenticación de usuarios
y toda la información de configuración necesaria para que el cliente entregue le servicio al
usuario. Un SCA RADIUS puede actuar como” proxy client” para otro SCA RADIUS o para
otro tipo de SCA.
EL SCA RADIUS posee una amplia variedad de métodos de autenticación de usuario. Cuando
al SCA se le entrega un nombre de usuario y una contraseña original dadas por el usuario, el

servidor puede soportar PPP PAP o CHAP, UNIX login u otros mecanismos. EL método
soportado depende de la implementación de cada vendedor/proveedor del servidor RADIUS.
Típicamente, un login consiste de un “query (Access-Request)” desde el RAS al SCA
RADIUS y su correspondiente respuesta (Access-Accept or Access-Reject) desde el servidor.
El paquete “Access-Request” contiene el “nombre de usuario”, contraseña encriptada,
dirección IP del RAS, y puerto. El formato del requerimiento también provee información
acerca del tipo de sesión que le usuario quiere iniciar.
Cuando el servidor RADIUS recibe el paquete de “Acces-Request” del RAS, busca en su
base de datos los nombres de usuario. Si el nombre de usuario no existe en la base de datos, o
un perfil predefinido no está cargado el servidor envía un mensaje de “Acces-Reject” . Este
mensaje Acces-Reject pudiera ser acompañado por un mensaje del texto optativo que puede
indicar la razón para la negativa. Si la búsqueda en la base de datos es positiva devuelve un
“Acces-Accept” confirmando la autenticación.
La Autorización de RADIUS
En el RADIUS, se acoplan la autenticación y funcionalidades de la autorización y van juntos.

Si el nombre de usuario es encontrado y la contraseña es correcta, el servidor del RADIUS
devuelve un “Acces-Accept” como contestación, incluyendo una la lista de pares de atributo-
valor que describen los parámetros a ser usados para esta sesión. Los parámetros típicos
incluyen el tipo de servicio (shell,framed), el tipo de protocolo , modo de asignación de la
dirección IP (estática o dinámica), si aplica a lista de acceso, o una ruta estática para instalar
en el RAS. La información de la configuración en el servidor del RADIUS define lo que se
instalará en el RAS.
La Contabilidad del RADIUS
La contabilidad que ofrece del protocolo RADIUS puede usarse independientemente de la

autenticación del RADIUS o aun de la autorización. Las funciones de contabilidad de
RADIUS permiten enviar los datos a la salida y fin de las sesiones, indicando la cantidad de
recursos (como tiempo, paquetes, los bytes, y así sucesivamente) que se usó durante la sesión.
Un proveedor de Internet (ISP) podría usar RADIUS para controlar el acceso y la
contabilidad de RADIUS para entregar al software de contabilidad estos datos para e cargar
a la cuenta del usuario.
Las Transacciones del RADIUS
Las transacciones entre el cliente y el servidor del RADIUS se autentican a través del uso de
un secreto compartido, qué nunca se envía sobre de la red. Además, cualquier contraseña del
usuario se envía encriptada entre el cliente y servidor del RADIUS para eliminar la posibilidad
de que alguien curioseando en una red insegura pudiera determinar la contraseña de un
usuario

Figura 7 muestra el login del RADIUS y proceso de la autenticación.
Secuencia de autenticación RADIUS:
El usuario inicia una autenticación de PPP al RAS

El RAS pide el nombre de usuario y contraseña
El usuario envía su nombre de usuario y contraseña
El RAS envía la contraseña y el nombre de usuario al servidor RADIUS
EL servidor RADIUS la ACEPTA. RECHAZA o pide un reto
EL RAS acepta y actúa según lo instruido por el servidor RADIUS y los datos colaterales
entregados por el
NOTA Comentario [JHRR6]: Con

TACACS+ y RADIUS, es
importante recordar que esa
encriptación se ha realizado
entre el cliente de
TACACS+/RADIUS y el servidor
El Protocolo Kerberos de TACACS+/RADIUS. Si el
cliente TACACS+/RADIUS
Kerberos es un protocolo de autenticación de clave secreta usado como metodología de es un RAS y no el cliente PC,
referencia desarrollado en Massachusetts Institute of Technology (MIT), el cual usa el cualquier comunicación entre el
PC y el NAS no se encripta
algoritmo de encripción Data Encryption Standard (DES). Kerberos Version 5 (la versión
actual) es un estándar Internet especificado en el RFC 1510.

Kerberos fue diseñado para autenticar requerimientos de usuarios por recursos de la red
(equipos activos, servidores, aplicaciones, uso de equipos de salida). Kerberos se basa en el
concepto de una tercera parte confiable (denominada Servidor de Control de Acceso-SCA) la
cual ejecuta la verificación segura del usuario y los servicios a los que tienen derecho a
acceder.
En la metodología del protocolo Kerberos esta tercera parte se denomina particularmente key
distribution center (KDC), también (SCA) servidor de control de acceso o sencillamente
servidor de autenticación o servidor Kerberos. El uso primario de Kerberos es la verificación
de usuarios y derechos de uso de servicios de cada usuario en la red y autenticar que cada
usuario sea quien dice ser. Para cumplir con su trabajo un servidor confiable de Kerberos
emite o genera "tickets" a los usuarios. Estos “tickets” tienen un ciclo de vida limitado y se
almacenan en repositorios cache durante un tiempo limitado (tanto en los clientes usuarios
como en los KDC´s) denominado credenciales de usuarios cache. Ellos puedes ser usados en
lugar de los nombres de usuarios y contraseña como mecanismos de autenticación en las
aplicaciones y servicios a los que requiera acceder el usuario.
Proceso Kerberos para requerimiento y respuesta de Autenticación

Inicialmente el cliente Kerberos tiene conocimiento de una clave de encripción que
únicamente conoce el cliente y el KDC, la que denominaremos Kclient. Adicionalmente cada
servidor de aplicaciones comparte una calve de encripción con el KDC la cual
denominaremos, Kserver (Figura 2-16).
Figure 8: Kerberos Keys
Las fases del proceso son:
Fase 1 El cliente envía un requerimiento de autenticación al KDC. EL mensaje enviado

al KDC contiene la siguiente información:
La identidad que se esta reclamando

El nombre de servidor de aplicaciones donde se requiere trabajar
El tiempo que debe durar el tiquete
Un número aleatorio que se usara para relacionar el mensaje con la respuesta
Fase 2 El KDC verifica los derechos de acceso del cliente y crea una respuesta de
autenticidad.

Fase 3 El KDC retorna una respuesta al cliente, la respuesta de autenticación, la cual
contiene la siguiente información:
La clave de sesión, Ksession

El tiempo de expiración
El número aleatorio que llegó en el request
El nombre de la aplicación o aplicaciones para las cuales se expide el tiquete
Información complementaria
La información esta encriptada con la clave igual a la contraseña del usuario, la cual fue
previamente autenticada en el KDC, con el mensaje Kclient. EL KDC envia también a
continuación el “Kerberos ticket” que contienen la clave aleatoria de sesión, Ksession , la cual
se usará para autenticar el cliente en el servidor de la aplicación o aplicaciones a usar; el
nombre del cliente para quien la Ksession se emitió y un tiempo de vencimiento para la
Ksession. El l “Kerberos ticket” se encripta usando Kserver.
Fase 4. Cuando el cliente recibes la respuesta de autenticación, pide la contraseña al usuario.

Esta que hemos llamado, Kclient, se usa para desencripta la clave de sesión Ksession,
Ksession. Ahora el cliente esta listo para comunicarse con el servidor de aplicaciones.
Nota Comentario [JHRR7]: Kclient

se usa como mecanismo de
Respuesta y requerimiento de la aplicación Kerberos “bootstrap”, pero en posteriores
comunicaciones entre el e KDC y
el cliente, una clave de cliente de
El intercambio entre la aplicación “Kerberizada” y el usuario es un intercambio entre las corto plazo Kclient-session, se usa.
partes conocido como el acceso kerberizado. El cliente le prueba a un “application Server” Kclient-session se crea en el KDC
convirtiendo la contraseña del
que el conoce la clave de sesión incluida en un “Kerberos ticket”, como se muestra en la figura usuario en una clave de corto
10 plazo. El KDC envía la Kclient-
session, encriptada con la
contraseña de usuario al cliente.
EL usuario desencripta la clave de
cliente de corto plazo ay
posteriormente la comunicación
KDC al cliente usa siempre esa
clave Kclient-session.
Figura 9: Kerberos: Request and Reply de autenticación

Fases detalladas del proceso de autenticación con el tiquete:
1 El cliente envía dos elementos al servidor de la aplicación como parte de la demanda por la
aplicación:
Los tiquete Kerberos (creados como se describió antes)

Un autenticador que incluye a lo siguiente (entre otros campos):
El tiempo actual
Un checksum de toda la información.
Una clave de encriptación optativa
Estos elementos son todos encriptados con la llave de la sesión, Ksession, del tiquete
compañero.
2 Después de recibir la demanda por la aplicación, el servidor de la aplicación descifra el
boleto con Kserver, extracta la llave de la sesión, Ksession, y usos la clave de sesión Ksession
para descifrar el autenticador.
Si la misma llave fuera usada para encriptar el autenticador como fue usado para descifrarlo,
los checksum serán iguales, y el verificador puede asumir que el autenticador se generó por el
cliente nombrado en el tiquete y para quien la llave de la sesión fue emitida. Solo, este
chequeo no es suficiente para la autenticación porque un hacker puede interceptar un
autenticador y suplantar al usuario. Por esta razón, el verificador también verifica el
timestamp. Si el timestamp está dentro de una ventana especificada (típicamente 5 minutos),
centrada alrededor del tiempo actual en el verificador, y si el timestamp no se ha visto en otras
demandas dentro de esa ventana de tiempo, el verificador acepta la demanda como auténtica.
A estas alturas, la identidad del cliente ha sido verificada por el servidor. Para algunas
aplicaciones, el cliente también quiere estar seguro de la identidad del servidor. Si la tal
autenticación mutua se requiere, un tercer paso se requiere.
3 El servidor de la aplicación genera una contestación de la aplicación extrayendo el tiempo
del cliente del autenticador e ingresando al cliente junto con otra información, todos
encriptado usando la clave de sesión, Ksession. Ver Figura 10
Reuso de Credenciales
El protocolo Kerberos de autenticación o básico permite a un cliente con el conocimiento de la

contraseña del usuario obtener un tiquete y una llave de la sesión para demostrar su identidad
a cualquier verificador (normalmente un servidor de la aplicación) registrado con el KDC. La
contraseña del usuario debe presentarse cada ves que el usuario realiza la autenticación con un
nuevo verificador.
La manera obvia de esconder la contraseña del usuario en el puesto de trabajo es peligrosa.
Aunque un tiquete de Kerberos y la llave asociadas con él son válidas durante sólo un tiempo
corto, un intruso que sabe la contraseña de usuario puede obtener los tiquetes válidos y
personifica al usuario hasta que la contraseña se cambie. Esto es por qué la llave del cliente a
corto plazo, la Kclient-sesión, se usa en lugar de la contraseña real del usuario en todos los
intercambios menos en la comunicación del bootstrap inicial. El enfoque de Kerberos es sólo

proveer tiquetes y llaves de encriptación (colectivamente llamadas las credenciales) que son
validas para un período de tiempo limitado.
El intercambio tiquetes de derechos del protocolo de Kerberos le permite a un usuario obtener
tiquetes y llaves del encriptación, las tales credenciales efímeras, sin volver a entrar la
contraseña del usuario. Cuando el usuario entra la primera petición de autenticación se emite
un tiquete y la llave de sesión de cliente para el servicio y un tiquete son devueltos por el
KDC. Este tiquete llamado de derechos (TGT), tiene una vida relativamente corta
(típicamente en el orden de 8 horas). La contestación se descifra, se salvan el tiquete y la
llave de la sesión, y se olvida de la contraseña del usuario. Como consecuencia, cuando el
usuario quiere demostrar su identidad a un nuevo verificador, un nuevo tiquete se pide del
KDC que usa el intercambio TGT.
Note El intercambio TGT es idéntico al intercambio de la autenticación sólo que el
TGT tiene embebido dentro de él una solicitud de la aplicación (autenticando al cliente y al el
servidor de la autenticación), y la contestación TGT que usa la llave de sesión de cliente
encripta el tiquete TGT en lugar de de la contraseña del usuario.
Figura 10 Requerimiento de aceptación del tiquete en la aplicación
Las Consideraciones prácticas

Los reinos múltiples, o dominios, se apoyan en Kerberos para permitir las aplicaciones
escalables. Por ejemplo una corporación ha llevado a cabo un sistema de Kerberos con dos
dominios o reinos separados, Italia y Hungría.
Cuando un cliente en el dominio de Italia conecta a un servidor en el dominio de Hungría, el
KDC de Italia autentica al cliente al KDC de Hungría. El KDC de Hungría autentica al cliente

al servidor de Hungría. Multi-KDC encadenados no se permiten, y si se confía en el KDC
encadenar debe remontarse sólo un nivel de encadenamiento..
Deben instalarse varios programas de utilidad en el puesto de trabajo para permitirles a los
usuarios obtener credenciales Kerberos (el kinit), destruir las credenciales (el kdestroy), listar
credenciales (el klist), y cambia su contraseña Kerberos (el kpasswd). Algunos sitios escogen
integrar el login de Kerberos de la herramienta kinit con el puesto de trabajo y los login se
programan para que los usuarios no tengan que teclear su contraseña dos veces. Estos hace un
uso de Kerberos casi transparente y los usuarios ni siquiera pueden ser conscientes que ellos
están usando Kerberos.
Deben modificarse las aplicaciones de Client/server para usar autenticación Kerberos; tal
Se dicen de estas, las aplicaciones Kerberos que están “Kerberized”.
El administrador Kerberos debe considerar también usar algún método de tiempo exacto en
todos los sistemas porque Kerberos tiene el problema de dependencia del tiempo través del
uso de timestamps. Un mecanismo fidedigno de sincronización es requerido
Para obtener el tiempo exacto que se necesita; el más probablemente, el uso de NTP se
garantiza esa exactitud.
Función hash
Una función HASH es un algoritmo unidireccional que toma un mensaje de longitud arbitraria
y produce una salida de código de longitud fija (hash o message digest)
Un algoritmo adecuado para realizar una función hash debe tener las siguientes propiedades:
Debe ser consistente, la misma entrada crea siempre la misma salida.
Debe ser aleatorio (o dar la apariencia) para prevenir que se adivine el mensaje original.
Debe ser único, debe ser imposible que dos mensajes produzcan el mismo hash (message
digest).
Debe ser de una sola vía, si uno tiene la salida, debe ser imposible obtener la entrada
Se utilizan típicamente como firmas (huellas) o sello de un archivo o mensaje. Los más
comunes son el SHA y toda su familia, MD4 y MD5.
Un “message authentication code (MAC)” (Fig. 11) es un pedacito de información usado para
autenticar un mensaje. El Algoritmo MAC, debe tener clave secreta y mensaje de longitud
arbitraria a ser autenticado
Es similar a hash, resistente a falsificación existente bajo ataques a un mensaje dado MAC
.debe ser segura así alguien que tenga la clave debería encontrar colisiones al usarla. MACs
difiere de la firma digital en que se genera y verifica con una sola clave. MACs no tiene la
propiedad del no repudio que da la firma digital, quien verifica un MAC puede generarla.
Algunos algoritmos MAC derivados de las primitivas siguientes
cryptographic hash functions (HMAC)
block cipher (OMAC, CBC-MAC and PMAC

Origen Destino
Alic Bo
Mensaj
Has
Has
Mensaj Mensaj
Firma
Firma, Firma,
sello o sello o
huella Firma, El Mensaje
huella
sello o llego sin
huella alteraciones
Fig. 11 MAC Message Authentication Code
Firma digital
La firma digital es un sello de representación que se fabrica aplicando una transformación
binaria hash a un documento de información. EL mensaje digerido (la salida del hash) se
encripta con una clave privada y se concatena con el mensaje original conformando la firma
digital. En algunas implementaciones se encripta el mensaje original con el sello concatenado.
La firma puede basarse en una función hash o en los tiempos modernos para algunas
implementaciones se puede usa una función MAC en ves del hash. Una firma digital es un
“message digest” encriptado que se adiciona a un documento. Se basan en una combinación de
algoritmos de encripción de llave pública y funciones hash de una vía. Se pueden utilizar para
confirmar la identidad del emisor y la integridad del documento
Certificados Digitales
El intercambio inicial de la llave pública debe realizarse de una manera confiable, para
preservar la seguridad. Esto es crítico y es la razón fundamental para la necesidad de
certificados digitales. Si el intercambio inicial no se realiza de una manera confiable,
alguien podría impersonalizar determinada entidad. Las firmas digitales no
proporcionan confidencialidad del contenido del mensaje.
A veces solo se necesita autenticación e integridad de los mensajes sin confidencialidad:
Ej updates de enrutamiento, transacciones bancarias y demas.

Alice 1
Bob
El emisor envía su llave pública al
Mensaje
Destino
El mensaje original es la entrada a la función

Has 3
La salida es el hash del

007FBC4 4
El hash se encripta con la llave privada del

Encripción 5
La firma digital es el hash

Firma 6
Mensaje
Firma
El emisor separa el
Firma mensaje y la firma Mensaje
Desencripta la
firma El mensaje es la
Desencriptación Hash
utilizando la llave Entrada a a función hash
pública
del emisor
El resultado es el hash
El resultado es 007FBC4 del mensaje
007FBC4 el hash
desencriptado
El certificado digital es una firma digital del documento denominado en el pasado el Realm
Name de una empresa, persona, dispositivo o entidad gubernamental o institución. A este
documento que puede contener cuantos atributos de la entidad se necesiten s ele aplican los
conceptos firma digital. Eso nos produce un certificado digital emitido por una entidad
certificadora, notario digital o un tercero con esas responsabilidades. En Internet el certificado
pudiera solo atestiguar la llave pública de una entidad o persona, pero puede colocar
realmname si la entidad lo decide.
Dependiendo de los límites financieros del certifica. EL estándar ITU-T X509 define los
procedimientos estándares de contenido para certificados digitales y sus contenidos.

La Autententicación y Sus Protocolos

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

La Autententicación y Sus Protocolos

Uploaded by

Copyright:

Available Formats

Escuela Colombiana de Ingeniería Julio Garavito

SYPI Semestre II 2005

Que es un sistema o protocolo de autenticación y control de acceso

Es un método basado en procesos operaciones y algoritmos de encripción o no encripción que

Controlar el acceso a un software, servidor, aplicación o sistema informático en red o

Protocolos de autenticación y control de acceso

Definamos algunos conceptos importantes del anterior marco de referencia.

Autor: Ingeniero Jaime Hernando Rubio Rincón página 1

Usuario persona finalmente es un ser humano accediendo un sistema.

Los protocolos de autenticación, autorización y contabilización son la herramienta tecnológica

Este curso tratará someramente los más importantes protocolos de autenticación a

Un amplio rango de tecnologías de seguridad existen hoy en día dentro de la estructura de

Nota Comentario [JHRR1]: A

Autor: Ingeniero Jaime Hernando Rubio Rincón página 2

Las Contraseñas seguras

Protocolo de contraseña S/Key

Autor: Ingeniero Jaime Hernando Rubio Rincón página 3

Figure 1: El Intercambio de S/Key Inicial

Expliquemos esta secuencia:

Autor: Ingeniero Jaime Hernando Rubio Rincón página 4

Figura 2: Computando la contraseña S/Key para uso de solo una vez .

El servidor Unix tiene un archivo (en la aplicación de referencia, / el etc/skeykeys)

Autor: Ingeniero Jaime Hernando Rubio Rincón página 5

Figure 3: Verificando la Contraseña de S/Key

Autor: Ingeniero Jaime Hernando Rubio Rincón página 6

1 El usuario accede a un servidor de autenticación el cual emite un requerimiento

El esquema de autenticación “time-synchronous” se muestra en la Figura 5. En este esquema

ESPACIO DEJADO INTENCIONALMENTE EN BLANCO

Autor: Ingeniero Jaime Hernando Rubio Rincón página 7

Figura 4: Autenticación por token de respuesta al reto

Password Authentication Protocol PAP

Protocolo de autenticación por reto

Autor: Ingeniero Jaime Hernando Rubio Rincón página 8

Figura 5: Autenticación CHAP

Autor: Ingeniero Jaime Hernando Rubio Rincón página 9

TACACS+ es un protocolo cliente/servidor; el cliente de TACACS+ es típicamente un RAS y

TACACS+ permite que el contenido del intercambio de autenticación sea de longitud

Autor: Ingeniero Jaime Hernando Rubio Rincón página 10

La autenticación de TACACS+ tiene tres tipos de paquete:

START que siempre se envía por el cliente inicialmente

La autenticación empieza con el cliente que envía un mensaje de START al servidor.

Diferencia entre las diferentes modalidades de TACACS

TACACS: Combina procesos de autenticación y autorización

Autorización es la acción de determinar lo que se le permite hace a cada usuario

Autor: Ingeniero Jaime Hernando Rubio Rincón página 11

Nota: Comentario [JHRR5]: En

La contabilidad es típicamente la tercera acción después de la autenticación y autorización. La

Con este fin, TACACS+ soporta tres tipos de registros de contabilidad:

Las transacciones entre el cliente de TACACS+ y el servidor de TACACS+ se autentican a

Autor: Ingeniero Jaime Hernando Rubio Rincón página 12

Figure 6: Un intercambio TACACS+

El usuario inicia una autenticación sobre PPP al RAS

Autor: Ingeniero Jaime Hernando Rubio Rincón página 13

En el RADIUS, se acoplan la autenticación y funcionalidades de la autorización y van juntos.

La Contabilidad del RADIUS

La contabilidad que ofrece del protocolo RADIUS puede usarse independientemente de la

Las Transacciones del RADIUS

Autor: Ingeniero Jaime Hernando Rubio Rincón página 14

Figura 7 muestra el login del RADIUS y proceso de la autenticación.

Secuencia de autenticación RADIUS:

El usuario inicia una autenticación de PPP al RAS

NOTA Comentario [JHRR6]: Con