From: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-deref-protocol-01.txt
Title: A Location Dereferencing Protocol Using HELD
Reference: draft-ietf-geopriv-deref-protocol-01
Date: September 29, 2010
HTML: http://tools.ietf.org/id/draft-ietf-geopriv-deref-protocol-01.html
Data Tracker: https://datatracker.ietf.org/doc/draft-ietf-geopriv-deref-protocol/
Tracker Listing: http://ietfreport.isoc.org/idref/draft-ietf-geopriv-deref-protocol/
Tools: http://tools.ietf.org/html/draft-ietf-geopriv-deref-protocol-01 (HTML)
Diff with version -00: http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-deref-protocol-01.txt
Announced: http://www.ietf.org/mail-archive/web/i-d-announce/current/msg33316.html
See also:
IETF Geographic Location/Privacy (GEOPRIV) Working Group Status Pages
http://tools.ietf.org/wg/geopriv/
Geographic Location/Privacy (GEOPRIV) Working Group Charter
http://www.ietf.org/html.charters/geopriv-charter.html
Geographic Location-Privacy Discussion List Archive
http://www1.ietf.org/mail-archive/web/geopriv/current/index.html
===============================================================================
GEOPRIV J. Winterbottom
Internet-Draft Andrew Corporation
Intended status: Standards Track H. Tschofenig
Expires: April 2, 2011 Nokia Siemens Networks
H. Schulzrinne
Columbia University
M. Thomson
M. Dawson
Andrew Corporation
September 29, 2010
A Location Dereferencing Protocol Using HELD
draft-ietf-geopriv-deref-protocol-01
Abstract
This document describes how to use the Hypertext Transfer Protocol
(HTTP) over Transport Layer Security (TLS) as a dereferencing
protocol to resolve a reference to a Presence Information Data Format
Location Object (PIDF-LO). The document assumes that a Location
Recipient possesses a secure HELD URI that can be used in conjunction
with the HELD protocol to request the location of the Target.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 2, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Winterbottom, et al. Expires April 2, 2011 [Page 1]
Internet-Draft HELD Dereferencing September 2010
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Authorization Models . . . . . . . . . . . . . . . . . . . . . 5
3.1. Authorization by Possession . . . . . . . . . . . . . . . 6
3.2. Authorization via Access Control . . . . . . . . . . . . . 7
3.3. Access Control with HELD Deference . . . . . . . . . . . . 7
4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 8
4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 9
4.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative references . . . . . . . . . . . . . . . . . . 15
Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 16
Appendix B. Compliance to Location Reference Requirements . . . . 19
B.1. Requirements for a Location Configuration Protocol . . . . 19
B.2. Requirements for a Location Dereference Protocol . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Winterbottom, et al. Expires April 2, 2011 [Page 2]
Internet-Draft HELD Dereferencing September 2010
1. Introduction
Provision of location information by reference [RFC5808] involves the
creation of a resource that is identified by a "location URI". A
"location URI" identifies resource that contains the location of an
entity. A location URI might be a temporary resource, created in
response to a HTTP-Enabled Location Delivery (HELD)
[I-D.ietf-geopriv-http-location-delivery] request. A location URI
does not intrinsically include location information, instead the URI
is "dereferenced" by a Location Recipient to acquire location
information. This document specifies how a holder of a location URI
uses that URI to retrieve location information.
The HELD protocol, as described in
[I-D.ietf-geopriv-http-location-delivery], defines a use of HTTP that
enables location configuration - the process where a Device acquires
location information about itself. A part of location configuration
is the provision of a location URI. However, HELD does not describe
how such a URI is used; this document provides that definition.
This document defines how HELD is used by a Location Recipient to
dereference a location URI and acquire location information. The
result of this process is location object in the form of a Presence
Information Data Format - Location Object (PIDF-LO) document
[RFC4119]. A constrained set of HELD features are defined such that
it is suitable for use as a location dereference protocol [RFC5808].
Use as a location dereference protocol requires use of the Transport
Layer Security (TLS) binding for HTTP [RFC2818] in order to provide
confidentiality, authentication and protection from modification.
Use of HELD as a dereferencing protocol has the advantage that the
Location Recipient can indicate the type of location information it
would like to receive. This functionality is already available with
the HELD base specification, described in
[I-D.ietf-geopriv-http-location-delivery]. Furthermore, the HELD
response from the LIS towards the Location Recipient not only
provides the PIDF-LO but also encapsulates supplementary information,
such as error messages, back to the Location Recipient.
Location URIs created for use with HELD dereferencing use the
"https:" or "http:" scheme. The behaviour described in this document
can be used by Location Recipients that are aware of the fact that
the URI is a location URI.
An example scenario envisioned by this document is shown in Figure 1.
This diagram shows how a location dereference protocol fits with
location configuration and conveyance. [RFC5808] contains more
information on this scenario and others like it.
Winterbottom, et al. Expires April 2, 2011 [Page 3]
Internet-Draft HELD Dereferencing September 2010
+-------------+
+------------+ | Location | +-----------+
| End Device | | Information | | Location |
| (Target) | | Server | | Recipient |
+-----+------+ +------+------+ +-----+-----+
| | |
.- + - - - - - - - - - - - - + -. |
: | locationRequest | : |
. |------(location URI)---->| . |
: | | : Location |
. | locationResponse | . Configuration |
: |<-----(location URI)-----| : Protocol |
. | | . |
`- + - - - - - - - - - - - - + -' |
| | |
| Location Conveyance |
|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
| | |
| .- + - - - - - - - - - - - - + -.
| : | locationRequest | :
| . |<--------(civic)---------| .
| Dereferencing : | | :
| Protocol . | locationResponse | .
| : |--------(PIDF-LO)------->| :
| . | | .
| `- + - - - - - - - - - - - - + -'
| | |
Figure 1: Example of Dereference Protocol Exchange
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document uses key terminology from several sources:
o terms for the GEOPRIV reference model defined in
[I-D.ietf-geopriv-arch];
o the term Location Information Server (LIS), from [RFC5687], is a
node in the access network that provides location information to
an end point; a LIS provides location URIs;
o the term Location Server (LS), from [I-D.ietf-geopriv-arch], is
used to identify the role that responds to a location dereference
Winterbottom, et al. Expires April 2, 2011 [Page 4]
Internet-Draft HELD Dereferencing September 2010
request; this might be the same entity as the LIS, but the model
in [RFC5808] allows for the existence of separate - but related -
entities; and
o the term location URI is coined in [RFC5808].
3. Authorization Models
This section discusses two extreme types of authorization models for
dereferencing with HELD URIs, namely "Authorization by Possession"
and "Authorization by Access Control". In the subsequent subsections
we discuss the properties of these two models. Figure 2, from
[RFC5808], shows the model applicable to location configuration,
conveyance and dereference.
+---------+--------+ Location +-----------+
| | | Dereference | Location |
| LIS - LS +---------------+ Recipient |
| | | Protocol | |
+----+----+--------+ (3) +-----+-----+
| `. |
| Policy `. |
Location | Exchange `. |
Configuration | (*) | |
Protocol | +----+----+ |
(1) | | Rule | Location |
| | Maker | Conveyance |
+-----+----+ +---------+ Protocol |
| | (2) |
| Target +------------------------------+
| |
+----------+
Figure 2: Communication Model
It is important to note that this document does not mandate a
specific authorization model. It is possible to combine aspects of
both models. However, no authentication framework is provided, which
limits the policy options available when the "Authorization by Access
Control" model is used.
For either authorization model, the overall process is similar. The
following steps are followed, with minor alterations:
1. The Target acquires a location URI from the LIS. This might use
HELD as a location configuration protocol (LCP).
Winterbottom, et al. Expires April 2, 2011 [Page 5]
Internet-Draft HELD Dereferencing September 2010
2. The Target then conveys the location URI to a third party, the
Location Recipient (for example using SIP as described in
[I-D.ietf-sipcore-location-conveyance]). This step is shown in
(2) of Figure 2.
3. The Location Recipient then needs to dereference the location URI
in order to obtain the Location Object (3). Depending on the URI
scheme of the location URI dereferencing might, as is the case
for "https:" or "http:" URIs, be performed as described in this
document.
In this final step, the Location Server (LS) or LIS makes an
authorization decision. How this decision is reached depends on the
authorization model.
3.1. Authorization by Possession
In this model, possession - or knowledge - of the 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
the set of entities that it is disclosed to is limited. The only
authentication required by the LS is evidence of possession of the
URI. The LS is able to immediately authorize any request that
indicates this URI.
Authorization by possession uses a very simple policy that does not
typically require direct interaction with a Rule Maker; it is assumed
that the Rule Maker is able to exert control over the distribution of
the location URI. Therefore, the LIS can operate with limited policy
input from a Rule Maker.
Limited disclosure is an important aspect of this authorization
model. The location URI is a secret; therefore, ensuring that
adversaries are not able to acquire this information is paramount.
Encryption, such as might be offered by TLS [RFC5246] or S/MIME
[RFC3851], protects the information from eavesdroppers.
Use of authorization by possession location URIs in a hop-by-hop
protocol such as SIP [RFC3261] adds the possibility of on-path
adversaries. Depending on the usage of the location URI for certain
location based applications (e.g., emergency services, location based
routing) specific treatment is important, as discussed in
[I-D.ietf-sipcore-location-conveyance].
Using possession as a basis for authorization means that, once
granted, authorization cannot be easily revoked. Cancellation of a
location URI ensures that legitimate users are also affected;
application of additional policy is theoretically possible, but could
Winterbottom, et al. Expires April 2, 2011 [Page 6]
Internet-Draft HELD Dereferencing September 2010
be technically infeasible. Therefore, other measures are provided to
prevent an adversary from gaining access to location information
indefinitely.
A very simple policy is established at the time that the location URI
is created. This policy specifies that the location URI expires
after a certain time, which limits any inadvertent exposure of
location information to adversaries. The expiration time of the
location URI might be negotiated at the time of its creation, or it
might be unilaterally set by the LIS.
3.2. Authorization via Access Control
Use of explicit access control provides a Rule Maker greater control
over the behaviour of an LS. In contrast to authorization by
possession, possession of a this form of location URI does not imply
authorization. Since an explicit policy is used to authorize access
to location information, the location URI can be distributed to many
potential Location Recipients.
Either before creation or dissemination of the location URI, the Rule
Maker establishes an authorization policy with the LS. In reference
to Figure 2, authorization policies might be established at creation
(Step 1), and need to be established before before the location URI
is published (Step 2) to ensure that the policy grants access to the
desired Location Recipients. Depending on the mechanism used, it
might also be possible to change authorization policies at any time.
A possible format for these authorization policies is available with
GEOPRIV Common Policy [RFC4745] and Geolocation Policy
[I-D.ietf-geopriv-policy]. Additional constraints might be
established by other means.
The LS enforces the authorization policy when a Location Recipient
dereferences the URI. Explicit authorization policies allow a Rule
Maker to specify how location information is provided to Location
Recipients.
3.3. Access Control with HELD Deference
This document does not describe a specific authentication mechanism.
This means that authorization policies are unable to specifically
identify authorized Location Recipients.
In order to control access to location information based on the
identity of the Location Recipient, use of authorization by
possession is employed. By controlling which Location Recipients
receive location URIs, access to location information is controlled.
Winterbottom, et al. Expires April 2, 2011 [Page 7]
Internet-Draft HELD Dereferencing September 2010
Other policy mechanisms, such as those described in
[I-D.ietf-geopriv-policy], can be applied to different Location
Recipients if multiple location URIs are used. Location Recipients
that receive a particular location URI are granted location
information based on the authorization policy associated with that
URI.
Providing that knowledge of a location URI is limited, policy
appropriate to the Location Recipients that receive the location URI
can be assigned. Selective disclosure used in this fashion can be
used in place of identity-based authorization.
How policy is associated with a location URI is not defined by this
document. [I-D.barnes-geopriv-policy-uri] describes one possible
mechanism.
Authentication of Location Recipients and use of identity-based
authorization policy is not precluded. A Location Server MAY support
an authentication mechanism that enables identity-based authorization
policies to be used. Future specifications might define means of
identifying recipients.
Note: Policy frameworks like [RFC4745] degrade in a way that
protects privacy if features are not supported. If a policy
specifies a rule that is conditional on the identity of a
recipient and the protocol does not (or cannot) provide an
assertion identity of the recipient, the rule has no effect and
the policy defaults to providing less information.
4. HELD Dereference Protocol
This section describes how HELD can be used to dereference a location
URI. This process can be applied when a Location Recipient is in
possession of a location URI with a "https:" or "http:" URI scheme.
A Location Recipient that wishes to dereference an "https:" or
"http:" URI performs a HELD request on HTTP to the identified
resource.
Note: In many cases, an "http:" URI does not provide sufficient
security for location URIs. The absence of the security
mechanisms provided by TLS means that the Rule Maker has no
control over who receives location information and the Location
Recipient has no assurance that the information is correct.
The Location Recipient establishes a connection to the LS, as
described in [RFC2818]. The TLS ciphersuite TLS_NULL_WITH_NULL_NULL
Winterbottom, et al. Expires April 2, 2011 [Page 8]
Internet-Draft HELD Dereferencing September 2010
MUST NOT be used. The LS MUST be authenticated to ensure that the
correct server is contacted.
A Location Server MAY reject a request and request that a Location
Recipient provide authentication credentials if authorization is
dependent on the Location Recipient identity. Future specifications
could define an authentication mechanism and a means by which
Location Recipients are identified in authorization policies. This
document provides definitions for neither item.
4.1. HELD Usage Profile
Use of HELD as a location dereference protocol is largely the same as
its use as a location configuration protocol. Aside from the
restrictions noted in this document, HELD semantics do not differ
from those established in [I-D.ietf-geopriv-http-location-delivery].
The HELD "locationRequest" is the only request permitted by this
specification. Similarly, request parameters other than the
following MUST NOT be accepted by the LS: "responseTime",
"locationType" (including the associated "exact" attribute).
Parameters and requests that do not have known behaviour for
dereference requests MUST NOT be used. The LS MUST ignore any
parameters that it does not understand unless it knows the parameters
to be invalid. If parameters are known to be invalid, the LS MAY
generate a HELD error response. For instance, those defined in
[I-D.ietf-geopriv-held-identity-extensions] are always invalid and
can be rejected.
The LS MUST NOT generate location URIs or provide a "locationUriSet"
in response to a dereference request. If the location request
contains a "locationType" element that includes "locationURI", this
parameter is either ignored or rejected as appropriate, based on the
associated "exact" attribute.
4.2. HTTP GET Behavior
GET is the method assumed by generic HTTP user agents, therefore
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
405 (Method Not Allowed) response indicating that POST is the only
permitted method, this document describes a way for a LIS to provide
a HELD location response if it receives an HTTP GET request.
Winterbottom, et al. Expires April 2, 2011 [Page 9]
Internet-Draft HELD Dereferencing September 2010
An HTTP GET request to a HELD URI produces a HELD response as if the
following HELD request had been sent using HTTP POST:
geodetic civic
Figure 3: GET Request Equivalent Location Request
HTTP GET requests must be safe and idempotent [RFC2616] - that is,
there are no side-effects of making the request. Only when a
location URI is created does HELD request have side-effects. A
request to a location URI can be both safe and idempotent, since a
location URI cannot be produced in response to a request to a
location URI.
Note: Idempotence does not require that the same answer be provided
to different requests only that there are no side effects.
Changes in the response can occur for a number of reasons,
including a change in the value of the resource: the location of
the Target.
Content negotiation MAY be supported to produce a presence document
in place of a HELD location response. Where the presence document
would otherwise be included in a "locationResponse" document, it can
be included in the body of the HTTP response directly.
5. Examples
The example in Figure 4 shows the simplest form of dereferencing
request using HELD to the location URI
"https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that
this differs from the example in Section 10.1 of
[I-D.ietf-geopriv-http-location-delivery] is in the request URI and
the source of the URI.
POST /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Content-Type: application/held+xml
Content-Length: 87
Figure 4: Minimal Dereferencing Request
Winterbottom, et al. Expires April 2, 2011 [Page 10]
Internet-Draft HELD Dereferencing September 2010
Figure 5 shows the response to the previous request listing both
civic and geodetic location information of the Target's location.
Again, this is identical to the response in Section 10.1 of
[I-D.ietf-geopriv-http-location-delivery] - unless policy specfies
otherwise, the Location Recipient receives the same information as
the Device.
HTTP/1.1 200 OK
Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private
Content-Type: application/held+xml
Content-Length: 676
-34.407 150.88001
false
2011-01-11T03:42:29+00:00
Wiremap
2006-01-10T03:42:28+00:00
Figure 5: Response with Location Information
Winterbottom, et al. Expires April 2, 2011 [Page 11]
Internet-Draft HELD Dereferencing September 2010
The following GET request is treated in an equivalent fashion. The
LS treats this request as though it were a location request of the
form shown in Figure 3. The same response might be provided.
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/held+xml
Figure 6: GET Request
The following GET request uses content negotiation to indicate a
preference for a presence document.
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/pidf+xml,application/held+xml;q=0.5
Figure 7: GET Request with Content Negotiation
The response only differs from a normal HELD location response to a
POST request in that the "locationResponse" element is omitted and
the "Content-Type" header reflects the changed content.
HTTP/1.1 200 OK
Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Length: 591
... PIDF contents are identical to the previous example ...
Figure 8: GET Response with PIDF-LO
6. Security Considerations
Privacy of location information is the most important security
consideration for this document. Two measures in particular are used
to protect privacy: TLS and authorization policies. TLS provides a
means of ensuring confidentiality of location information through
Winterbottom, et al. Expires April 2, 2011 [Page 12]
Internet-Draft HELD Dereferencing September 2010
encryption and mutual authentication. An authorization policy allows
a Rule Maker to explicitly control how location information is
provided to Location Recipients.
The process by which a Rule Maker establishes an authorization policy
is not covered by this document; several methods are possible, for
instance: [I-D.barnes-geopriv-policy-uri], [RFC4825].
Use of TLS for the dereferencing of location URIs is strongly
RECOMMENDED, as discussed in Section 4.1. Location Recipients MUST
authenticate the host identity using the domain name included in the
location URI, using the procedure described in Section 3.1 of
[RFC2818]. Local policy determines what a Location Recipient does if
authentication fails or cannot be attempted.
The authorization by possession model (Section 3.1) further relies on
TLS when transmitting the location URI to protect the secrecy of the
URI. Possession of such a URI implies the same privacy
considerations as possession of the PIDF-LO document that the URI
references.
Location URIs MUST only be disclosed to authorized Location
Recipients. The GEOPRIV architecture [I-D.ietf-geopriv-arch]
identifies the Rule Maker role as being the entity that authorizes
disclosure of this nature.
Protection of the location URI is necessary, since the policy
attached to such a location URI permits any who have the URI to view
it. This aspect of security is covered in more detail in the
specification of location conveyance protocols, such as
[I-D.ietf-sipcore-location-conveyance].
The LS MUST NOT provide any information about the Target except its
location, unless policy from a Rule Maker allows otherwise. In
particular, the requirements in [RFC5808] mandate this measure to
protect the identity of the Target. To this end, an unlinked
pseudonym MUST be provided in the "entity" attribute of the PIDF-LO
document.
Further security considerations and requirements relating to the use
of location URIs are described in [RFC5808].
7. IANA Considerations
This document makes no request of IANA.
[[IANA/RFC-EDITOR: Please remove this section before publication.]]
Winterbottom, et al. Expires April 2, 2011 [Page 13]
Internet-Draft HELD Dereferencing September 2010
8. Acknowledgements
Thanks to Barbara Stark and Guy Caron for providing early comments.
Thanks to Rohan Mahy for constructive comments on the scope and
format of the document. Thanks to Ted Hardie for his strawman
proposal that provided assistance with the security section of this
document. Richard Barnes made helpful observations on the
application of authorization policy.
The Participants of the GEOPRIV interim meeting 2008 provided
significant feedback on this document.
James Polk provided input on security in June 2008.
9. References
9.1. Normative References
[I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-16 (work in
progress), August 2009.
[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.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
Winterbottom, et al. Expires April 2, 2011 [Page 14]
Internet-Draft HELD Dereferencing September 2010
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
9.2. Informative references
[I-D.barnes-geopriv-policy-uri]
Barnes, R., Thomson, M., and J. Winterbottom, "Location
Configuration Extensions for Policy Management",
draft-barnes-geopriv-policy-uri-01 (work in progress),
May 2010.
[I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-02 (work in progress), May 2010.
[I-D.ietf-geopriv-held-identity-extensions]
Winterbottom, J., Thomson, M., Tschofenig, H., and R.
Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)",
draft-ietf-geopriv-held-identity-extensions-04 (work in
progress), June 2010.
[I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
and J. Polk, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-21 (work in progress),
January 2010.
[I-D.ietf-sipcore-location-conveyance]
Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-03 (work in
progress), July 2010.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Winterbottom, et al. Expires April 2, 2011 [Page 15]
Internet-Draft HELD Dereferencing September 2010
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 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.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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.
Appendix A. GEOPRIV Using Protocol Compliance
This section describes how use of HELD as a location dereference
protocol complies with the GEOPRIV requirements described in
[RFC3693].
Req. 1. (Location Object generalities):
This section relates to the PIDF-LO [RFC4119] document,
which is used by HELD. These requirements are addressed by
[RFC4119] and [RFC5491].
Req. 2. (Location Object fields):
This section relates to the PIDF-LO [RFC4119] document,
which is used by HELD. These requirements are addressed by
[RFC4119] and [RFC5491].
Req. 3. (Location Data Types):
This section relates to the PIDF-LO [RFC4119] document,
which is used by HELD. These requirements are addressed by
[RFC4119] and [RFC5491].
Section 7.2 of [RFC3693] details the requirements of a "Using
Protocol". These requirements are restated, followed by a statement
Winterbottom, et al. Expires April 2, 2011 [Page 16]
Internet-Draft HELD Dereferencing September 2010
of compliance:
Req. 4. "The using protocol has to obey the privacy and security
instructions coded in the Location Object and in the
corresponding Rules regarding the transmission and storage
of the LO."
Compliant: This document carries the PIDF-LO as is via HTTPS
from the LS to the Location Recipient. The sending and
receiving parties are expected to comply with the
instructions carried inside the object.
Req. 5. "The using protocol will typically facilitate that the keys
associated with the credentials are transported to the
respective parties, that is, key establishment is the
responsibility of the using protocol."
Compliant: This document specifies that authentication of
the LS uses the established public key infrastructure used
by HTTP over TLS [RFC2818]. Authentication of Location
Recipients is either based on distribution of a secret (the
location URI) using a conveyance protocol (for instance,
[I-D.ietf-sipcore-location-conveyance]), allowances are made
for later work to define alternative methods.
Req. 6. "(Single Message Transfer) In particular, for tracking of
small target devices, the design should allow a single
message/packet transmission of location as a complete
transaction."
Not Compliant: The XML encoding specified in [RFC4119] is
not suited to single packet transfers. Use of compressed
content encoding [RFC2616] might allow this condition to be
met.
Section 7.3 of [RFC3693] details the requirements of a "Rule based
Location Data Transfer". These requirements are restated where they
are applicable to this document:
Req. 7. "(LS Rules) The decision of a Location Server to provide a
Location Recipient access to Location Information MUST be
based on Rule Maker-defined Privacy Rules."
Compliant: This document describes two alternative methods
by which a Rule Maker is able to control access to location
information. Rule Maker policy is enforced by the LS when
a location URI is dereferenced. However, this document
does not describe how a location URI is created, or how a
Winterbottom, et al. Expires April 2, 2011 [Page 17]
Internet-Draft HELD Dereferencing September 2010
Rule Maker associates policy with a location URI. These
are covered by other specifications.
Req. 8. (LG Rules) Not Applicable: This relationship between LS and
the source of its information (be that Location Generator
(LG) or LIS) is out of scope for this document.
Req. 9. "(Viewer Rules) A Viewer does not need to be aware of the
full Rules defined by the Rule Maker (because a Viewer
SHOULD NOT retransmit Location Information), and thus a
Viewer SHOULD receive only the subset of Privacy Rules
necessary for the Viewer to handle the LO in compliance
with the full Privacy Rules (such as, instruction on the
time period for which the LO can be retained)."
Compliant: The Rule Maker might define (via mechanisms
outside the scope of this document) which policy rules are
disclosed to other entities. For instance, if [RFC4745] is
used to convey authorization policies from Rule Maker to
LS, this is possible using the parameters specified in
[I-D.ietf-geopriv-policy].
Req. 10. (Full Rule language) Not Applicable: Note however that
Geopriv has defined a rule language capable of expressing a
wide range of privacy rules (see [RFC4745] and
[I-D.ietf-geopriv-policy].
Req. 11. (Limited Rule language) Not Applicable: This requirement
applies to (and is addressed by) PIDF-LO [RFC4119].
Section 7.4 of [RFC3693] details the requirements of "Location Object
Privacy and Security". These requirements are restated where they
are applicable to this document:
Req. 12. (Identity Protection) Compliant: Identity protection of the
Target is provided as long as both of the following
conditions are true:
(a) the location URI is not associated with the identity
of the Target in any context, and
(b) the PIDF-LO does not contain information about the
identity about the Target.
For instance, this requirement is complied with if the
protocol that conveys the location URI does not link the
identity of the Target to the location URI and the LS
doesn't include meaningful identification information in
Winterbottom, et al. Expires April 2, 2011 [Page 18]
Internet-Draft HELD Dereferencing September 2010
the PIDF-LO document. Section 6 recommends that an
unlinked pseudonym is used by the LS.
Req. 13. (Credential Requirements) Compliant: The primary security
mechanism specified in this document is Transport Layer
Security. TLS offers the ability to use different types of
credentials, including symmetric, asymmetric credentials or
a combination of them.
Req. 14. (Security Features) Compliant: Geopriv defines a few
security requirements for the protection of Location
Objects such as mutual end-point authentication, data
object integrity, data object confidentiality and replay
protection. The ability to use Transport Layer security
fulfills most of these requirements. Authentication of
Location Recipients in this document relies on proof of a
shared secret - the location URI. This does not preclude
the addition of more robust authentication procedures.
Req. 15. (Minimal Crypto) Compliant: The mandatory to implement
ciphersuite is provided in the TLS layer security
specification.
Appendix B. Compliance to Location Reference Requirements
This section describes how HELD complies to the location reference
requirements stipulated in [RFC5808]. Compliance to the Location
Configuration Protocol are included in this document.
Note that use of HELD as a location dereference protocol does not
necessarily imply that HELD is the corresponding LCP. This
document is still applicable to HTTP location URIs that are
acquired by other means.
B.1. Requirements for a Location Configuration Protocol
C1. "Location URI support: The location configuration protocol MUST
support a location reference in URI form."
Compliant: HELD only provides location references in URI form.
C2. "Location URI expiration: When a location URI has a limited
validity interval, its lifetime MUST be indicated."
Compliant: HELD indicates the expiry time of location URIs using
the "expires" attribute. [I-D.barnes-geopriv-policy-uri]
provides a way to control expiration of a location URI; a Device
Winterbottom, et al. Expires April 2, 2011 [Page 19]
Internet-Draft HELD Dereferencing September 2010
is able to specify limits on the life time of a HELD context.
C3. "Location URI cancellation: The location configuration protocol
MUST support the ability to request a cancellation of a specific
location URI."
Compliant with Extension: [I-D.barnes-geopriv-policy-uri]
describes how a location URI can be cancelled through the
application of policy. Without extensions, HELD does not
provide a method for cancelling location URIs.
C4. "Location Information Masking: The location URI MUST ensure, by
default, through randomization and uniqueness, that the location
URI does not contain location information specific components."
Compliant: The HELD specification explicitly references this
requirement in providing guidance on the format of the location
URI.
C5. "Target Identity Protection: The location URI MUST NOT contain
information that identifies the Target (e.g., user or device)."
Compliant: The HELD specification provides specific guidance on
the anonymity of the Target with regards to the generation of
location URIs. Section 6 expands on this guidance.
C6. "Reuse indicator: There SHOULD be a way to allow a Target to
control whether a location URI can be resolved once only, or
multiple times."
Not Compliant: Specific extensions to the protocol or
authorization policy formats is needed to alter the default
behavior, which allows unlimited resolution of the location URI.
C7. "Selective disclosure: The location configuration protocol MUST
provide a mechanism that allows the Rule Maker to control what
information is being disclosed about the Target."
Compliant with Extension: Use of policy mechanisms and
[I-D.barnes-geopriv-policy-uri] enable this capability. Note
that this document recommends that only location information be
provided.
C8. "Location URI Not guessable: As a default, the location
configuration protocol MUST return location URIs that are random
and unique throughout the indicated lifetime. A location URI
with 128-bits of randomness is RECOMMENDED."
Winterbottom, et al. Expires April 2, 2011 [Page 20]
Internet-Draft HELD Dereferencing September 2010
Compliant: HELD specifies that location URIs conform to this
requirement.
C9. "Location URI Options: In the case of user-provided
authorization policies, where anonymous or non-guessable
location URIs are not warranted, the location configuration
protocol MAY support a variety of optional location URI
conventions, as requested by a Target to a location
configuration server, (e.g., embedded location information
within the location URI)."
Not Compliant: HELD does not support Device-specified location
URI forms.
B.2. Requirements for a Location Dereference Protocol
D1. "Location URI support: The location dereference protocol MUST
support a location reference in URI form."
Compliant: HELD only provides location references in URI form.
D2. "Authentication: The location dereference protocol MUST include
mechanisms to authenticate both the client and the server."
Partially Compliant: TLS provides means for mutual
authentication. This document only specifies the required
mechanism for server authentication. Client authentication is
not precluded.
D3. "Dereferenced Location Form: The value returned by the
dereference protocol MUST contain a well-formed PIDF-LO
document."
Compliant: HELD requires that location objects are in the form
of a PIDF-LO that complies with [RFC5491].
D4. "Location URI Repeated Use: The location dereference protocol
MUST support the ability for the same location URI to be
resolved more than once, based on dereference server
configuration."
Compliant: A Location Recipient may access and use a location
URI as many times as desired until URI expiration results in the
URI being invalidated. Authorization policies might include
rules that modify this behavior.
Winterbottom, et al. Expires April 2, 2011 [Page 21]
Internet-Draft HELD Dereferencing September 2010
D5. "The location dereference protocol MUST support confidentiality
protection of messages sent between the Location Recipient and
the location server."
Compliant: This document strongly recommends the use of TLS for
confidentiality and HELD mandates its implementation. Unsecured
HTTP is permitted, and some of the associated risks are
described in Section 4.1.
Authors' Addresses
James Winterbottom
Andrew Corporation
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 242 212938
Email: james.winterbottom@andrew.com
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building, New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Winterbottom, et al. Expires April 2, 2011 [Page 22]
Internet-Draft HELD Dereferencing September 2010
Martin Thomson
Andrew Corporation
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com
Martin Dawson
Andrew Corporation
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 2 4221 2992
Email: martin.dawson@andrew.com
Winterbottom, et al. Expires April 2, 2011 [Page 23]