--- title: Authentication Frameworks url: https://doc.liz6.com/en/networking/12-security-protocols/03-authentication-frameworks locale: en area: networking tags: - networking - security-protocols date: 2026-06-30 modified: 2026-07-16 description: 'Kerberos (symmetric key + tickets), SAML (federated identity + XML assertions), WebAuthn (public key + local biometrics) — three authentication frameworks addressing three distinct scenarios: intra-domain, cross-domain, and phishing resistance. LDAP and RADIUS provide directory and network access at the infrastructure layer.' --- # Authentication Frameworks > Kerberos (symmetric key + tickets), SAML (federated identity + XML assertions), WebAuthn (public key + local biometrics) — three authentication frameworks addressing three distinct scenarios: intra-domain, cross-domain, and phishing resistance. LDAP and RADIUS provide directory and network access at the infrastructure layer. ## Overview The question "authentication" always answers is the same — **how to prove you are you** — but different protocols place the "proof" in different places, leading to several generations: | Protocol | Year | Credential Form | Trust Place | Main Battlefield | |---|---|---|---|---| | Kerberos | 1988 | Symmetric Ticket | Central KDC | Enterprise Intranet / AD | | LDAP bind | 1993 | Username + Password | Directory Server | Internal Directory / Backend Storage | | SAML 2.0 | 2005 | Signed XML Assertion | IdP | Enterprise Web SSO | | RADIUS | 1991 | Shared Secret + EAP | AAA Server | Network Access (WiFi/VPN) | | WebAuthn | 2019 | Asymmetric Key Pair | User Device | Phishing-resistant passwordless login | Understanding one main thread is enough: **passwords are a liability**. They are reused, phished, subjected to credential stuffing, and leaked during transmission and storage. Each subsequent generation of protocols tries to make passwords appear less often — Kerberos ensures passwords are only used once locally to derive keys and never traverse the network; SAML/OIDC ensures passwords are only given to one IdP; WebAuthn completely replaces passwords with non-exportable private keys stored on the device. The essence of selection is: **to what extent can passwords be eliminated given your existing infrastructure and threat model**. ## Kerberos — Ticket-based Single Sign-On The foundation of AD domain login. The core idea: the user derives a key from their password only once during login, and thereafter accesses services entirely using **time-limited symmetric encryption tickets**, so the password never traverses the network. Kerberos Three Stages: Log in once, then rely entirely on tickets Roles: KDC = AS (Authentication Server) + TGS (Ticket Granting Server); Client; Service ① AS-REQ/REP · Log in once Client → AS: "I am alice" AS → Client: TGT (encrypted with TGS key) + Session Key (encrypted with key derived from password) → The password itself never goes online ② TGS-REQ/REP · Every access Client → TGS: Present TGT, "I want to access fileserver" TGS → Client: Service Ticket (encrypted with fileserver key) + New Session Key ③ AP-REQ/REP · Access Service Client → fileserver: Service Ticket + Authenticator (timestamp, anti-replay) fileserver decrypts ticket → Trust KDC endorsement → (optional) AP-REP Mutual Authentication The service does not need to contact the KDC or store user passwords to verify the client — as long as it can decrypt the "ticket encrypted with its own key", it proves the ticket was issued by the KDC. The password is only involved in derivation once during login, and never traverses the network afterwards. Why designed this way: The service can verify the client **without contacting the KDC or storing user passwords** — as long as it can decrypt the "ticket encrypted with its own key", it proves the ticket was issued by the KDC. Costs and threats: - **Clock Synchronization**: Authenticators rely on timestamps to prevent replay attacks; global clock skew usually must be < 5 minutes (hence AD's strong reliance on NTP). - **KDC is a high-value single point of failure**: Obtaining the `krbtgt` account hash allows forging arbitrary TGTs (**Golden Ticket**); obtaining a service key allows forging that service's tickets (Silver Ticket). - **Kerberoasting**: Service tickets are encrypted with keys derived from service account passwords. Attackers can request them and brute-force weak passwords for service accounts offline — hence service accounts should use strong random passwords / gMSA. ## LDAP — Directory and Bind Authentication LDAP (RFC 4511) is primarily a **hierarchical directory** (`cn=alice,ou=users,dc=example,dc=com`), storing people, groups, devices, and their attributes. Its "authentication" is the **bind** operation: presenting a DN + password to the server to exchange for a "pass/fail" result. LDAP Application Access: search-then-bind two steps ① Service Account Bind Application binds using service account → searches out alice's full DN ② User DN + Password Bind Then use alice's DN + her entered password to perform a bind → success means password is correct Bind Method Comparison simple bind DN + plaintext password Must run over LDAPS/StartTLS, otherwise passwords are exposed SASL bind GSSAPI (Kerberos) / EXTERNAL (mTLS) No password transmitted, stronger LDAP itself is not an SSO protocol — it is "credential verification + identity data source", often hidden behind SAML/OIDC/RADIUS as storage. Key positioning: LDAP itself is **not an SSO protocol**; it is "credential verification + identity data source", often hidden behind SAML/OIDC/RADIUS as storage. Active Directory ≈ LDAP (directory) + Kerberos (authentication) + DNS (location) combination. ## SAML 2.0 — Enterprise Web SSO The browser SSO standard of the XML era (Okta, Azure AD, enterprise intranets). The SP (Service Provider) outsources authentication to the IdP (Identity Provider), which returns a **digitally signed Assertion**. SAML 2.0 SP-initiated Flow (HTTP Redirect + Form POST Binding) 1 User → SP: Access protected resource 2 SP → Browser: Redirect to IdP, carrying AuthnRequest (HTTP-Redirect binding) 3 IdP verifies user (may reuse existing session) → generates Assertion 4 IdP → Browser → SP: Auto POST form back Response (HTTP-POST binding) 5 SP verifies XML signature + conditions → establishes local session Key Assertion Fields <Issuer> Who issued it (must be in SP trust list) <Subject><NameID> User identifier <Conditions NotBefore=".." NotOnOrAfter=".."> Validity period → anti-replay <AttributeStatement> email / groups / role, etc. <ds:Signature> XML-DSig signature (covers assertion or entire Response) Security points (SAML's pitfalls are almost all in signature verification): - **XML Signature Wrapping (XSW)**: Attackers shift validly signed elements and inject forged assertions. The SP must strictly verify that "the signature covers exactly the element being trusted" and fix schema parsing — this is the most common source of CVEs in SAML implementations. - **Must verify** `Audience` (this assertion is for me), `NotOnOrAfter` (not expired), `Recipient` and `InResponseTo` (anti-replay/anti-injection), and treat `NameID` as single-use. - Why it still survives: Pure browser redirects, no JS required, best compatibility with legacy enterprise IdPs. New projects should prefer OIDC. ## WebAuthn / Passkeys — Phishing-resistant Passwordless FIDO2/WebAuthn (W3C) replaces passwords with a pair of **asymmetric keys**: the private key is generated and locked in the device's secure element, non-exportable, while the server only stores the public key. WebAuthn: Asymmetric key pairs replace passwords, private keys never leave the device Registration · navigator.credentials.create Server → challenge (random) Authenticator Generates key pair for (RP ID=example.com), private key stays local → returns credential_id + public_key +(optional) attestation Server Stores credential_id ↔ public_key Authentication · navigator.credentials.get Server → challenge + allowed credential_id Authenticator User verifies (fingerprint/PIN) → signs with private key (challenge + origin + RP ID) Server Verifies signature with public key + checks challenge + origin The signature binds origin/RP ID — the authenticator only recognizes the correct domain, providing phishing resistance that passwords and OTPs cannot. Its **only truly important property is phishing resistance**: the signature binds `origin`/RP ID, and the browser will only use `example.com` credentials for `example.com`. Even if the user is tricked into `examp1e.com`, the authenticator won't find matching credentials and cannot produce a valid signature — a guarantee that passwords, OTPs, and push notifications cannot provide. Other concepts: - **Attestation**: Proves "this is a genuine authenticator of a specific model"; consumption scenarios generally do not verify this (privacy + compatibility). - **Discoverable credential (resident key)**: Stores the user handle in the authenticator, enabling login "without entering a username first" — this is the basis of **Passkeys**. - **Passkey = Syncable discoverable credentials**: Synced across devices via iCloud Keychain / Google Password Manager, greatly improving usability, but trust shifts to that cloud account; pure hardware keys (device-bound) do not sync, are stronger, but are easier to lose. ## RADIUS — Network Access AAA RADIUS (RFC 2865) does not manage "logging into a website", but rather "**can you access this network**" — WiFi (WPA2/3-Enterprise), VPN, switch ports (802.1X). It performs AAA: Authentication, Authorization, Accounting. RADIUS: AAA Frontend for Network Access Layer NAS AP / Switch / VPN Gateway RADIUS Server Authentication/Authorization/Accounting UDP 1812/1813 Shared Secret (NAS ↔ Server) EAP tunnel carries the actual authentication method EAP-TLS = Certificate mutual authentication (strongest) PEAP/TTLS = Run inside TLS tunnel MSCHAPv2, etc. Often queries LDAP / AD / Kerberos 802.1X Three Parties Endpoint (supplicant) Switch (authenticator) RADIUS (server) RADIUS is just the AAA frontend, decoupling the access layer from the identity layer — actual account data remains in LDAP/AD/Kerberos. Key points: RADIUS itself is just an AAA frontend; identity data usually remains in LDAP/AD; it decouples the "access layer" from the "identity layer". When fine-grained authorization and auditing by command are needed (network device operations), use **TACACS+** (per-command authorization, full encryption) instead. ## Selection | Requirement | Preferred | Key Reason | |---|---|---| | AD domain service mutual recognition | Kerberos | Ticket SSO, passwords don't traverse network | | Internal directory / as backend identity source | LDAP(S) | It is a data source, not SSO, hidden behind other protocols | | Enterprise Web SSO (legacy IdP) | SAML 2.0 | Pure browser, best compatibility | | Modern App / Mobile / Federated Login | [OIDC](/networking/12-security-protocols/02-oauth2-and-openid-connect.md) | JSON/JWT, lighter than SAML | | Phishing-resistant user login | WebAuthn/Passkey | Origin binding, eliminates passwords | | WiFi / VPN / Port Access | RADIUS + EAP | Network access layer AAA | | Network device per-command authorization audit | TACACS+ | Fine-grained + full encryption | In practice, they are layered and used together rather than being mutually exclusive: a typical combination is **WebAuthn/OIDC for user login frontend + LDAP/AD for identity source + Kerberos/RADIUS for intranet and access**. ## References - **Kerberos**: RFC 4120 · MIT Kerberos Documentation · "Kerberos: The Definitive Guide" - **WebAuthn**: w3c.github.io/webauthn · webauthn.guide · passkeys.dev - **SAML**: OASIS SAML 2.0 Core · "On Breaking SAML" (XSW attack paper) - **Unified Platform**: Keycloak (covers OIDC/SAML/LDAP/Kerberos brokering, worth setting up and reading) *Keywords: Kerberos, KDC, TGT, Golden Ticket, Kerberoasting, LDAP, bind, SAML, Assertion, XML Signature Wrapping, WebAuthn, Passkey, FIDO2, phishing-resistant, RADIUS, EAP, 802.1X, TACACS+*