[IPsec] DH Tests draft - failure behavior

Tero Kivinen <kivinen@iki.fi> Tue, 12 March 2013 17:45 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9829321F89EE for <ipsec@ietfa.amsl.com>; Tue, 12 Mar 2013 10:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.419
X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SizQrPAcGg54 for <ipsec@ietfa.amsl.com>; Tue, 12 Mar 2013 10:45:54 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi []) by ietfa.amsl.com (Postfix) with ESMTP id 57A6D21F89B5 for <ipsec@ietf.org>; Tue, 12 Mar 2013 10:45:53 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost []) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r2CHiSJq022444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Mar 2013 19:44:28 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r2CHiRfx023705; Tue, 12 Mar 2013 19:44:27 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20799.27003.633105.446538@fireball.kivinen.iki.fi>
Date: Tue, 12 Mar 2013 19:44:27 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
In-Reply-To: <513F404E.5060608@gmail.com>
References: <513F404E.5060608@gmail.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 5 min
X-Total-Time: 5 min
Cc: IPsecme WG <ipsec@ietf.org>
Subject: [IPsec] DH Tests draft - failure behavior
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2013 17:45:57 -0000

Yaron Sheffer writes:
> 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.

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.