Location Configuration Extensions for Policy Management
Extracted elements (28)
A policy URI functions as a shared secret (possession model): knowledge of the URI is treated as adequate evidence of authorization, analogous to a possession-model location URI, rather than requiring separate authentication credentials.
Location by reference is preferred over location by value from a privacy perspective because the required dereference transaction provides a policy enforcement point; an opaque location URI can be safely conveyed over untrusted media if privacy policies are in place.
Once a client indicates it understands policy URIs (via 'requestPolicyUri'), the server may adopt a more restrictive default policy (even empty/default-deny), since the client can set a more permissive policy if desired. This shifts the burden of openness to the informed client.
Setting no policy (no HTTP request to policy URI) is explicitly distinct from setting an empty policy (PUT with a ruleset containing no rules). An empty policy is default-deny; no policy tacitly accepts whatever default the server applies, which may include open access.
The policy URI approach reduces overall location privacy risk compared to bare location URIs: the shared secret (policy URI) can stay on the client device and be used to set access controls, whereas without policy URIs, location URIs must be conveyed externally and are subject to server-set defaults.
A client that does not support policy URIs can continue to use the location URI as it would without a policy URI; the initial policy is identical to the default, so non-implementing clients are not broken by the presence of policy URI support on the server.
The HTTP-based policy URI usage is generally compatible with XCAP (RFC 4825) and WebDAV (RFC 4918) for managing policy documents, but this document does not define or require the use of these protocols.
A Location Server MUST NOT respond to any requests to a policy URI once the corresponding location URI set has expired, as specified by the 'expires' attribute in the HELD locationResponse.
A Location Server that is the authority for policy URIs MUST support GET, PUT, and DELETE requests to these URIs, in order to allow clients to inspect, replace, and delete policy documents.
A policy URI is created at the same time as the location URI it controls; the URI of the policy resource MUST be different from the location URI, and a policy URI MUST NOT be provided to an entity not authorized to view or set policy.
An LCP server MUST create a different location URI and policy URI for every request, unless the requests can be reliably identified as being from the same client, to handle middlebox scenarios where multiple clients appear as one.
Clients implementing this specification MUST verify that a policy URI received from HELD uses either the 'http:' or 'https:' scheme; if not, the client MUST discard the URI and behave as if no policy URI was provided.
Each location URI and policy URI issued to a different Target MUST be different from others; two clients MUST NOT receive the same location URI or the same policy URI, to prevent correlation and cross-target policy manipulation.
If a DELETE request is authorized, the Location Server MUST delete the policy referenced by the URI and disallow access to the governed location URIs until a new policy document is installed via PUT.
The initial policy referenced by a policy URI MUST be identical to the policy that would be applied in the absence of a policy URI, ensuring backward compatibility for clients that do not support policy URIs.
The Location Server MUST generate a new policy URI whenever it generates a new location URI set, to avoid reusing shared secrets.
The Location Server MUST support policy documents in the common-policy format (RFC 4745), identified by MIME type 'application/auth-policy+xml', and MUST provide it as the default format for GET requests without explicit Accept headers.
When a Location Server receives a PUT request, it MUST validate the policy document included in the body; if valid and authorized, it MUST replace the current policy with the policy provided in the request.
A policy URI is an HTTP or HTTPS URI that identifies a policy resource containing the authorization policy for a linked location resource. It allows a Rule Maker (target host) to inspect and install policy documents that tell a Location Server how to protect the associated location resource.
The HELD extension defines two XML elements: 'requestPolicyUri' (an empty element added to a location request to indicate the device desires a policy URI allocation) and 'policyUri' (carried in the location response, referencing the common access control policy for the locationUriSet).
This document registers an XML schema under the URI 'urn:ietf:params:xml:schema:geopriv:held:policy' in the IETF XML registry per RFC 3688; the schema content is defined in Section 4.1.
This document registers the XML namespace 'urn:ietf:params:xml:ns:geopriv:held:policy' in the IETF XML registry per RFC 3688, for use as the namespace for the HELD Policy URI Extension elements.
Knowledge of a policy URI MUST be restricted to authorized Rule Makers. When neither application-layer nor network-layer security is provided, location servers MUST reject requests using the PUT and DELETE methods.
Location Servers SHOULD provide policy URIs with the 'https:' scheme and require HTTP over TLS to protect integrity and confidentiality. Servers SHOULD reject PUT and DELETE requests for 'http:' policy URIs unless other protection mechanisms are available.
Policy URIs function as shared secrets; clients SHOULD protect them as passwords. Policy URIs SHOULD NOT be transmitted to other hosts or stored in plaintext, as any holder of the URI is authorized to access and modify the referenced policy.
Servers SHOULD apply rate limits to make brute-force guessing infeasible. If N bits of entropy are used with lifetime T seconds, the server should limit clients to (2^(N/2))/T queries per second, bounding the probability of URI compromise over its lifetime.
The Location Server MUST ensure a policy URI is unpredictable even to an attacker who has requested many URIs; it MUST NOT be derived solely from public information. Adding 128 bits or more of random entropy is RECOMMENDED to make guessing infeasible.
The XML schema for the HELD policy URI extension is defined under namespace 'urn:ietf:params:xml:ns:geopriv:held:policy'. It declares 'requestPolicyUri' as an empty complex type element and 'policyUri' as an xs:anyURI element.