Hi Hui,
Thank you for your comments. Regarding your second comment, please see
http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-resumption-08#section-9.4
Regards,
Yaron
-----Original Message-----
From: Hui Deng [mailto:denghui02(_at_)gmail(_dot_)com]
Sent: Tuesday, September 22, 2009 17:40
To: Tero Kivinen
Cc: Yaron Sheffer; IPsecme WG; ietf(_at_)ietf(_dot_)org; Peny Yang
Subject: Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption
(IKEv2 Session Resumption) to Proposed Standard
Comments inline, thanks
2009/9/3 Tero Kivinen <kivinen(_at_)iki(_dot_)fi>:
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).
[Hui] I don't think so. IMO, in the list, the comparison of extended
IKE_SA_INIT exchange and IKE_SESSION_RESUME still did not have a consensus
yet.
It was a ballot in the mailing list in the begining, and it is quite
clear more people opposing
sepaparate exchange, we could do one more round ballot if needed.
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.
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.
[Hui] I also agree with Peny and Tero. Although way of detecting
failure of gateways is out of the scope of current charter, WG draft
should at least handle the issues incurred by mis-judgement of client.
thanks
-Hui
Scanned by Check Point Total Security Gateway.
Email secured by Check Point
Email secured by Check Point
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf