Subject: AW: [Geopriv] 3GPP LCS Privacy options

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 16 May 2006 01:13:05 +0200

Hi Martin, 

thanks for your mail. Please find some comments below:
 
> -----Ursprüngliche Nachricht-----
> Von: Thomson, Martin [mailto:[email-masked]] 
> Gesendet: Donnerstag, 11. Mai 2006 05:41
> An: [email-masked]
> Betreff: [Geopriv] 3GPP LCS Privacy options
> 
> I considered writing a draft on this topic, but I decided not 
> to, since it would be a throwaway anyhow.  If you think that 
> this warrants more (formal) explanation, then I might be able 
> to find time to write some more on the topic.
> 
> One of the goals for SIMPLE that I have heard stated is that 
> the system must provide the same level of service as those 
> more specialized IM systems that already exist.  I think that 
> the SIMPLE WG have this under control, but there are some 
> aspects of the 3GPP LCS architecture that I think GEOPRIV 
> should examine to see if they are applicable.
> 
> To my knowledge, not many people in the WG are familiar with 
> the privacy work in 3GPP/OMA LCS.  There are some major 
> differences in the approach, so some of these wont be 
> applicable.  I'll try to touch on a few points.
> 
> Probably the fundamental difference in approach arises from 
> how location is determined in the cellular world.  For them, 
> it is a costly operation in both time and network resources 
> (particularly over the air interface - in GSM, delivering 
> A-GPS assistance data can take several seconds, voice quality 
> can be degraded so that greater bandwidth is available).  
> This has lead to a model where location is only determined 
> when it is needed.  Subscription interfaces exist at the 
> public edge of the network, but the support for the tracking 
> features that support this is quite limited in the core.

This probably refers to the issue of location by reference. 

> 
> The other thing to consider is that many phone users wont 
> manage their privacy policies, or even be aware that one 
> exists.  Cellular operators often manage these policies 
> themselves.  Currently, 3GPP and OMA do not define a means of 
> expressing policy, except for a deprecated protocol interface 
> where a limited policy can be sent from HLR to VLR.  The 
> policy life-cycle is a topic for another (long) email.

Do you have some data whether users don't like to manage their privacy settings? 

> 
> The on-demand request arrangement has lead to a limited set 
> of privacy options.  The controlled environment also provides 
> some interesting options to cellular providers.
> 
> When a request is received, privacy rules are evaluated based 
> on a simple set of criteria:
>  - the identity of the requester
>  - the time of day
>  - the location of the target
>  - whether the requester is currently in a call with the target

We don't have the capability to express something like 'Please do not send my location info from 8:00am to 4pm.'
This was dumped some time ago. 

I don't understand what the purpose of the last item on your list is. 

> 
> We can deal with all of those, except the last.  I think that 
> a condition like this would be very useful.  In fact this 
> rule is implicit for 9-1-1 in mobile networks - the emergency 
> overrides should be denied unless a 9-1-1 call is in progress 
> (providers take this responsibility very seriously).  
> Unfortunately, I can't claim to have the breadth of SIP 
> knowledge required to specify this, or even know if it is 
> feasible, otherwise you would be seeing a draft rather than an email.

I am not sure I understood the purpose of this. 

> 
> Another aspect that has been discussed in 3GPP documents is 
> the concept of a service type.  This means that requesters 
> are classified by the type of service that they provide.  A 
> number of basic types are identified including roadside 
> assistance, food delivery, find a friend, navigation.  This 
> demonstrates one of the advantages of the closed model - 
> services who want location have to establish a relationship 
> with the carrier, who can then guarantee that they provide 
> this service.  Users can use the assurance of their carrier 
> to make decisions on a class of services, rather than having 
> to make multiple decisions.

Interesting.

> 
> This is where some of my enthusiasm for SAML and 
> attribute-based authentication has come from.  I also think 
> that this is a useful feature.

Where do you see SAML playing a role here? 

> 
> The results of privacy evaluation are less useful, but I'll 
> cover them for completeness.  There are five basic classes of result:
>  - allow
>  - disallow
>  - allow and notify the user
>  - ask the user and disallow if there is no response
>  - ask the user and allow if there is no response
> 
> Remember that as a consequence of the basic model these would 
> apply on a per-request basis.  This differs from the 
> subscription model.  Watcher Info tells you of the existence 
> of a subscription, not when location information is being 
> determined.  Similarly, the two ask methods would only occur 
> once when using common policy.
> 
> Based on my research, common policy and SIP would be able to 
> provide all of these (or a close approximation thereof), 
> except the last.  The question is whether this option is 
> worth pursuing.  I'd suggest no for this one - and I'm sure 
> that we will get many good reasons for that conclusion.
> 
> The only other aspect of this is to whether real-time 
> decision making is worth having.  Personally, I don't like 
> the possibilities for denial of service and the various 
> annoyances that could be caused by an attacker.  In a 

> controlled environment these might work, but I don't think 
> that these are appropriate for the Internet.
> 
> Things to consider:
>  1. Call-related/unrelated condition for common policy and 
> whatever is required to make this work (event package?)

I guess more information is needed here. I wonder how this relates to the SPAM policies some of us have been working on where authorization decisions can be made based on some call specific properties. ;

>  2. Attribute-based authentication

This item refers to SAML. Right? 

>  3. Per-request consent arrangements
> If any of the features are interesting, what is required?  
> More formal analysis, requirements gathering, drafts...

Ciao
Hannes

> 
> Disclaimer: This is all from my experience, so inaccuracies 
> arising from faulty memory and more recent changes in 3GPP 
> are possible.
> 
> Ta,
> Martin 
> --------------------------------------------------------------
> ----------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.  
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------
> ----------------------------------
> [mf2]
> 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 16 May 2006 21:15:00 -0500

Thanks for the feedback Hannes, I've put a little extra clarification inline and trimmed it back a little.

> This probably refers to the issue of location by reference.
 
I included this so that people have some understanding of the motivation behind the by-reference arguments.

> Do you have some data whether users don't like to manage their privacy

I can't speak for "liking", only that our 3GPP location products have provided an interface where users are able to manage their own privacy preferences.  This feature has been included for many years and to my knowledge, no operator has ever enabled the option.

> > ...
> > ...

Imagine that I want a pizza delivery service to locate me, but I don't want them locating me when I haven't asked for a pizza.  Therefore, I set a rule that says: "pizza service X may know my location, but only if I am currently talking to them on the phone".

This is termed a "call-related" policy, as opposed to the "call-unrelated" policy, which dictates how you may be located when you aren't in a call.

> I am not sure I understood the purpose of this.

See above.

I'm suggesting that emergency calling fits into this "call-related" category.  If calling an emergency services implies that you have waived privacy rights, that is OK, but do emergency services have the right to locate you when you aren't calling them?  It's a specific example of how "call-related" can apply, depending on the answer to that question.

> Where do you see SAML playing a role here?

SAML can be used to make assertions about attributes of an entity.

To go back to the pizza example, I might want to be able to call for pizza no matter where I go.  Given the large number of different chains, and independent local delivery services, with the current policy you would have to include the identity of each of these services in your policy.

On the other hand, if each of these pizza shops were able to provide a SAML assertion that signified that they had the attribute "pizza delivery service", then you would be able to base a decision on a simple rule: "is this a pizza delivery service?"  You wouldn't have to establish a list of all possible pizza delivery services in advance of making the call.

> I guess more information is needed here. I wonder how this relates to the
> SPAM policies some of us have been working on where authorization
> decisions can be made based on some call specific properties. ;

Like I said, I don't have the necessary knowledge to address this.  It sounds like you might have something.

> This item refers to SAML. Right?

I'm suggesting that SAML is a possibility.

> > More formal analysis, requirements gathering, drafts...

Thanks,
Martin
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
[mf2]