Protocolo de autenticación extensible

El método Lightweight Extensible Authentication Protocol (LEAP) fue desarrollado por Cisco Systems antes de la ratificación del estándar de seguridad 802.11i por parte del IEEE . ^{[ 3 ]} Cisco distribuyó el protocolo a través de CCX (Cisco Certified Extensions) como parte de la adopción de 802.1X y WEP dinámico en la industria ante la ausencia de un estándar. No existe soporte nativo para LEAP en ningún sistema operativo Windows , pero es ampliamente compatible con software cliente de terceros, incluido comúnmente con dispositivos WLAN (redes de área local inalámbricas). El soporte para LEAP en Microsoft Windows 7 y Microsoft Windows Vista se puede agregar descargando un complemento de cliente de Cisco que brinda soporte tanto para LEAP como para EAP-FAST. Debido a la amplia adopción de LEAP en la industria de redes, muchos otros proveedores de WLAN afirman ser compatibles con LEAP.

LEAP utiliza una versión modificada de MS-CHAP , un protocolo de autenticación en el que las credenciales de usuario no están protegidas con solidez y son fácilmente vulnerables; Joshua Wright lanzó a principios de 2004 una herramienta de explotación llamada ASLEAP. ^{[ 4 ]} Cisco recomienda que los clientes que necesiten usar LEAP lo hagan únicamente con contraseñas suficientemente complejas, aunque estas son difíciles de administrar y de hacer cumplir. La recomendación actual de Cisco es utilizar protocolos EAP más recientes y robustos, como EAP-FAST, PEAP o EAP-TLS.

EAP Transport Layer Security (EAP-TLS), definido en la RFC 5216 , es un estándar abierto de la IETF que utiliza el protocolo Transport Layer Security (TLS) y cuenta con un amplio soporte entre los proveedores de redes inalámbricas. EAP-TLS es el protocolo de autenticación EAP original y estándar para redes LAN inalámbricas. 

EAP-TLS sigue considerándose uno de los estándares EAP más seguros disponibles, aunque TLS proporciona una seguridad sólida solo siempre que el usuario comprenda las posibles advertencias sobre credenciales falsas, y es compatible universalmente con todos los fabricantes de hardware y software de LAN inalámbrica. Hasta abril de 2005, EAP-TLS era el único tipo de EAP que los proveedores necesitaban certificar para un logotipo WPA o WPA2. ^{[ 5 ]} Hay implementaciones de cliente y servidor de EAP-TLS en 3Com, Apple, Avaya , Brocade Communications, Cisco, Enterasys Networks, Fortinet, Foundry, Hirschmann, HP, Juniper, Microsoft y sistemas operativos de código abierto. EAP- TLS es compatible de forma nativa con Mac OS X 10.3 y superior, wpa_supplicant , Windows 2000 SP4, Windows XP y superior, Windows Mobile 2003 y superior, Windows CE 4.2 y el sistema operativo móvil iOS de Apple.

A diferencia de la mayoría de las implementaciones TLS de HTTPS , como en la World Wide Web , la mayoría de las implementaciones de EAP-TLS requieren autenticación mutua mediante certificados X.509 del lado del cliente sin dar la opción de deshabilitar el requisito, aunque el estándar no exige su uso. ^{[ 6 ] [ 7 ]} Algunos han identificado que esto tiene el potencial de reducir drásticamente la adopción de EAP-TLS y evitar puntos de acceso "abiertos" pero cifrados. ^{[ 6 ] [ 7 ]} El 22 de agosto de 2012, hostapd (y wpa_supplicant) agregaron soporte en su repositorio Git para un tipo de EAP específico del proveedor UNAUTH-TLS (usando el número de empresa privada RFC 5612 del proyecto hostapd/wpa_supplicant), ^{[ 8 ]} y el 25 de febrero de 2014 agregaron soporte para el tipo de EAP específico del proveedor WFA-UNAUTH-TLS (usando el número de empresa privada de Wi-Fi Alliance ), ^{[ 9 ] [ 10 ]} que solo realiza autenticación de servidor. Esto permitiría situaciones muy parecidas a HTTPS, donde un punto de acceso inalámbrico permite el acceso libre y no autentica a los clientes de la estación, pero estos últimos desean usar cifrado ( IEEE 802.11i-2004 , es decir, WPA2 ) y potencialmente autenticar el punto de acceso inalámbrico. También se han propuesto usar IEEE 802.11u para que los puntos de acceso indiquen que permiten EAP-TLS usando solo autenticación del lado del servidor, usando el tipo estándar EAP-TLS IETF en lugar de un tipo EAP específico del proveedor. ^{[ 11 ]} 

El requisito de un certificado del lado del cliente, por impopular que sea, es lo que confiere a EAP-TLS su solidez de autenticación e ilustra la clásica disyuntiva entre comodidad y seguridad. Con un certificado del lado del cliente, una contraseña comprometida no basta para acceder a sistemas habilitados para EAP-TLS, ya que el intruso aún necesita el certificado del lado del cliente; de ​​hecho, ni siquiera se necesita una contraseña, puesto que solo se utiliza para cifrar el certificado del lado del cliente para su almacenamiento. La máxima seguridad disponible se alcanza cuando las "claves privadas" del certificado del lado del cliente se almacenan en tarjetas inteligentes . ^{[ 12 ]} Esto se debe a que no hay forma de robar la clave privada correspondiente a un certificado del lado del cliente de una tarjeta inteligente sin robar la tarjeta misma. Es más probable que se detecte el robo físico de una tarjeta inteligente (y que esta sea revocada inmediatamente) que el robo de una contraseña (típica). Además, la clave privada de una tarjeta inteligente suele estar encriptada mediante un PIN que solo conoce el propietario de la tarjeta, lo que minimiza su utilidad para un ladrón incluso antes de que la tarjeta haya sido denunciada como robada y revocada.

EAP-MD5 fue el único método EAP basado en la vía de estándares de la IETF cuando se definió por primera vez en el RFC original para EAP, RFC 2284. Ofrece una seguridad mínima; la función hash MD5 es vulnerable a ataques de diccionario y no admite la generación de claves, lo que lo hace inadecuado para su uso con WEP dinámico o WPA/WPA2 empresarial. EAP-MD5 se diferencia de otros métodos EAP en que solo proporciona autenticación del par EAP al servidor EAP, pero no autenticación mutua. Al no proporcionar autenticación del servidor EAP, este método EAP es vulnerable a ataques de intermediario (man-in-the-middle). ^{[ 13 ]} La compatibilidad con EAP-MD5 se incluyó por primera vez en Windows 2000 y se dejó de usar en Windows Vista . ^{[ 14 ]} 

La contraseña de un solo uso protegida por EAP (EAP-POTP), descrita en la RFC 4793 , es un método EAP desarrollado por RSA Laboratories que utiliza tokens de contraseña de un solo uso (OTP), como un dispositivo de hardware portátil o un módulo de hardware o software que se ejecuta en una computadora personal, para generar claves de autenticación. EAP-POTP puede utilizarse para proporcionar autenticación unilateral o mutua y material de clave en protocolos que utilizan EAP. 

El método EAP-POTP proporciona autenticación de usuario de dos factores, lo que significa que un usuario necesita tanto acceso físico a un token como conocimiento de un número de identificación personal (PIN) para realizar la autenticación. ^{[ 15 ]}

^{[ 1 ]} La clave precompartida EAP (EAP-PSK), definida enRFC4764, es un método EAP para la autenticación mutua y la derivación de claves de sesión mediante unaclave precompartida(PSK). Proporciona un canal de comunicación protegido, cuando la autenticación mutua es exitosa, para que ambas partes se comuniquen y está diseñado para la autenticación en redes no seguras como IEEE 802.11. 

EAP-PSK está documentado en un RFC experimental que proporciona un método EAP ligero y extensible que no requiere criptografía de clave pública. El intercambio de protocolos del método EAP se realiza en un mínimo de cuatro mensajes.

La contraseña EAP (EAP-PWD), definida en la RFC 5931 , es un método EAP que utiliza una contraseña compartida para la autenticación. Esta contraseña puede ser de baja entropía y extraerse de un conjunto de contraseñas posibles, como un diccionario, al que tiene acceso un atacante. El intercambio de claves subyacente es resistente a ataques activos, pasivos y de diccionario. 

EAP-PWD está en la base de Android 4.0 (ICS). Está presente en los servidores RADIUS FreeRADIUS ^{[ 16 ]} y Radiator ^{[ 17 ]} , y también en hostapd y wpa_supplicant. ^{[ 18 ]}

EAP Tunneled Transport Layer Security (EAP-TTLS) es un protocolo EAP que extiende TLS . Fue desarrollado conjuntamente por Funk Software y Certicom y cuenta con un amplio soporte en diversas plataformas. Microsoft no incorporó soporte nativo para el protocolo EAP-TTLS en Windows XP , Vista ni 7. El soporte para TTLS en estas plataformas requiere software certificado por el Protocolo de Control de Cifrado (ECP) de terceros. Microsoft Windows comenzó a ofrecer soporte para EAP-TTLS con Windows 8 , ^{[ 19 ] y [ 20 ]} apareció en Windows Phone versión 8.1 . ^{[ 21 ]}

El cliente puede, pero no es obligatorio, autenticarse en el servidor mediante un certificado PKI firmado por una CA. Esto simplifica enormemente el procedimiento de configuración, ya que no se necesita un certificado en cada cliente.

Una vez que el servidor se autentica de forma segura ante el cliente mediante su certificado CA, y opcionalmente el cliente ante el servidor, este último puede utilizar la conexión segura establecida ("túnel") para autenticar al cliente. Puede emplear un protocolo e infraestructura de autenticación existentes y ampliamente implementados, que incorporen mecanismos de contraseñas heredados y bases de datos de autenticación, mientras que el túnel seguro proporciona protección contra la interceptación de comunicaciones y los ataques de intermediario . Cabe destacar que el nombre del usuario nunca se transmite en texto plano sin cifrar, lo que mejora la privacidad.

Existen dos versiones distintas de EAP-TTLS: la versión original (también conocida como EAP-TTLSv0) y la versión EAP-TTLSv1. EAP-TTLSv0 se describe en la RFC 5281 , mientras que EAP-TTLSv1 está disponible como borrador en Internet. ^{[ 22 ]} 

EAP Internet Key Exchange v. 2 (EAP-IKEv2) es un método EAP basado en el protocolo de intercambio de claves de Internet versión 2 (IKEv2). Proporciona autenticación mutua y establecimiento de claves de sesión entre un par EAP y un servidor EAP. Admite técnicas de autenticación basadas en los siguientes tipos de credenciales:

Pares de claves asimétricas

Pares de claves pública/privada donde la clave pública está integrada en un certificado digital y la clave privada correspondiente solo la conoce una única parte.

Contraseñas

Cadenas de bits de baja entropía conocidas tanto por el servidor como por el interlocutor.

Claves simétricas

Cadenas de bits de alta entropía conocidas tanto por el servidor como por el interlocutor.

Es posible utilizar una credencial de autenticación diferente (y, por lo tanto, una técnica distinta) en cada dirección. Por ejemplo, el servidor EAP se autentica mediante un par de claves pública/privada y el cliente EAP mediante una clave simétrica. Sin embargo, no se esperan en la práctica todas las nueve combinaciones teóricas. En concreto, el estándar RFC 5106 enumera cuatro casos de uso: que el servidor se autentique con un par de claves asimétricas mientras que el cliente utilice cualquiera de los tres métodos; y que ambas partes utilicen una clave simétrica. 

EAP-IKEv2 se describe en el RFC 5106 y existe una implementación prototipo . 

La autenticación flexible mediante tunelización segura (EAP-FAST; RFC 4851 ) es una propuesta de protocolo de Cisco Systems para reemplazar a LEAP . ^{[ 23 ]} El protocolo se diseñó para abordar las debilidades de LEAP, manteniendo al mismo tiempo una implementación ligera. El uso de certificados de servidor es opcional en EAP-FAST. EAP-FAST utiliza una credencial de acceso protegido (PAC) para establecer un túnel TLS en el que se verifican las credenciales del cliente. 

EAP-FAST tiene tres fases: ^{[ 24 ]}

Cuando se habilita el aprovisionamiento automático de PAC, EAP-FAST presenta una vulnerabilidad que permite a un atacante interceptar el PAC y utilizarlo para comprometer las credenciales de los usuarios. Esta vulnerabilidad se mitiga mediante el aprovisionamiento manual de PAC o mediante el uso de certificados de servidor para la fase de aprovisionamiento de PAC.

Cabe destacar que el archivo PAC se emite por usuario. Este es un requisito de la RFC 4851, sección 7.4.4, por lo que si un nuevo usuario se conecta a la red desde un dispositivo, primero se debe aprovisionar un nuevo archivo PAC. Esta es una de las razones por las que resulta difícil evitar ejecutar EAP-FAST en modo de aprovisionamiento anónimo inseguro. La alternativa es usar contraseñas de dispositivo, pero en ese caso se valida el dispositivo en la red, no el usuario. 

EAP-FAST se puede utilizar sin archivos PAC, recurriendo al protocolo TLS normal.

EAP-FAST es compatible de forma nativa con Apple OS X 10.4.8 y versiones posteriores. Cisco proporciona un módulo EAP-FAST ^{[ 25 ]} para Windows Vista ^{[ 26 ]} y sistemas operativos posteriores que cuentan con una arquitectura EAPHost extensible para nuevos métodos de autenticación y solicitantes. ^{[ 27 ]}

El Protocolo de Autenticación Extensible por Túnel (TEAP; RFC 7170 ) es un método EAP basado en túneles que permite la comunicación segura entre un par y un servidor mediante el protocolo TLS (Transport Layer Security) para establecer un túnel con autenticación mutua. Dentro del túnel, se utilizan objetos TLV (Tipo-Longitud-Valor) para transmitir datos relacionados con la autenticación entre el par EAP y el servidor EAP. 

Además de la autenticación entre pares, TEAP permite que el par solicite un certificado al servidor mediante una solicitud en formato PKCS#10 . Tras recibir la solicitud de certificado y autenticar al par, el servidor puede proporcionarle un certificado en formato PKCS#7 ( RFC 2325 ). El servidor también puede distribuir certificados raíz de confianza al par en formato PKCS#7 ( RFC 2325 ). Ambas operaciones se realizan dentro de los TLV correspondientes y de forma segura a través del túnel TLS ya establecido.  

El módulo de identidad del suscriptor EAP (EAP-SIM) se utiliza para la autenticación y la distribución de claves de sesión mediante el módulo de identidad del suscriptor (SIM) del Sistema Global para Comunicaciones Móviles ( GSM ).

Las redes celulares GSM utilizan una tarjeta SIM (módulo de identidad del suscriptor) para autenticar al usuario. EAP-SIM utiliza un algoritmo de autenticación SIM entre el cliente y un servidor de autenticación, autorización y contabilidad (AAA), lo que proporciona autenticación mutua entre el cliente y la red.

En EAP-SIM, la comunicación entre la tarjeta SIM y el Centro de Autenticación (AuC) elimina la necesidad de una contraseña preestablecida entre el cliente y el servidor AAA.

Los algoritmos A3/A8 se están ejecutando varias veces con diferentes desafíos de 128 bits, por lo que habrá más claves Kc-s de 64 bits que se combinarán para crear claves más seguras (las claves Kc-s no se usarán directamente). También se ha superado la falta de autenticación mutua en GSM.

EAP-SIM se describe en el RFC 4186 . 

El método de protocolo de autenticación extensible para la autenticación y el acuerdo de claves del sistema universal de telecomunicaciones móviles (UMTS, por sus siglas en inglés) (EAP-AKA) es un mecanismo EAP para la autenticación y la distribución de claves de sesión mediante el módulo de identidad del suscriptor UMTS ( USIM ). EAP-AKA se define en el RFC 4187 . 

La variante EAP-AKA' de EAP-AKA, definida en RFC 5448 , se utiliza para el acceso no 3GPP a una red central 3GPP . Por ejemplo, a través de EVDO , WiFi o WiMax . 

La tarjeta de token genérica EAP, o EAP-GTC, es un método EAP creado por Cisco como alternativa a PEAPv0/EAP-MSCHAPv2 y definido en los RFC 2284 y 3748. EAP-GTC incluye un desafío de texto del servidor de autenticación y una respuesta generada por un token de seguridad . El mecanismo de autenticación PEAP-GTC permite la autenticación genérica en varias bases de datos, como Novell Directory Service (NDS) y Lightweight Directory Access Protocol (LDAP), así como el uso de una contraseña de un solo uso .  

EAP con intercambio de claves cifradas , o EAP-EKE, es uno de los pocos métodos EAP que proporciona autenticación mutua segura mediante contraseñas cortas y sin necesidad de certificados de clave pública . Se trata de un intercambio de tres rondas, basado en la variante Diffie-Hellman del conocido protocolo EKE.

EAP-EKE se especifica en RFC 6124 . 

La autenticación ágil fuera de banda para EAP ^{[ 28 ]} (EAP-NOOB) es una solución de arranque genérica para dispositivos que no tienen credenciales de autenticación preconfiguradas y que aún no están registrados en ningún servidor. Es especialmente útil para dispositivos y juguetes del Internet de las Cosas (IoT) que no incluyen información sobre el propietario, la red o el servidor. La autenticación para este método EAP se basa en un canal fuera de banda (OOB) asistido por el usuario entre el servidor y el par. EAP-NOOB admite muchos tipos de canales OOB, como códigos QR, etiquetas NFC, audio, etc., y a diferencia de otros métodos EAP, la seguridad del protocolo se ha verificado mediante el modelado formal de la especificación con las herramientas ProVerif y MCRL2 . ^{[ 29 ]}

