Geopriv J. Winterbottom Internet-Draft Andrew Corporation Intended status: Standards Track H. Tschofenig Expires: May 14, 2008 Nokia Siemens Networks H. Schulzrinne Columbia University M. Thomson M. Dawson Andrew Corporation November 11, 2007 An HTTPS Location Dereferencing Protocol Using HELD draft-winterbottom-geopriv-deref-protocol-00.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 May 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Winterbottom, et al. Expires May 14, 2008 [Page 1] Internet-Draft HTTPS Dereferencing Protocol November 2007 Abstract This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference into a Presence Information Data Format Location Object (PIDF-LO). The document assumes that a Location Recipient possesses a secure HELD URI that can be used in conjunction with the HELD protocol to request the location of the Target. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Steps for Retrieval . . . . . . . . . . . . . . . . . . . . . 6 4. Threat Models . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Using HELD to Dereference a Location URI . . . . . . . . . . . 9 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative references . . . . . . . . . . . . . . . . . 16 Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 18 Appendix B. HELD Compliance to IETF Location Reference Requirements . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Winterbottom, et al. Expires May 14, 2008 [Page 2] Internet-Draft HTTPS Dereferencing Protocol November 2007 1. Introduction This document describes how to transport Presence Information Data Format Location Object (PIDF-LO) when dereferencing a location URI in the form of a secure HELD URI (held: URI scheme) [I-D.ietf-geopriv-http-location-delivery]. This held: URI indicates that the XML-based HELD messages are carried on top of the Hypertext Transfer Protocol (HTTP), which is secured using Transport Layer Security (TLS) ([RFC2616] and [RFC2818]). The document describes how HELD [I-D.ietf-geopriv-http-location-delivery] is used to request and to receive location information in a way that also satisfies the requirements laid out in [I-D.ietf-geopriv-lbyr-requirements]. HELD provides location information in the form of a PIDF-LO (see [RFC4119]) which, as part of its definition, complies with the requirements of a location object as described in [RFC3693]. To use HELD as a dereferencing protocol has the advantage that the Location Recipient can indicate the type of location information it would like to receive. This functionality is already available with the HELD base specification, described in [I-D.ietf-geopriv-http-location-delivery]. Furthermore, the HELD response from the LIS towards the Location Recipient not only provides the PIDF-LO but also encapsulates supplementary information, such as error messages, back to the Location Recipient. The general usage scenario envisioned by this document is shown in Figure 1. While the figure shows a typical HELD location request being made to initially obtain the location URI. As Figure 1 indicates, an alternative Location Configuration Protocol (LCP) that can provide a HELD URI can be used. Winterbottom, et al. Expires May 14, 2008 [Page 3] Internet-Draft HTTPS Dereferencing Protocol November 2007 +-----------+ +------------+ | Location | +-----------+ | End Device | |Information| | Location | | (Target) | | Server | | Recipient | +-----+------+ +----+------+ +-----+-----+ | | | +--+--------------------------+--+ | | | | | | | |===locationRequest(URI)==>0 | | | | | | Location | | | | | Configuration | | 0<==locationResponse(URI)==| | Protocol | | | | | | +--+--------------------------+--+ | | | | | | | |~~~~~~~~~~~~Location Conveyance (URI)~~~~~~~~~~~~~~~~~~>0 | | | | +--+-----------------------------+--+ | | | | | | | 0<===locationRequest(Civic)===| | | Dereferencing | | | | | Protocol | | | | | | |==locationResponse(PIDF-LO)=>0 | | | | | | | +--+-----------------------------+--+ | | | | | | Figure 1: HTTPS Dereference Context Diagram Using HELD Winterbottom, et al. Expires May 14, 2008 [Page 4] Internet-Draft HTTPS Dereferencing Protocol November 2007 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 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 Information Server, LIS, 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 Location Recipient acts as a HELD client and the LIS as a HELD server in the context of this document. Winterbottom, et al. Expires May 14, 2008 [Page 5] Internet-Draft HTTPS Dereferencing Protocol November 2007 3. Steps for Retrieval 1. The Location Recipient obtains a helds: based location URI. 2. The HELD client establishes a TLS connection to the LIS, as described in [RFC2818]. The TLS ciphersuite TLS_NULL_WITH_NULL_NULL MUST NOT be used. 3. When certificate based authentication is used the client authenticates the server and compares the domain part of the location URI with the identity information in the certificate. 4. The server MAY require the client to be authenticated. This is, however, only useful in certain deployment environments where a strong relationship between the LIS and the Location Recipients exists. 5. The client retrieves the PIDF-LO document encapsulated into the HELD locationResponse or an error message conveyed in a HELD error message. Winterbottom, et al. Expires May 14, 2008 [Page 6] Internet-Draft HTTPS Dereferencing Protocol November 2007 4. Threat Models This document assumes that the HELD messages between the Location Recipient and the LIS are carried on top of HTTP and secured via TLS. HTTP can be used as a substrate to a number of different applications, and defining a set of guidelines for conveying a PIDF-LO for any application that might use HTTP would be difficult or impossible. This document does not attempt that task. Instead, it is limited in applicability to the case where a client uses a HELD locationRequest to retrieve a PIDF-LO object from a server. No other functionality is covered. This document does not describe how the Location Recipient obtains the location URI pointing to the PIDF-LO document. This is subject of the Location Conveyance protocol [I-D.ietf-sip-location-conveyance] There are three security models. They assume that the Location Recipient who obtains the the location URI does not act maliciously and does not distribute the obtained Location Object without inspecting the privacy policies attached with the Location Object. Authorization Policy Security Model: The assumption of this model is that the LIS has some authorization policies (such as those specified in [RFC4745] and [I-D.ietf-geopriv-policy]) that are provided by the Target and uploaded to the LIS. The policies have the form of access control lists that indicate to which Location Recipients location information is disclosed. The LIS is therefore able to control access to location information. Consequently, when the reference is conveyed to the potential Location Recipient (e.g., via SIP [I-D.ietf-sip-location-conveyance]), then it does not need to be protected (neither hop-by-hop nor end-to-end). Authentication by the Location Recipient to the LIS is necessary (e.g., TLS client authentication, HTTP Digest authentication) to allow the LIS to determine whether access to location information has to be granted. End-to-End Security Model: In this security model we assume that the transport of the location URI is encrypted end-to-end, for example using S/MIME, and an adversary along the signaling path is not able to eavesdrop, modify or replay a location URI. The Target is able to control the disclosure of the PIDF-LO by making it available only to trusted entities. Consequently, only the entity that is able to decrypt the end-to-end protected object, such as S/MIME encrypted object, can resolve the reference. Winterbottom, et al. Expires May 14, 2008 [Page 7] Internet-Draft HTTPS Dereferencing Protocol November 2007 Hop-by-Hop Security Model: In this security model we assume that the location URI can either be directly communicated between the Target and the Location Recipient or from the Target via trusted proxies to the Location Recipient. In some cases the location URI is conveyed to multiple Location Recipients, for example in case of location-based routing applications. The entity that observes the location URI has to be able to resolve it into a literal location. The description of the security models above shows the responsibility of the participating entities; from a dereferencing protocol point of view an important responsibility can be found in the protection of the interaction between the Location Recipient and the LIS against the classical communication security threats. With respect to the Location Configuration and the Location Conveyance protocol interaction, which are outside the scope of this document, this document at least assumes the hop-by-hop security model. Additionally, it is assumed that the requirements outlined in [I-D.ietf-geopriv-lbyr-requirements], such as the requirement that the location URI contains a random component with sufficient entropy and that it does not contain identity information. When the pre- requisites for the end-to-end security model are met then further protection can be accomplished. End-to-end security mechanisms do, however, not enjoy widespread deployment so in SIP so far (when SIP is used as the Location Conveyance protocol). The usage of policies local to the LIS are possible. Furthermore, [I-D.winterbottom-geopriv-held-context] allows constraints to be placed on the dereferencing procedure that limit the location information available to the Location Recipient, for example limiting the number of times a reference may be used. Winterbottom, et al. Expires May 14, 2008 [Page 8] Internet-Draft HTTPS Dereferencing Protocol November 2007 5. Using HELD to Dereference a Location URI This section describes how HELD protected by TLS can be used to qualify location requests to the LIS. Only a subset of HELD functionality is required and is described in the following paragraphs. The HELD based dereferencing step provides ways to tell the LIS what information is desired and allows the LIS to communicate additional information back to the client. The element allows location to be requested in a specific form, such as civic or geodetic location information. The Location Recipient SHOULD NOT request location as a locationURI. The LIS MUST respond with a "requestError" if it receives a request for a locationURI where HELD is being used as a dereference protocol. Location information provided by the LIS MUST correspond to the rules and guidelines in [I-D.ietf-geopriv-pdif-lo-profile]. If the requested form of location violates any authorization policies known to the LIS, then the LIS MUST respond with a "cannotProvideLiType" error. The LIS 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 LIS to return an error if location information is not available in the form requested. This is done using the "exact" attribute. Location systems often have more than one location determination mechanism at their disposal. Differing determination techniques provide different degrees of accuracy over differing periods of time. Generally, more accurate 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 allows the LIS to select the most accurate determination technique at its disposal that can return a result in the specified time. The HELD attribute for specifying this value is the "responseTime" attribute and MAY be used by a Location Recipient to specify their preference for the accuracy-time trade-off. The LIS MUST support the HELD locationRequest semantic using an HTTP GET as described in [I-D.ietf-geopriv-http-location-delivery]. Where the LIS is unable to process the Location Recipient's request, it MUST return the appropriate error from the existing HELD error set defined in [I-D.ietf-geopriv-http-location-delivery]. Winterbottom, et al. Expires May 14, 2008 [Page 9] Internet-Draft HTTPS Dereferencing Protocol November 2007 6. Examples Figure 2 illustrates a simple dereferencing request example. GET /357yc6s64ceyoiuy5ax3o HTTP/1.1 Host: lis.example.com Accept:application/held+xml Figure 2: Minimal Dereferencing Request Figure 3 shows a request indicating that both civic and geodetic location information has to be returned. If it cannot be provided, the request fails. HTTP/1.x 200 OK Server: Example LIS Expires: Tue, 10 Jan 2006 03:49:20 GMT Content-Type: application/held+xml Content-Length: XYZ civic geodetic Figure 3: Dereferencing Request for Civic and Geodetic Information Figure 4 shows the response to the previous request listing both civic and geodetic location information of the Target's location. HTTP/1.x 200 OK Server: Example LIS Expires: Tue, 10 Jan 2006 03:49:20 GMT Content-Type: application/held+xml Content-Length: XYZ Winterbottom, et al. Expires May 14, 2008 [Page 10] Internet-Draft HTTPS Dereferencing Protocol November 2007 -34.407242 150.882518 30 AU NSW Wollongong Gwynneville Northfield Avenue University of Wollongong 2 Andrew Corporation 2500 39 WS-183 U40 false 2007-05-25T12:35:02+10:00 Wiremap 2007-05-24T12:35:02+10:00 Figure 4: Response with Civic and Geodetic Location Information Figure 5 shows an error message returned in response to a request. Winterbottom, et al. Expires May 14, 2008 [Page 11] Internet-Draft HTTPS Dereferencing Protocol November 2007 HTTP/1.x 200 OK Server: Example LIS Expires: Tue, 10 Jan 2006 03:49:20 GMT Content-Type: application/held+xml Content-Length: XYZ Figure 5: Error Message Winterbottom, et al. Expires May 14, 2008 [Page 12] Internet-Draft HTTPS Dereferencing Protocol November 2007 7. Security Considerations This document assumes that the use of TLS to protect HTTP is sufficient to protect the privacy of the PIDF-LO content while in flight. When access control at the LIS is not applied, as described in the threat models in Section 4, then the possession of the location URI is equal to the possession of location information. When the requirements for creating a location URI, as described in [I-D.winterbottom-geopriv-held-context], are met, then the reference provides sufficiently high security guarantees for most usages. Furthermore, the ability of the Target to put constraints on the dereferencing step, as described in [I-D.winterbottom-geopriv-held-context], provides additional security guarantees. In the normal case, connection establishment from the Location Recipient to the LIS will be made on HTTP over TLS, and the location URI being dereferenced by the Location Recipient will contain the hostname of the LIS. The Location Recipient MUST check the FQDN of the LIS in the reference with the identity presented in the server's certificate. A discrepancy may indicate a possible man-in-the- middle-attack, and the Location Recipient should take appropriate action based on application dependent semantics. Actions may include but are not limited to; proceeding anyway, flagging the result as suspect, or giving up. In some applications the Location Recipient has a pre-established relationship with one or several Location Information Servers and hence the LIS might authorize only certain Location Recipients might be allowed to resolve a reference. Winterbottom, et al. Expires May 14, 2008 [Page 13] Internet-Draft HTTPS Dereferencing Protocol November 2007 8. IANA Considerations There are no specific IANA considerations for this document. Winterbottom, et al. Expires May 14, 2008 [Page 14] Internet-Draft HTTPS Dereferencing Protocol November 2007 9. Acknowledgements Thanks to Barbara Stark and Guy Caron for providing early comments. Thanks to Rohan Mahy for constructive comments on the scope and format of the document. Thanks to Ted Hardie for his strawman proposal that provided assistance with the security section of this document. Winterbottom, et al. Expires May 14, 2008 [Page 15] Internet-Draft HTTPS Dereferencing Protocol November 2007 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [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. [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-10 (work in progress), October 2007. [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP Enabled Location Delivery (HELD)", draft-ietf-geopriv-http-location-delivery-02 (work in progress), September 2007. [I-D.ietf-geopriv-lbyr-requirements] Marshall, R., "Requirements for a Location-by-Reference Mechanism", draft-ietf-geopriv-lbyr-requirements-01 (work in progress), October 2007. 10.2. Informative references [I-D.ietf-geopriv-policy] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", draft-ietf-geopriv-policy-13 (work in progress), October 2007. [I-D.winterbottom-geopriv-held-context] Winterbottom, J., Tschofenig, H., and M. Thomson, "HELD Protocol Context Management Extensions", Winterbottom, et al. Expires May 14, 2008 [Page 16] Internet-Draft HTTPS Dereferencing Protocol November 2007 draft-winterbottom-geopriv-held-context-01 (work in progress), October 2007. [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007. [I-D.ietf-sip-location-conveyance] Polk, J. and B. Rosen, "Location Conveyance for the Session Initiation Protocol", draft-ietf-sip-location-conveyance-08 (work in progress), July 2007. [I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in progress), September 2007. Winterbottom, et al. Expires May 14, 2008 [Page 17] Internet-Draft HTTPS Dereferencing Protocol November 2007 Appendix A. GEOPRIV Using Protocol Compliance This section compares the GEOPRIV requirements described in [RFC3693] with the approach outlined in this document. Req. 1. (Location Object generalities): o Regarding requirement 1.1, the Location Object has to be understood by the Location Recipient and the Location Server, the two communication end points. The PIDF-LO [RFC4119] allows both civic and geospatial location information to be expressed. Combining this with [I-D.ietf-geopriv-pdif-lo-profile] ensures that location can be constructed and interpreted in a consistent manner. o Regarding requirement 1.2, a number of fields in the civic location information format are optional. o Regarding requirement 1.3, the civic location information is defined in an extensible way. o Regarding requirement 1.4, the location information itself is not defined in this document. o Regarding requirement 1.5, the protocol described in this document allows the Location Recipient to resolve a reference to a PIDF-LO only. o Regarding requirement 1.6, the Location Object contains both location information and privacy rules. Depending on the deployment scenario, which is outside the scope of this document, the privacy rules might have stronger or a weaker semantic. o Regarding requirement 1.7, the Location Object is usable in a variety of protocols. o Regarding requirement 1.8, no change regarding with respect to the encoding of the Location Object (see [RFC4119]) was made by this document. Req. 2. (Location Object fields): o Regarding requirement 2.1, depending on the deployment scenario an identifier pointing to the Target may be carried inside the PIDF-LO since the PIDF object provides the ability to carry this identifier. In some circumstances it might be desirable not to carry information about the Target's identity in the PIDF-LO. Winterbottom, et al. Expires May 14, 2008 [Page 18] Internet-Draft HTTPS Dereferencing Protocol November 2007 o Regarding requirement 2.2, depending on the deployment scenario the LIS might require that the Location Recipient performs an authentication step. The security mechanisms for client and server authentication are outside the scope of this document and defined already for HTTPS itself. o Regarding requirement 2.3, proof of possession of the Location Recipient credentials is provided outside the scope of this document. The security mechanisms defined for HTTPS are used by this document. o Regarding requirement 2.5, RFC 4119 defines the basis for carrying location information in a PIDF document. The ability to extend RFC 4119 to convey motion specific information is work in progress. o Regarding requirement 2.6, this document as specified only allows the Location Recipient to resolve the reference and to indicate which location format has to be returned. o Regarding requirement 2.7, the PIDF-LO relevant elements and attributes are available. o Regarding requirement 2.8, provision exists for a reference to an external (more detailed rule set) within the PIDF-LO to be made. This is the element. o Regarding requirement 2.9, security headers and trailers are provided Transport Layer Security. o Regarding requirement 2.10, extensibility within the PIDF-LO is provided regarding the definition of namespaces. Req. 3. (Location Data Types): o Regarding requirement 3.1, [RFC4119] defines geospatial location information as the mandatory to implement location format. [I-D.ietf-geopriv-pdif-lo-profile] describes in more detail the acceptable forms of geolocation and its interaction with civic notations. o With the support of civic and geodedic location information in [RFC4119] the requirement 3.2 is fulfilled. o Regarding requirement 3.3, rules described in [I-D.ietf-geopriv-policy] apply to an absolute geodetic point. Geodetic information expressed in a PIDF-LO that complies with [I-D.ietf-geopriv-pdif-lo-profile] may express an area or volume Winterbottom, et al. Expires May 14, 2008 [Page 19] Internet-Draft HTTPS Dereferencing Protocol November 2007 there-by "fuzzing" the location of the Target. o Regarding requirement 3.4, since the PIDF-LO format is designed to be extensible it allows further location information types to be defined in the future. Section 7.2 of [RFC3693] details the requirements of a "Using Protocol". These requirements are listed below: Req. 4. The using protocol has to obey the privacy and security instructions coded in the Location Object regarding the transmission and storage of the LO. This document carries the PIDF-LO as is via HTTPS from the LIS to the Location Recipient. The sending and receiving parties must obey the instructions carried inside the object. Req. 5. The using protocol will typically facilitate that the keys associated with the credentials are transported to the respective parties, that is, key establishment is the responsibility of the using protocol. This document does not define additional security mechanisms beyond HTTPS. Req. 6. (Single Message Transfer): In particular, for tracking of small target devices, the design should allow a single message / packet transmission of location as a complete transaction. The encoding of the RFC 4119-defined Location Object format is not changed. Because of the verbose XML encoding it is not tailored towards inclusion into a single message. Section 7.3 of [RFC3693] details the requirements of a "Rule based Location Data Transfer". These requirements are listed below: Req. 7. (LS Rules): Access to location information is controlled by allowing the Target (or by an entity on behalf of the Target) to indicate to which Location Recipients the short- lived location URI that contains a unguessable random component. Additionally, constraints can be put on the dereferencing step by the Target. Winterbottom, et al. Expires May 14, 2008 [Page 20] Internet-Draft HTTPS Dereferencing Protocol November 2007 Req. 8. (LG Rules): In context of location URI it is not possible that there is no relationship between the Location Generator and the Location Information Server. As such, the statement made in Requirement 7 applies. Req. 9. (Viewer Rules): The Rule Maker might define (via mechanisms outside the scope of this document) which policy rules are disclosed to other entities. These mechanisms are available with [I-D.ietf-geopriv-policy]. These rules are, however, best used when the location URI is not directly provided to Location Recipients but rather to an intermediary that stores these authorization policies, such as a location- based presence server. Req. 10. (Full Rule language): Geopriv has defined a rule language capable of expressing a wide range of privacy rules which is applicable in the area of the distribution of Location Objects. The format of these rules are described in [RFC4745] and [I-D.ietf-geopriv-policy]. These rules may be used in a larger context but this document does not define their usage. Req. 11. (Limited Rule language): A limited (or basic) ruleset was introduced with PIDF-LO [RFC4119]). Section 7.4 of [RFC3693] details the requirements of "Location Object Privacy and Security". These requirements are listed below: Req. 12. (Identity Protection): Identity protection of the Target can be provided if both the following conditions are true: (a) the protocol used to convey the reference does not disclose the identity of the Target and (b) if the PIDF-LO does not contain information about the identity about the Target. Currently, there is no mechanism available that allows the Target to tell the LIS which identity information to include in the PIDF-LO. Winterbottom, et al. Expires May 14, 2008 [Page 21] Internet-Draft HTTPS Dereferencing Protocol November 2007 Req. 13. (Credential Requirements): The security mechanism specified in this document is Transport Layer Security. TLS offers the ability to use different types of credentials, including symmetric, asymmetric credentials or a combination of them. Req. 14. (Security Features): Geopriv defines a few security requirements for the protection of Location Objects such as mutual end-point authentication, data object integrity, data object confidentiality and replay protection. The ability to use Transport Layer security fulfills these requirements. Req. 15. Minimal Crypto: The mandatory to implement ciphersuite is provided in the TLS layer security specification. Winterbottom, et al. Expires May 14, 2008 [Page 22] Internet-Draft HTTPS Dereferencing Protocol November 2007 Appendix B. HELD Compliance to IETF Location Reference Requirements This section describes how HELD complies to the location reference requirements stipulated in [I-D.ietf-geopriv-lbyr-requirements]. High-level requirements for a location configuration protocol. C1. "Location URI support - LCP: The configuration protocol MUST support a location reference in URI form." COMPLY. HELD only provides location references in URI form. C2. "Location URI expiration: The LCP MUST support the ability to specify to the server, the length of time that a location URI will be valid." COMPLY. basic HELD supports the LIS informing the Target of the location URI expiry time. HELD context management extension [I-D.winterbottom-geopriv-held-context] provides the Target the ability to specify exipry times for location URIs. C3. "Location URI cancellation: The LCP MUST support the ability to request the cancellation of a specific location URI." COMPLY. HELD context management extension [I-D.winterbottom-geopriv-held-context] provides the Target the ability to void location URIs when required. C4. "Random Generated: The location URI MUST be hard to guess, i.e., it MUST contain a cryptographically random component." COMPLY. The HELD specification provides specific guidance on the security surrounding location URI generation. C5. "Identity Protection - LCP: The location URI MUST NOT contain any information that identifies the user, device or address of record within the URI form." COMPLY. The HELD specification provides specific guidance on Winterbottom, et al. Expires May 14, 2008 [Page 23] Internet-Draft HTTPS Dereferencing Protocol November 2007 the anonymity of the Target with regards to the generation of location URIs. C6. "Reuse flag default: The LCP MUST support the default condition of a requested location URI being repeatedly reused." COMPLY. The default semantics of location URIs in HELD place no limits on the number of times that a location URI can be dereferenced. C7. "One-time-use: The LCP MUST support the ability for the client to request a 'one-time-use' location URI (e.g., via a reuse flag setting)." COMPLY. HELD context management extension [I-D.winterbottom-geopriv-held-context] provides the Target the ability to set the number of times that a location URI may yield the Target's location. High-level requirements for a location dereference protocol. D1. "Location URI support - LDP: The LDP MUST support a location reference in URI form." COMPLY. HELD only provides location references in URI form. D2. "Location URI expiration status: The LDP MUST support a message indicating that for a location URI which is no longer valid, that the location URI has expired." COMPLY. HELD indicates to the requestor that location for the URI cannot be provided by returning a locationUnknown error when a location URI is found to have expired. D3. "Authentication: The LDP MUST support either client-side and server-side authentication between client and server." COMPLY. Client authentication may be provided using a variety Winterbottom, et al. Expires May 14, 2008 [Page 24] Internet-Draft HTTPS Dereferencing Protocol November 2007 of techniques. However, this document does not mandate a specific procedure nor does it specify the format of authorization policies that may be in place to control access at the LIS. The server authenticates itself using the methods described in HTTP on TLS [RFC2818]. D4. "Dereferenced Location Form: Location URI dereferencing 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 5. D5. "Repeated use: The LDP MUST support the ability for the same location URI to be resolved more than once, based on server settings and LCP parameters." COMPLY. A Location Recipient may access and use a location URI as many times as desired until such time as the URI expires due to age, or is made invalid by other Target policies on the LIS. D6. "Updated location: The LDP MUST support the ability for the same location URI to be resolved into a continuum of location values (e.g., location updates)." COMPLY. Using base-HELD the location of the Target is determined each time that URI is accessed. D7. "Location form: The LDP MUST support dereferenced location in both coordinate and civic forms." COMPLY. HELD provide the locationType parameter allowing the Location Recipient the ability to specify the form of location they require. Winterbottom, et al. Expires May 14, 2008 [Page 25] Internet-Draft HTTPS Dereferencing Protocol November 2007 Authors' Addresses James Winterbottom Andrew Corporation PO Box U40 University of Wollongong, NSW 2500 AU Phone: +61 242 212938 Email: james.winterbottom@andrew.com URI: http://www.andrew.com/products/geometrix Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Phone: +49 89 636 40390 Email: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building, New York, NY 10027 US Phone: +1 212 939 7004 Email: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu Martin Thomson Andrew Corporation PO Box U40 University of Wollongong, NSW 2500 AU Email: martin.thomson@andrew.com Winterbottom, et al. Expires May 14, 2008 [Page 26] Internet-Draft HTTPS Dereferencing Protocol November 2007 Martin Dawson Andrew Corporation PO Box U40 University of Wollongong, NSW 2500 AU Email: martin.dawson@andrew.com Winterbottom, et al. Expires May 14, 2008 [Page 27] Internet-Draft HTTPS Dereferencing Protocol November 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 May 14, 2008 [Page 28]