The veterans and the vanguard: Kerberos, RADIUS, WS-*, and FIDO2

Five protocols before coffee

Daniel’s first week on the security team starts at 8:40. He opens his laptop and unlocks it with his domain password. The office Wi-Fi connects on its own. He opens a spreadsheet on the shared drive, then signs in to the old procurement portal that finance still uses, and finally logs into a new SaaS tool with a passkey on his phone. None of that felt like five different technologies. It was five different protocols, and only the last one is anything this module has covered so far.

We’ve spent most of our time on the modern federation and provisioning stack: directory services, SAML, OAuth, OIDC, SCIM. But a real company runs a wider collection of protocols that quietly do critical work. Some are veterans, decades old and unglamorous, still holding up millions of sign-ins a day. One is the vanguard, the phishing-resistant future that’s actually replacing passwords. The newest protocol on the architecture slide is rarely the one carrying the most weight in production, and you can’t secure or troubleshoot an environment while ignoring what holds it up.

This article tours the ones from Daniel’s morning. Kerberos unlocked the laptop and opened the shared drive. RADIUS let it onto the Wi-Fi. WS-Federation signed him in to the procurement portal. And FIDO2, with WebAuthn and CTAP, sat behind the passkey.

Kerberos: the ticket system under every AD sign-in

Kerberos (RFC 4120) is a ticket-based authentication protocol born at MIT in the 1980s, and it’s the heart of Active Directory authentication. Its central idea is that after the first sign-in, a user should prove who they are to services without ever sending the password again. Instead they present cryptographic tickets issued by a trusted third party.

That third party is the Key Distribution Center (KDC), which in Active Directory is every domain controller. It has two functions, the Authentication Service (AS) and the Ticket-Granting Service (TGS), and the flow happens in three acts.

sequenceDiagram
  accTitle: The Kerberos ticket flow
  accDescr: At sign-in the client sends an authentication request to the Authentication Service of the Key Distribution Center, which returns a ticket-granting ticket (TGT) encrypted so only the client and KDC can use it. When the client wants a specific service, it sends the TGT to the Ticket-Granting Service, which returns a service ticket for that one service. The client then presents the service ticket to the target service, which validates it and grants access. The user's password is only used at the first step and never travels across the network.
  actor U as Client (user)
  participant AS as KDC (AS)
  participant TGS as KDC (TGS)
  participant S as Service
  U->>AS: 1. Sign-in request (AS-REQ)
  AS->>U: Ticket-Granting Ticket (TGT)
  U->>TGS: 2. TGT + "I want service X"
  TGS->>U: Service ticket for X
  U->>S: 3. Present service ticket
  S->>U: Access granted (mutual auth)

When Daniel unlocked his laptop, the client got a Ticket-Granting Ticket (TGT) from the AS. When he opened the shared drive, the client showed the TGT to the TGS and got back a service ticket valid only for that file server, then handed that ticket to the server, which checked it and could authenticate itself back to him. The password was used only to obtain the TGT and never traveled over the network, which is Kerberos’s defining security property. Tickets expire, which explains Kerberos’s famous sensitivity to clock differences: machines have to agree on the time to within a few minutes.

Organizations are grouped into realms (an Active Directory domain is a Kerberos realm), and trust between realms lets tickets work across domains. Kerberos’s older sibling, NTLM, is the challenge-response protocol Active Directory falls back to when Kerberos can’t be used, and it’s a liability. NTLM is vulnerable to relay and pass-the-hash attacks, so hardening a Windows environment is largely a matter of pushing NTLM down and Kerberos up.

Delegation and its dangers

A subtle and powerful Kerberos feature is delegation: letting a service act on the user’s behalf toward another service, such as a web app reaching a database as the signed-in user. It’s useful and historically risky. Unconstrained delegation lets a compromised service impersonate users widely, which is why modern Active Directory uses constrained and resource-based delegation to fence it in. The Kerberos attacks we saw in directory services, Kerberoasting, cracking service-account tickets offline, and the Golden Ticket, forging TGTs with the domain’s master key, abuse exactly this ticket machinery. Protecting the KDC, meaning the domain controllers, and keeping delegation to a minimum come first: whoever controls the ticket system controls the realm.

RADIUS: the network’s gatekeeper

When you join a corporate Wi-Fi network or connect to a VPN, the protocol authenticating you is almost certainly RADIUS (Remote Authentication Dial-In User Service, RFC 2865). It dates from the dial-up era, as the “Dial-In” in its name gives away, but it became the backbone of modern network access control.

There are three parties: the supplicant, which is Daniel’s laptop or phone; the network access device or NAS, which is the Wi-Fi controller, switch, or VPN concentrator; and the RADIUS server. The access device doesn’t decide who gets on the network. It passes the question to the central RADIUS server, which authenticates the user, very often against Active Directory or LDAP behind it, and answers accept or reject.

sequenceDiagram
  accTitle: RADIUS authentication for network access (802.1X)
  accDescr: A supplicant such as a laptop tries to join a corporate Wi-Fi network. The access point, acting as the network access device, requests the user's identity and relays it as a RADIUS Access-Request to the central RADIUS server. The server may issue an Access-Challenge to which the supplicant responds, then validates the credentials, frequently against Active Directory or LDAP, and returns either an Access-Accept or an Access-Reject. The access point enforces that decision by granting or denying network access.
  actor U as Supplicant (device)
  participant NAS as Access point / NAS
  participant R as RADIUS server
  participant D as AD / LDAP
  U->>NAS: Connect (802.1X / EAP)
  NAS->>R: Access-Request (credentials)
  R->>D: Verify identity
  D->>R: OK
  R->>NAS: Access-Accept (or Reject)
  NAS->>U: Network access granted / denied

EAP: the methods inside

In 802.1X, the actual credential exchange travels inside EAP (Extensible Authentication Protocol), and the EAP method you configure decides how secure it really is. EAP-TLS uses certificates on both sides. It’s the strongest option and increasingly the standard for managed devices, since there’s no password to phish, and when the certificates are issued to devices it quietly ties network access to company-managed hardware. PEAP and EAP-TTLS build a TLS tunnel that protects an inner password-based exchange, usually checked against Active Directory. They’re common, but only as strong as the password.

RADIUS is also where the AAA model, authentication, authorization, and accounting, comes from, which we met in the IAAA pillars. Its cousin TACACS+ (RFC 8907) plays a similar role for administering network devices, common in Cisco environments, with the difference that it separates the three A’s more cleanly and encrypts the whole payload. The protocols that decide who gets onto the network at all form their own layer beneath application-level federation, and RADIUS owns that layer.

WS-Federation and WS-Trust: the SOAP-era veterans

Before SAML’s browser-redirect federation took over, and alongside it in the enterprise, there was a family of identity standards based on SOAP and XML: WS-Trust and WS-Federation, part of the broader WS-* stack. They solve the same basic problem as SAML, federating identity across trust boundaries, but in the heavier world of SOAP web services with its envelopes and namespaces.

The central concept is the Security Token Service (STS), a trusted issuer that mints and validates security tokens. WS-Trust defines the protocol for requesting, issuing, renewing, and validating those tokens, and WS-Federation builds federation between organizations on top. If that sounds like a SAML identity provider issuing assertions, it is: the same idea with different and clunkier plumbing. The underlying notion, claims-based identity issued by an STS, is exactly what SAML and OIDC express more simply.

They’re worth knowing because they’re legacy without being dead. Large estates built on SAP, Oracle, and older Microsoft ADFS deployments still speak WS-Federation and WS-Trust, and that procurement portal Daniel signed in to is one of them. Nobody starts a new project on WS-*, but plenty of systems the business depends on still run on it. You’ll meet it the day someone asks you to connect a modern OIDC app to an older partner or internal system that only speaks WS-Federation. The usual answer is a protocol-bridging gateway. Many identity providers translate between WS-Fed, SAML, and OIDC, so the legacy system keeps its protocol and the new app speaks its own.

Kerberos, RADIUS, and WS-* have something in common: each predates the web and mobile era, and each is still everywhere in its own niche, Windows networks, network access, and enterprise SOAP respectively. New systems reach for OIDC and FIDO2, but the installed base of veterans is enormous, and replacing it is a migration measured in years, not a switch you flip.

FIDO2, WebAuthn, and CTAP: the vanguard

Now the future. FIDO2 is the standard that finally makes authentication resistant to phishing by dropping the shared secret entirely. Instead of a password, or even a one-time code, that can be phished, relayed, or leaked, FIDO2 uses public-key cryptography. The authenticator holds a private key that never leaves it and registers a public key with the service. Signing in means signing a challenge, and because the signature is tied to the real site’s origin, a phishing site can’t produce a valid one.

FIDO2 is really two specifications working together. WebAuthn is a W3C standard browser API that the website calls to register and use credentials. CTAP (Client to Authenticator Protocol) is how the browser talks to the authenticator: a roaming security key such as a YubiKey over USB, NFC, or Bluetooth, or a platform authenticator like the biometric sensor in a phone or laptop. Together they make passkeys work, the synced, phishing-resistant credentials we introduced in authentication factors, and the first authentication technology with a credible claim to ending password phishing at scale.

What earns the label “phishing-resistant” is origin binding. When the authenticator signs the sign-in challenge, the signature is cryptographically tied to the real site’s origin, its domain. A look-alike site on a different origin can’t get a usable signature. There’s no secret the user can hand over by mistake, because the private key never leaves the authenticator and the signature won’t validate for the wrong origin. That’s a difference in kind from passwords and even one-time codes, both of which a convincing fake site can collect. This is only a preview; the authentication module takes apart the WebAuthn registration and authentication ceremonies, attestation, and the passkey experience in detail.

A word on mTLS and client certificates

One more veteran deserves a mention because it never really went away: mutual TLS (mTLS) with X.509 client certificates. Ordinary TLS only authenticates the server to the client; mTLS adds the reverse, with the client presenting a certificate that proves its own identity. It’s heavy to manage, since every client needs a certificate and a way to renew it, but very strong, so it survives in high-assurance settings: government and military smart cards, regulated B2B APIs, and increasingly machine-to-machine authentication inside service meshes, which comes up in the next articles. Certificate-based identity is old, but the public-key idea under it is exactly what FIDO2 modernizes for people.

How the veterans connect to the modern stack

These protocols aren’t separate islands. They interlock with the OIDC and SAML world, usually through the directory.

In Daniel’s company, the RADIUS server checking Wi-Fi sign-ins, the Kerberos KDC issuing tickets, and the identity provider issuing SAML and OIDC tokens all read the same Active Directory. The directory is the hub, and each protocol is a different door into the same identities. Kerberos also bridges to the web: “Windows Integrated Authentication” lets a Kerberos-authenticated desktop session carry over into the browser, and an identity provider can accept that Kerberos sign-in and mint a SAML or OIDC token from it, giving seamless SSO from the domain-joined desktop all the way to a cloud app. And FIDO2 plugs into OIDC and SAML rather than replacing them. WebAuthn is usually the method an identity provider uses to authenticate the person: Daniel signs in to the identity provider with his passkey, and the identity provider still issues the OIDC ID token to the app.

So picture the directory as the hub and the protocols as spokes: Kerberos for Windows networks, RADIUS for network access, WS-* for SOAP estates, SAML and OIDC for web federation, SCIM for provisioning, FIDO2 for phishing-resistant sign-in, very often all turning around the same identities.

When the veterans break

These protocols fail in recognizable ways, and spotting the symptom is half the fix.

Kerberos fails on clock skew and SPNs. Tickets carry timestamps, so if a machine’s clock drifts more than a few minutes from the KDC, authentication fails without a clear message. “It worked yesterday” right after a time change is a classic. The other Kerberos trap is a missing or duplicated Service Principal Name (SPN), which stops the TGS from issuing a service ticket. RADIUS fails on the shared secret: the access device and the RADIUS server authenticate each other with one, and a mismatch, a typo or a value someone forgot to rotate, produces silent rejections that look like a wrong password but aren’t. NTLM creeps back when apps reach a server by IP address instead of hostname, or when an SPN is missing, and quietly fall back from Kerberos, which is why “we disabled NTLM and things broke” is such a common story. Find the fallbacks before you switch it off. And like SAML, the WS-* veterans break when a signing or token-service certificate expires, an outage that arrives on a date nobody had in their calendar.

Each veteran has a short list of well-known failure modes, and a few minutes identifying the category beats hours of guessing. Match the symptom to the protocol, a time change, a connection by IP, a rotated shared secret, an expired certificate, and the fix usually follows quickly. That’s why the veterans matter even in a company that thinks of itself as OIDC-first: someone still has to debug them at 2 a.m.

The layers by era

Each standard piled on top of the ones before it, and none fully erased its predecessors.

timeline
  accTitle: Eras of identity and access protocols
  accDescr: A timeline of identity protocol eras. In the 1980s, Kerberos introduced ticket-based authentication. In the 1990s, RADIUS brought network access control, NTLM handled Windows challenge-response, and mTLS with X.509 enabled certificate-based mutual authentication. In the 2000s, the SOAP-based WS-Trust and WS-Federation standards enabled enterprise federation, and SAML brought web single sign-on. In the 2010s, OAuth, OpenID Connect, and SCIM defined the modern API-era stack. From 2018 onward, FIDO2, WebAuthn, and CTAP brought phishing-resistant, public-key authentication and passkeys.
  1980s : Kerberos (tickets)
  1990s : RADIUS (network access) : NTLM (Windows) : mTLS / X.509
  2000s : WS-Trust / WS-Federation : SAML web SSO
  2010s : OAuth 2.0 / OIDC / SCIM
  2018+ : FIDO2 / WebAuthn / CTAP (passkeys)

The shape of the table is the point. New standards don’t erase old ones; they stack on top, and a working company runs every layer at once, as Daniel’s morning showed. Part of the job is always knowing which layer you’re standing on.

Recap

Beyond the core federation stack, these are the protocol families you’ll meet in the field.

1. Kerberos provides ticket-based authentication (TGT, then service ticket) behind every Active Directory sign-in. The password never crosses the network. Protect the KDC and push down its insecure fallback, NTLM.
2. RADIUS guards network access (Wi-Fi, VPN, 802.1X) by forwarding authentication to a central server, often backed by Active Directory. It’s where the AAA model comes from.
3. WS-Federation and WS-Trust provide SOAP-era federation through a Security Token Service. They’re legacy but still relied on in SAP, Oracle, and older ADFS.
4. FIDO2, WebAuthn, and CTAP are the phishing-resistant, public-key vanguard behind passkeys, resistant because the signature is bound to the site’s real origin.
5. mTLS with X.509 certificates is strong mutual authentication that persists in high-assurance and machine-to-machine settings.
6. Identity comes in layers by era. New standards sit on top of the veterans instead of replacing them, and real environments run every layer at once, very often around a single directory.

Hands-on exercises

These are meant to be done, not just read.

1. Find Kerberos in the wild. On a domain-joined Windows machine, run klist in a terminal and read your cached tickets. Identify your TGT and any service tickets, and note their lifetimes. If you don’t have Windows, describe what you’d expect to see and why the TGT is special.
2. Trace the Wi-Fi decision. Sketch, protocol by protocol, what happens when your laptop joins a WPA2-Enterprise network. Name the supplicant, the NAS, the RADIUS server, and the directory behind it, and say which one actually decides accept or reject.
3. Spot the veteran. Name the protocol most likely doing the work in each case: opening an on-premises file share after signing in to Windows; connecting to the corporate VPN; signing in to an old portal integrated with SAP; signing in to a new web app with a passkey.
4. Make the case against NTLM. Your security team wants to disable NTLM. Explain why (the attacks), what would break, and how you’d move safely toward Kerberos only.
5. Answer the CISO. A CISO asks: “If FIDO2 is phishing-resistant, why are we still running Kerberos and RADIUS?” Write the honest two-paragraph answer about layers, the installed base, and what FIDO2 does and doesn’t replace.
6. Diagnose the outage. After a daylight saving time change, users at one site can’t authenticate to internal services, while web SSO still works. Name the most likely protocol and the specific cause, and explain why only the internal services broke.

Three questions to test yourself

1. Explain how Kerberos lets a user reach a dozen services after a single sign-in without resending the password, naming the TGT and the service ticket.
2. In an 802.1X Wi-Fi sign-in, which component enforces the access decision and which one makes it, and why is that separation useful?
3. Why is WS-Federation described as legacy but still relied on, and what’s the risk of assuming you can ignore it when modernizing a company’s identity?