draft-ietf-p2psip-share-01.txt		draft-ietf-p2psip-share-02.txt
	P2PSIP Working Group A. Knauf		P2PSIP Working Group A. Knauf
	Internet-Draft T C. Schmidt, Ed.		Internet-Draft T. Schmidt, Ed.
	Intended status: Standards Track HAW Hamburg		Intended status: Standards Track HAW Hamburg
	Expires: August 28, 2013 G. Hege		Expires: February 28, 2014 G. Hege
	daviko GmbH		daviko GmbH
	M. Waehlisch		M. Waehlisch
	link-lab & FU Berlin		link-lab & FU Berlin
	February 24, 2013		August 27, 2013
	A Usage for Shared Resources in RELOAD (ShaRe)		A Usage for Shared Resources in RELOAD (ShaRe)
	draft-ietf-p2psip-share-01		draft-ietf-p2psip-share-02
	Abstract		Abstract
	This document defines a RELOAD Usage for managing shared write access		This document defines a RELOAD Usage for managing shared write access
	to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic		to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic
	primitive for enabling various coordination and notification schemes		primitive for enabling various coordination and notification schemes
	among distributed peers. Access in ShaRe is controlled by a		among distributed peers. Access in ShaRe is controlled by a
	hierarchical trust delegation scheme maintained within an access		hierarchical trust delegation scheme maintained within an access
	list. A new USER-CHAIN-ACL access policy allows authorized peers to		list. A new USER-CHAIN-ACL access policy allows authorized peers to
	write a Shared Resource without owning its corresponding certificate.		write a Shared Resource without owning its corresponding certificate.
	This specification also adds mechanisms to store Resources with a		This specification also adds mechanisms to store Resources with a
	variable name which is useful whenever peer-independent rendezvous		variable name which is useful whenever peer-independent rendezvous
	processes are required.		processes are required.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 28, 2013.		This Internet-Draft will expire on February 28, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Shared Resources in RELOAD . . . . . . . . . . . . . . . . . . 5		3. Shared Resources in RELOAD . . . . . . . . . . . . . . . . . 4
	3.1. Mechanisms for Isolating Stored Data . . . . . . . . . . . 6		3.1. Mechanisms for Isolating Stored Data . . . . . . . . . . 5
	4. Access Control List Definition . . . . . . . . . . . . . . . . 7		4. Access Control List Definition . . . . . . . . . . . . . . . 6
	4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 8		4.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 8
	5. Extension for Variable Resource Names . . . . . . . . . . . . 10		5. Extension for Variable Resource Names . . . . . . . . . . . . 9
	5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 10		5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 9
	5.3. Overlay Configuration Document Extension . . . . . . . . . 11		5.3. Overlay Configuration Document Extension . . . . . . . . 10
	6. Access Control to Shared Resources . . . . . . . . . . . . . . 13		6. Access Control to Shared Resources . . . . . . . . . . . . . 11
	6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 13		6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 11
	6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 14		6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 12
	6.3. Validating Write Access through an ACL . . . . . . . . . . 14		6.3. Validating Write Access through an ACL . . . . . . . . . 12
	6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 15		6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 13
	6.5. Operations of Accessing Peers . . . . . . . . . . . . . . 15		6.5. Operations of Accessing Peers . . . . . . . . . . . . . . 14
	6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . . 15		6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . 14
	7. ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . . 17		7. ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . . 15
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 18		8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 15
	8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 18		8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 16
	8.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 18		8.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 16
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	9.1. Access Control Policy . . . . . . . . . . . . . . . . . . 19		9.1. Access Control Policy . . . . . . . . . . . . . . . . . . 16
	9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 19		9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 16
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20		9.3. XML Name Space Registration . . . . . . . . . . . . . . . 17
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 21		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	11.2. Informative References . . . . . . . . . . . . . . . . . . 21		11.1. Normative References . . . . . . . . . . . . . . . . . . 17
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22		11.2. Informative References . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
			Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	This document defines a RELOAD Usage for managing shared write access		This document defines a RELOAD Usage for managing shared write access
	to RELOAD Resources and a mechanism to store Resources with a		to RELOAD Resources and a mechanism to store Resources with a
	variable name. The Usage for Shared Resources in RELOAD (ShaRe)		variable name. The Usage for Shared Resources in RELOAD (ShaRe)
	enables overlay users to share their exclusive write access to		enables overlay users to share their exclusive write access to
	specific Resource/Kind pairs with others. Shared Resources form a		specific Resource/Kind pairs with others. Shared Resources form a
	basic primitive for enabling various coordination and notification		basic primitive for enabling various coordination and notification
	schemes among distributed peers. Write permission is controlled by		schemes among distributed peers. Write permission is controlled by
	skipping to change at page 5, line 45		skipping to change at page 5, line 32
	Section 3.1.		Section 3.1.
	Access Control Policy: To ensure write access to Shared Resource by		Access Control Policy: To ensure write access to Shared Resource by
	Authorized Peers, each Usage MUST use the USER-CHAIN-ACL access		Authorized Peers, each Usage MUST use the USER-CHAIN-ACL access
	policy as described in Section 6.6.		policy as described in Section 6.6.
	Resource Name Extension: To enable Shared Resources to be stored		Resource Name Extension: To enable Shared Resources to be stored
	using a variable resource name, this document defines an optional		using a variable resource name, this document defines an optional
	ResourceNameExtension structure. It contains the Resource Name of		ResourceNameExtension structure. It contains the Resource Name of
	the Kind data to be stored and allows any receiver of a shared		the Kind data to be stored and allows any receiver of a shared
	data to validate whether the Resource Name hashes to the		data to validate whether the Resource Name hashes to the Resource-
	Resource-ID. The ResourceNameExtension is made optional by		ID. The ResourceNameExtension is made optional by configuration.
	configuration. The ResourceNameExtension field is only present in		The ResourceNameExtension field is only present in the Kind data
	the Kind data structure when configured in the corresponding kind-		structure when configured in the corresponding kind-block of the
	block of the overlay configuration document (for more details see		overlay configuration document (for more details see Section 5.3).
	Section 5.3). If the configuration allows variable resource		If the configuration allows variable resource names, a Kind using
	names, a Kind using the USER-CHAIN-ACL policy MUST use the		the USER-CHAIN-ACL policy MUST use the ResourceNameExtension as
	ResourceNameExtension as initial field within the Kind data		initial field within the Kind data structure definition.
	structure definition. Otherwise the Kind data structure does not		Otherwise the Kind data structure does not contain the
	contain the ResourceNameExtension structure.		ResourceNameExtension structure.
	3.1. Mechanisms for Isolating Stored Data		3.1. Mechanisms for Isolating Stored Data
	This section defines mechanisms to avoid race conditions while		This section defines mechanisms to avoid race conditions while
	concurrently writing an array or dictionary of a Shared Resource.		concurrently writing an array or dictionary of a Shared Resource.
	If a dictionary is used in the Shared Resource, the dictionary key		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		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.		stored data. Thus data access is bound to the unique ID-holder.
	skipping to change at page 6, line 35		skipping to change at page 6, line 24
	3. Concatenate an 8 bit long short individual index value to those		3. Concatenate an 8 bit long short individual index value to those
	24 bit of the Node-ID		24 bit of the Node-ID
	The resulting 32 bits long integer MUST be used as the index for		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		storing an array entry in a Shared Resource. The 8 bit individual
	index can be incremented individually for further array entries and		index can be incremented individually for further array entries and
	allows for 256 distinct entries per Peer.		allows for 256 distinct entries per Peer.
	The mechanism to create the array index is related to the pseudo-		The mechanism to create the array index is related to the pseudo-
	random algorithm to generate an SSRC identifier in RTP, see Section		random algorithm to generate an SSRC identifier in RTP, see
	8.1 in [RFC3550] for calculating the probability of a collision.		Section 8.1 in [RFC3550] for calculating the probability of a
			collision.
	4. Access Control List Definition		4. Access Control List Definition
	4.1. Overview		4.1. Overview
	An Access Control List (ACL) is a (self-managed) shared resource that		An Access Control List (ACL) is a (self-managed) shared resource that
	contains a list of AccessControlListItem structures as defined in		contains a list of AccessControlListItem structures as defined in
	Section 4.2. Each entry delegates write access for a specific Kind		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		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		authorized to write a specific Resource-ID to delegate his exclusive
	skipping to change at page 8, line 13		skipping to change at page 7, line 36
	To manage Shared Resource access of multiple Kinds at a single		To manage Shared Resource access of multiple Kinds at a single
	location, the Resource Owner can create new ACL entries that refer to		location, the Resource Owner can create new ACL entries that refer to
	another Kind-ID as shown in array entry index 0x123abc003. Note that		another Kind-ID as shown in array entry index 0x123abc003. Note that
	overwriting existing items in an Access Control List that reference a		overwriting existing items in an Access Control List that reference a
	different Kind-ID revokes all trust delegations in the corresponding		different Kind-ID revokes all trust delegations in the corresponding
	subtree (see Section 6.2). Authorized Peers are only enabled to		subtree (see Section 6.2). Authorized Peers are only enabled to
	overwrite existing ACL item they own. The Resource Owner is allowed		overwrite existing ACL item they own. The Resource Owner is allowed
	to overwrite any existing ACL item, but should be aware of its		to overwrite any existing ACL item, but should be aware of its
	consequences.		consequences.
	+------------------------------------------------------+		+------------------------------------------------------+
	| Access Control List |		| Access Control List |
	+-----------+------------------------------+-----------+		+-----------+------------------------------+-----------+
	| #Index | Array Entries | signed by |		| #Index | Array Entries | signed by |
	+-----------+------------------------------+-----------+		+-----------+------------------------------+-----------+
	| 123abc001 | to_user:Owner Kind:1234 ad:1 | Owner |		| 123abc001 | to_user:Owner Kind:1234 ad:1 | Owner |
	+-----------+------------------------------+-----------+		+-----------+------------------------------+-----------+
	| 123abc002 | to_user:Alice Kind:1234 ad:1 | Owner |		| 123abc002 | to_user:Alice Kind:1234 ad:1 | Owner |
	+-----------+------------------------------+-----------+		+-----------+------------------------------+-----------+
	| 123abc003 | to_user:Owner Kind:4321 ad:1 | Owner |		| 123abc003 | to_user:Owner Kind:4321 ad:1 | Owner |
	+-----------+------------------------------+-----------+		+-----------+------------------------------+-----------+
	| 123abc004 | to_user:Carol Kind:4321 ad:0 | Owner |		| 123abc004 | to_user:Carol Kind:4321 ad:0 | Owner |
	+-----------+------------------------------+-----------+		+-----------+------------------------------+-----------+
	| ... | ... | ... |		| ... | ... | ... |
	+-----------+------------------------------+-----------+		+-----------+------------------------------+-----------+
	| 456def001 | to_user:Bob Kind:1234 ad:0 | Alice |		| 456def001 | to_user:Bob Kind:1234 ad:0 | Alice |
	+-----------+------------------------------+-----------+		+-----------+------------------------------+-----------+
	| ... | ... | ... |		| ... | ... | ... |
	+-----------+------------------------------+-----------+		+-----------+------------------------------+-----------+
	Figure 1: Simplified example of an Access Control including entries		Figure 1: Simplified example of an Access Control including entries
	for two different Kind-IDs and varying delegation (ad) configurations		for two different Kind-IDs and varying delegation (ad) configurations
	Implementations of ShaRe should be aware that the trust delegation in		Implementations of ShaRe should be aware that the trust delegation in
	an Access Control List need not be loop free. Self-contained		an Access Control List need not be loop free. Self-contained
	circular trust delegation from A to B and B to A are syntactically		circular trust delegation from A to B and B to A are syntactically
	possible, even though not very meaningful.		possible, even though not very meaningful.
	4.2. Data Structure		4.2. Data Structure
	The Kind data structure for the Access Control List is defined as		The Kind data structure for the Access Control List is defined as
	follows:		follows:
	struct {		struct {
	/* res_name_ext is optional, see documentation */		/* res_name_ext is optional, see documentation */
	ResourceNameExtension res_name_ext;		ResourceNameExtension res_name_ext;
	opaque to_user<0..2^16-1>;		opaque to_user<0..2^16-1>;
	KindId kind;		KindId kind;
	Boolean allow_delegation;		Boolean allow_delegation;
	} AccessControlListItem;		} AccessControlListItem;
	The AccessControlListItem structure is composed of:		The AccessControlListItem structure is composed of:
	res_name_ext: This optional field contains the Resource Name of a		res_name_ext: This optional field contains the Resource Name of a
	ResourceNameExtension (see Section 5.2) to be used by a Shared		ResourceNameExtension (see Section 5.2) to be used by a Shared
	Resource with variable resource name. This name serves the		Resource with variable resource name. This name serves the
	storing peer for validating, whether a variable resources name		storing peer for validating, whether a variable resources name
	matches one of the predefined naming pattern from the		matches one of the predefined naming pattern from the
	configuration document for this Kind. The presence of this field		configuration document for this Kind. The presence of this field
	is bound to a variable resource name element in the corresponding		is bound to a variable resource name element in the corresponding
	skipping to change at page 10, line 28		skipping to change at page 9, line 32
	name (or Node-ID) while storing data under a specific Resource-ID.		name (or Node-ID) while storing data under a specific Resource-ID.
	The specifications in this document scheme adhere to this paradigm,		The specifications in this document scheme adhere to this paradigm,
	but enable a RELOAD peer to store values of Resource Names that are		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		derived from the username in its certificate. This is done by using
	a Resource Name with a variable substring that still matches the user		a Resource Name with a variable substring that still matches the user
	name in the certificate using a pattern defined in the overlay		name in the certificate using a pattern defined in the overlay
	configuration document. Thus despite being variable, an allowable		configuration document. Thus despite being variable, an allowable
	Resource Name remains tied to the Owner's certificate. A sample		Resource Name remains tied to the Owner's certificate. A sample
	pattern might be formed as follows.		pattern might be formed as follows.
	Example Pattern:		Example Pattern:
	.*-conf-\$USER@\$DOMAIN		.*-conf-\$USER@\$DOMAIN
	When defining the pattern, care must be taken to avoid conflicts		When defining the pattern, care must be taken to avoid conflicts
	arising from two usernames of witch one is a substring of the other.		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		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		the resources of the longer-named peer by choosing the variable part
	of a Resource Name to contain the entire longer username. This		of a Resource Name to contain the entire longer username. This
	problem can easily be mitigated by delimiting the variable part of		problem can easily be mitigated by delimiting the variable part of
	the pattern from the username part by some fixed string, that by		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		convention is not part of a username (e.g., the "-conf-" in the above
	Example).		Example).
	5.2. Data Structure		5.2. Data Structure
	This section defines the optional ResourceNameExtension structure for		This section defines the optional ResourceNameExtension structure for
	every Kind that uses the USER-CHAIN-ACL access control policy.		every Kind that uses the USER-CHAIN-ACL access control policy.
	enum { pattern (1),		enum { pattern (1),
	(255)} ResourceNameType;		(255)} ResourceNameType;
			struct {
	struct {		ResourceNameType type;
	ResourceNameType type;		uint16 length;
	uint16 length;		select(type) {
	select(type) {		case pattern:
	case pattern:		opaque resource_name<0..2^16-1>;
	opaque resource_name<0..2^16-1>;
	/* Types can be extended */		/* Types can be extended */
	}		}
	} ResourceNameExtension		} ResourceNameExtension
	The content of the ResourceNameExtension consist of		The content of the ResourceNameExtension consist of
	length: This field contains the length of the remaining data		length: This field contains the length of the remaining data
	structure. It is only used to allow for further extensions to		structure. It is only used to allow for further extensions to
	this data structure.		this data structure.
	The content of the rest of the data structure depends of the		The content of the rest of the data structure depends of the
	ResourceNameType. Currently, the only defined type is "pattern".		ResourceNameType. Currently, the only defined type is "pattern".
	skipping to change at page 12, line 16		skipping to change at page 11, line 15
	A <pattern> element MUST be present if the "enabled" attribute of its		A <pattern> element MUST be present if the "enabled" attribute of its
	parent element is set to true. Each <pattern> element defines a		parent element is set to true. Each <pattern> element defines a
	pattern for constructing extended resource names for a single Kind.		pattern for constructing extended resource names for a single Kind.
	It is of type xsd:string and interpreted as a regular expression		It is of type xsd:string and interpreted as a regular expression
	according to "POSIX Extended Regular Expression" (see the		according to "POSIX Extended Regular Expression" (see the
	specifications in [IEEE-Posix]). In this regular expression, $USER		specifications in [IEEE-Posix]). In this regular expression, $USER
	and $DOMAIN are used as variables for the corresponding parts of the		and $DOMAIN are used as variables for the corresponding parts of the
	string in the certificate user name field (with $USER preceding and		string in the certificate user name field (with $USER preceding and
	$DOMAIN succeeding the '@'). Both variables MUST be present in any		$DOMAIN succeeding the '@'). Both variables MUST be present in any
	given pattern definition. If no pattern is defined for a Kind or the		given pattern definition. If no pattern is defined for a Kind or the
	"enabled" attribute is false, allowable Resource Names are restricted		"enable" attribute is false, allowable Resource Names are restricted
	to the username of the signer for Shared Resource.		to the username of the signer for Shared Resource.
	The Relax NG Grammar for the Variable Resource Names Extension reads:		The Relax NG Grammar for the Variable Resource Names Extension reads:
	<!-- VARIABLE RESOURCE URN SUB-NAMESPACE -->		<!-- VARIABLE RESOURCE URN SUB-NAMESPACE -->
	namespace share = "urn:ietf:params:xml:ns:p2p:config-base:share"		namespace share = "urn:ietf:params:xml:ns:p2p:config-base:share"
	<!-- VARIABLE RESOURCE NAMES ELEMENT -->		<!-- VARIABLE RESOURCE NAMES ELEMENT -->
	kind-parameter &= element share:variable-resource-names {		kind-parameter &= element share:variable-resource-names {
	attribute enable { xsd:boolean }		attribute enable { xsd:boolean }
	<!-- PATTERN ELEMENT -->		<!-- PATTERN ELEMENT -->
	element pattern { xsd:string }*		element pattern { xsd:string }*
	}?		}?
			Figure 2
	6. Access Control to Shared Resources		6. Access Control to Shared Resources
	6.1. Granting Write Access		6.1. Granting Write Access
	Write access to a Kind that is intended to be shared with other		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		RELOAD users can solely be issued by the Resource Owner. A Resource
	Owner can share RELOAD Kinds by using the following procedure.		Owner can share RELOAD Kinds by using the following procedure.
	o The Resource Owner stores an ACL root item at the Resource-ID of		o The Resource Owner stores an ACL root item at the Resource-ID of
	the Shared Resource. The root item contains the resource name		the Shared Resource. The root item contains the resource name
	skipping to change at page 13, line 33		skipping to change at page 12, line 18
	the Authorized Peer and the Kind-Id of the Shared Resource.		the Authorized Peer and the Kind-Id of the Shared Resource.
	Optionally, the Resource Owner sets the "ad" to 1 (the default		Optionally, the Resource Owner sets the "ad" to 1 (the default
	equals 0) to enable the Authorized Peer to further delegate write		equals 0) to enable the Authorized Peer to further delegate write
	access. Each succeeding ACL item created by the Resource Owner		access. Each succeeding ACL item created by the Resource Owner
	can be stored in the numerical order of the array index starting		can be stored in the numerical order of the array index starting
	with the index of the root item incremented by one.		with the index of the root item incremented by one.
	An Authorized Peer with delegation allowance ("ad"=1) can extend the		An Authorized Peer with delegation allowance ("ad"=1) can extend the
	access to an existing Shared Resource as follows.		access to an existing Shared Resource as follows.
	o An Authorized Peer can store additional ACL items at the		o An Authorized Peer can store additional ACL items at the Resource-
	Resource-ID of the Shared Resource. These ACL items contain the		ID of the Shared Resource. These ACL items contain the resource
	resource name extension field, the username of the newly		name extension field, the username of the newly Authorized Peer,
	Authorized Peer, and the Kind-Id of the Shared Resource.		and the Kind-Id of the Shared Resource. Optionally, the "ad" flag
	Optionally, the "ad" flag is set to 1 for allowing the Authorized		is set to 1 for allowing the Authorized Peer to further delegate
	Peer to further delegate write access. The array index MUST be		write access. The array index MUST be generated as described in
	generated as described in Section 3.1. Each succeeding ACL item		Section 3.1. Each succeeding ACL item can be stored in the
	can be stored in the numerical order of the array index.		numerical order of the array index.
	A store request by an Authorized Peer that attempts to overwrite any		A store request by an Authorized Peer that attempts to overwrite any
	ACL item signed by another Peer is unauthorized and causes an		ACL item signed by another Peer is unauthorized and causes an
	Error_Forbidden response from the Storing Peer. Such access		Error_Forbidden response from the Storing Peer. Such access
	conflicts could be caused by an array index collision. However, the		conflicts could be caused by an array index collision. However, the
	probability of a collision of two or more identical array indices		probability of a collision of two or more identical array indices
	will be negligibly low using the mechanism for isolating stored data		will be negligibly low using the mechanism for isolating stored data
	(see Section 3.1)		(see Section 3.1)
	6.2. Revoking Write Access		6.2. Revoking Write Access
	skipping to change at page 16, line 14		skipping to change at page 15, line 7
	inbound store request on a Kind that uses the USER-CHAIN-ACL access		inbound store request on a Kind that uses the USER-CHAIN-ACL access
	policy, the following rules MUST be applied:		policy, the following rules MUST be applied:
	In the USER-CHAIN-ACL policy, a given value MUST be written or		In the USER-CHAIN-ACL policy, a given value MUST be written or
	overwritten, if either one of USER-MATCH or USER-NODE-MATCH		overwritten, if either one of USER-MATCH or USER-NODE-MATCH
	(mandatory if the data model is dictionary) access policies of the		(mandatory if the data model is dictionary) access policies of the
	base document [I-D.ietf-p2psip-base] applies.		base document [I-D.ietf-p2psip-base] applies.
	Otherwise, the value MUST be written if the certificate of the signer		Otherwise, the value MUST be written if the certificate of the signer
	contains a username that matches to one of the variable resource name		contains a username that matches to one of the variable resource name
	pattern (c.f. Section 5) specified in the configuration document		pattern (c.f. Section 5) specified in the configuration document and,
	and, additionally, the hashed Resource Name matches the Resource-ID.		additionally, the hashed Resource Name matches the Resource-ID. The
	The Resource Name of the Kind to be stored MUST be taken from the		Resource Name of the Kind to be stored MUST be taken from the
	mandatory ResourceNameExtension field in the corresponding Kind data		mandatory ResourceNameExtension field in the corresponding Kind data
	structure.		structure.
	Otherwise, the value MUST be written if the ACL validation procedure		Otherwise, the value MUST be written if the ACL validation procedure
	described in Section 6.3 has been successfully applied.		described in Section 6.3 has been successfully applied.
	7. ACCESS-CONTROL-LIST Kind Definition		7. ACCESS-CONTROL-LIST Kind Definition
	This section defines the ACCESS-CONTROL-LIST Kind previously		This section defines the ACCESS-CONTROL-LIST Kind previously
	described in this document.		described in this document.
	skipping to change at page 19, line 15		skipping to change at page 16, line 35
	9. IANA Considerations		9. IANA Considerations
	9.1. Access Control Policy		9.1. Access Control Policy
	IANA shall register the following entry in the "RELOAD Access Control		IANA shall register the following entry in the "RELOAD Access Control
	Policies" Registry (cf., [I-D.ietf-p2psip-base]) to represent the		Policies" Registry (cf., [I-D.ietf-p2psip-base]) to represent the
	USER-CHAIN-ACL Access Control Policy, as described in Section 6.6.		USER-CHAIN-ACL Access Control Policy, as described in Section 6.6.
	[NOTE TO IANA/RFC-EDITOR: Please replace RFC-AAAA with the RFC number		[NOTE TO IANA/RFC-EDITOR: Please replace RFC-AAAA with the RFC number
	for this specification in the following list.]		for this specification in the following list.]
	+-------------------+----------+		+-------------------+----------+
	| Kind | RFC |		| Kind | RFC |
	+-------------------+----------+		+-------------------+----------+
	| USER-CHAIN-ACL | RFC-AAAA |		| USER-CHAIN-ACL | RFC-AAAA |
	+-------------------+----------+		+-------------------+----------+
	9.2. Data Kind-ID		9.2. Data Kind-ID
	IANA shall register the following code point in the "RELOAD Data		IANA shall register the following code point in the "RELOAD Data
	Kind-ID" Registry (cf., [I-D.ietf-p2psip-base]) to represent the		Kind-ID" Registry (cf., [I-D.ietf-p2psip-base]) to represent the
	ShaRe ACCESS-CONTROL-LIST kind, as described in Section 7. [NOTE TO		ShaRe ACCESS-CONTROL-LIST kind, as described in Section 7. [NOTE TO
	IANA/RFC-EDITOR: Please replace RFC-AAAA with the RFC number for this		IANA/RFC-EDITOR: Please replace RFC-AAAA with the RFC number for this
	specification in the following list.]		specification in the following list.]
	+----------------------+------------+----------+		+----------------------+------------+----------+
	| Kind | Kind-ID | RFC |		| Kind | Kind-ID | RFC |
	+----------------------+------------+----------+		+----------------------+------------+----------+
	| ACCESS-CONTROL-LIST | 17 | RFC-AAAA |		| ACCESS-CONTROL-LIST | 17 | RFC-AAAA |
	+----------------------+------------+----------+		+----------------------+------------+----------+
			9.3. XML Name Space Registration
			This document registers the following URI for the config XML
			namespace in the IETF XML registry defined in [RFC3688]
			URI: urn:ietf:params:xml:ns:p2p:config-base:share
			Registrant Contact: The IESG
			XML: N/A, the requested URI is an XML namespace
	10. Acknowledgments		10. Acknowledgments
	This work was stimulated by fruitful discussions in the P2PSIP		This work was stimulated by fruitful discussions in the P2PSIP
	working group and SAM research group. We would like to thank all		working group and SAM research group. We would like to thank all
	active members for constructive thoughts and feedback. In		active members for constructive thoughts and feedback. In
	particular, the authors would like to thank (in alphabetical order)		particular, the authors would like to thank (in alphabetical order)
	Lothar Grimm, Cullen Jennings, Peter Musgrave, Joerg Ott, Marc Petit-		Lothar Grimm, Cullen Jennings, Peter Musgrave, Joerg Ott, Marc Petit-
	Huguenin, Peter Pogrzeba, and Jan Seedorf. This work was partly		Huguenin, Peter Pogrzeba, and Jan Seedorf. This work was partly
	funded by the German Federal Ministry of Education and Research,		funded by the German Federal Ministry of Education and Research,
	projects HAMcast, Mindstone, and SAFEST.		projects HAMcast, Mindstone, and SAFEST.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-p2psip-base]		[I-D.ietf-p2psip-base]
	Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and		Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
	H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)		H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
	Base Protocol", draft-ietf-p2psip-base-25 (work in		Base Protocol", draft-ietf-p2psip-base-26 (work in
	progress), February 2013.		progress), February 2013.
	[IEEE-Posix]		[IEEE-Posix]
	"IEEE Standard for Information Technology - Portable		, "IEEE Standard for Information Technology - Portable
	Operating System Interface (POSIX) - Part 2: Shell and		Operating System Interface (POSIX) - Part 2: Shell and
	Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 1-55937-		Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN
	255-9, January 1993.		1-55937-255-9, January 1993.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
			January 2004.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-p2psip-concepts]		[I-D.ietf-p2psip-concepts]
	Bryan, D., Willis, D., Shim, E., Matthews, P., and S.		Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
	Dawkins, "Concepts and Terminology for Peer to Peer SIP",		Dawkins, "Concepts and Terminology for Peer to Peer SIP",
	draft-ietf-p2psip-concepts-04 (work in progress),		draft-ietf-p2psip-concepts-05 (work in progress), July
	October 2011.		2013.
	[I-D.ietf-p2psip-disco]		[I-D.ietf-p2psip-disco]
	Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A		Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A
	RELOAD Usage for Distributed Conference Control (DisCo)",		RELOAD Usage for Distributed Conference Control (DisCo)",
	draft-ietf-p2psip-disco-00 (work in progress),		draft-ietf-p2psip-disco-02 (work in progress), July 2013.
	October 2012.
	[I-D.ietf-p2psip-sip]		[I-D.ietf-p2psip-sip]
	Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.,		Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.,
	Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD",		Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD",
	draft-ietf-p2psip-sip-08 (work in progress),		draft-ietf-p2psip-sip-11 (work in progress), July 2013.
	December 2012.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, July 2003.		Applications", STD 64, RFC 3550, July 2003.
	Appendix A. Change Log		Appendix A. Change Log
	The following changes have been made from version		The following changes have been made from version draft-ietf-p2psio-
	draft-ietf-p2psio-share-00:		share-01:
			1. Added IANA registration for namespace
			2. Editorial improvements
			3. Updated References
			The following changes have been made from version draft-ietf-p2psio-
			share-00:
	1. Clarified use of identities in ACLs		1. Clarified use of identities in ACLs
	2. Specified use of Posix regular expressions in configuration		2. Specified use of Posix regular expressions in configuration
	document		document
	3. Added IANA considerations		3. Added IANA considerations
	4. Editorial improvements		4. Editorial improvements
	5. Updated References		5. Updated References
			The following changes have been made from version draft-knauf-p2psip-
	The following changes have been made from version		share-02:
	draft-knauf-p2psip-share-02:
	1. Editorial improvements		1. Editorial improvements
	2. Updated References		2. Updated References
	The following changes have been made from version		The following changes have been made from version draft-knauf-p2psip-
	draft-knauf-p2psip-share-01:		share-01:
	1. Simplified the ACL data structure in response to WG feedback		1. Simplified the ACL data structure in response to WG feedback
	2. Added ResourceNameExtension data structure to simplify the use of		2. Added ResourceNameExtension data structure to simplify the use of
	variable resource names		variable resource names
	3. Restructured document		3. Restructured document
	4. Many editorial improvements		4. Many editorial improvements
	The following changes have been made from version		The following changes have been made from version draft-knauf-p2psip-
	draft-knauf-p2psip-share-00:		share-00:
	1. Integrated the USER-PATTERN-MATCH access policy into USER-CHAIN-		1. Integrated the USER-PATTERN-MATCH access policy into USER-CHAIN-
	ACL		ACL
	2. Access Control List Kind uses USER-CHAIN-ACL exclusively		2. Access Control List Kind uses USER-CHAIN-ACL exclusively
	3. Resources to be shared use USER-CHAIN-ACL exclusively		3. Resources to be shared use USER-CHAIN-ACL exclusively
	4. More precise specification of mandatory User_name and		4. More precise specification of mandatory User_name and
	Resource_name fields for Shared Resources		Resource_name fields for Shared Resources
	skipping to change at page 24, line 6		skipping to change at page 20, line 4
	Resource_name fields for Shared Resources		Resource_name fields for Shared Resources
	5. Added mechanism for isolating stored data to prevent race		5. Added mechanism for isolating stored data to prevent race
	conditions while concurrent storing		conditions while concurrent storing
	6. XML Extension for variable resource names uses its own namespace		6. XML Extension for variable resource names uses its own namespace
	7. Many editorial improvements		7. Many editorial improvements
	Authors' Addresses		Authors' Addresses
	Alexander Knauf		Alexander Knauf
	HAW Hamburg		HAW Hamburg
	Berliner Tor 7		Berliner Tor 7
	Hamburg D-20099		Hamburg D-20099
	Germany		Germany
	Phone: +4940428758067		Phone: +4940428758067
	Email: alexanderknauf@gmail.com		Email: alexanderknauf@gmail.com
	URI:
	Thomas C. Schmidt		Thomas C. Schmidt
	HAW Hamburg		HAW Hamburg
	Berliner Tor 7		Berliner Tor 7
	Hamburg D-20099		Hamburg D-20099
	Germany		Germany
	Email: schmidt@informatik.haw-hamburg.de		Email: schmidt@informatik.haw-hamburg.de
	URI: http://inet.cpt.haw-hamburg.de/members/schmidt		URI: http://inet.cpt.haw-hamburg.de/members/schmidt
	Gabriel Hege		Gabriel Hege
	daviko GmbH		daviko GmbH
	Am Borsigturm 50		Am Borsigturm 50
	Berlin D-13507		Berlin D-13507
	Germany		Germany
	Phone: +493043004344		Phone: +493043004344
	Email: hege@daviko.com		Email: hege@daviko.com
	URI:
	Matthias Waehlisch		Matthias Waehlisch
	link-lab & FU Berlin		link-lab & FU Berlin
	Hoenower Str. 35		Hoenower Str. 35
	Berlin D-10318		Berlin D-10318
	Germany		Germany
	Email: mw@link-lab.net		Email: mw@link-lab.net
	URI: http://www.inf.fu-berlin.de/~waehl		URI: http://www.inf.fu-berlin.de/~waehl
End of changes. 35 change blocks.
	135 lines changed or deleted		156 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/