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 element in the . Information that the End-Point wants in the context is included inside the 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. locationURI 7200 . . . Figure 1: createContext Usage An LCS that understands this new element SHALL include a 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 element in the 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 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769 data guff in here for extension Figure 2: LCS response to createContext The End-Point can update information associated with a context by sending an 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 data set SHALL remain unchanged. The End-Point MUST include the "id" attribute that it received as part of the with any 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 any 3600 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. https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769 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 as it did for a . The LCS SHALL return the same "id" as was used in the request. The End-Point MAY include the "lifeTime" in an 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 . If the "lifeTime" attribute is set to zero or is negative then the context SHALL expire immediately, and an empty 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 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 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 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 Winterbottom Expires December 24, 2007 [Page 10] Internet-Draft HELD Context June 2007 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 HELD Context Management Messages

Namespace for HELD Context Management Messages

urn:ietf:params:xml:ns:geopriv:held:context

[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]]

See RFCXXXX.

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]