Tabla de contenidos 
NFS
Figura: El sistema de autentificación y autorización Kerberos
Según el Gran Diccionario del Diablo("Enlarged Devil's Dictionary(Ambrose Bierce)"), Cerbero es "el perro guardián del Hades, cuyo deber era guardar la entrada del infierno; se sabe que Cerbero tenía tres cabezas".
El sistema de autentificación y autorización Kerberos es un sistema de seguridad basado en la encriptación que proporcionar autentificación mutua entre usuarios y servidores en un entorno de red. Las metas asumidas por este sistema son:
El sistema Kerberos se usa principalmente con propósitos de autentificación, aunque también aporta la flexibilidad necesaria para añadir información de auto.
Las versiones actual del protocolo Kerberos son las 4 y 5. La versión 4 tiene un amplio uso y es la que se suele implementar en productos comerciales. La versión 5 está propuesta actualmente como borrador de Internet. Se basa en la versión 4 e incorpora cierto número de mejoras y nuevas características.
Kerberos da por hecho lo siguiente:
Un Identificador Principal es el nombre que define un cliente o un servicio en el sistema Kerberos.
En la versión 4, el identificador consta de tres componentes:
En la versión 4, cada uno de estos componentes tiene un límite de longitud de 39 caracteres. Debido a convenios, (.) no es un carácter aceptado.
En la versión 5, el identificador consta sólo de dos partes, el reino y el resto, que es una secuencia de cuantos componentes sean necesarios para determinar al principal. Tanto el reino como cada componente del resto se definen como Ristras Genéricas("GeneralStrings") de ASN.1("Abstract Syntax Notation One", estándar ISO 8824), lo que supone pocas restricciones para los caracteres disponibles para los identificadores principales.
En el sistema Kerberos, el cliente que desea contactar con un servidor para que le dé un servicio, debe pedir primero un ticket de una tercera parte de mutua confianza, el KAS("Kerberos Authentication Server"). Este ticket se obtiene como una función en la que uno de los componentes es una llave privada conocida sólo por el servicio y el KAS, de modo que el servicio puede estar seguro de que el ticket procede sólo de Kerberos. El KAS conoce al cliente por su nombre principal(c). La llave privada(K(c)) es la llave de autentificación conocida sólo por el usuario y el KAS.
En este capítulo, el símbolo {X,Y} indica un aje que contiene información o datos X e Y. {X,Y}K(z) indica que un mensaje que contiene los datos X e Y ha sido cifrado usando la llave k(z).
Figura: Esquema de autentificación de Kerberos
El proceso de autentificación consiste en el intercambio de cinco mensajes(ver Figura: Esquema de autentificación de Kerberos):
1 Cliente -> KAS
El cliente envía un mensaje {c, tgs, n}, al KAS, que contiene su identidad(c), un una palabra temporal o "nonce"(un sello de tiempo u otro forma de identificar su solicitud), y solicita un ticket para usarlo con el servidor de tickets(TGS).
2 KAS -> Cliente
El servidor de autentificación busca el nombre del cliente(c) y el nombre del servicio(TGS, el servidor de tickets) en la base de datos de Kerberos, y obtiene una llave de encriptación para cada uno de ellos K(c) y K(TGS).
El KAS crea a continuación una respuesta para enviársela al cliente. Esta respuesta contiene un ticket inicial T(c, TGS) que garantiza al cliente acceso al servidor solicitado(el TGS). T(c, TGS) contiene k(c.TGS), c, TGS, el "nonce", el tiempo de vida y otra información. El KAS también genera una llave aleatoria de encriptación K(c, TGS), llamada llave de sesión. Luego encripta este ticket usando la llave de encriptación del TGS(K(TGS)). Este procedimiento es lo que se denomina un ticket sellado {T( c,tgs)}K( tgs). Inmediatamente se crea un mensaje consistente en el ticket sellado y la llave de sesión de TGS K(c, TGS).
Nota: En la versión 4 de Kerberos, el mensaje es:
{K(c,tgs),n,{T(c,tgs)}K(tgs)}K(c)
, mientras que en la 5 el mensaje tiene una forma más simple:
{K(c,tgs), n}K(c), {T(c,tgs)}K(tgs)
Esto simplifica la doble encriptación(innecesaria) del ticket.
3 Cliente -> TGS
A la recepción del mensaje, el cliente lo desencripta usando su llave secreta K(c) que es la única que él y el KAS conocen. Comprueba que el "nonce" (n) coincide con la solicitud específica, y entonces guarda la llave de sesión K(c,tgs) para futuras comunicaciones con el TGS.
El cliente envía a continuación un mensaje al YGS. Este mensaje contiene el ticket inicial {T(c,tgs)}K(tgs), el nombre del servidor(s), un "nonce", y un nuevo autentificador A(c) que lleva un sello de tiempo. A(c) es {c, nonce}. El mensaje es:
{A(c)}K(c,tgs), {T(c,TGS)}K(TGS), s, n
4 TGS -> Cliente
El TGS recibe el mensaje anterior del cliente(c), y descifra primero el ticket sellado usando su llave de encriptación TGS(este ticket fue sellado originalmente por el KAS en el paso 2 usando la misma llave). El TGS obtiene la llave de sesión para TGS de del ticket descifrado, y la emplea a su vez para descifrar el autentificador sellado (la validez se chequea comparando el nombre del cliente tanto en el ticket como en el autentificador, el nombre del servidor TGS que figura en el ticket, la dirección de red que debe ser igual en el ticket, en el autentificador y en el mensaje recibido). Finalmente, chequea la hora actual en el autentificador para cerciorarse de que el mensaje es reciente. Esto requiere que todos los clientes y servidores matengan sus relojes dentro de cierto margen prescrito de tolerancia. Ahora el TGS busca el nombre del servidor que aparece en el mensaje en la base de datos de Kerberos, y obtiene la lave de encriptación(K(s)) para el servicio especificado.
El TGS crea una nueva llave aleatoria de sesión K(c,s) para el cliente(c) y el servidor, para generar a continuación un nuevo ticket. T(c,s) que contiene:
K(c,s), n, "nonce", tiempo de vida
Luego ensambla un mensaje y lo envía al cliente.
Nota: En la versión 4 de Kerberos Version, el mensaje es:
{K(c,s),n,{T(c,s)}K(s)}K(c,tgs)
En la versión 5 el mensaje tiene una forma más simple:
{K(c,s),n}K(c,tgs), {T(c,s)}K(s)
Esto simplifica la doble encriptación(innecesaria) del ticket.
5 Cliente -> Servidor
El cliente recibe este mensaje y lo descifra usando la llave de sesión para el TGS que sólo comparten él y el TGS. De este mensaje calcula una nueva llave de sesión K( c,s) que comparte con el servidor(s) y un ticket sellado que no puede descifrar porque está cifrado con la llave secreta del servidor K(s).
El cliente construye un autentificador y lo sella con la nueva llave de sesión K(c,s). Por último, envía un mensaje que contiene el ticket sellado y el autentificador al servidor(s) para solicitar su servicio.
El servidor(s) recibe este mensaje y descifra primero el ticket sellado con su llave de encriptación, conocida sólo por él y el KAS. Luego usa la nueva llave de sesión contenida en el ticket para descifrar el autentificador y realiza el mismo proceso de validación que el descrito en el paso 4.
Una vez que el servidor ha validado a un cliente, el cliente tiene la opción de validar a su vez al servidor. Esto evita que un intruso suplante al servidor. El cliente requiere que el servidor le devuelva un mensaje con el sello de tiempo(procedente del autentificador del cliente, incrementado en uno). Este mensaje se cifra con la llave de sesión que pasó del cliente al servidor.
Resumamos los puntos centrales de este esquema:
Kerberos necesita un registro para cada usuario y servicio de su reino y cada registro sólo contiene la información necesaria, que es la siguiente:
El campo de llave privada se cifra con una llave maestra de forma que la eliminación de la base de datos no causará ningún problema puesto que la llave maestra no está en ella.
La entidad responsable de gestionar la base de datos es el KDBM("Kerberos Database Manager"). Sólo hay un KDBM en un reino, pero es posible tener más de un KKDS("Kerberos Key Distribution Server"), cada uno con una copia de la base de datos de Kerberos. Esto se hace para mejorar la disponibilidad y el rendimiento de modo que el usuario pueda elegir de entre un grupo de KKDSs a cuál enviar su petición. El KKDS efectúa sólo operaciones de lectura, dejando la actualización al KDBM, que copia toda la base de datos unas cuantas veces al día. Así se simplifica la operación al usar un protocolo protegido de Kerberos. Este protocolo es básicamente una autentificación mutua entre el KDBM Y EL KDDS seguida de una operación de transferencia de dicheros con campos de checksum y checkpoint.
El modelo de autentificación de Kerberos sólo permite al servicio verificar la identidad del solicitante pero no da información de si éste puede usar o no el servicio. El lema de autorización de Kerberos se basa en el principio de que cada servicio conoce al usuario de modo que puede mantener su propia información de autorización. Sin embargo, el sistema de autentificación de Kerberos se podría extender con información y algoritmos que servirían para propósitos de autorización. (Esto es más fácil en la versión 5. Ver la siguiente sección). El Kerberos podría chequear entonces si un usuuario/cliente está autorizado a usar cierto servicio.
Obviamente, tanto la aplicación del cliente como la del servidor deben ser capaces de manejar el proceso de autentificación de Kerberos. Es decir, cliente y servidor deben estar kerberizados.
La versión 5 de Kerberos tiene una serie de mejoras sobre la versión 4. Algunas de las importantes son:
Para más detalles sobre la diferencia entre las dos versiones de Kerberos, remitirse a [Kohl, Neuman y Ts'o]. Para detalles sobre GSSAPI, remitirse a [Linn].
Gestión de redes