stringtranslate.com

Protocolo de autenticación extensible

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.

Métodos

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 funcionar 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.

Protocolo de autenticación extensible y ligero (LEAP)

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.

Seguridad de la capa de transporte EAP (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

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]

Contraseña de un solo uso protegida por EAP (EAP-POTP)

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]

Clave precompartida EAP (EAP-PSK)

[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.

Contraseña EAP (EAP-PWD)

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]

Seguridad de la capa de transporte en túnel EAP (EAP-TTLS)

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]

Intercambio de claves de Internet EAP v. 2 (EAP-IKEv2)

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:

Pares de claves asimétricas
Pares de claves pública/privada donde la clave pública está incorporada en un certificado digital y la clave privada correspondiente es conocida solo por una única parte.
Contraseñas
Cadenas de bits de baja entropía que son conocidas tanto por el servidor como por el par.
Llaves simétricas
Cadenas de bits de alta entropía que son conocidas tanto por el servidor como por el par.

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.

Autenticación flexible EAP mediante túnel seguro (EAP-FAST)

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]

Protocolo de autenticación extensible por túnel (TEAP)

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.

Módulo de identidad del suscriptor EAP (EAP-SIM)

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.

Acuerdo de clave y autenticación EAP (EAP-AKA)

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.

Autenticación EAP y acuerdo de claveprincipal(EAP-TAMBIÉN CONOCIDO COMO')

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 .

Tarjeta de token genérica EAP (EAP-GTC)

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 .

Intercambio de claves cifradas EAP (EAP-EKE)

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.

Autenticación fuera de banda ágil para EAP (EAP-NOOB)

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.

Encapsulación

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]

IEEE802.1X

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 ).

PEAP

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 ]

RADIO y Diámetro

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.

PANA

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.

PPP

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.

Véase también

