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

From: Richard Shockey ^lt;rich.shockey@NeuStar.com>
Date: Thu May 23 2002 - 16:07:36 EDT

>
> >
> > 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.

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?

> > 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.

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.

>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."

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.

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

yes sorry

> > 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".

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.

> > 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.

agreed

> > 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.

of course ... agreed

> > 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.

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

> > 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, ...

  . just a thought

> > 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.

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...

> > 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?)

I guess Device in your terminology

> > 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.

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.

> > 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.

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

> > 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,

Thank you very much !

>Jorge
>--------------------------------------------
>Dr. Jorge R Cuellar T +49 89 636-47 585
>Security
>CT IC 3
>Siemens jorge.cuellar@mchp.siemens.de
>----------------------------------------------

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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: rshockey@ix.netcom.com> or
<mailto: rich.shockey@neustar.biz>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Received on Thu May 23 16:03:41 2002

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST