EAP-TLS vs PEAP: seguridad, certificados y compatibilidad
Published
El consejo más común sobre eap tls vs peap es ordenado e incorrecto. Elija EAP-TLS porque es "más seguro" y deje PEAP para los equipos que no se han actualizado. Eso ignora la pregunta que determina si una WLAN de múltiples sitios sigue funcionando un lunes. ¿Puede emitir, renovar y revocar un certificado para cada dispositivo que se supone debe usarlo?
No aplicaría un solo método a toda la red. EAP-TLS pertenece a los dispositivos que puede inscribir y renovar. PEAP, casi siempre con EAP-MSCHAPv2 interno, pertenece a donde ya existe una contraseña de directorio y la inscripción de certificados no es práctica. El método más complejo no siempre es el que puede ejecutar. Un certificado vencido en la oficina administrativa de un hotel deja fuera al personal mientras sus cuentas siguen siendo válidas. Un perfil PEAP que omite la verificación del servidor puede entregar una contraseña de directorio a un punto de acceso no autorizado. Ambos fallos son operacionales. Asigne el método a la población en lugar de buscar un ganador para toda la red.
Tabla de contenido
- EAP-TLS y PEAP frente a frente
- Cómo autentica cada método y por dónde se filtran las contraseñas
- Requisitos de certificado antes del despliegue
- Ciclo de vida del certificado y esfuerzo de despliegue
- Revocación, velocidad de itinerancia y soporte de clientes
- Asigne cada población y demuestre la división
EAP-TLS y PEAP cara a cara
La diferencia práctica entre EAP-TLS y PEAP es la credencial que cada punto final puede admitir y el trabajo necesario para mantenerla funcional. Utilice EAP-TLS para dispositivos que pueda inscribir y renovar. Utilice PEAP donde los usuarios ya tengan contraseñas de directorio y la inscripción de certificados no sea viable. Ningún método es la respuesta correcta para todos los grupos de usuarios.
| Criterio | EAP-TLS | PEAP |
|---|---|---|
| ID de tipo EAP | 13 | 26 |
| Credencial de cliente | Certificado de cliente X.509 | Nombre de usuario y contraseña, generalmente EAP-MSCHAPv2 o EAP-GTC |
| Credencial de servidor | Certificado de servidor RADIUS | Certificado de servidor RADIUS en el túnel TLS externo |
| Autenticación mutua | Certificados de cliente y servidor | Certificado de servidor más autenticación interna de usuario o dispositivo |
| Contraseña en tránsito | Ninguna | Sí, dentro del túnel TLS |
| Lo que un AP apócrifo puede robar si el cliente omite las comprobaciones del servidor | Nada similar a una contraseña; la autenticación falla por seguridad | Contraseña de directorio |
| Revocación de un dispositivo | Revocar o expirar ese certificado | Deshabilitar la cuenta o restablecer una contraseña que podría reutilizarse |
| Trabajo de PKI | Certificados de servidor y cliente, renovación y recuperación | Certificado de servidor únicamente |
| Mejor opción inicial | Personal y dispositivos con privilegios gestionados por MDM | Endpoints no gestionados que no pueden inscribir certificados |
Un artículo técnico de Authentik de 2025 identifica EAP-TLS como EAP de tipo ID 13 y PEAP como de tipo ID 26. Estos ID identifican los métodos ante el RADIUS y el suplicante. No determinan qué personas o dispositivos deben usarlos.
Lo que realmente cambia en cada fila
La credencial del cliente establece el límite operativo. EAP-TLS presenta un certificado de cliente X.509. PEAP utiliza un nombre de usuario y contraseña, comúnmente a través de EAP-MSCHAPv2 o EAP-GTC. Eso convierte la inscripción y renovación de certificados en la carga de trabajo decisiva, en lugar de una clasificación teórica de métodos.
Las comprobaciones de confianza también difieren. EAP-TLS autentica tanto el certificado del cliente como el del servidor. PEAP valida el certificado del servidor RADIUS en el túnel TLS exterior, y luego autentica al usuario o dispositivo mediante un método interior.
La exposición de contraseñas depende de la configuración del suplicante. EAP-TLS no transmite contraseñas por la red. PEAP lleva una contraseña dentro de su túnel, por lo que un cliente que omita las comprobaciones del servidor puede revelar una contraseña de directorio a un punto de acceso no autorizado. Con EAP-TLS, si falta un certificado de cliente o este no es de confianza, la autenticación falla.
La desincorporación también depende de lo que se esté gestionando. Un certificado de dispositivo se puede revocar o dejar expirar sin restablecer la contraseña de directorio de una persona. Deshabilitar una cuenta o cambiar una contraseña reutilizada puede afectar a otros inicios de sesión vinculados a esa credencial.
El balance operacional es claro: EAP-TLS requiere certificados de cliente, renovación y una ruta de recuperación, mientras que PEAP requiere el certificado del servidor y una configuración cuidadosa del suplicante. Asigne EAP-TLS al personal inscrito y a los dispositivos con privilegios; mantenga PEAP para los puntos finales no administrados que no pueden unirse a la gestión de certificados. Los equipos que ejecutan infraestructura serverless para plataformas de membresía pueden tener poblaciones distintas de miembros, personal y dispositivos, pero el modelo de alojamiento no elige el método de autenticación. La credencial tiene que coincidir con a quién puede administrar.
Cómo autentica cada método y dónde se filtran las contraseñas
EAP-TLS no es automáticamente la respuesta correcta para todos los usuarios. La decisión clave es si su equipo puede emitir, renovar y revocar certificados de manera confiable para cada grupo. PEAP mantiene la incorporación más simple para usuarios no gestionados, pero su contraseña depende de la configuración correcta del suplicante.
Ambos métodos utilizan 802.1X. El suplicante es el dispositivo que solicita acceso, el autenticador es el punto de acceso o switch que retransmite esa solicitud, y el servidor RADIUS la acepta o la rechaza. Comparten el entorno EAP, no una credencial.
El índice de especificaciones IETF EAP describe EAP-TLS, definido en IETF RFC 5216, como la autenticación de cliente y servidor basada en certificados, con autenticación mutua, negociación de suites de cifrado protegidas por integridad y derivación de claves. La especificación se publicó en marzo de 2008. En la práctica, EAP-TLS requiere un certificado de cliente emitido a través de PKI, junto con el certificado del servidor RADIUS.
Dos secuencias, un marco de trabajo
EAP-TLS autentica ambos puntos finales en un solo intercambio TLS:
- El suplicante inicia EAP con el autenticador, el cual retransmite la solicitud a RADIUS.
- Los certificados de servidor y cliente se verifican durante el intercambio TLS.
- El intercambio protege la negociación de suites de cifrado y deriva claves, sin enviar una contraseña que pueda ser objeto de phishing, retransmisión o fuerza bruta.
- Un certificado de cliente faltante o no confiable significa que el dispositivo es rechazado. No puede recurrir a ingresar una contraseña.
PEAP crea un túnel TLS externo que autentica al servidor y luego ejecuta un método interno, comúnmente EAP-MSCHAPv2 o EAP-GTC. Debido a que el método interno puede usar un nombre de usuario y contraseña, los puntos finales generalmente no necesitan certificados de cliente. El índice de especificaciones EAP de la IETF también describe el marco de estándares que utilizan estos métodos.
Los usuarios no ven el túnel externo de PEAP. La identidad interna, que suele ser un nombre de usuario y contraseña o un token, se envía únicamente después de que se establece TLS. Esto hace que PEAP sea familiar para los suplicantes basados en directorio, pero deja una contraseña expuesta si el cliente no verifica el túnel correctamente.
El PEAP con EAP-TLS interior es un caso especial más complejo, que combina un método basado en certificados con un túnel TLS exterior. Un despliegue etiquetado como "PEAP" por lo general significa PEAP-MSCHAPv2.
Dónde decide el resultado el suplicante
Un informe de métodos EAP de seguridad inalámbrica empresarial explica la distinción: EAP-TLS utiliza autenticación mutua X.509. RADIUS valida el certificado del cliente y el cliente valida el certificado del servidor. No hay ninguna contraseña disponible para phishing, retransmisión o fuerza bruta. El informe también señala que el NIST requiere que tanto la estación inalámbrica como el servidor de autenticación cuenten con certificados válidos.
Con PEAP, el cliente debe validar la cadena de certificados RADIUS y el nombre de servidor esperado. Si falta cualquiera de las dos comprobaciones, un punto de acceso no autorizado puede solicitar una contraseña de directorio. Un perfil de suplicante configurado en "no validar" no protege la contraseña.
Regla práctica: Fije el nombre del servidor RADIUS y la CA emisora en el perfil de WiFi. Sin esas comprobaciones, PEAP puede ofrecer una contraseña a un servidor no autorizado.
Las respuestas MS-CHAPv2 capturadas se pueden descifrar fuera de línea después de que un atacante las obtiene a través de un túnel no autorizado. Validar el túnel es el control; el método interno no rescata un perfil que acepta un servidor no confiable. El mismo riesgo de contraseña se extiende más allá del WiFi. Los informes de credenciales comprometidas en pequeñas empresas australianas destacan por qué una contraseña de directorio reutilizada sigue siendo valiosa para un atacante.
Asigne EAP-TLS a dispositivos y usuarios gestionados cuyo ciclo de vida de certificados pueda operar. Utilice PEAP donde los usuarios o dispositivos no puedan recibir y renovar certificados de forma confiable, pero aplique la validación del nombre del servidor y de la CA a través del perfil del suplicante. La compensación operativa es directa: los certificados requieren trabajo de inscripción y recuperación, mientras que las contraseñas lo obligan a gestionar la reutilización y los cambios de cuenta. El mejor método depende de a quién pueda gestionar, no de declarar un ganador único para cada SSID.
Requisitos de certificados antes del despliegue
Confirme estos seis elementos en un laboratorio antes de la primera asociación en producción. La falta de una cadena o un nombre incorrecto se verá como "el WiFi no funciona", no como un error de certificado.
- Certificado de servidor RADIUS. Emítalo desde su CA privada. Coloque el nombre que fija el perfil del suplicante en el asunto o SAN. Configure el uso de autenticación de servidor y sirva la cadena intermedia completa con el certificado. Una CA pública que firme cualquier nombre coincidente es el modelo de confianza incorrecto para un nombre RADIUS interno.
- Certificado de cliente. Uno por dispositivo o usuario, con uso de autenticación de cliente. Coloque una identidad única en el SAN, como un nombre principal de usuario o un número de serie de dispositivo. Guarde la clave privada en el TPM o enclave seguro cuando la plataforma lo admita.
- Ancla de confianza. Instale la CA raíz o emisora interna a través del perfil MDM. No apunte los dispositivos a una raíz pública esperando que la verificación de nombre sea suficiente.
- Validez y renovación. Establezca un periodo de vigencia para el certificado de servidor y los certificados de cliente. Genere una ventana de superposición para que el reemplazo esté instalado antes de que expire el anterior.
- Revocación. Proporcione al servidor RADIUS un punto de enlace CRL u OCSP al que pueda acceder. Decida por escrito si la autenticación falla o continúa cuando ese punto de enlace esté fuera de línea. Pruebe el caso fuera de línea. No lo descubra durante un parpadeo de la red WAN.
- Canal de inscripción. Entregue certificados con SCEP o un PKCS#12 a través del MDM. Compruébelo en un dispositivo, incluida la renovación, antes de dirigirse a un grupo.
Supongamos que una clínica utiliza Okta para la identidad del personal e Intune para las laptops. El nombre de RADIUS en el perfil debe coincidir con el certificado, y el grupo de Okta que debe asignarse a la VLAN clínica debe ser el mismo grupo que el MDM utiliza para la inscripción. Nuestras notas sobre la autenticación WiFi con Okta explican esa transferencia de identidad sin convertir el laboratorio en un SSID con contraseña.
Conecte una laptop de prueba, revoque su certificado y confirme que la siguiente asociación falle antes de aplicar los cambios en un entorno de producción real.
Ciclo de vida del certificado y esfuerzo de despliegue
La seguridad de EAP-TLS se convierte en una interrupción del servicio cuando un certificado expira o cuando un cliente no puede acceder a la información de revocación, aunque la cuenta de usuario siga siendo totalmente válida. Esa es la cuestión que vale la pena plantearse. Dirigirse con la premisa de que "los certificados son más difíciles" no es un diseño.
La Publicación Especial 800-120 de NIST expone el mismo riesgo. EAP-TLS requiere una confiable emisión, distribución, renovación, gestión de la cadena de confianza y verificación de revocación. Un dispositivo con un certificado vencido, o un servicio de revocación inaccesible, puede perder el acceso a la red incluso si la identidad del usuario sigue siendo válida. PEAP generalmente autentica el servidor en la fase TLS externa y un nombre de usuario y contraseña a través de un método interno como MS-CHAPv2, por lo que omite ese ciclo de vida del cliente. Un primer día más fácil traslada la carga hacia el restablecimiento de contraseñas y perfiles incorrectos.
Evite que los certificados se conviertan en la causa de una caída del servicio
La solución a nivel de diseño es la automatización, no un manual de procedimientos más extenso.
- Inscriba a través de MDM. Despliegue el perfil, el ancla de confianza y el certificado juntos. La configuración manual de WiFi es la razón por la que se desmarcan las verificaciones de nombre de servidor.
- Traslape la renovación. Instale el nuevo certificado antes de que expire el anterior. Un fin de semana donde todas las laptops fallan al mismo tiempo es consecuencia de un traslape demasiado corto.
- Pruebe la revocación fuera de línea. Sepa si RADIUS falla en modo cerrado o abierto cuando no se puede obtener la CRL o el OCSP.
- Mantenga una ruta de recuperación. Un punto final con fallas necesita una forma de regresar que no sea "pedir prestada la contraseña PEAP de alguien." Un puerto de soporte por cable o un SSID de recuperación estrictamente delimitado es mejor que una secreta compartida escrita en un pizarrón.
Purple Access toma certificados EAP-TLS de Microsoft Intune, Jamf Pro, JumpCloud, Kandji, Hexnode, Iru y Addigy, entregados a través de SCEP, con una configuración que toma de cinco a diez minutos una sola vez para la organización en lugar de por dispositivo. La red segura no requiere contraseñas y se basa en certificados, y un dispositivo que no cumpla con la postura de seguridad es rechazado en la autenticación mediante el Acceso Condicional. Esa es una incorporación sujeta a cumplimiento normativo, no un segundo aviso de contraseña.
PEAP sigue siendo la opción directa cuando la PKI no está lo suficientemente desarrollada, cuando los contratistas no se pueden incluir en el MDM o cuando los entornos BYOD mixtos no aceptan un certificado. El sector salud, la educación, la hospitalidad y otras flotas de múltiples sitios a menudo enfrentan los tres desafíos al mismo tiempo. Utilice EAP-TLS para dispositivos corporativos gestionados, del personal y de alto riesgo. Mantenga una alternativa estrictamente controlada para puntos finales no gestionados o temporales. La identidad a escala del recinto es la decisión clave, no el eslogan de que TLS le ganó a las contraseñas.
Si RADIUS es la pieza frágil, un backend alojado elimina el fallo de tener "un solo servidor en el armario de la sede principal". Nuestra reseña sobre RADIUS-as-a-Service es el lugar ideal para verificar la accesibilidad y la redundancia antes de culpar al método EAP.
El breve recorrido a continuación muestra el registro de certificados junto con un método interior basado en contraseña, que es la diferencia que observa el equipo de soporte técnico cuando la renovación se retrasa.
Revocación, velocidad de roaming y soporte a clientes
El soporte y la velocidad son problemas de consulta. Los suplicantes actuales de Windows, macOS, iOS, Android y ChromeOS admiten ambos métodos. El modo de fallo es lo que varía.
EAP-TLS falla cuando el perfil, la CA emisora o las fechas de validez son incorrectas. PEAP falla cuando el método interno, el formato de identidad o la verificación del nombre del servidor no coinciden con la política de RADIUS. Ninguno de estos fallos significa que el punto de acceso "no admite enterprise".
La revocación tiene la misma división. Deshabilitar el certificado de un dispositivo corta la conexión de esa laptop sin afectar los demás inicios de sesión de la persona. Restablecer una contraseña de directorio afecta a todos los clientes no gestionados que todavía la utilicen. El bloqueo inmediato y específico por dispositivo es la ventaja de EAP-TLS. Los fallos críticos por certificados expirados son el costo.
Intercambios de comunicación, no nombres de marcas
Un artículo de ACM sobre la latencia de autenticación inalámbrica señala que el rendimiento depende más del recuento de intercambio de paquetes, la itinerancia, la validación de certificados y la latencia del backend que del nombre del método. EAP-TLS estándar completa la autenticación de certificados de cliente y servidor en su intercambio TLS. PEAP establece un túnel TLS y luego ejecuta la autenticación interna, añadiendo una fase distinta. El material técnico de Cisco mencionado en ese artículo señala que PEAP con EAP-TLS interno implica dos intercambios de paquetes TLS y puede ser lento cuando ocurre una reautenticación completa durante la itinerancia.
Mida estos aspectos por separado. No determine un ganador a partir de un solo tiempo promedio de inicio de sesión.
- Tiempo de asociación a IP en el percentil 95
- Autenticación completa frente a latencia de reanudación de itinerancia
- Tiempo de ida y vuelta de RADIUS
- Tasa de fallos de autenticación
- Fallos de renovación de certificados
La reanudación de sesión, el almacenamiento en caché de PMK o 802.11r, la accesibilidad de RADIUS local y una cadena de certificados corta mejoran esos números más que cambiar una suite de cifrado. PEAP puede parecer sencillo el primer día y aún así generar demoras debido a repetidos intercambios de contraseñas y correcciones de usuario. EAP-TLS puede verse instantáneo tras la inscripción y luego fallar drásticamente por un certificado vencido.
| Síntoma | Método más probable | Causa habitual | Solución práctica |
|---|---|---|---|
| Repite la solicitud de contraseña cerca de un AP desconocido | PEAP | El suplicante no valida el nombre del servidor o la cadena | Despliegue un perfil que fije el nombre RADIUS y la CA |
| Se pierde el acceso en una laptop tras un cambio de rol | EAP-TLS | Certificado revocado o dispositivo eliminado del MDM | Confirme la revocación y reinscriba solo ese dispositivo |
| Todo el equipo bloqueado un lunes | EAP-TLS | Los certificados expiraron juntos o el traslape de renovación fue muy corto | Programe la renovación antes del vencimiento y mantenga una ruta de recuperación |
| La iteración de roaming se siente lenta solo en la reautenticación completa | PEAP con EAP-TLS interno | Dos handshakes TLS | Priorice la reanudación, el almacenamiento en caché PMK o 802.11r; evite el EAP-TLS interno a menos que sea necesario |
| Rechazos aleatorios solo en un sitio | Cualquiera de los dos | Tiempo de ida y vuelta de RADIUS o búsqueda de cadena, no el nombre de EAP | Mida el RTT y el percentil 95 de asociación a IP antes de cambiar de método |
Una iteración de roaming lenta en un sitio suele deberse a la distancia con el servidor RADIUS o a la obtención de la cadena de certificados, no es una prueba de que haya elegido el tipo de EAP incorrecto.
Asigne cada grupo de usuarios y demuestre la separación
Un mismo edificio puede albergar laptops del personal, un invitado de conferencia, la Mac de un contratista y una caja registradora. No deberían compartir el mismo tipo de credencial. Mapee cada grupo, haga una prueba piloto en un sitio junto a la red que ya opera y evalúe los tickets más el registro de autenticación antes de replicar el diseño.
| Población | Utilizar | No utilizar | Por qué |
|---|---|---|---|
| Personal gestionado por MDM y usuarios con privilegios | EAP-TLS en un SSID WPA-Enterprise | PSK compartida o PEAP | Identidad por certificado, VLAN por grupo, el acceso finaliza cuando la cuenta se deshabilita |
| Invitados y visitantes de corta estancia | Captive Portal o Passpoint en una VLAN de invitados | Inscripción PEAP o EAP-TLS en recepción | Sin ciclo de vida de certificados y sin contraseña de directorio que pueda ser objeto de phishing|
| Laptops no gestionadas y contratistas | PEAP-MSCHAPv2 solo con validación forzada del servidor | EAP-TLS si no puede inscribirlos o renovarlos | Las contraseñas ya existen, pero el perfil debe verificar el certificado RADIUS |
| Impresoras, TVs, cajas registradoras, CCTV y sensores | PSK por dispositivo con su propia VLAN | EAP-TLS o una contraseña PEAP compartida | Estos dispositivos por lo general no pueden almacenar certificados, y una clave compartida es difícil de rotar |
| Lugar de uso mixto en un solo edificio | División por identidad a través de VLANs independientes | Un SSID y un método para todos | El personal, los invitados y los dispositivos fallan de diferentes maneras y no deben compartir un tipo de credencial |
Quiénes continúan con contraseñas y quiénes no deben hacerlo
El personal gestionado y los usuarios con privilegios obtienen EAP-TLS en un SSID WPA-Enterprise. El personal de limpieza, recepción y operaciones puede autenticarse con certificados desde un MDM mediante SCEP, asignarse a una VLAN por grupo de directorio y perder el acceso cuando la cuenta se deshabilite. Un PSK compartido o una contraseña PEAP recrea exactamente lo que intentaba retirar.
Los invitados y visitantes se mantienen en un Captive Portal o Passpoint, en una VLAN de invitados. No inscriba certificados en la recepción ni los configure con PEAP. No hay un ciclo de vida que vaya a gestionar y hay una contraseña de directorio que no quiere que sufra phishing. Un perfil Passpoint puede volver a conectarse en la siguiente visita sin generar un nuevo ticket.
Las laptops no gestionadas y los contratistas pueden permanecer en PEAP-MSCHAPv2, y únicamente si el perfil fuerza la validación del servidor. Si no puede inscribirlos o renovarlos, EAP-TLS los dejará sin conexión. Si no puede forzar la comprobación del servidor, el riesgo de la contraseña supera la conveniencia y no deberían estar en absoluto en el SSID del personal.
Las impresoras, TVs, cajas registradoras, EPOS, CCTV, sensores y controladores de puertas obtienen una PSK por dispositivo y su propia VLAN. Por lo general, no pueden almacenar certificados. Una contraseña PEAP compartida vuelve a generar el problema de las claves compartidas. El requisito PCI DSS v4.0.1 Req 2.3.2 exige que las claves inalámbricas cambien cuando cualquiera que las conozca se retire, lo que resulta poco práctico con una clave compartida. xPSK es la solución adecuada para esos dispositivos. Las TVs de habitaciones, los termostatos y las cajas registradoras pertenecen a VLAN vinculadas a claves que los invitados nunca ven.
Pruébelo en un sitio
Aplique el nuevo diseño en los puntos de acceso que el sitio ya tiene, junto a la red actual. Evalúelo con base en tickets y evidencias de auditoría, no en una sesión de prueba.
Requiera un registro de autenticación que recopile cada aceptación y rechazo con identidad, dispositivo, estado de inscripción en MDM, método, punto de acceso, SSID, sitio, VLAN, rol, motivo y hora. Ese mismo registro es el conjunto de evidencias para los controles de acceso y registro de ISO 27001 y para los requisitos 8 y 10 de PCI-DSS. Sin MDM, asegure primero los perfiles PEAP y programe los certificados únicamente para la población gestionada.
Podemos ejecutar esta división como tres redes por propiedad. Los invitados usan el Captive Portal, incluyendo una verificación de habitación en el PMS donde la propiedad disponga de uno. El personal usa EAP-TLS o Passpoint. Los dispositivos IoT usan claves por dispositivo. RADIUS en la nube envía cada dispositivo a la red y VLAN correctas por identidad, y rechaza a un usuario saliente cuya cuenta esté deshabilitada. La ruta de migración para dejar de usar una contraseña compartida de personal es la misma que se describe en nuestra guía para migrar el WiFi del personal multisitio a 802.1X.
Comenzaría la prueba piloto con el SSID del personal gestionado y las claves por dispositivo para las cajas registradoras, y dejaría a los contratistas en un perfil PEAP validado hasta que el registro sea efectivo. Un solo método para todos se ve más limpio en un diagrama, pero falla de tres maneras diferentes en la práctica.
Purple Access ejecuta WiFi para el personal basado en certificados y claves por dispositivo para los elementos en los puntos de acceso que ya posee, por lo que eap tls vs peap se convierte en una elección de población en lugar de una apuesta para toda la infraestructura. Puede probar conexiones abiertas, seguras y xPSK en un solo sitio, y luego evaluar los tickets y el registro de autenticación antes de un despliegue más amplio. Visite Purple Access para mapear sus redes de personal, invitados y dispositivos.