Referencias

  1. ^ ab "Introducción". Protocolo de autenticación extensible (EAP). sec. 1. doi : 10.17487/RFC3748 . RFC 3748.
  2. ^ "Registro del Protocolo de Autenticación Extensible (EAP)" www.iana.org . Consultado el 1 de junio de 2021 .
  3. ^ George Ou (11 de enero de 2007). "Guía de seguridad inalámbrica definitiva: Introducción a la autenticación LEAP". TechRepublic . Consultado el 17 de febrero de 2008 .
  4. ^ Dan Jones (1 de octubre de 2003). "Mira antes de dar un salto". Unstrung. Archivado desde el original el 9 de febrero de 2008. Consultado el 17 de febrero de 2008 .
  5. ^ "Comprensión de los estándares WPA y WPA2 actualizados". techrepublic.com . Consultado el 17 de febrero de 2008 .
  6. ^ ab Byrd, Christopher (5 de mayo de 2010). «Open Secure Wireless» (PDF) . Archivado desde el original (PDF) el 12 de diciembre de 2013. Consultado el 14 de agosto de 2013 .
  7. ^ ab El protocolo de autenticación EAP-TLS. Marzo de 2008. doi : 10.17487/RFC5216 . RFC 5216. 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.
  8. ^ "Agregar tipo de EAP específico del proveedor UNAUTH-TLS". hostapd . Archivado desde el original el 13 de febrero de 2013 . Consultado el 14 de agosto de 2013 .
  9. ^ "HS 2.0R2: Agregar método de pares EAP-TLS solo para servidor WFA". hostapd . Archivado desde el original el 2014-09-30 . Consultado el 2014-05-06 .
  10. ^ "HS 2.0R2: Agregar método de servidor EAP-TLS exclusivo para servidores WFA". hostapd . Archivado desde el original el 2014-09-30 . Consultado el 2014-05-06 .
  11. ^ Byrd, Christopher (1 de noviembre de 2011). «Open Secure Wireless 2.0». Archivado desde el original el 26 de noviembre de 2013. Consultado el 14 de agosto de 2013 .
  12. ^ Rand Morimoto; Kenton Gardinier; Michael Noel; Joe Coca (2003). Microsoft Exchange Server 2003 Unleashed. Sams. pág. 244. ISBN 978-0-672-32581-6.
  13. ^ "Esquemas de cifrado alternativos: cómo abordar las debilidades del WEP estático". Ars Technica . Consultado el 17 de febrero de 2008 .
  14. ^ "922574", Base de conocimientos , Microsoft
  15. ^ "Protocolo de autenticación EAP-POTP". Juniper.net . Consultado el 17 de abril de 2014 .
  16. ^ Módulo EAP de FreeRADIUS rlm_eap_pwd
  17. ^ McCauley, Mike. "Compatibilidad añadida con EAP-PWD según RFC 5931". radiador-anuncio (Lista de correo).
  18. ^ Autenticación segura con solo una contraseña
  19. ^ Configuración del Protocolo de autenticación extensible (EAP) para el acceso a la red
  20. ^ "¿Compatibilidad con TTLS 802.1x/EAP? – Foros de Windows Phone Central". Forums.wpcentral.com . Consultado el 17 de abril de 2014 .
  21. ^ "Autenticación de Wi-Fi empresarial (EAP)". Microsoft.com . Consultado el 23 de abril de 2014 .
  22. ^ Protocolo de autenticación TLS tunelizado EAP versión 1 (EAP-TTLSv1). ID draft-funk-eap-ttls-v1-01.
  23. ^ "Guía definitiva sobre seguridad inalámbrica: introducción a la autenticación Cisco EAP-FAST". techrepublic.com. Archivado desde el original el 24 de marzo de 2008. Consultado el 17 de febrero de 2008 .
  24. ^ "EAP-FAST > Protocolos de autenticación EAP para redes WLAN". Ciscopress.com . Consultado el 17 de abril de 2014 .
  25. ^ "Guía del administrador de EAP-FAST para Windows Vista". Archivado desde el original el 10 de febrero de 2009.
  26. ^¿ Cómo instalo CISCO EAP-FAST en mi computadora?
  27. ^ EAPHost en Windows
  28. ^ Aura, Tuomas; Sethi, Mohit; Peltonen, A. (diciembre de 2021). Autenticación fuera de banda ágil para EAP (EAP-NOOB). doi : 10.17487/RFC9140 . RFC 9140.
  29. ^ Modelo EAP-NOOB en GitHub
  30. ^ Pedersen, Torben (2005). "HTTPS, HTTPS seguro". Enciclopedia de criptografía y seguridad . págs. 268-269. doi :10.1007/0-387-23483-7_189. ISBN . 978-0-387-23473-1.
  31. ^ Plumb, Michelle, CAPPS: Redes HTTPS , OCLC  944514826
  32. ^ "Uso de EAP dentro de IEEE 802". Protocolo de autenticación extensible (EAP). sec. 3.3. doi : 10.17487/RFC3748 . RFC 3748.
  33. ^ "Capa de enlace". Protocolo de autenticación extensible (EAP). sec. 7.12. doi : 10.17487/RFC3748 . RFC 3748.
  34. ^ IEEE 802.1X-2001, § 7
  35. ^ IEEE 802.1X-2004, § 3.2.2
  36. ^ IEEE 802.1X-2010, § 5
  37. ^ "Encapsulación EAP". Versión 0 de PEAP de Microsoft (implementación en Windows XP SP1). sección 1.1. ID draft-kamath-pppext-peapv0-00.
  38. ^ ab Protocolo EAP protegido (PEAP) versión 2. Resumen. ID draft-josefsson-pppext-eap-tls-eap-10.
  39. ^ "Introducción". Protocolo EAP Protegido (PEAP), versión 2. Sección 1. ID draft-josefsson-pppext-eap-tls-eap-10.
  40. ^ "Introducción". Protocolo EAP Protegido (PEAP), versión 2. Sección 1. ID draft-josefsson-pppext-eap-tls-eap-07.
  41. ^ Protocolo EAP protegido (PEAP). sec. 2.3. ID draft-josefsson-pppext-eap-tls-eap-05.
  42. ^ "Negociación de versiones". Protocolo EAP protegido (PEAP). Sección 2.3. ID draft-josefsson-pppext-eap-tls-eap-06.
  43. ^ "Descripción general del protocolo". Protocolo EAP protegido (PEAP), versión 2. pág. 11. ID draft-josefsson-pppext-eap-tls-eap-10.

Lectura adicional

Enlaces externos