A Usage for Shared Resources in RELOAD (ShaRe)
Extracted elements (30)
ACLs are themselves stored as Shared Resources using the array data model and the USER-CHAIN-ACL policy, making them self-managed and enabling the same isolated-data indexing scheme to prevent concurrent write collisions on delegation entries.
Pattern separators are required to prevent a user with a shorter name from blocking resources for a longer-named peer; for example, a '*$USER' pattern would allow user EVE to define a resource named 'STEVE', preempting that name for user STEVE.
ShaRe extends RELOAD's security model, which normally restricts writes to locations bound to a peer's username or Node-ID certificate, by enabling controlled shared write access for multiple users to a common Resource-ID via Access Control Lists.
Accessing peers wishing to validate ACL authorization must first send a Stat request to obtain all array indexes of stored ACL Kinds, then fetch all existing ACL items; cached ACLs may be used up to item maximum lifetime, but a Stat request SHOULD be used to check for updates before using cached data.
A <pattern> element MUST be present if the 'enabled' attribute of the <variable-resource-names> element is set to true; both $USER and $DOMAIN variables MUST be present in any given pattern definition.
A storing peer MUST perform the ACL access validation procedure on any incoming store request for every Kind that uses the USER-CHAIN-ACL policy, and SHALL ensure that only the Resource Owner stores new ACL root items for Shared Resources.
An existing ACL item MUST only be overwritten by the user who initially stored the corresponding entry, or by the Resource Owner; attempting to overwrite an ACL item signed by another peer causes an Error_Forbidden response from the Storing Peer.
Each Usage intending to share RELOAD Resources MUST use the USER-CHAIN-ACL access policy as described in Section 6.6 to ensure write access by Authorized Peers.
If the overlay configuration allows variable resource names, a Kind using the USER-CHAIN-ACL policy MUST use the ResourceNameExtension as the initial field within the Kind data structure definition.
If the ResourceNameExtension type is 'pattern', the Resource Name MUST match one of the variable resource name patterns defined for this Kind in the configuration document.
The ACL root item MUST contain the username of the Resource Owner in the 'to_user' field and can only be written by the owner of the public key certificate associated with that Resource-ID; the allow_delegation flag for a root ACL item is set to 1 by default.
The resulting 32-bit array index (24-bit Node-ID prefix + 8-bit individual index) MUST be used as the index for storing an array entry in a Shared Resource.
Under the USER-CHAIN-ACL policy, a given value MUST NOT be written or overwritten if neither USER-MATCH nor USER-NODE-MATCH (mandatory for dictionary data models) access policies from the base RELOAD document apply.
Under USER-CHAIN-ACL, the store request MUST be denied if the signer's certificate username does not match a variable resource name pattern, or if the hashed Resource Name does not match the Resource-ID, or if access rights cannot be verified via ACL validation.
Usages that allow storage of Shared Resources are REQUIRED to use either the array or dictionary data model and MUST apply additional mechanisms for isolating data to prevent concurrent writing race conditions.
Variable parts in <pattern> elements defined in the overlay configuration document MUST remain syntactically separated from the username part (e.g., by a dedicated delimiter) to prevent collisions with resource names of other users.
When using a dictionary data model for a Shared Resource, the dictionary key MUST be the Node-ID of the certificate used to sign the stored data, binding data access to the unique ID holder and preventing write concurrency.
All data stored in a Shared Resource is readable by any node in the overlay; applications requiring privacy must encrypt their data. The ACL itself must be stored unencrypted, making group membership permanently publicly visible.
The ACCESS-CONTROL-LIST Kind uses the Resource Name of the Kind to be shared as its own Resource Name, employs the array data model with indexes formed by the isolated-data mechanism (Section 3.1), and uses the USER-CHAIN-ACL access control policy.
The AccessControlListItem structure contains an optional ResourceNameExtension, a 'to_user' field (opaque, up to 2^16-1 octets) identifying the authorized user, a 'kind' field (KindId) for the shared resource, and a Boolean 'allow_delegation' flag indicating whether the authorized peer may further delegate access.
When using an array data model for Shared Resources, the array index is formed by taking the least significant 24 bits of the signer's Node-ID as a prefix and appending an 8-bit individual index, yielding a 32-bit index allowing each peer up to 256 distinct entries.
Write access revocation is performed by storing a nonexistent value at the corresponding ACL item, automatically invalidating all delegations in the subtree rooted at that item, allowing entire delegation subtrees to be revoked in a single operation.
IANA registered 'ACCESS-CONTROL-LIST' with Kind-ID 0x4 in the 'RELOAD Data Kind-ID' registry (RFC 6940) to represent the ShaRe ACL kind defined in Section 7.
IANA registered the XML namespace URI 'urn:ietf:params:xml:ns:p2p:config-base:share' in the IETF XML registry (RFC 3688) for the ShaRe overlay configuration document extension.
IANA registered 'USER-CHAIN-ACL' in the 'RELOAD Access Control Policies' registry (RFC 6940) to represent the new access control policy defined in Section 6.6.
A malicious storing peer can withhold Shared Resource data (denial of service to the group) but cannot return forged data, since validity of all stored data can be independently verified using attached signatures.
A Resource Owner that erroneously delegates write access to a misbehaving peer enables that peer to exhaust shared storage or misuse the shared application; the Resource Owner retains the ability to revoke an entire delegation subtree in a single overwrite operation.
Shared Resources allow multiple peers to write at a single Resource-ID, potentially storing an arbitrary number of entries such as ACL delegations, leading to enhanced resource consumption at storing overlay nodes; this can be mitigated by imposing <max-size> limits in the configuration document.
ACL validation traverses the trust delegation tree recursively: (1) obtain the signer's username from the Shared Resource write request, (2) find a matching 'to_user' in the ACL, (3) check the signing certificate of that ACL item, (4) repeat up the chain until reaching a root item signed by the Resource Owner. The chain is valid only if all steps succeed.
The ResourceNameExtension structure contains a ResourceNameType enum (1 octet), a uint16 length field, and a type-dependent payload; for type 'pattern', the payload is an opaque field of up to 2^16-1 octets containing the Resource Name.