Subject: [Geopriv] 3GPP LCS Privacy options

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 10 May 2006 22:40:50 -0500

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.

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.

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

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.

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.

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?)
 2. Attribute-based authentication
 3. Per-request consent arrangements
If any of the features are interesting, what is required?  More formal analysis, requirements gathering, drafts...

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