Entity Authentication

Sheng Zhong

Password Authentication
Oldest(?) way to authenticate an entity. Each user has a password.
Host keeps a list of (user id, password).

When a user needs to login, he sends the host his password.

Host checks password before granting access.

Problems with Password Authentication

The hosts list of (user id, password) may be revealed to adversary.
This list becomes an attractive target of attack.

The password may be eavesdropped in transmission.

No Password Storage in Clear

We can address the first problem using one-way hash function.
Host stores H(password) instead of password. Verifying password is still easy for host. Adversary cant figure out password even if he sees H(password).

Lamports Hash Chain

We can address the second problem using a hash chain.
Let H() be a one-way hash function. Host keeps a list of (user id, Hn(password)). When user needs to login for the ith time, he sends the host h=Hn-i(password). The host checks Hi(h)= Hn(password).

Security of Lamports Hash Chain

Suppose the adversary can see all communications and all storage of host.
So he sees Hn-1(password), Hn-2(password), , Hn-(i-1)(password) in the i-1 previous sessions. He also sees Hn(password) in the hosts storage. But he still cant figure out Hn-i(password), which is needed for login.
6

Vulnerability of Lamports Hash Chain

The above security analysis assumes that adversary cant find password from H(password) since H() is one-way. Unfortunately, normally this is not true.
Most human memorizable passwords belong to a very small space: a few letters and digits with special meanings. So exhaustive search in this space is efficient. The most important part of the attack is construction of the space; usually we build it based on a dictionary. This is called dictionary attack.
7

Entity Authentication without Shared Secret

Password-based authentication needs both parties to share a secretthe password. Can Alice authenticates to Bob who does not share any secret with her?
Without further assumption this is impossible.
Who is Alice anyway? What is the definition of Alice?

With further assumption (e.g., trusted third party) this is possible.

8

Woo-Lam Authentication
Assume there is a trusted third party: Trent.
Alice shares a key KAT with Trent. Bob shares a key KBT with Trent. Alice wants to authenticate to Bob.

Woo and Lam proposed a protocol.

This protocol is flawed. There are many fixes, but most fixed versions are also flawed.
9

Woo-Lam Protocol
Alice Bob: Alice Bob Alice: Nonce. Alice Bob: {Nonce}KAT Bob Trent: {Alice, {Nonce}KAT}KBT Trent Bob: {Nonce}KBT Bob: Decrypt the above ciphertext. If getting Nonce back, then accept. Otherwise, reject.
10

Idea behind Woo-Lam Protocol (1)

Why did they think this is secure?
If Bob finally gets Nonce through decryption, then in 5th step Trent sends Bob {Nonce}KBT. This implies Trent gets Nonce when he decrypts the message received in 4th step. This further implies in 4th step the inner-layer key used to encrypt Nonce corresponds to Alice. In the 3rd step, Nonce is encrypted using KAT.
11

Idea behind Woo-Lam Protocol (2)

Since only Alice and Trent know KAT, the message in the 3rd step must be sent by Alice.
So this is indeed Alice.

12

Error in the Idea

Look at the 2nd part of the idea:
This implies Trent gets Nonce when he decrypts the message received in 4th step.

In the 4th step of which session?

This is not clear; actually not necessary this session. When there are more than one sessions in parallel, the protocol is broken.
13

Parallel Session Attack (1)

Malice impersonates Alice Bob: (Session 1) Alice Malice Bob: (Session 2) Malice Bob Alice (intercepted by Malice): Nonce1. Bob Malice: Nonce2. Malice impersonates Alice Bob: Note Malice {Nonce2}KMT exchanges the Malice Bob: {Nonce1}KMT nonces of two
sessions
14

Parallel Session Attack (2)

Bob Trent: {Alice, {Nonce2}KMT}KBT Bob Trent: {Malice, {Nonce1}KMT}KBT Trent Bob: Garbage Trent Bob: {Nonce1}KBT Bob: Reject session 2 for Malice. Accept session 1 for Alice (Who is actually Malice).
Actually Bob should reject session 1; but he identifies session using the nonce, which has been switched.

15

A Quick Fix
The main problem causing the parallel session attack is that messages from different sessions are not appropriately separated.
So each message should carry a session number. Accept a session only if the last message of this session is accepted. However, this fixed version is still subject to other attacks.
16

IPSec
Internet security standard.
Established by Internet Engineering Task Force (IETF). Provides authentication (mandatory) and data confidentiality (optional) services. Very complex. Has many security problems.

17

Authentication Header
A header immediately following IP header in an IP packet. Includes Security Parameter Index (SPI).
Specifies the method used for authentication.

Includes Sequence Number.

To prevent replay.

Includes Authentication Data.

Data for integrity protection, generated using method specified in SPI.
18

Data Confidentiality
Optional service provided by Encapsulating Security Payload (ESP).
Also includes SPI specifying the method used for confidentiality. Also includes sequence number. Optionally includes authentication data for integrity of ciphertext.

19

Internet Key Exchange (IKE)

To use IPSec, two nodes need to first authenticate each other, agree on keys, etc.
This is achieved using IKE. Very complex procedure.

IKE consists of two phases.

Phase 1 for newly met nodes. Phase 2: fast-track process for old partners based on phase 1.
20

Variants of Phase 1
Four types of keys:
Pre-shared symmetric key. Public key for encryption (old style). Public key for encryption (new style). Public key for digital signature.

Two modes:
Main mode and aggressive mode.

So altogether 8 variants.
21

Signature-based IKE Phase 1 Main Mode

I R I R I R R: HDR(I), SA(I). I: HDR(R), SA(R). R: HDR(I), gx, Nonce(I). I: HDR(R), gy, Nonce(R). R: HDR(I), {ID(I), Cert(I), Sig(I)}gxy. I: HDR(R), {ID(R), Cert(R), Sig(R)}gxy.

22

Notations in the Protocol (1)

HDR(I), HDR(R): Message headers.
Containing the cookies CI, CR, respectively. CI, CR contain the state info of I, R.

SA(I), SA(R): Security associations.

The algorithm/protocol/parameter (to be) used.

NonceI, NonceR: Nonces. Cert(I), Cert(R): Certificates.

23

Notations in the Protocol (2)

Sig (I) = Sign(PrivateKey(I), PRF1(PRF2(NonceI, NonceR, gxy), gx, gy, CI, CR, SA(I), ID(I))). Sig (R) = Sign(PrivateKey(R), PRF1(PRF2(NonceI, NonceR, gxy), gy, gx, CR, CI, SA(R), ID(R))).
PRF1, PRF2: pseudorandom functions agreed in SA(I), SA(R).
24

Idea behind the Protocol

For mutual authentication, giving digital signature + certificate is enough. However, dont want eavesdropper to learn the signature.
So need to encrypt it using the agreed key. Diffie-Hellman key agreement should go first.

To prevent replay attack, nonces are needed for Diffie-Hellman key exchange. What signature scheme/ pseudorandom function/ should be used?
Need to first agree on SAs.
25

Attack on Signature-based IKE Phase 1 Main Mode (1)

I Malice: HDR(I), SA(I). Malice impersonates I R: HDR(I), SA(I). R Malice impersonates I: HDR(R), SA(R). Malice I: HDR(R), SA(R). I Malice: HDR(I), gx, Nonce(I). Malice impersonates I R: HDR(I), gx, Nonce(I).
26

Attack on Signature-based IKE Phase 1 Main Mode (2)

R Malice impersonates I : HDR(R), gy, Nonce(R). Malice I: HDR(R), gy, Nonce(R). I Malice: HDR(I), {ID(I), Cert(I), Sig(I)}gxy. Malice impersonates I R: HDR(I), {ID(I), Cert(I), Sig(I)}gxy. R Malice impersonates I : HDR(R), {ID(R), Cert(R), Sig(R)}gxy.
27

Effect of Attack
R recognizes Malice as I.
This is complete failure of mutual authentication. So an amount of resource of R is held for this session with Malice. Potentially denial-of-service attack.

28

General Critique on IPSec

Too complex, too flexible.
This is due to the practical needs from engineering point of view. However, from security point of view, this means a lot of potential security flaws. It is still hard to give complete analysis of IPSec; only isolated flaws are identified. Implementation is also hard due to the complexity.
29

Kerberos
(Mutual authentication and) key exchange protocol between client and server who do not know each other.
Based on Trusted Third Party (TTP). Proposed by Project Athena@MIT. Very popular, e.g., adopted by Windows.

30

Principals Involved
U: User; always using client computer C. C: Client; the computer used by U. S: Application Server, e.g., a database server C wants to access. TGS: Ticket Granting Server; the server that grants a ticket for accessing S. AS: Authentication Server; the server that grants a ticket for accessing TGS.
31

(Simplified) Kerberos Protocol (1)

C AS: U, TGS, Life_time1, Nonce1. AS C: U, T(C,TGS), TGT(C).
T(C,TGS)={U, C, TGS, KC, TGS, Time_start, Time_expire}KAS, TGS TGT(C)={TGS, KC, TGS, Time_start, Time_expire, Nonce1}KU

32

(Simplified) Kerberos Protocol (2)

C TGS: S, Life_time2, Nonce2, T(C,TGS), A(C, TGS). TGS C: U, T(C, S), TKT(C).
A(C,TGS)={C, Client_time}
KC, TGS

This is called an authenticator. But actually no authentication is involved; just a timestamp.

T(C, S)={U, C, S, KC, S, Time_start, Time_expire}KTGS, S TKT(C)={S, KC, S, Time_start, Time_expire, Nonce2}KC,
TGS

33

(Simplified) Kerberos Protocol (3)

C S: T(C, S), A(C, S). S C: A(S, C).
A(C, S)={C, Client_time1} KC, S T(S, C)={Client_time1 }KC, S

34

Summary of Kerberos
Evolved from the time-stamped version of Needham-Schroeder Protocol.
To establish mutual authentication and key agreement between C and S, C need to first get a ticket from TGS. However, since the number of TGSs is large, C may not know all of them. So C needs to first get a ticket from AS so that he can contact the right TGS.

The security properties of Kerberos is not completely clear.

35