< draft-ietf-geopriv-policy-uri-03.txt		draft-ietf-geopriv-policy-uri-04.txt >
	GEOPRIV R. Barnes		GEOPRIV R. Barnes
	Internet-Draft BBN Technologies		Internet-Draft BBN Technologies
	Intended status: Informational M. Thomson		Intended status: Standards Track M. Thomson
	Expires: May 20, 2012 J. Winterbottom		Expires: May 31, 2012 J. Winterbottom
	Andrew Corporation		Andrew Corporation
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	November 17, 2011		November 28, 2011
	Location Configuration Extensions for Policy Management		Location Configuration Extensions for Policy Management
	draft-ietf-geopriv-policy-uri-03.txt		draft-ietf-geopriv-policy-uri-04.txt
	Abstract		Abstract
	Current location configuration protocols are capable of provisioning		Current location configuration protocols are capable of provisioning
	an Internet host with a location URI that refers to the host's		an Internet host with a location URI that refers to the host's
	location. These protocols lack a mechanism for the target host to		location. These protocols lack a mechanism for the target host to
	inspect or set the privacy rules that are applied to the URIs they		inspect or set the privacy rules that are applied to the URIs they
	distribute. This document extends the current location configuration		distribute. This document extends the current location configuration
	protocols to provide hosts with a reference to the rules that are		protocols to provide hosts with a reference to the rules that are
	applied to a URI, so that the host can view or set these rules.		applied to a URI, so that the host can view or set these rules.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 20, 2012.		This Internet-Draft will expire on May 31, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.3. Basic Access Control Policy . . . . . . . . . . . . . . . 10		5.3. Basic Access Control Policy . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	6.1. URN Sub-Namespace Registration for		6.1. URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 12		urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 12
	6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12		6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
	6.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 13		6.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7.1. Integrity and Confidentiality for Authorization Policy		7.1. Integrity and Confidentiality for Authorization Policy
	Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.2. Access Control for Authorization Policy . . . . . . . . . 13		7.2. Access Control for Authorization Policy . . . . . . . . . 14
	7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 14		7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 14
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 15		9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	9.2. Informative References . . . . . . . . . . . . . . . . . . 16		9.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	A critical step in enabling Internet hosts to access location-based		A critical step in enabling Internet hosts to access location-based
	skipping to change at page 13, line 46 ¶		skipping to change at page 13, line 46 ¶
	Each LCP ensures integrity and confidentiality through different		Each LCP ensures integrity and confidentiality through different
	means (see [RFC5985] and [I-D.ietf-geopriv-dhcp-lbyr-uri-option]).		means (see [RFC5985] and [I-D.ietf-geopriv-dhcp-lbyr-uri-option]).
	These measures ensure that a policy URI is conveyed to the client		These measures ensure that a policy URI is conveyed to the client
	without modification or interception.		without modification or interception.
	To protect the integrity and confidentiality of policy data during		To protect the integrity and confidentiality of policy data during
	management, the Location Server SHOULD provide policy URIs with the		management, the Location Server SHOULD provide policy URIs with the
	"https:" scheme and require the use of HTTP over TLS [RFC2818]. The		"https:" scheme and require the use of HTTP over TLS [RFC2818]. The
	cipher suites required by TLS [RFC5246] provide both integrity		cipher suites required by TLS [RFC5246] provide both integrity
	protection and confidentiality. If other means of protection are		protection and confidentiality. If other means of protection are
	available, an "http:" URI MAY be used.		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		7.2. Access Control for Authorization Policy
	Access control for the policy resource is based on knowledge of its		Access control for the policy resource is based on knowledge of its
	URI. The URI of a policy resource operates under the same		URI. The URI of a policy resource operates under the same
	constraints as a possession model location URI [RFC5808] and is		constraints as a possession model location URI [RFC5808] and is
	subject to the same constraints:		subject to the same constraints:
	o Knowledge of a policy URI MUST be restricted to authorized Rule		o Knowledge of a policy URI MUST be restricted to authorized Rule
	Makers. ConfideConfidentiality and integrity protections SHOULD		Makers. ConfideConfidentiality and integrity protections SHOULD
	be used when policy URIs are conveyed in a location configuration		be used when policy URIs are conveyed in a location configuration
	protocol, and in the requests that are used to inspect, change or		protocol, and in the requests that are used to inspect, change or
	delete the policy resource. Note that in some protocols (such as		delete the policy resource. Note that in some protocols (such as
	DHCP), these protections may arise from limiting the use of the		DHCP), these protections may arise from limiting the use of the
	protocol to the local network, thus relying on lower-layer		protocol to the local network, thus relying on lower-layer
	security mechanisms. When neither application-layer or network-		security mechanisms. When neither application-layer or network-
	layer security is provided, location servers MUST reject requests		layer security is provided, location servers MUST reject requests
	using the PUT and DELETE methods, and SHOULD reject PUT and DELETE		using the PUT and DELETE methods.
	requests for policy URIs that use the "http:" URI scheme.
	o The Location Server MUST ensure that the URI cannot be easily		o The Location Server MUST ensure that the URI cannot be easily
	predicted. The policy URI MUST NOT be derived solely from		predicted. The policy URI MUST NOT be derived solely from
	information that might be public, including the Target identity or		information that might be public, including the Target identity or
	any location URI. The addition of 32 bits or more of random		any location URI. The addition of 32 bits or more of random
	entropy is RECOMMENDED to make it infeasible for a third party to		entropy is RECOMMENDED to make it infeasible for a third party to
	guess a policy URI.		guess a policy URI.
	o Servers SHOULD apply rate limits in order to make brute-force		o Servers SHOULD apply rate limits in order to make brute-force
	guessing infeasible. If a server allocates policy URIs that		guessing infeasible. If a server allocates policy URIs that
End of changes. 7 change blocks.
	9 lines changed or deleted		10 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/