Re: [Iotsi] Sticky Policy: Attaching privacy policies to data

"Smith, Ned" <ned.smith@intel.com> Mon, 21 March 2016 17:52 UTC

Return-Path: <ned.smith@intel.com>
X-Original-To: iotsi@ietfa.amsl.com
Delivered-To: iotsi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B38A12D869 for <iotsi@ietfa.amsl.com>; Mon, 21 Mar 2016 10:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 5hYD6QiqXyOq for <iotsi@ietfa.amsl.com>; Mon, 21 Mar 2016 10:52:52 -0700 (PDT)
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id C553D12D9CB for <iotsi@iab.org>; Mon, 21 Mar 2016 10:52:48 -0700 (PDT)
Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 21 Mar 2016 10:52:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.24,372,1455004800"; d="scan'208";a="673312631"
Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by FMSMGA003.fm.intel.com with ESMTP; 21 Mar 2016 10:52:23 -0700
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.142]) by ORSMSX107.amr.corp.intel.com ([169.254.1.161]) with mapi id 14.03.0248.002; Mon, 21 Mar 2016 10:52:23 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "iotsi@iab.org" <iotsi@iab.org>
Thread-Topic: [Iotsi] Sticky Policy: Attaching privacy policies to data
Thread-Index: AQHRg5pswcubxTHCtkGfNI03+7PJxA==
Date: Mon, 21 Mar 2016 17:52:23 +0000
Message-ID: <D3157922.4B301%ned.smith@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-originating-ip: [10.24.1.222]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9C5CD8CCE44B8548B9211D311A15EB1B@intel.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/iotsi/8O_KHwJzpngDdT1DbAU6jWCrmcQ>
Subject: Re: [Iotsi] Sticky Policy: Attaching privacy policies to data
X-BeenThere: iotsi@iab.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Internet of Things Semantic Interoperability Workshop <iotsi.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/iotsi>, <mailto:iotsi-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotsi/>
List-Post: <mailto:iotsi@iab.org>
List-Help: <mailto:iotsi-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/iotsi>, <mailto:iotsi-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2016 17:52:56 -0000

Thanks Hannes!

RFC4119 could be characterized as an information model and data model
expression of a set of context attributes (location, presence) that when
extant represent possible privacy sensitive attributes for which some form
of privacy preservation strategy may be needed. The paper suggests a few
possible strategies such as retention limitations / data expiry and
retransmission rules.

It was noted at the F2F that 'context' was an aspect of information
modeling that represented a form of meta-data that has value (hence
shouldn't be ignored?). Given IM practice will be inclusive of context
attributes (which normally might include location, presence etc...), the
IM can inform the trust model seeking to realize privacy goals.

It could be observed that at least part of the objectives of RFC4119 could
be realized, namely that contextual metadata (location, presence) may be
available through a more comprehensive IM - one that is inclusive of
context. That suggests to me at least, that an existing IM and DM may
satisfy some of the RFC4119 objectives though possibly not being RFC4119
compliant.

It would be preferable, IMO, if the IM that describes the "system" informs
the Trust Model (security / privacy) rather than having the Trust Model
define the IM and DM that then must be retrofitted into the system IM/DM.
I'm not suggesting there won't be a need for security / privacy goals of
an IM to inform the system IM, but it should do so using the languages of
the system IM and DM.

Given a comprehensive system IM and DM, this may be sufficient toward
properly informing privacy models regarding privacy context. If there are
gaps, they likely are small. For example, the system IM/DM that defines an
identifier, might leave undefined intended mutability properties.
Normally, we'd expect the DM would specify the identifier's possible
values, but it might not specify its uniqueness properties. Uniqueness may
be understood within some context, such as a life expectancy for reuse or
a namespace authority that can manage / check for namespace collision.

A 32-bit identifier can uniquely identify 4B things at a given time. The
4B+1 item could collide with an existing identifier. If the rollover rate
is specified, then a privacy model could use that information to manage
privacy risk because there is a window in which the transaction associated
with the identifier will be extant. It may be appropriate for IOTSI to
consider defining rollover rate parameters as a possible 'range' attribute
that is associated with identifiers.

This is more the approach I would advocate vs. an RFC4119 approach.

-Ned


Ned Smith
Principal IoT Security Architect
Intel SSG-OTC
Ned.smith@intel.com
+1.503.712.3695




On 3/21/16, 1:58 AM, "Iotsi on behalf of Hannes Tschofenig"
<iotsi-bounces@iab.org on behalf of Hannes.Tschofenig@arm.com> wrote:

>Hi all,
>
>During the security discussion the idea of attaching privacy policies to
>data was mentioned and I noted that there has been work in the IETF on
>that topic.
>
>Here are the relevant pointers: RFC 4119 (see
>https://www.ietf.org/rfc/rfc4119.txt) specified a way to convey
>usage-rules along with location data. These usage-rules contain four
>pieces of information:
>- retransmission-allowed
>- retention-expires
>- ruleset-reference
>- note-well
>
>The ruleset-reference contains richer information about what a recipient
>of location information is allowed to do with that information. RFC 4745
>(see http://tools.ietf.org/html/rfc4745) defines the format of those
>policies and they have been extended for use with application specific
>domains, such as presence information and geolocation information. The
>former can be found in https://tools.ietf.org/html/rfc5025 and the latter
>in http://tools.ietf.org/html/rfc6772
>
>Ciao
>Hannes
>
>IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended
>recipient, please notify the sender immediately and do not disclose the
>contents to any other person, use it for any purpose, or store or copy
>the information in any medium. Thank you.
>
>_______________________________________________
>Iotsi mailing list
>Iotsi@iab.org
>https://www.iab.org/mailman/listinfo/iotsi