Those who participated should send any corrections to the people cc'd
in the next day or so. We'll send the participants' list out later
today - it's wandered off somewhere...
Draft Minutes from geopriv WG Interim Meeting
June 5-6, 2002
San Diego, CA
Reported by Aaron Burstein
Samuelson Law, Technology and Public Policy Clinic.
Chairs:
Allison Mankin, USC/ISI
Randall Gellens, Qualcomm
Chairs' Note:
A small number of chair-like edits were made to Aaron's
excellent and detailed notes - many thanks to Aaron for
taking such detailed minutes, much needed for a 1.5 day meeting.
Many thanks too to Qualcomm and John Noerenberg for hosting,
with excellent facilities and hospitality.
There were both in person and phone bridge attendees.
Viewgraphs were online for the phone attendees.
Allison and Randy
**********************************************************************
** **
** **
** JUNE 5, 2002 **
** **
** **
**********************************************************************
Preliminaries
-------------
There have been no changes to our charter language,
but our dates have been updated. Notice:
- Jun 02: privacy and security requirements i-d.
- Initial geopriv scenarios and application requirements.
Goal for this interim meeting: to go through privacy and security
requirements so thoroughly that we feel comfortable with finishing
the draft by Yokohama.
Agenda for June 5, 2002: to discuss issues raised with the most
recent requirements draft (draft-cuellar-geopriv-reqs-02.txt).
Slides for this are at:
http://www.east.isi.edu/~mankin/geopriv-Interim-Meeting-Issues-2002-06-05-short.ppt
Agenda for June 6, 2002: grounding discussion on protocols that
will carry the geopriv object, as well as technologies that will
use the object.
Other goals: a consensus statement on concerns about HTML and HTTP
tags in draft-daviel-html-geo-tag-05.txt.
A new document, draft-gogic-geopriv-concepts-00.txt, explores
location information concepts and privacy concerns, but was
submitted to late to be discussed in detail here. We will try
to identify how it differs from draft-cuellar.
Discussion of the Cuellar-02 Requirement Draft
----------------------------------------------
NOTE: The first day of the meeting tracked the of issues raised
in Jorge Cuellar's email of June 2, 2002 to the WG mailing list.
The discussion did depart from the exact format of this email,
in that additional issues were introduced by the chairs and others,
but these departures should be clear from the headings in this
document.
Issue 1
-------
In the early paragraphs of the draft, "user" is used in an informal
sense. "Rule maker" is what is meant.
Issue 2
-------
A small typo in paragraph 4. "LIF" should read "FLI."
Issue 3
-------
Does the Computational Location Server (CLServ) belong in the draft?
IETF (and geopriv) is not in the business of processing raw location
information, so why is this mentioned? The charter does not even
speak of computation.
It looks like the actual computation is done at a lower level,
filtered and passed on in a header, payload, etc.
CLServ may be mentioned in order to set it aside as a
black box. It belongs in picture of components, but not in
something geopriv will actually use.
Still, there are privacy concerns in the change from computation
to distribution. It may be sufficient to require that data shouldn't
be shipped in plain text. Computation server can use the protocol of
its own choice to ship data en masse, etc.
Issue 4
-------
This section is ``unnecessarily long.''
This information is relevant to the geopriv object and/or
combined protocol, but is not logically arranged in the draft.
Overall, the document needs more coherent grouping.
Material in 3.5.1 relevant to protocol and should be kept.
Section 3.4.2 (data flows, scenario 1): acts like closed system, no
interface with the internet at all. Might be useful as background,
but does not have clear application to geopriv, unless the
information is being sent upstream.
This is a scenario in which device is self-contained,
and the owner/target requests information to be sent to itself.
Relevance may depend on whether device only gets and displays
displays location (such as a handheld GPS device),
or whether part of more general purpose device capable of further
processing and transmission.
Contrast to using cell phone -- use this scenario as a foil to
illustrate differences in other uses, aspects of the protocol.
Issue 6
-------
``Initial access provider'': Is it necessarily
the same as a location sighter? E.g. 802.11b signal may be
provided by an entity distinct from the location sighter.
But then does geopriv come into play? It must, if the user
does not have a choice of initial access provider. But in
that case, LoSi = IAP. In the 802.11 case, the IAP would never
get the LI.
-> Could say that IAP is a special case of a LoSi.
Back to Issue 4: identity management.
-------------------------------------
Is it necessary to talk about identities, roles? (Section 3.5.2)
Or is this issue something for a using protocol (IM, SIP) to handle?
There may be many cases in which identities are used for many
purposes, need global ID (IM, SIP), and there are cases when
the target does not need any identifying information from the
requester.
For example, the query: ``Where is the nearest Pizza Hut?''
Requester contacts
Pizza Hut server, gives location. The transaction can be
anonymous -- the business target has no
business knowing who is requesting information.
There may be cases where businesses and people may be identified
in the same way.
3.5 is important in getting multiple identification options supported
in geopriv. That should remain even if GUID idea is dropped.
Raises issues of authentication, entity identifier, role identifier,
etc. that can be handled in standard ways.
A sub-issue: "transport protocol" terminology
--------------------------------------------
``Transport protocol'' may not be the right description for
what geopriv interfaces with; should refer to whatever is
USING geopriv, for example, the use of geopriv by another
protocol.
The name "using protocol" may be more accurate.
(End of this sub-issue).
Geopriv must not assume that the relationship
between roles and identities/entities/handles is anything
but m-to-n. Less general assumptions (n-to-1, 1-to-n, 1-to-1)
would not be realizable across geopriv uses.
Suggestion: separate roles from identities.
2 types of identities: well-known and anonymous.
Shall geopriv know of identities? E.g., ``My wife
wants to know where I am.'' Are these identities part of
geopriv or are they part of the using protocol?
Does this mean there is some sort of UID assumed in geopriv?
- Understand this to mean that geopriv is not aware of any identities
at all. These are part of the using protocol.
- May not have ability to express in using protocol.
The identity of requester is a fundamental question. But geopriv
needs to identify simplest possible way to manage identities.
There is also a problem with security associations at different layers.
E.g., in SIP, problem with end-to-end authentication -- dealing with
spam voice calls. At some layers, you know who your peers
are, at others you don't. Thus, suggest using identities
at an object level, not using protocol level.
Trouble with understanding mapping of roles and identities:
A supplement to the discussion immediately
above.
------------------------------------------------------------
---> Switch to "short" slide set. <---
(Available at
http://www.east.isi.edu/~mankin/geopriv-Interim-Meeting-2002-06-05-short.ppt)
Either leave it to using protocols to handle identities, or
require that using protocol inherit identity information from
geopriv.
1st scenario
------------
``Entities, Data Flow'': Client C seeks the location of target T.
LServ reveals this information. C NEEDS to request target T, ie.,
C must specify a target.
Next scenario:
--------------
Rule Maker makes a policy: C may access certain data type
DT, using identity A_T. E.g., ``My wife may know what part
of the city I'm in, but anyone may know what time zone I'm in.''
C requests A_T, DT(l).
If geopriv will support this for any protocol,
identifiers must be included in geopriv -- for requests, and
for Rule Maker to supply policy.
Other scenarios that have more general queries: e.g., ``Where are the
cars in our fleet?''
Old BOF: URI solved this. Ask for the URI of a device. Does
geopriv inherit this URI? Or does this create a location
query protocol?
Is this IETF "presence?" Not necessarily.
An argument for including security in the geopriv object itself:
a geopriv object may traverse many layers that can't be counted
on to respect security. An object without identity poses security
problems.
Suppose SIP uses ID; geopriv could recognize it as a SIP ID
(or a URI or a text field or whatever). This is not simply an
instance of an opaque ID, merely handled by geopriv; geopriv
may DO something to the ID.
How can we put together anonymous identifiers, identifiers, etc.
into a generalizable geopriv representation? May need to begin
with SIP, 802.11 ID, etc. and allow geopriv to anonymize it.
Even in SIP, there is no bright-line identity. Why does
proliferation of IDs in SIP present a problem in geopriv.
There is no universal way of asserting identity, but there is
a way of saying who is requesting, who is sending.
Proposed closure:
-----------------
ID must be in the object.
Reaction:
---------
1. There is a difference between REQUIRING and ALLOWING ID
to be in the object.
2. There are always 2 IDs: the requestor and the target.
3. Analogy to Pizza Hut: don't want to reveal ID when
requesting location, no need for target to know
ID of requestor. In other cases, request and response
IDs may be known.
4. Why can't I just ask my ISA to locate the nearest
Pizza Hut?
5. Very good reasons for staging security in the
object may also have application value, e.g. in
ensuring that identity specified in the request is
the identity returned in the response.
6. Don't want to require huge amount of infrastructure
to pass IDs between consenting parties.
7. Certain cases require identities.
8. C needs to know how to identify T.
9. Different protocols requesting ID strongly suggests
that there should be a generalizable ID structure in
geopriv. Geopriv should therefore avoid wholesale importation
SIP or URL-centric ID.
10. How then to encrypt, authenticate IDs?
11. So there should at least be an option to have 1 or
more IDs in geopriv.
A new case: 3GPP context.
-------------------------
Need not only C, T IDs but also
intermediary ID -- would like to ask brokers for information,
e.g., in foreign countries where you don't know how to request.
This could reduce to dealing with a broker, which makes its
own request in behalf of the requester.
New case:
---------
C creates (pub key, priv key) and passes to Rule Maker or
T. But C does not know how to address T. T replies that C
can use A_T for T's identity, and can use pub key P_C to
identify itself.
This may be useful when C has no security relationship to LS.
T can then tell LS that C can request its information.
This would allow security even if there are eavesdroppers.
Many reasons to hide identities: T doesn't want C to know,
or C, T not relating in service provider situation in which
they have security relationships with the IAP.
(pub key, priv key) not the only method. Could use Lamport's
sequence of hashes, 1-time passwords. Also, don't need certificates
(they pose their own privacy problems -- can track owner of the
certificates. Costly to make privacy-friendly PKI, certificates.
This is a cheaper way of doing the same thing.)
Would this mean eliminating certs between S and LS? No.
There may be more fixed security associations appropriate to certs.
****************************************
REQUIREMENT
****************************************
There was agreement that geopriv MUST implement, but not
always use, identities.
The geopriv Object MUST be able to carry identities, but geopriv
does not necessarily specify the namespace.
****************************************
Use of identities will be context-specific, depend on
specification of messaging syntax.
Is there a risk that this will allow some implementations to
prohibit anonymous access?
This should keep geopriv from going into blind alley that
"anonymous" = "no identity." Pseudonymity is often
useful.
The (un)linkability question: a pseudonym that can be stored
for a long period of time is different from transaction-duration
pseudonyms.
********************************************************
===> Discussion returned to the main set of slides. <===
********************************************************
Issue 5
-------
Should geopriv talk about location storage ``LStor?'' Isn't
this just a part of LS, location seeker, etc.? Or is it part
of geopriv?
From a privacy standpoint, data storage is crucial. Knowing storage
policy may affect what kind of information is revealed. This may
mean that there has to be some recognition of data retention.
This could be answered if there is an unlinkable ID. Saying
more than this may go beyond the geopriv charter.
It is not only the ID of T that must be concealed, but also
identity of C, if T's privacy is to be considered.
===> There was a strong feeling that this kind of use of aggregation is
necessary.
This need not reach HOW data is stored, or some sort of
enforcement, but just the expression that ``You may not
have my location if you will store it for more than 2 days.''
A policy should somehow cover use, disclosure, and
retention.
All based on RM? Probably.
May need to settle for good enough -- truly unlinkable
IDs may not be possible.
What is the damage of introducing this to geopriv?
### What is this??
Issue 7
-------
Figure 1 data flows -- discuss later. Delay until scenarios draft
discussion.
Issue 8
-------
Is it necessary to distinguish FLI and LI? NO -- it's all LI.
"Filtering" in this case was meant to mean translation from
coordinates to e.g., time zone.
But others thought this was a way of manipulating ACCURACY of
location.
Filtering (in the sense of accuracy manipulations)
may be addressed in Gogic draft. Can think of it as
LI lat/long with another attribute associated with it.
Is there a FLI field in the object? Which would allow someone
to hack the object, see cleartext position information?
One view -- LS should apply policy (and the requisite imprecision)
before serving it.
Could handle this in the policy -- person A may know exact
location, person B may know location +/- 1 km, etc. This is the
reference to ``data type.''
This issue is distinct from the "full integrity" issue (Issue 16,
below), which discusses the introduction of explicit
errors; obfuscation.
Is there a convenient or useful distinction to be
maintained between LI and FLI?
The distinction may be useful only to discover the intent in
degraded location information.
Should inaccuracy be introduced in the LS/proxy, or elsewhere?
This question raised 2 sub-issues:
providing (1) filtering vs. (2) providing an accuracy attribute in
object, i.e., a flag saying
"I'm not telling you the whole truth."
Creating levels of vagueness is one way of degrading information;
there are other ways of obfuscation that may be used.
Responses to these sub-issues
-----------------------------
C doesn't need to know that the information has been degraded.
It should just get an answer, preferably in lat/long.
Geopriv should not allow location seeker to know the degree of
precision specified by the Target.
It is possible to be more vague with string locations rather
than just lat/long. "North America" may be more vague than an
inaccurate lat/long.
There was basic agreement that geopriv must allow the target to
insert vagueness or inaccuracy.
Full Integrity
--------------
But a separate issue was the "full integrity" issue:
Should geopriv permit some form of "obfuscation"? There seemed to
be a consensus that it would always be possible to mislead as to
one's location; the question was whether geopriv should facilitate
this obfuscation.
This "obfuscation" could take several forms, including (1) a
deliberately false, but potentially exact, location; or
(2) a true location mixed in with
a number of false locations; or (3) (2) a position
that is so vague as to reveal no useful information.
(2) could be effected either by including multiple locations within a
single object, or by providing some attribute in the object to
link multiple objects together.
Objection: giving a false location may do damage, whereas a
vague answer may give safer information. E.g., an assassination
target is in a bus whose location is transported with the locations
of 4 other buses. Potential result: all 5 buses are blown up.
===> But are there risks that are created by multiple queries that
aren't present if object has multiple representations.
Also, multiple locations in one object may be useful: (1) for other
obfuscation/cloaking scenarios; (2) to specify location as
a trigger for certain events, e.g., ``When I'm at Company X,
do Y;'' (3) ``I'm going to be at these 5 locations and
want to know which one has the closest coffee shop.''
Clarification
-------------
Having multiple REPRESENTATIONS of a device in object is different
from multiple location representation FORMATS.
But having both creates a multiplication problem -- multiple
formats with multiple locations could create semantic problems.
Semantics could be left to the using protocol, or the application that
handles geopriv data. More complicated things (like translating
lat/long into street addresses, etc.) should be left
to applications.
===> This could create interoperability issues: if a client
has a private schema, will it need to get LI in this format?
Will geopriv mandate 3rd party conversion engine.
Is there anything we couldn't do with multiple queries
that we could do with multiple representations?
But should leave open possibility that application can
request LI in a certain representation, if it has a reason
to believe it can get a reply from the target in that format.
Could have client make a conversion to lat/long; server doesn't
need to know how to do this.
Consensus on multiple locations
-------------------------------
I.e., repeating a single schema vs. multiple schemas:
- Geopriv needs multiple representations of a single
location. Only one is mandatory,
but there must be an option to have more than one.
- Still unclear what multiple locations will mean.
- Concern: leaving semantics entirely to applications
introduces hand-waving, may put a lot of security and privacy
beyond the reach of geopriv.
Implementation issues
---------------------
Is it easier to deal with multiple objects or multiple
representations within an object, from an implementation
perspective? This provoked several responses.
1. Expression of location -- ``I'm on a golf course'' -- may not
be something that needs to be represented in multiple locations.
This deals with categories, not necessarily best
conceptualized as multiple locations.
2. Geopriv need not go into representation of boundaries.
3. There was interest in having multiple precise locations.
Must be able, semantically, to distinguish 10 locations in
one message; 10 messages each with 1 location but all related
to 1 query.
4. From an implementation point of view, it may be easier to
send 5 different requests.
5. But privacy may suffer -- sending separate objects may create
a risk that a single object may be intercepted, understood
as an exact location, and cause damage. Sending all locations
together may create "bigger picture" that there is ambiguity.
6. But that may be security by obscurity. Cannot rely on
that ambiguity to provide security; may discover the right answer
or cause damage nonetheless. It is better to handle this
problem by securing the object and the relationships
between target and clients.
7. Reputability concerns. Explicit meaning of multiple locations
may be that multiple locations --> they are dummies. But it
isn't clear that this is what people are asking for.
8. Putting multiple locations in one object allows
them to be interpreted together with less metadata.
Should geopriv therefore explicitly specify that multiple related
objects, or multiple locations within an object, signify that some of
the locations are dummies?
Response: May need to provide intent flags -- can specify that
multiple locations represent an attempt to specify the
same location but are done so by different technologies
(GPS, dead reckoning, etc.)
There are different risks -- making and linking multiple queries can
reveal a lot of information.
Consensus:
----------
If geopriv needs to express multiple locations,
it is probably simpler to do it by expressing multiple
locations in one object, rather than linking multiple
objects.
----------
Further discussion of false information and multiple locations.
---------------------------------------------------------------
Geopriv needs to ensure that false information is not
returned in any predictable fashion.
There was concern about forcing owner/rule maker to have secure external
location, rather than expressing this in the object.
Three general possibilities
for the meaning of multiple
locations:
---------------------------
(1) Multiple locations can mean only 1 thing.
(2) Geopriv specifies a complicated way to express
semantics of multiple locations.
(3) Leave to application policy.
There are 2 problems: who is making the request, or who will
use it later on.
Policies should control who can access a certain kind of information.
May allow, e.g., a certain set of people to know "I am either
at home or at work."
But this involves heavy user configuration, something
that the average
user would probably not take the time to do.
Another possible limit to LI access: time-stamping/time-limiting
objects.
Agreed:
-------
Jorge Cuellar, John Morris, and Alex Gogic would post
discussions of:
- Multiple location, single object vs. multiple
location, multiple objects;
- Expressing meaning of multiple locations.
- This is a fundamental issue; is there a reason to
require that, in the first release, there must be the
ability to link multiple locations in some way. Or
can it be deferred to a later release?
- How far could we get with geopriv if we just settle on
one location for the present time?
- The feasibility of requiring that the geopriv
object have a bit to signify that the object does not
give the "whole picture."
Issue 9
-------
Trusted vs. untrusted data flows.
Trusted means that there is a contract that governs privacy between
the two parties.
Is "trusted" different from "security? YES: trust in this sense
involves a legal relationship.
Does this affect the design of the object?
As long as security is taken care of, if there is a
contractual relationship, then there may not be a need for
special treatment within the geopriv object.
The idea behind this distinction is to "thin" the policies that
need to be written, and thus reduces the emphasis that is placed
on privacy NOTICES (see P3P discussion below).
By allowing multiple identities, etc.
there is a way of building in a sense of trust, and there need
not be a complex policy when information is exchanged between
trusted identities.
E.g., in restaurant location case, a client may need to give very
specific location information but no identifying information.
This is taken care of by multiple identities, rather than
an explicit expression of ``trust.''
Aside:
------
This raises a NEW QUESTION about the design of the protocol:
How is this information about trust being conveyed? Does
the object carry the policy?
This is an open question. There is a sense that there should
be some policy in the object, but this is not a consensus.
Concern about the footprint of attaching policy to the object --
both bandwidth and processing power may limit how fully rules
can be expressed.
E.g., cell phone in a different carrier's area. How much information
should carrier be able to get from device, and how much will
be referred to policy held by the home provider?
(End of aside)
Issue 10
--------
Scenario 2 billing data -- is this location data in the geopriv
sense? Or is it application layer information?
Distinction between "accounting" and "billing" -- "accounting"
is what was meant here.
Issue 11
--------
This presents a basic scope question: is geopriv dealing with
a protocol, or objects and policy surrounding the objects.
Seems to be consensus that we are specifying not only objects
but also how they are to be used.
Suggestion: Look at CMS (RFC 2630) to see how to blend object and protocol
language into a document that everyone can accept.
Does the LO include "commands" or "requests"? YES.
Embedded protocol/combined protocol -- security has to be
standalone, but use is something that can be specified as a
feature of the combined protocol.
Issue 12
--------
MUST implement vs. MUST use.
Policies must be able to say that, e.g., identification
MUST BE USED. IETF Security Area will require certain minimum
algorithms for cryptographic authentication, etc.
Issue 13
--------
Contents of LO: these are things the LO MUST implement/MUST
support.
Location Data: YES
Location Data Type: YES
Target identity: YES
Version number: YES
Policies: **** Use, disclose, retain ****
policies should travel with the object.
Policy Format: ?
Negotiation parameters: e.g., specifying
format (postal address, etc.)
for returned LI.
- Cryptographic suites, etc.
Issue 14
--------
The protocol MUST define one LO (syntax and semantics) that
must be understood by all geopriv implementations; the LO
cannot be opaque.
Issue 15
--------
The multiple locations issue was discussed above.
Issue 16
--------
Should geopriv help users to lie? What is an example of this?
It may be better to be vague. Giving multiple false locations
could allow averaging in order to give a better location.
May want to be able to send rule to LS to lie for the target.
Also, may want to be able to find out locations that will be useful
in the future, or locations that do not rely upon accurate
location information.
Agreed:
-------
The user should be able to hand a rule to the server,
to reply ``I am always in location X.'' User MUST be able to
do this in the rules; otherwise geopriv would have to be able
to decide what response a user can or cannot specify.
-------
But is "lying" the correct way to describe the capability? Could it
create legal problems? Doubtful, but could create perception
problems -- go with a more general description, other than
"geopriv allows you to lie."
Is deliberately false information more protective than
vague information? A poorly designed algorithm could reveal
more than the user intended to be revealed.
On the other hand, some request contexts may render low precision
inadequate -- there is a separate interest in telling someone
you are somewhere other than where you actually are,
rather than just giving a low precision response.
There is generally a mixed bag of uses for lying, some good, some
bad. So geopriv shouldn't decide whether user can lie; legal
norms and regulations will probably develop around false LI.
Room Consensus:
---------------
The protocol will not assume that the location is provided
represents where the user or target is situated at the
moment of transmission.
----------
But this consensus does not settle the issue of whether a user
can provide a false location.
Some ideas:
-----------
Would like to ensure that obfuscation MUST be a capability of
the protocol. However, this will not prevent an implementer
from disabling obfuscation. But the protocol should not be
silent on this point.
Geopriv should protect users who cannot trust a carrier/sighter.
The protocol can be designed to give privacy-concerned
users as much leverage as possible with carriers who are
not willing to allow obfuscation.
This assumes carriers will follow the protocol, a big
assumption, and there is no way to ensure that carriers will
implement the full protocol.
But from privacy advocacy perspective, this at least gives some
way of making a company responsive to concerns that they are not
implementing full privacy capabilities of the protocol.
The underlying idea is to push carriers to do as much as
possible to implement privacy protection, with the realization
that one cannot expect complete compliance with geopriv.
====> THIS ISSUE NEEDS TO GO TO THE LIST. <====
[Note from co-chair - the issue to the list is the provision
of conscious falsification feature by the protocol]
**********************************************************************
** **
** **
** JUNE 6, 2002 **
** **
** **
**********************************************************************
Wrap-up of Issue 16
-------------------
Consequences of allowing user to provide false information:
1. Cannot make an assumption about the truth of information.
2. Other protocols (e.g., Diameter) might want to assume that
the information is true; if it cannot do this, the protocol
may need to look into the policies. Messy.
There is a distinction between
a. giving a deliberately vague position (changing
GRANULARITY; accuracy) and
b. giving a false but perhaps precise location.
Agreed:
-------
Activity (b) immediately above needs a new term -- obfuscation
is too broad a term.
**************
NOTE:
**************
The following issue will be summarized and presented to
the WG for discussion in an Internet-Draft being prepared by Jorge
Cuellar/Alex Gogin/John Morris.
[It seems now it will be an email/viewgraphs. Allison]
**************
Three questions:
----------------
a. Can you have mutliple locations in a single object,
one use of which might be obfuscation?
b. Is it OK to blur your location by increasing radius?
c. Can you provide a false location (i.e., ``I'm in
Europe,'' when you are actually in N. America)?
Cuellar, Gogic and Morris will post short draft requirement to the
list.
Issue 17
--------
Is it out of scope to specify a policy language for geopriv?
Analogies to presence work. This may be inadequate -- geopriv
would like to have at least some pieces of policy traveling
with the object to control disposition after initial
access authorization.
Presence does allow watcher info (SIP-specific) -- a list of
identities that can be updated or will update a user upon
change in presence.
An outstanding question:
-----------------------
Is there an existing system that can be reused for this purpose?
SIP, IMPP are logical protocol options. Is P3P or a subset
thereof suited to the task?
Geopriv should have the simplest possible relationship
to the internal maintenance of policy servers, policy retention, etc.
Issue 18
--------
Do LoSi, ULR need explicit knowledge of rule maker policies,
or can they follow a set of policies established by other means?
(1) LoSi in examples yesterday did not seem to interact with rules;
LoSi is a ``dumb'' piece of hardware.
(2) Policy may specify: a group of people may know my location
with certain granularity. Does the ULR need to receive the
full statement of rules? Probably not. But ULR does need to
receive a statement of the terms on which it is receiving the LI,
e.g., ``You must destroy this information within 24 hours.''
But (2) may not be enforceable -- a consumer of data may not
abide by the terms. This is always a risk; not addressable by
technology. In such cases, the owner of the data may have
recourse to some legal action, such as damages arising from breach
of contract.
Geopriv doesn't have much to say about what ULRs do; is this moot?
NO; if ULR receives terms, it creates a relationship that may
provide legal redress if the trust is violated.
This may be the most protection that geopriv can offer.
Further protections available within geopriv
--------------------------------------------
(1) There may be self-enforcing technology to help: expiration
dates on the LI, for example. Making this part of the protocol
will facilitate the building of hardware that will be built
that will enforce these rules.
But won't there always be people who will capture momentarily
decrypted information, copy it, etc.? YES; this is always a
problem, but there should be some sort of RISK MANAGEMENT
built into the protocol, so such an effort is not moot.
(2) Does ALL LI pass policy to ALL ULR? Or is it sufficient to
pass a do-not-distribute bit and perhaps a timestamp?
Requiring more would constrain how dumb the receiving device
can be, if it is to follow the rules of distribution.
Could be a question of whether recipients MUST process the
instructions, or recipients MAY follow it (rendering the
instructions optional).
Possibilities for passing policy to ULR:
----------------------------------------
(1) ULR receives no policy on LI use.
(2) Object MAY/SHOULD/MUST contain arbitrarily complex
LI use policy.
(3) Object MAY/SHOULD/MUST implement some information --
a ``do not distribute bit'' and a timestamp.
It may not always be the case that the target device needs to carry
all policies -- there may be a policy server that fills in
information before LI is sent back to policy.
There was a feeling that (3) would deal with a lot of privacy issues;
there could be another bit that tells ULR to look to another
location/application to get more detailed policy, but that
policy would not be part of geopriv.
Leakage/disregarding this policy specification could grounds for
LEGAL ACTION.
More about the timestamp in (3):
--------------------------------
Need more than 1 timestamp:
(1) When was the LI accurate?
(2) Until when should the LI be considered current? TTL, in essence.
(3) Until when are you permitted to retain the LI?
Possible analogy with a web browser -- do-not-cache bit only
works to flag information for expiration, but does not create
requirement to actively purge caches, and applications do not
do this.
Should there be something more affirmative to signal permissibility
of redistribution?
==> ASIDE <== : There should be something in the requirements about
capability negotiations.
Identity requirements issues were discussed yesterday; issues 25 and
26 should go to the list.
Issue 19
--------
Generic policies MUST be made explicit.
E.g. you are roaming in
a geopriv-compliant environment that is not a trusted environment.
Target/Owner/Device must be able to know what the LoSi, LDS, etc. does
with LI.
It was agreed yesterday that there is not always a rule maker
between the device and the LoSi. There is no way, in that case, to tell
LoSi what it may do with LI.
Does this create a requirement that all LoSi must have a certain
amount of intelligence?
NO. This is what the policy server is supposed to do;
but in order to be geopriv-compliant, the
LoSi MUST NOT disclose LI to anyone but the Location Server.
LServ enforces the rules, and if LI goes anywhere else, there is
a total circumvention of geopriv. So this is the only explicit
rule (and it assumes secure communication between LoSi and
LServ).
****************************************
* END OF REQUIREMENTS DRAFT DISCUSSION *
****************************************
****************************************
* DISCUSSION OF SOME *
* PROTOCOLS/MECHANISMS/ISSUES *
****************************************
II. PGP - discussion led by John Noerenberg
a. General background.
----------------------
- Mechanism for defining enc, auth protocols.
- Defines mechanism for putting these things together.
- Set of packets, each with value that specifies
function (e.g., priv key, enc data).
- Geopriv could use PGP to exchange data; it is
truly end-to-end. Parties exchange keys via web of
trust; there is no other key distrib mechanism.
b. Questions/comments.
----------------------
1. Will PGP work for geopriv?
PGP is a vehicle for
client/server relations, but it assumes that parties have
exchanged keys. This may not be possible in geopriv
applications.
2. Does the lack of key distribution break models like
"Where is the nearest Pizza Hut?"
Not necessarily;
parties can specify where their public key is.
3. Should there be a mandatory key distribution model?
This is a very difficult problem (PKI) that does not
have a general, easily implemented solution.
Kerberos distributes keys to communities, something
like that might work. Requires trusted 3rd party to
authenticate the parties.
4. Within geopriv, many different models may work -- PGP,
message digests (giving weaker forms of shared secrets),
Kerberos.
5. Authentication based on identities is problematic;
want authentication based on pseudonym.
6. Geopriv should be able to support exchange of keys,
pseudonyms for discrete transactions between parties.
This is a requirement for a 3rd security association -- between
the Client and the LServ (in addition to Object and
LServ, Client and Object).
7. But if want to use key distribution, you can't do
this because authentication of keys is based on knowing
true identities.
8. (f) may not be practical; privacy and pseudonymity
are antithetical. INTEGRITY is an agreement over keys to be
used for information exchange. CONFIDENTIALITY ...
PRIVACY has more to do
with the linkability of information to an entity's identity.
Next topic:
-----------
II. (Probable) Security requirements for geopriv. -
Discussion led by Jon Peterson
a. Mutual auth of the generator of the object and the
consumer.
- Anonymity/pseudonymity. --> PGP is OK here.
But web of trust model is weak for ultimate assurance
that the other party can be trusted. (GnuPG may
also work, avoid potential IP rights
problems with PGP.)
- Shared secret may suffice.
- Certs may be needed in other cases.
b. Integrity of the object (perhaps optional).
c. Optional confidentiality.
d. Replay protection.
e. Though we do need some actual threat models.
Next topic:
-----------
III. An Example of a Geopriv-Using Protocol - SIP -
Discussion led by Jon Peterson
a. SIP: security mechanisms. TLS (SSL successor). Layer 4
cert-based or key-based confidentiality.
Doesn't work for UDP.
- SIP Digest. Challenge-based 1-way or mutual
authentication. Can provide some hash-based
signatures for confidentiality.
*** Hop-by-hop only.
-S/MIME. Provides security at MIME level.
Reuses CMS (Cryptographic Message Syntax; RFC 2630; ASN.1
based system; relatively heavyweight.)
Can provide integrity/1-way authentication
via signatures and optional confidentiality.
*** End-to-end security protocol; security lives
as long as the object does.
b. SIP could be seen as providing basis for
inheritable security characteristics.
c. Encourage development of several interoperable security
protocols, rather than one monolith that MUST be used.
d. PGP and S/MIME may provide a better model for geopriv
than TLS. Geopriv object could be transported by SIP and
SMTP; would want to allow geopriv security to survive
this.
e. But this is a heavier-weight solution and may not
limit the kinds of implementations that can support
geopriv. Therefore need to examine further the requirements
before settling on something too heavyweight.
f. On the other hand, there may be an argument for
hop-by-hop security only, because of the policies governing
the use and distribution of LI.
Next topic:
-----------
IV. SOAP and XML - Models for the GEOPRIV object?
Discussion led by Jon Peterson
a. XML has standard signature and encryption.
b. XML-staged signatures and encryption allow one to
assign different security properties to different groups
of elements.
- Different parties can sign different elements,
or a single party can control access to data at
a fine level of granularity.
- Signature with a certificate for authentication properties.
- *** Argument for staging security inside the object ***:
Not only can there be fine-grained control over security
policy, but also different levels of security for location
added/handled by different
entities along the way.
- It is important for the WG to record the kinds of THREATS
that require this kind of granularity.
c. SAML (authent/authorization)
d. Web services can still rely on underlying HTTP or BEEP
security properties like SSL/TLS, SASL.
e. GML may have some interest for geopriv.
f. Need to develop threat scenarios.
g. Need to analyze the computational cost effects of
an XML-based approach.
Next topic:
-----------
V. HTML/HTTP
Discussion led by Andrew Daviel, including discussion of
whether the HTML part is pre-geopriv.
Putting LI into legacy HTML documents. The related HTTP draft was
meant to make queries easier.
a. HTML draft: intended to add machine-readable location
info to legacy pages, to make more accessible to search
engines. NOT intended to insert personally identifying
information about authors.
3 attributes:
- Position (lat/long).
- Region (country code + state/province).
- Placename.
Implemented in the HTML ``meta'' element.
Privacy risks: same as search engines. It is possible to
collect history, track requests/published information.
This becomes a concern if there is a web server on a mobile
device, continually broadcasting its position.
The concern may not be so great because:
- User has to go out its way to do this.
- Most people do not run their own servers; assume
those that do so know what they're doing.
- Current internet architecture can reveal a certain
amount of geographic information (i.e., by IP address).
b. HTTP draft: embedding position information in HTTP
headers.
Purpose: CONVENIENCE. E.g., going to map site,
you wouldn't have to type in your location all the time.
- Client side: simplify location-based search;
location-based browsing.
- Server side: location-based search of non-HTML
objects.
Objectives: targeted information (weather,
traffic); less irrelevant advertising.
- Would be easily accommodated in existing
web servers.
- Could be sent directly by client or added
by client's proxy.
- Privacy risks: prior risks include IP-based
resolution.
Outstanding question:
---------------------
Does the HTML draft create information
that should be protected by something like geopriv?
- Or would HTML authoring tools end up putting this
information in HTML pages?
- This may be the way to go for HTML ONLY; there is a
risk in introducing this too soon and having other people
use it as a model for all sorts of location information.
Next topic:
-----------
6. P3P and its applicability to geopriv. Also other privacy
technology components.
Discussion led by John Morris and Deirdre Mulligan
a. A THREAT MODEL will be more useful than a
DESCRIPTIVE MODEL for analyzing privacy risks.
- Identities (anonymity tools directed toward
dealing with this problem).
- Onion routing/crowds/freedom: traffic analysis
as well as hiding who you are.
- Identity and information management tools: ways
to exchange information about policies that
govern use of information.
b. PRESENCE is a privacy risk; is there a way to "cloak"
yourself, hide the fact that you are there?
c. The closer information is to the underlying entity,
the stronger the (legal) privacy protections on the information.
E.g., information residing on one's computer is much more
strongly guarded than the same information residing
on someone else's server.
d. P3P implementations: Microsoft has a "compact"
implementation dealing mostly with cookies.
More complete implementations would describe uses of information
more fully, and allow identity management.
- P3P does not allow policy negotiation, in the sense
of back-and-forth negotiation.
e. Reaction to the idea of using P3P in geopriv.
- It may be overly complex for geopriv, given the
limited set of data and ability to set defaults.
- P3P DOES NOT HAVE ANY PRIVACY DEFAULTS.
===> It does not start with ANY privacy protection,
but merely provides for the expression of
certain preferences.
- The complexity is in part a function of the lack
of defaults. If there are no defaults, the protocol
has to provide for the expression of many,
many preferences.
- P3P ended up this way because (i) there are
many contexts in which information is shared,
e.g., between doctor and patient; (ii) the web is
general purpose and relatively open to competition.
There is no structural barrier to competition, and
sites could actually compete in marketplace for
privacy.
- Factor (ii) will very likely be quite different in
contexts where geopriv is used. There are only
a handful of wireless carriers in a region, etc.
- P3P placed a heavy burden on NOTICE, which will
not meet the requirements for geopriv.
Next topic:
-----------
7. Emergency Services.
Discussion led by James Polk
a. The Rub: jurisdictions have made or are making location of
a caller to an emergency center mandatory (e.g., FCC
regulations in US).
- There is some pressure here: FCC has taken one wireless
company to court for failure to comply with
regulation to supply 911 location information.
- It is not desirable to have wireless companies their own
protocols for FCC compliance.
- Policy engines could refuse to allow users
to specify ``Do not give my location to any person
whatsoever.''
- Dangers with this: (i) Efforts to co-opt the
emergency location information. (ii) Carriers
could decide whether to set policy about E911.
(iii) If 911 provider is not required to be
authenticated (perhaps it takes too long),
then LI is subject to attack by someone impersonating
a 911 provider. (iv) (iii) might be handled by
use of certificates, rather than high-level
requirements in the object.
- Introducing 911 exception to authentication,
authorization, encryption creates a path that
could be exploited.
- Concern: failed authorization could prevent
a call from being completed.
- Geopriv does not require that all communications
be encrypted.
- "Group key" idea: public key that could be
shared by all emergency services in a state, for example.
This would allow communication with emergency
services regardless of whether it is in an area
where the user has contemplated authorizing
access by emergency services to location information.
- Could have a short-term solution: encryption
and authentication are MUST implement items.
- Problem: it may politically untenable to
require implementation of encryption; people will
want to build devices that do not do encryption.
- Could say that encryption MUST be implemented but
its control is part of policy.
- Another concern: failure to authenticate on
the client/caller side could leave emergency
system vulnerable to attack by a flood of bogus
emergency calls.
- It may be possible to take a two-tiered approach: a
"Yugo" challenge and a "Cadillac" challenge.
911 might be able to use Yugo challenge, to
prevent emergency calls from being dropped due
to failure to authenticate. But then attackers will be able
send Yugo challenges.
- But in this context the phone will always be
initiating, and will expect something back. If a
response comes back from some entity that is not
- LServ will likely have the legal duty to provide the
location information.
- Assertion: geopriv CANNOT allow emergency centers to query locations;
this would open up a huge exception.
- Objection: there may be situations in which emergency
center may need to call someone back.
- Response: there are many reasons not
to allow emergency centers to query people --
this power is subject to abuse by the people who work in the
centers.
- Sense of the Meeting:
----------------------
We need to solve this first in IP; worry about
gateway to other worlds later. Bridging is
out of scope, for now, but could become a later
requirement.
------------
- Sense of the Meeting:
-----------------------
Geopriv needs to develop a list of MUST,
SHOULD, MAY requirements.
This is a list of
features that all geopriv implementations
must have, for security and interoperability.
Geopriv must arrive a minimum set of security requirements that
all geopriv implementations MUST support.
SHOULDs, MAYs to follow.
--------------
********************************
** **
** INTERIM MEETING ADJOURNED. **
** **
********************************
Received on Mon Jun 24 12:05:25 2002
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST