Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard

[Peny Yang <[e-mail]>]

On Thu, Sep 3, 2009 at 5:11 PM, Tero Kivinen<[e-mail]> 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.

> --
> [e-mail]
>