From: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-00.txt (ephemeral URL designed to be broken) Title: Policy Rules for Disclosure and Modification of Geographic Information Reference: draft-ietf-geopriv-policy-00 See also: IETF Geographic Location/Privacy (geopriv) Working Group Charter http://www.ietf.org/html.charters/geopriv-charter.html See also: Geographic Location/Privacy WG Drafts http://xml.coverpages.org/ni2003-06-27-a.html ----------------------------------------------------------------------------- GEOPRIV H. Schulzrinne Internet-Draft Columbia U. Expires: April 19, 2004 J. Morris CDT H. Tschofenig J. Cuellar Siemens J. Polk Cisco October 20, 2003 Policy Rules for Disclosure and Modification of Geographic Information draft-ietf-geopriv-policy-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 19, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes an XML schema for governing the disclosure and transformation of geographic location information. It also describes the goals and the non-goals of the design considerations for the policy rules and the details of the attributes used within the policy rules. Schulzrinne, et al. Expires April 19, 2004 [Page 1] Internet-Draft Geopriv Policy Rules October 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Passive Request-Response - LS as Server (Responder) . . . . 4 1.2 Request-Response - LS as Client (Initiator) . . . . . . . . 4 1.3 Event Notification . . . . . . . . . . . . . . . . . . . . . 4 2. Goals and Assumptions . . . . . . . . . . . . . . . . . . . 6 3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Basic Data Model . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Civil Location . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Rule Transport . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2 SIP Message Body . . . . . . . . . . . . . . . . . . . . . . 11 4.2.3 Location Object . . . . . . . . . . . . . . . . . . . . . . 12 4.3 Securing the Location Object . . . . . . . . . . . . . . . . 12 4.4 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.5 Identification . . . . . . . . . . . . . . . . . . . . . . . 13 4.6 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6.1 Identity of the requestor (URI) . . . . . . . . . . . . . . 14 4.6.2 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6.3 Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.6.4 Civil Location . . . . . . . . . . . . . . . . . . . . . . . 15 4.6.5 Geospatial Location . . . . . . . . . . . . . . . . . . . . 16 4.7 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.8 Procedure for combining Permissions . . . . . . . . . . . . 17 5. Access Control for Policies . . . . . . . . . . . . . . . . 19 6. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1 Subscription Duration . . . . . . . . . . . . . . . . . . . 20 6.2 Confirm Subscription . . . . . . . . . . . . . . . . . . . . 20 7. Transformations . . . . . . . . . . . . . . . . . . . . . . 22 7.1 Set D (Distribute) Flag . . . . . . . . . . . . . . . . . . 22 7.2 Set R (Retention) Time . . . . . . . . . . . . . . . . . . . 22 7.3 Keep Rule (RR) . . . . . . . . . . . . . . . . . . . . . . . 22 7.4 Provide Civil Location . . . . . . . . . . . . . . . . . . . 22 7.5 Provide Geospatial Location . . . . . . . . . . . . . . . . 23 7.6 Provide Timezone Flag . . . . . . . . . . . . . . . . . . . 23 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1 Example for a rule . . . . . . . . . . . . . . . . . . . . . 25 8.2 Permission-combining Example . . . . . . . . . . . . . . . . 26 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . 30 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 31 Normative References . . . . . . . . . . . . . . . . . . . . 34 Informative References . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . 40 Schulzrinne, et al. Expires April 19, 2004 [Page 2] Internet-Draft Geopriv Policy Rules October 2003 1. Introduction Location information needs to be protected against unauthorized access to preserve privacy of the owner of the location information. The GEOPRIV working group has defined a protocol-independent model for access to geographic information. The model includes a location generator (LG) that produces location information, a location server (LS) that authorizes access to location information, a location recipient (LR) that requests and receives information, and a rulemaker (RM) that provides policy rules to the LS which enforce access control policies on access to a target. Two policy rule namespaces have been defined. The first basic rule set [10] can restrict how long the receiver can retain the information and it can prohibit any further distribution of the information. It does not allow to customize information to specific receivers, for example. This document describes an enhanced rule set that provides richer constrains on location objects, including the basic rules in [10]. We refer to any element that uses the rules in this document to restrict the retention or distribution of information as a rule enforcer. Typically, these are LS and LR. This rule set allows the rule enforcer to enforce access restrictions on location data, including prohibiting any dissemination to particular individuals or during particular times. The rule maker can also stipulate that only certain parts of the location object are distributed to recipients or that the resolution of parts of the location object is limited. Below, we describe how different types of using protocols might employ the rules described in this document. We assume that a basic location object [10] can contain a reference to additional rule sets. Note that the protocols used to query location information (between LS and LR), update policies at the location server and the protocol between the LG to LS and from LS to LR do not have to be the same. In all cases, the abstract sequence of operations is similar. The LS receives either a query for location data or receives an update for the location of the target, via the using protocol. The using protocol provides the identity of the requestor, either at the time of the query or subscription to the location information. This verified location recipient identity, together with other information contained in the location information or generally available to the server, is then used to search the rule set. All matching rules are combined according to a merging algorithm described in this document. The resulting rule is applied to the location data, yielding a Schulzrinne, et al. Expires April 19, 2004 [Page 3] Internet-Draft Geopriv Policy Rules October 2003 possibly modified location object that is delivered to the location recipient. A single LS may serve location data in more than one mode. Rather than having different rulesets for different modes, this document takes the approach of supporting all three modes in one ruleset schema. Specific instances of the ruleset can omit elements that are only applicable to the subscription model. The three different modes are explained below. 1.1 Passive Request-Response - LS as Server (Responder) In a passive request-response scenario, the LR queries the LS for location information about the target. Examples of protocols following this mode of operation include HTTP, ftp, LDAP, finger or various RPC protocols, including Sun RPC, DCE, DCOM, Corba and SOAP. The LS uses the rule set to prevent the transmission of information to the LR by refusing the request or to filter the information by removing elements or by reducing the resolution of elements. 1.2 Request-Response - LS as Client (Initiator) Alternatively, the LS may contact the LR and convey the location information, e.g., to obtain some location-specific service. Examples include HTTP, SIP session setup (INVITE request), H.323 session setup or SMTP. 1.3 Event Notification Event notification adds a subscription phase to the "LS as client" mode of operation. A watcher or subscriber asks to be added to the notification list for a particular presentity [cite] or event. When the presentity changes state or the event occurs, the LS sends a message to the LR containing the updated state. (Presence is a special case of event notification; thus, we often use the term interchangeably.) In addition, the subscriber may itself add a filter to the subscription, limiting the rate [cite] or content [cite] of the notifications. If an event, after filtering by the rulemaker-provided rules and by the subscriber-provide rules, only produces the same notification content that was sent previously, no event notification is sent. For SIP, the model is described in more detail in [cite]. Thus, for this model, a policy is needed for both subscription and Schulzrinne, et al. Expires April 19, 2004 [Page 4] Internet-Draft Geopriv Policy Rules October 2003 notification operations. While both can be expressed in separate policy rulesets, it is often helpful to synchronize the two. For example, it allows the location server to indicate to the subscriber what kind of information the subscriber can obtain. A subscriber may decide that the information is too limited to be of use and thus drop the subscription before wasting its own resources or those of the LS. (This does not reveal any additional information since the notification has to indicate the data received.) Schulzrinne, et al. Expires April 19, 2004 [Page 5] Internet-Draft Geopriv Policy Rules October 2003 2. Goals and Assumptions Below, we summarize our design goals and constraints. Table representation: Each rule must be representable as a row in a relational database. This design goal should allow efficient policy rule implementation by utilizing standard database optimization techniques. Permit only: Allowing both 'permit' and 'deny' actions requires some rule ordering which has implications to the update operations executed on these rules. Additionally it makes distributed rule sets more complicated. An advantage is the more efficient rule handling. However, to avoid complex conflict resolution with these rules only 'permit'. This also implies that rule ordering is not important. Consequently, to make achieve a policy decision it is necessary to process all policy rules. Additive permissions: A query of the location recipient is matched against the rules in the rule database. If several rules fire then, the location recipient obtains the permissions of all rules. Upgradeable: It should be possible to add additional rule elements later, without breaking location servers that have not been upgraded. Any such upgrades must not degrade privacy constraints, but may reveal less information than the rulemaker would have chosen. Versioning support: In addition to the previous goal, a rule maker should be able to determine which types of rule elements are supported by the LS. We assume that the number of different versions of rule sets is best kept modest, so that a capability indication rather than an enumeration of fields is sufficient. This capability indication may take the form of indicating support for an XML namespace. Protocol-independent: The rule set supports constraints on both notifications or queries as well as subscriptions for event-based systems such as presence systems. No false assurance: It appears more dangerous to give the user the impression that the system will prevent disclosure automatically, but fail to do so with a significant probability of operator error or misunderstanding, than to force the user to explicitly invoke simpler rules. Among the rules proposed in earlier working group discussion, rules based on weekday and time-of-day ranges seem particularly subject to misinterpretation and false assumptions on part of the rulemaker. (For example, a non-technical rulemaker Schulzrinne, et al. Expires April 19, 2004 [Page 6] Internet-Draft Geopriv Policy Rules October 2003 would probably assume that the rules are based on the timezone of his current location, which may not be known to other components of the system.) Schulzrinne, et al. Expires April 19, 2004 [Page 7] Internet-Draft Geopriv Policy Rules October 2003 3. Non-Goals We explicitly decided that a number of possibly worthwhile capabilities are beyond the scope of this first version. Future versions may include these capabilities, using the extension mechanism described in this document. Non-goals include: No queries: Following the model being pursued for presence information, we do not support the notion of queries where the LR requests only a subset of the information available. This can readily be separated into a separate rule set and has different properties and authentication models. No external references: Attributes within specific rules cannot refer to external rule sets, databases, directories or other network elements. Any such external reference would make simple database implementation impossible and would severely impact the scalability of the LS. External references also add significant failure handling complexity. An LS would have to make decisions on how long or often to attempt, what credentials to use and how to query. Thus, any such queries would have to be constrained to queries expressible as URIs. No regular expression or wildcard matching: Conditions are matched on equality or 'greater-than'-style comparisons, not regular expressions, partial matches such as the SQL LIKE operator (e.g., LIKE "%foo%") or glob-style matches ("*@example.com"). Most of these are better expressed as explicit elements. For example, if it were desired to allow domain matches, the domain of the LR should be identified as a separate condition element. No all-except conditions: It is not possible to express exclusion conditions based on identities such as "everybody except Alice". This is not only a ruleset limitation, but a limitation inherent in many access control systems (such as [8]). Limitations on the identity of this type do not provide rich functionality since it is easy for users such as Alice to acquire a different identity that is not blacklisted. No repeat times: Repeat times are difficult to make work correctly, due to the different time zones that LG, LS and LR may occupy. It appears that suggestions for including time intervals are often based on supporting work/non-work distinctions, which unfortunately are difficult to capture by time alone. Schulzrinne, et al. Expires April 19, 2004 [Page 8] Internet-Draft Geopriv Policy Rules October 2003 4. Basic Data Model A rule set consists of zero or more rules. The ordering of these rules is immaterial. The rule set can be stored in the LS and conveyed from RM to LS as a single document, in subsets or as individual rules. In addition, the LO can carry these rules as a data object, e.g., as multi-part MIME, or reference them via a URI. These alternatives are described in more detail in Section Section 4.2. While the rules are encoding in XML, this is purely an exchange format between RM and LS. Additionally, if rules are attached to the location object then the rules are encoded in XML. The format does not imply that the RM or the LS use this format internally, e.g., in matching a query with the policy rules. The rules are designed so that a LS may translate the rules into a relational database table, with each rule represented by one row in the database. The database representation is by no means mandatory; we will use it as a convenient and widely-understood example of an interna representation. The database model has the advantage that operations on rows have tightly defined meanings. In addition, it appears plausible that larger-scale implementations will employ a backend database to store and query rules, as they can then benefit from existing optimized indexing, access control, scaling and integrity constraint mechanisms. Smaller-scale implementations may well choose different implementations, e.g., a simple traversal of the set of rules. A rule consists of three types of elements (or fields): conditions, transformations and actions. (Some people have also used the term matching rules, matching conditions or constraints for what we term conditions.) One can think of the "conditions" part as the 'if' part of a statement, the transformations and actions as the "then" part of the statement. Since only one type of action i.e. 'permit' is allowed it does not need to be represented. Transforming permissions ask the entity using the rules to modify the location object, e.g., to remove or modify a particular element. Actions cause the location server to take a certain action, such as adding a subscription. 4.1 Civil Location TBD: The description below is only included for concreteness, since a civil location object has not yet been defined and the description does not make sense without. It will migrate to a separate document. This designation offers street-level precision. Schulzrinne, et al. Expires April 19, 2004 [Page 9] Internet-Draft Geopriv Policy Rules October 2003 The civil location elements are as follows: +----------------------+----------------------+---------------------+ | Label | Description | Example | +----------------------+----------------------+---------------------+ | country | The country is | US | | | identified by the | | | | two-letter ISO 3166 | | | | code. | | | | | | | A1 | national | New York | | | subdivisions (state, | | | | region, province, | | | | prefecture) | | | | | | | A2 | county, parish, gun | King's County | | | (JP), district (IN) | | | | | | | A3 | city, township, shi | New York | | | (JP) | | | | | | | A4 | city division, | Manhattan | | | borough, city | | | | district, ward, chou | | | | (JP) | | | | | | | A5 | neighborhood, block | Morningside Heights | | | | | | A6 | street | Broadway | | | | | | PRD | Leading street | N, W | | | direction | | | | | | | POD | Trailing street | SW | | | suffix | | | | | | | STS | Street suffix | Avenue, Platz, | | | | Street | | | | | | HNO | House number, | 123 | | | numeric part only. | | | | | | | HNS | House number suffix | A, 1/2 | | | | | | LMK | Landmark or vanity | Low Library | | | address | | | | | | | LOC | Additional location | Room 543 | Schulzrinne, et al. Expires April 19, 2004 [Page 10] Internet-Draft Geopriv Policy Rules October 2003 | | information | | | | | | | FLR | Floor | 5 | | | | | | NAM | Name (residence, | Joe's Barbershop | | | business or office | | | | occupant) | | | | | | | PC | Postal code | 10027-0401 | +----------------------+----------------------+---------------------+ Table 1 4.2 Rule Transport We make no assumption as to how rules are conveyed to entities within the network. Purely as examples, we below describe a few plausible options. None of the elements depend on the properties of how rule sets are conveyed to an LS or LR. Mechanism may allow partial updates of rule sets. To simplify such partial updates, we include an identifier in each rule. This identifier is only unique among all the rules for a single target. Transaction semantics for policy rule update is not required since 'permit only' and 'additive permissions' properties have to be used (as described in Section 2). These properties also prevent inconsistency during concurrent query and update operations. 4.2.1 HTTP A rule set could be uploaded to the LS via an HTTP POST operation or more fully-featured WEBDAV. Each rule could be modeled as a single 'file', with the rule identifier as a file name. (Since multiple rules may have the LR identity in the condition part of the rule, the LR identity cannot be used.) One example of this approach includes XCAP [6]. The rule set can also be referenced from within a location object. The attribute 'ruleset-reference' specified in Section 2.2.2 of [10] and contains a URI that indicates where a fuller ruleset of policies related to this object can be found. The URI MAY alternatively use the CID URI scheme in which case it MUST denote a MIME body carried with the Location Object by the using protocol. 4.2.2 SIP Message Body The rule set can be carried, as a separate MIME message body, in the Schulzrinne, et al. Expires April 19, 2004 [Page 11] Internet-Draft Geopriv Policy Rules October 2003 SIP message that conveys location information from a LG (a SIP UAC) via an LS (a SIP proxy) to an LR (a SIP UAS). The ruleset would then govern the behavior expected of the LR. 4.2.3 Location Object The ruleset can be carried in location objects in two ways: by reference and by value. In any case the 'ruleset-reference' attribute inside the LO [10] points to to the location of the rules. Instead the LG or LS can include the ruleset itself. One of the transformations of the ruleset is the removal of the ruleset described here before further transmission. Only the whole ruleset can be removed. 4.3 Securing the Location Object The Geopriv requirements draft [2] addresses the minimal security protection required for the Location Object: Mutual end-point authentication, data object integrity, data object confidentiality and replay protection. These security properties are implemented via S/MIME and between elements. Protection for the LO includes any attached authorization rules. Protection is likely to be necessary against adversaries who eavesdrop on the communication between the LS and the LR or the LG and the LS, who tamper with the location object or who replay previously recorded LOs. Securing the communication between rule maker and the LS depends on the protocol which is used to perform the desired actions (e.g., https). The communication between the LG and the LS can also be secured using channel security. If the LO is integrity and confidentiality-protected then the receiving entity (LS or LR) has to be able to decrypt and to verify the LO. Since the policy rules described in this document allow the modification of the LO (via granularity reduction or by setting flags), it is not possible to forward the LO without reapplying the cryptographic protection. This is particularly true for the LS as it is not the final consumer of the LO. When the LS protects the LO for transmission to the LR (after successful authorization), then the authenticated identity can be used to select a security association to apply proper protection of the location object. Securing the LO for multiple LRs is not provided. Instead of encrypting the LO, the LG could digitally sign the LO, Schulzrinne, et al. Expires April 19, 2004 [Page 12] Internet-Draft Geopriv Policy Rules October 2003 offering integrity, but no confidentiality. However, if the LS needs to perform modifications on the LO, then it would have to break the digital signature and may apply its own digital signature. Since the LO is generally distributed to more than one LR, the LG lacks the necessary information about the recipient and thus cannot usually apply confidentially protections. By default, the LS re-signs LOs if the signed LO has been modified according to the rule set. If the LS receives an LO that it cannot decrypt, it discards it if and only if the rule requires modification of the content. It remains for further study whether there should be an action that discards an LO that is signed or encrypted and needs to be modified according to the matching rule set. 4.4 Extensions The format is meant to be extensible. Each new extension needs to define a new namespace for its conditions and actions. A rule-enforcing entity MUST drop any rules where one or more of the elements or actions has an unknown namespace. It SHOULD simply ignore any transformations with unknown elements. This behavior is privacy-safe since it prevents adding any permissions where the rule enforcer would not test for a particular condition. Consider an example: If a condition "Dow Jones Industrial Average" is added and a rule enforcer would ignore this condition, a watcher may obtain additional information even though the stock market condition is not met. Similarly, rules with unknown actions must be dropped since these actions may provide additional privacy protections, such as logging. Omitting transformations is safe, however, since this will only prevent the inclusion of data. 4.5 Identification Each rule has an identifier, using the 'id' parameter of the rule element, which serves the purpose of partial updates as mentioned in Section 4.2. The identifier is an opaque token chosen by the rulemaker. A rule maker MUST NOT use the same identifier for two rules that are available to the LS at the same time for a given target. The combination uniquely identifies a rule. 4.6 Conditions Conditions are identified by the element in a rule. In Schulzrinne, et al. Expires April 19, 2004 [Page 13] Internet-Draft Geopriv Policy Rules October 2003 all cases, conditions elements that are missing or empty are treated as if they contain a NULL value and always match. 4.6.1 Identity of the requestor (URI) Location recipients are identified by URIs and matched by string matching on the element. Matching rules are governed by the URI scheme. For some using protocols, the identity is encoded in the URI. It does not have to be the same identity that the protocol-specific authentication mechanism uses. For example, SIP URIs are sufficient to describe a requestor, but the user name for the SIP Digest authentication may differ from that identifier. (Some domains, for example, only require a name as the user identifier, while other use the full user@host form.) For HTTP, the user name is not encoded in the URI. Thus, we define a new pseudo-URI scheme, http-auth, that carries the user name found in the authentication operation. For example, http-auth:alice@example.com. It is left to the URI scheme and the using protocol to designate an identifier that denotes an 'anonymous user', i.e., a user that has not authenticated themselves. This allows to restrict anonymous access to users of a particular protocol, for example. As an example, SIP can use the anonymous Digest authentication mechanism to grant access to holders of a particular secret. The rule sip:anonymous:myticket@anonymous.invalid would then match a requestor that includes the 'secret' myticket in the password part of the SIP request URI. This requires no special capabilities in the ruleset described here. The definition of pseudonyms is left to each URI scheme and the related using protocol and any domain that it implies. For example, in SIP, a pseudonym might be 'sip:user42@coldmail.example', assuming that coldmail.example offers pseudonym accounts. Anonymous users are treated by omitting this attribute in the rule which causes a 'NULL' value to be created in the ruleset table of a relational database. Any request for a location object (for a given target) would match with respect to this attribute in a rule. 4.6.2 Validity The rule validity period is expressed as a two elements, a starting and ending time. Times are expressed in XML schema dateTime format. Schulzrinne, et al. Expires April 19, 2004 [Page 14] Internet-Draft Geopriv Policy Rules October 2003 An example of a rule fragment is shown below: 2003-08-15T10:20:00.000-05:00 2003-09-15T10:20:00.000-05:00 4.6.3 Sphere The rule matches only if the target is currently in the state indicated. The state may be conveyed by manual configuration of the LS or by some protocol. For example, RPID provides the LG with the ability to inform the LS of its current sphere. The 'sphere' element is an XML schema token. An example of a rule fragment is shown below: work 4.6.4 Civil Location The Civil Location matches if the current civil location of the target matches all elements in the description given in the rule. The civil location match includes a number of fields, including the timezone, the country (expressed as a two-letter ISO 3166 code), and the administrative units of [12] A1 through A6. This designation offers street-level precision. If the civil location of the target is not known, rules that contain a civil location never match. (This case may occur, for example, if location information has been removed by earlier transmitters of location information or if only the geospatial location is known.) If any of the elements through are specified, also MUST to be specified. The schema does not enforce that the specification uniquely identifies a particular location. For example, it would be possible to omit the region and match only on city name, so that any city sharing that name within a country would match. This 'feature' is primarily designed to deal with users that may not know the administrative divisions between country and city level. For example, many users may not know the county for cities in the United States. An example of a civil location condition fragment is shown below: Schulzrinne, et al. Expires April 19, 2004 [Page 15] Internet-Draft Geopriv Policy Rules October 2003 US NJ Bergen Leonia Westview 4.6.5 Geospatial Location The geospatial location conditions make the rule apply if the target is currently located within the area bounded by a set of two longitude (longitude1, longitude2) and two latitude (latitude1, latitude2) values, describing a spherical trapezoid. These four elements define a spherical trapezoid that is characterized as follows: the northern boundary of the spherical trapezoid is on the latitude given by the latitude1 element, and the southern boundary is on the latitude given by the latitude2 element - the western boundary is on the longitude given by the longitude1 element, and the eastern boundary is on the longitude given by the longitude2 element. 4.7 Conditions Conditions are in conjunctive normal form, i.e., all defined elements in the rule have to match the query. It is possible to leave some attributes within a row empty or omit the element altogether; these attributes then assume the default value of NULL. NULL entries always match. Expressed in database terms, queries on the rule set can be modeled as SELECT queries, as in SELECT permission1,permission2, ... FROM ruleset WHERE (condition1='p1' OR condition1 IS NULL) AND (condition2='p2' OR condition2 IS NULL) AND (...) Here, p1, p2, etc. are properties of the querier, time of day or properties of the target, such as its current location. The attributes available for these conditions are described in Section 4.6. After determining the rules which fire for a given query the permissions have to be combined. Combining the permissions is described in Section 7 and leads to a final result which is applied to the location object. Expressed in programming terms, the process of determining a result Schulzrinne, et al. Expires April 19, 2004 [Page 16] Internet-Draft Geopriv Policy Rules October 2003 can be written as (the first part represents the query): for each policy rule in ruleset do { if ((condition1 == 'p1' || condition1 == NULL) && (condition2 == 'p2' || condition2 == NULL) ,.. then { collect permissions and add them to the firing-ruleset } // end if } // end for result = Apply permission-combining algorithm on firering-ruleset Transform location object based on result Conditions can be of four datatypes: a string (e.g. civil location) an integer a date (e.g. validity) Naturally, sets are equivalent from an implementation perspective to integers. In addition to the equality operator, range operators ("is between"), set intersection and inequality operators are also supported. Only one type of operator is defined for each element. 4.8 Procedure for combining Permissions This section describes the procedure for combining permissions in case that multiple rules fire. As indicated in Section 2 permissions are additive i.e. a LR obtains permissions of multiple firing rules. The assumption is made that the attributes are ordered and that the value of one attribute does not depend on the value of another (different) attribute. Combining permissions depends on the following four datatypes: undefined (NULL) an integer or enumeration a boolean (true or false) A query will be matched against all rules and any number of rules might fire. The permissions of all fireing rules are combined Schulzrinne, et al. Expires April 19, 2004 [Page 17] Internet-Draft Geopriv Policy Rules October 2003 according to permission-specific combining rules. The combining rules are simple and depend on the datatype: Boolean: If any boolean row for a transformation is true, the result is true. If all rows are either undefined or false, the result is false. Integer or enumeration: The result is the maximum across all rows. If all rows are 'NULL', the interpretation depends on the permission type. Schulzrinne, et al. Expires April 19, 2004 [Page 18] Internet-Draft Geopriv Policy Rules October 2003 5. Access Control for Policies Each rule set is logically associated with exactly one target; we can consider this target to be another condition column in the rule set. A single rule maker can manage rule sets for a large number of targets, and a location server can be provided with rules for different targets by different rule makers. Access restrictions to the rule set itself are beyond the scope of this document. A complete geo-privacy system would need to specify how a location server can verify the identity and authorization of a rule maker to insert, update or delete a particular rule. A simple mechanism, followed in XCAP Section 2, restricts modifications to the target itself, but third-party authorizations are likely to be useful. Schulzrinne, et al. Expires April 19, 2004 [Page 19] Internet-Draft Geopriv Policy Rules October 2003 6. Actions Actions describe what the recipient of the rule is allowed to do if the rule matches. Note that subscriptions are automatically allowed for any subscriber that matches a ruleset, possibly after confirmation. To refuse a subscription, the rulemaker simply omits the undesirable subscriber from the ruleset. Actions that modify the location object have a default value of NULL. The behavior of NULL actions differs for parts of the LO describing the location and parts of the LO describing usage rules. For the former, only components that are explicitly included through non-NULL actions are kept by the LS. For the usage rules, elements are left unchanged unless a non-NULL action modifies the rule. This approach ensures that extensions in the capabilities of the location server do not suddenly change the behavior of the location server for the same rule set. The behavior is also privacy-preserving, under the assumption that removing location objects can only enhance privacy and that keeping unknown usage rules also does not diminuish privacy. The operations defined in Section 4.8 are also applicable in this context if multiple rules fire. 6.1 Subscription Duration The Subscription Duration action only applies to event-based or presence systems. It indicates the duration, measured in seconds, that the watcher is allowed to subscribe to this event. This action is ignored for queries. The default value is 3600 seconds (one hour). 6.2 Confirm Subscription This action only applies to using protocols that follow a subscription model. If the Confirm Subscription flag is set, the principal whose information is being desired has to approve the subscription. The subscription is marked as 'pending' while the server waits for the presentity to decide. The approval mechanism depends on the using protocol and is beyond the scope of this document. As an example, SIP defines a mechanism where the presentity is notified of the subscription attempt [cite] and then updates the ruleset to either allow or refuse the subscription. It is an error if both the Confirm Subscription and Subscription Schulzrinne, et al. Expires April 19, 2004 [Page 20] Internet-Draft Geopriv Policy Rules October 2003 Duration action are non-null. The default value for this attribute is 'true'. Schulzrinne, et al. Expires April 19, 2004 [Page 21] Internet-Draft Geopriv Policy Rules October 2003 7. Transformations In addition to the transformations below, LS MAY translate and add location information. For example, they may add timezone information based on civil information. All transformations are privacy-safe, i.e., if a transformation is NULL (i.e., if the attribute is not present or empty in a policy rule), the LS removes the corresponding location information from the LO and leaves the LO flags undisturbed. Extensions to this document may define other transformations. 7.1 Set D (Distribute) Flag This transformation sets the D flag in the location object to either 'true' or 'false'. A value of 'true' means the recipient of the LO is allowed to further distribute it. A value of 'false' prevents further distribution. The value NULL keeps the D flag in the LO as is. 7.2 Set R (Retention) Time The retention transformation sets the retention value in the location object to the current time plus the time provided in the element, measured in seconds. The value NULL keeps the retention time in the LO as is. 7.3 Keep Rule (RR) If the Keep Rule (RR) flag is set, any extended rules included in the location object are kept. 7.4 Provide Civil Location The Provide Civil Location transformation restricts the civil location to one of six levels, from lowest to highest: null, country, region, city, building, full. Each level includes all elements included by the lower levels. The 'country' level includes only the element; the 'region' level adds the element; the 'city' level adds the and elements; the 'building' level and the 'full' level add further civil location data as shown below. If this action is NULL, all civil information is removed from the LO. Schulzrinne, et al. Expires April 19, 2004 [Page 22] Internet-Draft Geopriv Policy Rules October 2003 The lattice for this attribute has the following shape: Full {, , , , , , , , , , , , , , , , , } | Building {, , , , , , , , , , , , , , } | City {, , } | Region {, } | Country {} | 'NULL' {} 7.5 Provide Geospatial Location The Provide Geospatial Location transformation restricts the resolution of the geospatial location information to the number of bits provided, separately for longitude and latitude. The default value is zero. For purposes of this transformation, longitude and latitude are treated as a 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. Altitude is treated as a fixed-point 22-bit integer part with a 8-bit fraction, measured in meters. This corresponds to the representation in [7], but does not constrain the representation in the location object. If the transformation value is NULL, all geospatial location information is removed from the LO. 7.6 Provide Timezone Flag The Provide Timezone transformation includes the timezone of the target, i.e., the offset from UTC. The value of 'false' causes timezone information to be excluded from the LO. Schulzrinne, et al. Expires April 19, 2004 [Page 23] Internet-Draft Geopriv Policy Rules October 2003 If the transformation value is NULL, all timezone information is removed from the LO. Schulzrinne, et al. Expires April 19, 2004 [Page 24] Internet-Draft Geopriv Policy Rules October 2003 8. Example This section lists some basic examples to show the functionality. 8.1 Example for a rule This example rule illustrates a ruleset with a single rule. The rule consists of three parts: an part which represents the conditions, an part and a part. The conditions match to a location requestor named alice@example.com. The rule is valid for one month (2003-08-15 to 2003-09-15). Requests only match if the target has set its sphere identifier to "work" and it is currently located at the indicated civil location. The indicate that the granularity of the location information is reduced for both civil and for geospatial location information. The D flag is set to 'true' and the rules included in the LO are kept. pres:alice@example.com 2003-08-15T10:20:00.000-05:00 2003-09-15T10:20:00.000-05:00 work US NJ Bergen Leonia Westview 1800 true region 10 true true 9 9 6 Schulzrinne, et al. Expires April 19, 2004 [Page 25] Internet-Draft Geopriv Policy Rules October 2003 8.2 Permission-combining Example TBD: Example should go in here. Schulzrinne, et al. Expires April 19, 2004 [Page 26] Internet-Draft Geopriv Policy Rules October 2003 9. XML Schema This section describes an XML schema for the authorization policies described in the previous sections. It does not extend other schemas. It is a preliminary version primarily to show the simplicity of the policies. In [5] the XML schema in the XCAP Usages for Setting Presence Authorization draft [4] to have a better alignment with policies used in SIP presence. It is expected that future versions of [4] will experience some changes. We do not abandon either one of the approaches. Schulzrinne, et al. Expires April 19, 2004 [Page 27] Internet-Draft Geopriv Policy Rules October 2003 Schulzrinne, et al. Expires April 19, 2004 [Page 28] Internet-Draft Geopriv Policy Rules October 2003 Schulzrinne, et al. Expires April 19, 2004 [Page 29] Internet-Draft Geopriv Policy Rules October 2003 10. Security Considerations This document aims to make it simple for users to prevent the unintended disclosure of private information to third parties. The described policies accomplish this task. Threats applicable to this draft are described in [3] and requirements are addressed in [2]. Section 4.3 addresses issues of protecting the policy rules within the LO and location information itself. Aspects of privacy-safe combining permissions is illustrated in Section 7. Schulzrinne, et al. Expires April 19, 2004 [Page 30] Internet-Draft Geopriv Policy Rules October 2003 11. Open Issues Some open issues have been identified during the process of working on this draft: Transformation: A default behavior for transformation attributes (see Section 7) has to be defined to indicate what behavior has to be assumed for omitted values (i.e. for values how appear as 'NULL' values in an attribute of row. Currently it seems that it is not sufficient to specify a single default behavior rule for all transformation attributes in order for them to be privacy-safe. Instead at least a differentiation between Attributes whose removal may lessen privacy (the R/D/microwave flags) and Attributes whose removal can only increase privacy (location objects). Extensions: More text needs to be provided on how to deal with extensions and version conflicts. Logging: Functionality for triggering logging has been started with [14] and continued in [5]. For this draft it was decided not to provide encryption and logging functionality as part of the policy rules. For logging a simple mechanism would be to just have this be a binary flag. It is then up to the LS to decide where to log this and how. One problem with logging is that it does not apply if the rule set is included in the LO. Asking the LR to log the information is meaningless in most cases since the target/RM would not be able to access this information. While logging seems simple, it also causes interactions with the retention mechanism. If someone sends a LO that says "do no retain" and "log", you have a problem. Additionally, you may want to specify exactly what gets logged: Just the fact that user A got location information at a certain time? The precise location information he did get, after filtering? Just the fact that location information was distributed to some set of users, which you can derive by looking at the rule set? Finally, logging would be done in general for each target, not just for one recipient. Hence there is a question why it should be done based on one particular rule. Encryption: For encryption similar concerns are applicable as for logging. It needs to be decided whether encryption should be handled on a per-rule basis and whether a single flag would be sufficient. Some further issues deserve attention such as: Schulzrinne, et al. Expires April 19, 2004 [Page 31] Internet-Draft Geopriv Policy Rules October 2003 What happens if the public key is not known for the recipient? What encryption technique should I use? Should an identity be provided within the rule? What happens if this identity specifies a SIPS URI (i.e., requiring that the request be via SIP-over-TLS) and the flag is not set, should it be refused? If encryption is specified and the request was HTTP (not HTTPS), should the request be refused? Identities: A number of issues have been discussed with regard to identities of the LR (specified in the URI attribute). Authentication Types: Element E (Permission to disclose only to someone presenting a specified key) of [14] was implemented in [5] as authentication levels (see Section 2.1 in ). [4] specifies the elements and inside the acceptance permission which allows to refer to SIP specific authentication mechanisms such as None, TLS, Digest, SMIME and P-Asserted-ID. For this draft is was decided to omit these attributes since they might be difficult to understand for end users, difficult to realize since authentication levels are not universally defined and in case of specific authentication mechanisms it is difficult to imply the meaning for Geopriv. Notifications: A concept which appears to be simple is to require notice to the rule maker if location is provided (Element K of [14]. The concept of 'notice' might be meaningless without saying how. Currently there is no such mechanism define in Geopriv and therefore there are no parameters which might be needed for this operation.There are certainly many possible protocols on how to notify the RM, including event notification (using SIP, Jabber, SOAP events, etc.), email, some kind of RPC mechanism, an HTTP request to a specific address, syslog. Currently we think that this issues deserves further discussion. Permission-Combining Example: An example describing the permission-combining algorithm has to be provided for Section 8. Working on this example the concept of a 'default' rule was discussed. The term default rule refers to a rule where the condition elements are all set to 'NULL'. This rule will fire with every query. Schulzrinne, et al. Expires April 19, 2004 [Page 32] Internet-Draft Geopriv Policy Rules October 2003 Lying: Functionality for lying by the LS is not supported. A number of other minor issues are still buried in the drafts [5], [14] and in [4]. Schulzrinne, et al. Expires April 19, 2004 [Page 33] Internet-Draft Geopriv Policy Rules October 2003 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, "Geopriv requirements", draft-ietf-geopriv-reqs-03 (work in progress), March 2003. [3] Morris, J., Danley, M. and J. Peterson, "Threat Analysis of the geopriv Protocol", draft-ietf-geopriv-threat-analysis-01 (work in progress), September 2003. Schulzrinne, et al. Expires April 19, 2004 [Page 34] Internet-Draft Geopriv Policy Rules October 2003 Informative References [4] Rosenberg, J., "Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usages for Setting Presence Authorization", draft-ietf-simple-xcap-auth-usage-00 (work in progress), June 2003. [5] Tschofenig, H., Morris, J., Cuellar, J., Polk, J. and H. Schulzrinne, "Location Object Authorization Policies", draft-tschofenig-geopriv-authz-00 (work in progress), August 2003. [6] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-00 (work in progress), June 2003. [7] Polk, J., Schnizlein, J. and M. Linsner, "DHC Location Object within GEOPRIV", draft-ietf-geopriv-dhcp-lo-option-00 (work in progress), January 2003. [8] Gong, L., "Inside Java 2 Platform Security", Addison Wesley, Reading, Massachusetts Addison Wesley, Reading, Massachusetts, June 1999. [9] Mealling, M., "The IETF XML Registry", draft-mealling-iana-xmlns-registry-05 (work in progress), June 2003. [10] Peterson, J., "A Presence-based GEOPRIV Location Object Format", DRAFT draft-peterson-geopriv-pidf-lo-01, September 2003. [11] Schulzrinne, H., "RPID - Rich Presence Information Data Format", draft-ietf-simple-rpid-00 (work in progress), July 2003. [12] Schulzrinne, H., "DHCP Option for Civil Location", draft-ietf-geopriv-dhcp-civil-00 (work in progress), July 2003. [13] Sugano, H. and S. Fujimoto, "Presence Information Data Format (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. [14] Morris, J., Mulligan, D. and J. Cuellar, "Core Privacy Protections for Geopriv Location Object", draft-morris-geopriv-core-02 (work in progress), July 2003. Schulzrinne, et al. Expires April 19, 2004 [Page 35] Internet-Draft Geopriv Policy Rules October 2003 Authors' Addresses Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7042 EMail: hgs+geopriv@cs.columbia.edu URI: http://www.cs.columbia.edu John B. Morris, Jr. Center for Democracy and Technology 1634 I Street NW, Suite 1100 Washington, DC 20006 US EMail: jmorris@cdt.org URI: http://www.cdt.org Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Jorge.Cuellar@siemens.com URI: http://www.cdt.org Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Jorge.Cuellar@siemens.com URI: http://www.cdt.org Schulzrinne, et al. Expires April 19, 2004 [Page 36] Internet-Draft Geopriv Policy Rules October 2003 James Polk Cisco 2200 East President George Bush Turnpike Richardson, Texas 75082 US EMail: jmpolk@cisco.com Schulzrinne, et al. Expires April 19, 2004 [Page 37] Internet-Draft Geopriv Policy Rules October 2003 Appendix A. Contributors Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054-2711 USA Email: jdrosen@dynamicsoft.com Schulzrinne, et al. Expires April 19, 2004 [Page 38] Internet-Draft Geopriv Policy Rules October 2003 Appendix B. Acknowledgments This document is based on the discussions within the IETF GEOPRIV working group. Discussions at the Geopriv Interim Meeting 2003 in Washington, D.C. helped the working group to make progress on the authorization policies based on the discussions among the participants. We would to particularly thank Jon Peterson for his helpful comments. Additionally, we would like to thank Christian Guenther for his work on the XML schema. Schulzrinne, et al. Expires April 19, 2004 [Page 39] Internet-Draft Geopriv Policy Rules October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Schulzrinne, et al. Expires April 19, 2004 [Page 40] Internet-Draft Geopriv Policy Rules October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schulzrinne, et al. Expires April 19, 2004 [Page 41]