Saltar al contenido principal

EAP-TLS vs. PEAP: ¿Qué protocolo de autenticación es el adecuado para su red?

Una comparación técnica detallada de los protocolos de autenticación EAP-TLS y PEAP, que abarca la arquitectura de seguridad, la complejidad de implementación y las implicaciones de cumplimiento. Esta guía proporciona marcos de decisión prácticos para responsables de TI en los sectores de hostelería, retail, eventos y sector público que necesitan seleccionar el método de autenticación 802.1X adecuado para su infraestructura de WiFi empresarial.

Por Iain JewittPublicado Actualizado
📖 6 min de lectura1,667 palabras2 ejemplos prácticos3 preguntas de práctica9 definiciones clave

Video overview

Escuchar esta guía

Ver transcripción del podcast
EAP-TLS vs PEAP: ¿Qué protocolo de autenticación es el adecuado para su red? Una sesión informativa técnica de Purple [INTRODUCCIÓN - aproximadamente 1 minuto] Le damos la bienvenida a la sesión informativa técnica de Purple. Soy su anfitrión, y hoy vamos a analizar una de las decisiones más trascendentales que tomará al diseñar o actualizar la infraestructura inalámbrica de su empresa: la elección entre EAP-TLS y PEAP para su marco de autenticación 802.1X. Si es usted un responsable de TI, arquitecto de red o CTO a cargo de un grupo hotelero, un complejo comercial, un estadio o una organización del sector público, esta decisión afecta a su postura de seguridad, su nivel de cumplimiento y la carga de trabajo operativo diario que soporta su equipo. Así que vayamos directos al grano. Tanto EAP-TLS como PEAP son métodos de autenticación 802.1X. Ambos dependen de un servidor RADIUS para gestionar las solicitudes de autenticación y ofrecen una seguridad significativamente mayor que una contraseña WPA2 compartida. Pero la forma en que verifican la identidad es fundamentalmente diferente, y esa diferencia tiene importantes implicaciones para la forma en que despliega, gestiona y escala su red. [ANÁLISIS TÉCNICO DETALLADO - aproximadamente 5 minutos] Empecemos con EAP-TLS: Extensible Authentication Protocol Transport Layer Security. EAP-TLS es el estándar de oro de la autenticación de WiFi corporativa. Su característica definitoria es la autenticación mutua por certificado. Lo que esto significa en la práctica es lo siguiente: cuando un dispositivo intenta conectarse a su red, el servidor RADIUS presenta un certificado digital al dispositivo. El dispositivo comprueba ese certificado con sus Autoridades de Certificación de confianza. Pero aquí está la diferencia crítica con PEAP: a continuación, el dispositivo presenta su propio certificado al servidor. El servidor valida ese certificado de cliente y, solo si ambos certificados son válidos y de confianza, la red concede el acceso. No hay contraseñas implicadas. Ninguna. La autenticación se basa totalmente en certificados. Esto hace que EAP-TLS sea extraordinariamente resistente al robo de credenciales, a los ataques de diccionario y a los ataques de Man-in-the-Middle. Sencillamente, no se puede robar una contraseña que no existe en el flujo de autenticación. Ahora bien, la contrapartida es la complejidad del despliegue. Para ejecutar EAP-TLS a escala, se necesita una infraestructura de clave pública (PKI) para emitir, gestionar y revocar certificados para cada uno de los dispositivos de la red. También se necesita una solución de gestión de dispositivos móviles para enviar esos certificados de forma silenciosa a los terminales. Si gestiona un entorno corporativo con Microsoft Intune o Jamf, esto es totalmente viable. Si no es así, EAP-TLS se convierte en una tarea de gran envergadura. La otra consideración operativa es la gestión del ciclo de vida de los certificados. Los certificados caducan. Si el certificado de su servidor RADIUS caduca, todos los dispositivos de su red fallarán en la autenticación simultáneamente. Eso supone una interrupción catastrófica. Los procesos de supervisión y renovación de certificados son innegociables. Ahora examinemos PEAP: Protected Extensible Authentication Protocol. PEAP se diseñó para abordar la complejidad de implementación de EAP-TLS ofreciendo al mismo tiempo una seguridad robusta. La clave fundamental de PEAP es esta: solo se necesita que el servidor tenga un certificado. El cliente no necesita ninguno. Así es como funciona. El servidor RADIUS presenta su certificado al dispositivo cliente. El cliente valida al servidor - al igual que en EAP-TLS. Esto establece un túnel TLS cifrado. Dentro de ese túnel, el cliente realiza una autenticación estándar basada en contraseña, normalmente utilizando MSCHAPv2, contra su almacén de identidades - ya sea Active Directory, LDAP, Google Workspace o lo que sea que esté utilizando. La contraseña nunca viaja en texto plano. Siempre está protegida dentro del túnel cifrado. Por lo tanto, PEAP es verdaderamente seguro - siempre que esté configurado correctamente. Y ahí es donde tenemos que hablar sobre la configuración incorrecta más común y peligrosa en las implementaciones de PEAP. Si un dispositivo cliente no está configurado para validar estrictamente el certificado del servidor RADIUS, un atacante puede configurar un punto de acceso falso con el mismo nombre de red, presentar un certificado fraudulento y el dispositivo se conectará sin problemas. El atacante captura entonces el intercambio de autenticación MSCHAPv2, que puede ser descifrado sin conexión. Esto no es un ataque teórico - es una técnica bien documentada utilizada en pruebas de penetración reales. La solución es sencilla: utilice políticas de grupo (GPO), perfiles MDM o herramientas de incorporación para aplicar una validación estricta del certificado del servidor en cada dispositivo cliente. Pero la realidad operativa es que, en entornos BYOD, garantizar que esta configuración se aplique de forma coherente en miles de dispositivos personales no gestionados es verdaderamente difícil. Permítame ofrecerle una comparación concreta. Piense en una cadena de tiendas con 500 ubicaciones. Disponen de tabletas y escáneres portátiles propiedad de la empresa, todos gestionados a través de Microsoft Intune. EAP-TLS es la opción correcta. Intune distribuye los certificados automáticamente. Si se pierde un escáner, el departamento de TI revoca su certificado y queda fuera de la red en cuestión de minutos - sin restablecimiento de contraseñas ni cambios de contraseñas compartidas en 500 tiendas. La seguridad es absoluta. Piense ahora en un gran centro de conferencias que ofrece WiFi para 3.000 miembros del personal en sus dispositivos personales. Sin MDM. El personal utiliza Google Workspace. PEAP integrado con Google Secure LDAP es la opción pragmática. El personal se autentica con sus credenciales estándar. El equipo de TI proporciona documentación de incorporación para configurar la validación de certificados. Se puede implementar en días, no en meses. La arquitectura que sustenta ambos protocolos es el mismo modelo 802.1X de tres componentes: el suplicante - que es el dispositivo cliente -, el autenticador, que es su punto de acceso o switch, y el servidor RADIUS. El autenticador actúa como un guardián, bloqueando todo el tráfico hasta que el servidor RADIUS indica que la autenticación se ha realizado correctamente. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES - aproximadamente 2 minutos] Entonces, ¿cuáles son las recomendaciones prácticas? Primero: si dispone de una solución MDM y de dispositivos propiedad de la empresa, implemente EAP-TLS. La inversión inicial en PKI y gestión de certificados da sus frutos al reducir el riesgo y simplificar las auditorías de cumplimiento. Para entornos regulados - sector sanitario, financiero, público - esto no es opcional. Es la arquitectura que sus auditores esperan ver. Segundo: si gestiona un entorno BYOD o no dispone de infraestructura de MDM, implemente PEAP. Pero no se salte la configuración de validación del certificado del servidor. Utilice herramientas de incorporación, portales de control de acceso a la red o perfiles de MDM siempre que sea posible para exigir esto. Trátelo como un paso de despliegue obligatorio, no como una medida de refuerzo opcional. Tercero: independientemente del protocolo que elija, incorpore redundancia de RADIUS en su arquitectura. La autenticación es un proceso crítico. El fallo de un único servidor RADIUS significa que nadie puede acceder a la red. Las soluciones de RADIUS alojadas en la nube pueden proporcionar resiliencia sin los costes fijos de gestionar una infraestructura local redundante. Cuarto: segmente su red tras la autenticación. Una autenticación de 802.1X correcta no debería conceder acceso sin restricciones a toda su red corporativa. Utilice políticas de asignación de VLAN para ubicar a los usuarios en los segmentos de red adecuados con los controles de acceso correspondientes. Los errores comunes que deben evitarse: la expiración de certificados que causa fallos de autenticación masivos en despliegues EAP-TLS; los dispositivos cliente que no validan los certificados del servidor en despliegues PEAP; y los problemas de tiempo de espera de RADIUS causados por una alta latencia entre el controlador inalámbrico y el servidor de autenticación - especialmente relevante en entornos distribuidos geográficamente. [PREGUNTAS Y RESPUESTAS RÁPIDAS - aproximadamente 1 minuto] Permítame repasar algunas preguntas que escucho con frecuencia. ¿Puedo ejecutar tanto EAP-TLS como PEAP en la misma red? Sí. Muchas organizaciones ejecutan EAP-TLS para dispositivos corporativos en un SSID y PEAP para BYOD o acceso de invitados en un SSID independiente, con la segmentación de red adecuada entre ellos. ¿Modifica WPA3 esta decisión? WPA3 Enterprise exige el modo de seguridad de 192 bits para despliegues de alta seguridad, lo que se alinea con EAP-TLS. WPA3 Personal utiliza SAE en lugar de PSK, pero para los despliegues empresariales de 802.1X, la selección del método EAP sigue siendo relevante. ¿Cumple PEAP con PCI-DSS? Sí, cuando se configura correctamente exigiendo la validación del certificado del servidor. Sin embargo, para los entornos que gestionan datos de titulares de tarjetas, EAP-TLS es cada vez más el enfoque recomendado en las evaluaciones de seguridad. ¿Qué ocurre con OpenRoaming? OpenRoaming utiliza autenticación basada en certificados de forma interna, alineándose con los principios de EAP-TLS. Las plataformas como Purple pueden actuar como proveedor de identidad para OpenRoaming, lo que permite un roaming seguro y fluido entre ubicaciones sin necesidad de volver a autenticarse. [RESUMEN Y PASOS SIGUIENTES - aproximadamente 1 minuto] En resumen: EAP-TLS es la opción de mayor seguridad, ya que elimina por completo las contraseñas mediante la autenticación mutua por certificados. Requiere una infraestructura PKI y MDM, pero ofrece el nivel de cumplimiento más sólido y el control de acceso más detallado a nivel de dispositivo. PEAP es la opción pragmática para BYOD y entornos sin infraestructura de gestión de certificados, ya que proporciona una autenticación cifrada sólida utilizando las credenciales existentes, pero solo si la validación del certificado del servidor se aplica de forma rigurosa. El marco de decisión es sencillo: si gestiona sus dispositivos, utilice EAP-TLS. Si sus usuarios traen sus propios dispositivos, utilice PEAP - pero configúrelo correctamente. Para sus próximos pasos: audite su configuración de autenticación actual, evalúe su preparación para PKI y MDM, y revise su infraestructura RADIUS en busca de redundancia y latencia. Si está desplegando o actualizando el WiFi para invitados junto con su red corporativa, considere cómo una plataforma como Purple puede integrarse con su marco de autenticación para proporcionar tanto seguridad como análisis prácticos a partir de su red. Gracias por escuchar el Purple Technical Briefing. Hasta la próxima.

