Subject: Notes from Non-meeting

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 19 Mar 2002 18:36:18 -0500

The geopriv meeting was, of course, cancelled as announced.
There was however, a non-meeting, totally unauthorized,
and totally informal.

At the non-meeting, a small group discussed several aspects
of the problem.  Since I was talking, I didn't write, but
here is what I remember we discussed.

The first thing we had surprising (to me) agreement on
is that what we want first is an object, and not a protocol.
The first uses of geopriv is within existing protocols.
So, we can, for a while, not talk about how we transport
the object, but only about the object and the operations
on it.

One of the things that keeps getting us "wrapped around the
axle" is that we can't seem to separate four different aspects
of this work:

1. The format of location information.  I believe we agreed
that it won't be hard to agree on this.  There seems to be
reluctance to actually  do this before we settle harder
problems.  I personally think this is wrong, and we should
just go ahead and pick a format (or actually more than one)
now. 

2. The transport of the object. As discussed above, we should
avoid dealing with this for the moment.

3. The policy that governs what can be done with the object.

4. The cryptographic operations needed to protect the object
when it is transported, and possibly as part of the implementation
of the policy.

One of the things we also agreed on (almost too readily it seems)
is that the latter is NOT going to be specified by geopriv.
We probably will offer guidelines on appropriate choices, but
because we agreed that transport was not on the table, precise
crypto is not on the table.  I think this is a very helpful thing
if the entire group agrees.

It would facilitate further discussion if participants tried
to keep these concepts separated.  Surely they are inter-related,
but we can discuss them separately.  I'd request that we try hard
to do that.  So, for example, you can talk about needing to know
whom you are disclosing location information to, but it may or
may not include cryptographic authentication (and in fact
in some cases there would NOT be any form of cryptographic
authentication, for example, with emergency calls).  

We also agreed that policy was the "messy" part of the subject,
but we also agreed that policy would have several forms including:
	1) Policy governed by contract or law
	2) Very simple policy - the example given was: I will give
		my location only to a proxy server, which will apply
		a more robust statement of policy to any other users
		of my location.  The policy of the first device is
		extremely simple.  The policy implemented by the
		proxy server can be complex.
	3) More expressive policy expressed in a variety of ways

There was great reluctance to get geopriv into the business of
devising new ways to express policy and in particular, we did
not see the WG designing a new policy expression language.
It was also observed that policy can be expressed by a user
interface as well as a formal policy language.

It was observed that the output RFC of the work could have
a 1/2 page statement on policy that would be possible to
agree on, but it was REALLY hard to figure out how to
agree on a multipage document in less than infinite time.

We had a really short discussion on terminology.  The discussion
centered around the word "target".  The basic confusion is
whether the target is an object like a cell phone, a collection
of objects like a cell phone a pager and a PDA, or a person
carrying all of the above.

Henning observed that we should use "object oriented" language,
and thus talk about the person object inheriting location from
the cell phone object.  The set of objects (cell/pager/PDA) problem
was observed to be a case of multiple inheritance but unlike in
computer science, not an inherently hard problem to solve :)

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Mar 2002 18:19:45 -0600

Some additional minor note: At various points, I noted that in many
practical cases, location information will be a part of some bigger set
of privacy-related information, for example in a session setup (user
name, organization, subject of conversation, IP addresses, etc.), an
email message or presence document or request. In many cases, these
systems will already have an overarching policy mechanism. As an
example, we have extended CPL for managing presence information and it
may well make sense to incorporate location policy in this. It would
seem odd to force a datatype-specific mechanism. Given that policy can,
in general, only be expressed by a Turing-complete program, complete
with various database interfaces, trying to agree on one subset seems
like an exercise in futility, as there is no natural stopping point
short of inventing another full programming language. (In another
context, floor control has suffered a similar fate, except that it's
been going on for five+ years.)

---

From: Dante Castiglione <[email-masked]>
Date: Tue, 19 Mar 2002 23:09:02 -0300

>just go ahead and pick a format (or actually more than one)

Brian, i.m.h.o. your are right, we should work on this right now, and choose
a handfull of formats that we believe (based on experience) can resolve a
good number of problems/situations. My 2c.

Regards,

Dante

Dante Castiglione
IT & Telecommunications Training
Capacitación en Informática y Telecomunicaciones
[email-masked]
www.geocities.com/dantecastiglione
ICQ: 49465083

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Mar 2002 07:15:22 -0600

i am easily confused by this stuff, so bear with me.

> if the entire group agrees.

i suspect that one cares about whether the box is locked or not,
and whether the checks in it are signed, irrespective whether the
box is carried by car or by plane.

> authentication, for example, with emergency calls).  

i thought that the 911 call centers were quite interested in being
able to know the phone number which called the service.

> interface as well as a formal policy language.

i suspect that security folk may be of some help de-confusing
policy mechanisms from policy description from policy decisions.

> agree on a multipage document in less than infinite time.

"i apologize for writing such a long letter, i did not have time to
write a short one."  i.e. a short description may require deeper
understanding and more work on simplification than a long complex
description.  so i deeply admire this goal.

> the cell phone object.

from a decade of oo in my dark and dirty past: inheritance is data
*and behavior*.

> The set of objects (cell/pager/PDA) problem was observed to be a
> case of multiple inheritance but unlike in computer science, not
> an inherently hard problem to solve :)

in computer science, multiple inheritance is easy.  there are fun
problems in implementation.

randy

---

From: Adam Shostack <[email-masked]>
Date: Wed, 20 Mar 2002 10:26:21 -0500

> able to know the phone number which called the service.

Firstly, let me say that I like Brian's seperation of issues; I think
it will help us move forward.

I think it is important to check the authorization of the emergency
service to demand location information; authenticating the number less
so.  Checking the authorization of an emergency service is important
because if we don't, it becomes possible for a script kiddie to
override all the privacy policies by sending a "I'm an emergency
center, please respond with your location" message.  

Authorization may be as simple as "You dialed 911; privacy is now
off."  The question becomes more complex if you dial another emergency
service, say, a suicide support line.  We may wish to punt on that, as
it's really hard.

Authenticating the number is less important because firstly, it may
not matter: someone called 911 and needs emergency help at this
location.  Secondly, it may not be available.  In some jurisdictions,
an otherwise non-functional mobile phone can be used to call emergency
services numbers.  Thirdly, if caller id breaks, emergency service
should not.  So, if we're going to authenticate the calling number,
and that authentication ever fails, we have two choices.  We can cut
off the call (which I think is a bad idea), or we can accept it
without authentication.  If we accept it with an authentication
failure, why bother trying to authenticate?

Adam

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Mar 2002 09:49:03 -0600

The current design of the VoIP 911 architecture (to be re-issued
shortly) envisions that the release of any privacy-related information
(IP address, name, etc.) is in-band with the call request, typically
included by the caller (if local user agent policy provides for that).
Thus, the PSAP/emergency call center never asks a third party. This
simplifies the problem greatly. Since the current design designates a
universal emergency identifier ('sos') for VoIP, the user agent can
easily make a policy decision ("only include location information if the
call is destined for 'sos'").

> should not.  So, if we're going to authenticate the calling number,

The problem is not authenticating the caller, but authenticating the
PSAP.

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Mar 2002 10:22:30 -0600

> The problem is not authenticating the caller, but authenticating the

i agree on the latter.  i suspect the psap would like to get the caller's
location if reasonably possible.  i suspect it would also like to get the
caller's identity, but not to check if they are authorized to call.

randy