IEEE 802.1X

El estándar 802.1X-2001 define dos entidades de puerto lógicas para un puerto autenticado: el "puerto controlado" y el "puerto no controlado". El puerto controlado es gestionado por la PAE (Entidad de Acceso al Puerto) 802.1X para permitir (en estado autorizado) o impedir (en estado no autorizado) el tráfico de red entrante y saliente hacia/desde dicho puerto. El puerto no controlado es utilizado por la PAE 802.1X para transmitir y recibir tramas EAPOL.

El estándar 802.1X-2004 define las entidades de puerto equivalentes para el solicitante; por lo tanto, un solicitante que implemente 802.1X-2004 puede impedir el uso de protocolos de nivel superior si no está seguro de que la autenticación se haya completado correctamente. Esto resulta especialmente útil cuando se utiliza un método EAP que proporciona autenticación mutua , ya que el solicitante puede evitar la fuga de datos al conectarse a una red no autorizada.

El procedimiento de autenticación típico consta de:

1. Inicialización: Al detectar un nuevo solicitante, el puerto del conmutador (autenticador) se habilita y se establece en el estado "no autorizado". En este estado, solo se permite el tráfico 802.1X; otro tráfico, como el Protocolo de Internet (y, por lo tanto, TCP y UDP ), se descarta.
2. Para iniciar la autenticación, el autenticador transmitirá periódicamente tramas EAP-Request Identity a una dirección MAC de capa 2 específica ( 01:80:C2:00:00:03 ) en el segmento de red local. El solicitante escucha en esta dirección y, al recibir la trama EAP-Request Identity, responde con una trama EAP-Response Identity que contiene un identificador para el solicitante, como un ID de usuario. El autenticador encapsula esta respuesta Identity en un paquete RADIUS Access-Request y lo reenvía al servidor de autenticación. El solicitante también puede iniciar o reiniciar la autenticación enviando una trama EAPOL-Start al autenticador, que responderá con una trama EAP-Request Identity.
3. Negociación (técnicamente, negociación EAP): El servidor de autenticación envía una respuesta (encapsulada en un paquete RADIUS Access-Challenge) al autenticador, que contiene una solicitud EAP que especifica el método EAP (el tipo de autenticación basada en EAP que desea que realice el solicitante). El autenticador encapsula la solicitud EAP en una trama EAPOL y la transmite al solicitante. En este punto, el solicitante puede comenzar a usar el método EAP solicitado o realizar un NAK ("Acuse de recibo negativo") y responder con los métodos EAP que está dispuesto a realizar.
4. Autenticación Si el servidor de autenticación y el solicitante acuerdan un método EAP, se envían solicitudes y respuestas EAP entre el solicitante y el servidor de autenticación (traducidas por el autenticador) hasta que el servidor de autenticación responde con un mensaje EAP-Success (encapsulado en un paquete RADIUS Access-Accept) o un mensaje EAP-Failure (encapsulado en un paquete RADIUS Access-Reject). Si la autenticación es exitosa, el autenticador establece el puerto en estado "autorizado" y se permite el tráfico normal. Si no es exitosa, el puerto permanece en estado "no autorizado". Cuando el solicitante cierra sesión, envía un mensaje EAPOL-logoff al autenticador, quien entonces establece el puerto en estado "no autorizado", bloqueando nuevamente todo el tráfico que no sea EAP.

Windows, por defecto, no responde a las solicitudes de autenticación 802.1X durante 20 minutos después de un fallo de autenticación. Esto puede causar importantes interrupciones en los clientes.

El período de bloqueo se puede configurar mediante el valor DWORD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\dot3svc\BlockTime ^{[ 14 ]} (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\wlansvc\BlockTime para redes inalámbricas) en el registro (introducido en minutos). Se requiere una revisión para Windows XP SP3 y Windows Vista SP2 para que el período sea configurable. ^{[ 15 ]}

Los certificados de servidor comodín no son compatibles con EAPHost, el componente de Windows que proporciona soporte EAP en el sistema operativo. ^{[ 16 ]} Esto implica que, al utilizar una autoridad de certificación comercial, se deben comprar certificados individuales.

La mayoría de las distribuciones de Linux son compatibles con 802.1X a través de wpa_supplicant y la integración con el escritorio, como NetworkManager .

El iPhone y el iPod Touch son compatibles con 802.1X desde el lanzamiento de iOS 2.0. macOS ofrece compatibilidad nativa desde Mac OS X Panther . ^{[ 25 ]}

