--- 1/draft-ietf-ecrit-lost-09.txt 2008-05-28 22:12:12.000000000 +0200 +++ 2/draft-ietf-ecrit-lost-10.txt 2008-05-28 22:12:12.000000000 +0200 @@ -1,24 +1,24 @@ ECRIT T. Hardie Internet-Draft Qualcomm, Inc. Intended status: Standards Track A. Newton -Expires: September 29, 2008 American Registry for Internet +Expires: November 28, 2008 American Registry for Internet Numbers H. Schulzrinne Columbia University H. Tschofenig Nokia Siemens Networks - March 28, 2008 + May 27, 2008 LoST: A Location-to-Service Translation Protocol - draft-ietf-ecrit-lost-09.txt + draft-ietf-ecrit-lost-10.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 @@ -29,21 +29,21 @@ 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 September 29, 2008. + This Internet-Draft will expire on November 28, 2008. Abstract This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. Table of Contents @@ -98,27 +98,27 @@ 15. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 43 16. Internationalization Considerations . . . . . . . . . . . . . 50 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 17.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 51 17.2. Content-type registration for 'application/lost+xml' . . . 51 17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53 17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53 17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54 18. Security Considerations . . . . . . . . . . . . . . . . . . . 55 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 - 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 - 20.1. Normative References . . . . . . . . . . . . . . . . . . . 59 - 20.2. Informative References . . . . . . . . . . . . . . . . . . 60 - Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 61 - Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 75 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 - Intellectual Property and Copyright Statements . . . . . . . . . . 77 + 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 + 20.1. Normative References . . . . . . . . . . . . . . . . . . . 60 + 20.2. Informative References . . . . . . . . . . . . . . . . . . 61 + Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 62 + Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 76 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 + Intellectual Property and Copyright Statements . . . . . . . . . . 78 1. Introduction Protocols such as NAPTR records and the Service Location Protocol (SLP) can be used to discover servers offering a particular service. However, for an important class of services the appropriate specific service instance depends both on the identity of the service and the geographic location of the entity that needs to reach it. Emergency telecommunications services are an important example; here, the service instance is a Public Safety Answering Point (PSAP) that has @@ -1299,21 +1299,26 @@ required to forward a call to one of its neighbors; this is an expected part of the overall emergency response system. In non- emergency service use cases, the service deployment model should take into account this issue as part of the provisioning model, as the combination of the data in the LoST server and the algorithm used for mapping determine which contact URIs are returned when shapes are used which overlap multiple service areas. As a general guideline, any deployed matching algorithm should ensure that the algorithm used does not needlessly return NULL results if - there are valid results for any portion of the shape. + there are valid results for any portion of the shape. If an + authoritative server receives a query for which the area in the query + overlaps the area for which the server has mapping information, then + it MUST return either a mapping whose coverage area intersects the + query area or a redirect to another server whose coverage area is a + subset of the server's coverage area. When geodetic location information of this location profile is placed in the element then the elements with geospatial coordinates are alternative descriptions of the same service region, not additive geometries. 12.3. Basic Civic Profile The basic-civic location profile is identified by the token 'civic'. Clients use this profile by placing a element, defined @@ -2051,38 +2056,64 @@ attacker that can prevent the lookup of contact URIs can impair the reachability of such services. An attacker that can eavesdrop on the communication requesting this lookup can surmise the existence of an emergency and possibly its nature, and may be able to use this to launch a physical attack on the caller. To avoid an attacker modifying the query or its result, TLS MUST be implemented and SHOULD be used. Use is RECOMMENDED both for clients' queries to servers and for queries among servers; this latter recommendation is to help avoid LoST cache poisoning attacks by - replacing answers given to caching LoST servers. The use of server - identity checks is also RECOMMENDED, as described in [4] . + replacing answers given to caching LoST servers. - In emergency service use cases, it is likely that deployments will - see a large number of inputs to the U-NAPTR algorithm resolving to a - single server. This is because local organizations will likely be - permitted or even encouraged to use LoST servers provided by the - local emergency services authority. This makes the use of - alternatives to server identity which would check the input to the - U-NAPTR algorithm against the certificates provided by the LoST - server impractical, as the list of organizations using it would be - large, subject to rapid change, and unknown to the LoST server - operator. The use of server identity does leave open the possibility - of DNS cache poisoning attacks, as the NAPTR records may be altered - by an attacker. U-NAPTR recommends DNSSEC [20] as protection. While + The use of server identity checks with TLS, as described in Section + 3.1 of [4] is also RECOMMENDED. Omitting the server identity check + allows an attacker to masquerade as a LoST server, so this approach + should be used only when getting any answer, even from a potentially + malicious LoST server, is preferred over closing the connection (and + thus not getting any answer at all). The host name compared against + the server certificate is the host name in the URI, not the DNS name + used as input to NAPTR resolution. + + Note that the security considerations in [22] recommend comparing the + input of NAPTR resolution to the certificate, not the output (host + name in the URI). This approach was not chosen because in emergency + service use cases, it is likely that deployments will see a large + number of inputs to the U-NAPTR algorithm resolving to a single + server, typically run by a local emergency services authority. In + this case, checking the input to the NAPTR resolution against the + certificates provided by the LoST server would be impractical, as the + list of organizations using it would be large, subject to rapid + change, and unknown to the LoST server operator. + + The use of server identity does leave open the possibility of DNS + based attacks, as the NAPTR records may be altered by an attacker. he + attacks include, for example, interception of DNS packets between the + client and the recursive name server, DNS cache poisoning, and + intentional modifications by the recursive name server; see [23] for + more comprehensive discussion. + + DNSSEC [20] can be used to protect against these threats. While DNSSEC is incompletely deployed, users should be aware of the risk, - particularly when they are requesting NAPTR records for domains or - from servers with which they have no previous trust relationship. + particularly when they are requesting NAPTR records in environments + where the local recursive name server, or the network between the + client and the local recursive name server, is not considered + trustworthy. + + LoST deployments which are unable to use DNSSEC and unwilling to + trust DNS resolution without DNSSEC, cannot use the NATPR-based + discovery of LoST servers as-is. When suitable configuration + mechanisms are available, one possibility is to configure the LoST + server URIs (instead of the domain name to be used for NAPTR + resolution) directly. Future specifications for applying LoST in + non-emergency services may also specify additional discovery + mechanisms and name matching semantics. Generally, LoST servers will not need to authenticate or authorize clients presenting mapping queries. If they do, an authentication of the underlying transport mechanism, such as HTTP basic and digest authentication MAY be used. Basic Authentication SHOULD only be used in combination with TLS. A more detailed description of threats and security requirements are provided in [17]. The threats and security requirements in non- emergency service uses of LoST may be considerably different from @@ -2138,22 +2169,20 @@ o James Polk (error handling) o Ron Watro and Richard Barnes (expiry of cached data) o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James Winterbottom (Indication of PSAP Confidence Level) o Martin Thomson (service boundary references) o Martin Thomson (service URN in LoST response message) - o Cullen Jennings (service boundaries) - o Clive D.W. Feather, Martin Thomson (Validation Functionality) o Roger Marshall (PSAP Preference in LoST response) o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor, Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W. Feather, Richard Stastny, John Hearty, Roger Marshall, Jean- Francois Mule, Pierre Desjardins (Location Profiles) o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson, @@ -2181,21 +2210,27 @@ o Wonsang Song o Jong-Yul Kim o Anna Makarowska o Krzysztof Rzecki o Blaszczyk Piotr - We would like to thank Jon Peterson for his IESG review comments. + We would like to thank Jon Peterson, Dan Romascanu, Lisa Dusseault, + and Tim Polk for their IESG review comments. Blocking IESG comments + were also received from Pasi Eronen (succeeding Sam Hartman's review) + and Cullen Jennings. Adjustments have been made to several pieces of + text to satisfy these requests for changes, most notably in the + Security Considerations and in the discussion of redirection in the + presence of overlapping coverage areas. 20. References 20.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, @@ -2268,23 +2303,30 @@ progress), September 2007. [20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [21] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", draft-ietf-ecrit-phonebcp-04 (work in progress), February 2008. + [22] Daigle, L. and A. Newton, "Domain-Based Application Service + Location Using SRV RRs and the Dynamic Delegation Discovery + Service (DDDS)", RFC 3958, January 2005. + + [23] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + URIs - [22] Appendix A. Non-Normative RELAX NG Schema in XML Syntax @@ -2927,21 +2969,21 @@ Figure 21 Appendix B. Examples On-line - The XML examples and Relax NG schemas may be found on-line [22]. + The XML examples and Relax NG schemas may be found on-line [24]. Authors' Addresses Ted Hardie Qualcomm, Inc. Email: hardie@qualcomm.com Andrew Newton American Registry for Internet Numbers