Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns

Yoav Nir <ynir.ietf@gmail.com> Fri, 16 February 2018 19:36 UTC

Return-Path: <ynir.ietf@gmail.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 04EDE1200C1 for <ipsec@ietfa.amsl.com>; Fri, 16 Feb 2018 11:36:29 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 QDffHnEjuatR for <ipsec@ietfa.amsl.com>; Fri, 16 Feb 2018 11:36:26 -0800 (PST)
Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9BC12D7EF for <ipsec@ietf.org>; Fri, 16 Feb 2018 11:36:26 -0800 (PST)
Received: by mail-wr0-x22d.google.com with SMTP id b52so3944126wrd.10 for <ipsec@ietf.org>; Fri, 16 Feb 2018 11:36:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WMbHrLEblhpskzvxMEd+J88+WVgJ8IK71AefIE+1EnY=; b=tJIFZvdjwxGfEi12rdFU+oiw/dz5sU7bA6/3ypuBATLpLfRR7UPjYE+i5wlrtfhxuD vzu3iktdxc72xfPyIa0Ed/AKax1CXMlpQqBq4uwKJcg68igFelRa4aS1l5cobk7FGdkb /DkHYnjeYRtgBNyp20WGwOdCQSQMDtgzt2aWg4ldEZcXhWaFIyznmi9uu2oKYFjFp3Xp LW0RWKYujEcvG1kV599AhwHYJqO2dzoY9SZ+zE+5Cn9BI9bI7RtTbC9e8phjy9UxsoBu 2LRPrBbEEnrkr6Pyv41rlOVNkbQ0cuR6WbMK4WIpoqwKte0t1DCvWSyMenIDOP5Bv4PP 9Wlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WMbHrLEblhpskzvxMEd+J88+WVgJ8IK71AefIE+1EnY=; b=StO0UWlvWAMDfl8nr4PE/SvDuTngriJ7E1nGU36dytNezKckPtVAe4RSJxK8amvbMS NkAMEDKEVeR2lHr5D5i19zqxlXb5B6W6Uq2rr7yu5m07eWxnEVKNC42kIOAV7AsgfsV/ QqHZDIjBop8BpLPNKK0RufvcTKKyFzzQdw2brizJZYSd8LgvfMqSVsj0q7IitBQ3DFpX QEXhjkFRMM7yV1viMh85x8+MryNWqZCpJIw+DP6Tl9p5PpsLp3zVH0WzvZeLHhN5gOTn meXUhm/AMvyVhqNrRSaUPu+wVFhQov7nTDAds+KJ2/QMsE+hh9lgiIYbjWoxX6eOkFOM nkhg==
X-Gm-Message-State: APf1xPDenTzbUttGbaZ2LedhqCPpBq1iTIh9n1uDHlyodxnbSvOSN9zL 2T3zVBsz18i7bJvVcu7z3ndG/HNX
X-Google-Smtp-Source: AH8x225Cy8ELurgfhl18cAh0SFWiiq9wc57iPuui6rw7WQZxNB/HtQrwui4qzoqEc52RRYlmrCcSCw==
X-Received: by 10.223.148.37 with SMTP id 34mr7011036wrq.243.1518809785034; Fri, 16 Feb 2018 11:36:25 -0800 (PST)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 19sm30565972wrv.0.2018.02.16.11.36.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Feb 2018 11:36:24 -0800 (PST)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <2D1FF22A-FD65-4365-BD17-2E434013A339@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_D675D3FB-C68F-4322-A388-B145372859D3"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Fri, 16 Feb 2018 21:36:22 +0200
In-Reply-To: <23175.11397.220795.627967@fireball.acr.fi>
Cc: ipsec@ietf.org
To: Tero Kivinen <kivinen@iki.fi>
References: <23175.8000.242283.548415@fireball.acr.fi> <97670585-978A-4E58-AC8A-833EB8790754@gmail.com> <23175.11397.220795.627967@fireball.acr.fi>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/mYwVSAvFVyEW68anGq7mfzKNjIQ>
Subject: Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns
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: Fri, 16 Feb 2018 19:36:29 -0000


> On 16 Feb 2018, at 21:09, Tero Kivinen <kivinen@iki.fi> wrote:
> 
> Yoav Nir writes:
>>> 2) The privacy of the initiator's identity in the presence of a man in
>>>  the middle attacker is not protected.
>>> 
>>>   Today an attacker with full control of the network can receive the
>>>   IDi/IDr sent by the initiator in the first AUTH packet. We should
>>>   add a mechanism to IKEv2 that allows the initiator to only send
>>>   IDi/IDr to known entities (e.g. that possess a shared secret).
>> 
>> This is more feasible. I understand the issue, but the only use case
>> where I think it’s important is remote access. It would make sense
>> in remote access to reverse the order of authentication so that the
>> responder identifies and authenticates first, but you’d still need
>> the initiator to send the IDr first.
> 
> The reason why we defined IKEv2 so that initiator provides identity
> first, was that if responder provides identity first, then attackers
> can make probe attacks and collect identities of the remote peers,
> even when the IPsec is not currently in use. I.e., like we might run
> nmap to find out the open ports, this would also provide authenticated
> (if using certificateS) identity of the peer…

I realize this, but one side has to identify itself first, and with remote access I think it’s more important to protect the initiator identity than to protect that fact that some organization has an IPsec remote access concentrator.

In fact we can run nmap and find which ports are open, and we can and do scan for HTTP(S) servers on ports 80 and 443, and we do get their certificates.