draft-ietf-geopriv-policy-uri-06.txt   draft-ietf-geopriv-policy-uri-07.txt 
GEOPRIV R. Barnes GEOPRIV R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Standards Track M. Thomson Intended status: Standards Track M. Thomson
Expires: March 25, 2013 Microsoft Expires: April 7, 2013 Microsoft
J. Winterbottom J. Winterbottom
Andrew Corporation Andrew Corporation
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
September 21, 2012 October 4, 2012
Location Configuration Extensions for Policy Management Location Configuration Extensions for Policy Management
draft-ietf-geopriv-policy-uri-06.txt draft-ietf-geopriv-policy-uri-07.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 41 skipping to change at page 1, line 41
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 March 25, 2013. This Internet-Draft will expire on April 7, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 7, line 49 skipping to change at page 7, line 49
preferences, and thus set no policy. On the other hand, another preferences, and thus set no policy. On the other hand, another
implementation might decide that if a user provides no positive implementation might decide that if a user provides no positive
authorization, then the empty policy should be installed. authorization, then the empty policy should be installed.
The same reasoning could also be applied to servers, with the caveat The same reasoning could also be applied to servers, with the caveat
that servers do not know whether a given HELD client supports the use that servers do not know whether a given HELD client supports the use
of policy URIs. A client that does not understand policy URIs will of policy URIs. A client that does not understand policy URIs will
not be able to set its own policy, and so the server must choose a not be able to set its own policy, and so the server must choose a
default that is open enough that clients will find it useful. On the default that is open enough that clients will find it useful. On the
other hand, once a client indicates that it understands policy URIs other hand, once a client indicates that it understands policy URIs
(e.g., by sending an HTTP request to a policy URI), the server may (by including a "requestPolicyUri" element in its HELD request), the
change its default policy to something more restrictive -- even the server may change its default policy to something more restrictive --
empty, default-deny policy -- since the client can specify something even the empty, default-deny policy -- since the client can specify
more permissive if desired. something more permissive if desired.
4. Location Configuration Extensions 4. Location Configuration Extensions
Location configuration protocols can provision hosts with location Location configuration protocols can provision hosts with location
URIs that refer to the host's location. If the target host is to URIs that refer to the host's location. If the target host is to
control policy on these URIs, it needs a way to access the policy control policy on these URIs, it needs a way to access the policy
that the Location Server uses to guide how it serves location URIs. that the Location Server uses to guide how it serves location URIs.
This section defines extensions to LCPs to carry policy URIs that the This section defines extensions to LCPs to carry policy URIs that the
target can use to control access to location resources. target can use to control access to location resources.
skipping to change at page 17, line 19 skipping to change at page 17, line 19
URIs, by default, any holder of a policy URI is authorized to access URIs, by default, any holder of a policy URI is authorized to access
and modify the referenced policy document, and thus, to control and modify the referenced policy document, and thus, to control
access to the associated location resources. Because policy URIs access to the associated location resources. Because policy URIs
function as shared secrets, clients SHOULD protect them as they would function as shared secrets, clients SHOULD protect them as they would
passwords. For example, policy URIs SHOULD NOT be transmitted to passwords. For example, policy URIs SHOULD NOT be transmitted to
other hosts or stored in plaintext. other hosts or stored in plaintext.
It should be noted that one of the benefits of the policy URI 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 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, the client device to which it is provided. Without policy URIs,
location URIs are subject to the "authorization by possession model", location URIs are subject to a default policy set unilaterally by the
and location URIs must be conveyed to another entity in order to be server, and location URIs must be conveyed to another entity in order
useful. With policy URIs, location URIs can have more nuanced access to be useful. With policy URIs, location URIs can have more nuanced
controls, and the shared secret used to authenticate the client access controls, and the shared secret used to authenticate the
(i.e., the policy URI) can simply be stored on the client and used to client (i.e., the policy URI) can simply be stored on the client and
set the access control policy on the location URI. So while policy used to set the access control policy on the location URI. So while
URIs do use a default model of authorization by possession, they policy URIs do use a default model of authorization by possession,
reduce the overall risk to location privacy posed by leakage of they reduce the overall risk to location privacy posed by leakage of
shared secret URIs. shared secret URIs.
8. Acknowledgements 8. Acknowledgements
Thanks to Mary Barnes and Alissa Cooper for providing critical Thanks to Mary Barnes and Alissa Cooper for providing critical
commentary and input on the ideas described in this document, and to commentary and input on the ideas described in this document, and to
Ted Hardie and Adam Roach for helping clarify the relationships Ted Hardie and Adam Roach for helping clarify the relationships
between policy URIs, policy documents, and location resources. between policy URIs, policy documents, and location resources.
Thanks to Stephen Farrell for a helpful discussion on security and Thanks to Stephen Farrell for a helpful discussion on security and
privacy challenges. privacy challenges.
 End of changes. 6 change blocks. 
16 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/