3 - Proceso de autenticación

Solicitud KRB_AS_REQ

El primer paso en el proceso de autenticación Kerberos consiste en que el cliente obtenga un Ticket Granting Ticket (TGT) del Key Distribution Center (KDC). Para ello, envía un mensaje de tipo KRB_AS_REQ al servicio de autenticación (AS) del KDC.

KRB_AS_REQ contiene, entre otros campos:

• Marca de tiempo cifrada: en la mayoría de los casos, el cliente incluye un timestamp cifrado con su clave secreta o secret key (derivada del hash de su contraseña). Esta medida permite al KDC verificar que el cliente conoce su clave secreta, y también sirve como protección contra ataques de repetición.

• Nombre de usuario: identifica al cliente que solicita el TGT.

• SPN de servicio: suele ser krbtgt/domain, que representa el servicio de emisión de tickets (Ticket Granting Service) dentro del dominio.

• Nonce: número aleatorio generado por el cliente, que debe ser devuelto por el KDC para confirmar la frescura del ticket y evitar ataques de repetición.

Clave secreta a largo plazo del cliente (Client LT Key o user secret key): esta clave será utilizada en las comunicaciones con el servidor de autenticación (AS) para cifrar o descifrar mensajes. De esta forma ni la contraseña del usuario ni la clave secreta del cliente son enviadas a través de la red para comunicarse con el KDC. El AS, por su parte, posee una copia de esta clave (obtenida del hash de la contraseña almacenado en Active Directory), lo que le permite descifrar y validar el mensaje. Además esta clave se usa en el siguiente paso, para cifrar la clave de sesión (session key) incluida en el TGT, asegurando que solo el cliente pueda acceder a ella con su clave secreta.

Respuesta KRB_AS_REP

Una vez recibido el mensaje KRB_AS_REQ, el KDC procede a verificar la identidad del usuario (descifrando la marca de tiempo con la clave del usuario). Si el contenido es válido, responde con un mensaje KRB_AS_REP.

KRB_AS_REP incluye:

• Nombre de usuario: confirma la identidad autenticada.

• TGT (Ticket Granting Ticket):

  • Nombre del cliente.

  • Clave de sesión (session key): que será compartida entre el cliente y el TGS.

  • Fecha de expiración del TGT.

  • PAC (Privilege Attribute Certificate): contiene los SIDs del usuario, grupos, y privilegios. Está firmado por el KDC para garantizar su integridad.

  • Este TGT ticket no puede ser descifrado por el cliente, ya que está cifrado con una clave que solo el KDC puede interpretar (KDC LT key).

• Datos cifrados con la clave del usuario: esta parte solo puede ser leída por el cliente, e incluye:

  • Clave de sesión (session key).

  • Fecha de expiración del TGT.

  • Nonce (devuelto como confirmación).

La clave de sesión es una clave temporal generada por el KDC al emitir un TGT. Su función es cifrar las comunicaciones entre el cliente, los servicios y el KDC, sin usar la contraseña real del usuario. Solo es válida durante la vida útil del ticket, y permite proteger la sesión sin exponer claves permanentes. Se encuentra cifrada con la secret key del usuario para que solo él pueda descifrarla

El TGT está cifrado con la KDC LT key asociada a la cuenta especial KRBTGT, y la session key está cifrada con la Client LT key (User Secret Key), de modo que solo el cliente puede acceder a ella.

La clave secreta del KDC (KDC long-term key) está asociada a la cuenta especial KRBTGT y se almacena en el KDC. Su función principal es cifrar y firmar los TGTs que emite el servidor de autenticación (AS), garantizando su integridad y validez dentro del dominio.

Solicitud de acceso a servicio KRB_TGS_REQ

Cuando el cliente desea acceder a un servicio específico (como cifs, http, ldap, etc.), envía al KDC un mensaje de tipo KRB_TGS_REQ. Este mensaje se dirige al componente TGS del KDC y utiliza el TGT previamente obtenido.

KRB_TGS_REQ contiene:

• TGT: utilizado como prueba de que el cliente ya fue autenticado (cifrado con la KDC LT key).

• Datos cifrados con la clave de sesión del TGT:

  • Nombre del cliente.

  • Marca de tiempo actual (para prevenir ataques de repetición).

• SPN del servicio solicitado: por ejemplo, cifs/server.dominio.local.

• Nonce: generado por el cliente para validar la respuesta del TGS.

El SPN (Service Principal Name) es un identificador único que vincula un servicio con su cuenta en Active Directory. Permite al cliente saber a qué cuenta autenticarse y al KDC encontrar la clave correcta para cifrar el ticket de servicio

Respuesta KRB_TGS_REP

El TGS, tras verificar la validez del TGT y de la solicitud, responde con un mensaje KRB_TGS_REP, que contiene un ticket de servicio (TGS) válido para autenticarse ante el servicio deseado.

KRB_TGS_REP incluye:

• Nombre del cliente.

• TGS (Ticket de Servicio):

  • Clave de sesión específica para el cliente y el servicio.

  • Nombre del cliente.

  • Fecha de expiración.

  • PAC con los privilegios del usuario, firmado por el KDC.

• Datos cifrados con la clave de sesión:

  • Clave de sesión de servicio.

  • Fecha de expiración del TGS.

  • Nonce (devuelto para confirmar autenticidad de la respuesta).

Solicitud KRB_AP_REQ

En la fase final, el cliente presenta su TGS al servidor del servicio (AP – Application Server), para acceder a un recurso protegido. Esto se hace mediante un mensaje KRB_AP_REQ.

Paso a paso del proceso KRB_AP_REQ

1. Envío del Service Ticket y el Authenticator

El cliente se comunica directamente con el servicio solicitado (por ejemplo, un servidor SQL o un controlador de dominio) y le envía el mensaje KRB_AP_REQ, compuesto por:

• Service Ticket (TGS): Es un ticket cifrado emitido por el KDC, destinado al servicio específico, que contiene información del usuario, su validez temporal, y una clave de sesión compartida.

• Authenticator: Es un paquete cifrado que contiene el nombre del usuario, un timestamp y otros datos relevantes. Este autenticador está cifrado con la Client-Server Session Key, también conocida como service session key, que fue generada por el KDC y compartida previamente con ambas partes.

2. Descifrado del Service Ticket

Al recibir el mensaje, el servicio utiliza su Service Long-Term Key (LT Key), es decir, su clave secreta a largo plazo derivada de su contraseña o clave de cuenta en Active Directory, para descifrar el Service Ticket. Este ticket fue cifrado originalmente por el KDC utilizando esa misma clave.

Una vez descifrado el TGS, el servicio extrae de su interior varios campos, incluyendo:

• La identidad del usuario

• Las fechas de validez del ticket

• La Client-Server Session Key (clave de sesión temporal)

3. Validación del Authenticator

Con la session key extraída del TGS, el servicio puede ahora descifrar el authenticator enviado por el cliente. Este proceso permite verificar:

• Que el autenticador fue generado por quien posee la session key (el cliente legítimo)

• Que el timestamp no está fuera de un rango aceptable (prevención de reenvíos)

• Que la identidad del usuario en el autenticador coincide con la del ticket

Si todas estas validaciones son exitosas, el servicio confía en la autenticidad del usuario y le concede acceso al recurso solicitado.

Verificación del PAC: Aunque es poco frecuente por motivos de rendimiento, el servidor puede validar el PAC mediante el mensaje KERB_VERIFY_PAC_REQUEST (no parte del estándar Kerberos, pero implementado en Active Directory). Esta verificación confirma la firma del PAC, pero no los privilegios.

Autenticación mutua: Si se requiere, el servicio puede responder con un KRB_AP_REP, validando su identidad ante el cliente y completando la autenticación mutua.