Internet DRAFT - draft-knauf-p2psip-share
draft-knauf-p2psip-share
P2PSIP Working Group A. Knauf
Internet-Draft G. Hege
Intended status: Standards Track T C. Schmidt
Expires: October 27, 2012 HAW Hamburg
M. Waehlisch
link-lab & FU Berlin
April 25, 2012
A Usage for Shared Resources in RELOAD (ShaRe)
draft-knauf-p2psip-share-03
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 October 27, 2012.
Copyright Notice
Copyright (c) 2012 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 October 27, 2012 [Page 1]
Internet-Draft ShaRe April 2012
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 . . . . . . . . . . . . 10
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Overlay Configuration Document Extension . . . . . . . . . 11
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 . . . . . . . . . . . . . . 15
6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . . 15
7. ACL Kind Definition . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 18
8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 18
8.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Knauf, et al. Expires October 27, 2012 [Page 2]
Internet-Draft ShaRe April 2012
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 (e.g., third
party registration, or distributed conferencing,
see[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 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 must contain the username
of the Resource creator.
Knauf, et al. Expires October 27, 2012 [Page 3]
Internet-Draft ShaRe April 2012
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 October 27, 2012 [Page 4]
Internet-Draft ShaRe April 2012
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.
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 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 initial field within the Kind data
Knauf, et al. Expires October 27, 2012 [Page 5]
Internet-Draft ShaRe April 2012
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.
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 individually for further array entries 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 the probability of a collision.
Knauf, et al. Expires October 27, 2012 [Page 6]
Internet-Draft ShaRe April 2012
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 a RELOAD
instance. Each Access Control List data structure therefore 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.
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 0x123abc001 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 0x123abc002 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 (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. On the contrary,
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, which makes the item 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 0x123abc003. Note that
Knauf, et al. Expires October 27, 2012 [Page 7]
Internet-Draft ShaRe April 2012
overwriting existing items in an Access Control List that reference a
different 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.
+------------------------------------------------------+
| Access Control List |
+-----------+------------------------------+-----------+
| #Index | Array Entries | signed by |
+-----------+------------------------------+-----------+
| 123abc001 | to_user:Owner Kind:1234 ad:1 | Owner |
+-----------+------------------------------+-----------+
| 123abc002 | to_user:Alice Kind:1234 ad:1 | Owner |
+-----------+------------------------------+-----------+
| 123abc003 | to_user:Owner Kind:4321 ad:1 | Owner |
+-----------+------------------------------+-----------+
| 123abc004 | to_user:Carol Kind:4321 ad:0 | Owner |
+-----------+------------------------------+-----------+
| ... | ... | ... |
+-----------+------------------------------+-----------+
| 456def001 | to_user: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 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. Expires October 27, 2012 [Page 8]
Internet-Draft ShaRe April 2012
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 variable resource name. This name serves 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.
Knauf, et al. Expires October 27, 2012 [Page 9]
Internet-Draft ShaRe April 2012
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 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 user
name (or Node-ID) while storing data under a specific Resource-ID.
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
When defining the pattern, care must be taken to avoid conflicts
arising from two usernames of witch 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. 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.
Knauf, et al. Expires October 27, 2012 [Page 10]
Internet-Draft ShaRe April 2012
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 consist 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 pattern 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.
5.3. Overlay Configuration Document Extension
This section 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 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 SHOULD 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
Knauf, et al. Expires October 27, 2012 [Page 11]
Internet-Draft ShaRe April 2012
pattern for constructing extended resource names for a single Kind.
It is of type xsd:string and interpreted as a regular expression. 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. If no
pattern is defined for a Kind or the "enabled" attribute is false,
allowable Resource Names are restricted to the username of the signer
for Shared Resource.
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 pattern { xsd:string }*
}?
Knauf, et al. Expires October 27, 2012 [Page 12]
Internet-Draft ShaRe April 2012
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 Resource-ID of
the Shared Resource. The root item contains the resource name
extension 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
will 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. Each succeeding ACL item created by the Resource Owner
can be stored in the numerical order of the array index starting
with the index of the root item incremented by one.
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 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)
Knauf, et al. Expires October 27, 2012 [Page 13]
Internet-Draft ShaRe April 2012
6.2. Revoking Write Access
Write permissions are revoked by storing a non-existent value
[I-D.ietf-p2psip-base] 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 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.
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.
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 and proceeds as follows.
1. Obtain the username of the certificate used for signing the data
stored at the Shared Resource.
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 step 2.
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 previously selected ACL item. This
final ACL item is expected to be the root item of this ACL which
SHALL 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
Knauf, et al. Expires October 27, 2012 [Page 14]
Internet-Draft ShaRe April 2012
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, i.e., 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.4), 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.
6.5. Operations of Accessing Peers
Accessing peers, i.e., peers that fetch a Shared Resource, MAY
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.
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 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-ACL allows the storage of Kinds with a variable resource name
that are following one of the specified naming pattern. Hence, on an
Knauf, et al. Expires October 27, 2012 [Page 15]
Internet-Draft ShaRe April 2012
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 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 one of 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 to be stored MUST be taken from the
mandatory ResourceNameExtension field in the corresponding Kind data
structure.
Otherwise, the value MUST be written if the ACL validation procedure
described in Section 6.3 has been successfully applied.
Knauf, et al. Expires October 27, 2012 [Page 16]
Internet-Draft ShaRe April 2012
7. ACL 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)
Knauf, et al. Expires October 27, 2012 [Page 17]
Internet-Draft ShaRe April 2012
8. Security Considerations
In this section we discuss security issues that are relevant to the
usage of shared resources in RELOAD.
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.
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. 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 October 27, 2012 [Page 18]
Internet-Draft ShaRe April 2012
9. IANA Considerations
TODO: register Kind-ID code point at the IANA
Knauf, et al. Expires October 27, 2012 [Page 19]
Internet-Draft ShaRe April 2012
10. 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 partly
funded by the German Federal Ministry of Education and Research,
projects HAMcast and Mindstone.
Knauf, et al. Expires October 27, 2012 [Page 20]
Internet-Draft ShaRe April 2012
11. References
11.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-21 (work in
progress), March 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[I-D.ietf-p2psip-concepts]
Bryan, D., Willis, D., Shim, E., Matthews, P., and S.
Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-04 (work in progress),
October 2011.
[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-04 (work in progress),
October 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 October 27, 2012 [Page 21]
Internet-Draft ShaRe April 2012
Appendix A. Change Log
The following changes have been made from version
draft-knauf-p2psip-share-02:
1. Editorial improvements
2. Updated References
The following changes have been made from version
draft-knauf-p2psip-share-01:
1. Simplified the ACL data structure in response to WG feedback
2. Added ResourceNameExtension data structure to simplify the use of
variable resource names
3. Restructured document
4. Many editorial improvements
The following changes have been made from version
draft-knauf-p2psip-share-00:
1. Integrated the USER-PATTERN-MATCH access policy into USER-CHAIN-
ACL
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 October 27, 2012 [Page 22]
Internet-Draft ShaRe April 2012
Authors' Addresses
Alexander Knauf
HAW Hamburg
Berliner Tor 7
Hamburg D-20099
Germany
Phone: +4940428758067
Email: alexanderknauf@gmail.com
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 October 27, 2012 [Page 23]
