5 Protocolos Seguros de Red

Protocolos
seguros de red
PID_00287477
Ángel Elbaz Sanz

© FUOC • PID_00287477 Protocolos seguros de red
Ángel Elbaz Sanz
La revisión de este recurso de aprendizaje UOC ha sido coordinada

por los profesores: Jordi Serra Ruiz, Víctor García Font
Primera edición: febrero 2022

© de esta edición, Fundació Universitat Oberta de Catalunya (FUOC)
Av. Tibidabo, 39-43, 08035 Barcelona
Autoría: Ángel Elbaz Sanz
Producción: FUOC
Todos los derechos reservados
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada,
reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea este eléctrico,
mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita
del titular de los derechos.
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 6
1. SSH.......................................................................................................... 7
1.1. Arquitectura del protocolo SSH .................................................. 8
1.2. Protocolo de capa de transporte ................................................. 9
1.2.1. SSH handshake................................................................. 9
1.2.2. Autenticación del servidor ............................................ 11
1.3. Protocolo de autenticación de usuario ....................................... 12
1.3.1. Autenticación con clave pública ................................... 12
1.3.2. Autenticación con contraseñas ..................................... 13
1.3.3. Autenticación basada en host......................................... 13
1.4. SSH connection protocol.................................................................. 14
1.5. Transferencia de ficheros con SSH: SCP y SFTP .......................... 14
1.6. Vulnerabilidades SSH .................................................................. 16
2. TLS.......................................................................................................... 18
2.1. Introducción a SSL/TLS ............................................................... 18
2.1.1. Motivación y origen ...................................................... 18
2.1.2. Versiones de SSL/TLS ..................................................... 18
2.2. TLS 1.3 ......................................................................................... 20
2.2.1. Diferencias con TLS 1.2 ................................................. 20
2.2.2. Descripción del protocolo ............................................. 20
2.2.3. TLS handshake protocol.................................................... 22
2.2.4. TLS record protocol............................................................ 23
2.2.5. TLS alert protocol.............................................................. 24
2.3. Protocolos que utilizan TLS ........................................................ 25
2.3.1. HTTPS ............................................................................. 25
2.3.2. SMTP, IMAP y POP3 ...................................................... 26
2.4. TLS en las redes privadas virtuales ............................................. 29
3. IPSEC...................................................................................................... 30
3.1. Introducción y arquitectura IPSEC ............................................. 30
3.2. AH ................................................................................................ 31
3.2.1. AH en modo transporte ................................................ 31
3.2.2. AH en modo túnel ........................................................ 31
3.3. ESP ............................................................................................... 32
3.3.1. ESP en modo transporte ................................................ 32
3.3.2. ESP en modo túnel ........................................................ 33
3.4. Protocolo de gestión de claves .................................................... 33
3.5. IPSec en las redes privadas virtuales ........................................... 34
4. RADIUS.................................................................................................. 36
4.1. Historia de RADIUS ..................................................................... 36
4.2. Arquitectura y funcionamiento de RADIUS ............................... 36
4.3. Alternativas a RADIUS: DIAMETER y TACACS+ ......................... 38
5. EAP (protocolo de autenticación extensible) y 802.1x............. 40

5.1. EAP (protocolo de autenticación extensible) .............................. 40
5.1.1. Arquitectura y modo de funcionamiento ...................... 40
5.1.2. Métodos EAP de autenticación ...................................... 41
5.2. Protocolo 802.1x ......................................................................... 44
5.2.1. Arquitectura 802.1x ....................................................... 44
5.2.2. Autenticación 802.1x ..................................................... 45
5.2.3. Autorización 802.1x ...................................................... 46
Resumen....................................................................................................... 48
Bibliografía................................................................................................. 49
© FUOC • PID_00287477 5 Protocolos seguros de red
Introducción
Internet es una red de ordenadores mundialmente conectados. Hemos de te-

ner presente que es una red que está formada, a su vez, por otras redes y que
en su conjunto podemos percibir como una infraestructura pública y no con-
fiable.
Esta arquitectura lleva implícita una falta de seguridad que, a su vez, presenta
una serie de riesgos, entre los que podemos citar: la suplantación de identidad,
la falta de privacidad o los ataques a la integridad de la información transmi-
tida.
En primer lugar, veremos protocolos que ofrecen seguridad en las diferentes

capas de la pila de protocolos TCP o IP. Comenzaremos con el estudio de secure
shell (SSH), que nos provee de servicios de seguridad en la capa de aplicación.
Posteriormente, seguiremos con el estudio de transport layer security (TLS), que
nos permite asegurar la capa de transporte y, por último, nos centraremos en
IP security (IPSec), que asegura los datos a nivel de la capa de red.
Finalmente, en los apartados cuatro y cinco, veremos un conjunto de proto-

colos de autenticación, que nos permitirán, utilizando diferentes algoritmos
criptográficos, dotar al proceso de autenticación de integridad y confidencia-
lidad.
Objetivos
Los objetivos que el estudiantado habrá alcanzado al finalizar este módulo son:
1. Comprender el concepto y utilidad de los protocolos de seguridad.
2. Utilizar protocolos seguros de acceso remoto a la red, como SSH.
3. Conocer el funcionamiento del protocolo TLS y su aplicación a los dife-

rentes protocolos de la capa de transporte de TCP o IP.
4. Diseñar redes seguras con el protocolo IPSec.
5. Conocer la arquitectura y funcionamiento del protocolo RADIUS.
6. Entender el marco de autenticación EAP.
7. Comprender el rol del protocolo de autenticación basado en puertos

802.1x.
1. SSH
La necesidad de tener comunicaciones remotas con otros equipos surgió de

forma paralela al auge de las redes de comunicaciones. Para cubrir esta nece-
sidad surgieron protocolos como rlogin o telnet, que no incorporaban medidas
de seguridad en su definición inicial y que eran vulnerables a ataques de su-
plantación de identidad o interceptación de las comunicaciones.
A principios del año 1995, la Universidad Tecnológica de Helsinki (Finlandia)

sufrió un ataque de password-sniffing (‘escucha de contraseñas’), mediante el
cual los atacantes podían obtener las contraseñas de los usuarios que se conec-
taban a los equipos de la universidad, ya que estas se transmitían en texto claro
por la red, es decir, sin cifrar, por lo tanto, se podían obtener los datos que pa-
saban por la red. Ante este problema de seguridad, Tatu Ylönen, investigador
de dicha universidad creó para sí mismo el protocolo SSH, con un desarrollo
centrado en la seguridad y el uso de algoritmos criptográficos. Nacía de esta
forma, la primera versión del protocolo SSH, conocida como SSH-1.
En julio de 1995, Ylönen hizo público el código fuente, lo que permitió la Enlace recomendado
copia y el uso del programa sin coste alguno. A final del mismo año miles de
Podéis ver el documento ori-
usuarios estaban utilizando SSH-1, lo que llevó a Ylönen a fundar la empresa ginal de esta especificación
SSH Communications Security Ltd. para continuar con el desarrollo del pro- en: <https://tools.ietf.org/
html/draft-ylonen-ssh-proto-
ducto. En el mismo año, 1995, el protocolo SSH-1 entró como borrador en el col-00>
grupo de trabajo de ingeniería de internet (IETF).
Poco a poco se fue descubriendo que el protocolo SSH-1 tenía ciertas limita-
ciones y adolecía de problemas de seguridad, por lo que, en 1996, apareció la
segunda versión del protocolo, SSH-2, que incorporaba nuevos algoritmos y
era compatible con la versión anterior. En estos momentos, el IETF creó un
grupo de trabajo, llamado secure shell, para trabajar sobre esta nueva versión
y estandarizar el protocolo.
A principios del año 2000, la empresa de Ylönen amplió el uso de la licencia

del protocolo SSH-2, permitió su uso gratuito para uso personal y no comercial
y dio también licencia de uso gratuito a los sistemas operativos NetBSD, Free-
BSD, OpenBSD y Linux, incluso para uso comercial. Coincidiendo con esta
política de SSH Communications Security, Ltd., y bajo los auspicios de Open-
BSD, nace el proyecto OpenSSH, una implementación del protocolo SSH-2 ba-
jo licencia OpenBSD. Rápidamente muchos desarrolladores contribuyeron al
proyecto, lo que permitió su rápido crecimiento y que se pudiera portar de
OpenBSD a otros sistemas operativos, como Linux, Solaris o AIX.
Desde entonces existen dos implementaciones del protocolo SSH 2.0 disponi-
bles, la de la empresa SSH Communications Security, Ltd. y la de OpenSSH,
aunque es habitual en este último que coloquialmente se confunda el propio
protocolo con la implementación de OpenSSH.
De forma generalizada, podemos decir que existen tres casos de uso principales
de SSH:
1)�Administración�remota�de�recursos: esto puede incluir la administración

y configuración de servidores o equipos de red y la ejecución de aplicaciones
remotas.
2)�Transferencia�de�ficheros: proporciona servicios de seguridad a otras apli-

caciones que realizan transferencia de ficheros entre diferentes equipos, como
por ejemplo secure copy (SCP).
3)�Tunelización�de�conexiones: permite crear túneles (o canales de comuni-

cación únicos) entre dos equipos remotos, lo que implementa una red privada
virtual (conocida como VPN por sus iniciales en inglés) y asegura las comuni-
caciones.
1.1. Arquitectura del protocolo SSH
Desde el punto de vista de su utilización, el protocolo SSH tiene la ar-

quitectura de una típica aplicación cliente-servidor. En esta arquitectura
un cliente SSH inicia una conexión con un servidor SSH y, después de
la negociación de todos los parámetros de la conexión y de la autenti-
cación, se establece un canal para la comunicación.
Además, desde un punto de vista formal, la especificación del protocolo

SSH 2.0 está dividida en un conjunto de documentos: RFC4251, RFC4252,
RFC4253 y RFC4254. En estos documentos, se describe su arquitectura inter-
na y requerimientos técnicos de implementación. Una primera diferenciación
importante que hemos de tener en cuenta es la división del protocolo en tres
capas o componentes:
1)�Protocolo�de�la�capa�de�transporte (transport layer protocol): esta capa pro-

porciona los servicios de autenticación del servidor, confidencialidad e inte-
gridad. Además, de manera opcional puede proporcionar compresión. Habi-
tualmente estará utilizando una conexión TCP o IP existente, pero puede uti-
lizar otros protocolos de la capa de transporte.
2)�Protocolo�de�autenticación�de�usuario (user authentication protocol): au-

tentica al cliente y usuario con el servidor. Se ejecuta sobre el protocolo de la
capa de transporte.
3)�Protocolo�de�conexión (connection protocol): multiplexa y cifra el túnel en

diferentes canales lógicos. Se ejecuta sobre la capa del protocolo de autentica-
ción de usuario.
Figura 1. Capas del protocolo SSH
A continuación, presentaremos con más detalle los aspectos más relevantes de

cada una de estas capas.
1.2. Protocolo de capa de transporte
El objetivo principal de esta capa es establecer un canal de comunica-

ción seguro entre los dos equipos previamente a la autenticación y al
intercambio de datos en la comunicación.
Para conseguir este objetivo, se establece un conjunto de negociaciones entre

cliente y servidor para encontrar algoritmos que permitan implementar este
canal. Estos mensajes de establecimiento de parámetros comunes se conocen
con el término inglés de handshake (‘apretón de manos’).
Además, esta capa nos proporciona de forma opcional compresión de datos,

lo que disminuye el tiempo total de transmisión de la información.
1.2.1. SSH handshake
Como hemos introducido, en el SSH handshake se intercambia la información

clave para que cliente y servidor puedan construir correctamente la capa de
transporte previamente al intercambio de información.
Aquí podemos ver de forma esquemática todas las fases del SSH handshake:
Figura 2. Fases del SSH handshake
Fuente: www.rfwireless-world.com/Terminology/SSL-Handshake-Protocol-vs-SSH-Protocol-Stacks.html
En la figura anterior, podemos apreciar que tenemos el protocolo SSH ejecu-

tándose sobre TCP en la capa de transporte. Una vez realizada la negociación
TCP, empieza el SSH handshake. Podemos identificar como fases principales
las siguientes:
1)�Identification�string�exchange: ambas partes deben enviar una cadena de

identificación, en la que anuncian, entre otras, la versión del protocolo sopor-
tado.
Ejemplo de cadena de identificación
SSH-2.0-billsSSH_3.6.3q3<CR><LF>
2)�Algorithm�negotiation: es el comienzo de la fase de generación de claves que

permiten el cifrado y la autenticación y que es conocida como key exchange.
En este paso el cliente y el servidor se intercambian una lista de mensajes con
los algoritmos de compresión y cifrado que tienen disponibles. Tanto cliente
como servidor tendrán definidos unos algoritmos preferidos para los cuales
generan una clave inicial en este intercambio.
3)�Key�exchange: como continuación de la fase anterior, y una vez que clien-

te y servidor han acordado los algoritmos iniciales con los que se establecerá
la comunicación, comienzan a intercambiarse otra serie de mensajes con el
objetivo de generar dos valores: un secreto compartido K y una llave de inter-
cambio hash.h. El secreto compartido K es una clave simétrica que se utilizará
durante toda la conexión, incluido el proceso de autenticación. Por su parte, la
llave hash.h se utilizará con fines de integridad de datos y para verificar la au-
tenticidad de la conexión. Durante esta fase de intercambio de claves también
se produce la autenticación de servidor que veremos en el siguiente apartado.
4)�End�of�key�exchange: una vez terminado el intercambio de claves, los dos

sistemas empiezan a calcular nuevas claves y algoritmos que se utilizarán para
proteger la autenticación y los datos que se enviarán en la conexión posterior-
mente. Cuando se intercambian el mensaje SSH_MSG_NEWKEYS, se vuelven a
intercambiar mensajes de forma similar a como ha ocurrido en el proceso de
KEY_EXCHANGE para utilizar las nuevas claves.
5)�Service�request: después de que acabe la fase de key exchange, el cliente envía

una petición al servidor con el servicio que quiere utilizar. Este servicio está
identificado con un nombre. Actualmente están soportados los servicios ssh-
userauth y ssh-connection.
1.2.2. Autenticación del servidor
Como hemos introducido anteriormente, en la fase de key exchange también

se produce la autenticación del servidor. Tal como se describe en el RFC 4251,
cada servidor debería tener una clave que le identificará de forma única ante
el cliente, conocida como Host Key.
Un mismo servidor puede tener diferentes host keys para cada uno de los al-
goritmos que utiliza. De igual forma, diferentes servidores pueden compartir
la misma host key.
Durante esta fase de key exchange, el servidor se identificará ante el cliente con
la host key que tiene almacenada. Si el cliente no se había comunicado nunca
con este servidor, esta host key le resultará desconocida y, por tanto, no podría
autenticar con el servidor. Para resolver esta primera conexión OpenSSH, per-
mite que el cliente acepte la host key después de notificar al usuario y verificar
la aceptación por parte de este.
Figura 3. Ejemplo de menú de aceptación de host key por parte de cliente SSH
Fuente: es.ephesossoftware.com
En esta figura inicial, un atacante podría enmascararse como el servidor obje-

tivo para realizar una suplantación de este, por lo que es importante verificar
la identidad del host con el administrador de seguridad del mismo. Para co-
nexiones posteriores, el cliente ya dispondrá de la host key, con lo que podrá
garantizar que se está comunicando con el servidor correcto.
1.3. Protocolo de autenticación de usuario
Una vez asegurada la conexión con el protocolo de capa de transporte, el ser-

vidor informará al cliente de los diferentes métodos soportados para que se
autentique.
De esta forma se consigue que el servidor tenga completo control sobre

el proceso de autenticación al ser él quien presenta un listado de méto-
dos permitidos.
Adicionalmente, se recomienda que el servidor configure otros aspectos del

proceso de autenticación del cliente, como por ejemplo limitar el número má-
ximo de intentos fallidos de conexión o establecer un tiempo de espera máxi-
mo (timeout, en inglés) para esperar que se produzca la conexión.
Cuando el cliente recibe el listado de métodos soportados, tiene libertad para

elegir el método de autenticación de los presentados por el servidor, enviando
su petición de autenticación al servidor con el método escogido.
A continuación, introduciremos los principales métodos que puede presentar

el servidor al cliente para autenticarse. Cada uno de estos métodos está iden-
tificado con un nombre en el RFC 4252.
1.3.1. Autenticación con clave pública
El nombre de este método es publickey. Es el único método requerido y todas

las implementaciones de SSH 2.0 deben soportarlo.
En este método de autenticación, el cliente debe generar un par de claves: una

privada, que mantendrá de forma secreta, y una pública, que transferirá al ser-
vidor donde se quiere conectar. Para autenticarse, el cliente generará un men-
saje conocido como desafío (challenge message), lo firmará con su clave privada
y se lo enviará al servidor por el canal establecido de comunicación. Cuando el
servidor reciba este mensaje, al disponer de la clave pública del cliente, podrá
descifrarlo y contestar al cliente de forma que verifique su identidad.
Figura 4. Autenticación de usuario con clave pública
Una ventaja importante de este sistema de autenticación es que no crea rela-

ciones implícitas que permitan la autenticación, ya que solo las que se han
programado explícitamente están autorizadas.
1.3.2. Autenticación con contraseñas
Este método recibe el nombre de password. No es obligatorio, pero todas las

implementaciones de SSH 2.0 deberían soportarlo.
Es importante darse cuenta de que, aunque la contraseña se transmite en texto

claro, el paquete entero está cifrado en el túnel de comunicación creado con el
protocolo de la capa de transporte. Es responsabilidad tanto del cliente como
del servidor comprobar que la capa de transporte provee esta confidencialidad,
y en caso de que no sea así, desactivar la autenticación con contraseñas.
1.3.3. Autenticación basada en host
Este método recibe el nombre de hostbased. Es un método de autenticación

definido como opcional en el RFC. Su objetivo es dar cabida a los escenarios,
en los cuales en lugar de autenticar a un usuario se necesita autenticar el host
desde el cual se inicia la comunicación.
Al igual que en el método publickey, se requiere de la copia de la clave pública

del cliente SSH en el servidor SSH; en este método, en cambio, cada usuario
no tiene su propio par de claves, sino que es una única para el host cliente.
Es, por lo tanto, una configuración no apropiada para entornos que necesiten
implementar unos requisitos de seguridad altos.
En esta figura es responsabilidad del servidor verificar que la llave de host que
tiene actualmente almacenada corresponde con el nombre del cliente que se
envía en el mensaje. Adicionalmente se recomienda que el servidor realice al-
gunas otras comprobaciones adicionales, como, por ejemplo, comprobar que
la dirección de red del host coincide con la del nombre del host cliente trans-
mitido en el mensaje.
1.4. SSH connection protocol
Esta capa del protocolo SSH 2.0 multiplexa y cifra el túnel en diferentes
canales lógicos. Cada uno de estos canales administra la conexión para
cada una de las diferentes sesiones de terminal y también para sesiones
de reenvío de X11, lo que permite reenviar las sesiones gráficas.
Tanto el cliente como el servidor tienen la capacidad de crear un canal nuevo,

al que se le asignará un identificador diferente en cada extremo de la conexión.
Si el cliente intenta abrir un nuevo canal, envía al servidor la petición en la que
se incluye el nuevo número del canal. El servidor almacena esta información
y la usa para enviar la comunicación por ese canal.
Esta forma de administrar la comunicación entre cliente y servidor en forma

de canales permite que diferentes tipos de sesión no se afecten entre sí y la
posibilidad de cerrar un canal sin afectar la conexión SSH principal, que, como
habíamos visto, se negocia en el protocolo de la capa de transporte.
El protocolo define múltiples opciones para la apertura de canales, como, por

ejemplo, control de flujo, paso de variables a la shell remota o el envío de
señales.
1.5. Transferencia de ficheros con SSH: SCP y SFTP
El protocolo SSH no fue diseñado para realizar transferencias de archivos, por

lo que un cliente SSH no puede solicitar, por ejemplo, el envío de un fichero
por parte del servidor. Es en este contexto en el que surgieron aplicaciones que
se ejecutan sobre SSH para realizar este tipo de operaciones.
El primero de ellos es secure copy protocol (SCP), que es un protocolo que ga-
rantiza la transferencia segura de información entre un cliente y un equipo
remoto. Originalmente estaba basado en los comandos RCP, aparecidos en la
versión 4.2BSD en la Universidad de Berkeley (California).
Para lograr transmitir esta información es necesario que se establezca, con an-
terioridad, una conexión SSH entre el equipo local o cliente y el equipo remo-
to. Por tanto, necesitaremos poder autenticarnos contra el servidor remoto se-
gún el método de autenticación elegido, tal como explicamos en el protocolo
de autenticación de usuario (por ejemplo, con password).
Una vez establecida la conexión SSH, el cliente puede iniciar el proceso de co-
pia segura. Podemos ver en la siguiente figura el proceso de forma esquemática:
Figura 5. Proceso de copia mediante SCP
Fuente: blogs.oracle.com
SCP es un protocolo antiguo y que adolece de ciertas características de seguri-

dad. Los desarrolladores de OpenSSH, en las notas de lanzamiento de la ver-
sión 8.0 del software, desaconsejaron su uso:
«The scp protocol is outdated, inflexible and not readily fixed. We recommend the use
of more modern protocols like sftp and rsync for file transfer instead.»
SSH file transfer protocol (SFTP), o secure file transfer protocol, es un protocolo di-
señado por el IETF que proporciona transferencia segura de ficheros (y en ge-
neral acceso al sistema de ficheros del sistema). Fue propuesto como extensión
de SSH 2.0, pero es posible utilizarlo también sobre otros protocolos como TLS.
Este protocolo asume que se ejecuta sobre un canal confiable (como por ejem-
plo el definido para SSH en el RFC 4251), que el servidor ha realizado la auten-
ticación del cliente y que la identidad del cliente está disponible para SFTP. Es-
te último requisito es necesario para que pueda interactuar el programa cliente
de acceso a ficheros a través del túnel SSH.
El protocolo sigue un modelo simple de solicitud de respuestas. Cada solicitud

que se envía por parte del cliente SFTP contiene un número de secuencia que
la identifica. El servidor puede enviar diferentes respuestas asociadas a este
identificador de secuencia.
El cliente SFTP implementa la parte de cliente de este protocolo. Un ejemplo

de cliente SFTP es el programa sftp, suministrado con el paquete de OpenSSH.
El servidor SFTP lo podemos encontrar en algunas de las implementaciones de
servidores FTP, o bien como implementación del servidor SSH utilizado, que
comparte el puerto 22 con otros servicios.
1.6. Vulnerabilidades SSH
Hoy en día, SSH es el principal método de acceso usado para adminis-

tración remota de sistemas como servidores Unix o Linux o dispositivos
de red, como cortafuegos o enrutadores. Además, es un protocolo am-
pliamente utilizado para automatización de procesos entre servidores,
con lo que su seguridad es crucial para mantener intactos los recursos
e información de la organización.
La seguridad en el acceso SSH (tanto automatizado como interactivo) se ha

ignorado por muchas organizaciones que no tienen control sobre cuántas cla-
ves SSH se han configurado para dar acceso a determinados recursos o sobre
el número de copias de las claves. Esta situación se agrava debido a que las
cuentas asociadas a estas claves otorgan más privilegios de los realmente ne-
cesarios para realizar el objetivo solicitado.
Tal como indica el National Institute of Standards and Tecnology (NIST) en su

documento NISTIR 7966 – Security of Interactive and Automated Access Manage-
ment Using Secure Shell (SSH), podemos clasificar las vulnerabilidades de SSH
en las siguientes categorías:
• Vulnerabilidades�en�la�implementación: ocurre cuando la implementa-

ción del cliente o del servidor SSH presenta vulnerabilidades que pueden
ser aprovechadas por un atacante. Estas vulnerabilidades pueden ser debi-
do a debilidades en el proceso de desarrollo, debilidades de configuración
o debilidades del propio protocolo.
• Deficiente�configuración�de�los�controles�de�acceso: puede llegar a per-

mitir un acceso no autorizado. Es una configuración difícil de mantener y
actualizar, ya que están implicados diferentes controles: los propios de la
implementación del servidor SSH más los integrados en el sistema opera-
tivo subyacente, tales como el módulo de autenticación conectable (PAM),
Kerberos y otros componentes de seguridad.
• Política�deficiente�de�gestión�de�claves: corresponde con una mala po-

lítica de gestión de las claves, en las que no se controlen aquellas que han
sido robadas, débiles o de las que no podamos determinar su origen o
identidad.
• Puertas� traseras: en este caso la autenticación basada en clave pública

de SSH se utiliza para crear una puerta trasera que ignore el sistema de
control de acceso. Aprovecha la falta de controles de seguridad internos
(auditorías) de los ficheros que guardan las claves autorizadas de acceso
en los servidores SSH.
• Pivoting: se produce cuando un software malintencionado utiliza las cla-

ves SSH mal configuradas para saltar de un sistema a otro aprovechando
la red de conexiones interactivas y automatizadas que tienen los sistemas
configuradas por defecto.
• Falta�de�conocimiento�y�errores�humanos: la complejidad de la admi-

nistración y configuración de SSH puede provocar que muchos adminis-
tradores comentan errores que deriven en vulnerabilidades que pueden
pasar inadvertidos durante mucho tiempo y, por tanto, ser aprovechados
por un atacante. Una buena política de control y auditoría interna puede
detectar y solucionar estos errores.
2. TLS
Hoy en día, cada vez que alguno de nosotros navegamos por internet y utili-
zamos algún servicio de una página segura que disponga de certificados (como
por ejemplo una compra en línea) estamos utilizando en nuestras comunica-
ciones el protocolo�transport�layer�security (TLS).
TLS es la versión moderna de secure sockets layer (SSL), que fue el primer proto-
colo pensado para dar seguridad a la navegación web, y es por esta razón que
en muchas referencias técnicas lo vemos escrito como SSL/TLS. Comenzare-
mos con una breve historia de la evolución de este protocolo para centrarnos
posteriormente en sus características.
2.1. Introducción a SSL/TLS
Comenzaremos repasando el origen del protocolo y las diferentes versiones

que han ido apareciendo hasta el día de hoy.
2.1.1. Motivación y origen
Cuando apareció la red internet, la world wide web (WWW) y el protocolo HTTP
a principios de la década de los noventa, lo importante era el funcionamiento
de la red y la posibilidad de comunicarse con equipos remotos mediante la
navegación por sus páginas HTML.
Todos los protocolos que aparecían en esta época, como FTP, SMTP o el propio
HTTP no fueron diseñados con características de seguridad importantes, con lo
que poco a poco se fue viendo que era necesario implementar otros protocolos
que sirvieran para transportar la comunicación de los protocolos no seguros.
Es en este contexto en el que en 1994 la empresa Netscape, que en aquellos

momentos disponía de uno de los primeros navegadores para la WWW, lla-
mado Netscape Navigator, comienza a trabajar en un protocolo para dar segu-
ridad a las comunicaciones web, el protocolo SSL.
2.1.2. Versiones de SSL/TLS
A partir de este momento podemos considerar que comienza la historia de este

protocolo, que ha evolucionado de la siguiente forma a lo largo del tiempo:
Figura 6. Historial de versiones de los protocolos SSL/TLS
Fuente: dev.to/techschoolguru/a-complete-overview-of-ssl-tls-and-its-cryptographic-system-36pd
La primera versión desarrollada por Netscape fue SSL 2.0 y apareció en 1995
(la versión SSL 1.0 nunca llegó a aparecer debido a que era una prueba de con-
cepto). Esta versión SSL 2.0 fue integrada en el navegador Netscape Navigator,
pero rápidamente se dieron cuenta de que tenía muchos problemas de seguri-
dad y, en 1996, apareció una nueva versión, conocida como SSL 3.0.
En esta época comienza una lucha legal entre Microsoft y Netscape, propietaria
del protocolo, y a finales de los noventa, pasa a manos del IETF, que modifica
el nombre del protocolo a TLS para eliminar toda relación con la empresa
Netscape. Aparece en 1999 TLS 1.0, definido en el RFC 2246. Técnicamente
este protocolo supuso una mínima evolución respecto a SSL 3.0.
Se tardaron siete años en publicar una nueva versión del protocolo, y en el

año 2006 apareció la versión TLS 1.1, definida en el RFC 4346. En esta versión,
además de solucionar problemas de seguridad, se introdujeron las extensiones
a�TLS, que permiten añadir funcionalidades extra al protocolo.
Dos años más tarde, en el año 2008, aparece TLS v1.2, definida en el RFC
5246, que introdujo algunas novedades, como por ejemplo el soporte para la
autenticación.
Finalmente, en 2018, después de un gran proceso de revisión del protocolo,

apareció la versión TLS 1.3, definida en el RFC 8446, que veremos con detalle
en este apartado.
Nos podemos dar cuenta de que el proceso de diseño y definición de protoco-

los seguros para la red internet ha sido un proceso lento que no ha ayudado a
una rápida implantación de medidas de seguridad y era frecuente hasta hace
bien poco encontrarse muchos sitios de internet sin medidas de seguridad o
navegadores que soportaban versiones retiradas de los protocolos.
2.2. TLS 1.3
A continuación, nos centraremos en el estudio detallado de la última versión

del protocolo, TLS 1.3. Para ello introduciremos brevemente las diferencias
que tiene respecto a la versión 1.2, para después ver las diferentes partes que
lo integran y cuál es su modo de operación.
2.2.1. Diferencias con TLS 1.2
Como hemos comentado en la introducción histórica del protocolo, TLS 1.3

tardó ocho años en liberarse con respecto a la anterior versión, debido a que
se revisó a fondo con el objetivo de cubrir carencias detectadas en la anterior
versión. De forma esquemática, podemos agrupar los cambios en la nueva
versión en los siguientes grupos:
• Velocidad: se ha conseguido que TLS 1.3 sea más rápido y, por tanto, tenga
más rendimiento que su predecesor. Para ello, se ha modificado el TLS
handshake entre cliente y servidor, para intercambiar menos mensajes y
conseguir, por tanto, que el round-trip time (RTT) sea menor. Además, se
ha mejorado la reanudación de la sesión, lo que permite compartir los
mismos datos de clave secreta compartida entre varias conexiones, con lo
que se optimiza la latencia y los cálculos criptográficos necesarios.
• Seguridad: se han eliminado todas aquellas características obsoletas e in-

seguras, tales como los algoritmos SHA-1, RC4, DES, MD5, etc. Además,
también se ha deshabilitado en el handshake la opción de «compresión».
2.2.2. Descripción del protocolo
El principal objetivo de TLS es proporcionar un canal seguro de comu-

nicación entre dos nodos, y el único requisito subyacente para lograr
este objetivo es que exista una capa de transporte de datos confiable y
orientada a conexión, es decir, que entregue los paquetes en orden.
Este canal seguro de comunicación debe tener las siguientes propiedades:
• Autenticación: es obligatoria la autenticación del servidor, y es opcional

la del cliente. Esta autenticación se podrá realizar mediante criptografía
asimétrica, algoritmo digital de curva elíptica, algoritmo de firma digital
de curva de Edwards o una clave previamente compartida simétrica.
• Confidencialidad: los datos transmitidos por el canal solo serán visibles

para los nodos que se comunican.
• Integridad: los datos enviados por el canal no pueden ser modificados por
atacantes sin detectar esta modificación.
Las tres propiedades anteriores deberían cumplirse incluso aunque un atacante

tenga el control completo de la red.
En la siguiente figura se pueden ver los componentes del protocolo TLS:
Figura 7. Capas del protocolo TLS
Fuente: www.hep.by/gnu/gnutls/TLS-layers.html
Tenemos dos componentes principales, que son:
1)�TLS�handshake�protocol: se encarga de autenticar las partes en la comuni-

cación, negociar los módulos y parámetros criptográficos y establecer todas las
claves de codificación compartidas.
2)�TLS�record�protocol: utiliza los parámetros establecidos por el TLS hands-

hake protocol para proteger el tráfico entre las partes. Para ello divide el tráfi-
co en una serie de registros, cada uno de los cuales está protegido de forma
independiente.
Además de estos dos componentes principales, tenemos un tercer componente

de apoyo, que es el TLS alert protocol.
3)�TLS�alert�protocol: permite que se envíen señales entre los nodos de la co-

municación e informa a la otra parte de que ha ocurrido un fallo en el proto-
colo o el cierre de una conexión.
Como vemos en la figura anterior, también tenemos el llamado protocolo de

aplicación, que en este caso sería aquel que utilizará el canal de TLS creado. El
protocolo TLS, por lo tanto, es un protocolo independiente del protocolo de
aplicación utilizado con lo que estos protocolos de aplicación pueden usarlo
de forma transparente.
2.2.3. TLS handshake protocol
Como hemos comentado en la introducción al protocolo, este se encarga de

autenticar a las partes en la comunicación, negociar los módulos y parámetros
criptográficos y establecer todas las claves de codificación compartida. En la
siguiente figura podemos ver una figura del funcionamiento del protocolo y
las diferencias con la versión TLS 1.2:
Figura 8. TLS handshake en TLS 1.2 y TLS 1.3
Fuente: www.cdn77.com/blog/improving-webperf-security-tls-1-3
Como podemos ver en la figura anterior, el tiempo del handshake se ha redu-

cido, al unir los mensajes de ClientHello y KeyShare en un solo mensaje.
El mensaje ClientHello está compuesto por una serie de campos en los que el
cliente se anuncia y comienza a proponer opciones para la negociación de los
parámetros. Algunos de estos campos se conservan por interoperabilidad con
versiones anteriores del protocolo, como el campo Client_Version, que se
anuncia con un valor de «0x0303», correspondiente a TLS 1.2. Posteriormente,
se introduce una extensión para la negociación real en la versión 1.3. De igual
forma ocurre con el campo SessionID, que ya no es necesario en TLS 1.3, y al
que se rellena con un valor aleatorio. Los diseñadores del protocolo debieron
tener en cuenta todas estas cuestiones de interoperabilidad para que todo el
software que se ejecuta en los nodos intermedios de la comunicación TLS no
se viera afectado.
También en el mensaje ClientHello se envía una lista de algoritmos simétri-

cos de cifrado soportados por el cliente y se desactiva poniendo el valor NULL,
la opción de compresión del protocolo, para aumentar la seguridad y evitar
ataques como CRIME, que compromete la integridad de las sesiones HTTP.
Por último, también se envía en este mensaje un conjunto de extensiones

soportadas por el cliente. En TLS 1.3 el uso de ciertas extensiones es obligatorio
y, al igual que comentábamos anteriormente, esto permite compatibilidad con
versiones anteriores del protocolo. En estas extensiones que envía el cliente,
se envían parámetros, como el algoritmo de firma, las claves públicas o los
modos disponibles para establecer claves compartidas.
Cuando el servidor recibe el mensaje ClientHello, contestará con un men-

saje ServerHello para proceder con el handshake si considera que es capaz
de negociar un conjunto de parámetros lo suficientemente seguros para esta-
blecer el canal.
La estructura del mensaje ServerHello es similar a la estructura del Client-

Hello y, por tanto, en esta respuesta el servidor tiene que seleccionar todos
los parámetros necesarios para establecer la comunicación y enviar aquellas
extensiones que sean obligatorias al cliente.
Una vez que el cliente recibe el mensaje ServerHello, tiene que contestar
al servidor, para que este sepa que el cliente ha recibido los parámetros. Esta
respuesta, llamada client handshake finished, puede viajar dentro de la petición
de la capa de aplicación (por ejemplo, una petición GET), con lo que se con-
sigue terminar el handshake en este primer mensaje de intercambio de datos
de las aplicaciones.
Hay un tipo adicional de mensaje relacionado con el handshake que pueden

intercambiar cliente y servidor. Se trata del HelloRetryRequest. El servidor
enviará este mensaje en respuesta a un ClientHello si es capaz de encontrar
un conjunto de parámetros aceptables para la comunicación, pero el mensaje
ClientHello no contiene suficiente información en otros campos para com-
pletar el handshake.
Si ocurre un error en el handshake, se terminará la conexión y, opcionalmente,

puede ir precedido de la generación de un mensaje de alerta.
2.2.4. TLS record protocol
Una vez establecido el canal, el TLS record protocol recibe los mensajes que tie-
nen que ser transmitidos, los fragmenta en bloques, protege los registros y
transmite el resultado por el canal. Una vez recibidos los datos, estos se verifi-
can, descifran, se vuelven a ensamblar y se entregan a la capa de nivel superior.
De forma general, podemos decir que todos los mensajes e información que se
intercambian cliente y servidor se convierten en un tipo de registro llamado
TLSPlainText, con un tamaño de fragmento máximo de 214 bytes. El tamaño
exacto del fragmento dependerá del tipo de contenido, con una serie de reglas
que se deben respetar según el RFC 8446.
Si se está encapsulando un mensaje del TLS handshake protocol, como por ejem-
plo ClientHello, una vez creado el registro se escribirá inmediatamente en
la capa de transporte subyacente.
En el caso de que no sean mensajes de este protocolo y tengamos datos de

la aplicación, estos se convierten a un registro del tipo TLSCiphertext, el
cual añade protección cifrando los datos antes de que se escriba en la capa de
transporte. De igual manera ocurre si es un mensaje del TLS alert protocol, a los
que también se les añade protección. Aquí podemos ver de forma esquemática
este proceso:
Figura 9. Proceso de trabajo del protocolo TLS record protocol
Fuente: www.slideshare.net/yassl/wolfssl-and-tls-13
Por tanto, si un servidor recibe un registro TLSCiphertext antes que el pri-

mer ClientHello o después de un mensaje de finalización, debe tratar es-
te mensaje como un tipo de registro inesperado y descartarlo generando un
mensaje de alerta unexpected message.
2.2.5. TLS alert protocol
El objetivo del TLS alert protocol es que se puedan enviar mensajes de señaliza-
ción entre cliente y servidor. Al igual que otros mensajes, los mensajes gene-
rados por TLS alert protocol se cifran con las claves de seguridad de la conexión
actual.
Los mensajes generados por el protocolo pueden ser de dos clases: de cierre o
para informar sobre un error:
1)� Los� mensajes� de� cierre se utilizan para informar del cierre ordenado de
una conexión. El nodo que es informado del cierre de la conexión, al recibir
dicha alerta debe indicar el final de los datos a la aplicación. En el RFG 8446
tenemos definidos dos mensajes de cierre: close_notify y user_canceled.
2)�Las�alertas�de�error indican el cierre repentino de la conexión debido al

error generado. El nodo que es informado debe indicar un error a la aplicación
y no debe permitir enviar o recibir más datos sobre la conexión. Existen de-
finidos más de veinte tipos de mensajes de error en el RFC 8446, como, por
ejemplo: certificate_required o internal_error. Además, se ha defi-
nido un mecanismo de extensión de nuevos mensajes de error mediante IANA.
2.3. Protocolos que utilizan TLS
Como parte final del estudio de TLS, vamos a presentar algunos ejemplos de
su adopción por protocolos de la capa de aplicación que no estaban diseñados
con características de seguridad intrínsecas. Estos ejemplos no suponen una
lista exhaustiva de todos los protocolos de capa de aplicación que soportan
TLS, sino que se han escogido por su uso en servicios de amplia difusión, como
la navegación web o el correo electrónico.
2.3.1. HTTPS
El aumento de las comunicaciones por internet con HTTP y el uso de aplica-

ciones con información sensible, llevó a crear un nuevo protocolo, llamado
HTTPS y definido en el RFC 2818, para utilizar HTTP sobre un canal SSL/TLS
para dotarlas de seguridad.
Conceptualmente, HTTPS es sencillo de entender: usa HTTP sobre TLS de la

misma forma que se usaría HTTP sobre TCP. Podemos verlo aquí de forma
gráfica:
Figura 10. Pila de protocolos en HTTP y HTTPS
Fuente: code.tutsplus.com/es/tutorials/http-the-protocol-every-web-developer-must-know-
part-2--net-31155
El agente que actúa como cliente HTTP también debe hacerlo como cliente
TLS y, por lo tanto, para iniciar una conexión tendrá que enviar al servidor el
mensaje TLS ClientHello. Una vez que el handshake haya concluido, ya se
podrá enviar sobre el canal la primera petición HTTP.
Como resultado, vemos que un servidor HTTPS la primera petición que espe-
ra recibir es un ClientHello, diferente de lo que espera un servidor HTTP.
Es, por lo tanto, recomendable, a efectos prácticos, que escuchen en puertos
diferentes, y el puerto predeterminado para HTTPS es el 443.
Además, el formato de uniform resource identifier (URI) se diferencia también Ejemplo

mediante el uso de «https» en lugar de «http».
Un URI HTTPS válido se-
ría, por ejemplo, <https://
Un punto importante en HTTPS es la identificación�del�servidor, que debe www.example.com/>
disponer de un certificado emitido por una autoridad de certificación que per-

mita al cliente certificar que el titular del certificado es quien dice ser.
Normalmente, el cliente conoce el nombre del host del servidor, y este se co-
difica en la URI. En estos casos, el cliente debe comparar este nombre de host
con el que aparece en el certificado.
En algunos otros casos está especificada la dirección IP en lugar del nombre

del servidor. En estos casos, para poder verificar la identidad del servidor debe
estar la dirección IP en el campo subjectAltName.
En el caso de que el nombre del host o la IP no coincidan con la información

del certificado, los clientes deben notificar al usuario, dando la oportunidad de
cerrar la conexión o continuar con ella informando de los riesgos de seguridad
que esto supone.
Por último, recordemos que en TLS la autenticación del servidor es obligatoria

y la autenticación del cliente es opcional, con lo que podríamos configurar
también que el servidor autenticará también al cliente HTTPS.
Hoy en día, prácticamente todos los navegadores disponibles soportan TLS 1.3 Enlace recomendado
en sus últimas versiones.
Podéis comprobar el sopor-
te para un navegador y ver-
2.3.2. SMTP, IMAP y POP3 sión concreta en páginas co-
mo, por ejemplo: <https://
caniuse.com/tls1-3>
Los protocolos utilizados para el envío y recepción del correo electrónico, co-
mo simple mail transport protocol (SMTP), post office protocol versión 3 (POP3)
o internet message access protocol (IMAP), son similares conceptualmente al de
HTTP. Son protocolos que fueron diseñados al principio de las comunicaciones
de internet y, por lo tanto, sin funciones intrínsecas de seguridad. Podemos
ver el uso de cada uno de estos protocolos de forma general la siguiente figura:
Figura 11. Uso de los protocolos SMTP, POP3 e IMAP
Fuente: www.hostinger.es/tutoriales/smtp-pop-imap
A principios de 1997, IANA registró el puerto 465 para su utilización en el

intercambio de correo electrónico de forma cifrada. El puerto, conocido como
smpts, no se utilizó, ya que el software encargado del transporte SMTP siempre
enviaba el correo por el puerto 25. Como resultado, este registro de IANA fue
revocado y posteriormente reasignado a un registro diferente.
A principios de 1998, se estandarizó STARTTLS (también conocido como TLS

oportunista). Define un conjunto de extensiones a protocolos de comunica-
ción en texto plano, para actualizar la conexión actual a una conexión cifra-
da, sin usar un puerto separado para ello. La extensión STARTTLS para IMAP
y POP3 se define en el RFC 2595 y la extensión STARTTLS para SMTP en el
RFC 3207 (hay extensiones STARTTLS para otros protocolos, tales como FTP,
LDAP o XMPP).
La principal característica del uso de STARTTLS es que podemos actualizar una

conexión a un canal seguro y seguir usando el mismo número de puerto que
la conexión no segura. Es decir, podríamos seguir utilizando los puertos que
define IANA para SMTP (25), IMAP (143) o POP3 (110). Aquí podemos ver un
ejemplo del intercambio de mensajes para una conexión SMTP:
Figura 12. Conexión SMTP con STARTTLS
Fuente: www.redeszone.net
En el caso de SMTP podemos diferenciar dos tipos de tráfico de correo elec-

trónico:
• SMTP transfer, que ocurre entre servidores de correo electrónico.
• SMTP submission, que ocurre entre el agente de usuario y su servidor de

correo electrónico.
Al principio, ambos tipos de comunicaciones utilizaban el puerto 25. Poste-

riormente, debido a los problemas de envío de correo basura (spam, en inglés)
y a la necesidad de proveer mecanismos de autenticación para el usuario, en
el RFC 2486 se definió el puerto 587 para el tráfico SMTP submission.
Adicionalmente al método STARTTLS, o TLS oportunista, también se definió

un TLS�implícito, en el que se hace toda la comunicación TLS por un número
de puerto diferente (al igual que ocurre con HTTPS). El RFC 8314, publicado
en 2018, recomienda el uso de TLS implícito sobre STARTTLS para fomentar
una mayor coherencia respecto al uso de TLS.
Esto supone dedicar un puerto separado para los diferentes protocolos. En el

caso de POP3, se usa el puerto 995 y, en el caso de IMAP, el 993. En ambos
casos, una vez comenzado el TLS handshake los clientes deben comenzar la
validación del certificado del servidor.
En el caso de SMTP, el documento RFC recomienda que se implemente, en la

medida de lo posible TLS sobre el puerto 465. Como este registro fue asignado
y posteriormente revocado por IANA para smtps, existen hoy en día algunos
problemas de compatibilidad con determinado software que, tal como reco-
mienda este RFC, deberían actualizarse para poder utilizar SMTP submission
sobre este puerto.
2.4. TLS en las redes privadas virtuales
Como último punto de este apartado, vamos a hacer una pequeña mención
a uno de los usos más habituales hoy en día del protocolo TLS, en concreto
su uso en redes privadas virtuales.
Podemos definir una red privada virtual (virtual private network, VPN,
por sus siglas en inglés) como una tecnología de red que permite una
extensión de la red privada de la organización sobre una red pública
como internet.
La implementación de una VPN se suele realizar creando túneles donde la in-

formación que atraviesa la red pública viaja encapsulada dentro de los paque-
tes de otro protocolo, normalmente IP. Existen diferentes tecnologías con las
que implementar estos túneles, siendo SSL/TLS una de las más utilizadas hoy
en día.
Las VPN basadas en SSL/TLS ofrecen confidencialidad, autenticación e inte-

gridad de datos y gozan de gran popularidad, debido a que muchas de sus im-
plementaciones (aunque no todas) presentan al usuario un acceso web desde
el navegador con el que conectarse a los recursos de la organización.
3. IPSEC
IP security protocol (IPSec) es un conjunto de protocolos de seguridad diseñados

para garantizar la seguridad de todas las comunicaciones IP entre dos o más
participantes. Tiene múltiples aplicaciones de seguridad, entre ellas las redes
privadas virtuales.
3.1. Introducción y arquitectura IPSEC
IP security protocol (IPSec) es un estándar del IETF que proporciona ser-

vicios de seguridad a la capa IP y a los protocolos de las capas superiores,
tales como UDP o TCP.
Está diseñado para trabajar tanto con la versión IPv4 como con la versión
IPv6 del protocolo IP. Entre los servicios de seguridad que se ofrecen están el
control de accesos, la integridad, confidencialidad, autenticación del origen
de los datos o protección contra repeticiones.
Para conseguir estos objetivos de seguridad, IPSec combina tecnologías de cla-

ve pública, algoritmos de cifrado simétricos, algoritmos de hash y certificados
digitales. Debido a su diseño modular, se pueden seleccionar el conjunto de
algoritmos deseados para cada una de estas tecnologías sin afectar a otras par-
tes de la implementación.
Podemos distinguir los siguientes componentes principales dentro de IPSec:
• Protocolos�de�seguridad: concretamente dos, AH (authentication header)

y ESP (encapsulating security payload).
• Protocolo�de�gestión�de�claves: IKE (internet key exchange), que permite

negociar las claves y parámetros para una conexión AH o ESP.
Otro concepto importante que no podemos olvidar en IPSec son sus dos posi-
bles modos de funcionamiento para cada uno de sus protocolos de seguridad:
modo�transporte y modo�túnel.
3.2. AH
El protocolo authentication heatder (AH) es el encargado dentro de IPSec de

dotar las comunicaciones de integridad y autenticación de los datagramas IP.
Es decir, proporciona al receptor de los paquetes un mecanismo de verificación
del origen y la no alteración de los datos.
Para el protocolo IP, AH es un protocolo nuevo con un número de protocolo

diferente dentro de su cabecera. Por lo tanto, el valor del campo protocolo
dentro de la cabecera IP no corresponde con los valores de TCP o UDP (6 o 17),
sino con el de AH (51). AH asegura la integridad y autenticidad de todos los
datos de la cabecera IP, excepto aquellos que son variables, como por ejemplo
TTL.
Para lograr dotar al datagrama de autenticidad e integridad, AH utiliza un al-

goritmo de autenticación de mensajes HMAC, que aplica un algoritmo de hash
a los datos de entrada a partir de una clave.
3.2.1. AH en modo transporte
En este modo de funcionamiento, el contenido transportado dentro del da-

tagrama AH son los datos de la capa de transporte (TCP o UDP). Es decir, la
cabecera AH se colocará detrás de la cabecera IP y antes de los datos de esta
capa de transporte:
Figura 13. Protocolo AH en modo transporte
3.2.2. AH en modo túnel
En este modo el contenido del datagrama AH es un datagrama IP completo,

incluida la cabecera IP original. Por lo tanto, después de insertar la cabecera
AH se tiene que añadir una nueva cabecera IP, que es la que nos permitirá que
el paquete llegue al nodo destino:
Figura 14. Protocolo AH en modo túnel
Con el modo túnel conseguimos ocultar la identidad (direcciones IP) de los

nodos participantes en la comunicación, ya que está protegida por la nueva
cabecera IP.
3.3. ESP
Además de ofrecer (opcionalmente) integridad y autenticidad del ori-

gen, el protocolo encapsulating security payload (ESP) es capaz de propor-
cionar confidencialidad cifrando los datos del datagrama IP.
Al igual que en el protocolo AH, el protocolo ESP tiene asignado un número

de protocolo para identificarlo dentro de la cabecera IP, en este caso el 50.
Para conseguir el cifrado de los datos se utiliza un algoritmo de clave simétrica,

normalmente alguno de cifrado de bloque. Es por esta razón que se incorpo-
ra un campo adicional de relleno dentro de la cabecera ESP (ESP trailer) que
permite que la longitud del bloque sea múltiplo del tamaño que necesita el
algoritmo.
3.3.1. ESP en modo transporte
Al igual que en el protocolo AH en modo transporte, ESP protege los datos de

la capa de transporte (TCP o UDP). La parte final de la cabecera ESP es opcional
y aparecerá si ESP provee de servicios de autenticación de origen.
Figura 15. Protocolo ESP en modo transporte

3.3.2. ESP en modo túnel
En este caso protegemos todo el datagrama IP original, añadiendo como en el

caso anterior de AH una nueva cabecera IP:
Figura 16. Protocolo ESP en modo túnel
3.4. Protocolo de gestión de claves
Todos los parámetros de seguridad necesarios para utilizar AH o ESP se gestio-

nan mediante el protocolo de gestión de claves internet key exchange (IKE).
Antes de presentar IKE, tenemos que introducir un concepto fundamental en

IPSec, llamado asociación�de�seguridad (SA). Una SA es un canal de comuni-
cación unidireccional que conecta dos nodos participantes en una comunica-
ción IPSec. Por lo tanto, al ser unidireccional una conexión entre dos nodos
IPSec, requerirá de dos SA, una para cada sentido de la comunicación.
Por lo tanto, para iniciar una comunicación IPSec ambos nodos deben tener
configurada una SA con los parámetros necesarios para enviar o recibir infor-
mación con AH o ESP. Esta configuración de SA podría realizarse de forma
manual en cada uno de los nodos, aunque resultaría bastante costoso a nivel
de tiempo y propenso a errores.
Es por esta razón por la que el IETF definió el protocolo IKE, que permite
una gestión automática de claves y establecer a partir de ellas las SA
resultantes. IKE, por lo tanto, es un protocolo de gestión de claves y
su utilidad va más allá de IPSec, por lo que se puede utilizar en otros
escenarios.
IKE es un protocolo resultante de la integración de otros dos protocolos:

ISAKMP y Oakley. Del primero IKE utiliza la sintaxis de los mensajes que se
intercambian entre los nodos, y del segundo, la lógica para realizar el inter-
cambio de claves entre los participantes en la comunicación.
Para conseguir su objetivo, IKE trabaja en dos fases:
1) Una primera fase en la que ambos nodos establecen un canal seguro de

comunicación. Este canal se consigue mediante el intercambio de mensajes
HMAC y algoritmos de cifrado simétrico. Las claves necesarias para esta fase
se obtienen a partir de una clave maestra generada con el algoritmo de inter-

cambio de clave «Diffie-Hellman». Esta primera fase puede contar además con
un paso adicional para la autenticación de los nodos, bien mediante una clave
compartida conocida con anterioridad, o bien mediante certificados digitales
«x509v3».
2) En la segunda fase se utilizará el canal creado para negociar los parámetros

necesarios de trabajo para AH o ESP. El nodo que inicia la comunicación in-
forma de todas las posibilidades que tiene configuradas, con la prioridad aso-
ciada a cada una de ellas. El nodo receptor aceptará, de las opciones que re-
ciba, aquella configuración que tenga definida dentro de sus parámetros de
seguridad.
Podemos ver estas dos fases de forma esquemática en la siguiente figura.
Ejemplo
En la primera fase del protocolo IKE phase 1 se establece un canal seguro de comunicación.
En la segunda fase, IKE phase 2, se negociarán los parámetros de trabajo AH o ESP.
Figura 17. Fases del protocolo IKE
Fuente: https://vilarrasa.com.ar/ike_timeout.htm
3.5. IPSec en las redes privadas virtuales
Al igual que hicimos con el protocolo TLS, vamos a mencionar uno de los
principales usos de IPSec hoy en día, como protocolo para crear redes privadas
virtuales (virtual private network, VPN, por sus siglas en inglés).
Uno de los usos más habituales de IPSec en VPN es crear una configu-
ración conocida como site-to-site VPN, en la que se conectan dos sedes
remotas por una red pública como internet, con el direccionamiento
público conocido por ambos.
Para ello, se configuran cada uno de los equipos que acceden a la red pública
en cada sitio (normalmente cortafuegos), como punto de acceso de un túnel
IPSec, y se ocultan todas las direcciones internas de las redes privadas dentro
del tráfico IPSec. Estos dos equipos serán los que negocien las SA con el pro-
tocolo IKE:
Figura 18. VPN con el protocolo IPSec
Fuente: https://techbast.com/2016/07/sphos-xg-configure-ipsec-vpn-connection.html
Una vez realizada esta configuración, los equipos de la red interna de cada
sitio podrán comunicarse entre ellos por el túnel, como si fueran dos redes de
área local de la misma sede física.
Además de la configuración site-to-site, IPSec también puede utilizarse para

VPN de acceso remoto, en la que un cliente se conecta a un servidor VPN que
permite acceder a los recursos compartidos de la organización.
Por último, hay que mencionar también que IPSec ofrece el soporte de seguri-
dad en las VPN que están basadas en el protocolo L2TP (layer-2 tunnel protocol),
ya que este protocolo no fue diseñado con características intrínsecas de segu-
ridad, y la IETF puede usarlos de manera conjunta para crear VPN confiables.
4. RADIUS
Remote authentication dial-in user service (RADIUS) es un protocolo de autenti-

cación, autorización y auditoría que nació en 1991 a partir de una necesidad
existente en esta época: controlar y garantizar el acceso a recursos de compu-
tación que eran accedidos de forma heterogénea.
4.1. Historia de RADIUS
La empresa Merit Network en 1991 requería de un sistema de control de acceso

por línea telefónica para la red National Science Foundation’s Network (NSF-
Net), red dedicada a la investigación y a la educación y que fue el reemplazo
de ARPANET como backbone de internet), ya que muchos clientes usaban di-
ferentes sistemas de autenticación, autorización y auditoría.
Ante esta necesidad de Merit Network, la empresa Livingston Enterprises creó

un primer borrador del protocolo RADIUS y, posteriormente, escribió la pri-
mera versión del servidor, que se instaló en un sistema operativo UNIX. Pasado
un tiempo, Livingston (adquirida por Lucent) y Merit ofrecieron a la industria
el servidor RADIUS sin cargo, lo que llevó a publicar las primeras RFC en 1997.
Unos años más tarde, en junio del año 2000, estas RFC fueron reemplazadas
por las RFC 2865 y 2866, que actualizan los aspectos más importantes del
protocolo RADIUS. Desde entonces han ido apareciendo diferentes RFC que
complementan la RFC 2865 y 2866 y añaden soporte a nuevas funcionalidades
y protocolos que han aparecido durante estos años.
RADIUS fue, por lo tanto, el primero de los protocolos pertenecientes a la

familia de protocolos conocidos como authentication, authorization y accounting
(AAA), ya que era necesario controlar estos tres aspectos en el acceso de los
usuarios mediante las líneas telefónicas.
4.2. Arquitectura y funcionamiento de RADIUS
La especificación de RADIUS indica que es un protocolo sin estado y

que debe usar como protocolo de transporte el protocolo UDP (concre-
tamente en el puerto 1812). Se concibió de esta forma para poder aten-
der a multitud de clientes que entraban y salían de las conexiones por
línea telefónica y, además, hacerlo de la forma más rápida posible.
En la arquitectura más habitual de RADIUS tenemos:

• Cliente: que realiza la petición de autenticación. Esta petición se realiza,

bien utilizando PPP (en las primeras épocas de RADIUS), o bien, hoy en
día, más habitualmente por LAN con protocolos como HTTP o HTTPS.
• Network�access�server�(NAS): es el punto central de acceso a la red y en-

cargado de recoger las peticiones de los clientes y enviarlas al servidor RA-
DIUS. Podemos, por lo tanto, ver que el NAS actúa como cliente RADIUS.
• Servidor� RADIUS: es el encargado de recibir el paquete enviado por el

cliente RADIUS y verificar contra el backend de autenticación (por ejemplo,
una base de datos o un servicio de directorio) si las credenciales del usuario
son correctas.
Todos los paquetes que se intercambian el cliente y el servidor RADIUS tienen

el siguiente formato:
Figura 19. Formato del paquete RADIUS
• Code: tipo de mensajes RADIUS.
• Identifier: campo para relacionar peticiones y respuestas.
• Length: longitud total del paquete, incluyendo todos los campos.
• Authenticator: se usa para autenticar la respuesta recibida del servidor RA-

DIUS. También se usa en los passwords cifrados.
• AVPS: son campos opcionales que, de estar presentes, transportan infor-

mación relacionada con la autenticación, autorización o accounting. En su
primera versión RADIUS proporcionaba más de cincuenta pares «atribu-
to-valor» y permitía, además, que los fabricantes crearan los suyos propios.
Los paquetes que se envían entre el cliente y el servidor RADIUS (cabe recordar
que el cliente RADIUS es el servidor NAS, no los usuarios finales) deben ir
autenticados usando una clave compartida o secreta, la cual no se envía nunca
por la red. Las contraseñas de usuario son cifradas entre el cliente y el servidor
RADIUS con el algoritmo MD5.
RADIUS soporta de forma nativa dos protocolos de autenticación: PAP y CHAP.

El primero de ellos, PAP, es un protocolo simple de autenticación. Cuando
tiene lugar la autenticación PAP, el NAS recoge el PAP ID y el password y lo
envía al servidor RADIUS en un paquete Access-Request, como UserName y
User-Password. Opcionalmente, el NAS puede incluir otros atributos, como
Service-Type o Framed-Protocol.
CHAP es un protocolo de desafío-respuesta, en el que el servidor RADIUS envía

un paquete de desafío al cliente antes de que este se pueda autenticar. Podemos
ver la secuencia en este diagrama:
Figura 20. Protocolo RADIUS con autenticación CHAP
4.3. Alternativas a RADIUS: DIAMETER y TACACS+
Cuando en el año 2000 se publicó el RFC de RADIUS, surgió en el IETF un

grupo de trabajo denominado AAA que se puso a trabajar en un protocolo que
fuese el sucesor de RADIUS. Después de una fase de estudio inicial, se decidió
evolucionar el protocolo DIAMETER, intentando maximizar la compatibili-
dad con RADIUS y facilitar la migración desde este.
DIAMETER está definido en el RFC 6733 y entre sus principales diferencias

con RADIUS, podemos citar:
• Ya no es un protocolo cliente-servidor como RADIUS, sino que es más bien

un protocolo peer-to-peer, por lo que permite, por lo tanto, que los mensajes
se inicien también en el servidor.
• Utiliza protocolos de transporte fiables, como TCP o SCTP, en lugar de

UDP.
• Se dota de capacidades de seguridad mediante protocolos como TLS o

IPSec. Todas las implementaciones de servidores o clientes deben soportar
IPSec ESP en modo transporte y utilizar IKE para autenticación, negocia-
ción de asociaciones de seguridad y gestión de claves. Además, los servi-
dores DIAMETER tienen que soportar TLS, mientras que esto es opcional
para los clientes.
• Presenta algunas otras características, como por ejemplo la negociación de

capacidades entre los peers o una mejor notificación de errores.
Por su parte, TACACS+ es un protocolo AAA propietario de Cisco, evolución de

TACACS (también propietario de Cisco, aunque incompatibles entre ambos).
Al ser un protocolo propietario, no es un estándar de internet del IETF, pero sí
que tiene un documento RFC con objeto informativo, concretamente el RFC
8907, de septiembre de 2020.
Entre sus principales características, cabe destacar las siguientes:
• Utiliza TCP como protocolo de la capa de transporte.
• Al igual que RADIUS, tiene una arquitectura cliente y servidor, en la que

la comunicación la inicia el cliente.
• Las capas de autenticación y autorización son independientes, lo que per-

mite, por ejemplo, utilizar autenticación con un protocolo diferente de
TACACS y la autorización con TACACS +.
• Es especialmente útil en la gestión de enrutadores, ya que presenta dos

métodos de autorización de los comandos de un router: por usuarios y por
grupos.
5. EAP (protocolo de autenticación extensible) y

802.1x
En este apartado introduciremos el marco de autenticación EAP y su uso en el

protocolo 802.1x de control de acceso a la red basado en puertos.
5.1. EAP (protocolo de autenticación extensible)
Extensible authentication protocol (EAP) es un marco de autenticación (frame-

work) que soporta diferentes métodos de autenticación, conocidos como mé-
todos�EAP.
EAP define un formato de trama y unos tipos de mensajes que los dis-
tintos métodos de autenticación utilizarán en el proceso de autentica-
ción. Provee funciones comunes de negociación para los métodos EAP
soportados. Está definido en el RFC 3748.
5.1.1. Arquitectura y modo de funcionamiento
EAP se ejecuta normalmente directamente sobre la capa de enlace, sin necesi-

dad de IP. Originalmente se usaba en PPP y hoy en día se utiliza tanto en redes
inalámbricas (WLAN) como en redes cableadas (LAN).
En la arquitectura EAP podemos definir las siguientes entidades:
• Peer: punto final del enlace (cliente) que responde al autenticador. Vere-
mos que en el protocolo 802.1x se le conoce como suplicante (supplicant,
en inglés).
• Authenticator: punto final del enlace (servidor) que inicia la autentica-

ción EAP. Por lo tanto, la autenticación EAP se inicia en el servidor, a di-
ferencia de otros muchos protocolos de autenticación que comienzan en
el cliente. Esto puede suponer, dependiendo del método EAP, que algún
algoritmo necesite añadir uno o dos mensajes adicionales para completar
la autenticación.
• Backend�server: cuando se utiliza, es una entidad que proporciona un ser-

vicio de autenticación a un autenticador. Es decir, ejecuta métodos EAP pa-
ra el autenticador. Estos servidores de backend normalmente utilizan pro-
tocolos AAA que soportan EAP, tales como RADIUS o DIAMETER. Cuando
existe esta entidad, la arquitectura se referencia como pass-through.
Figura 21. Arquitectura EAP pass-through
Como vemos en esta figura, la separación por capas permite una arquitectura
modular en la que podemos añadir un servidor de autenticación. En el caso
de no tener este servidor, el authenticator tendría la capa con los métodos EAP.
Las funciones de cada una de las capas son siguientes:
• Low�layer: transmitir y recibir las tramas EAP entre peer y authenticator. EAP
se ejecuta sobre diferentes protocolos, como, por ejemplo: PPP, protocolos
de LAN 802.x, protocolos 802.11 wireless LAN, etc.
• EAP� layer: recibe y transmite los paquetes EAP recibidos de low layer, e
implementa la detección de duplicados y retransmisión. También recibe y
transmite paquetes con la capa superior (EAP peer o EAP authenticator).
• EAP�peer�y�EAP�authenticator�layer: analizan el mensaje EAP y lo envían

al método EAP correspondiente.
• EAP�method�layer: es la capa que implementa directamente los algoritmos

de autenticación. Es interesante citar que el protocolo EAP no provee de
fragmentación entre sus capacidades, por lo que será el método EAP co-
rrespondiente quien tenga que proporcionarla en caso de necesitarse.
Podemos encontrarnos casos en los que el authenticator, por ejemplo, un net-

work access server (NAS), tenga un comportamiento pass-through para los peers
remotos y al mismo tiempo actúe como authenticator final para los peers locales.
5.1.2. Métodos EAP de autenticación
Como hemos introducido, EAP es un marco de autenticación que soporta di- Enlace recomendado
ferentes métodos de autenticación. Existen métodos de autenticación descri-
Podéis consultar todos los
tos en el RFC 3748 que describe EAP (como por ejemplo EAP MD5), otros des- métodos de autenticación
critos en RFC propios (como por ejemplo EAP TLS en el RFC 5216) y existen disponibles y la lista de có-
digos de tipo y paquetes uti-
algunos específicos de proveedores. Cada uno de estos tipos de métodos debe lizados en EAP en el regis-
tro IANA: <www.iana.org/as-
tener un número diferente dentro de los mensajes del protocolo EAP. Vamos
signments/eap-numbers/eap-
a continuación a presentar tres de los métodos de autenticación disponibles: numbers.xhtml>
EAP-MD5, EAP TLS y EAP-TTLS.
1) El primero de los métodos que vamos a presentar es EAP-MD5, descrito en el

RFC 3748. Es una autenticación basada en password sobre la que se aplica una
función hash MD5. Es vulnerable a ataques de diccionario y solo proporciona
autenticación del servidor EAP:
Figura 22. Autenticación con el método EAP-MD5
Debido a sus debilidades, la compatibilidad con EAP MD5 ha ido paulatina-

mente dejando de implementarse, y ha dejado de utilizarse en los diferentes
sistemas operativos (por ejemplo, quedó obsoleta en Windows en la versión
Vista).
2) Otro de los métodos de autenticación EAP es EAP-TLS, definido en el RFC

5216. Surge de la necesidad de disponer de métodos de autenticación que per-
mitan la autenticación mutua y la derivación de claves, especialmente nece-
saria en entornos wireless LAN (tal como se describe en el RFC 4017). En la
siguiente figura podemos observar el proceso de autenticación con EAP-TLS:
Figura 23. Autenticación con el método EAP-TLS
Es importante recalcar que, técnicamente, el estándar no exige el uso de cer-

tificados digitales para autenticar a cliente y servidor. La omisión de los certi-
ficados en esta figura de autenticación EAP, por contra, anularía los beneficios
de seguridad del protocolo y haría que gran parte de la infraestructura necesa-
ria para su uso no tuviera sentido. Dado que EAP TLS requiere autenticación
mutua, es poco probable encontrarnos con una implementación de este que
no requiera certificados del lado cliente.
3) Otro de los métodos EAP disponibles, y que no tenemos que confundir con
el anterior, es EAP-TTLS, descrito en el RFC 5281. En este método la auten-
ticación mutua se realiza de forma diferente. Lo más habitual es que el servi-
dor se autentique con un certificado y que, una vez autenticado, se utilice el
certificado del servidor para crear un túnel que permita autenticar al cliente
por otros métodos, como por ejemplo PAP, CHAP, MS CHAP o incluso otro
método de autenticación EAP.
Con EAP-TTLS, el cliente y el servidor se comunican usando pares atributo-va-

lor encriptados usando TLS. Esto permite añadir funcionalidades más allá de
la autenticación y el intercambio de claves, y es compatible con una infraes-
tructura tipo RADIUS.
Es un método de autenticación ampliamente implementado, ya que permite

utilizar protocolos de autenticación heredados basados en contraseñas contra
bases de datos existentes, frente a la necesidad de expedir certificados para los
clientes en un entorno EAP-TLS.
5.2. Protocolo 802.1x
802.1x es un protocolo de acceso a la red, basado en puerto definido

por el IEEE, que permite la autenticación y autorización de equipos co-
nectados a LAN IEEE 802, como por ejemplo Ethernet o 802.11 WLAN.
Verifica, por lo tanto, que cualquier dispositivo que se quiera conectar a un

