Kerberos: Autenticación Segura en Redes Distribuidas

Clasificado en Informática

Escrito el en español con un tamaño de 3,59 KB

Kerberos tiene como objetivo la implementación de un servicio de autenticación.

    1. Usa un intercambio de claves con una tercera parte de confianza.
    2. Se asume un ámbito abierto en el cual usuarios desean acceder a recursos publicados en servidores distribuidos por toda la red.
    3. Kerberos proporciona un servidor centralizado de autentificación cuya función es autenticar usuarios para los servidores y servidores para los usuarios.
    4. La funcionalidad básica la proporciona el KDC mediante dos servicios:
      • Authentication Service (AS).
      • Ticket Granting Service (TGS).
    5. Mecanismo de control de acceso:
      • Un usuario inicia sesión con su nombre y contraseña. Esta se cifra mediante un algoritmo, y se envía un SMS al KDC para iniciar la sesión. El SMS va en claro y sólo contiene el nombre de usuario. El AS busca al usuario en la BBDD, si lo encuentra hace la misma transformación de contraseña y le devuelve dos SMS:
        • SMS 1: La clave de sesión entre el usuario y el TGS.
        • SMS 2: Ticket-Granting-Ticket, que incluye el nombre del usuario, su IP, un periodo de validez y la clave de sesión con el TGS.
      • Cada vez que el usuario quiera acceder a un tipo de servicio concreto se sigue el mismo procedimiento, el usuario envía 2 SMS al TGS:
        • SMS 3: El TGT que el AS le envió al iniciar sesión y el ID del servicio que se solicita.
        • SMS 4: El autenticador.
      • El TGS recupera el TGT del SMS 3 y lo descifra con su clave privada.
        • De aquí obtiene la clave de sesión para este usuario.
      • Con esta clave puede descifrar el SMS 4 y responder con dos SMS más:
        • SMS 5: Client-to-server ticket que incluye el nombre del usuario, su IP, un periodo de validez y la clave de sesión con el servidor solicitado.
        • SMS 6: Clave de sesión entre el cliente y el servidor.
      • Después de recibir estos dos SMS del TGS el cliente tiene info suficiente para iniciar las sesiones que necesite con el servidor solicitado. Para cada sesión envía dos SMS más:
        • SMS 7: Client-to-server ticket tal y como se recibió del TGS.
        • SMS 8: Un nuevo autenticador.
      • El servidor recupera el ticket del SMS 7 y lo descifra con su clave privada.
      • Con esta clave se puede descifrar el SMS 8 y responder con una confirmación:
        • SMS 9: EL timestamp recuperado del autenticador + 1.
      • Si el timestamp ha sido actualizado correctamente desde el servidor, el cliente puede confiar en él y este empieza a dar servicio.
    6. La versión 4 está muy extendida pero plantea importantes limitaciones:
      • Basada en DES.
      • Depende de los protocolos de comunicaciones.
      • La utilización de timestamp obliga a la sincronización de relojes.
      • La centralización es un problema para la tolerancia a fallos, la disponibilidad y la propia seguridad.
    7. Esto se intenta superar en la versión 5:
      • Se limita el acceso al recurso pero también el uso que se permite que el usuario haga de él.
      • Para ello se encapsula cada objeto con un procedimiento que se encarga de controlar el acceso a él.
    8. La idea es restringir el acceso de los usuarios al objeto y lo que puedan hacer con él.
    9. Roles (RBAC):
      • Mecanismo de control de acceso complementario a cualquiera de las soluciones vistas hasta ahora.
      • Permite distinguir entre diferentes tipos de usuarios, agruparlos y asignar privilegios en función de su pertenencia a dichos grupos.

Entradas relacionadas: