idnits 2.17.1 draft-knauf-p2psip-share-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 07, 2011) is 4770 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-12 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-03 == Outdated reference: A later version (-05) exists of draft-knauf-p2psip-disco-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP Working Group A. Knauf 3 Internet-Draft G. Hege 4 Intended status: Standards Track T C. Schmidt 5 Expires: September 8, 2011 HAW Hamburg 6 M. Waehlisch 7 link-lab & FU Berlin 8 March 07, 2011 10 A Usage for Shared Resources in RELOAD (ShaRe) 11 draft-knauf-p2psip-share-00 13 Abstract 15 This document defines a RELOAD Usage for shared write access to 16 RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic 17 primitive for enabling various coordination and notification schemes 18 among distributed peers. Access in ShaRe is controlled by a 19 hierarchical trust delegation scheme maintained within an access 20 list. A new USER-CHAIN-ACL access policy allows authorized peers to 21 write a Shared Resource without owning its corresponding certificate. 22 This specification also adds mechanisms to store Resources with a 23 variable name which is useful whenever peer-independent rendezvous 24 processes are required. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 8, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Shared Resources in RELOAD . . . . . . . . . . . . . . . . . . 5 63 4. Access List Definition . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Access List . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Access Control to Shared Resources . . . . . . . . . . . . . . 9 67 5.1. Granting Write Access . . . . . . . . . . . . . . . . . . 9 68 5.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 9 69 5.3. Storage and Validation . . . . . . . . . . . . . . . . . . 10 70 5.3.1. Operations of the Storing Peer . . . . . . . . . . . . 10 71 5.3.2. Operations of the Accessing Peer . . . . . . . . . . . 10 72 5.4. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . . 11 73 6. Extension for Variable Resource Names . . . . . . . . . . . . 13 74 6.1. USER-PATTERN-MATCH Access Policy . . . . . . . . . . . . . 13 75 6.2. Overlay Configuration Document Extension . . . . . . . . . 14 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 7.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 15 78 7.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 15 79 7.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 15 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 This document defines a RELOAD Usage for shared write access to 90 RELOAD Resources and a mechanism to store Resources with a variable 91 name. The Usage for Shared Resources in RELOAD (ShaRe) enables 92 overlay users to share their exclusive write access of specific 93 Resource/Kind pairs with others. Shared Resources form a basic 94 primitive for enabling various coordination and notification schemes 95 among distributed peers. Write permission is controlled by an Access 96 List Kind that maintains a chain of Authorized Peers for a particular 97 Shared Resource. Additionally, this document defines the USER-CHAIN- 98 ACL access control policy that enables a shared write access in 99 RELOAD. 101 The Usage for Shared Resources in RELOAD is designed for jointly 102 coordinated group applications among distributed peers (c.f. 103 [I-D.knauf-p2psip-disco]). Of particular interest are rendezvous 104 processes, where a single identifier is linked to multiple, dynamic 105 instances of a distributed cooperative service. Shared write access 106 is based on a trust delegation mechanism. It transfers the 107 authorization to write a specific Kind data by storing logical Access 108 Lists. An Access list contains the Kind-ID of the Kind to be shared 109 and contains trust delegations from one authorized to another 110 (previously unauthorized) user. 112 Shared write access extends the RELOAD security model, which is based 113 on the restriction that peers are only allowed to write resources at 114 a small set of well defined locations (Resource IDs) in the overlay. 115 Using the standard access control rules in RELOAD, these locations 116 are bound to the user name or Node Id in the peer's certificate. 117 This document extends these policies and allows a controlled write 118 access for multiple users at a common Resource Id. 120 Additionally, this specification defines a new access control policy 121 that enables RELOAD users to store Resources with a variable Resource 122 Name. The USER-PATTERN-MATCH policy allows the storage of Resources 123 whose name complies to a specific pattern. Definition of the pattern 124 is arbitrary, but must contain the user name of the Resource creator. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 This document uses the terminology and definitions from the RELOAD 133 base [I-D.ietf-p2psip-base]and the peer-to-peer SIP concepts draft 134 [I-D.ietf-p2psip-concepts]. Additionally, the following terms are 135 used: 137 Shared Resource: The term Shared Resource in this document defines a 138 RELOAD Resource with its associated Kinds, that can be written or 139 overwritten by multiple RELOAD users following the specifications 140 in this document. 142 Access List: The term Access List in this document defines a logical 143 list of RELOAD users allowed to write a specific RELOAD Resource/ 144 Kind pair by following the specifications in this document. The 145 list items are stored as Access List Kinds that map trust 146 delegations from user A to user B, where A is allowed to write a 147 Shared Resource and Access List, while B is a user that obtains 148 write access to specified Kinds from A. 150 Resource Owner: The term Resource Owner in this document defines a 151 RELOAD peer that initially stored a Resource to be shared. The 152 Resource Owner possesses the RELOAD certificate that grants write 153 access to a specific Resource/Kind pair using the RELOAD 154 certificate based access control policies. 156 Authorized Peer: The term Authorized Peer in this document defines a 157 RELOAD peer that was granted write access to a Shared Resource by 158 permission of the Resource Owner or another Authorized Peer. 160 3. Shared Resources in RELOAD 162 A RELOAD user that owns a certificate for writing at a specific 163 overlay location can provide one or more RELOAD Kinds that are 164 designated for a shared write access with other RELOAD users. The 165 mechanism to share those Resource/Kind pairs with a group of users 166 consists of two basic steps. Storage of the Resource/Kind pair to be 167 shared and storage of an Access List to those Kinds. Access Lists 168 are initiated by the Resource Owner and contain Access List items, 169 each delegating the permission to write the shared Kind to a specific 170 user called Authorized Peer. This trust delegation to the Authorized 171 Peer can include the right to further delegate the write permission 172 to the Shared Resource. For each shared Kind data, the Resource 173 owner stores a root item that initiates an Access List. The result 174 is a tree of trust delegations with the Resource Owner as trust 175 anchor. 177 The Resource/Kind pair to be shared can be any RELOAD Kind that 178 complies to the following specifications: 180 Separated Data Storage: The specifications in this document ensure 181 that concurrent writing does not effect race conditions. Each 182 data stored within a Shared Resource MUST be exclusively 183 maintained by the RELOAD user that created it. Hence, Usages that 184 allow the storage of Shared Resources MUST use a RELOAD data model 185 consisting of multiple objects (e.g. Array or Dictionary), each 186 assigned to a single user. 188 Access Control Policy: To ensure write access to Shared Resource by 189 Authorized Peers, each Usage MUST permit the USER-CHAIN-ACL access 190 policy (see Section 5.4) in addition to its regular access 191 policies (USER-MATCH, USER-NODE-MATCH, etc.). 193 user_name field: To identify the originator of a stored value, the 194 Kind data structure of a Resource allowing shared write access 195 MUST define a <0..2^16-1> long opaque user_name value. It 196 contains the user name value of the RELOAD certificate which was 197 used to store and sign Kind data. The user_name field allows any 198 consumer of the data to request the public key certificate of the 199 originator of the stored data and to verify its provenance and 200 integrity. 202 4. Access List Definition 204 4.1. Access List 206 An Access List in this document specifies a logical list of 207 AccessList data structures defined in Section 4.2. Each entry 208 delegates write access to specific Kind data and is stored at the 209 same overlay location as the Shared Resource. It allows the RELOAD 210 user who is authorized to write at a specific Resources-ID to 211 delegate his exclusive write access for the specified Kinds to 212 further users of a RELOAD instance. Each Access List data structure 213 therefore carries the information about who delegates write access to 214 whom, the Kind-ID of the Resource to be shared, and whether 215 delegation includes write access to the Access List itself. The 216 latter condition grants the right to delegate write access further 217 for an Authorized Peer. Access Lists are stored within a RELOAD 218 array data model and are initially created by the Resource Owner. 220 Figure 1 shows an example of an Access List. The array entry at 221 index #0 displays the initial storage of an Access list to a Shared 222 Resource with Kind-ID 1234 at the same Resource-ID. It represents 223 the root item of the trust delegation tree to the shared RELOAD Kind 224 and initiates an Access List to the specified Kind data. The root 225 entry MUST contain the mapping from Resource owner to Resource owner 226 and MUST only be written by the owner of the public key certificate 227 to this Resource-ID. 229 The array entry at index #1 represents the first trust delegation to 230 an Authorized peer that is permitted write access to the Shared 231 Resource with Kind-ID 1234. Additionally, the Authorized peer Alice 232 is also granted write access to the Access List as indicated by the 233 allow_delegation flag (AD) set to 1. It authorizes Alice to store 234 further trust delegations to the Shared Resource, respectively, store 235 items into the Access List. For instance, Alice permits Bob to 236 access the Shared Resource, but Bob in turn is not allowed to write 237 the Access List (AD = 0). The Authorized Peer Alice signs the Access 238 List item with her own private key. 240 In order to share multiple Kinds at a single location, the Resource 241 Owner can initiate new Access Lists that are referencing to another 242 Kind-IDs as shown in array entry index #42. Note that overwriting 243 existing items in an Access List that reference a different Kind-ID, 244 revokes all succeeding trust delegations in the tree. Hence, 245 Authorized Peers are not enabled to overwrite any existing Access 246 List item (see Section 5.2). The Resource Owner is allowed to 247 overwrite existing Access List items, but should be aware of its 248 consequences. 250 +-------------------------------------------------------------+ 251 | Access List | 252 +--------------------------------------+----+-----------------+ 253 | # | Array Entries | AD | Signature | 254 +---+----------------------------------+----+-----------------+ 255 | 0 | Kind:1234 from:Owner -> to:Owner | 1 | signed by Owner | 256 +---+----------------------------------+----+-----------------+ 257 | 1 | Kind:1234 from:Owner -> to:Alice | 1 | signed by Owner | 258 +---+----------------------------------+----+-----------------+ 259 | 2 | Kind:1234 from:Alice -> to:Bob | 0 | signed by Alice | 260 +---+----------------------------------+----+-----------------+ 261 |...| ... | | ... | 262 +---+----------------------------------+----+-----------------+ 263 | 42| Kind:4321 from:Owner -> to:Owner | 1 | signed by Owner | 264 +---+----------------------------------+----+-----------------+ 265 | 43| Kind:4321 from:Owner -> to:Carol | 0 | signed by Owner | 266 +---+----------------------------------+----+-----------------+ 268 Figure 1: Access list example 270 Implementations of ShaRe should be aware that the trust delegation in 271 an Access List is not loop free per se. Self-contained circular 272 trust delegation from A to B and B to A are possible, even though not 273 very meaningful. 275 4.2. Data Structure 277 The Kind data structure for the access list is defined as follows: 279 struct { 280 opaque resource_name<0..2^16-1>; 281 KindId kind; 282 opaque from_user<0..2^16-1>; 283 opaque to_user<0..2^16-1>; 284 Boolean allow_delegation; 285 } AccessListData; 287 struct { 288 uint16 length; 289 AccessListData data; 290 } AccessListItem; 292 The AccessListItem structure is composed of: 294 length: 295 Length of the Access List data structure 296 data: 298 Data of the Access List 300 The content of the AccessListData structure is defined as follows: 302 resource_name: This opaque string contains the Resource Name of the 303 Shared Resource in an opaque string. Thus, the AccessListData 304 meet the requirements for the USER-PATTERN-MATCH access policy 305 (see Section 6.1). 307 kind: This field contains the Kind-ID of the Kind that will be 308 shared. 310 from_user: This field contains the user name of that RELOAD peer the 311 grants write permission to the Shared Resource. The user name is 312 stored as an opaque string and contains the user name value of the 313 certificate that is associated with the private key that signed 314 this Access List item. 316 to_user: This field contains the user name of the RELOAD peer that 317 obtains writing permission to the Shared Resource. 319 allow_delegation: This Boolean flag indicates if true, that the 320 Authorized peer in the 'to_user' field is allowed write access to 321 the Access List in order to delegate the write permission to the 322 Shared Resource to further users. 324 The ACCESS-LIST kind is defined as follows: 326 Name ACCESS-LIST 328 Data model The Data model for the ACCESS-LIST data is array. 330 Access Control Initial storages of ACCESS-LIST data by the Resource 331 Owner use the same Access Control Policy as the Shared Resource. 332 For instance, if the access policy for the Shared Resource is 333 USER-NODE-MATCH, then the access policy for the ACCESS-LIST data 334 is USER-NODE-MATCH. Storages by Authorized Peers use the USER- 335 CHAIN-ACL access policy (see Section 5.4). 337 5. Access Control to Shared Resources 339 5.1. Granting Write Access 341 Write access to a Kind that is intended to be shared with other 342 RELOAD users can solely be issued by the Resource Owner. If the 343 Resource owner shares an existing Resource/Kind pair, it should 344 ensure that it does not unintentionally overwrite an existing Access 345 List item. Hence, before sharing the Resource, its owner performs a 346 fetch request for the Access List Kind that requests the entire 347 array. If the retrieved array does not contain an Access List root 348 item to the desired Kind, the Resource Owner stores a new root item 349 for the desired Kind-ID and sets the AccessListData vales 'from_user' 350 and 'to_user' to the user name of the Resource Owner. If an Access 351 List root item exists, the Resource Owner delegates write access by 352 storing an Access List item setting the 'from_user' to its user name 353 and setting the 'to_user' equal to the name of the RELOAD user that 354 obtains write access. 356 If an Authorized Peer intents to delegate write access to a Shared 357 Resource, it likewise fetches the entire array of the Access List 358 Kind to prevent an unauthorized write attempt to an existing Access 359 List item. Afterwards it delegates write access to the specified 360 Kind by storing an Access List item setting the 'from_user' value to 361 its own user name and setting the 'to_user' value to RELOAD user that 362 obtains write access. Note, that an Authorized Peer is only allowed 363 to add items into an Access List it is registered in with the 364 'allow_delegation' flag set to true. 366 5.2. Revoking Write Access 368 Write permissions MAY be revoked by storing a non-existent value 369 [I-D.ietf-p2psip-base] to the corresponding item in the Access 370 Control List. A revoked permission automatically invalidates all 371 delegations performed by that user and also all subsequent 372 delegations. This allows to invalidate entire subtrees of the 373 delegations tree with only a single operation. Overwriting the root 374 item with a non-existent value of an Access List invalidates the 375 entire delegations tree. 377 An Access List item MUST only be written by the user who initially 378 stored the corresponding entry. The only exception is by the 379 Resource Owner that is allowed to overwrite Access list items at all 380 times with a non-existent value for revoking write access. 382 5.3. Storage and Validation 384 5.3.1. Operations of the Storing Peer 386 The storing peer (the peer at which Shared Resource and Access List 387 are physically stored) is responsible for enforcing the correct 388 access policy when it is requested to store values of a Shared 389 Resource. The storing peer first checks, whether the request is 390 signed with the private key that corresponds to a certificate valid 391 for this Resource-ID as enforced by the standard access policies 392 (USER-MATCH, USER-NODE-MATCH, etc.) defined in the RELOAD base 393 protocol [I-D.ietf-p2psip-base], or the policy USER-PATTERN-MATCH 394 defined in this document (see Section 6.1). 396 If not, the storing peer continues by checking whether any of the 397 received RELOAD Kinds of the store request allows the USER-CHAIN-ACL 398 access control policy. If so, the storing peer fetches the Access 399 Lists for those Kinds and enforce the USER-CHAIN-ACL access policy 400 (see Section 5.4). Since the Access list MUST be stored at the same 401 overlay location as the Shared Resource, this operation is a local 402 lookup. 404 Analogously, a storing peer that is requested to store an Access List 405 Kind first verifies whether the requester is allowed to store values 406 at this Resource-ID by its certificate. Otherwise the storing peer 407 MUST locally fetch the Access List of the requested Resource Id and 408 enforce the USER-CHAIN-ACL policy. 410 5.3.2. Operations of the Accessing Peer 412 An accessing peer (a RELOAD peer that fetches a Shared Resource) 413 SHOULD validate the provenance and integrity of a retrieved data 414 value and the authorization of the data originator. The latter is 415 verified using the Access List Kind. The accessing peer requests all 416 Access Lists that are stored under the same Resource-ID as the Shared 417 Resource by requesting the entire array range. This request could be 418 sent in the same fetch request as the request for the Shared 419 Resource. The accessing peer then checks, whether any of these 420 Access Lists refers to the Kind of Shared Resource by its Kind-ID. 421 If true, the accessing peer compares the 'to_user' value of each 422 Access List item with the mandatory user_name value of the Shared 423 Resource for equality. If the comparison fails, the accessing peer 424 MUST ignore the data of the retrieved Shared Resource. Else, the 425 accessing peer repeats this comparison with the value of the 426 'from_user' field of this item with each 'to_user' field of the 427 Access List. This procedure continues until both 'from_user' and 428 'to_user' values are equal. The accessing peer then hashes the 429 'from_user' using the hash function of the overlay algorithm. If the 430 hash is equal to the Resource-ID of the Shared Resource, the 431 authority of the originator of the stored data is validated. The 432 accessing peer then proceeds with the provenance and integrity tests. 434 The accessing peer verifies provenance and integrity of the retrieved 435 kind data using the certificate corresponding to the mandatory 436 user_name field of the Shared Resource entry. The certificate can be 437 retrieved by applying the Certificate Usage [I-D.ietf-p2psip-base] or 438 other means (e.g., caching from a previous request). 440 The accessing peer MAY cache previously fetched Access List to a 441 maximum of the individual items' lifetimes. Since stored values 442 could have been changed or invalidated prior to their expiration an 443 accessing peer uses a stat request to check for updates before using 444 the cached data. If a change has been detected it fetches the latest 445 Access List. 447 5.4. USER-CHAIN-ACL Access Policy 449 This document specifies an additional access control policy to the 450 RELOAD base draft [I-D.ietf-p2psip-base]. The USER-CHAIN-ACL policy 451 allows Authorized Peers to write a Shared Resource, even though they 452 do not own the corresponding certificate. Access is controlled by 453 the values stored within the Access List Kind that explicitly permits 454 Authorized Peers writing access to Shared Resources or the Access 455 List (or both) by their user name. Hence, if a request in not signed 456 with a private key that allows write access to a Resource by any 457 access control policy defined in the RELOAD base specification, a 458 storing peer MUST enforce the USER-CHAIN-ACL policy: 460 When accessing the Shared Resource, a given value MUST be written or 461 overwritten if and only if the request is signed with a key that is 462 associated with a certificate whose user name is stored in any 463 'to_user' value of an Access List associated to the Shared Resource. 464 If true, this comparison has to be repeated for the 'from_user' value 465 of that Access List item with each other 'to_user' value in this 466 Access List. This procedure continuous until 'from_user' and to 467 'to_user' are equal. Then, if the hash over the 'from_user' equals 468 the Resource-ID, the requester is authorized to write the Shared 469 Resource. 471 When accessing the Access List, a given value MUST be written or 472 overwritten if and only if the request is signed with a key that is 473 associated with a certificate whose user name is stored in any 474 'to_user' value in the same Access List as the requested Access List. 475 Additionally, the 'allow_delegate' value of this Access List item 476 MUST be set true. If this query is successes, the comparison has to 477 be repeated for the 'from_user' value of that Access List item with 478 each other 'to_user' value in the Access List. This procedure 479 continuous until 'from_user' and to 'to_user' are equal. Then, if 480 the hash over the 'from_user' equals the Resource-ID, the requester 481 is authorized to write the Access List. 483 6. Extension for Variable Resource Names 485 In certain use cases such as conferencing (c.f. 486 [I-D.knauf-p2psip-disco]) it is desirable to extend the set of 487 Resource Names and thus Resource-IDs a peer is allowed to write 488 beyond those defined through the user name or NodeId fields in its 489 certificate. This is accomplished by the USER-PATTERN-MATCH access 490 policy described here. 492 Each RELOAD node uses a certificate to identify itself using its user 493 name (or Node-ID) while storing data under a specific Resource-ID. 494 The USER-PATTERN-MATCH scheme follows this paradigm by allowing to 495 store values whose Resource Name is derived from the user name in the 496 certificate of a RELOAD peer, but extends the set of allowed Resource 497 Names. This is done by using a Resource Name which contains a 498 variable substring but matches the user name in the certificate using 499 a pattern defined in the configuration document. Thus despite being 500 variable an allowed Resource Name is closely related to the Owner's 501 certificate. A sample pattern might be formed as the following: 503 Example Pattern: 504 .*-conf-$USER@$DOMAIN 506 When defining the pattern care must be taken that no conflict arises 507 for two user names of witch one is a substring of the other. In this 508 case the peer with the name which is the substring could choose the 509 variable part of the Resource Name so that the resulting string 510 contains the whole other user name and thus he could write the other 511 user's resources. This can easily be prevented by delimiting the 512 variable part of the pattern from the user name part by some fixed 513 string, that is usually not part of a user name (e.g. the "-conf-" in 514 the above Example). 516 6.1. USER-PATTERN-MATCH Access Policy 518 Thus, using the USER-PATTERN-MATCH policy, a given value MUST be 519 written or overwritten if and only if the request is signed with a 520 key that is associated with a certificate whose user name matches the 521 Resource Name using the pattern specified in the configuration 522 document. The Resource Name MUST be taken from an opaque 523 resource_name field in the corresponding Kind data structure. Hence, 524 each RELOAD Usage that utilizes the USER-PATTERN-MATCH policy, MUST 525 define an opaque resource_name field within the Kind data structure, 526 that contains the Resource Name whose hash equals the Resource-ID. 528 6.2. Overlay Configuration Document Extension 530 This document extends the overlay configuration document by defining 531 new elements for patterns relating resource names to user names. 533 The element serves as a container for one 534 or multiple sub-elements. 536 Each element defines the pattern to be used for a single 537 Kind. It is of type xsd:string, which is interpreted as a regular 538 expression. In the regular expression $USER and $DOMAIN are used as 539 variables for the corresponding parts of the string in the 540 certificate user name field ($USER before and $DOMAIN after the '@'). 541 Both variables MUST be present in any given pattern. The 542 element has the attribute "kind" which contains the Kind name for 543 which this pattern is used. 545 A element MUST be present for every Kind for which the 546 variable resource names extension is allowed in an overlay. 548 The Relax NG Grammar for the Variable Resource Names Extension is: 550 553 parameter &= element variable-resource-names { 554 557 element pattern { 558 attribute kind { xsd:string }, 559 xsd:string 560 }* 561 }? 563 7. Security Considerations 565 In this section we discuss security issues that are relevant to the 566 usage of shared resources in RELOAD. 568 7.1. Resource Exhaustion 570 Joining a RELOAD overlay inherently poses a certain resource load on 571 a peer, because it has to store and forward data for other peers. In 572 common RELOAD semantics, each ResourceId and thus position in the 573 overlay may only be written by a limited set of peers - often even 574 only a single peer, which limits this burden. In the case of Shared 575 Resources, a single resource may be written by multiple peers, who 576 may even write an arbitrary number of entries (e.g., delegations in 577 the ACL). This leads to an enhanced use of resources at individual 578 overlay nodes. The problem of resource exhaustion can easily be 579 mitigated for Usages based on the ShaRe-Usage by imposing 580 restrictions on the maximum number of entries a single peer is 581 allowed to write at a single location. 583 7.2. Malicious or Misbehaving Storing Peer 585 The RELOAD overlay is designed to operate despite the presence of a 586 small set of misbehaving peers. This is not different for Shared 587 Resources since a small set of malicious peers does not disrupt the 588 functionality of the overlay in general, but may have implications 589 for the peers needing to store or access information at the specific 590 locations in the ID space controlled by a malicious peer. A storing 591 peer could withhold stored data which results in a denial of service 592 to the group using the specific resource. But it could not return 593 forged data, since the validity of any stored data can be 594 independently verified using the attached signatures. 596 7.3. Privacy Issues 598 All data stored in the Shared Resource is publicly readable, thus 599 applications requiring privacy need to encrypt the data. The ACL 600 needs to be stored unencrypted, thus the list members of a group 601 using a Shared Resource will always be publicly visible. 603 8. IANA Considerations 605 TODO: register Kind-ID code point at the IANA 607 9. Acknowledgments 609 This work was stimulated by fruitful discussions in the P2PSIP 610 working group and SAM research group. We would like to thank all 611 active members for constructive thoughts and feedback. This work was 612 party funded by the German Federal Ministry of Education and 613 Research, projects HAMcast and Mindstone. 615 10. References 617 10.1. Normative References 619 [I-D.ietf-p2psip-base] 620 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 621 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 622 Base Protocol", draft-ietf-p2psip-base-12 (work in 623 progress), November 2010. 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, March 1997. 628 10.2. Informative References 630 [I-D.ietf-p2psip-concepts] 631 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 632 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 633 draft-ietf-p2psip-concepts-03 (work in progress), 634 October 2010. 636 [I-D.knauf-p2psip-disco] 637 Knauf, A., Hege, G., Schmidt, T., and M. Waehlisch, "A 638 RELOAD Usage for Distributed Conference Control (DisCo)", 639 draft-knauf-p2psip-disco-01 (work in progress), 640 December 2010. 642 Authors' Addresses 644 Alexander Knauf 645 HAW Hamburg 646 Berliner Tor 7 647 Hamburg D-20099 648 Germany 650 Phone: +4940428758067 651 Email: alexander.knauf@haw-hamburg.de 652 URI: http://inet.cpt.haw-hamburg.de/members/knauf 654 Gabriel Hege 655 HAW Hamburg 656 Berliner Tor 7 657 Hamburg D-20099 658 Germany 660 Phone: +4940428758067 661 Email: hege@fhtw-berlin.de 662 URI: http://inet.cpt.haw-hamburg.de/members/hege 664 Thomas C. Schmidt 665 HAW Hamburg 666 Berliner Tor 7 667 Hamburg D-20099 668 Germany 670 Email: schmidt@informatik.haw-hamburg.de 671 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 673 Matthias Waehlisch 674 link-lab & FU Berlin 675 Hoenower Str. 35 676 Berlin D-10318 677 Germany 679 Email: mw@link-lab.net 680 URI: http://www.inf.fu-berlin.de/~waehl