puerto físico de un conmutador o a un punto de acceso ha realizado una au-
tenticación y, en su caso, autorización previa.
Para realizar este proceso 802.1x usa EAP como método de autenticación y
utiliza un servidor AAA externo (como por ejemplo RADIUS). El formato de
encapsulación EAP sobre la capa MAC es EAPOL.
5.2.1. Arquitectura 802.1x
La siguiente figura nos muestra los componentes y el procedimiento de ope-

ración en una infraestructura con 802.1x:
Figura 24. Infraestructura 802.1x
Fuente: https://foundation.wikimedia.org/wiki/File:802.1X_wired_protocols.png
Tal como vimos al introducir EAP, en el contexto de 802.1x, el peer se conoce

como suplicante. Como podemos apreciar en la imagen, para comunicarse
con el authenticator, se intercambian mensajes EAPOL (EAP over LAN). Esta
técnica de encapsulación de mensajes permite su uso tanto en redes cableadas
como inalámbricas.
El authenticator es el encargado de enviar al servidor de autenticación la soli-

citud de acceso al puerto, con alguno de los métodos EAP disponibles y con-
figurados. El servidor de autenticación enviará la respuesta a esta petición in-
dicando si el dispositivo se puede o no unir a la red.
5.2.2. Autenticación 802.1x
Más detalladamente, como ejemplo, podemos ver en el siguiente gráfico el

intercambio de mensajes que tiene lugar en un dispositivo inalámbrico (supli-
cante) con el rol de cliente WLAN que intenta unirse a una red wifi:
Figura 25. Autenticación 802.1x en una red wifi

1) Un usuario ejecuta un software cliente 802.1x e inicia una petición de co-

nexión, lo que genera un mensaje EAPOL Start que le llega al authenticator
(en este caso podríamos tener un punto de acceso que haga de authenticator, o
bien una infraestructura formada por puntos de acceso conectados a un con-
trolador WLAN).
2) El punto de acceso, después de recibir este mensaje EAPOL Start, envía

un paquete EAP-Request Identity, que es contestado por el suplicante con
un mensaje EAP-Response Identity, que contiene el nombre de usuario
y la contraseña.
3) El punto de acceso encapsula este mensaje en un paquete RADIUS Accept

Request y se lo envía al servidor RADIUS.
4) Cuando recibe este paquete, el servidor RADIUS utiliza el método EAP con-
figurado para autenticar al cliente, en este ejemplo EAP-MD5.
5) Una vez que el servidor verifica que la autenticación es correcta, el estado

del puerto pasa a «autorizado», y se permite el acceso a la red por el puerto.
6) Mientras el usuario está conectado, el punto de acceso periódicamente envía

un paquete handshake al cliente para seguir permitiendo su conexión.
7) Una vez que el usuario se desconecta se envía un paquete EAPOL Logoff

al punto de acceso.
5.2.3. Autorización 802.1x
Una vez que hemos comprobado la identidad del usuario que intenta acceder a
la red, podemos, mediante la autorización, comprobar sus derechos de acceso
sobre los recursos de la red.
Para realizar esta fase, podemos utilizar diferentes herramientas, entre las que
podemos destacar las siguientes:
• Virtual�LAN�(VLAN): para evitar que los usuarios accedan a recursos de

red no autorizados, la red se puede segmentar en diferentes VLAN y, una
vez que el usuario se autentica, se le asigna una VLAN autorizada. Es el
servidor RADIUS el que asigna la VLAN autorizada enviando un conjunto
de atributos al cliente.
• Access�control�list�(ACL): las listas de control de acceso permiten asignar al

usuario a una lista con los recursos de la red sobre los que tiene derechos de
acceso. En este caso, el dispositivo de acceso permite o deniega los paquetes
enviados por el cliente en función de la ACL asignada. La asignación de
estas ACL se puede realizar en el servidor RADIUS, o bien en el propio

punto de control de acceso (dependiendo del fabricante).
Resumen
En este módulo hemos estudiado protocolos seguros de red. Estos protocolos

se han diseñado (mediante documentos RFC) con el objetivo de proporcionar
diferentes mecanismos de seguridad entre los diferentes dispositivos que se
comunican en una red.
En primer lugar, hemos presentado el protocolo SSH. Surgido en la década de

los noventa para solucionar, entre otros, el problema del acceso a los recursos
remotos por la red. Este protocolo se ha convertido en un estándar de facto en
la administración de sistemas.
Posteriormente, hemos presentado TLS, que fue concebido en sus orígenes pa-
ra dotar de seguridad a la world wide web y, hoy en día, es ampliamente utili-
zado por todos aquellos sitios de internet que consideramos seguros. Además,
proporciona servicios de seguridad en otros servicios de red, como, por ejem-
plo, la transmisión de correo con SMTPS.
Después, hemos presentado el protocolo de nivel de red IPSec, con sus dife-
rentes formas de configuración mediante los protocolos AH, ESP e IKE, y he-
mos visto también cómo se utilizan para crear redes privadas virtuales (VPN)
que nos permiten conexiones privadas mediante redes públicas.
Otro grupo importante de protocolos son aquellos que nos proporcionan ser-
vicios de autenticación. El primero de los que hemos visto ha sido RADIUS,
base de lo que se conoce como protocolos que ofrecen servicios triple AAA
(autenticación, autorización y accounting) con algunas de sus evoluciones co-
mo son DIAMETER y TACACS+.
Por último, hemos presentado el marco de autenticación EAP, que soporta

diferentes métodos de autenticación y que es utilizado, por ejemplo, en el
protocolo de acceso a la red basado en puerto 802.1x.
Bibliografía
Blokdyk, G. (2018). IPsec: A Clear and Concise Reference. The Art of Service.
Fernández Hansen, Y. et. al. (2008). RADIUS/AAA/802.1x. Sistemas basados en la autenti-

cación en Windows y GNU/Linux. Ra-Ma.
Miller, F. P., y otros (2011). Extensible Authentication Protocol. Alphascript Publishing.
Ristic, I. (2021). Bulletprof TLS and PKI (2.ª ed.). Feisty Duck.

5 Protocolos Seguros de Red

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

5 Protocolos Seguros de Red

Cargado por

Copyright:

Formatos disponibles

Protocolos

Ángel Elbaz Sanz

Ángel Elbaz Sanz

La revisión de este recurso de aprendizaje UOC ha sido coordinada

Primera edición: febrero 2022

3.5. IPSec en las redes privadas virtuales ........................................... 34

5. EAP (protocolo de autenticación extensible) y 802.1x............. 40

Internet es una red de ordenadores mundialmente conectados. Hemos de te-

En primer lugar, veremos protocolos que ofrecen seguridad en las diferentes

Finalmente, en los apartados cuatro y cinco, veremos un conjunto de proto-

1. Comprender el concepto y utilidad de los protocolos de seguridad.

2. Utilizar protocolos seguros de acceso remoto a la red, como SSH.

3. Conocer el funcionamiento del protocolo TLS y su aplicación a los dife-

4. Diseñar redes seguras con el protocolo IPSec.

5. Conocer la arquitectura y funcionamiento del protocolo RADIUS.

6. Entender el marco de autenticación EAP.

7. Comprender el rol del protocolo de autenticación basado en puertos

La necesidad de tener comunicaciones remotas con otros equipos surgió de

A principios del año 1995, la Universidad Tecnológica de Helsinki (Finlandia)

A principios del año 2000, la empresa de Ylönen amplió el uso de la licencia

1)�Administración�remota�de�recursos: esto puede incluir la administración

2)�Transferencia�de�ficheros: proporciona servicios de seguridad a otras apli-

3)�Tunelización�de�conexiones: permite crear túneles (o canales de comuni-

1.1. Arquitectura del protocolo SSH

Desde el punto de vista de su utilización, el protocolo SSH tiene la ar-

Además, desde un punto de vista formal, la especificación del protocolo

1)�Protocolo�de�la�capa�de�transporte (transport layer protocol): esta capa pro-

2)�Protocolo�de�autenticación�de�usuario (user authentication protocol): au-

3)�Protocolo�de�conexión (connection protocol): multiplexa y cifra el túnel en

Figura 1. Capas del protocolo SSH

A continuación, presentaremos con más detalle los aspectos más relevantes de

1.2. Protocolo de capa de transporte

El objetivo principal de esta capa es establecer un canal de comunica-

Para conseguir este objetivo, se establece un conjunto de negociaciones entre

Además, esta capa nos proporciona de forma opcional compresión de datos,

1.2.1. SSH handshake

Como hemos introducido, en el SSH handshake se intercambia la información

Figura 2. Fases del SSH handshake

En la figura anterior, podemos apreciar que tenemos el protocolo SSH ejecu-

1)�Identification�string�exchange: ambas partes deben enviar una cadena de

Ejemplo de cadena de identificación

2)�Algorithm�negotiation: es el comienzo de la fase de generación de claves que

3)�Key�exchange: como continuación de la fase anterior, y una vez que clien-

4)�End�of�key�exchange: una vez terminado el intercambio de claves, los dos

5)�Service�request: después de que acabe la fase de key exchange, el cliente envía

1.2.2. Autenticación del servidor

Como hemos introducido anteriormente, en la fase de key exchange también

En esta figura inicial, un atacante podría enmascararse como el servidor obje-

1.3. Protocolo de autenticación de usuario

Una vez asegurada la conexión con el protocolo de capa de transporte, el ser-

De esta forma se consigue que el servidor tenga completo control sobre

Adicionalmente, se recomienda que el servidor configure otros aspectos del

Cuando el cliente recibe el listado de métodos soportados, tiene libertad para

A continuación, introduciremos los principales métodos que puede presentar

1.3.1. Autenticación con clave pública

El nombre de este método es publickey. Es el único método requerido y todas

En este método de autenticación, el cliente debe generar un par de claves: una

Figura 4. Autenticación de usuario con clave pública

Una ventaja importante de este sistema de autenticación es que no crea rela-

1.3.2. Autenticación con contraseñas

Este método recibe el nombre de password. No es obligatorio, pero todas las

Es importante darse cuenta de que, aunque la contraseña se transmite en texto

1.3.3. Autenticación basada en host