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

Cinco protocolos antes del café

La primera semana de Daniel en el equipo de seguridad empieza a las 8:40. Abre el portátil y lo desbloquea con su contraseña del dominio. La wifi de la oficina se conecta sola. Abre una hoja de cálculo de la unidad compartida, entra en el viejo portal de compras que Finanzas sigue usando y, por último, inicia sesión en una herramienta SaaS nueva con una passkey del móvil. Nada de eso le pareció tecnología distinta. Fueron cinco protocolos diferentes, y solo el último tiene que ver con lo que llevamos visto en este módulo.

Hemos dedicado casi todo el tiempo a la pila moderna de federación y aprovisionamiento: servicios de directorio, SAML, OAuth, OIDC, SCIM. Pero una empresa real funciona con una colección más amplia de protocolos que hacen trabajo crítico sin hacer ruido. Algunos son veteranos, con décadas encima y nada vistosos, que siguen sosteniendo millones de inicios de sesión al día. Uno es la vanguardia, el futuro resistente al phishing que de verdad está sustituyendo a las contraseñas. El protocolo más nuevo de la diapositiva de arquitectura casi nunca es el que más peso aguanta en producción, y no se puede proteger ni depurar un entorno ignorando lo que lo sostiene.

Este artículo recorre los de la mañana de Daniel. Kerberos desbloqueó el portátil y abrió la unidad compartida. RADIUS lo dejó entrar en la wifi. WS-Federation le abrió el portal de compras. Y FIDO2, con WebAuthn y CTAP, estaba detrás de la passkey.

Kerberos: el sistema de tickets debajo de cada inicio de sesión de AD

Kerberos (RFC 4120) es un protocolo de autenticación basado en tickets que nació en el MIT en los años 80, y es el corazón de la autenticación de Active Directory. Su idea central es que, después del primer inicio de sesión, el usuario debería poder demostrar quién es ante los servicios sin volver a mandar nunca la contraseña. En su lugar presenta tickets criptográficos emitidos por un tercero de confianza.

Ese tercero es el Key Distribution Center (KDC), que en Active Directory es cada controlador de dominio. Tiene dos funciones, el Authentication Service (AS) y el Ticket-Granting Service (TGS), y el flujo ocurre en tres actos.

sequenceDiagram
  accTitle: El flujo de tickets de Kerberos
  accDescr: Al iniciar sesión, 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 concreto, envía el TGT al Ticket-Granting Service, que devuelve un ticket de servicio solo para ese servicio. Después el cliente presenta el ticket de servicio al servicio de destino, que lo valida y concede el 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 (AS)
  participant TGS as KDC (TGS)
  participant S as Servicio
  U->>AS: 1. Solicitud de inicio de sesión (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 concedido (autenticación mutua)

Cuando Daniel desbloqueó el portátil, el cliente obtuvo un Ticket-Granting Ticket (TGT) del AS. Cuando abrió la unidad compartida, el cliente enseñó el TGT al TGS y recibió un ticket de servicio válido solo para ese servidor de ficheros, y luego se lo entregó al servidor, que lo comprobó y pudo autenticarse a su vez ante él. La contraseña solo sirvió para conseguir el TGT y nunca viajó por la red, que es la propiedad de seguridad que define a Kerberos. Los tickets caducan, y de ahí su famosa sensibilidad a las diferencias de reloj: las máquinas tienen que coincidir en la hora con un margen de pocos minutos.

Las organizaciones se agrupan en reinos (realms; un dominio de Active Directory es un reino de Kerberos), y las relaciones de confianza entre reinos permiten que los tickets funcionen entre dominios. El hermano mayor de Kerberos, NTLM, es el protocolo de desafío y respuesta al que recurre Active Directory cuando Kerberos no se puede usar, y es un lastre. NTLM es vulnerable a ataques de relay y pass-the-hash, así que endurecer un entorno Windows consiste en buena parte en bajar NTLM y subir Kerberos.

La delegación y sus peligros

Una función sutil y potente de Kerberos es la delegación: permitir que un servicio actúe en nombre del usuario ante otro servicio, como una app web que llega a una base de datos como el usuario que ha iniciado sesión. Es útil y ha sido arriesgada. La delegación sin restricciones permite a un servicio comprometido suplantar a usuarios a lo grande, y por eso el Active Directory moderno usa delegación restringida y basada en recursos para acotarla. Los ataques a Kerberos que vimos en servicios de directorio, el Kerberoasting, que rompe sin conexión los tickets de cuentas de servicio, y el Golden Ticket, que falsifica TGT con la clave maestra del dominio, abusan justo de esta maquinaria de tickets. Proteger el KDC, es decir, los controladores de dominio, y reducir la delegación al mínimo va primero: quien controla el sistema de tickets controla el reino.

RADIUS: el portero de la red

Cuando te conectas a la wifi corporativa o a una VPN, el protocolo que te autentica es casi seguro RADIUS (Remote Authentication Dial-In User Service, RFC 2865). Viene de la época de los módems, como delata el “Dial-In” del nombre, pero se convirtió en la columna vertebral del control de acceso a la red moderno.

Hay tres partes: el suplicante (supplicant), que es el portátil o el móvil de Daniel; el dispositivo de acceso a la red o NAS, que es el controlador wifi, el switch o el concentrador VPN; y el servidor RADIUS. El dispositivo de acceso no decide quién entra en la red. Le pasa la pregunta al servidor RADIUS central, que autentica al usuario, muy a menudo contra el Active Directory o el LDAP que tiene detrás, y responde aceptar o rechazar.

sequenceDiagram
  accTitle: Autenticación RADIUS para el acceso a la red (802.1X)
  accDescr: Un suplicante, como un portátil, intenta conectarse a una red wifi corporativa. El punto de acceso, que hace de dispositivo de acceso a la red, pide la identidad del usuario y la reenvía como un Access-Request de RADIUS al servidor RADIUS central. El servidor puede enviar un Access-Challenge al que el suplicante responde, después valida las credenciales, a menudo contra Active Directory o LDAP, y devuelve un Access-Accept o un Access-Reject. El punto de acceso aplica esa decisión concediendo o denegando el acceso a la red.
  actor U as Suplicante (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 concedido / denegado

EAP: los métodos de dentro

En 802.1X, el intercambio real de credenciales viaja dentro de EAP (Extensible Authentication Protocol), y el método EAP que configures decide lo seguro que es de verdad. EAP-TLS usa certificados en ambos lados. Es la opción más fuerte y cada vez más el estándar para equipos gestionados, porque no hay contraseña que robar, y cuando los certificados se emiten a dispositivos ata en silencio el acceso a la red al hardware gestionado por la empresa. PEAP y EAP-TTLS montan un túnel TLS que protege un intercambio interno basado en contraseña, normalmente comprobado contra Active Directory. Son habituales, pero solo tan fuertes como la contraseña.

RADIUS es también el origen del modelo AAA, autenticación, autorización y registro (accounting), que vimos en los pilares IAAA. Su primo TACACS+ (RFC 8907) cumple un papel parecido en la administración de equipos de red, muy común en entornos Cisco, con la diferencia de que separa mejor las tres A y cifra todo el contenido. Los protocolos que deciden quién entra en la red forman su propia capa por debajo de la federación de aplicaciones, y esa capa es de RADIUS.

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

Antes de que la federación por redirecciones de SAML se impusiera, y a su lado en la empresa, existió una familia de estándares de identidad basados en SOAP y XML: WS-Trust y WS-Federation, parte de la pila WS-*. Resuelven el mismo problema de fondo que SAML, federar la identidad entre fronteras de confianza, pero en el mundo más pesado de los servicios web SOAP, con sus sobres y sus espacios de nombres.

El concepto central es el Security Token Service (STS), un emisor de confianza que fabrica y valida tokens de seguridad. WS-Trust define el protocolo para pedir, emitir, renovar y validar esos tokens, y WS-Federation monta encima la federación entre organizaciones. Si te recuerda a un proveedor de identidad SAML emitiendo aserciones, es que lo es: la misma idea con una fontanería distinta y más torpe. La noción de fondo, la identidad basada en claims emitida por un STS, es exactamente lo que SAML y OIDC expresan de forma más sencilla.

Merece la pena conocerlos porque son heredados sin estar muertos. Los grandes entornos montados sobre SAP, Oracle y despliegues antiguos de ADFS de Microsoft siguen hablando WS-Federation y WS-Trust, y el portal de compras en el que entró Daniel es uno de ellos. Nadie empieza un proyecto nuevo con WS-*, pero muchos sistemas de los que depende el negocio siguen funcionando con él. Te lo encontrarás el día que te pidan conectar una app OIDC moderna con un socio o un sistema interno antiguo que solo habla WS-Federation. La respuesta habitual es una pasarela que traduce protocolos. Muchos proveedores de identidad traducen entre WS-Fed, SAML y OIDC, así que el sistema heredado mantiene su protocolo y la app nueva habla el suyo.

Kerberos, RADIUS y WS-* tienen algo en común: los tres son anteriores a la era web y móvil, y los tres siguen estando en todas partes dentro de su terreno, las redes Windows, el acceso a la red y el SOAP empresarial. Los sistemas nuevos tiran de OIDC y FIDO2, pero la base instalada de veteranos es enorme, y sustituirla es una migración de años, no un interruptor.

FIDO2, WebAuthn y CTAP: la vanguardia

Ahora, el futuro. FIDO2 es el estándar que por fin hace la autenticación resistente al phishing, porque abandona por completo el secreto compartido. En lugar de una contraseña, o incluso de un código de un solo uso, que se pueden robar, reenviar o filtrar, FIDO2 usa criptografía de clave pública. El autenticador guarda una clave privada que nunca sale de él y registra una clave pública en el servicio. Iniciar sesión es firmar un desafío, y como la firma está atada al origen real de la web, un sitio de phishing no puede conseguir una válida.

FIDO2 son en realidad dos especificaciones que trabajan juntas. WebAuthn es una API de navegador, estándar del W3C, a la que llama la web para registrar y usar credenciales. CTAP (Client to Authenticator Protocol) es cómo habla el navegador con el autenticador: una llave de seguridad itinerante como una YubiKey, por USB, NFC o Bluetooth, o un autenticador de plataforma como el sensor biométrico del móvil o del portátil. Juntos hacen funcionar las passkeys, las credenciales sincronizadas y resistentes al phishing que presentamos en factores de autenticación, y la primera tecnología de autenticación que puede aspirar en serio a acabar con el phishing de contraseñas a gran escala.

Lo que le gana la etiqueta de “resistente al phishing” es la vinculación al origen. Cuando el autenticador firma el desafío del inicio de sesión, la firma queda atada criptográficamente al origen real de la web, su dominio. Una web imitación en otro origen no puede obtener una firma que sirva. No hay ningún secreto que el usuario pueda entregar por error, porque la clave privada nunca sale del autenticador y la firma no valida para el origen equivocado. Es una diferencia de naturaleza frente a las contraseñas e incluso frente a los códigos de un solo uso, que una web falsa convincente puede recoger. Esto es solo un adelanto; el módulo de autenticación desmonta en detalle las ceremonias de registro y autenticación de WebAuthn, la atestación y la experiencia de las passkeys.

Unas palabras sobre mTLS y los certificados de cliente

Hay otro veterano que merece mención porque nunca se fue del todo: el TLS mutuo (mTLS) con certificados de cliente X.509. El TLS normal solo autentica al servidor ante el cliente; mTLS añade lo contrario, y el cliente presenta un certificado que demuestra su propia identidad. Es pesado de gestionar, porque cada cliente necesita un certificado y una forma de renovarlo, pero muy fuerte, así que sobrevive en entornos de alta exigencia: tarjetas inteligentes de la administración y del ejército, APIs B2B reguladas y, cada vez más, la autenticación entre máquinas dentro de las service mesh, que saldrá en los próximos artículos. La identidad basada en certificados es antigua, pero la idea de clave pública que tiene debajo es justo lo que FIDO2 moderniza para las personas.

Cómo conectan los veteranos con la pila moderna

Estos protocolos no son islas. Encajan con el mundo de OIDC y SAML, normalmente a través del directorio.

En la empresa de Daniel, el servidor RADIUS que comprueba los accesos a la wifi, el KDC de Kerberos que emite tickets y el proveedor de identidad que emite tokens SAML y OIDC leen el mismo Active Directory. El directorio es el centro, y cada protocolo es una puerta distinta a las mismas identidades. Kerberos además tiende un puente a la web: la “autenticación integrada de Windows” permite que una sesión de escritorio autenticada con Kerberos pase al navegador, y un proveedor de identidad puede aceptar ese inicio de sesión de Kerberos y fabricar a partir de él un token SAML u OIDC, con un SSO sin costuras desde el escritorio unido al dominio hasta una app en la nube. Y FIDO2 se enchufa a OIDC y SAML en lugar de sustituirlos. WebAuthn suele ser el método con el que el proveedor de identidad autentica a la persona: Daniel entra en el proveedor de identidad con su passkey, y el proveedor de identidad sigue emitiendo el ID token de OIDC para la app.

Así que imagina el directorio como el eje y los protocolos como radios: Kerberos para las redes Windows, RADIUS para el acceso a la red, WS-* para los entornos SOAP, SAML y OIDC para la federación web, SCIM para el aprovisionamiento y FIDO2 para el inicio de sesión resistente al phishing, muchas veces girando alrededor de las mismas identidades.

Cuando los veteranos fallan

Estos protocolos fallan de maneras reconocibles, y detectar el síntoma es media solución.

Kerberos falla por el desfase de reloj y por los SPN. Los tickets llevan marcas de tiempo, así que si el reloj de una máquina se desvía más de unos minutos respecto al KDC, la autenticación falla sin un mensaje claro. “Ayer funcionaba” justo después de un cambio de hora es un clásico. La otra trampa de Kerberos es un Service Principal Name (SPN) que falta o está duplicado, lo que impide al TGS emitir el ticket de servicio. RADIUS falla por el secreto compartido: el dispositivo de acceso y el servidor RADIUS se autentican entre sí con uno, y un desajuste, una errata o un valor que alguien olvidó rotar, produce rechazos silenciosos que parecen una contraseña incorrecta y no lo son. NTLM vuelve a colarse cuando las apps llegan a un servidor por dirección IP en lugar de por nombre, o cuando falta un SPN, y caen sin avisar de Kerberos a NTLM, y por eso “desactivamos NTLM y se rompieron cosas” es una historia tan repetida. Encuentra esos retrocesos antes de apagarlo. Y como SAML, los veteranos WS-* se rompen cuando caduca un certificado de firma o del servicio de tokens, una caída que llega en una fecha que nadie tenía en el calendario.

Cada veterano tiene una lista corta de fallos conocidos, y unos minutos identificando la categoría valen más que horas adivinando. Relaciona el síntoma con el protocolo, un cambio de hora, una conexión por IP, un secreto compartido rotado, un certificado caducado, y el arreglo suele llegar rápido. Por eso los veteranos importan incluso en una empresa que se considera “OIDC primero”: alguien tiene que depurarlos a las dos de la mañana.

Las capas por épocas

Cada estándar se apiló sobre los anteriores, y ninguno borró del todo a sus predecesores.

timeline
  accTitle: Épocas de los protocolos de identidad y acceso
  accDescr: Una línea de tiempo de las épocas 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 se encargó del desafío y respuesta de Windows, y mTLS con X.509 permitió la autenticación mutua basada en certificados. En los 2000, los estándares SOAP WS-Trust y WS-Federation permitieron la federación empresarial, y SAML trajo el inicio de sesión único web. En los 2010, OAuth, OpenID Connect y SCIM definieron la pila moderna de la era de las APIs. Desde 2018, FIDO2, WebAuthn y CTAP trajeron la autenticación de clave pública resistente al phishing y las 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. Los estándares nuevos no borran a los viejos; se apilan encima, y una empresa en marcha usa todas las capas a la vez, como mostró la mañana de Daniel. Parte del oficio consiste siempre en saber en qué capa estás pisando.

Resumen

Más allá de la pila principal de federación, estas son las familias de protocolos que te encontrarás sobre el terreno.

1. Kerberos da autenticación basada en tickets (TGT y después ticket de servicio) detrás de cada inicio de sesión de Active Directory. La contraseña nunca cruza la red. Protege el KDC y reduce su respaldo inseguro, NTLM.
2. RADIUS vigila el acceso a la red (wifi, VPN, 802.1X) reenviando la autenticación a un servidor central, a menudo respaldado por Active Directory. De ahí viene el modelo AAA.
3. WS-Federation y WS-Trust dan federación de la era SOAP mediante un Security Token Service. Son heredados, pero siguen siendo imprescindibles en SAP, Oracle y ADFS antiguos.
4. FIDO2, WebAuthn y CTAP son la vanguardia de clave pública y resistente al phishing detrás de las passkeys, resistente porque la firma está atada al origen real de la web.
5. mTLS con certificados X.509 es una autenticación mutua fuerte que se mantiene en entornos de alta exigencia y entre máquinas.
6. La identidad se organiza en capas por épocas. Los estándares nuevos se colocan encima de los veteranos en lugar de sustituirlos, y los entornos reales usan todas las capas a la vez, muchas veces alrededor de un único directorio.

Ejercicios prácticos

Están pensados para hacerse, no solo para leerse.

1. Encuentra Kerberos en vivo. En un equipo Windows unido al dominio, ejecuta klist en una terminal y lee tus tickets en caché. Identifica tu TGT y los tickets de servicio, y anota cuánto duran. Si no tienes Windows, describe qué esperarías ver y por qué el TGT es especial.
2. Sigue la decisión de la wifi. Dibuja, protocolo a protocolo, qué pasa cuando tu portátil se conecta a una red WPA2-Enterprise. Nombra el suplicante, el NAS, el servidor RADIUS y el directorio que hay detrás, y di cuál de ellos decide de verdad aceptar o rechazar.
3. Localiza al veterano. Di qué protocolo es más probable que esté trabajando en cada caso: abrir una carpeta compartida local después de iniciar sesión en Windows; conectarte a la VPN corporativa; entrar en un portal antiguo integrado con SAP; iniciar sesión en una app web nueva con una passkey.
4. Argumenta contra NTLM. Tu equipo de seguridad quiere desactivar NTLM. Explica por qué (los ataques), qué se rompería y cómo avanzarías con seguridad hacia solo Kerberos.
5. Responde al CISO. Un CISO pregunta: “Si FIDO2 es resistente al phishing, ¿por qué seguimos con Kerberos y RADIUS?”. Escribe la respuesta honesta en dos párrafos sobre las capas, la base instalada y lo que FIDO2 sustituye y lo que no.
6. Diagnostica la caída. Tras el cambio al horario de verano, los usuarios de una sede no pueden autenticarse en los servicios internos, mientras que el SSO web sigue funcionando. Nombra el protocolo más probable y la causa concreta, y explica por qué solo se rompieron los servicios internos.

Tres preguntas para ponerte a prueba

1. Explica cómo Kerberos permite a un usuario llegar a una docena de servicios con un solo inicio de sesión sin volver a mandar la contraseña, nombrando el TGT y el ticket de servicio.
2. En un inicio de sesión wifi con 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 dice que WS-Federation es heredado pero todavía imprescindible, y qué riesgo hay en dar por hecho que puedes ignorarlo al modernizar la identidad de una empresa?