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

RE: Some comments to draft-ietf-ipsec-ikev2-00.txt





On Tue, 11 Dec 2001, Andrew Krywaniuk wrote:

> >  > 3.1 Generating Keying Material for the IKE-SA
> > ...
> >  >        SKEYSEED = prf(Ni | Nr, g^ir)
> >
> > As this is the only place where nonces are used their entropy is
> > limited to the output of the PRF. I.e it is no use of using nonces
> > whose combined entropy is more than 128 bits if we using the HMAC-MD5
> > as PRF, as the output of the SKEYSEED is going to be 128 bits.
> >
> >  >        SKEYSEED_d = prf(SKEYSEED, g^ir | CKY-I | CKY-R | 0)
> >  >        SKEYSEED_a = prf(SKEYSEED, SKEYSEED_d | g^ir |
> > CKY-I | CKY-R | 1)
> >  >        SKEYSEED_e = prf(SKEYSEED, SKEYSEED_a | g^ir |
> > CKY-I | CKY-R | 2)
> >
> > I think that could be fixed by adding the nonces to the above
> > calculations also in addition of the cookies.
> 
> 
> Or by simply replacing the cookies with the nonces. That would be the
> *obvious* method ;-)

Introducing the nones would be ok, though I do not believe it would
practically make any difference (since they are already included under the
SKEYID computation). The reason to have the cookies is since they
act as a"session identifier" and it is good practice (and analytical 
advantage) to bind the keying material to the specific session.

> 
> Still, I notice that IKEv2 carries forward the "broken" phase 1 key
> stretching algorithm from IKEv1:
> 
>       K1 = prf(SKEYSEED_e, 0)
>       K2 = prf(SKEYSEED_e, K1)
>       K3 = prf(SKEYSEED_e, K2)
> 
> As was noted from earlier discussions, g^xy ought to be reintroduced at each
> stage in order to preserve the full entropy of the key exchange.

This is not broken. There is no need to re-introduce g^xy in each
computation. Quite the opposite, from an analytical point of view, 
it would be broken to 
re-introduce g^xy into the computation. As a general pricniple,
if you have two keys k and k' where k' was derived from k 
then applying prf(k', k) (here k' is the key to the prf and k the input)
may be insecure even if prf is an excelent pseudorandom function family
(see the book of Goldreich on the Foundations of Cryptography).
The same is the case if k' is derived from k through a chain of derivations:
in our case g^xy -> SKEYSEED -> SKEYSEED_e
so if you appply now prf(SKEYSEED_e, g^xy ....)
as you suggest then the theoretical anlysis is broken. 

And it makes no difference for the above argument if your prf is
generic or specifically HMAC as used in both JFK and IKEv2

Hugo

> 
> Andrew
> -------------------------------------------
> There are no rules, only regulations. Luckily,
> history has shown that with time, hard work,
> and lots of love, anyone can be a technocrat.
> 
> 
> 




Follow-Ups: References: