One document matched: draft-winterbottom-geopriv-deref-protocol-00.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2616 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC3693 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml">
<!ENTITY RFC4119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml">
<!ENTITY RFC2818 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY RFC2617 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
<!ENTITY RFC4745 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4745.xml">
<!ENTITY RFC3987 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3987.xml">
<!ENTITY I-D.ietf-geopriv-http-location-delivery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery.xml">
<!ENTITY I-D.ietf-geopriv-l7-lcp-ps PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-l7-lcp-ps.xml">
<!ENTITY I-D.ietf-geopriv-pdif-lo-profile PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-pdif-lo-profile.xml">
<!ENTITY I-D.ietf-geopriv-lbyr-requirements PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-lbyr-requirements.xml">
<!ENTITY I-D.ietf-sip-location-conveyance PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-location-conveyance.xml">
<!ENTITY I-D.ietf-geopriv-policy PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-policy.xml">
<!ENTITY I-D.winterbottom-geopriv-held-context PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.winterbottom-geopriv-held-context.xml">
]>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" ipr="full3978" docName="draft-winterbottom-geopriv-deref-protocol-00.txt">
<front>
<title abbrev="HTTPS Dereferencing Protocol">An HTTPS Location Dereferencing Protocol Using HELD</title>
<author initials="J." surname="Winterbottom" fullname="James Winterbottom">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<phone>+61 242 212938</phone>
<email>james.winterbottom@andrew.com</email>
<uri>http://www.andrew.com/products/geometrix</uri>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<phone>+49 89 636 40390</phone>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<city>450 Computer Science Building</city>
<region>New York, NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<email>martin.thomson@andrew.com</email>
</address>
</author>
<author initials="M." surname="Dawson" fullname="Martin Dawson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<email>martin.dawson@andrew.com</email>
</address>
</author>
<date year="2007"/>
<area>Real-Time Applications and Infrastructure</area>
<workgroup>Geopriv</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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. </t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> 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) <xref target="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) (<xref target="RFC2616"/> and
<xref target="RFC2818"/>). </t>
<t> The document describes how HELD <xref target="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 <xref target="I-D.ietf-geopriv-lbyr-requirements"/>. HELD provides
location information in the form of a PIDF-LO (see <xref target="RFC4119"/>) which, as part
of its definition, complies with the requirements of a location object as described in <xref
target="RFC3693"/>. </t>
<t>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 <xref
target="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. </t>
<t> The general usage scenario envisioned by this document is shown in <xref target="fig1"/>.
While the figure shows a typical HELD location request being made to initially obtain the
location URI. As <xref target="fig1"/> indicates, an alternative Location Configuration
Protocol (LCP) that can provide a HELD URI can be used. </t>
<t>
<figure anchor="fig1" title="HTTPS Dereference Context Diagram Using HELD">
<artwork><![CDATA[
+-----------+
+------------+ | 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 |
| | | | |
| +--+-----------------------------+--+
| | |
| | |
]]></artwork>
</figure>
</t>
</section>
<section anchor="terminology" title="Terminology">
<t>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
<xref target="RFC2119"/>. </t>
<t>The key conventions and terminology used in this document are defined as follows: </t>
<t>This document reuses the term Target, as defined in <xref target="RFC3693"/>. </t>
<t> 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 <xref target="I-D.ietf-geopriv-l7-lcp-ps"/>. </t>
<t>The Location Recipient acts as a HELD client and the LIS as a HELD server in the context of
this document.</t>
</section>
<section title="Steps for Retrieval">
<t>
<list style="numbers">
<t>The Location Recipient obtains a helds: based location URI.</t>
<t>The HELD client establishes a TLS connection to the LIS, as described in <xref
target="RFC2818"/>. The TLS ciphersuite TLS_NULL_WITH_NULL_NULL MUST NOT be used.</t>
<t>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.</t>
<t>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.</t>
<t>The client retrieves the PIDF-LO document encapsulated into the HELD locationResponse
or an error message conveyed in a HELD error message.</t>
</list>
</t>
</section>
<section anchor="threats" title="Threat Models">
<t>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 <xref
target="I-D.ietf-sip-location-conveyance"/></t>
<t>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. </t>
<t>
<list style="hanging">
<t hangText="Authorization Policy Security Model:">
<vspace blankLines="1"/> The assumption of this model is that the LIS has some
authorization policies (such as those specified in <xref target="RFC4745"/> and <xref
target="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 <xref
target="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. <vspace
blankLines="1"/>
</t>
<t hangText="End-to-End Security Model:">
<vspace blankLines="1"/> 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.<vspace
blankLines="1"/>
</t>
<t hangText="Hop-by-Hop Security Model:">
<vspace blankLines="1"/>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. </t>
</list>
</t>
<t>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. </t>
<t> 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
<xref target="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,
<xref target="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. </t>
</section>
<section anchor="details" title="Using HELD to Dereference a Location URI">
<t>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. </t>
<t>The <locationType> 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 <xref target="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. </t>
<t>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 <spanx style="verb">exact</spanx> attribute.</t>
<t>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 <spanx style="verb">responseTime</spanx>
attribute and MAY be used by a Location Recipient to specify their preference for the
accuracy-time trade-off. </t>
<t>The LIS MUST support the HELD locationRequest semantic using an HTTP GET as described in
<xref target="I-D.ietf-geopriv-http-location-delivery"/>. </t>
<t> 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 <xref
target="I-D.ietf-geopriv-http-location-delivery"/>. </t>
</section>
<section anchor="examples" title="Examples">
<t><xref target="fig2"/> illustrates a simple dereferencing request example. </t>
<t>
<figure anchor="fig2" title="Minimal Dereferencing Request">
<artwork><![CDATA[
GET /357yc6s64ceyoiuy5ax3o HTTP/1.1
Host: lis.example.com
Accept:application/held+xml
]]></artwork>
</figure>
</t>
<t><xref target="fig3"/> shows a request indicating that both civic and geodetic location
information has to be returned. If it cannot be provided, the request fails.</t>
<t>
<figure anchor="fig3" title="Dereferencing Request for Civic and Geodetic Information">
<artwork><![CDATA[
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
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">
civic
geodetic
</locationType>
</locationRequest>
]]></artwork>
</figure>
</t>
<t><xref target="fig4"/> shows the response to the previous request listing both civic and
geodetic location information of the Target's location.</t>
<t>
<figure anchor="fig4" title="Response with Civic and Geodetic Location Information">
<artwork><![CDATA[
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
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
entity="pres:ae3be8585902e2253ce2@10.102.23.9">
<tuple id="lisLocation">
<status>
<geopriv>
<location-info>
<gs:Circle
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407242 150.882518</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">30
</gs:radius>
</gs:Circle>
<ca:civicAddress
ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xml:lang="en-au">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>Gwynneville</ca:A4>
<ca:STS>Northfield Avenue</ca:STS>
<ca:LMK>University of Wollongong</ca:LMK>
<ca:FLR>2</ca:FLR>
<ca:NAM>Andrew Corporation</ca:NAM>
<ca:PC>2500</ca:PC>
<ca:BLD>39</ca:BLD>
<ca:SEAT>WS-183</ca:SEAT>
<ca:POBOX>U40</ca:POBOX>
</ca:civicAddress>
</location-info>
<usage-rules>
<retransmission-allowed>false</retransmission-allowed>
<retention-expiry>2007-05-25T12:35:02+10:00
</retention-expiry>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2007-05-24T12:35:02+10:00</timestamp>
</tuple>
</presence>
</locationResponse>
]]></artwork>
</figure>
</t>
<t><xref target="fig5"/> shows an error message returned in response to a request.</t>
<t>
<figure anchor="fig5" title="Error Message">
<artwork><![CDATA[
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
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="cannotProvideLiType"
message="Authorization policies do not permit
location information to be disclosed."/>
]]></artwork>
</figure>
</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>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 <xref target="threats"/>, 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 <xref
target="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 <xref
target="I-D.winterbottom-geopriv-held-context"/>, provides additional security guarantees. </t>
<t>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. </t>
<t>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.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>There are no specific IANA considerations for this document. </t>
</section>
<section title="Acknowledgements">
<t>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.
</t>
</section>
</middle>
<back>
<references title="Normative References"> &RFC2119; &RFC2616; &RFC4119;
&RFC3693; &RFC2818; &I-D.ietf-geopriv-pdif-lo-profile;
&I-D.ietf-geopriv-http-location-delivery; &I-D.ietf-geopriv-lbyr-requirements; </references>
<references title="Informative references"> &I-D.ietf-geopriv-policy;
&I-D.winterbottom-geopriv-held-context; &RFC4745;
&I-D.ietf-sip-location-conveyance; &I-D.ietf-geopriv-l7-lcp-ps; </references>
<section title="GEOPRIV Using Protocol Compliance">
<t>This section compares the GEOPRIV requirements described in <xref target="RFC3693"/> with
the approach outlined in this document. </t>
<t>
<list style="format Req. %d." counter="Requirements">
<t>(Location Object generalities):</t>
</list>
<list style="symbols">
<t>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 <xref
target="RFC4119"/> allows both civic and geospatial location information to be
expressed. Combining this with <xref target="I-D.ietf-geopriv-pdif-lo-profile"/> ensures
that location can be constructed and interpreted in a consistent manner. </t>
<t>Regarding requirement 1.2, a number of fields in the civic location information format
are optional. </t>
<t>Regarding requirement 1.3, the civic location information is defined in an extensible
way. </t>
<t>Regarding requirement 1.4, the location information itself is not defined in this
document. </t>
<t>Regarding requirement 1.5, the protocol described in this document allows the Location
Recipient to resolve a reference to a PIDF-LO only. </t>
<t>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. </t>
<t>Regarding requirement 1.7, the Location Object is usable in a variety of protocols. </t>
<t>Regarding requirement 1.8, no change regarding with respect to the encoding of the
Location Object (see <xref target="RFC4119"/>) was made by this document. </t>
</list>
<list style="format Req. %d." counter="Requirements">
<t>(Location Object fields):</t>
</list>
<list style="symbols">
<t>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. </t>
<t>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. </t>
<t>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. </t>
<t>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.</t>
<t>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. </t>
<t>Regarding requirement 2.7, the PIDF-LO relevant elements and attributes are available.
<!-- [[Editor's Note: I need to lookup whether the PIDF-LO contains 'sighting
time' and 'TTL']]-->
</t>
<t>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
<external-ruleset> element. </t>
<t>Regarding requirement 2.9, security headers and trailers are provided Transport Layer
Security. </t>
<t>Regarding requirement 2.10, extensibility within the PIDF-LO is provided regarding the
definition of namespaces. </t>
</list>
<list style="format Req. %d." counter="Requirements">
<t>(Location Data Types):</t>
</list>
<list style="symbols">
<t>Regarding requirement 3.1, <xref target="RFC4119"/> defines geospatial location
information as the mandatory to implement location format. <xref
target="I-D.ietf-geopriv-pdif-lo-profile"/> describes in more detail the acceptable
forms of geolocation and its interaction with civic notations. </t>
<t>With the support of civic and geodedic location information in <xref target="RFC4119"/>
the requirement 3.2 is fulfilled. </t>
<t>Regarding requirement 3.3, rules described in <xref target="I-D.ietf-geopriv-policy"/>
apply to an absolute geodetic point. Geodetic information expressed in a PIDF-LO that
complies with <xref target="I-D.ietf-geopriv-pdif-lo-profile"/> may express an area or
volume there-by "fuzzing" the location of the Target. </t>
<t>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. </t>
</list>
<vspace blankLines="1"/> Section 7.2 of <xref target="RFC3693"/> details the requirements of
a "Using Protocol". These requirements are listed below: <vspace
blankLines="1"/>
<list style="format Req. %d." counter="Requirements">
<t>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. </t>
</list>
<list style="format Req. %d." counter="Requirements">
<t>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. </t>
</list>
<list style="format Req. %d." counter="Requirements">
<t>(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. </t>
</list>
<vspace blankLines="1"/> Section 7.3 of <xref target="RFC3693"/> details the requirements of
a "Rule based Location Data Transfer". These requirements are listed
below: <vspace blankLines="1"/>
<list style="format Req. %d." counter="Requirements">
<t anchor="lsreq">(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.</t>
</list>
<list style="format Req. %d." counter="Requirements">
<t>(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. </t>
</list>
<list style="format Req. %d." counter="Requirements">
<t>(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 <xref target="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.</t>
</list>
<list style="format Req. %d." counter="Requirements">
<t>(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 <xref target="RFC4745"/> and <xref
target="I-D.ietf-geopriv-policy"/>. These rules may be used in a larger context but
this document does not define their usage.</t>
</list>
<list style="format Req. %d." counter="Requirements">
<t>(Limited Rule language): A limited (or basic) ruleset was introduced with PIDF-LO <xref
target="RFC4119"/>). </t>
</list>
<vspace blankLines="1"/> Section 7.4 of <xref target="RFC3693"/> details the requirements of
"Location Object Privacy and Security". These requirements are listed
below: <vspace blankLines="1"/>
<list style="format Req. %d." counter="Requirements">
<t>(Identity Protection): Identity protection of the Target can be provided if both the
following conditions are true: <list style="format (%c)" counter="subbullets">
<t>the protocol used to convey the reference does not disclose the identity of the
Target and </t>
<t>if the PIDF-LO does not contain information about the identity about the
Target.</t>
</list>
<vspace blankLines="1"/> Currently, there is no mechanism available that allows the
Target to tell the LIS which identity information to include in the PIDF-LO.
<!-- What identity information is included in the PIDF-LO when created by HELD. -->
</t>
</list>
<list style="format Req. %d." counter="Requirements">
<t>(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. </t>
</list>
<list style="format Req. %d." counter="Requirements">
<t>(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. </t>
</list>
<list style="format Req. %d." counter="Requirements">
<t>Minimal Crypto: The mandatory to implement ciphersuite is provided in the TLS layer
security specification.</t>
</list>
</t>
</section>
<section title="HELD Compliance to IETF Location Reference Requirements">
<t>This section describes how HELD complies to the location reference requirements stipulated
in <xref target="I-D.ietf-geopriv-lbyr-requirements"/>. </t>
<t>High-level requirements for a location configuration protocol. <list style="format C%d."
counter="HLLCP-LbyRreq">
<t><spanx style="verb">Location URI support - LCP: The configuration protocol MUST support
a location reference in URI form.</spanx>
<vspace blankLines="2"/> COMPLY. HELD only provides location references in URI form.
<vspace blankLines="1"/>
</t>
<t><spanx style="verb">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.</spanx>
<vspace blankLines="2"/> COMPLY. basic HELD supports the LIS informing the Target of the
location URI expiry time. HELD context management extension <xref
target="I-D.winterbottom-geopriv-held-context"/> provides the Target the ability to
specify exipry times for location URIs. <vspace blankLines="1"/>
</t>
<t><spanx style="verb">Location URI cancellation: The LCP MUST support the ability to
request the cancellation of a specific location URI.</spanx>
<vspace blankLines="2"/> COMPLY. HELD context management extension <xref
target="I-D.winterbottom-geopriv-held-context"/> provides the Target the ability to
void location URIs when required. <vspace blankLines="1"/>
</t>
<t><spanx style="verb">Random Generated: The location URI MUST be hard to guess, i.e., it
MUST contain a cryptographically random component.</spanx>
<vspace blankLines="2"/> COMPLY. The HELD specification provides specific guidance on
the security surrounding location URI generation. <vspace blankLines="1"/>
</t>
<t><spanx style="verb">Identity Protection - LCP: The location URI MUST NOT contain any
information that identifies the user, device or address of record within the URI form.</spanx>
<vspace blankLines="2"/> COMPLY. The HELD specification provides specific guidance on
the anonymity of the Target with regards to the generation of location URIs. <vspace
blankLines="1"/>
</t>
<t><spanx style="verb">Reuse flag default: The LCP MUST support the default condition of a
requested location URI being repeatedly reused.</spanx>
<vspace blankLines="2"/> COMPLY. The default semantics of location URIs in HELD place no
limits on the number of times that a location URI can be dereferenced. <vspace
blankLines="1"/>
</t>
<t><spanx style="verb">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).</spanx>
<vspace blankLines="2"/> COMPLY. HELD context management extension <xref
target="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. <vspace
blankLines="1"/>
</t>
</list>
</t>
<t>High-level requirements for a location dereference protocol.</t>
<t>
<list style="format D%d." counter="HLLDP-LbyRreq">
<t><spanx style="verb">Location URI support - LDP: The LDP MUST support a location
reference in URI form.</spanx>
<vspace blankLines="2"/> COMPLY. HELD only provides location references in URI form.
<vspace blankLines="1"/>
</t>
<t><spanx style="verb">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.</spanx>
<vspace blankLines="2"/> 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. <vspace blankLines="1"/>
</t>
<t><spanx style="verb">Authentication: The LDP MUST support either client-side and
server-side authentication between client and server.</spanx>
<vspace blankLines="2"/> COMPLY. Client authentication may be provided using a variety
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
<xref target="RFC2818"/>. <vspace blankLines="1"/>
</t>
<t><spanx style="verb">Dereferenced Location Form: Location URI dereferencing MUST result
in a well-formed PIDF-LO.</spanx>
<vspace blankLines="2"/> COMPLY. HELD when used as a dereference protocol MUST provide
location information as a PIDF-LO that complies with <xref
target="I-D.ietf-geopriv-pdif-lo-profile"/> as described in <xref target="details"/>.
<vspace blankLines="1"/>
</t>
<t><spanx style="verb">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.</spanx>
<vspace blankLines="2"/> 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. <vspace blankLines="1"/>
</t>
<t><spanx style="verb">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).</spanx>
<vspace blankLines="2"/> COMPLY. Using base-HELD the location of the Target is
determined each time that URI is accessed. <vspace blankLines="1"/>
</t>
<t><spanx style="verb">Location form: The LDP MUST support dereferenced location in both
coordinate and civic forms.</spanx>
<vspace blankLines="2"/> COMPLY. HELD provide the locationType parameter allowing the
Location Recipient the ability to specify the form of location they require. <vspace
blankLines="1"/>
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 05:06:46 |