idnits 2.17.1 draft-knauf-p2psip-share-03.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 == Line 336 has weird spacing: '...tension res_n...' -- The document date (April 25, 2012) is 4376 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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-21 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-04 == Outdated reference: A later version (-05) exists of draft-knauf-p2psip-disco-04 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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: October 27, 2012 HAW Hamburg 6 M. Waehlisch 7 link-lab & FU Berlin 8 April 25, 2012 10 A Usage for Shared Resources in RELOAD (ShaRe) 11 draft-knauf-p2psip-share-03 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 October 27, 2012. 43 Copyright Notice 45 Copyright (c) 2012 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 . . . . . . . . . . . . 10 68 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 10 70 5.3. Overlay Configuration Document Extension . . . . . . . . . 11 71 6. Access Control to Shared Resources . . . . . . . . . . . . . . 13 72 6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 13 73 6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 14 74 6.3. Validating Write Access through an ACL . . . . . . . . . . 14 75 6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 15 76 6.5. Operations of Accessing Peers . . . . . . . . . . . . . . 15 77 6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . . 15 78 7. ACL Kind Definition . . . . . . . . . . . . . . . . . . . . . 17 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 18 81 8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 18 82 8.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 18 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 87 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 88 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 91 1. Introduction 93 This document defines a RELOAD Usage for managing shared write access 94 to RELOAD Resources and a mechanism to store Resources with a 95 variable name. The Usage for Shared Resources in RELOAD (ShaRe) 96 enables overlay users to share their exclusive write access to 97 specific Resource/Kind pairs with others. Shared Resources form a 98 basic primitive for enabling various coordination and notification 99 schemes among distributed peers. Write permission is controlled by 100 an Access Control List (ACL) Kind that maintains a chain of 101 Authorized Peers for a particular Shared Resource. A newly defined 102 USER-CHAIN-ACL access control policy enables shared write access in 103 RELOAD. 105 The Usage for Shared Resources in RELOAD is designed for jointly 106 coordinated group applications among distributed peers (e.g., third 107 party registration, or distributed conferencing, 108 see[I-D.knauf-p2psip-disco]). Of particular interest are rendezvous 109 processes, where a single identifier is linked to multiple, dynamic 110 instances of a distributed cooperative service. Shared write access 111 is based on a trust delegation mechanism. It transfers the 112 authorization to write a specific Kind data by storing logical Access 113 Control Lists. An ACL contains the ID of the Kind to be shared and 114 contains trust delegations from one authorized to another (previously 115 unauthorized) user. 117 Shared write access augments the RELOAD security model, which is 118 based on the restriction that peers are only allowed to write 119 resources at a small set of well defined locations (Resource-IDs) in 120 the overlay. Using the standard access control rules in RELOAD, 121 these locations are bound to the username or Node-ID in the peer's 122 certificate. This document extends the base policies to enable a 123 controlled write access for multiple users to a common Resource Id. 125 Additionally, this specification defines an optional mechanism to 126 store Resources with a variable Resource Name. It enables the 127 storage of Resources whose name complies to a specific pattern. 128 Definition of the pattern is arbitrary, but must contain the username 129 of the Resource creator. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 This document uses the terminology and definitions from the RELOAD 138 base [I-D.ietf-p2psip-base]and the peer-to-peer SIP concepts draft 139 [I-D.ietf-p2psip-concepts]. Additionally, the following terms are 140 used: 142 Shared Resource: The term Shared Resource in this document defines a 143 RELOAD Resource with its associated Kinds, that can be written or 144 overwritten by multiple RELOAD users following the specifications 145 in this document. 147 Access Control List: The term Access Control List in this document 148 defines a logical list of RELOAD users allowed to write a specific 149 RELOAD Resource/Kind pair by following the specifications in this 150 document. The list items are stored as Access Control List Kinds 151 that map trust delegations from user A to user B, where A is 152 allowed to write a Shared Resource and the Access Control List, 153 while B is a user that obtains write access to specified Kinds 154 from A. 156 Resource Owner: The term Resource Owner in this document defines a 157 RELOAD peer that initially stored a Resource to be shared. The 158 Resource Owner possesses the RELOAD certificate that grants write 159 access to a specific Resource/Kind pair using the RELOAD 160 certificate-based access control policies. 162 Authorized Peer: The term Authorized Peer in this document defines a 163 RELOAD peer that was granted write access to a Shared Resource by 164 permission of the Resource Owner or another Authorized Peer. 166 3. Shared Resources in RELOAD 168 A RELOAD user that owns a certificate for writing at a specific 169 overlay location can maintain one or more RELOAD Kinds that are 170 designated for a non-exclusive write access shared with other RELOAD 171 users. The mechanism to share those Resource/Kind pairs with a group 172 of users consists of two basic steps. 174 1. Storage of the Resource/Kind pairs to be shared. 176 2. Storage of an Access Control List (ACL) associated with those 177 Kinds. 179 ACLs are created by the Resource Owner and contain ACL items, each 180 delegating the permission of writing the shared Kind to a specific 181 user called Authorized Peer. For each shared Kind data, its Resource 182 owner stores a root item that initiates an Access Control List. 183 Trust delegation to the Authorized Peer can include the right to 184 further delegate the write permission, enabling a tree of trust 185 delegations with the Resource Owner as trust anchor at its root. 187 The Resource/Kind pair to be shared can be any RELOAD Kind that 188 complies to the following specifications: 190 Isolated Data Storage: To prevent concurrent writing from race 191 conditions, each data item stored within a Shared Resource SHALL 192 be exclusively maintained by the RELOAD user who created it. 193 Hence, Usages that allow the storage of Shared Resources are 194 REQUIRED to use either the array or dictionary data model and 195 apply additional mechanisms for isolating data as described in 196 Section 3.1. 198 Access Control Policy: To ensure write access to Shared Resource by 199 Authorized Peers, each Usage MUST use the USER-CHAIN-ACL access 200 policy as described in Section 6.6. 202 Resource Name Extension: To enable Shared Resources to be stored 203 using a variable resource name, this document defines an optional 204 ResourceNameExtension structure. It contains the Resource Name of 205 the Kind data to be stored and allows any receiver of a shared 206 data to validate whether the Resource Name hashes to the 207 Resource-ID. The ResourceNameExtension is made optional by 208 configuration. The ResourceNameExtension field is only present in 209 the Kind data structure when configured in the corresponding kind- 210 block of the overlay configuration document (for more details see 211 Section 5.3). If the configuration allows variable resource 212 names, a Kind using the USER-CHAIN-ACL policy MUST use the 213 ResourceNameExtension as initial field within the Kind data 214 structure definition. Otherwise the Kind data structure does not 215 contain the ResourceNameExtension structure. 217 3.1. Mechanisms for Isolating Stored Data 219 This section defines mechanisms to avoid race conditions while 220 concurrently writing an array or dictionary of a Shared Resource. 222 If a dictionary is used in the Shared Resource, the dictionary key 223 MUST be the Node-ID of the certificate that will be used to sign the 224 stored data. Thus data access is bound to the unique ID-holder. 226 If the data model of the Shared Resource is an array, the following 227 algorithm will generate an array index that avoids collisions. 229 1. Obtain the Node-ID of the certificate that will be used to sign 230 the stored data 232 2. Take the least significant 24 bits of that Node-ID 234 3. Concatenate an 8 bit long short individual index value to those 235 24 bit of the Node-ID 237 The resulting 32 bits long integer MUST be used as the index for 238 storing an array entry in a Shared Resource. The 8 bit individual 239 index can be incremented individually for further array entries and 240 allows for 256 distinct entries per Peer. 242 The mechanism to create the array index is related to the pseudo- 243 random algorithm to generate an SSRC identifier in RTP, see Section 244 8.1 in [RFC3550] for calculating the probability of a collision. 246 4. Access Control List Definition 248 4.1. Overview 250 An Access Control List (ACL) is a (self-managed) shared resource that 251 contains a list of AccessControlListItem structures as defined in 252 Section 4.2. Each entry delegates write access for a specific Kind 253 data to a single RELOAD user. An ACL enables the RELOAD user who is 254 authorized to write a specific Resource-ID to delegate his exclusive 255 write access to a specific Kind to further users of a RELOAD 256 instance. Each Access Control List data structure therefore carries 257 the information about who obtains write access, the Kind-ID of the 258 Resource to be shared, and whether delegation includes write access 259 to the ACL itself. The latter condition grants the right to delegate 260 write access further for the Authorized Peer. Access Control Lists 261 are stored at the same overlay location as the Shared Resource and 262 use the RELOAD array data model. They are initially created by the 263 Resource Owner. 265 Figure 1 shows an example of an Access Control List. We omit the 266 res_name_ext field to simplify illustration. The array entry at 267 index 0x123abc001 displays the initial creation of an ACL for a 268 Shared Resource of Kind-ID 1234 at the same Resource-ID. It 269 represents the root item of the trust delegation tree for this shared 270 RELOAD Kind. The root entry MUST contain the username of the 271 Resource owner in the "to_user" field and can only be written by the 272 owner of the public key certificate associated with this Resource-ID. 273 The allow_delegation (ad) flag for a root ACL item is set to 1 by 274 default. The array index is generated by using the mechanism for 275 isolating stored data as described in Section 3.1. Hence, the most 276 significant 24 bits of the array index (0x123abc) are the least 277 significant 24 bits of the Node-ID of the Resource Owner. 279 The array item at index 0x123abc002 represents the first trust 280 delegation to an Authorized Peer that is thus permitted to write to 281 the Shared Resource of Kind-ID 1234. Additionally, the Authorized 282 peer Alice is also granted (limited) write access to the ACL as 283 indicated by the allow_delegation flag (ad) set to 1. This 284 configuration authorizes Alice to store further trust delegations to 285 the Shared Resource, i.e., add items to the ACL. On the contrary, 286 index 0x456def001 illustrates trust delegation for Kind-ID 1234, in 287 which the Authorized Peer Bob is not allowed to grant access to 288 further peers (ad = 0). Each Authorized Peer signs its ACL items 289 with its own private key, which makes the item ownership transparent. 291 To manage Shared Resource access of multiple Kinds at a single 292 location, the Resource Owner can create new ACL entries that refer to 293 another Kind-ID as shown in array entry index 0x123abc003. Note that 294 overwriting existing items in an Access Control List that reference a 295 different Kind-ID revokes all trust delegations in the corresponding 296 subtree (see Section 6.2). Authorized Peers are only enabled to 297 overwrite existing ACL item they own. The Resource Owner is allowed 298 to overwrite any existing ACL item, but should be aware of its 299 consequences. 301 +------------------------------------------------------+ 302 | Access Control List | 303 +-----------+------------------------------+-----------+ 304 | #Index | Array Entries | signed by | 305 +-----------+------------------------------+-----------+ 306 | 123abc001 | to_user:Owner Kind:1234 ad:1 | Owner | 307 +-----------+------------------------------+-----------+ 308 | 123abc002 | to_user:Alice Kind:1234 ad:1 | Owner | 309 +-----------+------------------------------+-----------+ 310 | 123abc003 | to_user:Owner Kind:4321 ad:1 | Owner | 311 +-----------+------------------------------+-----------+ 312 | 123abc004 | to_user:Carol Kind:4321 ad:0 | Owner | 313 +-----------+------------------------------+-----------+ 314 | ... | ... | ... | 315 +-----------+------------------------------+-----------+ 316 | 456def001 | to_user:Bob Kind:1234 ad:0 | Alice | 317 +-----------+------------------------------+-----------+ 318 | ... | ... | ... | 319 +-----------+------------------------------+-----------+ 321 Figure 1: Simplified example of an Access Control including entries 322 for two different Kind-IDs and varying delegation (ad) configurations 324 Implementations of ShaRe should be aware that the trust delegation in 325 an Access Control List need not be loop free. Self-contained 326 circular trust delegation from A to B and B to A are syntactically 327 possible, even though not very meaningful. 329 4.2. Data Structure 331 The Kind data structure for the Access Control List is defined as 332 follows: 334 struct { 335 /* res_name_ext is optional, see documentation */ 336 ResourceNameExtension res_name_ext; 337 opaque to_user<0..2^16-1>; 338 KindId kind; 339 Boolean allow_delegation; 340 } AccessControlListItem; 341 The AccessControlListItem structure is composed of: 343 res_name_ext: This optional field contains the Resource Name of a 344 ResourceNameExtension (see Section 5.2) to be used by a Shared 345 Resource with variable resource name. This name serves the 346 storing peer for validating, whether a variable resources name 347 matches one of the predefined naming pattern from the 348 configuration document for this Kind. The presence of this field 349 is bound to a variable resource name element in the corresponding 350 kind-block of the configuration document whose "enable" attribute 351 is set to true (see Section 5.3). Otherwise, if the "enable" 352 attribute is false, the res_name_ext field SHALL NOT be present in 353 the Kind data structure. 355 to_user: This field contains the username of the RELOAD peer that 356 obtains write permission to the Shared Resource. 358 kind: This field contains the Kind-ID of the Shared Resource. 360 allow_delegation: If true, this Boolean flag indicates that the 361 Authorized Peer in the 'to_user' field is allowed to add 362 additional entries to the ACL for the specified Kind-ID. 364 5. Extension for Variable Resource Names 366 5.1. Overview 368 In certain use cases such as conferencing (c.f. 369 [I-D.knauf-p2psip-disco]) it is desirable to increase the flexibility 370 of a peer in using Resource Names beyond those defined by the 371 username or Node-ID fields in its certificate. For this purpose, 372 this document presents the concept for variable Resources Names that 373 enables providers of RELOAD instances to define relaxed naming 374 schemes for overlay Resources. 376 Each RELOAD node uses a certificate to identify itself using its user 377 name (or Node-ID) while storing data under a specific Resource-ID. 378 The specifications in this document scheme adhere to this paradigm, 379 but enable a RELOAD peer to store values of Resource Names that are 380 derived from the username in its certificate. This is done by using 381 a Resource Name with a variable substring that still matches the 382 username in the certificate using a pattern defined in the overlay 383 configuration document. Thus despite being variable, an allowable 384 Resource Name remains tied to the Owner's certificate. A sample 385 pattern might be formed as follows. 387 Example Pattern: 388 .*-conf-$USER@$DOMAIN 390 When defining the pattern, care must be taken to avoid conflicts 391 arising from two usernames of witch one is a substring of the other. 392 In such cases, the holder of the shorter name could threaten to block 393 the resources of the longer-named peer by choosing the variable part 394 of a Resource Name to contain the entire longer username. This 395 problem can easily be mitigated by delimiting the variable part of 396 the pattern from the username part by some fixed string, that by 397 convention is not part of a username (e.g., the "-conf-" in the above 398 Example). 400 5.2. Data Structure 402 This section defines the optional ResourceNameExtension structure for 403 every Kind that uses the USER-CHAIN-ACL access control policy. 405 enum { pattern (1), 406 (255)} ResourceNameType; 408 struct { 409 ResourceNameType type; 410 uint16 length; 411 select(type) { 412 case pattern: 413 opaque resource_name<0..2^16-1>; 415 /* Types can be extended */ 416 } 417 } ResourceNameExtension 419 The content of the ResourceNameExtension consist of 421 length: This field contains the length of the remaining data 422 structure. It is only used to allow for further extensions to 423 this data structure. 425 The content of the rest of the data structure depends of the 426 ResourceNameType. Currently, the only defined type is "pattern". 428 If the type is "pattern", then the following data structure contains 429 an opaque <0..2^16-1> field containing the Resource Name of the Kind 430 being stored. The type "pattern" further indicates that the Resource 431 Name MUST match to one of the variable resource name pattern defined 432 for this Kind in the configuration document. 434 The ResourceNameType enum and the ResourceNameExtension structure can 435 be extended by further Usages to define other naming schemes. 437 5.3. Overlay Configuration Document Extension 439 This section extends the overlay configuration document by defining 440 new elements for patterns relating resource names to user names. 442 The element serves as a container for one 443 or multiple sub-elements. It is an additional parameter 444 within the kind block and has a boolean "enable" attribute that 445 indicates, if true, that the overlay provider allows variable 446 resource names for this Kind. The default value of the "enable" 447 attribute is "false". In the absence of a 448 element for a Kind using the USER-CHAIN-ACL access policy (see 449 Section 6.6), implementors SHOULD assume this default value. 451 A element MUST be present if the "enabled" attribute of its 452 parent element is set to true. Each element defines a 453 pattern for constructing extended resource names for a single Kind. 454 It is of type xsd:string and interpreted as a regular expression. In 455 this regular expression, $USER and $DOMAIN are used as variables for 456 the corresponding parts of the string in the certificate username 457 field (with $USER preceding and $DOMAIN succeeding the '@'). Both 458 variables MUST be present in any given pattern definition. If no 459 pattern is defined for a Kind or the "enabled" attribute is false, 460 allowable Resource Names are restricted to the username of the signer 461 for Shared Resource. 463 The Relax NG Grammar for the Variable Resource Names Extension reads: 465 467 namespace share = "urn:ietf:params:xml:ns:p2p:config-base:share" 469 471 kind-parameter &= element share:variable-resource-names { 473 attribute enable { xsd:boolean } 475 477 element pattern { xsd:string }* 478 }? 480 6. Access Control to Shared Resources 482 6.1. Granting Write Access 484 Write access to a Kind that is intended to be shared with other 485 RELOAD users can solely be issued by the Resource Owner. A Resource 486 Owner can share RELOAD Kinds by using the following procedure. 488 o The Resource Owner stores an ACL root item at the Resource-ID of 489 the Shared Resource. The root item contains the resource name 490 extension field (see Section 5.2), the username of the Resource 491 Owner and Kind-ID of the Shared Resource. The allow_delegation 492 flag is set to 1. The index of array data structure MUST be 493 generated as described in Section 3.1 495 o Further ACL items for this Kind-ID stored by the Resource Owner 496 will delegate write access to Authorized Peers. These ACL items 497 contain the same resource name extension field, the username of 498 the Authorized Peer and the Kind-Id of the Shared Resource. 499 Optionally, the Resource Owner sets the "ad" to 1 (the default 500 equals 0) to enable the Authorized Peer to further delegate write 501 access. Each succeeding ACL item created by the Resource Owner 502 can be stored in the numerical order of the array index starting 503 with the index of the root item incremented by one. 505 An Authorized Peer with delegation allowance ("ad"=1) can extend the 506 access to an existing Shared Resource as follows. 508 o An Authorized Peer can store additional ACL items at the 509 Resource-ID of the Shared Resource. These ACL items contain the 510 resource name extension field, the username of the newly 511 Authorized Peer, and the Kind-Id of the Shared Resource. 512 Optionally, the "ad" flag is set to 1 for allowing the Authorized 513 Peer to further delegate write access. The array index MUST be 514 generated as described in Section 3.1. Each succeeding ACL item 515 can be stored in the numerical order of the array index. 517 A store request by an Authorized Peer that attempts to overwrite any 518 ACL item signed by another Peer is unauthorized and causes an 519 Error_Forbidden response from the Storing Peer. Such access 520 conflicts could be caused by an array index collision. However, the 521 probability of a collision of two or more identical array indices 522 will be negligibly low using the mechanism for isolating stored data 523 (see Section 3.1) 525 6.2. Revoking Write Access 527 Write permissions are revoked by storing a non-existent value 528 [I-D.ietf-p2psip-base] at the corresponding item of the Access 529 Control List. Revoking a permission automatically invalidates all 530 delegations performed by that user including all subsequent 531 delegations. This allows to invalidate entire subtrees of the 532 delegations tree with only a single operation. Overwriting the root 533 item with a non-existent value of an Access List invalidates the 534 entire delegations tree. 536 An existing ACL item MUST only be overwritten by the user who 537 initially stored the corresponding entry, or by the Resource Owner 538 that is allowed to overwrite all ACL items for revoking write access. 540 6.3. Validating Write Access through an ACL 542 Access Control Lists are used to transparently validate authorization 543 of peers for writing a data value at a Shared Resource. Thereby it 544 is assumed that the validating peer is in possession of the complete 545 and most recent ACL for a specific Resource/Kind pair. The 546 corresponding procedure consists of recursively traversing the trust 547 delegation tree and proceeds as follows. 549 1. Obtain the username of the certificate used for signing the data 550 stored at the Shared Resource. 552 2. Validate that an item of the corresponding ACL (i.e., for this 553 Resource/Kind pair) contains a "to_user" field whose value equals 554 the username obtained in step 1. If the Shared Resource under 555 examination is an Access Control List Kind, further validate if 556 the "ad" flag is set to 1. 558 3. Select the username of the certificate that was used to sign the 559 ACL item obtained in step 2. 561 4. Validate that an item of the corresponding ACL contains a 562 "to_user" field whose value equals the username obtained in step 563 3. Additionally validate that the "ad" flag is set to 1. 565 5. Repeat steps 3 and 4 until the "to_user" value is equal to the 566 username of the signer of the previously selected ACL item. This 567 final ACL item is expected to be the root item of this ACL which 568 SHALL be further validated by verifying that the root item was 569 signed by the owner of the ACL Resource. 571 The trust delegation chain is valid if and only if all verification 572 steps succeed. In this case, the creator of the data value of the 573 Shared Resource is an Authorized Peer. 575 Note that the ACL validation procedure can be omitted whenever the 576 creator of data at a Shared Resource is the Resource Owner itself. 577 The latter can be verified by its public key certificate as defined 578 in Section 6.6. 580 6.4. Operations of Storing Peers 582 Storing peers, i.e., peers at which Shared Resource and ACL are 583 physically stored, are responsible for controlling storage attempts 584 to a Shared Resource and its corresponding Access Control List. To 585 assert the USER-CHAIN-ACL access policy (see Section 6.4), a storing 586 peer MUST perform the access validation procedure described in 587 Section 6.3 on any incoming store request using the most recent 588 Access Control List for every Kind that uses the USER-CHAIN-ACL 589 policy. It SHALL further ensure that only the Resource Owner stores 590 new ACL root items for Shared Resources. 592 6.5. Operations of Accessing Peers 594 Accessing peers, i.e., peers that fetch a Shared Resource, MAY 595 validate that the originator of a Shared Resource was authorized to 596 store data at this Resource-ID by processing the corresponding ACL. 597 To enable an accessing peer to perform the access validation 598 procedure described in Section 6.3, it first needs to obtain the most 599 recent Access Control List in the following way. 601 1. Send a Stat request to the Resource-ID of the Shared Resource to 602 obtain all array indexes of stored ACL Kinds. 604 2. Fetch all indexes of existing ACL items at this Resource-ID by 605 using the array ranges retrieved in the Stat request answer. 607 Peers can cache previously fetched Access Control Lists up to the 608 maximum lifetime of an individual item. Since stored values could 609 have been modified or invalidated prior to their expiration, an 610 accessing peer SHOULD use a Stat request to check for updates prior 611 to using the data cache. 613 6.6. USER-CHAIN-ACL Access Policy 615 This document specifies an additional access control policy to the 616 RELOAD base draft [I-D.ietf-p2psip-base]. The USER-CHAIN-ACL policy 617 allows Authorized Peers to write a Shared Resource, even though they 618 do not own the corresponding certificate. Additionally, the USER- 619 CHAIN-ACL allows the storage of Kinds with a variable resource name 620 that are following one of the specified naming pattern. Hence, on an 621 inbound store request on a Kind that uses the USER-CHAIN-ACL access 622 policy, the following rules MUST be applied: 624 In the USER-CHAIN-ACL policy, a given value MUST be written or 625 overwritten, if either one of USER-MATCH or USER-NODE-MATCH 626 (mandatory if the data model is dictionary) access policies of the 627 base document [I-D.ietf-p2psip-base] applies. 629 Otherwise, the value MUST be written if the certificate of the signer 630 contains a username that matches to one of the variable resource name 631 pattern (c.f. Section 5) specified in the configuration document 632 and, additionally, the hashed Resource Name matches the Resource-ID. 633 The Resource Name of the Kind to be stored MUST be taken from the 634 mandatory ResourceNameExtension field in the corresponding Kind data 635 structure. 637 Otherwise, the value MUST be written if the ACL validation procedure 638 described in Section 6.3 has been successfully applied. 640 7. ACL Kind Definition 642 This section defines the ACCESS-CONTROL-LIST Kind previously 643 described in this document. 645 Name: ACCESS-CONTROL-LIST 647 Kind IDs: The Resource Name for ACCESS-CONTROL-LIST Kind-ID is the 648 Resource Name of the Kind that will be shared by using the ACCESS- 649 CONTROL-LIST Kind. 651 Data Model: The data model for the ACCESS-CONTROL-LIST Kind-ID is 652 array. The array indexes are formed by using the mechanism for 653 isolated stored data as described in Section 3.1 655 Access Control: USER-CHAIN-ACL (see Section 6.6) 657 8. Security Considerations 659 In this section we discuss security issues that are relevant to the 660 usage of shared resources in RELOAD. 662 8.1. Resource Exhaustion 664 Joining a RELOAD overlay inherently poses a certain resource load on 665 a peer, because it has to store and forward data for other peers. In 666 common RELOAD semantics, each Resource ID and thus position in the 667 overlay may only be written by a limited set of peers - often even 668 only a single peer, which limits this burden. In the case of Shared 669 Resources, a single resource may be written by multiple peers, who 670 may even write an arbitrary number of entries (e.g., delegations in 671 the ACL). This leads to an enhanced use of resources at individual 672 overlay nodes. The problem of resource exhaustion can easily be 673 mitigated for Usages based on the ShaRe-Usage by imposing 674 restrictions on size, i.e., element for a certain Kind in 675 the configuration document. 677 8.2. Malicious or Misbehaving Storing Peer 679 The RELOAD overlay is designed to operate despite the presence of a 680 small set of misbehaving peers. This is not different for Shared 681 Resources since a small set of malicious peers does not disrupt the 682 functionality of the overlay in general, but may have implications 683 for the peers needing to store or access information at the specific 684 locations in the ID space controlled by a malicious peer. A storing 685 peer could withhold stored data which results in a denial of service 686 to the group using the specific resource. But it could not return 687 forged data, since the validity of any stored data can be 688 independently verified using the attached signatures. 690 8.3. Privacy Issues 692 All data stored in the Shared Resource is publicly readable, thus 693 applications requiring privacy need to encrypt the data. The ACL 694 needs to be stored unencrypted, thus the list members of a group 695 using a Shared Resource will always be publicly visible. 697 9. IANA Considerations 699 TODO: register Kind-ID code point at the IANA 701 10. Acknowledgments 703 This work was stimulated by fruitful discussions in the P2PSIP 704 working group and SAM research group. We would like to thank all 705 active members for constructive thoughts and feedback. In 706 particular, the authors would like to thank (in alphabetical order) 707 Lothar Grimm, Cullen Jennings, Peter Musgrave, Joerg Ott, Marc Petit- 708 Huguenin, Peter Pogrzeba, and Jan Seedorf. This work was partly 709 funded by the German Federal Ministry of Education and Research, 710 projects HAMcast and Mindstone. 712 11. References 714 11.1. Normative References 716 [I-D.ietf-p2psip-base] 717 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 718 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 719 Base Protocol", draft-ietf-p2psip-base-21 (work in 720 progress), March 2012. 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 11.2. Informative References 727 [I-D.ietf-p2psip-concepts] 728 Bryan, D., Willis, D., Shim, E., Matthews, P., and S. 729 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 730 draft-ietf-p2psip-concepts-04 (work in progress), 731 October 2011. 733 [I-D.knauf-p2psip-disco] 734 Knauf, A., Hege, G., Schmidt, T., and M. Waehlisch, "A 735 RELOAD Usage for Distributed Conference Control (DisCo)", 736 draft-knauf-p2psip-disco-04 (work in progress), 737 October 2011. 739 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 740 Jacobson, "RTP: A Transport Protocol for Real-Time 741 Applications", STD 64, RFC 3550, July 2003. 743 Appendix A. Change Log 745 The following changes have been made from version 746 draft-knauf-p2psip-share-02: 748 1. Editorial improvements 750 2. Updated References 752 The following changes have been made from version 753 draft-knauf-p2psip-share-01: 755 1. Simplified the ACL data structure in response to WG feedback 757 2. Added ResourceNameExtension data structure to simplify the use of 758 variable resource names 760 3. Restructured document 762 4. Many editorial improvements 764 The following changes have been made from version 765 draft-knauf-p2psip-share-00: 767 1. Integrated the USER-PATTERN-MATCH access policy into USER-CHAIN- 768 ACL 770 2. Access Control List Kind uses USER-CHAIN-ACL exclusively 772 3. Resources to be shared use USER-CHAIN-ACL exclusively 774 4. More precise specification of mandatory User_name and 775 Resource_name fields for Shared Resources 777 5. Added mechanism for isolating stored data to prevent race 778 conditions while concurrent storing 780 6. XML Extension for variable resource names uses its own namespace 782 7. Many editorial improvements 784 Authors' Addresses 786 Alexander Knauf 787 HAW Hamburg 788 Berliner Tor 7 789 Hamburg D-20099 790 Germany 792 Phone: +4940428758067 793 Email: alexanderknauf@gmail.com 794 URI: http://inet.cpt.haw-hamburg.de/members/knauf 796 Gabriel Hege 797 HAW Hamburg 798 Berliner Tor 7 799 Hamburg D-20099 800 Germany 802 Phone: +4940428758067 803 Email: hege@fhtw-berlin.de 804 URI: http://inet.cpt.haw-hamburg.de/members/hege 806 Thomas C. Schmidt 807 HAW Hamburg 808 Berliner Tor 7 809 Hamburg D-20099 810 Germany 812 Email: schmidt@informatik.haw-hamburg.de 813 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 815 Matthias Waehlisch 816 link-lab & FU Berlin 817 Hoenower Str. 35 818 Berlin D-10318 819 Germany 821 Email: mw@link-lab.net 822 URI: http://www.inf.fu-berlin.de/~waehl