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
<OUI> "-" <ProductClass> "-" <SerialNumber>
<OUI> "-" <SerialNumber>
The <OUI>, <ProductClass>, and <SerialNumber> 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 <ProductClass> and
<SerialNumber> 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]