Network Working Group H. Tschofenig (Editor) Internet-Draft Siemens Expires: December 21, 2006 H. Schulzrinne (Editor) Columbia U. June 19, 2006 GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements draft-tschofenig-geopriv-l7-lcp-ps-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 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides a problem statement and requirements for a GEOPRIV Layer 7 Location Configuration Protocol. The purpose of this protocol is for an end host to obtain location information from a special node, called the Location Information Server (LIS), and to optionally request the creation of a subscription URI. The LIS is located in the access network. The location information can then, Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 1] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 for example, be used by the Location-to-Service Translation Protocol (LoST) and in SIP for location conveyance. The subscription URI can be used by the Session Initiation Protocol (SIP) in order to obtain the most recenty location information, possibly in combination with location filters that limit the rate of notifications. Disclaimer: This document represents the current status of the discussions at the Geopriv-L7 design team and does not necessarily reflect the opinion of every design team participant. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. DSL Environment . . . . . . . . . . . . . . . . . . . . . 5 3.2. WiMax-like Fixed Access . . . . . . . . . . . . . . . . . 7 3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 8 4. Location Information Server (LIS) Discovery . . . . . . . . . 11 5. Identifier for Location Determination . . . . . . . . . . . . 13 6. Location-by-Reference and Location Subscriptions . . . . . . . 17 7. Authenticated Calls and Signed Location Information . . . . . 19 8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 28 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14.1. Normative References . . . . . . . . . . . . . . . . . . . 29 14.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 2] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 1. Introduction This document provides a problem statement and requirements for a GEOPRIV Layer 7 Location Configuration Protocol. The purpose of the protocol is twofold: o Firstly, it is used to obtain location information from a special node, called the Location Information Server (LIS). o Secondly, it enables the end host to obtain a subscription URI. The need for these two functions can be derived from the scenarios presented in Section 3. To accomplish these two functions a number of aspects need to be considered that are treated in separate sections in this document. Section 4 discusses the challenge of discovering the Location Information Server in the access network. Section 5 presents a discussion about the identifier choice when the LIS determines the location information. The concept of subscription URIs is described in Section 6. Digitally signing location information and the associated benefits and difficulties are covered in Section 7. A list of requirements for the GEOPRIV Layer 7 Location Configuration Protocol can be found in Section 8.This work is heavily influenced by security considerations. Hence, almost all sections address respective security concerns. A list of desired security properties can be found in Section 12 together with a short discussion about possible threat models. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 3] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 2. Terminology 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 [1]. Within this document we use terminology from [2]. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 4] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 3. Scenarios The following network types are within the scope: o DSL/Cable Network/WiMax-like Fixed Access o Airport/City/Campus Wireless Networks (802.11a/b/g, 802.16e/Wimax) o Cellular Networks o Enterprise Network We illustrate a few examples below. 3.1. DSL Environment The following figure shows a DSL scenario with the Access Network Provider and the customer premise. The Access Network Provider has link and network layer devices (represented as Node) and the Location Information Server (LIS). Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 5] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 +---------------------------+ | | | Access Network Provider | | | | +--------+ | | | Node | | | +--------+ +----------+ | | | | | LIS | | | | +---| | | | | +----------+ | | | | +-------+-------------------+ | <----------------> Access Network Provider demarc | +-------+-------------------+ | | | | +-------------+ | | | NTE | | | +-------------+ | | | | | | | | +--------------+ | | | Device with | | | | NAPT and | | | | DHCP server | | | +--------------+ | | | | | | | | +------+ | | | End | | | | Host | | | +------+ | | | |Customer Premises Networks | | | +---------------------------+ Figure 1: DSL Scenario The customer premise consists of a router with NAPT and DHCP server as used in most Customer Premises Networks (CPN) and the Network Termination Equipment (NTE) where Layer 1 and Layer 2 protocols are terminated. The router in the home network (e.g., broadband router, cable/DSL router) typically runs a NAPT and has a DHCP server. The NTE is a legacy device and cannot be modified for the purpose of delivering location information to the end host. The same is true for the device with the NAPT and DHCP server. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 6] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 It is possible for the NTE and home router to be physically in the same box, or for there to be no home router, or for the NTE and End Host to be in the same physical box (with no home router). An example of this last case is where Ethernet service is delivered to customers' homes, and the Ethernet NIC card in their PC serves as the NTE. In general, the case where the home router function is present is the one that we really need to consider. Current Customer Premises Network (CPN) deployments frequently show the following characteristics: 1. Single PC 1. with Ethernet NIC [PPPoE on PC; candidate for VoIP soft client]; there may be a bridged DSL modem as NTE, or the Ethernet NIC might be the NTE 2. with USB DSL modem [PPPoA on PC; candidate for VoIP soft client] Note that the device with NAPT and DHCP of Figure 1 is not present in such a scenario. 2. One or more hosts with at least one router [DHCP Client or PPPoE, DHCP server in router; VoIP can be soft client on PC, or ATA that provides LAN Ethernet port] 1. combined router + NTE 2. separate router with NTE in bridged mode 3. separate home router with NTE also as router [NTE does PPPoE to WAN, and provides DHCP Server to home router's DHCP Client; home router provides DHCP Server for hosts in LAN; double NAT The vast majority of customers use a router. 3.2. WiMax-like Fixed Access A "WIMAX-like" "fixed wireless" service is offered in several cities (like New Orleans, Biloxi, etc., where much of the communications infrastructure was destroyed). The customer-side antenna for this service is rather small (about the size of a mass market paperback book) and can be run off battery power. The output of this little antenna is a RJ-45 Ethernet jack. A laptop can be plugged into this Ethernet jack. The user would then run a PPPoE client (standard feature in XP) to connect to our network. Once the network Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 7] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 connection is established, the user can run a SIP client on the laptop. Now the user can drive all around the city and use VoIP from anywhere in a 7 square mile (or so) area. The network-side antenna is, for example, connected through ATM to the core network, and from there to the same BRASs that serve our regular DSL customers. These BRASs terminate the PPPoE sessions, just like they do for regular DSL. The laptop and SIP client in this case have absolutely no idea that they are "mobile". All they see is an Ethernet connection, and the IP address they get from PPPoE does not change over the 7 sq mi. Only the user and the network are aware of the laptop's mobility. 3.3. Wireless Access +--------------------------+ | Access Network Provider | | | | +----------+| | +-------| LIS || | | | || | +--------+ +----------+| | | Access | | | | Equip | | | +--------+ | | | | +------+-------------------+ | +------+ | End | | Host | +------+ Figure 2: Wireless Access Scenario Eventually, an Access Point or other piece of NTE may be able to self-configure by getting wireline location information and offer that to End Hosts on the wireless network. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 8] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 +--------------------------+ | Wireline | | Access Network Provider | | | | +----------+| | +-------| Location || | | | Server || | +--------+ +----------+| | | Access | | | | Equip | | | +--------+ | | | | +------+-------------------+ | | +--------------------------+ | | Wireless Access | | | Network Equip | | | | | | +----------+| | +-------| Location || | | | Server || | +--------+ +----------+| | | Access | | | | Equip | | | +--------+ | | | | +------+-------------------+ | +------+ | End | | Host | +------+ Figure 3: Mixed Wireless/Wired Access Scenario The question is whether it is sufficient to determine the location of the AP, i.e., get end user location within about 100' for 802.11a/b/g or whether we need to support triangulation where the end point measures signal strengths for a variety of APs. The latter seems to require a completely different set of parameters and may indeed be a whole different problem (since such a protocol would presumably also be useful for network management purposes). With 802.11 localization, there are at least two different approaches: Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 9] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 1. End Host-based: End Host measures the signal strength of different APs or possibly non-AP beacons, sends this information to an oracle and gets back some location information. This is the typical implementation, e.g., by Ekahau and others. 2. Infrastructure based: A series of measurement nodes places at know positions can simultaneously provide a control node with a signal strength, the control node is then able to compute the position of the end-point using an internal algorithm and RF- model of the network. This kind of solution is also referred to as Radio camera. For (2), the problem seems to be essentially the same as for the DSL/ cable case, namely just an identifier mapping. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 10] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 4. Location Information Server (LIS) Discovery Several LIS discovery solutions have been investigated with S-NAPTR being the most promising one. The idea can be described as follows: The end host obtains its public IP address (e.g., via STUN) in order to obtain its domain name (via the usual reverse DNS lookup). Then, the SRV or NAPTR record for that domain is retrieved. This relies on the user's public IP address having a DNS entry. Other alternatives have been discussed, namely to install a redirect rule at a device in the access network, such as the AAA client whereby the Geopriv-L7 signaling messages that use a specific port are redirected to the LIS. The end host could then discovery the LS by sending a packet to almost any address (as long it is not in the local network). The packet would be redirected to the respective LS being configured. The usage of a multicast query to limit the message distribution has also been proposed. There are, however, some deployment difficulties with regard to the multicast support. The quality of implementation in a DSL environment varies greatly from router to router on legacy devices. The DSL Forum requirements for routers have the following requirements: o The device must be configurable to prevent sending IGMP messages to the WAN interfaces for specified multicast groups or ranges (such as 239.0.0.0 through 239.255.255.255, which are limited scope or administratively scoped addresses). o The device must default to not sending IGMP messages for 239.0.0.0 through 239.255.255.255 to the WAN interfaces. Another alternative is the usage of NSIS discovery whereby nodes in the access network implement NSIS and assist with the discovery of the LIS when they see an NSIS discovery message. This solution supports cases where the NTE is a legacy device and does not support NSIS and also the case where it is. The LIS discovery procedure raises deployment and security considerations. When an end host discovers a LIS then it needs to ensure that this device is genuine to ensure that an adversary does not act as a man-in-the-middle. Consider the following scenario where a user arrives at an airport and found an open WiFi hotspot. The end host does not have a list of all possible Location Information Servers in the world, so it connects using TLS to the discovered LIS, and finds a the LIS certificate is rooted in a well-known Certificate Authority. How Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 11] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 does it know that the authenticated entity is indeed a LIS? The answer depends on the chosen discovery mechanism. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 12] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 5. Identifier for Location Determination There is no identifier for an end host except for the Host Identity introduced by the Host Identity Protocol (HIP). An identifier for the end host is, however, not needed for this application. What is needed is an identifier that can be used by the LIS to determine the location of the current location of the target (or a good approximation of it). Examples are switch/port, VPI/VCI, WiFi SSID, basestation MAC address, Cell ID, wall socket identifier, GPS pseudoranges, signal strength measurements, radio timing, etc. Since the request by the end host towards the LIS has to (a) determine the location information based on the information from the request and to (b) return the location information to the end host again. The chosen identifier needs to have the following properties: Known by the End Host: the end host "knows" it in order to be sent it to the LIS, Possibility for Location Determination: the LIS can use it directly or indirectly for location determination, and Security Properties: misuse needs to be minimized whereby an adversary must not obtain location information of other hosts. The identifier cannot be used by itself to obtain location information. The problem is further complicated by the requirement that the end host must not be aware of the network topology and the LIS must be placed in such a way that it can determine location information with the available information. As shown in Figure 1 the host behind the NTE/NAPT-DHCP device is not visible to the access network and the LIS itself. In the DSL network environment some identifier used at the NTE is observable for by the LIS/access network. The following represents a list of frequently discussed identifiers: o MAC address o IP address Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 13] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 o VCI/VPI o Authenticated user identity o Host Identifier o Cryptographically Generated Address (CGA) o Identities used as part of network attachment (e.g., NAI, CUI) The MAC address is, for example, not carried over an IP hop. PPP login info is only known by the router. It will generally not be known by end host. The authenticated user identity is only available if you run a network access authentication procedure in the first place. Even then it might not be available to the access network in case of a roaming environment. The network access authentication context would not identify the user identity directly but might just refer to a pseudonym. The VPI/VCI on the target side is generally only seen by the DSL modem. Almost all routers in the US use 1 of 2 VPI/VCI values: 0/35 and 8/35. This is terminated at the DSLAM, which uses a different VPI/VCI (per end customer) to connect to the ATM switch. Only the network provider is able to map VPI/VCI values through its network. With the coming of VDSL, ATM will slowly be phased out in favor of Ethernet. The DSL Forum has defined that all devices that expect to be managed by the TR-069 interface be able to generate an identifier as described in the text below. It also has a requirement that, going forward, routers that DHCP to the WAN use RFC 4361, DHCP option 61, to provide the DHCP server with a device identifier. The text below also describes the format of that option 61 identifier. OUI is as defined in http://standards.ieee.org/faqs/OUI.html. Product Class and Serial Number are defined by the vendor of the CPE. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 14] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 ... the CPE MUST use a username/userid that is globally unique among all CPE manufacturers. Specifically, the CPE username/userid MUST be in one of the following two formats "-" "-" "-" The , , and fields MUST match exactly the corresponding parameters included in the DeviceIdStruct in the Inform message, as defined in Appendix A, except that, in order to guarantee that the parameter values can be extracted from the username/userid, any character in the and that is not either alphanumeric or an underscore ("_") MUST be escaped using URI percent encoding, as defined in RFC 3986. This identifier is, however, not visible to the end host with the assumption of a legacy device like the NTE. If we assume that the LTE can be modified then a number of solutions come to mind including DHCP based location delivery. The end host's IP address is not visible to the LIS if the end host is behind a NAT (or behind multiple NATs). This is, however, not a problem since the location of a host behind the NAT cannot be determined by the access network since there is likely no cooperation between the two network operators. In this case the network behind a NAT is most likely run by the end user and he might not want to cooperate with the access network provider. Hence, in most cases the IP address of the end point will be the most useful identifier. The property of the IP address for a return routability check is attractive as well to return location information only to a device that transmitted the request. The LIS receives the request and provides location information back to the same IP address. If an adversary wants to learn location information from an IP address other than its own IP address then it would not see the response message (unless he is on the subnetwork or at a router along the path towards the LIS) since the LIS would (quite naturally) return the message to the address where it came from. On a shared medium an adversary could ask for location information of another host using its IP address. The adversary would be able to see the response message since he is sniffing on the shared medium. For multiple hosts being behind a NATed Network Termination Equipment (NTE) would not be differentiated by the LIS. For the hotel environment it is possible that such an attack indeed reveals information to the adversary if the adversary observes data traffic and uses a mechanism to determine which IP address belongs to which room number. Note that DHCP would suffer from the same problem here Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 15] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 unless each node uses a link layer security mechanism. Return routability checks are useful only if (a) the adversary does not see the response message (and if they are unable to craft a subsequent request without having seen the previous response message) and (b) the goal is to delay state establishment. If the adversary is in a broadcast network then a return routability check alone is not sufficient to prevent the above attack since the adversary will see the response. Spoofing prevention is necessary for this purpose. In a VPN scenario the request could either bypass the VPN or would be tunneled through the VPN tunnel to the tunnel end point (e.g., the corporate network). In the latter case the end host would, from a response by the LIS, believe it is in the home network since the LIS in the home network would see the inner IP address of the IPsec tunnel that is the IP address assigned by the home network. These considerations are largely equal to the consideration applicable to location delivery using DHCP. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 16] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 6. Location-by-Reference and Location Subscriptions In a network with mobile nodes where the network knows the location of the node it is not efficient to periodically query the LIS for up- to-date location information. Additionally, some network operators might not want to make location information available to the end host. [3] also provides a discussion about this subject. There is also a differentiation between a HTTP/HTTPS URI and a subscription URI but we do not address this aspect in more detail. The HTTP/HTTPS URI does not help with the polling problem as such. The following list describes the location subscription idea when the end host performs the subscription itself: 1. The end host discovers the LIS. 2. The end host sends a request to the LIS asking for a location-by- reference (or obtains one automatically if the network knows that the location might change). 3. The LIS responds to the request and includes location and a subscription URI. The URI contains a randomized component. 4. The end host takes location information and queries the LoST server and acquires the service boundary (e.g., PSAP boundary) and a URI (e.g., a PSAP URI). The service boundary indicates the region where the device can move without the need to re-query since the returned answer remains unchanged. 5. The end host subscribes to the previously acquired URI including a location filter (see [4]). 6. If the end host moves outside a certain area, indicated by the location filter, then it will receive a notification. The end host can re-query LoST to obtain a new service boundary in order to update the location filter. The following bullet list shows a procedure where an entity different from the Target subscribes to the Target's location URI (e.g., a SIP proxy): 1. The end host discovers the LIS. 2. The end host sends a request to the LIS asking for a location-by- reference (or obtains one automatically if the network knows that the location might change). Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 17] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 3. The LIS responds to the request and includes location and a subscription URI. The URI contains a randomized component. 4. The end host takes the subscription URI and places it into a SIP message as described in [5]. 5. A proxy or an end point then subscribes to the URI including a location filter (see [4]). 6. If the Target moves outside a certain area, indicated by the location filter, then a notification is sent. When the Target provided authorization policies (see [6] and [7]) to the LIS when the subscription URI was created then it can at any time change the policies in order to withdraw access to location information to the recipients of the subscription URI. A location-by-reference approach requires state establishment and is therefore vulnerable to denial-of-service. Standard delayed state establishment combined with soft-state expiry of the established state are applicable. Furthermore, a solution need to prevent unauthorized parties from dereferencing to a location object, if a location reference is obtained. Depending on the threat model a number of the usage of the random component when constructing the URI might be sufficient. In a more complicated threat model it is necessary to utilize authorization policies. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 18] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 7. Authenticated Calls and Signed Location Information The basic idea of asserted location information is to sign location information before it is sent to the end host whereby the signed location information (or asserted location information) is verified by the final Location Recipient rather than by the Target. The purpose of this procedure is to prevent nodes, like the potentially untrusted end host (i.e., Target) to modify location information, and allow the Location Recipient to verify the location information source. Signed location information is largely relevant for emergency calls and not for ordinary location based applications. Another aspect that is related to signed location information when it comes to rank emergency calls and to detect denial of service attacks is authentication of emergency calls. If most of the legitimate calls are authenticated in some way, then it is possible, under attack conditions only, to give "dubious" calls lower priority or to have them go through a turing test. PSAP operators do not want to reject legitimate emergency calls regardless of how they look like, but if the alternative is wasting 90% of your resources on bogus calls (and thus leaving many legitimate callers stranded) and not handling the unlucky unauthenticated, the expected outcome is better if you can separate. This is the standard "triage" model used in emergency medicine. If somebody places a signed (known-third-party VSP-authenticated) call, there is at least the possibility of catching a malicious caller and the number of such calls is limited. Thus, you are then left with legitimate calls o that use end system location determination (or another non-signed location information) o that have no (known) VSP o that are not signed in some other way In general, it is necessary to separate authentication from paying for service. There is no particular reason that you could not have certificates for users independent of being subscribed to either a VSP or ISP. Signing location information is challenging when a PIDF-LO [8] has to be signed instead of only location information since the PIDF-LO contains more than just location information, such as "entity" Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 19] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 attribute of the 'presence' element, usage-rules (e.g, 'retransmission-allowed', 'retention-expires', 'ruleset-reference', 'note-well'), etc. The value for the "entity" attribute of the 'presence' element is not known to the L2/L3 provider. If the LIS signs some layer-2/layer-3 (e.g., PPP/RADIUS/NAI) identity as entity URI, it will be unlikely be the SIP URI. If the target can provide any SIP URI and ask the LG to sign it, then this corresponds to the concept of a holder-of-the-key concept of SAML. The L2/L3 provider does not need to verify the entity URI; it obtains it from the end host. The LIS generates the PIDF-LO with that entity URI and can sign the PIDF-LO. It would be cleaner to put the URI into a separate XML element/attribute since the semantic of the "entity" attribute of the 'presence' element is different to the SAML holder-of-the-key concept. The security functionality that is offered by this mechanism is reference integrity. To use the PIDF-LO in SIP or another higher layer, the client needs to authenticate with the identity provided "entity" attribute of the 'presence' element. In SIP, a SIP proxy server can assert the entity URI corresponds to the client/UA by including an Identity header, whose integrity hash covers the From field and the whole body. Including the Layer 7 identity into the "entity" attribute of the 'presence' element represents a privacy problem since the access network provider can now see an identity that is in use. Hence, the LIS and possibly unauthorized listeners (if there's no privacy protection) find out where the L7 entity is located, rather than just the location object. The security difference between 1. including the L7 identity into the PIDF-LO, and 2. a signed PIDF-LO, without the L7 identity, conveyed security from the LIS to the Target and from the Target to the Location Recipient. (2) has the same security properties as (1) in terms of the ability of somebody else to steal and re-use the PIDF-LO location information ("location theft") if the threat model assumes that the Location Recipient is honest and no intermediary is able see the signed PIDF-LO. Different attributes can be used for reference integrity. In the best case no other party can reuse the PIDF-LO. This benefit seems to be similar to the one obtained by having a secure channel from the client to the LIS. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 20] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 8. Requirements The following requirements / assumptions have been identified: L7-1: In a DSL environment the location is that of the NTE/NAPT, e.g., the DSL or cable modem. Any devices behind a NAT box or other in- home device is reported as being at the location of the NTE/NAPT. L7-2: The system should work even if end systems move, either with or without change of network attachment point or network address. L7-3: There is no business or trust relationship between the provider of application-layer (e.g., SIP, XMPP, H.323) services and the network operating the LIS. L7-4: There is generally a trust relationship between the LIS and the L2/L3 provider. L7-5: Residential NAT devices and NTEs in an DSL environment cannot be modified to support additional protocols, to pass additional information through DHCP, etc. L7-6: If the L2 and L3 provider for the same host are different entities, they cooperate and can establish trust relationships for the purposes needed to determine end system locations. L7-7: Networks do not always require network access authentication (example: many open community wireless networks). The solution Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 21] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 must not assume prior network access authentication. L7-8: End systems may not know the precise properties of their residential NAT and the network topology of the access network, but can determine their IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP. L7-9: Multiple devices, located in different physical locations, may share the same L2/L3 credentials ("account", "user name/password") with the L2/L3 provider and LIS. L7-10: At least one end of a VPN is aware of the VPN. In an enterprise scenario, the enterprise side will provide the LIS used by the client and can thereby detect whether the LIS request was initiated through a VPN tunnel. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 22] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 9. IANA Considerations This document does not require actions by IANA. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 23] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 10. Contributors This contribution is a joint effort of the GEOPRIV Layer 7 Location Configuration Requirements Design Team of the Geopriv WG. The contributors include Henning Schulzrinne, Barbara Stark, Marc Linsner, James Winterbottom, Martin Thomson, Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig. The design team members can be reached at: Henning Schulzrinne: hgs@cs.columbia.edu Barbara Stark: Barbara.Stark@bellsouth.com Marc Linsner: mlinsner@cisco.com James Winterbottom: James.Winterbottom@andrew.com Martin Thomson: Martin.Thomson@andrew.com Rohan Mahy: rohan@ekabal.com Brian Rosen: br@brianrosen.net Jon Peterson: jon.peterson@neustar.biz Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 24] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 11. Acknowledgments Add your name here. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 25] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 12. Security Considerations As common elsewhere, several kinds of attackers can be distinguished. As always, Alice is the "good guy" and Trudy the attacker. Attackers can be o off-path (cannot see packets between Alice and the LIS), or o on-path (can see such packets) On-path attackers may be o passive (can only observe) o semi-active (can inject packets with a bogus IP address, but cannot prevent the delivery of packets from the end system or modify these packets) o active (can inject and modify packets at will) Furthermore, it is possible to distinguish between (at least) two different threat models. In the first threat model assumes that the communication between the LIS and the Target and between the Target and the Location Recipient is secured. This model assumes that security protection is provided against on-path adversaries that do not participate in the signaling exchange. If SIP proxies are involved in the communication then they are either trusted or bypassed by applying encryption of the location object. In the second threat model it is assumed that SIP proxies and Location Recipient(s) are untrusted. Depending on the assumption about the trust model the security countermeasures are provided. The end host might also be untrusted untrusted that lead to the idea of signed or asserted location information. If a location reference is returned to the end host then it seems reasonable that the end host is not malicious and does not pass the reference to untrusted parties. If intermediaries are untrusted and confidentiality protection between the Target and the Location Recipient was not applied then an eavesdropper (including the untrusted SIP proxies) would be able to resolve the reference to a location object. The usage of authorization policies would help to ensure that only those entities that are listed in the authorization policies provided by the Target are able to resolve the reference. If the reference contains a random, non-guessable component than an off-path adversary cannot subscribe to the location. An on-path adversary is also unable to eavesdrop the reference if the signaling communication is encrypted. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 26] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 Scenarios we may want to prevent include: o An end system can be pretend to be in an arbitrary location. o An end system can pretend to be in a location it was at a while ago. o An attacker can observe Alice's location and use it to generate its own location information. o An attacker can observe Alice's location. o An attacker can observe both Alice's location and her L7 identifier. o Alice and Bob, located at different location, can collude and swap location objects and pretend to be in each other's location. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 27] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 13. Open Issues This document is full of open issues. The design team work is ongoing. The most recent version of this draft can be found at: http://www.tschofenig.com/svn/draft-tschofenig-geopriv-l7-lcp-ps/ Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 28] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 14. References 14.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 14.2. Informative References [3] Winterbottom, J., "Rationale for Location by Reference", draft-winterbottom-location-uri-01 (work in progress), January 2006. [4] Mahy, R., "A Document Format for Filtering and Reporting Location Notications in the Presence Information Document Format Location Object (PIDF-LO)", draft-ietf-geopriv-loc-filters-00 (work in progress), March 2006. [5] Polk, J. and B. Rosen, "Session Initiation Protocol Location Conveyance", draft-ietf-sip-location-conveyance-02 (work in progress), March 2006. [6] Schulzrinne, H., "Common Policy: An XML Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-10 (work in progress), May 2006. [7] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences for Location Information", draft-ietf-geopriv-policy-08 (work in progress), February 2006. [8] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 29] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 Authors' Addresses Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Phone: +49 89 636 40390 Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 Email: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 30] Internet-Draft Geopriv L7 LCP; Problem Statement June 2006 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 (2006). 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. Tschofenig (Editor) & Schulzrinne (Editor) Expires December 21, 2006 [Page 31]