A partir de iOS 17 y macOS 14 , los dispositivos Apple admiten la conexión a redes 802.1X mediante EAP-TLS con TLS 1.3 (EAP-TLS 1.3). Además, los dispositivos con iOS/iPadOS/tvOS 17 o posterior admiten redes 802.1X cableadas. ^{[ 26 ] [ 27 ]}

Android es compatible con 802.1X desde el lanzamiento de la versión 1.6 Donut.

eduroam (el servicio de roaming internacional) exige el uso de la autenticación 802.1X al proporcionar acceso a la red a los visitantes procedentes de otras instituciones habilitadas para eduroam. ^{[ 28 ]}

BT (British Telecom, PLC) emplea Identity Federation para la autenticación en los servicios prestados a una amplia variedad de industrias y gobiernos. ^{[ 29 ]}

No todos los dispositivos son compatibles con la autenticación 802.1X. Algunos ejemplos son las impresoras de red, los dispositivos electrónicos basados ​​en Ethernet, como los sensores ambientales, las cámaras y los teléfonos inalámbricos. Para que estos dispositivos puedan utilizarse en un entorno de red protegido, se deben proporcionar mecanismos alternativos para su autenticación.

Una opción sería deshabilitar 802.1X en ese puerto, pero esto lo deja desprotegido y vulnerable a abusos. Otra opción, ligeramente más fiable, es usar la opción MAB. Al configurar MAB en un puerto, este primero intentará verificar si el dispositivo conectado cumple con el estándar 802.1X. Si no recibe respuesta, intentará autenticarse con el servidor AAA utilizando la dirección MAC del dispositivo como nombre de usuario y contraseña. El administrador de red deberá entonces configurar el servidor RADIUS para autenticar esas direcciones MAC, ya sea agregándolas como usuarios regulares o implementando lógica adicional para resolverlas en una base de datos de inventario de red.

Muchos conmutadores Ethernet gestionados ^{[ 30 ]} ofrecen opciones para esto.

En el verano de 2005, Steve Riley de Microsoft publicó un artículo (basado en la investigación original del MVP de Microsoft Svyatoslav Pidgorny) que detallaba una grave vulnerabilidad en el protocolo 802.1X, relacionada con un ataque de intermediario (man-in-the-middle) . En resumen, la vulnerabilidad radica en que 802.1X solo se autentica al inicio de la conexión, pero después de dicha autenticación, un atacante puede usar el puerto autenticado si tiene la capacidad de interponerse físicamente (quizás mediante un concentrador de grupo de trabajo) entre el equipo autenticado y el puerto. Riley sugiere que, para redes cableadas, el uso de IPsec o una combinación de IPsec y 802.1X sería más seguro. ^{[ 31 ]}

Las tramas EAPOL-Logoff transmitidas por el solicitante 802.1X se envían en texto plano y no contienen datos derivados del intercambio de credenciales que autenticó inicialmente al cliente. ^{[ 32 ]} Por lo tanto, son trivialmente fáciles de falsificar en medios compartidos y pueden usarse como parte de un ataque DoS dirigido tanto en LAN cableadas como inalámbricas. En un ataque EAPOL-Logoff, un tercero malicioso con acceso al medio al que está conectado el autenticador envía repetidamente tramas EAPOL-Logoff falsificadas desde la dirección MAC del dispositivo objetivo. El autenticador (creyendo que el dispositivo objetivo desea finalizar su sesión de autenticación) cierra la sesión de autenticación del objetivo, bloqueando el tráfico entrante desde el objetivo, denegándole el acceso a la red.

La especificación 802.1X-2010, que comenzó como 802.1af, aborda las vulnerabilidades de las especificaciones 802.1X anteriores, mediante el uso de MACsec IEEE 802.1AE para cifrar datos entre puertos lógicos (que se ejecutan sobre un puerto físico) y dispositivos autenticados IEEE 802.1AR (Identidad segura del dispositivo / DevID). ^{[ 7 ] [ 8 ] [ 33 ] [ 34 ]}

Como solución provisional, hasta que estas mejoras se implementen de forma generalizada, algunos proveedores han extendido los protocolos 802.1X-2001 y 802.1X-2004, permitiendo que se produzcan varias sesiones de autenticación simultáneas en un solo puerto. Si bien esto impide que el tráfico de dispositivos con direcciones MAC no autenticadas ingrese a un puerto autenticado 802.1X, no impedirá que un dispositivo malicioso espíe el tráfico de un dispositivo autenticado y no ofrece protección contra la suplantación de MAC ni contra los ataques EAPOL-Logoff.