stringtranslate.com

Kerberos (protocolo)

Kerberos ( / ˈkɜːrbərɒs / ) es un protocolo de autenticación de redes informáticas que funciona sobre la base de tickets para permitir que los nodos que se comunican a través de una red no segura prueben su identidad entre sí de forma segura. Sus diseñadores lo orientaron principalmente hacia un modelo cliente-servidor y proporciona autenticación mutua (tanto el usuario como el servidor verifican la identidad del otro). Los mensajes del protocolo Kerberos están protegidos contra escuchas clandestinas y ataques de reproducción .

Kerberos se basa en criptografía de clave simétrica y requiere un tercero confiable , y opcionalmente puede usar criptografía de clave pública durante ciertas fases de autenticación. [2] Kerberos usa el puerto UDP 88 de manera predeterminada.

El protocolo debe su nombre al personaje Kerberos (o Cerbero ) de la mitología griega , el feroz perro guardián de tres cabezas del Hades . [3]

Historia y desarrollo

El Instituto Tecnológico de Massachusetts (MIT) desarrolló Kerberos en 1988 para proteger los servicios de red proporcionados por el Proyecto Athena . [4] [5] Su primera versión fue diseñada principalmente por Steve Miller y Clifford Neuman basándose en el protocolo de clave simétrica Needham-Schroeder anterior . [6] [7] Las versiones 1 a 3 de Kerberos eran experimentales y no se lanzaron fuera del MIT. [8]

La versión 4 de Kerberos, la primera versión pública, se publicó el 24 de enero de 1989. Dado que Kerberos 4 se desarrolló en Estados Unidos y que utilizaba el algoritmo de cifrado Data Encryption Standard (DES) , las restricciones de control de las exportaciones de Estados Unidos impidieron que se exportara a otros países. El MIT creó una versión exportable de Kerberos 4 con todo el código de cifrado eliminado, [8] llamada "Bones". [9] Eric Young, de la Bond University de Australia , reimplementó DES en Bones, en una versión llamada "eBones", que podía usarse libremente en cualquier país. El Royal Institute of Technology de Suecia publicó otra reimplementación llamada KTH-KRB. [10]

Neuman y John Kohl publicaron la versión 5 en 1993 con la intención de superar las limitaciones y los problemas de seguridad existentes. La versión 5 apareció como RFC 1510, que luego quedó obsoleta con la RFC 4120 en 2005.

En 2005, el grupo de trabajo de Kerberos del Grupo de trabajo de ingeniería de Internet (IETF) actualizó las especificaciones. Las actualizaciones incluyeron:

El MIT pone a disposición de forma gratuita una implementación de Kerberos, con permisos de copyright similares a los utilizados para BSD . En 2007, el MIT formó el Consorcio Kerberos para fomentar el desarrollo continuo. Entre los patrocinadores fundadores se incluyen proveedores como Oracle , Apple Inc. , Google , Microsoft , Centrify Corporation y TeamF1 Inc., e instituciones académicas como el Instituto Real de Tecnología de Suecia, la Universidad de Stanford, el MIT y proveedores como CyberSafe que ofrecen versiones con soporte comercial.

Protocolo

Descripción

El cliente se autentica en el servidor de autenticación (AS) , que forma parte del centro de distribución de claves (KDC) . El KDC emite un ticket de concesión de tickets (TGT) , que lleva una marca de tiempo y lo cifra utilizando la clave secreta del servicio de concesión de tickets (TGS), y devuelve el resultado cifrado a la estación de trabajo del usuario. Esto se hace con poca frecuencia, normalmente al iniciar sesión el usuario; el TGT caduca en algún momento, aunque el administrador de sesión del usuario puede renovarlo de forma transparente mientras está conectado.

Cuando el cliente necesita comunicarse con un servicio en otro nodo (un "principal", en la jerga de Kerberos), el cliente envía el TGT al TGS, que es otro componente del KDC y que normalmente comparte el mismo host que el servidor de autenticación. El servicio ya debe haberse registrado en el TGS con un nombre principal de servicio (SPN) . El cliente utiliza el SPN para solicitar acceso a este servicio. Después de verificar que el TGT es válido y que el usuario tiene permiso para acceder al servicio solicitado, el TGS emite un ticket de servicio (ST) y claves de sesión al cliente. A continuación, el cliente envía el ticket al servidor de servicio (SS) junto con su solicitud de servicio.

Negociaciones de Kerberos

El protocolo se describe en detalle a continuación.

Inicio de sesión basado en cliente de usuario sin Kerberos

  1. Un usuario ingresa un nombre de usuario y una contraseña en la (s) máquina(s) cliente . Otros mecanismos de credenciales como pkinit (RFC 4556) permiten el uso de claves públicas en lugar de una contraseña. El cliente transforma la contraseña en la clave de un cifrado simétrico. Esto utiliza la programación de claves incorporada o un hash unidireccional , según el conjunto de cifrados utilizado.
  2. El servidor recibe el nombre de usuario y el código simétrico y los compara con los datos de la base de datos. El inicio de sesión se ha realizado correctamente si el código coincide con el código almacenado para el usuario.

Autenticación del cliente

  1. El cliente envía un mensaje de texto sin formato con el ID del usuario al AS (servidor de autenticación) solicitando servicios en nombre del usuario. (Nota: ni la clave secreta ni la contraseña se envían al AS).
  2. El AS comprueba si el cliente está en su base de datos. Si es así, el AS genera la clave secreta mediante el algoritmo hash de la contraseña del usuario que se encuentra en la base de datos (por ejemplo, Active Directory en Windows Server) y envía los dos mensajes siguientes al cliente:
    • Mensaje A: Clave de sesión de cliente/TGS cifrada utilizando la clave secreta del cliente/usuario.
    • Mensaje B: Ticket-Granting-Ticket (TGT, que incluye el ID del cliente, la dirección de red del cliente , el período de validez del ticket y la clave de sesión del cliente/TGS ) cifrado utilizando la clave secreta del TGS.
  3. Una vez que el cliente recibe los mensajes A y B, intenta descifrar el mensaje A con la clave secreta generada a partir de la contraseña ingresada por el usuario. Si la contraseña ingresada por el usuario no coincide con la contraseña en la base de datos del AS, la clave secreta del cliente será diferente y, por lo tanto, no podrá descifrar el mensaje A. Con una contraseña y una clave secreta válidas, el cliente descifra el mensaje A para obtener la clave de sesión del cliente/TGS . Esta clave de sesión se utiliza para futuras comunicaciones con el TGS. (Nota: el cliente no puede descifrar el mensaje B, ya que está cifrado utilizando la clave secreta del TGS). En este punto, el cliente tiene suficiente información para autenticarse ante el TGS.

Autorización de servicio al cliente

  1. Al solicitar servicios, el cliente envía los siguientes mensajes al TGS:
    • Mensaje C: Compuesto por el mensaje B (el TGT encriptado utilizando la clave de sesión TGS) y el ID del servicio solicitado.
    • Mensaje D: Autenticador (que se compone del ID del cliente y la marca de tiempo), cifrado utilizando la clave de sesión del cliente/TGS (que el cliente encontró en el mensaje A).
  2. Al recibir los mensajes C y D, el TGS recupera el mensaje B del mensaje C. Descifra el mensaje B utilizando la clave secreta del TGS. Esto le proporciona la clave de sesión de cliente/TGS y el ID de cliente (ambos están en el TGT). Utilizando esta clave de sesión de cliente/TGS , el TGS descifra el mensaje D (autenticador) y compara los ID de cliente de los mensajes B y D; si coinciden, el servidor envía los dos mensajes siguientes al cliente:
    • Mensaje E: Ticket de cliente a servidor (que incluye el ID del cliente, la dirección de red del cliente, el período de validez y la clave de sesión cliente/servidor ) cifrado utilizando la clave secreta del servicio.
    • Mensaje F: Clave de sesión cliente/servidor cifrada con la clave de sesión cliente/TGS .

Solicitud de servicio al cliente

  1. Al recibir los mensajes E y F de TGS, el cliente tiene suficiente información para autenticarse en el Servidor de Servicios (SS). El cliente se conecta al SS y envía los dos mensajes siguientes:
    • Mensaje E: Del paso anterior (el ticket de Cliente a Servidor , encriptado usando la Clave Secreta del servicio por el TGS).
    • Mensaje G: Un nuevo autenticador, que incluye el ID del cliente, la marca de tiempo y está encriptado usando la clave de sesión cliente/servidor .
  2. El SS descifra el ticket (mensaje E) utilizando su propia clave secreta para recuperar la clave de sesión de cliente/servidor . Utilizando la clave de sesión, el SS descifra el autenticador y compara el ID del cliente de los mensajes E y G; si coinciden, el servidor envía el siguiente mensaje al cliente para confirmar su verdadera identidad y su voluntad de servir al cliente:
    • Mensaje H: La marca de tiempo encontrada en el Autenticador del cliente (más 1 en la versión 4, pero no es necesario en la versión 5 [11] [12] ), cifrada utilizando la clave de sesión cliente/servidor .
  3. El cliente descifra la confirmación (mensaje H) utilizando la clave de sesión cliente/servidor y verifica si la marca de tiempo es correcta. Si es así, el cliente puede confiar en el servidor y comenzar a enviarle solicitudes de servicio.
  4. El servidor proporciona los servicios solicitados al cliente.

Soporte por sistemas operativos

Microsoft Windows

Windows 2000 y versiones posteriores utilizan Kerberos como método de autenticación predeterminado. [13] Algunas incorporaciones de Microsoft al conjunto de protocolos Kerberos están documentadas en RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols". RFC 4757 documenta el uso del cifrado RC4 por parte de Microsoft . Si bien Microsoft utiliza y amplía el protocolo Kerberos, no utiliza el software MIT.

Kerberos se utiliza como el método de autenticación preferido: en general, unir un cliente a un dominio de Windows significa habilitar Kerberos como el protocolo predeterminado para las autenticaciones de ese cliente a los servicios en el dominio de Windows y todos los dominios con relaciones de confianza con ese dominio. [13]

Por el contrario, cuando el cliente o el servidor, o ambos, no están unidos a un dominio (o no forman parte del mismo entorno de dominio confiable), Windows utilizará NTLM para la autenticación entre el cliente y el servidor. [13]

Las aplicaciones web de Internet pueden aplicar Kerberos como método de autenticación para clientes unidos a un dominio mediante el uso de API proporcionadas en SSPI .

Microsoft Windows y Windows Server incluyen setspn , una utilidad de línea de comandos que se puede utilizar para leer, modificar o eliminar los nombres principales de servicio (SPN) de una cuenta de servicio de Active Directory . [14] [15]

Unix y otros sistemas operativos

Muchos sistemas operativos similares a Unix, incluidos FreeBSD , macOS de Apple , Red Hat Enterprise Linux , Solaris de Oracle , AIX de IBM , HP-UX y otros, incluyen software para la autenticación Kerberos de usuarios o servicios. Una variedad de sistemas operativos no similares a Unix, como z/OS , IBM i y OpenVMS, también cuentan con soporte Kerberos. La implementación integrada del protocolo de autenticación Kerberos V para agentes de cliente y servicios de red que se ejecutan en plataformas integradas también está disponible en empresas [ which? ] .

Desventajas y limitaciones

Seguridad

El cifrado Estándar de cifrado de datos (DES) se puede utilizar en combinación con Kerberos, pero ya no es un estándar de Internet porque es débil. [16] Existen vulnerabilidades de seguridad en productos que implementan versiones heredadas de Kerberos que carecen de soporte para cifrados más nuevos como AES.

Véase también

Referencias

  1. ^ "Kerberos 5 versión 1.21".
  2. ^ RFC 4556, resumen.
  3. ^ "Autenticación Kerberos". IONOS Digitalguide . Consultado el 25 de agosto de 2022 .
  4. ^ Garman 2003, pág. 5.
  5. ^ Steiner, Jennifer G.; Geer, Daniel E. (21 de julio de 1988). Servicios de red en el entorno Athena . Actas de la conferencia Usenix de invierno de 1988. CiteSeerX 10.1.1.31.8727 . 
  6. ^ Steiner, Jennifer G.; Neuman, Clifford; Schiller, Jeffrey I. (febrero de 1988).Kerberos : un servicio de autenticación para sistemas de redes abiertas . Actas de la Conferencia USENIX de invierno de 1988. CiteSeerX  10.1.1.112.9002 . S2CID  222257682.
  7. ^ Elizabeth D. Zwicky; Simon Cooper; D. Brent (26 de junio de 2000). Construcción de cortafuegos para Internet: seguridad en Internet y en la Web . O'Reilly. ISBN 9781565928718.
  8. ^ desde Garman 2003, pág. 7.
  9. ^ Pröhl y Kobras 2022, pág. 7.
  10. ^ Garman 2003, págs. 7–8.
  11. ^ C., Neuman; J., Kohl (1993). "El servicio de autenticación de red Kerberos (V5)". doi : 10.17487/RFC1510 . Archivado desde el original el 21 de agosto de 2016. {{cite journal}}: Requiere citar revista |journal=( ayuda )
  12. ^ Clifford, Neuman; Sam, Hartman; Tom, Yu; Kenneth, Raeburn (2005). "El servicio de autenticación de red Kerberos (V5)". doi :10.17487/RFC4120. Archivado desde el original el 21 de agosto de 2016. {{cite journal}}: Requiere citar revista |journal=( ayuda )
  13. ^ abc "¿Qué es la autenticación Kerberos?". Microsoft TechNet. 8 de octubre de 2009. Archivado desde el original el 20 de diciembre de 2016.
  14. ^ Setspn - CMD de Windows - SS64.com
  15. ^ Setspn | Documentos de Microsoft
  16. ^ Tom, Yu; Love, Astrand (2012). "Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos" (Descontinuar DES, RC4-HMAC-EXP y otros algoritmos criptográficos débiles en Kerberos). doi :10.17487/RFC6649. Archivado desde el original el 27 de octubre de 2015. {{cite journal}}: Requiere citar revista |journal=( ayuda )
General
RFC (Requerimientos de comentarios)

Lectura adicional

Enlaces externos

Wikimedia Commons tiene medios relacionados con Kerberos .