Network Security: Authentication and Key
Distribution Exam Notes 🔒
User Authentication and Protocol (CRITICAL PRIORITY)
1. User Authentication
User Authentication is the process of verifying a claimed identity.
Goals of Authentication
1. One-Way Authentication (Client → Server): The server verifies the identity of the client.
Common in basic login scenarios (user/password).
2. Mutual Authentication (Client ⇌ Server): Both entities verify each other's identities.
Essential for secure protocols like TLS and Kerberos, ensuring the client is talking to the
legitimate server.
Preventing Replay Attacks
A Replay Attack is a passive attack where a valid data transmission (or authentication token) is
maliciously or fraudulently repeated or delayed.
Mechanism Definition Role in Prevention
A unique, typically random, The client/server includes a fresh nonce in a
Nonce (Number
number or string used in a challenge. If the same nonce appears again, the
used once)
communication. subsequent message is rejected as a replay.
The received message must contain a timestamp
Using a time value to
close to the current system time (within a small
Timestamps establish the currency of a
tolerance). Old messages are discarded. Kerberos
message.
relies heavily on this.
The receiver tracks the expected sequence
Sequence A counter attached to each
number. Messages received out of order or with a
Numbers message in a stream.
previously seen number are discarded.
2. Kerberos Protocol
Kerberos is a network authentication protocol that allows users to prove their identity to network
services over a non-secure network using secret-key cryptography. It minimizes the need for a client
to repeatedly send its password.
Architecture Components
1. Client (C): The user's workstation seeking network services.
2. Authentication Server (AS): A server that knows the secret key of every client and server
in the domain. It performs the initial user authentication.
3. Ticket-Granting Server (TGS): Issues service-granting tickets to clients. It shares a secret
key with the AS.
4. Application Server (SS - Service Server): The server providing the requested resource
(e.g., file server, mail server).
Kerberos Protocol Flow (Version 5)
The goal is for the Client (C) to obtain a secure Ticket to access the Service Server (SS).
Step Component Action Description/Key Product
1. Authentication
Request for a
Service Exchange C→AS Client sends {C,TGS,Timestamp}.
TGT.
(AS)
Message 1: {Kc,tgs} encrypted with Kc
Send TGT and (Client's secret key). Message 2: The TGT
2. AS Reply AS→C
Session Key. ({Kc,tgs,C,Valid Time,TGS} encrypted with
Ktgs).
Client sends TGT (from M2),
3. Ticket-Granting
Request for a **Authenticator
Service Exchange C→TGS
Service Ticket. ({C,Timestamp} encrypted with Kc,tgs)}$
(TGS)
and SS.
Send Service Message 3: {Kc,ss} encrypted with Kc,tgs.
4. TGS Reply TGS→C Ticket and Message 4: The Service Ticket ({Kc,ss
Session Key. ,C,Valid Time,SS} encrypted with Kss).
Client sends Service Ticket (from M4) and
5. Client/Server Request for
C→SS **new Authenticator
Exchange (SS) Service Access.
({C,Timestamp} encrypted with Kc,ss)}$
6. SS Reply Mutual Server sends Authenticator Timestamp + 1
SS→C
(Optional) Authentication. encrypted with Kc,ss.
• Ticket: Encrypted information containing the client's identity and the session key, used to
prove identity without sending the password.
• Kc,tgs: Session Key shared between the Client and the TGS.
• Kc,ss: Session Key shared between the Client and the Service Server (SS).
Key Distribution Models (HIGH PRIORITY)
3. Symmetric Key Distribution
The challenge is distributing the Session Key (Ks) securely, as it must be shared by the two
communicating parties.
KDC-Based Approach (Key Distribution Center)
The KDC is a trusted third party (like the AS in Kerberos) that shares a unique secret key with
every registered user/server.
Method Description Security Mechanism
If Alice (A) wants to communicate with Bob
Using a Master (B), the KDC encrypts the session key Ks KDC sends to A: $\
Key twice: once for A using A's master key (Ka) mathbf{E_{K_a}}[K_s
and once for B using B's master key (Kb).
A secure protocol allowing two parties to
The shared secret calculated
Diffie-Hellman establish a shared secret session key over an
(K=gab(modp)) is used as the
Key Exchange insecure public channel without the need for
symmetric session key Ks.
prior shared secrets.
4. Public Key-based Distribution
In asymmetric cryptography, everyone knows the Public Key (PU), but it must be authenticated as
belonging to the claimed owner.
Distribution Models
Model Mechanism Vulnerability / Drawback
No inherent security; easily spoofed via a
Public Users broadcast their PU (e.g., in an Masquerade/MITM attack where an
Announcement email signature or on a website). attacker announces their own key
claiming to be the target.
The directory itself must be fully trusted
Publicly Available A trusted entity maintains a public
for integrity and authenticity (i.e., it must
Directory directory of all user $\text{PU}$s.
be secure against tampering).
A PKA issues certificates signed
PKA is a Single Point of Failure
with its own private key to
Public Key (SPOF). Requires on-line
authenticate user public keys.
Authority (PKA) communication to the PKA for every key
Clients must know the PKA's public
lookup.
key.
A third-party Certificate Authority
Requires a system for managing the CA
Public Key (CA) digitally signs a user's PU,
and revoking compromised certificates
Certificates (PKI) binding it to their identity. This is
(PKI).
the dominant model.
Public Key Infrastructure (PKI) and Certificates (CRITICAL
PRIORITY)
5. X.509 Certificates
An X.509 Certificate is a standard format for digital certificates that ensures a public key belongs
to the entity named within the certificate.
X.509 Certificate Structure (Critical Fields)
Field Description Purpose
Version Specifies the X.509 version (e.g., v3). Defines the format and fields used.
Used to track the certificate,
Serial Number Unique identifier issued by the CA.
especially for revocation.
Signature Algorithm used by the CA to sign the Tells the verifying party which
Algorithm ID certificate (e.g., SHA-256 with RSA). algorithm to use.
Issuer Name The name of the Certificate Authority that
Establishes the trust anchor.
(CA) issued and signed the certificate.
The start and end dates/times for which the Prevents using expired or future-
Validity Period
certificate is valid. dated certificates.
The name (ID) of the entity whose public
Subject Name key is being certified (e.g., domain name, The identity being verified.
user name).
Subject Public The certified Public Key and the algorithm
The payload of the certificate.
Key Info it uses.
Issuer Unique ID
A unique identifier for the issuing CA. (Deprecated in modern versions).
(Optional)
Standard or proprietary fields (e.g., Key Provides additional constraints and
Extensions (v3)
Usage, Subject Alternative Name). information.
Used by the verifier to prove the
The digital signature created by the CA's
CA Signature certificate's authenticity and
Private Key over the entire certificate.
integrity.
Certificate Validation and Revocation
• Validation:
1. Verify the CA Signature using the CA's Public Key.
2. Check the Validity Period (must be current).
3. Check if the Subject Name matches the entity being verified.
4. Check the certificate's revocation status.
• Certificate Revocation: The process by which a CA invalidates an active certificate before
its scheduled expiration date (e.g., if the private key is compromised).
1. CRL (Certificate Revocation List): A time-stamped, digitally signed list issued by
the CA containing the serial numbers of all revoked certificates. Clients check this
list to ensure a certificate hasn't been revoked.
6. PKI Components and Trust
Public Key Infrastructure (PKI) is the set of hardware, software, people, policies, and procedures
needed to create, manage, distribute, use, store, and revoke digital certificates.
Core Components
1. Certificate Authority (CA): The trusted entity that digitally signs and issues certificates. It
is the root of trust in the PKI. Examples: DigiCert, Let's Encrypt.
2. Registration Authority (RA): Verifies the identity of the certificate applicant (Subject)
before instructing the CA to issue the certificate. It offloads the identity verification burden
from the CA.
3. Certificate Repository: A secure, publicly accessible database where certificates and CRLs
are stored for retrieval by users.
Trust Hierarchy/Chain of Trust
A hierarchical structure where trust flows down from a single, highly secured Root CA.
• Root CA: Self-signed, topmost CA. Its public key must be manually trusted by all users
(often pre-installed in browsers/OS).
• Intermediate CAs: Issued and signed by the Root CA (or another Intermediate CA). They
issue certificates to end entities. This structure protects the highly sensitive Root CA key
from compromise.
• Chain of Trust: A certificate is validated by tracing its issuer back up to a trusted Root CA.
If all certificates in the path are valid, the end-entity certificate is trusted.
Identity Management and Federation (MEDIUM PRIORITY)
7. Identity Management and Federation
• Identity Management (IdM): The organizational function of controlling and tracking users'
identities, permissions, and access privileges within a single security domain (e.g., a
corporate network).
• Identity Federation: A process that allows a user to access services in multiple,
independent security domains using a single set of credentials. It establishes a trusting
relationship between domains.
8. SAML (Security Assertion Markup Language)
SAML is an XML-based framework for exchanging authentication and authorization data between
security domains. It is the standard protocol for web-based Identity Federation and Single Sign-
On (SSO).
• Purpose: Enables a user who has authenticated once with an Identity Provider (IdP) to
seamlessly access a resource from a separate Service Provider (SP) without re-entering
credentials.
• Role in SSO:
1. The user authenticates with the IdP (e.g., an enterprise login server).
2. The IdP creates a signed SAML Assertion (an XML document stating the user's
identity and authentication status).
3. The assertion is sent to the SP (the target website).
4. The SP verifies the IdP's signature and grants the user access to the service.