idnits 2.17.1 draft-ietf-p2psip-share-10.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 354 has weird spacing: '...tension res_n...' -- The document date (November 13, 2016) is 2720 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' Summary: 0 errors (**), 0 flaws (~~), 2 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: May 17, 2017 G. Hege 6 daviko GmbH 7 M. Waehlisch 8 link-lab & FU Berlin 9 November 13, 2016 11 A Usage for Shared Resources in RELOAD (ShaRe) 12 draft-ietf-p2psip-share-10 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 May 17, 2017. 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 . . . . . . . . 11 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 . . . 17 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 . . . . . . . . . . . . . . . 18 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), which allows for application-specific extensions 99 by 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 variable names. 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 [RFC7904], or distributed conferencing). Of 114 particular interest are rendezvous processes, where a single 115 identifier is linked to multiple, dynamic instances of a distributed 116 cooperative service. Shared write access is based on a trust 117 delegation mechanism that transfers the authorization to write a 118 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 [RFC7890], in particular the RELOAD Usage, 145 Resource and Kind. Additionally, the following terms are used: 147 Shared Resource: The term Shared Resource in this document defines a 148 RELOAD Resource with its associated Kinds, that can be written or 149 overwritten by multiple RELOAD users following the specifications 150 in this document. 152 Access Control List: The term Access Control List in this document 153 defines a logical list of RELOAD users allowed to write a specific 154 RELOAD Resource/Kind pair by following the specifications in this 155 document. The list items are stored as Access Control List Kinds 156 that map trust delegations from user A to user B, where A is 157 allowed to write a Shared Resource and the Access Control List, 158 while B is a user that obtains write access to specified Kinds 159 from A. 161 Resource Owner: The term Resource Owner in this document defines a 162 RELOAD peer that initially stored a Resource to be shared. The 163 Resource Owner possesses the RELOAD certificate that grants write 164 access to a specific Resource/Kind pair using the RELOAD 165 certificate-based access control policies. 167 Authorized Peer: The term Authorized Peer in this document defines a 168 RELOAD peer that was granted write access to a Shared Resource by 169 permission of the Resource Owner or another Authorized Peer. 171 3. Shared Resources in RELOAD 173 A RELOAD user that owns a certificate for writing at a specific 174 overlay location can maintain one or more RELOAD Kinds that are 175 designated for a non-exclusive write access shared with other RELOAD 176 users. The mechanism to share those Resource/Kind pairs with a group 177 of users consists of two basic steps. 179 1. Storage of the Resource/Kind pairs to be shared. 181 2. Storage of an Access Control List (ACL) associated with those 182 Kinds. 184 ACLs are created by the Resource Owner and contain ACL items, each 185 delegating the permission of writing the shared Kind to a specific 186 user called the Authorized Peer. For each shared Kind data, its 187 Resource owner stores a root item that initiates an Access Control 188 List. Trust delegation to the Authorized Peer can include the right 189 to further delegate the write permission, enabling a tree of trust 190 delegations with the Resource Owner as trust anchor at its root. 192 The Resource/Kind pair to be shared can be any RELOAD Kind that 193 complies to the following specifications: 195 Isolated Data Storage: To prevent concurrent writing from race 196 conditions, each data item stored within a Shared Resource SHALL 197 be exclusively maintained by the RELOAD user who created it. 198 Hence, Usages that allow the storage of Shared Resources are 199 REQUIRED to use either the array or dictionary data model and 200 apply additional mechanisms for isolating data as described in 201 Section 3.1. 203 Access Control Policy: To ensure write access to Shared Resource by 204 Authorized Peers, each Usage MUST use the USER-CHAIN-ACL access 205 policy as described in Section 6.6. 207 Resource Name Extension: To enable Shared Resources to be stored 208 using a variable resource name, this document defines an optional 209 ResourceNameExtension structure. It contains the Resource Name of 210 the Kind data to be stored and allows any receiver of a shared 211 data to validate whether the Resource Name hashes to the Resource- 212 ID. The ResourceNameExtension is made optional by configuration. 213 The ResourceNameExtension field is only present in the Kind data 214 structure when configured in the corresponding kind-block of the 215 overlay configuration document (for more details see Section 5.3). 216 If the configuration allows variable resource names, a Kind using 217 the USER-CHAIN-ACL policy MUST use the ResourceNameExtension as 218 initial field within the Kind data structure definition. 219 Otherwise the Kind data structure does not contain the 220 ResourceNameExtension structure. 222 3.1. Mechanisms for Isolating Stored Data 224 This section defines mechanisms to avoid race conditions while 225 concurrently writing an array or dictionary of a Shared Resource. 227 If a dictionary is used in the Shared Resource, the dictionary key 228 MUST be the Node-ID of the certificate that will be used to sign the 229 stored data. Thus data access is bound to the unique ID holder, and 230 write concurrency does not occur. 232 If the data model of the Shared Resource is an array, each Authorized 233 Peer that chooses to write data SHALL obtain its exclusive range of 234 the array indices. The following algorithm will generate an array 235 indexing scheme that avoids collisions. 237 1. Obtain the Node-ID of the certificate that will be used to sign 238 the stored data 240 2. Take the least significant 24 bits of that Node-ID to prefix the 241 array index 243 3. Append an 8 bit individual index value to those 24 bit of the 244 Node-ID 246 The resulting 32 bits long integer MUST be used as the index for 247 storing an array entry in a Shared Resource. The 24 bits of the 248 Node-ID serve as a collision-resistant identifier. The 8 bit 249 individual index remain under the control of a single Peer and can be 250 incremented individually for further array entries. In total, each 251 Peer can generate 256 distinct entries for application-specific use. 253 The mechanism to create the array index inherits collision-resistance 254 from the overlay hash function in use (e.g., SHA-1). It is designed 255 to work reliably for small sizes of groups as applicable to resource 256 sharing. In the rare event of a collision, the Storing Peer will 257 refuse to (over-)write the requested array index and protect indexing 258 integrity as defined in Section 6.1. A Peer could rejoin the overlay 259 with different Node-ID in such a case. 261 4. Access Control List Definition 263 4.1. Overview 265 An Access Control List (ACL) is a (self-managed) shared resource that 266 contains a list of AccessControlListItem structures as defined in 267 Section 4.2. Each entry delegates write access for a specific Kind 268 data to a single RELOAD user. An ACL enables the RELOAD user who is 269 authorized to write a specific Resource-ID to delegate his exclusive 270 write access to a specific Kind to further users of the same RELOAD 271 overlay. Each Access Control List data structure therefore carries 272 the information about who obtains write access, the Kind-ID of the 273 Resource to be shared, and whether delegation includes write access 274 to the ACL itself. The latter condition grants the right to delegate 275 write access further for the Authorized Peer. Access Control Lists 276 are stored at the same overlay location as the Shared Resource and 277 use the RELOAD array data model. They are initially created by the 278 Resource Owner. 280 Figure 1 shows an example of an Access Control List. We omit the 281 res_name_ext field to simplify illustration. The array entry at 282 index 0x123abc01 displays the initial creation of an ACL for a Shared 283 Resource of Kind-ID 1234 at the same Resource-ID. It represents the 284 root item of the trust delegation tree for this shared RELOAD Kind. 285 The root entry MUST contain the user name of the Resource owner in 286 the "to_user" field and can only be written by the owner of the 287 public key certificate associated with this Resource-ID. The 288 allow_delegation (ad) flag for a root ACL item is set to 1 by 289 default. The array index is generated by using the mechanism for 290 isolating stored data as described in Section 3.1. Hence, the most 291 significant 24 bits of the array index (0x123abc) are the least 292 significant 24 bits of the Node-ID of the Resource Owner. 294 The array item at index 0x123abc02 represents the first trust 295 delegation to an Authorized Peer that is thus permitted to write to 296 the Shared Resource of Kind-ID 1234. Additionally, the Authorized 297 peer Alice is also granted write access to the ACL as indicated by 298 the allow_delegation flag (ad) set to 1. This configuration 299 authorizes Alice to store further trust delegations to the Shared 300 Resource, i.e., add items to the ACL. On the contrary, index 301 0x456def01 illustrates trust delegation for Kind-ID 1234, in which 302 the Authorized Peer Bob is not allowed to grant access to further 303 peers (ad = 0). Each Authorized Peer signs its ACL items by using 304 its own signer identity along with its own private key. This allows 305 other peers to validate the origin of an ACL item and makes ownership 306 transparent. 308 To manage Shared Resource access of multiple Kinds at a single 309 location, the Resource Owner can create new ACL entries that refer to 310 another Kind-ID as shown in array entry index 0x123abc03. Note that 311 overwriting existing items in an Access Control List with a change in 312 the Kind-ID revokes all trust delegations in the corresponding 313 subtree (see Section 6.2). Authorized Peers are only enabled to 314 overwrite existing ACL item they own. The Resource Owner is allowed 315 to overwrite any existing ACL item, but should be aware of its 316 consequences on the trust delegation chain. 318 +------------------------------------------------------+ 319 | Access Control List | 320 +-----------+------------------------------+-----------+ 321 | #Index | Array Entries | signed by | 322 +-----------+------------------------------+-----------+ 323 | 123abc01 | to_user:Owner Kind:1234 ad:1 | Owner | 324 +-----------+------------------------------+-----------+ 325 | 123abc02 | to_user:Alice Kind:1234 ad:1 | Owner | 326 +-----------+------------------------------+-----------+ 327 | 123abc03 | to_user:Owner Kind:4321 ad:1 | Owner | 328 +-----------+------------------------------+-----------+ 329 | 123abc04 | to_user:Carol Kind:4321 ad:0 | Owner | 330 +-----------+------------------------------+-----------+ 331 | ... | ... | ... | 332 +-----------+------------------------------+-----------+ 333 | 456def01 | to_user:Bob Kind:1234 ad:0 | Alice | 334 +-----------+------------------------------+-----------+ 335 | ... | ... | ... | 336 +-----------+------------------------------+-----------+ 338 Figure 1: Simplified example of an Access Control List including 339 entries for two different Kind-IDs and varying delegation (ad) 340 configurations 342 Implementors of ShaRe should be aware that the trust delegation in an 343 Access Control List need not be loop free. Self-contained circular 344 trust delegation from A to B and B to A are syntactically possible, 345 even though not very meaningful. 347 4.2. Data Structure 349 The Kind data structure for the Access Control List is defined as 350 follows: 352 struct { 353 /* res_name_ext is optional, see documentation */ 354 ResourceNameExtension res_name_ext; 355 opaque to_user<0..2^16-1>; 356 KindId kind; 357 Boolean allow_delegation; 358 } AccessControlListItem; 360 The AccessControlListItem structure is composed of: 362 res_name_ext: This optional field contains the Resource Name of a 363 ResourceNameExtension (see Section 5.2) to be used by a Shared 364 Resource with variable resource name. This name is used by the 365 storing peer for validating, whether a variable resources name 366 matches one of the predefined naming pattern from the 367 configuration document for this Kind. The presence of this field 368 is bound to a variable resource name element in the corresponding 369 kind-block of the configuration document whose "enable" attribute 370 is set to true (see Section 5.3). Otherwise, if the "enable" 371 attribute is false, the res_name_ext field SHALL NOT be present in 372 the Kind data structure. 374 to_user: This field contains the user name of the RELOAD peer that 375 obtains write permission to the Shared Resource. 377 kind: This field contains the Kind-ID of the Shared Resource. 379 allow_delegation: If true, this Boolean flag indicates that the 380 Authorized Peer in the 'to_user' field is allowed to add 381 additional entries to the ACL for the specified Kind-ID. 383 5. Extension for Variable Resource Names 385 5.1. Overview 387 In certain use cases, such as conferencing, it is desirable to 388 increase the flexibility of a peer in using Resource Names beyond 389 those defined by the user name or Node-ID fields in its certificate. 390 For this purpose, this document presents the concept for variable 391 Resources Names that enables providers of RELOAD instances to define 392 relaxed naming schemes for overlay Resources. 394 Each RELOAD node uses a certificate to identify itself using its user 395 name (or Node-ID) while storing data under a specific Resource-ID 396 (see Section 7.3 in [RFC6940]). The specifications in this document 397 scheme adhere to this paradigm, but enable a RELOAD peer to store 398 values of Resource Names that are derived from the user name in its 399 certificate. This is done by using a Resource Name with a variable 400 substring that still matches the user name in the certificate using a 401 pattern defined in the overlay configuration document. Thus despite 402 being variable, an allowable Resource Name remains tied to the 403 Owner's certificate. A sample pattern might be formed as follows. 405 Example Pattern: 406 .*-conf-$USER@$DOMAIN 408 When defining the pattern, care must be taken to avoid conflicts 409 arising from two user names of which one is a substring of the other. 410 In such cases, the holder of the shorter name could threaten to block 411 the resources of the longer-named peer by choosing the variable part 412 of a Resource Name to contain the entire longer user name. For 413 example, a "*$USER" pattern would allow user EVE to define a resource 414 with name "STEVE" and to block the resource name for user STEVE 415 through this. This problem can easily be mitigated by delimiting the 416 variable part of the pattern from the user name part by some fixed 417 string, that by convention is not part of a user name (e.g., the 418 "-conf-" in the above Example). 420 5.2. Data Structure 422 This section defines the optional ResourceNameExtension structure for 423 every Kind that uses the USER-CHAIN-ACL access control policy. 425 enum { pattern(1), (255)} ResourceNameType; 427 struct { 428 ResourceNameType type; 429 uint16 length; 431 select(type) { 432 case pattern: 433 opaque resource_name<0..2^16-1>; 435 /* Types can be extended */ 436 }; 437 } ResourceNameExtension; 439 The content of the ResourceNameExtension consist of 441 length: This field contains the length of the remaining data 442 structure. It is only used to allow for further extensions to 443 this data structure. 445 The content of the rest of the data structure depends of the 446 ResourceNameType. Currently, the only defined type is "pattern". 448 If the type is "pattern", then the following data structure contains 449 an opaque <0..2^16-1> field containing the Resource Name of the Kind 450 being stored. The type "pattern" further indicates that the Resource 451 Name MUST match to one of the variable resource name pattern defined 452 for this Kind in the configuration document. 454 The ResourceNameType enum and the ResourceNameExtension structure can 455 be extended by further Usages to define other naming schemes. 457 5.3. Overlay Configuration Document Extension 459 This section extends the overlay configuration document by defining 460 new elements for patterns relating resource names to user names. It 461 is noteworthy that additional constraints on the syntax and semantic 462 of names can apply according to specific Usages. For example, 463 Address of Record (AOR) syntax restrictions apply when using P2PSIP 464 [RFC7904], while a more general naming is feasible in plain RELOAD. 466 The element serves as a container for one 467 or multiple sub-elements. It is an additional parameter 468 within the kind-block and has a boolean "enable" attribute that 469 indicates, if true, that the overlay provider allows variable 470 resource names for this Kind. The default value of the "enable" 471 attribute is "false". In the absence of a 472 element for a Kind using the USER-CHAIN-ACL access policy (see 473 Section 6.6), implementors MUST assume this default value. 475 A element MUST be present if the "enabled" attribute of its 476 parent element is set to true. Each element defines a 477 pattern for constructing extended resource names for a single Kind. 478 It is of type xsd:string and interpreted as a regular expression 479 according to "POSIX Extended Regular Expression" (see the 480 specifications in [IEEE-Posix]). In this regular expression, $USER 481 and $DOMAIN are used as variables for the corresponding parts of the 482 string in the certificate user name field (with $USER preceding and 483 $DOMAIN succeeding the '@'). Both variables MUST be present in any 484 given pattern definition. Furthermore, variable parts in 485 elements defined in the overlay configuration document MUST remain 486 syntactically separated from the user name part (e.g., by a dedicated 487 delimiter) to prevent collisions with other names of other users. If 488 no pattern is defined for a Kind, if the "enable" attribute is false, 489 or if the regular expression does not meet the requirements specified 490 in this section, the allowable Resource Names are restricted to the 491 user name of the signer for Shared Resource. 493 The Relax NG Grammar for the Variable Resource Names Extension reads: 495 # VARIABLE RESOURCE URN SUB-NAMESPACE 497 namespace share = "urn:ietf:params:xml:ns:p2p:config-base:share" 499 # VARIABLE RESOURCE NAMES ELEMENT 501 kind-parameter &= element share:variable-resource-names { 503 attribute enable { xsd:boolean }, 505 # PATTERN ELEMENT 507 element share:pattern { xsd:string }* 508 }? 510 6. Access Control to Shared Resources 512 6.1. Granting Write Access 514 Write access to a Kind that is intended to be shared with other 515 RELOAD users can solely be initiated by the Resource Owner. A 516 Resource Owner can share RELOAD Kinds by using the following 517 procedure. 519 o The Resource Owner stores an ACL root item at the Resource-ID of 520 the Shared Resource. The root item contains the resource name 521 extension field (see Section 5.2), the user name of the Resource 522 Owner and Kind-ID of the Shared Resource. The allow_delegation 523 flag is set to 1. The index of array data structure MUST be 524 generated as described in Section 3.1 526 o Further ACL items for this Kind-ID stored by the Resource Owner 527 MAY delegate write access to Authorized Peers. These ACL items 528 contain the same resource name extension field, the user name of 529 the Authorized Peer and the Kind-Id of the Shared Resource. 530 Optionally, the Resource Owner sets the "ad" to 1 (the default 531 equals 0) to enable the Authorized Peer to further delegate write 532 access. For each succeeding ACL item, the Resource Owner 533 increments its individual index value by one (see Section 3.1) so 534 that items can be stored in the numerical order of the array index 535 starting with the index of the root item. 537 An Authorized Peer with delegation allowance ("ad"=1) can extend the 538 access to an existing Shared Resource as follows. 540 o An Authorized Peer can store additional ACL items at the Resource- 541 ID of the Shared Resource. These ACL items contain the resource 542 name extension field, the user name of the newly Authorized Peer, 543 and the Kind-Id of the Shared Resource. Optionally, the "ad" flag 544 is set to 1 for allowing the newly Authorized Peer to further 545 delegate write access. The array index MUST be generated as 546 described in Section 3.1. Each succeeding ACL item can be stored 547 in the numerical order of the array index. 549 A store request by an Authorized Peer that attempts to overwrite any 550 ACL item signed by another Peer is unauthorized and causes an 551 Error_Forbidden response from the Storing Peer. Such access 552 conflicts could be caused by an array index collision. However, the 553 probability of a collision of two or more identical array indices 554 will be negligibly low using the mechanism for isolating stored data 555 (see Section 3.1) 557 6.2. Revoking Write Access 559 Write permissions are revoked by storing a non-existent value (see 560 [RFC6940] Section 7.2.1) at the corresponding item of the Access 561 Control List. Revoking a permission automatically invalidates all 562 delegations performed by that user including all subsequent 563 delegations. This allows the invalidation of entire subtrees of the 564 delegations tree with only a single operation. Overwriting the root 565 item with a non-existent value of an Access List invalidates the 566 entire delegations tree. 568 An existing ACL item MUST only be overwritten by the user who 569 initially stored the corresponding entry, or by the Resource Owner 570 that is allowed to overwrite all ACL items for revoking write access. 572 To protect the privacy of the users, the Resource Owner SHOULD 573 overwrite all subtrees that have been invalidated. 575 6.3. Validating Write Access through an ACL 577 Access Control Lists are used to transparently validate authorization 578 of peers for writing a data value at a Shared Resource. Thereby it 579 is assumed that the validating peer is in possession of the complete 580 and most recent ACL for a specific Resource/Kind pair. The 581 corresponding procedure consists of recursively traversing the trust 582 delegation tree with strings compared as binary objects. It proceeds 583 as follows. 585 1. Obtain the user name of the certificate used for signing the data 586 stored at the Shared Resource. This is the user who requested 587 the write operation. 589 2. Validate that an item of the corresponding ACL (i.e., for this 590 Resource/Kind pair) contains a "to_user" field whose value equals 591 the user name obtained in step 1. If the Shared Resource under 592 examination is an Access Control List Kind, further validate if 593 the "ad" flag is set to 1. 595 3. Select the user name of the certificate that was used to sign the 596 ACL item obtained in the previous step. 598 4. Validate that an item of the corresponding ACL contains a 599 "to_user" field whose value equals the user name obtained in step 600 3. Additionally validate that the "ad" flag is set to 1. 602 5. Repeat steps 3 and 4 until the "to_user" value is equal to the 603 user name of the signer of the ACL in the selected item. This 604 final ACL item is expected to be the root item of this ACL which 605 MUST be further validated by verifying that the root item was 606 signed by the owner of the ACL Resource. 608 The trust delegation chain is valid if and only if all verification 609 steps succeed. In this case, the creator of the data value of the 610 Shared Resource is an Authorized Peer. 612 Note that the ACL validation procedure can be omitted whenever the 613 creator of data at a Shared Resource is the Resource Owner itself. 614 The latter can be verified by its public key certificate as defined 615 in Section 6.6. 617 6.4. Operations of Storing Peers 619 Storing peers, at which Shared Resource and ACL are physically 620 stored, are responsible for controlling storage attempts to a Shared 621 Resource and its corresponding Access Control List. To assert the 622 USER-CHAIN-ACL access policy (see Section 6.6), a storing peer MUST 623 perform the access validation procedure described in Section 6.3 on 624 any incoming store request using the most recent Access Control List 625 for every Kind that uses the USER-CHAIN-ACL policy. It SHALL further 626 ensure that only the Resource Owner stores new ACL root items for 627 Shared Resources. 629 6.5. Operations of Accessing Peers 631 Accessing peers, i.e., peers that fetch a Shared Resource, can 632 validate that the originator of a Shared Resource was authorized to 633 store data at this Resource-ID by processing the corresponding ACL. 634 To enable an accessing peer to perform the access validation 635 procedure described in Section 6.3, it first needs to obtain the most 636 recent Access Control List in the following way. 638 1. Send a Stat request to the Resource-ID of the Shared Resource to 639 obtain all array indexes of stored ACL Kinds (as per [RFC6940], 640 Section 7.4.3.) 642 2. Fetch all indexes of existing ACL items at this Resource-ID by 643 using the array ranges retrieved in the Stat request answer 645 Peers can cache previously fetched Access Control Lists up to the 646 maximum lifetime of an individual item. Since stored values could 647 have been modified or invalidated prior to their expiration, an 648 accessing peer SHOULD use a Stat request to check for updates prior 649 to using the data cache. 651 6.6. USER-CHAIN-ACL Access Policy 653 This document specifies an additional access control policy to the 654 RELOAD base document [RFC6940]. The USER-CHAIN-ACL policy allows 655 Authorized Peers to write a Shared Resource, even though they do not 656 own the corresponding certificate. Additionally, the USER-CHAIN-ACL 657 allows the storage of Kinds with a variable resource name that are 658 following one of the specified naming pattern. Hence, on an inbound 659 store request on a Kind that uses the USER-CHAIN-ACL access policy, 660 the following rules MUST be applied: 662 In the USER-CHAIN-ACL policy, a given value MUST NOT be written or 663 overwritten, if neither one of USER-MATCH or USER-NODE-MATCH 664 (mandatory if the data model is dictionary) access policies of the 665 base document [RFC6940] applies. 667 Additionally, the store request MUST be denied if the certificate of 668 the signer does not contain a user name that matches to the user and 669 domain portion in one of the variable resource name patterns (c.f. 670 Section 5) specified in the configuration document or if the hashed 671 Resource Name does not match the Resource-ID. The Resource Name of 672 the Kind to be stored MUST be taken from the mandatory 673 ResourceNameExtension field in the corresponding Kind data structure. 675 The store request MUST also be denied, if the access rights cannot be 676 verified according to the ACL validation procedure described in 677 Section 6.3. 679 Otherwise, the store request can be processed further. 681 7. ACCESS-CONTROL-LIST Kind Definition 683 This section defines the ACCESS-CONTROL-LIST Kind previously 684 described in this document. 686 Name: ACCESS-CONTROL-LIST 688 Kind IDs: The Resource Name for ACCESS-CONTROL-LIST Kind-ID is the 689 Resource Name of the Kind that will be shared by using the ACCESS- 690 CONTROL-LIST Kind. 692 Data Model: The data model for the ACCESS-CONTROL-LIST Kind-ID is 693 array. The array indexes are formed by using the mechanism for 694 isolated stored data as described in Section 3.1 696 Access Control: USER-CHAIN-ACL (see Section 6.6) 698 8. Security Considerations 700 In this section we discuss security issues that are relevant to the 701 usage of shared resources in RELOAD [RFC6940]. 703 8.1. Resource Exhaustion 705 Joining a RELOAD overlay inherently poses a certain resource load on 706 a peer, because it has to store and forward data for other peers. In 707 common RELOAD semantics, each Resource-ID and thus position in the 708 overlay may only be written by a limited set of peers - often even 709 only a single peer, which limits this burden. In the case of Shared 710 Resources, a single resource may be written by multiple peers, who 711 may even write an arbitrary number of entries (e.g., delegations in 712 the ACL). This leads to an enhanced use of resources at individual 713 overlay nodes. The problem of resource exhaustion can easily be 714 mitigated for Usages based on the ShaRe-Usage by imposing 715 restrictions on size, i.e., element for a certain Kind in 716 the configuration document. 718 8.2. Malicious or Misbehaving Storing Peer 720 The RELOAD overlay is designed to operate despite the presence of a 721 small set of misbehaving peers. This is not different for Shared 722 Resources since a small set of malicious peers does not disrupt the 723 functionality of the overlay in general, but may have implications 724 for the peers needing to store or access information at the specific 725 locations in the ID space controlled by a malicious peer. A storing 726 peer could withhold stored data which results in a denial of service 727 to the group using the specific resource. But it could not return 728 forged data, since the validity of any stored data can be 729 independently verified using the attached signatures. 731 8.3. Trust Delegation to a Malicious or Misbehaving Peer 733 A Resource Owner that erroneously delegated write access to a Shared 734 Resource for a misbehaving peer enables this malicious member of the 735 overlay to interfere with the corresponding group application in 736 several unwanted ways. Examples of destructive interferences range 737 from exhausting shared storage to dedicated application-specific 738 misuse. Additionally, a bogus peer that was granted delegation 739 rights may authorize further malicious collaborators to writing the 740 Shared Resource. 742 It is the obligation of the Resource Owner to bind trust delegation 743 to apparent trustworthiness. Additional measures to monitor proper 744 behavior may be applied. In any case, the Resource Owner will be 745 able to revoke trust delegation of an entire tree in a single 746 overwrite operation. It further holds the right to overwrite any 747 malicious contributions to the shared resource under misuse. 749 8.4. Privacy Issues 751 All data stored in the Shared Resource is readable by any node in the 752 overlay, thus applications requiring privacy need to encrypt the 753 data. The ACL needs to be stored unencrypted, thus the list members 754 of a group using a Shared Resource will always be publicly visible. 756 9. IANA Considerations 758 9.1. Access Control Policy 760 IANA shall register the following entry in the "RELOAD Access Control 761 Policies" Registry (cf., [RFC6940]) to represent the USER-CHAIN-ACL 762 Access Control Policy, as described in Section 6.6. [NOTE TO IANA/ 763 RFC-EDITOR: Please replace RFC-AAAA with the RFC number for this 764 specification in the following list.] 766 +-------------------+----------+ 767 | Kind | RFC | 768 +-------------------+----------+ 769 | USER-CHAIN-ACL | RFC-AAAA | 770 +-------------------+----------+ 772 9.2. Data Kind-ID 774 IANA shall register the following code point in the "RELOAD Data 775 Kind-ID" Registry (cf., [RFC6940]) to represent the ShaRe ACCESS- 776 CONTROL-LIST kind, as described in Section 7. [NOTE TO IANA/RFC- 777 EDITOR: Please replace RFC-AAAA with the RFC number for this 778 specification in the following list.] 779 +----------------------+------------+----------+ 780 | Kind | Kind-ID | RFC | 781 +----------------------+------------+----------+ 782 | ACCESS-CONTROL-LIST | TBD | RFC-AAAA | 783 +----------------------+------------+----------+ 785 9.3. XML Name Space Registration 787 This document registers the following URI for the config XML name 788 space in the IETF XML registry defined in [RFC3688] 790 URI: urn:ietf:params:xml:ns:p2p:config-base:share 792 Registrant Contact: The IESG 794 XML: N/A, the requested URI is an XML name space 796 10. References 798 10.1. Normative References 800 [IEEE-Posix] 801 "IEEE Standard for Information Technology - Portable 802 Operating System Interface (POSIX) - Part 2: Shell and 803 Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 804 1-55937-255-9, January 1993. 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", BCP 14, RFC 2119, 808 DOI 10.17487/RFC2119, March 1997, 809 . 811 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 812 DOI 10.17487/RFC3688, January 2004, 813 . 815 [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., 816 and H. Schulzrinne, "REsource LOcation And Discovery 817 (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, 818 January 2014, . 820 10.2. Informative References 822 [RFC7890] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 823 Dawkins, "Concepts and Terminology for Peer-to-Peer SIP 824 (P2PSIP)", RFC 7890, DOI 10.17487/RFC7890, June 2016, 825 . 827 [RFC7904] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., 828 Schulzrinne, H., and T. Schmidt, Ed., "A SIP Usage for 829 REsource LOcation And Discovery (RELOAD)", RFC 7904, 830 DOI 10.17487/RFC7904, October 2016, 831 . 833 Acknowledgments 835 This work was stimulated by fruitful discussions in the P2PSIP 836 working group and the 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, Ben Campbell, Alissa Cooper, Lothar Grimm, Russ 840 Housley, Cullen Jennings, Matt Miller, Peter Musgrave, Joerg Ott, 841 Marc Petit-Huguenin, Peter Pogrzeba, and Jan Seedorf. This work was 842 partly funded by the German Federal Ministry of Education and 843 Research, projects HAMcast, Mindstone, and SAFEST. 845 Authors' Addresses 847 Alexander Knauf 848 HAW Hamburg 849 Berliner Tor 7 850 Hamburg D-20099 851 Germany 853 Phone: +4940428758067 854 Email: alexanderknauf@gmail.com 856 Thomas C. Schmidt 857 HAW Hamburg 858 Berliner Tor 7 859 Hamburg D-20099 860 Germany 862 Email: t.schmidt@haw-hamburg.de 863 URI: http://inet.haw-hamburg.de/members/schmidt 865 Gabriel Hege 866 daviko GmbH 867 Schillerstr. 107 868 Berlin D-10625 869 Germany 871 Phone: +493043004344 872 Email: hege@daviko.com 873 Matthias Waehlisch 874 link-lab & FU Berlin 875 Hoenower Str. 35 876 Berlin D-10318 877 Germany 879 Email: mw@link-lab.net 880 URI: http://www.inf.fu-berlin.de/~waehl