Veteranos y vanguardia: Kerberos, RADIUS, WS-* y FIDO2

Más allá de los cuatro centrales

Este módulo ha pasado la mayor parte del tiempo en el stack moderno de federación y aprovisionamiento — servicios de directorio, SAML, OAuth, OIDC, SCIM. Pero entra a cualquier empresa real y encontrarás un zoológico más amplio de protocolos haciendo trabajo crítico en silencio. Algunos son veteranos — de décadas, sin glamour, y aún load-bearing bajo millones de logins al día. Uno es la vanguardia — el futuro resistente a phishing que está reemplazando activamente las contraseñas. La fluidez en identidad significa reconocerlos todos — y saber que el protocolo más nuevo en la diapositiva de arquitectura rara vez es el que carga más peso en producción.

Este artículo recorre cuatro: Kerberos (el sistema de tickets detrás de cada login de Active Directory), RADIUS (el protocolo detrás de tu Wi-Fi y VPN corporativos), WS-Federation / WS-Trust (la federación de la era SOAP aún viva en grandes estados de ERP) y FIDO2 / WebAuthn / CTAP (la vanguardia de clave pública). Tres veteranos y un vistazo al futuro.

Kerberos: el sistema de tickets bajo cada login de AD

Kerberos (RFC 4120) es un protocolo de autenticación basado en tickets nacido en el MIT en los años 80, y es el corazón palpitante de la autenticación de Active Directory. Su idea central: tras un login inicial, un usuario debería probar su identidad a los servicios sin volver a enviar nunca su contraseña — en su lugar presenta tickets criptográficos emitidos por un tercero de confianza.

El tercero de confianza es el Key Distribution Center (KDC) — en AD, cada controlador de dominio — que tiene dos funciones: el Authentication Service (AS) y el Ticket-Granting Service (TGS). El flujo tiene tres actos:

sequenceDiagram
  accTitle: El flujo de tickets de Kerberos
  accDescr: En el login el cliente envía una solicitud de autenticación al Authentication Service del Key Distribution Center, que devuelve un ticket-granting ticket (TGT) cifrado para que solo el cliente y el KDC puedan usarlo. Cuando el cliente quiere un servicio específico, envía el TGT al Ticket-Granting Service, que devuelve un ticket de servicio para ese único servicio. El cliente luego presenta el ticket de servicio al servicio destino, que lo valida y otorga acceso. La contraseña del usuario solo se usa en el primer paso y nunca viaja por la red.
  actor U as Cliente (usuario)
  participant AS as KDC — Authentication Service
  participant TGS as KDC — Ticket-Granting Service
  participant S as Servicio destino
  U->>AS: 1. Solicitud de login (AS-REQ)
  AS->>U: Ticket-Granting Ticket (TGT)
  U->>TGS: 2. TGT + "quiero el servicio X"
  TGS->>U: Ticket de servicio para X
  U->>S: 3. Presenta el ticket de servicio
  S->>U: Acceso otorgado (auth mutua)

Lectura: en el login el cliente obtiene un Ticket-Granting Ticket (TGT) del AS. Para alcanzar un servicio específico, presenta el TGT al TGS y recibe un ticket de servicio acotado a ese único servicio. Se lo entrega al servicio, que lo valida — y puede autenticarse mutuamente de vuelta. La contraseña solo se usa para arrancar el TGT y nunca viaja por la red, que es la propiedad de seguridad insignia de Kerberos. Los tickets son de tiempo limitado (de ahí la notoria sensibilidad de Kerberos al clock skew — las máquinas deben coincidir en la hora dentro de unos minutos).

Las organizaciones se agrupan en realms (un dominio de AD es un realm de Kerberos), y la confianza entre realms permite que los tickets funcionen entre dominios. El hermano más viejo de Kerberos, NTLM, es el protocolo de desafío-respuesta al que AD recurre cuando no se puede usar Kerberos — y es un pasivo: NTLM es vulnerable a ataques de relay y pass-the-hash, así que endurecer un estado Windows consiste en gran medida en bajar NTLM y subir Kerberos.

Delegación y sus peligros

Una función sutil y poderosa de Kerberos es la delegación — permitir que un servicio actúe en nombre del usuario hacia un servicio posterior (una app web que alcanza una base de datos como el usuario logueado). Útil, pero históricamente riesgosa: la delegación no restringida deja que un servicio comprometido suplante usuarios ampliamente, por lo que el AD moderno usa delegación constrained y basada en recursos para acotarla. Los ataques de Kerberos que vimos en servicios de directorio — Kerberoasting (crackear tickets de cuentas de servicio offline) y el Golden Ticket (forjar TGTs con la llave maestra del dominio) — son abusos de exactamente esta maquinaria de tickets. Por eso proteger el KDC (los controladores de dominio) y minimizar la delegación es primordial: posee el sistema de tickets y posees el realm.

RADIUS: el guardián de la red

Cuando te unes a un Wi-Fi corporativo o conectas una VPN, el protocolo que te autentica casi seguramente es RADIUS (Remote Authentication Dial-In User Service, RFC 2865). Data de la era del dial-up — el nombre todavía dice “Dial-In” — pero se volvió la columna vertebral del control de acceso a la red moderno.

El modelo tiene tres partes: el supplicant (tu laptop o teléfono), el dispositivo de acceso a la red o NAS (el controlador Wi-Fi, switch o concentrador VPN) y el servidor RADIUS. El dispositivo no decide quién entra a la red — reenvía la pregunta al servidor RADIUS central, que autentica al usuario (muy a menudo contra Active Directory o LDAP detrás) y responde aceptar o rechazar.

sequenceDiagram
  accTitle: Autenticación RADIUS para acceso a la red (802.1X)
  accDescr: Un supplicant como una laptop intenta unirse a una red Wi-Fi corporativa. El punto de acceso, actuando como dispositivo de acceso a la red, solicita la identidad del usuario y la reenvía como un Access-Request de RADIUS al servidor RADIUS central. El servidor puede emitir un Access-Challenge al que el supplicant responde, luego valida las credenciales, frecuentemente contra Active Directory o LDAP, y devuelve un Access-Accept o un Access-Reject. El punto de acceso aplica esa decisión otorgando o denegando el acceso a la red.
  actor U as Supplicant (dispositivo)
  participant NAS as Punto de acceso / NAS
  participant R as Servidor RADIUS
  participant D as AD / LDAP
  U->>NAS: Conectar (802.1X / EAP)
  NAS->>R: Access-Request (credenciales)
  R->>D: Verificar identidad
  D->>R: OK
  R->>NAS: Access-Accept (o Reject)
  NAS->>U: Acceso a la red otorgado / denegado

EAP: los métodos por dentro

El intercambio real de credenciales en 802.1X viaja dentro de EAP (Extensible Authentication Protocol), y qué método EAP esté configurado determina la seguridad real:

• EAP-TLS — certificados mutuos en ambos lados; el más fuerte y cada vez más el estándar para dispositivos gestionados (sin contraseña que phishear).
• PEAP / EAP-TTLS — un túnel TLS que protege un intercambio interno basado en contraseña, a menudo validado contra AD; común pero solo tan fuerte como la contraseña.
• EAP-TLS con certificados de dispositivo — ata el acceso a la red a un dispositivo gestionado, un control silencioso pero poderoso.

RADIUS es también el origen histórico del modelo AAA — Autenticación, Autorización y Accounting — que vimos en los pilares IAAA. Su primo TACACS+ (RFC 8907) cumple un rol similar para la administración de dispositivos de red (común en entornos Cisco), con la diferencia de que separa las tres A más limpiamente y cifra todo el payload. La conclusión: los protocolos que deciden quién entra a la red siquiera son una capa distinta debajo de la federación a nivel de app — y RADIUS la posee.

WS-Federation y WS-Trust: los veteranos de la era SOAP

Antes de que la federación por redirección de navegador de SAML se impusiera del todo, y junto a ella en la empresa, vivía una familia de estándares de identidad basados en SOAP/XML: WS-Trust y WS-Federation (parte del stack WS-* más amplio). Resuelven el mismo problema fundamental que SAML — federar identidad a través de fronteras de confianza — pero en el mundo más pesado de envoltorios y namespaces de los servicios web SOAP.

El concepto central es el Security Token Service (STS): un emisor de confianza que acuña y valida tokens de seguridad. WS-Trust define el protocolo para solicitar, emitir, renovar y validar esos tokens; WS-Federation construye la federación entre organizaciones encima. Si eso suena al IdP de SAML emitiendo assertions, lo es — la misma idea, plomería distinta y más torpe.

¿Por qué aprenderlos? Porque son legacy pero no muertos. Grandes estados construidos sobre SAP, Oracle y el viejo Microsoft ADFS todavía hablan WS-Federation y WS-Trust, y cuando integres identidad en uno de esos sistemas los encontrarás. El marco honesto: nadie arranca un proyecto nuevo en WS-*, pero muchos sistemas empresariales críticos para el negocio todavía corren sobre él, y “legacy” en identidad significa “load-bearing e irreemplazable por ahora”.

Concretamente, encontrarás WS-* el día que te pidan conectar una app moderna OIDC a un sistema socio o interno más viejo que solo habla WS-Federation. La respuesta usual es un gateway que traduce protocolos — muchos IdP traducen entre WS-Fed, SAML y OIDC — dejando que el sistema legacy conserve su protocolo mientras la app nueva habla el suyo. La noción subyacente, la identidad basada en claims emitida por un STS, es exactamente la misma idea que SAML y OIDC expresan más simplemente; WS-* solo la envuelve en sobres SOAP. Reconoce el modelo y el SOAP es solo empaque desconocido.

FIDO2 / WebAuthn / CTAP: la vanguardia

Ahora el futuro. FIDO2 es el estándar que por fin vuelve la autenticación resistente a phishing al abandonar por completo el secreto compartido. En lugar de una contraseña (o incluso un OTP) que puede ser phisheada, reenviada o filtrada, FIDO2 usa criptografía de clave pública: el autenticador guarda una clave privada que nunca lo abandona, y registra una clave pública con el servicio. El login es un desafío firmado — y como la firma está atada al origen del sitio real, un sitio de phishing simplemente no puede producir una válida.

FIDO2 son en realidad dos especificaciones trabajando juntas:

• WebAuthn — una API de navegador estándar de W3C que el relying party (sitio web) llama para registrar y autenticar credenciales.
• CTAP (Client to Authenticator Protocol) — cómo el navegador/cliente habla con el autenticador: una llave de seguridad roaming (YubiKey) por USB/NFC/Bluetooth, o un autenticador de plataforma (el sensor biométrico de tu teléfono o laptop).

Juntos son lo que hace funcionar las passkeys — las credenciales sincronizadas y resistentes a phishing que presentamos en factores de autenticación. Esta es la genuina vanguardia: la primera tecnología de autenticación con una afirmación creíble de terminar el phishing de contraseñas a escala.

La propiedad que le gana la palabra “resistente a phishing” es el origin binding (atadura al origen). Cuando el autenticador firma el desafío de login, la firma queda atada criptográficamente al origen del sitio real (su dominio). Un sitio de phishing imitador en un origen distinto simplemente no puede obtener una firma usable — no hay secreto que el usuario pueda entregar por error, porque la clave privada nunca abandona el autenticador y la firma no validará para el origen equivocado. Es una mejora categórica sobre contraseñas e incluso OTPs, que un sitio falso convincente puede cosechar. Solo lo previsualizamos aquí; el módulo de autenticación disecciona las ceremonias de registro y autenticación de WebAuthn, la atestación y la UX de passkeys en profundidad. Por ahora, colócalo en tu mapa como el estándar hacia el que toda la industria está migrando.

Una nota sobre mTLS y certificados de cliente

Un veterano más que vale la pena mencionar, porque nunca se fue del todo: mutual TLS (mTLS) con certificados de cliente X.509. La mayoría de TLS autentica solo el servidor ante el cliente; mTLS agrega lo inverso — el cliente presenta un certificado que prueba su identidad también. Es pesado de gestionar (cada cliente necesita un certificado y una forma de renovarlo) pero extremadamente fuerte, así que persiste en entornos de alto aseguramiento: smart cards de gobierno y militares, APIs B2B reguladas y — cada vez más — autenticación máquina-a-máquina dentro de service meshes, que veremos en el próximo artículo. La identidad basada en certificados es vieja, pero la idea de clave pública debajo de ella es exactamente lo que FIDO2 moderniza para humanos.

Cómo se conectan los veteranos con el stack moderno

Estos protocolos no son islas aisladas — se entrelazan con el mundo OIDC/SAML, normalmente a través del directorio:

• Comparten una fuente de verdad. Un servidor RADIUS autenticando Wi-Fi, un KDC Kerberos emitiendo tickets, y un IdP SAML/OIDC emitiendo tokens frecuentemente leen todos el mismo Active Directory. El directorio es el hub; cada protocolo es una puerta distinta hacia las mismas identidades.
• Kerberos hace de puente a la web. La “Windows Integrated Authentication” deja que una sesión de escritorio autenticada por Kerberos fluya hacia el navegador, y un IdP puede aceptar ese login Kerberos y acuñar un token SAML u OIDC a partir de él — SSO fluido desde el escritorio unido al dominio hasta una app cloud.
• FIDO2 se enchufa a OIDC/SAML. WebAuthn suele ser el método de autenticación que usa un IdP, no un reemplazo de la federación: el usuario se autentica ante el IdP con una passkey, y el IdP igual emite el ID token de OIDC. Autenticación de vanguardia y federación moderna trabajando juntas.

El modelo mental que ata todo el módulo: el directorio es el hub, y los protocolos son los rayos — Kerberos para redes Windows, RADIUS para acceso a la red, WS-* para estados SOAP, SAML/OIDC para federación web, SCIM para aprovisionamiento, FIDO2 para login resistente a phishing — muy a menudo todos girando en torno a las mismas identidades.

Diagnosticar a los veteranos

Estos protocolos fallan de maneras características, y reconocer el síntoma es la mitad de arreglarlo:

• Kerberos: clock skew y SPNs. Los tickets llevan marca de tiempo, así que si el reloj de una máquina se desvía más de unos minutos del KDC, la autenticación falla en silencio — “funcionaba ayer” tras un cambio de hora es un clásico. El otro tropiezo de Kerberos es un Service Principal Name (SPN) faltante o duplicado, que rompe la capacidad del TGS de emitir un ticket de servicio.
• RADIUS: el secreto compartido. El NAS y el servidor RADIUS se autentican entre sí con un secreto compartido; una discrepancia (un typo, un valor sin rotar) produce rechazos silenciosos que parecen “contraseña incorrecta” pero no lo son.
• NTLM reapareciendo. Las apps que alcanzan un servidor por IP en lugar de hostname, o con un SPN faltante, recurren en silencio de Kerberos a NTLM — por lo que “deshabilitamos NTLM y las cosas se rompieron” es tan común. Encuentra los fallbacks antes de apagarlo.
• WS-*: vencimiento de certificados. Como SAML, los veteranos SOAP se rompen cuando un certificado de firma o del token service caduca — una caída que llega en un calendario que olvidaste llevar.

La meta-lección: cada veterano tiene un pequeño conjunto de modos de fallo bien conocidos, y unos minutos reconociendo la categoría de fallo le ganan a horas adivinando. Empareja el síntoma — un cambio de hora, una conexión por IP-en-vez-de-hostname, un secreto compartido rotado, un certificado vencido — con el protocolo, y el arreglo suele seguir en minutos. Es justo por esto que conocer a los veteranos importa incluso en un mundo OIDC-first: tú serás quien los depure a las 2 de la mañana.

El panorama de un vistazo

Una línea de tiempo rápida de cómo se acumularon estas capas — cada estándar nuevo apilándose sobre los anteriores, ninguno borrando del todo a sus predecesores:

timeline
  accTitle: Eras de los protocolos de identidad y acceso
  accDescr: Una línea de tiempo de las eras de los protocolos de identidad. En los años 80, Kerberos introdujo la autenticación basada en tickets. En los 90, RADIUS trajo el control de acceso a la red, NTLM manejó el desafío-respuesta de Windows, y mTLS con X.509 habilitó la autenticación mutua basada en certificados. En los 2000, los estándares basados en SOAP WS-Trust y WS-Federation habilitaron la federación empresarial, y SAML trajo el single sign-on web. En los 2010, OAuth, OpenID Connect y SCIM definieron el stack moderno de la era de las APIs. De 2018 en adelante, FIDO2, WebAuthn y CTAP trajeron autenticación de clave pública resistente a phishing y passkeys.
  1980s : Kerberos (tickets)
  1990s : RADIUS (acceso a la red) : NTLM (Windows) : mTLS / X.509
  2000s : WS-Trust / WS-Federation : SAML web SSO
  2010s : OAuth 2.0 / OIDC / SCIM
  2018+ : FIDO2 / WebAuthn / CTAP (passkeys)

La forma de la tabla es la lección: la identidad está estratificada por era. Los estándares más nuevos no borran los viejos; se apilan encima, y una empresa que funciona corre todas las capas a la vez. Tu trabajo es saber sobre qué capa estás parado en cada momento.

Recapitulación

Más allá del stack de federación central, cuatro familias de protocolos que encontrarás en el campo:

1. Kerberos — auth basada en tickets (TGT → ticket de servicio) detrás de cada login de AD; la contraseña nunca cruza la red; protege el KDC, y baja su fallback inseguro NTLM.
2. RADIUS — el guardián del acceso a la red (Wi-Fi, VPN, 802.1X), reenviando la auth a un servidor central, a menudo respaldado por AD; el origen del modelo AAA.
3. WS-Federation / WS-Trust — federación de la era SOAP vía un Security Token Service; legacy pero aún load-bearing en SAP, Oracle y ADFS viejo.
4. FIDO2 / WebAuthn / CTAP — la vanguardia de clave pública resistente a phishing que impulsa las passkeys, resistente porque la firma está atada al origen real del sitio; cubierta en profundidad en el módulo de autenticación.
5. mTLS / X.509 — auth mutua fuerte basada en certificados, persistente en entornos de alto aseguramiento y máquina-a-máquina.
6. La identidad está estratificada por era — los estándares nuevos se apilan sobre los veteranos en lugar de reemplazarlos; los entornos reales corren todas las capas a la vez, muy a menudo girando en torno a un directorio compartido. “Modernizar” la identidad es arqueología aditiva, no demolición — por lo que debes conocer a los veteranos incluso en un mundo OIDC-first.

Ejercicios prácticos

Estos son prácticos — hazlos, no solo los leas:

1. Encuentra Kerberos en la práctica. En una máquina Windows unida al dominio, corre klist en una terminal y lee tus tickets en caché — identifica tu TGT y cualquier ticket de servicio, y nota sus vidas. (¿Sin Windows? Describe qué esperarías ver y por qué el TGT es especial.)
2. Rastrea la decisión del Wi-Fi (caso de uso). Esboza qué ocurre, protocolo por protocolo, cuando tu laptop se une a una red WPA2-Enterprise — nombra el supplicant, el NAS, el servidor RADIUS y el directorio detrás, y di cuál de ellos toma realmente la decisión de aceptar/rechazar.
3. Detecta al veterano (caso de uso). Para cada uno, nombra el protocolo que probablemente hace el trabajo: abrir un recurso compartido on-prem tras el login de Windows; conectar la VPN corporativa; iniciar sesión en un portal viejo integrado con SAP; entrar a una app web nueva con una passkey.
4. Haz el caso de NTLM (caso de uso). Tu equipo de seguridad quiere deshabilitar NTLM. Explica por qué (los ataques), qué se rompería, y cómo migrarías hacia solo-Kerberos de forma segura.
5. Argumenta la migración (caso de uso). Un CISO pregunta “si FIDO2 es resistente a phishing, ¿por qué seguimos corriendo Kerberos y RADIUS?”. Da la respuesta honesta de dos párrafos sobre capas, base instalada, y qué reemplaza y qué no reemplaza FIDO2.
6. Diagnostica la caída (caso de uso). Tras un cambio de horario de verano, los usuarios de un sitio no pueden autenticarse a los servicios internos, mientras que el SSO web sigue funcionando bien. Nombra el protocolo más probablemente culpable y la causa específica, y explica por qué solo se rompieron los servicios internos.

Tres preguntas para autoevaluarte

1. Explica cómo Kerberos permite a un usuario autenticarse a una docena de servicios tras un solo login sin reenviar su contraseña, nombrando el TGT y el ticket de servicio.
2. En un login Wi-Fi 802.1X, ¿qué componente aplica la decisión de acceso y cuál la toma — y por qué es útil esa separación?
3. ¿Por qué se describe a WS-Federation como “legacy pero load-bearing”, y cuál es el riesgo de asumir que puedes ignorarlo al modernizar la identidad de una empresa?