Chapter eight:

Authentication Protocols

2013 Term 2
 Protocol

Human protocols  the rules followed

in human interactions
Example: Asking a question in class 
Networking protocols  rules followed
in networked communication systems
.Examples: HTTP, FTP, etc 
Security protocol  the
(communication) rules followed in a
security application
.Examples: SSL, IPSec, Kerberos, etc 
Part 3  Protocols
2
 Protocols

Protocol flaws can be very subtle

Several well-known security protocols
have significant flaws
Including WEP, GSM, and even IPSec 

Implementation errors can occur

Such as IE implementation of SSL 

…Not easy to get protocols right

Part 3  Protocols
3
 Ideal Security Protocol

Satisfies security requirements

Requirements must be precise 

Efficient
Small computational requirement 

…Small bandwidth usage, network delays 

Not fragile
Works when attacker tries to break it 

Works even if environment changes 

…Easy to use and implement, flexible

!Difficult to satisfy all of these

Part 3  Protocols
4
 ATM Machine Protocol

Insert ATM card .1

Enter PIN .2
?Correct PIN .3
Yes? Conduct your transaction(s)
No? Machine (eventually) eats card

Part 3  Protocols
5
 Authentication Protocols

Part 3  Protocols
6
 Authentication

Alice must prove her identity to Bob

Alice and Bob can be humans or computers 
May also require Bob to prove he’s Bob
(mutual authentication)
Probably need to establish a session
key
May have other requirements, such as
Use only public keys 
Use only symmetric keys 
Use only hash functions 

Part 3  Protocols
7
 Authentication

Authentication on a stand-alone
computer is relatively simple
Secure path” is an issue“ 
Attacks on authentication software 
Authentication over a network is
challenging
Attacker can passively observe messages 
Attacker can replay messages 
Active attacks possible (insert, delete, 
change)
Part 3  Protocols
8
 Simple Authentication

”I’m Alice“

Prove it

”My password is “frank

Alice Bob

Simple and may be OK for standalone

system
But insecure for networked system
Subject to a replay attack (next 2 slides) 
Also, Bob must know Alice’s password 
Part 3  Protocols
9
 Authentication Attack

”I’m Alice“

Prove it

”My password is “frank

Alice Bob

Trudy

Part 3  Protocols
 Authentication Attack

”I’m Alice“

Prove it

”My password is “frank

Trudy Bob

This is an example of a replay attack

?How can we prevent a replay

Part 3  Protocols
 Simple Authentication

”I’m Alice, my password is “frank

Alice Bob

…More efficient, but

same problem as previous version …

Part 3  Protocols
 Better Authentication

”I’m Alice“

Prove it

h(Alice’s password)

Alice Bob

Better since it hides Alice’s password

From both Bob and Trudy 
But still subject to replay

Part 3  Protocols
 Challenge-Response

To prevent replay, use challenge-

response
”Goal is to ensure “freshness 
Suppose Bob wants to authenticate
Alice
Challenge sent from Bob to Alice 
Challenge is chosen so that
Replay is not possible 
Only Alice can provide the correct response 
Part 3  Protocols
Bob can verify the response 
 Nonce

To ensure freshness, can employ a

nonce
Nonce == number used once 
?What to use for nonces
?That is, what is the challenge 
?What should Alice do with the nonce
?That is, how to compute the response 
?How can Bob verify the response
?Should we rely on passwords or keys

Part 3  Protocols
 Challenge-Response

”I’m Alice“

Nonce

h(Alice’s password, Nonce)

Alice Bob

 Nonce is the challenge

 The hash is the response
Nonce prevents replay, ensures freshness
 Password is something Alice knows
 Bob must know Alice’s pwd to verify

Part 3  Protocols
 Generic Challenge-Response

”I’m Alice“

Nonce

Something that could only be

Alice from Alice (and Bob can verify) Bob

?In practice, how to achieve this

…Hashed pwd works
?Maybe encryption is better? Why

Part 3  Protocols
 Symmetric Key Notation

Encrypt plaintext P with key K

C = E(P,K)
Decrypt ciphertext C with key K
P = D(C,K)
Here, we are concerned with attacks on
protocols, not attacks on crypto
So, we assume crypto algorithms secure

Part 3  Protocols
 Authentication: Symmetric Key

Alice and Bob share symmetric key K

Key K known only to Alice and Bob
Authenticate by proving knowledge of
shared symmetric key
?How to accomplish this
Must not reveal key, must not allow replay (or 
… ,other) attack, must be verifiable

Part 3  Protocols
 Authentication with Symmetric Key

”I’m Alice“

E(R,K)
Alice, K Bob, K

Secure method for Bob to authenticate Alice 

Alice does not authenticate Bob 

?So, can we achieve mutual authentication 

Part 3  Protocols
 Mutual Authentication?

I’m Alice”, R“

E(R,K)

E(R,K)
Alice, K Bob, K

?What’s wrong with this picture

Alice” could be Trudy (or anybody“
!else)
Part 3  Protocols
 Mutual Authentication

Since we have a secure one-way

…authentication protocol
The obvious thing to do is to use the protocol
twice
Once for Bob to authenticate Alice 

Once for Alice to authenticate Bob 

…This has got to work

Part 3  Protocols
 Mutual Authentication

I’m Alice”, RA“

RB, E(RA, K)

E(RB, K)
Alice, K Bob, K

…This provides mutual authentication

or does it? See the next slide…

Part 3  Protocols
 Mutual Authentication Attack
I’m Alice”, RA“ .1

RB, E(RA, K) .2

E(RB, K) .5
Trudy Bob, K

I’m Alice”, RB“ .3

RC, E(RB, K) .4

Trudy Bob, K

Part 3  Protocols
 Mutual Authentication

Our one-way authentication protocol

is not secure for mutual
authentication
!Protocols are subtle 
The “obvious” thing may not be secure 
Also, if assumptions or environment
change, protocol may not be secure
This is a common source of security failure 
For example, Internet protocols 

Part 3  Protocols
 Symmetric Key Mutual
Authentication

I’m Alice”, RA“

RB, E(“Bob”,RA,K)

E(“Alice”,RB,K)

Alice, K Bob, K

?Do these “insignificant” changes help

!Yes

Part 3  Protocols
 Public Key Notation

Encrypt M with Alice’s public key:

{M}Alice
Sign M with Alice’s private key: [M]Alice
Then
Alice = M]Alice}M{[ 

Alice = M}Alice]M[{ 

Anybody can do public key operations

Only Alice can use her private key 
Part 3  Protocols
 Public Key Authentication

”I’m Alice“

Alice }R{

Alice Bob

?Is this secure

!Trudy can get Alice to decrypt anything
So, should have two key pairs 

Part 3  Protocols
 Public Key Authentication

”I’m Alice“

Alice ]R [

Alice Bob

?Is this secure

!Trudy can get Alice to sign anything
Same a previous  should have two key pairs 

Part 3  Protocols
 Public Keys

Generally, a bad idea to use the same key

pair for encryption and signing
…Instead, should have
…one key pair for encryption/decryption… 

and a different key pair for signing/verifying… 

signatures

Part 3  Protocols
 Session Key

Usually, a session key is required

I.e., a symmetric key for a particular session 
Used for confidentiality and/or integrity 
How to authenticate and establish a
session key (i.e., shared symmetric
?key)
When authentication completed, want Alice 
and Bob to share a session key
…Trudy cannot break the authentication 
and Trudy cannot determine the session… 
key
Part 3  Protocols
 Authentication & Session Key

I’m Alice”, R“

Alice }R,K{

Bob }R +1,K{
Alice Bob

?Is this secure

Alice is authenticated and session key is 
secure
Alice’s “nonce”, R, useless to authenticate Bob 
The key K is acting as Bob’s nonce to Alice 
No mutual authentication
Part 3  Protocols
 Public Key Authentication and Session
Key

I’m Alice”, R“

Bob ]R,K[

Alice ]R +1,K[

Alice Bob

?Is this secure

…Mutual authentication (good), but 
session key is not secret (very bad) … 

Part 3  Protocols
 Public Key Authentication and Session
Key

I’m Alice”, R“

}
Alice Bob ]R,K[{

}
Bob Alice ]R +1,K[{
Alice Bob

?Is this secure

Seems to be OK
!Mutual authentication and session key
Part 3  Protocols
 Public Key Authentication and
Session Key

I’m Alice”, R“

]
Bob Alice }R,K{[

]
Alice Bob}R +1,K{[

Alice Bob

?Is this secure

Seems to be OK
Anyone can see {R,K}Alice and {R +1,K}Bob 

Part 3  Protocols
 Perfect Forward Secrecy
…”Consider this “issue
Alice encrypts message with shared key K 
and sends ciphertext to Bob
Trudy records ciphertext and later attacks 
Alice’s (or Bob’s) computer to recover K
Then Trudy decrypts recorded messages 
Perfect forward secrecy (PFS): Trudy
cannot later decrypt recorded
ciphertext
Even if Trudy gets key K or other secret(s) 
?Is PFS possible
Part 3  Protocols
 Perfect Forward Secrecy

Suppose Alice and Bob share key K

For perfect forward secrecy, Alice and
Bob cannot use K to encrypt
Instead they must use a session key KS
and forget it after it’s used
Can Alice and Bob agree on session key
?KS in a way that ensures PFS

Part 3  Protocols
 Naïve Session Key Protocol

E(KS, K)

E(messages, KS)

Alice, K Bob, K

Trudy could record E(KS, K) 

If Trudy later gets K then she can get 
KS
Then Trudy can decrypt recorded messages 
Part 3  Protocols
 Perfect Forward Secrecy
We use Diffie-Hellman for PFS
Recall: public g and p

ga mod p

gb mod p

Alice, a Bob, b

But Diffie-Hellman is subject to MiM 

?How to get PFS and prevent MiM 

Part 3  Protocols
 Perfect Forward Secrecy

E(ga mod p, K)

E(gb mod p, K)

Alice: K, a Bob: K, b

Session key KS = gab mod p

Alice forget sa, Bob forget sb
So-called Ephemeral Diffie-Hellman
Neither Alice nor Bob can later recover KS
?Are there other ways to achieve PFS
Part 3  Protocols
 Mutual Authentication, Session
Key and PFS
I’m Alice”, RA“

RB, [{RA, gb mod p}Alice]Bob

] }RB, ga mod p{[

Alice Bob

Alice Bob

 Session key is K = gab mod p

 Alice forgets a and Bob forgets b
 If Trudy later gets Bob’s and Alice’s secrets, she
cannot recover session key K
Part 3  Protocols
 Timestamps

A timestamp T is derived from current

time
Timestamps used in some security
protocols
Kerberos, for example 
Timestamps reduce number of msgs
(good)
Like a nonce that both sides know in advance 
Time” is a security-critical parameter“
(bad)
Clocks never exactly the same, so must
allow for clock skew  creates risk of
Part 3  Protocols
 Public Key Authentication with
Timestamp T

I’m Alice”, {[T, K]Alice}Bob“

}
Alice Bob ]T +1, K[{

Alice Bob

 Secure mutual authentication?

 Session key?
 Seems to be OK

Part 3  Protocols
 Public Key Authentication with
Timestamp T

I’m Alice”, [{T, K}Bob]Alice“

] }T +1, K{[
Bob Alice

Alice Bob

 Secure authentication and session key?

 Trudy can use Alice’s public key to find

{T, K}Bob and then…

Part 3  Protocols
 Public Key Authentication with
Timestamp T

I’m Trudy”, [{T, K}Bob]Trudy“

]
Bob Trudy }T +1, K{[

Trudy Bob

 Trudy obtains Alice-Bob session key K

 Note: Trudy must act within clock skew

Part 3  Protocols
 Public Key Authentication

…Sign and encrypt with nonce

Secure 
…Encrypt and sign with nonce
Secure 
…Sign and encrypt with timestamp
Secure 
…Encrypt and sign with timestamp
Insecure 
!Protocols can be subtle

Part 3  Protocols
 Public Key Authentication with
Timestamp T

I’m Alice”, [{T, K}Bob]Alice“

] }T +1{[
Bob Alice

Alice Bob

 Is this “encrypt and sign” secure?

o Yes, seems to be OK
 Does “sign and encrypt” also work here?

Part 3  Protocols
 Authentication and TCP

Part 3  Protocols
 TCP-based Authentication

TCP not intended for use as an authentication

protocol
But IP address in TCP connection often used
for authentication
One mode of IPSec uses IP address for
authentication
This can cause problems

Part 3  Protocols
 TCP 3-way Handshake

SYN, SEQ a

SYN, ACK a+1, SEQ b

ACK b+1, data

Alice Bob
 Recall the TCP three way handshake
 Initial SEQ numbers, SEQ a and SEQ b
o Supposed to be random
 If not…

Acknowledges the synchronization request,

SYN= synchronization
ACK= Acknowledges
Part 3  Protocols
 TCP Authentication Attack
SYN, SEQ = t (as .1
Trudy)
SYN, ACK = t+1, SEQ = .2
b1

…
SYN, SEQ = t (as .3
Trudy Alice) Bob
ACK = b2+1, data . 5

.5 .4
b2
=
.5 Q
, SE
1
.5 t+
=
ACK
Alice N ,
.5 SY

Part 3  Protocols
 TCP Authentication Attack

Initial SEQ numbers

Random SEQ numbers Mac OS X

 If initial SEQ numbers not very random…

 …possible to guess initial SEQ number…
 …and previous attack will succeed

Part 3  Protocols
 TCP Authentication Attack

Trudy cannot see what Bob sends, but she can 

send packets to Bob, while posing as Alice
Trudy must prevent Alice from receiving Bob’s 
packets (or else connection will terminate)
If password (or other authentication) 
required, this attack fails
If TCP connection is relied on for 
authentication, then attack can succeed
Bad idea to rely on TCP for authentication 

Part 3  Protocols
 Zero Knowledge Proofs

Part 3  Protocols
 Zero Knowledge Proof (ZKP)

Alice wants to prove that she knows a

secret without revealing any info about
it
Bob must verify that Alice knows secret
But Bob gains no info about the secret 
Process is probabilistic
Bob can verify that Alice knows the secret to 
an arbitrarily high probability
”An “interactive proof system
Part 3  Protocols
 Bob’s Cave

Alice knows secret

phrase to open P
path between R
and S (“open
sarsaparilla”) Q
Can she convince R S
Bob that she
knows the secret
without revealing
?phrase
Part 3  Protocols
 Bob’s Cave

Bob: “Alice come out on S  P

”side
Alice (quietly): “Open 
”sarsaparilla
Q
If Alice does not know the 
…secret R S

then Alice could come out from the correct side with probability 1/2… 

If Bob repeats this n times, then Alice (who does not know secret) can only 
fool Bob with probability 1/2n

Part 3  Protocols
 Best Authentication Protocol?
…It depends on
The sensitivity of the application/data 
The delay that is tolerable 
The cost (computation) that is tolerable 
What crypto is supported (public key, 
symmetric key, …)
Whether mutual authentication is required 
Whether PFS, anonymity, etc., are concern 
and possibly other factors…

Part 3  Protocols