Un ticket válido no es un permiso universal
Un servicio recibe una petición de [email protected] y un analista ve que la application request (AP-REQ) fue aceptada. La conclusión “Alice puede usar el servicio” parece razonable, pero todavía comprime varias preguntas: ¿qué autoridad emitió el ticket?, ¿para qué principal de servicio?, ¿qué clave permitió descifrarlo?, ¿el authenticator —la estructura fresca con la que el cliente demuestra conocer la session key— era válido?, ¿los relojes estaban dentro del clock skew o margen admitido?, ¿se evitó un replay, la reutilización de una presentación anterior?, ¿qué política autorizó la operación concreta? Kerberos resuelve una parte de esa cadena: permite a un servicio comprobar que un Key Distribution Center (KDC) emitió una credencial para un principal y que el cliente conoce una clave asociada. No decide por sí solo qué recurso puede usar ese principal.
Este capítulo construye el modelo de Kerberos V5 genérico de RFC 4120, con las extensiones de preautenticación de RFC 6113 y referrals de RFC 6806. Active Directory tiene objetos, extensiones y políticas propias; quedan para el capítulo 43. Aquí interesan las relaciones que un auditor o diseñador debe poder reconstruir: principales, realms, claves, tickets, autenticators, relojes, replay caches y fronteras de confianza.
El modelo mínimo: quién conoce qué clave
Un principal es una identidad operativa nombrada en Kerberos: una persona, servicio o proceso. El nombre incluye componentes y un realm, por ejemplo [email protected] o files/[email protected]. Un realm es el dominio administrativo cuyo KDC mantiene la base de principales y emite credenciales conforme a su política. El nombre no prueba una identidad civil ni autorización fuera del alcance de esa autoridad.
El KDC se describe lógicamente mediante dos roles. El Authentication Server (AS) atiende el primer intercambio, una authentication-service request/reply (AS-REQ/AS-REP); en el camino de bootstrap habitual entrega un Ticket-Granting Ticket (TGT), aunque el protocolo también permite solicitar credenciales para un servidor concreto. El Ticket-Granting Server (TGS) atiende una ticket-granting-service request/reply (TGS-REQ/TGS-REP), usando un TGT para emitir un ticket para un servicio concreto. Una instalación puede implementar ambos roles en el mismo proceso y endpoint; la distinción es de función del protocolo, no necesariamente de máquina.
Conviene separar tres familias de claves:
- La long-term key de un principal es un secreto persistente conocido por el KDC y por el principal que puede actuar como cliente o servicio. Una contraseña puede ser la entrada para obtener una clave, pero no debe asumirse que el KDC envía la contraseña.
- La ticket encryption key es la clave con la que el KDC cifra la parte protegida de un ticket para el servicio que lo aceptará. El cliente transporta el ticket, pero no necesita leer su contenido protegido.
- La session key es una clave aleatoria compartida por dos participantes para una conversación: cliente–TGS durante la solicitud de tickets, o cliente–servicio durante el uso del service ticket. Una session key no es una sesión de aplicación ni concede permisos por sí misma.
El TGT está cifrado para el TGS del realm; un service ticket está cifrado para el principal del servicio. Esa separación es la base de la intermediación: Alice puede pedir muchos tickets sin entregar a cada servicio su long-term key. También limita el alcance de una clave comprometida: conocer una session key de files/fs1 no equivale a poder descifrar TGTs ni a impersonar el KDC.
Desliza horizontalmente para leer el diagrama a tamaño completo.
AS: obtener un TGT sin confundir respuesta con identidad
Alice comienza con un AS-REQ al AS. Incluye el principal solicitado, el realm, opciones de KDC, tipos de cifrado soportados, tiempos deseados y, cuando aplica, datos de pre-authentication. El cliente genera un nonce para asociar la respuesta a la solicitud. RFC 4120 permite que una petición sin preautenticación resulte en una respuesta o en KDC_ERR_PREAUTH_REQUIRED con METHOD-DATA que indica mecanismos aceptables; la política del realm decide cuándo es obligatoria.
El AS resuelve el principal y aplica su política de tiempos, tipos de cifrado y flags. Si la preautenticación es correcta, genera una session key para cliente y TGS y un TGT cuya parte cifrada contiene, entre otros campos, el cliente, el servicio TGS, flags, session key, tiempos y datos de autorización. La respuesta AS-REP cifra la parte que Alice debe leer con la clave derivada de su long-term key o con una reply key (clave de respuesta) establecida por el mecanismo de preautenticación. El TGT sigue protegido para el TGS.
Hay dos comprobaciones distintas en el cliente. Primero, debe asociar el cname y crealm de la respuesta con lo que pidió, verificar el nonce y comprobar sname, srealm y las direcciones cuando el intercambio las use. Segundo, debe descifrar la parte de la respuesta que contiene la session key y otros datos. La clave de esa parte es la del cliente, salvo que un mecanismo de preautenticación haya establecido o reemplazado la reply key. Que el cliente pueda descifrar no convierte la respuesta en una afirmación global sobre una persona: demuestra que el KDC aceptó una prueba para ese principal dentro de ese realm y esa ceremonia. El AS-REP tampoco prueba por sí solo al host de aplicación que una persona física sea ese principal; la confirmación frente al servicio ocurre en el intercambio AP.
El TGT tiene un lifetime. starttime y endtime limitan su uso; renew-till sólo existe para tickets RENEWABLE y establece el límite absoluto de renovaciones. Solicitar un lifetime no obliga al KDC a concederlo: la política puede recortarlo por principal, servicio o realm. Un TGT INVALID postdated requiere validación posterior. Estas son restricciones del artefacto, no una promesa de disponibilidad permanente.
Qué protege cada parte del mensaje
Los nombres de los campos pueden inducir una falsa sensación de uniformidad. En Kerberos, algunas estructuras se transportan como objetos opacos y otras tienen una porción en claro que sirve para enrutar o seleccionar una clave. Un Ticket expone su versión, realm, nombre de servicio y enc-part; el contenido que atribuye el ticket al cliente, transporta la session key y fija tiempos está dentro de esa parte cifrada. El servicio no acepta el nombre visible sin comprobar que el contenido protegido corresponde al principal y a su propia clave.
El Authenticator es diferente: no es otra copia del ticket. Está cifrado con la session key que el ticket permite obtener y lleva datos de la petición actual. Un checksum dentro del authenticator puede ligar datos de aplicación, pero sólo tiene el alcance de la clave y del protocolo que lo verifica. Si una aplicación necesita integridad de mensajes posteriores, debe definir cómo usa subkeys, números de secuencia o los mensajes Kerberos SAFE/PRIV (KRB_SAFE/KRB_PRIV); aceptar el AP-REQ no protege automáticamente el cuerpo de todas las operaciones de Hypertext Transfer Protocol (HTTP) o Remote Procedure Call (RPC) siguientes.
Esta distinción también evita llamar “cifrada” a toda garantía. El cifrado del ticket protege confidencialidad frente a quien no tiene la clave del servicio; el authenticator y sus checksums aportan prueba de posesión e integridad bajo la session key; el reloj y la replay cache aportan frescura operacional. Una aplicación puede tener un AP-REQ correcto y, aun así, transmitir después datos sin protección o aplicar una autorización obsoleta. El análisis debe nombrar la propiedad, la clave, el mensaje y el punto de verificación concretos.
Preautenticación, padata y FAST
La preautenticación añade evidencia o material criptográfico al intercambio AS. RFC 4120 trata padata como una extensión tipada; RFC 6113 define cómo los mecanismos cambian el estado de solicitud y respuesta, cómo se encadenan y qué funciones conceptuales pueden aportar: autenticar al cliente, autenticar al KDC, fortalecer o reemplazar la reply key y proteger la conversación.
Flexible Authentication Secure Tunneling (FAST) es una facility de preautenticación que crea un canal protegido entre cliente y KDC mediante un armor ticket (ticket de armadura) y puede transportar factores. El túnel protege integridad y confidencialidad del intercambio; no dice qué factor prueba la identidad ni qué autorización recibirá el principal en un servicio. Un diseño puede encapsular un factor de contraseña, certificado u otro método, pero la asociación entre factor, cuenta y política debe comprobarse por separado.
FAST también cambia el análisis de errores y negociación. Sin una protección adicional, una respuesta que indica un referral o un mecanismo de preautenticación puede ser manipulada en tránsito para alterar la decisión del cliente. RFC 6113 exige que, al terminar una autenticación exitosa, ambas partes hayan verificado el plaintext relevante y que los mensajes de una conversación no se reordenen ni repitan. Eso protege la conversación; no corrige un KDC comprometido ni una política de realm equivocada.
Desliza horizontalmente para leer el diagrama a tamaño completo.
TGS: del TGT al ticket de servicio
Cuando Alice necesita files/fs1.northstar.example, construye un TGS-REQ al TGS. Presenta el TGT, normalmente un authenticator cifrado con la session key cliente–TGS, el nombre del servicio, opciones y tiempos. Si el authenticator aporta una sub-session key (subclave específica de ese intercambio), el TGS puede usarla para proteger la respuesta según el intercambio. El TGS descifra el TGT con su clave, obtiene la session key y verifica el authenticator. Si la verificación funciona, emite un service ticket cifrado con la long-term key del servicio y una nueva session key cliente–servicio.
El TGT permite solicitar tickets; no es el ticket que el servidor de archivos debe aceptar. El service ticket contiene el nombre del servicio y el principal cliente en su parte cifrada, además de flags, claves y lifetimes. El cliente guarda ambos objetos normalmente en una credential cache. La cache es almacenamiento local de credenciales; no es la replay cache del servidor y no debe llamarse “la sesión Kerberos” sin explicar qué entry y qué lifecycle se observan.
Un TGS-REP puede incluir una nueva clave de sesión y tiempos que el cliente valida. El cliente no necesita abrir el service ticket: lo conserva para entregarlo al servicio correcto. Si el nombre solicitado fue canonicalizado o resultó en un referral, el nombre efectivo de la respuesta puede diferir. RFC 6806 requiere que el cliente solicite canonicalize para recibir ese comportamiento y recomienda limitar referrals a realms permitidos por política local.
Intercambio con el application server (AP): ticket más authenticator
Para usar el servicio, Alice crea un AP-REQ con el service ticket y un authenticator nuevo. El authenticator incluye al menos el nombre del cliente y un timestamp; puede incluir checksum de datos de aplicación, número de secuencia o una subkey (subclave negociada para este intercambio). Está cifrado con la session key cliente–servicio. El ticket permite al servicio obtener esa clave; el authenticator demuestra que el presentador la conoce y liga la prueba a un instante reciente.
El servidor verifica el tipo de mensaje, la clave de versión disponible, el realm y nombre de servicio del ticket, descifra y verifica la integridad del authenticator con la session key, valida el checksum opcional si la aplicación lo usa, y comprueba el cliente esperado, el timestamp y la ventana de clock skew. También evalúa flags, direcciones si se usan y authorization data que sea crítica para ese servicio. Si se solicitó autenticación mutua, el servidor devuelve una application reply (AP-REP), normalmente protegiendo el timestamp recibido y, opcionalmente, una subkey. Esa respuesta permite a Alice comprobar que el peer conocía la session key; no convierte la aplicación en una autoridad de autorización.
RFC 4120 exige que los authenticators no se reutilicen. El servidor debería rechazar una reproducción; en un transporte que duplica mensajes, el cliente genera un authenticator nuevo o el protocolo de aplicación empareja el duplicado con la primera respuesta. El dato temporal no sustituye una memoria de uso: dos mensajes distintos pueden llegar dentro del mismo margen y un mensaje repetido puede parecer válido si el servicio no conserva estado suficiente.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Tiempo: tres campos y un margen, no una licencia de retraso
Kerberos usa relojes para acotar el uso de credenciales y detectar repetición. El ticket contiene starttime, endtime y, si es renovable, renew-till. El servicio compara su tiempo local con esos valores con un acceptable clock skew. RFC 4120 §8.2 recomienda cinco minutos como valor de ese margen; no es un requisito de la configuración mínima de §8.1 ni un valor universal. MIT Kerberos documenta un default de 300 segundos para clockskew; no debe trasladarse a otro producto sin comprobarlo.
El margen opera en ambas direcciones con cuidado. Un ticket cuyo inicio está más de la ventana en el futuro se rechaza como not yet valid; uno cuyo fin quedó atrás más allá del margen se rechaza como expired. Dentro de la ventana puede aceptarse un límite que el servicio considera ligeramente adelantado o atrasado, pero esa tolerancia no transforma renew-till en un nuevo endtime ni permite renovar después del máximo absoluto.
El diagnóstico debe comparar el reloj del cliente, el del KDC que atiende AS/TGS y el del servicio que valida; si AS y TGS están separados, se comparan también ambos. En virtualización, suspensión, sincronización insegura o una máquina virtual con deriva, un KRB_AP_ERR_SKEW puede ser síntoma de infraestructura, no de credenciales inválidas. Sin embargo, sincronizar relojes mediante una fuente no autenticada sólo desplaza el problema: RFC 4120 exige proteger el protocolo de sincronización si los relojes se sincronizan por red.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Replay cache: la memoria que el ticket no contiene
Una replay cache registra identificadores de authenticators ya aceptados durante la ventana relevante. Salvo que el servidor tenga un mecanismo propio adecuado —por ejemplo, challenge–response iniciado por él o una server-generated encryption subkey cuya protección de replay esté definida por el protocolo de aplicación—, debe usar replay cache. La comprobación no busca detectar toda repetición de bytes de red; busca impedir que el mismo authenticator, asociado a un ticket y principal, sea aceptado otra vez en condiciones donde aún parece temporalmente válido.
La distribución importa. Si varias instancias comparten un service principal, deben compartir la replay cache o usar un protocolo de aplicación que elimine esa necesidad. De lo contrario, un balanceador puede enviar el primer uso a fs1-a y el replay a fs1-b, que no conoce la decisión previa. Una cache perdida o inconsistente no es sólo un problema operativo: amplía la ventana en la que una credencial capturada puede repetirse. RFC 4120 indica que un servidor que pierde seguimiento de authenticators debe rechazar solicitudes hasta que el intervalo de clock skew haya transcurrido, si no puede asegurar que los datos antiguos ya no sean aceptables.
MIT Kerberos expone un default_rcache_name y formatos de replay cache configurables; esos nombres son detalles de implementación. La propiedad normativa es la protección contra replay en el modelo de servicio, no el tipo concreto de archivo. La credential cache del cliente conserva tickets y claves para solicitudes posteriores; la replay cache del servicio conserva la memoria de authenticators ya aceptados. No son dos nombres para el mismo estado. En un despliegue con contenedores o múltiples workers, la revisión debe localizar quién conserva cada cache, cómo se comparte, qué ocurre al reiniciar y qué evidencia demuestra un rechazo.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Flags: capacidades acotadas y decisiones explícitas
Los ticket flags no son etiquetas decorativas. RENEWABLE permite pedir renovación hasta renew-till; FORWARDABLE permite que un TGT sea reenviado para que otro proceso actúe con las credenciales del cliente; PROXIABLE permite solicitar tickets para un servicio desde un proxy; POSTDATED y INVALID controlan tickets cuyo inicio es futuro; MAY-POSTDATE permite pedirlos según política; OK-AS-DELEGATE comunica que el realm considera al servicio un receptor apropiado de delegación. Cada flag tiene un contexto y una política de aceptación concretos.
Un cliente no obtiene un flag sólo por pedirlo: el KDC aplica políticas del principal, servicio y realm. Que un ticket sea FORWARDABLE no prueba que el intermediario sea confiable. El cliente puede usar OK-AS-DELEGATE como señal para decidir si entrega credenciales, pero el servicio todavía debe restringir qué operaciones puede efectuar en nombre del cliente y registrar la cadena de mediación.
Las direcciones (caddr) son otra restricción opcional. Un ticket addressless puede funcionar a través de traducción de direcciones de red (Network Address Translation, NAT); un ticket con direcciones limita ubicaciones declaradas, pero no prueba integridad del endpoint ni impide a un atacante que controla el host usar las credenciales desde ese host. El servicio y el KDC deciden si emiten o aceptan tickets sin direcciones. No conviene tratar una dirección dentro del ticket como control de dispositivo.
Delegación: una capacidad no es consentimiento
La delegación aparece cuando Alice permite que un intermediario contacte otro servicio en su nombre. Con credenciales forwardable, el intermediario puede recibir un TGT reenviado y solicitar tickets posteriores; con credenciales proxiable puede obtener tickets con restricciones diferentes. Es una capacidad de protocolo que debe combinarse con una política de confianza, un alcance temporal y una auditoría de actor original, mediador y servicio final.
Si un gateway recibe el TGT de Alice, eso no le concede todas las operaciones que Alice podría ejecutar directamente. El gateway debe imponer su propia política y el servicio final debe saber si el principal efectivo es Alice, el gateway o ambos. Sobrescribir el principal humano con el del servicio pierde atribución; copiarlo sin marcar la mediación permite atribuir al usuario una acción que el servicio tomó por su cuenta. El diseño de evidencia debe conservar initiator, delegating principal, intermediate service, effective principal, ticket id o referencia, operación y policy version, sin registrar secretos reutilizables.
Cross-realm: una ruta de confianza, no una identidad global
Cuando el servicio reside en otro realm, el cliente puede obtener una cadena de cross-realm TGTs. Un TGT inter-realm está cifrado con una clave compartida por KDCs de realms vecinos o por una relación de confianza equivalente en el diseño; cada salto limita qué KDC puede emitir el siguiente ticket. El campo transited permite al servicio conocer los realms atravesados. El application server es el actor último de aceptación: debe comprobar la política de tránsito o rechazar tickets que no tengan el estado requerido. El KDC del realm del servicio puede aplicar una política previa y marcar TRANSITED-POLICY-CHECKED, pero esa marca no elimina la responsabilidad del servicio cuando su política exige comprobarlo.
RFC 6806 introduce client referrals y server referrals. Con canonicalize, el cliente acepta que la respuesta use un principal distinto al nombre solicitado y que el KDC devuelva un referral TGT hacia el siguiente realm. El cliente debe limitar el número de referrals para evitar bucles y aceptar mappings sólo desde realms confiables por política local. FAST puede proteger la integridad de solicitudes y errores del proceso de referral, pero no convierte cualquier realm que responda en confiable.
La confianza criptográfica tampoco resuelve account mapping. alice@REALM-A puede tener o no una cuenta equivalente en REALM-B; el servicio debe decidir cómo interpreta el principal, qué atributos o authorization data acepta, qué recursos están dentro de su scope y qué cambios de relación revocan acceso. “Hay trust” describe un camino para verificar credenciales, no una concesión universal de derechos.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Lo que Kerberos autentica y lo que debe decidir la aplicación
Al aceptar un AP-REQ, el servicio puede sostener que un KDC emitió un ticket para el principal nombrado, que el ticket se dirige a ese servicio, que el presentador conocía la session key y que el authenticator pasó verificaciones de tiempo y replay según la implementación. Puede sostener más si el protocolo de aplicación y la authorization data lo permiten, pero cada afirmación necesita su evidencia.
No puede inferir sólo de eso que una persona física estuvo frente al teclado, que el endpoint está libre de malware, que el usuario quiso una operación específica o que existe permiso sobre un recurso. RFC 4120 dice explícitamente que autenticar al principal no implica autorización para usar el servicio; la aplicación debe decidir según nombre autenticado, operación, control de acceso y, si corresponde, un servicio de autorización separado.
La cifratura tampoco equivale a autorización. Cifrar un ticket protege su contenido frente a quien no posee la clave del servicio; un checksum o una session key protegen integridad y autenticación de mensajes según su uso. Ninguno de esos mecanismos responde por sí solo “¿puede alice escribir /finance/payroll?”. La decisión debe considerar recurso, acción, estado actual, delegación, tenant, separación de funciones y frescura requerida.
Diagnóstico por evidencia, no por nombres de error
Un diagnóstico útil conserva el intercambio y sus fronteras:
- AS: principal solicitado, realm, preauth requerida y usada, nonce, tipos de cifrado, lifetime concedido y motivo de error.
- TGS: principal de servicio solicitado y efectivo, TGT usado, referral/canonicalization, flags heredados y tiempos.
- AP: service principal, versión de clave disponible, resultado de ticket y authenticator, clock offset observado, replay-cache lookup y solicitud de mutual authentication.
- Aplicación: principal autenticado, actor mediador, operación, recurso, decisión de autorización, policy version y resultado de enforcement.
Los logs deben usar referencias no reutilizables a tickets y sesiones, nunca claves, contraseñas, authenticators completos o credenciales forwardable. Un KRB_AP_ERR_TKT_EXPIRED apunta a lifetime o reloj; KRB_AP_ERR_REPEAT apunta a replay o retry; un KDC_ERR_PREAUTH_REQUIRED es una transición negociable, no evidencia automática de ataque. Un AP aceptado seguido de un 403 puede ser el comportamiento correcto: autenticación exitosa y autorización negativa son estados distintos.
Modelo de revisión del incidente
Supóngase que el mismo AP-REQ se acepta dos veces detrás de un balanceador. La observación es doble aceptación; la inferencia inicial es una falla de replay protection. Hay que discriminar: ¿las instancias comparten service principal?, ¿la replay cache es común y durable?, ¿el segundo mensaje tenía authenticator nuevo?, ¿la aplicación generó una respuesta idempotente?, ¿hubo reinicio que borró estado? Sólo después se asigna causa y remediación. Rotar la clave del servicio podría invalidar tickets, pero no arregla un diseño donde cada instancia mantiene una cache aislada.
Otro caso: el cliente recibe referral a un realm inesperado. La observación es el nombre efectivo distinto; no basta para afirmar redirección maliciosa. Se revisan canonicalize, integridad de la respuesta, FAST, lista local de realms confiables, ruta transited y política de aceptación. Si la política permite cualquier referral, el riesgo es de trust mapping; si el mensaje fue alterado sin protección, es de integridad del intercambio. Son controles distintos.
Síntesis: cuatro invariantes para no sobreinterpretar un ticket
Kerberos coordina claves y credenciales temporales mediante tres intercambios. En el bootstrap habitual, AS entrega un TGT protegido para pedir otros tickets; TGS entrega un service ticket protegido para un servicio concreto; AP combina ticket y authenticator para demostrar conocimiento reciente de una session key y, opcionalmente, obtener autenticación mutua. Cada paso tiene claves, lifetimes y participantes diferentes.
El tiempo limita uso; la replay cache añade memoria; los flags restringen capacidades; la preautenticación y FAST protegen o amplían la ceremonia inicial; la delegación y el cross-realm expresan rutas que requieren decisiones de confianza. Ninguno elimina la necesidad de autorización local.
La afirmación profesional final es acotada: “el servicio aceptó un ticket emitido para este principal, con un authenticator válido dentro de esta ventana, bajo esta política de replay, reloj y claves”. Para convertirla en “la acción fue permitida”, todavía hace falta la decisión de autorización y su enforcement. El ticket es evidencia de una relación criptográfica temporal, no una licencia universal.