draft-ietf-ecrit-trustworthy-location-13.txt   draft-ietf-ecrit-trustworthy-location-14.txt 
ECRIT Working Group H. Tschofenig ECRIT Working Group H. Tschofenig
INTERNET-DRAFT ARM Ltd. INTERNET-DRAFT Independent
Category: Informational H. Schulzrinne Category: Informational H. Schulzrinne
Expires: December 29, 2014 Columbia University Expires: January 5, 2015 Columbia University
B. Aboba (ed.) B. Aboba (ed.)
Microsoft Corporation Microsoft Corporation
28 June 2014 28 July 2014
Trustworthy Location Trustworthy Location
draft-ietf-ecrit-trustworthy-location-13.txt draft-ietf-ecrit-trustworthy-location-14.txt
Abstract Abstract
The trustworthiness of location information is critically important The trustworthiness of location information is critically important
for some location-based applications, such as emergency calling or for some location-based applications, such as emergency calling or
roadside assistance. roadside assistance.
This document describes threats relating to conveyance of location in This document describes threats relating to conveyance of location in
an emergency call, and describes techniques that improve the an emergency call, and describes techniques that improve the
reliability and security of location information conveyed in a IP- reliability and security of location information conveyed in a IP-
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on December 29, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Emergency Services Architecture . . . . . . . . . . . . . 5 1.2 Emergency Services Architecture . . . . . . . . . . . . . 5
2. Threat Models . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Threat Models . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Existing Work . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Existing Work . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Adversary Model . . . . . . . . . . . . . . . . . . . . . 9 2.2 Adversary Model . . . . . . . . . . . . . . . . . . . . . 9
2.3. Location Spoofing . . . . . . . . . . . . . . . . . . . . 10 2.3. Location Spoofing . . . . . . . . . . . . . . . . . . . . 10
2.4. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 11 2.4. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 10
3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 11 3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 11
3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 12 3.1. Signed Location-by-Value . . . . . . . . . . . . . . . . . 11
3.2. Location by Reference . . . . . . . . . . . . . . . . . . 15 3.2. Location-by-Reference . . . . . . . . . . . . . . . . . . 15
3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 18 3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 18
4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 20 4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7.1. Informative references . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Informative references . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Several public and commercial services depend upon location Several public and commercial services depend upon location
information in their operations. This includes emergency services information in their operations. This includes emergency services
(such as fire, ambulance and police) as well as commercial services (such as fire, ambulance and police) as well as commercial services
such as food delivery and roadside assistance. such as food delivery and roadside assistance.
For circuit-switched calls from landlines, as well as for Voice over For circuit-switched calls from landlines, as well as for Voice over
IP (VoIP) services only supporting emergency service calls from IP (VoIP) services only supporting emergency service calls from
skipping to change at page 5, line 42 skipping to change at page 5, line 42
victim's device). Location theft may also be combined with time victim's device). Location theft may also be combined with time
shifting to present someone else's location information after the shifting to present someone else's location information after the
original Target has moved. original Target has moved.
1.2. Emergency Services Architecture 1.2. Emergency Services Architecture
This section describes how location is utilized in the Internet This section describes how location is utilized in the Internet
Emergency Services Architecture, as well as the existing work on the Emergency Services Architecture, as well as the existing work on the
problem of hoax calls. problem of hoax calls.
1.2.1. Location Conveyance 1.2.1. Location
The Internet architecture for emergency calling is described in The Internet architecture for emergency calling is described in
"Framework for Emergency Calling Using Internet Multimedia" "Framework for Emergency Calling Using Internet Multimedia"
[RFC6443]. Best practices for utilizing the architecture to make [RFC6443]. Best practices for utilizing the architecture to make
emergency calls are described in "Best Current Practice for emergency calls are described in "Best Current Practice for
Communications Services in Support of Emergency Calling" [RFC6881]. Communications Services in Support of Emergency Calling" [RFC6881].
As noted in "An Architecture for Location and Location Privacy in As noted in "An Architecture for Location and Location Privacy in
Internet Applications" [RFC6280] Section 6.3: Internet Applications" [RFC6280] Section 6.3:
skipping to change at page 6, line 18 skipping to change at page 6, line 18
1. Determine the location of the caller. 1. Determine the location of the caller.
2. Determine the proper Public Safety Answering Point (PSAP) for 2. Determine the proper Public Safety Answering Point (PSAP) for
the caller's location. the caller's location.
3. Send a SIP INVITE message, including the caller's location, to 3. Send a SIP INVITE message, including the caller's location, to
the PSAP." the PSAP."
The conveyance of location information within the Session Initiation The conveyance of location information within the Session Initiation
Protocol (SIP) is described in "Location Conveyance for the Session Protocol (SIP) is described in "Location Conveyance for the Session
Initiation Protocol" [RFC6442]. The Security Considerations (Section Initiation Protocol" [RFC6442]. Conveyance of Location-by-Value
7) discusses privacy, authentication and integrity concerns relating (LbyV) as well as Location-by-Reference (LbyR) are supported. The
to conveyed location. This includes discussion of transmission layer Security Considerations (Section 7) discusses privacy, authentication
security for confidentiality and integrity protection of SIP, as well and integrity concerns relating to conveyed location. This includes
as undeployed end-to-end security mechanisms for protection of discussion of transmission layer security for confidentiality and
location information (e.g. S/MIME). integrity protection of SIP, as well as (undeployed) end-to-end
security mechanisms for protection of location information (e.g.
However, the conveyance architecture has limitations with respect to S/MIME). Regardless of whether transmission-layer security is
privacy protection. Even where transmission-layer security is utilized, location information may be available for inspection by an
utilized, since it terminates at each hop, location information may intermediary which, if it decides that the location value is
be available for inspection by an intermediary which, if it decides unacceptable or insufficiently accurate, may send an error indication
that the location value is unacceptable or insufficiently accurate, or replace the location, as described in [RFC6442] Section 3.4.
may send an error indication or replace the location, as described in
[RFC6442] Section 3.4.
Furthermore, the privacy concerns are not necessarily limited to Although the infrastructure for location-based routing described in
emergency services. Although the infrastructure for location-based [RFC6443] was developed for use in emergency services, [RFC6442]
routing described in [RFC6443] was developed for use in emergency supports conveyance of location within non-emergency calls as well as
services, [RFC6442] does not prohibit the conveyance of location emergency calls. "Implications of 'retransmission-allowed' for SIP
within non-emergency calls. "Implications of 'retransmission- Location Conveyance" [RFC5606] Section 1 describes the overall
allowed' for SIP Location Conveyance" [RFC5606] Section 1 describes architecture, as well as non-emergency usage scenarios:
the overall architecture, as well as non-emergency usage scenarios:
The Presence Information Data Format for Location Objects (PIDF-LO The Presence Information Data Format for Location Objects (PIDF-LO
[RFC4119]) carries both location information (LI) and policy [RFC4119]) carries both location information (LI) and policy
information set by the Rule Maker, as is stipulated in [RFC3693]. information set by the Rule Maker, as is stipulated in [RFC3693].
The policy carried along with LI allows the Rule Maker to The policy carried along with LI allows the Rule Maker to
restrict, among other things, the duration for which LI will be restrict, among other things, the duration for which LI will be
retained by recipients and the redistribution of LI by recipients. retained by recipients and the redistribution of LI by recipients.
The Session Initiation Protocol [RFC3261] is one proposed Using The Session Initiation Protocol [RFC3261] is one proposed Using
Protocol for PIDF-LO. The conveyance of PIDF-LO within SIP is Protocol for PIDF-LO. The conveyance of PIDF-LO within SIP is
specified in [RFC6442]. The common motivation for providing LI in specified in [RFC6442]. The common motivation for providing LI in
SIP is to allow location to be considered in routing the SIP SIP is to allow location to be considered in routing the SIP
message. One example use case would be emergency services, in message. One example use case would be emergency services, in
which the location will be used by dispatchers to direct the which the location will be used by dispatchers to direct the
response. Another use case might be providing location to be used response. Another use case might be providing location to be used
by services associated with the SIP session; a location associated by services associated with the SIP session; a location associated
with a call to a taxi service, for example, might be used to route with a call to a taxi service, for example, might be used to route
to a local franchisee of a national service and also to route the to a local franchisee of a national service and also to route the
taxi to pick up the caller. taxi to pick up the caller.
As noted in [RFC6280] Section 1.1, the intent of the Geopriv
architecture was to provide strong privacy protections:
A central feature of the Geopriv architecture is that location
information is always bound to privacy rules to ensure that
entities that receive location information are informed of how
they may use it. These rules can convey simple directives ("do
not share my location with others"), or more robust preferences
("allow my spouse to know my exact location all of the time, but
only allow my boss to know it during work hours")... The binding
of privacy rules to location information can convey users' desire
for and expectations of privacy, which in turn helps to bolster
social and legal systems' protection of those expectations.
However, when location objects are included within SIP messages,
practical limitations arise, as noted in [RFC5606] Section 3.2:
Consensus has emerged that any SIP entity that receives a SIP
message containing LI through the operation of SIP's normal
routing procedures or as a result of location-based routing should
be considered an authorized recipient of that LI. Because of this
presumption, one SIP element may pass the LI to another even if
the LO it contains has <retransmission-allowed> set to "no"; this
sees the passing of the SIP message as part of the delivery to
authorized recipients, rather than as retransmission. SIP
entities are still enjoined from passing these messages outside
the normal routing to external entities if <retransmission-
allowed> is set to "no", as it is the passing to third parties
that <retransmission-allowed> is meant to control.
1.2.2. Hoax Calls 1.2.2. Hoax Calls
Hoax calls have been a problem for emergency services dating back to Hoax calls have been a problem for emergency services dating back to
the time of street corner call boxes. As the European Emergency the time of street corner call boxes. As the European Emergency
Number Association (EENA) has noted [EENA]: "False emergency calls Number Association (EENA) has noted [EENA]: "False emergency calls
divert emergency services away from people who may be in life- divert emergency services away from people who may be in life-
threatening situations and who need urgent help. This can mean the threatening situations and who need urgent help. This can mean the
difference between life and death for someone in trouble." difference between life and death for someone in trouble."
EENA [EENA] has attempted to define terminology and describe best EENA [EENA] has attempted to define terminology and describe best
skipping to change at page 9, line 26 skipping to change at page 8, line 41
authentication (Section 8.3), and issues relating to identity and authentication (Section 8.3), and issues relating to identity and
anonymity (Section 8.4). anonymity (Section 8.4).
"Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats "Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats
against geographic location privacy, including protocol threats, against geographic location privacy, including protocol threats,
threats resulting from the storage of geographic location data, and threats resulting from the storage of geographic location data, and
threats posed by the abuse of information. threats posed by the abuse of information.
"Security Threats and Requirements for Emergency Call Marking and "Security Threats and Requirements for Emergency Call Marking and
Mapping" [RFC5069] reviews security threats associated with the Mapping" [RFC5069] reviews security threats associated with the
marking of signalling messages and the process of mapping locations marking of signaling messages and the process of mapping locations to
to Universal Resource Identifiers (URIs) that point to PSAPs. RFC Universal Resource Identifiers (URIs) that point to PSAPs. RFC 5069
5069 describes attacks on the emergency services system, such as describes attacks on the emergency services system, such as
attempting to deny system services to all users in a given area, to attempting to deny system services to all users in a given area, to
gain fraudulent use of services and to divert emergency calls to non- gain fraudulent use of services and to divert emergency calls to non-
emergency sites. In addition, it describes attacks against emergency sites. In addition, it describes attacks against
individuals, including attempts to prevent an individual from individuals, including attempts to prevent an individual from
receiving aid, or to gain information about an emergency, as well as receiving aid, or to gain information about an emergency, as well as
attacks on emergency services infrastructure elements, such as attacks on emergency services infrastructure elements, such as
mapping discovery and mapping servers. mapping discovery and mapping servers.
"Secure Telephone Identity Threat Model" [I-D.ietf-stir-threats] "Secure Telephone Identity Threat Model" [I-D.ietf-stir-threats]
analyzes threats relating to impersonation and obscuring of calling analyzes threats relating to impersonation and obscuring of calling
skipping to change at page 12, line 15 skipping to change at page 11, line 31
2. Location-by-reference (Section 3.2), which enables location to 2. Location-by-reference (Section 3.2), which enables location to
be obtained by the PSAP directly from the location server, over a be obtained by the PSAP directly from the location server, over a
confidential and integrity-protected channel, avoiding confidential and integrity-protected channel, avoiding
modification by the end-host or an intermediary. This mechanism modification by the end-host or an intermediary. This mechanism
is specified in [RFC6753]. is specified in [RFC6753].
3. Proxy added location (Section 3.3), which protects against 3. Proxy added location (Section 3.3), which protects against
location forgery by the end host. This mechanism is specified in location forgery by the end host. This mechanism is specified in
[RFC6442]. [RFC6442].
3.1. Signed Location by Value 3.1. Signed Location-by-Value
With location signing, a location server signs the location With location signing, a location server signs the location
information before it is sent to the Target. The signed location information before it is sent to the Target. The signed location
information is then sent to the location recipient, who verifies it. information is then sent to the location recipient, who verifies it.
Figure 1 shows the communication model with the target requesting Figure 1 shows the communication model with the target requesting
signed location in step (a), the location server returns it in step signed location in step (a), the location server returns it in step
(b) and it is then conveyed to the location recipient in step (c) who (b) and it is then conveyed to the location recipient in step (c) who
verifies it. For SIP, the procedures described in "Location verifies it. For SIP, the procedures described in "Location
Conveyance for the Session Initiation Protocol" [RFC6442] are Conveyance for the Session Initiation Protocol" [RFC6442] are
skipping to change at page 15, line 26 skipping to change at page 15, line 5
intermediate Certificate Authorities (CAs) certified by the VESA, intermediate Certificate Authorities (CAs) certified by the VESA,
which will then issue certificates to the LIS. In terms of the which will then issue certificates to the LIS. In terms of the
workload imposed on the VESA, the latter approach is highly workload imposed on the VESA, the latter approach is highly
preferable. However, this raises the question of who would operate preferable. However, this raises the question of who would operate
the intermediate CAs and what the expectations would be. the intermediate CAs and what the expectations would be.
In particular, the question arises as to the requirements for LIS In particular, the question arises as to the requirements for LIS
certificate issuance, and how they would compare to requirements for certificate issuance, and how they would compare to requirements for
issuance of other certificates such as an SSL/TLS web certificate. issuance of other certificates such as an SSL/TLS web certificate.
3.2. Location by Reference 3.2. Location-by-Reference
Location-by-reference was developed so that end hosts can avoid Location-by-Reference was developed so that end hosts can avoid
having to periodically query the location server for up-to-date having to periodically query the location server for up-to-date
location information in a mobile environment. Additionally, if location information in a mobile environment. Additionally, if
operators do not want to disclose location information to the end operators do not want to disclose location information to the end
host without charging them, location-by-reference provides a host without charging them, location-by-reference provides a
reasonable alternative. Also, since location-by-reference enables reasonable alternative. Also, since location-by-reference enables
the PSAP to directly contact the location server, it avoids potential the PSAP to directly contact the location server, it avoids potential
attacks by intermediaries. As noted in "A Location Dereference attacks by intermediaries.
Protocol Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a
location reference can be obtained via HTTP-Enabled Location Delivery As noted in "A Location Dereference Protocol Using HTTP-Enabled
(HELD) [RFC5985]. Location Delivery (HELD)" [RFC6753], a location reference can be
obtained via HTTP-Enabled Location Delivery (HELD) [RFC5985]. In
addition, "Location Configuration Extensions for Policy Management"
[RFC7199] extends location configuration protocols such as HELD to
provide hosts with a reference to the rules that apply to a Location-
by-Reference so that the host can view or set these rules.
Figure 2 shows the communication model with the target requesting a Figure 2 shows the communication model with the target requesting a
location reference in step (a), the location server returns the location reference in step (a), the location server returns the
reference in step (b), and it is then conveyed to the location reference and potentially the policy in step (b), and it is then
recipient in step (c). The location recipient needs to resolve the conveyed to the location recipient in step (c). The location
reference with a request in step (d). Finally, location information recipient needs to resolve the reference with a request in step (d).
is returned to the Location Recipient afterwards. For location Finally, location information is returned to the Location Recipient
conveyance in SIP, the procedures described in [RFC6442] are afterwards. For location conveyance in SIP, the procedures described
applicable. in [RFC6442] are applicable.
+-----------+ Geopriv +-----------+ +-----------+ Geopriv +-----------+
| | Location | Location | | | Location | Location |
| LIS +<------------->+ Recipient | | LIS +<------------->+ Recipient |
| | Dereferencing | | | | Dereferencing | |
+-+-------+-+ Protocol (d) +----+------+ +-+-------+-+ Protocol (d) +----+------+
^ | --^ ^ | --^
| | -- | | --
Geopriv |Req. | -- Geopriv |Req. |LbyR + --
Location |LbyR |LbyR -- Protocol Conveying Location |LbyR |Policy -- Protocol Conveying
Configuration |(a) |(b) -- Location (e.g. SIP) Configuration |(a) |(b) -- Location (e.g. SIP)
Protocol | | -- (c) Protocol | | -- (c)
| V -- | V --
+-+-------+-+ -- +-+-------+-+ --
| Target / | -- | Target / | --
| End Host + | End Host +
| | | |
+-----------+ +-----------+
Figure 2: Location by Reference Figure 2: Location by Reference
skipping to change at page 18, line 13 skipping to change at page 17, line 41
could be technically infeasible. Expiration of location URIs could be technically infeasible. Expiration of location URIs
limits the usable time for a location URI, requiring that an limits the usable time for a location URI, requiring that an
attacker continue to learn new location URIs to retain access to attacker continue to learn new location URIs to retain access to
current location information. current location information.
In situations where "Authorization by Possession" is not suitable In situations where "Authorization by Possession" is not suitable
(such as where location hiding [RFC6444] is required), the (such as where location hiding [RFC6444] is required), the
"Authorization via Access Control Lists" model may be preferred. "Authorization via Access Control Lists" model may be preferred.
Without the introduction of hierarchy, it would be necessary for the Without the introduction of hierarchy, it would be necessary for the
PSAP to obtain client certificates or Digest credentials for all the PSAP to obtain credentials, such as certificates or shared symmetric
LISes in its coverage area, to enable it to successfully dereference keys, for all the LISes in its coverage area, to enable it to
LbyRs. In situations with more than a few LISes per PSAP, this would successfully dereference LbyRs. In situations with more than a few
present operational challenges. LISes per PSAP, this would present operational challenges.
A certificate hierarchy providing PSAPs with client certificates A certificate hierarchy providing PSAPs with client certificates
chaining to the VESA could be used to enable the LIS to authenticate chaining to the VESA could be used to enable the LIS to authenticate
and authorize PSAPs for dereferencing. Note that unlike PIDF-LO and authorize PSAPs for dereferencing. Note that unlike PIDF-LO
signing (which mitigates against modification of PIDF-LOs), this signing (which mitigates against modification of PIDF-LOs), this
merely provides the PSAP with access to a (potentially unsigned) merely provides the PSAP with access to a (potentially unsigned)
PIDF-LO, albeit over a protected TLS channel. PIDF-LO, albeit over a protected TLS channel.
Another approach would be for the local LIS to upload location Another approach would be for the local LIS to upload location
information to a location aggregation point who would in turn manage information to a location aggregation point who would in turn manage
the relationships with the PSAP. This would shift the management the relationships with the PSAP. This would shift the management
burden from the PSAPs to the location aggregation points. burden from the PSAPs to the location aggregation points.
3.3. Proxy Adding Location 3.3. Proxy Adding Location
Instead of relying upon the end host to provide location, is possible Instead of relying upon the end host to provide location, is possible
for a proxy that has the ability to determine the location of the end for a proxy that has the ability to determine the location of the end
point (e.g., based on the end host IP or MAC address) to retrieve and point (e.g., based on the end host IP or MAC address) to retrieve and
add or override location information. add or override location information. This requires deployment of
application layer entities by ISPs, unlike the two other techniques.
The proxies could be used for emergency or non-emergency
communications, or both.
The use of proxy-added location is primarily applicable in scenarios The use of proxy-added location is primarily applicable in scenarios
where the end host does not provide location. As noted in [RFC6442] where the end host does not provide location. As noted in [RFC6442]
Section 4.1: Section 4.1:
A SIP intermediary SHOULD NOT add location to a SIP request that A SIP intermediary SHOULD NOT add location to a SIP request that
already contains location. This will quite often lead to already contains location. This will quite often lead to
confusion within LRs. However, if a SIP intermediary adds confusion within LRs. However, if a SIP intermediary adds
location, even if location was not previously present in a SIP location, even if location was not previously present in a SIP
request, that SIP intermediary is fully responsible for addressing request, that SIP intermediary is fully responsible for addressing
skipping to change at page 23, line 9 skipping to change at page 22, line 42
detected by the location recipient (e.g., the PSAP), using detected by the location recipient (e.g., the PSAP), using
cryptographic mechanisms, as described in "Enhancements for cryptographic mechanisms, as described in "Enhancements for
Authenticated Identity Management in the Session Initiation Protocol" Authenticated Identity Management in the Session Initiation Protocol"
[RFC4474]. However, compatibility with Session Border Controllers [RFC4474]. However, compatibility with Session Border Controllers
(SBCs) that modify integrity-protected headers has proven to be an (SBCs) that modify integrity-protected headers has proven to be an
issue in practice, and as a result, a revision is in progress issue in practice, and as a result, a revision is in progress
[I.D.ietf-stir-rfc4474bis]. In the absence of an end-to-end [I.D.ietf-stir-rfc4474bis]. In the absence of an end-to-end
solution, SIP over Transport Layer Security (TLS) can be used to solution, SIP over Transport Layer Security (TLS) can be used to
provide message authentication and integrity protection hop-by-hop. provide message authentication and integrity protection hop-by-hop.
As noted in Section 1.2, although the GEOPRIV architecture can
deliver the caller's privacy preferences along with the location
object, location information included within SIP messages is
available to intermediaries, as well as to snoopers if transmission
layer security is not used. Therefore where the ability to make
anonymous calls is restricted (potentially due to concerns over hoax
calling), location information transmitted within SIP messages can be
linked to the caller identity.
PSAPs remain vulnerable to distributed denial of service attacks, PSAPs remain vulnerable to distributed denial of service attacks,
even where the mitigation techniques described in this document are even where the mitigation techniques described in this document are
utilized. Placing a large number of emergency calls that appear to utilized. Placing a large number of emergency calls that appear to
come from different locations is an example of an attack that is come from different locations is an example of an attack that is
difficult to carry out within the legacy system, but is easier to difficult to carry out within the legacy system, but is easier to
imagine within IP-based emergency services. Also, in the current imagine within IP-based emergency services. Also, in the current
system, it would be very difficult for an attacker from country 'Foo' system, it would be very difficult for an attacker from country 'Foo'
to attack the emergency services infrastructure located in country to attack the emergency services infrastructure located in country
'Bar', but this attack is possible within IP-based emergency 'Bar', but this attack is possible within IP-based emergency
services. services.
While manually mounting the attacks described in Section 2 is non- While manually mounting the attacks described in Section 2 is non-
trivial, the attacks described in this document can be automated. trivial, the attacks described in this document can be automated.
While manually carrying out a location theft would require the While manually carrying out a location theft would require the
attacker to be in proximity to the location being spoofed, or to attacker to be in proximity to the location being spoofed, or to
collude with another end host, an attacker able to run code on an end collude with another end host, an attacker able to run code on an end
host can obtain its location, and cause an emergency call to be made. host can obtain its location, and cause an emergency call to be made.
While manually carrying out a time shifting attack would require that While manually carrying out a time shifting attack would require that
the attacker visit the location and submit it before the location the attacker visit the location and submit it before the location
information is considered stale, while travelling rapidly away from information is considered stale, while traveling rapidly away from
that location to avoid apprehension, these limitations would not that location to avoid apprehension, these limitations would not
apply to an attacker able to run code on the end host. While apply to an attacker able to run code on the end host. While
obtaining a PIDF-LO from a spoofed IP address requires that the obtaining a PIDF-LO from a spoofed IP address requires that the
attacker be on the path between the HELD requester and the LIS, if attacker be on the path between the HELD requester and the LIS, if
the attacker is able to run code requesting the PIDF-LO, retrieve it the attacker is able to run code requesting the PIDF-LO, retrieve it
from the LIS, and then make an emergency call using it, this attack from the LIS, and then make an emergency call using it, this attack
becomes much easier. To mitigate the risk of automated attacks, becomes much easier. To mitigate the risk of automated attacks,
service providers can limit the ability of untrusted code (such as service providers can limit the ability of untrusted code (such as
WebRTC applications written in Javascript) to make emergency calls. WebRTC applications written in Javascript) to make emergency calls.
skipping to change at page 24, line 14 skipping to change at page 23, line 38
protecting other high-value service providers, except that location protecting other high-value service providers, except that location
information may be used to filter call setup requests, to weed out information may be used to filter call setup requests, to weed out
requests that are out of area. Even for large cities PSAPs may only requests that are out of area. Even for large cities PSAPs may only
have a handful of call takers on duty. So even if automated have a handful of call takers on duty. So even if automated
techniques are utilized to evaluate the trustworthiness of conveyed techniques are utilized to evaluate the trustworthiness of conveyed
location and call takers can, by questioning the caller, eliminate location and call takers can, by questioning the caller, eliminate
many hoax calls, PSAPs can be overwhelmed even by a small-scale many hoax calls, PSAPs can be overwhelmed even by a small-scale
attack. Finally, first responder resources are scarce, particularly attack. Finally, first responder resources are scarce, particularly
during mass-casualty events. during mass-casualty events.
6. IANA Considerations 6. Privacy Considerations
The emergency calling architecture described in [RFC6443] utilizes
the PIDF-LO format defined in [RFC4119]. As described in the
location privacy architecture [RFC6280], privacy rules that may
include policy instructions are conveyed along with the location
object.
The intent of the location privacy architecture was to provide strong
privacy protections, as noted in [RFC6280] Section 1.1:
A central feature of the Geopriv architecture is that location
information is always bound to privacy rules to ensure that
entities that receive location information are informed of how
they may use it. These rules can convey simple directives ("do
not share my location with others"), or more robust preferences
("allow my spouse to know my exact location all of the time, but
only allow my boss to know it during work hours")... The binding
of privacy rules to location information can convey users' desire
for and expectations of privacy, which in turn helps to bolster
social and legal systems' protection of those expectations.
However, in practice this architecture has limitations which apply
within emergency and non-emergency situations. As noted in Section
1.2.2, concerns about hoax calls have lead to restrictions on
anonymous emergency calls. Caller identification (potentially
asserted in SIP via P-Asserted-Identity and via SIP Identity) may be
used during emergency calls. As a result, in many cases location
information transmitted within SIP messages can be linked to caller
identity. For example, in case of signed LbyV, there are privacy
concerns arising from linking the location object to identifiers to
prevent replay attacks, as described in Section 3.1.
The ability to observe location information during emergency calls
may also represent a privacy risk. As a result, [RFC6443] requires
transmission layer security for SIP messages, as well as interactions
with the location server. However, even where transmission layer
security is used, privacy rules associated with location information
may not apply.
In many jurisdictions, an individual requesting emergency assistance
is assumed to be granting permission to the PSAP, call taker and
first responders to obtain their location in order to accelerate
dispatch. As a result, privacy policies associated with location are
implicitly waived when an emergency call is initiated. In addition,
when location information is included within SIP messages either in
emergency or non-emergency uses, SIP entities receiving the SIP
message are implicitly assumed to be authorized location recipients,
as noted in [RFC5606] Section 3.2:
Consensus has emerged that any SIP entity that receives a SIP
message containing LI through the operation of SIP's normal
routing procedures or as a result of location-based routing should
be considered an authorized recipient of that LI. Because of this
presumption, one SIP element may pass the LI to another even if
the LO it contains has <retransmission-allowed> set to "no"; this
sees the passing of the SIP message as part of the delivery to
authorized recipients, rather than as retransmission. SIP
entities are still enjoined from passing these messages outside
the normal routing to external entities if <retransmission-
allowed> is set to "no", as it is the passing to third parties
that <retransmission-allowed> is meant to control.
Where LbyR is utilized rather than LbyV, it is possible to apply more
restrictive authorization policies, limiting access to intermediaries
and snoopers. However, this is not possible if the "authorization by
possession" model is used.
7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
7. References 8. References
7.1. Informative References 8.1. Informative References
[I-D.ietf-stir-problem-statement] [I-D.ietf-stir-problem-statement]
Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement", Internet draft (work in Telephone Identity Problem Statement", Internet draft (work in
progress), draft-ietf-stir-problem-statement-05.txt, May 2014. progress), draft-ietf-stir-problem-statement-05.txt, May 2014.
[I-D.ietf-stir-threats] [I-D.ietf-stir-threats]
Peterson, J., "Secure Telephone Identity Threat Model", Peterson, J., "Secure Telephone Identity Threat Model",
Internet draft (work in progress), draft-ietf-stir- Internet draft (work in progress), draft-ietf-stir-
threats-03.txt, June 2014. threats-03.txt, June 2014.
[I-D.ietf-stir-rfc4474bis] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C. and E. Rescorla, "Authenticated Peterson, J., Jennings, C. and E. Rescorla, "Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
Internet draft (work in progress), draft-ietf-stir- Internet draft (work in progress), draft-ietf-stir-
rfc4474bis-00.txt, June 2014. rfc4474bis-01.txt, July 2014.
[I-D.thomson-geopriv-location-dependability] [I-D.thomson-geopriv-location-dependability]
Thomson, M. and J. Winterbottom, "Digital Signature Methods Thomson, M. and J. Winterbottom, "Digital Signature Methods
for Location Dependability", Internet draft (work in for Location Dependability", Internet draft (work in
progress), draft-thomson-geopriv-location- progress), draft-thomson-geopriv-location-
dependability-07.txt, March 2011. dependability-07.txt, March 2011.
[EENA] EENA, "False Emergency Calls", EENA Operations Document, [EENA] EENA, "False Emergency Calls", EENA Operations Document,
Version 1.1, May 2011, http://www.eena.org/ressource/static/ Version 1.1, May 2011, http://www.eena.org/ressource/static/
files/2012_05_04-3.1.2.fc_v1.1.pdf files/2012_05_04-3.1.2.fc_v1.1.pdf
skipping to change at page 27, line 5 skipping to change at page 27, line 50
Location Delivery (HELD)", RFC 6753, October 2012. Location Delivery (HELD)", RFC 6753, October 2012.
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling", BCP Communications Services in Support of Emergency Calling", BCP
181, RFC 6881, March 2013. 181, RFC 6881, March 2013.
[RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C. and M. Patel, [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C. and M. Patel,
"Public Safety Answering Point (PSAP) Callback", RFC 7090, "Public Safety Answering Point (PSAP) Callback", RFC 7090,
April 2014. April 2014.
[RFC7199] Barnes, R., Thomson, M., Winterbottom, J. and H. Tschofenig,
"Location Configuration Extensions for Policy Management", RFC
7199, April 2014.
[SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in hoax [SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in hoax
calls", Arab News, May 4, 2010, calls", Arab News, May 4, 2010,
http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384 http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384
[STIR] IETF, "Secure Telephone Identity Revisited (stir) Working [STIR] IETF, "Secure Telephone Identity Revisited (stir) Working
Group", http://datatracker.ietf.org/wg/stir/charter/, October Group", http://datatracker.ietf.org/wg/stir/charter/, October
2013. 2013.
[Swatting] [Swatting]
"Don't Make the Call: The New Phenomenon of 'Swatting', "Don't Make the Call: The New Phenomenon of 'Swatting',
skipping to change at page 27, line 43 skipping to change at page 29, line 8
would also like to thank members of the IETF GEOPRIV WG, including would also like to thank members of the IETF GEOPRIV WG, including
Andrew Newton, Murugaraj Shanmugam, Martin Thomson, Richard Barnes Andrew Newton, Murugaraj Shanmugam, Martin Thomson, Richard Barnes
and Matt Lepinski for their feedback to previous versions of this and Matt Lepinski for their feedback to previous versions of this
document. Thanks also to Pete Resnick, Adrian Farrel, Alissa Cooper, document. Thanks also to Pete Resnick, Adrian Farrel, Alissa Cooper,
Bert Wijnen and Meral Shirazipour who provided review comments in Bert Wijnen and Meral Shirazipour who provided review comments in
IETF last call. IETF last call.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
ARM Ltd. Austria
110 Fulbourn Rd
Cambridge CB1 9NJ
Great Britain
Email: Hannes.tschofenig@gmx.net Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building, New York, NY 10027 450 Computer Science Building, New York, NY 10027
US US
 End of changes. 30 change blocks. 
107 lines changed or deleted 143 lines changed or added

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