El Protocolo de Autenticación Extensible ( EAP ) es un marco de autenticación que se utiliza con frecuencia en conexiones de red e Internet. Se define en el RFC 3748, que dejó obsoleto el RFC 2284, y se actualiza en el RFC 5247. EAP es un marco de autenticación para proporcionar el transporte y el uso de material y parámetros generados por métodos EAP. Existen muchos métodos definidos por los RFC, y existen varios métodos específicos de cada proveedor y nuevas propuestas. EAP no es un protocolo de cable; en cambio, solo define la información de la interfaz y los formatos. Cada protocolo que utiliza EAP define una forma de encapsular por parte del usuario los mensajes EAP dentro de los mensajes de ese protocolo.
El uso de EAP está muy extendido. Por ejemplo, en IEEE 802.11 (Wi-Fi), los estándares WPA y WPA2 han adoptado IEEE 802.1X (con varios tipos de EAP) como mecanismo de autenticación canónico.
EAP es un marco de autenticación, no un mecanismo de autenticación específico. [1] Proporciona algunas funciones comunes y la negociación de métodos de autenticación denominados métodos EAP. Actualmente hay definidos unos 40 métodos diferentes. Los métodos definidos en las RFC de la IETF incluyen EAP-MD5, EAP-POTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, EAP-AKA y EAP-AKA'. Además, existen varios métodos específicos de cada proveedor y nuevas propuestas. Los métodos modernos de uso común capaces de operar en redes inalámbricas incluyen EAP-TLS, EAP-SIM, EAP-AKA, LEAP y EAP-TTLS. Los requisitos para los métodos EAP utilizados en la autenticación de LAN inalámbrica se describen en la RFC 4017. La lista de códigos de tipo y paquetes utilizados en EAP está disponible en el Registro EAP de la IANA. [2]
La norma también describe las condiciones bajo las cuales se pueden satisfacer los requisitos de gestión de claves AAA descritos en RFC 4962.
El método LEAP ( Lightweight Extensible Authentication Protocol ) 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 en ausencia de un estándar. No hay soporte nativo para LEAP en ningún sistema operativo Windows , pero es ampliamente compatible con el software de cliente de terceros que se incluye más comúnmente con los dispositivos WLAN (LAN inalámbrica). La compatibilidad con LEAP para Microsoft Windows 7 y Microsoft Windows Vista se puede agregar descargando un complemento de cliente de Cisco que proporciona compatibilidad tanto para LEAP como para EAP-FAST. Debido a la amplia adopción de LEAP en la industria de las redes, muchos otros proveedores de WLAN [ ¿quién? ] 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 fuertemente protegidas y son fácilmente vulneradas; a principios de 2004, Joshua Wright lanzó una herramienta de explotación llamada ASLEAP. [4] Cisco recomienda que los clientes que deban usar LEAP lo hagan únicamente con contraseñas lo suficientemente complejas, aunque las contraseñas complejas son difíciles de administrar y hacer cumplir. La recomendación actual de Cisco es utilizar protocolos EAP más nuevos y más sólidos, como EAP-FAST, PEAP o EAP-TLS.
EAP Transport Layer Security (EAP-TLS), definido en RFC 5216, es un estándar abierto de IETF que utiliza el protocolo Transport Layer Security (TLS) y cuenta con un amplio respaldo entre los proveedores de servicios inalámbricos. EAP-TLS es el protocolo de autenticación EAP para redes LAN inalámbricas estándar original.
EAP-TLS todavía se considera uno de los estándares EAP más seguros disponibles, aunque TLS proporciona una seguridad sólida solo mientras 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] Existen 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 utilizando 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 esto como algo que 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 del proyecto hostapd/wpa_supplicant RFC 5612), [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 realizan autenticación de servidor. Esto permitiría situaciones muy similares a HTTPS, donde un punto de acceso inalámbrico permite el acceso libre y no autentica a los clientes de la estación, pero los clientes de la estación desean utilizar el cifrado ( IEEE 802.11i-2004 , es decir, WPA2 ) y potencialmente autenticar el punto de acceso inalámbrico. También ha habido propuestas para utilizar IEEE 802.11u para que los puntos de acceso indiquen que permiten EAP-TLS utilizando solo la autenticación del lado del servidor, utilizando 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 pueda ser, es lo que le da a EAP-TLS su fuerza de autenticación e ilustra la clásica disyuntiva entre conveniencia y seguridad. Con un certificado del lado del cliente, una contraseña comprometida no es suficiente para entrar en sistemas habilitados para EAP-TLS porque el intruso todavía necesita tener el certificado del lado del cliente; de hecho, ni siquiera se necesita una contraseña, ya que solo se usa para cifrar el certificado del lado del cliente para su almacenamiento. La mayor seguridad disponible es cuando las "claves privadas" del certificado del lado del cliente están alojadas en tarjetas inteligentes . [12] Esto se debe a que no hay forma de robar la clave privada correspondiente de un certificado del lado del cliente de una tarjeta inteligente sin robar la tarjeta misma. Es más probable que se note el robo físico de una tarjeta inteligente (y la tarjeta inteligente se revoque inmediatamente) que un robo de contraseña (típico). Además, la clave privada de una tarjeta inteligente normalmente está cifrada utilizando un PIN que sólo el propietario de la tarjeta inteligente conoce, 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 norma IETF Standards Track 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. [13] La compatibilidad con EAP-MD5 se incluyó por primera vez en Windows 2000 y quedó obsoleta en Windows Vista . [14]
La contraseña de un solo uso protegida por EAP (EAP-POTP), que se describe 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 se puede utilizar para proporcionar autenticación unilateral o mutua y material de claves 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 en RFC 4764, es un método EAP para la autenticación mutua y la derivación de claves de sesión mediante una clave precompartida (PSK). Proporciona un canal de comunicación protegido para que ambas partes se comuniquen cuando la autenticación mutua es exitosa y está diseñada para la autenticación en redes inseguras como IEEE 802.11.
EAP-PSK está documentado en una RFC experimental que proporciona un método EAP ligero y extensible que no requiere criptografía de clave pública. El intercambio de protocolo del método EAP se realiza en un mínimo de cuatro mensajes.
La contraseña EAP (EAP-PWD), definida en RFC 5931, es un método EAP que utiliza una contraseña compartida para la autenticación. La contraseña puede ser de baja entropía y puede extraerse de un conjunto de contraseñas posibles, como un diccionario, que está disponible para un atacante. El intercambio de claves subyacente es resistente a ataques activos, pasivos y de diccionario.
EAP-PWD se encuentra en la base de Android 4.0 (ICS). Se encuentra en los servidores RADIUS FreeRADIUS [16] y Radiator [17] , y 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 tiene un amplio soporte en todas las plataformas. Microsoft no incorporó soporte nativo para el protocolo EAP-TTLS en Windows XP , Vista o 7. Para soportar TTLS en estas plataformas se requiere software certificado por el Protocolo de control de cifrado (ECP) de terceros. Microsoft Windows comenzó a soportar EAP-TTLS con Windows 8 , [19] el soporte para EAP-TTLS [20] apareció en la versión 8.1 de Windows Phone . [21]
El cliente puede, pero no tiene por qué, autenticarse mediante un certificado PKI firmado por una CA en el servidor. Esto simplifica enormemente el procedimiento de configuración, ya que no es necesario un certificado en cada cliente.
Una vez que el servidor se autentica de forma segura con el cliente a través de su certificado CA y, opcionalmente, el cliente con el servidor, el servidor puede utilizar la conexión segura establecida ("túnel") para autenticar al cliente. Puede utilizar un protocolo y una infraestructura de autenticación existentes y ampliamente implementados, que incorporen mecanismos de contraseñas y bases de datos de autenticación heredados, mientras que el túnel seguro proporciona protección contra escuchas clandestinas y ataques de intermediarios . Tenga en cuenta que el nombre del usuario nunca se transmite en texto claro sin cifrar, lo que mejora la privacidad.
Existen dos versiones distintas de EAP-TTLS: EAP-TTLS original (también conocido como EAP-TTLSv0) y EAP-TTLSv1. EAP-TTLSv0 se describe en RFC 5281, 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 por 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:
Es posible utilizar una credencial de autenticación diferente (y, por lo tanto, una técnica) en cada dirección. Por ejemplo, el servidor EAP se autentica a sí mismo utilizando un par de claves pública/privada y el par EAP utilizando una clave simétrica. Sin embargo, no todas las nueve combinaciones teóricas se esperan en la práctica. En concreto, el estándar RFC 5106 enumera cuatro casos de uso: el servidor se autentica con un par de claves asimétricas mientras que el cliente utiliza cualquiera de los tres métodos; y ambos lados utilizan una clave simétrica.
EAP-IKEv2 se describe en RFC 5106 y existe una implementación prototipo.
La autenticación flexible mediante túnel seguro (EAP-FAST; RFC 4851) es una propuesta de protocolo de Cisco Systems como reemplazo de LEAP . [23] El protocolo fue diseñado para abordar las debilidades de LEAP y, al mismo tiempo, preservar la implementación "liviana". 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.
El EAP-FAST tiene tres fases: [24]
Cuando se habilita el aprovisionamiento automático de PAC, EAP-FAST tiene una vulnerabilidad en la que un atacante puede interceptar el PAC y usarlo para comprometer las credenciales de usuario. Esta vulnerabilidad se mitiga con el aprovisionamiento manual de PAC o mediante el uso de certificados de servidor para la fase de aprovisionamiento de PAC.
Vale la pena señalar que el archivo PAC se emite por usuario. Este es un requisito de la sección 7.4.4 de RFC 4851, por lo que si un nuevo usuario inicia sesión en la red desde un dispositivo, primero se debe aprovisionar un nuevo archivo PAC. Esta es una de las razones por las que es difícil no ejecutar EAP-FAST en un modo de aprovisionamiento anónimo inseguro. La alternativa es utilizar contraseñas de dispositivo en su lugar, pero entonces el dispositivo se valida en la red, no el usuario.
EAP-FAST se puede utilizar sin archivos PAC, volviendo al 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 tienen 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 uso del protocolo de seguridad de la capa de transporte (TLS) para establecer un túnel autenticado mutuamente. 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 el envío de una solicitud en formato PKCS#10 . Después de 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 incluyen en los TLV correspondientes y se realizan de forma segura dentro del túnel TLS ya establecido.
El módulo de identidad de suscriptor EAP (EAP-SIM) se utiliza para la autenticación y la distribución de claves de sesión utilizando el módulo de identidad de suscriptor (SIM) del Sistema global para comunicaciones móviles ( GSM ).
Las redes celulares GSM utilizan una tarjeta de módulo de identidad del suscriptor para llevar a cabo la autenticación del usuario. EAP-SIM utiliza un algoritmo de autenticación SIM entre el cliente y un servidor de autenticación, autorización y contabilidad (AAA) 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) reemplaza 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 Kc-s de 64 bits que se combinarán/mezclarán para crear claves más seguras (los Kc-s no se utilizarán directamente). También se ha superado la falta de autenticación mutua en GSM.
EAP-SIM se describe en RFC 4186.
El Protocolo de autenticación extensible (EAP-AKA) para el sistema universal de telecomunicaciones móviles (UMTS) es un mecanismo EAP para la autenticación y distribución de claves de sesión mediante el módulo de identidad del suscriptor ( USIM ) de UMTS. EAP-AKA se define en 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 RFC 2284 y RFC 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 una serie de 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 .
El EAP con intercambio de claves cifradas , o EAP-EKE, es uno de los pocos métodos EAP que proporcionan una 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 fuera de banda ágil para EAP [28] (EAP-NOOB) es una solución genérica de arranque 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 de Internet de las cosas (IoT) que no incluyen información sobre ningún propietario, red o 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 una curva elíptica efímera Diffie-Hellman (ECDHE) sobre el canal EAP en banda. Luego, el usuario confirma este intercambio transfiriendo el mensaje OOB. Los usuarios pueden transferir el mensaje OOB del par al servidor, cuando, por ejemplo, el dispositivo es un televisor inteligente que puede mostrar un código QR. Alternativamente, los usuarios pueden transferir el mensaje OOB del servidor al par, cuando, por ejemplo, el dispositivo que se está iniciando es una cámara que solo puede leer un código QR.
EAP no es un protocolo de transmisión por cable, sino que solo define formatos de mensajes. Cada protocolo que utiliza EAP define una forma de encapsular los mensajes EAP dentro de los mensajes de ese protocolo. [30] [31]
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 se diseñó originalmente para IEEE 802.3 Ethernet en 802.1X-2001, pero se aclaró para adaptarse a otras tecnologías de LAN IEEE 802, como IEEE 802.11 inalámbrica y Fiber Distributed Data Interface (ANSI X3T9.5/X3T12, adoptada 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 (Identidad inicial del dispositivo, IDevID) en 802.1X-2010. [36]
Cuando un dispositivo de servidor de acceso a red (NAS) habilitado para 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 por pares, PMK) entre el cliente y el NAS, que luego puede usarse para una sesión de cifrado inalámbrico utilizando 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 el EAP dentro de un túnel de Seguridad de Capa de Transporte (TLS) potencialmente cifrado y autenticado . [37] [38] [39] El propósito era corregir deficiencias en el EAP; el EAP asumía un canal de comunicación protegido, como el proporcionado por la seguridad física, por lo que no se proporcionaban facilidades para la protección de la conversación del EAP. [40]
PEAP fue desarrollado conjuntamente por Cisco Systems, Microsoft y RSA Security. PEAPv0 era 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. [ cita requerida ]
Los protocolos RADIUS y Diameter AAA pueden encapsular mensajes EAP. Los dispositivos NAS ( Network Access Server ) suelen utilizarlos para reenviar paquetes EAP entre puntos finales IEEE 802.1X y servidores AAA para facilitar IEEE 802.1X.
El Protocolo para la transmisión de autenticación para el acceso a redes (PANA) es un protocolo basado en IP que permite que un dispositivo se autentique a sí mismo en una red para obtener acceso. PANA no definirá ningún nuevo protocolo de autenticación, distribución de claves, acuerdo de claves o protocolos de derivación de claves; para estos fines, se utilizará EAP y PANA transmitirá la carga útil de EAP. PANA permite la selección dinámica de proveedores de servicios, admite varios métodos de autenticación, es adecuado para usuarios itinerantes 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 respaldado a EAP desde que se creó como una alternativa al Protocolo de autenticación por desafío mutuo (CHAP) y al Protocolo de autenticación por contraseña (PAP), que finalmente se incorporaron a EAP. La extensión EAP de PPP se definió por primera vez en RFC 2284, ahora obsoleta por RFC 3748.
El mensaje certificate_request se incluye cuando el servidor desea que el par se autentique a sí mismo mediante una clave pública. Si bien el servidor EAP DEBERÍA requerir la autenticación del par, esto no es obligatorio, ya que existen circunstancias en las que no será necesaria la autenticación del par (por ejemplo, servicios de emergencia, como se describe en [UNAUTH]), o donde el par se autenticará mediante algún otro medio.