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

Re: A fix for main mode with preshared keys



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: