Re: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01

Tero Kivinen <kivinen@iki.fi> Thu, 04 April 2013 10:30 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F5221F9408 for <ipsec@ietfa.amsl.com>; Thu, 4 Apr 2013 03:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTkRo3Aj9OAz for <ipsec@ietfa.amsl.com>; Thu, 4 Apr 2013 03:30:37 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA9B21F9401 for <ipsec@ietf.org>; Thu, 4 Apr 2013 03:30:36 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r34AUTVE008594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Apr 2013 13:30:29 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r34AUSIE020120; Thu, 4 Apr 2013 13:30:29 +0300 (EEST)
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: <20829.22084.868314.364667@fireball.kivinen.iki.fi>
Date: Thu, 4 Apr 2013 13:30:28 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
In-Reply-To: <A113ACFD9DF8B04F96395BDEACB3404209051DF4@xmb-rcd-x04.cisco.com>
References: <20826.55248.860637.210630@fireball.kivinen.iki.fi> <A113ACFD9DF8B04F96395BDEACB3404209051DF4@xmb-rcd-x04.cisco.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 9 min
X-Total-Time: 10 min
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01
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: Thu, 04 Apr 2013 10:30:38 -0000

Scott Fluhrer (sfluhrer) writes:
> How is that behavior fundamentally different from the behavior we
> would get if the attacker inserted a valid, but different KEr*
> payload?  In that case, the tests will pass, and we'll perform the
> DH, and come up with incorrect SKEYSEED. 

Not that much difference, but for those RFC5996 already has text
saying you can process multiple KEr's if you want to:

----------------------------------------------------------------------
2.4.  State Synchronization and Connection Timeouts
...
   There is a DoS attack on the initiator of an IKE SA that can be
   avoided if the initiator takes the proper care.  Since the first two
   messages of an SA setup are not cryptographically protected, an
   attacker could respond to the initiator's message before the genuine
   responder and poison the connection setup attempt.  To prevent this,
   the initiator MAY be willing to accept multiple responses to its
   first message, treat each as potentially legitimate, respond to it,
   and then discard all the invalid half-open connections when it
   receives a valid cryptographically protected response to any one of
   its requests.  Once a cryptographically valid response is received,
   all subsequent responses should be ignored whether or not they are
   cryptographically valid.
----------------------------------------------------------------------

I.e. implementation is allowed to fork the IKE SA creation at that
point and process all of the branches and see which one of them leads
to the valid authenticated IKE SA. I do not think any of the
implementations actually do that, but it is allowed.

The current text in the dh-checks would overwrite that and as it says
the whole IKE SA MUST be dropped, (not only the offending message),
that would open new DoS and prevent using the solution offered for it
in the RFC5996.


> If the real responder will then send the correct "HDR, SAr1, KEr,
> Nr, [CERTREQ]", well, the initiator has already received its
> response and generated some SKEYSEEDs.  I wasn't aware that it was a
> requirement that the initiator create multiple SKEYSEEDs if it
> happens to receive multiple initial exchange 2 messages.

As you can read from above, there is no REQUIREMENT to do that, but it
is allowed. The text in the dh-checks would forbid that...

> For an attacker's point of view, the behavior he gets by sending
> valid KEr* payloads is even more advantageous; he has not only
> prevented the SA from being created, he also forced the initiator to
> do more work before doing so.

Yep. 

> > Also these tests might also fail during the CREATE_CHILD_SA exchange.
> 
> There isn't a real requirement to discard the parent IKE SA; of
> course, we can't allow the creation of the child SA. 

The problem is that if this is noticed in the Initiator then the
Responder has already created Child SA, but Initiator cannot create
it. Thus Child SA state is out of sync, and the general solution for
that in the IKEv2 is to restart the IKE SA, i.e. delete IKE SA and
start over.

As here the other end cannot be unauthenticated, this is most likely
caused by a bug in the implementation and restarting might or might
not help, but at least that does not cause black hole problems. 

> While I don't think the below text is wrong (except I would point
> out that there is no security requirement to discard the parent IKE
> SA during a test failure while generating a child SA), I would also
> point out that these don't appear to have any advantage over the
> current text. 

There is no security requirement to discard IKE SA, but there
operatinal reasons to do it. I.e. that would be clear indication that
something is wrong, thus most likely will cause one of the peers to
start investingating the problem, especially if it is persistent
problem. On the other hand if the problem is not persistent, and is
fixed by starting IKE SA over, then even better...
-- 
kivinen@iki.fi