Re: [Ideas] Addressing the privacy issues exposed by IDEAS

Robert Moskowitz <rgm-ietf@htt-consult.com> Wed, 18 October 2017 15:10 UTC

Return-Path: <rgm-ietf@htt-consult.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1284013334E for <ideas@ietfa.amsl.com>; Wed, 18 Oct 2017 08:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 3-ysbi1L2fBm for <ideas@ietfa.amsl.com>; Wed, 18 Oct 2017 08:10:46 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 98D5A13420D for <ideas@ietf.org>; Wed, 18 Oct 2017 08:10:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D3FA3621F4; Wed, 18 Oct 2017 11:10:44 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zVLKIeHPiJFp; Wed, 18 Oct 2017 11:10:36 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 040BD621F2; Wed, 18 Oct 2017 11:10:34 -0400 (EDT)
To: AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>, "d.lake@surrey.ac.uk" <d.lake@surrey.ac.uk>, "ideas@ietf.org" <ideas@ietf.org>
References: <9155d3fe-cbe2-ae2d-9c59-f3dee85b1409@htt-consult.com> <DB3PR0602MB37564BF38A6638EE375055B4B54D0@DB3PR0602MB3756.eurprd06.prod.outlook.com> <7AE6A4247B044C4ABE0A5B6BF427F8E2323942B7@YYZEML701-CHM.china.huawei.com>
From: Robert Moskowitz <rgm-ietf@htt-consult.com>
Message-ID: <adf6aecd-4049-4ca0-8630-a6b95829f90f@htt-consult.com>
Date: Wed, 18 Oct 2017 11:10:30 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E2323942B7@YYZEML701-CHM.china.huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/tPj0hVv8zQsQUSgGJuz2mq591TM>
Subject: Re: [Ideas] Addressing the privacy issues exposed by IDEAS
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Oct 2017 15:10:49 -0000


On 10/18/2017 11:01 AM, AshwoodsmithPeter wrote:
>>> 	" ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-Peer communications without any triangular routing achievable."
>> Yes but we need to keep in mind the operation of LI and should be supportive of that.   It can be achieved without triangular routing, but we should not consider it as an after-thought.   It is a regulatory and business requirement for the operators and they will (and have) reject any technology which does not meet these needs.   That is why we are still seeing anchored GTP tunnels in Rel.15.
> LI - Lawful Intercept can be implemented with ID/Loc technologies via the mapping system. In fact traffic can be directed to any convenient DC for intercept rather than having to be on a known data path. Fixed tunnels actually give you less flexibility for intercept since you can only do it on paths that you know the traffic is traversing and for access technologies that use those tunnels.

I had another proposal for LI using IPFIX or similar to fork traffic 
from the routing note between Alice and Barb.  And as long as Alice or 
Barb stays on the cellular network, their location would be known and 
the forking would move to a new place.

And none of this addresses that perhaps the traffic is from a connected 
friend via the mobile device's hotspot functionality.

Bob

>
> An ID loc / mapping system approach means that all interception for lawful, policy, etc. reasons are handled the same way, for multiple different access technologies and work under mobility the same way regardless of access. I'd have thought the regulatory bodies would be all over a more flexible intercept technology ;(
>
>
> Cheers,
>
> Peter
>
>
> ....
>
> David
>
> -----Original Message-----
> From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Robert Moskowitz
> Sent: 18 October 2017 06:05
> To: ideas@ietf.org
> Subject: [Ideas] Addressing the privacy issues exposed by IDEAS
>
> I chose the subject line carefully as you will see by my analysis of the privacy issue(s).  I have discussed this with Padma before bringing this up to the list.
>
> Here is the privacy attack, as I see it:
>
> It is fairly well established that web sites collect a lot of personal information and information about the device(s) connected to that personal information.  IP addresses, even the actual address of NATed clients are part of the harvest.  Mal and his cousins are busy stealing this information and putting it all together in their own big data pile.
>
> Meanwhile, Eve and her cousins are busy watching the network and seeing which IP addresses are communicating with other IP addresses.  Eve and cohorts put their data together with Mal and cohorts' data and then is able to note that:  "Hey look, Alice is talking directly with Barb."
> Oh, look, they both moved to new addresses, but we can see it is still Alice and Barb.
>
> What is going on here?
>
> ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-Peer communications without any triangular routing achievable.
> As long as these P2P communications use the same IP addresses as used in web Client/Server communications, the linkage is there to the privacy leakage occuring through those websites.
>
> Three things have to happen to protect the privacy of P2P communications from the swamp of privacy leakage in C/S communications.
>
> Identities need to be masked/hidden by both the ID/Loc technologies and IDEAS.
>
> Identifiers of all ilk, both in the control channel and the data channel need to change with each move using some Perfect Forward Secrecy (PFS) technology.
>
> Multiple IP addresses MUST be used, at least separating the P2P from C/S communications.  Different addresses for different P2P connections is wise.
>
> Note that if IDEAS-ID/Loc does everything to hide and confuse Identity/Identifier, it is all for naught if multiple IP addresses are not used.  At this point I should mention that TLS 1.3 may have a similar privacy risk, but that is for a different soapbox.
>
> Action plan:
>
> The IDEAS charter should say something like:
>
> "IDEAS will act as an enabling technology for the various ID/Loc technologies currently specified within the IETF.  As such it will result in a wider deployment of, mobile, Peer to Peer communications.
> Care will be taken in the design of the IDEAS technology not to enable the privacy leakage attacks in current Client/Server (predominately
> web-based) to be linked to these P2P communications."
>
> This means that whatever technology we come up for IDEAS will mask/hide PII/Identity/Identifier.  So that Eve is in the dark and we need only defend the IDEAS data store from Mal.
>
> Each ID/Loc technolgy (and this means ME with HIP) will need revisions to both their control and data plane (this means ESP for HIP) to change how Indentity and Identifiers are handled to break privacy tracking by Eve.  This may require using IDEAS as an enabler of privacy functions (I suspect I will need it in HIP to deal with the HI in the R1 packet).
> TLS 1.3 may also need revisions with its zero RT method.
>
> The final, and potentially big one that is outside the IETF's control is that OSs and ISPs MUST enable support for multiple addresses per host and let technologies within the hosts (like ID/Loc) to get addresses to provide privacy separation.  This ALSO extends to MAC addresses!  Eve could be tapping into those IPFIX flows (now there is a BIG privacy leakage attack that no one is talking about) and getting all the MAC/IP address mappings!
>
> One caveat that makes the multiple address not so big of a challenge is that ISPs are already providing some level of multiple address support by allowing hotspot usage on the mobile devices.  The IP address seen on the network MAY be from a given device or a device using it as a gateway.  This will become increasingly more common with automotive hotspots.  But this is NOT something we should count on as a mitigation of this privacy attack.
>
> ==========
>
> Conclusion
>
> IDEAS will analyse all security and privacy risks and include mitigation approaches in its design.
>
> I will take this attack to the HIP group for revisions there.  I already have some work going (fast moblity draft for one) that I can leverage to this purpose.
>
> I will reach out to the experts of other ID/Loc technologies (including
> MobileIKE) to discuss what they can do to ensure privacy as a design goal.
>
> Finally, as some of you know, my suit has a kevlar armor layer.  So have
> at it!   :)
>
> Bob
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas