draft-ietf-p2psip-share-00.txt   draft-ietf-p2psip-share-01.txt 
P2PSIP Working Group A. Knauf P2PSIP Working Group A. Knauf
Internet-Draft T C. Schmidt, Ed. Internet-Draft T C. Schmidt, Ed.
Intended status: Standards Track HAW Hamburg Intended status: Standards Track HAW Hamburg
Expires: April 12, 2013 G. Hege Expires: August 28, 2013 G. Hege
daviko GmbH daviko GmbH
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
October 9, 2012 February 24, 2013
A Usage for Shared Resources in RELOAD (ShaRe) A Usage for Shared Resources in RELOAD (ShaRe)
draft-ietf-p2psip-share-00 draft-ietf-p2psip-share-01
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.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 April 12, 2013. This Internet-Draft will expire on August 28, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Overlay Configuration Document Extension . . . . . . . . . 11 5.3. Overlay Configuration Document Extension . . . . . . . . . 11
6. Access Control to Shared Resources . . . . . . . . . . . . . . 13 6. Access Control to Shared Resources . . . . . . . . . . . . . . 13
6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 13 6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 13
6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 14 6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 14
6.3. Validating Write Access through an ACL . . . . . . . . . . 14 6.3. Validating Write Access through an ACL . . . . . . . . . . 14
6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 15 6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 15
6.5. Operations of Accessing Peers . . . . . . . . . . . . . . 15 6.5. Operations of Accessing Peers . . . . . . . . . . . . . . 15
6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . . 15 6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . . 15
7. ACL Kind Definition . . . . . . . . . . . . . . . . . . . . . 17 7. ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 18 8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 18
8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 18 8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 18
8.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 18 8.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. Access Control Policy . . . . . . . . . . . . . . . . . . 19
9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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
an Access Control List (ACL) Kind that maintains a chain of an Access Control List (ACL) Kind that maintains a chain of
Authorized Peers for a particular Shared Resource. A newly defined Authorized Peers for a particular Shared Resource. A newly defined
USER-CHAIN-ACL access control policy enables shared write access in USER-CHAIN-ACL access control policy enables shared write access in
RELOAD. RELOAD.
The Usage for Shared Resources in RELOAD is designed for jointly The Usage for Shared Resources in RELOAD is designed for jointly
coordinated group applications among distributed peers (e.g., third coordinated group applications among distributed peers (e.g., third
party registration, or distributed conferencing, party registration, see [I-D.ietf-p2psip-sip] , or distributed
see[I-D.knauf-p2psip-disco]). Of particular interest are rendezvous conferencing, see[I-D.ietf-p2psip-disco]). Of particular interest
processes, where a single identifier is linked to multiple, dynamic are rendezvous processes, where a single identifier is linked to
instances of a distributed cooperative service. Shared write access multiple, dynamic instances of a distributed cooperative service.
is based on a trust delegation mechanism. It transfers the Shared write access is based on a trust delegation mechanism. It
authorization to write a specific Kind data by storing logical Access transfers the authorization to write a specific Kind data by storing
Control Lists. An ACL contains the ID of the Kind to be shared and logical Access Control Lists. An ACL contains the ID of the Kind to
contains trust delegations from one authorized to another (previously be shared and contains trust delegations from one authorized to
unauthorized) user. another (previously unauthorized) user.
Shared write access augments the RELOAD security model, which is Shared write access augments the RELOAD security model, which is
based on the restriction that peers are only allowed to write based on the restriction that peers are only allowed to write
resources at a small set of well defined locations (Resource-IDs) in resources at a small set of well defined locations (Resource-IDs) in
the overlay. Using the standard access control rules in RELOAD, the overlay. Using the standard access control rules in RELOAD,
these locations are bound to the username or Node-ID in the peer's these locations are bound to the username or Node-ID in the peer's
certificate. This document extends the base policies to enable a certificate. This document extends the base policies to enable a
controlled write access for multiple users to a common Resource Id. controlled write access for multiple users to a common Resource Id.
Additionally, this specification defines an optional mechanism to Additionally, this specification defines an optional mechanism to
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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.
If the data model of the Shared Resource is an array, the following If the data model of the Shared Resource is an array, each Authorized
algorithm will generate an array index that avoids collisions. Peer SHALL obtain its exclusive range of the array indices. The
following algorithm will generate an array indexing scheme that
avoids collisions.
1. Obtain the Node-ID of the certificate that will be used to sign 1. Obtain the Node-ID of the certificate that will be used to sign
the stored data the stored data
2. Take the least significant 24 bits of that Node-ID 2. Take the least significant 24 bits of that Node-ID
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
skipping to change at page 7, line 14 skipping to change at page 7, line 14
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
write access to a specific Kind to further users of a RELOAD write access to a specific Kind to further users of the same RELOAD
instance. Each Access Control List data structure therefore carries overlay. Each Access Control List data structure therefore carries
the information about who obtains write access, the Kind-ID of the the information about who obtains write access, the Kind-ID of the
Resource to be shared, and whether delegation includes write access Resource to be shared, and whether delegation includes write access
to the ACL itself. The latter condition grants the right to delegate to the ACL itself. The latter condition grants the right to delegate
write access further for the Authorized Peer. Access Control Lists write access further for the Authorized Peer. Access Control Lists
are stored at the same overlay location as the Shared Resource and are stored at the same overlay location as the Shared Resource and
use the RELOAD array data model. They are initially created by the use the RELOAD array data model. They are initially created by the
Resource Owner. Resource Owner.
Figure 1 shows an example of an Access Control List. We omit the Figure 1 shows an example of an Access Control List. We omit the
res_name_ext field to simplify illustration. The array entry at res_name_ext field to simplify illustration. The array entry at
skipping to change at page 7, line 47 skipping to change at page 7, line 47
The array item at index 0x123abc002 represents the first trust The array item at index 0x123abc002 represents the first trust
delegation to an Authorized Peer that is thus permitted to write to delegation to an Authorized Peer that is thus permitted to write to
the Shared Resource of Kind-ID 1234. Additionally, the Authorized the Shared Resource of Kind-ID 1234. Additionally, the Authorized
peer Alice is also granted (limited) write access to the ACL as peer Alice is also granted (limited) write access to the ACL as
indicated by the allow_delegation flag (ad) set to 1. This indicated by the allow_delegation flag (ad) set to 1. This
configuration authorizes Alice to store further trust delegations to configuration authorizes Alice to store further trust delegations to
the Shared Resource, i.e., add items to the ACL. On the contrary, the Shared Resource, i.e., add items to the ACL. On the contrary,
index 0x456def001 illustrates trust delegation for Kind-ID 1234, in index 0x456def001 illustrates trust delegation for Kind-ID 1234, in
which the Authorized Peer Bob is not allowed to grant access to which the Authorized Peer Bob is not allowed to grant access to
further peers (ad = 0). Each Authorized Peer signs its ACL items further peers (ad = 0). Each Authorized Peer signs its ACL items by
with its own private key, which makes the item ownership transparent. using its own signer identity along with its own private key. This
allows other peers to validate the origin of an ACL item and makes
ownership transparent.
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.
skipping to change at page 10, line 9 skipping to change at page 10, line 9
kind: This field contains the Kind-ID of the Shared Resource. kind: This field contains the Kind-ID of the Shared Resource.
allow_delegation: If true, this Boolean flag indicates that the allow_delegation: If true, this Boolean flag indicates that the
Authorized Peer in the 'to_user' field is allowed to add Authorized Peer in the 'to_user' field is allowed to add
additional entries to the ACL for the specified Kind-ID. additional entries to the ACL for the specified Kind-ID.
5. Extension for Variable Resource Names 5. Extension for Variable Resource Names
5.1. Overview 5.1. Overview
In certain use cases such as conferencing (c.f. In certain use cases such as conferencing (c.f.,
[I-D.knauf-p2psip-disco]) it is desirable to increase the flexibility [I-D.ietf-p2psip-disco]) it is desirable to increase the flexibility
of a peer in using Resource Names beyond those defined by the of a peer in using Resource Names beyond those defined by the
username or Node-ID fields in its certificate. For this purpose, username or Node-ID fields in its certificate. For this purpose,
this document presents the concept for variable Resources Names that this document presents the concept for variable Resources Names that
enables providers of RELOAD instances to define relaxed naming enables providers of RELOAD instances to define relaxed naming
schemes for overlay Resources. schemes for overlay Resources.
Each RELOAD node uses a certificate to identify itself using its user Each RELOAD node uses a certificate to identify itself using its user
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 a Resource Name with a variable substring that still matches the user
username 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).
skipping to change at page 11, line 41 skipping to change at page 11, line 41
Name MUST match to one of the variable resource name pattern defined Name MUST match to one of the variable resource name pattern defined
for this Kind in the configuration document. for this Kind in the configuration document.
The ResourceNameType enum and the ResourceNameExtension structure can The ResourceNameType enum and the ResourceNameExtension structure can
be extended by further Usages to define other naming schemes. be extended by further Usages to define other naming schemes.
5.3. Overlay Configuration Document Extension 5.3. Overlay Configuration Document Extension
This section extends the overlay configuration document by defining This section extends the overlay configuration document by defining
new elements for patterns relating resource names to user names. new elements for patterns relating resource names to user names.
Configurations in this overlay document MUST adhere in syntax and
semantic of names as defined by the context of use. For example, AOR
syntax restrictions apply when using P2PSIP[I-D.ietf-p2psip-sip] ,
while a more general naming is feasible in plain RELOAD.
The <variable-resource-names> element serves as a container for one The <variable-resource-names> element serves as a container for one
or multiple <pattern> sub-elements. It is an additional parameter or multiple <pattern> sub-elements. It is an additional parameter
within the kind block and has a boolean "enable" attribute that within the kind block and has a boolean "enable" attribute that
indicates, if true, that the overlay provider allows variable indicates, if true, that the overlay provider allows variable
resource names for this Kind. The default value of the "enable" resource names for this Kind. The default value of the "enable"
attribute is "false". In the absence of a <variable-resource-names> attribute is "false". In the absence of a <variable-resource-names>
element for a Kind using the USER-CHAIN-ACL access policy (see element for a Kind using the USER-CHAIN-ACL access policy (see
Section 6.6), implementors SHOULD assume this default value. Section 6.6), implementors SHOULD assume this default value.
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. In It is of type xsd:string and interpreted as a regular expression
this regular expression, $USER and $DOMAIN are used as variables for according to "POSIX Extended Regular Expression" (see the
the corresponding parts of the string in the certificate username specifications in [IEEE-Posix]). In this regular expression, $USER
field (with $USER preceding and $DOMAIN succeeding the '@'). Both and $DOMAIN are used as variables for the corresponding parts of the
variables MUST be present in any given pattern definition. If no string in the certificate user name field (with $USER preceding and
pattern is defined for a Kind or the "enabled" attribute is false, $DOMAIN succeeding the '@'). Both variables MUST be present in any
allowable Resource Names are restricted to the username of the signer given pattern definition. If no pattern is defined for a Kind or the
for Shared Resource. "enabled" attribute is false, allowable Resource Names are restricted
to the username of the signer for Shared Resource.
The Relax NG Grammar for the Variable Resource Names Extension reads: 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 {
skipping to change at page 15, line 13 skipping to change at page 15, line 13
steps succeed. In this case, the creator of the data value of the steps succeed. In this case, the creator of the data value of the
Shared Resource is an Authorized Peer. Shared Resource is an Authorized Peer.
Note that the ACL validation procedure can be omitted whenever the Note that the ACL validation procedure can be omitted whenever the
creator of data at a Shared Resource is the Resource Owner itself. creator of data at a Shared Resource is the Resource Owner itself.
The latter can be verified by its public key certificate as defined The latter can be verified by its public key certificate as defined
in Section 6.6. in Section 6.6.
6.4. Operations of Storing Peers 6.4. Operations of Storing Peers
Storing peers, i.e., peers at which Shared Resource and ACL are Storing peers at which Shared Resource and ACL are physically stored,
physically stored, are responsible for controlling storage attempts are responsible for controlling storage attempts to a Shared Resource
to a Shared Resource and its corresponding Access Control List. To and its corresponding Access Control List. To assert the USER-CHAIN-
assert the USER-CHAIN-ACL access policy (see Section 6.4), a storing ACL access policy (see Section 6.6), a storing peer MUST perform the
peer MUST perform the access validation procedure described in access validation procedure described in Section 6.3 on any incoming
Section 6.3 on any incoming store request using the most recent store request using the most recent Access Control List for every
Access Control List for every Kind that uses the USER-CHAIN-ACL Kind that uses the USER-CHAIN-ACL policy. It SHALL further ensure
policy. It SHALL further ensure that only the Resource Owner stores that only the Resource Owner stores new ACL root items for Shared
new ACL root items for Shared Resources. Resources.
6.5. Operations of Accessing Peers 6.5. Operations of Accessing Peers
Accessing peers, i.e., peers that fetch a Shared Resource, MAY Accessing peers, i.e., peers that fetch a Shared Resource, MAY
validate that the originator of a Shared Resource was authorized to validate that the originator of a Shared Resource was authorized to
store data at this Resource-ID by processing the corresponding ACL. store data at this Resource-ID by processing the corresponding ACL.
To enable an accessing peer to perform the access validation To enable an accessing peer to perform the access validation
procedure described in Section 6.3, it first needs to obtain the most procedure described in Section 6.3, it first needs to obtain the most
recent Access Control List in the following way. recent Access Control List in the following way.
skipping to change at page 17, line 5 skipping to change at page 17, line 5
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, additionally, the hashed Resource Name matches the Resource-ID. and, additionally, the hashed Resource Name matches the Resource-ID.
The Resource Name of the Kind to be stored MUST be taken from the 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. ACL 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.
Name: ACCESS-CONTROL-LIST Name: ACCESS-CONTROL-LIST
Kind IDs: The Resource Name for ACCESS-CONTROL-LIST Kind-ID is the Kind IDs: The Resource Name for ACCESS-CONTROL-LIST Kind-ID is the
Resource Name of the Kind that will be shared by using the ACCESS- Resource Name of the Kind that will be shared by using the ACCESS-
CONTROL-LIST Kind. CONTROL-LIST Kind.
skipping to change at page 19, line 7 skipping to change at page 19, line 7
8.3. Privacy Issues 8.3. Privacy Issues
All data stored in the Shared Resource is publicly readable, thus All data stored in the Shared Resource is publicly readable, thus
applications requiring privacy need to encrypt the data. The ACL applications requiring privacy need to encrypt the data. The ACL
needs to be stored unencrypted, thus the list members of a group needs to be stored unencrypted, thus the list members of a group
using a Shared Resource will always be publicly visible. using a Shared Resource will always be publicly visible.
9. IANA Considerations 9. IANA Considerations
TODO: register Kind-ID code point at the IANA 9.1. Access Control Policy
IANA shall register the following entry in the "RELOAD Access Control
Policies" Registry (cf., [I-D.ietf-p2psip-base]) to represent the
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
for this specification in the following list.]
+-------------------+----------+
| Kind | RFC |
+-------------------+----------+
| USER-CHAIN-ACL | RFC-AAAA |
+-------------------+----------+
9.2. Data Kind-ID
IANA shall register the following code point in the "RELOAD Data
Kind-ID" Registry (cf., [I-D.ietf-p2psip-base]) to represent the
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
specification in the following list.]
+----------------------+------------+----------+
| Kind | Kind-ID | RFC |
+----------------------+------------+----------+
| ACCESS-CONTROL-LIST | 17 | RFC-AAAA |
+----------------------+------------+----------+
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 and Mindstone. 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-22 (work in Base Protocol", draft-ietf-p2psip-base-25 (work in
progress), July 2012. progress), February 2013.
[IEEE-Posix]
"IEEE Standard for Information Technology - Portable
Operating System Interface (POSIX) - Part 2: Shell and
Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 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.
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., Willis, D., Shim, E., Matthews, P., 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-04 (work in progress),
October 2011. October 2011.
[I-D.knauf-p2psip-disco] [I-D.ietf-p2psip-disco]
Knauf, A., Hege, G., Schmidt, T., 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-knauf-p2psip-disco-05 (work in progress), May 2012. draft-ietf-p2psip-disco-00 (work in progress),
October 2012.
[I-D.ietf-p2psip-sip]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.,
Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD",
draft-ietf-p2psip-sip-08 (work in progress),
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-share-00:
1. Clarified use of identities in ACLs
2. Specified use of Posix regular expressions in configuration
document
3. Added IANA considerations
4. Editorial improvements
5. Updated References
The following changes have been made from version
draft-knauf-p2psip-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-share-01: draft-knauf-p2psip-share-01:
1. Simplified the ACL data structure in response to WG feedback 1. Simplified the ACL data structure in response to WG feedback
 End of changes. 25 change blocks. 
52 lines changed or deleted 116 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/