Authentication Framework

Kerberos, LDAP, SAML, WebAuthn, and RADIUS are not five successive generations of login protocols replacing one another. They organize tickets, directory operations, cross-system assertions, public key credentials, and network access, respectively, and can collaborate within the same system. When comparing them, first ask: who verifies credentials, who makes the authorization decision, and which component ultimately enforces that decision?

Whether a password is involved is only one dimension of comparison. How keys are registered and revoked, how accounts are recovered, and how established sessions are invalidated also determine system behavior.

Kerberos: Tickets Are Not Reusable Complete Login Proofs

The KDC includes two logical roles: AS and TGS. The client first obtains a TGT via AS exchange, then requests a ticket for the target service from the TGS using the TGT, and finally sends an AP request to the service. Tickets can usually be cached for use until their validity period expires; they do not require re-accessing the TGS every time a file is read.

Password-based initial exchanges do not send raw passwords but use long-term keys derived from passwords and typically include pre-authentication. Kerberos also supports public key initial authentication such as PKINIT; one cannot write "all logins derive a password key only once" as a protocol law. RFC 4120, PKINIT

After the service decrypts the ticket, it must still verify the target principal, validity period, identity and time in the authenticator, and prevent reuse of the same authenticator. Timestamps only limit the acceptable window; replay is still possible within that window, so "not expired" cannot replace replay caches or other replay protection allowed by the protocol. Allowed clock skew is controlled by implementation and policy, not a universal fixed five minutes.

AP-REP can provide mutual authentication, proving the service also holds the session key. Basic verification does not require online access to the KDC, but specific deployments may still involve authorization data validation and other dependencies. Since symmetric keys can be used by the service itself, "being able to decrypt cryptographically proves only the KDC could have issued it" is also inaccurate.

Caching improves availability but introduces revocation latency: when the KDC is temporarily unreachable, already valid service tickets may continue to be used, while requests for new tickets or renewals are affected. Compromise of a service long-term key affects trust in that service's tickets; compromise of the TGS key has a wider scope. After ticket authentication is complete, the service still needs to determine whether the principal can read a specific directory or perform a specific action based on authorization data.

Why reject the second authenticator within its time window?

Deliver twice at one time: the second is replay despite valid time. A fresh authenticator keeps principalalice and can pass again. Moving receive time away triggers a separate freshness rejection.

LDAP: Directory Queries and Connection Identity Are Two Layers of State

LDAP entries have DNs, such as uid=alice,ou=people,dc=example,dc=com; search specifies base DN, scope, filter, and attribute set. The DN is a directory location identifier and can change with renaming or moving; long-term associations for directory accounts should be designed based on stable identifiers provided by the deployment. RFC 4511

The common search-then-bind flow is: the application searches for the user with limited-privilege service identity, confirms exactly one matching record, and then authenticates using the returned DN and user password. Directly concatenating user input into a DN may not conform to directory structure, and obtaining multiple search results does not allow arbitrarily taking the first one.

Login interfaces should reject empty passwords from entering the username/password authentication path. When using StartTLS, confirm that the upgrade and server certificate verification are complete before submitting credentials; do not treat continuing bind after upgrade failure as an equivalent path. EXTERNAL can leverage externally established secure identity, but certificate identity to directory authorization identity still requires mapping. RFC 4513

Bind changes the connection's authentication state. Temporarily binding to a specific user on a shared search connection affects subsequent requests; authentication connections and service query connections should have clear lifecycles. Re-bind failure does not imply the original service account permissions are retained.

Filter Escape and DN Escape Are Not the Same Rules

The asterisk in (uid=alice*) has pattern meaning; if a username truly contains an asterisk, it needs to be encoded according to filter syntax. The following escapes each byte of the UTF-8 value, resulting in a verbose format but allowing direct inspection to ensure no filter structure injection; in practice, use the LDAP library's filter value encoding function.

def filter_value(text):
    return ''.join('\\' + format(b, '02x') for b in text.encode('utf-8'))

assert filter_value('a*(b)\\') == r'\61\2a\28\62\29\5c'
assert filter_value('中') == r'\e4\b8\ad'
assert filter_value('\0') == r'\00'
query = '(uid=' + filter_value('alice*') + ')'
assert query == r'(uid=\61\6c\69\63\65\2a)'
print('Filter values encoded by byte; not used for DN or attribute names')

