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 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 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]