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

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Tue, 02 April 2013 13:37 UTC

Return-Path: <sfluhrer@cisco.com>
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 0B20B21F8867 for <ipsec@ietfa.amsl.com>; Tue, 2 Apr 2013 06:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 P7CgN5n7zv4s for <ipsec@ietfa.amsl.com>; Tue, 2 Apr 2013 06:37:00 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E506E21F883E for <ipsec@ietf.org>; Tue, 2 Apr 2013 06:36:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7248; q=dns/txt; s=iport; t=1364909820; x=1366119420; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TqXz1TteJZxevPsYNGIu4qJ3uZ699exg9blwDv3aHrk=; b=jRLs8moGV8z7huwgWmwUC0IX6SXshMrxGrxWOCy+K0LPDthKrFPd1z4h 57WCJa7xHSWikN9/Os4GcbcMKmOv/oQp6QpuIxSIPUrkiRXajsRzxoJAg lHzrXmaOSV4/p4JUX83VXYAjhf843vrh/GOaGNT7mtcI2PaoGWwVYRPwA I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFACfeWlGtJXG//2dsb2JhbABDgzu/Q4EDFnSCHwEBAQMBAQEBJBM0FwQCAQgRBAEBCxQJBycLFAkIAgQBEgiIBgYMsUGQDQSOeSYSBoJZYQOndoMLgWoHNxE
X-IronPort-AV: E=Sophos;i="4.87,393,1363132800"; d="scan'208";a="194051640"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 02 Apr 2013 13:36:59 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r32Daxf0001381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Apr 2013 13:36:59 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 2 Apr 2013 08:36:58 -0500
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: Tero Kivinen <kivinen@iki.fi>, "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01
Thread-Index: AQHOL6MLS81K9s92YEqIKsk5DhTTIZjC6Ejw
Date: Tue, 2 Apr 2013 13:36:58 +0000
Message-ID: <A113ACFD9DF8B04F96395BDEACB3404209051DF4@xmb-rcd-x04.cisco.com>
References: <20826.55248.860637.210630@fireball.kivinen.iki.fi>
In-Reply-To: <20826.55248.860637.210630@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.32.244.83]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 02 Apr 2013 13:37:01 -0000

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of Tero Kivinen
> Sent: Tuesday, April 02, 2013 9:06 AM
> To: ipsec@ietf.org
> Subject: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01
> 
> The section 2.5 says:
> 
> ----------------------------------------------------------------------
> 2.5.  Protocol Behavior
> 
>    The recipient of a DH public key that fails one of the above tests
>    can assume that the sender either is truly malicious or else it has a
>    bug in its implementation.  The recipient MAY respond with an
>    unauthenticated INVALID_SYNTAX notification, and MUST immediately
>    drop the IKE SA.
> ----------------------------------------------------------------------
> 
> I think the "MUST immediately drop the IKE SA" is wrong.
> 
> I.e if initiator sends IKE_SA_INIT request out as follows:
> 
>    Initiator                         Responder
>    -------------------------------------------------------------------
>    HDR, SAi1, KEi, Ni  -->
> 
> 
> and the responder gets it and starts to generate proper respond message
> (i.e. starts to do Diffie-Hellman generate), but while it is doing it attacker M
> sends faked message back:
> 
>                                 <--  HDR, SAr1, KEr*, Nr, [CERTREQ]
> 
> where the KEr* is generated so that it will fail the tests (i.e.
> sending all 0xffff...fff as KEr, which would fail the 1 < r < p-1 check), then
> using current text the Initiator deletes the IKE SA. When the Responder is
> ready with properly generated KEr, it will send its
> reply:
> 
>                                 <--  HDR, SAr1, KEr, Nr, [CERTREQ]
> 
> but it is too late, as Initiator has already "immediately dropped the IKE SA".

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.

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.

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.

> 
> 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.

> 
> I think the more appropriate text would be to say:

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.

> 
> ----------------------------------------------------------------------
> 2.5.  Protocol Behavior
> 
>    The recipient of a DH public key that fails one of the above tests
>    can assume that the sender either is truly malicious or else it has a
>    bug in its implementation.
> 
>    If this error happens during the IKE_SA_INIT exchange, then the
>    recipient MUST drop the message containing invalid KE payload. If
>    the invalid KE payload was in the IKE_SA_INIT request, then
>    responder receiving it MAY send INVALID_SYNTAX error back, but it
>    MUST NOT start creating any new IKE SA based on such request. If
>    the invalid KE payload was in the IKE_SA_INIT reply, then Initiator
>    receiving that reply, ignores the message, and continues waiting
>    for later messages containing properly formatted KE payload.
> 
>    If the invalid KE payload happen during the CREATE_CHILD_SA
>    exchange (or any other exchange after the IKE SA connection has
>    been authenticated) and the invalid KE payload is in the request
>    message, then responder MUST reply with INVALID_SYNTAX error notify
>    and drop the IKE SA. If the invalid KE payload is in the reply
>    message, then initiator getting this reply message MUST immediately
>    delete the IKE SA by sending IKE SA delete notification (as an new
>    exchange).
> 
> ----------------------------------------------------------------------
> 
> This also requires some changes to the section 3.3, i.e. replace
> 
> ----------------------------------------------------------------------
>    The behavior recommended in Section 2.5 is in line with generic error
>    treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of [RFC5996].
>    The sender is not required to send back an error notification, and
>    the recipient cannot depend on this notification because it is
>    unauthenticated.  Thus, the notification is only useful to debug
>    implementation errors.
> ...
> ----------------------------------------------------------------------
> 
> with
> 
> ----------------------------------------------------------------------
>    The behavior recommended in Section 2.5 is in line with generic
>    error treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of
>    [RFC5996]. The sender is not required to send back an error
>    notification, and the recipient cannot depend on this notification
>    because it is unauthenticated. Thus, the notification is only
>    useful to debug implementation errors. Also the Initiator getting
>    reply message back with invalid KE payload should simply drop it as
>    it can be from attacker, and wait for the real peer to reply.
> 
>    If the error happens after the peers have been authenticated we do
>    have a trusted channel to send the errors. In that case we want to
>    tear down the IKE SA as this kind of failures indicate there is
>    something seriously wrong with the other peer, and clearing the IKE
>    SA and starting from the beginning might help. If it is the
>    responder failing these tests, it can simply return the fatal error
>    notify (INVALID_SYNTAX, see Section 2.21.3 of RFC5996) and both
>    peers will delete the IKE SA. The Initiator does not have this
>    option, as when he notices this problem the exchange is already
>    done. It needs to start new exchange to delete IKE SA. This IKE SA
>    clearing is mandatory as Initiator cannot create the Child SA based
>    on the invalid KE data, and other end already created it as it sent
>    its reply, thus Child SA state is out of sync. Most compatible way
>    to delete IKE SA is to just send IKE SA delete notification, even
>    though starting new INFORMATIONAL exchange and sending
>    INVALID_SYNTAX notify could also work.
> ...
> --
> kivinen@iki.fi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec