Resumen

  • La RFC 1510, publicada en septiembre de 1993, conectó realms Kerberos mediante claves entre realms y tickets TGT para los servicios de concesión de tickets (TGS). transited era un conjunto sin orden de los realms intermedios; el realm del cliente y el del servicio aparecían en otros campos.
  • Por eso, un salto directo entre dos realms podía dejar vacío transited sin dejar de cruzar la frontera. La RFC 4120, que sustituyó a la RFC 1510 en 2005, hizo explícito el control: el servidor de aplicación comprueba la ruta o rechaza el ticket entre realms si falta la marca de verificación del KDC.

Análisis

Los extremos están fuera de la lista

Pensemos en un usuario de ALPHA.EXAMPLE que solicita un ticket para el servicio de archivos de BETA.EXAMPLE. Si ambos realms comparten la clave necesaria y no hay un tercer realm entre ellos, el campo transited puede quedar vacío. Los campos del ticket siguen identificando ambos extremos; el valor vacío registra un salto directo sin realm intermedio.

transited funciona como un apunte breve de los realms intermedios. Los extremos se guardan en otros campos y un salto directo deja vacío el tramo intermedio.

La RFC 1510 describe cada realm como un dominio administrativo con su propio servicio Kerberos. El realm forma parte del nombre del principal y ayuda al servicio receptor a decidir si atender la solicitud. Para que un cliente cruce a otro realm, sus administradores establecen una clave entre realms; pueden usar claves distintas en cada dirección. El servicio de concesión de tickets del realm remoto se registra como principal en el otro, y el KDC remoto descifra el ticket que recibe con esa relación de claves.

El cliente no necesita una cuenta paralela en todos los realms de destino. Primero obtiene un ticket TGT para el servicio de concesión de tickets (TGS) remoto; después lo presenta para solicitar el ticket de la aplicación. La clave compartida hace de puente criptográfico. Decidir si se instala y conserva ese puente es tarea administrativa.

La lista conserva los nombres; el orden queda fuera

La ruta puede atravesar varios realms. La RFC 1510 dice que lo habitual era organizarlos jerárquicamente: cada uno compartía una clave con su padre y claves diferentes con sus hijos. Así se podía construir una ruta cuando los extremos no tenían una clave directa. El texto también permitía rutas alternativas que saltaban realms intermedios, incluso para hacer más eficiente la comunicación. En una estructura sin jerarquía, podía hacer falta consultar otra base de datos.

RFC 1510 guarda los realms intermedios como un conjunto sin orden y comprime los nombres jerárquicos habituales para acortar el campo. La secuencia del recorrido queda en otro registro; este campo aporta los nombres que el ticket reporta.

El servicio de concesión de tickets añade el realm que emitió el ticket que recibió; su propio realm queda fuera del campo. RFC 1510 explica que así un servidor no puede ocultar su participación omitiendo su nombre. La especificación marca el límite: ese servidor aún podría omitir otros realms. La política del servicio debe evaluar esas otras declaraciones.

La RFC 4120, publicada en julio de 2005, reemplazó a la RFC 1510 y detalló quién debía revisar el trayecto. El servidor de aplicación conserva la decisión final de aceptar o rechazar. Debe comprobar que confía en los KDC que autenticaron al principal. El KDC del realm de destino puede aplicar una política local y marcar el ticket con TRANSITED-POLICY-CHECKED. Si no hizo esa comprobación, el servidor de aplicación tiene que verificar los realms por su cuenta o rechazar el ticket entre realms sin la marca. La RFC advierte que un KDC no confiable puede fabricar la lista aunque aparezcan en ella nombres conocidos.

La decisión se reparte en tres escritorios: los administradores instalan las claves, los KDC emiten tickets y registran sus comprobaciones, y cada aplicación acepta o cierra el paso. Añadir una clave reduce pasos para algunos usuarios. También amplía el grupo de identidades que pueden llegar a los servicios conectados. Quien instala la clave aprueba acceso futuro y deja en el diagrama la ruta que ese acceso seguirá.

La nota de septiembre de 1993 decía que el protocolo seguía bajo revisión y que aún no se proponía como estándar de Internet. RFC 4120 entró en la vía Standards Track en 2005 y detalló mejor las obligaciones de implementación. Falta un registro de despliegue de los años noventa que indique qué servidores comprobaron transited; ese registro mostraría si el control operaba en sistemas reales, mientras las RFC documentan el diseño.

Fuentes