Uso continuado de Kerberos

Kerberos tiene múltiples implementaciones interoperables y maduras en las principales plataformas con comunidades de usuarios activas y en desarrollo continuo (MIT Kerberos, Heimdal, Microsoft, Java), y mediante capas de abstracción estándar como GSSAPI y SASL, es fácil de usar Kerberos directa o indirectamente para asegurar muchas aplicaciones y protocolos estándar, incluyendo:

• SSH (OpenSSH, ssh.com, VanDyke VShell / SecureCRT)
• IMAP y SMTP (Cyrus, sendmail, postfix, Thunderbird, OS X Mail, Alpine)
• Subversion
• CIFS / SMB (Samba, Windows, Netapp)
• Base de datos (SQL Server, Postgres, jTDS, FreeTDS)
• HTTP (Apache, nginx, todos los principales navegadores web, curl, bibliotecas HTTP de clientes en Perl / Python / Java / C / ...)
• DNS (autenticación para actualización dinámica, implementada por Windows y BIND)
• NFS

Todos estos protocolos e implementaciones tienen soporte Kerberos incorporado listo para ser utilizado, solo si proporciona la infraestructura y sabe cómo hacerlo. Esto no es sólo teórico; donde trabajo, estoy a cargo de la infraestructura de Kerberos para mi empresa, y tenemos todas estas aplicaciones y más. Todos ellos interoperan sin problemas tanto en Windows como en Unix; nuestros usuarios inician sesión en su escritorio de Windows o Unix, escriben su contraseña una vez, y nunca vuelven a escribirla al acceder a todos estos servicios, directamente y después de usar SSH para iniciar sesión en otros hosts (donde sus credenciales de Kerberos se reenvían y se usan automáticamente). La delegación de credenciales en diferentes versiones está disponible para permitir que los servidores autorizados accedan a otros servicios en nombre de un usuario a través del uso controlado de la identidad del usuario. No tenemos la pesadilla de administrar claves de host SSH en varias plataformas y clientes (archivos de hosts conocidos de OpenSSH, claves de registro PuTTY, etc.); Kerberos autentica nuestros servidores SSH y sus clientes.

Si tiene necesidades limitadas, entonces puede salirse con otros sistemas. Si todo lo que desea es, por ejemplo, un inicio de sesión único para las aplicaciones web desde navegadores web completos, entonces puede usar cualquiera de varios esquemas, pero si también desea acceder a esa aplicación web mediante programación desde un programa simple que no tiene El motor de Javascript y un usuario para escribir una contraseña, estás bastante atascado. Con Kerberos, las mismas credenciales funcionan de la misma manera en ambos escenarios.

Nada de esto quiere decir que Kerberos no tiene sus debilidades, o cosas que deberían mejorarse. El uso de Kerberos en HTTP ("Negociar con HTTP") es un truco con problemas; En realidad, lo que necesitamos es una implementación generalizada de los conjuntos de cifrado Kerberos en TLS. El uso de Kerberos para asegurar el tráfico de datos carece de secreto hacia adelante, lo que es cada vez más importante en estos días; necesitamos un mecanismo GSSAPI que combine la autenticación Kerberos con un intercambio Diffie-Hellman, como lo hacen los intercambios de claves GSSAPI SSH; una vez que existe, puede funcionar de manera transparente con cualquier cliente SASL correctamente escrito que use una capa de seguridad (como lo hacen varios de los casos mencionados anteriormente). Esto evita la combinación de Kerberos y TLS en capas separadas, que tiene demasiados viajes de ida y vuelta y requiere PKI cuando Kerberos por sí solo es suficiente.

Además, gran parte de esta utilidad se debe a la amplia adopción de GSSAPI y SASL en los protocolos a través de los cuales se usa Kerberos, en lugar de las propiedades específicas de Kerberos; otros mecanismos que se pueden utilizar como mecanismos GSSAPI pueden tener una facilidad de uso similar, y hay trabajo actual para hacer esto para OAuth, por ejemplo. Kerberos tiene la ventaja de que todavía permite la autenticación simple basada en contraseña, al tiempo que también permite métodos más sólidos (ambos certificados de clave pública a través de PKINIT y OTP son compatibles), mientras que PKI está vinculado a la necesidad de un segundo factor de algún tipo para mantener la clave privada del usuario y los certificados de CA confiables, lo que ha limitado su adopción para la autenticación del usuario durante bastante tiempo.

En cualquier caso: si desea un inicio de sesión único today , con los sistemas existentes listos para usar, a través de una amplia variedad de aplicaciones y protocolos, particularmente en un entorno de sistemas abiertos, Kerberos es bastante el único juego en la ciudad: nada más coincide con su amplia disponibilidad, facilidad de uso y soporte en productos y protocolos existentes, tanto comerciales como de código abierto.

Para que los protocolos antiguos sean reemplazados por otros más nuevos, no es suficiente que el protocolo antiguo sea ineficiente, complejo, y tenga más agujeros que Queso emmental . Que el nuevo protocolo sea brillante, rápido, simple, moderno y seguro tampoco garantiza la actualización.

Para realmente deshacerte de un protocolo antiguo, debes matar a todos los humanos que se hayan acostumbrado a él. Imagina un joven estudiante; Lo llamaremos Herbert. En la década de 1980, Herbert aprendió sobre Kerberos y, en la locura de su juventud, imaginó que era la cima. De ingenio y perfección en seguridad. Avance rápido de 30 años: ahora es 2014. Herbert se ha casado, se ha divorciado, ha engordado 40 libras, ha cumplido 50 años y ha seguido una carrera exitosa como profesional de TI. Ahora es un "arquitecto sénior" y decide sobre las orientaciones tecnológicas en una gran organización (quizás una institución gubernamental con más de 10000 empleados). Llegó a través de la magia de las promociones basadas en el tiempo y permanece en el nexo de los círculos de toma de decisiones porque es el mejor amigo de algún gerente de alto rango.

Desafortunadamente, a pesar de todas sus habilidades para superar a los competidores y matar reputaciones con algunos rumores bien afinados, Herbert nunca ha encontrado adecuado actualizar sus habilidades tecnológicas y, por ejemplo, tomarse el tiempo para entender realmente lo que esa "novedad" de Internet podría ser. Por lo tanto, Herbert todavía responde a todas las preguntas: "Kerberos. Necesitamos Kerberos". Y, en la tierra del capitalismo triunfante, si Herbert quiere Kerberos, encontrará a algunas personas para que le vendan algunos Kerberos (en ese caso, Microsoft, que usa Kerberos de manera preferencial para todo lo relacionado con Active Directory).

Herbert seguirá activo por otros 10 a 15 años. Peor aún, es contagioso: jóvenes ambiciosos de aproximadamente 35 años de edad navegan en su sombra e imitan sus posturas con la esperanza de alcanzar niveles más altos en la jerarquía local; y estos también repiten la postura de Kerberos, porque funcionó para Herbert, y realmente no comprenden de qué se trata todo esto. En 30 años estas personas seguirán siendo tóxicas.

En una nota similar, medita este extracto de una página de Wikipedia :

  

En 2006 y 2012, las encuestas Computerworld encontraron que más del 60% de las organizaciones usaban COBOL (más que C ++ y Visual Basic .NET) y que para la mitad de ellas, COBOL se usó para la mayoría de Su software interno. El 36% de los gerentes dijo que planeaba migrar de COBOL y el 25% dijo que les gustaría si fuera más barato. En cambio, algunas empresas han migrado sus sistemas de mainframes costosos a sistemas más baratos y modernos, mientras mantienen sus programas COBOL.

Si el cadáver de COBOL aún no solo está contrayéndose, sino que está caminando y entrando activamente en su negocio, entonces no puede esperar que Kerberos desaparezca pronto.