Geopriv J. Winterbottom
Internet-Draft M. Thomson
Intended status: Best Current M. Dawson
Practice Andrew Corporation
Expires: December 3, 2007 June 2007
Using HELD as a Location URI Dereference Protocol
draft-winterbottom-geopriv-held-deref-bcp-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 3, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Winterbottom, et al. Expires December 3, 2007 [Page 1]
Internet-Draft HELD Deref June 2007
Abstract
The need and use of location references introduces the need for a
dereference protocol. This document explores the suitability of
using HELD as a dereference protocol HTTP location URIs.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Detailed Description . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4.1. LCS Identity . . . . . . . . . . . . . . . . . . . . . . . 7
5. Recipient Identity . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative references . . . . . . . . . . . . . . . . . . 11
Appendix A. HELD Compliance to IETF Location Reference
Requirements . . . . . . . . . . . . . . . . . . . . 13
A.1. Rq1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.2. Rq2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.3. Rq3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.4. Rq4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.5. Rq5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.6. Rq6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.7. Rq7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.8. Rq8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Winterbottom, et al. Expires December 3, 2007 [Page 2]
Internet-Draft HELD Deref June 2007
1. Introduction
This memo relates to the IETF requirements document for a location
configuration protocol (LCP) [I-D.ietf-geopriv-l7-lcp-ps] and the
requirements document describing location by reference functionality
[I-D.marshall-geopriv-lbyr-requirements]. The HELD specification
[I-D.ietf-geopriv-http-location-delivery] describes the geopriv
layer-7 LCP, and can provide location by value, in the form of a
PIDF-LO [RFC4119], and location by reference, in the form of location
URIs. This memo shows how HELD can satisfy all of the requirements
outlined in [I-D.marshall-geopriv-lbyr-requirements] to make it
suitable for reuse as a dereference protocol for HTTP location URIs.
This document only addresses HTTP location URIs. Other URI forms,
the required permissions, and the need for authentication by any
specific Recipient is deemed to be in the application domain and
therefore out of scope for this document. A location URI is
dereferenced by a location Recipient to obtain the location of a
Target. How the recipient obtains the location URI is not in scope
for this document. However, a mechanism such as that described in
[I-D.ietf-sip-location-conveyance] may be used to provide this
functionality.
In order to use a location URI a dereference protocol is required.
The entity retrieving location (the Recipient) needs to be able to
convey basic information to the LCS ensure that information for the
correct Target, in the correct form, to the best accuracy, is
provided. To support this functionality the dereference protocol
needs to provide a means to:
1: identify the Target for which location is required.
2: request location in the form required by the application.
3: indicate the acceptable trade-off between time and accuracy.
Using HELD, a requestor is able to request a literal location in the
form of a PIDF-LO, or indirectly in the form of a location URI. A
HELD location URI explicitly satisfies the first criteria described
above in that it must uniquely identify an End-Point. The remaining
two criteria are directly addressed by functionality provided in the
HELD protocol specification. The remainder of this memo addresses
HELD's suitability as a dereference protocol based on the
requirements described in [I-D.marshall-geopriv-lbyr-requirements],
and describes how it is to be used when dereferencing an HTTP
location URI.
Winterbottom, et al. Expires December 3, 2007 [Page 3]
Internet-Draft HELD Deref June 2007
2. Terminology
The key conventions and terminology used in this document are defined
as follows:
This document reuses the term Target, as defined in [RFC3693].
This document uses the term Location Configuration Server, LCS, as
the node in the access network providing location information to an
End-Point, or to the node dereferencing a location URI. This term is
also used in [I-D.ietf-geopriv-l7-lcp-ps].
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].
Winterbottom, et al. Expires December 3, 2007 [Page 4]
Internet-Draft HELD Deref June 2007
3. Detailed Description
The following assumptions are made when HELD is used a HTTP location
URI dereference protocol:
1: An End-Device has requested a location URI from the LCS using
HELD.
2: The LCS has generated an HTTP location URI that uniquely
identifies the End-Point to the LCS.
3: The End-Point has conveyed the location URI to a location
Recipient in a suitably secure manner.
Given these assumptions a location Recipient is able to request the
location of a Target from the LCS using a subset of parameters in a
HELD <locationRequest> message. The HELD locationRequest is directed
to the location URI provided by the Target to the location Recipient.
+------------+ +---------+ +-----------+
| End-Device | | | | Location |
| (Target) | | LCS | | Recipient |
| | | | | |
+-----+------+ +----+----+ +-----+-----+
| | |
| | |
|===locationRequest(URI)==>0 |
| | |
| | |
0<==locationResponse(URI)==| |
| | |
| | |
|~~~~~~~~~~~~~~~~~~~~~Conveyance~~~~~~~~~~~~~~~~~~~~~~~~>0
| | |
| | |
| 0<===locationRequest(Civic)===|
| | |
| | |
| |==locationRespone(PIDF-LO)==>0
| | |
Figure 1: HELD Location URI Dereference Context Diagram
The <locationType> parameter allows location to be requested in a
specific form. The a thrid-party location Recipient SHOULD NOT
request location as a locationURI. The LCS MUST respond with a 400
Winterbottom, et al. Expires December 3, 2007 [Page 5]
Internet-Draft HELD Deref June 2007
"Request Error" if it receives a request for a locationURI where HELD
is being used as a dereference protocol. Location information
provided by the LCS SHALL be a well-formed PIDF-LO complying to the
rules and guidelines in [I-D.ietf-geopriv-pdif-lo-profile].
A semantic of HELD is that the LCS will provide location information
on request even if the location information does not fit the form
requested. This stems from the premise that some location is better
than no location. HELD provides a means for the requestor to modify
this behaviour and instruct the LCS to return an error if location
information is not available in the form requested. This is done
using the "exact" attribute, and can be used by a third-party
location Recipient when HELD is used as dereference protocol.
Location systems often have more than one determination mechanism at
their disposal. Differing determination techniques provide different
degrees of accuracy over differing periods of time. Generally, more
acurate determination techniques require more time. HELD addresses
this trade-off by allowing the requestor to specify how long they are
prepared to wait for a location result. This the LCS to select the
most accurate determination technique at it disposal that return a
result in the specified time. The HELD attribute for specifying this
value is the "responseTime" attribute and can be used by a third-
party location Recipient to specify their preference for accuracy-
time trade-off .
Where the LCS is unable to process the location Recipient's request,
it SHOULD return the appropriate error from the existing HELD error
set defined in [I-D.ietf-geopriv-http-location-delivery].
Winterbottom, et al. Expires December 3, 2007 [Page 6]
Internet-Draft HELD Deref June 2007
4. Security Considerations
In the general case, possession of the location URI is a grant of
permission to access location information for the Target. It is
therefore the responsibility of the Target to ensure the conveyance
of a location URI is secure from interception. One proposed set of
conveyance measures is addressed in
[I-D.ietf-sip-location-conveyance]. The TLS_NULL_WITH_NULL_NULL
cipher suite MUST NOT be used.
4.1. LCS Identity
In the normal case connection establishment from the recipient to the
LCS will be made on HTTP over TLS, and the location URI being
dereferenced by the Recipient will contain the hostname of the LCS.
Where the hostname is known to the Recipient, the Recipient MUST
check it against the LCS identity presented in the server's
certificate message. A discrepency MAY indicate a possible man-in-
the-middle-attack, the the Recpient should take appropriate action
based on application dependent semantics. Actions MAY include but ar
not limited to; proceeding anyway, flagging the result as suspect,
dropping to HTTP over TCP, or giving up.
In some applications the Recipient has prior knowledge of the
expected identity of the LCS, in such cases hostname checking is not
required.
Winterbottom, et al. Expires December 3, 2007 [Page 7]
Internet-Draft HELD Deref June 2007
5. Recipient Identity
Typically the Recipient will not be required to authenticate with the
LCS as possession of the location URI is suffcient is a reasonable
access token. Where Recipient authentication is required HTTP basic
and digest authentication MAY be used; in this situation TLS MUST BE
used.
Winterbottom, et al. Expires December 3, 2007 [Page 8]
Internet-Draft HELD Deref June 2007
6. IANA Considerations
There are no specific IANA considerations for this document.
Winterbottom, et al. Expires December 3, 2007 [Page 9]
Internet-Draft HELD Deref June 2007
7. 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 http stawman
proposal that provided assistance with the security section of this
document.
Winterbottom, et al. Expires December 3, 2007 [Page 10]
Internet-Draft HELD Deref June 2007
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[I-D.ietf-geopriv-pdif-lo-profile]
Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
Considerations and Recommendations",
draft-ietf-geopriv-pdif-lo-profile-07 (work in progress),
April 2007.
[I-D.ietf-geopriv-http-location-delivery]
Barnes, M., "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-00 (work in
progress), June 2007.
[I-D.marshall-geopriv-lbyr-requirements]
Marshall, R., "Requirements for a Location-by-Reference
Mechanism used in Location Configuration and Conveyance",
draft-marshall-geopriv-lbyr-requirements-01 (work in
progress), March 2007.
8.2. Informative references
[I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Session Initiation Protocol
Location Conveyance",
draft-ietf-sip-location-conveyance-07 (work in progress),
February 2007.
[I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and
Winterbottom, et al. Expires December 3, 2007 [Page 11]
Internet-Draft HELD Deref June 2007
Requirements", draft-ietf-geopriv-l7-lcp-ps-02 (work in
progress), April 2007.
Winterbottom, et al. Expires December 3, 2007 [Page 12]
Internet-Draft HELD Deref June 2007
Appendix A. HELD Compliance to IETF Location Reference Requirements
This appendix describes how HELD complies to the location reference
requirements stipulated in [I-D.marshall-geopriv-lbyr-requirements].
A.1. Rq1
"Location Reference Identifier as a URI: The dereferencing protocol
MUST support an LRI in URI form, and may support other non-URI
forms."
COMPLY. HELD only provide location references in URI form.
A.2. Rq2
"Dereference Protocol Confidentiality: The dereferencing protocol
MUST support mechanisms for encrypting messages sent between client
(Location recipient) and server (Location server)."
COMPLY. HELD supports the use of HTTP over TLS.
A.3. Rq3
"Dereference Protocol Transparancy: The dereferencing protocol MUST
support the exchange of messages without encryption (i.e., in
plaintext)."
COMPLY. HELD can, if required, be used over straight HTTP. The
recommended usage however is over TLS.
A.4. Rq4
"Location Reference Expiry: The dereference protocol MUST support
specification of a finite period of validity for the LRI."
COMPLY. HELD location URIs are provided to the End-Point with an
explicit expiry time. How and if the End-Point chooses to provide
this expiry time to a location Recipient is a matter of conveyance
and is out of scope for HELD.
A.5. Rq5
"Dereference Protocol Transport: The de-reference protocol MUST
support TCP/IP and MAY support UDP/IP."
COMPLY. HELD uses HTTP as a transport which runs on top of TCP.
Winterbottom, et al. Expires December 3, 2007 [Page 13]
Internet-Draft HELD Deref June 2007
A.6. Rq6
"Dereference Protocol Authentication: The dereferencing protocol MUST
support both client-side and server-side authentication."
COMPLY. The client may authenticate itself to the server using
HTTP's digest authentication mechanism as described in [RFC2617] and
updated errata. The server authenticates itself using the methods
described in HTTP on TLS [RFC2818].
A.7. Rq7
"Location Privacy: The dereference protocol MUST support the
application of privacy rules to the dissemination of a requested
location object."
COMPLY. When used as a dereference protocol HELD provides location
in PIDF-LO, including default, or Target assigned usage-rule values.
A.8. Rq8
"Dereferenced PIDF-LO Result: The dereferencing of an LRI MUST result
in a well-formed PIDF-LO."
COMPLY. HELD when used as a dereference protocol MUST provide
location information as a PIDF-LO that complies with
[I-D.ietf-geopriv-pdif-lo-profile] as described in Section 3.
Winterbottom, et al. Expires December 3, 2007 [Page 14]
Internet-Draft HELD Deref June 2007
Authors' Addresses
James Winterbottom
Andrew Corporation
PO Box U40
University of Wollongong, NSW 2500
AU
Email: james.winterbottom@andrew.com
Martin Thomson
Andrew Corporation
PO Box U40
University of Wollongong, NSW 2500
AU
Email: martin.thomson@andrew.com
Martin Dawson
Andrew Corporation
PO Box U40
University of Wollongong, NSW 2500
AU
Email: martin.dawson@andrew.com
Winterbottom, et al. Expires December 3, 2007 [Page 15]
Internet-Draft HELD Deref June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Winterbottom, et al. Expires December 3, 2007 [Page 16]