< draft-tschofenig-geopriv-l7-lcp-ps-02.txt   draft-tschofenig-geopriv-l7-lcp-ps-03.txt >
Network Working Group H. Tschofenig Network Working Group H. Tschofenig
Internet-Draft Siemens Internet-Draft Siemens Networks GmbH & Co KG
Intended status: Informational H. Schulzrinne Intended status: Informational H. Schulzrinne
Expires: March 2, 2007 Columbia U. Expires: April 26, 2007 Columbia U.
August 29, 2006 October 23, 2006
GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and
Requirements Requirements
draft-tschofenig-geopriv-l7-lcp-ps-02.txt draft-tschofenig-geopriv-l7-lcp-ps-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 2, 2007. This Internet-Draft will expire on April 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document provides a problem statement and lists requirements for This document provides a problem statement, lists requirements and
a GEOPRIV Layer 7 Location Configuration Protocol. This protocol captures discussions for a GEOPRIV Layer 7 Location Configuration
aims to allow an end host to obtain location information, by value or Protocol (LCP). This protocol aims to allow an end host to obtain
by reference, from a Location Information Server (LIS) that is location information, by value or by reference, from a Location
located in the access network. The obtained location information can Information Server (LIS) that is located in the access network. The
then be used for a variety of different protocols and purposes. For obtained location information can then be used for a variety of
example, it can be used as input to the Location-to-Service different protocols and purposes. For example, it can be used as
Translation Protocol (LoST) or to convey location within SIP to other input to the Location-to-Service Translation Protocol (LoST) or to
entities. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5 3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5
3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9 3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9
4. Discovery of the Location Information Server . . . . . . . . . 11 4. Discovery of the Location Information Server . . . . . . . . . 11
5. Identifier for Location Determination . . . . . . . . . . . . 13 5. Identifier for Location Determination . . . . . . . . . . . . 13
6. Location-by-Reference and Location Subscriptions . . . . . . . 17 6. Virtual Private Network (VPN) Considerations . . . . . . . . . 17
7. Preventing Faked Location based DoS Attacks . . . . . . . . . 19 6.1. VPN Tunneled Internet Traffic . . . . . . . . . . . . . . 17
7.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 19 6.2. VPN Client and End Point Physically Co-Located . . . . . . 17
7.2. Discussion about Countermeasures . . . . . . . . . . . . . 19 6.3. VPN Client and End Point Physically Separated . . . . . . 18
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Location-by-Reference and Location Subscriptions . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Preventing Faked Location based DoS Attacks . . . . . . . . . 22
9.1. Capabilities of the Adversary . . . . . . . . . . . . . . 25 8.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 22
9.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Discussion about Countermeasures . . . . . . . . . . . . . 22
9.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 27 9. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Capabilities of the Adversary . . . . . . . . . . . . . . 30
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 10.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 32
13.1. Normative References . . . . . . . . . . . . . . . . . . . 31 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . . 31 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
14.1. Normative References . . . . . . . . . . . . . . . . . . . 36
14.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 39
1. Introduction 1. Introduction
This document provides a problem statement and lists requirements for This document provides a problem statement, lists requirements and
a GEOPRIV Layer 7 Location Configuration Protocol. The protocol has captures discussions for a GEOPRIV Layer 7 Location Configuration
two purposes: Protocol (LCP). The protocol has two purposes:
o It is used to obtain location information from a special node, o It is used to obtain location information from a special node,
called the Location Information Server (LIS). called the Location Information Server (LIS).
o It enables the end host to obtain a reference to location o It enables the end host to obtain a reference to location
information. This reference can take the form of a subscription information. This reference can take the form of a subscription
URI, such as a SIP presence URI, an HTTP/HTTPS URI, or any others. URI, such as a SIP presence URI, an HTTP/HTTPS URI, or any others.
The need for these two functions can be derived from the scenarios The need for these two functions can be derived from the scenarios
presented in Section 3. presented in Section 3.
This document splits the problem space into separate parts and This document splits the problem space into separate parts and
discusses them in separate subsections. Section 4 discusses the discusses them in separate subsections. Section 4 discusses the
challenge of discovering the Location Information Server in the challenge of discovering the Location Information Server in the
access network. Section 5 compares different types of identifiers access network. Section 5 compares different types of identifiers
that can be used to retrieve location information. The concept of that can be used to retrieve location information. The concept of
subscription URIs is described in Section 6. Digitally signing subscription URIs is described in Section 7. Digitally signing
location information and the perceived benefits are covered in location information and the perceived benefits are covered in
Section 7. A list of requirements for the GEOPRIV Layer 7 Location Section 8. A list of requirements for the GEOPRIV Layer 7 Location
Configuration Protocol can be found in Section 8. This work is Configuration Protocol can be found in Section 9. This work is
heavily influenced by security considerations. Hence, almost all heavily influenced by security considerations. Hence, almost all
sections address security concerns. A list of desired security sections address security concerns. A list of desired security
properties can be found in Section 9 together with a discussion about properties can be found in Section 10 together with a discussion
possible threat models. about possible threat models.
This document does not describe how the access network provider This document does not describe how the access network provider
determines the location of the end host. determines the location of the end host.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1], and "OPTIONAL" are to be interpreted as described in RFC 2119 [1],
with the qualification that unless otherwise stated these words apply with the qualification that unless otherwise stated these words apply
skipping to change at page 17, line 5 skipping to change at page 17, line 5
privacy of hotel guests. Note that DHCP would suffer from the privacy of hotel guests. Note that DHCP would suffer from the
same problem here unless each node uses link layer security same problem here unless each node uses link layer security
mechanism. mechanism.
Return routability checks are useful only if the adversary does Return routability checks are useful only if the adversary does
not see the response message and if the goal is to delay state not see the response message and if the goal is to delay state
establishment. If the adversary is in a broadcast network then a establishment. If the adversary is in a broadcast network then a
return routability check alone is not sufficient to prevent the return routability check alone is not sufficient to prevent the
above attack since the adversary will observe the response. above attack since the adversary will observe the response.
6. Location-by-Reference and Location Subscriptions 6. Virtual Private Network (VPN) Considerations
To establish a VPN, a VPN client uses a particular VPN protocol to
create a tunnel to a VPN server. VPNs can be established using a
variety of protocols (e.g., IPsec, L2TP). The protocol used to
establish the VPN does not impact LIS discovery or location
acquisition.
VPN characteristics that can impact LIS discovery or acquiring a
location from a LIS include the relationship of the VPN client to the
communications application (e.g., VoIP phone), and whether the VPN
server requires the device with the VPN client to send all outbound
IP traffic across the VPN.
6.1. VPN Tunneled Internet Traffic
Any form of LIS discovery that would work without the VPN being
established, will also be able to work after the VPN has been
established. The DNS method of LIS discovery requires a device to
discover the proper IP address for discovering and querying the LIS.
Some devices may be expected to operate in a number of different
networks, including corporate networks, hotspots, home networks, and
protected networks by way of a VPN. The appropriate IP address to
use for LIS discovery may vary depending on the network.
It may be useful for such devices to do a reverse DNS lookup, LIS
discovery request, and LIS query for all IP addresses they can
determine for themselves. When all LISs involved in these queries
are properly configured, only one of these queries should be expected
to succeed. LISs should not be configured to provide a location for
an IP address that may be used by many geographically dispersed
users, or when the LIS has no way to determine the geographic
location of the device using the IP address.
This form of VPN will not interfere with queries to the LIS, once the
LIS has been discovered. It will also not interfere with location
dereferencing.
6.2. VPN Client and End Point Physically Co-Located
If LIS discovery and queries are done prior to establishing the VPN,
then the VPN will not interfere. For this reason, it is highly
desirable for devices that may support communications applications to
do location acquisition shortly after initial bootstrap, and prior to
establishing any VPN. As the communication application may not be
running prior to establishing the VPN, it is best if the
communication application is not responsible for location
acquisition.
Once a VPN has been established, the device should not permit
location acquisition to be attempted. Location acquisition done
after a VPN is established will either fail, or provide the wrong
location.
If the device does allow attempts at location acquisition after
establishing the VPN, these attempts should fail. LIS discovery
through DHCP, Redirect, and Multicast methods would fail due to lack
of support by the VPN server (it is undesirable for a VPN server to
support LIS discovery). For DNS discovery, the device might know a
variety of IP addresses, such as the IP address obtained at bootstrap
(which may be public or private, depending on whether the device is
behind a NAT), the VPN IP address, and an IP address the VPN provider
uses for Internet traffic through its firewall. RDNS of private LAN
addresses will fail. Success for RDNS of the VPN address would
depend on whether there are entries in the VPN provider's DNS server.
If RDNS of the VPN IP address succeeds, and the VPN provider has a
LIS in their network, LIS discovery of the VPN network's LIS should
succeed. It is desirable for a LIS that may get queries from devices
entering the network through a VPN, to provide an error response to
location queries that use such IP addresses. The LIS should not be
configured to return a location for these IP addresses.
RDNS of public IP addresses should generally succeed (assuming the
VPN provider's DNS allows for these queries to succeed). For IP
addresses used to connect the VPN network to the Internet, the
returned domain of RDNS would be the owner of that IP address, which
is either the VPN provider or its ISP. If the domain is that of the
VPN provider, the VPN provider may or may not have a DNS LIS entry
associated with that domain. If there is a LIS, that LIS should not
be configured to return a location for its public IP addresses. If
an ISP owns the domain of the VPN's public IP address, the device
will discover the ISP's LIS, and that LIS will return the location
where traffic from that IP address enters the access network. If the
device knows its public IP address, and RDNS and LIS discovery
succeeded, the LIS would not provide location information (assuming
the LIS would not be able to authenticate the device through means
other than return routability). The message that reached the LIS
would not be using (in the IP Header) an IP address from its domain.
If the private network allows traffic to go to the Internet,
dereferencing of a location reference will work.
6.3. VPN Client and End Point Physically Separated
In this case, it is possible for the device with the VPN client to
participate in the location acquisition process, and to provide
location to end devices. If the VPN client device does participate,
then it must acquire location information before setting up its VPN.
If the VPN client device that participates in location acquisition is
also the DHCP server for the LAN, then it would be able to either
provide its location by DHCP, or provide itself as the LIS by DHCP.
If this device names itself as the DNS server for devices in the LAN,
then it could support RDNS for LAN addresses and provide itself as
the LIS. If it says it is the LIS, then it must be able to respond
to LIS queries for location acquisition. This device would also be
able to support Redirect or Multicast methods of LIS determination.
If the VPN client device does not participate in location
acquisition, then location acquisition will either fail or provide
the wrong location, with the same results as described in section X.2
for a device that attempts location acquisition after establishing a
VPN.
If the private network allows traffic to go to the Internet,
dereferencing of a location reference will work.
7. Location-by-Reference and Location Subscriptions
In mobile wireless networks it is not efficient for the end host to In mobile wireless networks it is not efficient for the end host to
periodically query the LIS for up-to-date location information. periodically query the LIS for up-to-date location information.
Furthermore, the end host might want to delegate the task of Furthermore, the end host might want to delegate the task of
retrieving and publishing location information to a third party, such retrieving and publishing location information to a third party, such
as a presence server. Finally, in some deployments the network as a presence server. Finally, in some deployments the network
operator might not want to make location information available to the operator might not want to make location information available to the
end hosts. end hosts.
These usage scenarios motivated the introduction of the location-by- These usage scenarios motivated the introduction of the location-by-
skipping to change at page 19, line 5 skipping to change at page 22, line 5
Location references must prevent adversaries from obtaining the Location references must prevent adversaries from obtaining the
Target's location. There are at least two approaches: The location Target's location. There are at least two approaches: The location
reference contains a random component and allows any holder of the reference contains a random component and allows any holder of the
reference to obtain location information. Alternatively, the reference to obtain location information. Alternatively, the
reference can be public and the LIS performs access control via a reference can be public and the LIS performs access control via a
separate authentication mechanism, such as HTTP digest or TLS client separate authentication mechanism, such as HTTP digest or TLS client
side authentication, when resolving the reference to a location side authentication, when resolving the reference to a location
object. object.
7. Preventing Faked Location based DoS Attacks 8. Preventing Faked Location based DoS Attacks
A security threat is described in Section 7.1 and countermeasures are This section describes a possible security threat in emergency
discussed in Section 7.2. related location conveyance and subsequently discusses
countermeasures to overcome the threat.
7.1. Security Threat 8.1. Security Threat
Consider an end host that wants to act maliciously and creates its Consider an end host that wants to act maliciously and creates its
own location object with faked location information and uses this own location object with faked location information and uses this
information in a subsequent SIP communication. In case of an information in a subsequent SIP communication. In case of an
emergency call the other communication partner, the Public Safety emergency call the other communication partner, the Public Safety
Answering Point (PSAP) operator, would use the information Answering Point (PSAP) operator, would use the information
potentially without having a further possibility to verify the potentially without having a further possibility to verify the
received location information. Emergency personnel would be sent to received location information. Emergency personnel would be sent to
the indicated location noticing that there is no incident. the indicated location noticing that there is no incident.
skipping to change at page 19, line 42 skipping to change at page 22, line 43
some aspects refer to other protocols, as shown in Figure 4. For some aspects refer to other protocols, as shown in Figure 4. For
example, in an emergency call, the PSAP (as a Location Recipient) example, in an emergency call, the PSAP (as a Location Recipient)
wishes to verify that the location is indeed that of the calling wishes to verify that the location is indeed that of the calling
party. Further, the Geopriv-L7 LCP is not the only protocol that party. Further, the Geopriv-L7 LCP is not the only protocol that
could be used by an end host to acquire its location. Therefore, the could be used by an end host to acquire its location. Therefore, the
topic of signatures on the location information was deemed out of topic of signatures on the location information was deemed out of
scope. The subsequent discussion about countermeaures aims to scope. The subsequent discussion about countermeaures aims to
capture the state of the discussions and illustrates the complexity capture the state of the discussions and illustrates the complexity
in the overall design. in the overall design.
7.2. Discussion about Countermeasures 8.2. Discussion about Countermeasures
The goal of the above-described mechanism is to prevent prank calls The goal of the above-described mechanism is to prevent prank calls
and, in case of emergency services, unnecessary first-responder and, in case of emergency services, unnecessary first-responder
dispatch. As such, it is a mechanism to reduce the vulnerability of dispatch. As such, it is a mechanism to reduce the vulnerability of
denial of service attacks. The benefit of a digital signature denial of service attacks. The benefit of a digital signature
created by the LIS and covering the location information (plus some created by the LIS and covering the location information (plus some
other fields) is to treat a missing or invalid signature as suspect other fields) is to treat a missing or invalid signature as suspect
during the call. The call would be treated differently in the sense during the call. The call would be treated differently in the sense
that more questions might be asked (if an interaction with a human that more questions might be asked (if an interaction with a human
person is possible). In case of emergency services, the call might person is possible). In case of emergency services, the call might
get ranked differently if certain criteria are not fulfilled and if get ranked differently if certain criteria are not fulfilled and if
the PSAP operator is confronted with a massive amount of calls the PSAP operator is confronted with a massive amount of calls
without the possiblity to respond to all of them. without the possiblity to respond to all of them.
7.2.1. Signed Location Information 8.2.1. Signed Location Information
One of the proposed countermeasures is to sign location information One of the proposed countermeasures is to sign location information
by the LIS before it is sent to the end host whereby the signed by the LIS before it is sent to the end host whereby the signed
location information is verified by the final Location Recipient location information is verified by the final Location Recipient
rather than the Target. This prevents the Target from tampering with rather than the Target. This prevents the Target from tampering with
the received location information since the digital signature would the received location information since the digital signature would
become invalid. The Location Recipient would be able to verify the become invalid. The Location Recipient would be able to verify the
source of the location information. Since the number of nodes that source of the location information. Since the number of nodes that
may play the role of a Location Recipient is large a public key based may play the role of a Location Recipient is large it is difficult to
infrastructure is necessary. utilize a pre-shared secret key based infrastructure. Hence, a
public key based infrastructure is required but authorization still
remains challenging.
This solution approach is challenging when a PIDF-LO [16] has to be This solution approach is challenging when a PIDF-LO [16] has to be
signed (instead of location information only) since the PIDF-LO signed (instead of location information only) since the PIDF-LO
contains more than just location information, such as "entity" contains more than just location information, such as "entity"
attribute of the 'presence' element, and usage-rules (e.g., attribute of the 'presence' element, and usage-rules (e.g.,
'retransmission-allowed', 'retention-expires', 'ruleset-reference', 'retransmission-allowed', 'retention-expires', 'ruleset-reference',
'note-well'). 'note-well').
The value for the "entity" attribute of the 'presence' element is, in 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 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 layer-2/layer-3 (e.g., PPP/RADIUS/NAI) identity as entity URI, it
will unlikely be the SIP URI. will unlikely be the SIP URI.
To prevent adversaries from reusing an eavesdropped a signed location To prevent adversaries from reusing an eavesdropped signed location
object it is necessary to include additional information when object it is necessary to include additional information when
generating the digital signature. For example, a timestamp and a generating the digital signature. For example, a timestamp and a
validity field are useful to prevent certain replay attacks. validity field are useful to prevent certain replay attacks.
Furthermore, the "entity" attribute may be included in the digital Furthermore, the "entity" attribute may be included in the digital
signature of a PIDF-LO with the following semantic: When using the signature of a PIDF-LO with the following semantic: When using the
signed location object (e.g., in SIP or another higher layer signed location object (e.g., in SIP or another higher layer
protocol), the Target needs to authenticate to the Location Recipient protocol), the Target needs to authenticate to the Location Recipient
using the same identity carried in the "entity" attribute of the using the same identity carried in the "entity" attribute of the
'presence' element of the signed PIDF-LO. Using SIP, for example, a 'presence' element of the signed PIDF-LO. Using SIP, for example, a
SIP proxy server could assert the entity URI corresponding to the SIP proxy server could assert the entity URI corresponding to the
Target using the SIP identity mechanism. Target using the SIP identity mechanism.
Including the layer 7 identity into the "entity" attribute of the Including the layer 7 identity into the "entity" attribute of the
'presence' element represents a privacy problem since the access 'presence' element poses a privacy problem since the access network
network provider can now see an identity that is in use. Hence, the provider can now see an identity that is in use. Hence, the LIS and
LIS and possibly unauthorized listeners (if there's no privacy possibly unauthorized listeners (if there's no privacy protection)
protection) find out where the L7 entity is located, rather than just find out where the L7 entity is located, rather than just the
the location information. location information.
With regard to the ability for an adversary to replay eavesdrop a With regard to the ability for an adversary to replay an eavesdropped
signed location object, consider the following two approaches: a signed location object, the following two approaches need to be
considered:
1. A signed PIDF-LO with the L7 identity included, conveyed without 1. A signed PIDF-LO with the L7 identity included, conveyed without
confidentiality protection from the Target to the Location confidentiality protection from the Target to the Location
Recipient, and Recipient, and
2. A signed PIDF-LO, without the L7 identity, conveyed with 2. A signed PIDF-LO, without the L7 identity, conveyed with
confidentiality protection from the Target to the Location confidentiality protection from the Target to the Location
Recipient. Recipient.
Note that in both cases confidentiality protection for the Note that in both cases confidentiality protection for the
communication between the LIS and the Target is provided. (2) has the communication between the LIS and the Target is provided. (2) has the
same security properties as (1) in terms of the ability of somebody 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 else to steal and re-use the PIDF-LO ("location theft") (assuming the
Location Recipient and the Target are honest). Different attributes Location Recipient and the Target are honest).
can be included in the signature and in the best case no other party
can reuse the signed location object.
7.2.2. Authenticated Calls An adversary might, for example, want to perform a replay attack by
eavesdropping the signed location object. If the LIS includes
additional attributes, such as a timestamp and the validity time, the
vulnerability can be reduced although not entirely prevented. The
reason for an adversary to still be able to replay the location
information is that there is no verifiable identifier is associated
with the signed location information. For example, the LIS might
include the IP address of the end host to the signed location object.
Spoofing the IP address is, however, relatively easy. Moreover, the
IP address that is used to associate the location information cannot
be verified by the LR since the IP address can be modified
legitimately (e.g., NAT reasons) or might not be seen due to
tunneling techniques (e.g., VPN, Mobile IP).
Ideally, an "identifier" with the property of being non-spoofable by
an adversary and verifiable by the LR when it receives a signed
location object, which will ensure that the submitted location
information is actually sent by the claimed end host and not
replayed. One such verifiable identifier is a public key, the serial
number of a certificate, a hash of a public key (in the sense of
Purpose-Built-Keys or Cryptographically-Generated-Addresses) or the
value of a hash chain. We call this identifier, key identifier or
keyID for short.
In more details, the end host provides this identifier to the LIS and
it is signed together with location information. The following steps
are executed:
1. The end host interacts with the LIS to obtain its location
information. The communication is secured using Transport Layer
Security. This request carries the keyID. In this example, we
use a keyID that represents the hash of a public key. The LIS
ties the received keyID to the location object and signs it.
2. The LIS returns the signed location object that includes the
keyID to the requesting end host.
3. Whenever the end host wants to distribute its location
information to a LR, it attaches location information to a SIP
message as described in [14]. The end host computes a digital
signature over the SIP header fields and signed location object
(as, for example, envisioned by SIP Identity [17]) with the
private key that corresponds to the hashed public key found in
the signed location object.
4. This message is sent to the LR.
5. The LR receives the message and it performs the following steps:
* It retrieves the public key.
* It computes the hash over the public key and compares it with
the value in the key identifier included in the signed
location object.
* It verifies the digital signature and thereby ensures that the
end host is indeed in possession of the private key
corresponding to the obtained public key.
* It verifies the digital signature protecting the location
information and checks whether it was signed by a trusted
access provider.
Even if an adversary eveasdrops the communication between the end
host and the LR it cannot successfully replay a signed location
object since it does not know the private key corresponding to the
hashed public key found in the signed location information. The
achieved security protection might even be stronger in context of
CGAs.
8.2.2. Authenticated Calls
In many cases, authenticated calls, i.e., verifying the callers In many cases, authenticated calls, i.e., verifying the callers
identity, are at least as useful as location signing since it identity, are at least as useful as location signing since it
establishes accountability for later prosecution. establishes accountability for later prosecution.
If most of the legitimate calls are authenticated in some way, then If most of the legitimate calls are authenticated in some way, then
it is possible, under attack conditions only, to give "dubious" calls it is possible, under attack conditions only, to give "dubious" calls
lower priority or to have them go through some sort of turing test. lower priority or to have them go through some sort of turing test.
As an example, PSAP operators do not want to reject emergency calls As an example, PSAP operators do not want to reject emergency calls
regardless of how they look like, but if the alternative is wasting regardless of how they look like, but if the alternative is wasting
skipping to change at page 22, line 4 skipping to change at page 26, line 28
legitimate calls left legitimate calls left
o that use end system location determination (e.g., GPS, manual o that use end system location determination (e.g., GPS, manual
configuration); configuration);
o that have no (known) VSP; o that have no (known) VSP;
o that are not signed in some other way o that are not signed in some other way
In general, it is necessary to separate authentication from charging. In general, it is necessary to separate authentication from charging.
There is no reason for tying authentication, authorization and There is no reason for tying authentication, authorization and
charging together for this particular context. For example, charging together for this particular context. For example,
certificates can be used, for example, for emergency service without certificates can be used, for example, for emergency service without
being subscribed to either a VSP or ISP. being subscribed to either a VSP or ISP.
7.2.3. Location-by-Reference 8.2.3. Location-by-Reference
The concept of location-by-reference was described in Section 6. The The concept of location-by-reference was described in Section 7. The
properties of location signing are very similar (if not equal) to the properties of location signing are very similar (if not equal) to the
properties of the location-by-reference concept when the Location properties of the location-by-reference concept when the Location
Recipient only authenticates the LIS (but not vice-versa). Bot Recipient only authenticates the LIS (but not vice-versa). Both
mechanisms allow the Location Recipient to authenticate the LIS (and mechanisms allow the Location Recipient to authenticate the LIS (and
potentially the access network provider). potentially the access network provider).
There are also a few drawbacks with the location signing and the There are also a few drawbacks with the location signing and the
location-by-reference concept: location-by-reference concept:
o Location signing has very limited utility if the number of signing o Location signing has very limited utility if the number of signing
parties is very large parties is very large
o Location signing has very limited utility for commercial o Location signing has very limited utility for commercial
transactions. Commercial entities do not care whether a customer transactions. Commercial entities do not care whether a customer
lies about their location, as long as they can make you pay for lies about their location, as long as they can make you pay for
the service you asked for. the service you asked for.
Authenticated calls also have their disadvantage since they require Authenticated calls also have their disadvantage since they require
end-host or end-user certificates, which creates a deployment burden, end-host or end-user certificates, which creates a deployment burden,
unless mechanisms similar to SIP Identity [17] are used. unless mechanisms similar to SIP Identity [18] are used.
Furthermore, authenticated calls do not prevent attacks where the Furthermore, authenticated calls do not prevent attacks where the
location information was obtained unsecured from a LIS and an location information was obtained unsecured from a LIS and an
adversary in the access network was able to tamper with the in-flight adversary in the access network was able to tamper with the in-flight
location information. location information.
8. Requirements 9. Requirements
The following requirements and assumptions have been identified: The following requirements and assumptions have been identified:
Requirement L7-1: Identifier Choice Requirement L7-1: Identifier Choice
The LIS MUST be presented with a unique identifier of its own The LIS MUST be presented with a unique identifier of its own
addressing realm associated in some way with the physical location addressing realm associated in some way with the physical location
of the end host. of the end host.
An identifier is only appropriate if it is from the same realm as An identifier is only appropriate if it is from the same realm as
skipping to change at page 24, line 32 skipping to change at page 29, line 32
The design of the GEOPRIV Layer 7 Location Configuration Protocol The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume prior network access authentication. MUST NOT assume prior network access authentication.
Requirement L7-8: Network Topology Unawareness Requirement L7-8: Network Topology Unawareness
The design of the GEOPRIV Layer 7 Location Configuration Protocol The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume end systems being aware of the access network MUST NOT assume end systems being aware of the access network
topology. End systems are, however, able to determine their topology. End systems are, however, able to determine their
public IP address(es) via mechanisms such as STUN [4] or NSIS public IP address(es) via mechanisms such as STUN [4] or NSIS
NATFW NSLP [18] . NATFW NSLP [19] .
9. Security Considerations 10. Security Considerations
9.1. Capabilities of the Adversary 10.1. Capabilities of the Adversary
As common elsewhere, several kinds of attackers can be distinguished. As common elsewhere, several kinds of attackers can be distinguished.
As always, Alice is the "good guy" and Trudy the attacker. Attackers As always, Alice is the "good guy" and Trudy the attacker. Attackers
can be: can be:
o off-path, i.e., it cannot see packets between Alice and the LIS; o off-path, i.e., it cannot see packets between Alice and the LIS;
o on-path, i.e., can see such packets. o on-path, i.e., can see such packets.
On-path attackers may be: On-path attackers may be:
o passive, i.e., can only observe; o passive, i.e., can only observe;
o semi-active, i.e., can inject packets with a bogus IP address, but o semi-active, i.e., can inject packets with a bogus IP address, but
cannot prevent the delivery of packets from the end system or cannot prevent the delivery of packets from the end system or
modify these packets; modify these packets;
o active, i.e., can inject and modify packets at will. o active, i.e., can inject and modify packets at will.
9.2. Threats 10.2. Threats
When the reference to location information is communicated to the When the reference to location information is communicated to the
Location Recipient then on-path adversaries can eavesdrop the Location Recipient then on-path adversaries can eavesdrop the
signaling communication together with the reference. Furthermore, signaling communication together with the reference. Furthermore,
the end-to-end communication might involve SIP proxies and they may the end-to-end communication might involve SIP proxies and they may
not be trustworthy. Hence, they can eavesdrop the reference and not be trustworthy. Hence, they can eavesdrop the reference and
misuse it (by resolving it). misuse it (by resolving it).
Untrusted proxies that are involved in the communication lead to a Untrusted proxies that are involved in the communication lead to a
requirement for the Target to selectively grant access to already requirement for the Target to selectively grant access to already
skipping to change at page 27, line 10 skipping to change at page 32, line 10
Table 1 Table 1
Legend: Legend:
-: Functionality not necessary to accomplish the desired -: Functionality not necessary to accomplish the desired
functionality. functionality.
X: Functionality needed to prevent threat. X: Functionality needed to prevent threat.
9.3. Requirements 10.3. Requirements
The following requirements are placed on the location-by-value The following requirements are placed on the location-by-value
approach: approach:
o No conclusion was reached whether a PIDF-LO or just location o No conclusion was reached whether a PIDF-LO or just location
information has to be signed. information has to be signed.
o No conclusion was reached whether location information should be o No conclusion was reached whether location information should be
signed. signed.
skipping to change at page 28, line 5 skipping to change at page 33, line 5
o The Location Recipient MUST be able to resolve the reference more 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 than once (i.e., there is no implicit limit on the number of
dereferencing actions). dereferencing actions).
o Possessing a reference to location information allows a Location o Possessing a reference to location information allows a Location
Recipient to repeately obtain the latest information about the Recipient to repeately obtain the latest information about the
Target with the same granularity. Target with the same granularity.
o The Target MUST be able to resolve the reference itself. o The Target MUST be able to resolve the reference itself.
10. IANA Considerations 11. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
11. Contributors 12. Contributors
This contribution is a joint effort of the GEOPRIV Layer 7 Location This contribution is a joint effort of the GEOPRIV Layer 7 Location
Configuration Requirements Design Team of the Geopriv WG. The Configuration Requirements Design Team of the Geopriv WG. The
contributors include Henning Schulzrinne, Barbara Stark, Marc contributors include Henning Schulzrinne, Barbara Stark, Marc
Linsner, James Winterbottom, Martin Thomson, Rohan Mahy, Brian Rosen, Linsner, Andrew Newton, James Winterbottom, Martin Thomson, Rohan
Jon Peterson and Hannes Tschofenig. Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig.
The design team members can be reached at: The design team members can be reached at:
Marc Linsner: mlinsner@cisco.com Marc Linsner: mlinsner@cisco.com
Rohan Mahy: rohan@ekabal.com Rohan Mahy: rohan@ekabal.com
Andrew Newton: andy@hxr.us
Jon Peterson: jon.peterson@neustar.biz Jon Peterson: jon.peterson@neustar.biz
Brian Rosen: br@brianrosen.net Brian Rosen: br@brianrosen.net
Henning Schulzrinne: hgs@cs.columbia.edu Henning Schulzrinne: hgs@cs.columbia.edu
Barbara Stark: Barbara.Stark@bellsouth.com Barbara Stark: Barbara.Stark@bellsouth.com
Martin Thomson: Martin.Thomson@andrew.com Martin Thomson: Martin.Thomson@andrew.com
Hannes Tschofenig: Hannes.Tschofenig@siemens.com Hannes Tschofenig: Hannes.Tschofenig@siemens.com
James Winterbottom: James.Winterbottom@andrew.com James Winterbottom: James.Winterbottom@andrew.com
12. Acknowledgements The authors would like to thank Barbara Stark for her 'Virtual
Private Network (VPN) Considerations' text proposal.
13. Acknowledgements
We would like to thanks the IETF GEOPRIV working group chairs, Andy We would like to thanks the IETF GEOPRIV working group chairs, Andy
Newton, Allison Mankin and Randall Gellens, for creating this design Newton, Allison Mankin and Randall Gellens, for creating this design
team. Furthermore, we would like thank Andy Newton for his support team. Furthermore, we would like thank Andy Newton for his support
during the design team mailing list, the Jabber chat conference and during the design team mailing list, the Jabber chat conference and
the phone conference discussions. Finally, we would like to thank the phone conference discussions. Finally, we would like to thank
Murugaraj Shanmugam for his draft review. Murugaraj Shanmugam for his draft review.
13. References 14. References
13.1. Normative References 14.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-12 (work in progress), draft-ietf-ecrit-requirements-12 (work in progress),
August 2006. August 2006.
13.2. Informative References 14.2. Informative References
[4] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN [4] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through - Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003. Network Address Translators (NATs)", RFC 3489, March 2003.
[5] Aboba, B., "Link-local Multicast Name Resolution (LLMNR)", [5] Aboba, B., "Link-local Multicast Name Resolution (LLMNR)",
draft-ietf-dnsext-mdns-47 (work in progress), August 2006. draft-ietf-dnsext-mdns-47 (work in progress), August 2006.
[6] Cheshire, S. and M. Krochmal, "Multicast DNS", [6] Cheshire, S. and M. Krochmal, "Multicast DNS",
draft-cheshire-dnsext-multicastdns-06 (work in progress), draft-cheshire-dnsext-multicastdns-06 (work in progress),
skipping to change at page 32, line 12 skipping to change at page 37, line 12
for Dynamic Host Configuration Protocol Version Four (DHCPv4)", for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
RFC 4361, February 2006. RFC 4361, February 2006.
[13] Mahy, R., "A Document Format for Filtering and Reporting [13] Mahy, R., "A Document Format for Filtering and Reporting
Location Notications in the Presence Information Document Location Notications in the Presence Information Document
Format Location Object (PIDF-LO)", Format Location Object (PIDF-LO)",
draft-ietf-geopriv-loc-filters-00 (work in progress), draft-ietf-geopriv-loc-filters-00 (work in progress),
March 2006. March 2006.
[14] Polk, J. and B. Rosen, "Session Initiation Protocol Location [14] Polk, J. and B. Rosen, "Session Initiation Protocol Location
Conveyance", draft-ietf-sip-location-conveyance-03 (work in Conveyance", draft-ietf-sip-location-conveyance-04 (work in
progress), June 2006. progress), August 2006.
[15] Hardie, T., "LoST: A Location-to-Service Translation Protocol", [15] Hardie, T., "LoST: A Location-to-Service Translation Protocol",
draft-ietf-ecrit-lost-00 (work in progress), June 2006. draft-ietf-ecrit-lost-01 (work in progress), September 2006.
[16] Peterson, J., "A Presence-based GEOPRIV Location Object [16] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[17] Peterson, J. and C. Jennings, "Enhancements for Authenticated [17] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[18] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06 (work in progress), October 2005. draft-ietf-sip-identity-06 (work in progress), October 2005.
[18] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol [19] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-12 (work in progress), (NSLP)", draft-ietf-nsis-nslp-natfw-12 (work in progress),
June 2006. June 2006.
[19] Schulzrinne, H., "Common Policy: A Document Format for [20] Schulzrinne, H., "Common Policy: A Document Format for
Expressing Privacy Preferences", Expressing Privacy Preferences",
draft-ietf-geopriv-common-policy-11 (work in progress), draft-ietf-geopriv-common-policy-11 (work in progress),
August 2006. August 2006.
[20] Schulzrinne, H., "A Document Format for Expressing Privacy [21] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences for Location Information", Preferences for Location Information",
draft-ietf-geopriv-policy-08 (work in progress), February 2006. draft-ietf-geopriv-policy-08 (work in progress), February 2006.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Phone: +49 89 636 40390 Phone: +49 89 636 40390
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
 End of changes. 48 change blocks. 
90 lines changed or deleted 287 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/