Geopriv J. Winterbottom Internet-Draft M. Thomson Expires: August 10, 2005 M. Dawson Nortel Networks February 9, 2005 ECRIT Location Scope Requirements draft-winterbottom-ecrit-location-scope-req-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 10, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Special kinds of services require user location information to be authenticated and validated within a specific operating domain. An example of such a service is the emergency services network, where the location of a caller is known with in the domain of the telephone network, while the name or true identity of the caller is not intrinsically known. This paper describes the entities and key Winterbottom, et al. Expires August 10, 2005 [Page 1] Internet-Draft ECRIT Location Scope February 2005 requirements necessary to provide such a service in an internet environment. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Key Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Requirement 1 . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Requirement 2 . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Requirement 3 . . . . . . . . . . . . . . . . . . . . . . 5 3.4 Requirement 4 . . . . . . . . . . . . . . . . . . . . . . 5 3.5 Requirement 5 . . . . . . . . . . . . . . . . . . . . . . 6 3.6 Requirement 6 . . . . . . . . . . . . . . . . . . . . . . 6 3.7 Requirement 7 . . . . . . . . . . . . . . . . . . . . . . 6 3.8 Requirement 8 . . . . . . . . . . . . . . . . . . . . . . 6 3.9 Requirement 9 . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Normative references . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Winterbottom, et al. Expires August 10, 2005 [Page 2] Internet-Draft ECRIT Location Scope February 2005 1. Introduction Some network elements and services have special requirements on information concerning a user's location that must be satisfied before the service is provided to the user. The primary group of services that fall into this category are the emergency services that make use of a user's location to route calls to their destination and subsequently dispatch service crews to that destination. Since the cost of providing these services is high, and the risk to service crews in many cases is life threatening, simply trusting that a user has provided an accurate and valid location is not enough. The service provider requires additional information tying the user to his/her location and some audit trail to the access network servicing the user in the event of a mishap. In the interests of continuous improvement, it is desirable that incidences of erroneous location information being provided can be traced back to an answerable access provider and corrected. This paper describes a base set of requirements that need to be met to satisfy emergency service provider's and then goes on to place scope around these requirements based on possible access types and situations. Winterbottom, et al. Expires August 10, 2005 [Page 3] Internet-Draft ECRIT Location Scope February 2005 2. Terminology The key conventions and terminology used in this paper are defined as follows: End-User: The user or user device entity needing sending his/her location to another entity in the network. Domain: An area or group of services falling with in a specific category or jurisdictional boundary. Domain Authentication and Validation Entity: A node that has authority within a given domain to authenticate and validate user location information. 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, et al. Expires August 10, 2005 [Page 4] Internet-Draft ECRIT Location Scope February 2005 3. Key Requirements 3.1 Requirement 1 The emergency network in most cases today is accessed via the PSTN using either a wireline or a cellular device. In both cases location information is provided by the Carrier and is used directly to route the call. Since the Carrier must route the call to the emergency network, the emergency network holds the carrier responsible for the correct location determination and routing, and this forms the basis of requirement 1. A certain level of authentication and validation around the source of the location is required for the domain in which the information is to be used. 3.2 Requirement 2 The location information MUST be attributed to a specific point in time. That is, the location used for routing and which is reported to the emergency services operator, must be the actual location of the caller at the time of making the call. This provides operator's with confidence that the End-User is at the location. This is accomplished today with existing telephony networks either through the use of a calling-number to address "wire-map" database, or for cellular with more complex triangulation and GPS based techniques where the location is determined by the network and delivered at the time of the call. 3.3 Requirement 3 The location information MUST be attributed to a specific End-User. That is, for each call initiated, the emergency network requires that the location was determined for that specific caller and is not reused from a location determination applicable to a different End-User. This information defines when the location was attributed to the End-User, thereby tying a valid location to a user at a specific point in time. 3.4 Requirement 4 Requirement 1 states that a level of authentication and validation for the source of the location is required. This implies the need to for the End-User to determine the authenticating and validating entity for the emergency services domain in which they reside. That is, it must be possible for an End-User to discover and utilize an answerable source of location in the access network they are using. Winterbottom, et al. Expires August 10, 2005 [Page 5] Internet-Draft ECRIT Location Scope February 2005 3.5 Requirement 5 The End-User must be able to establish a session with the access domain authenticating and validating entity to obtain a certified location. The authentication of the location is granted with an expiry time, after which the location within the domain is deemed invalid. 3.6 Requirement 6 The session between the End-User and the domain authenticating and validating entity SHALL NOT require the true identity of the End-User. That is, the true identity of the user need never be revealed to the domain authenticating and validating entity, a random unique pseudonym generated within the authenticated domain is sufficient. 3.7 Requirement 7 The domain authenticating and validation entity MUST be able to accept a location provided by an End-User. On receipt of the End-User's location the domain authenticating and validation entity SHOULD validate the location as being applicable to that domain that is, it falls within reasonable geographic boundaries for that domain - before returning the certified location to the End-User. 3.8 Requirement 8 The End-User may have no means of determining or providing a location, in which case the domain authentication and validation entity MAY provide an estimate of location. 3.9 Requirement 9 Where the End-User does not desire the transmission of their location in-band with their call setup, they shall have the option of requesting a unique query key such that only authorized end points may query the location directly from the domain. Winterbottom, et al. Expires August 10, 2005 [Page 6] Internet-Draft ECRIT Location Scope February 2005 4. Security Considerations The requirements put forth in this draft suggest signaling interfaces which have a variety of potential threats. Each of the specific protocols defined in support of these requirements must adequately address those threats. Winterbottom, et al. Expires August 10, 2005 [Page 7] Internet-Draft ECRIT Location Scope February 2005 5. IANA Considerations This document does not introduce any IANA considerations. Winterbottom, et al. Expires August 10, 2005 [Page 8] Internet-Draft ECRIT Location Scope February 2005 6. Acknowledgments 7 Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. Authors' Addresses James Winterbottom Nortel Networks Wollongong NSW Australia EMail: winterb@nortelnetworks.com Martin Thomson Nortel Networks Wollongong NSW Australia EMail: marthom@nortelnetworks.com Martin Dawson Nortel Networks Wollongong NSW Australia EMail: mdawson@nortelnetworks.com Winterbottom, et al. Expires August 10, 2005 [Page 9] Internet-Draft ECRIT Location Scope February 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Winterbottom, et al. Expires August 10, 2005 [Page 10]