Subject: [IPsec] DH Tests draft - failure behavior

From: Yaron Sheffer <[email-masked]>
Date: Tue, 12 Mar 2013 16:48:46 +0200

Following up on the discussion we just had:

Paul raised the question whether we should respond with an error message 
in case any of the tests fail. We know from many examples that errors 
can reveal secret information.

However in this particular case:

- All IKEv2 DH groups are public information.
- All of the proposed tests only depend on public information, plus the 
information received from the sender in the clear. In other words, the 
test could just as well be performed by an eavesdropper.

The only thing that such an error message does reveal is that the 
receiver implements the test, but this is something that an attacker can 
find out anyway.

Which is why I think we should treat such failures as a normal syntax 
error, and respond with an error message, as a courtesy to the sender.

We should make these considerations explicit in the draft, specifically 
that the groups are well known.

Thanks,
     Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Mar 2013 19:44:27 +0200

> that the groups are well known.

On the other hand failure there means we didn't manage to negotiate
shared secret, thus the whatever error message we sent out must be
unauthenticated. The recipient of such unauthenticated notify cannot
act directly on it, as attacker might have sent it instead of the real
peer, and real peer might actually take some time to do the checks and
other calculations before answering. Befcause of this sending the
notification does not help that much, it only opens new way to do DoS
attack. As this error cannot happen in valid implementations, it is
always either attack or implementation working incorrectly, I see no
point of making special code for error messages in that case.

My recommendation is that the recipient will simply silently ignore
the IKE_SA_INIT packet having invalid KE payload. It MAY continue
keep setting up the SA, i.e. see if there is properly formatted and
generated KE payload in the future. Otherwise the attacker could again
do DoS attack against the peer, by sending there IKE_SA_INIT response
with invalid KE payload and cause inititor to drop the connection
before the real responder have time to reply. 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 12 Mar 2013 22:40:39 +0200

Hi Tero,

I think this case should be handled exactly like any badly formatted 
message.

Referring to http://tools.ietf.org/html/rfc5996#section-2.21.1, we did 
not mandate sending errors back, but it is implied in the text. And yes, 
the receiver is free to ignore these errors for the reasons you cite. In 
fact there's no obvious remedial action anyway, similarly to "invalid 
syntax", the error basically indicates a bug. So sending this error just 
helps in debugging the sender and nothing more. But IMHO this is still a 
good reason to send it.

Thanks,
	Yaron