It seems to me the difference between the two options is not very
important (assuming reasonable rate limits), because the cost of
receiving an IKE_AUTH message and detecting an incorrect MAC is not very
high, after the initial generation of the IKE SA key material.
But Yoav's model also demonstrates that we could get the same effect by
attaching the puzzle to IKE_AUTH - though I don't see an advantage.
Re: RFC 6989, yes, the test refers to IKE_SA_INIT. But the response
message does not depend on the received DH public key, so IMHO it's fine
to postpone the test until IKE_AUTH is received, and before generating
the IKE shared key.
Thanks,
Yaron
On 10/06/2014 11:31 AM, Graham Bartlett (grbartle) wrote:
Hi
This is a very interesting attack, I would dismiss (1) as it leaves an
implementation open for a semi-easy DOS (just one packet that generates
work rate on both initiator and responder).
Basing the behaviour on (2) the attacker would only have the window from
when the responder sends the SA_INIT, to receiving the (valid) IKE_AUTH.
As Nico said shortening the time is critical, but also once the responder
receives a valid IKE_AUTH it should (IMO) dismiss any more IKE_AUTH
messages it receives.
I guess you could look at rate limiting IKE_AUTH messages if they fail to
decrypt, but then you could drop the legit IKE_AUTH. Unless the attacker
is very very lucky (in their packet generation), or has the authentication
credentials they will not be able to send a valid IKE_AUTH, so the window
that occurs between the responder receiving the valid IKE_AUTH is key.
I see the potential for an attacker dropping, or delaying the legit
IKE_AUTH and then sending many IKE_AUTH as you said, so if the behaviour
was set to 10s if a device detected it was under this attack it should
reduce the window of time to process IKE_AUTH (as Nico said), but once
again this could then drop the legit IKE_AUTH.
As I understand the RFC6989 checks are performed on the public value
received in SA_INIT, no IKE_AUTH. (FROM RFC6989) "A receiving peer MUST
check that its peer's public value is valid;", so these checks (as I
understand) would be performed before the responder sends the SA_INIT.
So to summarise, I think that (1) is worse, (2) should be implemented
(maybe with a different timer), but with guidance on what to do should a
device become under attack.
cheers
On 05/10/2014 21:22, "Yoav Nir" <ynir.i...@gmail.com> wrote:
Hi, Yaron
On Oct 5, 2014, at 10:56 PM, Yaron Sheffer <yaronf.i...@gmail.com> wrote:
- I'm not sure what is special about "[the case] when an Authentication
request fails to decrypt." Seems to me this is a verified DoS attack
>from a specific IP.
I see I wasn¹t clear about this, because both you and Graham missed what
I meant.
Suppose we have a responder where half-open SAs time out after 10
seconds.
This responder receives an Initial Request, and responds with an Initial
Response.
It stores its own private value and the peer¹s public value in the
half-open SA database, keyed by IKE SPIs.
0.5 seconds later, it receives an IKE_AUTH request with the right IKE
SPIs.
It derives the keys (making any ECDH check that¹s needed)
It tries to decrypt the message
The message fails to decrypt (or more likely, the MAC comparison fails)
Now the responder has two options:
(1) delete the entry in the half-open SA database, or
(2) store the derived key, and keep the half-open SA another 9.5 seconds.
(2) has the disadvantage that the attacker can keep sending more junk
packets and get the responder to attempt to decrypt all of them.
(1) has the disadvantage that an attacker can inject a junk IKE_AUTH
request by just copying the IKE SPIs from the IKE_INIT response, which
will prevent the responder from processing the real initiator¹s IKE_AUTH
request.
So I¹m not sure which is worse.
Yoav
_______________________________________________
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
