Configuration of Access Control Policy in REsource LOcation And Discovery (RELOAD) Base Protocol(Unaffiliated)petithug@acm.orgThis 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.
The RELOAD base protocol specifies 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.
The problem with a new Access Control Policy is that, because it is executed when a Store request is processed, it needs to be implemented by all the peers and so requires 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.
This extension defines a new element <access-control-code> that can be optionally added to a <configuration> element in the configuration document.
The <access-control-code> element contains ECMAScript code that will be called for each StoredData object that use this access control policy.
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.
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:The <kind> parameters are also passed to the code, so the NODE-MULTIPLE Access Control Policy could be implemented like this: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 .
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are appropriate when valid exceptions to a general requirement are known to exist or appear to exist, and it is infeasible or impractical to enumerate all of them.
However, they should not be interpreted as permitting implementors to fail to implement the general requirement when such failure would result in interoperability failure.
A peer receiving a configuration document containing one or more <access-control-code> elements, either by retrieving it from the configuration server or in a ConfigUpdateReq message, MUST reject this configuration if is not is not signed or if the signature verification fails.The Compact Relax NG Grammar for this element is:The "name" attribute defines the access control policy and can then be used in a <kind> element as if it was defined by IANA.
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 a Kind that is defined with this access control policy.
The content of the <access-control-code> element MUST be decoded using the base64 encoding, uncompressed using gzip then converted to characters using UTF-8.
<access-control-code> elements that are not encoded using UTF-8, compressed with gzip or finally converted to the base64 format MUST be ignored.
For each call to the code, the following ECMAScript objects, properties and functions MUST be available:
The name of the overlay, as a String object.The overlay algorithm, as a String object.The length of a NodeId in bytes, as a Number object.An array of kinds (with the same definition than the kind object), indexed by id and eventually by name.
A function that evaluates the first parameter as an XPath expression against the configuration element, and returns the result as a String object.
The second parameter must contain a namespace prefix and the third parameter must contain a namespace.
The id of the Kind associated with the entry, as a Number object.
If the Kind associated with the entry is registered by IANA, contains the name as a String object.
If not, this property is undefined.
The name of the Data Model associated with the entry, as a String object.The name of the Access Control Policy associated with the entry, as a String object.The value of the max-count element in the configuration file, as a Number object.The value of the max-size element in the configuration file as a Number object.
If the Access Control is MULTIPLE-NODE, contains the value of the max-node-multiple element in the configuration file, as a Number object.
If not, this property is undefined.
A function that evaluates the first parameter as an XPath expression against the kind element, and returns the result as a String object.
The second parameter must contain a namespace prefix and the third parameter must contain a namespace.
An opaque object representing the Resource-ID, as an array of bytes.
An array of arrays of entry objects, with the first array level indexed by Kind-Id and kind names, and the second level indexed by index, key or nothing, depending on the data model of the kind.
This permits to retrieve all the values of all Kinds stored at the same Resource-ID than the entry currently processed.
A function that returns true if hashing the concatenation of the arguments according to the mapping function of the overlay algorithm is equal to the Resource-ID.
Each argument is an array of bytes.
If the Data Model is ARRAY, contains the index of the entry, as a Number object.
If not, this property is undefined.
If the Data Model is DICTIONARY, contains the key of the entry, as an array of bytes.
If not, this property is undefined.
The date and time used to store the entry, as a Date object.The validity for the entry in seconds, as a Number object.Indicates if the entry value exists, as Boolean object.This property contains an opaque object that represents the whole data, as an array of bytes.The rfc822Name stored in the certificate that was used to sign the request, as a String object.The Node-ID stored in the certificate that was used to sign the request, as an array of bytes.
The properties SHOULD NOT be modifiable or deletable and if they are, modifying or deleting them MUST NOT modify or delete the equivalent internal values (in other words, the code cannot be used to modify the elements that will be stored).
The value returned by the code is evaluated to true or false, according to the ECMAScript 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.
Because the configuration document containing the ECMAScript code is under the responsability of the same entity that will sign it, using a scripting language does not introduce any additional risk if the RELOAD implementers follow the rules in this document (no side effect when modifying the parameters, only base classes of ECMAScript implemented, etc...).
It is even possible to deal with less than perfect implementations as long as they do not accept a configuration file that is not signed correctly.
One way for the signer to enforce this would be to deliberately send in a ConfigUpdate an incorrectly signed version of the configuration file and blacklist all the nodes that accepted it in a newly issued configuration file.
By permitting multiple overlay implementations to interoperate inside one overlay, RELOAD helps build overlays that are not only resistant to hardware or communication failures, but also to programmer errors.
Distributing the access control policy code inside the configuration document reintroduces this single point of failure.
To mitigate this problem, new access control policies should be implemented natively as soon as possible, but if all implementations uses the script as a blueprint for the native code, an hidden bug can be duplicated.
This is why developers should implement new access control policies from the normative text instead of using the code.
That is anyway probably not legal under most copyright laws but to help developers do the right thing the code in the configuration is obfuscated by compressing and encoding it as a base64 character string.
If this document is accepted as a standard track document this section will request an URN in the "XML Namespaces" class of the "IETF XML Registry" from IANA.
Until this is done, implementions should use the following URN:
http://implementers.org/access-controlThis document was written with the xml2rfc tool described in .GZIP file format specification version 4.3Aladdin Enterprises203 Santa Margarita Ave.Menlo ParkCA94025US+1 415 322 0103+1 415 322 1734ghost@aladdin.comgzip@prep.ai.mit.edumadler@alumni.caltech.edughost@aladdin.comrandeg@alumni.rpi.eduThis specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. The format includes a cyclic redundancy check value for detecting data corruption. The format presently uses the DEFLATE method of compression but can be easily extended to use other compression methods. The format can be implemented readily in a manner not covered by patents.Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
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:
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.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
The Base16, Base32, and Base64 Data EncodingsThis document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]REsource LOcation And Discovery (RELOAD) Base ProtocolNOTE: This version address some, but not all, of the comments received during IESG review. The authors are still working on addressing many more of the comments but as the draft deadline for IETF 82 arrives, this represents the modification made so far. 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.ECMAScript Language Specification 3rd EditionWriting I-Ds and RFCs using XMLInvisible Worlds, Inc.660 York StreetSan FranciscoCA94110US+1 415 695 3975mrose@not.invisible.nethttp://invisible.net/
General
RFCRequest for CommentsI-DInternet-DraftXMLExtensible Markup LanguageThis 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.Service Discovery Usage for REsource LOcation And Discovery (RELOAD)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.A Usage of Resource Location and Discovery (RELOAD) for Public Switched Telephone Network (PSTN) VerificationVerification Involving PSTN Reachability (VIPR) is a technique for inter-domain SIP federation. VIPR makes use of the RELOAD protocol to store unverified mappings from phone numbers to RELOAD nodes, with whom a validation process can be run. This document defines the usage of RELOAD for this purpose.A Usage for Shared Resources in RELOAD (ShaRe)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.This section shows the ECMAScript code that could be used to implement the standard Access Control Policies defined in .[[Note that base-15 still does not state exactly the length of i when concatenated in the hash input]] 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 ECMAScript code would look something like this:
Note that the code for the BigNumber object was removed from this example, as the licensing terms are unclear.
The code is available at .
defines a specific Access Control Policy.
If implemented as specified by this document, the ECMAScript code would look something like this:
defines a new Access Control Policies, USER-CHAIN-ACL.
If implemented as specified by this document, the ECMAScript code would look something like this:
[[Note: the code is incomplete]]This section must be removed before publication as an RFC.Added a kinds array on the configuration object.Added an entries array on the resource object for retrieve all the entries of all kinds stored at the same Resource-Id.the signer property is now an attribute of entry.Added initial code for ShaRe policy.
Moved the access-control-code element fom the kind element to the configuration element so the code can be shared between kinds.
A new "name" attribute is used to name the access control policy.
Added configuration object to pass information about the whole overlay.Added evaluate functions to retrieve extensions parameters.Renamed the signature attribute to signer.Filled Security section.Added temporary namespace to IANA section.The content of the access-control-code is now UTF-8 encoded, compressed with gzip and converted back to characters with base64.Fixed the implementation of the service discovery access control policy.Added code for VIPR policy.Made clear that an unsigned kind with this extension must be rejected.
Removed the kind.params array, and converted the max-count, max-size and max-node-multiple as Number objects.
Fixed the examples.
Removed the parsing of extensions in the kind element.
The former system did not work with namespaces or attributes, and the right solution (xpath) is probably too complex.
The value of the parameters can still be manually mirrored in the script, so there is perhaps no need for the added complexity.
Also fixed the examples.
Reference draft-p2psip-share instance of draft-p2psip-disco.Added a "Running Code Considerations" section that contain the reference to the reference implementation and script tester.NitsChanged reference from JavaScript to ECMAScript.Changed signature from equals() to equalsHash().Fixed the examples following implementation.Replaced automatic decoding of value by ECMAScript code.Added the type of each property.Specified that the code cannot be used to modify the value stored.
Reference Implementation and Access Control Policy script tester (<http://debian.implementers.org/testing/source/reload.tar.gz>).
Marc Petit-Huguenin.
Implements version -03.
Finish the code for ShaRe.