idnits 2.17.1 draft-ietf-p2psip-share-04.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 345 has weird spacing: '...tension res_n...' -- The document date (August 29, 2014) is 3522 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-Posix' == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-06 == Outdated reference: A later version (-21) exists of draft-ietf-p2psip-sip-13 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP Working Group A. Knauf 3 Internet-Draft T. Schmidt, Ed. 4 Intended status: Standards Track HAW Hamburg 5 Expires: March 2, 2015 G. Hege 6 daviko GmbH 7 M. Waehlisch 8 link-lab & FU Berlin 9 August 29, 2014 11 A Usage for Shared Resources in RELOAD (ShaRe) 12 draft-ietf-p2psip-share-04 14 Abstract 16 This document defines a RELOAD Usage for managing shared write access 17 to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic 18 primitive for enabling various coordination and notification schemes 19 among distributed peers. Access in ShaRe is controlled by a 20 hierarchical trust delegation scheme maintained within an access 21 list. A new USER-CHAIN-ACL access policy allows authorized peers to 22 write a Shared Resource without owning its corresponding certificate. 23 This specification also adds mechanisms to store Resources with a 24 variable name which is useful whenever peer-independent rendezvous 25 processes are required. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 2, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Shared Resources in RELOAD . . . . . . . . . . . . . . . . . 4 64 3.1. Mechanisms for Isolating Stored Data . . . . . . . . . . 5 65 4. Access Control List Definition . . . . . . . . . . . . . . . 6 66 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 8 68 5. Extension for Variable Resource Names . . . . . . . . . . . . 9 69 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 10 71 5.3. Overlay Configuration Document Extension . . . . . . . . 10 72 6. Access Control to Shared Resources . . . . . . . . . . . . . 11 73 6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 12 74 6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 12 75 6.3. Validating Write Access through an ACL . . . . . . . . . 13 76 6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 14 77 6.5. Operations of Accessing Peers . . . . . . . . . . . . . . 14 78 6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . 14 79 7. ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . . 15 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 15 82 8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 16 83 8.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 16 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 9.1. Access Control Policy . . . . . . . . . . . . . . . . . . 16 86 9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 16 87 9.3. XML Name Space Registration . . . . . . . . . . . . . . . 17 88 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 11.2. Informative References . . . . . . . . . . . . . . . . . 18 92 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 This document defines a RELOAD Usage for managing shared write access 98 to RELOAD Resources and a mechanism to store Resources with a 99 variable name. The Usage for Shared Resources in RELOAD (ShaRe) 100 enables overlay users to share their exclusive write access to 101 specific Resource/Kind pairs with others. Shared Resources form a 102 basic primitive for enabling various coordination and notification 103 schemes among distributed peers. Write permission is controlled by 104 an Access Control List (ACL) Kind that maintains a chain of 105 Authorized Peers for a particular Shared Resource. A newly defined 106 USER-CHAIN-ACL access control policy enables shared write access in 107 RELOAD. 109 The Usage for Shared Resources in RELOAD is designed for jointly 110 coordinated group applications among distributed peers (e.g., third 111 party registration, see [I-D.ietf-p2psip-sip] , or distributed 112 conferencing, see[I-D.ietf-p2psip-disco]). Of particular interest 113 are rendezvous processes, where a single identifier is linked to 114 multiple, dynamic instances of a distributed cooperative service. 115 Shared write access is based on a trust delegation mechanism. It 116 transfers the authorization to write a specific Kind data by storing 117 logical Access Control Lists. An ACL contains the ID of the Kind to 118 be shared and contains trust delegations from one authorized to 119 another (previously unauthorized) user. 121 Shared write access augments the RELOAD security model, which is 122 based on the restriction that peers are only allowed to write 123 resources at a small set of well defined locations (Resource-IDs) in 124 the overlay. Using the standard access control rules in RELOAD, 125 these locations are bound to the username or Node-ID in the peer's 126 certificate. This document extends the base policies to enable a 127 controlled write access for multiple users to a common Resource Id. 129 Additionally, this specification defines an optional mechanism to 130 store Resources with a variable Resource Name. It enables the 131 storage of Resources whose name complies to a specific pattern. 132 Definition of the pattern is arbitrary, but must contain the username 133 of the Resource creator. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 This document uses the terminology and definitions from the RELOAD 142 base [RFC6940]and the peer-to-peer SIP concepts draft 143 [I-D.ietf-p2psip-concepts]. Additionally, the following terms are 144 used: 146 Shared Resource: The term Shared Resource in this document defines a 147 RELOAD Resource with its associated Kinds, that can be written or 148 overwritten by multiple RELOAD users following the specifications 149 in this document. 151 Access Control List: The term Access Control List in this document 152 defines a logical list of RELOAD users allowed to write a specific 153 RELOAD Resource/Kind pair by following the specifications in this 154 document. The list items are stored as Access Control List Kinds 155 that map trust delegations from user A to user B, where A is 156 allowed to write a Shared Resource and the Access Control List, 157 while B is a user that obtains write access to specified Kinds 158 from A. 160 Resource Owner: The term Resource Owner in this document defines a 161 RELOAD peer that initially stored a Resource to be shared. The 162 Resource Owner possesses the RELOAD certificate that grants write 163 access to a specific Resource/Kind pair using the RELOAD 164 certificate-based access control policies. 166 Authorized Peer: The term Authorized Peer in this document defines a 167 RELOAD peer that was granted write access to a Shared Resource by 168 permission of the Resource Owner or another Authorized Peer. 170 3. Shared Resources in RELOAD 172 A RELOAD user that owns a certificate for writing at a specific 173 overlay location can maintain one or more RELOAD Kinds that are 174 designated for a non-exclusive write access shared with other RELOAD 175 users. The mechanism to share those Resource/Kind pairs with a group 176 of users consists of two basic steps. 178 1. Storage of the Resource/Kind pairs to be shared. 180 2. Storage of an Access Control List (ACL) associated with those 181 Kinds. 183 ACLs are created by the Resource Owner and contain ACL items, each 184 delegating the permission of writing the shared Kind to a specific 185 user called Authorized Peer. For each shared Kind data, its Resource 186 owner stores a root item that initiates an Access Control List. 187 Trust delegation to the Authorized Peer can include the right to 188 further delegate the write permission, enabling a tree of trust 189 delegations with the Resource Owner as trust anchor at its root. 191 The Resource/Kind pair to be shared can be any RELOAD Kind that 192 complies to the following specifications: 194 Isolated Data Storage: To prevent concurrent writing from race 195 conditions, each data item stored within a Shared Resource SHALL 196 be exclusively maintained by the RELOAD user who created it. 197 Hence, Usages that allow the storage of Shared Resources are 198 REQUIRED to use either the array or dictionary data model and 199 apply additional mechanisms for isolating data as described in 200 Section 3.1. 202 Access Control Policy: To ensure write access to Shared Resource by 203 Authorized Peers, each Usage MUST use the USER-CHAIN-ACL access 204 policy as described in Section 6.6. 206 Resource Name Extension: To enable Shared Resources to be stored 207 using a variable resource name, this document defines an optional 208 ResourceNameExtension structure. It contains the Resource Name of 209 the Kind data to be stored and allows any receiver of a shared 210 data to validate whether the Resource Name hashes to the Resource- 211 ID. The ResourceNameExtension is made optional by configuration. 212 The ResourceNameExtension field is only present in the Kind data 213 structure when configured in the corresponding kind-block of the 214 overlay configuration document (for more details see Section 5.3). 215 If the configuration allows variable resource names, a Kind using 216 the USER-CHAIN-ACL policy MUST use the ResourceNameExtension as 217 initial field within the Kind data structure definition. 218 Otherwise the Kind data structure does not contain the 219 ResourceNameExtension structure. 221 3.1. Mechanisms for Isolating Stored Data 223 This section defines mechanisms to avoid race conditions while 224 concurrently writing an array or dictionary of a Shared Resource. 226 If a dictionary is used in the Shared Resource, the dictionary key 227 MUST be the Node-ID of the certificate that will be used to sign the 228 stored data. Thus data access is bound to the unique ID-holder. 230 If the data model of the Shared Resource is an array, each Authorized 231 Peer SHALL obtain its exclusive range of the array indices. The 232 following algorithm will generate an array indexing scheme that 233 avoids collisions. 235 1. Obtain the Node-ID of the certificate that will be used to sign 236 the stored data 238 2. Take the least significant 24 bits of that Node-ID 240 3. Concatenate an 8 bit long short individual index value to those 241 24 bit of the Node-ID 243 The resulting 32 bits long integer MUST be used as the index for 244 storing an array entry in a Shared Resource. The 8 bit individual 245 index can be incremented individually for further array entries and 246 allows for 256 distinct entries per Peer. 248 The mechanism to create the array index is related to the pseudo- 249 random algorithm to generate an SSRC identifier in RTP, see 250 Section 8.1 in [RFC3550] for calculating the probability of a 251 collision. 253 4. Access Control List Definition 255 4.1. Overview 257 An Access Control List (ACL) is a (self-managed) shared resource that 258 contains a list of AccessControlListItem structures as defined in 259 Section 4.2. Each entry delegates write access for a specific Kind 260 data to a single RELOAD user. An ACL enables the RELOAD user who is 261 authorized to write a specific Resource-ID to delegate his exclusive 262 write access to a specific Kind to further users of the same RELOAD 263 overlay. Each Access Control List data structure therefore carries 264 the information about who obtains write access, the Kind-ID of the 265 Resource to be shared, and whether delegation includes write access 266 to the ACL itself. The latter condition grants the right to delegate 267 write access further for the Authorized Peer. Access Control Lists 268 are stored at the same overlay location as the Shared Resource and 269 use the RELOAD array data model. They are initially created by the 270 Resource Owner. 272 Figure 1 shows an example of an Access Control List. We omit the 273 res_name_ext field to simplify illustration. The array entry at 274 index 0x123abc001 displays the initial creation of an ACL for a 275 Shared Resource of Kind-ID 1234 at the same Resource-ID. It 276 represents the root item of the trust delegation tree for this shared 277 RELOAD Kind. The root entry MUST contain the username of the 278 Resource owner in the "to_user" field and can only be written by the 279 owner of the public key certificate associated with this Resource-ID. 280 The allow_delegation (ad) flag for a root ACL item is set to 1 by 281 default. The array index is generated by using the mechanism for 282 isolating stored data as described in Section 3.1. Hence, the most 283 significant 24 bits of the array index (0x123abc) are the least 284 significant 24 bits of the Node-ID of the Resource Owner. 286 The array item at index 0x123abc002 represents the first trust 287 delegation to an Authorized Peer that is thus permitted to write to 288 the Shared Resource of Kind-ID 1234. Additionally, the Authorized 289 peer Alice is also granted (limited) write access to the ACL as 290 indicated by the allow_delegation flag (ad) set to 1. This 291 configuration authorizes Alice to store further trust delegations to 292 the Shared Resource, i.e., add items to the ACL. On the contrary, 293 index 0x456def001 illustrates trust delegation for Kind-ID 1234, in 294 which the Authorized Peer Bob is not allowed to grant access to 295 further peers (ad = 0). Each Authorized Peer signs its ACL items by 296 using its own signer identity along with its own private key. This 297 allows other peers to validate the origin of an ACL item and makes 298 ownership transparent. 300 To manage Shared Resource access of multiple Kinds at a single 301 location, the Resource Owner can create new ACL entries that refer to 302 another Kind-ID as shown in array entry index 0x123abc003. Note that 303 overwriting existing items in an Access Control List that reference a 304 different Kind-ID revokes all trust delegations in the corresponding 305 subtree (see Section 6.2). Authorized Peers are only enabled to 306 overwrite existing ACL item they own. The Resource Owner is allowed 307 to overwrite any existing ACL item, but should be aware of its 308 consequences. 310 +------------------------------------------------------+ 311 | Access Control List | 312 +-----------+------------------------------+-----------+ 313 | #Index | Array Entries | signed by | 314 +-----------+------------------------------+-----------+ 315 | 123abc001 | to_user:Owner Kind:1234 ad:1 | Owner | 316 +-----------+------------------------------+-----------+ 317 | 123abc002 | to_user:Alice Kind:1234 ad:1 | Owner | 318 +-----------+------------------------------+-----------+ 319 | 123abc003 | to_user:Owner Kind:4321 ad:1 | Owner | 320 +-----------+------------------------------+-----------+ 321 | 123abc004 | to_user:Carol Kind:4321 ad:0 | Owner | 322 +-----------+------------------------------+-----------+ 323 | ... | ... | ... | 324 +-----------+------------------------------+-----------+ 325 | 456def001 | to_user:Bob Kind:1234 ad:0 | Alice | 326 +-----------+------------------------------+-----------+ 327 | ... | ... | ... | 328 +-----------+------------------------------+-----------+ 330 Figure 1: Simplified example of an Access Control including entries 331 for two different Kind-IDs and varying delegation (ad) configurations 333 Implementations of ShaRe should be aware that the trust delegation in 334 an Access Control List need not be loop free. Self-contained 335 circular trust delegation from A to B and B to A are syntactically 336 possible, even though not very meaningful. 338 4.2. Data Structure 340 The Kind data structure for the Access Control List is defined as 341 follows: 343 struct { 344 /* res_name_ext is optional, see documentation */ 345 ResourceNameExtension res_name_ext; 346 opaque to_user<0..2^16-1>; 347 KindId kind; 348 Boolean allow_delegation; 349 } AccessControlListItem; 351 The AccessControlListItem structure is composed of: 353 res_name_ext: This optional field contains the Resource Name of a 354 ResourceNameExtension (see Section 5.2) to be used by a Shared 355 Resource with variable resource name. This name serves the 356 storing peer for validating, whether a variable resources name 357 matches one of the predefined naming pattern from the 358 configuration document for this Kind. The presence of this field 359 is bound to a variable resource name element in the corresponding 360 kind-block of the configuration document whose "enable" attribute 361 is set to true (see Section 5.3). Otherwise, if the "enable" 362 attribute is false, the res_name_ext field SHALL NOT be present in 363 the Kind data structure. 365 to_user: This field contains the username of the RELOAD peer that 366 obtains write permission to the Shared Resource. 368 kind: This field contains the Kind-ID of the Shared Resource. 370 allow_delegation: If true, this Boolean flag indicates that the 371 Authorized Peer in the 'to_user' field is allowed to add 372 additional entries to the ACL for the specified Kind-ID. 374 5. Extension for Variable Resource Names 376 5.1. Overview 378 In certain use cases such as conferencing (c.f., 379 [I-D.ietf-p2psip-disco]) it is desirable to increase the flexibility 380 of a peer in using Resource Names beyond those defined by the 381 username or Node-ID fields in its certificate. For this purpose, 382 this document presents the concept for variable Resources Names that 383 enables providers of RELOAD instances to define relaxed naming 384 schemes for overlay Resources. 386 Each RELOAD node uses a certificate to identify itself using its user 387 name (or Node-ID) while storing data under a specific Resource-ID. 388 The specifications in this document scheme adhere to this paradigm, 389 but enable a RELOAD peer to store values of Resource Names that are 390 derived from the username in its certificate. This is done by using 391 a Resource Name with a variable substring that still matches the user 392 name in the certificate using a pattern defined in the overlay 393 configuration document. Thus despite being variable, an allowable 394 Resource Name remains tied to the Owner's certificate. A sample 395 pattern might be formed as follows. 397 Example Pattern: 398 .*-conf-\$USER@\$DOMAIN 400 When defining the pattern, care must be taken to avoid conflicts 401 arising from two usernames of witch one is a substring of the other. 402 In such cases, the holder of the shorter name could threaten to block 403 the resources of the longer-named peer by choosing the variable part 404 of a Resource Name to contain the entire longer username. This 405 problem can easily be mitigated by delimiting the variable part of 406 the pattern from the username part by some fixed string, that by 407 convention is not part of a username (e.g., the "-conf-" in the above 408 Example). 410 5.2. Data Structure 412 This section defines the optional ResourceNameExtension structure for 413 every Kind that uses the USER-CHAIN-ACL access control policy. 415 enum { pattern (1), 416 (255)} ResourceNameType; 418 struct { 419 ResourceNameType type; 420 uint16 length; 421 select(type) { 422 case pattern: 423 opaque resource_name<0..2^16-1>; 425 /* Types can be extended */ 426 } 427 } ResourceNameExtension 429 The content of the ResourceNameExtension consist of 431 length: This field contains the length of the remaining data 432 structure. It is only used to allow for further extensions to 433 this data structure. 435 The content of the rest of the data structure depends of the 436 ResourceNameType. Currently, the only defined type is "pattern". 438 If the type is "pattern", then the following data structure contains 439 an opaque <0..2^16-1> field containing the Resource Name of the Kind 440 being stored. The type "pattern" further indicates that the Resource 441 Name MUST match to one of the variable resource name pattern defined 442 for this Kind in the configuration document. 444 The ResourceNameType enum and the ResourceNameExtension structure can 445 be extended by further Usages to define other naming schemes. 447 5.3. Overlay Configuration Document Extension 449 This section extends the overlay configuration document by defining 450 new elements for patterns relating resource names to user names. 451 Configurations in this overlay document MUST adhere in syntax and 452 semantic of names as defined by the context of use. For example, AOR 453 syntax restrictions apply when using P2PSIP[I-D.ietf-p2psip-sip] , 454 while a more general naming is feasible in plain RELOAD. 456 The element serves as a container for one 457 or multiple sub-elements. It is an additional parameter 458 within the kind block and has a boolean "enable" attribute that 459 indicates, if true, that the overlay provider allows variable 460 resource names for this Kind. The default value of the "enable" 461 attribute is "false". In the absence of a 462 element for a Kind using the USER-CHAIN-ACL access policy (see 463 Section 6.6), implementors SHOULD assume this default value. 465 A element MUST be present if the "enabled" attribute of its 466 parent element is set to true. Each element defines a 467 pattern for constructing extended resource names for a single Kind. 468 It is of type xsd:string and interpreted as a regular expression 469 according to "POSIX Extended Regular Expression" (see the 470 specifications in [IEEE-Posix]). In this regular expression, $USER 471 and $DOMAIN are used as variables for the corresponding parts of the 472 string in the certificate user name field (with $USER preceding and 473 $DOMAIN succeeding the '@'). Both variables MUST be present in any 474 given pattern definition. If no pattern is defined for a Kind or the 475 "enable" attribute is false, allowable Resource Names are restricted 476 to the username of the signer for Shared Resource. 478 The Relax NG Grammar for the Variable Resource Names Extension reads: 480 482 namespace share = "urn:ietf:params:xml:ns:p2p:config-base:share" 484 486 kind-parameter &= element share:variable-resource-names { 488 attribute enable { xsd:boolean } 490 492 element pattern { xsd:string }* 493 }? 495 6. Access Control to Shared Resources 496 6.1. Granting Write Access 498 Write access to a Kind that is intended to be shared with other 499 RELOAD users can solely be issued by the Resource Owner. A Resource 500 Owner can share RELOAD Kinds by using the following procedure. 502 o The Resource Owner stores an ACL root item at the Resource-ID of 503 the Shared Resource. The root item contains the resource name 504 extension field (see Section 5.2), the username of the Resource 505 Owner and Kind-ID of the Shared Resource. The allow_delegation 506 flag is set to 1. The index of array data structure MUST be 507 generated as described in Section 3.1 509 o Further ACL items for this Kind-ID stored by the Resource Owner 510 will delegate write access to Authorized Peers. These ACL items 511 contain the same resource name extension field, the username of 512 the Authorized Peer and the Kind-Id of the Shared Resource. 513 Optionally, the Resource Owner sets the "ad" to 1 (the default 514 equals 0) to enable the Authorized Peer to further delegate write 515 access. Each succeeding ACL item created by the Resource Owner 516 can be stored in the numerical order of the array index starting 517 with the index of the root item incremented by one. 519 An Authorized Peer with delegation allowance ("ad"=1) can extend the 520 access to an existing Shared Resource as follows. 522 o An Authorized Peer can store additional ACL items at the Resource- 523 ID of the Shared Resource. These ACL items contain the resource 524 name extension field, the username of the newly Authorized Peer, 525 and the Kind-Id of the Shared Resource. Optionally, the "ad" flag 526 is set to 1 for allowing the Authorized Peer to further delegate 527 write access. The array index MUST be generated as described in 528 Section 3.1. Each succeeding ACL item can be stored in the 529 numerical order of the array index. 531 A store request by an Authorized Peer that attempts to overwrite any 532 ACL item signed by another Peer is unauthorized and causes an 533 Error_Forbidden response from the Storing Peer. Such access 534 conflicts could be caused by an array index collision. However, the 535 probability of a collision of two or more identical array indices 536 will be negligibly low using the mechanism for isolating stored data 537 (see Section 3.1) 539 6.2. Revoking Write Access 541 Write permissions are revoked by storing a non-existent value 542 [RFC6940] at the corresponding item of the Access Control List. 543 Revoking a permission automatically invalidates all delegations 544 performed by that user including all subsequent delegations. This 545 allows to invalidate entire subtrees of the delegations tree with 546 only a single operation. Overwriting the root item with a non- 547 existent value of an Access List invalidates the entire delegations 548 tree. 550 An existing ACL item MUST only be overwritten by the user who 551 initially stored the corresponding entry, or by the Resource Owner 552 that is allowed to overwrite all ACL items for revoking write access. 554 6.3. Validating Write Access through an ACL 556 Access Control Lists are used to transparently validate authorization 557 of peers for writing a data value at a Shared Resource. Thereby it 558 is assumed that the validating peer is in possession of the complete 559 and most recent ACL for a specific Resource/Kind pair. The 560 corresponding procedure consists of recursively traversing the trust 561 delegation tree and proceeds as follows. 563 1. Obtain the username of the certificate used for signing the data 564 stored at the Shared Resource. 566 2. Validate that an item of the corresponding ACL (i.e., for this 567 Resource/Kind pair) contains a "to_user" field whose value equals 568 the username obtained in step 1. If the Shared Resource under 569 examination is an Access Control List Kind, further validate if 570 the "ad" flag is set to 1. 572 3. Select the username of the certificate that was used to sign the 573 ACL item obtained in step 2. 575 4. Validate that an item of the corresponding ACL contains a 576 "to_user" field whose value equals the username obtained in step 577 3. Additionally validate that the "ad" flag is set to 1. 579 5. Repeat steps 3 and 4 until the "to_user" value is equal to the 580 username of the signer of the previously selected ACL item. This 581 final ACL item is expected to be the root item of this ACL which 582 SHALL be further validated by verifying that the root item was 583 signed by the owner of the ACL Resource. 585 The trust delegation chain is valid if and only if all verification 586 steps succeed. In this case, the creator of the data value of the 587 Shared Resource is an Authorized Peer. 589 Note that the ACL validation procedure can be omitted whenever the 590 creator of data at a Shared Resource is the Resource Owner itself. 592 The latter can be verified by its public key certificate as defined 593 in Section 6.6. 595 6.4. Operations of Storing Peers 597 Storing peers at which Shared Resource and ACL are physically stored, 598 are responsible for controlling storage attempts to a Shared Resource 599 and its corresponding Access Control List. To assert the USER-CHAIN- 600 ACL access policy (see Section 6.6), a storing peer MUST perform the 601 access validation procedure described in Section 6.3 on any incoming 602 store request using the most recent Access Control List for every 603 Kind that uses the USER-CHAIN-ACL policy. It SHALL further ensure 604 that only the Resource Owner stores new ACL root items for Shared 605 Resources. 607 6.5. Operations of Accessing Peers 609 Accessing peers, i.e., peers that fetch a Shared Resource, MAY 610 validate that the originator of a Shared Resource was authorized to 611 store data at this Resource-ID by processing the corresponding ACL. 612 To enable an accessing peer to perform the access validation 613 procedure described in Section 6.3, it first needs to obtain the most 614 recent Access Control List in the following way. 616 1. Send a Stat request to the Resource-ID of the Shared Resource to 617 obtain all array indexes of stored ACL Kinds. 619 2. Fetch all indexes of existing ACL items at this Resource-ID by 620 using the array ranges retrieved in the Stat request answer. 622 Peers can cache previously fetched Access Control Lists up to the 623 maximum lifetime of an individual item. Since stored values could 624 have been modified or invalidated prior to their expiration, an 625 accessing peer SHOULD use a Stat request to check for updates prior 626 to using the data cache. 628 6.6. USER-CHAIN-ACL Access Policy 630 This document specifies an additional access control policy to the 631 RELOAD base draft [RFC6940]. The USER-CHAIN-ACL policy allows 632 Authorized Peers to write a Shared Resource, even though they do not 633 own the corresponding certificate. Additionally, the USER-CHAIN-ACL 634 allows the storage of Kinds with a variable resource name that are 635 following one of the specified naming pattern. Hence, on an inbound 636 store request on a Kind that uses the USER-CHAIN-ACL access policy, 637 the following rules MUST be applied: 639 In the USER-CHAIN-ACL policy, a given value MUST be written or 640 overwritten, if either one of USER-MATCH or USER-NODE-MATCH 641 (mandatory if the data model is dictionary) access policies of the 642 base document [RFC6940] applies. 644 Otherwise, the value MUST be written if the certificate of the signer 645 contains a username that matches to one of the variable resource name 646 pattern (c.f. Section 5) specified in the configuration document 647 and, additionally, the hashed Resource Name matches the Resource-ID. 648 The Resource Name of the Kind to be stored MUST be taken from the 649 mandatory ResourceNameExtension field in the corresponding Kind data 650 structure. 652 Otherwise, the value MUST be written if the ACL validation procedure 653 described in Section 6.3 has been successfully applied. 655 7. ACCESS-CONTROL-LIST Kind Definition 657 This section defines the ACCESS-CONTROL-LIST Kind previously 658 described in this document. 660 Name: ACCESS-CONTROL-LIST 662 Kind IDs: The Resource Name for ACCESS-CONTROL-LIST Kind-ID is the 663 Resource Name of the Kind that will be shared by using the ACCESS- 664 CONTROL-LIST Kind. 666 Data Model: The data model for the ACCESS-CONTROL-LIST Kind-ID is 667 array. The array indexes are formed by using the mechanism for 668 isolated stored data as described in Section 3.1 670 Access Control: USER-CHAIN-ACL (see Section 6.6) 672 8. Security Considerations 674 In this section we discuss security issues that are relevant to the 675 usage of shared resources in RELOAD. 677 8.1. Resource Exhaustion 679 Joining a RELOAD overlay inherently poses a certain resource load on 680 a peer, because it has to store and forward data for other peers. In 681 common RELOAD semantics, each Resource ID and thus position in the 682 overlay may only be written by a limited set of peers - often even 683 only a single peer, which limits this burden. In the case of Shared 684 Resources, a single resource may be written by multiple peers, who 685 may even write an arbitrary number of entries (e.g., delegations in 686 the ACL). This leads to an enhanced use of resources at individual 687 overlay nodes. The problem of resource exhaustion can easily be 688 mitigated for Usages based on the ShaRe-Usage by imposing 689 restrictions on size, i.e., element for a certain Kind in 690 the configuration document. 692 8.2. Malicious or Misbehaving Storing Peer 694 The RELOAD overlay is designed to operate despite the presence of a 695 small set of misbehaving peers. This is not different for Shared 696 Resources since a small set of malicious peers does not disrupt the 697 functionality of the overlay in general, but may have implications 698 for the peers needing to store or access information at the specific 699 locations in the ID space controlled by a malicious peer. A storing 700 peer could withhold stored data which results in a denial of service 701 to the group using the specific resource. But it could not return 702 forged data, since the validity of any stored data can be 703 independently verified using the attached signatures. 705 8.3. Privacy Issues 707 All data stored in the Shared Resource is publicly readable, thus 708 applications requiring privacy need to encrypt the data. The ACL 709 needs to be stored unencrypted, thus the list members of a group 710 using a Shared Resource will always be publicly visible. 712 9. IANA Considerations 714 9.1. Access Control Policy 716 IANA shall register the following entry in the "RELOAD Access Control 717 Policies" Registry (cf., [RFC6940]) to represent the USER-CHAIN-ACL 718 Access Control Policy, as described in Section 6.6. [NOTE TO IANA/ 719 RFC-EDITOR: Please replace RFC-AAAA with the RFC number for this 720 specification in the following list.] 722 +-------------------+----------+ 723 | Kind | RFC | 724 +-------------------+----------+ 725 | USER-CHAIN-ACL | RFC-AAAA | 726 +-------------------+----------+ 728 9.2. Data Kind-ID 730 IANA shall register the following code point in the "RELOAD Data 731 Kind-ID" Registry (cf., [RFC6940]) to represent the ShaRe ACCESS- 732 CONTROL-LIST kind, as described in Section 7. [NOTE TO IANA/RFC- 733 EDITOR: Please replace RFC-AAAA with the RFC number for this 734 specification in the following list.] 735 +----------------------+------------+----------+ 736 | Kind | Kind-ID | RFC | 737 +----------------------+------------+----------+ 738 | ACCESS-CONTROL-LIST | 17 | RFC-AAAA | 739 +----------------------+------------+----------+ 741 9.3. XML Name Space Registration 743 This document registers the following URI for the config XML 744 namespace in the IETF XML registry defined in [RFC3688] 746 URI: urn:ietf:params:xml:ns:p2p:config-base:share 748 Registrant Contact: The IESG 750 XML: N/A, the requested URI is an XML namespace 752 10. Acknowledgments 754 This work was stimulated by fruitful discussions in the P2PSIP 755 working group and SAM research group. We would like to thank all 756 active members for constructive thoughts and feedback. In 757 particular, the authors would like to thank (in alphabetical order) 758 Lothar Grimm, Cullen Jennings, Peter Musgrave, Joerg Ott, Marc Petit- 759 Huguenin, Peter Pogrzeba, and Jan Seedorf. This work was partly 760 funded by the German Federal Ministry of Education and Research, 761 projects HAMcast, Mindstone, and SAFEST. 763 11. References 765 11.1. Normative References 767 [IEEE-Posix] 768 "IEEE Standard for Information Technology - Portable 769 Operating System Interface (POSIX) - Part 2: Shell and 770 Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 771 1-55937-255-9, January 1993. 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, March 1997. 776 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 777 January 2004. 779 [RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 780 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 781 Base Protocol", RFC 6940, January 2014. 783 11.2. Informative References 785 [I-D.ietf-p2psip-concepts] 786 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 787 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 788 draft-ietf-p2psip-concepts-06 (work in progress), June 789 2014. 791 [I-D.ietf-p2psip-disco] 792 Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A 793 RELOAD Usage for Distributed Conference Control (DisCo)", 794 draft-ietf-p2psip-disco-02 (work in progress), July 2013. 796 [I-D.ietf-p2psip-sip] 797 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., 798 Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD", 799 draft-ietf-p2psip-sip-13 (work in progress), July 2014. 801 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 802 Jacobson, "RTP: A Transport Protocol for Real-Time 803 Applications", STD 64, RFC 3550, July 2003. 805 Appendix A. Change Log 807 The following changes have been made from version draft-ietf-p2psio- 808 share-02: 810 1. Updated References 812 The following changes have been made from version draft-ietf-p2psio- 813 share-01: 815 1. Added IANA registration for namespace 817 2. Editorial improvements 819 3. Updated References 821 The following changes have been made from version draft-ietf-p2psio- 822 share-00: 824 1. Clarified use of identities in ACLs 826 2. Specified use of Posix regular expressions in configuration 827 document 829 3. Added IANA considerations 830 4. Editorial improvements 832 5. Updated References 834 The following changes have been made from version draft-knauf-p2psip- 835 share-02: 837 1. Editorial improvements 839 2. Updated References 841 The following changes have been made from version draft-knauf-p2psip- 842 share-01: 844 1. Simplified the ACL data structure in response to WG feedback 846 2. Added ResourceNameExtension data structure to simplify the use of 847 variable resource names 849 3. Restructured document 851 4. Many editorial improvements 853 The following changes have been made from version draft-knauf-p2psip- 854 share-00: 856 1. Integrated the USER-PATTERN-MATCH access policy into USER-CHAIN- 857 ACL 859 2. Access Control List Kind uses USER-CHAIN-ACL exclusively 861 3. Resources to be shared use USER-CHAIN-ACL exclusively 863 4. More precise specification of mandatory User_name and 864 Resource_name fields for Shared Resources 866 5. Added mechanism for isolating stored data to prevent race 867 conditions while concurrent storing 869 6. XML Extension for variable resource names uses its own namespace 871 7. Many editorial improvements 873 Authors' Addresses 874 Alexander Knauf 875 HAW Hamburg 876 Berliner Tor 7 877 Hamburg D-20099 878 Germany 880 Phone: +4940428758067 881 Email: alexanderknauf@gmail.com 883 Thomas C. Schmidt 884 HAW Hamburg 885 Berliner Tor 7 886 Hamburg D-20099 887 Germany 889 Email: schmidt@informatik.haw-hamburg.de 890 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 892 Gabriel Hege 893 daviko GmbH 894 Am Borsigturm 50 895 Berlin D-13507 896 Germany 898 Phone: +493043004344 899 Email: hege@daviko.com 901 Matthias Waehlisch 902 link-lab & FU Berlin 903 Hoenower Str. 35 904 Berlin D-10318 905 Germany 907 Email: mw@link-lab.net 908 URI: http://www.inf.fu-berlin.de/~waehl