< draft-ietf-ecrit-trustworthy-location-12.txt   draft-ietf-ecrit-trustworthy-location-13.txt >
ECRIT Working Group H. Tschofenig ECRIT Working Group H. Tschofenig
INTERNET-DRAFT ARM Ltd. INTERNET-DRAFT ARM Ltd.
Category: Informational H. Schulzrinne Category: Informational H. Schulzrinne
Expires: December 2, 2014 Columbia University Expires: December 29, 2014 Columbia University
B. Aboba (ed.) B. Aboba (ed.)
Microsoft Corporation Microsoft Corporation
2 June 2014 28 June 2014
Trustworthy Location Trustworthy Location
draft-ietf-ecrit-trustworthy-location-12.txt draft-ietf-ecrit-trustworthy-location-13.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 2, 2014. This Internet-Draft will expire on December 29, 2014.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Literature review . . . . . . . . . . . . . . . . . . . . 5 1.2 Emergency Services Architecture . . . . . . . . . . . . . 5
2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Threat Models . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 9 2.1. Existing Work . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 9 2.2 Adversary Model . . . . . . . . . . . . . . . . . . . . . 9
3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 10 2.3. Location Spoofing . . . . . . . . . . . . . . . . . . . . 10
3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 10 2.4. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 11
3.2. Location by Reference . . . . . . . . . . . . . . . . . . 14 3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 11
3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 17 3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 12
4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 18 3.2. Location by Reference . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7.1. Informative references . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Informative references . . . . . . . . . . . . . . . . . . 24
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
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 36 skipping to change at page 5, line 36
because the attacker has moved. because the attacker has moved.
"Location Theft" is where the attacker captures a Target's location "Location Theft" is where the attacker captures a Target's location
information (possibly including a signature) and presents it as their information (possibly including a signature) and presents it as their
own. Location theft can occur in a single instance, or may be own. Location theft can occur in a single instance, or may be
continuous (e.g., where the attacker has gained control over the continuous (e.g., where the attacker has gained control over the
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. Literature Review 1.2. Emergency Services Architecture
There is existing work on the problem of hoax calls, as well as This section describes how location is utilized in the Internet
analyses of aspects of the security of emergency services, threats to Emergency Services Architecture, as well as the existing work on the
geographic location privacy, threats relating to spoofing of caller problem of hoax calls.
identification and modification of location information in transit.
This section reviews the literature.
1.2.1. Hoax Calls 1.2.1. Location Conveyance
The Internet architecture for emergency calling is described in
"Framework for Emergency Calling Using Internet Multimedia"
[RFC6443]. Best practices for utilizing the architecture to make
emergency calls are described in "Best Current Practice for
Communications Services in Support of Emergency Calling" [RFC6881].
As noted in "An Architecture for Location and Location Privacy in
Internet Applications" [RFC6280] Section 6.3:
"there are three critical steps in the placement of an emergency
call, each involving location information:
1. Determine the location of the caller.
2. Determine the proper Public Safety Answering Point (PSAP) for
the caller's location.
3. Send a SIP INVITE message, including the caller's location, to
the PSAP."
The conveyance of location information within the Session Initiation
Protocol (SIP) is described in "Location Conveyance for the Session
Initiation Protocol" [RFC6442]. The Security Considerations (Section
7) discusses privacy, authentication and integrity concerns relating
to conveyed location. This includes discussion of transmission layer
security for confidentiality and integrity protection of SIP, as well
as undeployed end-to-end security mechanisms for protection of
location information (e.g. S/MIME).
However, the conveyance architecture has limitations with respect to
privacy protection. Even where transmission-layer security is
utilized, since it terminates at each hop, location information may
be available for inspection by an intermediary which, if it decides
that the location value is unacceptable or insufficiently accurate,
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
emergency services. Although the infrastructure for location-based
routing described in [RFC6443] was developed for use in emergency
services, [RFC6442] does not prohibit the conveyance of location
within non-emergency calls. "Implications of 'retransmission-
allowed' for SIP Location Conveyance" [RFC5606] Section 1 describes
the overall architecture, as well as non-emergency usage scenarios:
The Presence Information Data Format for Location Objects (PIDF-LO
[RFC4119]) carries both location information (LI) and policy
information set by the Rule Maker, as is stipulated in [RFC3693].
The policy carried along with LI allows the Rule Maker to
restrict, among other things, the duration for which LI will be
retained by recipients and the redistribution of LI by recipients.
The Session Initiation Protocol [RFC3261] is one proposed Using
Protocol for PIDF-LO. The conveyance of PIDF-LO within SIP is
specified in [RFC6442]. The common motivation for providing LI in
SIP is to allow location to be considered in routing the SIP
message. One example use case would be emergency services, in
which the location will be used by dispatchers to direct the
response. Another use case might be providing location to be used
by services associated with the SIP session; a location associated
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
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
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
current practices for dealing with false emergency calls. Reducing current practices for dealing with false emergency calls. Reducing
the number of hoax calls represents a challenge, since emergency the number of hoax calls represents a challenge, since emergency
services authorities in most countries are required to answer every services authorities in most countries are required to answer every
call (whenever possible). Where the caller cannot be identified, the call (whenever possible). Where the caller cannot be identified, the
ability to prosecute is limited. ability to prosecute is limited.
A particularly dangerous form of hoax call is "swatting" - a hoax A particularly dangerous form of hoax call is "swatting" - a hoax
emergency call that draws a response from law enforcement prepared emergency call that draws a response from law enforcement prepared
for a violent confrontation (e.g. a fake hostage situation that for a violent confrontation (e.g. a fake hostage situation that
skipping to change at page 6, line 41 skipping to change at page 8, line 39
attack against the PSAP, or to make fraudulent emergency calls. attack against the PSAP, or to make fraudulent emergency calls.
Where emergency calls have been allowed from handsets lacking a SIM Where emergency calls have been allowed from handsets lacking a SIM
card, or where ownership of the SIM card cannot be determined, the card, or where ownership of the SIM card cannot be determined, the
frequency of hoax calls has often been unacceptably high frequency of hoax calls has often been unacceptably high
[TASMANIA][UK][SA]. [TASMANIA][UK][SA].
However, there are few documented cases of hoax calls that have However, there are few documented cases of hoax calls that have
arisen from conveyance of untrustworthy location information within arisen from conveyance of untrustworthy location information within
an emergency call, which is the focus of this document. an emergency call, which is the focus of this document.
1.2.2. Existing IETF Work 2. Threat Models
The Internet architecture for emergency calling is described in This section reviews existing analyses of the security of emergency
"Framework for Emergency Calling Using Internet Multimedia" [RFC6443] services, threats to geographic location privacy, threats relating to
and "Best Current Practice for Communications Services in Support of spoofing of caller identification and modification of location
Emergency Calling" [RFC6881]. The conveyance of location information information in transit. In addition, the threat model applying to
within the Session Initiation Protocol (SIP) is described in this work is described.
"Location Conveyance for the Session Initiation Protocol" [RFC6442],
which in the Security Considerations (Section 7) includes discussion
of privacy, authentication and integrity concerns relating to
conveyed location. Note that while [RFC6442] does not prohibit the
conveyance of location within non-emergency calls, in practice,
location conveyance requires additional infrastructure as described
in [RFC6443]. As a result, privacy issues inherent in conveyance of
location within non-emergency calls are not considered within
[RFC6442].
"Secure Telephone Identity Threat Model" [I-D.ietf-stir-threats] 2.1. Existing Work
analyzes threats relating to impersonation and obscuring of calling
party numbers, reviewing the capabilities available to attackers, and
the scenarios in which attacks are launched.
"An Architecture for Location and Location Privacy in Internet "An Architecture for Location and Location Privacy in Internet
Applications" [RFC6280] describes an architecture for privacy- Applications" [RFC6280] describes an architecture for privacy-
preserving location-based services in the Internet, focusing on preserving location-based services in the Internet, focusing on
authorization, security and privacy requirements for the data formats authorization, security and privacy requirements for the data formats
and protocols used by these services. Within the Security and protocols used by these services.
Considerations (Section 5), mechanisms for ensuring the security of
the location distribution chain are discussed; these include
mechanisms for hop-by-hop confidentiality and integrity protection as
well as end-to-end assurance. As noted in Section 6.3:
"there are three critical steps in the placement of an emergency
call, each involving location information:
1. Determine the location of the caller.
2. Determine the proper Public Safety Answering Point (PSAP) for
the caller's location.
3. Send a SIP INVITE message, including the caller's location, to Within the Security Considerations (Section 5), mechanisms for
the PSAP." ensuring the security of the location distribution chain are
discussed; these include mechanisms for hop-by-hop confidentiality
and integrity protection as well as end-to-end assurance.
"Geopriv Requirements" [RFC3693] focuses on the authorization, "Geopriv Requirements" [RFC3693] focuses on the authorization,
security and privacy requirements of location-dependent services, security and privacy requirements of location-dependent services,
including emergency services. Within the Security Considerations including emergency services. Within the Security Considerations
(Section 8), this includes discussion of emergency services (Section 8), this includes discussion of emergency services
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,
skipping to change at page 8, line 13 skipping to change at page 9, line 37
to Universal Resource Identifiers (URIs) that point to PSAPs. RFC to Universal Resource Identifiers (URIs) that point to PSAPs. RFC
5069 describes attacks on the emergency services system, such as 5069 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.
2. Threat Model "Secure Telephone Identity Threat Model" [I-D.ietf-stir-threats]
analyzes threats relating to impersonation and obscuring of calling
party numbers, reviewing the capabilities available to attackers, and
the scenarios in which attacks are launched.
2.2. Adversary Model
To provide a structured analysis we distinguish between three To provide a structured analysis we distinguish between three
adversary models: adversary models:
External adversary model: The end host, e.g., an emergency caller External adversary model: The end host, e.g., an emergency caller
whose location is going to be communicated, is honest and the whose location is going to be communicated, is honest and the
adversary may be located between the end host and the location adversary may be located between the end host and the location
server or between the end host and the PSAP. None of the server or between the end host and the PSAP. None of the
emergency service infrastructure elements act maliciously. emergency service infrastructure elements act maliciously.
skipping to change at page 9, line 10 skipping to change at page 10, line 39
Also, we do not cover threats arising from inadequate location Also, we do not cover threats arising from inadequate location
infrastructure. For example, a stale wiremap or an inaccurate access infrastructure. For example, a stale wiremap or an inaccurate access
point location database could be utilized by the Location Information point location database could be utilized by the Location Information
Server (LIS) or the end host in its location determination, thereby Server (LIS) or the end host in its location determination, thereby
leading to an inaccurate determination of location. Similarly, a leading to an inaccurate determination of location. Similarly, a
Voice Service Provider (VSP) (and indirectly a LIS) could utilize the Voice Service Provider (VSP) (and indirectly a LIS) could utilize the
wrong identity (such as an IP address) for location lookup, thereby wrong identity (such as an IP address) for location lookup, thereby
providing the end host with misleading location information. providing the end host with misleading location information.
2.1. Location Spoofing 2.3. Location Spoofing
Where location is attached to the emergency call by an end host, the Where location is attached to the emergency call by an end host, the
end host can fabricate a PIDF-LO and convey it within an emergency end host can fabricate a PIDF-LO and convey it within an emergency
call. The following represent examples of location spoofing: call. The following represent examples of location spoofing:
Place shifting: Trudy, the adversary, pretends to be at an Place shifting: Trudy, the adversary, pretends to be at an
arbitrary location. arbitrary location.
Time shifting: Trudy pretends to be at a location she was a Time shifting: Trudy pretends to be at a location she was a
while ago. while ago.
Location theft: Trudy observes or obtains Alice's location and Location theft: Trudy observes or obtains Alice's location and
replays it as her own. replays it as her own.
2.2. Identity Spoofing 2.4. Identity Spoofing
While this document does not focus on the problems created by While this document does not focus on the problems created by
determination of location based on spoofed caller identification, the determination of location based on spoofed caller identification, the
ability to ascertain identity is important, since the threat of ability to ascertain identity is important, since the threat of
punishment reduces hoax calls. As an example, calls from pay phones punishment reduces hoax calls. As an example, calls from pay phones
are subject to greater scrutiny by the call taker. are subject to greater scrutiny by the call taker.
With calls originating on an IP network, at least two forms of With calls originating on an IP network, at least two forms of
identity are relevant, with the distinction created by the split identity are relevant, with the distinction created by the split
between the IAP and the VSP: between the IAP and the VSP:
skipping to change at page 21, line 15 skipping to change at page 22, line 40
This document focuses on threats that arise from conveyance of This document focuses on threats that arise from conveyance of
misleading location information, rather than caller identification or misleading location information, rather than caller identification or
authentication and integrity protection of the messages in which authentication and integrity protection of the messages in which
location is conveyed. Nevertheless, these aspects are important. In location is conveyed. Nevertheless, these aspects are important. In
some countries, regulators may not require the authenticated identity some countries, regulators may not require the authenticated identity
of the emergency caller (e.g. emergency calls placed from PSTN pay of the emergency caller (e.g. emergency calls placed from PSTN pay
phones or SIM-less cell phones). Furthermore, if identities can phones or SIM-less cell phones). Furthermore, if identities can
easily be crafted (as it is the case with many VoIP offerings today), easily be crafted (as it is the case with many VoIP offerings today),
then the value of emergency caller authentication itself might be then the value of emergency caller authentication itself might be
limited. As a result, attackers can forge emergency call information limited. As a result, attackers can forge emergency calls with a
with a lower risk of being held accountable, which may encourage hoax lower risk of being held accountable, which may encourage hoax calls.
calls.
In order to provide authentication and integrity protection for the In order to provide authentication and integrity protection for the
Session Initiation Protocol (SIP) messages conveying location, Session Initiation Protocol (SIP) messages conveying location,
several security approaches are available. It is possible to ensure several security approaches are available. It is possible to ensure
that modification of the identity and location in transit can be that modification of the identity and location in transit can be
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.jennings-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.
skipping to change at page 22, line 45 skipping to change at page 24, line 30
7.1. Informative References 7.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-02.txt, February 2014. threats-03.txt, June 2014.
[I-D.jennings-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-jennings-stir- Internet draft (work in progress), draft-ietf-stir-
rfc4474bis-01.txt, February 2014. rfc4474bis-00.txt, June 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 23, line 28 skipping to change at page 25, line 13
December 2003. December 2003.
[NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 [NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1
Services (i2)", December 2005. Services (i2)", December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat
Analysis of the Geopriv Protocol", RFC 3694, February 2004. Analysis of the Geopriv Protocol", RFC 3694, February 2004.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004. 3748, June 2004.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and
J. Peterson, "Presence Information Data Format (PIDF)", RFC J. Peterson, "Presence Information Data Format (PIDF)", RFC
3863, August 2004. 3863, August 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006. RFC 4474, August 2006.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July
2006. 2006.
[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales- [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales-
Valenzuela, C., and K. Tammi, "Diameter Session Initiation Valenzuela, C., and K. Tammi, "Diameter Session Initiation
Protocol (SIP) Application", RFC 4740, November 2006. Protocol (SIP) Application", RFC 4740, November 2006.
skipping to change at page 24, line 21 skipping to change at page 26, line 13
and Mapping", RFC 5069, January 2008. and Mapping", RFC 5069, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Level Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Level Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", RFC Usage Clarification, Considerations, and Recommendations", RFC
5491, March 2009. 5491, March 2009.
[RFC5606] Peterson, J., Hardie, T. and J. Morris, "Implications of
'retransmission-allowed' for SIP Location Conveyance", RFC
5606, August 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.2 Message Specification", RFC Extensions (S/MIME) Version 3.2 Message Specification", RFC
5751, January 2010. 5751, January 2010.
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference [RFC5808] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010. Mechanism", RFC 5808, May 2010.
[RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985, [RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985,
September 2010. September 2010.
 End of changes. 26 change blocks. 
71 lines changed or deleted 170 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/