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

Beyond the core four

This module has spent most of its time on the modern federation and provisioning stack — directory services, SAML, OAuth, OIDC, SCIM. But walk into any real enterprise and you’ll find a wider zoo of protocols quietly doing critical work. Some are veterans — decades old, unglamorous, and still load-bearing under millions of logins a day. One is the vanguard — the phishing-resistant future that’s actively replacing passwords. Fluency in identity means recognizing all of them — and knowing that the newest protocol on the architecture slide is rarely the one carrying the most weight in production.

This article tours four: Kerberos (the ticket system behind every Active Directory login), RADIUS (the protocol behind your corporate Wi-Fi and VPN), WS-Federation / WS-Trust (the SOAP-era federation still alive in big ERP estates), and FIDO2 / WebAuthn / CTAP (the public-key vanguard). Three veterans and one glimpse of the future.

Kerberos: the ticket system under every AD login

Kerberos (RFC 4120) is a ticket-based authentication protocol born at MIT in the 1980s, and it is the beating heart of Active Directory authentication. Its central insight: after an initial login, a user should prove their identity to services without ever sending their password again — instead they present cryptographic tickets issued by a trusted third party.

The trusted third party is the Key Distribution Center (KDC) — in AD, every domain controller — which has two functions: the Authentication Service (AS) and the Ticket-Granting Service (TGS). The flow has three acts:

sequenceDiagram
  accTitle: The Kerberos ticket flow
  accDescr: At login 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 — Authentication Service
  participant TGS as KDC — Ticket-Granting Service
  participant S as Target service
  U->>AS: 1. Login 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)

Reading it: at login the client gets a Ticket-Granting Ticket (TGT) from the AS. To reach a specific service, it presents the TGT to the TGS and receives a service ticket scoped to that one service. It hands that ticket to the service, which validates it — and can mutually authenticate back. The password is used only to bootstrap the TGT and never travels the network, which is Kerberos’s signature security property. Tickets are time-limited (hence Kerberos’s notorious sensitivity to clock skew — machines must agree on time within minutes).

Organizations are grouped into realms (an AD domain is a Kerberos realm), and cross-realm trust lets tickets work across domains. Kerberos’s older sibling, NTLM, is the challenge-response protocol AD 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 estate largely means driving NTLM down and Kerberos up.

Delegation and its dangers

A subtle, powerful Kerberos feature is delegation — letting a service act on the user’s behalf toward a further service (a web app reaching a database as the logged-in user). Useful, but historically risky: unconstrained delegation lets a compromised service impersonate users broadly, which is why modern AD uses constrained and resource-based delegation to box it in. The Kerberos attacks we met in directory services — Kerberoasting (cracking service-account tickets offline) and the Golden Ticket (forging TGTs with the domain’s master key) — are abuses of exactly this ticket machinery. That’s why protecting the KDC (the domain controllers) and minimizing delegation are paramount: own the ticket system and you own the realm.

RADIUS: the gatekeeper of the network

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

The model has three parties: the supplicant (your laptop or phone), the network access device or NAS (the Wi-Fi controller, switch, or VPN concentrator), and the RADIUS server. The device doesn’t decide who gets on the network — it forwards 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

The actual credential exchange in 802.1X rides inside EAP (Extensible Authentication Protocol), and which EAP method is configured determines the real security:

• EAP-TLS — mutual certificates on both sides; the strongest and increasingly the standard for managed devices (no password to phish).
• PEAP / EAP-TTLS — a TLS tunnel protecting an inner password-based exchange, often validated against AD; common but only as strong as the password.
• EAP-TLS with device certs — ties network access to a managed device, a quiet but powerful control.

RADIUS is also the historical origin of the AAA model — Authentication, Authorization, and Accounting — that we met in the IAAA pillars. Its cousin TACACS+ (RFC 8907) serves a similar role for network-device administration (common in Cisco environments), with the difference that it separates the three A’s more cleanly and encrypts the full payload. The takeaway: the protocols deciding who gets onto the network at all are a distinct layer beneath the app-level federation — and RADIUS owns it.

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

Before SAML’s browser-redirect federation fully took over, and alongside it in the enterprise, lived a family of SOAP/XML-based identity standards: WS-Trust and WS-Federation (part of the broader WS-* stack). They solve the same fundamental problem as SAML — federating identity across trust boundaries — but in the heavier, envelope-and-namespace world of SOAP web services.

The core 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; WS-Federation builds cross-organization federation on top. If that sounds like SAML’s IdP issuing assertions, it is — same idea, different and clunkier plumbing.

Why learn them? Because they’re legacy but not dead. Large estates built on SAP, Oracle, and older Microsoft ADFS still speak WS-Federation and WS-Trust, and when you integrate identity into one of those systems you’ll meet them. The honest framing: nobody starts a new project on WS-*, but plenty of revenue-critical enterprise systems still run on it, and “legacy” in identity means “load-bearing and irreplaceable for now.”

Concretely, you’ll meet WS-* the day you’re asked 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 IdPs translate between WS-Fed, SAML, and OIDC — letting the legacy system keep its protocol while the new app speaks its own. The underlying notion, claims-based identity issued by an STS, is the very same idea SAML and OIDC express more simply; WS-* just wraps it in SOAP envelopes. Recognize the model and the SOAP is just unfamiliar packaging.

FIDO2 / WebAuthn / CTAP: the vanguard

Now the future. FIDO2 is the standard that finally makes authentication phishing-resistant by abandoning the shared secret entirely. Instead of a password (or even an OTP) 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. Login is a signed challenge — and because the signature is bound to the real site’s origin, a phishing site simply can’t produce a valid one.

FIDO2 is really two specifications working together:

• WebAuthn — a W3C standard browser API the relying party (website) calls to register and authenticate credentials.
• CTAP (Client to Authenticator Protocol) — how the browser/client talks to the authenticator: a roaming security key (YubiKey) over USB/NFC/Bluetooth, or a platform authenticator (your phone or laptop’s biometric sensor).

Together they’re what makes passkeys work — the synced, phishing-resistant credentials we introduced in authentication factors. This is the genuine vanguard: the first authentication technology with a credible claim to end password phishing at scale.

The property that earns the word “phishing-resistant” is origin binding. When the authenticator signs the login challenge, the signature is cryptographically tied to the real site’s origin (its domain). A look-alike phishing site at a different origin simply cannot obtain a usable signature — there’s no secret for the user to mistakenly hand over, because the private key never leaves the authenticator and the signature won’t validate for the wrong origin. That’s a categorical improvement over passwords and even OTPs, both of which a convincing fake site can harvest. We’re only previewing FIDO2 here; the authentication module dissects the WebAuthn registration and authentication ceremonies, attestation, and passkey UX in depth. For now, place it on your map as the standard the whole industry is migrating toward.

A note on mTLS and client certificates

One more veteran worth a mention, because it never really left: mutual TLS (mTLS) with X.509 client certificates. Most TLS authenticates only the server to the client; mTLS adds the reverse — the client presents a certificate proving its identity too. It’s heavy to manage (every client needs a certificate and a way to renew it) but extremely strong, so it persists in high-assurance settings: government and military smart cards, regulated B2B APIs, and — increasingly — machine-to-machine authentication inside service meshes, which we’ll meet in the next article. Certificate-based identity is old, but the public-key idea underneath it is exactly what FIDO2 modernizes for humans.

How the veterans connect to the modern stack

These protocols aren’t isolated islands — they interlock with the OIDC/SAML world, usually through the directory:

• They share one source of truth. A RADIUS server authenticating Wi-Fi, a Kerberos KDC issuing tickets, and a SAML/OIDC IdP issuing tokens are frequently all reading the same Active Directory. The directory is the hub; each protocol is a different door into the same identities.
• Kerberos bridges to the web. “Windows Integrated Authentication” lets a Kerberos-authenticated desktop session flow into a browser, and an IdP can accept that Kerberos login and mint a SAML or OIDC token from it — seamless SSO from the domain-joined desktop all the way to a cloud app.
• FIDO2 plugs into OIDC/SAML. WebAuthn is usually the authentication method an IdP uses, not a replacement for federation: the user authenticates to the IdP with a passkey, and the IdP still issues the OIDC ID token. Vanguard authentication and modern federation working together.

The mental model that ties the whole module together: the directory is the hub, and the protocols are spokes — Kerberos for Windows networks, RADIUS for network access, WS-* for SOAP estates, SAML/OIDC for web federation, SCIM for provisioning, FIDO2 for phishing-resistant login — very often all turning around the same identities.

Troubleshooting the veterans

These protocols fail in characteristic ways, and recognizing the symptom is half of fixing it:

• Kerberos: clock skew and SPNs. Tickets are time-stamped, so if a machine’s clock drifts more than a few minutes from the KDC, authentication silently fails — “it worked yesterday” after a time change is a classic. The other Kerberos gotcha is a missing or duplicate Service Principal Name (SPN), which breaks the TGS’s ability to issue a service ticket.
• RADIUS: the shared secret. The NAS and the RADIUS server authenticate to each other with a shared secret; a mismatch (a typo, an un-rotated value) produces silent rejects that look like “wrong password” but aren’t.
• NTLM creeping back. Apps that reach a server by IP instead of hostname, or with a missing SPN, quietly fall back from Kerberos to NTLM — which is why “we disabled NTLM and things broke” is so common. Find the fallbacks before you turn it off.
• WS-*: certificate expiry. Like SAML, the SOAP veterans break when a signing or token-service certificate lapses — an outage that arrives on a calendar you forgot to keep.

The meta-lesson: each veteran has a small set of well-known failure modes, and a few minutes recognizing the category of failure beats hours guessing. Pattern-match the symptom — a time change, an IP-not-hostname connection, a rotated shared secret, an expired certificate — to the protocol, and the fix usually follows in minutes. This is exactly why knowing the veterans matters even in an OIDC-first world: you’ll still be the one debugging them at 2 a.m.

The landscape at a glance

A quick timeline of how these layers accreted — each new standard piling on top of the ones before, none fully erasing 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 lesson: identity is stratified by era. The newest standards don’t erase the old ones; they pile on top, and a working enterprise runs all the layers at once. Your job is to know which layer you’re standing on at any moment.

Recap

Beyond the core federation stack, four protocol families you’ll meet in the field:

1. Kerberos — ticket-based auth (TGT → service ticket) behind every AD login; the password never crosses the wire; protect the KDC, and drive down its insecure fallback NTLM.
2. RADIUS — the gatekeeper of network access (Wi-Fi, VPN, 802.1X), forwarding auth to a central server, often AD-backed; the origin of the AAA model.
3. WS-Federation / WS-Trust — SOAP-era federation via a Security Token Service; legacy but still load-bearing in SAP, Oracle, and old ADFS.
4. FIDO2 / WebAuthn / CTAP — the phishing-resistant, public-key vanguard powering passkeys, resistant because the signature is bound to the site’s real origin; covered in depth in the authentication module.
5. mTLS / X.509 — strong certificate-based mutual auth, persistent in high-assurance and machine-to-machine settings.
6. Identity is stratified by era — new standards layer on top of veterans rather than replacing them; real environments run every layer at once, very often turning around one shared directory. “Modernizing” identity is additive archaeology, not demolition — which is why you must know the veterans even in an OIDC-first world.

Hands-on exercises

These are practical — do them, don’t just read them:

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. (No Windows? Describe what you’d expect to see and why the TGT is special.)
2. Trace the Wi-Fi decision (use case). Sketch what happens, protocol by protocol, 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 makes the accept/reject decision.
3. Spot the veteran (use case). For each, name the protocol most likely doing the work: opening an on-prem file share after Windows login; connecting the corporate VPN; logging into an old SAP-integrated portal; signing in to a new web app with a passkey.
4. Make the NTLM case (use case). Your security team wants to disable NTLM. Explain why (the attacks), what would break, and how you’d migrate toward Kerberos-only safely.
5. Argue the migration (use case). A CISO asks “if FIDO2 is phishing-resistant, why are we still running Kerberos and RADIUS?” Give the honest two-paragraph answer about layers, installed base, and what FIDO2 does and doesn’t replace.
6. Diagnose the outage (use case). After a daylight-saving time change, users on one site can’t authenticate to internal services, while web SSO still works fine. Name the most likely culprit 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 authenticate to a dozen services after a single login without resending their password, naming the TGT and the service ticket.
2. In an 802.1X Wi-Fi login, 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 load-bearing,” and what’s the risk of assuming you can ignore it when modernizing an enterprise’s identity?