Network Working Group H. Tschofenig (Editor)
Internet-Draft Siemens
Intended status: Informational H. Schulzrinne (Editor)
Expires: February 14, 2007 Columbia U.
August 13, 2006
GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and
Requirements
draft-tschofenig-geopriv-l7-lcp-ps-01.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 February 14, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 1]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
Abstract
This document provides a problem statement and lists requirements for
a GEOPRIV Layer 7 Location Configuration Protocol. This protocol
aims to allow an end host to obtain location information (by value or
by reference) from a Location Information Server (LIS) that is
located in the access network. The obtained location information can
then be used for a variety of different protocols and purposes. For
example, it can be used as input to the Location-to-Service
Translation Protocol (LoST) or to convey location within SIP to other
entities.
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. Moving Network . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9
4. Location Information Server (LIS) Discovery . . . . . . . . . 11
5. Identifier for Location Determination . . . . . . . . . . . . 13
6. Location-by-Reference and Location Subscriptions . . . . . . . 17
7. Signed Location Information . . . . . . . . . . . . . . . . . 19
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.1. Capabilities of the Adversary . . . . . . . . . . . . . . 24
9.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . . 30
13.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 2]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
1. Introduction
This document provides a problem statement and lists 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 reference to
location information. This reference can take the form of a
subscription URI, such as a SIP presence URI, or an HTTP/HTTPS
URI.
The need for these two functions can be derived from the scenarios
presented in Section 3.
This document splits the problem space into separate parts and
discusses them in separate subsections. Section 4 discusses the
challenge of discovering the Location Information Server in the
access network. Section 5 presents a discussion about the possible
identifiers, by which a LIS can determine the location. The concept
of subscription URIs is described in Section 6. Digitally signing
location information and the perceived benefits are covered in
Section 7. A list of requirements for the GEOPRIV Layer 7 Location
Configuration Protocol can be found in Section 8. The entire work is
heavily influenced by security considerations. Hence, almost all
sections address security concerns. A list of desired security
properties can be found in Section 9 together with a discussion about
possible threat models.
This document does not describe how the access network provider
determines the location of the end host.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 3]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1],
with the qualification that unless otherwise stated these words apply
to the design of the GEOPRIV Layer 7 Location Configuration Protocol.
Within this document we use terminology from [2].
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 4]
Internet-Draft Geopriv L7 LCP; Problem Statement August 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 3G 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 February 14, 2007 [Page 5]
Internet-Draft Geopriv L7 LCP; Problem Statement August 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 February 14, 2007 [Page 6]
Internet-Draft Geopriv L7 LCP; Problem Statement August 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 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. Moving Network
An example of a moving network is a "WIMAX-like fixed wireless"
scenario that is offered in several cities (like New Orleans, Biloxi,
etc.) where much of the communications infrastructure was destroyed
due to a natural disaster. 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 to connect to
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 7]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
the network. Once the network 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 several square mile
area.
The network-side antenna is, for example, connected through ATM to
the core network, and from there to the same BRASs that serve 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.
Further examples of moving networks can be found in busses, trains,
airplanes.
Figure 2 shows an example topology for a moving network.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 8]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
+--------------------------+
| Wireless |
| Access Network Provider |
| |
| +----------+|
| +-------+ Location ||
| | | Server ||
| +---+----+ +----------+|
| | Router | |
| | | |
| +---+----+ |
| | |
+------+-------------------+
|
|
+------+-------------------+
| | Moving Network |
| +---+----+ |
| | Access | +--------+ |
| | Equip +---+ Host | |
| +-+-----++ | B | |
| | \ +--------+ |
| | \ |
|+---+----+ \ +---+----+ |
|| Host | \ | Host | |
|| A | \+ B | |
|+--------+ +--------+ |
+--------------------------+
Figure 2: Moving Network
3.3. Wireless Access
Figure 3 shows a wireless access network where a moving end host
obtains location information or references to location information
from the LIS. The access equipment are, in many cases, link layer
devices. This figure represents a classical hotspot network found at
hotels, airports, coffee shops.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 9]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
+--------------------------+
| Access Network Provider |
| |
| +----------+|
| +-------| LIS ||
| | | ||
| +--------+ +----------+|
| | Access | |
| | Equip | |
| +--------+ |
| | |
+------+-------------------+
|
+------+
| End |
| Host |
+------+
Figure 3: Wireless Access Scenario
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 10]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
4. Location Information Server (LIS) Discovery
When an end host wants to retrieve location information from the LIS
it first needs to discover it. Several LIS discovery solutions have
been investigated.
DNS-based Discovery:
With this idea 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.
Redirect Rule:
A redirect rule at a device in the access network, for example at
the AAA client, will be used to redirect the Geopriv-L7 signalling
messages (destined to a specific port) to the LIS. The end host
could then discover the LIS 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
same procedure is used by captive portals whereby any HTTP traffic
is intercepted and redirected.
Multicast Query:
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 have the following router
requirements:
* 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).
* The device must, by default, not send IGMP messages for
239.0.0.0 through 239.255.255.255 to the WAN interfaces.
The LIS discovery procedure raises deployment and security
considerations. When an end host discovers a LIS then it (a) needs
to ensure that the discovered device is genuine and (b) should ensure
that it does not suffer from man-in-the-middle attacks.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 11]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
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
does it know that the authenticated entity is indeed a LIS?
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 12]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
5. Identifier for Location Determination
The LIS needs to return location information to the end host when it
receives a request. Some form of identifier is therefore needed to
allow the LIS to determine the the current location of the target (or
a good approximation of it).
The chosen identifier needs to have the following properties:
Ability for end host to learn or know the identifier:
The end host MUST knows or MUST be able to learn the identifier
(explicitly or implicitly) in order to send it to the LIS.
Ability to use the identifier for location determination:
The LIS MUST be able to use the identifier (directly or
indirectly) for location determination.
Security properties of the identifier:
Misuse needs to be minimized whereby off-path adversary MUST NOT
be able to obtain location information of other hosts. A on-path
adversary in the same subnet SHOULD NOT be able to spoof the
identifier of another host in the same subnet.
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 list shows frequently discussed identifiers:
MAC address:
The MAC address is, for example, not carried over an IP hop.
VCI/VPI:
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
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 13]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
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.
Switch/Port Number:
This identifier is available only to certain networks and the
switch/port number might not be available to the end host.
Cell ID:
This identifier is available only to certain networks and the Cell
ID might not be available to the end host.
Authenticated User Identity:
In the DSL environment the user credentials are, in many cases,
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.
Host Identifier:
The Host Identifier introduced by the Host Identity Protocol
allows identification of a particular host. Unfortunately, the
network can only use this identifier for location determination if
the operator already stores an mapping of Host Identities to
location information. Furthermore, there is a deployment problem
since the Host Identities are not used in todays networks.
Cryptographically Generated Address (CGA):
This identifier has similar properties than IP address with the
except that it allows a proof of ownership of the IP address.
Hence, a return routability check can be omitted.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 14]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
Network Access Identifiers:
A Network Access Identifier is only used during the network access
authentication procedure. Furthermore, in a roaming scenario it
does not help the access network to make meaningful decisions
since the username part might be a pseudonym and no relationship
to the end hosts location can be derived.
Unique Client Identifier
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
routers that use DHCP to the WAN use RFC 4361, DHCP option 61, to
provide the DHCP server with a unique client identifier. 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.
IP Address:
In this approach the IP address of the end host is used for
location determination (either directly or indirectly). 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 that is located behind a NAT
cannot be determined by the access network. 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. The
LIS would in this case determine the location information of the
NAT, which is the correct behavior. 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
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 15]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
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 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.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 16]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
6. Location-by-Reference and Location Subscriptions
In wireless networks it is not efficient for the end host to
periodically query the LIS for up-to-date location information.
Furthermore, the end host might want to delegate the task of
retrieving and publishing location information to a third party, such
as a presence server.
These usage scenarios have motivated the introduction of the
location-by-reference concept. Depending on the type of reference,
such as HTTP/HTTPS or SIP/Presence URI, different operations can be
performed. While an HTTP/HTTPS URI can be resolved to location
information a SIP/Presence URI provides further benefits based on the
SUBSCRIBE/NOTIFY concept that can additionally be combined with
filters.
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 [3]).
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, call server, or presence server):
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 17]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
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 the subscription URI and places it into a SIP
message as described in [4].
5. A proxy or an end point then subscribes to the URI including a
location filter (see [3]).
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 [5] and [6]) 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. The main idea is to delay state establishment
to a later message exchange after performing at least a return-
routability check.
Furthermore, a solution is needed to prevent unauthorized parties
from dereferencing to a location object, if a location reference is
obtained. Depending on the requirements the usage of a random
component in the construction of the URI might be sufficient. In
other cases end-to-end confidentiality protection of the location
reference and/or the usage of authorization policies might be
necessary.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 18]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
7. Signed Location Information
This section starts with the consideration of a security threat: An
end host that wants to act maliciously creates its own location
object with faked location information and uses this information in a
subsequent SIP communication. In case of an emergency call the other
communication partner, the Public Safety Answering Point (PSAP),
would like to ensure that the provided location information is
genuine to avoid sending emergency personnel to a location where no
emergency happened.
The proposed countermeasure is to sign location information by the
LIS before it is sent to the end host whereby the signed location
information is verified by the final Location Recipient rather than
the Target. This prevents the Target from tampering with the
received location information since the digital signature would
become invalid. The Location Recipient would be able to verify the
source of the location information. Since almost every node may play
the role of a Location Recipient a public key based infrastructure
might be necessary.
The main goal is to limit the effectiveness of bogus calls and denial
of service attacks. To explain the likelihood for success it is
necessary to consider the behavior of the Location Recipient and
additional countermeasures. Thereby, a related aspect are
authenticated calls (e.g., authenticated 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. As an example,
PSAP operators do not want to reject legitimate emergency calls
regardless of how they look like, but if the alternative is wasting
90% of the 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
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 19]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
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 [7] has to
be signed instead of only location information since the PIDF-LO
contains more than just location information, such as "entity"
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, in
many cases, 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. 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.
Consider the following two approaches:
1. A signed PIDF-LO with the L7 identity included, and
2. A signed PIDF-LO, without the L7 identity, conveyed with 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 theft")
(assuming the Location Recipient being honest and no intermediary
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 20]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
being 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 February 14, 2007 [Page 21]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
8. Requirements
The following requirements / assumptions have been identified:
Requirement L7-1: Identifier Choice
The LIS MUST be presented with an identifier of its own addressing
realm.
In a DSL environment the LIS can determine the location 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.
An identifier is only appropriate if it is from the same realm as
the one for which the location information service maintains
identifier to location mapping.
Requirement L7-2: Mobility Support
The GEOPRIV Layer 7 Location Configuration Protocol SHOULD work
even if end systems move, either with or without change of network
attachment point or network address.
Requirement L7-3: Layer 7 and Layer 2/3 Provider Relationship
The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume a business or trust relationship between the
provider of application layer (e.g., SIP, XMPP, H.323) provider
and the access network provider operating the LIS.
Requirement L7-4: Layer 2 and Layer 3 Provider Relationship
The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that there is a trust and business relationship
between the L2 and the L3 provider. The L3 provider operates the
LIS and needs to obtain location information from the L2 provider
since this one is closest to the end host. If the L2 and L3
provider for the same host are different entities, they cooperate
for the purposes needed to determine end system locations.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 22]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
Requirement L7-5: Legacy Device Considerations
The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST consider legacy residential NAT devices and NTEs in an DSL
environment that cannot be modified to support additional
protocols, for example to pass additional information through
DHCP.
Requirement L7-6: VPN Awareness
The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that at least one end of a VPN is aware of the VPN
functionality. 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.
Requirement L7-7: Network Access Authentication
The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume prior network access authentication.
Requirement L7-8: Network Topology Unawareness
The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume end systems being aware of the access network
topology. End systems are, however, able to determine their
public IP address(es) via mechanisms such as STUN or NSIS NATFW
NSLP.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 23]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
9. Security Considerations
9.1. Capabilities of the Adversary
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)
9.2. Threats
When the reference to location information is communicated to the
Location Recipient then on-path adversaries can eavesdrop the
signaling communication together with the reference. Furthermore,
the end-to-end communication might involve SIP proxies and they may
not be trustworthy. Hence, they can eavesdrop the reference and
misuse it (by resolving it).
Untrusted proxies that are involved in the communication lead to a
requirement for the Target to selectively grant access to already
known and trusted Location Recipients.
The following list presents threats specific to location information
handling:
o Trudy pretends to be at an arbitrary location.
o Trudy pretends to be at a location she was a while ago.
o Trudy can observe Alice's location and use it to generate her own
location object.
o Trudy can observe Alice's location.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 24]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
o Trudy can observe both Alice's location and her identity (e.g.,
presence identity).
o Trudy' and Trudy'', located at different locations, can collude
and swap location objects and pretend to be in each other's
location.
Open Issue: We need to decide which threats are relevant for us and
what requirements we derive from them?
9.3. Requirements
The following requirements are placed on the location-by-value:
o Open Issue: Should we require a solution to provide a mechanism
to sign location information? If yes, what requirements should
place on the reference-integrity mechanism and the fields that are
used?
The following requirements are placed on the location-by-reference:
o The reference MUST be valid for a limited amount of time.
o The reference MUST be hard to guess (i.e., it MUST contain a
random component)
o The reference MUST NOT contain any information that identifies the
user, device or Address of Record
o The Location Recipient MUST be able to resolve the reference more
than once (i.e., there is no implicit limit on the number of
dereferencing actions).
o Possessing a reference to location information allows a Location
Recipient to repeately obtain the latest information about the
Target with the same granularity. Open Issues:
* The Target SHOULD be able to revoke the reference.
* The Target SHOULD be able to change the granularity of the
location information presented to the Location Recipient over
time. This might, for example, be necessary when the Target
switches to a different sphere (e.g., from 'work' to 'home').
o The Target MUST be able to resolve the reference by himself.
o Open issue that depends on the threat model: The Target SHOULD be
able to store authorization policies along with the reference to
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 25]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
control the dereferencing process.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 26]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
10. IANA Considerations
This document does not require actions by IANA.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 27]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
11. 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:
Marc Linsner: mlinsner@cisco.com
Rohan Mahy: rohan@ekabal.com
Jon Peterson: jon.peterson@neustar.biz
Brian Rosen: br@brianrosen.net
Henning Schulzrinne: hgs@cs.columbia.edu
Barbara Stark: Barbara.Stark@bellsouth.com
Martin Thomson: Martin.Thomson@andrew.com
Hannes Tschofenig: Hannes.Tschofenig@siemens.com
James Winterbottom: James.Winterbottom@andrew.com
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 28]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
12. Acknowledgements
We would like to thank Murugaraj Shanmugam for his draft review.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 29]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
13. References
13.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.
13.2. Informative References
[3] 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.
[4] Polk, J. and B. Rosen, "Session Initiation Protocol Location
Conveyance", draft-ietf-sip-location-conveyance-03 (work in
progress), June 2006.
[5] Schulzrinne, H., "Common Policy: A Document Format for
Expressing Privacy Preferences",
draft-ietf-geopriv-common-policy-11 (work in progress),
August 2006.
[6] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences for Location Information",
draft-ietf-geopriv-policy-08 (work in progress), February 2006.
[7] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
RFC 4119, December 2005.
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 30]
Internet-Draft Geopriv L7 LCP; Problem Statement August 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 February 14, 2007 [Page 31]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
Full 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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Tschofenig (Editor) & Schulzrinne (Editor) Expires February 14, 2007 [Page 32]