P2PSIP Working Group                                            A. Knauf
Internet-Draft                                                   G. Hege
Intended status: Standards Track                            T C. Schmidt
Expires: January 12, 2012                                    HAW Hamburg
                                                            M. Waehlisch
                                                    link-lab & FU Berlin
                                                           July 11, 2011


             A Usage for Shared Resources in RELOAD (ShaRe)
                      draft-knauf-p2psip-share-01

Abstract

   This document defines a 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 which is useful whenever peer-independent rendezvous
   processes are required.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 12, 2012.

Copyright Notice

   Copyright (c) 2011 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



Knauf, et al.           Expires January 12, 2012                [Page 1]


Internet-Draft                    ShaRe                        July 2011


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   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 . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Extension for Variable Resource Names  . . . . . . . . . . . . 11
     5.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Overlay Configuration Document Extension . . . . . . . . . 11
   6.  Access Control to Shared Resources . . . . . . . . . . . . . . 13
     6.1.  Granting Write Access  . . . . . . . . . . . . . . . . . . 13
     6.2.  Revoking Write Access  . . . . . . . . . . . . . . . . . . 13
     6.3.  Storage and Validation . . . . . . . . . . . . . . . . . . 14
       6.3.1.  Operations of the Storing Peer . . . . . . . . . . . . 14
       6.3.2.  Operations of the Accessing Peer . . . . . . . . . . . 15
     6.4.  USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
     7.1.  Resource Exhaustion  . . . . . . . . . . . . . . . . . . . 17
     7.2.  Malicious or Misbehaving Storing Peer  . . . . . . . . . . 17
     7.3.  Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 17
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     10.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22











Knauf, et al.           Expires January 12, 2012                [Page 2]


Internet-Draft                    ShaRe                        July 2011


1.  Introduction

   This document defines a RELOAD Usage for managing shared write access
   to RELOAD Resources and a mechanism to store Resources with a
   variable name.  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 (c.f.
   [I-D.knauf-p2psip-disco]).  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.  It 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 extends 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 must contain the username
   of the Resource creator.













Knauf, et al.           Expires January 12, 2012                [Page 3]


Internet-Draft                    ShaRe                        July 2011


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 [I-D.ietf-p2psip-base]and the peer-to-peer SIP concepts draft
   [I-D.ietf-p2psip-concepts].  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.
















Knauf, et al.           Expires January 12, 2012                [Page 4]


Internet-Draft                    ShaRe                        July 2011


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: Storage of the Resource/Kind
   pair to be shared and storage of an Access Control List (ACL)
   associated with those Kinds.  ACLs are initiated by the Resource
   Owner and contain ACL items, each delegating the permission of
   writing the shared Kind to a specific user called Authorized Peer.
   This trust delegation to the Authorized Peer can include the right to
   further delegate the write permission.  For each shared Kind data,
   the Resource owner stores a root item that starts an Access Control
   List.  The result is a tree of trust delegations with the Resource
   Owner as trust anchor.

   The Resource/Kind pair to be shared can be any RELOAD Kind that
   complies to the following specifications:

   Isolated Data Storage:  To ensure that concurrent writing does not
      cause race conditions, each data item stored within a Shared
      Resource needs to be exclusively maintained by the RELOAD user who
      created it.  Hence, Usages that allow the storage of Shared
      Resources MUST use either array or dictionary data model and
      require the 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 (see Section 6.4).

   Resource_name field:  Any Kind using the USER-CHAIN-MATCH policy MUST
      define an opaque <0..2^16-1> initial field within the Kind data
      structure definition.  It contains the Resource Name of the Kind
      data to be stored.  The Resource_name field allows any receicer of
      a shared data to validate if the Resource Name hashes to the
      Resource-ID of Shared Resource.

   User_name field:  Any a Kind using the USER-CHAIN-ACL policy MUST
      define an opaque <0..2^16-1> as second field within the Kind data
      structure definition.  It contains the username from the
      certificate of the signer of the data to be stored.  The User_name
      field allows any receiver of the data to request the public key
      certificate of the originator of the stored data and to verify his
      provenance and integrity.





