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

Re: A fix for main mode with preshared keys

     
Hugo,

I like very much your solution based on redifining SKEYID_e.

Concerning the ID_KEY_ID solution, if I understand it correctly, it works when 
the key is shared between two parties only.  It does not work in the case where 
it is shared by multiple parties (e.g. all machines in a given domain).  And in 
the case of two parties, it has the synchronization problems that were pointed 
out by Andrew Krywaniuk.  So I think the SKEYD_e solution is much better.

Francisco


______________________________ Reply Separator _________________________________
Subject: Re: A fix for main mode with preshared keys
Author:  Non-HP-hugo (hugo@ee.technion.ac.il) at HP-ColSprings,mimegw5
Date:    12/12/99 8:33 AM


     
     
On Tue, 7 Dec 1999 francisco_corella@hp.com wrote:
     
[........]
     
> But there is no reason why the keying material should be derived from 
> these two sources.  In other protocols that use ephemeral 
> Diffie-Hellman, the keying material is derived only from the 
> Diffie-Hellman secret.
     
Mixing both g^xy and the pre-shared key provides additional strength 
to the protocol: even if the DH group is eventually cryptanalyzed 
you still need to know what the pre-shared key was in order to 
find the keys that protect(ed) the ipsec traffic (this may seem as 
a surrealistic improvement for whoever believes that no DH group
in use today will ever be cryptanalyzed -- but I prefer to be in the 
safe side when the improvement costs nothing).
     
For the problem at hand, I prefer the solution (as described by Dan 
Harkins) via ID_KEY_ID. 
     
If for whatever reasons (e.g., to avoid tracing attacks via repeated 
ID_KEY_ID values, though Dan's solution refers to that too)
one still wants a solution of the type outlined by Francisco in the next 
paragraph:
     
> 
> So I'd like to propose that we derive the keying material exclusively 
> from the Diffie-Hellman secret.  One way of doing this with minimal 
> change to the existing protocol is simply to change 
> 
>       SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
>       SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) 
>       SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) 
> 
> to
> 
>       SKEYID_d = hash(g^xy | CKY-I | CKY-R | 0)
>       SKEYID_a = hash(SKEYID_d | g^xy | CKY-I | CKY-R | 1) 
>       SKEYID_e = hash(SKEYID_a | g^xy | CKY-I | CKY-R | 2) 
> 
> I believe this solves the problem. 
>   
     
then I suggest a different change:
     
leave the definition of SKEYID_d and SKEYID_a unchanged (why weaken 
unnecessarily the really important keys?), and change SKEYID_e to:
     
   SKEYID_e = prf(hash(Ni_b | Nr_b), g^xy | CKY-I | CKY-R | 2)
     
this preserves the general design in IKE by which the prf "hashes" the 
value g^xy in order to extract the "computational entropy" from the DH 
key.
It weakens a bit SKEYID_e but this only impacts the security of 
identity protection. It leaves SKEYID_d and SKEYID_a (and thus 
the main security of IKE) unchanged.
     
Hugo
Follow-Ups: References: