Paul,
Before the one roundtrip mechanism is deleted, could you summarize how
the security issue that was raised is applicable under the threat model
we work with? Let me help you out. It is not really applicable. Here
is why:
RFC 3552 says that "While it is not a requirement that any given
protocol or system be
immune to all forms of attack, it is still necessary for authors to
consider as many forms as possible. Part of the purpose of the
Security Considerations section is to explain what attacks are out of
scope and what countermeasures can be applied to defend against them.
In"
That poorly written and poorly edited RFC (notice the dangling "In") is
all we have as guidance unfortunately. What it does say is that it is
perfectly fine to specify what attacks are out of scope. We cannot have
someone noting that "auditors" will force large installations to do this
or that and have that dictate using a grossly inefficient resumption
protocol! It begs that questions of who those auditors are, what
jurisdiction they are operating under and assuming what threat model?
The IKEv2 RFC really defines what is in scope. Server state exhaustion
attacks are not in scope for being mandatorily made "more difficult" for
some definition of more.
Finally, if we don't like options, we are in the wrong standards body!
When we design a security protocol for a variety of threat models and
performance constraints, we are bound to have options.
Thank you.
best regards,
Lakshminath
On 4/20/2009 10:45 PM, Paul Hoffman wrote:
<co-chair hat on>
Greetings again. Of the people who replied, two favored mandating two
round trips, and one favored keeping the current one round trip. That
(anemic) result, plus the comment that lead to this thread, leads me
to say that we need to change draft-ietf-ipsecme-ikev2-resumption to
require two round trips.
Draft authors: please prepare a -03 with only the two-round-trip
solution, and pull out the text about the one-round-trip option.
If someone really objects to this, please prepare a personal Internet
Draft that lists exactly how you would change the current -03 draft
to cover all the security issues that were brought forward.
--Paul Hoffman, Director --VPN Consortium
_______________________________________________ IPsec mailing list
IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