Knauf, et al.           Expires January 12, 2012                [Page 5]


Internet-Draft                    ShaRe                        July 2011


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.

   If the data model of the Shared Resource is an array, the following
   algorithm will generate an array index 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

   3.  Concatenate an 8 bit long short individual index value to those
       24 bit of the Node-ID

   The resulting 32 bits long integer MUST be used as the index for
   storing an array entry in a Shared Resource.  The 8 bit individual
   index can be incremented by one for each further array entry stored
   and allows for 256 distinct entries per Peer.

   The mechanism to create the array index is related to the pseudo-
   random algorithm to generate an SSRC identifier in RTP, see Section
   8.1 in [RFC3550] for calculating a collision probability.























Knauf, et al.           Expires January 12, 2012                [Page 6]


Internet-Draft                    ShaRe                        July 2011


4.  Access Control List Definition

4.1.  Overview

   In this document, an Access Control List (ACL) contains a list of
   AccessControlListData structures defined in Section 4.2.  Each entry
   delegates write access for a specific Kind data to a single RELOAD
   user.  The information is stored at the same overlay location as the
   Shared Resource.  An ACL allows the RELOAD user who is authorized to
   write a specific Resource-ID to delegate his exclusive write access
   for the specified Kinds to further users of a RELOAD instance.  Each
   Access Control List data structure therefore carries the information
   about who delegates write access to whom, 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 an Authorized Peer.  Access Control Lists are
   stored within a RELOAD array data model.  They are initially created
   by the Resource Owner.

   Figure 1 shows an example of an Access Control List.  We omit the
   resource_name field to simplify illustration.  The array entry at
   index 0x123abc001 displays the initial entry of an ACL about 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 mapping from Resource owner to
   Resource owner and MUST only be written by the owner of the public
   key certificate associated with this Resource-ID.  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 24bits of the
   Node-ID of the Resource Owner.

   The array item at index 0x123abc002 represents the first trust
   delegation to an Authorized Peer, which is thus permitted write
   access to the Shared Resource of Kind-ID 1234.  Additionally, the
   Authorized peer Alice is also granted (limited) 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.  In contrast to this,
   index 0x456def001 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
   with its own private key.

   In order to maintain Shared Resource access for 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 0x123abc003.
   Note, that overwriting existing items in an Access Control List that



Knauf, et al.           Expires January 12, 2012                [Page 7]


Internet-Draft                    ShaRe                        July 2011


   reference a different Kind-ID revokes all trust delegations in the
   tree (see Section 6.2).  Hence, Authorized Peers are not enabled to
   overwrite any existing ACL item .  The Resource Owner is allowed to
   overwrite existing ACL items, but should be aware of its
   consequences.

     +---------------------------------------------------------------+
     |                      Access Control List                      |
     +-----------+---------------------------------------+-----------+
     |  #Index   |             Array Entries             | signed by |
     +-----------+---------------------------------------+-----------+
     | 123abc001 | user:Owner -> to:Owner Kind:1234 ad:1 |   Owner   |
     +-----------+---------------------------------------+-----------+
     | 123abc002 | user:Owner -> to:Alice Kind:1234 ad:1 |   Owner   |
     +-----------+---------------------------------------+-----------+
     | 123abc003 | user:Owner -> to:Owner Kind:4321 ad:1 |   Owner   |
     +-----------+---------------------------------------+-----------+
     | 123abc004 | user:Owner -> to:Carol Kind:4321 ad:0 |   Owner   |
     +-----------+---------------------------------------+-----------+
     |    ...    |                  ...                  |    ...    |
     +-----------+---------------------------------------+-----------+
     | 456def001 | user:Alice -> to:Bob   Kind:1234 ad:0 |   Alice   |
     +-----------+---------------------------------------+-----------+
     |    ...    |                  ...                  |    ...    |
     +-----------+---------------------------------------+-----------+

    Figure 1: Simplified example of an Access Control including entries
   for two different Kind-IDs and varying delegation (ad) configurations

   Implementations 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 possible, even
   though not very meaningful.

4.2.  Data Structure

   The Kind data structure for the Access Control List is defined as
   follows:













Knauf, et al.           Expires January 12, 2012                [Page 8]


Internet-Draft                    ShaRe                        July 2011


   struct {
     opaque resource_name<0..2^16-1>;
     opaque user_name<0..2^16-1>;
     opaque to_user<0..2^16-1>;
     KindId kind;
     Boolean allow_delegation;
   } AccessControlListData;

   struct {
     uint16 length;
     AccessControlListData data;
   } AccessControlListItem;

   The AccessControlListItem structure is composed of:

   length:  This field contains the length of the Access Control List
      data structure

   data:  This field contains the data of an ACL item

   The content of the AccessControlListData structure is defined as
   follows:

   resource_name:  This opaque string represents the Resource Name of
      the Shared Resource as an opaque string.  It is used by the
      storing peer to validate whether a variable Resources Name matches
      the corresponding pattern defined in the configuration document.

   user_name:  This field contains the username of that RELOAD peer the
      grants write permission to the Shared Resource.  The username is
      stored as an opaque string and contains the username value from
      the certificate that is associated with the private key that
      signed this Access Control List item.

   to_user:  This field contains the username of the RELOAD peer that
      obtains writing 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 into the ACL for the specified Kind-ID.

   The ACCESS-CONTROL-LIST kind is defined as follows:







Knauf, et al.           Expires January 12, 2012                [Page 9]


Internet-Draft                    ShaRe                        July 2011


   Name:  ACCESS-CONTROL-LIST

   Data model:  The Data model for the ACCESS-CONTROL-LIST data is
      array.

   Access Control:  USER-CHAIN-ACL access policy (see Section 6.4).













































Knauf, et al.           Expires January 12, 2012               [Page 10]


Internet-Draft                    ShaRe                        July 2011


5.  Extension for Variable Resource Names

5.1.  Overview

   In certain use cases such as conferencing (c.f.
   [I-D.knauf-p2psip-disco]) it is desirable to extend the set of
   Resource Names and thus Resource-IDs a peer is allowed to write
   beyond those defined through the username or Node-ID fields in its
   certificate.  Therefore, this document presents the concept for
   variable Resources Names that enables providers of RELOAD instances
   to define a relaxed naming scheme for overlay Resources.

   Each RELOAD node uses a certificate to identify itself using its user
   name (or Node-ID) while storing data under a specific Resource-ID.
   The specifications in this document scheme follows this paradigm by
   allowing to store values whose Resource Names are derived from the
   username in the certificate of a RELOAD peer.  This is done by using
   a Resource Name which contains a variable substring but matches the
   username in the certificate using a pattern defined in the overlay
   configuration document.  Thus despite being variable an allowed
   Resource Name is closely related to the Owner's certificate.  A
   sample pattern might be formed as the following:

   Example Pattern:
   .*-conf-$USER@$DOMAIN

   When defining the pattern care must be taken that no conflict arises
   for two usernames of witch one is a substring of the other.  In this
   case the peer with the name which is the substring could choose the
   variable part of the Resource Name so that the resulting string
   contains the whole other username and thus he could write the other
   user's resources.  This can easily be prevented by delimiting the
   variable part of the pattern from the username part by some fixed
   string, that is usually not part of a username (e.g. the "-conf-" in
   the above Example).

5.2.  Overlay Configuration Document Extension

   This document extends the overlay configuration document by defining
   new elements for patterns relating resource names to user names.

   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.

   Each <pattern> element defines the pattern to be used for a single
   Kind.  It is of type xsd:string, which is interpreted as a regular
   expression.  In the regular expression $USER and $DOMAIN are used as



Knauf, et al.           Expires January 12, 2012               [Page 11]


Internet-Draft                    ShaRe                        July 2011


   variables for the corresponding parts of the string in the
   certificate username field ($USER before and $DOMAIN after the '@').
   Both variables MUST be present in any given pattern.

   A <pattern> element MUST be present for every Kind using the USER-
   CHAIN-MATCH access policy Section 6.4.

   The Relax NG Grammar for the Variable Resource Names Extension is:

   <!-- 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 {

       <!-- PATTERN ELEMENT -->

       element pattern { xsd:string }*
   }?






























Knauf, et al.           Expires January 12, 2012               [Page 12]


Internet-Draft                    ShaRe                        July 2011


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 solely be issued 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 same Resource-ID
      as the Shared Resource.  The root item contains the Resource Name
      and Kind-ID of the Shared Resource in the "resource_name" field
      and "Kind-ID" fields.  It further contains the username of the
      Resource Owner in the "user_name" and "to_user" field.  The "ad"
      flag SHOULD be set to 1.  The array index of MUST be generated as
      described in Section 3.1

   o  Further ACL items stored by the Resource Owner will delegate write
      access to the Shared Resource.  These ACL items contain the same
      Resource Name, Kind-ID and "user_name" values as the root item.
      Each "to_user" field is set to the username of an Authorized Peer.
      Optionally, the Resource Owner sets the "ad" to 1 (we define 0 as
      default).  Each succeeding ACL item created by the Resource Owner
      MAY be stored in the numerical order of the array index starting
      with the index of the root item plus one.

   An Authorized Peer (with "ad"=1) can further share an exiting Shared
   Resource as follows:

   o  An Authorized Peer stores one or more ACL items at the Resource-ID
      of the Shared Resource.  These ACL items contain the shared
      Resource Name and Kind-Id in the "resource_name" field and
      "Kind-ID" fields.  The "user_name" value is set to the username of
      the Authorized Peer and the "to_user" value is set to username of
      the added Authorized Peer.  Optionally, the "ad" flag could be set
      to 1.  The array index of MUST be generated as described in
      Section 3.1.  Each succeeding ACL item MAY be stored in the
      numerical order of the array index.

6.2.  Revoking Write Access

   Write permissions MAY be revoked by soring a non-existent value
   [I-D.ietf-p2psip-base] to the corresponding item in the Access
   Control List.  A revoked permission automatically invalidates all
   delegations performed by that user and also all subsequent
   delegations.  This allows to invalidate entire subtrees of the
   delegations tree with only a single operation.  Overwriting the root
   item with a non-existent value of an Access List invalidates the
   entire delegations tree.



Knauf, et al.           Expires January 12, 2012               [Page 13]


Internet-Draft                    ShaRe                        July 2011


   An ACL item MUST only be written by the user who initially stored the
   corresponding entry.  The only exception is by the Resource Owner
   that is allowed to overwrite every single ACL item for revoking write
   access.

6.3.  Storage and Validation

6.3.1.  Operations of the Storing Peer

   The storing peer (the peer at which Shared Resource and Access List
   are physically stored) is responsible to control storing attempts on
   a Shared Resource and the corresponding Access Control List.  To
   assert the USER-CHAIN-ACL (see Section 6.4) access policy a storing
   peer need to implement several operations to validate a store attempt
   on a Shared Resource.  The following ACL validation mechanism has to
   be performed on an incoming store request to a Shared Resource by an
   Authorized Peer:

   1.  The storing peer sends a Stat request to Resource-ID of the
       Shared Resource to obtain all array indexes of stored ACL Kinds.

   2.  Using the retrieved meta information, the storing peer fetches
       for all ACL Kinds at this Resource-ID.  Since the ACL is stored
       at the storing peer, both operations are local lookups.

   3.  The storing peer then validates if any of the retrieved ACL items
       contains a user_name field whose value is equal to the username
       in the certificate of the Authorized Peer and, if the Kind value
       is equal the Kind-ID of the Shared Resource.

   4.  If the requested Shared Resource is an Access Control List Kind,
       the storing peer MUST further validate if the "ad" flag is set to
       1.

   5.  If true, the ACL validation procedure returns true.

   A storing peer MAY validate the entire ACL to a Shared Resource on an
   inbound store request.  Beginning at the ACL item from the above ACL
   validation procedure, the storing peer validates if any ACL item with
   the same Kind-ID has a "user_name" value equal to the "to_user" value
   of recently validated ACL item.  If true, the validation continues
   with the next ACL item with any other ACL item with the same Kind-ID.
   This procedure continues until an ACL item is found with "user_name"
   is equal "to_user".  Then, if this "user_name" value hashes to the
   Resource-ID or it matches the variable resource name pattern and the
   corresponding "resource_name" value hashes to the Resource-ID, the
   ACL root validation returns true.




Knauf, et al.           Expires January 12, 2012               [Page 14]


Internet-Draft                    ShaRe                        July 2011


   If a store request by an Authorized Peer would overwrite and ACL item
   from another Authorized Peer (or Resource Owner), an Error_Forbidden
   response MUST be returned.  The probability of a collision of two or
   more identical array index will be negligibly low using the mechanism
   for isolated stored data (see Section 3.1)

6.3.2.  Operations of the Accessing Peer

   The accessing peer (a RELOAD peer that fetches a Shared Resource)
   SHOULD validate whether its originator was allowed to store at this
   Resource-ID by processing the corresponding ACL.  The accessing peer
   previously performs Stat request to retrieve the meta information at
   the Resource-ID of the Shared Resource.  Then, it fetches all
   existing ACL Kinds at this location.  After retrival, the accessing
   peer compares the "to_user" value of each ACL item with the mandatory
   "user_name" field of the Shared Resource for equality.  If the
   comparison fails, the accessing peer MUST ignore the data of the
   retrieved Shared Resource.

   Else, the accessing peer MAY validate whether the "user_name" value
   of recently observed ACL item exist in any other "to_user" field in
   the corresponding ACL.  If true, this procedure continues with the
   next ACL item with any other ACL item of the list.  The procedure
   contiues until both "user_name" and "to_user" values are equal, thus
   the root item to the ACL is found.  The Shared Resource and
   corresponding ACL are permitted at this location if the hash over the
   "user_name" value equals to the Resource-ID.  Or otherwise, if the
   "user_name" value matches the corresponding variable resource name
   pattern defined in the configuration document and the hash over the
   corresponding "resource_name" value matches the Resource-ID

   The accessing peer can further verify provenance and integrity of the
   retrieved Shared Resource using the certificate corresponding to the
   mandatory user_name field of the Shared Resource entry.  The
   certificate can be retrieved by applying the Certificate Usage
   [I-D.ietf-p2psip-base] or other means (e.g., caching from a previous
   request).

   The accessing peer MAY cache previously fetched Access Control Lists
   to a maximum of the individual items' lifetimes.  Since stored values
   could have been changed or invalidated prior to their expiration an
   accessing peer uses a Stat request to check for updates before using
   the cached data.  If a change has been detected it fetches the latest
   Access Control List.







Knauf, et al.           Expires January 12, 2012               [Page 15]


Internet-Draft                    ShaRe                        July 2011


6.4.  USER-CHAIN-ACL Access Policy

   This document specifies an additional access control policy to the
   RELOAD base draft [I-D.ietf-p2psip-base].  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-MATCH allows the storage of Kinds with a variable resource name
   that are following the specified naming pattern.  Hence, on an
   inbound store request on a Kind that uses the USER-CHAIN-ACL access
   policy, the following rules MUST applied:

   In the USER-CHAIN-ACL policy, a given value MUST be written or
   overwritten if either one of USER-MATCH or USER-NODE-MATCH (mandatory
   if the data model is dictionary) access policies of the base document
   [I-D.ietf-p2psip-base] applies.

   Otherwise, the value MUST be written if the certificate of the signer
   contains a username that matches to the variable resource name
   pattern (c.f.  Section 5) specified in the configuration document
   and, additionally, the hashed Resource Name matches the Resource-ID.
   The Resource Name of the Kind been stored MUST be taken from the
   mandatory resource_name field in the corresponding Kind data
   structure.

   Otherwise, the value MUST be written if the ACL Validation procedure
   as described in Section 6.3.1 returns true.

























