idnits 2.17.00 (12 Aug 2021) /tmp/idnits12219/draft-ietf-geopriv-common-policy-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1428. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 389: '...e information delivered to the WR MUST...' RFC 2119 keyword, line 414: '...que token chosen by the RM. A RM MUST...' RFC 2119 keyword, line 429: '... MUST define its own namespace....' RFC 2119 keyword, line 517: '... Common policy MUST either use UTF-8...' RFC 2119 keyword, line 518: '...r non-IDNs, lower-case ASCII SHOULD be...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 917 has weird spacing: '... sphere from ...' == Line 920 has weird spacing: '... alice wor...' == Line 1080 has weird spacing: '...:choice minOc...' -- 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 (May 21, 2006) is 5843 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. '1' ** Obsolete normative reference: RFC 3490 (ref. '2') (Obsoleted by RFC 5890, RFC 5891) ** Downref: Normative reference to an Informational RFC: RFC 3694 (ref. '3') ** Obsolete normative reference: RFC 4288 (ref. '5') (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) == Outdated reference: draft-ietf-simple-presence-rules has been published as RFC 5025 == Outdated reference: draft-ietf-geopriv-policy has been published as RFC 6772 == Outdated reference: draft-ietf-simple-rpid has been published as RFC 4480 Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: November 22, 2006 H. Tschofenig 5 Siemens 6 J. Morris 7 CDT 8 J. Cuellar 9 Siemens 10 J. Polk 11 J. Rosenberg 12 Cisco 13 May 21, 2006 15 Common Policy: An XML Document Format for Expressing Privacy Preferences 16 draft-ietf-geopriv-common-policy-10.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on November 22, 2006. 43 Copyright Notice 45 Copyright (C) The Internet Society (2006). 47 Abstract 48 This document defines a framework for authorization policies 49 controlling access to application specific data. This framework 50 combines common location- and presence-specific authorization 51 aspects. An XML schema specifies the language in which common policy 52 rules are represented. The common policy framework can be extended 53 to other application domains. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. Modes of Operation . . . . . . . . . . . . . . . . . . . . . . 7 60 3.1. Passive Request-Response - PS as Server (Responder) . . . 7 61 3.2. Active Request-Response - PS as Client (Initiator) . . . . 7 62 3.3. Event Notification . . . . . . . . . . . . . . . . . . . . 7 63 4. Goals and Assumptions . . . . . . . . . . . . . . . . . . . . 9 64 5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 6. Basic Data Model and Processing . . . . . . . . . . . . . . . 12 66 6.1. Identification of Rules . . . . . . . . . . . . . . . . . 13 67 6.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 13 68 7. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 7.1. Identity Condition . . . . . . . . . . . . . . . . . . . . 14 70 7.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 14 71 7.1.2. Matching One Entity . . . . . . . . . . . . . . . . . 14 72 7.1.3. Matching Multiple Entities . . . . . . . . . . . . . . 15 73 7.2. Single Entity . . . . . . . . . . . . . . . . . . . . . . 19 74 7.3. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 7.4. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 21 76 8. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 77 9. Transformations . . . . . . . . . . . . . . . . . . . . . . . 24 78 10. Procedure for Combining Permissions . . . . . . . . . . . . . 25 79 10.1. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 25 80 10.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 26 81 11. Meta Policies . . . . . . . . . . . . . . . . . . . . . . . . 29 82 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 83 13. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 31 84 14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 85 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 86 15.1. Common Policy Namespace Registration . . . . . . . . . . . 35 87 15.2. Content-type registration for 88 'application/auth-policy+xml' . . . . . . . . . . . . . . 35 89 15.3. Common Policy Schema Registration . . . . . . . . . . . . 37 90 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 91 16.1. Normative References . . . . . . . . . . . . . . . . . . . 38 92 16.2. Informative References . . . . . . . . . . . . . . . . . . 38 93 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 39 94 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 40 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 96 Intellectual Property and Copyright Statements . . . . . . . . . . 43 98 1. Introduction 100 This document defines a framework for creating authorization policies 101 for access to application specific data. This framework is the 102 result of combining the common aspects of single authorization 103 systems that more specifically control access to presence and 104 location information and that previously had been developed 105 separately. The benefit of combining these two authorization systems 106 is two-fold. First, it allows to build a system which enhances the 107 value of presence with location information in a natural way and 108 reuses the same underlying authorization mechanism. Second, it 109 encourages a more generic authorization framework with mechanisms for 110 extensibility. The applicability of the framework specified in this 111 document is not limited to policies controlling access to presence 112 and location information data, but can be extended to other 113 application domains. 115 The general framework defined in this document is intended to be 116 accompanied and enhanced by application-specific policies specified 117 elsewhere. The common policy framework described here is enhanced by 118 domain-specific policy documents, including presence [7] and location 119 [8]. This relationship is shown in Figure 1. 121 +-----------------+ 122 | | 123 | Common | 124 | Policy | 125 | | 126 +---+---------+---+ 127 /|\ /|\ 128 | | 129 +-------------------+ | | +-------------------+ 130 | | | enhance | | | 131 | Location-specific | | | | Presence-specific | 132 | Policy |----+ +----| Policy | 133 | | | | 134 +-------------------+ +-------------------+ 136 Figure 1: Common Policy Enhancements 138 This document starts with an introduction to the terminology in 139 Section 2, an illustration of basic modes of operation in Section 3, 140 a description of goals (see Section 4) and non-goals (see Section 5) 141 of the policy framework, followed by the data model in Section 6. 142 The structure of a rule, namely conditions, actions and 143 transformations, is described in Section 7, in Section 8 and in 144 Section 9. The procedure for combining permissions is explained in 145 Section 10 and used when more than one rule fires. A short 146 description of meta policies is given in Section 11. An example is 147 provided in Section 12. The XML schema will be discussed in 148 Section 13. IANA considerations in Section 15 follow the security 149 considerations from Section 14. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [1]. 157 This document introduces the following terms: 159 PT - Presentity / Target: The PT is the entity about whom information 160 has been requested. RFC 3693 [9] uses the term Target to identify 161 the object or person of which location information is requested. 163 The presence model described in RFC 2778 [10] uses the term 164 presentity to describe the entity that provides presence 165 information to a presence service. We introduce a neutral term 166 here to avoid confusion or loose generality. 168 RM - Rule Maker: RM is an entity that creates the authorization rules 169 which restrict access to data items. 171 PS - (Authorization) Policy Server: This entity has access to both 172 the authorization policies and to the data items. In location- 173 specific applications, the entity PS is labeled as location server 174 (LS). 176 WR - Watcher / Recipient: This entity requests access to data items 177 of the PT. An access operation might be either be a read, write 178 or be any other operation. In case of access to location 179 information is likely to be a read operation. 181 The receiver of the requested data items is the Location Recipient 182 (LR) in the terminology of RFC 3693 [9]. A watcher, i.e., an 183 entity that requests presence information about a presentity, is a 184 recipient in presence systems (see [10]). 186 A policy is given by a 'rule set' that contains an unordered list of 187 'rules'. A 'rule' has a 'conditions', an 'actions' and a 188 'transformations' part. 190 The term 'permission' refers to the action and transformation 191 components of a 'rule'. 193 The term 'using protocol' is defined in [9]. It refers to the 194 protocol that is used to request access to and to return privacy 195 sensitive data items. 197 3. Modes of Operation 199 The abstract sequence of operations can roughly be described as 200 follows. The PS receives a query for data items for a particular PT, 201 via the using protocol. The using protocol (or more precisely the 202 authentication protocol) provides the identity of the requestor, 203 either at the time of the query or at the subscription time. The 204 authenticated identity of the WR, together with other information 205 provided by the using protocol or generally available to the server, 206 is then used for searching through the rule set. All matching rules 207 are combined according to a permission combining algorithm described 208 in Section 10. The combined rules are applied to the application 209 data, resulting in the application of privacy based on the 210 transformation policies. The resulting application data is returned 211 to the WR. 213 Three different modes of operation can be distinguished: 215 3.1. Passive Request-Response - PS as Server (Responder) 217 In a passive request-response mode, the WR queries the PS for data 218 items about the PT. Examples of protocols following this mode of 219 operation include HTTP, FTP, LDAP, finger or various RPC protocols, 220 including Sun RPC, DCE, DCOM, Corba and SOAP. The PS uses the 221 ruleset to determine whether the WR is authorized to access the PTs 222 information, refusing the request if necessary. Furthermore, the PS 223 might filter information by removing elements or by reducing the 224 resolution of elements. 226 3.2. Active Request-Response - PS as Client (Initiator) 228 Alternatively, the PS may contact the WR and convey data items. 229 Examples include HTTP, SIP session setup (INVITE request), H.323 230 session setup or SMTP. 232 3.3. Event Notification 234 Event notification adds a subscription phase to the "Active Request- 235 Response - PS as Client (Initiator)" mode of operation. A watcher or 236 subscriber asks to be added to the notification list for a particular 237 presentity or event. When the presentity changes state or the event 238 occurs, the PS sends a message to the WR containing the updated 239 state. (Presence is a special case of event notification; thus, we 240 often use the term interchangeably.) 242 In addition, the subscriber may itself add a filter to the 243 subscription, limiting the rate or content of the notifications. If 244 an event, after filtering by the rule maker-provided rules and by the 245 subscriber-provided rules, only produces the same notification 246 content that was sent previously, no event notification is sent. 248 A single PS may authorize access to data items in more than one mode. 249 Rather than having different rule sets for different modes all three 250 modes are supported with a one rule set schema. 252 4. Goals and Assumptions 254 Below, we summarize our design goals and constraints. 256 Table representation: 258 Each rule must be representable as a row in a relational database. 259 This design goal should allow efficient policy implementation by 260 utilizing standard database optimization techniques. 262 Permit only: 264 Rules only provide permissions rather than denying them. Removing 265 a rule can never increase permissions. Allowing both 'permit' and 266 'deny' actions would require some rule ordering that has 267 implications on the update operations executed on these rules. 268 Additionally, it would make distributed rule sets more 269 complicated. Hence, only 'permit' actions are allowed that result 270 in more efficient rule processing. This also implies that rule 271 ordering is not important. 273 Additive permissions: 275 A query for access to data items is matched against the rules in 276 the rule database. If several rules match, then the overall 277 permissions granted to the WR are the union of those permissions. 278 A more detailed discussion is provided in Section 10. 280 Upgradeable: 282 It should be possible to add additional rules later, without 283 breaking PSs that have not been upgraded. Any such upgrades must 284 not degrade privacy constraints, but PSs not yet upgraded may 285 reveal less information than the rule maker would have chosen. 287 Capability support: 289 In addition to the previous goal, a RM should be able to determine 290 the extensions that are supported by the PS. The mechanism used 291 to determine the capability of a PS is outside the scope of this 292 specification. 294 Protocol-independence: 296 The rule set supports constraints on both notifications or queries 297 as well as subscriptions for event-based systems such as presence 298 systems. 300 No false assurance: 302 It appears more dangerous to give the user the impression that the 303 system will prevent disclosure automatically, but fail to do so 304 with a significant probability of operator error or 305 misunderstanding, than to force the user to explicitly invoke 306 simpler rules. For example, rules based on weekday and time-of- 307 day ranges seem particularly subject to misinterpretation and 308 false assumptions on part of the RM. (For example, a non- 309 technical RM would probably assume that the rules are based on the 310 timezone of his current location, which may not be known to other 311 components of the system.) 313 5. Non-Goals 315 We explicitly decided that a number of possibly worthwhile 316 capabilities are beyond the scope of this first version. Future 317 versions may include these capabilities, using the extension 318 mechanism described in this document. Non-goals include: 320 No external references: 322 Attributes within specific rules cannot refer to external rule 323 sets, databases, directories or other network elements. Any such 324 external reference would make simple database implementation 325 difficult and hence they are not supported in this version. 327 No regular expression: 329 Conditions are matched on equality or 'greater-than'-style 330 comparisons, not regular expressions, partial matches such as the 331 SQL LIKE operator (e.g., LIKE "%foo%") or glob-style matches 332 ("*@example.com"). Most of these are better expressed as explicit 333 elements. 335 No repeat times: 337 Repeat times (e.g., every day from 9am to 4pm) are difficult to 338 make work correctly, due to the different time zones that PT, WR, 339 PS and RM may occupy. It appears that suggestions for including 340 time intervals are often based on supporting work/non-work 341 distinctions, which unfortunately are difficult to capture by time 342 alone. Note that this feature must not be confused with the 343 'Validity' element that provides a mechanism to restrict the 344 lifetime of a rule. 346 6. Basic Data Model and Processing 348 A rule set (or synonymously, a policy) consists of zero or more 349 rules. The ordering of these rules is irrelevant. The rule set can 350 be stored at the PS and conveyed from RM to PS as a single document, 351 in subsets or as individual rules. A rule consists of three parts - 352 conditions (see Section 7), actions (see Section 8), and 353 transformations (see Section 9). 355 The conditions part is a set of expressions, each of which evaluates 356 to either TRUE or FALSE, i.e., each of which is equipped with a value 357 of either TRUE or FALSE by the PS. When a WR asks for information 358 about a PT, the PS goes through each rule in the rule set. For each 359 rule, it evaluates the expressions in the conditions part. If all of 360 the expressions evaluate to TRUE, then the rule is applicable to this 361 request. Generally, each expression specifies a condition based on 362 some variable that is associated with the context of the request. 363 These variables can include the identity of the WR, the domain of the 364 WR, the time of day, or even external variables, such as the 365 temperature or the mood of the PT. 367 Assuming that the rule is applicable to the request, the actions and 368 transformations (commonly referred to as permissions) in the rule 369 specify how the PS is supposed to handle this request. If the 370 request is to view the location of the PT, or to view its presence, 371 the typical action is "permit" that allows the request to proceed. 373 Assuming the action allows the request to proceed, the 374 transformations part of the rule specifies how the information about 375 the PT - their location information, their presence, etc. - is 376 modified before being presented to the WR. These transformations are 377 in the form of positive permissions. That is, they always specify a 378 piece of information that is allowed to be seen by the WR. When a PS 379 processes a request, it takes the transformations specified across 380 all rules that match, and creates the union of them. For computing 381 this union the data type, such as Integer, Boolean, Set, or the Undef 382 data type, plays a role. The details of the algorithm for combining 383 permissions is described in Section 10. The resulting union 384 effectively represents a "mask" - it defines what information is 385 exposed to the WR. This mask is applied to the actual location or 386 presence data for the PT, and the data which is permitted by the mask 387 is shown to the WR. If the WR request a subset of information only 388 (such as city-level civil location data only, instead of the full 389 civil location information), the information delivered to the WR MUST 390 be the intersection of the permissions granted to the WR and the data 391 requested by the WR. 393 In accordance to this document, rules are encoded in XML. To this 394 end, Section 13 contains an XML schema defining the Common Policy 395 Markup Language. This, however, is purely an exchange format between 396 RM and PS. The format does not imply that the RM or the PS use this 397 format internally, e.g., in matching a query with the policy rules. 398 The rules are designed so that a PS can translate the rules into a 399 relational database table, with each rule represented by one row in 400 the database. The database representation is by no means mandatory; 401 we will use it as a convenient and widely-understood example of an 402 internal representation. The database model has the advantage that 403 operations on rows have tightly defined meanings. In addition, it 404 appears plausible that larger-scale implementations will employ a 405 backend database to store and query rules, as they can then benefit 406 from existing optimized indexing, access control, scaling and 407 integrity constraint mechanisms. Smaller-scale implementations may 408 well choose different implementations, e.g., a simple traversal of 409 the set of rules. 411 6.1. Identification of Rules 413 Each rule is equipped with a parameter that identifies the rule. 414 This rule identifier is an opaque token chosen by the RM. A RM MUST 415 NOT use the same identifier for two rules that are available to the 416 PS at the same time for a given PT. If more than one RM modifies the 417 same rule set then it needs to be ensured that a unique identifier is 418 chosen for each rule. A RM can accomplish this goal by retrieving 419 the already specified ruleset and to choose a new identifier for a 420 rule that is different from the values used by the rules in the rule 421 set. 423 6.2. Extensions 425 The policy framework defined in this document is meant to be 426 extensible towards specific application domains. Such an extension 427 is accomplished by defining conditions, actions and transformations 428 that are specific to the desired application domain. Each extension 429 MUST define its own namespace. 431 Extensions cannot change the schema defined in this document, and 432 this schema is not expected to change excepting a revision to this 433 specification, and that no versioning procedures for this schema or 434 namespace are therefore provided. 436 7. Conditions 438 The access to data items needs to be matched with the rule set stored 439 at the PS. Each instance of a request has different attributes 440 (e.g., the identity of the requestor) that are used for 441 authorization. A rule in a rule set might have a number of 442 conditions that need to be met before executing the remaining parts 443 of a rule (i.e., actions and transformations). Details about rule 444 matching are described in Section 10. This document specifies only a 445 few conditions (i.e., identity, sphere, and validity). Further 446 condition elements can be added via extensions to this document. 448 7.1. Identity Condition 450 7.1.1. Overview 452 The identity condition restricts matching of a rule either to a 453 single entity or a group of entities. Only authenticated entities 454 can be matched; acceptable means of authentication are defined in 455 protocol-specific documents. If the element is absent, or 456 it is present but is empty (meaning that there are no child 457 elements), identities are not considered, and thus, other conditions 458 in the rule apply to any user, authenticated or not. 460 The condition is considered TRUE if any of its child 461 elements (e.g., the and the elements defined in this 462 document) evaluate to TRUE, i.e., the results of the individual child 463 element are combined using a logical OR. 465 If a child element of is in a namespace that is not known 466 or not supported, it can be ignored. 468 7.1.2. Matching One Entity 470 The element matches the authenticated identity (as contained in 471 the 'id' attribute) of exactly one entity or user. For 472 considerations regarding the 'id' attribute refer to Section 7.2. 474 An example is shown below: 476 477 479 480 481 482 483 484 485 486 487 488 489 491 493 This example matches if the authenticated identity of the WR is 494 either sip:alice@example.com, tel:+1-212-555-1234 or 495 mailto:bob@example.net. 497 7.1.3. Matching Multiple Entities 499 The element is a mechanism to perform authorization decisions 500 based on the domain part of the authenticated identity. As such, it 501 allows to match a large and possibly unknown number of users within a 502 domain. 504 Furthermore, it is possible to include one or multiple 505 elements to exclude either individual users or users belonging to a 506 specific domain. Excluding individual entities is implemented using 507 a statement. The semantic of the 'id' attribute 508 of the element has the same meaning as the 'id' attribute of 509 the element (see Section 7.2). Excluding users belonging to a 510 specific domain is implemented using the 511 element that excludes any user from the indicated domain. 513 If multiple elements are listed as child elements of the 514 element then the result of each element is combined 515 using a logical OR. 517 Common policy MUST either use UTF-8 or UTF-16 to store domain names 518 in the 'domain' attribute. For non-IDNs, lower-case ASCII SHOULD be 519 used. For the comparison operation between the value stored in the 520 'domain' attribute and the domain value provided via the using 521 protocol (referred as "protocol domain identifier") the following 522 rules are applicable: 524 1. If the values of the 'domain' attribute and the value of the 525 protocol domain identifier does not begin with xn--, attempt a 526 string comparison. If the string comparison indicates equality, 527 the comparison succeeds and the remaining steps are skipped. 529 2. Translate percent-encoding for either string and repeat (1). 531 3. Convert both domain strings using the toASCII operation described 532 in RFC 3490 [2]. (Naturally, if one of the strings already 533 begins with the ACE prefix xn--, the conversion operation has 534 already been performed.) 536 4. Compare the two domain strings for ASCII equality, for each 537 label. If the string comparison for each label indicates 538 equality, the comparison succeeds. Otherwise, the domains are 539 not equal. 541 If the conversion fails in step (3), the domains are not equal. 543 7.1.3.1. Matching Any Authenticated Identity 545 The element without any child elements or attributes matches 546 any authenticated user. 548 The following example shows a rule that matches any authenticated 549 user: 551 552 554 555 556 557 558 559 560 561 562 564 566 7.1.3.2. Matching Any User, Authenticated and Unauthenticated 568 If the element is used without child elements then it 569 matches any user, authenticated and unauthenticated. The same is 570 true for a rule where the element is omitted. 572 The following example shows two rules that match any user, 573 authenticated and unauthenticated. 575 576 578 579 580 581 582 583 584 586 587 588 589 590 592 594 7.1.3.3. Matching Any Authenticated Identity Excepting Enumerated 595 Domains/Identities 597 The element enclosing one or more 598 elements matches any user from any domain except those enumerated. 599 The element excludes particular users. The 600 semantic of the 'id' attribute of the element is described 601 in Section 7.2. The results of the child elements of the 602 element are combined using a logical OR. 604 An example is shown below: 606 607 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 626 628 This example matches all users except any user in example.com, or any 629 user in example.org or the particular users alice@bad.example.net, 630 bob@good.example.net and the user with the telephone number 631 'tel:+1-212-555-1234'. The last 'except' element is redundant since 632 alice@example.com is already excluded through the following statement 633 in the example. 635 7.1.3.4. Matching Any Authenticated Identity Within a Domain Excepting 636 Enumerated Identities 638 The element with a 'domain' attribute and zero or more elements matches any authenticated user from the indicated 640 domain except those explicitly enumerated. The semantic of the 'id' 641 attribute of the element is described in Section 7.2. 643 It is nonsensical to have domains in the 'id' attribute that do not 644 match the value of the 'domain' attribute in the enclosing 645 element. 647 An example is shown below: 649 650 652 653 654 655 656 657 658 659 660 661 662 663 665 667 This example matches any user within example.com (such as 668 carol@example.com) except alice@example and bob@example.com. 670 7.2. Single Entity 672 The 'id' attribute used in the and in the element 673 refers to a single entity. In the subsequent text we use the term 674 'single-user' entity as a placeholder for the and the 675 element. The element fulfills the purpose of excluding 676 elements from the solution set. 678 A single-user entity matches the authenticated identity (as contained 679 in the 'id' attribute) of exactly one entity or user. If there is a 680 match, the single-user entity is considered TRUE. The single-user 681 entity MUST NOT contain a 'domain' attribute. 683 The 'id' attribute contains an identity that MUST be expressed as 684 URI. Applications using this framework must describe how the 685 identities they are using can be expressed as a URIs. 687 7.3. Sphere 689 The element belongs to the group of condition elements. It 690 can be used to indicate a state (e.g., 'work', 'home', 'meeting', 691 'travel') the PT is currently in. A sphere condition matches only if 692 the PT is currently in the state indicated. The state may be 693 conveyed by manual configuration or by some protocol. For example, 694 RPID [11] provides the ability to inform the PS of its current 695 sphere. The application domain needs to describe in more detail how 696 the sphere state is determined. Switching from one sphere to another 697 causes a switch between different modes of visibility. As a result 698 different subsets of rules might be applicable. 700 The content of the 'value' attribute of the element MAY 701 contain more than one token. The individual tokens MUST be separated 702 by a blank character. A logical OR is used for the matching the 703 tokens against the sphere settings of the PT. As an example, if the 704 content of the 'value' attribute in the sphere attribute contains two 705 tokens 'work' and 'home' then this part of the rule matches if the 706 sphere for a particular PT is either 'work' or 'home'. To compare 707 the content of the 'value' attribute in the element with the 708 stored state information about the PT's sphere setting a case 709 insensitive string comparison MUST be used for each individual token. 710 There is no registry for these values nor a language specific 711 indication of the sphere content. As such, the tokens are treated as 712 opaque strings. 714 The rule example below illustrates that the rule with the entity 715 andrew@example.com matches if the sphere is been set to 'work'. In 716 the second rule with the entity allison@example.com matches if the 717 sphere is set to 'home'. The third rule also matches if the sphere 718 is set to 'home' since the value in the sphere element also contains 719 the token 'home'. 721 722 724 725 726 727 728 729 730 731 732 733 735 736 737 738 739 740 741 742 743 744 746 747 748 749 750 751 752 753 754 755 756 758 7.4. Validity 760 The element is the third condition element specified in 761 this document. It expresses the rule validity period by two 762 attributes, a starting and a ending time. The validity condition is 763 TRUE if the current time is greater than or equal to at least one 764 child, but less than the child after it. This 765 represents a logical OR operation across each and 766 pair. Times are expressed in XML dateTime format. 768 A rule maker might not always have access to the PS to invalidate 769 rules. Hence, this mechanism allows to invalidate granted 770 permissions automatically without further interaction between the 771 rule maker and the PS. The PS does not remove the rules instead the 772 rule maker has to clean them up. 774 An example of a rule fragment is shown below: 776 777 779 780 781 782 2003-08-15T10:20:00.000-05:00 783 2003-09-15T10:20:00.000-05:00 784 785 786 787 788 789 791 The element MUST have the and subelements 792 in pairs. Multiple and elements might appear in pairs 793 (i.e., without nesting of and elements). Using 794 multiple elements as subelements of the 795 element is not useful since all subelements of the 796 element are combined as a logical AND. 798 8. Actions 800 While conditions are the 'if'-part of rules, actions and 801 transformations build the 'then'-part of them. The actions and 802 transformations parts of a rule determine which operations the PS 803 MUST execute after having received from a WR a data access request 804 that matches all conditions of this rule. Actions and 805 transformations only permit certain operations; there is no 'deny' 806 functionality. Transformations exclusively specify PS-side 807 operations that lead to a modification of the data items requested by 808 the WR. Regarding location data items, for instance, a 809 transformation could force the PS to lower the precision of the 810 location information that is returned to the WR. 812 Actions, on the other hand, specify all remaining types of operations 813 the PS is obliged to execute, i.e., all operations that are not of 814 transformation type. Actions are defined by application specific 815 usages of this framework. The reader is referred to the 816 corresponding extensions to see examples of such elements. 818 9. Transformations 820 Two sub-parts follow the conditions part of a rule: transformations 821 and actions. As defined in Section 8, transformations specify 822 operations that the PS MUST execute and that modify the result which 823 is returned to the WR. This functionality is particularly helpful in 824 reducing the granularity of information provided to the WR, as for 825 example required for location privacy. Transformations are defined 826 by application specific usages of this framework. 828 A simple transformation example is provided in Section 10. 830 10. Procedure for Combining Permissions 832 This section describes the mechanism to evaluate the final result of 833 a rule evaluation. The result is reflected in the action and 834 transformation part of a rule. This procedure is sometimes referred 835 as conflict resolution. 837 To simplify the description of the algorithm we introduce the term 838 'item' to refer to child elements and attributes of these child 839 elements that apear in the condition, action and transformation part 840 of a rule. An item has a name and a data type. A value may be 841 assigned to an item or it may be undefined, in case it does not have 842 a value associated with the item. The values of a particular item 843 have the same data type. For example, the name of the item 844 discussed in Section 7 is 'sphere', its data type is 'string', and 845 its value may be set to 'home'. To evaluate a condition means to 846 associate either TRUE or FALSE to the condition. 848 When the PS receives a request for access to privacy-sensitive data 849 then it needs to be matched against a rule set. The conditions part 850 of each individual rule is evaluated and as a result one or more 851 rules might match. If only a single rule matches then the result is 852 determined by executing the actions and the transformations part 853 following the conditions part of a rule. However, it can also be the 854 case that two or more matching rules contain a permission of the same 855 name (e.g., two rules contain a permission named 'precision of 856 geospatial location information'), but do not specify the same value 857 for that permission (e.g., the two rule might specify values of '10 858 km' and '200 km', respectively, for the permission named 'precision 859 of geospatial location information'). This section describes the 860 procedure for combining permissions in such cases. 862 The combining operation will result in the largest value for an 863 integer type, the OR operation for a boolean type, and union for a 864 set. 866 As such, applications should define values such that, for integers, 867 the lowest value corresponds to the most privacy, for booleans, false 868 corresponds to the most privacy, and for sets, the empty set 869 corresponds to the most privacy. 871 10.1. Algorithm 873 The algorithm for combining permissions is simple and depends on the 874 data types of the values of items: Let P be a rule set. Let M be the 875 subset of P consisting of rules r in P that match with respect to a 876 given request. Let n be a name of an item contained in a rule r in 877 M, and let M(n) be the subset of M consisting of rules r in M that 878 have a item of name n. For each rule r in M(n), let v(r,n) and 879 d(r,n) be the value and the data type, respectively, of the item of r 880 with name n. Finally, let V(n) be the combined value of all the 881 values v(r,n), r in M(n). The algorithm that leads to the resulting 882 value V(n) is the following: 884 CR 1: If d(r,n)=Boolean for all r in M(n), then V(n) is given as 885 follows: If there is a r in M(n) with v(r,n)=TRUE, then V(n)=TRUE. 886 Otherwise, V(n)=FALSE. 888 CR 2: If d(r,n)=Integer for all r in M(n), then V(n) is given as 889 follows: If v(r,n)=undefined for all r in M(n), then V(n) is not 890 specified by this specification. Otherwise, V(n)=max{v(r,n) | r 891 in M(n)}. 893 CR 3: If d(r,n)=Set for all r in M(n), then V(n) is given as 894 follows: V(n)=union of all v(r,n), the union to be computed over all 895 r in M(n) with v(r,n)!=undefined. 897 10.2. Example 899 In the following example we illustrate the process of the combining 900 permissions algorithm. We will consider three items in the 901 conditions part in our example, namely identity, sphere, and 902 validity. For editorial reasons the rule set in this example is 903 represented in a table. Furthermore, the domain part of the identity 904 of the WR is omitted. For actions we use two items in the action 905 part of the rule with names X and Y. The values of X and Y are of 906 data types boolean and integer, respectively. For transformations we 907 use the item with the name Z whose value can be set either to '+'(or 908 1), 'o' (or 2) or '-' (or 3). Item Z allows us to show the 909 granularity reduction whereby a value of '+' shows the corresponding 910 information unrestricted and '-' shows nothing. This item might be 911 related to location information or other presence attributes like 912 mood. Internally we use the data type integer for computing the 913 permission of this item. 915 Conditions Actions/Transformations 916 +---------------------------------+----------------------+ 917 | Id WR-ID sphere from until | X Y Z | 918 +---------------------------------+----------------------+ 919 | 1 bob home A1 A2 | TRUE 10 o | 920 | 2 alice work A1 A2 | FALSE 5 + | 921 | 3 bob work A1 A2 | TRUE 3 - | 922 | 4 tom work A1 A2 | TRUE 5 + | 923 | 5 bob work A1 A3 | undef 12 o | 924 | 6 bob work B1 B2 | FALSE 10 - | 925 +---------------------------------+----------------------+ 927 For editorial reasons we use the items 'from' and 'until' to refer to 928 validity and we use the following abbreviations for the values: 930 A1=2003-12-24T17:00:00+01:00 931 A2=2003-12-24T21:00:00+01:00 932 A3=2003-12-24T23:30:00+01:00 933 B1=2003-12-22T17:00:00+01:00 934 B2=2003-12-23T17:00:00+01:00 936 Note that B1 < B2 < A1 < A2 < A3. 938 The entity 'bob' acts as a WR. The policy P consists of the six 939 rules shown in the table and identified by the values 1 to 6 in the 940 'Id' column. The PS receives the query at 2003-12-24T17:15:00+01:00 941 which falls between A1 and A2. The value of the item 'sphere' 942 indicates that the sphere of PT is currently set to 'work'. 944 Rule 1 does not match since the sphere condition does not match. 945 Rule 2 does not match as the identity of the WR (here 'alice') does 946 not equal 'bob'. Rule 3 matches since all conditions evaluate to 947 TRUE. Rule 4 does not match as the identity of the WR (here 'tom') 948 does not equal 'bob'. Rule 5 matches. Rule 6 does not match since 949 the rule is not valid anymore. Therefore, the set M of matching 950 rules consists of the rules 3 and 5. These two rules are used to 951 compute the combined permission V(X), V(Y), and V(Z) for each of the 952 permissions X, Y, and Z: 954 Actions/Transformations 955 +-----+-----------------------+ 956 | Id | X Y Z | 957 +-----+-----------------------+ 958 | 3 | TRUE 3 - | 959 | 5 | undef 12 o | 960 +-----+-----------------------+ 962 The results of the permission combining algorithm is shown below. 963 The combined value V(X) regarding the permission with name X equals 964 TRUE according to the first combining rule listed above. The maximum 965 of 3 and 12 is 12, so that V(Y)=12. For the attribute Z in this 966 example the maximum between 'o' and '-' (i.e., between 2 and 3) is 967 '-'. 969 Actions/Transformations 970 +-----+-----------------------+ 971 | Id | X Y Z | 972 +-----+-----------------------+ 973 | 5 | TRUE 12 - | 974 +-----+-----------------------+ 976 11. Meta Policies 978 Meta policies authorize a rule maker to insert, update or delete a 979 particular rule or an entire rule set. Some authorization policies 980 are required to prevent unauthorized modification of rule sets. Meta 981 policies are outside the scope of this document. 983 A simple implementation could restrict access to the rule set only to 984 the PT but more sophisticated mechanisms could be useful. As an 985 example of such policies one could think of parents configuring the 986 policies for their children. 988 12. Example 990 This section gives an example of an XML document valid with respect 991 to the XML schema defined in Section 13. Semantically richer 992 examples can be found in documents which extend this schema with 993 application domain specific data (e.g., location or presence 994 information). 996 Below a rule is shown with a condition that matches for a given 997 authenticated identity (bob@example.com) and within a given time 998 period. Additionally, the rule matches only if the target has set 999 its sphere to 'work'. 1001 1002 1004 1005 1006 1007 1008 1009 1010 1011 2003-12-24T17:00:00+01:00 1012 2003-12-24T19:00:00+01:00 1013 1014 1015 1016 1017 1018 1020 13. XML Schema Definition 1022 This section provides the XML schema definition for the common policy 1023 markup language described in this document. 1025 1026 1030 1031 1032 1033 1034 1035 1036 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1050 1052 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1066 1068 1070 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1095 1096 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1109 1110 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1147 1148 1149 1150 1151 1153 14. Security Considerations 1155 This document describes a framework for policies. This framework is 1156 intended to be enhanced elsewhere towards application domain specific 1157 data. Security considerations are to a great extent application data 1158 dependent, and therefore need to be covered by documents that extend 1159 the framework defined in this specification. RFC 3693 [9] and RFC 1160 3694 [3] are good sources to consider for the type of analysis 1161 required by such documents and applications. 1163 Extensions to the action and transformation elements must be defined 1164 in a way so that the usage of the permissions combining rules of 1165 Section 10 does not lower the level of privacy protection. This is 1166 particularly important when defining the semantic of the a more 1167 detailed description of the values for the defined attributes and 1168 elements. See Section 10 for more details on this privacy aspect. 1170 15. IANA Considerations 1172 This section registers a new XML namespace, a new XML schema and a 1173 new MIME-type. This section registers a new XML namespace per the 1174 procedures in [4]. 1176 15.1. Common Policy Namespace Registration 1178 URI: urn:ietf:params:xml:ns:common-policy 1180 Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne 1181 (hgs+geopriv@cs.columbia.edu). 1183 XML: 1185 BEGIN 1186 1187 1189 1190 1191 1193 Common Policy Namespace 1194 1195 1196

Namespace for Common Authorization Policies

1197

urn:ietf:params:xml:ns:common-policy

1198

See RFCXXXX 1199 [NOTE TO IANA/RFC-EDITOR: 1200 Please replace XXXX with the RFC number of this 1201 specification.].

1202 1203 1204 END 1206 15.2. Content-type registration for 'application/auth-policy+xml' 1208 This specification requests the registration of a new MIME type 1209 according to the procedures of RFC 4288 [5] and guidelines in RFC 1210 3023 [6]. 1212 MIME media type name: application 1213 MIME subtype name: auth-policy+xml 1215 Mandatory parameters: none 1217 Optional parameters: charset 1219 Indicates the character encoding of enclosed XML. 1221 Encoding considerations: 1223 Uses XML, which can employ 8-bit characters, depending on the 1224 character encoding used. See RFC 3023 [6], Section 3.2. 1226 Security considerations: 1228 This content type is designed to carry authorization policies. 1229 Appropriate precautions should be adopted to limit disclosure of 1230 this information. Please refer to Section 14 of RFCXXXX [NOTE TO 1231 IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this 1232 specification.] and to the security considerations described in 1233 Section 10 of RFC 3023 [6] for more information. 1235 Interoperability considerations: None 1237 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please 1238 replace XXXX with the RFC number of this specification.] this 1239 document 1241 Applications which use this media type: 1243 Presence- and location-based systems 1245 Additional information: 1247 Magic Number: None 1248 File Extension: .apxml 1250 Macintosh file type code: 'TEXT' 1252 Personal and email address for further information: Hannes 1253 Tschofenig, Hannes.Tschofenig@siemens.com 1255 Intended usage: LIMITED USE 1257 Author/Change controller: 1259 This specification is a work item of the IETF GEOPRIV working 1260 group, with mailing list address . 1262 15.3. Common Policy Schema Registration 1264 URI: urn:ietf:params:xml:schema:common-policy 1266 Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne 1267 (hgs+geopriv@cs.columbia.edu). 1269 XML: The XML schema to be registered is contained in Section 13. Its 1270 first line is 1272 1274 and its last line is 1276 1278 16. References 1280 16.1. Normative References 1282 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1283 Levels", March 1997. 1285 [2] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing 1286 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 1288 [3] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat 1289 Analysis of the Geopriv Protocol", RFC 3694, February 2004. 1291 [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1292 January 2004. 1294 [5] Freed, N. and J. Klensin, "Media Type Specifications and 1295 Registration Procedures", BCP 13, RFC 4288, December 2005. 1297 [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 1298 RFC 3023, January 2001. 1300 16.2. Informative References 1302 [7] Rosenberg, J., "Presence Authorization Rules", 1303 draft-ietf-simple-presence-rules-06 (work in progress), 1304 May 2006. 1306 [8] Schulzrinne, H., "A Document Format for Expressing Privacy 1307 Preferences for Location Information", 1308 draft-ietf-geopriv-policy-08 (work in progress), February 2006. 1310 [9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 1311 Polk, "Geopriv Requirements", RFC 3693, February 2004. 1313 [10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 1314 and Instant Messaging", RFC 2778, February 2000. 1316 [11] Schulzrinne, H., "RPID: Rich Presence Extensions to the 1317 Presence Information Data Format (PIDF)", 1318 draft-ietf-simple-rpid-10 (work in progress), December 2005. 1320 Appendix A. Contributors 1322 We would like to thank Christian Guenther for his help with initial 1323 versions of this document. 1325 Appendix B. Acknowledgments 1327 This document is partially based on the discussions within the IETF 1328 GEOPRIV working group. Discussions at the Geopriv Interim Meeting 1329 2003 in Washington, D.C., helped the working group to make progress 1330 on the authorization policies based on the discussions among the 1331 participants. 1333 We particularly want to thank Allison Mankin , 1334 Randall Gellens , Andrew Newton 1335 , Ted Hardie and Jon 1336 Peterson for discussing a number of 1337 details with us. They helped us to improve the quality of this 1338 document. Allison, Ted and Andrew also helped us to make good 1339 progress with the internationalization support of the identifier/ 1340 domain attributes. 1342 Furthermore, we would like to thank the IETF SIMPLE working group for 1343 their discussions of J. Rosenberg's draft on presence authorization 1344 policies. We would also like to thank Stefan Berg, Murugaraj 1345 Shanmugam, Christian Schmidt, Martin Thomson, Markus Isomaki, Aki 1346 Niemi, Eva Maria Leppanen, Mark Baker, Tim Polk and Brian Carpenter 1347 for their comments. Martin Thomson helped us with the XML schema. 1348 Mark Baker provided a review of the media type. Scott Brim provided 1349 a review on behalf of the General Area Review Team. 1351 Authors' Addresses 1353 Henning Schulzrinne 1354 Columbia University 1355 Department of Computer Science 1356 450 Computer Science Building 1357 New York, NY 10027 1358 USA 1360 Phone: +1 212 939 7042 1361 Email: schulzrinne@cs.columbia.edu 1362 URI: http://www.cs.columbia.edu/~hgs 1364 Hannes Tschofenig 1365 Siemens 1366 Otto-Hahn-Ring 6 1367 Munich, Bavaria 81739 1368 Germany 1370 Email: Hannes.Tschofenig@siemens.com 1371 URI: http://www.tschofenig.com 1373 John B. Morris, Jr. 1374 Center for Democracy and Technology 1375 1634 I Street NW, Suite 1100 1376 Washington, DC 20006 1377 USA 1379 Email: jmorris@cdt.org 1380 URI: http://www.cdt.org 1382 Jorge R. Cuellar 1383 Siemens 1384 Otto-Hahn-Ring 6 1385 Munich, Bavaria 81739 1386 Germany 1388 Email: Jorge.Cuellar@siemens.com 1389 James Polk 1390 Cisco 1391 2200 East President George Bush Turnpike 1392 Richardson, Texas 75082 1393 USA 1395 Email: jmpolk@cisco.com 1397 Jonathan Rosenberg 1398 Cisco 1399 600 Lanidex Plaza 1400 Parsippany, New York 07054 1401 USA 1403 Email: jdrosen@cisco.com 1404 URI: http://www.jdrosen.net 1406 Intellectual Property Statement 1408 The IETF takes no position regarding the validity or scope of any 1409 Intellectual Property Rights or other rights that might be claimed to 1410 pertain to the implementation or use of the technology described in 1411 this document or the extent to which any license under such rights 1412 might or might not be available; nor does it represent that it has 1413 made any independent effort to identify any such rights. Information 1414 on the procedures with respect to rights in RFC documents can be 1415 found in BCP 78 and BCP 79. 1417 Copies of IPR disclosures made to the IETF Secretariat and any 1418 assurances of licenses to be made available, or the result of an 1419 attempt made to obtain a general license or permission for the use of 1420 such proprietary rights by implementers or users of this 1421 specification can be obtained from the IETF on-line IPR repository at 1422 http://www.ietf.org/ipr. 1424 The IETF invites any interested party to bring to its attention any 1425 copyrights, patents or patent applications, or other proprietary 1426 rights that may cover technology that may be required to implement 1427 this standard. Please address the information to the IETF at 1428 ietf-ipr@ietf.org. 1430 Disclaimer of Validity 1432 This document and the information contained herein are provided on an 1433 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1434 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1435 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1436 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1437 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1438 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1440 Copyright Statement 1442 Copyright (C) The Internet Society (2006). This document is subject 1443 to the rights, licenses and restrictions contained in BCP 78, and 1444 except as set forth therein, the authors retain all their rights. 1446 Acknowledgment 1448 Funding for the RFC Editor function is currently provided by the 1449 Internet Society.