Estoy buscando terminar una infraestructura relativamente segura usando solo herramientas OSS. En el lado de Linux, tengo el IPH RedHat muy capaz que proporciona Kerberos y administra los registros de host y servicio. En el lado del cliente, hay una combinación de dispositivos, pero para fines de discusión, limitémoslo a Linux, Mac OS e iOS.
Los dos servicios que más me preocupan son VPN y correo electrónico, ya que creo que estos crean la mayor exposición en uso por los guerreros del camino. Y como describiré a continuación, hay un vector escalofriante para que las contraseñas se enganchen a los incautos.
La VPN parece lo más fácil, no es irrazonable para el usuario generar una OTP al iniciar sesión en la VPN y RADIUS ha estado disponible como servicio FreeIPA desde hace algún tiempo. Las VPN suelen ser compatibles con RADIUS, por lo que deberían ser razonables.
Fuera de eso, GSSAPI + OTP resuelve todos los problemas que se me ocurren. Los usuarios pueden generar un TGT una vez al día por la mañana usando 2FA y todos los servicios lo usarían idealmente para los tickets de servicio. Al hacerlo, el secreto compartido de OTP puede usar una ventana de intervalo estándar y todo es Hunky Dory. (En un mundo que lo tiene todo, un IPSEC SA está utilizando dinámicamente la rotación de los tickets de Kerberos para la autenticación en lugar de RADIUS y no tiene que solicitar una VPN, solo está allí cuando la necesita ...)
Lamentablemente, GSSAPI tiene poco soporte en los clientes que usan las personas, como iOS Mail. Por su parte, dos de las cuatro opciones de autenticación de correo de iOS incluyen algún tipo de MD5 y el tercero de cuatro es una contraseña de texto simple. Sería algo patético en Apple Mail si no fuera tan común en todos los clientes.
Los certificados de cliente TLS son otra opción razonable, pero igual de mal soportada. Peor aún, no es seguro confiar en ellos mismos, ya que cualquier persona que posea un dispositivo certificado podría usar el certificado. Una OTP puede ayudar cuando se combina con TLS CC, pero no es práctico usar una OTP con un intervalo razonablemente corto para un servicio como IMAP, ya que se está revisando a lo largo del día y no creo que sea razonable pedir una OTP más de una vez.
Gmail resuelve esto con contraseñas específicas de la aplicación y FreeIPA ha pensado en esto en esta solicitud de estudiante para tesis . Pero, por desgracia, no hay un movimiento real en eso durante años, incluido el período previo a eso en aquí .
Entonces, a menos que me esté faltando algo, IMAP y SMTP comienzan a recurrir a la autenticación de contraseña simple, lo cual es muy peligroso. Los puntos de acceso WiFi públicos a menudo permiten que una máquina se conecte al SSID sin autenticación, pero todo el tráfico del puerto se enruta a los vectores MIM que probablemente recopilan contraseñas (hola Starbucks). Sin 2FA y la misma contraseña entre la VPN y el correo electrónico, toda su red ahora se ve comprometida con un clic involuntario para aceptar un certificado SSL desconocido en aplicaciones desconocidas como Calendario.
Lo que creo que sucede para evitar estos problemas es que las grandes empresas instalan entornos limitados de aplicaciones en dispositivos con interfaces virtuales que se ejecutan a través de redes privadas virtuales a pedido. De esa manera, simplemente no hay forma de que un usuario pueda cometer un error simple que comprometa su autenticación y las operaciones. La gente no tiene que ser "el malo" al limitar las aplicaciones que las personas pueden o no pueden ejecutar en su BYOD. (O al menos, si no es así como funcionan estas cosas, deberían). Simplemente no tengo esa cantidad de dinero para este proyecto.
Sé que este es un problema complejo. Mi pregunta es cómo resolver todo lo posible. Espero haber expuesto dónde se encuentran los problemas, estoy agradecido por los comentarios sobre cómo podría estar viendo el problema incorrecto o las soluciones que me faltan que podrían ayudar.