I agree that if session resumption is implemented, it is a good way to
reduce the problem drastically. Resuming clients go to the "fast track",
and any new connections get the anti-DOS treatment - cookie- or
puzzle-based.
To answer Yoav's two objections:
1. This is a standard trade-off. We can only hope people will eventually
find a way to notify the IKE gateway when a password is changed, which
would enable longer ticket lifetimes.
2. Quoting RFC 5723:
This document therefore requires that the ticket be presented to the
IKEv2 responder only once; under normal circumstances (e.g., no
active attacker), there should be no multiple use of the same ticket.
We are not aware of additional security issues associated with ticket
reuse: the protocol guarantees freshness of the generated crypto
material even in such cases. As noted in Section 4.3.1, the gateway
SHOULD prevent multiple uses of the same ticket. But this is only an
extra precaution, to ensure that clients do not implement reuse. In
other words, the gateway is not expected to cache old tickets for
extended periods of time.
Thanks,
Yaron
On 09/25/2014 08:02 PM, Yoav Nir wrote:
On Sep 25, 2014, at 2:27 PM, Tero Kivinen <[email protected]> wrote:
Michael Richardson writes:
Yoav Nir <[email protected]> wrote:
One proposal that I kind of liked (and I’m sorry I’ve forgotten who
suggested it) was to relegate the puzzle to a second line of defense,
through the use of some kind of anti-dos ticket. The ticket would be a
bearer token (perhaps an encrypted timestamp) that would allow the
bearer to get by with a much easier version of the puzzle. The
Would this ticket be provided in a Notify, after AUTHentication, in a
previous PARENT-SA?
Wouldn't it be better to use IKEv2 session resumption (RFC 5723) for
those clients coming back.
I.e if you resume old existing session then you do not need to do
puzzle... And after the resume, the ticket is usually changed again,
so the ticket would always be fresh.
That’s possible. But session tickets are different from these tickets in two
ways:
1. Session tickets are time-limited with a rather short validity period. If
policy requires checking the certificate / password every two hours, then the
ticket cannot be valid for more than that.
2. Session tickets must not be replayed, so the gateway has to use some very
strict anti-replay mechanisms.
The proposed tickets can be valid for a long time, and while replay prevention
is desired, it doesn’t need to be very strict.
This laxness has operational benefits. It’s easier to implement in a cluster of
gateways, and a ticket will be valid even for a user that hasn’t connected in a
while. This makes sense because the prize from a replayed RFC 5723 ticket is
great - a valid, authenticated session. OTOH managing to replay this new kind
of ticket only gets you a half-open SA without bothering to solve a puzzle.
Yoav
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
