ietf
[Top] [All Lists]

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

2009-09-03 10:43:09
On Thu, Sep 3, 2009 at 5:11 PM, Tero Kivinen<kivinen(_at_)iki(_dot_)fi> 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(_at_)iki(_dot_)fi

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf