Saltar al contenido principal

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

Una comparación técnica completa de los protocolos de autenticación EAP-TLS y PEAP, que abarca la arquitectura de seguridad, la complejidad de la implementación y las implicaciones de cumplimiento. Esta guía proporciona marcos de decisión prácticos para líderes de TI en sectores como hotelería, retail, eventos y entornos del 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,477 palabras2 ejemplos resueltos3 preguntas de práctica9 definiciones clave

Video overview

Escucha 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 nos adentraremos en una de las decisiones más trascendentales que tomará al diseñar o actualizar su infraestructura inalámbrica empresarial: la elección entre EAP-TLS y PEAP para su marco de autenticación 802.1X. Si usted es un gerente de TI, arquitecto de red o CTO responsable de un grupo hotelero, un complejo comercial, un estadio o una organización del sector público, esta decisión afecta su postura de seguridad, su nivel de cumplimiento y la carga operativa diaria que soporta su equipo. Así que vayamos directo 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 ambos ofrecen una seguridad significativamente más sólida que una frase de contraseña compartida de WPA2. Pero la forma en que verifican la identidad es fundamentalmente diferente - y esa diferencia tiene implicaciones importantes para la forma en que implementa, gestiona y escala su red. [ANÁLISIS TÉCNICO PROFUNDO - aproximadamente 5 minutos] Comencemos con EAP-TLS - Extensible Authentication Protocol Transport Layer Security. EAP-TLS es el estándar de oro de la autenticación de WiFi empresarial. La característica definitoria es la autenticación mutua por certificados. 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 verifica ese certificado frente a sus Autoridades de Certificación de confianza. Pero aquí está la diferencia crítica con PEAP - el dispositivo presenta entonces su propio certificado de vuelta al servidor. El servidor valida ese certificado de cliente, y solo si ambos certificados son válidos y de confianza, la red otorga el acceso. No hay contraseñas involucradas. Ninguna. La autenticación se basa completamente en certificados. Esto hace que EAP-TLS sea extraordinariamente resistente al robo de credenciales, a los ataques de diccionario y a los ataques de intermediario (Man-in-the-Middle). Sencillamente no se puede robar una contraseña que no existe en el flujo de autenticación. Ahora bien, la desventaja es la complejidad de la implementación. Para ejecutar EAP-TLS a escala, necesita una infraestructura de clave pública - una PKI - para emitir, gestionar y revocar certificados para cada uno de los dispositivos de su red. También necesita una solución de gestión de dispositivos móviles para enviar esos certificados de forma silenciosa a los endpoints. 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 expiran. Si el certificado de su servidor RADIUS expira, la autenticación de todos los dispositivos de su red fallará simultáneamente. Eso representa una caída catastrófica del servicio. Los procesos de monitoreo y renovación de certificados son innegociables. Ahora analicemos PEAP - Protected Extensible Authentication Protocol. PEAP fue diseñado para abordar la complejidad de implementación de EAP-TLS al tiempo que proporciona una seguridad sólida. La clave detrás de PEAP es esta: solo se necesita que el servidor tenga un certificado. El dispositivo cliente no necesita uno. Así es como funciona. El servidor RADIUS presenta su certificado al dispositivo cliente. El cliente valida al servidor, tal como en EAP-TLS. Esto establece un túnel TLS cifrado. Dentro de ese túnel, el cliente realiza la autenticación estándar basada en contraseña, normalmente utilizando MSCHAPv2, contra su almacén de identidades: 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 genuinamente seguro, siempre que se configure correctamente. Y ahí es donde debemos 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 luego captura el intercambio de autenticación MSCHAPv2, que se puede descifrar sin conexión. Este no es un ataque teórico - es una técnica bien documentada utilizada en pruebas de penetración del mundo real. La solución es sencilla: use directivas de grupo, perfiles MDM o herramientas de incorporación para imponer 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 manera consistente en miles de dispositivos personales no administrados es realmente difícil. Permítame darle una comparación concreta. Considere una cadena minorista de 500 ubicaciones. Tienen tabletas y escáneres portátiles propiedad de la empresa, todos administrados 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 restablecimientos de contraseña ni cambios de frase de contraseña compartida en 500 tiendas. La seguridad es absoluta. Ahora considere un gran centro de conferencias que opera 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. Es implementable 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 ha sido exitosa. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES - aproximadamente 2 minutos] Entonces, ¿cuáles son las recomendaciones prácticas? Primero: si cuenta con una solución MDM y dispositivos propiedad de la empresa, implemente EAP-TLS. La inversión inicial en PKI y gestión de certificados rinde frutos en forma de reducción de riesgos y auditorías de cumplimiento simplificadas. Para entornos regulados - sector salud, finanzas, sector público - esto no es opcional. Es la arquitectura que sus auditores esperan ver. Segundo: si opera en un entorno BYOD o no cuenta con infraestructura MDM, implemente PEAP. Pero no omita 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 MDM donde sea posible para exigir esto. Trátelo como un paso de implementación obligatorio, no como una medida de seguridad opcional. Tercero: independientemente del protocolo que elija, incorpore redundancia RADIUS en su arquitectura. La autenticación es una ruta crítica. Una sola falla en el servidor RADIUS significa que nadie puede acceder a la red. Las soluciones RADIUS alojadas en la nube pueden proporcionar resiliencia sin la sobrecarga que implica gestionar una infraestructura local redundante. Cuarto: segmente su red después de la autenticación. Una autenticación 802.1X exitosa no debe otorgar 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 se deben evitar: el vencimiento de certificados que causa fallas masivas de autenticación en implementaciones EAP-TLS; los dispositivos cliente que no validan los certificados del servidor en implementaciones 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 - algo particularmente relevante en propiedades distribuidas 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. ¿WPA3 cambia esta decisión? WPA3 Enterprise exige el modo de seguridad de 192 bits para implementaciones de alta seguridad, lo cual se alinea con EAP-TLS. WPA3 Personal utiliza SAE en lugar de PSK, pero para implementaciones empresariales de 802.1X, la selección del método EAP sigue siendo relevante. ¿PEAP cumple con PCI-DSS? Sí, cuando se configura correctamente exigiendo la validación del certificado del servidor. Sin embargo, para entornos que manejan datos de tarjetahabientes, EAP-TLS es cada vez más el enfoque recomendado en las evaluaciones de seguridad. ¿Qué pasa 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 un proveedor de identidad para OpenRoaming, permitiendo un roaming seguro y sin interrupciones a través de diferentes sitios sin necesidad de volver a autenticarse. [RESUMEN Y PRÓXIMOS PASOS - aproximadamente 1 minuto] En resumen: EAP-TLS es la opción de mayor seguridad, ya que elimina las contraseñas por completo mediante la autenticación mutua de certificados. Requiere una infraestructura PKI y MDM, pero ofrece la postura de cumplimiento más sólida y el control de acceso a nivel de dispositivo más detallado. 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 cuando la validación del certificado del servidor se aplica rigurosamente. 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 para detectar redundancia y latencia. Si está implementando 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 boletín técnico de Purple. Hasta la próxima.

Parte de nuestra serie principal: Guía de seguridad de 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 a la postura de seguridad como a la carga operativa. Para los administradores 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 a menudo dicta el equilibrio entre una seguridad de hierro y la viabilidad de la implementación.

EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) es considerado ampliamente como el estándar de oro para la seguridad de WiFi empresarial, ya que se basa en la 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 de la implementación.

Esta guía de referencia técnica proporciona un análisis arquitectónico profundo e independiente del proveedor para ambos protocolos. Exploramos su mecánica operativa, evaluamos las complejidades de implementación y brindamos recomendaciones prácticas para garantizar que su infraestructura de red cumpla con los estándares de seguridad modernos - incluyendo el cumplimiento de PCI-DSS y GDPR - al mismo tiempo que se mantiene una conectividad fluida para sus usuarios.

Technical Deep-Dive: Protocol Architecture

To make an informed decision, it is essential to understand the underlying mechanics of how these protocols secure the 802.1X authentication framework. Both protocols utilise a RADIUS server to handle authentication requests, but their methods of validating identity differ fundamentally. For a foundational understanding of RADIUS infrastructure, refer to our guide on What Is RADIUS? How RADIUS Servers Secure WiFi Networks.

EAP-TLS: Mutual Certificate Authentication

EAP-TLS operates on the principle of mutual authentication. Both the client device (supplicant) and the authentication server (RADIUS) must present valid digital certificates to establish a connection.

The Handshake: When a device attempts to connect, the RADIUS server presents its certificate to the client. The client validates this certificate against its trusted Root Certificate Authorities (CAs). Once the server is verified, the client presents its own unique certificate back to the server. If both certificates are valid and have not been revoked - checked via CRL or OCSP - a secure TLS session is established and network access is granted.

This mutual verification makes EAP-TLS highly resistant to credential theft, dictionary attacks, and Man-in-the-Middle (MitM) attacks. Because no passwords are transmitted, compromised user credentials cannot be used to breach the network.

PEAP: Tunnelled Password Authentication

PEAP was developed as a more deployable alternative to EAP-TLS, eliminating the need for client-side certificates while still providing robust security.

Tunnel Establishment: The RADIUS server presents its certificate to the client. The client validates the server, establishing an encrypted TLS tunnel. Within this secure tunnel, the client performs standard password-based authentication - typically MSCHAPv2 - against an identity provider such as Active Directory. The RADIUS server validates the credentials and grants access.

While PEAP is highly secure when configured correctly, it relies on users maintaining strong passwords. Critically, if a user's device is not configured to validate the server certificate, a rogue access point can intercept credentials. This is not a theoretical risk; it is a well-documented attack vector used in real-world penetration tests.

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

Dimension EAP-TLS PEAP
Security Level Very High - mutual certificate authentication High - encrypted tunnel, server certificate only
Credential Type Client and server digital certificates Username and password (inside TLS tunnel)
Deployment Complexity Higher - requires PKI and MDM Lower - integrates with existing directory services
Ideal para Flotas de dispositivos de la empresa, industrias reguladas Entornos BYOD, organizaciones sin PKI
Requiere certificado de cliente Sí No
Cumplimiento de PCI-DSS / GDPR Excelente - preferido para entornos con alto nivel de cumplimiento Bueno - cumple cuando se fuerza la validación del servidor

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

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

Guía de implementación: estrategias de despliegue

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

Desplegando 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 en la red. Las soluciones de Mobile Device Management (MDM) o Enterprise Mobility Management (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, manejando 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 ideal para redes corporativas con dispositivos propiedad de la empresa, entornos altamente regulados como el sector de la salud o financiero, y arquitecturas zero-trust.

Desplegando 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 requerir 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 comenzar. La carga operativa es mínima: los usuarios se autentican con sus credenciales corporativas estándar. Se aplican las políticas de rotación de contraseñas, lo que puede causar un impacto menor en el soporte técnico cuando los usuarios olvidan actualizar sus perfiles de WiFi después de un cambio de contraseña. PEAP es ideal para entornos BYOD, el sector educativo y organizaciones que no cuentan con una infraestructura de PKI o MDM establecida.

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

Mejores prácticas y estándares de la industria

Independientemente del protocolo elegido, el cumplimiento de los estándares de la industria es innegociable para mitigar los riesgos.

Forzar 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 maliciosos y recopilar credenciales. El equipo de TI debe utilizar políticas de grupo o perfiles de MDM para forzar una validación estricta del servidor en cada endpoint.

Implementar redundancia RADIUS: La autenticación es una ruta crítica. Asegúrese de que su infraestructura RADIUS tenga una alta disponibilidad. Las soluciones RADIUS basadas en la nube pueden aliviar los puntos únicos de falla locales. Las consideraciones de arquitectura para la resiliencia de redes distribuidas se analizan a detalle en The Core SD WAN Benefits for Modern Businesses.

Integrate with Modern Identity Providers: For public-facing venues, leveraging a robust Guest WiFi platform that acts as a secure identity provider can streamline access while maintaining security. Purple's Connect licence, for example, provides a free identity provider for services like OpenRoaming, bridging the gap between enterprise-grade security and seamless guest onboarding.

Network Segmentation Post-Authentication: A successful 802.1X authentication should not grant unrestricted access to the entire corporate subnet. Use dynamic VLAN assignment policies to place users in appropriate network segments with restricted ACLs.

Troubleshooting & Risk Mitigation

When managing 802.1X networks, IT teams must be prepared for common failure modes.

Certificate Expiry (EAP-TLS): If the CA certificate or the RADIUS server certificate expires, all authentication will fail simultaneously. Implement aggressive monitoring and alerting for certificate validity periods - set alerts at 90, 30, and 7 days before expiry.

Supplicant Misconfiguration (PEAP): Failing to validate the server certificate is a critical risk. Regularly audit endpoint configurations to ensure "Validate server certificate" is strictly enforced. Include this as a standard item in your security audit checklist.

RADIUS Timeout Issues: High latency between the wireless controller and the RADIUS server, or between the RADIUS server and Active Directory, can cause EAP timeouts and authentication failures. Ensure robust connectivity and consider local RADIUS proxies for distributed sites. This is particularly relevant for multi-site Transport and retail deployments.

Rogue Access Point Attacks: Conduct periodic wireless security assessments to detect rogue APs. Wireless intrusion detection systems (WIDS) integrated into your access point infrastructure can provide continuous monitoring.

ROI & Business Impact

The decision between EAP-TLS and PEAP carries significant business implications beyond the technical architecture.

EAP-TLS requires a higher initial CapEx for PKI and MDM solutions, alongside ongoing OpEx for certificate management. However, it provides the highest level of risk mitigation against credential-based breaches, which can result in devastating financial and reputational damage. For venues handling sensitive data or operating under strict regulatory compliance, the ROI of EAP-TLS is realised through avoided breach costs and streamlined compliance audits. A single credential-based breach in a retail or hospitality environment can cost millions in remediation, regulatory fines, and brand damage.

PEAP ofrece un tiempo de obtención de valor más rápido y menores costos de implementación. Es altamente efectivo para 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 mientras extraen información operativa valiosa de los datos de uso de la red - conectando la infraestructura de autenticación con resultados comerciales medibles, tales como el análisis del tiempo de permanencia, los patrones de afluencia y las tasas de visitantes recurrentes.

Definiciones clave

EAP (Extensible Authentication Protocol)

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 global; EAP-TLS y PEAP son métodos específicos que se ejecutan dentro de él. Los equipos de TI encuentran EAP al configurar políticas RADIUS y perfiles de suplicantes inalámbricos.

Suplicante

El dispositivo del cliente - ya sea laptop, 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 de manera correcta, en particular respecto 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 - por lo general un punto de acceso inalámbrico o un switch administrado - que bloquea todo el tráfico del suplicante hasta que el servidor RADIUS confirma que la autenticación fue exitosa.

El autenticador actúa como el 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 frente a 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 confiable.

PKI (Infraestructura de clave pública)

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

Una PKI robusta es un prerrequisito absoluto para implementar EAP-TLS de manera exitosa a gran escala. Sin 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 el departamento de TI para monitorear, administrar y asegurar 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 para las implementaciones de EAP-TLS a fin de 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 comunes.

Autenticación mutua

Un proceso de seguridad en el que ambas partes de un enlace de comunicación se autentican entre sí antes de que se intercambien datos - a diferencia de la autenticación de una sola vía 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 de cliente autorizado.

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

Un protocolo de autenticación basado en contraseñas que se utiliza comúnmente como el 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 esta razón, la validación del certificado del servidor en PEAP es no negociable.

OpenRoaming

Un estándar de federación 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 de EAP-TLS.

Ejemplos resueltos

Una cadena nacional de retail con 500 ubicaciones necesita proteger el acceso a la red corporativa para las tabletas y los escáneres de inventario portátiles de los gerentes de tienda. Actualmente utilizan un WPA2-PSK compartido en todos los sitios. Tienen implementado Microsoft Intune para la gestión de dispositivos.

Implementar EAP-TLS. Dado que la organización ya utiliza Microsoft Intune, el trabajo pesado de la implementación de certificados ya está resuelto. Configure Intune para enviar certificados de cliente únicos a todas las tabletas 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 de 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. Después de la autenticación, la asignación dinámica de VLAN coloca los dispositivos en el segmento de operaciones de tienda correspondiente.

Comentario del examinador: Este enfoque elimina el enorme riesgo de seguridad de un PSK compartido en 500 ubicaciones; anteriormente, un PSK comprometido en una sola tienda habría expuesto todos los sitios. 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, interrumpiendo 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 de MDM hace que la gestión del ciclo de vida de los certificados sea escalable. El riesgo clave a monitorear es el vencimiento 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 3,000 empleados internos que utilizan sus propios dispositivos personales (BYOD). Utilizan Google Workspace para la identidad corporativa, pero no gestionan los teléfonos ni las laptops personales del personal.

Implementar PEAP (específicamente PEAP-MSCHAPv2 o EAP-TTLS/PAP con 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 estándar 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 - instruyendo al personal a configurar sus dispositivos para que confíen en el certificado específico del servidor RADIUS y validen el nombre de dominio del servidor. Se mantiene un SSID de invitados independiente para los asistentes al evento, administrado a través de la plataforma Guest WiFi de Purple para análisis y control de acceso.

Comentario del examinador: EAP-TLS no es viable aquí porque la organización no tiene el control de MDM sobre los dispositivos personales para enviar certificados. PEAP proporciona un túnel cifrado y seguro para la autenticación utilizando las credenciales existentes, lo que lo hace altamente implementable para escenarios de BYOD al mismo tiempo que 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é configurado correctamente 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 WiFi seguro en todo el campus para 20,000 estudiantes. Los estudiantes traen sus propias laptops 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: Considere la carga operativa que representa la gestión de certificados en dispositivos personales no administrados dentro de un ecosistema de dispositivos tan heterogéneo.

Ver respuesta modelo

Desaconseje el uso de EAP-TLS para este caso de uso específico. Aunque EAP-TLS ofrece la seguridad más alta, implementar y administrar más de 20,000 certificados de cliente en dispositivos de estudiantes no administrados sin una solución de MDM creará una carga de soporte insuperable. 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 son administrados por la universidad, creando una arquitectura de seguridad por niveles.

Q2. Durante una auditoría de seguridad, un probador de penetración recopila con éxito credenciales de usuario de su red inalámbrica protegida con PEAP al configurar un punto de acceso no autorizado que transmite 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 sucede durante la fase de establecimiento del túnel TLS en PEAP y en lo que el dispositivo del cliente está - o no está - verificando.

Ver respuesta modelo

La causa raíz es una configuración incorrecta del suplicante. Los dispositivos de los clientes no están configurados para validar estrictamente el certificado digital del servidor RADIUS. Cuando el AP no autorizado presentó un certificado fraudulento, los dispositivos cliente confiaron ciegamente 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 consta de tres partes: (1) exigir una validación estricta del certificado del servidor mediante políticas de grupo o perfiles de MDM en todos los dispositivos cliente; (2) especificar el nombre de dominio exacto del servidor RADIUS esperado en la configuración del suplicante para evitar la aceptación de certificados de otros dominios; (3) implementar un Sistema de Detección de Intrusos Inalámbricos (WIDS) para detectar y alertar sobre puntos de acceso no autorizados.

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

Sugerencia: Evalúe el entorno regulatorio, el nivel de control del dispositivo y la sensibilidad de los datos a los que se accede.

Ver respuesta modelo

Implemente EAP-TLS sin dudarlo. El entorno de atención médica requiere un cumplimiento estricto y la máxima seguridad contra el robo de credenciales - una contraseña comprometida en una red de atención médica puede exponer los expedientes de los pacientes y provocar sanciones regulatorias significativas bajo GDPR y otros requisitos de protección de datos específicos del sector. Debido a que los dispositivos son propiedad de la empresa y están administrados estrictamente a través de Microsoft Intune, la implementación de certificados de cliente es operativamente viable y se puede automatizar por completo. EAP-TLS proporciona la autenticación mutua necesaria para garantizar que solo los dispositivos autorizados y administrados 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 la red verán un sistema de autenticación sin contraseñas basado en certificados que es intrínsecamente 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 radica en la autenticación mutua mediante certificados digitales. EAP-TLS requiere certificados digitales X.509 tanto en el servidor RADIUS como en el dispositivo del cliente, eliminando 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 de los clientes se autentican utilizando nombres de usuario y contraseñas tradicionales canalizados 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 del cliente valide el certificado del servidor RADIUS antes de transmitir las credenciales. En la práctica, los endpoints no gestionados y los suplicantes mal configurados a menudo no logran validar 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 basados en la nube o tablas rainbow.

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

La implementación de EAP-TLS en dispositivos personales no gestionados requiere un flujo de trabajo de registro automatizado o un asistente de registro en el portal cautivo 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 no cuentan con un mecanismo automatizado de registro de certificados suelen implementar EAP-TTLS con credenciales de directorio en la nube o WPA3-Enterprise con perfiles Passpoint para flotas de dispositivos BYOD.

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

Microsoft Entra ID (anteriormente Azure AD) no admite los protocolos de autenticación heredados basados en contraseñas como MSCHAPv2 porque no almacena hashes de contraseñas de manera 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, el cual vincula 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 inalámbrica también requiere un servidor RADIUS con capacidad 802.1X para validar las cadenas de certificados entrantes y verificar el estado de revocación mediante CRL u OCSP.

¿Cómo simplifica Cloud RADIUS la migración de PEAP a EAP-TLS?

Cloud RADIUS elimina la necesidad de implementar 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 los clientes frente a las CA emisoras y asignan VLAN basadas en roles y políticas de acceso 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 implementación para Intune, Jamf y Microsoft Entra ID

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

Leer la guía →

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

Podrá configurar la parte de validación de 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 servidor de certificado con el certificado RADIUS, implementará la CA raíz correcta, alineará las asignaciones de grupos de Microsoft Entra ID y programará las renovaciones de certificados antes de que interrumpan las conexiones de forma silenciosa.

Leer la guía →

Resolución de problemas de Android 802.1X y EAP-TLS: una lista de verificación de implementación para Intune y Microsoft Entra ID

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

Leer la guía →

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

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