Geolocation Privacy

1
Geolocation Privacy

• Hannes Tschofenig

International Working Group on Data Protection
in Telecommunications Rome, 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.co
  m/tools/docstats.html

General Area
Internet Area
RAI Area
O M Area
Applications Area
Routing Area
RAI
Transport Area

SIP
SIPPING
AVT
GEOPRIV
SIMPLE
MMUSIC
Security 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 informationhttp//www.ietf.org/html.charter
  s/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

7
Presence in the IETF

• Instant Messaging and Presence Protocol (IMPP)
  Working Group founded in 1999
• Originally, hoped to arrive at a single, standard
  instant messaging and presence protocol
• Instead, became a massive religious war
• Surviving proposals today are SIMPLE and XMPP
• Eventually, created a toolset for
  interoperability of instant messaging and
  presence protocols
• Assumes an pluralistic environment
• Among those tools, defined the pres URI scheme
  and an XML-based format for presence
• Presence Information Data Format (PIDF)

8
Basic Presence Model
Notification
(3) SUBSCRIBE
(4) PUBLISH
Publication
Presence Server
(5) NOTIFY
Watcher
Presentity
(2) XCAP
Policy
Simplified SIP exchanges
Rule Maker
9
Geolocation and Presence

• Presence
• Ditto
• Ditto
• Ditto
• Ditto
• Ditto
• Ditto

• 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

10
Basic GEOPRIV Architecture
Publication
Notification
Location Server
Location Recipient
Location Generator
Policy Rules
Rule Maker
Shows only the network agents, not the human
actors
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
  SIPhttp//tools.ietf.org/html/draft-ietf-sip-loc
  ation-conveyance-10

A tiny tutorial can be found at
http//www.shingou.info/twiki/pub/EmergencyServic
es/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 ltfeature.xsdgt schema (mandatory-to-impleme
  nt)
• Clarified by draft-ietf-geopriv-pdif-lo-profile
• Supports civic location format (optional-to-implem
  ent)
• 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

20
Whats in an Location Object (LO)?

• LO encodes bindings between data elements
• Sighting bindings (ID, Location, Time)An
  entity with this identifier was at this location
  at this time
• Rule bindings (Tuple, Rule)These are the rules
  for how this sighting should be handled

21
Sighting Binding

• lt?xml version"1.0" encoding"UTF-8"?gt
• ltpresence xmlns"urnietfparamsxmlnspidf"
• xmlnsgp"urnietfparamsxmlnspidfgeopriv
  10"
• xmlnsgml"urnopengisspecificationgmlsche
  ma-xsdfeaturev3.0"
• entity"presmeaningless-F32AC8D_at_example.com"
  gt
• lttuple id"sg89ae"gt
• ltstatusgt
• ltgpgeoprivgt
• ltgplocation-infogt
• ltgmllocationgt
• ltgmlPoint gmlid"point1"
  srsName"epsg4326"gt
• ltgmlcoordinatesgt374630N
  1222510Wlt/gmlcoordinatesgt
• lt/gmlPointgt
• lt/gmllocationgt
• lt/gplocation-infogt
• ltgpusage-rulesgt
• ltgpretransmission-allowedgtnolt/gpretrans
  mission-allowedgt
• ltgpretention-expirygt2003-06-23T045729Z
  lt/gpretention-expirygt
• lt/gpusage-rulesgt

22
Rule Binding

• lt?xml version"1.0" encoding"UTF-8"?gt
• ltpresence xmlns"urnietfparamsxmlnspidf"
• xmlnsgp"urnietfparamsxmlnspidfgeopriv
  10"
• xmlnsgml"urnopengisspecificationgmlsche
  ma-xsdfeaturev3.0"
• entity"presmeaningless-F32AC8D_at_example.com"
  gt
• lttuple id"sg89ae"gt
• ltstatusgt
• ltgpgeoprivgt
• ltgplocation-infogt
• ltgmllocationgt
• ltgmlPoint gmlid"point1"
  srsName"epsg4326"gt
• ltgmlcoordinatesgt374630N
  1222510Wlt/gmlcoordinatesgt
• lt/gmlPointgt
• lt/gmllocationgt
• lt/gplocation-infogt
• ltgpusage-rulesgt
• ltgpretransmission-allowedgtnolt/gpretrans
  mission-allowedgt
• ltgpretention-expirygt2003-06-23T045729Z
  lt/gpretention-expirygt
• lt/gpusage-rulesgt

23
Integrity and authenticity

• High-level Threat Corruption / falsification of
  bindings
• Sighting bindings
• Location and time Replay
• Location and identity Spoofing / swapping
• Levels of identity Swapping between layers
• Rule bindings Removal of rules

24
Confidentiality

• Unauthorized disclosure of a location object or
  parts of a location object
• Rules can express policy, but not enforce
• Eavesdropping
• Whole LO or parts of it
• Anonymity is selective availability
• Location, time authorized, but not identity
• Identity, time, but only rough location

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
Authorization Framework
Basic Ruleset
Extended Ruleset
Common Policy
PIDF-LO
Geopriv Policy
Presence Policy
RFC 4745 Common Policy
RFC 5020 -- Presence Authorization Policy
draft-ietf-geopriv-policy-14.txt Geolocation
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

28
Extended Ruleset Common Policy

• Rule consists of
• conditions part
• actions parts
• transformations part
• Conditions
• Identity Conditions
• Matching One Entity
• Matching Multiple Entities
• Matching Any Authenticated Identity
• Matching Any Authenticated Identity Excepting
  Enumerated Domains/Identities
• Sphere
• Validity
• No actions no transformations specified

29
Common PolicyExample

• lt?xml version"1.0" encoding"UTF-8"?gt
• ltruleset xmlns"urnietfparamsxmlnscommon-p
  olicy"gt
• ltrule id"f3g44r1"gt
• ltconditionsgt
• ltidentitygt
• ltone id"sipalice_at_example.com"
  /gt
• ltone id"tel[phone]"
  /gt
• ltone id"mailtobob_at_example.net
  " /gt
• ltmany domain"example.com"/gt
• lt/identitygt
• ltsphere value"work"/gt
• ltvaliditygt
• ltfromgt2003-12-24T1700000100
  lt/fromgt
• ltuntilgt2003-12-24T190000010
  0lt/untilgt
• lt/validitygt
• lt/conditionsgt
• ltactions/gt
• lttransformations/gt
• lt/rulegt

30
Identity Handling

• Identity information depends on the selected
  conveyance protocol.
• Specification needs to indicate how the identity
  fields of Common Policy are populated.
• Functionality about identity management and
  privacy inherited from conveyance protocol (e.g.,
  SIP)
• Examples in the SIP context
• P-Asserted ID (RFC 3325)
• SIP Identity (RFC 4474) / Authenticated Identity
  Body (RFC 3893)
• SIP SAML (draft-ietf-sip-saml-03.txt)
• SIP CERTS (draft-ietf-sip-certs-05.txt)
• Privacy in SIP RFC 3323

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

32
PolicyExample (1/2)
ltrule id"BB56A19"gt ltconditionsgt
ltgplocation-conditiongt ltgplocation
profile"geodetic-condition"gt
ltgsCircle
srsName"urnogcdefcrsEPSG4326"gt
ltgmlposgt
-34.410649 150.87651
lt/gmlposgt ltgsradius
uom"urnogcdefuomEPSG9001"gt
1500
lt/gsradiusgt lt/gsCirclegt
lt/gplocationgt lt/gplocation-conditio
ngt lt/conditionsgt lttransformations/gt lt/rule
gt

• ltcprule id"AA56i09"gt
• ltcpconditionsgt
• ltgpcivic-loc-conditiongt
• ltcountrygtDElt/countrygt
• ltA1gtBavarialt/A1gt
• ltA3gtMunichlt/A3gt
• ltA4gtPerlachlt/A4gt
• ltA6gtOtto-Hahn-Ringlt/A6gt
• ltHNOgt6lt/HNOgt
• lt/gpcivic-loc-conditiongt
• lt/cpconditionsgt

