Cuando un cliente pregunta si puede añadir TOTP al WiFi corporativo para cumplir con su política de MFA, la respuesta técnicamente correcta es “sí, pero no deberías”. Este artículo explica por qué TOTP es prácticamente inutilizable en 802.1X, cómo comparar los métodos EAP más comunes y cuál es la ruta recomendada hacia una autenticación WiFi robusta.
El problema de TOTP en redes inalámbricas#
La intuición detrás de querer TOTP en WiFi es razonable: si lo usas en VPN y en aplicaciones web, ¿por qué no en la red inalámbrica? El problema está en cómo funciona el supplicant WiFi.
En cualquier dispositivo —Windows, iOS, Android— el cliente WiFi guarda las credenciales para reconectar automáticamente. Cada vez que el dispositivo pierde señal, cambia de punto de acceso o sale de suspensión, el supplicant intenta la autenticación sin intervención del usuario. Ese comportamiento es el que hace que el WiFi empresarial sea usable.
Ahora añade un OTP con validez de 30 segundos a esa ecuación:
- El usuario introduce su usuario, contraseña y el código TOTP del momento.
- La autenticación funciona.
- El dispositivo se desconecta (ascensor, parking, suspensión).
- El supplicant intenta reconectar automáticamente con las mismas credenciales.
- El código TOTP ya ha caducado. La autenticación falla.
- El usuario ve que no tiene WiFi sin entender por qué.
El helpdesk empieza a recibir llamadas. Los usuarios aprenden a desactivar el WiFi y usar datos móviles. La política de seguridad ha conseguido exactamente lo contrario de lo que pretendía.
El método que haría esto posible técnicamente es PEAP/GTC (Generic Token Card), que transmite la contraseña en texto plano dentro del túnel TLS externo. A diferencia de MSCHAPv2, GTC no aplica hash a las credenciales, por lo que el servidor RADIUS puede verificar un OTP en tiempo real. Pero sin caché de credenciales, cada reconexión requiere intervención manual del usuario. En la práctica, es inaceptable para cualquier entorno de producción.
Comparativa de métodos EAP#
Antes de elegir un método EAP hay que entender qué hace cada uno con las credenciales y qué implica para la infraestructura:
| Método | Autenticación interna | Requiere cert. cliente | Compatible con TOTP | Experiencia de usuario |
|---|---|---|---|---|
| PEAP/MSCHAPv2 | NTLM hash | No | No | Buena |
| PEAP/GTC | Texto plano (en túnel TLS) | No | Teóricamente sí | Mala (sin caché) |
| EAP-TLS | Certificado X.509 | Sí | N/A | Excelente |
PEAP/MSCHAPv2 es el punto de partida habitual. El dispositivo abre un túnel TLS con el servidor RADIUS usando el certificado del servidor, y dentro negocia MSCHAPv2 con el hash NTLMv2 de la contraseña. No requiere certificado en el cliente, solo un par usuario/contraseña. La reconexión automática funciona perfectamente porque las credenciales son estáticas.
La debilidad de MSCHAPv2 es que el hash NTLMv2 es vulnerable a ataques offline si alguien captura el intercambio y el diccionario de contraseñas es débil. Además, si el dispositivo no valida correctamente el certificado del servidor RADIUS, es posible un ataque man-in-the-middle con un RADIUS falso.
EAP-TLS elimina estas debilidades por diseño: no hay contraseña que capturar ni hash que atacar.
EAP-TLS: el certificado como factor de autenticación#
En EAP-TLS, ambos lados presentan un certificado: el servidor RADIUS demuestra al cliente que es legítimo, y el dispositivo demuestra al RADIUS que está autorizado. La autenticación es mutua por construcción.
El certificado de dispositivo cumple la función de “algo que tienes” de forma nativa. No necesitas añadir un segundo factor porque el certificado ya es ese segundo factor: está vinculado a un dispositivo concreto, fue emitido por tu CA interna, y solo puede usarse desde ese dispositivo (la clave privada nunca sale del TPM o del almacén de certificados del sistema operativo).
Ventajas prácticas:
- No hay credenciales que phishear. Un atacante no puede engañar a un usuario para que “introduzca su contraseña WiFi” porque no existe tal contraseña.
- No hay credenciales que rotar. Cuando un empleado se va, revocas su certificado. El dispositivo queda excluido de la red en el siguiente intento de autenticación, sin necesidad de cambiar contraseñas de grupo ni tocar la GPO de WiFi.
- La reconexión automática funciona perfectamente. El certificado no caduca en 30 segundos.
El coste es la infraestructura: necesitas una CA interna que emita certificados a los dispositivos. En entornos con Active Directory, esto significa ADCS (Active Directory Certificate Services), y el proceso de distribución se automatiza con autoenrollment via GPO.
Implementación básica con FreeRADIUS + ADCS#
Certificados en ADCS#
El primer paso es crear una plantilla de certificado en ADCS para autenticación de equipos. La plantilla debe tener:
- Propósito: Autenticación de cliente (OID 1.3.6.1.5.5.7.3.2)
- Nombre del sujeto: Construido desde Active Directory (nombre DNS del equipo)
- Permisos de inscripción: Equipos del dominio → Leer + Inscribir automáticamente
Con esta plantilla publicada, el autoenrollment vía GPO distribuye los certificados sin intervención del usuario. Los equipos del dominio solicitan y renuevan sus propios certificados automáticamente.
Configuración de FreeRADIUS#
El módulo EAP de FreeRADIUS necesita apuntar a los ficheros de certificado del servidor y activar la verificación del cliente:
eap {
default_eap_type = tls
tls {
private_key_file = /etc/ssl/private/radius.key
certificate_file = /etc/ssl/certs/radius.pem
CA_file = /etc/ssl/certs/ca.pem
dh_file = /etc/ssl/certs/dh.pem
verify {
client = yes
}
}
}El parámetro CA_file debe apuntar a la cadena completa de tu CA interna —raíz e intermedias si las hay—. FreeRADIUS verificará que el certificado presentado por el cliente esté firmado por esa CA y no haya sido revocado. Para la revocación en tiempo real puedes configurar CRL o OCSP en el mismo bloque tls.
El certificado del servidor (radius.pem) debe estar firmado por la misma CA o una CA de confianza que los clientes conozcan. Si usas ADCS, lo más limpio es emitir también el certificado del servidor RADIUS desde allí.
GPO para distribución automática#
Dos objetos de directiva de grupo cubren el despliegue completo:
GPO de autoenrollment (Computer Configuration → Windows Settings → Security Settings → Public Key Policies):
- Activar el autoenrollment de certificados de equipo
- Renovar automáticamente los certificados caducados
- Actualizar los certificados que usan plantillas de certificado
GPO del perfil WiFi (Computer Configuration → Windows Settings → Security Settings → Wireless Network Policies):
- SSID corporativo
- Tipo de seguridad: WPA2-Enterprise
- Método EAP: Microsoft: Smart Card u otro certificado
- CA de validación: tu CA interna (marcada como confianza)
- Sin prompt al usuario (silent authentication)
Con ambas GPO aplicadas, un equipo que se une al dominio recibe su certificado y su perfil WiFi automáticamente. El usuario no configura nada: la red aparece y conecta sola.
Ruta de migración recomendada#
No todos los entornos pueden pasar a EAP-TLS de un día para otro. La infraestructura PKI requiere planificación: definir la jerarquía de CA, decidir si la raíz es online u offline, establecer el ciclo de vida de los certificados y preparar el proceso de revocación.
Una ruta pragmática:
Fase 1 — Hoy: Desplegar WPA2-Enterprise con PEAP/MSCHAPv2 si aún no lo tienes. Es infinitamente mejor que WPA2-PSK (contraseña compartida). Asegúrate de que los clientes validan el certificado del servidor RADIUS para evitar ataques MitM.
Fase 2 — Medio plazo: Montar ADCS si no existe o auditar la CA existente. Publicar la plantilla de autoenrollment para equipos. Hacer una prueba piloto con EAP-TLS en una VLAN separada.
Fase 3 — Objetivo: Migrar el SSID corporativo a EAP-TLS. Mantener temporalmente un SSID secundario con PEAP/MSCHAPv2 para dispositivos de invitados o equipos no gestionados.
Lo que nunca deberías hacer: activar PEAP/GTC con TOTP en producción. El impacto en la experiencia de usuario garantiza que la política no se cumplirá —los usuarios buscarán alternativas— y el helpdesk pagará las consecuencias.
Conclusión#
TOTP es una herramienta excelente para autenticación web y VPN, donde el usuario inicia la sesión de forma explícita. En WiFi empresarial, el modelo de reconexión automática lo hace incompatible con la realidad operativa.
La respuesta correcta al “quiero MFA en el WiFi” no es añadir TOTP: es migrar a EAP-TLS, donde el certificado de dispositivo ya incorpora el segundo factor de forma transparente para el usuario y robusta para el equipo de seguridad.