< draft-winterbottom-geopriv-deref-protocol-03.txt   draft-winterbottom-geopriv-deref-protocol-04.txt >
GEOPRIV J. Winterbottom GEOPRIV J. Winterbottom
Internet-Draft Andrew Corporation Internet-Draft Andrew Corporation
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: August 27, 2009 Nokia Siemens Networks Expires: January 28, 2010 Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
M. Thomson M. Thomson
M. Dawson M. Dawson
Andrew Corporation Andrew Corporation
February 23, 2009 July 27, 2009
An HTTPS Location Dereferencing Protocol Using HELD A Location Dereferencing Protocol Using HELD
draft-winterbottom-geopriv-deref-protocol-03 draft-winterbottom-geopriv-deref-protocol-04
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2009. This Internet-Draft will expire on January 28, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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 secure HELD URI that can be used in conjunction Recipient possesses a secure HELD URI that can be used in conjunction
with the HELD protocol to request the location of the Target. with the HELD protocol to request the location of the Target.
A held: URI scheme is defined for use with resources that can be
accessed using the mechanisms defined in this document. [Note: this
is a provisional inclusion only]
Table of Contents Table of Contents
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
4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 7 4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 7
4.1. Using a held: URI . . . . . . . . . . . . . . . . . . . . 8 4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 8
4.2. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 9 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. The held: URI Scheme . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2. Informative references . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 18
9.2. Informative references . . . . . . . . . . . . . . . . . . 16 Appendix B. Compliance to Location Reference Requirements . . . . 21
Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 21 B.1. Requirements for a Location Configuration Protocol . . . . 21
Appendix B. Compliance to Location Reference Requirements . . . . 23 B.2. Requirements for a Location Dereference Protocol . . . . . 24
B.1. Requirements for a Location Configuration Protocol . . . . 24
B.2. Requirements for a Location Dereference Protocol . . . . . 26
1. Introduction 1. Introduction
Provision of location information by reference Provision of location information by reference
[I-D.ietf-geopriv-lbyr-requirements] involves the creation of a [I-D.ietf-geopriv-lbyr-requirements] involves the creation of a
resource that is identified by a URI. This "location URI" can resource that is identified by a "location URI". A "location URI"
identify a temporary resource, created in response to a HTTP-Enabled identifies resource that contains the location of an entity. A
Location Delivery (HELD) [I-D.ietf-geopriv-http-location-delivery] location URI might be a temporary resource, created in response to a
request. A location URI does not necessarily include any useful HTTP-Enabled Location Delivery (HELD)
information, instead the URI is "dereferenced" by a Location [I-D.ietf-geopriv-http-location-delivery] request. A location URI
Recipient to acquire location information. This document specifies does not intrinsically include location information, instead the URI
how a recipient of a location URI uses that URI to retrieve location is "dereferenced" by a Location Recipient to acquire location
information. information. This document specifies how a holder of a location URI
uses that URI to retrieve location information.
The HELD protocol, as described in The HELD protocol, as described in
[I-D.ietf-geopriv-http-location-delivery], defines a use of HTTP that [I-D.ietf-geopriv-http-location-delivery], defines a use of HTTP that
enables location configuration - the process where a Device acquires enables location configuration - the process where a Device acquires
location information about itself. A part of location configuration location information about itself. A part of location configuration
is the provision of a location URI. However, HELD does not describe is the provision of a location URI. However, HELD does not describe
how such a URI is used; this document provides that definition. how such a URI is used; this document 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 location object in the form of a Presence result of this process is location object in the form of a Presence
Information Data Format - Location Object (PIDF-LO) document Information Data Format - Location Object (PIDF-LO) document
[RFC4119]. A constrained set of HELD features are defined such that [RFC4119]. A constrained set of HELD features are defined such that
it is suitable for use as a location dereference protocol it is suitable for use as a location dereference protocol
[I-D.ietf-geopriv-lbyr-requirements]. Use as a location dereference [I-D.ietf-geopriv-lbyr-requirements]. Use as a location dereference
protocol requires use of the Transport Layer Security (TLS) binding protocol requires use of the Transport Layer Security (TLS) binding
for HTTP [RFC2818]. 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 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 the HELD base specification, described in
[I-D.ietf-geopriv-http-location-delivery]. Furthermore, the HELD [I-D.ietf-geopriv-http-location-delivery]. Furthermore, the HELD
response from the LIS towards the Location Recipient not only response from the LIS towards the Location Recipient not only
provides the PIDF-LO but also encapsulates supplementary information, provides the PIDF-LO but also encapsulates supplementary information,
such as error messages, back to the Location Recipient. such as error messages, back to the Location Recipient.
LIS discovery [I-D.ietf-geopriv-lis-discovery] uses "https:" or Location URIs created for use with HELD dereferencing use the
"http:" URIs to identify the target of a HELD location configuration "https:" or "http:" scheme for the HTTP binding of HELD. The
request. In contrast, location URIs can be used in a much wider behaviour described in this document can be used by Location
scope; the context where a location URI is found might not convey Recipients that are aware of the fact that the URI is a location URI.
information about how it could be used to a recipient. This document
mints a new URI scheme, the "held:" URI, to clearly distinguish
resources that can be accessed using HELD from other URIs.
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. location configuration and conveyance.
[I-D.ietf-geopriv-lbyr-requirements] contains more information on [I-D.ietf-geopriv-lbyr-requirements] contains more information on
this scenario and others like it. this scenario and others like it.
+-------------+ +-------------+
+------------+ | Location | +-----------+ +------------+ | Location | +-----------+
| End Device | | Information | | Location | | End Device | | Information | | Location |
| (Target) | | Server | | Recipient | | (Target) | | Server | | Recipient |
+-----+------+ +------+------+ +-----+-----+ +-----+------+ +------+------+ +-----+-----+
skipping to change at page 5, line 34 skipping to change at page 5, line 33
location configuration, conveyance and dereference. location configuration, conveyance and dereference.
+---------+--------+ Location +-----------+ +---------+--------+ Location +-----------+
| | | Dereference | Location | | | | Dereference | Location |
| LIS - LS +---------------+ Recipient | | LIS - LS +---------------+ Recipient |
| | | Protocol | | | | | Protocol | |
+----+----+--------+ (3) +-----+-----+ +----+----+--------+ (3) +-----+-----+
| `. | | `. |
| Policy `. | | Policy `. |
Location | Exchange `. | Location | Exchange `. |
Configuration | (*) | Location | Configuration | (*) | |
Protocol | +----+----+ Conveyance | Protocol | +----+----+ |
(1) | | Rule | Protocol ; (1) | | Rule | Location |
| | Maker | (2) / | | Maker | Conveyance |
+-----+----+ +---------+ ,' +-----+----+ +---------+ Protocol |
| | _,-' | | (2) |
| Target +----------------------' | Target +------------------------------+
| | | |
+----------+ +----------+
Figure 2: Communication Model Figure 2: Communication Model
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, nor does it constrain the usage with specific authorization model, nor does it constrain the usage with
regard to these models in any way. Additionally, it is possible to regard to these models in any way. Additionally, it is possible to
combine certain parts of both models. combine certain parts of both models.
skipping to change at page 6, line 19 skipping to change at page 6, line 17
HELD as a location configuration protocol (LCP). HELD as a location configuration protocol (LCP).
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-sip-location-conveyance]). This step is shown in (2) [I-D.ietf-sip-location-conveyance]). This step is shown in (2)
of Figure 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). Depending on the URI
scheme of the location URI dereferencing might, as is the case scheme of the location URI dereferencing might, as is the case
for a "held:" URI, be performed as described in this document. for "https:" or "http:" URIs, be performed as described in this
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 constructed such that it is hard to guess (see C9 of
skipping to change at page 7, line 51 skipping to change at page 7, line 51
The LS enforces the authorization policy when a Location Recipient The LS enforces the authorization policy when a Location Recipient
dereferences the URI. Explicit authorization policies allow a Rule dereferences the URI. Explicit authorization policies allow a Rule
Maker to specify the identity of Location Recipients, constrain the Maker to specify the identity of Location Recipients, constrain the
accuracy and form of location information, and to control other accuracy and form of location information, and to control other
aspects of the authorization process. aspects of the authorization process.
4. HELD Dereference Protocol 4. HELD Dereference Protocol
This section describes how HELD can be used to dereference a location This section describes how HELD can be used to dereference a location
URI. URI. This process can be applied when a Location Recipient is in
possession of a location URI with a "https:" or "http:" URI scheme.
[[This version of the document describes a held: URI and its usage.
It is the consensus of the authors of this document that the cost of
a new URI scheme is not justified by the benefits provided. The
intent of the inclusion of the scheme in this version of the document
is to provide a concrete basis for discussion of the issue. The
following is a summary of arguments already presented:
For a new scheme: The benefit provided by the held: URI scheme is
the explicit indication that the URI is a reference to location
information and that HELD can be used. If the Location Recipient
has specific preferences for location information, then
dereferencing without this explicit indication requires some trial
and error. Without the explicit indication, a generic UA like a
web browser might need to make a second request once the
destination is identified as a HELD LS.
Against: The Location Recipient is still likely to need to use
contextual information to identify the subject of the location
information (c.f. rules on using unlinked pseudonyms in the
PIDF-LO). Since some contextual information is required no matter
what circumstances, requiring that context also identify the type
of URI is not a significant leap. This approach is taken for many
web services: RESTful services, SOAP, and so forth.
The costs involved in minting a new URI scheme are non-trivial.
In particular, new URI schemes cannot be used by existing software
without some modification. Generic UAs like web browsers can use
the HELD MIME type (application/held+xml) to identify that the URI
is a location URI. Once identified thus, if more specific
information is required, a using application is able to make a
second request.
]]
4.1. Using a held: URI
Section 7.1 contains the registration template for a "held:" URI
scheme. This URI indicates a resource that is able to provide the
location of an entity, accessible using the HELD protocol, as
described in this section.
A Location Recipient that wishes to dereference a "held:" URI A Location Recipient that wishes to dereference an "https:" or
performs a HELD request to the equivalent "https:" URI. The "https:" "http:" URI performs a HELD request on HTTP to the identified
URI is found by replacing the "held:" scheme in the URI with resource.
"https:". A limited subset of HELD is used for this request, as
defined in Section 4.2.
For example, for "held://ls.example.com/12345", the Location Note: In many cases, an "http:" URI does not provide sufficient
Recipient makes a HELD request to "https://ls.example.com/12345". 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 TLS connections to the LS, as The Location Recipient establishes a connection to the LS, as
described in [RFC2818]. The TLS ciphersuite TLS_NULL_WITH_NULL_NULL described in [RFC2818]. The TLS ciphersuite TLS_NULL_WITH_NULL_NULL
MUST NOT be used. The LS MUST be authenticated to ensure that the MUST NOT be used. The LS MUST be authenticated to ensure that the
correct server is contacted. Given that a location URI does not correct server is contacted. Given that a location URI does not
indicate the authorization model used, the Location Recipient MUST be indicate the authorization model used, the Location Recipient MUST be
prepared to provide authentication information unless it has prepared to provide authentication information unless it has external
information to the contrary. This document does not specify how the information on the authorization model used by the URI. This
LS authenticates the Location Recipient; a Location Recipient MUST document does not specify how the LS authenticates the Location
support provision of a client certificate during TLS session creation Recipient; however, a Location Recipient MUST support provision of a
and HTTP digest authentication [RFC2617], unless these authentication client certificate during TLS session creation and HTTP digest
methods are known to be inapplicable. authentication [RFC2617], unless these authentication methods are
known to be inapplicable.
A Location Recipient MAY use an "https:" or "http:" URI as a location
URI and make a HELD request. The Location Recipient relies on
external information to determine that a "https:" or "http:" URI is a
location URI since these URIs contain no inherent indication of their
purpose.
Note: An "http:" URI SHOULD NOT be used for location URIs. Lack of
encryption and ineffectual authentication mechanisms mean that the
Rule Maker has no control over who receives location information
and the Location Recipient has no assurance that the information
is correct.
4.2. HELD Usage Profile 4.1. HELD Usage Profile
Use of HELD as a location dereference protocol is largely the same as Use of HELD as a location dereference protocol is largely the same as
its use as a location configuration protocol. Aside from the its use as a location configuration protocol. Aside from the
restrictions noted in this document, HELD semantics do not differ restrictions noted in this document, HELD semantics do not differ
from those established in [I-D.ietf-geopriv-http-location-delivery]. from those established in [I-D.ietf-geopriv-http-location-delivery].
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 supported by the LS: "responseTime", following MUST NOT be accepted by the LS: "responseTime",
"locationType" (including the associated "exact" attribute). Other "locationType" (including the associated "exact" attribute). Other
specifications MUST explicitly describe how other requests or specifications MUST explicitly describe whether other requests or
parameters apply to dereference requests. The LS MUST ignore any parameters apply to dereference requests and how they are to be
parameters that it does not understand unless it knows the parameters interpreted if they are permitted. The LS MUST ignore any parameters
to be invalid, such as those defined in that it does not understand unless it knows the parameters to be
invalid, such as those defined in
[I-D.winterbottom-geopriv-held-identity-extensions]. If parameters [I-D.winterbottom-geopriv-held-identity-extensions]. If parameters
are known to be invalid, the LS MAY generate a HELD error response. are known to be invalid, the LS MAY generate a HELD error response.
The LS MUST NOT generate any location URIs or provide a The LS MUST NOT generate any location URIs or provide a
"locationUriSet" in response to a dereference request. If the "locationUriSet" in response to a dereference request. If the
location request contains a "locationType" element that includes location request contains a "locationType" element that includes
"locationURI", this parameter is either ignored or rejected as "locationURI", this parameter is either ignored or rejected as
appropriate, based on the associated "exact" attribute. appropriate, based on the associated "exact" attribute.
This document requires additional HTTP features from Location This document requires additional HTTP features from Location
Recipients that are not required of Devices in HELD. HTTP digest Recipients that are not required of Devices in HELD. HTTP digest
authentication [RFC2617] MUST be supported by Location Recipients, authentication [RFC2617] MUST be supported by Location Recipients,
unless there is no means to provide such authentication information. unless there is no means to provide such authentication information.
5. Examples 5. Examples
The example in Figure 3 shows the simplest form of dereferencing The example in Figure 3 shows the simplest form of dereferencing
request using HELD to the URI request using HELD to the location URI
"held://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that "https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that
this differs from the example in Section 10.1 of this differs from the example in Section 10.1 of
[I-D.ietf-geopriv-http-location-delivery] is in the request URI and [I-D.ietf-geopriv-http-location-delivery] is in the request URI and
the source of the URI. the source of the URI.
POST /uri/w3g61nf5n66p0 HTTP/1.1 POST /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152 Host: ls.example.com:49152
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 87 Content-Length: 87
<?xml version="1.0"?> <?xml version="1.0"?>
skipping to change at page 12, line 36 skipping to change at page 11, line 36
Target, unless policy is provided that allows this. To this end, an Target, unless policy is provided that allows this. To this end, an
unlinked pseudonym MUST be provided in the "entity" attribute of the unlinked pseudonym MUST be provided in the "entity" attribute of the
PIDF-LO document. PIDF-LO document.
Further security considerations and requirements relating to the use Further security considerations and requirements relating to the use
of location URIs are described in of location URIs are described in
[I-D.ietf-geopriv-lbyr-requirements]. [I-D.ietf-geopriv-lbyr-requirements].
7. IANA Considerations 7. IANA Considerations
This document registers a new URI scheme, the "held:" URI. This document makes no request of IANA.
[[IANA/RFC-EDITOR: Please replace RFCXXXX with the assigned number
of this document throughout the following section and remove this
note.]]
7.1. The held: URI Scheme
The following template registers a new "held:" URI scheme, following
the guidelines in [RFC4395]:
URI scheme name: held
Status: permanent
URI scheme syntax: The "held:" scheme uses identical syntax to the
http: scheme [RFC2616]. The following ABNF [RFC5234] uses the
updated URI syntax from [RFC3986]:
held-URI = "held://" authority path-abempty
[ "?" query ] [ "#" fragment ]
The default TCP port for the "held:" URI scheme is 443, since use
of this URI implies use of HTTP over TLS [RFC2818]. User
information MUST NOT be included in a "held:" URI, inclusion of
these parameters in the ABNF is allowed only to retain
compatibility with "http:" and "https:" URIs.
URI scheme semantics: A "held:" URI indicates a resource that can be
accessed by the HELD protocol. The resource indicates the
physical location of a particular entity. The limited profile of
HELD that can be used for this purpose is described in Section 4.2
of RFCXXXX.
Encoding considerations: Encoding considerations are identical to
those of "http:" URIs. The URI MAY contain fragments of human-
readable text.
Applications/protocols that use this URI scheme name: The "held:"
URI scheme is intended for use as a location URI
[I-D.ietf-geopriv-lbyr-requirements]. A location URI is a
reference to physical location information for a given Target
entity. The identity of the Target entity is derived either from
the context that URI appears in, or from the PIDF-LO [RFC4119]
document that is the result of successfully using the URI.
A "held:" URI can be published through a variety of means in place
of a representation of the physical location of an entity. For
instance, a "held:" URI might be published on a web page to
provide a means to acquire a user's current location. In one
known protocol use, a "held:" URI is conveyed in Session
Initiation Protocol (SIP) signalling
[I-D.ietf-sip-location-conveyance] to indicate to a user agent
server (UAS) the location of the initiating user agent client
(UAC).
Interoperability considerations: No known considerations.
Security considerations: See Section 6 of RFCXXXX.
Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin
Thomson (martin.thomson@andrew.com).
Author/Change controller: The IESG.
References: RFCXXXX [[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. document.
The authors would like to thank the participants of the GEOPRIV The authors would like to thank the participants of the GEOPRIV
skipping to change at page 14, line 39 skipping to change at page 12, line 19
[I-D.ietf-geopriv-http-location-delivery] Barnes, M., [I-D.ietf-geopriv-http-location-delivery] Barnes, M.,
Winterbottom, Winterbottom,
J., Thomson, M., J., Thomson, M.,
and B. Stark, and B. Stark,
"HTTP Enabled "HTTP Enabled
Location Location
Delivery Delivery
(HELD)", draft- (HELD)", draft-
ietf-geopriv- ietf-geopriv-
http-location- http-location-
delivery-12 delivery-15
(work in (work in
progress), progress),
January 2009. June 2009.
[I-D.ietf-geopriv-pdif-lo-profile] Winterbottom,
J., Thomson, M.,
and H.
Tschofenig,
"GEOPRIV PIDF-LO
Usage
Clarification,
Considerations
and
Recommendations"
, draft-ietf-
geopriv-pdif-lo-
profile-14 (work
in progress),
November 2008.
[RFC2119] Bradner, S., [RFC2119] Bradner, S.,
"Key words for "Key words for
use in RFCs to use in RFCs to
Indicate Indicate
Requirement Requirement
Levels", BCP 14, Levels", BCP 14,
RFC 2119, RFC 2119,
March 1997. March 1997.
skipping to change at page 16, line 45 skipping to change at page 14, line 9
[RFC5234] Crocker, D. and [RFC5234] Crocker, D. and
P. Overell, P. Overell,
"Augmented BNF "Augmented BNF
for Syntax for Syntax
Specifications: Specifications:
ABNF", STD 68, ABNF", STD 68,
RFC 5234, RFC 5234,
January 2008. January 2008.
[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 9.2. Informative references
[I-D.barnes-geopriv-lo-sec] Barnes, R., [I-D.barnes-geopriv-lo-sec] Barnes, R.,
Lepinski, M., Lepinski, M.,
Cooper, A.,
Morris, J.,
Tschofenig, H., Tschofenig, H.,
and H. and H.
Schulzrinne, Schulzrinne, "An
"Additional Architecture for
Location and
Location Privacy Location Privacy
Considerations", in Internet
draft-barnes- Applications", d
raft-barnes-
geopriv-lo-sec- geopriv-lo-sec-
04 (work in 05 (work in
progress), progress),
January 2009. March 2009.
[I-D.garcia-simple-indirect-presence-publish] Garcia-Martin,
M., Tschofenig,
H., and H.
Schulzrinne,
"Indirect
Presence
Publication with
the Session
Initiation
Protocol(SIP)",
draft-garcia-
simple-indirect-
presence-
publish-00 (work
in progress),
February 2008.
[I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. [I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H.
and H. and H.
Schulzrinne, Schulzrinne,
"GEOPRIV Layer 7 "GEOPRIV Layer 7
Location Location
Configuration Configuration
Protocol; Protocol;
Problem Problem
Statement and Statement and
Requirements", d Requirements", d
raft-ietf- raft-ietf-
geopriv-l7-lcp- geopriv-l7-lcp-
ps-09 (work in ps-10 (work in
progress), progress),
February 2009. July 2009.
[I-D.ietf-geopriv-lbyr-requirements] Marshall, R., [I-D.ietf-geopriv-lbyr-requirements] Marshall, R.,
"Requirements "Requirements
for a Location- for a Location-
by-Reference by-Reference
Mechanism", draf Mechanism", draf
t-ietf-geopriv- t-ietf-geopriv-
lbyr- lbyr-
requirements-05 requirements-07
(work in (work in
progress), progress),
November 2008. February 2009.
[I-D.ietf-geopriv-lis-discovery] Thomson, M. and [I-D.ietf-geopriv-lis-discovery] Thomson, M. and
J. Winterbottom, J. Winterbottom,
"Discovering the "Discovering the
Local Location Local Location
Information Information
Server (LIS)", d Server (LIS)", d
raft-ietf- raft-ietf-
geopriv-lis- geopriv-lis-
discovery-07 discovery-11
(work in (work in
progress), progress),
February 2009. May 2009.
[I-D.ietf-geopriv-policy] Schulzrinne, H., [I-D.ietf-geopriv-policy] Schulzrinne, H.,
Tschofenig, H., Tschofenig, H.,
Morris, J., Morris, J.,
Cuellar, J., and Cuellar, J., and
J. Polk, J. Polk,
"Geolocation "Geolocation
Policy: A Policy: A
Document Format Document Format
for Expressing for Expressing
Privacy Privacy
Preferences for Preferences for
Location Location
Information", dr Information", dr
aft-ietf- aft-ietf-
geopriv-policy- geopriv-policy-
20 (work in 21 (work in
progress), progress),
February 2009. July 2009.
[I-D.ietf-sip-location-conveyance] Polk, J. and B. [I-D.ietf-sip-location-conveyance] Polk, J. and B.
Rosen, "Location Rosen, "Location
Conveyance for Conveyance for
the Session the Session
Initiation Initiation
Protocol", draft Protocol", draft
-ietf-sip- -ietf-sip-
location- location-
conveyance-12 conveyance-13
(work in (work in
progress), progress),
November 2008. March 2009.
[I-D.winterbottom-geopriv-held-context] Winterbottom, [I-D.winterbottom-geopriv-held-context] Winterbottom,
J., Tschofenig, J., Tschofenig,
H., and M. H., and M.
Thomson, "HELD Thomson,
Protocol Context "Establishing
Management Location URI
Extensions", dra Contexts using
ft-winterbottom- HTTP-Enabled
Location
Delivery
(HELD)", draft-
winterbottom-
geopriv-held- geopriv-held-
context-03 (work context-04 (work
in progress), in progress),
September 2008. April 2009.
[I-D.winterbottom-geopriv-held-identity-extensions] Thomson, M., [I-D.winterbottom-geopriv-held-identity-extensions] Thomson, M.,
Tschofenig, H., Tschofenig, H.,
Barnes, R., and Barnes, R., and
J. Winterbottom, J. Winterbottom,
"HELD Identity "Use of Target
Extensions", dra Identity in
ft-winterbottom- HTTP-Enabled
Location
Delivery
(HELD)", draft-
winterbottom-
geopriv-held- geopriv-held-
identity- identity-
extensions-08 extensions-09
(work in (work in
progress), progress),
January 2009. February 2009.
[RFC3261] Rosenberg, J., [RFC3261] Rosenberg, J.,
Schulzrinne, H., Schulzrinne, H.,
Camarillo, G., Camarillo, G.,
Johnston, A., Johnston, A.,
Peterson, J., Peterson, J.,
Sparks, R., Sparks, R.,
Handley, M., and Handley, M., and
E. Schooler, E. Schooler,
"SIP: Session "SIP: Session
skipping to change at page 21, line 17 skipping to change at page 18, line 42
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
[RFC4119] and [I-D.ietf-geopriv-pdif-lo-profile]. [RFC4119] and [RFC5491].
Req. 2. (Location Object fields): Req. 2. (Location Object fields):
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
[RFC4119] and [I-D.ietf-geopriv-pdif-lo-profile]. [RFC4119] and [RFC5491].
Req. 3. (Location Data Types): Req. 3. (Location Data Types):
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
[RFC4119] and [I-D.ietf-geopriv-pdif-lo-profile]. [RFC4119] and [RFC5491].
Section 7.2 of [RFC3693] details the requirements of a "Using Section 7.2 of [RFC3693] details the requirements of a "Using
Protocol". These requirements are repeated here for reference, Protocol". These requirements are repeated here for reference,
followed by a statement of compliance: followed by a statement of compliance:
Req. 4. "The using protocol has to obey the privacy and security Req. 4. "The using protocol has to obey the privacy and security
instructions coded in the Location Object and in the instructions coded in the Location Object and in the
corresponding Rules regarding the transmission and storage corresponding Rules regarding the transmission and storage
of the LO." of the LO."
skipping to change at page 23, line 28 skipping to change at page 21, line 9
are applicable to this document: are applicable to this document:
Req. 12. (Identity Protection) Potentially Compliant: Identity Req. 12. (Identity Protection) Potentially Compliant: Identity
protection of the Target is provided as long as both of the protection of the Target is provided as long as both of the
following conditions are true: following conditions are true:
(a) the location URI is not associated with the identity (a) the location URI is not associated with the identity
of the Target in any context, and of the Target in any context, and
(b) if the PIDF-LO does not contain information about the (b) if the PIDF-LO does not contain information about the
identity about the Target. Section 6 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
the PIDF-LO document. Section 6 recommends that an
unlinked pseudonym is used by the LS.
Req. 13. (Credential Requirements) Compliant: The primary security Req. 13. (Credential Requirements) Compliant: The primary security
mechanism specified in this document is Transport Layer mechanism specified in this document is Transport Layer
Security. TLS offers the ability to use different types of Security. TLS offers the ability to use different types of
credentials, including symmetric, asymmetric credentials or credentials, including symmetric, asymmetric credentials or
a combination of them. a combination of them.
Req. 14. (Security Features) Compliant: Geopriv defines a few Req. 14. (Security Features) Compliant: Geopriv defines a few
security requirements for the protection of Location security requirements for the protection of Location
Objects such as mutual end-point authentication, data Objects such as mutual end-point authentication, data
skipping to change at page 26, line 40 skipping to change at page 24, line 32
Compliant: TLS provides means for mutual authentication. This Compliant: TLS provides means for mutual authentication. This
document only specifies the required mechanism for server document only specifies the required mechanism for server
authentication. authentication.
D4. "Dereferenced Location Form: The value returned by the D4. "Dereferenced Location Form: The value returned by the
dereference protocol MUST contain a well-formed PIDF-LO dereference protocol MUST contain a well-formed PIDF-LO
document." document."
Compliant: HELD requires that location objects are in the form Compliant: HELD requires that location objects are in the form
of a PIDF-LO that complies with of a PIDF-LO that complies with [RFC5491].
[I-D.ietf-geopriv-pdif-lo-profile].
D5. "Location URI Repeated Use: The location dereference protocol D5. "Location URI Repeated Use: The location dereference protocol
MUST support the ability for the same location URI to be MUST support the ability for the same location URI to be
resolved more than once, based on dereference server resolved more than once, based on dereference server
configuration." configuration."
Compliant: A Location Recipient may access and use a location Compliant: A Location Recipient may access and use a location
URI as many times as desired until URI expiration results in URI as many times as desired until URI expiration results in
the URI being invalidated. Authorization policies might the URI being invalidated. Authorization policies might
include rules that modify this behavior. include rules that modify this behavior.
skipping to change at page 27, line 48 skipping to change at page 25, line 38
access to location information based on proof of knowledge of access to location information based on proof of knowledge of
the location URI. the location URI.
D10. "Location Confidentiality: The dereference protocol MUST D10. "Location Confidentiality: The dereference protocol MUST
support encryption of messages sent between the location support encryption of messages sent between the location
dereference client and the location dereference server, and MAY dereference client and the location dereference server, and MAY
alternatively provide messaging unencrypted." alternatively provide messaging unencrypted."
Compliant: This document strongly recommends the use of TLS Compliant: This document strongly recommends the use of TLS
for confidentiality. Unsecured HTTP is permitted, and some of for confidentiality. Unsecured HTTP is permitted, and some of
the associated risks are described in Section 4.2. the associated risks are described in Section 4.1.
D11. "Location URI Authorization Model: The location dereference D11. "Location URI Authorization Model: The location dereference
protocol SHOULD indicate whether the requested location URI protocol SHOULD indicate whether the requested location URI
conforms to the access control authorization model or the conforms to the access control authorization model or the
possession authorization model." possession authorization model."
Not Compliant: The basis of an authorization decision is Not Compliant: The basis of an authorization decision is
potentially private information; this document does not provide potentially private information; this document does not provide
this indication. Note that the recipient of a location URI is this indication. Note that the recipient of a location URI is
expected to respect the confidentiality of a location URI as if expected to respect the confidentiality of a location URI as if
 End of changes. 54 change blocks. 
263 lines changed or deleted 146 lines changed or added

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