A Location Dereferencing Protocol Using HELDAndrew CorporationAndrew Building (39)Wollongong University CampusNorthfields AvenueWollongongNSW2522AU+61 242 212938james.winterbottom@andrew.comNokia Siemens NetworksLinnoitustie 6Espoo02600Finland+358 (50) 4871445Hannes.Tschofenig@gmx.nethttp://www.tschofenig.priv.atColumbia UniversityDepartment of Computer Science450 Computer Science BuildingNew York, NY10027US+1 212 939 7004hgs@cs.columbia.eduhttp://www.cs.columbia.eduAndrew CorporationAndrew Building (39)Wollongong University CampusNorthfields AvenueWollongongNSW2522AU+61 2 4221 2915martin.thomson@andrew.comAndrew CorporationAndrew Building (39)Wollongong University CampusNorthfields AvenueWollongongNSW2522AU+61 2 4221 2992martin.dawson@andrew.com
RAI
GEOPRIVInternet-DraftHELDDereferencelbyrHTTPLocationGEOPRIVThis document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference to 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.
Provision of location information by reference involves the creation of a resource that is identified by a "location URI". A "location URI" identifies resource that contains the location of an entity. A location URI might be a temporary resource, created in response to a HTTP-Enabled Location Delivery (HELD) request. A location URI does not intrinsically include location information, instead the URI is "dereferenced" by a Location Recipient to acquire location information. This document specifies how a holder of a location URI uses that URI to retrieve location information.
The HELD protocol, as described in , defines a use of HTTP that enables location configuration - the process where a Device acquires location information about itself. A part of location configuration is the provision of a location URI. However, HELD does not describe how such a URI is used; this document provides that definition.
This document defines how HELD is used by a Location Recipient to dereference a location URI and acquire location information. The result of this process is location object in the form of a Presence Information Data Format - Location Object (PIDF-LO) document. A constrained set of HELD features are defined such that it is suitable for use as a location dereference protocol. Use as a location dereference protocol requires use of the Transport Layer Security (TLS) binding for HTTP in order to provide confidentiality, authentication and protection from modification.
Use of 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 . 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.
Location URIs created for use with HELD dereferencing use the https: or http: scheme. The behaviour described in this document can be used by Location Recipients that are aware of the fact that the URI is a location URI.
An example scenario envisioned by this document is shown in . This diagram shows how a location dereference protocol fits with location configuration and conveyance. contains more information on this scenario and others like it.
| . |
: | | : Location |
. | locationResponse | . Configuration |
: |<-----(location URI)-----| : Protocol |
. | | . |
`- + - - - - - - - - - - - - + -' |
| | |
| Location Conveyance |
|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
| | |
| .- + - - - - - - - - - - - - + -.
| : | locationRequest | :
| . |<--------(civic)---------| .
| Dereferencing : | | :
| Protocol . | locationResponse | .
| : |--------(PIDF-LO)------->| :
| . | | .
| `- + - - - - - - - - - - - - + -'
| | |
]]>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 .
This document uses key terminology from several sources:
terms for the GEOPRIV reference model defined in ;
the term Location Information Server (LIS), from , is a node in the access network that provides location information to an end point; a LIS provides location URIs;
the term Location Server (LS), from , is used to identify the role that responds to a location dereference request; this might be the same entity as the LIS, but the model in allows for the existence of separate - but related - entities; and
the term location URI is coined in .
This section discusses two extreme types of authorization models for dereferencing with HELD URIs, namely "Authorization by Possession" and "Authorization by Access Control". In the subsequent subsections we discuss the properties of these two models. , from , shows the model applicable to location configuration, conveyance and dereference.
It is important to note that this document does not mandate a specific authorization model. It is possible to combine aspects of both models. However, no authentication framework is provided, which limits the policy options available when the "Authorization by Access Control" model is used.
For either authorization model, the overall process is similar. The following steps are followed, with minor alterations:
The Target acquires a location URI from the LIS. This might use HELD as a location configuration protocol (LCP).The Target then conveys the location URI to a third party, the Location Recipient (for example using SIP as described in ). This step is shown in (2) of . The Location Recipient then needs to dereference the location URI in order to obtain the Location Object (3). Depending on the URI scheme of the location URI dereferencing might, as is the case for https: or http: URIs, be performed as described in this document.In this final step, the Location Server (LS) or LIS makes an authorization decision. How this decision is reached depends on the authorization model.
In this model, possession - or knowledge - of the location URI is used to control access to location information. A location URI is constructed such that it is hard to guess (see C9 of ) and the set of entities that it is disclosed to is limited. The only authentication required by the LS is evidence of possession of the URI. The LS is able to immediately authorize any request that indicates this URI.
Authorization by possession uses a very simple policy that does not typically require direct interaction with a Rule Maker; it is assumed that the Rule Maker is able to exert control over the distribution of the location URI. Therefore, the LIS can operate with limited policy input from a Rule Maker.
Limited disclosure is an important aspect of this authorization model. The location URI is a secret; therefore, ensuring that adversaries are not able to acquire this information is paramount. Encryption, such as might be offered by TLS or S/MIME, protects the information from eavesdroppers.
Use of authorization by possession location URIs in a hop-by-hop protocol such as SIP adds the possibility of on-path adversaries. Depending on the usage of the location URI for certain location based applications (e.g., emergency services, location based routing) specific treatment is important, as discussed in .
Using possession as a basis for authorization means that, once granted, authorization cannot be easily revoked. Cancellation of a location URI ensures that legitimate users are also affected; application of additional policy is theoretically possible, but could be technically infeasible. Therefore, other measures are provided to prevent an adversary from gaining access to location information indefinitely.
A very simple policy is established at the time that the location URI is created. This policy specifies that the location URI expires after a certain time, which limits any inadvertent exposure of location information to adversaries. The expiration time of the location URI might be negotiated at the time of its creation, or it might be unilaterally set by the LIS.
Use of explicit access control provides a Rule Maker greater control over the behaviour of an LS. In contrast to authorization by possession, possession of a this form of location URI does not imply authorization. Since an explicit policy is used to authorize access to location information, the location URI can be distributed to many potential Location Recipients.
Either before creation or dissemination of the location URI, the Rule Maker establishes an authorization policy with the LS. In reference to , authorization policies might be established at creation (Step 1), and need to be established before before the location URI is published (Step 2) to ensure that the policy grants access to the desired Location Recipients. Depending on the mechanism used, it might also be possible to change authorization policies at any time.
A possible format for these authorization policies is available with GEOPRIV Common Policy and Geolocation Policy . Additional constraints might be established by other means.
The LS enforces the authorization policy when a Location Recipient dereferences the URI. Explicit authorization policies allow a Rule Maker to specify how location information is provided to Location Recipients.
This document does not describe a specific authentication mechanism. This means that authorization policies are unable to specifically identify authorized Location Recipients.
In order to control access to location information based on the identity of the Location Recipient, use of authorization by possession is employed. By controlling which Location Recipients receive location URIs, access to location information is controlled.
Other policy mechanisms, such as those described in , can be applied to different Location Recipients if multiple location URIs are used. Location Recipients that receive a particular location URI are granted location information based on the authorization policy associated with that URI.
Providing that knowledge of a location URI is limited, policy appropriate to the Location Recipients that receive the location URI can be assigned. Selective disclosure used in this fashion can be used in place of identity-based authorization.
How policy is associated with a location URI is not defined by this document. describes one possible mechanism.
Authentication of Location Recipients and use of identity-based authorization policy is not precluded. A Location Server MAY support an authentication mechanism that enables identity-based authorization policies to be used. Future specifications might define means of identifying recipients.
Policy frameworks like degrade in a way that protects privacy if features are not supported. If a policy specifies a rule that is conditional on the identity of a recipient and the protocol does not (or cannot) provide an assertion identity of the recipient, the rule has no effect and the policy defaults to providing less information.
This section describes how HELD can be used to dereference a location URI. This process can be applied when a Location Recipient is in possession of a location URI with a https: or http: URI scheme.
A Location Recipient that wishes to dereference an https: or http: URI performs a HELD request on HTTP to the identified resource.
In many cases, an http: URI does not provide sufficient security for location URIs. The absence of the security mechanisms provided by TLS means that the Rule Maker has no control over who receives location information and the Location Recipient has no assurance that the information is correct.
The Location Recipient establishes a connection to the LS, as described in . The TLS ciphersuite TLS_NULL_WITH_NULL_NULL MUST NOT be used. The LS MUST be authenticated to ensure that the correct server is contacted.
A Location Server MAY reject a request and request that a Location Recipient provide authentication credentials if authorization is dependent on the Location Recipient identity. Future specifications could define an authentication mechanism and a means by which Location Recipients are identified in authorization policies. This document provides definitions for neither item.
Use of HELD as a location dereference protocol is largely the same as its use as a location configuration protocol. Aside from the restrictions noted in this document, HELD semantics do not differ from those established in .
The HELD locationRequest is the only request permitted by this specification. Similarly, request parameters other than the following MUST NOT be accepted by the LS: responseTime, locationType (including the associated exact attribute).
Parameters and requests that do not have known behaviour for dereference requests MUST NOT be used. The LS MUST ignore any parameters that it does not understand unless it knows the parameters to be invalid. If parameters are known to be invalid, the LS MAY generate a HELD error response. For instance, those defined in are always invalid and can be rejected.
The LS MUST NOT generate location URIs or provide a locationUriSet in response to a dereference request. If the location request contains a locationType element that includes locationURI, this parameter is either ignored or rejected as appropriate, based on the associated exact attribute.
GET is the method assumed by generic HTTP user agents, therefore unless context identifies an https: URI as a HELD URI, such a user agent might simply send an HTTP GET. Rather than providing an HTTP 405 (Method Not Allowed) response indicating that POST is the only permitted method, this document describes a way for a LIS to provide a HELD location response if it receives an HTTP GET request.
An HTTP GET request to a HELD URI produces a HELD response as if the following HELD request had been sent using HTTP POST:
geodetic civic
]]>HTTP GET requests must be safe and idempotent - that is, there are no side-effects of making the request. Only when a location URI is created does HELD request have side-effects. A request to a location URI can be both safe and idempotent, since a location URI cannot be produced in response to a request to a location URI.
Idempotence does not require that the same answer be provided to different requests only that there are no side effects. Changes in the response can occur for a number of reasons, including a change in the value of the resource: the location of the Target.
Content negotiation MAY be supported to produce a presence document in place of a HELD location response. Where the presence document would otherwise be included in a locationResponse document, it can be included in the body of the HTTP response directly.
The example in shows the simplest form of dereferencing request using HELD to the location URI https://ls.example.com:49152/uri/w3g61nf5n66p0. The only way that this differs from the example in Section 10.1 of is in the request URI and the source of the URI.
]]> shows the response to the previous request listing both civic and geodetic location information of the Target's location. Again, this is identical to the response in Section 10.1 of - unless policy specfies otherwise, the Location Recipient receives the same information as the Device.
-34.407 150.88001
false
2011-01-11T03:42:29+00:00Wiremap2006-01-10T03:42:28+00:00
]]>The following GET request is treated in an equivalent fashion. The LS treats this request as though it were a location request of the form shown in . The same response might be provided.
The following GET request uses content negotiation to indicate a preference for a presence document.
The response only differs from a normal HELD location response to a POST request in that the locationResponse element is omitted and the Content-Type header reflects the changed content.
... PIDF contents are identical to the previous example ...
]]>Privacy of location information is the most important security consideration for this document. Two measures in particular are used to protect privacy: TLS and authorization policies. TLS provides a means of ensuring confidentiality of location information through encryption and mutual authentication. An authorization policy allows a Rule Maker to explicitly control how location information is provided to Location Recipients.
The process by which a Rule Maker establishes an authorization policy is not covered by this document; several methods are possible, for instance: , .
Use of TLS for the dereferencing of location URIs is strongly RECOMMENDED, as discussed in . Location Recipients MUST authenticate the host identity using the domain name included in the location URI, using the procedure described in Section 3.1 of . Local policy determines what a Location Recipient does if authentication fails or cannot be attempted.
The authorization by possession model further relies on TLS when transmitting the location URI to protect the secrecy of the URI. Possession of such a URI implies the same privacy considerations as possession of the PIDF-LO document that the URI references.
Location URIs MUST only be disclosed to authorized Location Recipients. The GEOPRIV architecture identifies the Rule Maker role as being the entity that authorizes disclosure of this nature.
Protection of the location URI is necessary, since the policy attached to such a location URI permits any who have the URI to view it. This aspect of security is covered in more detail in the specification of location conveyance protocols, such as .
The LS MUST NOT provide any information about the Target except its location, unless policy from a Rule Maker allows otherwise. In particular, the requirements in mandate this measure to protect the identity of the Target. To this end, an unlinked pseudonym MUST be provided in the entity attribute of the PIDF-LO document.
Further security considerations and requirements relating to the use of location URIs are described in .
This document makes no request of IANA.
[[IANA/RFC-EDITOR: Please remove this section before publication.]]
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. Richard Barnes made helpful observations on the application of authorization policy.The Participants of the GEOPRIV interim meeting 2008 provided significant feedback on this document.James Polk provided input on security in June 2008.This section describes how use of HELD as a location dereference protocol complies with the GEOPRIV requirements described in .
(Location Object generalities):
This section relates to the PIDF-LO document, which is used by HELD. These requirements are addressed by and .
(Location Object fields):
This section relates to the PIDF-LO document, which is used by HELD. These requirements are addressed by and .
(Location Data Types):
This section relates to the PIDF-LO document, which is used by HELD. These requirements are addressed by and .
Section 7.2 of details the requirements of a "Using Protocol". These requirements are restated, followed by a statement of compliance:
"The using protocol has to obey the privacy and security instructions coded in the Location Object and in the corresponding Rules regarding the transmission and storage of the LO."
Compliant: This document carries the PIDF-LO as is via HTTPS from the LS to the Location Recipient. The sending and receiving parties are expected to comply with the instructions carried inside the object.
"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."
Compliant: This document specifies that authentication of the LS uses the established public key infrastructure used by HTTP over TLS. Authentication of Location Recipients is either based on distribution of a secret (the location URI) using a conveyance protocol (for instance, ), allowances are made for later work to define alternative methods.
"(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."
Not Compliant: The XML encoding specified in is not suited to single packet transfers. Use of compressed content encoding might allow this condition to be met.
Section 7.3 of details the requirements of a "Rule based Location Data Transfer". These requirements are restated where they are applicable to this document:
"(LS Rules) The decision of a Location Server to provide a Location Recipient access to Location Information MUST be based on Rule Maker-defined Privacy Rules."
Compliant: This document describes two alternative methods by which a Rule Maker is able to control access to location information. Rule Maker policy is enforced by the LS when a location URI is dereferenced. However, this document does not describe how a location URI is created, or how a Rule Maker associates policy with a location URI. These are covered by other specifications.
(LG Rules) Not Applicable: This relationship between LS and the source of its information (be that Location Generator (LG) or LIS) is out of scope for this document.
"(Viewer Rules) A Viewer does not need to be aware of the full Rules defined by the Rule Maker (because a Viewer SHOULD NOT retransmit Location Information), and thus a Viewer SHOULD receive only the subset of Privacy Rules necessary for the Viewer to handle the LO in compliance with the full Privacy Rules (such as, instruction on the time period for which the LO can be retained)."
Compliant: The Rule Maker might define (via mechanisms outside the scope of this document) which policy rules are disclosed to other entities. For instance, if is used to convey authorization policies from Rule Maker to LS, this is possible using the parameters specified in .
(Full Rule language) Not Applicable: Note however that Geopriv has defined a rule language capable of expressing a wide range of privacy rules (see and .
(Limited Rule language) Not Applicable: This requirement applies to (and is addressed by) PIDF-LO.
Section 7.4 of details the requirements of "Location Object Privacy and Security". These requirements are restated where they are applicable to this document:
(Identity Protection) Compliant: Identity protection of the Target is provided as long as both of the following conditions are true:
the location URI is not associated with the identity of the Target in any context, and
the PIDF-LO does not contain information about the identity about the Target.
For instance, this requirement is complied with if the protocol that conveys the location URI does not link the identity of the Target to the location URI and the LS doesn't include meaningful identification information in the PIDF-LO document. recommends that an unlinked pseudonym is used by the LS.
(Credential Requirements) Compliant: The primary 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.(Security Features) Compliant: 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 most of these requirements. Authentication of Location Recipients in this document relies on proof of a shared secret - the location URI. This does not preclude the addition of more robust authentication procedures.
(Minimal Crypto) Compliant: The mandatory to implement ciphersuite is provided in the TLS layer security specification.This section describes how HELD complies to the location reference requirements stipulated in . Compliance to the Location Configuration Protocol are included in this document.
Note that use of HELD as a location dereference protocol does not necessarily imply that HELD is the corresponding LCP. This document is still applicable to HTTP location URIs that are acquired by other means.
"Location URI support: The location configuration protocol MUST support a location reference in URI form."
Compliant: HELD only provides location references in URI form.
"Location URI expiration: When a location URI has a limited validity interval, its lifetime MUST be indicated."
Compliant: HELD indicates the expiry time of location URIs using the expires attribute. provides a way to control expiration of a location URI; a Device is able to specify limits on the life time of a HELD context.
"Location URI cancellation: The location configuration protocol MUST support the ability to request a cancellation of a specific location URI."
Compliant with Extension: describes how a location URI can be cancelled through the application of policy. Without extensions, HELD does not provide a method for cancelling location URIs.
"Location Information Masking: The location URI MUST ensure, by default, through randomization and uniqueness, that the location URI does not contain location information specific components."
Compliant: The HELD specification explicitly references this requirement in providing guidance on the format of the location URI.
"Target Identity Protection: The location URI MUST NOT contain information that identifies the Target (e.g., user or device)."
Compliant: The HELD specification provides specific guidance on the anonymity of the Target with regards to the generation of location URIs. expands on this guidance.
"Reuse indicator: There SHOULD be a way to allow a Target to control whether a location URI can be resolved once only, or multiple times."
Not Compliant: Specific extensions to the protocol or authorization policy formats is needed to alter the default behavior, which allows unlimited resolution of the location URI.
"Selective disclosure: The location configuration protocol MUST provide a mechanism that allows the Rule Maker to control what information is being disclosed about the Target."
Compliant with Extension: Use of policy mechanisms and enable this capability. Note that this document recommends that only location information be provided.
"Location URI Not guessable: As a default, the location configuration protocol MUST return location URIs that are random and unique throughout the indicated lifetime. A location URI with 128-bits of randomness is RECOMMENDED."
Compliant: HELD specifies that location URIs conform to this requirement.
"Location URI Options: In the case of user-provided authorization policies, where anonymous or non-guessable location URIs are not warranted, the location configuration protocol MAY support a variety of optional location URI conventions, as requested by a Target to a location configuration server, (e.g., embedded location information within the location URI)."
Not Compliant: HELD does not support Device-specified location URI forms.
"Location URI support: The location dereference protocol MUST support a location reference in URI form."
Compliant: HELD only provides location references in URI form.
"Authentication: The location dereference protocol MUST include mechanisms to authenticate both the client and the server."
Partially Compliant: TLS provides means for mutual authentication. This document only specifies the required mechanism for server authentication. Client authentication is not precluded.
"Dereferenced Location Form: The value returned by the dereference protocol MUST contain a well-formed PIDF-LO document."
Compliant: HELD requires that location objects are in the form of a PIDF-LO that complies with .
"Location URI Repeated Use: The location dereference protocol MUST support the ability for the same location URI to be resolved more than once, based on dereference server configuration."
Compliant: A Location Recipient may access and use a location URI as many times as desired until URI expiration results in the URI being invalidated. Authorization policies might include rules that modify this behavior.
"The location dereference protocol MUST support confidentiality protection of messages sent between the Location Recipient and the location server."
Compliant: This document strongly recommends the use of TLS for confidentiality and HELD mandates its implementation. Unsecured HTTP is permitted, and some of the associated risks are described in .