Knauf, et al.           Expires January 12, 2012               [Page 16]


Internet-Draft                    ShaRe                        July 2011


7.  Security Considerations

   In this section we discuss security issues that are relevant to the
   usage of shared resources in RELOAD.

7.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.

7.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.

7.3.  Privacy Issues

   All data stored in the Shared Resource is publicly readable, 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.           Expires January 12, 2012               [Page 17]


Internet-Draft                    ShaRe                        July 2011


8.  IANA Considerations

   TODO: register Kind-ID code point at the IANA
















































Knauf, et al.           Expires January 12, 2012               [Page 18]


Internet-Draft                    ShaRe                        July 2011


9.  Acknowledgments

   This work was stimulated by fruitful discussions in the P2PSIP
   working group and SAM research group.  We would like to thank all
   active members for constructive thoughts and feedback.  In
   particular, the authors would like to thank (in alphabetical order)
   Lothar Grimm, Cullen Jennings, Peter Musgrave, Joerg Ott, Marc Petit-
   Huguenin, Peter Pogrzeba, and Jan Seedorf.  This work was party
   funded by the German Federal Ministry of Education and Research,
   projects HAMcast and Mindstone.









































Knauf, et al.           Expires January 12, 2012               [Page 19]


Internet-Draft                    ShaRe                        July 2011


10.  References

10.1.  Normative References

   [I-D.ietf-p2psip-base]
              Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
              H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
              Base Protocol", draft-ietf-p2psip-base-16 (work in
              progress), July 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

   [I-D.ietf-p2psip-concepts]
              Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
              Dawkins, "Concepts and Terminology for Peer to Peer SIP",
              draft-ietf-p2psip-concepts-03 (work in progress),
              October 2010.

   [I-D.knauf-p2psip-disco]
              Knauf, A., Hege, G., Schmidt, T., and M. Waehlisch, "A
              RELOAD Usage for Distributed Conference Control (DisCo)",
              draft-knauf-p2psip-disco-02 (work in progress),
              March 2011.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.





















Knauf, et al.           Expires January 12, 2012               [Page 20]


Internet-Draft                    ShaRe                        July 2011


Appendix A.  Change Log

   The following changes have been made from version
   draft-knauf-p2psip-share-00:

   1.  Integrated the USER-PATTERN-MATCH access policy into USER-CHAIN-
       MATCH

   2.  Access Control List Kind uses USER-CHAIN-ACL exclusively

   3.  Resources to be shared use USER-CHAIN-ACL exclusively

   4.  More precise specification of mandatory User_name and
       Resource_name fields for Shared Resources

   5.  Added mechanism for isolating stored data to prevent race
       conditions while concurrent storing

   6.  XML Extension for variable resource names uses its own namespace

   7.  Many editorial improvements






























Knauf, et al.           Expires January 12, 2012               [Page 21]


Internet-Draft                    ShaRe                        July 2011


Authors' Addresses

   Alexander Knauf
   HAW Hamburg
   Berliner Tor 7
   Hamburg  D-20099
   Germany

   Phone: +4940428758067
   Email: alexander.knauf@haw-hamburg.de
   URI:   http://inet.cpt.haw-hamburg.de/members/knauf


   Gabriel Hege
   HAW Hamburg
   Berliner Tor 7
   Hamburg  D-20099
   Germany

   Phone: +4940428758067
   Email: hege@fhtw-berlin.de
   URI:   http://inet.cpt.haw-hamburg.de/members/hege


   Thomas C. Schmidt
   HAW Hamburg
   Berliner Tor 7
   Hamburg  D-20099
   Germany

   Email: schmidt@informatik.haw-hamburg.de
   URI:   http://inet.cpt.haw-hamburg.de/members/schmidt


   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.           Expires January 12, 2012               [Page 22]