Parte de nuestra serie principal: Guía de seguridad para WiFi empresarial →

EAP-TLS vs. PEAP: ¿Qué protocolo de autenticación es el adecuado para su red?

Resumen Ejecutivo

Seleccionar el protocolo de autenticación adecuado es una decisión arquitectónica crítica que afecta tanto al estado de la seguridad como a los costes operativos. Para los responsables de TI, arquitectos de red y CTO que operan en entornos complejos, como Hospitality, Retail, estadios y organizaciones del sector público, la elección entre EAP-TLS y PEAP suele determinar el equilibrio entre una seguridad de hierro y la viabilidad del despliegue.

EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) se considera el estándar de oro para la seguridad de redes WiFi empresariales, ya que se basa en una autenticación mutua basada en certificados. PEAP (Protected Extensible Authentication Protocol), por el contrario, encapsula la autenticación estándar basada en contraseñas dentro de un túnel TLS cifrado, lo que reduce significativamente la complejidad del despliegue.

Esta guía de referencia técnica ofrece un análisis arquitectónico detallado y neutro con respecto a los proveedores de ambos protocolos. Analizamos su funcionamiento operativo, evaluamos la complejidad de sus despliegues y ofrecemos recomendaciones prácticas para garantizar que su infraestructura de red cumpla los estándares de seguridad modernos - incluidos los requisitos de PCI-DSS y GDPR - al tiempo que mantiene una conectividad sin interrupciones para sus usuarios.

Análisis técnico profundo: Arquitectura del protocolo

Para tomar una decisión informada, es fundamental comprender los mecanismos subyacentes de cómo estos protocolos aseguran el marco de autenticación 802.1X. Ambos protocolos utilizan un servidor RADIUS para gestionar las solicitudes de autenticación, pero sus métodos para validar la identidad difieren sustancialmente. Para comprender los aspectos fundamentales de la infraestructura RADIUS, consulte nuestra guía sobre ¿Qué es RADIUS? Cómo los servidores RADIUS aseguran las redes WiFi.

EAP-TLS: Autenticación mutua mediante certificados

EAP-TLS funciona bajo el principio de autenticación mutua. Tanto el dispositivo cliente (suplicante) como el servidor de autenticación (RADIUS) deben presentar certificados digitales válidos para establecer una conexión.

El saludo (Handshake): cuando un dispositivo intenta conectarse, el servidor RADIUS presenta su certificado al cliente. El cliente valida este certificado frente a sus Autoridades de Certificación (CA) raíz de confianza. Una vez verificado el servidor, el cliente presenta su propio certificado único de vuelta al servidor. Si ambos certificados son válidos y no han sido revocados - verificado a través de CRL u OCSP - se establece una sesión TLS segura y se concede el acceso a la red.

Esta verificación mutua hace que EAP-TLS sea altamente resistente al robo de credenciales, a los ataques de diccionario y a los ataques Man-in-the-Middle (MitM). Dado que no se transmiten contraseñas, las credenciales de usuario comprometidas no se pueden utilizar para vulnerar la red.

PEAP: Autenticación mediante contraseña tunelizada

PEAP se desarrolló como una alternativa de más fácil implementación que EAP-TLS, eliminando la necesidad de certificados en el lado del cliente y proporcionando al mismo tiempo una seguridad sólida.

Establecimiento del túnel: el servidor RADIUS presenta su certificado al cliente. El cliente valida el servidor, estableciendo un túnel TLS cifrado. Dentro de este túnel seguro, el cliente realiza la autenticación estándar basada en contraseña - normalmente MSCHAPv2 - contra un proveedor de identidad como Active Directory. El servidor RADIUS valida las credenciales y concede el acceso.

Aunque PEAP es altamente seguro cuando se configura correctamente, depende de que los usuarios mantengan contraseñas seguras. De manera crítica, si el dispositivo de un usuario no está configurado para validar el certificado del servidor, un punto de acceso no autorizado puede interceptar las credenciales. Esto no es un riesgo teórico; es un vector de ataque bien documentado utilizado en pruebas de penetración reales.

EAP-TLS vs. PEAP: ¿Qué protocolo de autenticación es el adecuado para su red? - comparison chart

Dimensión EAP-TLS PEAP
Nivel de seguridad Muy alto - autenticación mutua mediante certificados Alto - túnel cifrado, solo certificado de servidor
Tipo de credencial Certificados digitales de cliente y servidor Nombre de usuario y contraseña (dentro del túnel TLS)
Complejidad de implementación Mayor - requiere PKI y MDM Menor - se integra con los servicios de directorio existentes
Ideal para Flotas de dispositivos propiedad de la empresa, sectores regulados Entornos BYOD, organizaciones sin PKI
Requiere certificado de cliente Sí No
Adecuación para PCI-DSS / GDPR Excelente: preferido para entornos con alto nivel de cumplimiento Bueno: cumple con la normativa cuando se exige la validación del servidor

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.

Guía de implementación: Estrategias de despliegue

La principal divergencia entre EAP-TLS y PEAP radica en su complejidad de despliegue y en la gestión del ciclo de vida.

Despliegue de EAP-TLS

La implementación de EAP-TLS requiere una infraestructura de clave pública (PKI) robusta para emitir, gestionar y revocar certificados para cada dispositivo de la red. Las soluciones de gestión de dispositivos móviles (MDM) o de gestión de la movilidad empresarial (EMM) son prácticamente obligatorias para automatizar el aprovisionamiento de certificados en los endpoints a escala. Los equipos de TI deben gestionar el ciclo de vida de los certificados, gestionando las renovaciones antes de su vencimiento y garantizando la pronta revocación en caso de pérdida de dispositivos o salida de empleados. EAP-TLS es la opción más adecuada para redes corporativas con dispositivos propiedad de la empresa, entornos altamente regulados como el sector de Healthcare o financiero, y arquitecturas de confianza cero.

Despliegue de PEAP

PEAP es significativamente más fácil de desplegar porque aprovecha los almacenes de identidad existentes (Active Directory, LDAP o directorios en la nube) sin necesidad de certificados de cliente. Un servidor RADIUS con un certificado de servidor válido (idealmente de una CA pública) e integración con su servicio de directorio existente es suficiente para empezar. Los costes operativos son mínimos: los usuarios se autentican con sus credenciales corporativas estándar. Se aplican políticas de rotación de contraseñas, lo que puede causar un pequeño trabajo adicional de soporte técnico cuando los usuarios olvidan actualizar sus perfiles de WiFi tras un cambio de contraseña. PEAP es el más adecuado para entornos BYOD, sectores educativos y organizaciones sin una infraestructura PKI o MDM establecida.

EAP-TLS vs. PEAP: ¿Qué protocolo de autenticación es el adecuado para su red? - architecture overview

Buenas prácticas y estándares del sector

Independientemente del protocolo elegido, el cumplimiento de los estándares del sector no es negociable para mitigar el riesgo.

Exigir la validación del certificado del servidor: La vulnerabilidad más común en los despliegues de PEAP son los dispositivos de cliente mal configurados que no validan el certificado del servidor RADIUS. Esto permite a los atacantes configurar puntos de acceso no autorizados y recopilar credenciales. El departamento de TI debe utilizar políticas de grupo o perfiles MDM para exigir una validación estricta del servidor en cada endpoint.

Implementar redundancia de RADIUS: La autenticación es un proceso crítico. Asegúrese de que su infraestructura RADIUS sea de alta disponibilidad. Las soluciones RADIUS basadas en la nube pueden mitigar los puntos únicos de fallo locales. Las consideraciones arquitectónicas para la resiliencia de la red distribuida se analizan más detalladamente en The Core SD WAN Benefits for Modern Businesses. Integrar con proveedores de identidad modernos: para lugares de cara al público, aprovechar una plataforma robusta de Guest WiFi que actúe como un proveedor de identidad seguro puede agilizar el acceso manteniendo la seguridad. La licencia Connect de Purple, por ejemplo, proporciona un proveedor de identidad gratuito para servicios como OpenRoaming, cerrando la brecha entre la seguridad de nivel empresarial y la incorporación fluida de invitados.

Segmentación de red tras la autenticación: una autenticación 802.1X exitosa no debe otorgar acceso sin restricciones a toda la subred corporativa. Utilice políticas dinámicas de asignación de VLAN para ubicar a los usuarios en los segmentos de red adecuados con ACL restringidas.

Solución de problemas y mitigación de riesgos

Al gestionar redes 802.1X, los equipos de TI deben estar preparados para los modos de fallo comunes.

Expiración de certificados (EAP-TLS): si el certificado de la CA o el certificado del servidor RADIUS expira, toda la autenticación fallará simultáneamente. Implemente una monitorización y alertas proactivas para los periodos de validez de los certificados; configure alertas a los 90, 30 y 7 días antes de la expiración.

Configuración incorrecta del suplicante (PEAP): no validar el certificado del servidor es un riesgo crítico. Audite periódicamente las configuraciones de los endpoints para asegurarse de que se aplique estrictamente la opción "Validar certificado de servidor". Incluya esto como un elemento estándar en su lista de verificación de auditoría de seguridad.

Problemas de tiempo de espera de RADIUS: una latencia alta entre el controlador inalámbrico y el servidor RADIUS, o entre el servidor RADIUS y Active Directory, puede provocar tiempos de espera de EAP y fallos de autenticación. Garantice una conectividad sólida y considere proxies RADIUS locales para sitios distribuidos. Esto es especialmente relevante para implementaciones multisitio en sectores como el Transport y el comercio minorista.

Ataques de puntos de acceso no autorizados: realice evaluaciones periódicas de seguridad inalámbrica para detectar puntos de acceso no autorizados. Los sistemas de detección de intrusiones inalámbricas (WIDS) integrados en su infraestructura de puntos de acceso pueden proporcionar una monitorización continua.

Retorno de la inversión (ROI) e impacto empresarial

La decisión entre EAP-TLS y PEAP conlleva importantes implicaciones empresariales más allá de la arquitectura técnica.

EAP-TLS requiere un CapEx inicial más alto para las soluciones de PKI y MDM, junto con un OpEx continuo para la gestión de certificados. Sin embargo, proporciona el nivel más alto de mitigación de riesgos contra brechas basadas en credenciales, que pueden resultar en daños financieros y de reputación devastadores. Para los centros que gestionan datos sensibles o que operan bajo un estricto cumplimiento normativo, el ROI de EAP-TLS se materializa a través de la evitación de costes por brechas de seguridad y auditorías de cumplimiento más sencillas. Una sola brecha basada en credenciales en un entorno minorista o de hostelería puede costar millones en remediación, multas regulatorias y daños a la marca. PEAP ofrece una obtención de valor más rápida y menores costes de implementación. Es muy eficaz en entornos donde el objetivo principal es el acceso seguro y cifrado sin la sobrecarga de la gestión de dispositivos. Al integrar PEAP con una solución integral de WiFi Analytics, los establecimientos pueden gestionar el acceso de forma segura y obtener valiosa información operativa a partir de los datos de uso de la red - conectando la infraestructura de autenticación con resultados empresariales medibles, como el análisis del tiempo de permanencia, los patrones de afluencia y las tasas de visitantes recurrentes.

Definiciones clave

EAP (Protocolo de autenticación extensible)

Un marco de autenticación definido en IEEE 802.1X que proporciona el mecanismo de transporte para varios métodos de autenticación sobre la infraestructura de acceso a la red.

EAP es el marco general; EAP-TLS y PEAP son métodos específicos que se ejecutan dentro de él. Los equipos de TI se encuentran con EAP al configurar las políticas de RADIUS y los perfiles de suplicantes inalámbricos.

Suplicante

El dispositivo cliente (portátil, smartphone, escáner o dispositivo IoT) que inicia la solicitud de autenticación para unirse a la red.

Los equipos de TI deben asegurarse de que los suplicantes estén configurados correctamente, especialmente en lo que respecta a la validación de certificados, para evitar ataques de tipo Man-in-the-Middle. La configuración del suplicante es la fuente más común de vulnerabilidades en PEAP.

Autenticador

El dispositivo de red (normalmente un punto de acceso inalámbrico o un switch gestionado) que bloquea todo el tráfico del suplicante hasta que el servidor RADIUS confirma que la autenticación se ha realizado correctamente.

El autenticador actúa como guardián, pasando los mensajes EAP entre el suplicante y el servidor RADIUS sin procesar la autenticación por sí mismo.

Servidor RADIUS

Remote Authentication Dial-In User Service. El servidor centralizado que recibe las solicitudes de autenticación del autenticador, valida las credenciales con un almacén de identidades y devuelve una respuesta Access-Accept o Access-Reject.

El servidor RADIUS es el cerebro de la arquitectura 802.1X. La alta disponibilidad y la baja latencia entre el servidor RADIUS y el almacén de identidades (Active Directory, LDAP) son fundamentales para una autenticación fiable.

PKI (Infraestructura de clave pública)

El marco de funciones, políticas, hardware y software necesarios para crear, gestionar, distribuir y revocar certificados digitales.

Una PKI sólida es un requisito previo absoluto para implementar EAP-TLS con éxito a gran escala. Sin una PKI, la gestión del ciclo de vida de los certificados se vuelve inmanejable y genera un riesgo operativo significativo.

MDM (Gestión de dispositivos móviles)

Software utilizado por TI para supervisar, gestionar y proteger los dispositivos móviles corporativos, incluida la capacidad de enviar perfiles de configuración, certificados y políticas de forma silenciosa a los dispositivos registrados.

El MDM es fundamental en las implementaciones de EAP-TLS para automatizar el aprovisionamiento silencioso de certificados de cliente en los dispositivos de los usuarios finales. Microsoft Intune, Jamf y VMware Workspace ONE son plataformas MDM habituales.

Autenticación mutua

Un proceso de seguridad en el que ambas partes de un enlace de comunicación se autentican mutuamente antes de que se intercambien datos, a diferencia de la autenticación unidireccional en la que solo se verifica a una de las partes.

La característica definitoria de EAP-TLS. La autenticación mutua garantiza que el cliente sepa que se está comunicando con el servidor de red legítimo, y que el servidor sepa que se está comunicando con un dispositivo cliente autorizado.

MSCHAPv2 (Protocolo de autenticación por desafío mutuo de Microsoft v2)

Un protocolo de autenticación basado en contraseña que se utiliza habitualmente como método de autenticación interno dentro de los túneles PEAP. Utiliza un mecanismo de desafío y respuesta para evitar la transmisión de contraseñas en texto plano.

Los hashes de MSCHAPv2 se pueden capturar y descifrar sin conexión si el túnel PEAP se ve comprometido por un punto de acceso no autorizado. Por este motivo, la validación del certificado del servidor en PEAP no es negociable.

OpenRoaming

Un estándar de federación de WiFi que permite a los usuarios conectarse de forma automática y segura a las redes participantes en diferentes establecimientos y operadores sin tener que volver a autenticarse, utilizando una autenticación basada en certificados.

Purple actúa como un proveedor de identidad gratuito para OpenRoaming bajo su licencia Connect, lo que permite a los establecimientos ofrecer una conectividad fluida y segura que se alinea con los principios de autenticación de certificados EAP-TLS.

Ejemplos prácticos

Una cadena nacional de retail con 500 ubicaciones necesita proteger el acceso a la red corporativa para las tablets de los directores de tienda y los escáneres de inventario portátiles. Actualmente utilizan una clave WPA2-PSK compartida en todos los centros. Tienen Microsoft Intune implementado para la gestión de dispositivos.

Implementar EAP-TLS. Dado que la organización ya utiliza Microsoft Intune, la parte más compleja de la distribución de certificados ya está resuelta. Configure Intune para enviar certificados de cliente únicos a todas las tablets y escáneres propiedad de la empresa a través de un perfil de certificado SCEP o PKCS. La infraestructura inalámbrica se reconfigura para utilizar 802.1X apuntando a un servidor RADIUS central o basado en la nube (como Microsoft NPS o un servicio RADIUS en la nube). El servidor RADIUS se configura para aceptar la autenticación únicamente de los dispositivos que presenten certificados emitidos por la CA interna de la organización. Tras la autenticación, la asignación dinámica de VLAN ubica los dispositivos en el segmento de operaciones de tienda correspondiente.

Comentario del examinador: Este enfoque elimina el enorme riesgo de seguridad de una PSK compartida en 500 ubicaciones - una PSK comprometida en una tienda habría expuesto previamente a todos los centros. Con EAP-TLS, si un escáner se pierde o se roba, el departamento de TI simplemente revoca su certificado específico a través de la PKI, anulando instantáneamente su acceso a la red sin afectar a ningún otro dispositivo. EAP-TLS es la opción óptima aquí porque la infraestructura MDM hace que la gestión del ciclo de vida de los certificados sea escalable. El riesgo clave a vigilar es la caducidad de los certificados - asegúrese de que las políticas de renovación automática estén configuradas en Intune.

Un gran centro de conferencias necesita proporcionar WiFi seguro para 3000 empleados internos que utilizan sus propios dispositivos personales (BYOD). Utilizan Google Workspace para la identidad corporativa, pero no gestionan los teléfonos ni portátiles personales del personal.

Implementar PEAP (específicamente PEAP-MSCHAPv2 o EAP-TTLS/PAP contra Google Secure LDAP). El equipo de TI configura un servidor RADIUS integrado con Google Workspace Secure LDAP. Los miembros del personal se conectan al SSID 'Staff_WiFi' utilizando su correo electrónico y contraseña habituales de Google Workspace. El equipo de TI proporciona documentación de incorporación - idealmente a través de un Captive Portal o una herramienta de incorporación a la red - indicando al personal que configure sus dispositivos para confiar en el certificado específico del servidor RADIUS y validar el nombre de dominio del servidor. Se mantiene un SSID de invitados independiente para los asistentes al evento, gestionado a través de la plataforma Guest WiFi de Purple para analíticas y control de acceso.

Comentario del examinador: EAP-TLS es inviable en este caso porque la organización no tiene el control de MDM sobre los dispositivos personales para enviar los certificados. PEAP proporciona un túnel seguro y cifrado para la autenticación utilizando las credenciales existentes, lo que lo hace muy fácil de implementar para escenarios BYOD y al mismo tiempo protege contra la interceptación de datos. El paso operativo crítico es el proceso de incorporación - el equipo de TI debe asegurarse de que el dispositivo de cada miembro del personal esté correctamente configurado para validar el certificado del servidor. No hacerlo es el mayor riesgo individual en esta implementación.

Preguntas de práctica

Q1. El departamento de TI de una universidad está implementando un acceso WiFi seguro en todo el campus para 20.000 estudiantes. Los estudiantes traen sus propios portátiles y smartphones con una combinación de Windows, macOS, iOS y Android. El director de TI insiste en la máxima seguridad y propone EAP-TLS. ¿Cuál es su recomendación arquitectónica?

Sugerencia: Tenga en cuenta la sobrecarga operativa que supone la gestión de certificados en dispositivos personales no gestionados dentro de un parque de dispositivos heterogéneo.

Ver respuesta modelo

Desaconseje el uso de EAP-TLS para este caso de uso específico. Aunque EAP-TLS ofrece el nivel más alto de seguridad, implementar y gestionar más de 20.000 certificados de cliente en dispositivos de estudiantes no gestionados sin una solución MDM creará una carga de soporte insalvable. Los estudiantes cambian de dispositivo con frecuencia, y el proceso de incorporación para la instalación de certificados en iOS, Android, Windows y macOS es complejo sin la automatización de un MDM. Recomiende PEAP (o EAP-TTLS) integrado con el servicio de directorio de estudiantes de la universidad. Asegúrese de utilizar herramientas de incorporación robustas para configurar los dispositivos de los estudiantes para que validen estrictamente el certificado del servidor. Opcionalmente, implemente EAP-TLS en un SSID independiente para los dispositivos del personal que estén gestionados por la universidad, creando así una arquitectura de seguridad por niveles.

Q2. ¿Durante una auditoría de seguridad, un pentester logra capturar credenciales de usuario de su red inalámbrica protegida con PEAP configurando un punto de acceso no autorizado que emite el mismo SSID. ¿Cuál es la causa raíz de esta vulnerabilidad y cuál es la solución?

Sugerencia: Piense en lo que ocurre durante la fase de establecimiento del túnel TLS en PEAP, y en lo que el dispositivo cliente está - o no está - comprobando.

Ver respuesta modelo

La causa raíz es una configuración incorrecta del suplicante. Los dispositivos cliente no están configurados para validar estrictamente el certificado digital del servidor RADIUS. Cuando el punto de acceso no autorizado presentó un certificado fraudulento, los dispositivos cliente confiaron plenamente en él, establecieron el túnel TLS con el atacante y transmitieron el intercambio de autenticación MSCHAPv2. El atacante puede descifrar esto sin conexión. La solución es triple: (1) aplicar una validación estricta del certificado del servidor mediante directivas de grupo o perfiles MDM en todos los dispositivos cliente; (2) especificar el nombre de dominio exacto esperado del servidor RADIUS en la configuración del suplicante para evitar la aceptación de certificados de otros dominios; (3) implementar un Sistema de Detección de Intrusiones Inalámbricas (WIDS) para detectar y alertar sobre puntos de acceso no autorizados.

Q3. Un proveedor de servicios sanitarios está actualizando su red para dar soporte a estaciones de trabajo de enfermería móviles que acceden a historiales médicos. Estas estaciones de trabajo son propiedad de la empresa, están estrictamente gestionadas por TI a través de Microsoft Intune y el entorno debe cumplir con las normativas de protección de datos sanitarios. ¿Deberían implementar PEAP o EAP-TLS?

Sugerencia: Evalúe el entorno normativo, el nivel de control de los dispositivos y la confidencialidad de los datos a los que se accede.

Ver respuesta modelo

Implemente EAP-TLS sin dudarlo. El entorno sanitario requiere un cumplimiento normativo estricto y la máxima seguridad contra el robo de credenciales - una contraseña comprometida en una red sanitaria puede exponer historiales de pacientes y acarrear sanciones reglamentarias importantes en virtud del GDPR y de los requisitos de protección de datos específicos del sector. Dado que los dispositivos son propiedad de la empresa y están gestionados estrictamente a través de Microsoft Intune, la implementación de certificados de cliente es viable desde el punto de vista operativo y puede automatizarse por completo. EAP-TLS proporciona la autenticación mutua necesaria para garantizar que solo los dispositivos autorizados y gestionados por la empresa puedan acceder a la red clínica. Además, EAP-TLS simplifica las auditorías de cumplimiento - los auditores que revisen la arquitectura de red verán un sistema de autenticación sin contraseñas basado en certificados que es inherentemente más defendible que las alternativas basadas en contraseñas.

Preguntas frecuentes

¿Cuál es la diferencia clave entre EAP-TLS y PEAP?

La diferencia fundamental es la autenticación mutua mediante certificados digitales. EAP-TLS requiere certificados criptográficos X.509 tanto en el servidor RADIUS como en el dispositivo cliente, lo que elimina por completo las contraseñas y los ataques basados en credenciales. PEAP (normalmente PEAP-MSCHAPv2) solo requiere un certificado digital en el servidor RADIUS, mientras que los dispositivos cliente se autentican utilizando nombres de usuario y contraseñas tradicionales encapsulados a través de una sesión TLS cifrada.

¿Por qué se considera que PEAP-MSCHAPv2 es vulnerable al robo de credenciales y a los ataques de puntos de acceso no autorizados?

PEAP-MSCHAPv2 depende de que el dispositivo cliente valide el certificado del servidor RADIUS antes de transmitir las credenciales. En la práctica, los terminales no gestionados y los suplicantes mal configurados a menudo no validan el certificado del servidor o el nombre de dominio. Un atacante que opere un punto de acceso no autorizado (Evil Twin) puede presentar un certificado falso, capturar el intercambio de desafío y respuesta de MSCHAPv2 y descifrar la contraseña del usuario fuera de línea mediante ataques de diccionario o tablas arcoíris basados en la nube.

¿Se puede desplegar EAP-TLS en dispositivos no gestionados o BYOD?

Desplegar EAP-TLS en dispositivos personales no gestionados requiere un flujo de trabajo de incorporación automatizado o un asistente de incorporación en el Captive Portal que proporcione un certificado de cliente de corta duración o revocable. Debido a que la instalación manual de certificados es compleja para los usuarios no técnicos, las organizaciones que carecen de un mecanismo automatizado de incorporación de certificados a menudo despliegan EAP-TTLS con credenciales de directorio en la nube o WPA3-Enterprise con perfiles Passpoint para flotas BYOD.

¿Cómo gestiona Microsoft Entra ID el protocolo EAP-TLS en comparación con PEAP?

Microsoft Entra ID (anteriormente Azure AD) no es compatible con los protocolos de autenticación heredados basados en contraseñas como MSCHAPv2 porque no almacena hashes de contraseñas de forma local. Como resultado, los entornos nativos en la nube de Entra ID no pueden autenticar directamente PEAP-MSCHAPv2 sin controladores de dominio híbridos heredados. EAP-TLS es el estándar para las redes de Entra ID, combinando Microsoft Intune y Cloud PKI o SCEP con un servidor RADIUS en la nube para autenticar dispositivos basados en una identidad de directorio verificada.

¿Qué infraestructura operativa se requiere para gestionar los certificados de cliente EAP-TLS?

EAP-TLS requiere una infraestructura de clave pública (PKI) - ya sea una autoridad de certificación local (como AD CS) o un servicio PKI en la nube - y una plataforma de gestión de dispositivos móviles (MDM) como Microsoft Intune, Jamf o Workspace ONE para emitir, renovar y revocar certificados automáticamente a través de SCEP (RFC 8894) o EST. La red WiFi también requiere un servidor RADIUS compatible con 802.1X para validar las cadenas de certificados entrantes y comprobar el estado de revocación a través de CRL u OCSP.

¿Cómo simplifica el uso de un RADIUS en la nube la migración de PEAP a EAP-TLS?

Un RADIUS en la nube elimina la necesidad de desplegar y parchear servidores RADIUS físicos locales (como Windows Server NPS o clústeres FreeRADIUS). Las plataformas modernas de RADIUS en la nube se integran directamente con proveedores de identidad en la nube como Microsoft Entra ID, Okta y Google Workspace, validan dinámicamente los certificados de cliente frente a las CA emisoras y asignan VLAN y políticas de acceso basadas en roles sin necesidad de hardware local ni túneles VPN.

Continúe leyendo esta serie

Resolución de problemas de 802.1X en iOS y macOS: una lista de verificación de despliegue para Intune, Jamf y Microsoft Entra ID

Utilice esta lista de verificación para diagnosticar por qué los iPhones, iPads y Macs fallan al conectar con 802.1X en Intune o Jamf Pro. Cada fallo se asocia a una de estas cuatro causas: confianza en el servidor, certificado de identidad, modo macOS o ámbito de grupo de Microsoft Entra ID. Confirmará la causa mediante los registros de eapolclient y RADIUS, aplicará la solución y organizará las futuras rotaciones de certificados.

Leer la guía →

Confianza en el servidor del perfil de WiFi de Intune: nombres de servidor de certificados y lista de verificación de CA raíz para Microsoft Entra ID

Podrá configurar la mitad de la validación del servidor de un perfil de WiFi de Intune para que EAP-TLS y PEAP se conecten en Windows, Apple y Android. Hará coincidir los nombres de los servidores de certificados con el certificado de RADIUS, implementará la CA raíz correcta, alineará las asignaciones de grupos de Microsoft Entra ID y preparará las renovaciones de certificados antes de que interrumpan silenciosamente las conexiones.

Leer la guía →

Resolución de problemas de 802.1X y EAP-TLS en Android: lista de comprobación de despliegue para Intune y Microsoft Entra ID

Podrá identificar exactamente por qué los teléfonos Android gestionados fallan al usar EAP-TLS en el SSID de su personal y solucionarlo en Intune. Asocie cada síntoma con las cuatro causas habituales: falta de CA o dominio, certificado de cliente en el perfil incorrecto, valor de nombres de servidor RADIUS no coincidente o raíz de confianza no entregada. A continuación, aplique una lista de comprobación de despliegue que evite interrupciones repetidas.

Leer la guía →

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.