idnits 2.17.00 (12 Aug 2021) /tmp/idnits17125/draft-tschofenig-geopriv-authz-policies-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 144: '...self. (But this MAY be out of scope o...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 6908 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Kudo00' -- Possible downref: Non-RFC (?) normative reference: ref. 'XPath' -- Possible downref: Non-RFC (?) normative reference: ref. 'XPointer' -- Possible downref: Non-RFC (?) normative reference: ref. 'XSLT' -- Possible downref: Non-RFC (?) normative reference: ref. 'XACML' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAML' -- Possible downref: Non-RFC (?) normative reference: ref. 'Pet03' -- Possible downref: Non-RFC (?) normative reference: ref. 'CG03' -- Possible downref: Non-RFC (?) normative reference: ref. 'XCAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ros03a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ros03b' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Geopriv 3 Internet Draft H. Tschofenig 4 J. Cuellar 5 Siemens 6 Document: 7 draft-tschofenig-geopriv-authz-policies-00.txt 8 Expires: December 2003 June 2003 10 Geopriv Authorization Policies 11 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document describes authorization policies for usage with 37 Geopriv. It suggests using the eXtensible Access Control Markup 38 Language (XACML). XACML provides functionality required to express 39 policies for access to location information. 41 Table of Contents 43 1. Introduction..................................................2 44 2. Terminology...................................................3 45 3. The Process of Access Control.................................3 46 4. Features provided by XACML....................................6 47 4.1 Basic functionality of XACML..............................6 48 4.2 Combining Algorithms......................................7 49 4.3 Operators.................................................8 50 5. Examples......................................................9 51 5.1 Request Context Example 1.................................9 52 5.2 Policy Example 1.........................................10 53 5.3 Reponse Context Example 1................................12 54 6. Security Considerations......................................12 55 7. Open Issues..................................................13 56 8. Acknowledgments..............................................13 57 9. References...................................................13 58 Author's Addresses..............................................15 60 1. Introduction 62 Geopriv provides Location Information in a secure and private way. 64 A critical role is played by user-controlled Privacy Rules, which 65 describe the restrictions imposed or permissions given by the Rule 66 Maker. The Privacy Rules specify the necessary conditions that 67 allow a Location Server to forward Location Information to a 68 Location Recipient, and the conditions under which and purposes for 69 which the Location Information can be used. 71 One type of Privacy Rules specify in particular how location 72 information should be filtered, depending on who the recipient is. 73 Filtering is the process of reducing the precision or resolution of 74 the data. A typical rule may be of the form: "my location can only 75 be disclosed to the owner of such credentials in such precision or 76 resolution" (e.g., "my co-workers can be told the city I am 77 currently in"). 79 The Location Object should be able to carry a limited but core set 80 of Privacy Rules. 82 The access to location information (as XML objects) can be 83 controlled by XACML policies. The same is true for writing and 84 deleting Geopriv rules themselves. The Geopriv working group can 85 benefit from reusing existing work on access control. 87 This document therefore aims to provide the following description: 89 a) It introduces the reader to XACML and describes some of the 90 relevant features. 92 b) It explores how access control is accomplished in the Geopriv 93 environment. 95 c) It gives examples of access control policies. 97 2. Terminology 99 This draft uses terminology described in [CM+03] and in [XACML]. 101 3. The Process of Access Control 103 Figure 1 gives an abstract overview of the interaction between the 104 participating entities. Different actions are performed by different 105 entities requesting access to different information items stored at 106 the location server. The location server needs to store information 107 about users, group of users (including pseudonyms and roles). These 108 entities are subject to authorization (among other attributes). 110 The request from an entity to the Policy Decision Point, which is in 111 this case the location server, is carried over a Geopriv 'using 112 protocol'. A number of protocols might serve as a using protocol 113 such as the Presence protocol as described in [Pet03]. Recently J. 114 Rosenberg published the XML Configuration Access Protocol (XCAP) 115 [XCAP] which describes how to read, write and delete application 116 configuration data stored in XML format. XCAP can also be used to 117 manipulate XML based location information (see [CG03]) and it is 118 therefore another building block on the way to complete the work on 119 the Geopriv framework. Instantiation of XCAP for usage with SIP in 120 the area of presence (e.g. modification of buddy lists) can be found 121 in [Ros03a] and in [Ros03b]. XCAP, however, does not describe how to 122 control access to perform certain operations on these documents in a 123 sophisticated fashion. This draft adds this missing piece. 125 After the request reaches the location server it is necessary to 126 compare the request with a number of policies deciding whether the 127 operation is permitted or denied. More information on this step is 128 given with the description of Figure 2 This verification requires 129 matching a request with a number of rules and some sort of conflict 130 resolution. For combining algorithms provided by XACML, the details 131 of conflict resolution are given in Section 4.2. 133 Access control policies for location information demand a flexible 134 language to express the different needs such as: 136 - My boss should be granted access to my location (civil location, 137 building and room number only) only during working hours. My family 138 is always allowed to access my exact location. 140 - My students are allowed to access my location during the week if 141 they are in possession of an authorization token. 143 Furthermore it is necessary to specify policies even for access to 144 the policies itself. (But this MAY be out of scope of the Geopriv 145 WG). 147 Finally, it must be possible to cope with information stored in XML 148 format. 150 +-------------+ 151 | | +---------------------------+ 152 | | | | 153 | Rule | Rule Interface | Location Server | 154 | Holder +-------------------->+ | 155 | | | Various Databases | 156 | | | +-----------------------+ | 157 +-------------+ | | | | 158 | | User/Group Info | | 159 +-------------+ | | | | 160 | | | +-----------------------+ | 161 | | | +-----------------------+ | 162 | Location | Location | | Access Control | | 163 | Recipient +<------------------->+ | Policies | | 164 | | requests/responses | | | | 165 | | | +-----------------------+ | 166 +-------------+ | +-----------------------+ | 167 | | | | 168 +-------------+ | | Location Information | | 169 | | | | of different users | | 170 | Location | Location info | +-----------------------+ | 171 | Generator +<------------------->+ | 172 | | | | 173 +-------------+ +---------------------------+ 175 Figure 1: Interaction between the participating Entities 177 Access control policies require a number of input parameters to 178 compute the authorization decision. Some of these input parameters 179 can be obtained from the request itself (i.e. from domain-specific 180 input). To be accessible to the policy engine (as described in the 181 policy rules) it is convenient to have the context request defined 182 in an XACML schema. 184 Based on Figure 2 of [XACML] the relationship to Geopriv is drawn. 186 +------------------------------------------+ 187 | Covered by XACML specification | 188 | | 189 | +--------------+ | 190 | | XACML Policy | | 191 | +--------------+ | 192 | ^ | 193 | | | 194 domain- | v | domain- 195 specific | +-------+ +---------------+ +--------+ | specific 196 input | |XACML | |Access Control | |XACML | | output 197 =============>|Context|=>|Engine at the |=>|Context |============> 198 | |Request| |Location Server| |Response| | 199 | +-------+ +---------------+ +--------+ | 200 | | 201 | | 202 | | 203 | | 204 +------------------------------------------+ 206 Figure 2: XACML Context 208 The access control engine evaluates incoming requests from specific 209 subjects with specific actions (read, write, delete) for certain 210 objects. For Geopriv some of these objects are location information 211 "documents", as for example defined, in [CG03]. Location information 212 is stored in XML documents. 214 As shown in Figure 2 a native request is mapped into an XML request 215 (following a XACML schema) which allows the access control engine 216 and the policies to refer to certain items of the request. The XACML 217 Context Request identifies, for example, which elements the subject 218 wants to read. It provides information about the requesting entity 219 such as role, subject identity, information about the security 220 protocols used to authenticate, which credentials have been used, 221 etc. The Geopriv group might want to evaluate which information 222 items are typically associated with a request to re-evaluate the 223 XACL Context schema definition. 225 Note that attributes might appear in different envelopes such as 226 X.509 attribute certificates or as Security Assertion Markup 227 Language (SAML) assertions [SAML]. SAML allows distributing security 228 information. Thereby the security information is expressed as 229 assertions about subjects. These assertions carry information about 230 authentication acts, attributes and authorization decisions. 231 Conversion between the native format and the XACML context might be 232 specified with the help of the Extensible Stylesheet Language 233 Transformation [XSLT]. 235 4. Features provided by XACML 237 This section describes some of the features which make it an 238 attractive access control markup language for Geopriv policies. 239 Implementing a new access control markup language solely for Geopriv 240 without reusing existing systems requires recreating the same 241 functions and concepts. It seems that the solution space for 242 standardized languages is actually fairly small when designing a 243 flexible access control mechanism for XML based documents. 245 4.1 Basic functionality of XACML 247 Three top-level elements are defined in XACML [XACML]: , 248 and 250 The policy language model is defined in [XACML], Section 3.3 (see 251 also Figure 3 there). 253 A contains a Boolean expression and consists of the following 254 components: 256 - Target 257 - Effect and 258 - Condition 260 The rule target defines a set of resources, subjects and actions to 261 which the rule applies. The rule itself forms the basic building 262 block for a Policy. 264 The rule target consists of 265 - Resources 266 - Subjects and 267 - Actions 269 Subjects and resources might be internally structured. This allows 270 referencing them via an XPath [XPath] or XPointer [XPointer] 271 reference. Referring to resources could imply to 272 - refer to the content of the identified node itself 273 - refer to the content of the identified node and its immediate 274 child nodes or 275 - refer to the content of the identified node and all its descendant 276 nodes. 278 It is therefore also possible to base the authorization decision on 279 data contained in the resource to which access requested. 281 The effect describes the intended consequence of a "true" 282 evaluation. Two values are defined "permit" and "deny". 284 The condition furthermore allows refining the applicability of a 285 rule. This element is optional. 287 Rules themselves are not exchanged between entities. Therefore 288 are always embedded into a . A consists of 290 - a target 291 - a rule-combining algorithm id 292 - a set of rules and 293 - obligations. 295 elements might additionally attach to an information 296 resource itself. One application would be to attach the policy 297 itself to Geopriv location object. 299 Obligations allow to enforce certain actions that must be performed 300 either instead or in addition to the actions that may be performed. 301 This functionality simulates the idea of a provisional action as 302 described in [Kudo00]. Provisions are attached to the access 303 decision. 305 An example for such an access decision might be a logging action or 306 the encryption of the objects returned in response. 308 A again allows combining set of Policies together with 309 the following elements: 311 - a target 312 - a policy-combining algorithm id 313 - obligations. 315 4.2 Combining Algorithms 317 The rule-combining algorithm identifier is used to implement 318 conflict resolution (i.e. a mechanism for achieving a final 319 authorization decision after evaluating individual rules) with the 320 following standard algorithms: 322 * Deny-overrides 323 * Permit-overrides 324 * First applicable and 325 * Only-one-applicable 327 The policy-combining algorithm identifier enforces the same concept 328 as the rule-combining algorithm identifier but at a policy and not a 329 rule level. 331 An example: The permit-overrides algorithm causes a "permit" 332 evaluation if a single rule (or policy) in the applicable policy is 333 found with a "permit" evaluation, regardless of other rules or 334 policies in the applicable policy. 336 New rule-combining algorithms (or policy-combining algorithms) can 337 be specified, if necessary. 339 4.3 Operators 341 In order to compute an authorization decision it is necessary to 342 perform operations on attributes of subjects and resources. XACML 343 defines a number of operators: 345 - Operators on numerical data types 347 Examples: integer-add, double-add, integer-subtract, integer- 348 multiply, double-mod, integer-divide, round, floor, integer-abs, 349 double-to-integer, etc. 351 Additionally arithmetic comparison functions are defined such as 352 integer-less-than, double-greater-than-or-equal, etc. 353 Various non-numeric comparison functions also exist such as string- 354 greater-than, string-less-than, time-less-than, date-greater-than, 355 etc. 357 - Operators on date, time and duration data types 359 Examples: dateTime-subtract-yearMonthDuration, dateTime-add- 360 dayTimeDuration, date-subtract-yearMonthDuration 362 - Operators on Boolean data types 364 Examples: and, or, not, n-of 366 These operators allow specifying logical combination of predicates 367 of a rule. 369 - Operators on sets 371 Examples: type-bag-size, type-is-in, type-intersection, type-union, 372 type-subset, type-set-equals, any-of, all-of, any-of-any, map, etc. 374 - Relationship operators 376 Examples: Equality and comparison on RFC 822 and X.500 name forms, 377 strings, URIs, etc. (string-equal, Boolean-equal, integer-equal, 378 date-equal, time-equal, X500Name-eqal, rfc822Name-equal, anyURI- 379 equal, etc.) 380 Additionally it is possible to add non-standard functions. 382 5. Examples 384 This section shows some examples for the XACML policies. For this 385 version of the draft some very basic examples are provided. 386 Currently the examples are very much aligned to the examples in 387 Section 4 of [XACML]. Comments are inserted into the XML code within 388 "". 390 5.1 Request Context Example 1 392 The request in XACML for the first example might be stated as 393 follows: 395 "Jorge Cuellar wants to know (i.e. read) the location of Hannes 396 Tschofenig. Jorge Cuellar is identified with an RFC 822 type of 397 email address (for example obtained during the SIP authentication 398 procedure)". 400 This request therefore translates to the following XACML request 401 context: 403 404 410 412 413 416 Jorge.Cuellar@siemens.com 417 418 420 424 425 429 /geopriv/HannesTschofenig@siemens.com 431 432 434 441 442 445 read 446 447 448 450 453 5.2 Policy Example 1 455 The request described in Section 5.1 is then matched against a 456 policy at the location server. This policy might, for example, be 457 provided by the owner of the location itself. 459 460 469 476 477 Simple Geopriv policy. 478 480 482 483 484 485 486 487 488 489 490 491 492 494 497 500 501 Every subject with an identifier in the siemens.com domain is 502 allowed to read the location. 503 505 509 510 511 512 514 518 siemens.com 521 522 523 524 525 526 527 528 529 532 read 533 534 535 537 547 548 550 5.3 Reponse Context Example 1 552 The following XML text might represent a possible reponse context to 553 the request described in this example. 555 556 562 564 565 NotApplicable 566 568 571 6. Security Considerations 573 574 Refer to the threats doc here [DM+03]. There may be also some 575 additional threats to the xacml solution. 577 7. Open Issues 579 This draft is a first discussion starter. As such it creates a 580 number of open issues, such as: 582 - What attributes are useful for location requests? What information 583 should typically serve as input to the authorization engine? 585 - As soon as the work on the location object makes progress it is 586 necessary to describe how to access the attributes of the location 587 object. 589 - More sophisticated Geopriv example policies have to be added to 590 test the adequacy of the capabilities of XACML. 592 - Some data might not be available in form of a XML document - the 593 data might be computed on the fly (e.g. location information at a 594 different granularity). Another approach is to have all information 595 already available and to access as any other data item. Some 596 discussions might be required to determine the best approach 597 possible. 599 - How to structure access to location object information of 600 different entities? As mentioned in [XCAP] it is necessary to define 601 a schema for data used by a number of entities. One possible 602 approach is to access individual data items with the help of URIs. 603 In any case a naming convention for access to items of the location 604 objects and other information items has to be created. 606 8. Acknowledgments 608 We would like to thank Christian Guenther for his input to this 609 version of the draft. 611 This entire draft heavily borrows from the XACML [XACML] 612 specification. We would like to thank the authors of the [XACML] 613 specification for their excellent work. 615 9. References 617 [Kudo00] M. Kudo and S. Hada: "XML document security based on 618 provisional authorization", in: "Proceedings of the Seventh ACM 619 Conference on Computer and Communications Security", Nov. 2000, 620 Athens, Greece, pp. 87-96. 622 [XPath] XML Path Language (XPath), Version 1.0, W3C Recommendation, 623 16 November 1999, Available at: http://www.w3.org/TR/xpath. 625 [XPointer] XML Pointer Language (XPointer), Version 1.0, W3C 626 Candidate Recommendation, 11 September 2001, Available at: 627 http://www.w3.org/TR/2001/CR-xptr-20010911. 629 [XSLT] XSL Transformations (XLT) Version 1.0, W3C Recommendation, 630 16 November 1999, Available at: http://www.w3.org/TR/xslt. 632 [XACML] The OASIS eXtensible Access Control Markup Language 633 (XACML), OASIS Standard, Version 1.0, 18 February, 2003, Available 634 at: http://www.oasis-open.org/committees/xacml. 636 [SAML] Security Assertion Markup Language, Available at: 637 http://www.oasis-open.org/committees/security/#documents. 639 [Pet03] J. Peterson: "A Presence Architecture for the Distribution 640 of Geopriv Location Objects", Internet Draft, Internet Engineering 641 Task Force, (work in progress), February 2003. 643 [CG03] J. Cuellar and C. Guenther: "Geopriv Location Object Markup 644 Language", Internet Draft, Internet Engineering Task Force, (work in 645 progress), June 2003. 647 [CM+03] J. Cuellar, J. Morris, D. Mulligan, J. Peterson and J. 648 Polk: "Geopriv requirements", Internet Draft, Internet Engineering 649 Task Force, (work in progress), March 2003. 651 [DM+03] M. Danley, D. Mulligan, J. Morris and J. Peterson: "Threat 652 Analysis of the Geopriv Protocol", Internet Draft, Internet 653 Engineering Task Force, (work in progress), February 2003. 655 [XCAP] J. Rosenberg: "The Extensible Markup Language (XML) 656 Configuration Access Protocol (XCAP)", Internet Draft, Internet 657 Engineering Task Force, (work in progress), May 2003. 659 [Ros03a] J. Rosenberg: "An Extensible Markup Language (XML) 660 Configuration Access Protocol (XCAP) Usage for Presence Lists", 661 Internet Draft, Internet Engineering Task Force, (work in progress), 662 May 2003. 664 [Ros03b] J. Rosenberg: "A Session Initiation Protocol (SIP) Event 665 Package for Modification Events for the Extensible Markup Language 666 (XML) Configuration Access Protocol (XCAP) Managed Documents", 667 Internet Draft, Internet Engineering Task Force, (work in progress), 668 May 2003. 670 Author's Addresses 672 Hannes Tschofenig 673 Siemens AG 674 Corporate Technology 675 CT IC 3 676 Otto-Hahn-Ring 6 677 81739 Munich 678 Germany 679 EMail: Hannes.Tschofenig@siemens.com 681 Jorge R Cuellar 682 Siemens AG 683 Corporate Technology 684 CT IC 3 685 81730 Munich 686 Germany 687 EMail: Jorge.Cuellar@siemens.com 689 Intellectual Property Statement 691 The IETF takes no position regarding the validity or scope of any 692 intellectual property or other rights that might be claimed to 693 pertain to the implementation or use of the technology described in 694 this document or the extent to which any license under such rights 695 might or might not be available; neither does it represent that it 696 has made any effort to identify any such rights. Information on the 697 IETF's procedures with respect to rights in standards-track and 698 standards-related documentation can be found in BCP-11. Copies of 699 claims of rights made available for publication and any assurances 700 of licenses to be made available, or the result of an attempt made 701 to obtain a general license or permission for the use of such 702 proprietary rights by implementors or users of this specification 703 can be obtained from the IETF Secretariat. 705 The IETF invites any interested party to bring to its attention any 706 copyrights, patents or patent applications, or other proprietary 707 rights which may cover technology that may be required to practice 708 this standard. Please address the information to the IETF Executive 709 Director. 711 Full Copyright Statement 713 Copyright (C) The Internet Society (2003). All Rights Reserved. 715 This document and translations of it may be copied and furnished to 716 others, and derivative works that comment on or otherwise explain it 717 or assist in its implementation may be prepared, copied, published 718 and distributed, in whole or in part, without restriction of any 719 kind, provided that the above copyright notice and this paragraph 720 are included on all such copies and derivative works. However, this 721 document itself may not be modified in any way, such as by removing 722 the copyright notice or references to the Internet Society or other 723 Internet organizations, except as needed for the purpose of 724 developing Internet standards in which case the procedures for 725 copyrights defined in the Internet Standards process must be 726 followed, or as required to translate it into languages other than 727 English. 729 The limited permissions granted above are perpetual and will not be 730 revoked by the Internet Society or its successors or assignees. 732 This document and the information contained herein is provided on an 733 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 734 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 735 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 736 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 737 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 739 Acknowledgement 741 Funding for the RFC Editor function is currently provided by the 742 Internet Society.