Kerberos fué creado en el Massachusetts Institute of Technology (MIT) como una solución a los problemas de seguridad de la red. El protocolo Kerberos utiliza criptografía fuerte para que un cliente pueda demostrar su identidad en un servidor (y viceversa) a través de una conexión de red insegura.

Kerberos es el nombre de un protocolo de autentificación vía red y un adjetivo para describir programas que implementan el programa (Kerberos telnet, por ejemplo, conocido también como el “telnet kerberizado”). La versión actual del protocolo es la 5, descrita en RFC 1510.

Existen diversas implementaciones libres de este protocolo, cubriendo un amplio rango de sistemas operativos. El MIT, donde Kerberos fué desarrollado, continúa desarrollando su propio paquete Kerberos. Suele usarse en los EEUU como producto criptográfico y como tal ha sufrido las regulaciones de exportación de los EEUU. El Kerberos del MIT existe como un port en (security/krb5). Heimdal Kerberos es otra implementación de la versión 5, y fué desarrollada de forma intencionada fuera de los EEUU para sortear las regulaciones de exportación (y por eso puede incluirse en versiones no comerciales de UNIX®). La distribución Heimdal Kerberos está en el port (security/heimdal), y se incluye una instalación mínima en el sistema base de FreeBSD.

Para alcanzar la mayor audiencia estas instrucciones asumen el uso de la distribución Heimdal incluída en FreeBSD.

El centro de distribución de llaves (KDC, Key Distribution Center) es el servicio centralizado de validación que proporciona Kerberos: es el sistema que emite tickets Kerberos. El KDC goza del estátus de ser considerado como “confiable” por las demás computadoras del dominio Kerberos, y por eso tiene consideraciones de seguridad más elevadas.

Tenga en cuenta que, aunque la ejecución del servidor Kerberos requiere muy pocos recursos, se recomienda el uso de una máquina dedicada a KDC por razones de seguridad.

Para empezar a configurar un KDC asegúrese de que su /etc/rc.conf contenga la configuración adecuada para actuar como KDC (tal vez deba ajustar algunas rutas para que cuadren con su sistema):

kerberos5_server_enable="YES"
kadmind5_server_enable="YES"
kerberos_stash="YES"

A continuación configuraremos el fichero de configuración de Kerberos, /etc/krb5.conf:

[libdefaults]
    default_realm = EJEMPLO.ORG [realms]
    EXAMPLE.ORG = {
        kdc = kerberos.ejemplo.org
        admin_server = kerberos.ejemplo.org
    }
[domain_realm]
    .ejemplo.org = EJEMPLO.ORG

Tenga en cuenta que este /etc/krb5.conf implica que su KDC tendrá el nombre de equipo completo calificado de kerberos.ejemplo.org. Necesitará añadir una entrada CNAME (alias) a su fichero de zona si su KDC tiene un nombre de equipo diferente.

[libdefaults]
      default_realm = EJEMPLO.ORG

_kerberos._udp      IN  SRV     01 00 88 kerberos.ejemplo.org.
_kerberos._tcp      IN  SRV     01 00 88 kerberos.ejemplo.org.
_kpasswd._udp       IN  SRV     01 00 464 kerberos.ejemplo.org.
_kerberos-adm._tcp  IN  SRV     01 00 749 kerberos.ejemplo.org.
_kerberos           IN  TXT     EJEMPLO.ORG

A continuación crearemos la base de datos Kerberos. Esta base de datos contiene las llaves de todos los principales cifradas con una contraseña maestra. No es necesario que recuerde esta contraseña, pues se almacenará en /var/heimdal/m-key. Para crear la llave maestra ejecute kstash e introduzca una contraseña.

Una vez que se ha creado la llave maestra puede inicializar la base de datos usando el programa kadmin con la opción -l (que significa “local”). Esta opción le dice a kadmin que modifique los ficheros de la base de datos directamente en lugar de ir a través del servicio de red kadmind. Esto gestiona el problema del huevo y la gallina de tratar de conectar a la base de datos antes de que ésta exista. Una vez que tiene el “prompt” de kadmin, utilice init para crear su base de datos de dominios iniciales.

Para terminar, mientras está todavía en kadmin puede crear su primer principal mediante add. Utilice las opciones por defecto por ahora, más tarde puede cambiarlas mediante modify. Recuerde que puede usar ? en cualquier “prompt” para consultar las opciones disponibles.

Veamos un ejemplo de sesión de creación de una base de datos:

# kstash
Master key: xxxxxxxx
Verifying password - Master key: xxxxxxxx

# kadmin -l
kadmin> init EJEMPLO.ORG
Realm max ticket life [unlimited]:
kadmin> add tillman
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
Password: xxxxxxxx
Verifying password - Password: xxxxxxxx

Ahora puede arrancar los servicios KDC. Ejecute /etc/rc.d/kerberos start y /etc/rc.d/kadmind start para levantar dichos servicios. Recuerde que no tendrá ningún dæmon kerberizado ejecutándose pero debe poder confirmar que KDC funciona por el procedimiento de obtener y listar un boleto del principal (usuario) que acaba de crear en la línea de órdenes de KDC:

% k5init tillman
tillman@EJEMPLO.ORG's Password:

% k5list
Credentials cache: FILE:/tmp/krb5cc_500
	Principal: tillman@EJEMPLO.ORG

  Issued           Expires          Principal
Aug 27 15:37:58  Aug 28 01:37:58  krbtgt/EJEMPLO.ORG@EJEMPLO.ORG

Antes de nada necesitaremos una copia del fichero de configuración de Kerberos, /etc/krb5.conf. Cópielo al cliente desde KDC de forma segura (mediante scp(1), o usando un disquete).

A continuación necesitará un fichero /etc/krb5.keytab. Esta es la mayor diferencia entre un servidor que proporciona dæmons habilitados con Kerberos y una estación de trabajo: el servidor debe tener un fichero keytab. Dicho fichero contiene las llaves de equipo del servidor, las cuales le permiten a él y al KDC verificar la identidad entre ellos. Deben transmitirse al servidor de forma segura ya que la seguridad del servidor puede verse comprometida si la llave se hace pública. Por decirlo más claro, transferirla como texto plano a través de la red (por ejemplo por FTP) es una pésima idea.

Lo normal es que transmita su keytab al servidor mediante el programa kadmin. Esto es práctico porque también debe crear el principal del equipo (el KDC que aparece al final de krb5.keytab) usando kadmin.

Tenga en cuenta que ya debe disponer de un ticket, y que este ticket debe poder usar el interfaz kadmin en kadmind.acl. Consulte la sección “administración remota” en la página info de Heimdal (info heimdal), donde se exponen los detalles de diseño de las listas de control de acceso. Si no quiere habilitar acceso remoto kadmin, puede conectarse de forma segura al KDC (por medio de consola local, ssh(1) o telnet(1) Kerberos) y administrar en local mediante kadmin -l.

Después de instalar el fichero /etc/krb5.conf puede usar kadmin desde el servidor Kerberos. add --random-key le permitirá añadir el principal del equipo servidor, y ext le permitirá extraer el principal del equipo servidor a su propio keybat. Por ejemplo:

# kadmin
kadmin> add --random-key host/myserver.ejemplo.org
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
kadmin> ext host/miservidor.ejemplo.org
kadmin> exit

Tenga en cuenta que ext (contracción de “extract”) almacena la llave extraída por defecto en en /etc/krb5.keytab.

Si no tiene kadmind ejecutándose en KDC (posiblemente por razones de seguridad) y por lo tanto carece de acceso remoto a kadmin puede añadir el principal de equipo (host/miservidor.EJEMPLO.ORG) directamente en el KDC y entonces extraerlo a un fichero temporal (para evitar sobreescribir /etc/krb5.keytab en el KDC) mediante algo parecido a esto:

# kadmin
kadmin> ext --keytab=/tmp/ejemplo.keytab host/miservidor.ejemplo.org
kadmin> exit

Puede entonces copiar de forma segura el keytab al servidor (usando scp o un diquete). Asegúrese de usar un nombre de keytab diferente para evitar sobreescribir el keytab en el KDC.

Su servidor puede comunicarse con el KDC (gracias a su fichero krb5.conf) y puede probar su propia identidad (gracias al fichero krb5.keytab). Ahora está listo para que usted habilite algunos servicios Kerberos. En este ejemplo habilitaremos el servicio telnet poniendo una línea como esta en su /etc/inetd.conf y reiniciando el servicio inetd(8) con /etc/rc.d/inetd restart:

telnet    stream  tcp     nowait  root    /usr/libexec/telnetd  telnetd -a user

La parte crítica es -a, de autentificación de usuario. Consulte la página de manual telnetd(8) para más información.

Configurar una computadora cliente es extremadamente fácil. Lo único que necesita es el fichero de configuración de Kerberos que encontrará en /etc/krb5.conf. Simplemente cópielo de forma segura a la computadora cliente desde el KDC.

Pruebe su computadora cliente mediante kinit, klist, y kdestroy desde el cliente para obtener, mostrar y luego borrar un ticket para el principal que creó antes. Debería poder usar aplicaciones Kerberos para conectarse a servidores habilitados con Kerberos, aunque si no funciona y tiene problemas al intentar obtener el boleto lo más probable es que el problema esté en el servidor y no en el cliente o el KDC.

Al probar una aplicación como telnet, trate de usar un “sniffer” de paquetes ( como tcpdump(1)) para confirmar que su contraseña no viaja en claro por la red. Trate de usar telnet con la opción -x, que cifra el flujo de datos por entero (algo parecido a lo que hace ssh).

Las aplicaciones clientes Kerberos principales (llamadas tradicionalmente kinit, klist, kdestroy y kpasswd) están incluidas en la instalación base de FreeBSD. Tenga en cuenta que en las versiones de FreeBSD anteriores a 5.0 reciben los nombres de k5init, k5list, k5destroy, k5passwd y k5stash.

También se instalan por defecto diversas aplicaciones Kerberos que no entran dentro de la categoría de “imprescindibles”. Es aquí donde la naturaleza “mínima” de la instalación base de Heimdal salta a la palestra: telnet es el único servicio Kerberos habilitado.

El port Heimdal añade algunas de las aplicaciones cliente que faltan: versiones Kerberos de ftp, rsh, rcp, rlogin y algunos otros programas menos comunes. El port del MIT también contiene una suite completa de aplicaciones cliente de Kerberos.

Suele ser habitual que los usuarios de un dominio Kerberos (o “principales”) tengan su usuario (por ejemplo tillman@EJEMPLO.ORG) mapeado a una cuenta de usuario local (por ejemplo un usuario llamado llamado tillman). Las aplicaciones cliente como telnet normalmente no requieren un nombre de usuario o un principal.

Es posible que de vez en cuando quiera dar acceso a una una cuenta de usuario local a alguien que no tiene un principal Kerberos. Por ejemplo, tillman@EJEMPLO.ORG puede necesitar acceso a la cuenta de usuario local webdevelopers. Otros principales tal vez necesiten acceso a esas cuentas locales.

Los ficheros .k5login y .k5users, ubicados en el directorio home del usuario, pueden usarse de un modo similar a una combinación potente de .hosts y .rhosts. Por ejemplo, si pusiera un fichero .k5login con el siguiente contenido

tillman@example.org
jdoe@example.org

en el directorio home del usuario local webdevelopers ambos principales listados tendrían acceso a esa cuenta sin requerir una contraseña compartida.

Le recomendamos encarecidamente la lectura de las páginas de manual de estas órdenes. Recuerde que la página de manual de ksu abarca .k5users.

Las diferencias más grandes entre las instalaciones MIT y Heimdal están relacionadas con kadmin, que tiene un conjunto diferente (pero equivalente) de órdenes y utiliza un protocolo diferente. Esto tiene implicaciones muy grandes si su KDC es MIT, ya que no podrá utilizar el programa kadmin de Heimdal para administrar remotamente su KDC (o viceversa).

Las aplicaciones cliente pueden también disponer de diferentes opciones de línea de órdenes para lograr lo mismo. Le recomendamos seguir las instrucciones de la página web de Kerberos del MIT (http://web.mit.edu/Kerberos/www/). Sea cuidadoso con los parches: el port del MIT se instala por defecto en /usr/local/, y las aplicaciones “normales” del sistema pueden ser ejecutadas en lugar de las del MIT si su variable de entorno PATH lista antes los directorios del sistema.