Kerberos

1
Kerberos
2
Fue creado por el Instituto de Tecnología de
Massachusetts (MIT) a comienzos de los años 80.
La versión actual de Kerberos es la 5, la misma
está publicada por el IETF.
Kerberos puede proporcionar tres servicios de
seguridad

• Autenticación Probar que usted es quien dice
  ser.
• Integridad Asegurar que los datos no son
  modificados en su tránsito.
• Privacidad Asegurar que los datos no son leídos
  por personas ajenas.

Kerberos utiliza la encripción para proporcionar
cada servicio.
Todas las implementaciones de la versión 5 deben
soportar DES-CBC-MD5, aunque se permiten otros
algoritmos.
3
Terminología

• Secreto Compartido La técnica de
  autenticación se basa en secretos compartidos. Si
  un secreto es conocido sólo por dos entidades,
  cualquiera de ellas puede verificar la identidad
  de la otra confirmando que su par conoce dicho
  secreto.

Autenticador Consiste en una serie de datos
encriptados por medio del secreto compartido.
Esta información debe ser distinta cada vez que
se ejecute el protocolo. Básicamente consiste de
una marca temporal extraída del clock de la
estación de trabajo del cliente, dicha marca sólo
puede diferir en un lapso predeterminado con el
clock del servidor que autentica a dicho cliente
(Por defecto son cinco minutos).
4
KDC Resulta necesario encontrar una manera de
que ambas entidades conozcan el secreto
compartido cuando inician una transacción.
Kerberos utiliza un "intermediario de confianza"
para esta actividad conocido como "Centro de
Distribución de Claves" (KDC). El KDC es un
servicio que se ejecuta en un server seguro
físicamente.
Clave de Sesión Cuando un cliente solicita al
KDC el acceso a un servidor, éste genera en forma
aleatoria una clave denominada "Clave de Sesión"
que será utilizada por el cliente y el servidor
para encriptar el diálogo que mantendrán.
5
TGT Cuando un cliente inicia una sesión,
solicita al KDC un boleto especial que le permita
solicitar posteriormente otros boletos (boletos
de servicio), los cuales posibilitarán el acceso
a distintos servidores. Este boleto especial
recibe el nombre de "Boleto de Concesión de
Boletos" (Ticket Granting Ticket).
Boleto de Servicio Es aquel que solicita el
cliente al KDC para poder acceder a un servicio
que reside en un servidor que implementa Kerberos
como protocolo de autenticación. También se lo
conoce como "Ticket Granting Service".
6
Nomenclatura

• Kx Es la clave secreta (Resumen producido por
  una función Hash de la contraseña) de x, donde x
  es un cliente (c), una aplicación de servidor (s)
  o el KDC (k).
• datosKx Cualquier dato encriptado con la clave
  secreta de x.
• TKs Boleto encriptado con la clave secreta del
  servidor s (Tener en cuenta que no todo el boleto
  se encripta).
• Kx,y Clave de sesión utilizada por las
  instancias x , y.
• datosKx,y Cualquier dato encriptado con la
  clave de sesión compartida entre x , y.

7
Kerberos en un ejemplo

• Cuando un usuario inicia la sesión, la parte
  cliente del protocolo envía un mensaje al KDC
  solicitando un TGT.

El mensaje contiene información de autenticación
que consiste en un marca temporal, encriptada
mediante el resumen de la función de hash de la
contraseña del usuario. marca_temporalKc
 El KDC busca el registro asociado al usuario,
donde encontrará el resumen de su clave, y
procede a desencriptar el mensaje. Si este
proceso es exitoso y la marca temporal es
reciente, el usuario es autenticado.
8
El KDC genera en forma aleatoria un clave de
sesión que compartirá con el usuario, Kc,k.
El KDC envía al usuario un TGT encriptado con su
clave privada TGTKk. Este ticket contiene entre
otros el tiempo de validez del boleto, algunas
banderas, datos de autorización del cliente y la
clave de sesión entre ambos, Kc,k . También envía
esta clave en forma separada, encriptada con la
clave del propio usuario. Kc,kKc.
El usuario desencripta la clave de sesión,
almacena el TGT y está listo para solicitar
boletos de servicio cuando haga falta.
9
Cuando el usuario necesita acceder a un servidor
que ejecuta Kerberos, solicita un boleto de
servicio al KDC para dicho servidor.   Esta
petición contiene entre otras cosas el TGT del
usuario, el nombre del servidor que se pretende
acceder y una marca temporal encriptada usando la
clave de sesión entre el KDC y el usuario
marca_temporalKc,k.   Cuando el KDC recibe la
petición desencripta el TGT, luego extrae la
clave de sesión necesaria para desencriptar el
autenticador. Si dicho proceso es exitoso y la
marca temporal es reciente, se verifica la
identidad del usuario.
10
El KDC prepara el boleto de servicio copiando
algunos campos contenidos en el TGT, agrega un
clave de sesión para el cliente y el servidor,
Kc,s generada aleatoriamente, establece el tiempo
de vida y encripta dicho boleto usando la clave
del servidor TKs   Posteriormente el KDC envía
el boleto al cliente y una copia de la clave de
sesión recién generada, encriptada con la clave
que comparte con el cliente Kc,sKc,k  
11
Cuando recibe los mensajes, el cliente
desencripta y obtiene la clave de sesión que
usará con el servidor Kc,s y envía el boleto de
servicio a dicho server TKs, junto con un
autenticador encriptado con esta nueva clave de
sesión marca_temporalKc,s.   El servidor
desencripta el boleto, obtiene la clave de sesión
Kc,s y desencripta el autenticador. Si este
proceso fue exitoso y la marca temporal es
reciente, se autentica al usuario como válido.
Posteriormente los datos de autorización
contenidos en el boleto determinarán si este
usuario puede acceder a los servicios que desea.
12
Formato de un Ticket

• Existen tres campos que no están encriptados, el
  resto se encripta para protección usando la clave
  del servidor donde el ticket será presentado.

13
Campos no encriptados

• tkt-vno Versión del formato del ticket. Aquí la
  5.
•  
• Realm Nombre del reino (dominio) donde el ticket
•   fue emitido.
• Sname Nombre del servidor

14
Campos encriptados

• Flags Se usan banderas para indicar diferentes
  condiciones del ticket.
•  
• Key Clave de sesión compartida entre el cliente
  y el servidor.
•  
• Crealm Nombre del reino (dominio) del cliente.
•  
• Cname Nombre del cliente.
•  
• Authtime Marca temporal que el KDC especifica
  cuando emite un
• TGT.

15

• Startime Tiempo a partir del cual el ticket es
  válido.
•  
• Endtime Tiempo en que el ticket expira.
•  
• Renew-till (Opcional) Máximo endtime que puede
  tener un ticket con la bandera RENEWABLE
  activada.
•  
• Caddr (Opcional) Una o más direcciones desde las
  cuales el ticket puede ser utilizado. Si se
  omite, el ticket puede usarse desde cualquier
  dirección.
• Authorization-data Privilegios del usuario.
  Kerberos no interpreta este campo, su comprensión
  corre por cuenta del servicio donde el ticket se
  presentará.