Re: Choosing between IKEv2 and JFK

[Dan Harkins <dharkins@tibernian.com>]

On 12 Mar 2002 10:42:05 PST you wrote
>
> That said, I'm not sure that I agree with your assessment of
> this problem. Recall that JFK requires the responder to
> cache message 4s and simply replay them in response to duplicate
> message 3s. 

But they are not duplicate message 3s. They all have different Ni,g^i
pairs and therefore different authenticator blobs. All the Ni,g^i pairs
are different, and garbage. I even pointed out that it is not necessary
to retain all the Ni,g^i pairs generated as bogus message 1s in order to
construct the correct (and unique!) message 3s with the correct Ni,g^i
pairs accompanying the authenticator blob that is bound to them. All the
message 3s are bogus, all contain unique Ni,g^i pairs and authenticator
blobs, all are sent from random IP addresses, and the JFK implementation
must exponentiate for each one of them.

Caching authenticator blobs and blacklisting the naughty ones will not
stop this attack.

> In an exchange on or around Dec 3, Angelos and I had the
> following exchange (>> is me and > is Angelos).
> 
> >>
> >>    The Responder keeps a copy of recently-received Message (3)'s, and
> >>    their corresponding Message (4). Receiving a duplicate (or
> >>    replayed) Message (3) causes the Responder to simply retransmit the
> >>    corresponding Message (4), without creating new state or invoking IPsec
>.
> >>
> >>This suggests that the cache lookup is performed on the entire message 3.
> >>E.g. 
> >>
> >>      if(msg4=table_lookup(message3,message3_len)){
> >>        retransmit(msg4);
> >>      }
> >>      else ...
> >>
> >>However, this may open the responder to a DoS attack whereby the
> >>attacker replays copies of message 3 with different encrypted blocks
> >>(i.e. garbage).  The attacker can thereby force a cache miss and force
> >>the responder to repeatedly compute g^ir while attempting to process
> >>these messages.  This entails no particular computational burden on
> >>the attacker.
> >>
> >>The easiest fix for this is for the responder to use only the
> >>authenticated data (Ni,Nr,g^i,g^r) or simply HKr as the cache key.
> 
> >Yes -- sorry, I suppose that wasn't clear in the text; the intent was to
> >have the authenticator be the key.
> 
> It seems to me that your attack is isomorphic to the attack I'm
> describing and the fix is the same: use the authenticator as
> the cache lookup key.

No because all the authentictors are different for these message 3s that
are being flooded to the JFK implementation from random IP addresses.

The fix is to include the initiator's IP address in the authenticator
blob calculations.

> Actually, now that I think of it, it seems like my attack is
> possible against IKEv2 as well. Doesn't IKEv2 need a similar
> cache?

Yes, an IKEv2 implementation should maintain a blacklist or cache of bad 
"stateless cookies" it has received so as to not continue to exponentiate
when it is received again. I think it would be prudent to blacklist IP 
addresses as well once the attack is discovered.

But the attack I described against JFK is not possible against IKEv2.

In addition, it is possible to infer the rough location of the attacker
with IKEv2. The "stateless cookie" must be returned from the same IP 
address to which it was sent and if it is not the message will be thrown
away without any serious computational burden. If it is returned from the
same IP address and the attack is detected (and the cookie is blacklisted)
that IP address can be noted. The location of the attacker has been
narrowed. With JFK you have no idea.

  Dan.