33
PolicyExample (/2)

• ltrule id"AA56i09"gt
• ltconditions/gt
• ltactions/gt
• lttransformationsgt
• ltgpset-retransmission-allowedgt
• false
• lt/gpset-retransmission-allowedgt
• ltgpset-retention-expirygt
• 86400
• lt/gpset-retention-expirygt
• ltgpset-note-well xmllang"en"gt
• My privacy policy goes in here.
• lt/gpset-note-wellgt
• ltgpkeep-rule-referencegt
• false
• lt/gpkeep-rule-referencegt
• ltgpprovide-location
• profile"civic-transformation"gt

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., appointmentgt,
  ltbreakfastgt, ltdinnergt, ltholidaygt, ltlunchgt,
  ltmealgt, ltmeetinggt, ltperformancegt, lttravelgt, or
  ltvacationgt)
• 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

35
Presence PolicyExample

• lt?xml version"1.0" encoding"UTF-8"?gt
• ltcrruleset xmlns"urnietfparamsxmlnspres-
  rules"
• xmlnspr"urnietfparmasxmlnspres-rules"
• xmlnscr"urnietfparamsxmlnscommon-policy
  "gt
• ltcrrule id"a"gt
• ltcrconditionsgt
• ltcridentitygt
• ltcrone id"sipuser_at_example.com"/gt
• lt/cridentitygt
• lt/crconditionsgt
• ltcractionsgt
• ltprsub-handlinggtallowlt/prsub-handlinggt
• lt/cractionsgt
• ltcrtransformationsgt
• ltprprovide-servicesgt
• ltprservice-uri-schemegtsiplt/prservice-uri
  -schemegt
• ltprservice-uri-schemegtmailtolt/prservice-
  uri-schemegt
• lt/prprovide-servicesgt
• ltprprovide-personsgt

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.

Dissemination Channel
Request
LS
LR
LO
Rules
RH
37
The E2E Story Connecting Triangles
LG
Viewer
LR
LH
LR
LH
LR
LH
LR
LH
LS
LR
LS
LR
LS
LR
LS
LR
RH
RH
RH
RH

• Triangles can be combined to store and forward
  LOs
• Logically forms a distribution tree
• Branches when one LS provides same LO to multiple
  LRs
• RootLG, the entity that first determines the
  location of the target
• LeavesLRs, 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

38
The E2E Story Assurances about the tree
LG
Viewer
LR
LH
LR
LH
LR
LH
LR
LH
LS
LR
LS
LR
LS
LR
LS
LR
RH
RH
RH
RH

• 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

39
Example Scenario (1)

• Endpoint discovers LIS
• Endpoint acquires LO reference (referred as
  ID(LO))
• LIS Discovery Dissemination Channel
• LIS instance of LG
• Endpoint LR

LIS Discovery
(1)
ID(LIS)
LIS
(2)
End Point
ID(LO)
ID(LIS), ID(LO)
Rules
LR
40
Example Scenario (2)

• Endpoint sends reference to LR
• Endpoint sends rules to LIS
• LR dereferences reference
• Endpoint RM
• LIS LS
• LR LR

LIS Discovery
(1)
ID(LIS)
(2)
LIS
End Point
ID(LO)
(4)
(3)
ID(LIS), ID(LO)
Rules
(5)
LR
LO
41
Relevant IETF Work

• Creating, Modifying and Deleting XML Documents
• XCAP / WebDavhttp//www.jdrosen.net/papers/xcap-t
  utorial.ppt
• Presence Server Performance
• Partial Notifications / Event Throttling / Event
  Filters
• Session (dependent/independent) policies
• Mechanisms to obtain location information
• Discovering features of a Presence/Location
  Server
• Refinement and extensions of location formats

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)

Please give me access to your information. Here
is my privacy policy!
Presence Server
OK. Based on your privacy policy you get access
to X.
Watcher
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 todays 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