--- 1/draft-ietf-p2psip-share-01.txt 2013-08-27 03:14:21.943694650 -0700 +++ 2/draft-ietf-p2psip-share-02.txt 2013-08-27 03:14:21.987695768 -0700 @@ -1,102 +1,104 @@ P2PSIP Working Group A. Knauf -Internet-Draft T C. Schmidt, Ed. +Internet-Draft T. Schmidt, Ed. Intended status: Standards Track HAW Hamburg -Expires: August 28, 2013 G. Hege +Expires: February 28, 2014 G. Hege daviko GmbH M. Waehlisch link-lab & FU Berlin - February 24, 2013 + August 27, 2013 A Usage for Shared Resources in RELOAD (ShaRe) - draft-ietf-p2psip-share-01 + draft-ietf-p2psip-share-02 Abstract This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 28, 2013. + This Internet-Draft will expire on February 28, 2014. Copyright Notice Copyright (c) 2013 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. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Shared Resources in RELOAD . . . . . . . . . . . . . . . . . . 5 - 3.1. Mechanisms for Isolating Stored Data . . . . . . . . . . . 6 - 4. Access Control List Definition . . . . . . . . . . . . . . . . 7 - 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 8 - 5. Extension for Variable Resource Names . . . . . . . . . . . . 10 - 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 10 - 5.3. Overlay Configuration Document Extension . . . . . . . . . 11 - 6. Access Control to Shared Resources . . . . . . . . . . . . . . 13 - 6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 13 - 6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 14 - 6.3. Validating Write Access through an ACL . . . . . . . . . . 14 - 6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 15 - 6.5. Operations of Accessing Peers . . . . . . . . . . . . . . 15 - 6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . . 15 - 7. ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . . 17 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 18 - 8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 18 - 8.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 18 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 9.1. Access Control Policy . . . . . . . . . . . . . . . . . . 19 - 9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 19 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 - Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + 3. Shared Resources in RELOAD . . . . . . . . . . . . . . . . . 4 + 3.1. Mechanisms for Isolating Stored Data . . . . . . . . . . 5 + 4. Access Control List Definition . . . . . . . . . . . . . . . 6 + 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 8 + 5. Extension for Variable Resource Names . . . . . . . . . . . . 9 + 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 9 + 5.3. Overlay Configuration Document Extension . . . . . . . . 10 + 6. Access Control to Shared Resources . . . . . . . . . . . . . 11 + 6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 11 + 6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 12 + 6.3. Validating Write Access through an ACL . . . . . . . . . 12 + 6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 13 + 6.5. Operations of Accessing Peers . . . . . . . . . . . . . . 14 + 6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . 14 + 7. ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . . 15 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 15 + 8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 16 + 8.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 16 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 9.1. Access Control Policy . . . . . . . . . . . . . . . . . . 16 + 9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 16 + 9.3. XML Name Space Registration . . . . . . . . . . . . . . . 17 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 11.2. Informative References . . . . . . . . . . . . . . . . . 18 + + Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction This document defines a RELOAD Usage for managing shared write access to RELOAD Resources and a mechanism to store Resources with a variable name. The Usage for Shared Resources in RELOAD (ShaRe) enables overlay users to share their exclusive write access to specific Resource/Kind pairs with others. Shared Resources form a basic primitive for enabling various coordination and notification schemes among distributed peers. Write permission is controlled by @@ -199,30 +201,30 @@ Section 3.1. Access Control Policy: To ensure write access to Shared Resource by Authorized Peers, each Usage MUST use the USER-CHAIN-ACL access policy as described in Section 6.6. Resource Name Extension: To enable Shared Resources to be stored using a variable resource name, this document defines an optional ResourceNameExtension structure. It contains the Resource Name of the Kind data to be stored and allows any receiver of a shared - data to validate whether the Resource Name hashes to the - Resource-ID. The ResourceNameExtension is made optional by - configuration. The ResourceNameExtension field is only present in - the Kind data structure when configured in the corresponding kind- - block of the overlay configuration document (for more details see - Section 5.3). If the configuration allows variable resource - names, a Kind using the USER-CHAIN-ACL policy MUST use the - ResourceNameExtension as initial field within the Kind data - structure definition. Otherwise the Kind data structure does not - contain the ResourceNameExtension structure. + data to validate whether the Resource Name hashes to the Resource- + ID. The ResourceNameExtension is made optional by configuration. + The ResourceNameExtension field is only present in the Kind data + structure when configured in the corresponding kind-block of the + overlay configuration document (for more details see Section 5.3). + If the configuration allows variable resource names, a Kind using + the USER-CHAIN-ACL policy MUST use the ResourceNameExtension as + initial field within the Kind data structure definition. + Otherwise the Kind data structure does not contain the + ResourceNameExtension structure. 3.1. Mechanisms for Isolating Stored Data This section defines mechanisms to avoid race conditions while concurrently writing an array or dictionary of a Shared Resource. If a dictionary is used in the Shared Resource, the dictionary key MUST be the Node-ID of the certificate that will be used to sign the stored data. Thus data access is bound to the unique ID-holder. @@ -238,22 +240,23 @@ 3. Concatenate an 8 bit long short individual index value to those 24 bit of the Node-ID The resulting 32 bits long integer MUST be used as the index for storing an array entry in a Shared Resource. The 8 bit individual index can be incremented individually for further array entries and allows for 256 distinct entries per Peer. The mechanism to create the array index is related to the pseudo- - random algorithm to generate an SSRC identifier in RTP, see Section - 8.1 in [RFC3550] for calculating the probability of a collision. + random algorithm to generate an SSRC identifier in RTP, see + Section 8.1 in [RFC3550] for calculating the probability of a + collision. 4. Access Control List Definition 4.1. Overview An Access Control List (ACL) is a (self-managed) shared resource that contains a list of AccessControlListItem structures as defined in Section 4.2. Each entry delegates write access for a specific Kind data to a single RELOAD user. An ACL enables the RELOAD user who is authorized to write a specific Resource-ID to delegate his exclusive @@ -463,40 +465,42 @@ A element MUST be present if the "enabled" attribute of its parent element is set to true. Each element defines a pattern for constructing extended resource names for a single Kind. It is of type xsd:string and interpreted as a regular expression according to "POSIX Extended Regular Expression" (see the specifications in [IEEE-Posix]). In this regular expression, $USER and $DOMAIN are used as variables for the corresponding parts of the string in the certificate user name field (with $USER preceding and $DOMAIN succeeding the '@'). Both variables MUST be present in any given pattern definition. If no pattern is defined for a Kind or the - "enabled" attribute is false, allowable Resource Names are restricted + "enable" 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: namespace share = "urn:ietf:params:xml:ns:p2p:config-base:share" kind-parameter &= element share:variable-resource-names { attribute enable { xsd:boolean } element pattern { xsd:string }* }? + Figure 2 + 6. Access Control to Shared Resources 6.1. Granting Write Access Write access to a Kind that is intended to be shared with other RELOAD users can solely be issued by the Resource Owner. A Resource Owner can share RELOAD Kinds by using the following procedure. o The Resource Owner stores an ACL root item at the Resource-ID of the Shared Resource. The root item contains the resource name @@ -511,28 +515,28 @@ the Authorized Peer and the Kind-Id of the Shared Resource. Optionally, the Resource Owner sets the "ad" to 1 (the default equals 0) to enable the Authorized Peer to further delegate write access. Each succeeding ACL item created by the Resource Owner can be stored in the numerical order of the array index starting with the index of the root item incremented by one. An Authorized Peer with delegation allowance ("ad"=1) can extend the access to an existing Shared Resource as follows. - o An Authorized Peer can store additional ACL items at the - Resource-ID of the Shared Resource. These ACL items contain the - resource name extension field, the username of the newly - Authorized Peer, and the Kind-Id of the Shared Resource. - Optionally, the "ad" flag is set to 1 for allowing the Authorized - Peer to further delegate write access. The array index MUST be - generated as described in Section 3.1. Each succeeding ACL item - can be stored in the numerical order of the array index. + o An Authorized Peer can store additional ACL items at the Resource- + ID of the Shared Resource. These ACL items contain the resource + name extension field, the username of the newly Authorized Peer, + and the Kind-Id of the Shared Resource. Optionally, the "ad" flag + is set to 1 for allowing the Authorized Peer to further delegate + write access. The array index MUST be generated as described in + Section 3.1. Each succeeding ACL item can be stored in the + numerical order of the array index. A store request by an Authorized Peer that attempts to overwrite any ACL item signed by another Peer is unauthorized and causes an Error_Forbidden response from the Storing Peer. Such access conflicts could be caused by an array index collision. However, the probability of a collision of two or more identical array indices will be negligibly low using the mechanism for isolating stored data (see Section 3.1) 6.2. Revoking Write Access @@ -634,23 +636,23 @@ inbound store request on a Kind that uses the USER-CHAIN-ACL access policy, the following rules MUST be applied: In the USER-CHAIN-ACL policy, a given value MUST be written or overwritten, if either one of USER-MATCH or USER-NODE-MATCH (mandatory if the data model is dictionary) access policies of the base document [I-D.ietf-p2psip-base] applies. Otherwise, the value MUST be written if the certificate of the signer contains a username that matches to one of the variable resource name - pattern (c.f. Section 5) specified in the configuration document - and, additionally, the hashed Resource Name matches the Resource-ID. - The Resource Name of the Kind to be stored MUST be taken from the + pattern (c.f. Section 5) specified in the configuration document and, + additionally, the hashed Resource Name matches the Resource-ID. The + Resource Name of the Kind to be stored MUST be taken from the mandatory ResourceNameExtension field in the corresponding Kind data structure. Otherwise, the value MUST be written if the ACL validation procedure described in Section 6.3 has been successfully applied. 7. ACCESS-CONTROL-LIST Kind Definition This section defines the ACCESS-CONTROL-LIST Kind previously described in this document. @@ -730,111 +732,131 @@ 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 | +----------------------+------------+----------+ +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 This work was stimulated by fruitful discussions in the P2PSIP working group and SAM research group. We would like to thank all active members for constructive thoughts and feedback. In particular, the authors would like to thank (in alphabetical order) Lothar Grimm, Cullen Jennings, Peter Musgrave, Joerg Ott, Marc Petit- Huguenin, Peter Pogrzeba, and Jan Seedorf. This work was partly funded by the German Federal Ministry of Education and Research, projects HAMcast, Mindstone, and SAFEST. 11. References 11.1. Normative References [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) - Base Protocol", draft-ietf-p2psip-base-25 (work in + Base Protocol", draft-ietf-p2psip-base-26 (work in progress), February 2013. [IEEE-Posix] - "IEEE Standard for Information Technology - Portable + , "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. + 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 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 [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", - draft-ietf-p2psip-concepts-04 (work in progress), - October 2011. + draft-ietf-p2psip-concepts-05 (work in progress), July + 2013. [I-D.ietf-p2psip-disco] Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A RELOAD Usage for Distributed Conference Control (DisCo)", - draft-ietf-p2psip-disco-00 (work in progress), - October 2012. + draft-ietf-p2psip-disco-02 (work in progress), July 2013. [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. + draft-ietf-p2psip-sip-11 (work in progress), July 2013. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. Appendix A. Change Log - The following changes have been made from version - draft-ietf-p2psio-share-00: + The following changes have been made from version draft-ietf-p2psio- + 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 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: + The following changes have been made from version draft-knauf-p2psip- + share-02: 1. Editorial improvements 2. Updated References - The following changes have been made from version - draft-knauf-p2psip-share-01: + The following changes have been made from version draft-knauf-p2psip- + share-01: 1. Simplified the ACL data structure in response to WG feedback 2. Added ResourceNameExtension data structure to simplify the use of variable resource names 3. Restructured document 4. Many editorial improvements - The following changes have been made from version - draft-knauf-p2psip-share-00: + The following changes have been made from version draft-knauf-p2psip- + share-00: 1. Integrated the USER-PATTERN-MATCH access policy into USER-CHAIN- ACL 2. Access Control List Kind uses USER-CHAIN-ACL exclusively 3. Resources to be shared use USER-CHAIN-ACL exclusively 4. More precise specification of mandatory User_name and Resource_name fields for Shared Resources @@ -840,48 +862,45 @@ Resource_name fields for Shared Resources 5. Added mechanism for isolating stored data to prevent race conditions while concurrent storing 6. XML Extension for variable resource names uses its own namespace 7. Many editorial improvements Authors' Addresses - Alexander Knauf HAW Hamburg Berliner Tor 7 Hamburg D-20099 Germany Phone: +4940428758067 Email: alexanderknauf@gmail.com - URI: Thomas C. Schmidt HAW Hamburg Berliner Tor 7 Hamburg D-20099 Germany Email: schmidt@informatik.haw-hamburg.de URI: http://inet.cpt.haw-hamburg.de/members/schmidt Gabriel Hege daviko GmbH Am Borsigturm 50 Berlin D-13507 Germany Phone: +493043004344 Email: hege@daviko.com - URI: Matthias Waehlisch link-lab & FU Berlin Hoenower Str. 35 Berlin D-10318 Germany Email: mw@link-lab.net URI: http://www.inf.fu-berlin.de/~waehl