idnits 2.17.1 draft-knauf-p2psip-share-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2011) is 4671 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) == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-16 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-03 == Outdated reference: A later version (-05) exists of draft-knauf-p2psip-disco-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP Working Group A. Knauf 3 Internet-Draft G. Hege 4 Intended status: Standards Track T C. Schmidt 5 Expires: January 12, 2012 HAW Hamburg 6 M. Waehlisch 7 link-lab & FU Berlin 8 July 11, 2011 10 A Usage for Shared Resources in RELOAD (ShaRe) 11 draft-knauf-p2psip-share-01 13 Abstract 15 This document defines a RELOAD Usage for managing shared write access 16 to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic 17 primitive for enabling various coordination and notification schemes 18 among distributed peers. Access in ShaRe is controlled by a 19 hierarchical trust delegation scheme maintained within an access 20 list. A new USER-CHAIN-ACL access policy allows authorized peers to 21 write a Shared Resource without owning its corresponding certificate. 22 This specification also adds mechanisms to store Resources with a 23 variable name which is useful whenever peer-independent rendezvous 24 processes are required. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 12, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Shared Resources in RELOAD . . . . . . . . . . . . . . . . . . 5 63 3.1. Mechanisms for Isolating Stored Data . . . . . . . . . . . 6 64 4. Access Control List Definition . . . . . . . . . . . . . . . . 7 65 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Extension for Variable Resource Names . . . . . . . . . . . . 11 68 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 5.2. Overlay Configuration Document Extension . . . . . . . . . 11 70 6. Access Control to Shared Resources . . . . . . . . . . . . . . 13 71 6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 13 72 6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 13 73 6.3. Storage and Validation . . . . . . . . . . . . . . . . . . 14 74 6.3.1. Operations of the Storing Peer . . . . . . . . . . . . 14 75 6.3.2. Operations of the Accessing Peer . . . . . . . . . . . 15 76 6.4. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . . 16 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 7.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 17 79 7.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 17 80 7.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 17 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 86 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 89 1. Introduction 91 This document defines a RELOAD Usage for managing shared write access 92 to RELOAD Resources and a mechanism to store Resources with a 93 variable name. The Usage for Shared Resources in RELOAD (ShaRe) 94 enables overlay users to share their exclusive write access to 95 specific Resource/Kind pairs with others. Shared Resources form a 96 basic primitive for enabling various coordination and notification 97 schemes among distributed peers. Write permission is controlled by 98 an Access Control List (ACL) Kind that maintains a chain of 99 Authorized Peers for a particular Shared Resource. A newly defined 100 USER-CHAIN-ACL access control policy enables shared write access in 101 RELOAD. 103 The Usage for Shared Resources in RELOAD is designed for jointly 104 coordinated group applications among distributed peers (c.f. 105 [I-D.knauf-p2psip-disco]). Of particular interest are rendezvous 106 processes, where a single identifier is linked to multiple, dynamic 107 instances of a distributed cooperative service. Shared write access 108 is based on a trust delegation mechanism. It transfers the 109 authorization to write a specific Kind data by storing logical Access 110 Control Lists. An ACL contains the ID of the Kind to be shared and 111 contains trust delegations from one authorized to another (previously 112 unauthorized) user. 114 Shared write access extends the RELOAD security model, which is based 115 on the restriction that peers are only allowed to write resources at 116 a small set of well defined locations (Resource IDs) in the overlay. 117 Using the standard access control rules in RELOAD, these locations 118 are bound to the username or Node Id in the peer's certificate. This 119 document extends the base policies to enable a controlled write 120 access for multiple users to a common Resource Id. 122 Additionally, this specification defines an optional mechanism to 123 store Resources with a variable Resource Name. It enables the 124 storage of Resources whose name complies to a specific pattern. 125 Definition of the pattern is arbitrary, but must contain the username 126 of the Resource creator. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 This document uses the terminology and definitions from the RELOAD 135 base [I-D.ietf-p2psip-base]and the peer-to-peer SIP concepts draft 136 [I-D.ietf-p2psip-concepts]. Additionally, the following terms are 137 used: 139 Shared Resource: The term Shared Resource in this document defines a 140 RELOAD Resource with its associated Kinds, that can be written or 141 overwritten by multiple RELOAD users following the specifications 142 in this document. 144 Access Control List: The term Access Control List in this document 145 defines a logical list of RELOAD users allowed to write a specific 146 RELOAD Resource/Kind pair by following the specifications in this 147 document. The list items are stored as Access Control List Kinds 148 that map trust delegations from user A to user B, where A is 149 allowed to write a Shared Resource and the Access Control List, 150 while B is a user that obtains write access to specified Kinds 151 from A. 153 Resource Owner: The term Resource Owner in this document defines a 154 RELOAD peer that initially stored a Resource to be shared. The 155 Resource Owner possesses the RELOAD certificate that grants write 156 access to a specific Resource/Kind pair using the RELOAD 157 certificate based access control policies. 159 Authorized Peer: The term Authorized Peer in this document defines a 160 RELOAD peer that was granted write access to a Shared Resource by 161 permission of the Resource Owner or another Authorized Peer. 163 3. Shared Resources in RELOAD 165 A RELOAD user that owns a certificate for writing at a specific 166 overlay location can maintain one or more RELOAD Kinds that are 167 designated for a non-exclusive write access shared with other RELOAD 168 users. The mechanism to share those Resource/Kind pairs with a group 169 of users consists of two basic steps: Storage of the Resource/Kind 170 pair to be shared and storage of an Access Control List (ACL) 171 associated with those Kinds. ACLs are initiated by the Resource 172 Owner and contain ACL items, each delegating the permission of 173 writing the shared Kind to a specific user called Authorized Peer. 174 This trust delegation to the Authorized Peer can include the right to 175 further delegate the write permission. For each shared Kind data, 176 the Resource owner stores a root item that starts an Access Control 177 List. The result is a tree of trust delegations with the Resource 178 Owner as trust anchor. 180 The Resource/Kind pair to be shared can be any RELOAD Kind that 181 complies to the following specifications: 183 Isolated Data Storage: To ensure that concurrent writing does not 184 cause race conditions, each data item stored within a Shared 185 Resource needs to be exclusively maintained by the RELOAD user who 186 created it. Hence, Usages that allow the storage of Shared 187 Resources MUST use either array or dictionary data model and 188 require the additional mechanisms for isolating data as described 189 in Section 3.1. 191 Access Control Policy: To ensure write access to Shared Resource by 192 Authorized Peers, each Usage MUST use the USER-CHAIN-ACL access 193 policy (see Section 6.4). 195 Resource_name field: Any Kind using the USER-CHAIN-MATCH policy MUST 196 define an opaque <0..2^16-1> initial field within the Kind data 197 structure definition. It contains the Resource Name of the Kind 198 data to be stored. The Resource_name field allows any receicer of 199 a shared data to validate if the Resource Name hashes to the 200 Resource-ID of Shared Resource. 202 User_name field: Any a Kind using the USER-CHAIN-ACL policy MUST 203 define an opaque <0..2^16-1> as second field within the Kind data 204 structure definition. It contains the username from the 205 certificate of the signer of the data to be stored. The User_name 206 field allows any receiver of the data to request the public key 207 certificate of the originator of the stored data and to verify his 208 provenance and integrity. 210 3.1. Mechanisms for Isolating Stored Data 212 This Section defines mechanisms to avoid race conditions while 213 concurrently writing an array or dictionary of a Shared Resource. 215 If a dictionary is used in the Shared Resource, the dictionary key 216 MUST be the Node-ID of the certificate that will be used to sign the 217 stored data. 219 If the data model of the Shared Resource is an array, the following 220 algorithm will generate an array index that avoids collisions. 222 1. Obtain the Node-ID of the certificate that will be used to sign 223 the stored data 225 2. Take the least significant 24 bits of that Node-ID 227 3. Concatenate an 8 bit long short individual index value to those 228 24 bit of the Node-ID 230 The resulting 32 bits long integer MUST be used as the index for 231 storing an array entry in a Shared Resource. The 8 bit individual 232 index can be incremented by one for each further array entry stored 233 and allows for 256 distinct entries per Peer. 235 The mechanism to create the array index is related to the pseudo- 236 random algorithm to generate an SSRC identifier in RTP, see Section 237 8.1 in [RFC3550] for calculating a collision probability. 239 4. Access Control List Definition 241 4.1. Overview 243 In this document, an Access Control List (ACL) contains a list of 244 AccessControlListData structures defined in Section 4.2. Each entry 245 delegates write access for a specific Kind data to a single RELOAD 246 user. The information is stored at the same overlay location as the 247 Shared Resource. An ACL allows the RELOAD user who is authorized to 248 write a specific Resource-ID to delegate his exclusive write access 249 for the specified Kinds to further users of a RELOAD instance. Each 250 Access Control List data structure therefore carries the information 251 about who delegates write access to whom, the Kind-ID of the Resource 252 to be shared, and whether delegation includes write access to the ACL 253 itself. The latter condition grants the right to delegate write 254 access further for an Authorized Peer. Access Control Lists are 255 stored within a RELOAD array data model. They are initially created 256 by the Resource Owner. 258 Figure 1 shows an example of an Access Control List. We omit the 259 resource_name field to simplify illustration. The array entry at 260 index 0x123abc001 displays the initial entry of an ACL about a Shared 261 Resource of Kind-ID 1234 at the same Resource-ID. It represents the 262 root item of the trust delegation tree for this shared RELOAD Kind. 263 The root entry MUST contain the mapping from Resource owner to 264 Resource owner and MUST only be written by the owner of the public 265 key certificate associated with this Resource-ID. The array index is 266 generated by using the mechanism for isolating stored data as 267 described in Section 3.1. Hence, the most significant 24 bits of the 268 array index (0x123abc) are the least significant 24bits of the 269 Node-ID of the Resource Owner. 271 The array item at index 0x123abc002 represents the first trust 272 delegation to an Authorized Peer, which is thus permitted write 273 access to the Shared Resource of Kind-ID 1234. Additionally, the 274 Authorized peer Alice is also granted (limited) write access to the 275 ACL as indicated by the allow_delegation flag (ad) set to 1. This 276 configuration authorizes Alice to store further trust delegations to 277 the Shared Resource i.e., add items to the ACL. In contrast to this, 278 index 0x456def001 illustrates trust delegation for Kind-ID 1234, in 279 which the Authorized Peer Bob is not allowed to grant access to 280 further peers (ad = 0). Each Authorized Peer signs its ACL items 281 with its own private key. 283 In order to maintain Shared Resource access for multiple Kinds at a 284 single location, the Resource Owner can create new ACL entries that 285 refer to another Kind-ID as shown in array entry index 0x123abc003. 286 Note, that overwriting existing items in an Access Control List that 287 reference a different Kind-ID revokes all trust delegations in the 288 tree (see Section 6.2). Hence, Authorized Peers are not enabled to 289 overwrite any existing ACL item . The Resource Owner is allowed to 290 overwrite existing ACL items, but should be aware of its 291 consequences. 293 +---------------------------------------------------------------+ 294 | Access Control List | 295 +-----------+---------------------------------------+-----------+ 296 | #Index | Array Entries | signed by | 297 +-----------+---------------------------------------+-----------+ 298 | 123abc001 | user:Owner -> to:Owner Kind:1234 ad:1 | Owner | 299 +-----------+---------------------------------------+-----------+ 300 | 123abc002 | user:Owner -> to:Alice Kind:1234 ad:1 | Owner | 301 +-----------+---------------------------------------+-----------+ 302 | 123abc003 | user:Owner -> to:Owner Kind:4321 ad:1 | Owner | 303 +-----------+---------------------------------------+-----------+ 304 | 123abc004 | user:Owner -> to:Carol Kind:4321 ad:0 | Owner | 305 +-----------+---------------------------------------+-----------+ 306 | ... | ... | ... | 307 +-----------+---------------------------------------+-----------+ 308 | 456def001 | user:Alice -> to:Bob Kind:1234 ad:0 | Alice | 309 +-----------+---------------------------------------+-----------+ 310 | ... | ... | ... | 311 +-----------+---------------------------------------+-----------+ 313 Figure 1: Simplified example of an Access Control including entries 314 for two different Kind-IDs and varying delegation (ad) configurations 316 Implementations of ShaRe should be aware that the trust delegation in 317 an Access Control List need not be loop free. Self-contained 318 circular trust delegation from A to B and B to A are possible, even 319 though not very meaningful. 321 4.2. Data Structure 323 The Kind data structure for the Access Control List is defined as 324 follows: 326 struct { 327 opaque resource_name<0..2^16-1>; 328 opaque user_name<0..2^16-1>; 329 opaque to_user<0..2^16-1>; 330 KindId kind; 331 Boolean allow_delegation; 332 } AccessControlListData; 334 struct { 335 uint16 length; 336 AccessControlListData data; 337 } AccessControlListItem; 339 The AccessControlListItem structure is composed of: 341 length: This field contains the length of the Access Control List 342 data structure 344 data: This field contains the data of an ACL item 346 The content of the AccessControlListData structure is defined as 347 follows: 349 resource_name: This opaque string represents the Resource Name of 350 the Shared Resource as an opaque string. It is used by the 351 storing peer to validate whether a variable Resources Name matches 352 the corresponding pattern defined in the configuration document. 354 user_name: This field contains the username of that RELOAD peer the 355 grants write permission to the Shared Resource. The username is 356 stored as an opaque string and contains the username value from 357 the certificate that is associated with the private key that 358 signed this Access Control List item. 360 to_user: This field contains the username of the RELOAD peer that 361 obtains writing permission to the Shared Resource. 363 kind: This field contains the Kind-ID of the Shared Resource. 365 allow_delegation: If true, this Boolean flag indicates that the 366 Authorized Peer in the 'to_user' field is allowed to add 367 additional entries into the ACL for the specified Kind-ID. 369 The ACCESS-CONTROL-LIST kind is defined as follows: 371 Name: ACCESS-CONTROL-LIST 373 Data model: The Data model for the ACCESS-CONTROL-LIST data is 374 array. 376 Access Control: USER-CHAIN-ACL access policy (see Section 6.4). 378 5. Extension for Variable Resource Names 380 5.1. Overview 382 In certain use cases such as conferencing (c.f. 383 [I-D.knauf-p2psip-disco]) it is desirable to extend the set of 384 Resource Names and thus Resource-IDs a peer is allowed to write 385 beyond those defined through the username or Node-ID fields in its 386 certificate. Therefore, this document presents the concept for 387 variable Resources Names that enables providers of RELOAD instances 388 to define a relaxed naming scheme for overlay Resources. 390 Each RELOAD node uses a certificate to identify itself using its user 391 name (or Node-ID) while storing data under a specific Resource-ID. 392 The specifications in this document scheme follows this paradigm by 393 allowing to store values whose Resource Names are derived from the 394 username in the certificate of a RELOAD peer. This is done by using 395 a Resource Name which contains a variable substring but matches the 396 username in the certificate using a pattern defined in the overlay 397 configuration document. Thus despite being variable an allowed 398 Resource Name is closely related to the Owner's certificate. A 399 sample pattern might be formed as the following: 401 Example Pattern: 402 .*-conf-$USER@$DOMAIN 404 When defining the pattern care must be taken that no conflict arises 405 for two usernames of witch one is a substring of the other. In this 406 case the peer with the name which is the substring could choose the 407 variable part of the Resource Name so that the resulting string 408 contains the whole other username and thus he could write the other 409 user's resources. This can easily be prevented by delimiting the 410 variable part of the pattern from the username part by some fixed 411 string, that is usually not part of a username (e.g. the "-conf-" in 412 the above Example). 414 5.2. Overlay Configuration Document Extension 416 This document extends the overlay configuration document by defining 417 new elements for patterns relating resource names to user names. 419 The element serves as a container for one 420 or multiple sub-elements. It is an additional parameter 421 within the kind block. 423 Each element defines the pattern to be used for a single 424 Kind. It is of type xsd:string, which is interpreted as a regular 425 expression. In the regular expression $USER and $DOMAIN are used as 426 variables for the corresponding parts of the string in the 427 certificate username field ($USER before and $DOMAIN after the '@'). 428 Both variables MUST be present in any given pattern. 430 A element MUST be present for every Kind using the USER- 431 CHAIN-MATCH access policy Section 6.4. 433 The Relax NG Grammar for the Variable Resource Names Extension is: 435 437 namespace share = "urn:ietf:params:xml:ns:p2p:config-base:share" 439 441 kind-parameter &= element share:variable-resource-names { 443 445 element pattern { xsd:string }* 446 }? 448 6. Access Control to Shared Resources 450 6.1. Granting Write Access 452 Write access to a Kind that is intended to be shared with other 453 RELOAD users can solely be issued by the Resource Owner. A Resource 454 Owner can share RELOAD Kinds by using the following procedure: 456 o The Resource Owner stores an ACL root item at the same Resource-ID 457 as the Shared Resource. The root item contains the Resource Name 458 and Kind-ID of the Shared Resource in the "resource_name" field 459 and "Kind-ID" fields. It further contains the username of the 460 Resource Owner in the "user_name" and "to_user" field. The "ad" 461 flag SHOULD be set to 1. The array index of MUST be generated as 462 described in Section 3.1 464 o Further ACL items stored by the Resource Owner will delegate write 465 access to the Shared Resource. These ACL items contain the same 466 Resource Name, Kind-ID and "user_name" values as the root item. 467 Each "to_user" field is set to the username of an Authorized Peer. 468 Optionally, the Resource Owner sets the "ad" to 1 (we define 0 as 469 default). Each succeeding ACL item created by the Resource Owner 470 MAY be stored in the numerical order of the array index starting 471 with the index of the root item plus one. 473 An Authorized Peer (with "ad"=1) can further share an exiting Shared 474 Resource as follows: 476 o An Authorized Peer stores one or more ACL items at the Resource-ID 477 of the Shared Resource. These ACL items contain the shared 478 Resource Name and Kind-Id in the "resource_name" field and 479 "Kind-ID" fields. The "user_name" value is set to the username of 480 the Authorized Peer and the "to_user" value is set to username of 481 the added Authorized Peer. Optionally, the "ad" flag could be set 482 to 1. The array index of MUST be generated as described in 483 Section 3.1. Each succeeding ACL item MAY be stored in the 484 numerical order of the array index. 486 6.2. Revoking Write Access 488 Write permissions MAY be revoked by soring a non-existent value 489 [I-D.ietf-p2psip-base] to the corresponding item in the Access 490 Control List. A revoked permission automatically invalidates all 491 delegations performed by that user and also all subsequent 492 delegations. This allows to invalidate entire subtrees of the 493 delegations tree with only a single operation. Overwriting the root 494 item with a non-existent value of an Access List invalidates the 495 entire delegations tree. 497 An ACL item MUST only be written by the user who initially stored the 498 corresponding entry. The only exception is by the Resource Owner 499 that is allowed to overwrite every single ACL item for revoking write 500 access. 502 6.3. Storage and Validation 504 6.3.1. Operations of the Storing Peer 506 The storing peer (the peer at which Shared Resource and Access List 507 are physically stored) is responsible to control storing attempts on 508 a Shared Resource and the corresponding Access Control List. To 509 assert the USER-CHAIN-ACL (see Section 6.4) access policy a storing 510 peer need to implement several operations to validate a store attempt 511 on a Shared Resource. The following ACL validation mechanism has to 512 be performed on an incoming store request to a Shared Resource by an 513 Authorized Peer: 515 1. The storing peer sends a Stat request to Resource-ID of the 516 Shared Resource to obtain all array indexes of stored ACL Kinds. 518 2. Using the retrieved meta information, the storing peer fetches 519 for all ACL Kinds at this Resource-ID. Since the ACL is stored 520 at the storing peer, both operations are local lookups. 522 3. The storing peer then validates if any of the retrieved ACL items 523 contains a user_name field whose value is equal to the username 524 in the certificate of the Authorized Peer and, if the Kind value 525 is equal the Kind-ID of the Shared Resource. 527 4. If the requested Shared Resource is an Access Control List Kind, 528 the storing peer MUST further validate if the "ad" flag is set to 529 1. 531 5. If true, the ACL validation procedure returns true. 533 A storing peer MAY validate the entire ACL to a Shared Resource on an 534 inbound store request. Beginning at the ACL item from the above ACL 535 validation procedure, the storing peer validates if any ACL item with 536 the same Kind-ID has a "user_name" value equal to the "to_user" value 537 of recently validated ACL item. If true, the validation continues 538 with the next ACL item with any other ACL item with the same Kind-ID. 539 This procedure continues until an ACL item is found with "user_name" 540 is equal "to_user". Then, if this "user_name" value hashes to the 541 Resource-ID or it matches the variable resource name pattern and the 542 corresponding "resource_name" value hashes to the Resource-ID, the 543 ACL root validation returns true. 545 If a store request by an Authorized Peer would overwrite and ACL item 546 from another Authorized Peer (or Resource Owner), an Error_Forbidden 547 response MUST be returned. The probability of a collision of two or 548 more identical array index will be negligibly low using the mechanism 549 for isolated stored data (see Section 3.1) 551 6.3.2. Operations of the Accessing Peer 553 The accessing peer (a RELOAD peer that fetches a Shared Resource) 554 SHOULD validate whether its originator was allowed to store at this 555 Resource-ID by processing the corresponding ACL. The accessing peer 556 previously performs Stat request to retrieve the meta information at 557 the Resource-ID of the Shared Resource. Then, it fetches all 558 existing ACL Kinds at this location. After retrival, the accessing 559 peer compares the "to_user" value of each ACL item with the mandatory 560 "user_name" field of the Shared Resource for equality. If the 561 comparison fails, the accessing peer MUST ignore the data of the 562 retrieved Shared Resource. 564 Else, the accessing peer MAY validate whether the "user_name" value 565 of recently observed ACL item exist in any other "to_user" field in 566 the corresponding ACL. If true, this procedure continues with the 567 next ACL item with any other ACL item of the list. The procedure 568 contiues until both "user_name" and "to_user" values are equal, thus 569 the root item to the ACL is found. The Shared Resource and 570 corresponding ACL are permitted at this location if the hash over the 571 "user_name" value equals to the Resource-ID. Or otherwise, if the 572 "user_name" value matches the corresponding variable resource name 573 pattern defined in the configuration document and the hash over the 574 corresponding "resource_name" value matches the Resource-ID 576 The accessing peer can further verify provenance and integrity of the 577 retrieved Shared Resource using the certificate corresponding to the 578 mandatory user_name field of the Shared Resource entry. The 579 certificate can be retrieved by applying the Certificate Usage 580 [I-D.ietf-p2psip-base] or other means (e.g., caching from a previous 581 request). 583 The accessing peer MAY cache previously fetched Access Control Lists 584 to a maximum of the individual items' lifetimes. Since stored values 585 could have been changed or invalidated prior to their expiration an 586 accessing peer uses a Stat request to check for updates before using 587 the cached data. If a change has been detected it fetches the latest 588 Access Control List. 590 6.4. USER-CHAIN-ACL Access Policy 592 This document specifies an additional access control policy to the 593 RELOAD base draft [I-D.ietf-p2psip-base]. The USER-CHAIN-ACL policy 594 allows Authorized Peers to write a Shared Resource, even though they 595 do not own the corresponding certificate. Additionally, the USER- 596 CHAIN-MATCH allows the storage of Kinds with a variable resource name 597 that are following the specified naming pattern. Hence, on an 598 inbound store request on a Kind that uses the USER-CHAIN-ACL access 599 policy, the following rules MUST applied: 601 In the USER-CHAIN-ACL policy, a given value MUST be written or 602 overwritten if either one of USER-MATCH or USER-NODE-MATCH (mandatory 603 if the data model is dictionary) access policies of the base document 604 [I-D.ietf-p2psip-base] applies. 606 Otherwise, the value MUST be written if the certificate of the signer 607 contains a username that matches to the variable resource name 608 pattern (c.f. Section 5) specified in the configuration document 609 and, additionally, the hashed Resource Name matches the Resource-ID. 610 The Resource Name of the Kind been stored MUST be taken from the 611 mandatory resource_name field in the corresponding Kind data 612 structure. 614 Otherwise, the value MUST be written if the ACL Validation procedure 615 as described in Section 6.3.1 returns true. 617 7. Security Considerations 619 In this section we discuss security issues that are relevant to the 620 usage of shared resources in RELOAD. 622 7.1. Resource Exhaustion 624 Joining a RELOAD overlay inherently poses a certain resource load on 625 a peer, because it has to store and forward data for other peers. In 626 common RELOAD semantics, each Resource ID and thus position in the 627 overlay may only be written by a limited set of peers - often even 628 only a single peer, which limits this burden. In the case of Shared 629 Resources, a single resource may be written by multiple peers, who 630 may even write an arbitrary number of entries (e.g., delegations in 631 the ACL). This leads to an enhanced use of resources at individual 632 overlay nodes. The problem of resource exhaustion can easily be 633 mitigated for Usages based on the ShaRe-Usage by imposing 634 restrictions on size, i.e., element for a certain Kind in 635 the configuration document. 637 7.2. Malicious or Misbehaving Storing Peer 639 The RELOAD overlay is designed to operate despite the presence of a 640 small set of misbehaving peers. This is not different for Shared 641 Resources since a small set of malicious peers does not disrupt the 642 functionality of the overlay in general, but may have implications 643 for the peers needing to store or access information at the specific 644 locations in the ID space controlled by a malicious peer. A storing 645 peer could withhold stored data which results in a denial of service 646 to the group using the specific resource. But it could not return 647 forged data, since the validity of any stored data can be 648 independently verified using the attached signatures. 650 7.3. Privacy Issues 652 All data stored in the Shared Resource is publicly readable, thus 653 applications requiring privacy need to encrypt the data. The ACL 654 needs to be stored unencrypted, thus the list members of a group 655 using a Shared Resource will always be publicly visible. 657 8. IANA Considerations 659 TODO: register Kind-ID code point at the IANA 661 9. Acknowledgments 663 This work was stimulated by fruitful discussions in the P2PSIP 664 working group and SAM research group. We would like to thank all 665 active members for constructive thoughts and feedback. In 666 particular, the authors would like to thank (in alphabetical order) 667 Lothar Grimm, Cullen Jennings, Peter Musgrave, Joerg Ott, Marc Petit- 668 Huguenin, Peter Pogrzeba, and Jan Seedorf. This work was party 669 funded by the German Federal Ministry of Education and Research, 670 projects HAMcast and Mindstone. 672 10. References 674 10.1. Normative References 676 [I-D.ietf-p2psip-base] 677 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 678 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 679 Base Protocol", draft-ietf-p2psip-base-16 (work in 680 progress), July 2011. 682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", BCP 14, RFC 2119, March 1997. 685 10.2. Informative References 687 [I-D.ietf-p2psip-concepts] 688 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 689 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 690 draft-ietf-p2psip-concepts-03 (work in progress), 691 October 2010. 693 [I-D.knauf-p2psip-disco] 694 Knauf, A., Hege, G., Schmidt, T., and M. Waehlisch, "A 695 RELOAD Usage for Distributed Conference Control (DisCo)", 696 draft-knauf-p2psip-disco-02 (work in progress), 697 March 2011. 699 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 700 Jacobson, "RTP: A Transport Protocol for Real-Time 701 Applications", STD 64, RFC 3550, July 2003. 703 Appendix A. Change Log 705 The following changes have been made from version 706 draft-knauf-p2psip-share-00: 708 1. Integrated the USER-PATTERN-MATCH access policy into USER-CHAIN- 709 MATCH 711 2. Access Control List Kind uses USER-CHAIN-ACL exclusively 713 3. Resources to be shared use USER-CHAIN-ACL exclusively 715 4. More precise specification of mandatory User_name and 716 Resource_name fields for Shared Resources 718 5. Added mechanism for isolating stored data to prevent race 719 conditions while concurrent storing 721 6. XML Extension for variable resource names uses its own namespace 723 7. Many editorial improvements 725 Authors' Addresses 727 Alexander Knauf 728 HAW Hamburg 729 Berliner Tor 7 730 Hamburg D-20099 731 Germany 733 Phone: +4940428758067 734 Email: alexander.knauf@haw-hamburg.de 735 URI: http://inet.cpt.haw-hamburg.de/members/knauf 737 Gabriel Hege 738 HAW Hamburg 739 Berliner Tor 7 740 Hamburg D-20099 741 Germany 743 Phone: +4940428758067 744 Email: hege@fhtw-berlin.de 745 URI: http://inet.cpt.haw-hamburg.de/members/hege 747 Thomas C. Schmidt 748 HAW Hamburg 749 Berliner Tor 7 750 Hamburg D-20099 751 Germany 753 Email: schmidt@informatik.haw-hamburg.de 754 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 756 Matthias Waehlisch 757 link-lab & FU Berlin 758 Hoenower Str. 35 759 Berlin D-10318 760 Germany 762 Email: mw@link-lab.net 763 URI: http://www.inf.fu-berlin.de/~waehl