Authentication and Access Control: AAA to Passkeys

Authentication and Access Control: AAA to Passkeys

What you'll learn

• Structure any security conversation with AAA and the CIA triad
• Classify authentication factors correctly — know, have, are — including the one the textbook's quick list misfiles
• State current password guidance (NIST SP 800-63B-4) and why it reversed the old rules
• Place TOTP and passkeys/FIDO2 on the MFA ladder, and RADIUS, TACACS+ and Kerberos in the AAA back office
• Choose the right access-control model — MAC, DAC, rule-based, role-based — for a given scenario

Two acronyms to rule the module

This lesson builds on Chapter 15 of Dr. Tahseen Al-Doori's Network Essentials, which organizes everything identity-related under two three-letter frames that professionals still reach for daily.

AAA is the operational frame — three jobs, in order:

• Authentication — verify that you are who you claim. The login moment.
• Authorization — decide what the verified you may do. Permissions.
• Accounting — record what actually happened. Logs.

CIA is the goals frame (no relation to the agency, as the book wryly notes): Confidentiality — only authorized eyes see the data (lesson 3's encryption serves this); Integrity — the data is not tampered with; Availability — the data is there when needed (Module 8's uptime work serves this). AAA describes what your systems do; CIA describes why. Every control in this module serves at least one letter of each.

The book separates authentication from authorization with a domestic story worth retelling. You lend a friend your house key — "make yourself comfortable, use the kitchen." You return to find the hallway half-repainted in a color you would not have chosen. Your friend authenticated flawlessly: right key, rightful entry. What failed was authorization — entry never meant permission to redecorate. Getting in and being allowed are different systems, and every "but I was logged in!" argument you will ever hear confuses them.

Authentication factors: know, have, are

Everything you can present to prove identity falls into three classes:

• Something you know — a password, PIN, passphrase. Cheap, shareable, stealable at scale.
• Something you have — a smart card, hardware token, or the phone holding your authenticator app. Stealing it requires your pocket, not a database.
• Something you are — biometrics: fingerprint, face, iris, voice. Convenient, unforgettable — and unchangeable, which is why it pairs with other factors rather than replacing them.

One kind correction as we sort: the book's quick summary at one point files thumbprints and retinal scans under "something you have." Its own fuller list — fingerprints, retinal scans, voice — shows the intended teaching, so this is a filing slip, not a misunderstanding: biometrics are something you are. The distinction matters practically: a card you have can be revoked and reissued; what you are cannot be reissued, so systems must store it with special care (as a local template, ideally never in a central database).

Multi-factor authentication (MFA) means requiring two different classes — password plus phone app, card plus PIN. Two passwords is not MFA; it is one factor twice. The book's fingerprint scenario explains why mixing classes matters, and the insight has not aged: any single check can be beaten — a print can be lifted from a surface with tape, a password phished — but beating two different kinds of checks in one login session multiplies the attacker's problem rather than adding to it. That multiplication is the whole magic of MFA, and (as lesson 6 will show with numbers) turning it on remains the single highest-value security move an ordinary person or business can make.

Passwords: the great reversal

Here is the module's cleanest then-versus-now story, and it deserves its full arc.

The original foundation. The book teaches the password craft of its era: minimum length, complexity (mixed case, digits, symbols — its worked example walks a pet's name through the upgrades), scheduled expiration, and no-reuse rules. It also flags the deeper weaknesses no composition rule fixes: a password derived from your life is guessable by anyone who learns your life, and short passwords fall to sheer enumeration — Module 4's doubling arithmetic again. Its recommended peak was the passphrase — in the book's construction, the first letters of a memorable sentence, yielding a dense string you can actually retain.

Why it mattered. Every rule aimed at real attacks: complexity fought dictionary guessing; expiration bounded the life of a stolen credential; length fought brute force. For two decades this was orthodoxy, enforced by every corporate login screen you have ever sighed at.

What changed. Decades of breach data revealed how humans actually behave under these rules. Forced 90-day changes produced Autumn2026! rolling to Winter2026! — transformations attackers model trivially. Composition rules produced P@ssw0rd1, which satisfies every checkbox and survives seconds. Meanwhile the real killers were elsewhere: reuse (one breached site unlocks your others) and known-breached passwords circulating in attacker wordlists. The rules taxed honest users and barely taxed attackers.

2026 practice. NIST's current digital-identity guidance — SP 800-63B-4 (2025) — did not merely soften the old advice; it forbade it, in standards language: verifiers shall not require periodic password changes (change on evidence of compromise, not on a calendar), and shall not impose composition rules. What wins instead: length (support long passwords; passphrases of several random words beat dense line-noise for both strength and memorability), blocklists (reject passwords found in breach corpora and common-password lists), rate-limiting of guesses, and — closing the loop — MFA over it all. A password manager makes the whole regime livable: one strong memorized passphrase guarding a vault of long random unique secrets. The book's passphrase instinct, notice, was the piece that aged best — the industry caught up to it and kept going.

The modern ladder: TOTP to passkeys

Above passwords, the second factor has its own quality ladder, worth climbing rung by rung. SMS codes are the weakest real rung — better than nothing, undermined by phone-number takeover (SIM-swap) attacks. TOTP (time-based one-time passwords — the six-digit authenticator-app codes) is the solid middle: at enrollment, the service and your app share a secret (that QR code is the secret — treat it like one); from then on, app and server each combine the secret with the current time to derive a code that changes every half minute. Something you have, offline, cheap. Its residual weakness: a convincing fake login page can still ask you to type the code, and relay it in real time — TOTP does not know where you are typing it.

Passkeys (FIDO2/WebAuthn) close exactly that gap, which is why they headline the 2026 landscape. A passkey is lesson 3's asymmetric pair, applied to login: enrolling creates a key pair per site; the public key goes to the service, and the private key stays under your control, never leaving your credential store in usable form (guarded by your fingerprint, face or PIN — factors composing: have plus are). Two flavors are worth telling apart. A device-bound passkey never leaves the hardware that made it: strongest, but lose the device and you lose the credential. A synced passkey lives in a credential manager and is replicated end-to-end-encrypted across your devices — the common consumer form, which survives a lost phone at the price of also trusting the sync provider. NIST's current guidance covers both. Login is a signature challenge, not a shared secret: nothing to phish out of you, nothing reusable in a database dump, and — the decisive property — the credential is bound to the site's real identity, so a lookalike page fails cryptographically no matter how convincing it looks to you. Passkeys crossed from novelty to mainstream in the mid-2020s; as of 2026, industry tallies (FIDO Alliance and platform vendors) put passkeys in active use in the billions, with sign-in support across the major platforms and browsers you already use. The password is not dead — but for the first time, its successor is shipping at scale.

The AAA back office: RADIUS, TACACS+, Kerberos

Who actually does the checking when you authenticate to a network? Three names, three niches — plus a promise kept.

RADIUS (Remote Authentication Dial-In User Service — the name preserves its dial-up birth) is the network world's AAA workhorse: when you join enterprise Wi-Fi or a VPN, the access point or gateway does not know your password — it relays your credentials to a RADIUS server, which authenticates, authorizes and accounts in one transaction. This is the machinery behind 802.1X, the port-based admission control Module 3 promised when it admitted port security was hygiene rather than authentication: the switch port or AP acts as a doorman, passing your credentials (at the strong end, an EAP-TLS certificate exchange — lesson 3's key pairs again) to RADIUS for the real decision. Guest VLAN or full access, assigned at the moment of admission.

TACACS+ is RADIUS's sibling with a different specialty — and a small kindness to perform on the way in: the book's text renders the acronym as "TACAS"; the protocol's actual name is TACACS+ (Terminal Access Controller Access-Control System Plus — an easy one to drop a C from, and the expansion survives the typo intact). Cisco-lineage, it dominates device administration: controlling and logging what network administrators may do on routers and switches, with finer per-command authorization than RADIUS offers. Rule of thumb: RADIUS admits users to networks; TACACS+ governs admins on equipment.

Kerberos you met last lesson: ticket-based, symmetric-key single sign-on inside organizations — sign in once, present tickets everywhere, passwords stop crossing the network. Windows domains run on it to this day.

And the third A earns its own moment, because the book's accounting example is a small masterpiece of the healthy paranoia from lesson 1 — retold: server logs showed a login attempt against a manager's account, after hours, at the same time each night for weeks. The accounting logs also held the manager's badge-out times — consistently earlier. Two log streams, one conclusion: someone else was trying the manager's credentials. No firewall fired, no alarm sounded; a person reading logs caught it. Accounting is deterrence (the policy says you are being logged), diagnosis, and — as here — detection. Logs no one reads are the third A unplugged; Module 8 returns to make reading them systematic.

Access control models: four ways to say who may

Authorization at scale needs a model — a consistent scheme for deciding permissions. Chapter 15's four are still the foundation, and 2026 adds a fifth:

• Mandatory Access Control (MAC) — the system enforces security labels (classifications on data, clearances on people); not even a file's creator can override the label. Government, military, and anywhere policy must outrank ownership. (Third meaning of "MAC" in this course — context disambiguates, as the book cheerfully warns.)
• Discretionary Access Control (DAC) — the owner decides: you created the file, you grant access, typically via ACLs on the resource. Flexible, human-scaled — and dependent on every owner's judgment.
• Rule-based access control — device-enforced conditions: the ACLs you wrote in lesson 2, time-of-day rules, source-address restrictions. No one asks who owns anything; the rule fires for everyone.
• Role-Based Access Control (RBAC) — permissions attach to roles (jobs), and people hold permissions by holding roles. Join the support desk, receive the support desk's access; transfer out, lose it. RBAC operationalizes least privilege — everyone holds exactly what the role needs, nothing more — and it is how organizations of any size stay administrable.
• Attribute-Based Access Control (ABAC) (the 2026 addition) — the decision is computed per request from attributes: who you are, on what device, from where, at what hour, at what risk score. Where RBAC asks "what is your job?", ABAC asks "what is true right now?" This is the model zero trust actually runs on (lesson 1), and it is what a modern conditional-access policy — "finance staff, managed device, MFA within the hour" — is underneath.

The book's printer case shows the models layering, and it rewards retelling: marketing's team group is nested into a "color printer users" group on the domain controller, so joining the team grants printing automatically — RBAC. Then a router rule permits only the marketing VLAN to reach the printer's address at all — rule-based control, stopping stray traffic before authorization is even consulted, saving bandwidth and server work. Two models, two layers — lesson 1's motto again, applied to a printer.

From the textbook to 2026

What holds from Chapter 15: AAA and CIA as the organizing frames, the authentication/authorization distinction, MFA's multiplication logic, the passphrase instinct, the accounting-as-detection example, and the four-model access taxonomy — a remarkably durable chapter. What changed: password policy inverted from "expire and complicate" to NIST's shall-nots (length plus blocklists, change on evidence); the second factor climbed from tokens to TOTP to passkeys/FIDO2 at billion-scale; 802.1X/EAP-TLS became the enterprise admission standard the book's era was still reaching toward; the access-control taxonomy gained a fifth member in ABAC, the model zero trust is built on; and one acronym got its missing C back. The frames were right; the settings needed updating.

Activity: Turn on a second factor — and document the flow

Security you have configured yourself sticks better than security you have read about. You will enable TOTP or a passkey on a real account you own, and produce the kind of enrollment documentation an IT department would.

Objective. Enroll a second factor (TOTP app or passkey) on one of your accounts; document the flow privacy-safely; verify recovery works.

Setup. An account you own with MFA support (Google, Microsoft, GitHub and most major services qualify — look for Security in account settings). For TOTP: an authenticator app on your phone. For a passkey: a phone or laptop with a screen lock set. Plus your notes file.

Privacy rules (before anything else). Do not screenshot or copy the TOTP QR code or setup key — that QR is the shared secret; photographing it into your camera roll creates a copy you do not control. Never store recovery codes in the same place as your password. Your documentation records steps and choices, never secrets.

