| 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
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.
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 (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 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.
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.
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:
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:
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.
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.
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 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 |
+-----------+---------------------------------------+-----------+
| ... | ... | ... |
+-----------+---------------------------------------+-----------+
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.
The Kind data structure for the Access Control List is defined as follows:
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:
The content of the AccessControlListData structure is defined as follows:
The ACCESS-CONTROL-LIST kind is defined as follows:
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).
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 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 }*
}?
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:
An Authorized Peer (with "ad"=1) can further share an exiting Shared Resource as follows:
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.
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.
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:
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.
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)
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.
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.
In this section we discuss security issues that are relevant to the usage of shared resources in RELOAD.
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.
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.
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.
TODO: register Kind-ID code point at the IANA
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.
| [I-D.ietf-p2psip-base] | Jennings, C, Lowekamp, B, Rescorla, E, Baset, S and H Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", Internet-Draft draft-ietf-p2psip-base-19, October 2011. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [I-D.ietf-p2psip-concepts] | Bryan, D, Matthews, P, Shim, E, Willis, D and S Dawkins, "Concepts and Terminology for Peer to Peer SIP", Internet-Draft draft-ietf-p2psip-concepts-04, October 2011. |
| [I-D.knauf-p2psip-disco] | Knauf, A, Hege, G, Schmidt, T and M Waehlisch, "A RELOAD Usage for Distributed Conference Control (DisCo)", Internet-Draft draft-knauf-p2psip-disco-04, 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. |
The following changes have been made from version draft-knauf-p2psip-share-00: