See RFC 7199.
END 6.2. XML Schema Registration This section registers an XML schema as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:geopriv:held:policy Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Richard Barnes (rlb@ipv.sx) Schema: The XML for this schema can be found in Section 4.1. Barnes, et al. Standards Track [Page 12] RFC 7199 LCP Policy URIs April 2014 7. Security Considerations There are two main classes of risks associated with access control policy management: The risk of unauthorized grants or denial of access to the protected resource via manipulation of the policy management process, and the risk of disclosure of policy information itself. Protecting the policy management process from manipulation entails two primary requirements. First, the policy URI has to be faithfully and confidentially transmitted to the client; second, the policy document has to be faithfully and confidentially transmitted to the Location Server. The mechanism also needs to ensure that only authorized entities are able to acquire or alter policy. 7.1. Integrity and Confidentiality for Authorization Policy Data Each LCP ensures integrity and confidentiality through different means (see [RFC5985]). These measures ensure that a policy URI is conveyed to the client without modification or interception. In general, the requirements for TLS on policy transactions are the same as for the dereference transactions they set policy for [RFC6753]. To protect the integrity and confidentiality of policy data during management, the Location Server SHOULD provide policy URIs with the "https:" scheme and require the use of HTTP over TLS [RFC2818]. The cipher suites required by TLS [RFC5246] provide both integrity protection and confidentiality. If other means of protection are available, an "http:" URI MAY be used, but location servers SHOULD reject PUT and DELETE requests for policy URIs that use the "http:" URI scheme. 7.2. Access Control for Authorization Policy Access control for the policy resource is based on knowledge of its URI. The URI of a policy resource operates under the same constraints as a possession model location URI [RFC5808] and is subject to the same constraints: o Knowledge of a policy URI MUST be restricted to authorized Rule Makers. Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location configuration protocol and in the requests that are used to inspect, change, or delete the policy resource. Note that in some protocols (such as DHCP), these protections may arise from limiting the use of the protocol to the local network thus relying on lower-layer security Barnes, et al. Standards Track [Page 13] RFC 7199 LCP Policy URIs April 2014 mechanisms. When neither application-layer nor network-layer security is provided, location servers MUST reject requests using the PUT and DELETE methods. o The Location Server MUST ensure that it is not practical for an attacker to guess a policy URI value, even if the attacker has requested many policy URIs from the Location Server over time. The policy URI MUST NOT be derived solely from information that might be public, including the Target identity or any location URI. The addition of 128 bits or more of random entropy is RECOMMENDED to make it infeasible for a third party to guess a policy URI. o Servers SHOULD apply rate limits in order to make brute-force guessing infeasible. If a server allocates location URIs that include N bits of entropy with a lifetime of T seconds, then the server should limit clients to (2^(N/2))/T queries per second. (The lifetime T of a location URI set is specified by the "expires" attribute in HELD.) One possible algorithm for generating appropriately unpredictable policy URIs for a location URI set is described in Appendix A. The goal of the above recommendation on rate limiting is to bound the probability that an attacker can guess a policy URI during its lifetime. If an attacker is limited to (2^(N/2))/T queries per second, then he will be able to make at most 2^(N/2) guesses over the lifetime of the URI. Assuming these guesses are distinct, the probability of the attacker guessing any given URI is (2^(N/2))/(2^N), so the probability of compromise over the T-second lifetime of the URI is at most 2^(-N/2). (Of course, if the attacker guesses the URI after the policy URI has expired, then there is no risk.) With N=128, the probability of compromise is 5.4e-20 under this rate-limiting scheme. Operators should choose values for N so that the corresponding risk of compromise presents an acceptable level of risk. If M distinct URIs are issued within the same namespace, then the probability of any of the M URIs being compromised is M*2^(N/2). The example algorithm for generating policy URIs (see Appendix A) places them in independent namespaces (i.e., below the corresponding location URIs), so this compounding does not occur. Note that the chosen entropy level will also affect how quickly legitimate clients can query a given URI, especially for very long- lived URIs. If the default lifetime T is greater than 2^(N/2), then clients will have to wait multiple seconds between queries. Operators should choose entropy and lifetime values that result in Barnes, et al. Standards Track [Page 14] RFC 7199 LCP Policy URIs April 2014 acceptable high maximum query rates and acceptably low probability of compromise. For example, with 32 bits of entropy (much less than recommended above), the one-query-per-second policy URI lifetime is around 18 hours. 7.3. Location URI Allocation A policy URI enables the authorization by access control lists model [RFC5808] for associated location URIs. Under this model, it might be possible to more widely distribute a location URI, relying on the authorization policy to constrain access to location information. To allow for wider distribution, authorization by access control lists places additional constraints on the construction of location URIs. If multiple Targets share a location URI, an unauthorized location recipient that acquires location URIs for the Targets can determine that the Targets are at the same location by comparing location URIs. With shared policy URIs, Targets are able to see and modify authorization policy for other Targets. To allow for the creation of Target-specific authorization policies that are adequately privacy protected, each location URI and policy URI that is issued to a different Target MUST be different from other location URIs and policy URIs. That is, two clients MUST NOT receive the same location URI or the same policy URI. In some deployments, it is not always apparent to an LCP server that two clients are different. In particular, where a middlebox [RFC3234] exists, two or more clients might appear as a single client. An example of a deployment scenario of this nature is described in [RFC5687]. 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. 7.4. Policy URI Handling Although servers may choose to implement access controls on policy URIs, by default, any holder of a policy URI is authorized to access and modify the referenced policy document and, thus, to control access to the associated location resources. Because policy URIs function as shared secrets, clients SHOULD protect them as they would passwords. For example, policy URIs SHOULD NOT be transmitted to other hosts or stored in plaintext. Barnes, et al. Standards Track [Page 15] RFC 7199 LCP Policy URIs April 2014 It should be noted that one of the benefits of the policy URI construct is that in most cases, there is not a policy URI to leave the client device to which it is provided. Without policy URIs, location URIs are subject to a default policy set unilaterally by the server, and location URIs must be conveyed to another entity in order to be useful. With policy URIs, location URIs can have more nuanced access controls, and the shared secret used to authenticate the client (i.e., the policy URI) can simply be stored on the client and used to set the access control policy on the location URI. So while policy URIs do use a default model of authorization by possession, they reduce the overall risk to location privacy posed by leakage of shared secret URIs. 8. Acknowledgements Thanks to Mary Barnes and Alissa Cooper for providing critical commentary and input on the ideas described in this document. Also, thanks to Ted Hardie and Adam Roach for helping clarify the relationships between policy URIs, policy documents, and location resources. Thanks to Stephen Farrell for a helpful discussion on security and privacy challenges. Barnes, et al. Standards Track [Page 16] RFC 7199 LCP Policy URIs April 2014 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010. 9.2. Informative References [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. Barnes, et al. Standards Track [Page 17] RFC 7199 LCP Policy URIs April 2014 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007. [RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of 'retransmission-allowed' for SIP Location Conveyance", RFC 5606, August 2009. [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010. [RFC5808] Marshall, R., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010. [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", RFC 6155, March 2011. [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, July 2011. [RFC6753] Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M. Thomson, "A Location Dereference Protocol Using HTTP- Enabled Location Delivery (HELD)", RFC 6753, October 2012. [RFC6772] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", RFC 6772, January 2013. Barnes, et al. Standards Track [Page 18] RFC 7199 LCP Policy URIs April 2014 Appendix A. Example Policy URI Generation Algorithm One possible algorithm for generating appropriately unpredictable policy URIs for a location URI set is as follows: 1. Choose parameters: * A cryptographic hash function H, e.g., SHA256 * A number N of bits of entropy to add, such that N is no more than the length of the output of the hash function 2. On allocation of a location URI, generate a policy URI in the following way: 1. Generate a random value NONCE at least N/8 bytes long 2. Compute hash = H( Location-URI-Set || NONCE ) using some cryptographic hash function H and some serialization of the location URI set (e.g., the XML from a HELD response) 3. Form the policy URI by appending the base64url-encoded form of the hash [RFC4648] to one of the location URIs, e.g., as a query parameter: "http://example.com/loc/ foo?policy=j3WTGUb3smxcZA6eKIqmqdV3ALE" Barnes, et al. Standards Track [Page 19] RFC 7199 LCP Policy URIs April 2014 Authors' Addresses Richard Barnes Mozilla 331 E. Evelyn Ave. Mountain View, CA 94041 US EMail: rlb@ipv.sx Martin Thomson Mozilla Suite 300 331 E Evelyn Street Mountain View, CA 94041 US EMail: martin.thomson@gmail.com James Winterbottom Unaffiliated AU EMail: a.james.winterbottom@gmail.com Hannes Tschofenig Hall in Tirol 6060 Austria EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Barnes, et al. Standards Track [Page 20]-- Leo's gemini proxy
-- Connecting to gemini.bortzmeyer.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/plain
-- Response ended
-- Page fetched on Tue May 7 01:25:13 2024