Steps.

1. In the account's security settings, find second-factor options (names vary: "2-Step Verification," "Two-factor authentication," "Passkeys"). List in your notes which factor types this service offers — you can now classify each one.
2. Choose your path: TOTP — add an authenticator app; the service shows a QR code; scan it in the authenticator app (not the camera roll); enter the app's current six-digit code to confirm. Passkey — choose "create a passkey"; your device prompts for its screen-lock verification; enrollment completes in seconds (note how little there was to transcribe — nothing shared, that is the design).
3. Recovery codes: if offered, generate them, and store them offline (printed, or in your password manager's secure notes) — losing your phone must not mean losing the account. Record where they live, not what they say.
4. Sign out. Sign back in. Experience the new flow end to end and time it roughly — you will use this number in your write-up.
5. Document the enrollment as a numbered flow (five to eight steps), plus three fields: factor type and class (have/are/know, or a composition); what a lost phone would require of you tomorrow; what surprised you.

Deliverable. The documented flow with its three fields — no secrets anywhere in it.

Self-check. Your write-up should answer yes to: could a colleague repeat the enrollment from your steps alone? Does it state the factor's class correctly? Does it name the recovery plan? Sign-in cost is typically seconds — if your notes show the new flow costs less time than finding your keys in a bag, you have discovered why the "MFA is too annoying" objection rarely survives contact with MFA.

If it goes wrong. TOTP codes rejected: the phone's clock has drifted — enable automatic time; the codes are computed from the time. No passkey option: the service may not support it yet, or the device lacks a screen lock — set one, or fall back to TOTP (still excellent). Workplace account refuses changes: managed accounts often reserve security settings to the administrator — use a personal account; the lesson transfers. Lost recovery codes already: generate a fresh set now (old sets invalidate) — that is why you test recovery on a calm day.

Check yourself

1. Classify each as know / have / are — or a composition: a passphrase · a smart card · a fingerprint · a TOTP app on your phone · a passkey unlocked by your face · your mother's maiden name.
2. A new IT manager proposes 90-day forced password changes and mandatory symbols, "like we've always done." Advise them, citing current guidance by name — and propose the three controls that replace those rules.
3. An auditor finds: logins require password plus a four-digit PIN, both memorized. The policy binder claims MFA. Rule on the claim, with the one-word reason — then suggest the cheapest genuine fix.
4. Match the back office: enterprise Wi-Fi checks your login against a central server before the port opens · router admins' every command is authorized and logged · one morning sign-in unlocks the file server, printer and intranet without further prompts. Name the three technologies, and the Module 3 promise the first one keeps.
5. A phishing page perfectly clones your bank, and the victim is diligent: types the password, then the fresh TOTP code. Trace why the attack still works — then explain the property that makes the same attack fail against a passkey.
6. Using the scenario table's logic: a hospital wants ward nurses to see patients on their ward only, with access following staff between wards automatically, and one consultant to share a draft research note with two colleagues of her choosing. Which models combine, and where?

Answers

1. Passphrase — know. Smart card — have. Fingerprint — are. TOTP app — have (the phone holds the secret; the code proves possession). Passkey via face — composition: have (the device's private key) plus are (the biometric unlocking it). Maiden name — know, and a poor one: discoverable, unchangeable, shared with genealogy sites.
2. Current guidance — NIST SP 800-63B-4 — says verifiers shall not force periodic changes or composition rules: both trained users into predictable patterns that attackers model. Replace with: length-friendly policy favoring passphrases; blocklists rejecting breached and common passwords; and MFA above it all — change passwords on evidence of compromise, not on a calendar.
3. Not MFA — same class: two things you know. One database breach or one thorough phishing page captures both. Cheapest genuine fix: add a second class — TOTP apps cost nothing and turn the PIN's false comfort into a real second factor.
4. RADIUS (behind 802.1X — the real admission control Module 3 promised when port security's MAC-based limits showed) · TACACS+ (per-command device administration — with its restored C) · Kerberos (ticket-based single sign-on).
5. TOTP proves you hold the secret, not where you are typing: the phishing page relays password and code to the real bank in real time and rides the session. A passkey never types anything: it answers a signature challenge bound to the site's real identity, and the clone's identity does not match — the credential simply will not fire for the wrong site, however convinced the human is.
6. Ward access is RBAC — permissions attached to ward-nurse roles, following staff automatically on transfer (least privilege, administrable at scale). The consultant's draft is DAC — the owner granting two chosen colleagues access. A layer of rule-based control (ward VLANs reaching ward systems only) underneath would be the printer case's lesson applied to a hospital.

Key terms

• AAA — authentication (prove identity), authorization (grant permissions), accounting (record activity): the operational frame.
• CIA triad — confidentiality, integrity, availability: the goals frame.
• Authentication factor — a class of proof: something you know, have, or are; MFA requires two different classes.
• Biometrics — something-you-are factors (fingerprint, face, iris); unchangeable, so stored carefully and paired, not solo.
• NIST SP 800-63B-4 — current password guidance (2025): no forced expiry, no composition rules; length, blocklists and MFA instead.
• Passphrase — a long, memorable multi-word secret; the book's best-aging password advice, now the recommended form.
• TOTP — time-based one-time codes from a shared secret plus the clock; the authenticator-app rung of the ladder.
• Passkey / FIDO2 — per-site asymmetric credentials, device-held and origin-bound; phishing-resistant sign-in at billion-scale (current).
• RADIUS / 802.1X / EAP-TLS — central network AAA; port-based admission control; certificate-based authentication at its strong end.
• TACACS+ — device-administration AAA with per-command control (the book's "TACAS," C restored).
• Kerberos — ticket-based symmetric single sign-on inside organizations.
• MAC / DAC / rule-based / RBAC — the four authorization models: system-enforced labels · owner discretion · device conditions · permissions-follow-roles.
• Least privilege — grant exactly what the role requires; RBAC's operating principle and zero trust's daily practice.

Summary

• AAA says what identity systems do — authenticate, authorize, account; CIA says why — confidentiality, integrity, availability; the house-key story keeps the first two As honest.
• Factors come in three classes — know, have, are (biometrics are are, gently refiling the book's slip) — and MFA's power is multiplication across classes, not addition within one.
• Password orthodoxy inverted: NIST SP 800-63B-4 forbids forced expiry and composition rules; length, breach blocklists and password managers won; the book's passphrase instinct aged best of all.
• The second-factor ladder climbs SMS → TOTP → passkeys; passkeys' origin-binding defeats the real-time phishing that TOTP cannot, and they are mainstream as of 2026.
• The back office: RADIUS admits users (802.1X keeping Module 3's promise), TACACS+ governs admins, Kerberos hands out tickets — and accounting catches what prevention misses, if someone reads the logs.
• Four authorization models — MAC, DAC, rule-based, RBAC — and real designs layer them, from the book's printer to a hospital ward.
• You enrolled a second factor on a real account and documented it like a professional — without leaking a single secret into your notes.

Next lesson

Identity solved, distance remains: your authenticated, encrypted traffic still has to cross the open Internet to reach the office. VPNs and tunneling — the submarine returns from Module 1 — plus the post-mortem of a protocol whose death took twenty-five years, and the modern stack that replaced it.

Sources and further study

• Al-Doori, T., Network Essentials, Chapter 15 — AAA/CIA, factors, password craft, RADIUS/TACACS+/Kerberos and the access-control taxonomy this lesson preserves and updates.
• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management — https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf — the shall-nots, from the source.
• FIDO Alliance, "Passkeys" — https://fidoalliance.org/passkeys/ — how passkeys work and the adoption picture, maintained by the standard's home.
• Verizon, 2026 Data Breach Investigations Report — https://www.verizon.com/business/resources/reports/dbir/ — the credential-abuse numbers that make this lesson's controls urgent; lesson 6 completes that picture.