On Thu, Sep 3, 2009 at 5:11 PM, Tero Kivinen<kivinen@xxxxxx> wrote: > Yaron Sheffer writes: >> [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in >> fact an early version of our work did exactly that. But the working group >> gave us a clear direction to use a separate exchange, and this is where we >> disagree: I believe we did have a strong WG consensus that the >> implementation benefits of having a separate exchange (i.e. not overloading >> even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the >> alternative. > > I agree on that (both to the WG having consensus and also that using > separate exchange is better). >> > I know that how a client detects the need for resumption is out of the >> > scope of this draft. But, there is the possibility that IPsec client >> > may be continuously deceived and believe the fail of IPsec gateway. It >> > may continuously present the ticket and update the ticket. In this >> > sense, IMHO, this draft should take care of this case. >> > >> [YS] If I understand the scenario correctly, it is similar to an attacker >> repeatedly sending notifications to an IKE client, making it believe that >> the IKE exchange has failed and needs to be reinitiated. This attack against >> plain-vanilla IKE would be much more CPU-intensive to the client and to the >> (real) gateway, compared to repeated session resumption. Even when you >> factor in the cost of generating a new ticket. Moreover, the regular IKEv2 >> anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. > > Regardless what notifications or ICMP messages you send to any of the > IKE end points that MUST NOT cause them to consider IKE SA failed. It > "MUST conclude that the other endpoind has failed only when repeated > attemtps to contact it have gone unanswered for timeout period or when > a cryptographically protected INITIAL_CONTACT notification is received > on a different IKE SA to the same authenticated identity." (RFC 4306 > section 2.4) > > Notifications and ICMP messages may trigger other end to send empty > INFORMATIONAL message to check whether the other end is alive or not > and only if that times out then the other end is considered dead. > > This means this kind of attack is not possible with notifications and > ICMP. [Peny] Agree. I did not mean this kind of attacking originally. > > On the other hand I do agree with Peny that, as resumption draft makes > it out of scope for this draft, how a client detects the need of > resumption, we might need more text explaining this attack. I.e. we > might need to add text to security considerations which says that the > client implementations should not trust any untrusted source when they > are trying to detect whether the resumption is needed. [Peny] Agree. I also think we need more text to clarify this issue. In this meanwhile, I think the way in section 4.3.4 is not appropriate. Gateway should not silently delete the related SAs in this case. One possible solution is to use the anti-DOS cookie mechanism of IKEv2 to handle this issue. > -- > kivinen@xxxxxx > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf