draft-ietf-geopriv-deref-protocol-03.txt   draft-ietf-geopriv-deref-protocol-04.txt 
GEOPRIV J. Winterbottom GEOPRIV J. Winterbottom
Internet-Draft Commscope Internet-Draft Commscope
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: December 25, 2011 Nokia Siemens Networks Expires: May 3, 2012 Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
M. Thomson M. Thomson
M. Dawson M. Dawson
Commscope Commscope
June 23, 2011 October 31, 2011
A Location Dereferencing Protocol Using HELD A Location Dereferencing Protocol Using HELD
draft-ietf-geopriv-deref-protocol-03.txt draft-ietf-geopriv-deref-protocol-04
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. HTTP-Enabled Location Delivery (HELD) protocol to request the
location of the Target.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). 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 December 25, 2011. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 35
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative references . . . . . . . . . . . . . . . . . . 15 9.2. Informative references . . . . . . . . . . . . . . . . . . 15
Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 17 Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 17
Appendix B. Compliance to Location Reference Requirements . . . . 20 Appendix B. Compliance to Location Reference Requirements . . . . 20
B.1. Requirements for a Location Configuration Protocol . . . . 20 B.1. Requirements for a Location Configuration Protocol . . . . 20
B.2. Requirements for a Location Dereference Protocol . . . . . 22 B.2. Requirements for a Location Dereference Protocol . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 can be acquired containing the location of an entity. A location URI can be acquired
using a location configuration protocol, such as HTTP-Enabled using a location configuration protocol, such as HTTP-Enabled
Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration
Protocol (DHCP) location URI option Protocol (DHCP) location URI option
skipping to change at page 4, line 14 skipping to change at page 4, line 14
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)---->| . | . |----(for location URI)-->| . |
: | | : Location | : | | : Location |
. | locationResponse | . Configuration | . | locationResponse | . Configuration |
: |<-----(location URI)-----| : | : |<-----(location URI)-----| : |
. | | . | . | | . |
`- + - - - - - - - - - - - - + -' | `- + - - - - - - - - - - - - + -' |
| | | | | |
| Location Conveyance | | Location Conveyance |
|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>| |~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
| | | | | |
| .- + - - - - - - - - - - - - + -. | .- + - - - - - - - - - - - - + -.
| : | locationRequest | : | : | locationRequest | :
| . |<--------(civic)---------| . | . |<------(for civic)-------| .
| Dereferencing : | | : | Dereferencing : | | :
| . | locationResponse | . | . | locationResponse | .
| : |--------(PIDF-LO)------->| : | : |--------(PIDF-LO)------->| :
| . | | . | . | | .
| `- + - - - - - - - - - - - - + -' | `- + - - - - - - - - - - - - + -'
| | | | | |
Figure 1: Example of Dereference Protocol Exchange Figure 1: Example of Dereference Protocol Exchange
2. Terminology 2. Terminology
skipping to change at page 7, line 29 skipping to change at page 7, line 29
Use of explicit access control provides a Rule Maker greater control Use of explicit access control provides a Rule Maker greater control
over the behaviour of an LS. In contrast to authorization by over the behaviour of an LS. In contrast to authorization by
possession, possession of a this form of location URI does not imply possession, possession of a this form of location URI does not imply
authorization. Since an explicit policy is used to authorize access authorization. Since an explicit policy is used to authorize access
to location information, the location URI can be distributed to many to location information, the location URI can be distributed to many
potential Location Recipients. potential Location Recipients.
Either before creation or dissemination of the location URI, the Rule Either before creation or dissemination of the location URI, the Rule
Maker establishes an authorization policy with the LS. In reference Maker establishes an authorization policy with the LS. In reference
to Figure 2, authorization policies might be established at creation to Figure 2, authorization policies might be established at creation
(Step 1), and need to be established before before the location URI (Step 1), and need to be established before the location URI is
is published (Step 2) to ensure that the policy grants access to the published (Step 2) to ensure that the policy grants access to the
desired Location Recipients. Depending on the mechanism used, it desired Location Recipients. Depending on the mechanism used, it
might also be possible to change authorization policies at any time. might also be possible to change authorization policies at any time.
A possible format for these authorization policies is available with A possible format for these authorization policies is available with
GEOPRIV Common Policy [RFC4745] and Geolocation Policy GEOPRIV Common Policy [RFC4745] and Geolocation Policy
[I-D.ietf-geopriv-policy]. Additional constraints might be [I-D.ietf-geopriv-policy]. Additional constraints might be
established by other means. established by other means.
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
skipping to change at page 11, line 18 skipping to change at page 11, line 18
Content-Length: 87 Content-Length: 87
<?xml version="1.0"?> <?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
Figure 4: Minimal Dereferencing Request Figure 4: Minimal Dereferencing Request
Figure 5 shows the response to the previous request listing both Figure 5 shows the response to the previous request listing both
civic and geodetic location information of the Target's location. civic and geodetic location information of the Target's location.
Again, this is identical to the response in Section 10.1 of [RFC5985] Again, this is identical to the response in Section 10.1 of [RFC5985]
- unless policy specfies otherwise, the Location Recipient receives - unless policy specifies otherwise, the Location Recipient receives
the same information as the Device. the same information as the Device.
HTTP/1.1 200 OK HTTP/1.1 200 OK
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/held+xml Content-Type: application/held+xml
Content-Length: 676 Content-Length: 676
skipping to change at page 15, line 50 skipping to change at page 15, line 50
[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-dhcp-lbyr-uri-option] [I-D.ietf-geopriv-dhcp-lbyr-uri-option]
Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
and IPv6 Option for a Location Uniform Resource Identifier and IPv6 Option for a Location Uniform Resource Identifier
(URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-11 (work (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-12 (work
in progress), February 2011. in progress), October 2011.
[I-D.ietf-geopriv-policy] [I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
and J. Polk, "Geolocation Policy: A Document Format for Morris, J., and M. Thomson, "Geolocation Policy: A
Expressing Privacy Preferences for Location Information", Document Format for Expressing Privacy Preferences for
draft-ietf-geopriv-policy-23 (work in progress), Location Information", draft-ietf-geopriv-policy-25 (work
March 2011. in progress), October 2011.
[I-D.ietf-geopriv-policy-uri] [I-D.ietf-geopriv-policy-uri]
Barnes, R., Thomson, M., Winterbottom, J., and H. Barnes, R., Thomson, M., Winterbottom, J., and H.
Tschofenig, "Location Configuration Extensions for Policy Tschofenig, "Location Configuration Extensions for Policy
Management", draft-ietf-geopriv-policy-uri-01 (work in Management", draft-ietf-geopriv-policy-uri-02 (work in
progress), June 2011. progress), October 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-08 (work in draft-ietf-sipcore-location-conveyance-09 (work in
progress), May 2011. progress), September 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 17, line 42 skipping to change at page 17, line 42
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 restated, followed by a statement Protocol". These requirements are restated, followed by a statement
of compliance: 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."
Compliant: This document carries the PIDF-LO as is via HTTPS Compliant: This specification describes the use of HTTP over
from the LS to the Location Recipient. The sending and TLS for carring the PIDF-LO from the LS to the Location
receiving parties are expected to comply with the Recipient. The sending and receiving parties are expected
instructions carried inside the object. to comply with the instructions carried inside the object.
Though discouraged, using unsecured http: URIs is permitted.
Using unsecured HTTP is likely to result in non-compliance
with this requirement.
Req. 5. "The using protocol will typically facilitate that the keys Req. 5. "The using protocol will typically facilitate that the keys
associated with the credentials are transported to the associated with the credentials are transported to the
respective parties, that is, key establishment is the respective parties, that is, key establishment is the
responsibility of the using protocol." responsibility of the using protocol."
Compliant: This document specifies that authentication of Compliant: This document specifies that authentication of
the LS uses the established public key infrastructure used the LS uses the established public key infrastructure used
by HTTP over TLS [RFC2818]. Authentication of Location by HTTP over TLS [RFC2818]. Authentication of Location
Recipients is either based on distribution of a secret (the Recipients is either based on distribution of a secret (the
location URI) using a conveyance protocol (for instance, location URI) using a conveyance protocol (for instance,
[I-D.ietf-sipcore-location-conveyance]), allowances are made [I-D.ietf-sipcore-location-conveyance]), allowances are made
for later work to define alternative methods. for later work to define alternative methods.
Req. 6. "(Single Message Transfer) In particular, for tracking of Req. 6. "(Single Message Transfer) In particular, for tracking of
small target devices, the design should allow a single small target devices, the design should allow a single
skipping to change at page 19, line 9 skipping to change at page 19, line 14
with the full Privacy Rules (such as, instruction on the with the full Privacy Rules (such as, instruction on the
time period for which the LO can be retained)." time period for which the LO can be retained)."
Compliant: The Rule Maker might define (via mechanisms Compliant: The Rule Maker might define (via mechanisms
outside the scope of this document) which policy rules are outside the scope of this document) which policy rules are
disclosed to other entities. For instance, if [RFC4745] is disclosed to other entities. For instance, if [RFC4745] is
used to convey authorization policies from Rule Maker to used to convey authorization policies from Rule Maker to
LS, this is possible using the parameters specified in LS, this is possible using the parameters specified in
[I-D.ietf-geopriv-policy]. [I-D.ietf-geopriv-policy].
In order to comply with these rules, a Location Recipient
MUST NOT redistribute a location URI without express
permission. Depending on the access control model, the
location URI might be secret (see Section 3.3 of
[RFC5808]).
Req. 10. (Full Rule language) Not Applicable: Note however that Req. 10. (Full Rule language) Not Applicable: Note however that
Geopriv has defined a rule language capable of expressing a Geopriv has defined a rule language capable of expressing a
wide range of privacy rules (see [RFC4745] and wide range of privacy rules (see [RFC4745] and
[I-D.ietf-geopriv-policy]. [I-D.ietf-geopriv-policy].
Req. 11. (Limited Rule language) Not Applicable: This requirement Req. 11. (Limited Rule language) Not Applicable: This requirement
applies to (and is addressed by) PIDF-LO [RFC4119]. applies to (and is addressed by) PIDF-LO [RFC4119].
Section 7.4 of [RFC3693] details the requirements of "Location Object Section 7.4 of [RFC3693] details the requirements of "Location Object
Privacy and Security". These requirements are restated where they Privacy and Security". These requirements are restated where they
are applicable to this document: are applicable to this document:
Req. 12. (Identity Protection) Compliant: Identity protection of the Req. 12. (Identity Protection) Compliant: Identity protection of the
Target is provided as long as both of the following Target is provided as long as both of the following
conditions are true: 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) the PIDF-LO does not contain information about the (b) the PIDF-LO does not contain information about the
identity about the Target. identity of the Target.
For instance, this requirement is complied with if the For instance, this requirement is complied with if the
protocol that conveys the location URI does not link the protocol that conveys the location URI does not link the
identity of the Target to the location URI and the LS identity of the Target to the location URI and the LS
doesn't include meaningful identification information in doesn't include meaningful identification information in
the PIDF-LO document. Section 6 recommends that an the PIDF-LO document. Section 6 recommends that an
unlinked pseudonym is used by the LS. 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
skipping to change at page 20, line 33 skipping to change at page 20, line 48
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.ietf-geopriv-policy-uri] provides the "expires" attribute. [I-D.ietf-geopriv-policy-uri] provides
a way to control expiration of a location URI; a Device is able a way to control expiration of a location URI.
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.ietf-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.
skipping to change at page 21, line 36 skipping to change at page 21, line 52
[I-D.ietf-geopriv-policy-uri] enable this capability. Note that [I-D.ietf-geopriv-policy-uri] enable this capability. Note 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. The amount of randomness is not specifically
identified since it depends on a number of factors that change
over time, such as the number of valid location URIs, the
validity period of those URIs and the rate that guesses can be
made.
C9. "Location URI Options: In the case of user-provided C9. "Location URI Options: In the case of user-provided
authorization policies, where anonymous or non-guessable authorization policies, where anonymous or non-guessable
location URIs are not warranted, the location configuration location URIs are not warranted, the location configuration
protocol MAY support a variety of optional location URI protocol MAY support a variety of optional location URI
conventions, as requested by a Target to a location conventions, as requested by a Target to a location
configuration server, (e.g., embedded location information configuration server, (e.g., embedded location information
within the location URI)." within the location URI)."
Not Compliant: HELD does not support Device-specified location Not Compliant: HELD does not support Device-specified location
 End of changes. 20 change blocks. 
30 lines changed or deleted 45 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/