Geopriv J. Winterbottom
Internet-Draft Andrew Corporation
Intended status: Standards Track June 22, 2007
Expires: December 24, 2007
HELD Protocol Context Management Extensions
draft-winterbottom-geopriv-held-context-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 December 24, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Winterbottom Expires December 24, 2007 [Page 1]
Internet-Draft HELD Context June 2007
Abstract
This document describes a protocol extension for HELD enabling an
End-Point to manage stateful information on an LCS.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Detailed Description . . . . . . . . . . . . . . . . . . . . . 5
4. Location URI and id Generation Rules . . . . . . . . . . . . . 9
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Guidelines For Defining Context Data Extensions . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:context . . . . . . . 15
8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Winterbottom Expires December 24, 2007 [Page 2]
Internet-Draft HELD Context June 2007
1. Introduction
The HELD specification [I-D.ietf-geopriv-http-location-delivery]
provides a set of features that can be used by an End-Point to
retrieve location information from an LCS. The basic HELD
specification does this in a more or less stateless manner. There
are situations however, where the End-Point wants or requires
explicit management of data in a stateful manner on the LCS. This
specification describes an extension to the HELD protocol to support
End-Point management of state information contained in a "context" on
the LCS.
Information contained in a context relates to a specific End-Point.
One of the most critical pieces of functionality provided in this
specification is the ability to void a location URI. This is
important, because without this functionality there is no way stop a
third-party that has your location URI from obtaining your location.
This condition will persist until the location URI expires. The
extension defined in this specification changes this behaviour by
providing the End-Point the means to create, update, and terminate a
context on the LCS to which a specific location URI set is bound.
Terminating the context therefore explicitly voids the location URI
ending the ability of a third-party to locate the Target.
In addition to context management constructs this document also
provides a set of guidelines to be followed by designers of future
context data extensions.
Winterbottom Expires December 24, 2007 [Page 3]
Internet-Draft HELD Context June 2007
2. Terminology
The key conventions and terminology used in this document are defined
as follows:
This document reuses the terms Target, as defined in [RFC3693].
This document uses the term Location Configuration Server, LCS, as
the node in the access network providing location information to an
end-point. This term is also used in [I-D.ietf-geopriv-l7-lcp-ps].
This document uses the term End-Point to refer to the device or host
requesting to which contextual information stored on the LCS applies.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Winterbottom Expires December 24, 2007 [Page 4]
Internet-Draft HELD Context June 2007
3. Detailed Description
An End-Device wishing to have a context created on the LCS includes a
<createContext> element in the <locationRequest>. Information that
the End-Point wants in the context is included inside the
<createContext> element. Extensibility to the context scheme is
provided to allow additional elements to added to the context easily.
The general idea is shown in Figure 1.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType>locationURI</locationType>
<hcx:createContext
hcx:xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
hcx:lifeTime="7200">
<ex1:extension-1
ex1:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex1">
<ex1:value>7200</ex1:value>
</ex1:extension-1>
<extension-2 xmlns="urn:ietf:params:xml:ns:geopriv:held:ex2"/>
<extension-3 xmlns="urn:ietf:params:xml:ns:geopriv:held:ex3"/>
.
.
.
<extension-N xmlns="urn:ietf:params:xml:ns:geopriv:held:exN"/>
</hcx:createContext>
</locationRequest>
Figure 1: createContext Usage
An LCS that understands this new element SHALL include a
<contextResponse> element in the corresponding heldRepsonse message.
An LCS that does not understand this new element MUST ignore the
element as per [I-D.ietf-geopriv-http-location-delivery]. The End-
Point MUST assume that the LCS does not understand context related
messages if it does not obtain a <contextResponse> element in the
<heldResponse> message when a context was requested. Since it is
impossible to predict in advance which elements and extensions the
LCS will understand before sending them, a mechanism for the LCS to
tell the End-Point which elements were understood and used is
required by each context data extension. Guidelines for defining
context data extensions are provided in Section 6.
An LCS supporting the behaviour described in the previous section may
respond to the locationRequest of Figure 1 with a response similar to
Figure 2.
Winterbottom Expires December 24, 2007 [Page 5]
Internet-Draft HELD Context June 2007
<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="200" message="OK">
<locationUriSet expires="2007-08-01T13:00:00">
<locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>
sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769
</locationURI>
</locationUriSet>
<hcx:contextResponse
hcx:xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
hcx:id="uhvuhdbnuiehudbnvcujevuijeijcvij">
<ex1:extension-1 ex1:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex1"
ex1:response="OK"/>
<ex2:extension-2 ex2:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex2"
ex2:response="OK"/>
<ex3:extension-3
ex3:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex3">
<ex3:datum-3>data</ex3:datum-3>
<ex3:stuff>guff in here for extension</ex3:stuff>
</ex3:extension-3>
</hcx:contextRresponse>
</heldResponse>
Figure 2: LCS response to createContext
The End-Point can update information associated with a context by
sending an <updateContext> element in a locationRequest message,
along with the data that it wants changed in its context. Elements
previously provided to the LCS but not included in the
<updateContext> data set SHALL remain unchanged. The End-Point MUST
include the "id" attribute that it received as part of the
<contextResponse> with any <updateContext> request to clearly
identify the changing context to the LCS. This is important because
in some circumstances an End-Point may be behind a firewall or NAT so
the LCS can't distinguish the End-Point creating the context from
other devices behind the same NAT. The "id" makes this distinction
possible.
Winterbottom Expires December 24, 2007 [Page 6]
Internet-Draft HELD Context June 2007
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType>any</locationType>
<hcx:updateContext
hcx:xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
hcx:id="uhvuhdbnuiehudbnvcujevuijeijcvij">
<ex1:extension-1
ex1:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex1">
<ex1:value>3600</ex1:value>
</ex1:extension-1>
</hcx:updateContext>
</locationRequest>
Figure 3: updateContext Usage
In the example shown in Figure 3 the End-Point is updating the
context created in Figure 1 so that the value associated with
extensions-1 will be set to 3600 rather then the previous value of
7200. The response from the LCS is shown in Figure 4.
<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="200" message="OK">
<locationUriSet expires="2007-08-01T13:00:00">
<locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>
sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769
</locationURI>
</locationUriSet>
<hcx:contextResponse
hcx:xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
hcx:id="uhvuhdbnuiehudbnvcujevuijeijcvij">
<ex1:extension-1 ex1:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex1"
ex1:response="OK"/>
</hcx:contextRresponse>
</heldResponse>
Figure 4: LCS response to updateContext
The End-Point MUST include a locationType of locationURI in the
locationRequest, other location type MAY also be present. The LCS
SHALL return the same location URI set in response to an
Winterbottom Expires December 24, 2007 [Page 7]
Internet-Draft HELD Context June 2007
<updateContext> as it did for a <createContext>. The LCS SHALL
return the same "id" as was used in the request.
The End-Point MAY include the "lifeTime" in an <updateContext>
request if it wishes to alter the lifetime of the context. Any
change to lifetime SHALL be reflected in the expires attribute of the
returned <locationUriSet>. If the "lifeTime" attribute is set to
zero or is negative then the context SHALL expire immediately, and an
empty <heldResponse> message SHALL be returned with a "code" of 200.
When a context expires the LCS SHALL, immediately, delete all
information associated with the context and void all location URIs
associated with the context.
An <updateContext> request containing an "id" that is not recognized
by the LCS, or is for an expired context SHALL result in the LCS not
returning a <contextResponse> in the subsequent heldResponse.
Winterbottom Expires December 24, 2007 [Page 8]
Internet-Draft HELD Context June 2007
4. Location URI and id Generation Rules
A primary aim of this specification is to provide an End-Point with
the ability to void a location URI when it is associated with a
context. To achieve this, a location URI generated as part of a
context creation needs to be unique with in the scope of the LCS, and
applicable only to that context. If the End-Point destroys a context
and then subsequently creates a new one, URIs associated the new
context MUST be different from those generated for the previous
context.
The context id provided by the LCS to the End-Point in the
<contextResponse> MUST be unique per context, and SHOULD be different
from the identifier provided in any generated location URI. This
latter constraint ensures that possession of a location URI does not
automatically provide access and control over the internals of the
context.
A context id is generated by an LCS to uniquely identify a context.
The context id MUST NOT include any information that could be used to
identify the Target or End-Point. Similarly, it MUST NOT be feasible
for a third-party to easily determine a context id by knowing the
identity of the Target or End-Point. This implies that internal
correlation (using a hash-table or similar) is the only method that
the LCS can use to associate a context id with a particular End-
Point.
Winterbottom Expires December 24, 2007 [Page 9]
Internet-Draft HELD Context June 2007
5. XML Schema
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:context"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:heldCx="urn:ietf:params:xml:ns:geopriv:held:context"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:complexType name="createContextMsg">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="lifeTime" type="xs:integer"
use="optional"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="contextResponseMsg">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:token"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="updateContextMsg">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:token"
use="required"/>
Winterbottom Expires December 24, 2007 [Page 10]
Internet-Draft HELD Context June 2007
<xs:attribute name="lifeTime" type="xs:integer"
use="optional"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="createContext" type="heldCx:createContextMsg"/>
<xs:element name="updateContext" type="heldCx:updateContextMsg"/>
<xs:element name="contextResponse" type="heldCx:contextResponseMsg"/>
</xs:schema>
Figure 5: LCS response to updateContext
Winterbottom Expires December 24, 2007 [Page 11]
Internet-Draft HELD Context June 2007
6. Guidelines For Defining Context Data Extensions
A context contains specific information about an End-Point and is
stored on the LCS. It is impossible to predetermine all information
that an End-Point may want or need stored in a context so the context
control mechanisms need to be flexible to allow easy extensibility.
When defining context data extensions it is necessary to consider how
they will be used; this includes not only how to provide the
information from the End-Point to the LCS, but also acceptance and
error indications from the LCS back to the End-Point. For example a
context may be created with several extensions included, how does the
LCS indicate that extensions 1 and 3 were successful but that
extension 2 had a problem in its formatting? Guidelines for
designing context extensions that provide functionality are described
in this section.
Two basic types of context data extension are envisioned. The first
consist of data provided by the End-Point to be consumed by the LCS;
for example information pertaining to PIDF-LO construction, usage-
rules, and authorization policies. The second type of data consists
of a two way exchange between the End-Device and the LCS; for example
exchanging location determination capabilities.
When defining a context data extension it is necessary to ensure that
the LCS can provide an adequate response to the End-Point application
indicating acceptance or rejection of the data provided. This may be
an explicit OK or FAIL message within the extension namespace, or it
may be an attribute associated with part of a larger data exchange.
Either way it is mandatory for a context data extension to provide
this functionality.
When defining information to be included in a context data extension
consideration should be given to how that data can be removed from
the context. In some cases it may be necessary to void the context
on the LCS in order to remove information, but this SHOULD be treated
as a last resort and not used as the primary mechanism for removing
data from the context.
Winterbottom Expires December 24, 2007 [Page 12]
Internet-Draft HELD Context June 2007
7. Security Considerations
There are several security concerns associated with the details in
this specification. The first is to do with the nature of the
sensitivity of any data passed from the End-Point to the LCS for
inclusion in a context. The second is the ability of the LCS to
contain the number of contexts that it will permit to exist for a
given End-Point address.
HELD [I-D.ietf-geopriv-http-location-delivery] mandates the use of
TLS for exchanges between an End-Point and the LCS. This is deemed
sufficiently secure to hide any contextual data from a would-be
eavesdropper while the data is in transit. The LCS implementation
and the operator of the LCS need to take sufficient steps to ensure
that active contextual data on the LCS is not readily available to
anyone other than the End-Point that owns the data. The End-Point
MUST not provide any information to the LCS that it does not want the
LCS to know or be able to use in some capacity associated with
determination or providing of the End-Point's location. The LCS
SHALL not use any context information provided to it by an End-Point
except to assist it with the determination and generation of location
information associated with the End-Point.
It is quite conceivable that an LCS will be required to provide
location to end hosts residing behind a NAT; a DSL home router with 5
PCs attached is a good example this situation. In this case it is
reasonable for each device to create its own context on the LCS, and
for the LCS to treat each context individually even though the LCS
cannot make any other distinction between the end hosts; that is,
they share a common IP address/identity from the LCS perspective. It
may even be reasonable in some situations for a single device to want
more than one context. This environment however opens the LCS to a
type of denial of service attack through an overload on contexts. It
is RECOMMENDED that an implementor of this specification include
mechanisms to restrict to maximum number of contexts that can be
created on the LCS by an individual End-Point. It is RECOMMENDED
that an LCS operator impose limits on context creation such that it
is restricted to a sustainable level.
This specification provides the ability to for an End-Point to void a
location URI which extends the End-Point's ability to enforce it
rights to privacy. Using the mechanisms described in this memo an
End-Point can create URIs with short validity periods, this restricts
how long a third-party is able to obtain the location of the End-
Point while still allowing the End-Point the convenience of using a
location reference. Using short-term location URIs in a carefully
controlled manner may obviate the need for individual location
authorization policies on the LCS. This leads to reduced LCS
Winterbottom Expires December 24, 2007 [Page 13]
Internet-Draft HELD Context June 2007
complexity and the amount of private information that the End-Point
need share with the LCS.
The generation of context identifiers by the LCS is a critical
component to supporting the functionality described in this memo.
The LCS MUST follow the rules described in Section 4 for generating
context identifiers.
Winterbottom Expires December 24, 2007 [Page 14]
Internet-Draft HELD Context June 2007
8. IANA Considerations
This document registers the schema and associated namespace with
IANA.
8.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:context
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held:context", as per the guidelines
in [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:held:context
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), James Winterbottom
(james.winterbottom@andrew.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Context Management Messages</title>
</head>
<body>
<h1>Namespace for HELD Context Management Messages</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:context</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
8.2. XML Schema Registration
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held:context
Winterbottom Expires December 24, 2007 [Page 15]
Internet-Draft HELD Context June 2007
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
James Winterbottom (james.winterbottom@andrew.com).
Schema: The XML for this schema can be found as the entirety of
Figure 5 of this document.
Winterbottom Expires December 24, 2007 [Page 16]
Internet-Draft HELD Context June 2007
9. Acknowledgements
Thanks to Adam Muhlbauer and Neil Justusson for their comments on the
pre-version of this draft.
Winterbottom Expires December 24, 2007 [Page 17]
Internet-Draft HELD Context June 2007
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[I-D.ietf-geopriv-http-location-delivery]
Barnes, M., "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-00 (work in
progress), June 2007.
[I-D.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-02 (work in
progress), April 2007.
Winterbottom Expires December 24, 2007 [Page 18]
Internet-Draft HELD Context June 2007
Author's Address
James Winterbottom
Andrew Corporation
PO Box U40
University of Wollongong, NSW 2500
AU
Email: james.winterbottom@andrew.com
Winterbottom Expires December 24, 2007 [Page 19]
Internet-Draft HELD Context June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Winterbottom Expires December 24, 2007 [Page 20]