Re: [IPsec] Privacy attack vectors against IKEv2 and Postquantum

Paul Wouters <paul@nohats.ca> Sat, 12 August 2017 01:23 UTC

Return-Path: <paul@nohats.ca>
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 99729132344 for <ipsec@ietfa.amsl.com>; Fri, 11 Aug 2017 18:23:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoT1sdiKpMdm for <ipsec@ietfa.amsl.com>; Fri, 11 Aug 2017 18:23:34 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F428132051 for <ipsec@ietf.org>; Fri, 11 Aug 2017 18:23:28 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3xTkf45dw7zDL; Sat, 12 Aug 2017 03:23:24 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1502501004; bh=PNjxALQ0/Y2XmxNhPntzpGtrmkLR7e6C5uaM0nmrMCk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=S808EFWK2dZuJSc0X7yr02trpXE7PsCijHC2HDJk16K1DoWYiw3HtB3G9TBClQLcW yixjltjb8HDdq+RVh8SzzuF4NZEmNmoub67d+Pwf16lYnDGxvTpsDenUxZ4K8qG3Yw gB1sd6CIYQDCbhKhjekuKdQcvsE7DOD0fqd5aksk=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id CzPlpNVyPrXK; Sat, 12 Aug 2017 03:23:21 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 12 Aug 2017 03:23:21 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id E75592E75B6; Fri, 11 Aug 2017 21:23:19 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E75592E75B6
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CDAE74095D6C; Fri, 11 Aug 2017 21:23:19 -0400 (EDT)
Date: Fri, 11 Aug 2017 21:23:19 -0400
From: Paul Wouters <paul@nohats.ca>
To: David Schinazi <dschinazi@apple.com>
cc: IPsecME WG <ipsec@ietf.org>
In-Reply-To: <776D38D0-7EEC-46DA-873D-CA1B9394E515@apple.com>
Message-ID: <alpine.LRH.2.21.1708112112220.21721@bofh.nohats.ca>
References: <776D38D0-7EEC-46DA-873D-CA1B9394E515@apple.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/4MTNrG-P2cqafslXiMykF6U7KkM>
Subject: Re: [IPsec] Privacy attack vectors against IKEv2 and Postquantum
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 12 Aug 2017 01:23:37 -0000

On Fri, 11 Aug 2017, David Schinazi wrote:

> 1) Active man-in-the-middle attack against the initiator
> An attacker that can intercept and spoof packets can complete the SA_INIT part of the exchange with both sides and get the initiator to disclose its IDi (and PPK_id). This allows an attacker to fingerprint devices and/or users.

One of the two will have to show ID before the other can make a decision
(before revealing itself) if it sees an attacker or a valid endpoint.
There have been suggestions in the past (eg BTNS with channel binding)
but no one thought it was worth the extra round trips. In theory you
could still do this using NULL-AUTH on the client, which authenticates
the server without losing any privacy and then running a second
authentication to 'upgrade' the client.

> 2) Passive off-path attack against a "hidden" responder
> Today an IKEv2 server cannot hide the fact that it exists - the initiator's SA_INIT is not authenticated so the responder must respond to it even if it is forged, leaking the fact that it is running an IKEv2 server. Hypothetically speaking, if one were to run IKEv2 over TLS and sharing port 443 with a web server to obfuscate the fact that it is using IKEv2, an attacker could open a TLS connection and sending an SA_INIT to divulge the fact that this HTTPS server also supports IKEv2.

Maybe we should run DH on all webserver's for IKE :)

> Straw man Proposal:

[...]

> I believe this proposal does not reduce the security properties of the current draft, it also does not leak any information to any party that does not possess PPK, and it mitigates the attack vectors discussed above.
>
> What are your thoughts?

I think the tor people will tell you that you would still be able to
fingerprint this enough to tell it is IKE over TLS.

I'd also prefer a mechanism not tied to PPKs. Those are supposed to be
a bandaid that wouldn't be used anymore in the future where we have
quantum safe algorithms.

Paul