EAP-NOOB realiza un intercambio Diffie-Hellman de curva elíptica efímera (ECDHE) a través del canal EAP en banda. El usuario confirma este intercambio mediante la transferencia del mensaje OOB. Los usuarios pueden transferir el mensaje OOB del dispositivo remoto al servidor, por ejemplo, cuando el dispositivo es un televisor inteligente que puede mostrar un código QR. Alternativamente, los usuarios pueden transferir el mensaje OOB del servidor al dispositivo remoto, por ejemplo, cuando el dispositivo que se está configurando es una cámara que solo puede leer un código QR.

La encapsulación de EAP sobre IEEE 802 se define en IEEE 802.1X y se conoce como "EAP sobre LAN" o EAPOL. ^{[ 32 ] [ 33 ] [ 34 ]} EAPOL fue diseñado originalmente para IEEE 802.3 Ethernet en 802.1X-2001, pero se aclaró para adaptarse a otras tecnologías LAN IEEE 802 como IEEE 802.11 inalámbrico y Fiber Distributed Data Interface (ANSI X3T9.5/X3T12, adoptado como ISO 9314) en 802.1X-2004. ^{[ 35 ]} El protocolo EAPOL también se modificó para su uso con IEEE 802.1AE (MACsec) e IEEE 802.1AR (Initial Device Identity, IDevID) en 802.1X-2010. ^{[ 36 ]}

Cuando un dispositivo de servidor de acceso a la red (NAS) compatible con 802.1X, como un punto de acceso inalámbrico (WAP) IEEE 802.11i-2004 , invoca EAP , los métodos EAP modernos pueden proporcionar un mecanismo de autenticación seguro y negociar una clave privada segura (clave maestra de par, PMK) entre el cliente y el NAS, que luego se puede utilizar para una sesión de cifrado inalámbrico mediante el cifrado TKIP o CCMP (basado en AES ).

El Protocolo de Autenticación Extensible Protegido , también conocido como EAP Protegido o simplemente PEAP, es un protocolo que encapsula EAP dentro de un túnel de Seguridad de la Capa de Transporte (TLS) potencialmente cifrado y autenticado . ^{[ 37 ] [ 38 ] [ 39 ]} El propósito era corregir deficiencias en EAP; EAP asumía un canal de comunicación protegido, como el proporcionado por la seguridad física, por lo que no se proporcionaban mecanismos para proteger la conversación EAP. ^{[ 40 ]}

PEAP fue desarrollado conjuntamente por Cisco Systems, Microsoft y RSA Security. PEAPv0 fue la versión incluida con Microsoft Windows XP y se definió nominalmente en draft-kamath-pppext-peapv0-00 . PEAPv1 y PEAPv2 se definieron en diferentes versiones de draft-josefsson-pppext-eap-tls-eap . PEAPv1 se definió en draft-josefsson-pppext-eap-tls-eap-00 hasta draft-josefsson-pppext-eap-tls-eap-05 , ^{[ 41 ]} y PEAPv2 se definió en versiones que comienzan con draft-josefsson-pppext-eap-tls-eap-06 . ^{[ 42 ]}

El protocolo solo especifica el encadenamiento de múltiples mecanismos EAP y no ningún método específico. ^{[ 38 ] [ 43 ]} El uso de los métodos EAP-MSCHAPv2 y EAP-GTC son los más comúnmente admitidos.

Los protocolos AAA RADIUS y Diameter pueden encapsular mensajes EAP. Suelen ser utilizados por dispositivos de servidor de acceso a la red (NAS) para reenviar paquetes EAP entre terminales IEEE 802.1X y servidores AAA, facilitando así la comunicación entre IEEE 802.1X.

El Protocolo para la Autenticación de Acceso a la Red (PANA) es un protocolo basado en IP que permite a un dispositivo autenticarse en una red para obtener acceso. PANA no define ningún protocolo nuevo de autenticación, distribución de claves, acuerdo de claves ni derivación de claves; para estos fines, se utilizará EAP, y PANA transportará la carga útil de EAP. PANA permite la selección dinámica de proveedores de servicios, admite diversos métodos de autenticación, es adecuado para usuarios en itinerancia y es independiente de los mecanismos de la capa de enlace.

EAP fue originalmente una extensión de autenticación para el Protocolo Punto a Punto (PPP). PPP ha sido compatible con EAP desde su creación como alternativa al Protocolo de Autenticación de Reto-Intercambio (CHAP) y al Protocolo de Autenticación de Contraseña (PAP), que posteriormente se incorporaron a EAP. La extensión EAP para PPP se definió por primera vez en el RFC 2284 , ahora obsoleto según el RFC 3748 .