Geolocation Privacy

Hannes Tschofenig

International Working Group on Data Protection in TelecommunicationsRome, March 2008

2

Acknowledgements• Thanks to Henning Schulzrinne, Jon Peterson,

and Richard Barnes for their help with this slide set.

3

The IETF• 110+ working groups in 8 areas; security & privacy relevant topics in all

these groups• Statistics about ongoing work: http://www.arkko.com/tools/docstats.html

Applications

Area

General

AreaRAI

Area

Internet

Area

Routing

Area

Security

Area

Transport

Area

SIP SIPPING AVT GEOPRIV

RAI

SIMPLEMMUSIC

…

O & M

Area

4

The GEOPRIV Working Group• First BoF on Spatial Location held at 48th IETF (July 2000)

– IETF community had concerns that privacy was not sufficiently addressed

• GEOPRIV WG formed, met for the first time at 50th IETF (August 2001)– Strong user privacy mandate in WG charter– Location determination methods are out of scope– Scope is on protecting the transmission of location information over the

public Internet

• 2008: A number of RFCs associated already available.• Participation from vendors, operators, standards professionals, policy

experts, and academia• Challenging group with interesting individuals that produces a lot of

mails.• More information:

http://www.ietf.org/html.charters/geopriv-charter.html

5

Privacy Concerns• Location

– Many entities know your location today– In many cases, YOU do not control the systems that

determines and stores your location– Example: NetGeo database (see RFC 1876)

• In many cases, location is only one data element in the larger presence context. Distribution of these other attributes also deserves privacy protection.

• To understand the work in GEOPRIV the presence work has to be considered.

6

Overview of Presence• Presence emerged as a component of instant messaging

applications• Foremost, provides binary availability data

– Online or offline?

• Closely tied to the concept of a friends list– Based on subscription, a persistent relationship

• Modern presence systems also provide a disposition towards communication– Not just am I online, but am I busy, away, etc

• Capability information– What kinds of communication can I accommodate with my

endpoint?

• Customized responses – context dependent– Give different answers to different subscribers

8

Basic Presence Model

PresenceServer

Rule Maker

Watcher

(4) PUBLISH

(5) NOTIFY

(2) XCAP

Simplified SIPexchanges

(3) SUBSCRIBE

Publication

Notification

Policy

Presentity

9

Geolocation and Presence• Geopriv

– Real-time information, changing frequently

– Requires subscription model

– Use servers to enforce policy

– Need to be able to share information selectively

– Strong authentication & confidentiality model

– Extensibility (XML) required

• Presence– Ditto

– Ditto

– Ditto

– Ditto

– Ditto

– Ditto

10

Basic GEOPRIV Architecture

LocationServer

LocationGenerator

RuleMaker

LocationRecipient

Publication Notification

Shows only the networkagents, not the human actors

PolicyRules

11

GEOPRIV WG: Objectives

• Pick location information XML language• Identify protocols conveying location information

– Allow push model and subscription model• Select document format for location information

– Provide strong security measures to protect location information in transit

– Insert policy directives along with location information• Develop authorization policy language

for restricting the distribution of location information– Third parties enforce policies on behalf of “rule maker”– Motivated by a concern that many producers of geolocation

information will not be controlled by end users– Rule Maker may be the owner of the target device, or may not

12

GEOPRIV WG: Objectives

• Pick location information XML language

13

XML Language for Location Information

• The IETF did not want to define location information formats– Experts on these matters are largely elsewhere(Ignoring the work on DHCP geodetic location information…)

• Instead, the IETF is focusing on architectures and tools for the secure distribution of location information documents

• Defining an envelope to carry any XML-based location information format– Popular choice is Geographic Markup Language (GML) (from OCG)– http://www.opengeospatial.org/

• No suitable standardized format for civic location was available– Developed in Geopriv working group

14

GEOPRIV WG: Objectives

• Identify protocols conveying location information– Allow push model and subscription model

15

Conveyance Protocols• Once you have a geolocation document, you need

a protocol to carry it

• Traditional protocols are applicable (like HTTP, etc)– Anything that can carry MIME types works

• But a subscription model is ideal– Ability to track the location of a resource over time

– Could use a polling model, but a subscription/notification model was deemed superior

– Also, one-time fetch is desirable

• Most of the work on location conveyance using SIP:http://tools.ietf.org/html/draft-ietf-sip-location-conveyance-10

A tiny tutorial can be found at: http://www.shingou.info/twiki/pub/EmergencyServices/EswAgenda2007/IETF-Emergency-Services-Tutorial.ppt

16

Example: Vehicle Tracking

http://transport.wspgroup.fi/hklkartta/

17

GEOPRIV WG: Objectives

• Select document format for location information– Provide strong security measures to protect location

information in transit– Insert policy directives along with location information

18

PIDF-LO: RFC 4119• Presence Information Data Format (PIDF) is an

XML-based format for presence (RFC 3863)

• Extends PIDF to accommodate two new elements:– Location-Info

• Encapsulates location information• GML 3.0 <feature.xsd> schema (mandatory-to-implement)

– Clarified by draft-ietf-geopriv-pdif-lo-profile• Supports civic location format (optional-to-implement)

– Clarified by RFC 5139

– Usage-rules• Used to indicate privacy preferences

19

PIDF-LO: RFC 4119Basic Ruleset = Usage Restriction

• MUST always be attached to a PIDF-LO document

• Retention expires (how long are you allowed to keep the object)

• Policy for retransmission of location information (Yes/No)

• Reference to an external ruleset (optional) • A “note well” of free text, human readable privacy

policy

• Specified in RFC 4119

25

GEOPRIV WG: Objectives

• Develop authorization policy language for restricting the distribution of location information– Third parties enforce policies on behalf of “rule

maker”– Motivated by a concern that many producers of

geolocation information will not be controlled by end users

– Rule Maker may be the owner of the target device, or may not

26

Authorization for Presence and Location Information

RFC 4745 – Common Policy

RFC 5020 -- Presence Authorization Policy

draft-ietf-geopriv-policy-14.txt – Geolocation Policy

Authorization Framework

Basic Ruleset

Extended RulesetCommo

n PolicyGeopriv

PolicyPIDF-LO Presence

Policy

27

Extended RulesetCommon Policy

• Design Goals:– Permit only– Additive permissions (“Minimal Disclosure”)– Upgradeable/Extensibility– Capability/Versioning support– No false assurance– Efficient implementation (no regular expressions)– Protocol-independent

• Supports pluralism of contexts• Two Usage Models:

– Attached (per-value or per-reference) to PIDF-LO document– Available at the Location/Presence Server

• Identity information needs to be instantiated based on the specific conveyance protocol

31

Geopriv Policy

• Adds location-based authorization policies to the Common Policy framework

• Conditions:– IF **I am in the following area** THEN

• Transformations:– SET usage policies– REDUCE granularity of provided location information

34

Presence Policy• Attributes mostly taken from Rich Presence Extensions to the Presence

Information Data Format (RPID)• Conditions

– Details identity usage for SIP• Actions

– Subscription Handling (block, confirm, allow, polite block)• Transformations

– Providing Access to Data Component Elements (device, person, service)– Providing Access to Presence Attributes

• Provide Activities (e.g., appointment>, <breakfast>, <dinner>, <holiday>, <lunch>, <meal>, <meeting>, <performance>, <travel>, or <vacation>)

• Provide Class • Provide DeviceID • Provide Mood (e.g., happy, angry, etc.)• Provide Place-is (e.g., noisy, quiet)• Provide Place-type (e.g., bus, ship, ..... RFC 4589)• Provide Privacy (e.g., audio, text, video)• Provide Relationship (e.g., family, friend)• Provide Sphere • Provide Status-Icon • Provide Time-Offset • Provide User-Input (e.g., idle)• Provide Note • Provide Unknown Attribute • Provide All Attributes

36

The E2E StoryRecall the Basic Triangle

• Principals– Location Server LS– Location Recipient LR– Rule Holder RH

• Location Generator (LG) is a special role of a LS. Entity that initially injects LO into the system.

• Viewer is the final consumer of location information.

LS LR

RH

LO

Dissemination Channel

Rules

[Request]

37

The E2E Story Connecting Triangles

• Triangles can be combined to store and forward LOs• Logically forms a distribution tree

– Branches when one LS provides same LO to multiple LRs– Root=LG, the entity that first determines the location of the target– Leaves=LRs, entities that consume location objects

• Potentially many rule holders along this path– Target will usually be one of the rule holders– LG will usually be one of the rule holders

LRLH

RH

LRLH

RH

LRLH

RH

`LRLH

RH

LG ViewerLS LR LS LR LS LR LS LR

38

The E2E Story Assurances about the tree

• Critical parts of LO are unchanged• End-to-end privacy policy communication and

enforcement– Rules are communicated down the tree by RH adding them to LO

LRLH

RH

LRLH

RH

LRLH

RH

`LRLH

RH

LG ViewerLS LR LS LR LS LR LS LR

42

Not Accomplished in GEOPRIV

• Policy indication/negotiation in the style of P3P

• Usage restriction policy usage beyond location information.

• Make other SDOs to re-use usage restriction policies. • Extensions beyond presence

(such as generic web services)

PresenceServer

WatcherOK. Based on your privacy policy you get access to X.

Please give me access to your information. Here is my privacy policy!

43

Challenge: User Interface

• More work is necessary to develop user-friendly interfaces.

• Particularly important since authorization policies are an integral part of the solution

• A lot of today’s communication is still done without any policy handling.

• Paradigm change since we see user in the role of changing the privacy policies (“user control and consent”).

44

Outlook• Increased usage of PUB/SUB usage and richer

presence usage expected• As deployment increases the problems with data

retention and privacy will increase too • GEOPRIV architecture unique among the

standardization solutions. • More implementation work is needed to determine

better and extended policy handling

• Advertisement: Related area of interest is prevention of unwanted traffic. Identity management and authorization policies play an important role in this work as well. Will borrow a lot from the GEOPRIV concept. See http://www.shingou.info/bof-rucus.html