doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc8076.txt b/doc/rfc/rfc8076.txt
new file mode 100644
index 0000000..b4b401a
--- /dev/null
+++ b/doc/rfc/rfc8076.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. Knauf
+Request for Comments: 8076                               T. Schmidt, Ed.
+Category: Standards Track                                    HAW Hamburg
+ISSN: 2070-1721                                                  G. Hege
+                                                             daviko GmbH
+                                                            M. Waehlisch
+                                                    link-lab & FU Berlin
+                                                              March 2017
+
+
+             A Usage for Shared Resources in RELOAD (ShaRe)
+
+Abstract
+
+   This document defines a REsource LOcation And Discovery (RELOAD)
+   Usage for managing shared write access to RELOAD Resources.  Shared
+   Resources in RELOAD (ShaRe) form a basic primitive for enabling
+   various coordination and notification schemes among distributed
+   peers.  Access in ShaRe is controlled by a hierarchical trust
+   delegation scheme maintained within an access list.  A new
+   USER-CHAIN-ACL access policy allows authorized peers to write a
+   Shared Resource without owning its corresponding certificate.  This
+   specification also adds mechanisms to store Resources with a variable
+   name that is useful whenever peer-independent rendezvous processes
+   are required.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8076.
+
+
+
+
+
+
+
+
+
+
+
+
+Knauf, et al.                Standards Track                    [Page 1]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Knauf, et al.                Standards Track                    [Page 2]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   3.  Shared Resources in RELOAD  . . . . . . . . . . . . . . . . .   5
+     3.1.  Mechanisms for Isolating Stored Data  . . . . . . . . . .   6
+   4.  Access Control List Definition  . . . . . . . . . . . . . . .   7
+     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   7
+     4.2.  Data Structure  . . . . . . . . . . . . . . . . . . . . .   9
+   5.  Extension for Variable Resource Names . . . . . . . . . . . .  10
+     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  10
+     5.2.  Data Structure  . . . . . . . . . . . . . . . . . . . . .  11
+     5.3.  Overlay Configuration Document Extension  . . . . . . . .  12
+   6.  Access Control to Shared Resources  . . . . . . . . . . . . .  13
+     6.1.  Granting Write Access . . . . . . . . . . . . . . . . . .  13
+     6.2.  Revoking Write Access . . . . . . . . . . . . . . . . . .  14
+     6.3.  Validating Write Access through an ACL  . . . . . . . . .  14
+     6.4.  Operations of Storing Peers . . . . . . . . . . . . . . .  15
+     6.5.  Operations of Accessing Peers . . . . . . . . . . . . . .  16
+     6.6.  USER-CHAIN-ACL Access Policy  . . . . . . . . . . . . . .  16
+   7.  ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . .  17
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
+     8.1.  Resource Exhaustion . . . . . . . . . . . . . . . . . . .  17
+     8.2.  Malicious or Misbehaving Storing Peer . . . . . . . . . .  18
+     8.3.  Trust Delegation to a Malicious or Misbehaving Peer . . .  18
+     8.4.  Privacy Issues  . . . . . . . . . . . . . . . . . . . . .  18
+   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
+     9.1.  Access Control Policy . . . . . . . . . . . . . . . . . .  19
+     9.2.  Data Kind-ID  . . . . . . . . . . . . . . . . . . . . . .  19
+     9.3.  XML Namespace Registration  . . . . . . . . . . . . . . .  19
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .  20
+     10.2.  Informative References . . . . . . . . . . . . . . . . .  20
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  21
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Knauf, et al.                Standards Track                    [Page 3]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+1.  Introduction
+
+   [RFC6940] defines the base protocol for REsource LOcation And
+   Discovery (RELOAD), which allows for application-specific extensions
+   by Usages.  The present document defines such a RELOAD Usage for
+   managing shared write access to RELOAD Resources and a mechanism to
+   store Resources with variable names.  The Usage for Shared Resources
+   in RELOAD (ShaRe) enables overlay users to share their exclusive
+   write access to specific Resource/Kind pairs with others.  Shared
+   Resources form a basic primitive for enabling various coordination
+   and notification schemes among distributed peers.  Write permission
+   is controlled by an Access Control List (ACL) Kind that maintains a
+   chain of Authorized Peers for a particular Shared Resource.  A newly
+   defined USER-CHAIN-ACL access control policy enables shared write
+   access in RELOAD.
+
+   The Usage for Shared Resources in RELOAD is designed for jointly
+   coordinated group applications among distributed peers (e.g., third-
+   party registration, see [RFC7904], or distributed conferencing).  Of
+   particular interest are rendezvous processes, where a single
+   identifier is linked to multiple, dynamic instances of a distributed
+   cooperative service.  Shared write access is based on a trust
+   delegation mechanism that transfers the authorization to write a
+   specific Kind data by storing logical Access Control Lists.  An ACL
+   contains the ID of the Kind to be shared and contains trust
+   delegations from one authorized to another (previously unauthorized)
+   user.
+
+   Shared write access augments the RELOAD security model, which is
+   based on the restriction that peers are only allowed to write
+   resources at a small set of well-defined locations (Resource-IDs) in
+   the overlay.  Using the standard access control rules in RELOAD,
+   these locations are bound to the username or Node-ID in the peer's
+   certificate.  This document extends the base policies to enable a
+   controlled write access for multiple users to a common Resource-ID.
+
+   Additionally, this specification defines an optional mechanism to
+   store Resources with a variable Resource Name.  It enables the
+   storage of Resources whose name complies to a specific pattern.
+   Definition of the pattern is arbitrary, but it must contain the
+   username of the Resource creator.
+
+
+
+
+
+
+
+
+
+
+Knauf, et al.                Standards Track                    [Page 4]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+   This document uses the terminology and definitions from the RELOAD
+   base [RFC6940] and [RFC7890], in particular the RELOAD Usage,
+   Resource, and Kind.  Additionally, the following terms are used:
+
+   Shared Resource:  The term "Shared Resource" in this document defines
+      a RELOAD Resource with its associated Kinds that can be written or
+      overwritten by multiple RELOAD users following the specifications
+      in this document.
+
+   Access Control List:  The term "Access Control List" in this document
+      defines a logical list of RELOAD users allowed to write a specific
+      RELOAD Resource/Kind pair by following the specifications in this
+      document.  The list items are stored as Access Control List Kinds
+      that map trust delegations from user A to user B, where A is
+      allowed to write a Shared Resource and the Access Control List,
+      while B is a user that obtains write access to specified Kinds
+      from A.
+
+   Resource Owner:  The term "Resource Owner" in this document defines a
+      RELOAD peer that initially stored a Resource to be shared.  The
+      Resource Owner possesses the RELOAD certificate that grants write
+      access to a specific Resource/Kind pair using the RELOAD
+      certificate-based access control policies.
+
+   Authorized Peer:  The term "Authorized Peer" in this document defines
+      a RELOAD peer that was granted write access to a Shared Resource
+      by permission of the Resource Owner or another Authorized Peer.
+
+3.  Shared Resources in RELOAD
+
+   A RELOAD user that owns a certificate for writing at a specific
+   overlay location can maintain one or more RELOAD Kinds that are
+   designated for a non-exclusive write access shared with other RELOAD
+   users.  The mechanism to share those Resource/Kind pairs with a group
+   of users consists of two basic steps:
+
+   1.  Storage of the Resource/Kind pairs to be shared.
+
+   2.  Storage of an Access Control List (ACL) associated with those
+       Kinds.
+
+
+
+
+Knauf, et al.                Standards Track                    [Page 5]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+   ACLs are created by the Resource Owner and contain ACL items, each
+   delegating the permission of writing the shared Kind to a specific
+   user called the "Authorized Peer".  For each shared Kind data, its
+   Resource owner stores a root item that initiates an Access Control
+   List.  Trust delegation to the Authorized Peer can include the right
+   to further delegate the write permission, enabling a tree of trust
+   delegations with the Resource Owner as trust anchor at its root.
+
+   The Resource/Kind pair to be shared can be any RELOAD Kind that
+   complies to the following specifications:
+
+   Isolated Data Storage:  To prevent concurrent writing from race
+      conditions, each data item stored within a Shared Resource SHALL
+      be exclusively maintained by the RELOAD user who created it.
+      Hence, Usages that allow the storage of Shared Resources are
+      REQUIRED to use either the array or dictionary data model and
+      apply additional mechanisms for isolating data as described in
+      Section 3.1.
+
+   Access Control Policy:  To ensure write access to Shared Resource by
+      Authorized Peers, each Usage MUST use the USER-CHAIN-ACL access
+      policy as described in Section 6.6.
+
+   Resource Name Extension:  To enable Shared Resources to be stored
+      using a variable resource name, this document defines an optional
+      ResourceNameExtension structure.  It contains the Resource Name of
+      the Kind data to be stored and allows any receiver of a shared
+      data to validate whether the Resource Name hashes to the Resource-
+      ID.  The ResourceNameExtension is made optional by configuration.
+      The ResourceNameExtension field is only present in the Kind data
+      structure when configured in the corresponding kind-block of the
+      overlay configuration document (for more details, see
+      Section 5.3).  If the configuration allows variable resource
+      names, a Kind using the USER-CHAIN-ACL policy MUST use the
+      ResourceNameExtension as the initial field within the Kind data
+      structure definition.  Otherwise, the Kind data structure does not
+      contain the ResourceNameExtension structure.
+
+3.1.  Mechanisms for Isolating Stored Data
+
+   This section defines mechanisms to avoid race conditions while
+   concurrently writing an array or dictionary of a Shared Resource.
+
+   If a dictionary is used in the Shared Resource, the dictionary key
+   MUST be the Node-ID of the certificate that will be used to sign the
+   stored data.  Thus, data access is bound to the unique ID holder, and
+   write concurrency does not occur.
+
+
+
+
+Knauf, et al.                Standards Track                    [Page 6]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+   If the data model of the Shared Resource is an array, each Authorized
+   Peer that chooses to write data SHALL obtain its exclusive range of
+   the array indices.  The following algorithm will generate an array
+   indexing scheme that avoids collisions:
+
+   1.  Obtain the Node-ID of the certificate that will be used to sign
+       the stored data.
+
+   2.  Take the least significant 24 bits of that Node-ID to prefix the
+       array index.
+
+   3.  Append an 8-bit individual index value to those 24 bits of the
+       Node-ID.
+
+   The resulting 32-bit long integer MUST be used as the index for
+   storing an array entry in a Shared Resource.  The 24 bits of the
+   Node-ID serve as a collision-resistant identifier.  The 8-bit
+   individual index remains under the control of a single Peer and can
+   be incremented individually for further array entries.  In total,
+   each Peer can generate 256 distinct entries for application-specific
+   use.
+
+   The mechanism to create the array index inherits collision-resistance
+   from the overlay hash function in use (e.g., SHA-1).  It is designed
+   to work reliably for small sizes of groups as applicable to resource
+   sharing.  In the rare event of a collision, the Storing Peer will
+   refuse to (over-)write the requested array index and protect indexing
+   integrity as defined in Section 6.1.  A Peer could rejoin the overlay
+   with a different Node-ID in such a case.
+
+4.  Access Control List Definition
+
+4.1.  Overview
+
+   An Access Control List (ACL) is a (self-managed) Shared Resource that
+   contains a list of AccessControlListItem structures as defined in
+   Section 4.2.  Each entry delegates write access for a specific Kind
+   data to a single RELOAD user.  An ACL enables the RELOAD user who is
+   authorized to write a specific Resource-ID to delegate his exclusive
+   write access to a specific Kind to further users of the same RELOAD
+   overlay.  Therefore, each Access Control List data structure carries
+   the information about who obtains write access, the Kind-ID of the
+   Resource to be shared, and whether delegation includes write access
+   to the ACL itself.  The latter condition grants the right to delegate
+   write access further for the Authorized Peer.  Access Control Lists
+   are stored at the same overlay location as the Shared Resource and
+   use the RELOAD array data model.  They are initially created by the
+   Resource Owner.
+
+
+
+Knauf, et al.                Standards Track                    [Page 7]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+   Figure 1 shows an example of an Access Control List.  We omit the
+   res_name_ext field to simplify illustration.  The array entry at
+   index 0x123abc01 displays the initial creation of an ACL for a Shared
+   Resource of Kind-ID 1234 at the same Resource-ID.  It represents the
+   root item of the trust delegation tree for this shared RELOAD Kind.
+   The root entry MUST contain the username of the Resource owner in the
+   "to_user" field and can only be written by the owner of the public
+   key certificate associated with this Resource-ID.  The
+   allow_delegation (ad) flag for a root ACL item is set to 1 by
+   default.  The array index is generated by using the mechanism for
+   isolating stored data as described in Section 3.1.  Hence, the most
+   significant 24 bits of the array index (0x123abc) are the least
+   significant 24 bits of the Node-ID of the Resource Owner.
+
+   The array item at index 0x123abc02 represents the first trust
+   delegation to an Authorized Peer that is thus permitted to write to
+   the Shared Resource of Kind-ID 1234.  Additionally, the Authorized
+   peer Alice is also granted write access to the ACL as indicated by
+   the allow_delegation flag (ad) set to 1.  This configuration
+   authorizes Alice to store further trust delegations to the Shared
+   Resource, i.e., add items to the ACL.  On the contrary, index
+   0x456def01 illustrates trust delegation for Kind-ID 1234, in which
+   the Authorized Peer Bob is not allowed to grant access to further
+   peers (ad = 0).  Each Authorized Peer signs its ACL items by using
+   its own signer identity along with its own private key.  This allows
+   other peers to validate the origin of an ACL item and makes ownership
+   transparent.
+
+   To manage Shared Resource access of multiple Kinds at a single
+   location, the Resource Owner can create new ACL entries that refer to
+   another Kind-ID as shown in array entry index 0x123abc03.  Note that
+   overwriting existing items in an Access Control List with a change in
+   the Kind-ID revokes all trust delegations in the corresponding
+   subtree (see Section 6.2).  Authorized Peers are only enabled to
+   overwrite existing ACL item they own.  The Resource Owner is allowed
+   to overwrite any existing ACL item, but should be aware of its
+   consequences on the trust delegation chain.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Knauf, et al.                Standards Track                    [Page 8]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+         +------------------------------------------------------+
+         |                Access Control List                   |
+         +-----------+------------------------------+-----------+
+         |  #Index   |       Array Entries          | signed by |
+         +-----------+------------------------------+-----------+
+         | 123abc01  | to_user:Owner Kind:1234 ad:1 |   Owner   |
+         +-----------+------------------------------+-----------+
+         | 123abc02  | to_user:Alice Kind:1234 ad:1 |   Owner   |
+         +-----------+------------------------------+-----------+
+         | 123abc03  | to_user:Owner Kind:4321 ad:1 |   Owner   |
+         +-----------+------------------------------+-----------+
+         | 123abc04  | to_user:Carol Kind:4321 ad:0 |   Owner   |
+         +-----------+------------------------------+-----------+
+         |    ...    |           ...                |    ...    |
+         +-----------+------------------------------+-----------+
+         | 456def01  | to_user:Bob   Kind:1234 ad:0 |   Alice   |
+         +-----------+------------------------------+-----------+
+         |    ...    |           ...                |    ...    |
+         +-----------+------------------------------+-----------+
+
+     Figure 1: Simplified Example of an Access Control List, Including
+      Entries for Two Different Kind-IDs and Varying Delegation (AD)
+                              Configurations
+
+   Implementors of ShaRe should be aware that the trust delegation in an
+   Access Control List need not be loop free.  Self-contained circular
+   trust delegation from A to B and B to A are syntactically possible,
+   even though not very meaningful.
+
+4.2.  Data Structure
+
+   The Kind data structure for the Access Control List is defined as
+   follows:
+
+
+   struct {
+        /* res_name_ext is optional, see documentation */
+        ResourceNameExtension  res_name_ext;
+        opaque                 to_user<0..2^16-1>;
+        KindId                 kind;
+        Boolean                allow_delegation;
+   } AccessControlListItem;
+
+
+
+
+
+
+
+
+
+Knauf, et al.                Standards Track                    [Page 9]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+   The AccessControlListItem structure is composed of:
+
+   res_name_ext:  This optional field contains the Resource Name of a
+      ResourceNameExtension (see Section 5.2) to be used by a Shared
+      Resource with a variable resource name.  This name is used by the
+      storing peer for validating, whether a variable resources name
+      matches one of the predefined naming pattern from the
+      configuration document for this Kind.  The presence of this field
+      is bound to a variable resource name element in the corresponding
+      kind-block of the configuration document whose "enable" attribute
+      is set to true (see Section 5.3).  Otherwise, if the "enable"
+      attribute is false, the res_name_ext field SHALL NOT be present in
+      the Kind data structure.
+
+   to_user:  This field contains the username of the RELOAD peer that
+      obtains write permission to the Shared Resource.
+
+   kind:  This field contains the Kind-ID of the Shared Resource.
+
+   allow_delegation:  If true, this Boolean flag indicates that the
+      Authorized Peer in the 'to_user' field is allowed to add
+      additional entries to the ACL for the specified Kind-ID.
+
+5.  Extension for Variable Resource Names
+
+5.1.  Overview
+
+   In certain use cases, such as conferencing, it is desirable to
+   increase the flexibility of a peer in using Resource Names beyond
+   those defined by the username or Node-ID fields in its certificate.
+   For this purpose, this document presents the concept for variable
+   Resources Names that enables providers of RELOAD instances to define
+   relaxed naming schemes for overlay Resources.
+
+   Each RELOAD node uses a certificate to identify itself using its
+   username (or Node-ID) while storing data under a specific Resource-ID
+   (see Section 7.3 in [RFC6940]).  The specifications in this document
+   scheme adhere to this paradigm, but enable a RELOAD peer to store
+   values of Resource Names that are derived from the username in its
+   certificate.  This is done by using a Resource Name with a variable
+   substring that still matches the username in the certificate using a
+   pattern defined in the overlay configuration document.  Thus, despite
+   being variable, an allowable Resource Name remains tied to the
+   Owner's certificate.  A sample pattern might be formed as follows:
+
+   Example Pattern:
+   .*-conf-$USER@$DOMAIN
+
+
+
+
+Knauf, et al.                Standards Track                   [Page 10]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+   When defining the pattern, care must be taken to avoid conflicts
+   arising from two usernames of which one is a substring of the other.
+   In such cases, the holder of the shorter name could threaten to block
+   the resources of the longer-named peer by choosing the variable part
+   of a Resource Name to contain the entire longer username.  For
+   example, a "*$USER" pattern would allow user EVE to define a resource
+   with name "STEVE" and to block the resource name for user STEVE
+   through this.  This problem can easily be mitigated by delimiting the
+   variable part of the pattern from the username part by some fixed
+   string, that by convention is not part of a username (e.g., the
+   "-conf-" in the above Example).
+
+5.2.  Data Structure
+
+   This section defines the optional ResourceNameExtension structure for
+   every Kind that uses the USER-CHAIN-ACL access control policy.
+
+   enum { pattern(1), (255)} ResourceNameType;
+
+   struct {
+     ResourceNameType type;
+     uint16           length;
+
+     select(type) {
+         case pattern:
+           opaque     resource_name<0..2^16-1>;
+
+         /* Types can be extended */
+     };
+   } ResourceNameExtension;
+
+   The content of the ResourceNameExtension consists of:
+
+   length:  This field contains the length of the remaining data
+      structure.  It is only used to allow for further extensions to
+      this data structure.
+
+   The content of the rest of the data structure depends of the
+   ResourceNameType.  Currently, the only defined type is "pattern".
+
+   If the type is "pattern", then the following data structure contains
+   an opaque <0..2^16-1> field containing the Resource Name of the Kind
+   being stored.  The type "pattern" further indicates that the Resource
+   Name MUST match to one of the variable resource name patterns defined
+   for this Kind in the configuration document.
+
+   The ResourceNameType enum and the ResourceNameExtension structure can
+   be extended by further Usages to define other naming schemes.
+
+
+
+Knauf, et al.                Standards Track                   [Page 11]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+5.3.  Overlay Configuration Document Extension
+
+   This section extends the overlay configuration document by defining
+   new elements for patterns relating resource names to usernames.  It
+   is noteworthy that additional constraints on the syntax and semantic
+   of names can apply according to specific Usages.  For example,
+   Address of Record (AOR) syntax restrictions apply when using P2PSIP
+   [RFC7904], while a more general naming is feasible in plain RELOAD.
+
+   The <variable-resource-names> element serves as a container for one
+   or multiple <pattern> sub-elements.  It is an additional parameter
+   within the kind-block and has a boolean "enable" attribute that
+   indicates, if true, that the overlay provider allows variable
+   resource names for this Kind.  The default value of the "enable"
+   attribute is "false".  In the absence of a <variable-resource-names>
+   element for a Kind using the USER-CHAIN-ACL access policy (see
+   Section 6.6), implementors MUST assume this default value.
+
+   A <pattern> element MUST be present if the "enabled" attribute of its
+   parent element is set to true.  Each <pattern> element defines a
+   pattern for constructing extended resource names for a single Kind.
+   It is of type xsd:string and interpreted as a regular expression
+   according to "POSIX Extended Regular Expression" (see the
+   specifications in [IEEE-Posix]).  In this regular expression, $USER
+   and $DOMAIN are used as variables for the corresponding parts of the
+   string in the certificate username field (with $USER preceding and
+   $DOMAIN succeeding the '@').  Both variables MUST be present in any
+   given pattern definition.  Furthermore, variable parts in <pattern>
+   elements defined in the overlay configuration document MUST remain
+   syntactically separated from the username part (e.g., by a dedicated
+   delimiter) to prevent collisions with other names of other users.  If
+   no pattern is defined for a Kind, if the "enable" attribute is false,
+   or if the regular expression does not meet the requirements specified
+   in this section, the allowable Resource Names are restricted to the
+   username of the signer for Shared Resource.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Knauf, et al.                Standards Track                   [Page 12]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+   The RELAX NG Grammar for the Variable Resource Names Extension reads:
+
+   # VARIABLE RESOURCE URN SUB-NAMESPACE
+
+   namespace share = "urn:ietf:params:xml:ns:p2p:config-base:share"
+
+   # VARIABLE RESOURCE NAMES ELEMENT
+
+   kind-parameter &= element share:variable-resource-names {
+
+       attribute enable { xsd:boolean },
+
+       # PATTERN ELEMENT
+
+       element share:pattern { xsd:string }*
+   }?
+
+   Whitespace and case processing follows the rules of [OASIS.relax_ng]
+   and XML Schema Datatypes [W3C.REC-xmlschema-2-20041028].
+
+6.  Access Control to Shared Resources
+
+6.1.  Granting Write Access
+
+   Write access to a Kind that is intended to be shared with other
+   RELOAD users can be initiated solely by the Resource Owner.  A
+   Resource Owner can share RELOAD Kinds by using the following
+   procedure:
+
+   o  The Resource Owner stores an ACL root item at the Resource-ID of
+      the Shared Resource.  The root item contains the
+      ResourceNameExtension field (see Section 5.2), the username of the
+      Resource Owner and Kind-ID of the Shared Resource.  The
+      allow_delegation flag is set to 1.  The index of array data
+      structure MUST be generated as described in Section 3.1.
+
+   o  Further ACL items for this Kind-ID stored by the Resource Owner
+      MAY delegate write access to Authorized Peers.  These ACL items
+      contain the same resource name extension field, the username of
+      the Authorized Peer, and the Kind-ID of the Shared Resource.
+      Optionally, the Resource Owner sets the "ad" to 1 (the default
+      equals 0) to enable the Authorized Peer to further delegate write
+      access.  For each succeeding ACL item, the Resource Owner
+      increments its individual index value by one (see Section 3.1) so
+      that items can be stored in the numerical order of the array index
+      starting with the index of the root item.
+
+
+
+
+
+Knauf, et al.                Standards Track                   [Page 13]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+   An Authorized Peer with delegation allowance ("ad"=1) can extend the
+   access to an existing Shared Resource as follows:
+
+   o  An Authorized Peer can store additional ACL items at the Resource-
+      ID of the Shared Resource.  These ACL items contain the resource
+      name extension field, the username of the newly Authorized Peer,
+      and the Kind-ID of the Shared Resource.  Optionally, the "ad" flag
+      is set to 1 for allowing the newly Authorized Peer to further
+      delegate write access.  The array index MUST be generated as
+      described in Section 3.1.  Each succeeding ACL item can be stored
+      in the numerical order of the array index.
+
+   A store request by an Authorized Peer that attempts to overwrite any
+   ACL item signed by another Peer is unauthorized and causes an
+   Error_Forbidden response from the Storing Peer.  Such access
+   conflicts could be caused by an array index collision.  However, the
+   probability of a collision of two or more identical array indices
+   will be negligibly low using the mechanism for isolating stored data
+   (see Section 3.1).
+
+6.2.  Revoking Write Access
+
+   Write permissions are revoked by storing a nonexistent value (see
+   [RFC6940], Section 7.2.1) at the corresponding item of the Access
+   Control List.  Revoking a permission automatically invalidates all
+   delegations performed by that user including all subsequent
+   delegations.  This allows the invalidation of entire subtrees of the
+   delegations tree with only a single operation.  Overwriting the root
+   item with a nonexistent value of an Access List invalidates the
+   entire delegations tree.
+
+   An existing ACL item MUST only be overwritten by the user who
+   initially stored the corresponding entry, or by the Resource Owner
+   that is allowed to overwrite all ACL items for revoking write access.
+
+   To protect the privacy of the users, the Resource Owner SHOULD
+   overwrite all subtrees that have been invalidated.
+
+6.3.  Validating Write Access through an ACL
+
+   Access Control Lists are used to transparently validate authorization
+   of peers for writing a data value at a Shared Resource.  Thereby, it
+   is assumed that the validating peer is in possession of the complete
+   and most recent ACL for a specific Resource/Kind pair.  The
+   corresponding procedure consists of recursively traversing the trust
+   delegation tree with strings compared as binary objects.  It proceeds
+   as follows:
+
+
+
+
+Knauf, et al.                Standards Track                   [Page 14]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+   1.  Obtain the username of the certificate used for signing the data
+       stored at the Shared Resource.  This is the user who requested
+       the write operation.
+
+   2.  Validate that an item of the corresponding ACL (i.e., for this
+       Resource/Kind pair) contains a "to_user" field whose value equals
+       the username obtained in step 1.  If the Shared Resource under
+       examination is an Access Control List Kind, further validate if
+       the "ad" flag is set to 1.
+
+   3.  Select the username of the certificate that was used to sign the
+       ACL item obtained in the previous step.
+
+   4.  Validate that an item of the corresponding ACL contains a
+       "to_user" field whose value equals the username obtained in step
+       3.  Additionally, validate that the "ad" flag is set to 1.
+
+   5.  Repeat steps 3 and 4 until the "to_user" value is equal to the
+       username of the signer of the ACL in the selected item.  This
+       final ACL item is expected to be the root item of this ACL, which
+       MUST be further validated by verifying that the root item was
+       signed by the owner of the ACL Resource.
+
+   The trust delegation chain is valid if and only if all verification
+   steps succeed.  In this case, the creator of the data value of the
+   Shared Resource is an Authorized Peer.
+
+   Note that the ACL validation procedure can be omitted whenever the
+   creator of data at a Shared Resource is the Resource Owner itself.
+   The latter can be verified by its public key certificate as defined
+   in Section 6.6.
+
+6.4.  Operations of Storing Peers
+
+   Storing peers, at which Shared Resource and ACL are physically
+   stored, are responsible for controlling storage attempts to a Shared
+   Resource and its corresponding Access Control List.  To assert the
+   USER-CHAIN-ACL access policy (see Section 6.6), a storing peer MUST
+   perform the access validation procedure described in Section 6.3 on
+   any incoming store request using the most recent Access Control List
+   for every Kind that uses the USER-CHAIN-ACL policy.  It SHALL further
+   ensure that only the Resource Owner stores new ACL root items for
+   Shared Resources.
+
+
+
+
+
+
+
+
+Knauf, et al.                Standards Track                   [Page 15]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+6.5.  Operations of Accessing Peers
+
+   Accessing peers, i.e., peers that fetch a Shared Resource, can
+   validate that the originator of a Shared Resource was authorized to
+   store data at this Resource-ID by processing the corresponding ACL.
+   To enable an accessing peer to perform the access validation
+   procedure described in Section 6.3, it first needs to obtain the most
+   recent Access Control List in the following way:
+
+   1.  Send a Stat request to the Resource-ID of the Shared Resource to
+       obtain all array indexes of stored ACL Kinds (as per [RFC6940],
+       Section 7.4.3.).
+
+   2.  Fetch all indexes of existing ACL items at this Resource-ID by
+       using the array ranges retrieved in the Stat request answer.
+
+   Peers can cache previously fetched Access Control Lists up to the
+   maximum lifetime of an individual item.  Since stored values could
+   have been modified or invalidated prior to their expiration, an
+   accessing peer SHOULD use a Stat request to check for updates prior
+   to using the data cache.
+
+6.6.  USER-CHAIN-ACL Access Policy
+
+   This document specifies an additional access control policy to the
+   RELOAD base document [RFC6940].  The USER-CHAIN-ACL policy allows
+   Authorized Peers to write a Shared Resource, even though they do not
+   own the corresponding certificate.  Additionally, the USER-CHAIN-ACL
+   allows the storage of Kinds with a variable resource name that are
+   following one of the specified naming patterns.  Hence, on an inbound
+   store request on a Kind that uses the USER-CHAIN-ACL access policy,
+   the following rules MUST be applied:
+
+   In the USER-CHAIN-ACL policy, a given value MUST NOT be written or
+   overwritten, if neither one of USER-MATCH or USER-NODE-MATCH
+   (mandatory if the data model is dictionary) access policies of the
+   base document [RFC6940] applies.
+
+   Additionally, the store request MUST be denied if the signer's
+   certificate does not contain a username that matches to the user and
+   domain portion in one of the variable resource name patterns (cf.
+   Section 5) specified in the configuration document or if the hashed
+   Resource Name does not match the Resource-ID.  The Resource Name of
+   the Kind to be stored MUST be taken from the mandatory
+   ResourceNameExtension field in the corresponding Kind data structure.
+
+
+
+
+
+
+Knauf, et al.                Standards Track                   [Page 16]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+   If the access rights cannot be verified according to the ACL
+   validation procedure described in Section 6.3, the store request MUST
+   also be denied.
+
+   Otherwise, the store request can be processed further.
+
+7.  ACCESS-CONTROL-LIST Kind Definition
+
+   This section defines the ACCESS-CONTROL-LIST Kind previously
+   described in this document.
+
+   Name:  ACCESS-CONTROL-LIST
+
+   Kind IDs:  The Resource Name for ACCESS-CONTROL-LIST Kind-ID is the
+      Resource Name of the Kind that will be shared by using the ACCESS-
+      CONTROL-LIST Kind.
+
+   Data Model:  The data model for the ACCESS-CONTROL-LIST Kind-ID is
+      array.  The array indexes are formed by using the mechanism for
+      isolated stored data as described in Section 3.1.
+
+   Access Control:  USER-CHAIN-ACL (see Section 6.6).
+
+8.  Security Considerations
+
+   In this section, we discuss security issues that are relevant to the
+   usage of Shared Resources in RELOAD [RFC6940].
+
+8.1.  Resource Exhaustion
+
+   Joining a RELOAD overlay inherently poses a certain resource load on
+   a peer, because it has to store and forward data for other peers.  In
+   common RELOAD semantics, each Resource-ID and thus position in the
+   overlay, may only be written by a limited set of peers -- often even
+   only a single peer, which limits this burden.  In the case of Shared
+   Resources, a single resource may be written by multiple peers who may
+   even write an arbitrary number of entries (e.g., delegations in the
+   ACL).  This leads to an enhanced use of resources at individual
+   overlay nodes.  The problem of resource exhaustion can easily be
+   mitigated for Usages based on the ShaRe-Usage by imposing
+   restrictions on size, i.e., <max-size> element for a certain Kind in
+   the configuration document.
+
+
+
+
+
+
+
+
+
+Knauf, et al.                Standards Track                   [Page 17]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+8.2.  Malicious or Misbehaving Storing Peer
+
+   The RELOAD overlay is designed to operate despite the presence of a
+   small set of misbehaving peers.  This is not different for Shared
+   Resources since a small set of malicious peers does not disrupt the
+   functionality of the overlay in general, but may have implications
+   for the peers needing to store or access information at the specific
+   locations in the ID space controlled by a malicious peer.  A storing
+   peer could withhold stored data, which results in a denial of service
+   to the group using the specific resource.  But it could not return
+   forged data, since the validity of any stored data can be
+   independently verified using the attached signatures.
+
+8.3.  Trust Delegation to a Malicious or Misbehaving Peer
+
+   A Resource Owner that erroneously delegated write access to a Shared
+   Resource for a misbehaving peer enables this malicious member of the
+   overlay to interfere with the corresponding group application in
+   several unwanted ways.  Examples of destructive interferences range
+   from exhausting shared storage to dedicated application-specific
+   misuse.  Additionally, a bogus peer that was granted delegation
+   rights may authorize further malicious collaborators to writing the
+   Shared Resource.
+
+   It is the obligation of the Resource Owner to bind trust delegation
+   to apparent trustworthiness.  Additional measures to monitor proper
+   behavior may be applied.  In any case, the Resource Owner will be
+   able to revoke the trust delegation of an entire tree in a single
+   overwrite operation.  It further holds the right to overwrite any
+   malicious contributions to the shared resource under misuse.
+
+8.4.  Privacy Issues
+
+   All data stored in the Shared Resource is readable by any node in the
+   overlay; thus, applications requiring privacy need to encrypt the
+   data.  The ACL needs to be stored unencrypted; thus, the list members
+   of a group using a Shared Resource will always be publicly visible.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Knauf, et al.                Standards Track                   [Page 18]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+9.  IANA Considerations
+
+9.1.  Access Control Policy
+
+   IANA has registered the following entry in the "RELOAD Access Control
+   Policies" registry (cf. [RFC6940]) to represent the USER-CHAIN-ACL
+   Access Control Policy, as described in Section 6.6.
+
+                     +-------------------+----------+
+                     | Access Policy     |      RFC |
+                     +-------------------+----------+
+                     | USER-CHAIN-ACL    | RFC 8076 |
+                     +-------------------+----------+
+
+9.2.  Data Kind-ID
+
+   IANA has registered the following code point in the "RELOAD Data
+   Kind-ID" registry (cf. [RFC6940]) to represent the ShaRe ACCESS-
+   CONTROL-LIST kind, as described in Section 7.
+
+             +----------------------+------------+----------+
+             | Kind                 |    Kind-ID |      RFC |
+             +----------------------+------------+----------+
+             | ACCESS-CONTROL-LIST  |        0x4 | RFC 8076 |
+             +----------------------+------------+----------+
+
+9.3.  XML Namespace Registration
+
+   This document registers the following URI for the config XML
+   namespace in the IETF XML registry defined in [RFC3688].
+
+   URI:  urn:ietf:params:xml:ns:p2p:config-base:share
+
+   Registrant Contact:  The IESG
+
+   XML:  N/A, the requested URI is an XML namespace
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Knauf, et al.                Standards Track                   [Page 19]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+10.  References
+
+10.1.  Normative References
+
+   [IEEE-Posix]
+              "IEEE Standard for Information Technology - Portable
+              Operating System Interface (POSIX) - Part 2: Shell and
+              Utilities (Vol.  1)", IEEE Std 1003.2-1992, ISBN
+              1-55937-255-9, DOI 10.1109/IEEESTD.1993.6880751, January
+              1993, <http://ieeexplore.ieee.org/document/6880751/>.
+
+   [OASIS.relax_ng]
+              Clark, J. and M. Murata, "RELAX NG Specification",
+              December 2001.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              DOI 10.17487/RFC3688, January 2004,
+              <http://www.rfc-editor.org/info/rfc3688>.
+
+   [RFC6940]  Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,
+              and H. Schulzrinne, "REsource LOcation And Discovery
+              (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940,
+              January 2014, <http://www.rfc-editor.org/info/rfc6940>.
+
+   [W3C.REC-xmlschema-2-20041028]
+              Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
+              Second Edition", World Wide Web Consortium Recommendation
+              REC-xmlschema-2-20041028, October 2004,
+              <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
+
+10.2.  Informative References
+
+   [RFC7890]  Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
+              Dawkins, "Concepts and Terminology for Peer-to-Peer SIP
+              (P2PSIP)", RFC 7890, DOI 10.17487/RFC7890, June 2016,
+              <http://www.rfc-editor.org/info/rfc7890>.
+
+   [RFC7904]  Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.,
+              Schulzrinne, H., and T. Schmidt, Ed., "A SIP Usage for
+              REsource LOcation And Discovery (RELOAD)", RFC 7904,
+              DOI 10.17487/RFC7904, October 2016,
+              <http://www.rfc-editor.org/info/rfc7904>.
+
+
+
+
+Knauf, et al.                Standards Track                   [Page 20]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+Acknowledgments
+
+   This work was stimulated by fruitful discussions in the P2PSIP
+   working group and the SAM research group.  We would like to thank all
+   active members for their constructive thoughts and feedback.  In
+   particular, the authors would like to thank (in alphabetical order)
+   Emmanuel Baccelli, Ben Campbell, Alissa Cooper, Lothar Grimm, Russ
+   Housley, Cullen Jennings, Matt Miller, Peter Musgrave, Joerg Ott,
+   Marc Petit-Huguenin, Peter Pogrzeba, and Jan Seedorf.  This work was
+   partly funded by the German Federal Ministry of Education and
+   Research, projects HAMcast, Mindstone, and SAFEST.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Knauf, et al.                Standards Track                   [Page 21]
+
+RFC 8076                          ShaRe                       March 2017
+
+
+Authors' Addresses
+
+   Alexander Knauf
+   HAW Hamburg
+   Berliner Tor 7
+   Hamburg  D-20099
+   Germany
+
+   Phone: +4940428758067
+   Email: alexanderknauf@gmail.com
+
+
+   Thomas C. Schmidt
+   HAW Hamburg
+   Berliner Tor 7
+   Hamburg  D-20099
+   Germany
+
+   Email: t.schmidt@haw-hamburg.de
+   URI:   http://inet.haw-hamburg.de/members/schmidt
+
+
+   Gabriel Hege
+   daviko GmbH
+   Schillerstr. 107
+   Berlin  D-10625
+   Germany
+
+   Phone: +493043004344
+   Email: hege@daviko.com
+
+
+   Matthias Waehlisch
+   link-lab & FU Berlin
+   Hoenower Str. 35
+   Berlin  D-10318
+   Germany
+
+   Email: mw@link-lab.net
+   URI:   http://www.inf.fu-berlin.de/~waehl
+
+
+
+
+
+
+
+
+
+
+
+Knauf, et al.                Standards Track                   [Page 22]
+