--- 1/draft-ietf-p2psip-share-06.txt 2015-11-09 09:15:05.974954061 -0800 +++ 2/draft-ietf-p2psip-share-07.txt 2015-11-09 09:15:06.014955010 -0800 @@ -1,22 +1,22 @@ P2PSIP Working Group A. Knauf Internet-Draft T. Schmidt, Ed. Intended status: Standards Track HAW Hamburg -Expires: December 19, 2015 G. Hege +Expires: May 12, 2016 G. Hege daviko GmbH M. Waehlisch link-lab & FU Berlin - June 17, 2015 + November 9, 2015 A Usage for Shared Resources in RELOAD (ShaRe) - draft-ietf-p2psip-share-06 + draft-ietf-p2psip-share-07 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. @@ -32,21 +32,21 @@ 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 December 19, 2015. + This Internet-Draft will expire on May 12, 2016. Copyright Notice Copyright (c) 2015 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 @@ -78,26 +78,25 @@ 6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . 14 7. ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . 17 9.3. XML Name Space Registration . . . . . . . . . . . . . . . 17 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 - 11.2. Informative References . . . . . . . . . . . . . . . . . 18 - Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 10.2. Informative References . . . . . . . . . . . . . . . . . 18 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction [RFC6940] defines the base protocol for REsource LOcation And Discovery (RELOAD) that allows for application-specific extensions by Usages. The present document defines such 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 @@ -220,21 +219,21 @@ 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. + stored data. Thus data access is bound to the unique ID holder. If the data model of the Shared Resource is an array, each Authorized 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 the stored data 2. Take the least significant 24 bits of that Node-ID @@ -390,50 +389,50 @@ (see Section 7.3 in [RFC6940]). The specifications in this document scheme adhere to this paradigm, 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 a Resource Name with a variable substring that still matches the user name in the certificate using a pattern defined in the overlay configuration document. Thus despite being variable, an allowable Resource Name remains tied to the Owner's certificate. A sample pattern might be formed as follows. Example Pattern: - .*-conf-\$USER@\$DOMAIN + .*-conf-$USER@$DOMAIN When defining the pattern, care must be taken to avoid conflicts 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 the resources of the longer-named peer by choosing the variable part of a Resource Name to contain the entire longer username. This problem can easily be mitigated by delimiting the variable part of 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 Example). 5.2. Data Structure This section defines the optional ResourceNameExtension structure for every Kind that uses the USER-CHAIN-ACL access control policy. - enum { pattern (1), - (255)} ResourceNameType; + enum { pattern(1), (255)} ResourceNameType; struct { ResourceNameType type; uint16 length; + select(type) { case pattern: opaque resource_name<0..2^16-1>; /* Types can be extended */ - } - } ResourceNameExtension + }; + } ResourceNameExtension; The content of the ResourceNameExtension consist of length: This field contains the length of the remaining data structure. It is only used to allow for further extensions to this data structure. The content of the rest of the data structure depends of the ResourceNameType. Currently, the only defined type is "pattern". @@ -450,21 +449,21 @@ This section extends the overlay configuration document by defining 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 element serves as a container for one or multiple 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 resource names for this Kind. The default value of the "enable" attribute is "false". In the absence of a element for a Kind using the USER-CHAIN-ACL access policy (see Section 6.6), implementors SHOULD assume this default value. 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 @@ -472,33 +471,33 @@ 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 "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: - + # VARIABLE RESOURCE URN SUB-NAMESPACE namespace share = "urn:ietf:params:xml:ns:p2p:config-base:share" - + # VARIABLE RESOURCE NAMES ELEMENT kind-parameter &= element share:variable-resource-names { - attribute enable { xsd:boolean } + attribute enable { xsd:boolean }, - + # PATTERN ELEMENT - element pattern { xsd:string }* + element share:pattern { xsd:string }* }? 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 initiated by the Resource Owner. A Resource Owner can share RELOAD Kinds by using the following procedure. @@ -536,27 +535,27 @@ 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 Write permissions are revoked by storing a non-existent value - [RFC6940] at the corresponding item of the Access Control List. - Revoking a permission automatically invalidates all delegations - performed by that user including all subsequent delegations. This - allows to invalidate entire subtrees of the delegations tree with - only a single operation. Overwriting the root item with a non- - existent value of an Access List invalidates the entire delegations - tree. + (see[RFC6940] Section 7.2.1) at the corresponding item of the Access + Control List. Revoking a permission automatically invalidates all + delegations performed by that user including all subsequent + delegations. This allows to invalidate entire subtrees of the + delegations tree with only a single operation. Overwriting the root + item with a non-existent value of an Access List invalidates the + entire delegations tree. An existing ACL item MUST only be overwritten by the user who initially stored the corresponding entry, or by the Resource Owner that is allowed to overwrite all ACL items for revoking write access. 6.3. Validating Write Access through an ACL Access Control Lists are used to transparently validate authorization of peers for writing a data value at a Shared Resource. Thereby it is assumed that the validating peer is in possession of the complete @@ -625,21 +624,21 @@ Peers can cache previously fetched Access Control Lists up to the maximum lifetime of an individual item. Since stored values could have been modified or invalidated prior to their expiration, an accessing peer SHOULD use a Stat request to check for updates prior to using the data cache. 6.6. USER-CHAIN-ACL Access Policy This document specifies an additional access control policy to the - RELOAD base draft [RFC6940]. The USER-CHAIN-ACL policy allows + RELOAD base document [RFC6940]. The USER-CHAIN-ACL policy allows Authorized Peers to write a Shared Resource, even though they do not own the corresponding certificate. Additionally, the USER-CHAIN-ACL allows the storage of Kinds with a variable resource name that are following one of the specified naming pattern. Hence, on an inbound store request on a Kind that uses the USER-CHAIN-ACL access policy, the following rules MUST 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 @@ -746,142 +745,79 @@ 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) - Emmanuel Baccelli, 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. +10. References -11. References -11.1. Normative References +10.1. Normative References [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 - Requirement Levels", BCP 14, RFC 2119, March 1997. + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, - January 2004. + DOI 10.17487/RFC3688, January 2004, + . - [RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and - H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) - Base Protocol", RFC 6940, January 2014. + [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., + and H. Schulzrinne, "REsource LOcation And Discovery + (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, + January 2014, . -11.2. Informative References +10.2. Informative References [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts-07 (work in progress), May 2015. [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-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-14 (work in progress), January 2015. + draft-ietf-p2psip-sip-15 (work in progress), July 2015. [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-02: - - 1. Updated References - 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: - - 1. Editorial improvements - - 2. Updated References - - 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: - - 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 - - 5. Added mechanism for isolating stored data to prevent race - conditions while concurrent storing + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, . - 6. XML Extension for variable resource names uses its own namespace +Acknowledgments - 7. Many editorial improvements + 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) + Emmanuel Baccelli, 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. Authors' Addresses - Alexander Knauf HAW Hamburg Berliner Tor 7 Hamburg D-20099 Germany Phone: +4940428758067 Email: alexanderknauf@gmail.com Thomas C. Schmidt @@ -884,28 +820,29 @@ Phone: +4940428758067 Email: alexanderknauf@gmail.com Thomas C. Schmidt HAW Hamburg Berliner Tor 7 Hamburg D-20099 Germany Email: t.schmidt@haw-hamburg.de - URI: http://inet.cpt.haw-hamburg.de/members/schmidt + URI: http://inet.haw-hamburg.de/members/schmidt Gabriel Hege daviko GmbH - Am Borsigturm 50 - Berlin D-13507 + Schillerstr. 107 + Berlin D-10625 Germany Phone: +493043004344 Email: hege@daviko.com + 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