Re: RE: [Geopriv] Consensus on changes to location-conveyance

Hi Brian,

Brian Rosen wrote:
> I don't really understand why you think location by reference is so much of
> a concern. 

It is interesting that you say that. In the Geopriv L7 design team you
are the only person that wants to see an applicability statement being
written.

Having a SIP proxy adding something (either location-by-value or
location-by-reference) is not different to the stuff we discuss in the
design team. There, you see a lot of privacy, security, etc. problems.
Here you don't. How come?

If you go through my mail with the large number of scenarios then you
find a number of open issues that need to be answered. Alternatively,
you can also go through draft-tschofenig-geopriv-l7-lcp-ps-00.txt

  If you look at the discussion in context, PIDF-LO defines
> location as part of presence.  All of these concerns are relevant there, and
> I think they have been adequately covered there.  We even have some work on
> anonymization of the identity (and thus of the URI) in presence.  Generally,
> a presence uri:
> 
> Is not valid for a limited amount of time
> Is not hard to guess, if it uses an AoR and could be with anonymous URI.
> Identifies the user if it uses an AoR and doesn't with anonymous URI
> 
> The protocol (SIP) for retrieving presence, and thus location has the
> location ruleset as we defined for PIDF-LO, but otherwise does not have "no
> cache" semantics (albeit caching headers is not very interesting in SIP).

You cannot compare presence witht he location-by-reference solution
since the deployment case is different.

> 
> Generally, presence systems do have user control of who is allowed to access
> information, including location and identifying information, so I think that
> is covered fairly well.

Not true in this case.

Here we have a SIP proxy in the access network doing all the work. You
can compare it with a SIP-based LIS from the Geopriv-L7 work. This node
has no clue about your privacy preferrences and does not know your
identity. This is what we discussed in the past and several proposals
where made, namely:

* end host provides privacy preferences (see HELD)
* end host does not provide privacy preferences since there is no
PIDF-LO (see RELO).

> 
> Proxy insertion of location, whether by value or by reference has the threat
> of not being as subject to user control, but I think in every case you have
> to trust your provider to do as you wish, whether it is your presence
> provider or your location provider independent of your presence provider,
> and proxy insertion doesn't fundamentally alter that.  I worry more about
> it, but I don't objectively think it's much different.

In this case you don't really know the provider and it might not be your
  provider.

> 
> Now, if there are other location dereferencing systems, they may need an
> analysis like what you are suggesting, but with respect to SIP Presence, as
> a form of location by reference, I think we have been over the ground
> sufficiently, and we have RFCs that permit it.  Adding restrictions on the
> Location header, which I propose is useful precisely to allow an anonymous
> presence uri that does not reveal identity is not so great I think.  If you
> don't allow that, you would kind of have to use an AoR, which may be
> appropriate in some cases, but would not in others.

The reference might not reveal the identity but what about the identity
in the PIDF-LO. If you argue that there does not need to be one (or it
is a faked one) then I am puzzled why it has been a source of major
confusion in the Geopriv-L7 design team work (and in previous
discussions about the same subject in Geopriv).

> 
> I think the proponents of proxy insertion argue that providing it means
> endpoints don't have to do anything, so I would think they would object to
> explicit permission to do so.  You might get away with a flag that says
> "don't do it" in the IETF process, but whether such a flag would be deployed
> is another matter.   I think we all agree that the emergency case is
> different here; laws govern behavior, and in most cases compel location
> assertion.
This is indeed an interesting case where the end host indicates
something whether it wants the proxy to add location (by reference).

> 
> I kind of like the idea that the proxy inserts the header in the response so
> the UAC can see it.  What do others think of that? 
> 

Ciao
Hannes


> Brian
> 
> 
> 
>>-----Original Message-----
>>From: Jeroen van Bemmel [mailto:[email protected]]
>>Sent: Tuesday, July 25, 2006 7:22 PM
>>To: Brian Rosen; 'Marc Linsner'; Peterson, Jon; 'Andrew Newton'; Rosen,
>>Brian
>>Cc: [email protected]; [email protected]
>>Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-
>>conveyance
>>
>>Brian,
>>
>>
>>>Would you not agree that if a proxy is allowed to insert
>>>location-by-value,
>>>the concerns would be the same?
>>
>>That would depend whether the URL dereferences the current location, or
>>the
>>location at a particular moment in time. The value of a URI with up2date
>>location info is much higher and much more privacy invading than a one-
>>time
>>snapshot of a user's location. So perhaps same concerns, but much stronger
>>
>>For location-by-reference, you'd probably want some additional
>>requirements:
>>- URL must be valid for a limited amount of time
>>- URL must be cryptographically hard to guess
>>- URL must not contain any information that identifies the user / device /
>>AoR
>>- for whatever transport protocol is used: response must be marked as 'no
>>cache'
>>- user must be able to remove the information at the URL, ie explicit
>>invalidation
>>- user must be able to verify correctness of the issued information (ie
>>user
>>can access the URL himself)
>>- user must be able to control who accesses the URL, both upfront and
>>history of accesses (for a reasonable period)
>>- there must be explicit consent before a proxy would insert user location
>>
>>For the latter point: except for emergency scenario's, the UAC should
>>include some flag in the INVITE saying "proxy: please append location".
>>You'd probably also want some feedback (eg proxy or UAS adding a header to
>>the response saying 'this is the URL that I appended/got'
>>
>>Regards,
>>
>>Jeroen
>>
> 
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip