Security Handshake Protocols
The following is a series of
security handshake protocols.
They are presented and
evaluated according to:
security & pereformance
The performance parameters
are:
·
Number of messages,
·
Processing
power required, and
·
Compactness of messages
Å Shared Secret
«
Protocol 1:
Alice
Bob
I'm
Alice
>
<
a Challenge R
f(K, R)
>
f(K, R) : K is a shared secret between Alice and Bob.
f can be either encryption or hash function.
Ø Pitfalls:
An eavesdropper
could mount an off-line
passwd-guessing attack
knowing both R and f (K,R).
«
Protocol 2:
Alice
Bob
I'm Alice
>
<
K{R}
R
>
K{R} is an encryption and not a hash function.
Ø Pitfalls:
· If R is a recognizable quantity (e.g., a 32-bit random number padded with 32 zero
bits to fill out an encryption block), then Trudy, without eavesdropping, may mount a
dictionary attack by sending:
I'm Alice" and obtaining K{R}.
· On the other hand, Alice can authenticate Bob by Recognizing the 32 zero bits of R
· To foil the replaying of K{R} (Trudy impersonate Bob to Alice) Use a timestamp instead of
32 zero bits
to fill the
encryption block.
« Protocol 3 & 4:
Alice Bob
Protocol 3:
I'm Alice, K{timestamp}
>
Protocol 4:
I'm
Alice, timestamp, hash {K, timestamp} >
These two
protocols require both Alice and Bob to have reasonably synchronized clocks.
Besides saving two messages, Bob does not need to keep any volatile state (e.g., R).
Ø Pitfalls:
·
If
Alice using the same K on multiple
servers,
Trudy can send the same
message to another server as Alice!
·
Even
if Alice is using K for only one server,
If Trudy can reset back Bob's clock, he can impersonate Alice.
Clock-setting could be serious security vulnerability.
Å One-way Public Key
In
the above four protocols,
Trudy
can impersonate Alice
if she can read Bob's
database.
This
can be avoided by using public key technology.
«
Protocol 5:
Alice
Bob
I'm Alice
>
<
R
sign R: [R]Alice >
Ø Pitfall:
Trudy can trick
Alice into signing something she does not know!
«
Protocol 6:
Alice
Bob
I'm Alice
>
X <
{R}Alice
sign X: R = [X]Alice
>
Ø Pitfalls:
Trudy can trick
Alice into decrypting a message sent to Alice by someone else
that he likes to read.
ü The solutions
for the above pitfalls are to make sure that:
R has a known type/structure.
Å Shared Secret
«
Protocol 7:
Alice
Bob
I'm
Alice
>
<
Rb
f(K, Rb)
>
Ra
>
<
f(K, Ra)
«
Protocol 8:
Reduce number of messages in Protocol 7
by putting
more
than one item of
information into each message:
Alice Bob
I'm
Alice, Ra
>
<
f(K, Ra), Rb
f(K, Rb) >
Ø Pitfall 1: Reflection
Attack
Trudy can impersonate
Alice to Bob by:
Opening a second connection
to Bob
(or
to another sever that share the same secret with Alice):
Session1:
Trudy
Bob
I'm
Alice, Ra
>
<
f(K, Ra), Rb
suspend session 1......
Session 2:
Trudy Bob
I'm Alice, Rb
>
<
f(K, Rb),
Rb'
abort session 2.......
continue session 1......
f(K, Rb)
>
Possible
fix:
Add your name to the
encrypted quantity:
Alice
Bob
I'm Alice, Ra
>
<
f(K, Bob|Ra), Rb
f(K, Alice|Rb)
>
Why Protocol
7 does not suffer from the reflection attack?
It follows a good
security principle:
The initiator should be the first to prove its identity.
Ø
Pitfall
2: Passwod guessing
Trudy may mount an off-line password guessing attack:
Trudy
Bob
I'm
Alice, Ra
>
<
f(K,
Ra), Rb
.........
suspend session and
use: Ra, and f(K,Ra) to guess K.
Protocol 7 does not suffer from such attack
(though Trudy can impersonate Bob to
mount such attack,
but
it is much more difficult to impersonate Bob than to impersonate Alice).
«
Protocol 9:
Protocol 7 is very good, since it does not suffer from Reflection and Password attacks.
We can improve it by reducing the number of messages to four
instead of five as follows:
Alice
Bob
I'm Alice
>
<
Rb
f(K, Rb), Ra
>
<
f(K, Ra)
« Protocol 10:
We
can use time stamps to reduce
the number of messages to two:
Alice
Bob
I'm
Alice, f(K,
timestamp)
>
<
f(K, timestamp++)
Å Two-way Public Key
«
Protocol 11:
Alice
Bob
I'm Alice , Ra
>
<
[Ra]Bob , Rb
[Rb]Alice
>
«
Protocol 12:
Alice
Bob
I'm Alice, {Ra}Bob
>
<
Ra, {Rb}Alice
Rb
>
KDC operation (in Principle):
Alice KDC
Bob
Alice
wants Bob
>
<
Ka {use Kab for Bob}
Kb {use Kab for Alice}
>
KDC operation (in Practice):
Alice KDC
Bob
Alice
wants Bob
>
< Ka {use
Kab for Bob},
ticket to Bob = Kb {use Kab for Alice}
"I'm
Alice", ticket to Bob
>
..........
mutual authentication using Kab ...........
Classical Examples of KDC
authentication
The Basic Needham-Shroeder Protocol
Alice
KDC
Bob
N1, Alice wants Bob
>
<
Ka {N1,"Bob", Kab,
ticket to Bob},
where ticket to Bob = Kb
{Kab, "Alice"}
ticket to Bob, Kab{N2}
>
<
Kab{N2--, N3}
Kab {N3--}
>
· Nx: is a "Nonce", a number that is used only once
(e.g., random number, timestamp, etc.).
· N1: to prevent Trudy from impersonating KDC and
replaying
old replies to Alice.
· N2 and N3 are
challenges for mutual authentication.
The Kerberos Authentication
Protocol:
It is
based on Needham-Shroered protocol, but is much
simpler since it is based on timestamp
and the ticket includes expiration date.
Alice
KDC
Bob
N1, Alice wants Bob
>
<
Ka{N1,"Bob", Kab, ticket
to Bob},
where ticket to Bob = Kb {Kab, "Alice", expiration time}
ticket to Bob, Kab{timestamp}
>
<
Kab{timestamp++}