Network Security Protocols

Module 1 — Simplified Study Notes

APJ Abdul Kalam Technological University

# Topic

1 Authentication Protocols — Introduction

2 Mutual Authentication (Symmetric Encryption)

3 Needham & Schroeder Protocol

4 Denning's Protocol

5 Mutual Authentication (Public-Key Encryption)

6 One-Way Authentication

7 Kerberos — Introduction & Version 4

8 Kerberos — Version 5 & Improvements

9 X.509 Authentication Service

10 Public Key Infrastructure (PKI)

11 PKI Trust Models

12 Certificate Revocation
1. Authentication Protocols — Introduction
Authentication protocols allow two parties (say Alice and Bob) to prove who they are to each other and
safely exchange a session key (a temporary secret key used for that conversation).

Two Key Problems

1. Confidentiality — Identity info and keys must travel in encrypted form so an attacker cannot pretend to
be someone else (masquerade attack).
2. Timeliness — Messages must be checked to make sure they are fresh (not old copies). Old messages
replayed by attackers can compromise security.

Replay Attacks — What are they?

A replay attack means an attacker copies a genuine message and sends it again later to trick the system.

<b>Type</b> <b>What happens</b>

Simple Replay Attacker copies a message and sends it again later.

Logged Replay Attacker replays a timestamped message within its valid time window.

Undetectable Replay Original message is blocked; only the fake replay arrives.

Backward Replay Message is sent back to the original sender (works if symmetric encryption is used).

Solutions to Replay Attacks

Sequence Numbers: Each message gets a number. Only in-order numbers are accepted. Downside:
both sides must remember the last number used.
Timestamps: A message is accepted only if the time on it is close to the current time. Clocks must be
synchronized.
Nonces (Challenge/Response): Party A sends a random number (nonce) to B. B must include that
number in its reply. Since the nonce is random and unpredictable, a replayed message cannot contain the
correct nonce.

2. Mutual Authentication — Symmetric Encryption

In mutual authentication, both parties verify each other's identity. Here, a trusted third party called the Key
Distribution Center (KDC) helps.

Each user shares a master key with the KDC. The KDC generates a session key for two parties to use for
one session, and distributes it safely.

3. Needham & Schroeder Protocol

This protocol lets two users (A and B) get a session key from the KDC safely.

Original Protocol — Steps

Step Who sends to whom
What is sent Plain English

1 A → KDC ID_A || ID_B || N1 A tells KDC: I want to talk to B. Here is my nonce N1.

2 KDC → A E(Ka, [Ks || ID_B || N1 || E(Kb, [Ks || ID_A])])

KDC gives A a session key Ks (encrypted with A's key), plus a ticket
 3 A→B E(Kb, [Ks || ID_A]) A forwards B's ticket to B. Only B can open it.

4 B→A E(Ks, N2) B sends a nonce N2 encrypted with Ks to prove it knows the key.

5 A→B E(Ks, f(N2)) A replies with a function of N2 (e.g., N2+1) to prove it knows Ks.

Key Symbols:
Ka = A's master key | Kb = B's master key | Ks = Session key | N1, N2 = Nonces | E(K, M) =
Encrypt M with key K

Problem with Original Protocol

■■ If an attacker has an old session key Ks, they can replay Step 3 to B. B cannot tell if this is a fresh or old
message — it will think it is talking to A!

Denning's Fix — Add a Timestamp

Denning proposed adding a timestamp T to Steps 2 and 3. This lets A and B verify the session key was just
generated.

Denning's Protocol Steps:

1. A → KDC: ID_A || ID_B

2. KDC → A: E(Ka, [Ks || ID_B || T || E(Kb, [Ks || ID_A || T])])

3. A → B: E(Kb, [Ks || ID_A || T])

4. B → A: E(Ks, N1)

5. A → B: E(Ks, f(N1))

■■ Denning's protocol still has a problem: if clocks are out of sync, an attacker can intercept a message and
replay it later when its timestamp becomes 'valid' at the receiver. This is called a suppress-replay attack.

Modified Needham/Schroeder Protocol (using Nonces — No Clocks Needed)

This version uses nonces instead of timestamps, so clock synchronization is not needed.

1. A → B: ID_A || Na

2. B → KDC: ID_B || Nb || E(Kb, [ID_A || Na || Tb])

3. KDC → A: E(Ka, [ID_B || Na || Ks || Tb]) || E(Kb, [ID_A || Ks || Tb]) ||

Nb

4. A → B: E(Kb, [ID_A || Ks || Tb]) || E(Ks, Nb)

Na and Nb are nonces. Since they are unpredictable, replays are detected. Tb is a time limit on the session
key.
4. Denning's Protocol — Summary
Denning's protocol improves on Needham/Schroeder by using timestamps to prove freshness. However it
still requires synchronized clocks across the network.

To Defeat Suppress-Replay Attacks:

Option 1: Regularly synchronize all clocks with the KDC clock.
Option 2: Use handshaking with nonces (preferred — no clock sync needed).

5. Mutual Authentication — Public-Key Encryption

Instead of a KDC, we use an Authentication Server (AS) that hands out public-key certificates. Each
party has a public key and a private key.

Protocol using Timestamps:

1. A → AS: ID_A || ID_B

2. AS → A: E(PR_as, [ID_A || PU_a || T]) || E(PR_as, [ID_B || PU_b || T])

3. A → B: E(PR_as, [ID_A || PU_a || T]) || E(PR_as, [ID_B || PU_b || T]) ||

E(PU_b, E(PR_a, [Ks || T]))

PR = Private Key | PU = Public Key | T = Timestamp | Ks = Session key chosen by A

Woo and Lam Protocol (uses Nonces — 7 steps):

1. A → KDC: ID_A || ID_B

2. KDC → A: E(PR_auth, [ID_B || PU_b])

3. A → B: E(PU_b, [Na || ID_A])

4. B → KDC: ID_A || ID_B || E(PU_auth, Na)

5. KDC → B: E(PR_auth, [ID_A || PU_a]) || E(PU_b, E(PR_auth, [Na || Ks ||

ID_B]))

6. B → A: E(PU_a, E(PR_auth, [(Na || Ks || ID_A || ID_B) || Nb]))

7. A → B: E(Ks, Nb)

In the revised version, ID_A is added inside the encrypted triple in steps 5 and 6 to bind the session key Ks to
both identities. This prevents an attacker from using the same nonce Na from a different party.

6. One-Way Authentication
Used for email. Only one side (sender A) authenticates to the receiver (B). The receiver does not need to be
online at the same time.

Symmetric Encryption Approach:

1. A → KDC: ID_A || ID_B || N1

2. KDC → A: E(Ka, [Ks || ID_B || N1 || E(Kb, [Ks || ID_A])])

3. A → B: E(Kb, [Ks || ID_A]) || E(Ks, M)

M = the actual email message. Steps 4 & 5 of mutual auth are skipped since B may be offline.
Public-Key Encryption Approaches:
For confidentiality (only B can read it):

A → B: E(PU_b, Ks) || E(Ks, M)

A picks a one-time session key Ks, encrypts it with B's public key, and encrypts the message with Ks. Only B
(who has the private key) can get Ks and read M.

For authentication (B can verify it came from A — digital signature):

A → B: M || E(PR_a, H(M))

A signs the hash of the message with its private key. Anyone with A's public key can verify the signature.
7. Kerberos — Introduction & Version 4
Kerberos is a network authentication system developed at MIT (Project Athena). It is based on symmetric
encryption (DES in Version 4) and uses a trusted Key Distribution Center (KDC).

Three threats Kerberos addresses:

1. A user pretends to be someone else on the same workstation.
2. A user fakes the network address of a workstation.
3. A user eavesdrops and uses replay attacks.

Kerberos Requirements:
<b>Requirement</b> <b>What it means</b>

Secure Eavesdroppers cannot impersonate users.

Reliable Uses distributed servers so one can back up another.

Transparent User only types a password — auth happens silently.

Scalable Can support large numbers of clients and servers.

How Kerberos Works — The Ticket System

Kerberos uses tickets. Think of a ticket like a hall pass — it proves you have permission to access a service.
There are two types:

Ticket-Granting Ticket (TGT): Given at login. Used to get service tickets — so you only enter your
password once.
Service Ticket: Used to access a specific server.

Kerberos Version 4 — Full Authentication (3 phases):

Phase (a): Get a Ticket-Granting Ticket (once per login)
1. C → AS: ID_C || ID_tgs || TS1

2. AS → C: E(Kc, [Kc,tgs || ID_tgs || TS2 || Lifetime2 || Ticket_tgs])

Ticket_tgs = E(Ktgs, [Kc,tgs || ID_C || AD_C || ID_tgs || TS2 || Lifetime2])

Phase (b): Get a Service Ticket (once per service type)

3. C → TGS: ID_V || Ticket_tgs || Authenticator_C

4. TGS → C: E(Kc,tgs, [Kc,v || ID_V || TS4 || Ticket_V])

Ticket_V = E(Kv, [Kc,v || ID_C || AD_C || ID_V || TS4 || Lifetime4])

Authenticator_C = E(Kc,tgs, [ID_C || AD_C || TS3])

Phase (c): Access the Server (once per service session)

5. C → V: Ticket_V || Authenticator_C

6. V → C: E(Kc,v, [TS5 + 1]) ← optional, for mutual auth

Authenticator_C = E(Kc,v, [ID_C || AD_C || TS5])

Symbol Key:
Symbol Meaning
 C Client (workstation)

AS Authentication Server

TGS Ticket-Granting Server

V Service Server

Kc Key shared between C and AS (derived from user password)

Ktgs Key shared between AS and TGS

Kv Key shared between TGS and V

Kc,tgs Session key between C and TGS

Kc,v Session key between C and V

AD_C Network address of client (prevents ticket theft)

TS Timestamp

Lifetime How long the ticket is valid

Kerberos Realms
A Kerberos realm is a group of users and servers sharing one Kerberos database. If users in Realm A want
to use servers in Realm B, the two KDCs must share a secret key with each other.
8. Kerberos Version 5 — Improvements
Version 5 (RFC 1510) fixes the limitations of Version 4. Improvements fall into two categories:

Environmental Shortcomings Fixed:

<b>Problem in V4</b> <b>Fix in V5</b>

Only DES encryption allowed Any encryption algorithm can be used (tagged with type ID)

Only IP addresses supported Any network address type supported

Non-standard byte ordering Uses ASN.1 / BER standard for message encoding

Max ticket lifetime = 21 hours (8-bit, 5-min units) Explicit start/end times — arbitrary lifetimes

Cannot forward credentials to other hosts Credential forwarding supported

N realms need N² relationships Fewer cross-realm relationships needed

Technical Deficiencies Fixed:

Double Encryption: In V4, tickets were encrypted twice (wasteful). V5 removes the extra layer.
PCBC Encryption: V4 used a non-standard DES mode vulnerable to ciphertext block swapping. V5 uses
standard CBC with an explicit hash/checksum.
Session Keys: V5 allows a subsession key to be negotiated per connection, reducing risk from replayed
old-session messages.
Password Attacks: Both versions are vulnerable. V5 adds preauthentication to make brute-force harder
(but not impossible).

Version 5 Message Format:

1. C → AS: Options || ID_C || Realm_C || ID_tgs || Times || Nonce1

2. AS → C: Realm_C || ID_C || Ticket_tgs || E(Kc, [Kc,tgs || Times || Nonce1

|| Realm_tgs || ID_tgs])

Ticket_tgs = E(Ktgs, [Flags || Kc,tgs || Realm_C || ID_C || AD_C || Times])

3. C → TGS: Options || ID_V || Times || Nonce2 || Ticket_tgs ||

Authenticator_C

4. TGS → C: Realm_C || ID_C || Ticket_V || E(Kc,tgs, [Kc,v || Times ||

Nonce2 || Realm_V || ID_V])

5. C → V: Options || Ticket_V || Authenticator_C

6. V → C: E(Kc,v, [TS2 || Subkey || Seq#])

Authenticator_C = E(Kc,v, [ID_C || Realm_C || TS2 || Subkey || Seq#])

New in V5: Options/Flags (control ticket behavior), Realm (support multi-realm), Times (flexible
start/end/renew), Nonce (freshness), Subkey (per-session encryption key), Seq# (sequence number to
detect replays).
9. X.509 Authentication Service
X.509 is a standard for digital certificates. A digital certificate is like a digital ID card — it binds a person's
name to their public key, signed by a trusted Certification Authority (CA).

Certificate Fields:
<b>Field</b> <b>What it contains</b>

Version Version 1, 2, or 3 of X.509 format

Serial Number Unique number within the CA

Signature Algorithm Algorithm used to sign the certificate

Issuer Name Name of the CA that issued this certificate

Period of Validity Not-before and not-after dates

Subject Name Name of the certificate owner

Public Key Info The owner's public key + algorithm

Extensions (V3) Extra info: email, URL, key usage, policy

Signature Hash of all fields, encrypted with CA's private key

How it works:
1. CA hashes the certificate data.
2. CA encrypts the hash with its private key → this is the signature.
3. Anyone can verify the certificate using the CA's public key.

CA Hierarchy
If two users use different CAs, those CAs form a hierarchy. Trust travels up and down the tree. Forward
certificates are certificates of X created by others. Reverse certificates are certificates created by X for
others.

X.509 Authentication Procedures:

One-Way Authentication (1 message — e.g., email):
A sends: {t_A, r_A, ID_B, sgnData, E[PU_b, K_ab]}

Proves A's identity, message is intended for B, and message is fresh.

Two-Way Authentication (2 messages):

1. A → B: {t_A, r_A, ID_B, sgnData, E[PU_b, K_ab]}

2. B → A: {t_B, r_B, ID_A, r_A, sgnData, E[PU_a, K_ba]}

B's reply includes A's nonce (r_A) to prove freshness.

Three-Way Authentication (3 messages — no clock sync needed):

1. A → B: {t_A, r_A, ID_B, sgnData, E[PU_b, K_ab]}

2. B → A: {t_B, r_B, ID_A, r_A, sgnData, E[PU_a, K_ba]}

3. A → B: {r_B} ← signed copy of B's nonce

Both nonces are echoed back, so no timestamps are needed. Replay attacks are caught by the nonce check.
Revocation of Certificates
A certificate may need to be cancelled before it expires — for example, if the private key is stolen or the user
leaves the organization. CAs maintain a Certificate Revocation List (CRL). Users should always check the
CRL before trusting a certificate.
10. Public Key Infrastructure (PKI)
PKI is the full system — hardware, software, people, policies, and procedures — needed to manage digital
certificates. The X.509-based PKI is called PKIX.

PKIX Components:
<b>Component</b> <b>Role</b>

End Entity The user or device that owns a certificate.

Certification Authority (CA) Issues and signs certificates; also usually issues CRLs.

Registration Authority (RA) Optional — handles enrollment/identity verification on behalf of CA.

CRL Issuer Optional — CA can delegate publishing of CRLs to this.

Repository Stores certificates and CRLs so end entities can retrieve them.

PKIX Management Functions:

<b>Function</b> <b>What it does</b>

Registration User first introduces itself to the CA to enroll in PKI.

Initialization Install trusted CA public keys in the client before first use.

Certification CA issues a certificate for the user's public key.

Key Pair Recovery Restore lost encryption keys from a backup facility.

Key Pair Update Replace old key pairs and issue new certificates regularly.

Revocation Request Request to cancel a certificate (e.g., key compromised).

Cross Certification Two CAs issue certificates for each other to enable interoperability.

PKIX Management Protocols:

CMP (RFC 2510): Certificate Management Protocol — flexible, covers all PKI operations.
CMC (RFC 2797): Certificate Management Messages over CMS — built on existing implementations.
11. PKI Trust Models
<b>Model</b> <b>Description</b> <b>Problems</b>

1. Monopoly One single globally trusted CA. Its public key is built into
No universal
all software.
org exists. Single point of failure. Monopoly

2. Monopoly + RAs Same as above but uses Registration Authorities to verify

All other
identities.
monopoly problems remain.

3. Monopoly + Delegated CAs

Root CA signs for sub-CAs, who sign for users. Hierarchical
Still onechain.
root of trust. User sees a chain of certs.

4. Oligarchy Multiple CAs trusted by browsers (~80 CAs pre-installed).

Any compromised
Used today. CA threatens everyone. Vendor, not us

5. Anarchy (PGP model) No CAs. Users sign each other's certs. Trust web. Cannot scale to internet. Trusting a root of a chain is risky

6. Name Constraints CA trusted only for a specific domain of names. More flexible but complex to manage.

7. Hierarchical Name Constraints

Like model 3 but each delegated CA can only issue certs
Complex
for itssetup.
portion of namespace.

12. Certificate Revocation

Sometimes a valid certificate needs to be cancelled before it expires. Reasons include:

The user's private key was stolen or compromised.

The user is no longer associated with the organization.
The CA's own certificate was compromised.

How Revocation Works:

CAs publish a Certificate Revocation List (CRL) — a list of serial numbers of cancelled certificates. Anyone
verifying a certificate should check this list.

The CRL should be centrally hosted in a highly available location. Multiple copies can be hosted for
redundancy.

Revocation Mechanisms:
Delta CRLs: Instead of publishing the full CRL every time, only changes (delta) since the last CRL are
published. Smaller and faster.
OLRS (Online Revocation Status) Schemes: E.g., OCSP (Online Certificate Status Protocol) — check
revocation status in real-time by querying a server.
Good-lists vs. Bad-lists: Bad-list = list of revoked certs (CRL). Good-list = list of valid certs (positive
whitelist approach).
Quick Revision Summary
<b>Topic</b> <b>Key Point</b>

Replay Attack Old message replayed to trick system. Solved by timestamps, nonces, or sequence numbers.

KDC Trusted third party that distributes session keys encrypted with master keys.

Needham-Schroeder Classic 5-step protocol. Vulnerable to replay of old session keys.

Denning's Fix Adds timestamps. Vulnerable to suppress-replay if clocks are out of sync.

Modified N-S Uses nonces instead of timestamps. No clock sync needed.

Kerberos V4 Uses TGT + service tickets. 3-phase: login → get ticket → use service. Uses DES.

Kerberos V5 Fixes V4: any encryption, any address, ASN.1 encoding, flexible lifetimes, credential forwarding,

X.509 Certificate Digital ID card signed by CA. Contains public key, owner name, validity dates.

CA Hierarchy Chain of trust. Forward certs = others signed X. Reverse = X signed others.

PKI Full infrastructure to manage certs. Components: CA, RA, CRL Issuer, Repository.

Trust Models 1-Monopoly, 3-Delegated CA, 4-Oligarchy (web today), 5-Anarchy (PGP).

CRL List of revoked certificates. Check before trusting any certificate.

One-Way Auth Used for email. Sender authenticates to receiver. Receiver may be offline.

Mutual Auth Both parties verify each other. Used for real-time connections.

NSP Module 1 — Simplified Study Notes | APJ Abdul Kalam Technological University