One document matched: draft-petithuguenin-p2psip-access-control-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc compact="yes" ?>
<?rfc strict="no" ?>
<?rfc symrefs="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" docName="draft-petithuguenin-p2psip-access-control-00" ipr="noModificationTrust200902">
<front>
<title abbrev="Access Control Configuration">Configuration of Access Control Policy in REsource LOcation And Discovery (RELOAD) Base Protocol</title>
<author fullname="Marc Petit-Huguenin" initials="M.P.H" surname="Petit-Huguenin">
<organization>Stonyfish, Inc.</organization>
<address>
<email>petithug@acm.org</email>
</address>
</author>
<date day="6" month="March" year="2011"/>
<abstract>
<t>
This document describes an extension to the REsource LOcation And Discovery (RELOAD) base protocol to distribute the code of new Access Control Policies without having to upgrade the RELOAD implementations in an overlay.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The RELOAD base protocol defines an Access Control Policy as "defin[ing] whether a request from a given node to operate on a given value should succeed or fail."
The paragraph continues saying that "[i]t is anticipated that only a small number of generic access control policies are required", but there is indications that this assumption will not hold.
On all the RELOAD Usages defined in other documents than the RELOAD base protocol, roughly 50% defines a new Access Control Policy.
</t>
<t>
The problem with a new Access Control Policy is that, because they are executed when a Store request is processed, they need to be implemented by all the peers, and so require an upgrade of the software.
This is something that is probably not possible in large overlays or on overlays using different implementations.
For this reason, this document proposes an extension to the RELOAD configuration document that permits to transport the code of a new Access Control Policy to each peer.
</t>
<t>
This extension defines a set of new elements that can be optionally added to a <kind> element in the configuration document.
The most important of this elements is the <access-control-code> element that contains JavaScript code that will be called for each StoredData object in a StoreReq processed by a peer.
The code receives four parameters, corresponding to the Resource-ID, Signature, Kind and StoredDataValue of the value to store.
The code returns true or false to signal to the implementation if the request should succeed or fail.
</t>
<t>For example the USER-MATCH Access Control Policy defined in the base protocol could be redefined by inserting the following code in an <access-control-code> element:</t>
<t>
<figure>
<artwork><![CDATA[return resource.equals(signature.user_name);]]></artwork>
</figure>
</t>
<t>The <kind> parameters are also passed to the code, so the NODE-MULTIPLE Access Control Policy could be implemented like this:</t>
<t>
<figure>
<artwork><![CDATA[for (int i = 0; i < kind.params['max-node-multiple']; i++) {
if (resource.equals(signature.node_id, i)) return true;
}
return false;]]></artwork>
</figure>
</t>
<t>
Some Access Control Policies requires access to the content of the value to be stored.
To permit this a <data-stored> element can be added to describe the content of the value.
This description uses the same syntax that is used in the RELOAD base protocol to describe the various messages and is automatically converted to a JavaScript object accessible from the Access Control Policy code.
For example <xref target="I-D.ietf-p2psip-service-discovery">ReDiR</xref> requires such mechanism so if the structure described in section 4.1. is copied in the <data-stored> element then the following code can be used to define the NODE-ID-MATCH Access Control Policy:
</t>
<t>
<figure>
<artwork><![CDATA[return entry.key === signature.node_id
&& (!entry.exists
|| resource.equals(entry.value.data.namespace,
entry.value.data.level, entry.value.data.node);]]></artwork>
</figure>
</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
<section title="Processing an extended Kind">
<t>A peer receiving a <kind>, either by retrieving it from the configuration server or in a ConfigUpdateReq message, MUST verify the signature in the kind-signature element before executing the code.</t>
<t>
If the <access-control-code> element is present in the namespace allocated to this specification, and the Access Control Policy is not natively implemented, then the code inside the element MUST be called for each DataValue found in a received StoreReq for this Kind.
For each call to the code, the following JavaScript objects, properties and functions MUST be available:
</t>
<t>
<list style="hanging">
<t hangText="resource:">An opaque object representing the Resource-ID.</t>
<t hangText="resource.equals(Object...):">Returns true if hashing the concatenation of the arguments according to the mapping function of the overlay algorithm is equal to the Resource-ID.</t>
<t hangText="signature.user_name:">The rfc822Name stored in the certificate that was used to sign the request.</t>
<t hangText="signature.node_id:">The Node-ID stored in the certificate that was used to sign the request.</t>
<t hangText="kind.id:">The id of the Kind associated with the entry.</t>
<t hangText="kind.name:">The name of the Kind associated with the entry.</t>
<t hangText="kind.data_model:">The name of the Data Model associated with the entry.</t>
<t hangText="kind.access_control:">The name of the Access Control Policy associated with the entry.</t>
<t hangText="kind.params:">
An associative array containing the parameters of the Access Control Policy as specified in the configuration file.
<list style="hanging">
<t hangText="max-count:">The value of the max-count element in the configuration file.</t>
<t hangText="max-size:">The value of the max-size element in the configuration file.</t>
<t hangText="max-node-multiple:">
If the Access Control is MULTIPLE-NODE, contains the value of the max-node-multiple element in the configuration file.
If not, this property is undefined.
</t>
</list>
</t>
<t hangText="entry.index:">
If the Data Model is ARRAY, contains the index of the entry.
If not, this property is undefined.
</t>
<t hangText="entry.key:">
If the Data Model is DICTIONARY, contains the key of the entry.
If not, this property is undefined.
</t>
<t hangText="entry.storage_time:">A Date object containing the time for the storage.</t>
<t hangText="entry.lifetime:">A number that contain the validity for the data in seconds.</t>
<t hangText="entry.exist:">A boolean that indicates if the entry value exists.</t>
<t hangText="entry.value:">
If a <description> extension element is present in the <kind> element, then the content of this property is automatically generated from the definition.
If not, this property contains an opaque object that represent the whole data.
</t>
</list>
</t>
<t>If addition to the "max-count", "max-size" and eventually "max-node-multiple" properties in the kind.params associative array, any extension element in any namespace found in the <kind> element MUST be added to this array, using the element name as key and the content as value.</t>
<t>
The value returned by the code is evaluated to true or false, according to the JavaScript rules.
If the return value of one of the call to the code is evaluated to false, then the StoreReq fails, the state MUST be rolled back and an Error_Forbidden MUST be returned.
</t>
<t>
If the <data-stored> element is present in the namespace allocated to this specification, then its content MUST be parsed and converted in a way that will permit to parse the value in the DataValue structure and generate a JavaScript object with properties corresponding to each label.
The "value" attribute MUST be filled with the label of the statement inside the element that must be used as the root of the parsing.
Each statement in the content MUST be converted as follow:
</t>
<t>
<list style="hanging">
<t hangText="Vectors:">
Variable-length vectors are converted to arrays.
</t>
<t hangText="Numbers:">uint8, uint16, uint24, uint32, uint64, and uint128 are converted to a JavaScript number.</t>
<t hangText="Enumerateds:">TBD</t>
<t hangText="Structures:">Structures are converted to an object, which each fields being converted to a property of same name.</t>
<t hangText="Variants:">TBD</t>
</list>
</t>
<t>If the <data-stored> element is not present, the value in the DataValue structure will still be passed as an opaque object to the code.</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>No IANA considerations.</t>
</section>
<section title="Acknowledgements">
<t>This document was written with the xml2rfc tool described in <xref target="RFC2629"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t>
</list>
</t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT"/>
<format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML"/>
<format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML"/>
</reference>
<reference anchor="I-D.ietf-p2psip-base">
<front>
<title>REsource LOcation And Discovery (RELOAD) Base Protocol</title>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization/>
</author>
<author fullname="Bruce Lowekamp" initials="B" surname="Lowekamp">
<organization/>
</author>
<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
<organization/>
</author>
<author fullname="Salman Baset" initials="S" surname="Baset">
<organization/>
</author>
<author fullname="Henning Schulzrinne" initials="H" surname="Schulzrinne">
<organization/>
</author>
<date day="10" month="November" year="2010"/>
<abstract>
<t>This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. Legal THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-base-12"/>
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-12.txt" type="TXT"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2629">
<front>
<title>Writing I-Ds and RFCs using XML</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Invisible Worlds, Inc.</organization>
<address>
<postal>
<street>660 York Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country>
</postal>
<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri>
</address>
</author>
<date month="June" year="1999"/>
<area>General</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2629"/>
<format octets="48677" target="http://www.rfc-editor.org/rfc/rfc2629.txt" type="TXT"/>
<format octets="71741" target="http://xml.resource.org/public/rfc/html/rfc2629.html" type="HTML"/>
<format octets="53481" target="http://xml.resource.org/public/rfc/xml/rfc2629.xml" type="XML"/>
</reference>
<reference anchor="I-D.ietf-p2psip-service-discovery">
<front>
<title>Service Discovery Usage for REsource LOcation And Discovery (RELOAD)</title>
<author fullname="Jouni Maenpaa" initials="J" surname="Maenpaa">
<organization/>
</author>
<author fullname="Gonzalo Camarillo" initials="G" surname="Camarillo">
<organization/>
</author>
<date day="7" month="January" year="2011"/>
<abstract>
<t>REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as part of the base protocol. This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism used in OpenDHT can be applied to RELOAD overlays to provide a generic service discovery mechanism.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-service-discovery-02"/>
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-service-discovery-02.txt" type="TXT"/>
</reference>
<reference anchor="I-D.knauf-p2psip-disco">
<front>
<title>A RELOAD Usage for Distributed Conference Control (DisCo)</title>
<author fullname="Alexander Knauf" initials="A" surname="Knauf">
<organization/>
</author>
<author fullname="Gabriel Hege" initials="G" surname="Hege">
<organization/>
</author>
<author fullname="Thomas Schmidt" initials="T" surname="Schmidt">
<organization/>
</author>
<author fullname="Matthias Waehlisch" initials="M" surname="Waehlisch">
<organization/>
</author>
<date day="30" month="December" year="2010"/>
<abstract>
<t>This document defines a RELOAD Usage for Distributed Conference Control (DisCo) with SIP. DisCo preserves conference addressing through a single SIP URI by splitting its semantic of identifier and locator using a new Kind data structure. Conference members are enabled to select conference controllers based on proximity awareness and to recover from failures of individual resource instances. DisCo proposes call delegation to balance the load at focus peers. The document also introduces methods to establish security and trust for a shared resource access, as well as for compatibility with conference unaware clients.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-knauf-p2psip-disco-01"/>
<format target="http://www.ietf.org/internet-drafts/draft-knauf-p2psip-disco-01.txt" type="TXT"/>
</reference>
</references>
<section title="Examples">
<section title="Standard Access Control Policies">
<t>This section shows the JavaScript code that could be used to implement the standard Access Control Policies defined in <xref target="I-D.ietf-p2psip-base"/>.</t>
<section title="USER-MATCH">
<t>
<figure>
<artwork><![CDATA[return resource.equals(signature.user_name);]]></artwork>
</figure>
</t>
</section>
<section title="NODE-MATCH">
<t>
<figure>
<artwork><![CDATA[return resource.equals(signature.node_id);]]></artwork>
</figure>
</t>
</section>
<section title="USER-NODE-MATCH">
<t>
<figure>
<artwork><![CDATA[return resource.equals(signature.user_name)
&& entry.key === signature.node_id;]]></artwork>
</figure>
</t>
</section>
<section title="NODE-MULTIPLE">
<t>
<figure>
<artwork><![CDATA[for (int i = 0; i < kind.params['max-node-multiple']; i++) {
if (resource.equals(signature.node_id, i)) return true;
}
return false;]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Service Discovery Usage">
<t>
<xref target="I-D.ietf-p2psip-service-discovery"/> defines a specific Access Control Policy (NODE-ID-MATCH) that need to access the content of the entry to be written.
If implemented as specified by this document, the <kind> element would look something like this:
</t>
<t>
<figure>
<artwork><![CDATA[<kind name='REDIR'
xmlns:acp='http://implementers.org/access-control-policy'>
<data-model>DICTIONARY</data-model>
<access-control>NODE-ID-MATCH</access-control>
<max-count>100</max-count>
<max-size>60</max-size>
<acp:access-control-code>
return entry.key === signature.node_id
&& true /* placeholder */
&& (!entry.exists
|| (resource.equals(entry.value.data.namespace,
entry.value.data.level, entry.value.data.node);
</acp:access-control-code>
<acp:data-stored value='RedirServiceProvider'>
struct {
NodeId serviceProvider;
opaque namespace<0..2^16-1>;
uint16 level;
uint16 node;
/* This type can be extended */
} RedirServiceProviderData;
struct {
uint16 length;
RedirServiceProviderData data;
} RedirServiceProvider;
</acp:data-stored>
</kind>]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Release notes">
<t>This section must be removed before publication as an RFC.</t>
<section title="TODO List">
<t>
<list style="symbols">
<t>Need to present the complete list of certificates for the <xref target="I-D.knauf-p2psip-disco">DisCo</xref> Usage USER-CHAIN-MATCH.</t>
<t>Add ABNF for the presentation language.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:37:40 |