idnits 2.17.1 draft-ietf-p2psip-share-08.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 353 has weird spacing: '...tension res_n...' -- The document date (March 20, 2016) is 2960 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-08 == Outdated reference: A later version (-21) exists of draft-ietf-p2psip-sip-17 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: September 21, 2016 G. Hege 6 daviko GmbH 7 M. Waehlisch 8 link-lab & FU Berlin 9 March 20, 2016 11 A Usage for Shared Resources in RELOAD (ShaRe) 12 draft-ietf-p2psip-share-08 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 September 21, 2016. 44 Copyright Notice 46 Copyright (c) 2016 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 . . . . . . . . . . . . . 12 73 6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 12 74 6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . 15 79 7. ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . . 15 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 16 82 8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 16 83 8.3. Trust Delegation to a Malicious or Misbehaving Peer . . . 16 84 8.4. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 17 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 9.1. Access Control Policy . . . . . . . . . . . . . . . . . . 17 87 9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 17 88 9.3. XML Name Space Registration . . . . . . . . . . . . . . . 17 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 91 10.2. Informative References . . . . . . . . . . . . . . . . . 18 92 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 [RFC6940] defines the base protocol for REsource LOcation And 98 Discovery (RELOAD) that allows for application-specific extensions by 99 Usages. The present document defines such a RELOAD Usage for 100 managing shared write access to RELOAD Resources and a mechanism to 101 store Resources with a variable name. The Usage for Shared Resources 102 in RELOAD (ShaRe) enables overlay users to share their exclusive 103 write access to specific Resource/Kind pairs with others. Shared 104 Resources form a basic primitive for enabling various coordination 105 and notification schemes among distributed peers. Write permission 106 is controlled by an Access Control List (ACL) Kind that maintains a 107 chain of Authorized Peers for a particular Shared Resource. A newly 108 defined USER-CHAIN-ACL access control policy enables shared write 109 access in RELOAD. 111 The Usage for Shared Resources in RELOAD is designed for jointly 112 coordinated group applications among distributed peers (e.g., third 113 party registration, see [I-D.ietf-p2psip-sip], or distributed 114 conferencing). Of particular interest are rendezvous processes, 115 where a single identifier is linked to multiple, dynamic instances of 116 a distributed cooperative service. Shared write access is based on a 117 trust delegation mechanism. It transfers the authorization to write 118 a specific Kind data by storing logical Access Control Lists. An ACL 119 contains the ID of the Kind to be shared and contains trust 120 delegations from one authorized to another (previously unauthorized) 121 user. 123 Shared write access augments the RELOAD security model, which is 124 based on the restriction that peers are only allowed to write 125 resources at a small set of well defined locations (Resource-IDs) in 126 the overlay. Using the standard access control rules in RELOAD, 127 these locations are bound to the username or Node-ID in the peer's 128 certificate. This document extends the base policies to enable a 129 controlled write access for multiple users to a common Resource Id. 131 Additionally, this specification defines an optional mechanism to 132 store Resources with a variable Resource Name. It enables the 133 storage of Resources whose name complies to a specific pattern. 134 Definition of the pattern is arbitrary, but must contain the user 135 name of the Resource creator. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 This document uses the terminology and definitions from the RELOAD 144 base [RFC6940] and [I-D.ietf-p2psip-concepts], in particular the 145 RELOAD Usage, Resource and Kind. Additionally, the following terms 146 are used: 148 Shared Resource: The term Shared Resource in this document defines a 149 RELOAD Resource with its associated Kinds, that can be written or 150 overwritten by multiple RELOAD users following the specifications 151 in this document. 153 Access Control List: The term Access Control List in this document 154 defines a logical list of RELOAD users allowed to write a specific 155 RELOAD Resource/Kind pair by following the specifications in this 156 document. The list items are stored as Access Control List Kinds 157 that map trust delegations from user A to user B, where A is 158 allowed to write a Shared Resource and the Access Control List, 159 while B is a user that obtains write access to specified Kinds 160 from A. 162 Resource Owner: The term Resource Owner in this document defines a 163 RELOAD peer that initially stored a Resource to be shared. The 164 Resource Owner possesses the RELOAD certificate that grants write 165 access to a specific Resource/Kind pair using the RELOAD 166 certificate-based access control policies. 168 Authorized Peer: The term Authorized Peer in this document defines a 169 RELOAD peer that was granted write access to a Shared Resource by 170 permission of the Resource Owner or another Authorized Peer. 172 3. Shared Resources in RELOAD 174 A RELOAD user that owns a certificate for writing at a specific 175 overlay location can maintain one or more RELOAD Kinds that are 176 designated for a non-exclusive write access shared with other RELOAD 177 users. The mechanism to share those Resource/Kind pairs with a group 178 of users consists of two basic steps. 180 1. Storage of the Resource/Kind pairs to be shared. 182 2. Storage of an Access Control List (ACL) associated with those 183 Kinds. 185 ACLs are created by the Resource Owner and contain ACL items, each 186 delegating the permission of writing the shared Kind to a specific 187 user called Authorized Peer. For each shared Kind data, its Resource 188 owner stores a root item that initiates an Access Control List. 189 Trust delegation to the Authorized Peer can include the right to 190 further delegate the write permission, enabling a tree of trust 191 delegations with the Resource Owner as trust anchor at its root. 193 The Resource/Kind pair to be shared can be any RELOAD Kind that 194 complies to the following specifications: 196 Isolated Data Storage: To prevent concurrent writing from race 197 conditions, each data item stored within a Shared Resource SHALL 198 be exclusively maintained by the RELOAD user who created it. 199 Hence, Usages that allow the storage of Shared Resources are 200 REQUIRED to use either the array or dictionary data model and 201 apply additional mechanisms for isolating data as described in 202 Section 3.1. 204 Access Control Policy: To ensure write access to Shared Resource by 205 Authorized Peers, each Usage MUST use the USER-CHAIN-ACL access 206 policy as described in Section 6.6. 208 Resource Name Extension: To enable Shared Resources to be stored 209 using a variable resource name, this document defines an optional 210 ResourceNameExtension structure. It contains the Resource Name of 211 the Kind data to be stored and allows any receiver of a shared 212 data to validate whether the Resource Name hashes to the Resource- 213 ID. The ResourceNameExtension is made optional by configuration. 214 The ResourceNameExtension field is only present in the Kind data 215 structure when configured in the corresponding kind-block of the 216 overlay configuration document (for more details see Section 5.3). 217 If the configuration allows variable resource names, a Kind using 218 the USER-CHAIN-ACL policy MUST use the ResourceNameExtension as 219 initial field within the Kind data structure definition. 220 Otherwise the Kind data structure does not contain the 221 ResourceNameExtension structure. 223 3.1. Mechanisms for Isolating Stored Data 225 This section defines mechanisms to avoid race conditions while 226 concurrently writing an array or dictionary of a Shared Resource. 228 If a dictionary is used in the Shared Resource, the dictionary key 229 MUST be the Node-ID of the certificate that will be used to sign the 230 stored data. Thus data access is bound to the unique ID holder, and 231 write concurrency does not occur. 233 If the data model of the Shared Resource is an array, each Authorized 234 Peer SHALL obtain its exclusive range of the array indices. The 235 following algorithm will generate an array indexing scheme that 236 avoids collisions. 238 1. Obtain the Node-ID of the certificate that will be used to sign 239 the stored data 241 2. Take the least significant 24 bits of that Node-ID to prefix the 242 array index 244 3. Append an 8 bit individual index value to those 24 bit of the 245 Node-ID 247 The resulting 32 bits long integer MUST be used as the index for 248 storing an array entry in a Shared Resource. The 24 bits of the 249 Node-ID serve as a pseudo-random identifier. The 8 bit individual 250 index remain under the control of a single Peer and can be 251 incremented individually for further array entries. In total, each 252 Peer can generate 256 distinct entries for application-specific use. 254 The mechanism to create the array index is related to the pseudo- 255 random algorithm to generate an SSRC identifier in RTP, see 256 Section 8.1 in [RFC3550] for calculating the probability of a 257 collision (here L=24 is the length of the pseudo-random id). 259 4. Access Control List Definition 261 4.1. Overview 263 An Access Control List (ACL) is a (self-managed) shared resource that 264 contains a list of AccessControlListItem structures as defined in 265 Section 4.2. Each entry delegates write access for a specific Kind 266 data to a single RELOAD user. An ACL enables the RELOAD user who is 267 authorized to write a specific Resource-ID to delegate his exclusive 268 write access to a specific Kind to further users of the same RELOAD 269 overlay. Each Access Control List data structure therefore carries 270 the information about who obtains write access, the Kind-ID of the 271 Resource to be shared, and whether delegation includes write access 272 to the ACL itself. The latter condition grants the right to delegate 273 write access further for the Authorized Peer. Access Control Lists 274 are stored at the same overlay location as the Shared Resource and 275 use the RELOAD array data model. They are initially created by the 276 Resource Owner. 278 Figure 1 shows an example of an Access Control List. We omit the 279 res_name_ext field to simplify illustration. The array entry at 280 index 0x123abc001 displays the initial creation of an ACL for a 281 Shared Resource of Kind-ID 1234 at the same Resource-ID. It 282 represents the root item of the trust delegation tree for this shared 283 RELOAD Kind. The root entry MUST contain the user name of the 284 Resource owner in the "to_user" field and can only be written by the 285 owner of the public key certificate associated with this Resource-ID. 287 The allow_delegation (ad) flag for a root ACL item is set to 1 by 288 default. The array index is generated by using the mechanism for 289 isolating stored data as described in Section 3.1. Hence, the most 290 significant 24 bits of the array index (0x123abc) are the least 291 significant 24 bits of the Node-ID of the Resource Owner. 293 The array item at index 0x123abc002 represents the first trust 294 delegation to an Authorized Peer that is thus permitted to write to 295 the Shared Resource of Kind-ID 1234. Additionally, the Authorized 296 peer Alice is also granted write access to the ACL as indicated by 297 the allow_delegation flag (ad) set to 1. This configuration 298 authorizes Alice to store further trust delegations to the Shared 299 Resource, i.e., add items to the ACL. On the contrary, index 300 0x456def001 illustrates trust delegation for Kind-ID 1234, in which 301 the Authorized Peer Bob is not allowed to grant access to further 302 peers (ad = 0). Each Authorized Peer signs its ACL items by using 303 its own signer identity along with its own private key. This allows 304 other peers to validate the origin of an ACL item and makes ownership 305 transparent. 307 To manage Shared Resource access of multiple Kinds at a single 308 location, the Resource Owner can create new ACL entries that refer to 309 another Kind-ID as shown in array entry index 0x123abc003. Note that 310 overwriting existing items in an Access Control List with a change in 311 the Kind-ID revokes all trust delegations in the corresponding 312 subtree (see Section 6.2). Authorized Peers are only enabled to 313 overwrite existing ACL item they own. The Resource Owner is allowed 314 to overwrite any existing ACL item, but should be aware of its 315 consequences on the trust delegation chain. 317 +------------------------------------------------------+ 318 | Access Control List | 319 +-----------+------------------------------+-----------+ 320 | #Index | Array Entries | signed by | 321 +-----------+------------------------------+-----------+ 322 | 123abc001 | to_user:Owner Kind:1234 ad:1 | Owner | 323 +-----------+------------------------------+-----------+ 324 | 123abc002 | to_user:Alice Kind:1234 ad:1 | Owner | 325 +-----------+------------------------------+-----------+ 326 | 123abc003 | to_user:Owner Kind:4321 ad:1 | Owner | 327 +-----------+------------------------------+-----------+ 328 | 123abc004 | to_user:Carol Kind:4321 ad:0 | Owner | 329 +-----------+------------------------------+-----------+ 330 | ... | ... | ... | 331 +-----------+------------------------------+-----------+ 332 | 456def001 | to_user:Bob Kind:1234 ad:0 | Alice | 333 +-----------+------------------------------+-----------+ 334 | ... | ... | ... | 335 +-----------+------------------------------+-----------+ 337 Figure 1: Simplified example of an Access Control List including 338 entries for two different Kind-IDs and varying delegation (ad) 339 configurations 341 Implementations of ShaRe should be aware that the trust delegation in 342 an Access Control List need not be loop free. Self-contained 343 circular trust delegation from A to B and B to A are syntactically 344 possible, even though not very meaningful. 346 4.2. Data Structure 348 The Kind data structure for the Access Control List is defined as 349 follows: 351 struct { 352 /* res_name_ext is optional, see documentation */ 353 ResourceNameExtension res_name_ext; 354 opaque to_user<0..2^16-1>; 355 KindId kind; 356 Boolean allow_delegation; 357 } AccessControlListItem; 359 The AccessControlListItem structure is composed of: 361 res_name_ext: This optional field contains the Resource Name of a 362 ResourceNameExtension (see Section 5.2) to be used by a Shared 363 Resource with variable resource name. This name serves the 364 storing peer for validating, whether a variable resources name 365 matches one of the predefined naming pattern from the 366 configuration document for this Kind. The presence of this field 367 is bound to a variable resource name element in the corresponding 368 kind-block of the configuration document whose "enable" attribute 369 is set to true (see Section 5.3). Otherwise, if the "enable" 370 attribute is false, the res_name_ext field SHALL NOT be present in 371 the Kind data structure. 373 to_user: This field contains the user name of the RELOAD peer that 374 obtains write permission to the Shared Resource. 376 kind: This field contains the Kind-ID of the Shared Resource. 378 allow_delegation: If true, this Boolean flag indicates that the 379 Authorized Peer in the 'to_user' field is allowed to add 380 additional entries to the ACL for the specified Kind-ID. 382 5. Extension for Variable Resource Names 384 5.1. Overview 386 In certain use cases such as conferencing it is desirable to increase 387 the flexibility of a peer in using Resource Names beyond those 388 defined by the user name or Node-ID fields in its certificate. For 389 this purpose, this document presents the concept for variable 390 Resources Names that enables providers of RELOAD instances to define 391 relaxed naming schemes for overlay Resources. 393 Each RELOAD node uses a certificate to identify itself using its user 394 name (or Node-ID) while storing data under a specific Resource-ID 395 (see Section 7.3 in [RFC6940]). The specifications in this document 396 scheme adhere to this paradigm, but enable a RELOAD peer to store 397 values of Resource Names that are derived from the user name in its 398 certificate. This is done by using a Resource Name with a variable 399 substring that still matches the user name in the certificate using a 400 pattern defined in the overlay configuration document. Thus despite 401 being variable, an allowable Resource Name remains tied to the 402 Owner's certificate. A sample pattern might be formed as follows. 404 Example Pattern: 405 .*-conf-$USER@$DOMAIN 407 When defining the pattern, care must be taken to avoid conflicts 408 arising from two user names of witch one is a substring of the other. 409 In such cases, the holder of the shorter name could threaten to block 410 the resources of the longer-named peer by choosing the variable part 411 of a Resource Name to contain the entire longer user name. This 412 problem can easily be mitigated by delimiting the variable part of 413 the pattern from the user name part by some fixed string, that by 414 convention is not part of a user name (e.g., the "-conf-" in the 415 above Example). 417 5.2. Data Structure 419 This section defines the optional ResourceNameExtension structure for 420 every Kind that uses the USER-CHAIN-ACL access control policy. 422 enum { pattern(1), (255)} ResourceNameType; 424 struct { 425 ResourceNameType type; 426 uint16 length; 428 select(type) { 429 case pattern: 430 opaque resource_name<0..2^16-1>; 432 /* Types can be extended */ 433 }; 434 } ResourceNameExtension; 436 The content of the ResourceNameExtension consist of 438 length: This field contains the length of the remaining data 439 structure. It is only used to allow for further extensions to 440 this data structure. 442 The content of the rest of the data structure depends of the 443 ResourceNameType. Currently, the only defined type is "pattern". 445 If the type is "pattern", then the following data structure contains 446 an opaque <0..2^16-1> field containing the Resource Name of the Kind 447 being stored. The type "pattern" further indicates that the Resource 448 Name MUST match to one of the variable resource name pattern defined 449 for this Kind in the configuration document. 451 The ResourceNameType enum and the ResourceNameExtension structure can 452 be extended by further Usages to define other naming schemes. 454 5.3. Overlay Configuration Document Extension 456 This section extends the overlay configuration document by defining 457 new elements for patterns relating resource names to user names. It 458 is noteworthy that additional constraints on the syntax and semantic 459 of names can apply according to specific Usages. For example, AOR 460 syntax restrictions apply when using P2PSIP[I-D.ietf-p2psip-sip], 461 while a more general naming is feasible in plain RELOAD. 463 The element serves as a container for one 464 or multiple sub-elements. It is an additional parameter 465 within the kind-block and has a boolean "enable" attribute that 466 indicates, if true, that the overlay provider allows variable 467 resource names for this Kind. The default value of the "enable" 468 attribute is "false". In the absence of a 469 element for a Kind using the USER-CHAIN-ACL access policy (see 470 Section 6.6), implementors MUST assume this default value. 472 A element MUST be present if the "enabled" attribute of its 473 parent element is set to true. Each element defines a 474 pattern for constructing extended resource names for a single Kind. 475 It is of type xsd:string and interpreted as a regular expression 476 according to "POSIX Extended Regular Expression" (see the 477 specifications in [IEEE-Posix]). In this regular expression, $USER 478 and $DOMAIN are used as variables for the corresponding parts of the 479 string in the certificate user name field (with $USER preceding and 480 $DOMAIN succeeding the '@'). Both variables MUST be present in any 481 given pattern definition. Furthermore, variable parts in 482 elements defined in the overlay configuration document MUST remain 483 syntactically separated from the user name part (e.g., by a dedicated 484 delimiter) to prevent collisions with other names of other users. If 485 no pattern is defined for a Kind, if the "enable" attribute is false, 486 or if the regular expression does not meet the requirements specified 487 in this section, the allowable Resource Names are restricted to the 488 user name of the signer for Shared Resource. 490 The Relax NG Grammar for the Variable Resource Names Extension reads: 492 # VARIABLE RESOURCE URN SUB-NAMESPACE 494 namespace share = "urn:ietf:params:xml:ns:p2p:config-base:share" 496 # VARIABLE RESOURCE NAMES ELEMENT 498 kind-parameter &= element share:variable-resource-names { 500 attribute enable { xsd:boolean }, 502 # PATTERN ELEMENT 504 element share:pattern { xsd:string }* 505 }? 507 6. Access Control to Shared Resources 509 6.1. Granting Write Access 511 Write access to a Kind that is intended to be shared with other 512 RELOAD users can solely be initiated by the Resource Owner. A 513 Resource Owner can share RELOAD Kinds by using the following 514 procedure. 516 o The Resource Owner stores an ACL root item at the Resource-ID of 517 the Shared Resource. The root item contains the resource name 518 extension field (see Section 5.2), the user name of the Resource 519 Owner and Kind-ID of the Shared Resource. The allow_delegation 520 flag is set to 1. The index of array data structure MUST be 521 generated as described in Section 3.1 523 o Further ACL items for this Kind-ID stored by the Resource Owner 524 MAY delegate write access to Authorized Peers. These ACL items 525 contain the same resource name extension field, the user name of 526 the Authorized Peer and the Kind-Id of the Shared Resource. 527 Optionally, the Resource Owner sets the "ad" to 1 (the default 528 equals 0) to enable the Authorized Peer to further delegate write 529 access. For each succeeding ACL item, the Resource Owner 530 increments its individual index value by one (see Section 3.1) so 531 that items can be stored in the numerical order of the array index 532 starting with the index of the root item. 534 An Authorized Peer with delegation allowance ("ad"=1) can extend the 535 access to an existing Shared Resource as follows. 537 o An Authorized Peer can store additional ACL items at the Resource- 538 ID of the Shared Resource. These ACL items contain the resource 539 name extension field, the user name of the newly Authorized Peer, 540 and the Kind-Id of the Shared Resource. Optionally, the "ad" flag 541 is set to 1 for allowing the newly Authorized Peer to further 542 delegate write access. The array index MUST be generated as 543 described in Section 3.1. Each succeeding ACL item can be stored 544 in the numerical order of the array index. 546 A store request by an Authorized Peer that attempts to overwrite any 547 ACL item signed by another Peer is unauthorized and causes an 548 Error_Forbidden response from the Storing Peer. Such access 549 conflicts could be caused by an array index collision. However, the 550 probability of a collision of two or more identical array indices 551 will be negligibly low using the mechanism for isolating stored data 552 (see Section 3.1) 554 6.2. Revoking Write Access 556 Write permissions are revoked by storing a non-existent value 557 (see[RFC6940] Section 7.2.1) at the corresponding item of the Access 558 Control List. Revoking a permission automatically invalidates all 559 delegations performed by that user including all subsequent 560 delegations. This allows to invalidate entire subtrees of the 561 delegations tree with only a single operation. Overwriting the root 562 item with a non-existent value of an Access List invalidates the 563 entire delegations tree. 565 An existing ACL item MUST only be overwritten by the user who 566 initially stored the corresponding entry, or by the Resource Owner 567 that is allowed to overwrite all ACL items for revoking write access. 569 To protect the privacy of the users, the Resource Owner SHOULD 570 overwrite all subtrees that have been invalidated. 572 6.3. Validating Write Access through an ACL 574 Access Control Lists are used to transparently validate authorization 575 of peers for writing a data value at a Shared Resource. Thereby it 576 is assumed that the validating peer is in possession of the complete 577 and most recent ACL for a specific Resource/Kind pair. The 578 corresponding procedure consists of recursively traversing the trust 579 delegation tree with strings compared as binary objects. It proceeds 580 as follows. 582 1. Obtain the user name of the certificate used for signing the data 583 stored at the Shared Resource. 585 2. Validate that an item of the corresponding ACL (i.e., for this 586 Resource/Kind pair) contains a "to_user" field whose value equals 587 the user name obtained in step 1. If the Shared Resource under 588 examination is an Access Control List Kind, further validate if 589 the "ad" flag is set to 1. 591 3. Select the user name of the certificate that was used to sign the 592 ACL item obtained in step 2. 594 4. Validate that an item of the corresponding ACL contains a 595 "to_user" field whose value equals the user name obtained in step 596 3. Additionally validate that the "ad" flag is set to 1. 598 5. Repeat steps 3 and 4 until the "to_user" value is equal to the 599 user name of the signer of the previously selected ACL item. 600 This final ACL item is expected to be the root item of this ACL 601 which MUST be further validated by verifying that the root item 602 was signed by the owner of the ACL Resource. 604 The trust delegation chain is valid if and only if all verification 605 steps succeed. In this case, the creator of the data value of the 606 Shared Resource is an Authorized Peer. 608 Note that the ACL validation procedure can be omitted whenever the 609 creator of data at a Shared Resource is the Resource Owner itself. 610 The latter can be verified by its public key certificate as defined 611 in Section 6.6. 613 6.4. Operations of Storing Peers 615 Storing peers at which Shared Resource and ACL are physically stored, 616 are responsible for controlling storage attempts to a Shared Resource 617 and its corresponding Access Control List. To assert the USER-CHAIN- 618 ACL access policy (see Section 6.6), a storing peer MUST perform the 619 access validation procedure described in Section 6.3 on any incoming 620 store request using the most recent Access Control List for every 621 Kind that uses the USER-CHAIN-ACL policy. It SHALL further ensure 622 that only the Resource Owner stores new ACL root items for Shared 623 Resources. 625 6.5. Operations of Accessing Peers 627 Accessing peers, i.e., peers that fetch a Shared Resource, MAY 628 validate that the originator of a Shared Resource was authorized to 629 store data at this Resource-ID by processing the corresponding ACL. 630 To enable an accessing peer to perform the access validation 631 procedure described in Section 6.3, it first needs to obtain the most 632 recent Access Control List in the following way. 634 1. Send a Stat request to the Resource-ID of the Shared Resource to 635 obtain all array indexes of stored ACL Kinds (as per [RFC6940], 636 Section 7.4.3.) 638 2. Fetch all indexes of existing ACL items at this Resource-ID by 639 using the array ranges retrieved in the Stat request answer 641 Peers can cache previously fetched Access Control Lists up to the 642 maximum lifetime of an individual item. Since stored values could 643 have been modified or invalidated prior to their expiration, an 644 accessing peer SHOULD use a Stat request to check for updates prior 645 to using the data cache. 647 6.6. USER-CHAIN-ACL Access Policy 649 This document specifies an additional access control policy to the 650 RELOAD base document [RFC6940]. The USER-CHAIN-ACL policy allows 651 Authorized Peers to write a Shared Resource, even though they do not 652 own the corresponding certificate. Additionally, the USER-CHAIN-ACL 653 allows the storage of Kinds with a variable resource name that are 654 following one of the specified naming pattern. Hence, on an inbound 655 store request on a Kind that uses the USER-CHAIN-ACL access policy, 656 the following rules MUST be applied: 658 In the USER-CHAIN-ACL policy, a given value MUST be written or 659 overwritten, if either one of USER-MATCH or USER-NODE-MATCH 660 (mandatory if the data model is dictionary) access policies of the 661 base document [RFC6940] applies. 663 Otherwise, the value MUST be written if the certificate of the signer 664 contains a user name that matches to the user and domain portion in 665 one of the variable resource name patterns (c.f. Section 5) 666 specified in the configuration document and, additionally, the hashed 667 Resource Name matches the Resource-ID. The Resource Name of the Kind 668 to be stored MUST be taken from the mandatory ResourceNameExtension 669 field in the corresponding Kind data structure. 671 Otherwise, the value MUST be written if the ACL validation procedure 672 described in Section 6.3 has been successfully applied. 674 Otherwise, the store request MUST be denied. 676 7. ACCESS-CONTROL-LIST Kind Definition 678 This section defines the ACCESS-CONTROL-LIST Kind previously 679 described in this document. 681 Name: ACCESS-CONTROL-LIST 683 Kind IDs: The Resource Name for ACCESS-CONTROL-LIST Kind-ID is the 684 Resource Name of the Kind that will be shared by using the ACCESS- 685 CONTROL-LIST Kind. 687 Data Model: The data model for the ACCESS-CONTROL-LIST Kind-ID is 688 array. The array indexes are formed by using the mechanism for 689 isolated stored data as described in Section 3.1 691 Access Control: USER-CHAIN-ACL (see Section 6.6) 693 8. Security Considerations 695 In this section we discuss security issues that are relevant to the 696 usage of shared resources in RELOAD. 698 8.1. Resource Exhaustion 700 Joining a RELOAD overlay inherently poses a certain resource load on 701 a peer, because it has to store and forward data for other peers. In 702 common RELOAD semantics, each Resource ID and thus position in the 703 overlay may only be written by a limited set of peers - often even 704 only a single peer, which limits this burden. In the case of Shared 705 Resources, a single resource may be written by multiple peers, who 706 may even write an arbitrary number of entries (e.g., delegations in 707 the ACL). This leads to an enhanced use of resources at individual 708 overlay nodes. The problem of resource exhaustion can easily be 709 mitigated for Usages based on the ShaRe-Usage by imposing 710 restrictions on size, i.e., element for a certain Kind in 711 the configuration document. 713 8.2. Malicious or Misbehaving Storing Peer 715 The RELOAD overlay is designed to operate despite the presence of a 716 small set of misbehaving peers. This is not different for Shared 717 Resources since a small set of malicious peers does not disrupt the 718 functionality of the overlay in general, but may have implications 719 for the peers needing to store or access information at the specific 720 locations in the ID space controlled by a malicious peer. A storing 721 peer could withhold stored data which results in a denial of service 722 to the group using the specific resource. But it could not return 723 forged data, since the validity of any stored data can be 724 independently verified using the attached signatures. 726 8.3. Trust Delegation to a Malicious or Misbehaving Peer 728 A Resource Owner that erroneously delegated write access to a Shared 729 Resource for a misbehaving peer enables this malicious member of the 730 overlay to interfere with the corresponding group application in 731 several unwanted ways. Examples of destructive interferences range 732 from exhausting shared storage to dedicated application-specific 733 misuse. Additionally, a bogus peer that was granted delegation 734 rights may authorize further malicious collaborators to writing the 735 Shared Resource. 737 It is the obligation of the Resource Owner to bind trust delegation 738 to apparent trustworthiness. Additional measures to monitor proper 739 behavior may be applied. In any case, the Resource Owner will be 740 able to revoke trust delegation of an entire tree in a single 741 overwrite operation. It further holds the right to overwrite any 742 malicious contributions to the shared resource under misuse. 744 8.4. Privacy Issues 746 All data stored in the Shared Resource is readable by any node in the 747 overlay, thus applications requiring privacy need to encrypt the 748 data. The ACL needs to be stored unencrypted, thus the list members 749 of a group using a Shared Resource will always be publicly visible. 751 9. IANA Considerations 753 9.1. Access Control Policy 755 IANA shall register the following entry in the "RELOAD Access Control 756 Policies" Registry (cf., [RFC6940]) to represent the USER-CHAIN-ACL 757 Access Control Policy, as described in Section 6.6. [NOTE TO IANA/ 758 RFC-EDITOR: Please replace RFC-AAAA with the RFC number for this 759 specification in the following list.] 761 +-------------------+----------+ 762 | Kind | RFC | 763 +-------------------+----------+ 764 | USER-CHAIN-ACL | RFC-AAAA | 765 +-------------------+----------+ 767 9.2. Data Kind-ID 769 IANA shall register the following code point in the "RELOAD Data 770 Kind-ID" Registry (cf., [RFC6940]) to represent the ShaRe ACCESS- 771 CONTROL-LIST kind, as described in Section 7. [NOTE TO IANA/RFC- 772 EDITOR: Please replace RFC-AAAA with the RFC number for this 773 specification in the following list.] 775 +----------------------+------------+----------+ 776 | Kind | Kind-ID | RFC | 777 +----------------------+------------+----------+ 778 | ACCESS-CONTROL-LIST | TBD | RFC-AAAA | 779 +----------------------+------------+----------+ 781 9.3. XML Name Space Registration 783 This document registers the following URI for the config XML name 784 space in the IETF XML registry defined in [RFC3688] 786 URI: urn:ietf:params:xml:ns:p2p:config-base:share 788 Registrant Contact: The IESG 789 XML: N/A, the requested URI is an XML name space 791 10. References 793 10.1. Normative References 795 [IEEE-Posix] 796 "IEEE Standard for Information Technology - Portable 797 Operating System Interface (POSIX) - Part 2: Shell and 798 Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 799 1-55937-255-9, January 1993. 801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 802 Requirement Levels", BCP 14, RFC 2119, 803 DOI 10.17487/RFC2119, March 1997, 804 . 806 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 807 DOI 10.17487/RFC3688, January 2004, 808 . 810 [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., 811 and H. Schulzrinne, "REsource LOcation And Discovery 812 (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, 813 January 2014, . 815 10.2. Informative References 817 [I-D.ietf-p2psip-concepts] 818 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 819 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 820 draft-ietf-p2psip-concepts-08 (work in progress), February 821 2016. 823 [I-D.ietf-p2psip-sip] 824 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., 825 Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD", 826 draft-ietf-p2psip-sip-17 (work in progress), March 2016. 828 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 829 Jacobson, "RTP: A Transport Protocol for Real-Time 830 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 831 July 2003, . 833 Acknowledgments 835 This work was stimulated by fruitful discussions in the P2PSIP 836 working group and SAM research group. We would like to thank all 837 active members for constructive thoughts and feedback. In 838 particular, the authors would like to thank (in alphabetical order) 839 Emmanuel Baccelli, Alissa Cooper Lothar Grimm, Cullen Jennings, Peter 840 Musgrave, Joerg Ott, Marc Petit-Huguenin, Peter Pogrzeba, and Jan 841 Seedorf. This work was partly funded by the German Federal Ministry 842 of Education and Research, projects HAMcast, Mindstone, and SAFEST. 844 Authors' Addresses 846 Alexander Knauf 847 HAW Hamburg 848 Berliner Tor 7 849 Hamburg D-20099 850 Germany 852 Phone: +4940428758067 853 Email: alexanderknauf@gmail.com 855 Thomas C. Schmidt 856 HAW Hamburg 857 Berliner Tor 7 858 Hamburg D-20099 859 Germany 861 Email: t.schmidt@haw-hamburg.de 862 URI: http://inet.haw-hamburg.de/members/schmidt 864 Gabriel Hege 865 daviko GmbH 866 Schillerstr. 107 867 Berlin D-10625 868 Germany 870 Phone: +493043004344 871 Email: hege@daviko.com 872 Matthias Waehlisch 873 link-lab & FU Berlin 874 Hoenower Str. 35 875 Berlin D-10318 876 Germany 878 Email: mw@link-lab.net 879 URI: http://www.inf.fu-berlin.de/~waehl