5.6 Authentication Systems
5.6 Authentication Systems
Authentication systems verify that a person, device, application or service legitimately controls the identity it claims.
The security of authentication depends on more than the authenticator itself. It also depends on the protocol, credential store, trust relationships, network path, session handling and the systems making the authentication decision.
Identity
Determine which person, device or service is claiming access.
WHO?Proof
Verify possession or control of an appropriate authenticator.
PROVE ITTrust
Establish an authenticated state that other components can rely on.
TRUST THE RESULTImplement Authentication Systems
Unlike several other Domain 5 objectives, the current CISSP Exam Outline does not provide additional sub-bullets beneath objective 5.6.
Understanding the objective therefore requires understanding how authentication systems and protocols are designed, implemented and protected.
Understand where identities and credentials are verified.
Use shared authentication infrastructure rather than independent credentials everywhere.
Ticket-based authentication using a trusted Key Distribution Center.
Understand RADIUS and TACACS+ for network and device access.
Understand how identity repositories such as LDAP directories participate in authentication.
Understand extensible authentication for network-access scenarios.
Understand certificates, keys and challenge-response mechanisms.
Design for availability, logging, secure failure and attack resistance.
The Big Idea
An authentication system is not simply a password box.
It is a chain of trust.
Authentication Chain
🧩 Components of an Authentication System Understand the complete authentication path
The person or entity claiming an identity.
Something used to authenticate, such as a password, security key, certificate or cryptographic credential.
The system that validates the authentication evidence.
Stores or supplies information about recognised identities where required.
Defines how authentication information is exchanged.
May represent the authenticated state after successful authentication.
Authentication Factors - Quick Recap
KNOWLEDGE
POSSESSION
INHERENCE
The factors were introduced in 5.2. Here the important question is how authentication infrastructure securely verifies those factors and communicates the result.
Local vs Centralised Authentication
The individual system maintains and verifies its own identities or credentials.
A standalone server maintains its own administrator accounts.
Multiple systems rely on shared authentication infrastructure.
Corporate systems authenticate users through a central directory or authentication service.
Centralisation Benefits
Centralisation Risks
Central Authentication
🔤 Password Authentication Systems Passwords should be verified without requiring plaintext storage
A password-verification system should not need to store a reusable plaintext copy of every user's password.
Its purpose includes ensuring that identical passwords do not automatically produce identical stored verifier values and reducing the effectiveness of precomputed attacks.
Encryption is designed to be reversible with an appropriate key.
Password verification should normally use an appropriate one-way password hashing or derivation scheme rather than storing reversible plaintext equivalents.
🧨 Online vs Offline Password Attacks The defensive controls are different
The attacker sends authentication attempts to the real authentication service.
The attacker obtains password-verifier data and guesses passwords without interacting with the live authentication service.
Password Attack Memory
Challenge-Response Authentication
Challenge-response systems allow a verifier to challenge the claimant, who must produce a response demonstrating knowledge or possession of a secret without simply replaying the same static authentication value.
An authentication response captured from one exchange should not automatically be valid for a completely different challenge.
Kerberos
Kerberos is a trusted third-party network authentication system that uses symmetric cryptography and tickets to authenticate principals across an untrusted network.
Instead of repeatedly sending a user's password to every service, Kerberos allows the user to obtain tickets that can be presented to services.
Kerberos Core Idea
Password → TGT → Service Ticket → Service
🎫 Kerberos Components KDC · AS · TGS · TGT · Service Ticket
A Kerberos identity such as a user or service.
The administrative Kerberos domain in which principals exist.
The trusted Kerberos service responsible for issuing tickets.
Handles the initial authentication process and provides access to the ticket-granting process.
Issues tickets for individual services after an appropriate TGT is presented.
Allows the authenticated principal to request additional service tickets without repeatedly supplying the original user authenticator.
A ticket intended for a specific network service.
Fresh authentication information used with tickets to help establish that the ticket is being presented by the appropriate principal.
Alice Accesses a File Server
🧠 Kerberos Memory Aid The most important sequence to remember
Kerberos
🛡️ Kerberos Security Characteristics Tickets solve some problems but create their own valuable authentication material
The KDC plays a central trust role.
Kerberos fundamentally relies on shared-secret cryptography, although extensions can add other mechanisms.
Services can rely on tickets rather than requiring users to repeatedly transmit their original password.
Kerberos uses time-sensitive authentication information, making reliable clock synchronisation important.
Kerberos can support authentication of the service to the client as well as the client to the service.
KDC security and availability are critical to the environment.
Protect TGTs and service tickets because an attacker may attempt to reuse stolen authentication material without learning the original password.
🎭 Kerberos Attack Recognition Think stolen trust, not necessarily broken encryption
An attacker obtains legitimate Kerberos ticket material.
A stolen valid ticket is reused to impersonate the authenticated principal.
Poorly protected service secrets can expose authentication relationships.
Compromise of central Kerberos trust infrastructure can have a broad impact.
Many practical attacks target credentials, tickets, endpoints or trusted secrets rather than mathematically defeating the protocol's cryptography.
⏰ Why Time Matters in Kerberos Freshness helps prevent replay
Kerberos uses time-sensitive information when authenticating requests.
Significant clock differences between systems can therefore cause legitimate authentication to fail.
Client clock: 10:02
Authentication infrastructure: 14:47
Even valid credentials may not result in successful Kerberos authentication because the time information is inconsistent.
Kerberos Requirements
AAA Authentication Systems
Network environments often centralise Authentication, Authorization and Accounting through AAA infrastructure.
AAA
RADIUS
Remote Authentication Dial-In User Service - RADIUS - provides centralised authentication and authorization information for network access.
Separate RADIUS accounting functionality can record information about network-access sessions.
RADIUS
📡 RADIUS Access Flow Request · Accept · Reject · Challenge
The access device acts as a RADIUS client and communicates with the central RADIUS server on behalf of the connecting user or device.
TACACS+
TACACS+ is a centralised AAA protocol widely associated with administrative access to network devices.
One of its key architectural characteristics is that authentication, authorization and accounting are separate functions.
TACACS+
RADIUS vs TACACS+
| RADIUS | TACACS+ | |
|---|---|---|
| Think | Network access | Network-device administration |
| Typical Users | Employees / devices joining network | Administrators managing devices |
| AAA Design | Authentication and authorization commonly occur within the access exchange; accounting is separately defined | Authentication, authorization and accounting explicitly separated |
| Fine-Grained Commands | Not its primary device-administration strength | Strong device-command authorization use case |
| Classic Transport | UDP | TCP |
| Classic Port | 1812 authentication/authorization | 49 |
| Accounting | 1813 | Part of TACACS+ AAA suite |
RADIUS vs TACACS+
🔒 Modern TACACS+ Transport Security Do not rely on the old textbook shorthand
Traditional TACACS+ implementations used a legacy obfuscation mechanism rather than modern transport encryption.
Current IETF guidance defines TACACS+ over TLS 1.3 to protect communications between TACACS+ clients and servers.
RFC 9887 defines TACACS+ over TLS 1.3 and replaces the old obfuscation mechanism when using the TLS transport profile.
Older study material often describes TACACS+ simply as "encrypting the whole payload".
For current security architecture, treat legacy TACACS+ protection as insufficient and recognise that secure transport matters.
Current TACACS+
LDAP
Lightweight Directory Access Protocol - LDAP - provides a standard protocol for accessing and managing directory information.
Directories commonly contain identity information such as users, groups, organisational structure and other attributes.
LDAP can participate in authentication, including through its Bind operation, but do not confuse the directory protocol itself with an entire IAM or Single Sign-On architecture.
LDAP
📚 Directory Authentication Example An application relies on a central identity repository
Authentication exchanges and directory information can be sensitive. Appropriate transport protection and server validation are important.
Extensible Authentication Protocol - EAP
EAP is an authentication framework designed to support multiple authentication methods.
It is commonly encountered in network-access environments such as enterprise wired and wireless authentication.
EAP
🔌 802.1X Authentication Architecture Supplicant · Authenticator · Authentication Server
Enterprise network authentication commonly separates three roles.
The endpoint or client requesting network access.
The network-access device controlling access, such as a switch or wireless access point.
The backend system making the authentication decision, commonly reached through AAA infrastructure such as RADIUS.
802.1X Roles
📜 EAP-TLS Certificate-based network authentication
EAP-TLS uses TLS within the EAP framework and supports certificate-based mutual authentication and key establishment.
A certificate should not be trusted merely because a certificate is present. The trust chain, identity, validity and applicable status information must be evaluated according to policy.
Certificate-Based Authentication
Public-key authentication can prove possession of the private key associated with a trusted certificate.
Certificate Authentication
Certificates normally contain public information.
Authentication requires proof that the claimant controls the corresponding private key.
💳 Smart Cards & Hardware Authenticators Protect cryptographic credentials in dedicated hardware
Smart cards and hardware security authenticators can securely hold cryptographic key material used during authentication.
A smart card stores a user's private authentication key.
The user activates the card with a PIN.
The private key performs the cryptographic authentication operation without needing to be exposed as a reusable password.
Smart Card + PIN
One-Way vs Mutual Authentication
One party proves its identity to another.
Client authenticates the server.
Both parties authenticate each other.
Client validates server and server validates client.
Verifying the user while allowing the user to communicate with an unverified server can leave opportunities for impersonation and man-in-the-middle attacks.
Authentication Assurance
Different systems carry different consequences if authentication is wrong.
| Resource | Authentication Consideration |
|---|---|
| Public Information | Authentication may not be required |
| Employee Portal | Organisational authentication appropriate |
| Customer Banking | Stronger assurance appropriate |
| Production Administration | Strong authentication and privileged controls |
| Critical Trust Infrastructure | Very high authentication assurance and additional safeguards |
The correct design question is not simply "Do we have MFA?"
It is:
"Is the authentication system strong enough for this risk?"
Authentication Availability
Centralised authentication infrastructure can become a critical business dependency.
One authentication platform provides access to:
The authentication platform becomes unavailable.
Many otherwise healthy systems can now become inaccessible.
Resilience Considerations
Authentication Availability
🛟 Fallback Authentication Availability mechanisms must not become security bypasses
Normal authentication requires:
central MFA.
If the authentication server fails:
every user is allowed in automatically.
Possible Controlled Alternatives
💾 Cached Authentication Useful for resilience but changes revocation behaviour
Some endpoints can authenticate users using securely cached information when the central identity service is temporarily unavailable.
Cached authentication can allow an employee to use a laptop when disconnected from the corporate network.
However, changes made centrally may not be reflected immediately in the offline authentication decision.
Cached Authentication
Authentication Logging
Authentication systems provide high-value security telemetry.
One user account successfully authenticates from London.
Minutes later, hundreds of failures appear from unrelated systems.
Authentication telemetry can support detection and investigation of suspicious activity.
Logs can contain sensitive identity, infrastructure and security information.
🚦 Rate Limiting & Authentication Throttling Make automated guessing harder without creating unnecessary denial of service
Authentication services should consider controls against repeated automated authentication attempts.
Attackers may intentionally trigger lockouts against legitimate users. Authentication controls should consider both credential attacks and availability.
What Are We Defending Against?
Try many possible authentication values.
Try a small number of likely passwords across many accounts.
Reuse credentials exposed by other services.
Trick users into revealing or using credentials with an attacker.
Reuse captured authentication data.
Interpose between authentication participants.
Steal the authenticated state after login succeeds.
Steal reusable authentication material such as Kerberos tickets.
Attack password verifiers, keys or secrets at the authentication backend.
Compromise the system trusted to decide who is legitimate.
🔁 Replay Resistance A captured valid authentication should not automatically work forever
Authentication protocols can use freshness mechanisms to prevent old authentication exchanges from simply being reused.
Replay Defence
🌐 Authenticate the Authentication Server Do not send credentials to an untrusted verifier
A user is asked for credentials by what appears to be the corporate authentication service.
If the client does not verify the server, an attacker may impersonate the authentication infrastructure and collect credentials.
Protocols supporting server authentication or mutual authentication can help ensure that users and devices are communicating with the intended authentication service.
🕰️ Legacy Authentication Compatibility can preserve insecure authentication paths
Organisations frequently support older authentication protocols because legacy devices and applications cannot use modern mechanisms.
Modern authentication path:
certificate + strong cryptography + MFA.
Legacy fallback path:
reusable password through an older protocol.
An attacker will naturally prefer the weaker route.
Legacy Authentication
Machine & Service Authentication
Authentication systems must verify more than human users.
Application A requests sensitive customer information from API B.
API B should establish:
"Which workload is calling me?"
before performing authorization.
Certificates, cryptographic workload identities and short-lived credentials can reduce dependence on hard-coded shared passwords.
Enterprise Authentication Architecture
An employee arrives at the office with a managed laptop.
The Password Is Not the Weak Point
An organisation deploys strong passwords and MFA.
Legacy authentication remains enabled.
Server identity is not validated.
Authentication sessions are poorly protected.
Central authentication logs are never monitored.
Authentication-service failure automatically bypasses access control.
Service accounts contain embedded long-lived passwords.
User Authentication Succeeds but Service Access Fails
Kerberos may correctly authenticate the identity while the target service still denies the requested operation.
RADIUS or TACACS+?
Employees authenticate before joining the corporate wireless network.
Think RADIUS.
Network administrators log into routers and individual administrative commands require central authorization and auditing.
Think TACACS+.
Fast Recognition
🎓 CISSP Scenarios Identify the authentication system or principle
A standalone server verifies credentials using its own account database.
Which architecture?
Local authentication.
Hundreds of applications use one corporate authentication infrastructure.
Which architecture?
Centralised authentication.
Failure of one central authentication platform prevents users from accessing many otherwise healthy applications.
Which risk?
Authentication availability / concentration risk.
When central authentication fails, every user is automatically permitted access.
Primary concern?
Insecure fail-open authentication design.
An emergency administrator identity exists for use when central authentication is unavailable and its use is tightly monitored.
Which concept?
Controlled break-glass authentication.
The system stores reusable plaintext copies of every user's password.
Primary concern?
Poor password-verifier storage.
Each stored password verifier uses a unique random value so identical passwords do not automatically produce identical stored values.
Which mechanism?
Salt.
An attacker repeatedly tries credentials against the live login service.
Which attack category?
Online authentication attack.
An attacker steals password-verifier data and performs billions of guesses without contacting the authentication server.
Which attack category?
Offline password attack.
A verifier sends a fresh random value and the claimant computes a response using a secret.
Which authentication concept?
Challenge-response.
A user authenticates once and receives a Ticket Granting Ticket.
Which authentication system?
Kerberos.
Alice wants a ticket for a file server and already possesses a valid TGT.
Which Kerberos service does she contact?
Ticket Granting Service - TGS.
A principal needs initial Kerberos authentication before obtaining a TGT.
Which Kerberos component?
Authentication Service - AS.
A user presents a Kerberos ticket specifically intended for a database service.
Which ticket?
Service ticket.
An attacker steals a valid Kerberos ticket and attempts to reuse it without knowing the user's password.
Which attack pattern?
Pass-the-Ticket.
Kerberos authentication suddenly fails after a server's system clock becomes significantly inaccurate.
Which dependency?
Time synchronisation.
A security architect identifies the Kerberos KDC as a critical target.
Why?
It is a central trusted authentication component.
Employees authenticate before being permitted onto the enterprise wireless network.
Which AAA protocol is strongly associated?
RADIUS.
Network administrators authenticate to routers and individual commands can be centrally authorised and audited.
Which protocol?
TACACS+.
A protocol explicitly separates authentication, authorization and accounting and is primarily being used for network-device administration.
Which protocol?
TACACS+.
A RADIUS client asks a central server whether a connecting user should receive network access.
Which device commonly acts as the RADIUS client?
The Network Access Server / network access device.
An old study guide claims that classic TACACS+ protection should be considered equivalent to modern secure transport encryption.
Is this good current implementation guidance?
No.
Current standards define TACACS+ over TLS 1.3 for modern transport confidentiality, integrity and peer authentication.
A client queries a directory containing users, groups and identity attributes.
Which protocol is commonly associated?
LDAP.
A directory client exchanges authentication information with an LDAP server.
Which LDAP operation is associated with authentication?
Bind.
An engineer describes EAP as one specific password algorithm.
Is this correct?
No.
EAP is an extensible authentication framework supporting multiple methods.
An enterprise requires certificate-based mutual authentication for network access using EAP.
Which method fits?
EAP-TLS.
A workstation requesting 802.1X network access runs the client-side authentication software.
Which role?
Supplicant.
A network switch controls whether an endpoint is permitted through an 802.1X-controlled port.
Which role?
Authenticator.
A certificate is publicly available but the corresponding private key remains protected.
Can possession of the public certificate alone normally prove the identity?
No.
Authentication requires proof of control of the corresponding private key.
Both the client and server cryptographically verify one another.
Which concept?
Mutual authentication.
An attacker records an authentication response and tries to submit exactly the same value later.
Which threat?
Replay attack.
An authentication protocol uses a random challenge that is different for each authentication exchange.
Which property does this support?
Freshness / replay resistance.
Strong authentication succeeds but an attacker later steals the authenticated browser session.
Which lesson?
Authentication security must include protection of the resulting session.
An organisation uses modern MFA but still permits an older weaker authentication protocol against the same accounts.
Primary concern?
Authentication downgrade / weaker alternative path.
A service account uses the same hard-coded password on hundreds of servers.
Primary problem?
Poor machine-authentication credential design.
Authentication logs show thousands of attempts using one common password across many usernames.
Which attack pattern?
Password spraying.
Credentials stolen from an unrelated website are automatically tried against corporate accounts.
Which attack?
Credential stuffing.
Authentication systems permanently lock any account after two failed attempts.
Which additional risk should be considered?
Denial of service through intentional lockout.
A laptop can authenticate its usual employee locally while disconnected from corporate identity infrastructure.
Which mechanism may be involved?
Cached authentication.
An employee has been disabled centrally but their disconnected laptop still permits cached login.
Which trade-off is demonstrated?
Authentication availability versus immediate central revocation.
Recognise the Clue Words
Ticket-Based Authentication
Trusted third party.
KerberosInitial Kerberos Authentication
Obtain TGT.
ASGet Service Ticket
Present TGT.
TGSTicket Gets Tickets
Reusable within lifetime.
TGTTicket Gets Service
Intended for application.
Service TicketKerberos Clock Problem
Freshness dependency.
Time SynchronisationStolen Kerberos Ticket
Reuse authentication material.
Pass-the-TicketJoin Network
Central AAA.
RADIUSAdminister Router
Device administration.
TACACS+Per-Command Authorization
Device administration.
TACACS+User Directory
Query identity objects.
LDAPLDAP Authentication Operation
Authenticate to directory.
BindMultiple Network Auth Methods
Extensible framework.
EAPCertificate Network Authentication
Mutual certificate authentication.
EAP-TLSEndpoint Wants 802.1X Access
Client side.
SupplicantSwitch Controls Port
Controls admission.
AuthenticatorBackend Checks Identity
Makes authentication decision.
Authentication ServerBoth Parties Verify
Two-way trust.
Mutual AuthenticationCaptured Response Reused
Old authentication reused.
ReplayRandom Fresh Value
Prevent replay.
Challenge / NonceCentral Auth Down
Many services affected.
Availability DependencyAuth Down → Everyone Allowed
Unsafe fallback.
Fail-Open RiskOffline Login
Local copy of authentication state.
Cached AuthenticationOld Protocol Still Enabled
Attacker picks weaker path.
Legacy Authentication Risk⚠️ Common CISSP Mistakes Authentication protocols contain many similar-looking terms
Identification makes the claim. Authentication verifies the claim.
Kerberos or another system may authenticate successfully while the application still denies the requested action.
Protocol, transport, verifier, session and recovery controls still matter.
Authentication systems should not rely on reversible plaintext password storage merely because it has been encrypted.
TGT obtains tickets.
Service ticket accesses a particular service.
AS handles initial authentication.
TGS issues service tickets.
Kerberos fundamentally uses trusted third-party authentication and symmetric cryptography, although extensions can involve public-key mechanisms.
An attacker may abuse existing authentication material without discovering the user's plaintext password.
RADIUS is strongly associated with network access.
TACACS+ is strongly associated with network-device administration.
Current standards define TACACS+ over TLS 1.3 for modern transport protection.
LDAP provides directory access. An SSO architecture may use a directory but is a separate concept.
A directory is one component of a broader identity and access architecture.
EAP is a framework supporting different methods.
The authenticator controls the network-access point.
The backend authentication server performs or supports the authentication decision.
A certificate normally contains public information. The corresponding private key must remain protected.
Attackers may target authentication tokens, tickets or sessions after legitimate authentication succeeds.
Central identity systems can become critical dependencies.
Automatically allowing users when authentication fails can transform an availability incident into a security breach.
Offline authentication can introduce a delay before centrally applied changes affect the endpoint.
Devices, applications and services require authentication too.
Authentication Systems Quick Reference
| System / Protocol | Main Purpose | Think |
|---|---|---|
| Kerberos | Ticket-based network authentication | TICKETS |
| RADIUS | Central AAA for network access | JOIN NETWORK |
| TACACS+ | AAA for device administration | ADMIN NETWORK |
| LDAP | Directory access | DIRECTORY |
| EAP | Extensible authentication framework | FRAMEWORK |
| EAP-TLS | Certificate-based EAP authentication | CERTIFICATES |
| 802.1X | Port-based network access control architecture | NETWORK DOOR |
| Certificate Authentication | Proof of private-key possession | PRIVATE KEY |
Quick Reference
| If you see... | Think... |
|---|---|
| Local user database | Local Authentication |
| Shared enterprise identity service | Centralised Authentication |
| One central auth service fails | Availability Dependency |
| Password + random unique stored value | Salt |
| Guess against live login | Online Attack |
| Steal verifier and guess locally | Offline Attack |
| Fresh random challenge | Challenge-Response |
| Trusted third party + tickets | Kerberos |
| Initial Kerberos authentication | AS |
| Obtain service ticket | TGS |
| Ticket used to request other tickets | TGT |
| Ticket presented to application | Service Ticket |
| Kerberos suddenly fails with bad clock | Time Synchronisation |
| Stolen Kerberos ticket reused | Pass-the-Ticket |
| Wi-Fi / VPN network authentication | RADIUS |
| Router administrator AAA | TACACS+ |
| Fine-grained device commands | TACACS+ |
| Directory query | LDAP |
| Authenticate to LDAP directory | Bind |
| Extensible network authentication | EAP |
| Certificate-based EAP | EAP-TLS |
| Endpoint requesting 802.1X access | Supplicant |
| Switch/AP controlling access | Authenticator |
| Backend verifies network identity | Authentication Server |
| Both sides authenticate each other | Mutual Authentication |
| Old valid authentication reused | Replay |
| Authenticated browser token stolen | Session Theft |
| One common password against many users | Password Spraying |
| Stolen passwords tried elsewhere | Credential Stuffing |
| Authentication unavailable → access allowed | Fail-Open Risk |
| Offline endpoint login | Cached Authentication |
Kerberos Memory Aid
AS → TGT → TGS → Service Ticket → Service
Network Authentication Memory Aid
802.1X Memory Aid
Client → Door → Decision
Authentication System Security
5.6 Master Memory Aid
The Authentication Architect's Questions
Key Takeaways
The current CISSP 5.6 objective is simply: Implement authentication systems.
Unlike several other Domain 5 objectives, ISC2 does not provide additional official sub-bullets for this objective.
Authentication verifies that a claimant legitimately controls the identity being presented.
A strong authentication system includes the authenticator, protocol, verifier, credential store, trust architecture and resulting session - not merely the login screen.
Authentication can be performed locally by an individual system or centrally through shared identity infrastructure.
Central authentication improves consistency, lifecycle management and visibility but creates a valuable and potentially critical dependency.
Password-verification systems should avoid storing reusable plaintext passwords.
Password salts help ensure that identical passwords do not automatically have identical stored verifier representations and reduce the usefulness of precomputed attacks.
Online password attacks target the live authentication service. Offline attacks target stolen password-verifier information.
Challenge-response mechanisms use a changing challenge so a previously captured response cannot simply be reused for every future authentication.
Kerberos is a trusted third-party ticket-based network authentication system fundamentally based on symmetric cryptography.
The Key Distribution Center is the central trusted component in a Kerberos environment.
Kerberos memory: AS → TGT → TGS → Service Ticket → Service.
The Authentication Service handles initial Kerberos authentication.
A Ticket Granting Ticket allows a principal to request additional service tickets.
The Ticket Granting Service issues service tickets.
A service ticket is presented to the particular service the user wants to access.
Kerberos relies on time-sensitive authentication information, so clock synchronisation is an important operational dependency.
Kerberos can support mutual authentication between clients and services.
Kerberos tickets are authentication material and therefore need protection just like other valuable credentials.
Pass-the-Ticket attacks reuse stolen Kerberos ticket material rather than requiring the attacker to discover the original plaintext password.
RADIUS is strongly associated with centralised authentication and authorization for network access.
RADIUS accounting provides information about network-access sessions.
TACACS+ is strongly associated with administrative access to network devices.
Fast CISSP memory: RADIUS = get ON the network. TACACS+ = ADMINISTER the network.
TACACS+ explicitly separates authentication, authorization and accounting and supports fine-grained device-administration authorization.
Older descriptions of TACACS+ transport protection should not be confused with modern encryption.
Current IETF standards define TACACS+ over TLS 1.3 to provide confidentiality, integrity and peer authentication for TACACS+ communications.
LDAP is a protocol for accessing directory information and commonly participates in identity architectures.
The LDAP Bind operation can exchange authentication information between a directory client and server.
LDAP is not synonymous with Single Sign-On or with an entire IAM platform.
EAP is an extensible authentication framework capable of supporting multiple authentication methods.
EAP is commonly encountered in enterprise network-access authentication.
EAP-TLS provides certificate-based authentication and supports mutual authentication and key establishment.
In an 802.1X-style network-access architecture, the supplicant requests access, the authenticator controls the network access point and the authentication server supports the backend authentication decision.
802.1X memory: Supplicant = wants access. Authenticator = controls the door. Authentication Server = checks identity.
Certificate authentication requires proof of control of the private key associated with the certificate.
Possession of a public certificate alone does not establish possession of the corresponding private key.
Mutual authentication verifies both participants rather than only one side of the connection.
Freshness mechanisms such as challenges, nonces, timestamps and limited validity periods help resist replay.
Authentication systems should be designed for availability as well as confidentiality and integrity.
Failure of the authentication service should not silently convert into unauthenticated access.
Redundancy, replication and controlled emergency-access mechanisms can provide resilience without abandoning authentication policy.
Cached authentication can improve offline availability but may delay the effect of centrally applied revocation.
Authentication logs are important sources of security telemetry and can help identify brute force, password spraying, credential misuse and suspicious authentication patterns.
Rate limiting and similar controls can reduce automated guessing, but lockout mechanisms should also consider denial-of-service risk.
Attackers may target credentials before authentication, the protocol during authentication or the resulting tickets and sessions after authentication.
Legacy authentication mechanisms can undermine newer controls when they provide an easier alternative path to the same identity.
Authentication systems must include non-human identities such as devices, applications, APIs and workloads as well as people.
Machine authentication should avoid unnecessary shared, embedded and long-lived credentials where stronger identity mechanisms are available.
The central CISSP principle is: authenticate the right entity using an appropriate mechanism, protect the authentication exchange, verify the authentication system itself, protect the resulting authenticated state, monitor its use and design secure behaviour for failure.
📚 Sources & Further Reading Current authentication-system standards and primary references
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-63B-4 - Authentication and Authenticator Management
View current NIST authentication guidance - RFC 4120 - The Kerberos Network Authentication Service Version 5
View the Kerberos V5 standard - RFC 2865 - Remote Authentication Dial-In User Service - RADIUS
View the RADIUS specification - RFC 2866 - RADIUS Accounting
View the RADIUS accounting specification - RFC 8907 - TACACS+ Protocol
View the TACACS+ specification - RFC 9887 - TACACS+ over TLS 1.3
View current secure TACACS+ transport guidance - RFC 4511 - Lightweight Directory Access Protocol - LDAP
View the LDAP protocol specification - RFC 3748 - Extensible Authentication Protocol - EAP
View the EAP specification - RFC 5216 - EAP-TLS Authentication Protocol
View the EAP-TLS specification - RFC 9190 - EAP-TLS 1.3
View current EAP-TLS 1.3 guidance