Controlling Access to Location Information

Up until the Location Server receives location information, it is within a controlled environment. It is reasonable to assume that most of this occurs within the access network and that appropriate measures are taken to ensure that the information can't be viewed by anyone. After the Location Server receives, or determines, location information, it is responsible for issuing PIDF-LO documents to Location Recipients.

An authorization policy records a user's prior consent. It is a document that states when, and how, information is provided. Most importantly, it includes who can receive location information. The Location Server decides which Location Recipients receive location information based on an authorization policy.

The GEOPRIV common-policy (see 13) is an XML document format used for authorization policies. It is a typical authorization policy document, except that each rule includes a transformation. A transformation is essentially a special type of action that is used to modify information before it is sent to a particular recipient. Figure 2.12 shows how a common-policy document is structured.

Figure 2.12: The structure of a common-policy document.

Authorization Policies

Authorization policies all share a common structure. An authorization policy is formed of a set of rules, each with a condition and an action, hence authorization policies are often called rulesets. The condition section outlines when the rule applies and the action is a list of instructions for the policy enforcer-the entity that is applying the rules.

The policy enforcer evaluates every rule in the authorization policy and provides an answer: either "allow" or "deny." If any rule contains conditions that can be met, the associated actions are performed and location information is sent. Conversely, if no rule contains conditions that can be met, a failure response is sent and the requester does not receive any information.

When it receives a request, the Location Server evaluates the common-policy document by performing the following procedure:

1. The conditions component of each rule in the document is evaluated. If the conditions for a rule pass, the rule is collected. At the end of this step, the Location Server will either have a set of rules that matched, or nothing. If no rules matched, then the request is denied.

2. The actions for all the rules that matched are combined into a single set of actions. The same is done for all the transformations. This helps prevent the same action or transformation from being performed twice because of redundant rules.

3. The Location Server performs all the resulting actions.

4. The Location Server takes the PIDF-LO and applies the transformations. Transformations alter the PIDF-LO for the Location Recipient, removing or obscuring different parts as the Rule Maker determines.

5. The PIDF-LO is provided to the Location Recipient.

The simplest and therefore, most common, form of authorization policy is a list of recipients that are allowed to receive location information. This is otherwise known as a buddy list, much like the lists maintained by instant message services. The following common-policy document includes a single rule that specifies a group of authorized recipients:

 <?xml version="1.0"?> <cp:ruleset xmlns:cp="urn:ietf:params:xml:ns:common-policy">   <cp:rule >     <cp:conditions>       <cp:identity>         <cp:one />         <cp:one />         <cp:many domain="sample.net">           <cp:except [e-mail]"/>         </cp:many>       </cp:identity>     </cp:conditions>     <cp:actions/>     <cp:transformations/>   </cp:rule> </cp:ruleset> 

This authorization policy allows the SIP users, [e-mail] and [e-mail], access to location information. It also allows everyone from sample.net, with the exception of [e-mail]. The single rule in this authorization policy has no actions or transformations.

Common-policy is what is known as a policy framework. On its own, it specifies little more than conditions based on the identity of the recipient. Other specifications then define more conditions, actions, and transformations. The GEOPRIV-policy specification (see Reference 13) includes a range of conditions and transformations that are applicable to location information. Common-policy is also used as a basis for other specifications in other application areas.

Privacy for 3GPP Location Services

It is interesting to compare the model proposed by 3GPP in Reference 14 with the privacy model employed by GEOPRIV. The GEOPRIV model requires that the Location Server acquires the authorization policy and evaluates it. In contrast, 3GPP defines an enforcement node in their location architecture (see Reference 10), rather than a document. The architecture delegates the task of evaluating the policy to a separate node, called a Privacy Profile Register (PPR).

The PPR not only hosts a user's privacy policy, it also evaluates it. A network protocol, called the Privacy Checking Protocol (PCP) has been defined by the Open Mobile Alliance (OMA) in Reference 15 for querying the PPR. The GMLC gives the PPR sufficient information about the location request and then asks if the request should be permitted.

The most interesting feature of PCP is that it can be used before location information has been determined. In this situation, it can provide three answers: allow, deny, and conditional. A conditional response permits the location determination to continue, but it indicates that a second query to the PPR must occur after location information has been determined for a final evaluation. This feature avoids the cost of determining location in those situations when it isn't required. The PPR interaction is shown in Figure 2.13, with the conditional portion highlighted.

Figure 2.13: Delegating the evaluation of privacy rules in 3GPP.

The 3GPP model does not preclude the use of an authorization policy, but the structure of this architecture removes the need for a standardized form.

Security for Privacy

Security is a very important part of protecting privacy. An authorization policy is only one aspect of ensuring privacy. Other aspects include authentication, data integrity and attribution, and encryption.

An authorization policy can require that Location Recipients are authenticated by the Location Server before they are given location information. In common-policy, this authentication is implicitly required, if an identity is specified, that identity must be verified by authentication. How that authentication is achieved is not specified, in order to permit the selection of the most appropriate method by the Location Server.

Data integrity and encryption are always employed by the Location Server for protocols that carry location information. Encryption ensures that the information can't be viewed by any but the intended recipient; data integrity ensures that it is not modified by an attacker for any reason. These measures are also employed in the access network before the location information reaches the Location Server for the same reasons.

The security aspects of this architecture in this area are many and varied. This section barely scratches the surface. It is not the intent of this book to cover security in detail. In the next chapter, the HELD protocol is described, with a little more detail on security, including the use of the Transport Layer Security (TLS) protocol, as well as a range of security controls.