Subject: RE: Geopriv WG - meeting 5-6 Jun, other news

From: Cuellar Jorge <[email-masked]>
Date: Wed, 22 May 2002 22:26:40 +0200

Richard Shockey writes:

> Unfortunately I will personally be unable to attend the
> proposed off site but I wish to make some comments on the
> proposed requirements draft, which IMHO is currently
> inadequate to the task.
> 
> In the first place it is my belief that we are not dealing
> with a protocol here but objects and the policy surrounding
> those objects.

In a certain sense this is true: our main concern is a
Location Object. But the rules that govern the use of that 
object, may be seen as a "protocol", what we call a "embedded
protocol". Besides that protocol, we could also set some
requirements on the transporting protocol or on the union
of embedded and transport protocol. But anyway it must be made
clear how the 2 protocols together will manage the object.

> The proposed draft way too long on imposing policy on the
> objects without actually defining any requirements for the
> objects.

This is true, and we want to make progress in that direction too.
Up to now it has not been clear what parts of the object
will be "opaque" from the point of view of the embedded
protocol, that is: uninterpreted. The requirement draft focuses
on the privacy, authentication and security requirements.
As the Description of Working Group says:
"The primary task of this working group will be to assess
the authorization, integrity and privacy requirements
that must be met in order to transfer such information, or
authorize the release or representation of such information
through an agent."

> It strikes me there are two key requirements here which is
> 1. a Location Object which is the semantic expression of

You mean syntactic?

> location data and other useful information ( raw or other )
> of the Target that can be interpreted by Location Seeker in
> order to act upon it and 2. A Location Privacy Object that
> presumably under the control Rule Maker ( perhaps the Target
> ) that expresses what information can be transferred and
> under what conditions.

Yes, the Location Privacy Object is what we call the "policy".
But I would also agree with the name " Location Privacy Object".

>  Both of these objects reside in this
> "Location Server" that can be queried by some undefined and
> presumably out of scope application mechanism keyed on by
> some identifier ( phone number for instance).

How the Location Server indexes his Objects
may be out of our scope.

> I submit that any discussion of transport of geopriv objects
> be deemed out of scope and those discussions are best left
> to the applications that need geopriv data ...SIP for
> instance.

That would be acceptable, as long as the transport protocol
obeys the rules attached to the Location and Location Privacy
(Policy) Objects.

> Let be honest here .. though there are several applications
> where this architecture might be useful the clear and
> present need is in Internet Telephony and SIP in particular.

I know of other applications that would need this...

> Where it MIGHT be legitimate to discuss Authentication &
> Authorization requirements between geopriv entities it is
> not appropriate to impose requirements on other protocols
> that may already have built in AA methodologies. It is very
> easy for me see how these objects could be easily integrated
> into the SIP environment using all of the existing tools SIP
> has at its disposal without imposing any new protocol
> requirements on SIP.  

Yes, if you can integrate the Location Object into SIP
in a way that the entities unambiguously authenticate
themselves and an identity management is on the way
that provides anonymity to the parties, then
what you are saying is basically that the requirements
draft is in fact easily satisfied by SIP. Those are good news.

> The Location Object and its Privacy
> object could easily be transferred to a Location Server
> integrated as part of the SIP proxy during a REGISTER
> session for instance ...and a Location Seeker could request
> the Location Object in a form of INVITE where the PSAP could
> clearly and unambiguously authenticate its identity.

Perhaps there are other ways of doing this, ...

> Discussions on identity management is SIP is now well
> underway.
> 
> What I'm hoping will come out of this meeting is some
> agreement that the requirements document is not done unless
> the requirements for the Location Object and Privacy Object
> can be sufficiently defined, other wise we will not be able
> to progress the work froma short, clear, concise and
> reasonable document. I suggest now and will continue to
> suggest that the scope of the requirements document reflect
> this generally minimalist approach to object design and
> leave general policy details to the applications that must
> use the objects.

Yes, the document is way too long and has to be reduced to
a reasonable minimum. Many parts in it's current form
are meant only for discussion.

> Now on to some particulars.
> 
> IMHO these data elements look like XML objects and the
> Privacy Object should be an extension of the work already
> done in W3C on P3P.  Where as P3P was designed as a PULL
> mechanism to define privacy policy for servers running HTTP
> ..what we are seeing here is more of a PUSH mechanism in the
> opposite direction.  The Rule Maker defines what they want
> people should see not the Location Seeker defining what
> their policy is.
> 
> So What are the requirements for a Location Object?  I might
> suggest a good start might be ...
> 
> Index key - telephone number ?

The index key, if you need one, is probably the Target ID,
which could be a telephone number. Although for the behavioral
description of the protocol it does not seem to be necessary 
to specify how the Location Server manages internally
his Objects.

> TTL

Time to live? Is that an absolute value or relative to
the time of source sample? (in the first case you do not
necessarily need the time of source sample).
This could be an opaque field, from our point of view.

> Latitude Longitude

We need one format for location, but of course there are
many options: "the working group will
select an already standardized format to recommend for use
in representing location per se. A key task will be to
enhance this format and protocol approaches using the
enhanced format, to ensure that the security and privacy
methods are available to diverse location-aware
applications."

> Source

What is this exactly? (The name of the entity that provided
the Location Information in first place, that is, the
Location Sighter (LoSi) or Location Data Source?)

> Time of source sample
> Confidence Level
> Motion & Direction if available etc.

> What then are the requirements for the Privacy Object ... I
> make no claim to be a expert on the P3P work but I think
> that would be a good place to start.

I have looked at them in detail; we can use many ideas.

> Last but not least I have real problems with Identity
> Protection statements in REQ 12.  I've said this before and
> I'll say it again ..there are serious policy issues here
> with public safety officials if the protocol can permit the
> Policy Maker to override legitimate requests for identity
> information.  This is not the wiretapping issue ... on
> issues involving public safety state and federal regulators
> WILL take a very very firm stand. Therefore the language
> should be changed from MUST to MAY be able hide real
> identity.

I agree that our specification has to comply with public safety 
state and federal regulations, and we have to be clear on this.

> I want this list to understand that we are laying the ground
> work for what is perhaps a once in a generation advance in
> the concept of a public service location protocol that if
> defined correctly could link not just the location of an
> individual in distress but also provide life saving links to
> other forms of data ...health records that could save
> countless lives.  Think about that in the context of privacy
> requirements.

Yes, and health records are subject to lots of privacy regulations.
Not only the patient needs to be protected, also the doctor for
instance. It is indeed an apparent contradiction that you want 
on one side authentication and on the other side privacy. But
you can have both.

Regards,

Jorge
--------------------------------------------
Dr. Jorge R Cuellar     T +49 89 636-47 585
Security                
CT IC 3                 
Siemens        [email-masked]
----------------------------------------------

---

From: Richard Shockey <[email-masked]>
Date: Thu, 23 May 2002 16:07:36 -0400

>clear how the 2 protocols together will manage the object.

I dislike attempting to place requirements on other protocols and working 
groups.This is better left to a lengthy and well reasoned Security 
Consideration section. I have considerable faith in the ability of the IESG 
to impose security requirements where necessary. But this is clearly an 
issue of how / if the WG can impose specific security and authentication 
protocols on others when .. in the case of SIP for example ..there is an 
existing architecture in place that we have no need to tamper with.

How would you propose to resolve this apparent conflict?

>on the privacy, authentication and security requirements.

of which I submit the last two are out of scope for the objects themselves 
.. how SIP uses these objects in its transport and security framework is 
the business of the SIPPING WG and not here. What I am hoping to see is a 
rescope of the work plan and indeed perhaps even a recharter that focuses 
on a minimal set of real deliverables FIRST and a requirements document 
that narrows the scope of the problem to something that can be achieved in 
our lifetimes.

I continue to submit that your proposed requirements documents is 
insufficiently focused to be IETF WG plan. Many of us have seen WG's drift 
into all sorts of rat holes and wander in the wilderness when the 
requirements documents was not clear on what is to be achieved.

I believe I have a legitimate concern that the direction you propose leads 
down the path towards an"end world hunger" solution . Considering the 
legitimate need for a solution I just think it makes sense to break up the 
problem into clear, discrete problem statements that can be addressed one 
at a time.

>authorize the release or representation of such information

well yes but ... I still see no real discrete problem statements in your 
draft that can be translated into concrete requirements for how the WG is 
to express Location ( though this seems to be solving itself  the LIF work 
looks most promising ) or Privacy. What is privacy ? ..how can Privacy be 
expressed in a syntax that can be rationally machine processed by 
applications that may or may not have unlimited processing resources.  What 
is that syntax? What elements of Privacy MUST be expressed in this proposed 
syntax?

Forgive me for the rant ..but I've had to live with some of this before.

> > 1. a Location Object which is the semantic expression of

yes sorry

>But I would also agree with the name " Location Privacy Object".

I might add you have done a great service in your draft by attempting to 
rationally define functional geopriv elements. That work alone saves 
countless hours and misunderstandings I hope your next draft can further 
refine these terms ..Ive personally found them most useful.

>How the Location Server indexes his Objects

agreed

>obeys the rules attached to the Location and Location Privacy

of course ... agreed

>draft is in fact easily satisfied by SIP. Those are good news.

yes ... which I think supports my contention that the work here should be 
compartmentalized into more manageable pieces , however it would be useful 
work to offer a security and authentication framework for those OTHER 
protocols that are not as robust and well defined as SIP

>Perhaps there are other ways of doing this, ...

  .  just a thought

>This could be an opaque field, from our point of view.

Well this goes back to the concept of Confidence. The IMHO Target or Device 
9source) in your definitions may wish to set such a value..its probably 
arbitrary but I mentioned it as a possible example ..however given the 
kinds of discussion  we are seeing from experts in this problem space I be 
interested to hear their views...

>Location Sighter (LoSi) or Location Data Source?)

I guess Device in your terminology

>I have looked at them in detail; we can use many ideas.

This IMHO is where we will need the most brain power... syntactically 
expressing a complex and often vague term like privacy is going the be the 
#1 challenge.

>state and federal regulations, and we have to be clear on this.

please ... I have splinters on my rear from sitting on ancient government 
issue chairs trying to explain these kinds of things to them..

>on one side authentication and on the other side privacy. But

Thank you very much !

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Randall Gellens <[email-masked]>
Date: Thu, 23 May 2002 14:41:54 -0700

At 4:07 PM -0400 5/23/02, Richard Shockey wrote:

>  Considering the legitimate need for a solution I just think it 
> makes sense to break up the problem into clear, discrete problem 
> statements that can be addressed one at a time.

Sounds like a good idea to at least try this.  Can you start by 
proposing those you see?