draft-ietf-geopriv-deref-protocol-02.txt   draft-ietf-geopriv-deref-protocol-03.txt 
GEOPRIV J. Winterbottom GEOPRIV J. Winterbottom
Internet-Draft Andrew Corporation Internet-Draft Commscope
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: June 19, 2011 Nokia Siemens Networks Expires: December 25, 2011 Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
M. Thomson M. Thomson
M. Dawson M. Dawson
Andrew Corporation Commscope
December 16, 2010 June 23, 2011
A Location Dereferencing Protocol Using HELD A Location Dereferencing Protocol Using HELD
draft-ietf-geopriv-deref-protocol-02 draft-ietf-geopriv-deref-protocol-03.txt
Abstract Abstract
This document describes how to use the Hypertext Transfer Protocol This document describes how to use the Hypertext Transfer Protocol
(HTTP) over Transport Layer Security (TLS) as a dereferencing (HTTP) over Transport Layer Security (TLS) as a dereferencing
protocol to resolve a reference to a Presence Information Data Format protocol to resolve a reference to a Presence Information Data Format
Location Object (PIDF-LO). The document assumes that a Location Location Object (PIDF-LO). The document assumes that a Location
Recipient possesses a URI that can be used in conjunction with the Recipient possesses a URI that can be used in conjunction with the
HELD protocol to request the location of the Target. HELD protocol to request the location of the Target.
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 June 19, 2011. This Internet-Draft will expire on December 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Authorization Models . . . . . . . . . . . . . . . . . . . . . 5 3. Authorization Models . . . . . . . . . . . . . . . . . . . . . 5
3.1. Authorization by Possession . . . . . . . . . . . . . . . 6 3.1. Authorization by Possession . . . . . . . . . . . . . . . 6
3.2. Authorization via Access Control . . . . . . . . . . . . . 7 3.2. Authorization via Access Control . . . . . . . . . . . . . 7
3.3. Access Control with HELD Deference . . . . . . . . . . . . 7 3.3. Access Control with HELD Deference . . . . . . . . . . . . 7
4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 8 4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 8
4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 9 4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 9
4.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 9 4.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative references . . . . . . . . . . . . . . . . . . 14 9.2. Informative references . . . . . . . . . . . . . . . . . . 15
Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 16 Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 17
Appendix B. Compliance to Location Reference Requirements . . . . 19 Appendix B. Compliance to Location Reference Requirements . . . . 20
B.1. Requirements for a Location Configuration Protocol . . . . 19 B.1. Requirements for a Location Configuration Protocol . . . . 20
B.2. Requirements for a Location Dereference Protocol . . . . . 21 B.2. Requirements for a Location Dereference Protocol . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Provision of location information by reference [RFC5808] involves the Provision of location information by reference [RFC5808] involves the
creation of a resource that is identified by a "location URI". A creation of a resource that is identified by a "location URI". A
"location URI" is a URI [RFC3986] that identifies a resource "location URI" is a URI [RFC3986] that identifies a resource
containing the location of an entity. A location URI might identify containing the location of an entity. A location URI can be acquired
a temporary resource, created in response to a HTTP-Enabled Location using a location configuration protocol, such as HTTP-Enabled
Delivery (HELD) [RFC5985] request. A location URI does not Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration
Protocol (DHCP) location URI option
[I-D.ietf-geopriv-dhcp-lbyr-uri-option]. A location URI does not
intrinsically include location information, instead the URI is intrinsically include location information, instead the URI is
"dereferenced" by a Location Recipient to acquire location "dereferenced" by a Location Recipient to acquire location
information. This document specifies how a holder of a location URI information. This document specifies how a holder of an "http:" or
uses that URI to retrieve location information. "https:" location URI uses that URI to retrieve location information.
HELD defines a use of HTTP that enables location configuration - the HELD defines a use of HTTP that enables location configuration - the
process where a Device acquires location information about itself. A process where a Device acquires location information about itself. A
part of location configuration is the provision of a location URI. part of location configuration is the provision of a location URI.
However, HELD does not describe how such a URI is used; this document However, HELD does not describe how such a URI is used; this document
provides that definition. provides that definition.
This document defines how HELD is used by a Location Recipient to This document defines how HELD is used by a Location Recipient to
dereference a location URI and acquire location information. The dereference a location URI and acquire location information. The
result of this process is a location object in the form of a Presence result of this process is a location object in the form of a Presence
skipping to change at page 3, line 43 skipping to change at page 3, line 45
Use of HELD as a dereferencing protocol has the advantage that the Use of HELD as a dereferencing protocol has the advantage that the
Location Recipient can indicate the type of location information it Location Recipient can indicate the type of location information it
would like to receive. This functionality is already available with would like to receive. This functionality is already available with
the HELD base specification, described in [RFC5985]. Furthermore, the HELD base specification, described in [RFC5985]. Furthermore,
the HELD response from the LIS towards the Location Recipient not the HELD response from the LIS towards the Location Recipient not
only provides the PIDF-LO but also encapsulates supplementary only provides the PIDF-LO but also encapsulates supplementary
information, such as error messages, back to the Location Recipient. information, such as error messages, back to the Location Recipient.
Location URIs created for use with HELD dereferencing use the Location URIs created for use with HELD dereferencing use the
"https:" or "http:" scheme. The behaviour described in this document "https:" or "http:" scheme. HELD can be used by Location Recipients
can be used by Location Recipients that are aware of the fact that that are aware of the fact that the URI is a location URI. Mandatory
the URI is a location URI. support for an HTTP GET request ensures that the URI can be used even
if it is not recognized as a location URI.
An example scenario envisioned by this document is shown in Figure 1. An example scenario envisioned by this document is shown in Figure 1.
This diagram shows how a location dereference protocol fits with This diagram shows how a location dereference protocol fits with
location configuration and conveyance. [RFC5808] contains more location configuration and conveyance. [RFC5808] contains more
information on this scenario and others like it. information on this scenario and others like it.
+-------------+ +-------------+
+------------+ | Location | +-----------+ +------------+ | Location | +-----------+
| End Device | | Information | | Location | | End Device | | Information | | Location |
| (Target) | | Server | | Recipient | | (Target) | | Server | | Recipient |
+-----+------+ +------+------+ +-----+-----+ +-----+------+ +------+------+ +-----+-----+
| | | | | |
.- + - - - - - - - - - - - - + -. | .- + - - - - - - - - - - - - + -. |
: | locationRequest | : | : | locationRequest | : |
. |------(location URI)---->| . | . |------(location URI)---->| . |
: | | : Location | : | | : Location |
. | locationResponse | . Configuration | . | locationResponse | . Configuration |
: |<-----(location URI)-----| : Protocol | : |<-----(location URI)-----| : |
. | | . | . | | . |
`- + - - - - - - - - - - - - + -' | `- + - - - - - - - - - - - - + -' |
| | | | | |
| Location Conveyance | | Location Conveyance |
|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>| |~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
| | | | | |
| .- + - - - - - - - - - - - - + -. | .- + - - - - - - - - - - - - + -.
| : | locationRequest | : | : | locationRequest | :
| . |<--------(civic)---------| . | . |<--------(civic)---------| .
| Dereferencing : | | : | Dereferencing : | | :
| Protocol . | locationResponse | . | . | locationResponse | .
| : |--------(PIDF-LO)------->| : | : |--------(PIDF-LO)------->| :
| . | | . | . | | .
| `- + - - - - - - - - - - - - + -' | `- + - - - - - - - - - - - - + -'
| | | | | |
Figure 1: Example of Dereference Protocol Exchange Figure 1: Example of Dereference Protocol Exchange
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 48 skipping to change at page 6, line 5
It is important to note that this document does not mandate a It is important to note that this document does not mandate a
specific authorization model. It is possible to combine aspects of specific authorization model. It is possible to combine aspects of
both models. However, no authentication framework is provided, which both models. However, no authentication framework is provided, which
limits the policy options available when the "Authorization by Access limits the policy options available when the "Authorization by Access
Control" model is used. Control" model is used.
For either authorization model, the overall process is similar. The For either authorization model, the overall process is similar. The
following steps are followed, with minor alterations: following steps are followed, with minor alterations:
1. The Target acquires a location URI from the LIS. This might use 1. The Target acquires a location URI from the LIS. This uses a
HELD as a location configuration protocol (LCP). location configuration protocol (LCP), such as HELD or DHCP.
2. The Target then conveys the location URI to a third party, the 2. The Target then conveys the location URI to a third party, the
Location Recipient (for example using SIP as described in Location Recipient (for example using SIP as described in
[I-D.ietf-sipcore-location-conveyance]). This step is shown in [I-D.ietf-sipcore-location-conveyance]). This step is shown in
(2) of Figure 2. (2) of Figure 2.
3. The Location Recipient then needs to dereference the location URI 3. The Location Recipient then needs to dereference the location URI
in order to obtain the Location Object (3). Depending on the URI in order to obtain the Location Object (3). An "https:" or
scheme of the location URI dereferencing might, as is the case "http:" URI is dereferenced as described in this document; other
for "https:" or "http:" URIs, be performed as described in this URI schemes might be dereferenced using another method.
document.
In this final step, the Location Server (LS) or LIS makes an In this final step, the Location Server (LS) or LIS makes an
authorization decision. How this decision is reached depends on the authorization decision. How this decision is reached depends on the
authorization model. authorization model.
3.1. Authorization by Possession 3.1. Authorization by Possession
In this model, possession - or knowledge - of the location URI is In this model, possession - or knowledge - of the location URI is
used to control access to location information. A location URI is used to control access to location information. A location URI is
constructed such that it is hard to guess (see C9 of [RFC5808]) and constructed such that it is hard to guess (see C9 of [RFC5808]) and
skipping to change at page 8, line 18 skipping to change at page 8, line 20
that receive a particular location URI are granted location that receive a particular location URI are granted location
information based on the authorization policy associated with that information based on the authorization policy associated with that
URI. URI.
Providing that knowledge of a location URI is limited, policy Providing that knowledge of a location URI is limited, policy
appropriate to the Location Recipients that receive the location URI appropriate to the Location Recipients that receive the location URI
can be assigned. Selective disclosure used in this fashion can be can be assigned. Selective disclosure used in this fashion can be
used in place of identity-based authorization. used in place of identity-based authorization.
How policy is associated with a location URI is not defined by this How policy is associated with a location URI is not defined by this
document. [I-D.barnes-geopriv-policy-uri] describes one possible document. [I-D.ietf-geopriv-policy-uri] describes one possible
mechanism. mechanism.
Authentication of Location Recipients and use of identity-based Authentication of Location Recipients and use of identity-based
authorization policy is not precluded. A Location Server MAY support authorization policy is not precluded. A Location Server MAY support
an authentication mechanism that enables identity-based authorization an authentication mechanism that enables identity-based authorization
policies to be used. Future specifications might define means of policies to be used. Future specifications might define means of
identifying recipients. identifying recipients.
Note: Policy frameworks like [RFC4745] degrade in a way that Note: Policy frameworks like [RFC4745] degrade in a way that
protects privacy if features are not supported. If a policy protects privacy if features are not supported. If a policy
skipping to change at page 9, line 31 skipping to change at page 9, line 34
The HELD "locationRequest" is the only request permitted by this The HELD "locationRequest" is the only request permitted by this
specification. Similarly, request parameters other than the specification. Similarly, request parameters other than the
following MUST NOT be accepted by the LS: "responseTime", following MUST NOT be accepted by the LS: "responseTime",
"locationType" (including the associated "exact" attribute). "locationType" (including the associated "exact" attribute).
Parameters and requests that do not have known behaviour for Parameters and requests that do not have known behaviour for
dereference requests MUST NOT be used. The LS MUST ignore any dereference requests MUST NOT be used. The LS MUST ignore any
parameters that it does not understand unless it knows the parameters parameters that it does not understand unless it knows the parameters
to be invalid. If parameters are understood by the LS and known to to be invalid. If parameters are understood by the LS and known to
be invalid, the LS MAY generate a HELD error response. For instance, be invalid, the LS MAY generate a HELD error response. For instance,
those defined in [I-D.ietf-geopriv-held-identity-extensions] are those defined in [RFC6155] are always invalid and can be rejected.
always invalid and can be rejected.
The LS MUST NOT generate location URIs or provide a "locationUriSet" The LS MUST NOT generate location URIs or provide a "locationUriSet"
in response to a dereference request. If the location request in response to a dereference request. If the location request
contains a "locationType" element that includes "locationURI", this contains a "locationType" element that includes "locationURI", this
parameter is either ignored or rejected as appropriate, based on the parameter is either ignored or rejected as appropriate, based on the
associated "exact" attribute. associated "exact" attribute.
4.2. HTTP GET Behavior 4.2. HTTP GET Behavior
GET is the method assumed by generic HTTP user agents, therefore GET is the method assumed by generic HTTP user agents, therefore
unless context identifies an "https:" URI as a HELD URI, such a user unless context identifies an "https:" URI as a HELD URI, such a user
agent might simply send an HTTP GET. Rather than providing an HTTP agent might simply send an HTTP GET. Rather than providing an HTTP
405 (Method Not Allowed) response indicating that POST is the only 405 (Method Not Allowed) response indicating that POST is the only
permitted method, this document describes a way for a LIS to provide permitted method, a LIS MUST provide a HELD location response if it
a HELD location response if it receives an HTTP GET request. receives an HTTP GET request.
An HTTP GET request to a HELD URI produces a HELD response as if the An HTTP GET request to a HELD URI produces a HELD response as if the
following HELD request had been sent using HTTP POST: following HELD request had been sent using HTTP POST:
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="false"> <locationType exact="false">
geodetic civic geodetic civic
</locationType> </locationType>
</locationRequest> </locationRequest>
Figure 3: GET Request Equivalent Location Request Figure 3: GET Request Equivalent Location Request
HTTP GET requests must be safe and idempotent [RFC2616] - that is, HTTP GET requests MUST be safe and idempotent [RFC2616] - that is,
there are no side-effects of making the request and a repeated there are no side-effects of making the request and a repeated
request has no more effect than a single request. Only when a request has no more effect than a single request. Repeating a HELD
location URI is created does HELD request have side-effects. request might result in a different location, but only as a result of
Repeating a HELD request might result in a different location, but a change in the state of the resource: the location of the Target.
only as a result of a change in the state of the resource: the
location of the Target.
A request to a location URI can be both safe and idempotent, since a Only the creation of a location URI as a result of receiving a
location URI cannot be produced in response to a request to a request causes a HELD request to have side-effects. A request to a
location URI. location URI can be both safe and idempotent, since a location URI
cannot be produced in response to a request to a location URI.
A Location Recipient MAY infer from a response containing the HELD
content type, "application/held+xml", that a URI references a
resource that supports HELD.
Content negotiation MAY be supported to produce a presence document Content negotiation MAY be supported to produce a presence document
in place of a HELD location response. Where the presence document in place of a HELD location response. Where the presence document
would otherwise be included in a "locationResponse" document, it can would otherwise be included in a "locationResponse" document, it can
be included in the body of the HTTP response directly by including an be included in the body of the HTTP response directly by including an
"Accept" header that includes "application/pidf+xml". "Accept" header that includes "application/pidf+xml".
5. Examples 5. Examples
The example in Figure 4 shows the simplest form of dereferencing The example in Figure 4 shows the simplest form of dereferencing
skipping to change at page 12, line 39 skipping to change at page 13, line 29
Server: Example LIS Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private Cache-control: private
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-Length: 591 Content-Length: 591
<?xml version="1.0"?> <?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com"> entity="pres:3650n87934c@ls.example.com">
... PIDF contents are identical to the previous example ... <!-- PIDF contents are identical to the previous example -->
</presence> </presence>
Figure 8: GET Response with PIDF-LO Figure 8: GET Response with PIDF-LO
6. Security Considerations 6. Security Considerations
Privacy of location information is the most important security Privacy of location information is the most important security
consideration for this document. Two measures in particular are used consideration for this document. Two measures in particular are used
to protect privacy: TLS and authorization policies. TLS provides a to protect privacy: TLS and authorization policies. TLS provides a
means of ensuring confidentiality of location information through means of ensuring confidentiality of location information through
encryption and mutual authentication. An authorization policy allows encryption and mutual authentication. An authorization policy allows
a Rule Maker to explicitly control how location information is a Rule Maker to explicitly control how location information is
provided to Location Recipients. provided to Location Recipients.
The process by which a Rule Maker establishes an authorization policy The process by which a Rule Maker establishes an authorization policy
is not covered by this document; several methods are possible, for is not covered by this document; several methods are possible, for
instance: [I-D.barnes-geopriv-policy-uri], [RFC4825]. instance: [I-D.ietf-geopriv-policy-uri], [RFC4825].
Use of TLS for the dereferencing of location URIs is strongly Use of TLS for the dereferencing of location URIs is strongly
RECOMMENDED, as discussed in Section 4. Location Recipients MUST RECOMMENDED, as discussed in Section 4. Location Recipients MUST
authenticate the host identity using the domain name included in the authenticate the host identity using the domain name included in the
location URI, using the procedure described in Section 3.1 of location URI, using the procedure described in Section 3.1 of
[RFC2818]. Local policy determines what a Location Recipient does if [RFC2818]. Local policy determines what a Location Recipient does if
authentication fails or cannot be attempted. authentication fails or cannot be attempted.
The authorization by possession model (Section 3.1) further relies on The authorization by possession model (Section 3.1) further relies on
TLS when transmitting the location URI to protect the secrecy of the TLS when transmitting the location URI to protect the secrecy of the
skipping to change at page 14, line 12 skipping to change at page 14, line 48
[[IANA/RFC-EDITOR: Please remove this section before publication.]] [[IANA/RFC-EDITOR: Please remove this section before publication.]]
8. Acknowledgements 8. Acknowledgements
Thanks to Barbara Stark and Guy Caron for providing early comments. Thanks to Barbara Stark and Guy Caron for providing early comments.
Thanks to Rohan Mahy for constructive comments on the scope and Thanks to Rohan Mahy for constructive comments on the scope and
format of the document. Thanks to Ted Hardie for his strawman format of the document. Thanks to Ted Hardie for his strawman
proposal that provided assistance with the security section of this proposal that provided assistance with the security section of this
document. Richard Barnes made helpful observations on the document. Richard Barnes made helpful observations on the
application of authorization policy. application of authorization policy. Bernard Aboba and Julian
Reschke contributed constructive reviews.
The participants of the GEOPRIV interim meeting 2008 provided The participants of the GEOPRIV interim meeting 2008 provided
significant feedback on this document. significant feedback on this document.
James Polk provided input on security in June 2008. James Polk provided input on security in June 2008.
9. References 9. References
9.1. Normative References 9.1. Normative References
skipping to change at page 14, line 49 skipping to change at page 15, line 40
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010. RFC 5985, September 2010.
9.2. Informative references 9.2. Informative references
[I-D.barnes-geopriv-policy-uri]
Barnes, R., Thomson, M., Winterbottom, J., and H.
Tschofenig, "Location Configuration Extensions for Policy
Management", draft-barnes-geopriv-policy-uri-02 (work in
progress), November 2010.
[I-D.ietf-geopriv-arch] [I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-03 (work in progress), draft-ietf-geopriv-arch-03 (work in progress),
October 2010. October 2010.
[I-D.ietf-geopriv-held-identity-extensions] [I-D.ietf-geopriv-dhcp-lbyr-uri-option]
Winterbottom, J., Thomson, M., Tschofenig, H., and R. Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
Barnes, "Use of Device Identity in HTTP-Enabled Location and IPv6 Option for a Location Uniform Resource Identifier
Delivery (HELD)", (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-11 (work
draft-ietf-geopriv-held-identity-extensions-06 (work in in progress), February 2011.
progress), November 2010.
[I-D.ietf-geopriv-policy] [I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
and J. Polk, "Geolocation Policy: A Document Format for and J. Polk, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information", Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-22 (work in progress), draft-ietf-geopriv-policy-23 (work in progress),
October 2010. March 2011.
[I-D.ietf-geopriv-policy-uri]
Barnes, R., Thomson, M., Winterbottom, J., and H.
Tschofenig, "Location Configuration Extensions for Policy
Management", draft-ietf-geopriv-policy-uri-01 (work in
progress), June 2011.
[I-D.ietf-sipcore-location-conveyance] [I-D.ietf-sipcore-location-conveyance]
Polk, J., Rosen, B., and J. Peterson, "Location Conveyance Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", for the Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-04 (work in draft-ietf-sipcore-location-conveyance-08 (work in
progress), October 2010. progress), May 2011.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
skipping to change at page 16, line 16 skipping to change at page 17, line 5
Location Configuration Protocol: Problem Statement and Location Configuration Protocol: Problem Statement and
Requirements", RFC 5687, March 2010. Requirements", RFC 5687, March 2010.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference [RFC5808] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010. 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.
Appendix A. GEOPRIV Using Protocol Compliance Appendix A. GEOPRIV Using Protocol Compliance
This section describes how use of HELD as a location dereference This section describes how use of HELD as a location dereference
protocol complies with the GEOPRIV requirements described in protocol complies with the GEOPRIV requirements described in
[RFC3693]. [RFC3693].
Req. 1. (Location Object generalities): Req. 1. (Location Object generalities):
This section relates to the PIDF-LO [RFC4119] document, This section relates to the PIDF-LO [RFC4119] document,
which is used by HELD. These requirements are addressed by which is used by HELD. These requirements are addressed by
skipping to change at page 19, line 42 skipping to change at page 20, line 32
C1. "Location URI support: The location configuration protocol MUST C1. "Location URI support: The location configuration protocol MUST
support a location reference in URI form." support a location reference in URI form."
Compliant: HELD only provides location references in URI form. Compliant: HELD only provides location references in URI form.
C2. "Location URI expiration: When a location URI has a limited C2. "Location URI expiration: When a location URI has a limited
validity interval, its lifetime MUST be indicated." validity interval, its lifetime MUST be indicated."
Compliant: HELD indicates the expiry time of location URIs using Compliant: HELD indicates the expiry time of location URIs using
the "expires" attribute. [I-D.barnes-geopriv-policy-uri] the "expires" attribute. [I-D.ietf-geopriv-policy-uri] provides
provides a way to control expiration of a location URI; a Device a way to control expiration of a location URI; a Device is able
is able to specify limits on the life time of a HELD context. to specify limits on the life time of a HELD context.
C3. "Location URI cancellation: The location configuration protocol C3. "Location URI cancellation: The location configuration protocol
MUST support the ability to request a cancellation of a specific MUST support the ability to request a cancellation of a specific
location URI." location URI."
Compliant with Extension: [I-D.barnes-geopriv-policy-uri] Compliant with Extension: [I-D.ietf-geopriv-policy-uri]
describes how a location URI can be cancelled through the describes how a location URI can be cancelled through the
application of policy. Without extensions, HELD does not application of policy. Without extensions, HELD does not
provide a method for cancelling location URIs. provide a method for cancelling location URIs.
C4. "Location Information Masking: The location URI MUST ensure, by C4. "Location Information Masking: The location URI MUST ensure, by
default, through randomization and uniqueness, that the location default, through randomization and uniqueness, that the location
URI does not contain location information specific components." URI does not contain location information specific components."
Compliant: The HELD specification explicitly references this Compliant: The HELD specification explicitly references this
requirement in providing guidance on the format of the location requirement in providing guidance on the format of the location
skipping to change at page 20, line 36 skipping to change at page 21, line 26
Not Compliant: Specific extensions to the protocol or Not Compliant: Specific extensions to the protocol or
authorization policy formats is needed to alter the default authorization policy formats is needed to alter the default
behavior, which allows unlimited resolution of the location URI. behavior, which allows unlimited resolution of the location URI.
C7. "Selective disclosure: The location configuration protocol MUST C7. "Selective disclosure: The location configuration protocol MUST
provide a mechanism that allows the Rule Maker to control what provide a mechanism that allows the Rule Maker to control what
information is being disclosed about the Target." information is being disclosed about the Target."
Compliant with Extension: Use of policy mechanisms and Compliant with Extension: Use of policy mechanisms and
[I-D.barnes-geopriv-policy-uri] enable this capability. Note [I-D.ietf-geopriv-policy-uri] enable this capability. Note that
that this document recommends that only location information be this document recommends that only location information be
provided. provided.
C8. "Location URI Not guessable: As a default, the location C8. "Location URI Not guessable: As a default, the location
configuration protocol MUST return location URIs that are random configuration protocol MUST return location URIs that are random
and unique throughout the indicated lifetime. A location URI and unique throughout the indicated lifetime. A location URI
with 128-bits of randomness is RECOMMENDED." with 128-bits of randomness is RECOMMENDED."
Compliant: HELD specifies that location URIs conform to this Compliant: HELD specifies that location URIs conform to this
requirement. requirement.
skipping to change at page 22, line 8 skipping to change at page 23, line 8
the location server." the location server."
Compliant: This document strongly recommends the use of TLS for Compliant: This document strongly recommends the use of TLS for
confidentiality and HELD mandates its implementation. Unsecured confidentiality and HELD mandates its implementation. Unsecured
HTTP is permitted: the associated risks are described in HTTP is permitted: the associated risks are described in
Section 4. Section 4.
Authors' Addresses Authors' Addresses
James Winterbottom James Winterbottom
Andrew Corporation Commscope
Andrew Building (39) Andrew Building (39)
Wollongong University Campus Wollongong University Campus
Northfields Avenue Northfields Avenue
Wollongong, NSW 2522 Wollongong, NSW 2522
AU AU
Phone: +61 242 212938 Phone: +61 242 212938
Email: james.winterbottom@andrew.com Email: james.winterbottom@commscope.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
skipping to change at page 22, line 39 skipping to change at page 23, line 39
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building, New York, NY 10027 450 Computer Science Building, New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Martin Thomson Martin Thomson
Andrew Corporation Commscope
Andrew Building (39) Andrew Building (39)
Wollongong University Campus Wollongong University Campus
Northfields Avenue Northfields Avenue
Wollongong, NSW 2522 Wollongong, NSW 2522
AU AU
Phone: +61 2 4221 2915 Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com Email: martin.thomson@commscope.com
Martin Dawson Martin Dawson
Andrew Corporation Commscope
Andrew Building (39) Andrew Building (39)
Wollongong University Campus Wollongong University Campus
Northfields Avenue Northfields Avenue
Wollongong, NSW 2522 Wollongong, NSW 2522
AU AU
Phone: +61 2 4221 2992 Phone: +61 2 4221 2992
Email: martin.dawson@andrew.com Email: martin.dawson@commscope.com
 End of changes. 38 change blocks. 
76 lines changed or deleted 84 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/