Re: Choosing between IKEv2 and JFK

[Eric Rescorla <ekr@rtfm.com>]

Dan Harkins <dharkins@tibernian.com> writes:
>   I respectfully disagree with statement "both protocols are resistant
> to DoS attacks based on computational loading." Because JFK does not
> bind the authenticator blob to the initiator it is susceptible to a
> varient of Simpson's "cookie jar" attack. IKEv2 is not because its 
> "stateless cookie" is bound to the initiator.
> 
>   It would be trivial to fix this problem but I guess the authors do
> not intend on fixing it since I first brought it up during the SLC IETF
> with the -00.txt version of JFK and it was not fixed in the -01.txt
> version.
> 
>   This is a significant difference between the two.
Dan, I want to apologize to you for not getting back to you
earlier. You sent me this comment in private e-mail. I didn't
respond immediately because I wanted to take the time to
digest it, but then I just got swamped.

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. 

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.

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?

-Ekr