One document matched: draft-knauf-p2psip-share-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-knauf-p2psip-share-01" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="ShaRe">A Usage for Shared Resources in RELOAD
(ShaRe)</title>
<author fullname="Alexander Knauf" initials="A." surname="Knauf">
<organization abbrev="HAW Hamburg">HAW Hamburg</organization>
<address>
<postal>
<street>Berliner Tor 7</street>
<city>Hamburg</city>
<code>D-20099</code>
<country>Germany</country>
</postal>
<phone>+4940428758067</phone>
<email>alexander.knauf@haw-hamburg.de</email>
<uri>http://inet.cpt.haw-hamburg.de/members/knauf</uri>
</address>
</author>
<author fullname="Gabriel Hege" initials="G." surname="Hege">
<organization abbrev="HAW Hamburg">HAW Hamburg</organization>
<address>
<postal>
<street>Berliner Tor 7</street>
<city>Hamburg</city>
<code>D-20099</code>
<country>Germany</country>
</postal>
<phone>+4940428758067</phone>
<email>hege@fhtw-berlin.de</email>
<uri>http://inet.cpt.haw-hamburg.de/members/hege</uri>
</address>
</author>
<author fullname="Thomas C. Schmidt" initials="T C." surname="Schmidt">
<organization abbrev="HAW Hamburg">HAW Hamburg</organization>
<address>
<postal>
<street>Berliner Tor 7</street>
<city>Hamburg</city>
<code>D-20099</code>
<country>Germany</country>
</postal>
<email>schmidt@informatik.haw-hamburg.de</email>
<uri>http://inet.cpt.haw-hamburg.de/members/schmidt</uri>
</address>
</author>
<author fullname="Matthias Waehlisch" initials="M." surname="Waehlisch">
<organization abbrev="link-lab & FU Berlin">link-lab & FU
Berlin</organization>
<address>
<postal>
<street>Hoenower Str. 35</street>
<city>Berlin</city>
<code>D-10318</code>
<country>Germany</country>
</postal>
<email>mw@link-lab.net</email>
<uri>http://www.inf.fu-berlin.de/~waehl</uri>
</address>
</author>
<date/>
<workgroup>P2PSIP Working Group</workgroup>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.</t>
<t>The Usage for Shared Resources in RELOAD is designed for jointly
coordinated group applications among distributed peers (c.f. <xref
target="I-D.knauf-p2psip-disco"></xref>). 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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Terminology">
<t>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 <xref target="RFC2119">
</xref>.<vspace blankLines="1" /></t>
<t>This document uses the terminology and definitions from the RELOAD
base <xref target="I-D.ietf-p2psip-base"> </xref>and the peer-to-peer
SIP concepts draft <xref target="I-D.ietf-p2psip-concepts"></xref>.
Additionally, the following terms are used: <list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list></t>
</section>
<section anchor="sec-srir" title="Shared Resources in RELOAD">
<t>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.</t>
<t>The Resource/Kind pair to be shared can be any RELOAD Kind that
complies to the following specifications: <list style="hanging">
<t hangText="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 <xref
target="subsec-mfisd"></xref>.</t>
<t hangText="Access Control Policy:">To ensure write access to
Shared Resource by Authorized Peers, each Usage MUST use the
USER-CHAIN-ACL access policy (see <xref
target="subsec-aclacp"></xref>).</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list></t>
<section anchor="subsec-mfisd"
title="Mechanisms for Isolating Stored Data">
<t>This Section defines mechanisms to avoid race conditions while
concurrently writing an array or dictionary of a Shared Resource.</t>
<t>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.</t>
<t>If the data model of the Shared Resource is an array, the following
algorithm will generate an array index that avoids collisions. <list
style="numbers">
<t>Obtain the Node-ID of the certificate that will be used to sign
the stored data</t>
<t>Take the least significant 24 bits of that Node-ID</t>
<t>Concatenate an 8 bit long short individual index value to those
24 bit of the Node-ID</t>
</list> 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.</t>
<t>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 <xref target="RFC3550"></xref> for calculating a
collision probability.</t>
</section>
</section>
<section anchor="sec-acd" title="Access Control List Definition">
<section anchor="subsec-al" title="Overview">
<t>In this document, an Access Control List (ACL) contains a list of
AccessControlListData structures defined in <xref
target="subsec-ds"></xref>. 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.</t>
<t><xref target="fig-access-list"></xref> 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 <xref target="subsec-mfisd"/>.
Hence, the most significant 24 bits of the array index (0x123abc) are
the least significant 24bits of the Node-ID of the Resource Owner.</t>
<t>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.</t>
<t>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
reference a different Kind-ID revokes all trust delegations in the
tree (see <xref target="subsec-rwa"></xref>). 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.</t>
<figure align="center" anchor="fig-access-list" suppress-title="false"
title="Simplified example of an Access Control including entries for two different Kind-IDs and varying delegation (ad) configurations">
<artwork align="center" xml:space="preserve"><![CDATA[
+---------------------------------------------------------------+
| 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 |
+-----------+---------------------------------------+-----------+
| ... | ... | ... |
+-----------+---------------------------------------+-----------+
]]></artwork>
</figure>
<t>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.</t>
</section>
<section anchor="subsec-ds" title="Data Structure">
<t>The Kind data structure for the Access Control List is defined as
follows:</t>
<figure align="center" suppress-title="true">
<artwork align="left" xml:space="preserve"><![CDATA[
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;
]]></artwork>
</figure>
<t>The AccessControlListItem structure is composed of: <list
style="hanging">
<t hangText="length:">This field contains the length of the Access
Control List data structure</t>
<t hangText="data:">This field contains the data of an ACL
item</t>
</list></t>
<t>The content of the AccessControlListData structure is defined as
follows: <list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="to_user:">This field contains the username of the
RELOAD peer that obtains writing permission to the Shared
Resource.</t>
<t hangText="kind:">This field contains the Kind-ID of the Shared
Resource.</t>
<t hangText="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.</t>
</list></t>
<t>The ACCESS-CONTROL-LIST kind is defined as follows: <list
style="hanging">
<t hangText="Name:">ACCESS-CONTROL-LIST</t>
<t hangText="Data model:">The Data model for the
ACCESS-CONTROL-LIST data is array.</t>
<t hangText="Access Control:">USER-CHAIN-ACL access policy (see
<xref target="subsec-aclacp"></xref>).</t>
</list></t>
</section>
</section>
<section anchor="sec-vrne" title="Extension for Variable Resource Names">
<section anchor="subsec-vrn-o" title="Overview">
<t>In certain use cases such as conferencing (c.f. <xref
target="I-D.knauf-p2psip-disco"></xref>) 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.</t>
<t>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:</t>
<figure align="center" suppress-title="true">
<artwork align="left" xml:space="preserve"><![CDATA[
Example Pattern:
.*-conf-$USER@$DOMAIN
]]></artwork>
</figure>
<t>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).</t>
</section>
<section anchor="subsec-ocde"
title="Overlay Configuration Document Extension">
<t>This document extends the overlay configuration document by
defining new elements for patterns relating resource names to user
names.</t>
<t>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.</t>
<t>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 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.</t>
<t>A <pattern> element MUST be present for every Kind using the
USER-CHAIN-MATCH access policy <xref
target="subsec-aclacp"></xref>.</t>
<t>The Relax NG Grammar for the Variable Resource Names Extension
is:</t>
<figure align="left" anchor="fig-le" suppress-title="true">
<artwork align="left" xml:space="preserve"><![CDATA[
<!-- 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 }*
}?
]]></artwork>
</figure>
</section>
</section>
<section anchor="sec-actsr" title="Access Control to Shared Resources">
<section anchor="subsec-gwa" title="Granting Write Access">
<t>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: <list
style="symbols">
<t>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 <xref
target="subsec-mfisd"></xref></t>
<t>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.</t>
</list></t>
<t>An Authorized Peer (with "ad"=1) can further share an exiting
Shared Resource as follows: <list style="symbols">
<t>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 <xref
target="subsec-mfisd"></xref>. Each succeeding ACL item
MAY be stored in the numerical order of the array index.</t>
</list></t> </section>
<section anchor="subsec-rwa" title="Revoking Write Access">
<t>Write permissions MAY be revoked by soring a non-existent value
<xref target="I-D.ietf-p2psip-base"></xref> 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.</t>
<t>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.</t>
</section>
<section anchor="subsec-saac" title="Storage and Validation">
<section anchor="subsec-ootsp" title="Operations of the Storing Peer">
<t>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 <xref
target="subsec-aclacp"/>) 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:
<list style="numbers">
<t>The storing peer sends a Stat request to Resource-ID of the
Shared Resource to obtain all array indexes of stored ACL Kinds.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>If true, the ACL validation procedure returns true.</t>
</list></t>
<t>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.</t>
<t>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 <xref
target="subsec-mfisd"></xref>)</t> </section>
<section anchor="subsec-ootap"
title="Operations of the Accessing Peer">
<t>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.</t>
<t>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</t>
<t>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 <xref
target="I-D.ietf-p2psip-base"></xref> or other means (e.g., caching
from a previous request).</t>
<t>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.</t>
</section>
</section>
<section anchor="subsec-aclacp" title="USER-CHAIN-ACL Access Policy">
<t>This document specifies an additional access control policy to the
RELOAD base draft <xref target="I-D.ietf-p2psip-base"></xref>. 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:</t>
<t>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
<xref target="I-D.ietf-p2psip-base"></xref> applies.</t>
<t>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. <xref target="sec-vrne"></xref>) 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.</t>
<t>Otherwise, the value MUST be written if the ACL Validation
procedure as described in <xref target="subsec-ootsp"></xref> returns
true.</t>
</section>
</section>
<section title="Security Considerations">
<t>In this section we discuss security issues that are relevant to the
usage of shared resources in RELOAD.</t>
<section title="Resource Exhaustion">
<t>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.</t>
</section>
<section title="Malicious or Misbehaving Storing Peer">
<t>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.</t>
</section>
<section title="Privacy Issues">
<t>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.</t>
</section>
</section>
<section title="IANA Considerations">
<t>TODO: register Kind-ID code point at the IANA</t>
</section>
<section title="Acknowledgments">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-p2psip-base"?>
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-p2psip-concepts"?>
<?rfc include="reference.I-D.knauf-p2psip-disco"?>
<?rfc include="reference.RFC.3550"?>
</references>
<section title="Change Log">
<t>The following changes have been made from version
draft-knauf-p2psip-share-00: <list style="numbers">
<t>Integrated the USER-PATTERN-MATCH access policy into
USER-CHAIN-MATCH</t>
<t>Access Control List Kind uses USER-CHAIN-ACL exclusively</t>
<t>Resources to be shared use USER-CHAIN-ACL exclusively</t>
<t>More precise specification of mandatory User_name and
Resource_name fields for Shared Resources</t>
<t>Added mechanism for isolating stored data to prevent race
conditions while concurrent storing</t>
<t>XML Extension for variable resource names uses its own
namespace</t>
<t>Many editorial improvements</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:41:19 |