idnits 2.17.00 (12 Aug 2021) /tmp/idnits25979/draft-tschofenig-geopriv-authz-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.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (August 2003) is 6847 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) == Missing Reference: 'Core' is mentioned on line 773, but not defined == Missing Reference: 'Levels' is mentioned on line 147, but not defined == Missing Reference: 'RFC2445' is mentioned on line 531, but not defined ** Obsolete undefined reference: RFC 2445 (Obsoleted by RFC 5545) == Unused Reference: 'Level' is defined on line 796, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'XCAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'XCAP-USAGE' Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Location Object Authorization Policies August 2003 3 Geopriv 4 Internet Draft H. Tschofenig 5 Siemens 6 John B. Morris, Jr. 7 Center for Democracy and Technology 8 (Eds.) 10 J. Cuellar 11 Siemens 12 James Polk 13 Cisco 14 H. Schulzrinne 15 Columbia U. 17 Expires: February 2004 August 2003 19 Location Object Authorization Policies 20 22 Status of this Memo 24 This document is an Internet-Draft and is subject to all provisions 25 of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Abstract 45 This document describes a set of policy rules to satisfy Element E 46 through L of the "Core Privacy Protections for Geopriv Location 47 Object" draft. The draft uses XCAP. 49 Location Object Authorization Policies August 2003 51 This draft aims to provide input for discussions at the Geopriv 52 Interim Meeting in Washington (September 2003). This document 53 presents a very preliminary version of design team discussions. Not 54 all listed authors have fully reached consensus on all issues of the 55 proposed language. 57 Table of Contents 59 1. Introduction..................................................2 60 2. Authorization Policies........................................2 61 2.1 Element E.................................................3 62 2.2 Element F.................................................4 63 2.3 Element G.................................................6 64 2.4 Element H.................................................8 65 2.5 Element I.................................................9 66 2.6 Element J................................................11 67 2.7 Element K................................................13 68 2.8 Element L................................................14 69 3. XML Schema...................................................16 70 4. Security Considerations......................................16 71 5. Open Issues..................................................16 72 6. Normative References.........................................16 73 7. Informative References.......................................16 74 Acknowledgments.................................................16 75 Author's Addresses..............................................17 76 Full Copyright Statement........................................17 78 1. Introduction 80 The policy rules defined in this document extend the Extensible 81 Markup Language (XML) Configuration Access Protocol (XCAP) [XCAP] 82 and in particular the XML schema in [XCAP-USAGE]. Geopriv adds 83 authorization policies beyond what is offered in [XCAP-USAGE]. The 84 XML schema in [XCAP-USAGE] is extended with Geopriv specific content 85 as described in this document. 87 The authorization policies described in this document try to satisfy 88 the Elements E through L defined in [Core]. 90 Section 2 enumerates the Elements E through L with a description of 91 a possible way to address them. This includes XML schema snippets 92 and examples. Section 3 will (in a future version) provide a full 93 XML schema. 95 2. Authorization Policies 97 This section describes the outcome of the design team working on the 98 authorization policies described in [Core]. Code snippets for XML 99 Location Object Authorization Policies August 2003 101 schemas, which extend the [XCAP-USAGE] schema, are provided in 102 addition to some examples that explain the usage of these policies. 104 Most of the elements do not depend on the geospatial content and 105 thus should be additions to the basic XCAP authorization schema. For 106 instance, the element should be placed in a geopriv-specific 107 namespace. 109 2.1 Element E 111 Element E: Permission to disclose only to someone presenting a 112 specified key (for instance, a shared key or the 113 private key corresponding to a particular public 114 key), or a special type of credential (an e-token to 115 be defined). 117 [XCAP-USAGE] specifies the elements and 118 inside the acceptance permission which allows to refer to SIP 119 specific authentication mechanisms such as: 121 - None 122 - TLS 123 - Digest 124 - SMIME 125 - P-Asserted-ID 127 These mechanisms are sufficient for authorization policies in the 128 context of SIP and SIP Presence (although splitting TLS according to 129 the authentication mechanisms would be more appropriate e.g., public 130 key based authentication, Kerberos-based authentication or SRP based 131 authentication). For a first version of the Geopriv authorization 132 policies these authentication mechanisms and XML elements will be 133 reused without modification. 135 Another approach, which aims to be more generic and was also 136 considered, is to reuse a proposal of an (expired) Internet Draft on 137 "Authentication Mechanisms Levels" [Levels]. Instead of enumerating 138 different authentication protocols different authentication levels 139 are defined such as: 141 - None (no authentication) 142 - Weak (vulnerable against eavesdroppers) 143 - Limited (no protection against active attacks) 144 - Strong (protection against active attacks) 146 Examples for the different authentication levels are provided in 147 [Levels]. 149 Location Object Authorization Policies August 2003 151 Currently there is no provision in [XCAP-USAGE] to provide 152 authorization for anonymous access to location information (e.g. by 153 using tokens). A proposal will be described in a separate document. 155 2.2 Element F 157 Element F: Requirement that the granularity/precision of 158 location information be reduced 160 In Section 4.2.2.3 of [XCAP-USAGE] content permissions are defined. 161 These permissions allow to restrict access to certain XML elements. 162 In particular, the use of the seems to be useful to 163 support the concept of location information reduction. By listing 164 only those elements of the location object to which access is 165 allowed by a specific individual the granularity can be reduced. 166 This approach is similar to statement proposed in [Sch03] 167 but the functionality of the statement is not provided. 168 Adding field exclusion primarily offers efficiency advantages, 169 rather than new capabilities and thus can be safely omitted. 171 The following three approaches can be used to specify access to 172 certain location information elements. Please note that the text- 173 values inside the elements are 174 artificial since the format of the location object (civil and 175 geospatial) is not yet defined. Hence it should only be treated as a 176 hint for the reader what the future content will be. 178 a) Leave the XCAP schema unmodified and to repeat the 179 element (if required) 181 As an example, the following authorization policy will be the 182 result. 184 185 189 190 191 sip:mankin@psg.com 192 194 195 196 urn:ietf:params:xml:ns:pidf 197 198 199 rpids:placetype 200 Location Object Authorization Policies August 2003 202 203 204 lo:civil/c 205 206 207 lo:civil/a1 208 209 210 lo:gml/Point 211 212 213 215 216 218 b) Extend the XCAP schema to allow the element to 219 appear arbitrarily often 221 In the above-mentioned example the modifications would lead to: 223 224 rpids:placetype 225 lo:civil/c 226 lo:civil/a1 227 lo:gml/Point 228 230 The same result is achieved with approach (c). The difference 231 between (b) and (c) is only a technical detail and some alignment 232 with the [XCAP-USAGE] XML schema. The second option offers a more 233 space-efficient encoding of these rules. We strive to make the rule 234 set be space-efficient since it may be transported across bandwidth- 235 constrained links and since the number of rules may be large if they 236 are automatically generated from external information such as 237 address books and calendars. 239 c) Enhance the element of the XCAP schema itself to 240 appear arbitrarily often 242 243 Content Permissions 244 245 246 247 248 249 251 Location Object Authorization Policies August 2003 253 255 256 257 259 265 266 267 268 269 271 273 274 275 277 278 279 280 281 282 283 285 It seems to be easiest to use approach (a). More information on the 286 attributes provided by the location object is required to illustrate 287 useful and complete examples. 289 2.3 Element G 291 Element G: The ability to provide additional Privacy Rules for 292 specific requestors or groups of requestors 294 Using the schema extension described below the element of [XCAP-USAGE] is enhanced with an element 296 () pointing to additional privacy rules. 298 It must be ensured that an implementation prevents infinite loops by 299 limiting the inclusion depth. If it is not possible to resolve or 300 Location Object Authorization Policies August 2003 302 retrieve the policies at the indicated URL then the location object 303 is not returned. 305 An alternative approach would be to have the external rule set only 306 provide additional permissions, but not allow it to restrict 307 permissions granted in the base document. In that case, the rule 308 engine may not have to retrieve the additional rules in all cases, 309 e.g., if only a particular request needs to be evaluated against a 310 rule set rather than generating a set of notifications for all 311 recipients. External rule sets add a number of complications, such 312 as privacy concerns (retrieval indicates access to the information), 313 reliability and bandwidth issues. 315 Schema snippet: 317 320 322 323 324 325 326 328 329 330 331 ... 332 333 335 Example: 337 338 340 341 342 sip:mankin@psg.com 343 345 346 347 349 350 Location Object Authorization Policies August 2003 352 353 http://example.com/policies.xml 354 356 358 In this example additional privacy rules are available at 359 "http://example.com/policies.xml". 361 2.4 Element H 363 Element H: The ability to define a time until which a permission 364 is valid 366 To specify a time period until which a permission is valid two 367 attributes ("from" and "until") are added to the element. Both, the "from" and the "until" attribute are 369 optional. If the "from" attribute is missing then the policies are 370 valid immediately. If the "to" attribute is missing then the 371 policies have no restricted lifetime. Both attributes use the data 372 type dateTime. 374 Schema snippet: 376 379 381 382 383 384 385 386 387 389 391 Example: 393 394 397 398 399 sip:mankin@psg.com 400 Location Object Authorization Policies August 2003 402 404 405 406 408 410 411 http://example.com/policies.xml 412 414 416 This example shows that the described policy is valid from the 4th 417 of September (9am) to the 5th of September (6pm). 419 Note that in order for this extension to work it is necessary to 420 specify the element in [XCAP-USAGE] as 421 global (and not as local). 423 2.5 Element I 425 Element I: The ability to define a geographical area for which 426 the permission is valid ("if I am in area x then you 427 can tell y my location") 429 As part of the discussion regarding Element I it was decided to 430 support functionality like: 432 a) "Within z km of point x,y, assuming a spherical earth." 433 OR 434 b) "An equality match on country or state or city (civil location)." 436 The assumption about spherical earth provides a good simplification 437 and the error is said to be fairly low. Going beyond this, as in "as 438 long as I'm within three streets of my home" or "as long as I'm in 439 the area bounded by 112 and 120th Street and Amsterdam Avenue and 440 Broadway" (which describes the Morningside Heights campus of 441 Columbia University) is likely to get messy. 443 The details on the location object (for both civil and geospatial 444 coordinates) will be provided as soon as the discussions on the 445 location object are finished. Hence a placeholder is used for 446 illustrative purposes below. 448 The element is extended to support an element 449 which either contains civil location or spherical area (based on GML 450 most likely). 452 Location Object Authorization Policies August 2003 454 Schema snippet: 456 461 462 463 464 465 466 468 469 470 471 473 474 475 476 477 483 484 485 487 489 Example: 491 492 495 496 497 sip:mankin@psg.com 498 500 501 502 Location Object Authorization Policies August 2003 504 digest 505 506 507 508 US 509 NJ 510 Bergen 511 512 513 515 516 518 In this example location information is provided to Allison only if 519 the target is within the indicated area labeled as "bergen" (in 520 addition to the other policies). 522 2.6 Element J 524 Element J: The ability to define a repeatable time window (such 525 as weekdays during office hours) during which a 526 permission is valid 528 Various approaches have been investigated to support a repeatable 529 time window such as the flexible approach suggested in [Sch03]: 530 "The time recurrence rules are specified using the iCal notation in 531 RFC 2445 [RFC2445], translated into XML schema format, roughly 532 following the (expired) Internet draft draft-ietf-calsch-many-xcal- 533 00. 'exdate' 4.8.5.2, 'rdate' 4.8.5.3, 'rrule', 4.8.5.4.0" (Section 534 4.3). It was decided to consider this approach in future version of 535 Geopriv authorization policies. 537 Other suggestions reused flags for each weekday, included exceptions 538 or reused the format of the Unix CRON command. 540 Finally it was decided to address a repeatable time window with a 541 list of "from"/"until" XML dateTime values. Particularly for non- 542 human written authorization policies (which is likely to be case) 543 this approach seems to provide sufficient flexibility. 545 The following schema snippet extends the element and 546 adds another child element . The element 547 may appear arbitrarily often whereby each element has two sub- 548 elements and of data type dateTime. It may be 549 unnecessary to have both / and recurrence, since the 550 latter is a generalization of the former, but this redundancy may be 551 use-friendly. 553 Location Object Authorization Policies August 2003 555 Schema snippet: 557 561 562 563 564 565 566 569 570 571 572 574 575 576 577 578 579 581 583 Example: 585 586 589 590 591 sip:jon.peterson@neustar.biz 592 594 595 596 597 2003-09-04T09:00:00-05:00 598 2003-09-04T18:00:00-05:00 599 600 601 2003-09-05T09:00:00-05:00 602 2003-09-05T18:00:00-05:00 604 Location Object Authorization Policies August 2003 606 607 609 610 612 This example shows two recurrence elements which approximately 613 capture the timeframe of the Geopriv interim meeting. In the example 614 Jon Peterson will be able to request the location information of 615 target (e.g. Jorge) only during the interim meeting hours. 617 2.7 Element K 619 Element K: The ability to require that express consent of the 620 Target/Rule Maker be obtained prior to disclosing 621 location 623 The mechanism used to enforce consent requires enhancing the 624 element with a sub-child . The data 625 type of this element is anyURI. 627 Schema snippet: 629 633 634 635 636 637 638 641 642 643 644 646 648 Example: 650 651 654 655 Location Object Authorization Policies August 2003 657 658 sip:jon.peterson@neustar.biz 659 661 662 663 sip:hgs@cs.columbia.edu 664 666 667 669 This example shows the policy which requires to contact Henning 670 (hgs@cs.columbia.edu) if Jon asks for location information. There 671 currently is no protocol mechanism for inquiring about permissions 672 from users. In order to define an interoperable protocol, the 673 design team will strive to provide a protocol mechanism first, if 674 that proves feasible, or may remove the feature otherwise. 676 2.8 Element L 678 Element L: The ability to require that notice be provided to the 679 Target if location is provided 681 The mechanism used for Element L is similar to the one used for 682 Element K. Again the element is extended with a 683 element. 685 Schema snippet: 687 691 692 693 694 695 696 698 699 700 701 703 704 Location Object Authorization Policies August 2003 706 Example: 708 709 712 713 714 sip:mankin@psg.com 715 717 718 719 sip:anewton@ecotroph.net 720 722 723 725 Andrew Newton (anewton@ecotroph.net) is the rule maker and is 726 notified if Allison Mankin (mankin@psg.com) requests access to 727 Andrew's location information. 729 Section 4.3 of [Sch03] addresses some security considerations with 730 this mechanisms and in particular with third-party notifications: 732 "This clearly has security implications, since a malicious target 733 could use this mechanism to cause messages to be sent to third 734 parties, introducing a new form of 'open proxy' spamming. Thus, such 735 notification is only appropriate if the notifying party can convince 736 itself that the address indeed belongs to the presentity. 737 Unfortunately, there is no fool-proof way of ensuring that, but a 738 recipient of this information may compare the non-schema part of the 739 notification URI with the presentity and only allow notification on 740 equality. Given these constraints and the inherent unreliability and 741 delays in most current notification mechanisms, a target cannot rely 742 on receiving notification." 744 Third-party notifications must be ruled out. Related to some 745 scenarios presented in this context it might also be possible to use 746 some sort of logging statement to provide similar functionality. 748 There currently is no protocol mechanism for conveying semantically 749 meaningful information about location transmission about permissions 750 from users. In order to define an interoperable protocol, the 751 design team will strive to provide a protocol mechanism first, if 752 that proves feasible, or may remove the feature otherwise. 754 Location Object Authorization Policies August 2003 756 3. XML Schema 758 Once full consensus is reached on the authorization policies and on 759 how to implement them a full XML schema will be provided. 761 4. Security Considerations 763 This document raises and addresses some security issues which are 764 described in [DM+03]. Some additional security concerns (e.g. denial 765 of service attacks) are expressed in [Sch03]. 767 A future version of this document will structure these threats in 768 the appropriate manner once the discussions on the individual 769 mechanisms are finished. 771 5. Open Issues/Future Work 773 - Combining this draft with [Core] draft. 774 - How the authorization policies can be used with other using 775 protocols such as HTTP. 776 - XML Schema 777 - More examples 779 6. Normative References 781 [DM+03] M. Danley, D. Mulligan, J. Morris and J. Peterson: "Threat 782 Analysis of the Geopriv Protocol", Internet Draft, Internet 783 Engineering Task Force, (work in progress), February 2003. 785 [XCAP] Rosenberg, J., "The Extensible Markup Language (XML) 786 Configuration Access Protocol (XCAP)", Internet Draft, Internet 787 Engineering Task Force, (work in progress), May 2003. 789 [XCAP-USAGE] J. Rosenberg: "Extensible Markup Language (XML) 790 Configuration Access Protocol (XCAP) Usages for Setting Presence 791 Authorization", Internet Draft, Internet Engineering Task Force, 792 (work in progress), June, 2003. 794 7. Informative References 796 [Level] K. Zeilenga: "Authentication Mechanisms Levels" Internet 797 Draft, Internet Engineering Task Force, (expired), April, 2001. 799 [Sch03] H. Schulzrinne: "Location Objects and Location Privacy 800 Information for Presence Information", June, 2003. 802 Acknowledgments 803 Location Object Authorization Policies August 2003 805 We would like to thank Christian Guenther for his input on the XML 806 schema snippets in this draft. 808 Author's Addresses 810 Hannes Tschofenig 811 Siemens AG 812 Otto-Hahn-Ring 6 813 81739 Munich 814 Germany 815 EMail: Hannes.Tschofenig@siemens.com 817 Jorge R Cuellar 818 Siemens AG 819 Corporate Technology 820 CT IC 3 821 81730 Munich 822 Germany 823 EMail: Jorge.Cuellar@siemens.com 825 John B. Morris, Jr. 826 Director, Internet Standards, Technology & Policy Project 827 Center for Democracy and Technology 828 1634 I Street NW, Suite 1100 829 Washington, DC 20006 Email: jmorris@cdt.org 830 USA http://www.cdt.org 832 Henning Schulzrinne 833 Columbia University 834 Department of Computer Science 835 450 Computer Science Building 836 New York, NY 10027 837 US 839 Phone: +1 212 939 7042 840 EMail: hgs+nsis@cs.columbia.edu 841 URI: http://www.cs.columbia.edu 843 James M. Polk 844 Cisco Systems 845 2200 East President George Bush Turnpike 846 Richardson, Texas 75082 USA Email: jmpolk@cisco.com 848 Full Copyright Statement 850 Copyright (C) The Internet Society (2003). All Rights Reserved. 852 Location Object Authorization Policies August 2003 854 This document and translations of it may be copied and furnished to 855 others, and derivative works that comment on or otherwise explain it 856 or assist in its implementation may be prepared, copied, published 857 and distributed, in whole or in part, without restriction of any 858 kind, provided that the above copyright notice and this paragraph 859 are included on all such copies and derivative works. However, this 860 document itself may not be modified in any way, such as by removing 861 the copyright notice or references to the Internet Society or other 862 Internet organizations, except as needed for the purpose of 863 developing Internet standards in which case the procedures for 864 copyrights defined in the Internet Standards process must be 865 followed, or as required to translate it into languages other than 866 English. 868 The limited permissions granted above are perpetual and will not be 869 revoked by the Internet Society or its successors or assignees. 871 This document and the information contained herein is provided on an 872 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 873 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 874 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 875 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 876 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 878 Acknowledgement 880 Funding for the RFC Editor function is currently provided by the 881 Internet Society.