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

Login Protocols

Ø Shared Secret Protocols  

 

v 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

By knowing both R and f (K,R).

 

v Protocol 2:

  
{===============================

Alice                                                           Bob

I'm Alice                                                       >
<                                                                K{R}
R                                                                    >

===============================}

 

K{R}  is an  encryption  and

not  a hash function (since it is not reversible).

 

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

(to avoid replay attach).

Beside 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.

 

*   Thus  Clock-setting     could be serious    security vulnerability.

 

 

 

Ø One-way Public Key Protocols
 

In the above 4 protocols, Trudy can impersonate Alice if she can read Bob's database.

This can be avoided by using public key technology.
   

v Protocol 5:

 
{=================================
Alice                                                                 Bob  

I'm Alice                                                            >
<                                                                          R
sign R:  [R]Alice                                                  >

 

==================================}

Pitfalls:

Trudy can trick Alice into signing something she does not know!

 

v 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 solution for the above two pitfalls is to make sure that:

             R has a known type/structure.

 

 

 

Mutual Authentication

 

Ø Shared Secret Protocols
  

v Protocol 7: 

 
{=================================

Alice                                                                Bob

I'm Alice                                                          >
<                                                                       Rb
f(K, Rb)                                                            >


Ra                                                                      >
<                                                               f(K, Ra)

=================================} 

 

v 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)                                                              >

=================================}

 

*   This causes many problems!

 

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:
Each add his/her  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).

 

 

v 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 from 5 to 4 as follows:
 

{===============================

Alice                                                            Bob

I'm Alice                                                        >
<                                                                    Rb
f(K, Rb), Ra                                                   >
<                                                           f(K, Ra)

===============================}

 

v Protocol 10:    

We can use time stamps to reduce the number of messages to 2:

{===============================

Alice                                                           Bob

I'm Alice,  f(K, timestamp)                            >
<                                          f(K, timestamp++)

===============================}
 

Ø Two-way Public Key Protocols

v Protocol 11:  sign/verify

 

 
{==============================

Alice                                                          Bob  

I'm Alice , Ra                                               >
<                                                 [Ra]Bob , Rb
[Rb]Alice                                                          >

==============================}

 

 

v Protocol 12:   encrypt/decrypt

 

 

{===============================

Alice                                                     Bob

I'm Alice,  {Ra}Bob                                    >
<                                                Ra, {Rb}Alice
Rb                                                              >

===============================}

 

  

Mediated Authentication

 

Ø 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--}                                                                          >

=======================================}

 

ü  N1, N2 and N3  are  nonces. A nonce is a number that is used only once

          (e.g., a sequence numer, random number, timestamp).

ü N1: to prevent Trudy from impersonating KDC and   replaying old replies to Alice.

ü N2 & 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++}

============================================}