One document matched: draft-knauf-p2psip-share-01.txt
Differences from draft-knauf-p2psip-share-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:49:11 |