[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: IKMP Security Exchange Negotiation

---------------------------------- Forwarded ----------------------------------
From: Lambert Paul P15452 at AZ-SECTEL
Date: 12/16/94 6:16PM
To: ipsec@ans.net at #EMAIL
cc: Lambert Paul P15452
Subject: Re[2]: IKMP Security Exchange Negotiation
-------------------------------------------------------------------------------

Excuse the double posting if this has already hit the list.

p.l.
_______________________________________________________________________________
Subject: Re: IKMP Security Exchange Negotiation
Author:  Lambert Paul P15452
Date:    12/14/94  2:48 PM



Here are a few ramblings about negotiation of different IKMP key establishment 
approaches.

Paul

-------------------

>ashar<
>Like you said, it isn't free. If you dont want it, dont need it,
>you shouldn't have to pay for it.


>     Paul,
>
>     I pretty much agree with this....how do we get an IMKP protocol that
>     will let us do both?
>
>     Jim Zmuda

Jim,

Use of a SAMP-like Security Exchange option negotiation might work.
for example if we have Security Exchange Identifiers: A, B, C
each with defined exchanges:

A1, A2, A3, A4, A5, A6

B1, B2, B3, B4

C1, C2, C3, C4

The sequence of events (e.g. A1 to An) could correspond to a D-H exchange, a 
Photuris exchange (with cookies), or any other key establishment exchange.

As an example you could send PDUs like:
Note the arrows (  ->  and <-  indicate the flow of duplex traffic)


Example 1 - Initiator declares that it can use A, B, or C security exchanges.  
Responder picks B.  Exchange continues.

->  (A,),(B,),(C,)
<-  (B,)
->  (B,B1)
<-  (B,B2)
->  (B,B3)
... etc.



or 

Example 2 - Initiator declares A, or B and includes the first exchange info for 
both A and B.  The responder replies with B and the second exchange step of B.  
Note that this saves two steps over example 1.


->  (A,A1),(B,B1)
<-  (B,B2)

... etc.


Example 3 - Initiator declares support for A, B, or C and includes the first 
exchange for A.  Note that ordering could indicate initiator preference in the 
negotiation.  This examples shows how the protocol can be optimized for a 
prefered approach, A, but still allow negotiation to another technique.

->  (A,A1),(B,),(C,)
<-  (A,A2)
->  (A,A3)
->  (A,A4)
... etc.


This negotiation approach would work quite well to support the various security 
requirements that the working group is pursuing.  As another example, assume we 
have two Diffie-Hellman based exchanges:

DH - a basic Diffie-Hellman approach
KC - a Diffie-Hellman exchange with two extra exchanges to support cookie 
     PDUs to reduce the impact of flooding attacks (Karn-Cookies).



Example 4 - most systems might not want to use the extra PDUs to limit the 
flooding attacks.  Most of the time the two extra cookie PDUs are not needed.
->  (DH,DH1),(KC,)
<-  (DH,DH2)
... etc.

Example 5 - The cookies are needed when a recipient feels threatened (purhaps 
it just recieved a bogus DH initiation).  It is then very important to allow 
the recipient to request a cookie using a stateless response:
->  (DH,DH1),(KC,)
<-  (KC,)
->  (KC,KC1)
<-  (KC,KC2)
... etc.

Example 6 - Example 6 adds two PDUs beyond the cookie exchange.  This could be 
reduced if initiators always sent a cookie along with the more common DH (my 
assumption) exchange:
->  (DH,DH1),(KC,KC1)
<-  (KC,KC2)
... etc.


Example 6 may not be worth the extra exchange bits if example 5 is an uncommon 
scenario.