Kerberos para desarrolladores: protocolo y SSPI

## Protocolo Kerberos: Inmersión Profunda para Desarrolladores

Kerberos resuelve el desafío de la suplantación: un servicio en la máquina A recibe una solicitud de un cliente remoto y debe realizar operaciones en nombre de ese cliente, incluyendo el acceso a recursos locales. Para ello, se crea un nuevo token de acceso basado en las credenciales proporcionadas. Sin Kerberos, el servicio usaría su propio token, lo que bloquearía el acceso a archivos que requieren privilegios elevados.

En un escenario de solicitudes encadenadas, el servicio A solicita al servicio B. La delegación te permite elegir: suplantar desde tu propia cuenta o desde la del cliente original. Kerberos pasa tickets encriptados que contienen el SID del usuario, grupos y PAC (Certificado de Atributos de Privilegio).

Componentes Clave:

• Principal: una entidad con contraseña (usuario, equipo, servicio).
• KDC (Centro de Distribución de Claves): almacena contraseñas, emite TGT (Ticket de Concesión de Tickets) y tickets de servicio.
• SPN (Nombre de Principal de Servicio): identificador del servicio, a menudo apuntando a la cuenta bajo la que se ejecuta el servicio.

Kerberos distingue la autenticación de la autorización: descifrar el ticket confirma la identidad, mientras que el token determina los privilegios.

Estructura de Mensajes y Transporte

Los mensajes de Kerberos usan ASN.1 (codificación PER/DER según RFC 4120). Se transmiten sobre UDP/TCP en el puerto 88. UDP funciona para paquetes cortos (TGT ~1-2 KB), TCP para los más grandes (con PAC).

El KDC en Active Directory combina AS (Servicio de Autenticación) y TGS (Servicio de Concesión de Tickets). Los registros SRV (_kerberos._tcp.<domain>) apuntan a los controladores de dominio.

Proceso AS-Exchange (Obtención de TGT):

• Cliente → KDC: KRB_KDC_REQ (preautenticación con marca de tiempo, encriptada con contraseña o PKINIT).
• KDC → Cliente: KRB_KDC_REP (TGT, encriptado con la clave a largo plazo del cliente; clave de sesión en la preautenticación).
• Cliente almacena el TGT en LSA (Autoridad de Seguridad Local).

TGS-Exchange (Ticket de Servicio):

• Cliente → KDC: KRB_TGS_REQ (TGT + autenticador + nombre de servicio/SPN).
• KDC → Cliente: KRB_TGS_REP (ticket de servicio, clave de sesión del servicio).

AP-REQ (con ticket de servicio) se encapsula en LDAP, HTTP Negotiate, SMB, RPC. Wireshark muestra GSS-WRAP con token NTLM/Kerberos.

Cifrado y Claves

La contraseña se transforma en una clave a largo plazo mediante hash (AES-256-CTs para Windows). Las claves de sesión son temporales y se usan para proteger los mensajes.

Ejemplo de código C++ para el cifrado AES de Kerberos usando CNG (Cryptography API: Next Generation):

#include <windows.h>
#include <ncrypt.h>
#include <ntstatus.h>

NTSTATUS EncryptKerberosAES(
    PUCHAR key, ULONG keyLen,
    PUCHAR plaintext, ULONG ptLen,
    PUCHAR* ciphertext, ULONG* ctLen) {
    NCRYPT_ALG_HANDLE hAlg = NULL;
    BCRYPT_KEY_HANDLE hKey = NULL;
    NTSTATUS status;

    status = BCryptOpenAlgorithmProvider(&hAlg, BCRYPT_AES_ALGORITHM, NULL, 0);
    if (!NT_SUCCESS(status)) return status;

    status = BCryptSetProperty(hAlg, BCRYPT_CHAINING_MODE, (PUCHAR)BCRYPT_CHAIN_MODE_CTS, sizeof(BCRYPT_CHAIN_MODE_CTS), 0);
    // Kerberos uses AES-CTS

    status = BCryptGenerateSymmetricKey(hAlg, &hKey, NULL, 0, key, keyLen);
    // ... encrypt logic with IV from Kerberos spec
    // Full code omitted for brevity

    BCryptCloseAlgorithmProvider(hAlg, 0);
    return status;
}

El código demuestra la configuración de AES en modo CTS (Cipher Text Stealing), específico de Kerberos.

Tipos de Delegación y Pruebas

Kerberos soporta delegación restringida y no restringida.

Opciones de Delegación:

• Simple: sin delegación (el servicio no pasa las credenciales más allá).
• No restringida: reenvío completo del TGT (riesgoso, en desuso).
• Restringida: S4U2Proxy — solo ticket de servicio para el SPN especificado.
• Restringida basada en recursos: en el lado del servicio (Windows Server 2012+).

Pruebas en una sola máquina: usa klist, AcquireCredentialsHandle con SSPI. Ejemplo para U2U (User-to-User):

CredHandle cred;
TimeStamp expiry;
AcquireCredentialsHandle(NULL, L"Kerberos", SECPKG_CRED_OUTBOUND, NULL, NULL, NULL, NULL, &cred, &expiry);
// U2U: impersonate without KDC, direct exchange

Para PKINIT: pasa un certificado X.509 a AcquireCredentialsHandle con SECPKG_CRED_CERTIFICATE. GSS-API es un envoltorio para SSPI en Windows.

Autenticación entre Dominios y SPN

Las cuentas de confianza (nombre = dominio) permiten la autenticación entre dominios. Un cliente del dominio A solicita un TGT para el principal de confianza en el dominio B.

El SPN no tiene contraseña; identifica el host/usuario. SPN duplicados apuntan a un solo principal. El sistema determina el tipo por el formato: host/<fqdn>, HTTP/<fqdn>.

Gestión de Múltiples Credenciales:

• ImpersonateHandleExplicit con inicio de sesión.
• Política de LSA para SPN multiusuario.
• Acceptor GSS personalizado con verificación de múltiples claves.

Lecciones Clave

• Kerberos es la capa GSS-API para el inicio de sesión único en AD; los tickets contienen PAC con SIDs/grupos.
• La delegación es crítica para backend a backend; la restringida minimiza riesgos.
• Prueba SSPI: 3-5 líneas para AcquireCredentialsHandle en lugar de código repetitivo.
• PKINIT y U2U extienden escenarios sin contraseña.
• ASN.1 + AES-CTs es el núcleo del protocolo; supervísalo en Wireshark en el puerto 88.

— Editorial Team