Transcript Geolocation Privacy

Geolocation Privacy
Hannes Tschofenig
International Working Group on
Data Protection in Telecommunications
Rome, March 2008
Acknowledgements
• Thanks to Henning Schulzrinne, Jon Peterson,
and Richard Barnes for their help with this slide
set.
2
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
Internet
Area
General
Area
RAI
Area
O&M
Area
Applications
Area
Routing
Area
RAI
…
MMUSIC
SIMPLE
SIP
SIPPING
AVT
Transport
Area
GEOPRIV
Security
Area
3
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
4
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.
5
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
6
Basic Presence Model
Notification
(3) SUBSCRIBE
(4) PUBLISH
Publication
Presence
Server
(5) NOTIFY
Watcher
Presentity
(2) XCAP
Policy
Simplified SIP
exchanges
Rule Maker
8
Geolocation and Presence
• Geopriv
• Presence
– Real-time information, changing
frequently
– Ditto
– Requires subscription model
– Ditto
– Use servers to enforce policy
– Ditto
– Need to be able to share
information selectively
– Ditto
– Strong authentication &
confidentiality model
– Ditto
– Extensibility (XML) required
– Ditto
9
Basic GEOPRIV Architecture
Publication
Notification
Location
Server
Location
Generator
Policy
Rules
Rule
Maker
Location
Recipient
Shows only the network
agents, not the human actors
10
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
11
GEOPRIV WG: Objectives
• Pick location information XML language
12
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
13
GEOPRIV WG: Objectives
• Identify protocols conveying location
information
– Allow push model and subscription model
14
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
15
Example: Vehicle Tracking
http://transport.wspgroup.fi/hklkartta/
16
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
17
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
18
PIDF-LO: RFC 4119
Basic 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
19
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
25
may not
Authorization for Presence and
Location Information
Authorization Framework
Basic
Ruleset
PIDF-LO
Extended Ruleset
Geopriv
Policy
Common
Policy
Presence
Policy
RFC 4745 – Common Policy
RFC 5020 -- Presence Authorization Policy
draft-ietf-geopriv-policy-14.txt – Geolocation Policy
26
Extended Ruleset
Common 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
27
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
31
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
34
The E2E Story
Recall the Basic Triangle
• Principals
Dissemination Channel
[Request]
LS
LR
LO
Rules
RH
– 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.
36
The E2E Story
Connecting Triangles
LG
LS LH
RH
LRLR
LSLH
RH
LRLR
LSLH
RH
LRLR
LSLH
`LRLR
Viewer
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
– 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
37
The E2E Story
Assurances about the tree
LG
LS LH
RH
LRLR
LSLH
RH
LRLR
LSLH
RH
LRLR
LSLH
`LRLR
Viewer
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
38
Not Accomplished in GEOPRIV
• Policy indication/negotiation in the style of P3P
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
• Usage restriction policy usage beyond location
information.
• Make other SDOs to re-use usage restriction policies.
• Extensions beyond presence
(such as generic web services)
42
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”).
43
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
44