Internet Engineering Task Force Geopriv Internet Draft H. Tschofenig J. Cuellar Siemens Document: draft-tschofenig-geopriv-authz-policies-00.txt Expires: December 2003 June 2003 Geopriv Authorization Policies Status of this Memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes authorization policies for usage with Geopriv. It suggests using the eXtensible Access Control Markup Language (XACML). XACML provides functionality required to express policies for access to location information. Tschofenig, Cuellar Expires - December 2003 [Page 1] Geopriv Authorization Policies June 2003 Table of Contents 1. Introduction..................................................2 2. Terminology...................................................3 3. The Process of Access Control.................................3 4. Features provided by XACML....................................6 4.1 Basic functionality of XACML..............................6 4.2 Combining Algorithms......................................7 4.3 Operators.................................................8 5. Examples......................................................9 5.1 Request Context Example 1.................................9 5.2 Policy Example 1.........................................10 5.3 Reponse Context Example 1................................12 6. Security Considerations......................................12 7. Open Issues..................................................13 8. Acknowledgments..............................................13 9. References...................................................13 Author's Addresses..............................................15 1. Introduction Geopriv provides Location Information in a secure and private way. A critical role is played by user-controlled Privacy Rules, which describe the restrictions imposed or permissions given by the Rule Maker. The Privacy Rules specify the necessary conditions that allow a Location Server to forward Location Information to a Location Recipient, and the conditions under which and purposes for which the Location Information can be used. One type of Privacy Rules specify in particular how location information should be filtered, depending on who the recipient is. Filtering is the process of reducing the precision or resolution of the data. A typical rule may be of the form: "my location can only be disclosed to the owner of such credentials in such precision or resolution" (e.g., "my co-workers can be told the city I am currently in"). The Location Object should be able to carry a limited but core set of Privacy Rules. The access to location information (as XML objects) can be controlled by XACML policies. The same is true for writing and deleting Geopriv rules themselves. The Geopriv working group can benefit from reusing existing work on access control. This document therefore aims to provide the following description: Tschofenig, Cuellar Expires - December 2003 [Page 2] Geopriv Authorization Policies June 2003 a) It introduces the reader to XACML and describes some of the relevant features. b) It explores how access control is accomplished in the Geopriv environment. c) It gives examples of access control policies. 2. Terminology This draft uses terminology described in [CM+03] and in [XACML]. 3. The Process of Access Control Figure 1 gives an abstract overview of the interaction between the participating entities. Different actions are performed by different entities requesting access to different information items stored at the location server. The location server needs to store information about users, group of users (including pseudonyms and roles). These entities are subject to authorization (among other attributes). The request from an entity to the Policy Decision Point, which is in this case the location server, is carried over a Geopriv 'using protocol'. A number of protocols might serve as a using protocol such as the Presence protocol as described in [Pet03]. Recently J. Rosenberg published the XML Configuration Access Protocol (XCAP) [XCAP] which describes how to read, write and delete application configuration data stored in XML format. XCAP can also be used to manipulate XML based location information (see [CG03]) and it is therefore another building block on the way to complete the work on the Geopriv framework. Instantiation of XCAP for usage with SIP in the area of presence (e.g. modification of buddy lists) can be found in [Ros03a] and in [Ros03b]. XCAP, however, does not describe how to control access to perform certain operations on these documents in a sophisticated fashion. This draft adds this missing piece. After the request reaches the location server it is necessary to compare the request with a number of policies deciding whether the operation is permitted or denied. More information on this step is given with the description of Figure 2 This verification requires matching a request with a number of rules and some sort of conflict resolution. For combining algorithms provided by XACML, the details of conflict resolution are given in Section 4.2. Access control policies for location information demand a flexible language to express the different needs such as: Tschofenig, Cuellar Expires - December 2003 [Page 3] Geopriv Authorization Policies June 2003 - My boss should be granted access to my location (civil location, building and room number only) only during working hours. My family is always allowed to access my exact location. - My students are allowed to access my location during the week if they are in possession of an authorization token. Furthermore it is necessary to specify policies even for access to the policies itself. (But this MAY be out of scope of the Geopriv WG). Finally, it must be possible to cope with information stored in XML format. +-------------+ | | +---------------------------+ | | | | | Rule | Rule Interface | Location Server | | Holder +-------------------->+ | | | | Various Databases | | | | +-----------------------+ | +-------------+ | | | | | | User/Group Info | | +-------------+ | | | | | | | +-----------------------+ | | | | +-----------------------+ | | Location | Location | | Access Control | | | Recipient +<------------------->+ | Policies | | | | requests/responses | | | | | | | +-----------------------+ | +-------------+ | +-----------------------+ | | | | | +-------------+ | | Location Information | | | | | | of different users | | | Location | Location info | +-----------------------+ | | Generator +<------------------->+ | | | | | +-------------+ +---------------------------+ Figure 1: Interaction between the participating Entities Access control policies require a number of input parameters to compute the authorization decision. Some of these input parameters can be obtained from the request itself (i.e. from domain-specific input). To be accessible to the policy engine (as described in the policy rules) it is convenient to have the context request defined in an XACML schema. Based on Figure 2 of [XACML] the relationship to Geopriv is drawn. Tschofenig, Cuellar Expires - December 2003 [Page 4] Geopriv Authorization Policies June 2003 +------------------------------------------+ | Covered by XACML specification | | | | +--------------+ | | | XACML Policy | | | +--------------+ | | ^ | | | | domain- | v | domain- specific | +-------+ +---------------+ +--------+ | specific input | |XACML | |Access Control | |XACML | | output =============>|Context|=>|Engine at the |=>|Context |============> | |Request| |Location Server| |Response| | | +-------+ +---------------+ +--------+ | | | | | | | | | +------------------------------------------+ Figure 2: XACML Context The access control engine evaluates incoming requests from specific subjects with specific actions (read, write, delete) for certain objects. For Geopriv some of these objects are location information "documents", as for example defined, in [CG03]. Location information is stored in XML documents. As shown in Figure 2 a native request is mapped into an XML request (following a XACML schema) which allows the access control engine and the policies to refer to certain items of the request. The XACML Context Request identifies, for example, which elements the subject wants to read. It provides information about the requesting entity such as role, subject identity, information about the security protocols used to authenticate, which credentials have been used, etc. The Geopriv group might want to evaluate which information items are typically associated with a request to re-evaluate the XACL Context schema definition. Note that attributes might appear in different envelopes such as X.509 attribute certificates or as Security Assertion Markup Language (SAML) assertions [SAML]. SAML allows distributing security information. Thereby the security information is expressed as assertions about subjects. These assertions carry information about authentication acts, attributes and authorization decisions. Conversion between the native format and the XACML context might be specified with the help of the Extensible Stylesheet Language Transformation [XSLT]. Tschofenig, Cuellar Expires - December 2003 [Page 5] Geopriv Authorization Policies June 2003 4. Features provided by XACML This section describes some of the features which make it an attractive access control markup language for Geopriv policies. Implementing a new access control markup language solely for Geopriv without reusing existing systems requires recreating the same functions and concepts. It seems that the solution space for standardized languages is actually fairly small when designing a flexible access control mechanism for XML based documents. 4.1 Basic functionality of XACML Three top-level elements are defined in XACML [XACML]: , and The policy language model is defined in [XACML], Section 3.3 (see also Figure 3 there). A contains a Boolean expression and consists of the following components: - Target - Effect and - Condition The rule target defines a set of resources, subjects and actions to which the rule applies. The rule itself forms the basic building block for a Policy. The rule target consists of - Resources - Subjects and - Actions Subjects and resources might be internally structured. This allows referencing them via an XPath [XPath] or XPointer [XPointer] reference. Referring to resources could imply to - refer to the content of the identified node itself - refer to the content of the identified node and its immediate child nodes or - refer to the content of the identified node and all its descendant nodes. It is therefore also possible to base the authorization decision on data contained in the resource to which access requested. The effect describes the intended consequence of a "true" evaluation. Two values are defined "permit" and "deny". Tschofenig, Cuellar Expires - December 2003 [Page 6] Geopriv Authorization Policies June 2003 The condition furthermore allows refining the applicability of a rule. This element is optional. Rules themselves are not exchanged between entities. Therefore are always embedded into a . A consists of - a target - a rule-combining algorithm id - a set of rules and - obligations. elements might additionally attach to an information resource itself. One application would be to attach the policy itself to Geopriv location object. Obligations allow to enforce certain actions that must be performed either instead or in addition to the actions that may be performed. This functionality simulates the idea of a provisional action as described in [Kudo00]. Provisions are attached to the access decision. An example for such an access decision might be a logging action or the encryption of the objects returned in response. A again allows combining set of Policies together with the following elements: - a target - a policy-combining algorithm id - obligations. 4.2 Combining Algorithms The rule-combining algorithm identifier is used to implement conflict resolution (i.e. a mechanism for achieving a final authorization decision after evaluating individual rules) with the following standard algorithms: * Deny-overrides * Permit-overrides * First applicable and * Only-one-applicable The policy-combining algorithm identifier enforces the same concept as the rule-combining algorithm identifier but at a policy and not a rule level. Tschofenig, Cuellar Expires - December 2003 [Page 7] Geopriv Authorization Policies June 2003 An example: The permit-overrides algorithm causes a "permit" evaluation if a single rule (or policy) in the applicable policy is found with a "permit" evaluation, regardless of other rules or policies in the applicable policy. New rule-combining algorithms (or policy-combining algorithms) can be specified, if necessary. 4.3 Operators In order to compute an authorization decision it is necessary to perform operations on attributes of subjects and resources. XACML defines a number of operators: - Operators on numerical data types Examples: integer-add, double-add, integer-subtract, integer- multiply, double-mod, integer-divide, round, floor, integer-abs, double-to-integer, etc. Additionally arithmetic comparison functions are defined such as integer-less-than, double-greater-than-or-equal, etc. Various non-numeric comparison functions also exist such as string- greater-than, string-less-than, time-less-than, date-greater-than, etc. - Operators on date, time and duration data types Examples: dateTime-subtract-yearMonthDuration, dateTime-add- dayTimeDuration, date-subtract-yearMonthDuration - Operators on Boolean data types Examples: and, or, not, n-of These operators allow specifying logical combination of predicates of a rule. - Operators on sets Examples: type-bag-size, type-is-in, type-intersection, type-union, type-subset, type-set-equals, any-of, all-of, any-of-any, map, etc. - Relationship operators Examples: Equality and comparison on RFC 822 and X.500 name forms, strings, URIs, etc. (string-equal, Boolean-equal, integer-equal, date-equal, time-equal, X500Name-eqal, rfc822Name-equal, anyURI- equal, etc.) Tschofenig, Cuellar Expires - December 2003 [Page 8] Geopriv Authorization Policies June 2003 Additionally it is possible to add non-standard functions. 5. Examples This section shows some examples for the XACML policies. For this version of the draft some very basic examples are provided. Currently the examples are very much aligned to the examples in Section 4 of [XACML]. Comments are inserted into the XML code within "". 5.1 Request Context Example 1 The request in XACML for the first example might be stated as follows: "Jorge Cuellar wants to know (i.e. read) the location of Hannes Tschofenig. Jorge Cuellar is identified with an RFC 822 type of email address (for example obtained during the SIP authentication procedure)". This request therefore translates to the following XACML request context: Jorge.Cuellar@siemens.com Tschofenig, Cuellar Expires - December 2003 [Page 9] Geopriv Authorization Policies June 2003 /geopriv/HannesTschofenig@siemens.com read 5.2 Policy Example 1 The request described in Section 5.1 is then matched against a policy at the location server. This policy might, for example, be provided by the owner of the location itself. Tschofenig, Cuellar Expires - December 2003 [Page 10] Geopriv Authorization Policies June 2003 Simple Geopriv policy. Every subject with an identifier in the siemens.com domain is allowed to read the location. siemens.com Tschofenig, Cuellar Expires - December 2003 [Page 11] Geopriv Authorization Policies June 2003 read 5.3 Reponse Context Example 1 The following XML text might represent a possible reponse context to the request described in this example. NotApplicable 6. Security Considerations Tschofenig, Cuellar Expires - December 2003 [Page 12] Geopriv Authorization Policies June 2003 Refer to the threats doc here [DM+03]. There may be also some additional threats to the xacml solution. 7. Open Issues This draft is a first discussion starter. As such it creates a number of open issues, such as: - What attributes are useful for location requests? What information should typically serve as input to the authorization engine? - As soon as the work on the location object makes progress it is necessary to describe how to access the attributes of the location object. - More sophisticated Geopriv example policies have to be added to test the adequacy of the capabilities of XACML. - Some data might not be available in form of a XML document - the data might be computed on the fly (e.g. location information at a different granularity). Another approach is to have all information already available and to access as any other data item. Some discussions might be required to determine the best approach possible. - How to structure access to location object information of different entities? As mentioned in [XCAP] it is necessary to define a schema for data used by a number of entities. One possible approach is to access individual data items with the help of URIs. In any case a naming convention for access to items of the location objects and other information items has to be created. 8. Acknowledgments We would like to thank Christian Guenther for his input to this version of the draft. This entire draft heavily borrows from the XACML [XACML] specification. We would like to thank the authors of the [XACML] specification for their excellent work. 9. References [Kudo00] M. Kudo and S. Hada: "XML document security based on provisional authorization", in: "Proceedings of the Seventh ACM Tschofenig, Cuellar Expires - December 2003 [Page 13] Geopriv Authorization Policies June 2003 Conference on Computer and Communications Security", Nov. 2000, Athens, Greece, pp. 87-96. [XPath] XML Path Language (XPath), Version 1.0, W3C Recommendation, 16 November 1999, Available at: http://www.w3.org/TR/xpath. [XPointer] XML Pointer Language (XPointer), Version 1.0, W3C Candidate Recommendation, 11 September 2001, Available at: http://www.w3.org/TR/2001/CR-xptr-20010911. [XSLT] XSL Transformations (XLT) Version 1.0, W3C Recommendation, 16 November 1999, Available at: http://www.w3.org/TR/xslt. [XACML] The OASIS eXtensible Access Control Markup Language (XACML), OASIS Standard, Version 1.0, 18 February, 2003, Available at: http://www.oasis-open.org/committees/xacml. [SAML] Security Assertion Markup Language, Available at: http://www.oasis-open.org/committees/security/#documents. [Pet03] J. Peterson: "A Presence Architecture for the Distribution of Geopriv Location Objects", Internet Draft, Internet Engineering Task Force, (work in progress), February 2003. [CG03] J. Cuellar and C. Guenther: "Geopriv Location Object Markup Language", Internet Draft, Internet Engineering Task Force, (work in progress), June 2003. [CM+03] J. Cuellar, J. Morris, D. Mulligan, J. Peterson and J. Polk: "Geopriv requirements", Internet Draft, Internet Engineering Task Force, (work in progress), March 2003. [DM+03] M. Danley, D. Mulligan, J. Morris and J. Peterson: "Threat Analysis of the Geopriv Protocol", Internet Draft, Internet Engineering Task Force, (work in progress), February 2003. [XCAP] J. Rosenberg: "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", Internet Draft, Internet Engineering Task Force, (work in progress), May 2003. [Ros03a] J. Rosenberg: "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Presence Lists", Internet Draft, Internet Engineering Task Force, (work in progress), May 2003. [Ros03b] J. Rosenberg: "A Session Initiation Protocol (SIP) Event Package for Modification Events for the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Managed Documents", Tschofenig, Cuellar Expires - December 2003 [Page 14] Geopriv Authorization Policies June 2003 Internet Draft, Internet Engineering Task Force, (work in progress), May 2003. Author's Addresses Hannes Tschofenig Siemens AG Corporate Technology CT IC 3 Otto-Hahn-Ring 6 81739 Munich Germany EMail: Hannes.Tschofenig@siemens.com Jorge R Cuellar Siemens AG Corporate Technology CT IC 3 81730 Munich Germany EMail: Jorge.Cuellar@siemens.com 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. Tschofenig, Cuellar Expires - December 2003 [Page 15] Geopriv Authorization Policies June 2003 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Tschofenig, Cuellar Expires - December 2003 [Page 16]