This function only handles attribute values and cannot be used to allow users to arbitrarily choose search base, attribute names, or filter operators. RFC 4515

SAML: Which Signature Element and Which Request Are Trusted

In common SP-initiated Web SSO, the SP saves the request ID, sends the AuthnRequest to the IdP via the browser; after the IdP completes the applicable user authentication, it typically POSTs the Response to the SP's ACS via the browser. The SP verifies the response and assertion, then creates its own session. Base64 XML carried by the browser is not inherently trusted content, nor does it imply encryption. SAML Profiles

The core issue of XML Signature Wrapping is "verify signature A, but business logic reads B." Finding only one valid signature in the document is not enough; use a mature SAML library and ensure the consumed assertion and signature verification result are the same structure object. Element IDs, parsing, and allowed signature structures must also be handled according to library and profile requirements.

NameID is a subject identifier, not a one-time consumption login nonce. Its format and issuer constraints jointly affect identity mapping; persistent NameID can be used for multiple logins. Anti-replay should associate request ID, assertion/response ID, and validity period; do not permanently mark a user as "NameID used" after their first login.

IdP-initiated non-request-response logins do not have the same original SP request to match and require explicitly adopting the processing policy of that profile; do not turn off all InResponseTo checks for callbacks just for compatibility. RelayState is commonly used to restore application state and cannot directly become any arbitrary cross-site redirect address. SAML Core

The following only demonstrates one-time consumption after signature verification and other condition checks are complete; actual services must atomically check and register in shared storage and retain until the corresponding acceptance window ends.

seen = set()
def consume(issuer, assertion_id, expires, now):
    key = (issuer, assertion_id)
    if now >= expires or key in seen:
        return False
    seen.add(key)
    return True

assert consume('idp-a', 'assertion-1', 200, 100)
assert not consume('idp-a', 'assertion-1', 200, 101)
assert consume('idp-a', 'assertion-2', 200, 101)  # Same user can log in again.
assert not consume('idp-a', 'assertion-3', 200, 200)
print('Assertion replay and expiration boundaries passed; NameID is not consumed one-time')

WebAuthn: Credential Scope, Byte Signature, and User Verification

During registration, the RP issues a challenge, the browser and authenticator complete navigator.credentials.create(), the RP verifies the registration result, and saves the credential ID, public key, user handle, and required state associations. During authentication, navigator.credentials.get() is used; the verifier must know which local account the credential belongs to; adding new credentials also requires reliable registration authorization.

The input to the authentication signature is the raw bytes of authenticatorData || SHA256(clientDataJSON). clientDataJSON contains ceremony type, challenge, origin, etc.; authenticatorData contains RP ID hash, flags, and counter, etc. Do not parse the raw JSON, re-serialize it, and then calculate the digest, because changes in whitespace and field order will change the bytes.

The RP should check the expected challenge, allowed origin, RP ID hash, credential and account relationship, and UP/UV flags required by policy, then verify the signature according to the credential public key and algorithm. UP indicates user presence interaction, UV indicates completion of local user verification; touching the device is not always equivalent to fingerprint or PIN verification. WebAuthn Verifying Assertion

import hashlib
import json
import struct
rp_id = 'example.com'
raw_client_data = json.dumps({
    'type': 'webauthn.get', 'challenge': 'example-only',
    'origin': 'https://login.example.com'
}, separators=(',', ':')).encode()
# Minimal authenticatorData without extensions: 32 B hash + 1 B flags + 4 B counter.
auth_data = hashlib.sha256(rp_id.encode()).digest() + bytes([0x05])
auth_data += struct.pack('>I', 0)
signed_bytes = auth_data + hashlib.sha256(raw_client_data).digest()
assert len(auth_data) == 37 and len(signed_bytes) == 69
assert auth_data[32] & 0x01 and auth_data[32] & 0x04  # UP, UV
assert hashlib.sha256(raw_client_data).digest() != hashlib.sha256(
    json.dumps(json.loads(raw_client_data), indent=2).encode()).digest()
print('Signature input 69 B; here checking encoding, not replacing real signature verification and transaction validation')

RP ID is usually a valid domain name, while origin includes protocol, host, and applicable port. login.example.com can use example.com as the RP ID when compliant, but the RP must still restrict allowed origins; do not use direct string equality between the two as the only check.

Passkeys Are Not "Trapped in One Hardware Device Forever"

Passkeys can be synchronized credentials or bound to a single device. Synchronized providers use credentials across multiple devices under their protection mechanisms, with different lifecycles than device-bound keys; WebAuthn does not require all private keys to be located in non-exportable hardware security modules. Biometrics are also not a mandatory condition; user verification can be completed via device PIN, etc., and the RP typically does not receive raw biometrics. FIDO Passkeys

Authenticators that do not implement counters can always return 0; in other cases, non-incrementing may involve cloning, failure, or concurrent response out-of-order, and should be handled according to specifications and risk policies. One-time use of the challenge remains one of the cores of transaction freshness.

Domain scoping prevents spoofed sites from obtaining authentication results for the real RP like they would collecting passwords or OTPs. However, account recovery, already logged-in sessions, and terminal environments still have their own trust boundaries; removing passwords does not automatically strengthen weak recovery flows.

Why can a correct signature still fail login?

Initially RPexample.com differs from the login-subdomain origin, so direct equality is not the rule. Removing UV while retaining UP distinguishes presence from required verification; other correct fields cannot compensate.

RADIUS and EAP: Authentication Server Decides, NAS Executes

In typical 802.1X, the terminal interacts with the AP/switch via EAPOL, and the NAS encapsulates EAP messages into RADIUS attributes to send to the authentication server. EAP is an extensible authentication framework; EAP-TLS is the method within it that uses TLS; do not call all EAP encrypted tunnels. RADIUS/EAP, EAP-TLS 1.3

RADIUS Access-Request can receive Access-Challenge, Access-Accept, or Access-Reject. Multi-round challenges use attributes like State to associate the authentication process; Accept may include authorization attributes such as VLAN, filtering, or session time limits. If authentication passes but VLAN is not correctly applied, check NAS execution and attribute support, rather than just re-entering the password.

Classic RADIUS/UDP commonly uses 1812 for authentication and 1813 for accounting, with a basic 20-byte header including Code, Identifier, Length, and 16-byte Authenticator; the specific construction of the Authenticator depends on the message type and cannot be uniformly called a "nonce" or "full packet encryption." Shared secrets and traditional attribute protection do not equal modern transport confidentiality for the entire packet. RFC 2865

RADIUS/TLS or DTLS protects transport between NAS/proxy and server, which is a different boundary from EAP-TLS from terminal to EAP server. RADIUS/1.1 defined in RFC 9765 is an experimental specification that removes shared secrets, MD5 packet authentication, and attribute obfuscation mechanisms from its mode via TLS/DTLS ALPN negotiation; do not claim that all existing UDP RADIUS has been upgraded because of this. RADIUS/1.1

RADIUS servers can use local configuration, certificates, directories, or other identity sources, and do not necessarily need to place account data in LDAP/AD. Accounting records describe session events and statistics and do not naturally constitute an exactly-once ledger; applications need to handle retransmissions, missing records, and session association.

TACACS+ is commonly used for authentication, per-command authorization, and accounting in device management. Its traditional protocol header is plaintext, and the body uses shared-secret-based obfuscation; it cannot be simplified as "end-to-end modern encryption"; whether it is suitable to replace a specific RADIUS deployment depends on device capabilities and management needs. RFC 8907

Combining Them into an Identity System

An enterprise can use LDAP to store directories, Kerberos to access domain services, have the IdP authenticate users via WebAuthn, and then issue SAML or OIDC results to web applications; office networks use RADIUS/EAP for access. These components share the personnel lifecycle but do not automatically share the same session state.

After an employee leaves, directory deactivation, remaining ticket validity, IdP sessions, application sessions, registered passkeys, and network access sessions change separately. Complete design should clarify the holder, validity period, and revocation propagation method for each type of state. After protocol selection, the identity lifecycle still needs to be strung together.