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

Tero Kivinen <kivinen@iki.fi> Fri, 16 February 2018 20:15 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 1831A12D7F1 for <ipsec@ietfa.amsl.com>; Fri, 16 Feb 2018 12:15:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
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 MCaSsDgBl6lv for <ipsec@ietfa.amsl.com>; Fri, 16 Feb 2018 12:15:34 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 E11DA129C53 for <ipsec@ietf.org>; Fri, 16 Feb 2018 12:15:33 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1GKFPnZ027961 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Feb 2018 22:15:25 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1GKFOj7021479; Fri, 16 Feb 2018 22:15:24 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <23175.15324.37793.880546@fireball.acr.fi>
Date: Fri, 16 Feb 2018 22:15:24 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: ipsec@ietf.org
In-Reply-To: <2D1FF22A-FD65-4365-BD17-2E434013A339@gmail.com>
References: <23175.8000.242283.548415@fireball.acr.fi> <97670585-978A-4E58-AC8A-833EB8790754@gmail.com> <23175.11397.220795.627967@fireball.acr.fi> <2D1FF22A-FD65-4365-BD17-2E434013A339@gmail.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 5 min
X-Total-Time: 5 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Xt0X6i4G3fi_EBZM4-pF2AEqzvg>
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 20:15:36 -0000

Yoav Nir writes:
> > 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.

IKE is not unidirectional, it is not only client and server, it is
host to host. I.e., the remote access initiator should also respond to
the incoming connections as it might be the restarted remote peer
reconnecting etc.

There might actually be real IP connection between (i.e., no NAT)
which allows remote peer to connect to you too :-)

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

For server yes, but my web browser does not listen port 80 or 443, and
will not respond to them. My ipsec client will listen port 500 and
4500 and will respond to them. It might not allow incoming
IKE_SA_INITs to them, or might not even implement them, but originally
IPsec was seen more host to host than client to server...
-- 
kivinen@iki.fi