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

From: Cuellar Jorge ^lt;Jorge.R.Cuellar@mchp.siemens.de>
Date: Fri May 24 2002 - 09:44:26 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?

I also dislike placing requirements on other protocols and
working groups, but it is my understanding that this is our
charter:
"For reasons of both future interoperability and assurance
of the security and privacy goals, it is a goal of the
working group to deliver a specification that has broad
applicability and will become mandatory to implement for IETF
protocols that are location-aware."

Now if SIP is able to satisfy the security and privacy
requirements that seem necessary, and to interoperate
with other protocols assuring the security and privacy
goals, I do not see why those requirements for SIP
imply any changes for SIP.

Privacy refers to the right of an entity, normally a
person, acting in its own behalf, to determine the degree to which
it will interact with its environment, including the degree to
which the entity is willing to share information about itself with
others.
How does exactly SIP protect the privacy of Location Information?

To quote the International Working Group on Data Protection
in Telecommunications (Group of EU Privacy Commissioners)
(International Working Group on Data
Protection in Telecommunications: Common Position on Privacy
and location information in mobile communications
services. Adopted at the 29th meeting of the Working Group
on 15/16 February 2001 in Bangalore
http://www.datenschutz-berlin.de/doc/int/iwgdpt/locat_en.htm):

"The enhanced precision of location information and its
availability to parties other than the operators of mobile
telecommunications networks create new unprecedented threats
to the privacy of the users of mobile devices linked to
telecommunications networks. The Working Group therefore
deems it necessary that the technology for locating mobile
devices is designed as little invasive to privacy as
possible."

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

The last 2 reqs are:

21. When a Location Server accepts a policy from the Rule-
 Maker, the target MUST prove to the combined protocol that
 he owns the claimed group or role identifier that should be
 passed to the Location Recipient.

One simple way of implementing this requirements is avoiding
"role identifiers" altogether. But if the
information "A person of group A is in location X" may be
fake, what is it's value?

22. The "generic" policies (as opposed to the policies
 created by the Rule-Maker) used by the Location Data
 Source, by the Ultimate Location Recipients and by the
 Location Server of some special scenarios to be discussed
 yet, MUST be made explicit.

The purpose of the requirement is that, if some entity
uses some kind of "generic" policies (for instance:
the location information will be only passed to the
"Home Location Server" of the user), then those
generic policies must be spelled out.
I do not see your problem with that.

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

Recharter?

I really do think that we are able to solve the problem
in our lifetimes, if we go for it.

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

No. I know of many systems that offer authentication, confidentiality
and anonymity. Don't you?

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

Please make a start.

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

<snip>

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

I agree. We need to do that.

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

Yes, me too. But this discussion on what exactly are the
"fields" (or attributes) of the Location Object is still
somewhat premature here.

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

Although I have some ideas on that, I do not think that this
is the time for discussing those questions. For some ideas look
for instance to the IBM Privacy Institute
http://www.research.ibm.com/privacy/

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

Well, on the other side public regulations will enforce us to
provide privacy. How do you want to explain that to them?

<snip>

>> It is indeed an apparent contradiction that you want
>> on one side authentication and on the other side privacy. But
>> you can have both.

> Thank you very much !

Thank you too! Regards,

Jorge
Received on Fri May 24 09:48:25 2002

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