2.

6 Remote User Authentication using Symmetric Encryption

🔹 Introduction

Remote User Authentication is the process of verifying the identity of a user over an insecure
network (like the Internet).

When symmetric encryption is used, both parties share a secret key for authentication.

The most well-known protocol for this is:

👉 Needham–Schroeder Protocol

It provides mutual authentication between two parties.

🔹 What is Mutual Authentication?

Mutual authentication means:

 Client verifies Server

 Server verifies Client

Both confirm each other’s identity before communication.

🔹 Needham–Schroeder Protocol

There are two versions:

1️⃣ Symmetric Key Version

2️⃣ Public Key Version

Needham–Schroeder Public Key Authentication Protocol

(Mutual Authentication using Public Key Cryptography)

🔹 Introduction

The Needham–Schroeder Public Key Protocol is designed to provide mutual authentication

between two parties:

 Alice (A)

 Bob (B)

It uses public key cryptography instead of symmetric keys.

👉 Goal: Both parties verify each other’s identity before communication.

🔹 Notations Used

 K A → Alice’s Public Key

  K B→ Bob’s Public Key

 N A → Nonce generated by Alice

 N B→ Nonce generated by Bob

 {M}K → Message M encrypted with key K

A nonce is a random number used once to prevent replay attacks.

🔹 Step-by-Step Protocol

Step 1: Alice → Bob

A → B : { N_A , A }K_B

 Alice generates nonce N A .

 Sends her identity and nonce.

 Entire message encrypted using Bob’s public key.

👉 Only Bob can decrypt it using his private key.

Step 2: Bob → Alice (Challenge)

B → A : { N_A , N_B }K_A

 Bob decrypts message.

 Sends back:

o Alice’s nonce (N_A) → proves he decrypted correctly.

o His own nonce (N_B).

 Encrypted using Alice’s public key.

👉 This authenticates Bob to Alice.

Step 3: Alice → Bob (Response)

A → B : { N_B }K_B

 Alice decrypts Bob’s message.

 Verifies N_A.

 Sends back N_B encrypted using Bob’s public key.

👉 This proves Alice is genuine.

✅ Result
  Both parties are authenticated.

 Secure communication can begin.

 No shared secret key is required initially.

Needham–Schroeder Authentication Protocol

(Symmetric Key Version with KDC)

This diagram shows how Alice and Bob authenticate each other using a Key Distribution Center
(KDC) and symmetric encryption.

🔹 Entities Involved

 Alice (A) → Initiator

 Bob (B) → Receiver

 KDC → Trusted Key Distribution Center

🔑 Keys Used

 K_A → Secret key shared between Alice & KDC

 K_B → Secret key shared between Bob & KDC

 K_S → Session key (generated by KDC)

 R_A, R_B → Nonces (random numbers)

🔹 Step-by-Step Explanation (As per Diagram)

✅ Step 1: Alice → KDC

R_A, A, B

 Alice sends:

o Random number R A

o Her identity (A)

o Bob’s identity (B)

👉 She requests a session key to communicate with Bob.

✅ Step 2: KDC → Alice

K_A ( R_A, B, K_S, K_B (A, K_S) )

KDC generates session key K S .

Message contains:
  R_A (for verification)

 B’s identity

 Session key K S

 Ticket for Bob → K B (A , K S )

Entire message encrypted using K_A.

👉 Only Alice can decrypt it.

✅ Step 3: Alice → Bob

K_B (A, K_S), K_S (R_A2)

Alice sends:

 Ticket (encrypted with K_B)

 New nonce encrypted with session key

👉 Bob decrypts ticket using K_B and gets K_S.

✅ Step 4: Bob → Alice

K_S (R_A2 − 1, R_B)

Bob:

 Decrypts R_A2

 Subtracts 1 and sends back

 Sends his own nonce R_B

Encrypted with session key K_S.

👉 Proves Bob is genuine.

✅ Step 5: Alice → Bob

K_S (R_B − 1)

Alice:

 Decrypts R_B

 Subtracts 1

 Sends back to Bob

👉 Proves Alice is genuine.

🎯 Final Result

✔ Mutual authentication achieved

✔ Session key established
✔ Secure communication begins

Two-Way Authentication Using Shared Secret Key

(Challenge–Response Protocol)

🔹 Introduction

This method is based on a shared secret key between two parties:

 Party 1 (Source)

 Party 2 (Destination)

Both share a common secret key K.

👉 It is called a Challenge–Response Protocol because one party sends a random challenge and the
other proves identity by encrypting it.

🔹 Basic Idea

 One party sends a random number (challenge).

 The other encrypts it using the shared secret key.

 If the result is correct, identity is confirmed.

🔹 Step-by-Step Working (As in Fig 2.6.2)

✅ Message 1: Party 1 → Party 2

Sends its identity.

👉 “I am Party 1.”

✅ Message 2: Party 2 → Party 1

Sends a random number (R1) in plaintext.

👉 This is the challenge.

✅ Message 3: Party 1 → Party 2

Party 1 encrypts R1 using shared key K:

E K (R 1)
Sends encrypted value back.

👉 Party 2 decrypts it using the same key.

If correct → Party 1 is authenticated.

🔎 At this stage:

 Party 2 is sure about Party 1.

 But Party 1 is not yet sure about Party 2.

✅ Message 4: Party 1 → Party 2

Now Party 1 sends its own random number (R2).

✅ Message 5: Party 2 → Party 1

Party 2 encrypts R2 using shared key:

E K (R 2)
Sends it back.

👉 Party 1 decrypts and verifies.

🎯 Final Result

✔ Both parties authenticated

✔ Shared secret key used
✔ Mutual authentication achieved

🔹 Simple Diagram

Party 1 → Party 2 : Identity

Party 2 → Party 1 : R1
Party 1 → Party 2 : E(K, R1)
Party 1 → Party 2 : R2
Party 2 → Party 1 : E(K, R2)

2.7 Remote User Authentication Using Asymmetric Encryption

This method uses Public Key Cryptography instead of a shared secret key.

There are two approaches:

1. Mutual Authentication using Public Key

2. Certificate-Based Authentication
🔹 1️⃣ Mutual Authentication (Using Public Key)

🧩 Working Steps

Let:

 A and B are two users

 E B= B’s public key

 DB = B’s private key

 K s = Session key

 R A , R B= Random numbers (nonces)

✅ Message 1: A → B

A sends a random number encrypted with B’s public key:

E B (R A )
Only B can decrypt it using his private key.

✅ Message 2: B → A

B decrypts and sends back:

E A (R A , RB , K s)
Contains:

 A’s nonce R A

 B’s nonce R B

 Proposed session key K s

Encrypted using A’s public key.

✅ Message 3: A → B

A decrypts using private key.

If R A matches → message is from B.

A confirms session by sending:

K s (R B )
Encrypted using session key.

🎯 Result
✔ Mutual authentication achieved
✔ Session key established
✔ Secure communication begins

⚠ Disadvantages

✖ Both users must already know each other's public keys

✖ Public key operations are slower
✖ No proof that public key really belongs to that user

👉 That leads to certificate-based authentication.

🔹 2️⃣ Certificate-Based Authentication

🧩 Idea

Each user has:

 Public key

 Digital Certificate (issued by Certificate Authority – CA)

Certificate contains:

 User name
  Public key

 Validity period

 CA signature

🪜 Working Steps

✅ Step 1: A → B

A sends his digital certificate

✅ Step 2: B verifies certificate

B checks:

 CA signature

 Validity period

 Owner name

 Certificate authority details

If valid → B trusts A’s public key.

✅ Step 3: B → A

B sends a random number (challenge) R

✅ Step 4: A → B

A encrypts challenge using his private key:

E A (R)
pr

✅ Step 5: B verifies

B decrypts using A’s public key.

If value matches → A is authenticated.

🎯 Result

✔ Strong authentication
✔ No need to pre-share keys
✔ Public key authenticity verified

2.8 Kerberos System

Kerberos is a network authentication protocol that authenticates users and services using a
trusted third party.
It is designed to work over an insecure network.

🔹 Key Points About Kerberos

 Developed at MIT under Project Athena
 Current versions up to Kerberos Version 5
 Uses secret-key (symmetric) cryptography
 Provides mutual authentication
 Password is used only once during login
 After authentication, communication can be encrypted
 Widely used in enterprise networks (Windows Active Directory)

🔹 Why Kerberos is Needed?

In an insecure network:
 Passwords can be intercepted
 Attackers can impersonate users
 Replay attacks are possible
👉 Kerberos solves this using:
 Tickets
 Session keys
 Time stamps
 Trusted third party (KDC)

🔹 Basic Components of Kerberos

1. Client (User)
2. Server (Service)
3. KDC (Key Distribution Center)
o Authentication Server (AS)
o Ticket Granting Server (TGS)
🔹 Requirements of Kerberos
Kerberos must satisfy:
1️⃣ Security
 Strong enough to prevent eavesdropping
 No password sent in plaintext
2️⃣ Reliability
 Distributed server architecture
 Backup servers possible
 Graceful degradation
3️⃣ Transparency
 User should not know authentication details
 Only enters password once
4️⃣ Scalability
 Supports large number of users and services
 Easy to add new clients and servers
Kerberos Terminology
1️⃣ Authentication Server (AS)
 Issues tickets for requested services
 Verifies user credentials
 Part of the KDC
👉 First point of contact for the client.

2️⃣ Client
 User or system requesting service
 Receives tickets from Kerberos

3️⃣ Credentials
 Electronic proof of identity
 Also called a Ticket
Used to verify a client for a particular service.
4️⃣ Credential Cache
 File storing tickets and session keys
 Used to avoid repeated authentication

5️⃣ Crypt Hash

 One-way hash used to authenticate users
 Used to protect passwords

6️⃣ Key
 Used for encryption and decryption
 Can be:
o User key
o Session key
o Server key

7️⃣ Key Distribution Center (KDC)

 Central trusted authority
 Issues tickets
 Usually includes:
o Authentication Server (AS)
o Ticket Granting Server (TGS)

8️⃣ Realm
 A Kerberos administrative domain
 Contains:
o One or more KDCs
o Many clients
Example: [Link]
9️⃣ Ticket Granting Server (TGS)
 Issues service tickets
 Allows client to access services
 Part of KDC

🔟 Ticket Granting Ticket (TGT)

 Special ticket issued by AS
 Allows client to request service tickets
 Avoids sending password again
👉 Enables Single Sign-On (SSO)
Kerberos Version 4
Kerberos Version 4 uses DES (Data Encryption Standard) for authentication.
It has two authentication dialogues:
1. Simple Authentication Dialogue
2. More Secure Authentication Dialogue
Simple Authentication Dialogue
🔹 Assumptions / Notations
 Client → C
 Authentication Server → AS
 Server (Service) → V
 User ID → IDc
 Server ID → IDv
 Password → Pc
 Client network address → ADc
 Secret key shared between AS and V → Kv
 || → Concatenation
 E(K, data) → Encryption using key K

🔹 Message Flow
📩 Step 1: C → AS
IDc || Pc || IDv
Client sends:
 User ID
 Password
 ID of requested server
👉 AS verifies password from its centralized database.

📩 Step 2: AS → C
AS sends a Ticket
Ticket contains:
E(Kv, [IDc || ADc || IDv])
 Encrypted using server's secret key Kv
 Only server V can decrypt it.

📩 Step 3: C → V
IDc || Ticket
Client sends:
 Its ID
 Ticket received from AS

📩 Step 4: V verifies Ticket

Server decrypts ticket using Kv
If values match:
 Client identity verified
 Access granted

🔹 Diagram
C → AS : IDc || Pc || IDv
AS → C : Ticket
C → V : IDc || Ticket
Ticket = E(Kv, [IDc || ADc || IDv])
🔹 Explanation in Simple Words
1️⃣ Client logs into system and requests access to server V.
2️⃣ Authentication Server verifies credentials.
3️⃣ AS issues a ticket encrypted with server’s secret key.
4️⃣ Client presents ticket to server.
5️⃣ Server decrypts and grants service.
Secure Authentication Dialogue (Kerberos V4)
🔹 Three Sessions in Secure Kerberos V4
1️⃣ Authentication Service (AS Exchange)
👉 To obtain Ticket Granting Ticket (TGT)
2️⃣ Ticket Granting Service (TGS Exchange)
👉 To obtain Service Granting Ticket
3️⃣ Client/Server Authentication
👉 To access requested service