RFC 7378
Trustworthy Location
RFC 7378: Trustworthy Location 🎀
okay so bestie, this one is from the IETF 💖 It's an Informational RFC (so it's not a standards track thing, it's just sharing knowledge 🧚), published December 2014. It was written by H. Tschofenig (Independent), H. Schulzrinne (Columbia University), and B. Aboba, Ed. (Microsoft Corporation). It's ISSN 2070-1721. It doesn't obsolete or update anything, so it's standing on its own 💅
Quick vibe check: this doc is all about how much you can actually trust location info, especially when someone's calling emergency services 🚨 Like, if a PSAP (that's the Public Safety Answering Point, aka the 911-style call center) gets a location that's fake, that's a big mess 💀 So this RFC talks about the threats, some fixes, and how to judge whether a location is trustworthy 🦋
Full disclosure: this is part 1 of 7, so we're only covering the front matter and the first chunk of the doc for now. More parts coming, so stay tuned bestie 🫶
Status of This Memo ✨
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7378.
Copyright Notice 🌸
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents 🧚
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Emergency Services Architecture ............................5
2. Threat Models ...................................................8
2.1. Existing Work ..............................................8
2.2. Adversary Model ............................................9
2.3. Location Spoofing .........................................10
2.4. Identity Spoofing .........................................11
3. Mitigation Techniques ..........................................11
3.1. Signed Location-by-Value ..................................12
3.2. Location-by-Reference .....................................15
3.3. Proxy-Added Location ......................................18
4. Location Trust Assessment ......................................20
5. Security Considerations ........................................23
6. Privacy Considerations .........................................24
7. Informative References .........................................26
Acknowledgments ...................................................30
Authors' Addresses ................................................301. Introduction 🦋
okay so location info is literally needed by a bunch of services 💅 Emergency stuff (fire, ambulance, police) and commercial stuff like food delivery and roadside assistance 🍓
For circuit-switched calls from landlines, and for VoIP services that only do emergency calls from stationary Devices, the location the PSAP gets is looked up from the calling phone number 📞 So for landlines or stationary VoIP, if someone fakes their caller ID, the PSAP can end up totally wrong about where the caller is 😭 The Secure Telephone Identity Revisited [STIR] working group looked at calling party number and Caller ID assurance, as described in "Secure Telephone Identity Problem Statement and Requirements" [RFC7340]. Besides STIR, there are other ways to validate caller identification too. For example, as [EENA] notes, one option is for the PSAP to call the user back, as described in [RFC7090] 🌈
Since caller ID stuff is already being worked on, this doc zooms in on the extra threats that come with IP-based emergency services on nomadic and mobile Devices, where location can be sent to the PSAP inside the emergency call 🧚 Ideally, a call taker at a PSAP can assess in real time how much to trust the info in a call. That covers the automated location sent with the call, location the caller shares themselves, and identity info about the caller or the Device starting the call 🫶 When real-time checking isn't possible, it's important to figure out where the call came from after the fact, so accountability can be enforced 💜
This document defines terminology (including what "trustworthy location" means) in Section 1.1, reviews existing work in Section 1.2, describes threat models in Section 2, outlines potential mitigation techniques in Section 3, covers trust assessment in Section 4, and discusses security considerations in Section 5. ✨
1.1. Terminology 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🎀
We use the definitions of "Internet Access Provider (IAP)", "Internet Service Provider (ISP)", and "Voice Service Provider (VSP)" found in "Requirements for Emergency Context Resolution with Internet Technologies" [RFC5012]. 💅
[EENA] defines a "hoax call" as follows: "A false or malicious call is when a person deliberately telephones the emergency services and tells them there is an emergency when there is not." 🙈
The definitions of "Device", "Target", and "Location Information Server" (LIS) are taken from "An Architecture for Location and Location Privacy in Internet Applications" [RFC6280], Section 7. 🌸
The term "Device" denotes the physical device, such as a mobile phone, PC, or embedded microcontroller, whose location is tracked as a proxy for the location of a Target. 📱
The term "Target" denotes an individual or other entity whose location is sought in the Geopriv architecture [RFC6280]. In many cases, the Target will be the human user of a Device, or it may be an object such as a vehicle or shipping container to which a Device is attached. In some instances, the Target will be the Device itself. The Target is the entity whose privacy the architecture described in [RFC6280] seeks to protect. 🦋
The term "Location Information Server" denotes an entity responsible for providing Devices within an access network with information about their own locations. A Location Information Server uses knowledge of the access network and its physical topology to generate and distribute location information to Devices. 🗺️
The term "location determination method" refers to the mechanism used to determine the location of a Target. This may be something employed by a LIS or by the Target itself. It specifically does not refer to the location configuration protocol (LCP) used to deliver location information to either the Target or the Recipient. This term is reused from "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations" [RFC5491]. 🧠
The term "source" is used to refer to the LIS, node, or Device from which a Recipient (Target or third party) obtains location information. 🔍
Additionally, the terms "location-by-value" (LbyV), "location-by-reference" (LbyR), "Location Configuration Protocol", "Location Dereference Protocol", and "Location Uniform Resource Identifier" (URI) are reused from "Requirements for a Location-by-Reference Mechanism" [RFC5808]. ✨
"Trustworthy Location" is defined as location information that can be attributed to a trusted source, has been protected against modification in transmit, and has been assessed as trustworthy. 👑
"Location Trust Assessment" refers to the process by which the reliability of location information can be assessed. This topic is discussed in Section 4. 🌈
"Identity Spoofing" occurs when the attacker forges or obscures their identity so as to prevent themselves from being identified as the source of the attack. One class of identity spoofing attack involves the forging of call origin identification. 🙈
The following additional terms apply to location spoofing (Section 2.3):
With "Place Shifting", attackers construct a Presence Information Data Format Location Object (PIDF-LO) for a location other than where they are currently located. In some cases, place shifting can be limited in range (e.g., within the coverage area of a particular cell tower). 🍓
"Time Shifting" occurs when the attacker uses or reuses location information that was valid in the past but is no longer valid because the attacker has moved. ⏰
"Location Theft" occurs when the attacker captures a Target's location information (possibly including a signature) and presents it as their own. Location theft can occur in a single instance or may be continuous (e.g., where the attacker has gained control over the victim's Device). Location theft may also be combined with time shifting to present someone else's location information after the original Target has moved. 🥷
1.2. Emergency Services Architecture 🚨
This section describes how location is utilized in the Internet Emergency Services Architecture, as well as the existing work on the problem of hoax calls. 💜
1.2.1. Location ✨
okay so the big picture for emergency calling over the Internet is written up in "Framework for Emergency Calling Using Internet Multimedia" [RFC6443] 🦋. The best practices for actually using that architecture to make emergency calls are in "Best Current Practice for Communications Services in Support of Emergency Calling" [RFC6881] 💅.
"An Architecture for Location and Location Privacy in Internet Applications" [RFC6280] spells out the three critical steps for placing an emergency call, and every single one of them involves location info 😭 (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 way location gets carried inside the Session Initiation Protocol (SIP) is covered in "Location Conveyance for the Session Initiation Protocol" [RFC6442] 🌸. It supports both location-by-value (LbyV) and location-by-reference (LbyR) conveyance. Section 7 of [RFC6442] ("Security Considerations") is the part to read if you care about privacy, authentication, and integrity of conveyed location 🔥. It covers transmission-layer security for confidentiality and integrity protection of SIP, plus end-to-end mechanisms for protecting location information (e.g., S/MIME), which are not deployed yet 🙈. And here's the tea: even with transmission-layer security turned on, an intermediary can still inspect the location info. If it decides the location is unacceptable or not accurate enough, it can send an error indication or replace the location, as described in [RFC6442], Section 3.4 💀.
Location-based routing from [RFC6443] was built for emergency services, but [RFC6442] also works for non-emergency calls 🧚. "Implications of 'retransmission-allowed' for SIP Location Conveyance" [RFC5606] has the overall architecture plus the non-emergency use cases in its Section 1. Quick note: the [LOC-CONVEY] citation in the quote below is the document that was later published as [RFC6442] 🎀:
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 [LOC-CONVEY]. 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.
1.2.2. Hoax Calls 🚨
hoax calls have been a headache for emergency services since the days of street corner call boxes 🙄. The European Emergency Number Association (EENA) put it best [EENA]:
False emergency calls divert emergency services away from people who may be in life-threatening situations and who need urgent help. This can mean the difference between life and death for someone in trouble.
EENA [EENA] has also tried to define the terminology and describe best current practices for handling false emergency calls 💜. Cutting down on hoax calls is genuinely hard, because emergency services authorities in most countries are required to answer every call (whenever possible) 😩. And if the caller can't be identified, prosecution is limited 🙃.
The most dangerous kind is "swatting" 💀: a hoax emergency call that gets a response from law enforcement gearing up for a violent confrontation. Think a fake hostage situation that ends with a "Special Weapons And Tactics" (SWAT) team getting dispatched. In 2008, the Federal Bureau of Investigation (FBI) issued a warning [Swatting] about these attacks getting more frequent and more sophisticated 🚔.
Lots of documented swatting cases (also sometimes called "SWATing") involve faking the emergency AND falsifying or hiding the caller's identity [Swatting] [SWATing] 🫠. There are a bunch of techniques hoax callers use to dodge identification, and overall, how easy it is to identify the caller seems to affect how often hoax calls happen ✨.
Where a Voice Service Provider lets the caller set their own outbound caller identification without checking it against the authenticated identity, forging caller ID is trivial 😤. Similar deal with a Private Branch Exchange (PBX): if an attacker gets into one, they can use that access to launch a denial-of-service attack against the PSAP or make fraudulent emergency calls 🥀. And when emergency calls were allowed from handsets without a subscriber identification module (SIM) card (so-called non-service initialized (NSI) handsets), or when nobody could figure out who owned the SIM card, hoax calls often got unacceptably high [TASMANIA] [UK] [SA] 📉.
Here's the plot twist though: there are few documented cases of hoax calls coming from untrustworthy location info inside an emergency call. That's the exact focus of this document 🎯.
2. Threat Models 🕵️♀️
this section looks at the existing analyses of emergency services security, threats to geographic location privacy, threats involving spoofed caller identification, and threats around location info getting modified in transit 🌷. It also describes the threat model this work is built on 💅.
2.1. Existing Work 📚
"An Architecture for Location and Location Privacy in Internet Applications" [RFC6280] describes an architecture for privacy-preserving location-based services on the Internet. It focuses on the authorization, security, and privacy requirements for the data formats and protocols those services use 🦋.
Section 5 of [RFC6280] ("An Architecture for Location and Location Privacy in Internet Applications") talks about protecting the location distribution chain. It covers hop-by-hop confidentiality and integrity protection, as well as end-to-end assurance 🔐.
"Geopriv Requirements" [RFC3693] is all about the authorization, security, and privacy requirements of location-dependent services, emergency services included 🌈. Its Section 8 discusses emergency services authentication (Section 8.3) and issues around identity and anonymity (Section 8.4) 🫶.
"Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats against geographic location privacy. That covers protocol threats, threats from storing geographic location data, and threats from abuse of information 👀.
"Security Threats and Requirements for Emergency Call Marking and Mapping" [RFC5069] reviews the security threats tied to marking signaling messages and to mapping locations to Universal Resource Identifiers (URIs) that point to PSAPs 🛡️. RFC 5069 describes attacks on the emergency services system, like trying to deny service to everyone in an area, getting fraudulent use of services, and diverting emergency calls to non-emergency sites 😱. It also covers attacks on individuals, like trying to stop someone from getting help or digging up info about an emergency, plus attacks on infrastructure elements such as mapping discovery and mapping servers 🧩.
"Secure Telephone Identity Threat Model" [RFC7375] analyzes threats around impersonating and hiding calling party numbers. It goes over what attackers are capable of and the scenarios where attacks get launched 📞.
2.2. Adversary Model 😈
to give this a structured analysis, we split things up into three adversary models 🍓:
- External adversary model: The end host (for example, an emergency caller whose location is about to be communicated) is honest, and the adversary may sit between the end host and the location server, or between the end host and the PSAP. None of the emergency service infrastructure elements act maliciously.
- Malicious infrastructure adversary model: The emergency call routing elements, such as the Location Information Server (LIS), the Location-to-Service Translation (LoST) infrastructure (which is used for mapping locations to PSAP addresses), or call routing elements, may act maliciously.
- Malicious end host adversary model: The end host itself acts maliciously, whether or not the owner knows about it, and whether or not the end host is under the control of a third party.
Previous work already describes attacks on infrastructure elements (like location servers, call route servers, and mapping servers), attacks on the emergency services IP network, and threats from attackers trying to snoop location in transit 🕶️. So this document zooms in on threats from end hosts giving false location info inside emergency calls (the malicious end host adversary model) 🎯.
Since the focus is on malicious hosts, we don't cover threats from attacks on the infrastructure hosts rely on to get location 🙅♀️. For example, end hosts may get location from civilian GPS, which is vulnerable to spoofing [GPSCounter], or from third-party Location Service Providers (LSPs) that might be vulnerable to attack or might not offer location accuracy good enough for emergency purposes 🛰️.
We also don't cover threats from inadequate location infrastructure 🗺️. For example, the LIS or end host could base its location determination on a stale wiremap or an inaccurate access point location database, which leads to an inaccurate location estimate. Similarly, a Voice Service Provider (VSP) (and, indirectly, a LIS) could use the wrong identity (such as an IP address) for location lookup, giving the end host misleading location info 🤦♀️.
2.3. Location Spoofing 🎭
when an end host attaches location to the emergency call, the end host can fabricate a PIDF-LO and send it along inside the call 😬. Here are some examples of location spoofing, with Mallory as the adversary 👩💻:
Place shifting: Mallory, the adversary, pretends to be at an
arbitrary location.
Time shifting: Mallory pretends to be at a location where she was
a while ago.
Location theft: Mallory observes or obtains Alice's location and
replays it as her own.2.4. Identity Spoofing ✨
okay so this part is about who is making the call 📞 The document isn't really focused on fake caller IDs messing up location, but being able to tell who's calling matters a lot, bestie, because the threat of getting caught literally reduces hoax calls 🙈 That's why pay phone calls get extra side-eye from the call taker. 💅
When calls come over an IP network, there are at least two kinds of identity that matter, and the split between the IAP and the VSP is what separates them:
- (a) network access identity, like what you might figure out through authentication (for example, using the Extensible Authentication Protocol (EAP) [RFC3748]);
- (b) caller identity, like what you might figure out from authenticating the emergency caller at the VoIP application layer.
If the adversary didn't authenticate itself to the VSP, then accountability might come down to checking the network access identity 🕵️♀️ BUT the network access identity might not be authenticated either, like when someone uses an open IEEE 802.11 Access Point to start a hoax emergency call. The IP address or Media Access Control (MAC) address might have been logged, but tying that back to the Device owner can be really hard 😭
Here's the tea 🍵 Unlike the old phone system, VoIP emergency calls can give you an identity that doesn't have to be tied to a business relationship with the IAP, ISP, or VSP. However, emergency calls are time-critical, so multi-layer authentication is undesirable. So in most cases, only the Device placing the call will be identifiable 🦋 On top of that, adding extra credentials just for emergency service (like certificates) raises costs, adds a lot of admin overhead, and only pays off if they're widely deployed. Not me being like "that's a lot of work" 💀
3. Mitigation Techniques ✨
the next sections cover three mechanisms for fixing the threats from Section 2 🛡️💖
- Signed location-by-value (Section 3.1), which gives you authentication and integrity protection for the PIDF-LO. Only an expired straw-man proposal exists for this one [Loc-Dependability], so as of writing it's not suitable for deployment yet 🥲
- Location-by-reference (Section 3.2), which lets the PSAP grab location directly from the location server over a confidential, integrity-protected channel, so nobody on the end host or in the middle can mess with it 🔒 This one is specified in [RFC6753].
- Proxy-added location (Section 3.3), which protects against the end host forging its location 🙅♀️ This one is specified in [RFC6442].
3.1. Signed Location-by-Value 🎀
with location signing, a location server signs the location info before it's sent to the Target. Then the signed info goes to the Location Recipient, who verifies it. Iconic trust chain energy 👑
Figure 1 shows the flow: the Target asks for signed location in step (a), the location server returns it in step (b), and then it gets conveyed to the Location Recipient, who verifies it in step (c). For SIP, the procedures in "Location Conveyance for the Session Initiation Protocol" [RFC6442] are the ones that apply for location conveyance 🧚
+-----------+ +-----------+
| | | Location |
| LIS | | Recipient |
| | | |
+-+-------+-+ +----+------+
^ | --^
| | --
Geopriv |Req. | --
Location |Signed |Signed -- Protocol Conveying
Configuration |Loc. |Loc. -- Location (e.g., SIP)
Protocol |(a) |(b) -- (c)
| v --
+-+-------+-+ --
| Target / | --
| End Host +
| |
+-----------+
Figure 1: Location SigningA straw-man proposal for location signing lives in "Digital Signature Methods for Location Dependability" [Loc-Dependability]. Since [Loc-Dependability] isn't being developed anymore, location signing can't be considered deployable as of writing 🥀
To limit replay attacks, that proposal adds a "validity" element to the PIDF-LO. It has a "from" sub-element for when the signer validated the location info, and an "until" sub-element for the last time the signature can be considered valid ⏰
One consequence of that "until" element is that even a stationary Target would need to keep grabbing a fresh PIDF-LO, or else eat the extra delay of querying during an emergency call 😩
Privacy-preserving stuff might get turned off for emergency calls, but PIDF-LO objects are designed to limit the info available for real-time attribution 🫶 As noted in [RFC5985], Section 6.6:
The LIS MUST NOT include any means of identifying the Device in the PIDF-LO unless it is able to verify that the identifier is correct and inclusion of identity is expressly permitted by a Rule Maker. Therefore, PIDF parameters that contain identity are either omitted or contain unlinked pseudonyms [RFC3693]. A unique, unlinked presentity URI SHOULD be generated by the LIS for the mandatory presence "entity" attribute of the PIDF document. Optional parameters such as the "contact" and "deviceID" elements [RFC4479] are not used.
Also, the Device referred to in the PIDF-LO might not be the same entity that's sending the PIDF-LO to the PSAP 🤔 As noted in [RFC6442], Section 1:
In no way does this document assume that the SIP user agent client that sends a request containing a location object is necessarily the Target. The location of a Target conveyed within SIP typically corresponds to that of a Device controlled by the Target, for example, a mobile phone, but such Devices can be separated from their owners, and moreover, in some cases, the user agent may not know its own location.
Without a way to tie the Target identity to the identity asserted in the SIP message, an attacker could cut and paste a PIDF-LO obtained by a different Device or user into a SIP INVITE and send it to the PSAP 🙃 That cut-and-paste attack could still work even when a PIDF-LO is signed or when [RFC4474] is implemented. Yikes 😭
To address location-spoofing attacks, [Loc-Dependability] proposes an "identity" element that could include a SIP URI (so it can be compared against the identity asserted in the SIP headers) or an X.509v3 certificate. If the LIS authenticated the Target, an "authenticated" attribute gets added. BUT an "identity" element could enable location tracking, so a "hash" element is also proposed that could hold a hash of the "identity" element's content instead. In practice, though, that hash wouldn't be much better for real-time validation than a pseudonym 🧩
Location signing cannot deter attacks in which valid location information is provided. For example, an attacker in control of compromised hosts could launch a denial-of-service attack on the PSAP by initiating a large number of emergency calls, each containing valid signed location information. Since the work required to verify the location signature is considerable, this could overwhelm the PSAP infrastructure.
However, even though DDoS attacks probably won't get deterred by location signing, accurate location info would cut down the subset of compromised hosts that could be used for an attack 🎯 Only hosts inside the PSAP serving area would be useful for placing emergency calls.
Location signing is also tricky when the host gets location from things like GPS, unless trusted computing approaches with tamper-proof GPS modules can be applied 🛰️ Otherwise, an end host can pretend it has GPS, and the Recipient will have to rely on how much trust it can place in the end host's location claim 🤷♀️
Even though location-signing mechanisms haven't been standardized, [NENA-i2], Section 4.7 has operational recommendations for location signing, and they're giving main character energy:
Location configuration and conveyance requirements are described in NENA 08-752[27], but guidance is offered here on what should be considered when designing mechanisms to report location: 1. The location object should be digitally signed. 2. The certificate for the signer (LIS operator) should be rooted in VESA. For this purpose, VPC and ERDB operators should issue certificates to LIS operators. 3. The signature should include a timestamp. 4. Where possible, the Location Object should be refreshed periodically, with the signature (and thus the timestamp) being refreshed as a consequence. 5. Antispoofing mechanisms should be applied to the Location Reporting method.
(Quick note 📝 "VESA" means "Valid Emergency Services Authority," which is the root certificate authority. "VPC" is the VoIP Positioning Center, and "ERDB" is the Emergency Service Zone Routing Database.)
As mentioned above, signing location objects means building a trust hierarchy so a certificate chain from the LIS operator can be verified by the PSAP 🔗 Rooting that trust hierarchy in the VESA can happen either by having the VESA directly sign the LIS certificates, or by creating intermediate Certificate Authorities (CAs) that the VESA certifies and that then issue certificates to the LIS. For the workload on the VESA, the second approach is highly preferable 💜 But that raises the question of who would run those intermediate CAs and what would be expected of them.
Specifically, we need to figure out the requirements for LIS certificate issuance, and how they'd compare to requirements for issuing other certificates, like a Secure Socket Layer/Transport Layer Security (SSL/TLS) web certificate 🌈
3.2. Location-by-Reference
Okay so location-by-reference was built so end hosts don't have to keep pinging the location server for fresh location info every time they move 🚗💨. It's giving efficiency. If operators don't want to hand location info straight to the end host without charging for it 💸, LbyR is a solid alternative. And since LbyR lets the PSAP contact the location server directly, it dodges sketchy attacks from intermediaries 🙈
As noted in "A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a location reference can be obtained via HELD [RFC5985]. Then "Location Configuration Extensions for Policy Management" [RFC7199] levels up location configuration protocols like HELD so hosts get a reference to the rules that apply to a location-by-reference 📜. That means the host can view or set those rules 🎀
Figure 2 shows the communication model. The Target requests a location reference in step (a) 🙋♀️. The location server returns the reference and, potentially, the policy in step (b). Then it gets conveyed to the Location Recipient in step (c). The Location Recipient needs to resolve the reference with a request in step (d). After that, location information comes back to the Location Recipient 💌. For location conveyance in SIP, the procedures described in [RFC6442] apply 🦋
+-----------+ Geopriv +-----------+
| | Location | Location |
| LIS +<------------->+ Recipient |
| | Dereferencing | |
+-+-------+-+ Protocol (d) +----+------+
^ | --^
| | --
Geopriv |Req. |LbyR + --
Location |LbyR |Policy -- Protocol Conveying
Configuration |(a) |(b) -- Location (e.g., SIP)
Protocol | | -- (c)
| V --
+-+-------+-+ --
| Target / | --
| End Host +
| |
+-----------+
Figure 2: Location-by-ReferenceWhere location-by-reference is provided, the Recipient needs to dereference the LbyR to get the location 🔍. The details of dereferencing vary with the type of reference, like an HTTP, HTTPS, SIP, secure SIP (SIPS), or SIP Presence URI 🌈
The location server needs to keep one or several URIs for each Target, and those URIs time out after a certain amount of time ⏳. References need to expire so a Recipient of such a Uniform Resource Locator (URL) can't permanently track a host 👀. Expiry also gives the location server functionality for garbage collection 🧹
Off-path adversaries must be prevented from obtaining the Target's location 🛡️. The reference has a randomized component that stops third parties from guessing it 🎲. When the Location Recipient fetches up-to-date location info from the location server, it can also be assured the info is fresh and not replayed ✨. Honestly though, this does not address location theft 💀
Now for the security of the dereference operation. [RFC6753], Section 6 states:
TLS MUST be used for dereferencing location URIs unless confidentiality and integrity are provided by some other mechanism, as discussed in Section 3. Location Recipients MUST authenticate the host identity using the domain name included in the location URI, using the procedure described in Section 3.1 of [RFC2818]. Local policy determines what a Location Recipient does if authentication fails or cannot be attempted. The authorization by possession model (Section 4.1) further relies on TLS when transmitting the location URI to protect the secrecy of the URI. Possession of such a URI implies the same privacy considerations as possession of the PIDF-LO document that the URI references. Location URIs MUST only be disclosed to authorized Location Recipients. The GEOPRIV architecture [RFC6280] designates the Rule Maker to authorize disclosure of the URI. Protection of the location URI is necessary, since the policy attached to such a location URI permits anyone who has the URI to view the associated location information. This aspect of security is covered in more detail in the specification of location conveyance protocols, such as [RFC6442].
Translation: TLS is a MUST for dereferencing unless something else gives confidentiality and integrity 🔐. Recipients MUST check the host identity against the domain name in the URI 🕵️♀️. And location URIs MUST only go to authorized Recipients 🚫. Lowkey all the serious stuff lives in that list, so read it twice bestie 🫶
For authorizing access to location-by-reference, two models were developed: "Authorization by Possession" and "Authorization via Access Control Lists". About "Authorization by Possession", [RFC6753], Section 4.1 notes:
In this model, possession -- or knowledge -- of the location URI is used to control access to location information. A location URI might be constructed such that it is hard to guess (see C8 of [RFC5808]), and the set of entities that it is disclosed to can be limited. The only authentication this would require by the LS is evidence of possession of the URI. The LS could immediately authorize any request that indicates this URI. Authorization by possession does not require direct interaction with a Rule Maker; it is assumed that the Rule Maker is able to exert control over the distribution of the location URI. Therefore, the LIS can operate with limited policy input from a Rule Maker. Limited disclosure is an important aspect of this authorization model. The location URI is a secret; therefore, ensuring that adversaries are not able to acquire this information is paramount. Encryption, such as might be offered by TLS [RFC5246] or S/MIME [RFC5751], protects the information from eavesdroppers. ... Using possession as a basis for authorization means that, once granted, authorization cannot be easily revoked. Cancellation of a location URI ensures that legitimate users are also affected; application of additional policy is theoretically possible but could be technically infeasible. Expiration of location URIs limits the usable time for a location URI, requiring that an attacker continue to learn new location URIs to retain access to current location information.
So basically possession is the key 🔑, the URI is a secret 🤫, and once you've handed it out it's hard to take back 😩. Expiry helps, since an attacker would have to keep finding new URIs to keep access 🏃♀️
In situations where "Authorization by Possession" isn't suitable (like where location hiding [RFC6444] is required), the "Authorization via Access Control Lists" model may be preferred 📋
Without a hierarchy, the PSAP would need credentials, like certificates or shared symmetric keys, for all the LISs in its coverage area so it can dereference LbyRs successfully 😵💫. With more than a few LISs per PSAP, that's an operational nightmare 💀
A certificate hierarchy giving PSAPs client certificates that chain to the VESA could be used so the LIS can authenticate and authorize PSAPs for dereferencing 🌸. Note that this is different from PIDF-LO signing (which mitigates modification of PIDF-LOs). This only gives the PSAP access to a (potentially unsigned) PIDF-LO, though it does go over a protected TLS channel 🔒
Another approach is for the local LIS to upload location information to a location aggregation point, which then manages the relationships with the PSAP 🏢. That shifts the management burden from the PSAPs to the location aggregation points 🧚
3.3. Proxy-Added Location
Instead of relying on the end host to provide location, a proxy can do it. It can determine the location of the end point (for example from the end host IP or MAC address), then retrieve it and add or override location info 🗺️. The catch is this requires ISPs to deploy application-layer entities, unlike the two other techniques 😬. These proxies could be used for emergency or non-emergency communications, or both 📞
Proxy-added location is mainly useful where the end host doesn't provide location. As noted in [RFC6442], Section 4.1:
A SIP intermediary SHOULD NOT add location to a SIP request that already contains location. This will quite often lead to confusion within LRs. However, if a SIP intermediary adds location, even if location was not previously present in a SIP request, that SIP intermediary is fully responsible for addressing the concerns of any 424 (Bad Location Information) SIP response it receives about this location addition and MUST NOT pass on (upstream) the 424 response. A SIP intermediary that adds a locationValue MUST position the new locationValue as the last locationValue within the Geolocation header field of the SIP request. ... A SIP intermediary MAY add a Geolocation header field if one is not present -- for example, when a user agent does not support the Geolocation mechanism but their outbound proxy does and knows the Target's location, or any of a number of other use cases (see Section 3).
Translation: intermediaries SHOULD NOT add location to a request that already has it 🙅♀️. If they do add location, they MUST NOT pass along any 424 (Bad Location Information) response upstream, and they MUST put the new locationValue last in the Geolocation header field 📍. They MAY add a Geolocation header field if there isn't one 💁♀️
As noted in [RFC6442], Section 3.3:
This document takes a "you break it, you bought it" approach to dealing with second locations placed into a SIP request by an intermediary entity. That entity becomes completely responsible for all location within that SIP request (more on this in Section 4).
Iconic energy 💅 If an intermediary adds a second location, it's fully on the hook for all location in that request 😭
A proxy can override location the end host included, but [RFC6442], Section 3.4 notes the operational limits:
Overriding location information provided by the user requires a deployment where an intermediary necessarily knows better than an end user -- after all, it could be that Alice has an on-board GPS, and the SIP intermediary only knows her nearest cell tower. Which is more accurate location information? Currently, there is no way to tell which entity is more accurate or which is wrong, for that matter. This document will not specify how to indicate which location is more accurate than another.
Honestly this is so real 🤯 Alice's on-board GPS could be way better than the cell tower the proxy sees, and there's currently no way to tell which one is right 🗼 [RFC6442] doesn't specify how to flag which location is more accurate either 🙈
The downside of this approach is that application-layer entities, like SIP proxies, need to be deployed at IAPs or associated with IAPs 🏗️. That means a standardized VoIP profile has to be deployed at every end Device and every IAP, which might cause interoperability challenges 🧩
The IAP also has to take responsibility for emergency calls, even for customers it has no direct or indirect relationship with 😳. To get identity info about the emergency caller from the VSP, the IAP and VSP would need to interact for authentication (see, for example, "Diameter Session Initiation Protocol (SIP) Application" [RFC4740]). That interaction along the Authentication, Authorization, and Accounting infrastructure is often based on business relationships between the entities involved 🤝. An arbitrary IAP and VSP are unlikely to have a business relationship 🥲 If the IAP and VSP interaction fails because there's no business relationship, there's typically a fall-back where no emergency caller identity info reaches the PSAP. The emergency call still has to be completed though 📞🚨
4. Location Trust Assessment 🔍✨
okay so being able to figure out how trustworthy conveyed location info is actually matters a LOT 💅 because it tells you how much weight to put on location when you're making decisions. like, if the automated location is super suspicious or just missing, a call taker can put way more effort into checking that the call is legit and getting the location straight from the caller 🎀
location trust assessment still has value even if the location is authenticated (like signed location) or grabbed directly from the location server (location-by-reference) over a secure transport 🫶 bc those mechanisms don't actually give you assurance about whether the location data is valid or where it came from 🤷♀️
to stop location-theft attacks, the "entity" element of the PIDF-LO is kinda not very useful if an unlinked pseudonym is put in that field. BUT if the LIS authenticates the Target, the link between the pseudonym and the Target's identity can be recovered in a post-incident investigation 🕵️♀️
as noted in [Loc-Dependability], if the location object was signed, the Location Recipient gets extra stuff to base their trust assessment on 🧠 like the validity of the signature, the identity of the Target, the identity of the LIS, whether the LIS authenticated the Target, and the identifier in the "entity" field 💖
caller accountability is a huge part of this too 👑 can the individual who bought the Device or activated the service be identified? or did the call come from a non-service initialized (NSI) Device whose owner can't be figured out? before the call, was the caller authenticated at the network or application layer? and after a hoax call, can audit logs be handed to an investigator, or can info about the owner of an unlinked pseudonym be provided so investigators can unravel the whole chain of events that led to the attack? 😤
in practice, the source of the location data matters a ton ✨ for example, location from a Location Information Server (LIS) whose administrator has an established history of meeting emergency location accuracy requirements (e.g., United States Phase II E-911 location accuracy) may be considered more reliable than location from a third-party Location Service Provider (LSP) that disclaims using location info for emergency purposes 🌸
but even when an LSP doesn't try to meet the accuracy requirements for emergency location, it may still be able to share info that helps you judge how reliable the location is likely to be 🦋 like, was the location determined based on the nearest cell tower or 802.11 Access Point (AP), or was a triangulation method used? and if it's based on cell tower or AP location data, was the info from an authoritative source (e.g., the tower or AP owner), and when was the location of that tower or access point last verified? 🧐
for real-time validation, info in the signaling and media packets can be cross-checked against location info 🔥 for example, it may be possible to figure out the city, state, country, or continent associated with the IP address in SIP Via or Contact header fields, or the media source address, and then compare that against the location reported by the caller or conveyed in the PIDF-LO. however, in some situations, only entities close to the caller may be able to verify the location is correct 🙈
real-time validation of the timestamp in a PIDF-LO object (the time the location was determined) is also challenging 😭 to address time-shifting attacks, the "timestamp" element of the PIDF-LO, defined in [RFC3863], can be examined and compared against timestamps in the enclosing SIP message to figure out whether the location data is fresh enough 🍓 however, the timestamp only represents an assertion by the LIS, which may or may not be trustworthy. for example, the Recipient of the signed PIDF-LO may not know whether the LIS supports time synchronization, or whether it's possible to reset the LIS clock manually without anyone noticing 💀 even if the timestamp was valid when the location was determined, a time period may pass between when the PIDF-LO was provided and when it's conveyed to the Recipient. and periodically refreshing location info just to renew the timestamp, even though the location itself hasn't changed, puts extra load on LISs 😩 so, Recipients need to validate the timestamp to figure out whether it's credible 💅
while this document focuses on real-time determination of suspicious emergency calls, audit logs may help enforce accountability among emergency callers 📚 for example, in the event of a hoax call, info about the owner of the unlinked pseudonym could be given to investigators, so they can unravel the chain of events that led to the attack 🕵️♀️ however, while auditability is an important deterrent, it's likely to be most useful where attacks on the emergency services system are relatively infrequent, since investigations take a lot of resources 😮💨 still, even though real-time validation based on PIDF-LO elements is challenging, where LIS audit logs are available (such as where a law enforcement agency can present a subpoena), linking a pseudonym to the Device obtaining the location can be done during an investigation 🎀
where attacks are frequent and continuous, automated mechanisms are required 🤖 for example, it might be valuable to develop mechanisms to exchange audit trail info in a standardized format between ISPs and PSAPs / VSPs and PSAPs, or heuristics to tell potentially fraudulent emergency calls apart from real emergencies 🌈 a Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) may be applied to suspicious calls to lower the risk from bot-nets, but this is quite controversial for emergency services because of the risk of delaying or rejecting valid calls 😬
5. Security Considerations 🛡️💜
okay this section is the dramatic one and it deserves its moment 🎭 although it's super important to make sure location info can't be faked, the mitigation techniques in this document are not universally applicable 🙅♀️ for example, there will be lots of GPS-enabled Devices that will find it difficult to use any of the solutions described in Section 3. and it's also unlikely that users will be willing to upload their location info for "verification" to a nearby location server in the access network 🥺
this document focuses on threats that come from conveying misleading location info, rather than caller identification or authentication and integrity protection of the messages in which location is conveyed ✨ but honestly, those aspects are important too 💅 in some countries, regulators may not require the authenticated identity of the emergency caller (e.g., emergency calls placed from Public Switched Telephone Network (PSTN) pay phones or SIM-less cell phones) 📞 and if identities can easily be crafted (which is the case with many VoIP offerings today), then the value of emergency caller authentication itself might be limited 😒 as a result, attackers can forge emergency calls with a lower risk of being held accountable, which may encourage hoax calls 🚨
to provide authentication and integrity protection for the Session Initiation Protocol (SIP) messages conveying location, there are several security approaches available 🔐 it's possible to make sure that modification of the identity and location in transit can be detected by the Location Recipient (e.g., the PSAP), using cryptographic mechanisms, as described in "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474] 🧁 however, compatibility with Session Border Controllers (SBCs) that modify integrity-protected headers has turned out to be an issue in practice 🙃 so, a revision of [RFC4474] is in progress [SIP-Identity] 🛠️ and in the absence of an end-to-end solution, SIP over Transport Layer Security (TLS) can be used to provide message authentication and integrity protection hop by hop 🔗
PSAPs remain vulnerable to distributed denial-of-service attacks, even where the mitigation techniques described in this document are utilized 🚨 placing a large number of emergency calls that appear to come from different locations is an example of an attack that is difficult to carry out within the legacy system, but is easier to imagine within IP-based emergency services 😱 and also, in the current system, it would be very difficult for an attacker from one country to attack the emergency services infrastructure located in another country, but that attack is possible within IP-based emergency services 🌍
while manually mounting the attacks described in Section 2 is non-trivial, the attacks described in this document can be automated 🤖 manually carrying out a location theft would require the attacker to be in proximity to the location being spoofed, or to collude with another end host, but an attacker able to run code on an end host can obtain its location and cause an emergency call to be made 💻 and manually carrying out a time-shifting attack would require the attacker to visit the location and submit it before the location info is considered stale, while traveling rapidly away from that location to avoid apprehension 🏃♀️ those limitations would not apply to an attacker able to run code on the end host 😈 while obtaining a PIDF-LO from a spoofed IP address requires the attacker to be on the path between the HELD requester and the LIS, if the attacker can run code that requests the PIDF-LO, retrieves it from the LIS, and then makes an emergency call using it, this attack becomes much easier 📉 to mitigate the risk of automated attacks, service providers can limit the ability of untrusted code (such as WebRTC applications written in JavaScript) to make emergency calls 🛑
emergency services have three finite resources that are subject to denial-of-service attacks: the network and server infrastructure; call takers and dispatchers; and the first responders, such as firefighters and police officers 🚒 protecting the network infrastructure is similar to protecting other high-value service providers, except that location info may be used to filter call setup requests, to weed out 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 techniques are used to evaluate the trustworthiness of conveyed location, and call takers can eliminate many hoax calls by questioning the caller, PSAPs can be overwhelmed even by a small-scale attack 🌊 finally, first-responder resources are scarce, particularly during mass-casualty events 🫂
6. Privacy Considerations ✨
okay bestie, let's talk privacy 🫶 the emergency calling setup in [RFC6443] uses the PIDF-LO format from [RFC4119]. and like, the location privacy architecture in [RFC6280] says the privacy rules, policy instructions included, travel right along with the location object 🔒
the whole point of that location privacy architecture was to give people really strong privacy protections 💅 [RFC6280], Section 1.1 puts it perfectly:
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.but ngl, in practice this setup has limits in both emergency and non-emergency situations 😭 like we already covered in Section 1.2.2, hoax calls made everyone nervous, so anonymous emergency calls got restricted 🙈 caller identity can be asserted in SIP through P-Asserted-Identity and SIP Identity, and it may get used during emergency calls. so in lots of cases, location info inside SIP messages can be linked back to the caller 👀 for example, with a signed LbyV, there are privacy concerns from tying the location object to identifiers so replay attacks can be prevented, as described in Section 3.1.
the ability to observe location info during emergency calls can also be a privacy risk 😬 which is why [RFC6443] requires transmission-layer security for SIP messages, and for interactions with the location server too. however, even where transmission-layer security is used, the privacy rules attached to location info may not apply 💀
in lots of jurisdictions, someone asking for emergency help is assumed to be giving permission to the PSAP, call taker, and first responders to get their location so they can speed up dispatch 🚑 so privacy policies tied to location are implicitly waived once an emergency call starts. and when location info is included in SIP messages, whether in emergency or non-emergency use, the SIP entities that receive those messages are implicitly assumed to be authorized Location Recipients. as [RFC5606], Section 3.2 spells out:
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.finally, when LbyR is used instead of LbyV, it's possible to apply more restrictive authorization policies, which limit access for intermediaries and snoopers 🕵️♀️ but that's not possible if the "authorization by possession" model is used 🥲
7. Informative References ✨
okay bestie, here are all the extra reading links the document leans on 📚 they're not required to implement anything, but they're the receipts 💅
[EENA] EENA, "False Emergency Calls", EENA Operations Document, Version 1.1, May 2011, <http://www.eena.org/ressource/static/files/2012_05_04-3.1.2.fc_v1.1.pdf>.
[GPSCounter] Warner, J. and R. Johnston, "GPS Spoofing Countermeasures", Los Alamos research paper LAUR-03-6163, December 2003.
[Loc-Dependability] Thomson, M. and J. Winterbottom, "Digital Signature Methods for Location Dependability", Work in Progress, draft-thomson-geopriv-location-dependability-07, March 2011.
[NENA-i2] NENA 08-001, "NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)", Version 2, August 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[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, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004, <http://www.rfc-editor.org/info/rfc3693>.
[RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004, <http://www.rfc-editor.org/info/rfc3694>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004, <http://www.rfc-editor.org/info/rfc3863>.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005, <http://www.rfc-editor.org/info/rfc4119>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006, <http://www.rfc-editor.org/info/rfc4474>.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006, <http://www.rfc-editor.org/info/rfc4479>.
[RFC4740] Garcia-Martin, M., Ed., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C., and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", RFC 4740, November 2006, <http://www.rfc-editor.org/info/rfc4740>.
[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008, <http://www.rfc-editor.org/info/rfc5012>.
[RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008, <http://www.rfc-editor.org/info/rfc5069>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009, <http://www.rfc-editor.org/info/rfc5491>.
[RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of 'retransmission-allowed' for SIP Location Conveyance", RFC 5606, August 2009, <http://www.rfc-editor.org/info/rfc5606>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5808] Marshall, R., Ed., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010, <http://www.rfc-editor.org/info/rfc5808>.
[RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010, <http://www.rfc-editor.org/info/rfc5985>.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011, <http://www.rfc-editor.org/info/rfc6280>.
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011, <http://www.rfc-editor.org/info/rfc6442>.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, December 2011, <http://www.rfc-editor.org/info/rfc6443>.
[RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. Kuett, "Location Hiding: Problem Statement and Requirements", RFC 6444, January 2012, <http://www.rfc-editor.org/info/rfc6444>.
[RFC6753] Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M. Thomson, "A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)", RFC 6753, October 2012, <http://www.rfc-editor.org/info/rfc6753>.
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, March 2013, <http://www.rfc-editor.org/info/rfc6881>.
[RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. Patel, "Public Safety Answering Point (PSAP) Callback", RFC 7090, April 2014, <http://www.rfc-editor.org/info/rfc7090>.
[RFC7199] Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig, "Location Configuration Extensions for Policy Management", RFC 7199, April 2014, <http://www.rfc-editor.org/info/rfc7199>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, September 2014, <http://www.rfc-editor.org/info/rfc7340>.
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", RFC 7375, October 2014, <http://www.rfc-editor.org/info/rfc7375>.
[SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in hoax calls", Arab News, April 5, 2010, <http://www.arabnews.com/node/341463>.
[SIP-Identity] Peterson, J., Jennings, C. and E. Rescorla, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, draft-ietf-stir-rfc4474bis-02, October 2014.
[STIR] IETF, "Secure Telephone Identity Revisited (stir) Working Group", October 2013, <http://datatracker.ietf.org/wg/stir/charter/>.
[SWATing] "SWATing 911 Calls", Dispatch Magazine On-Line, April 6, 2013, <http://www.911dispatch.com/swating-911-calls/>.
[Swatting] "Don't Make the Call: The New Phenomenon of 'Swatting'", Federal Bureau of Investigation, February 4, 2008, <http://www.fbi.gov/news/stories/2008/february/swatting020408>.
[TASMANIA] "Emergency services seek SIM-less calls block", ABC News Online, August 18, 2006, <http://www.abc.net.au/elections/tas/2006/news/stories/1717956.htm?elections/tas/2006/>.
[UK] "Rapper makes thousands of prank 999 emergency calls to UK police", Digital Journal, June 24, 2010, <http://www.digitaljournal.com/article/293796?tp=1>.
Acknowledgments 🫶
huge shoutout to the IETF ECRIT working group, including Marc Linsner and Brian Rosen, for their input at IETF 85 that helped get this document pointed in the right direction 🧚 also big thanks to the IETF GEOPRIV working group folks, including Richard Barnes, Matt Lepinski, Andrew Newton, Murugaraj Shanmugam, and Martin Thomson, for their feedback on earlier versions 💜 and Alissa Cooper, Adrian Farrel, Pete Resnick, Meral Shirazipour, and Bert Wijnen gave super helpful review comments during the IETF last call 👑 literally iconic reviewers 🙈
Authors' Addresses 💖
Hannes Tschofenig, Austria
EMail: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.atHenning Schulzrinne, Columbia University, Department of Computer Science, 450 Computer Science Building, New York, NY 10027, United States
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.eduBernard Aboba (editor), Microsoft Corporation, One Microsoft Way, Redmond, WA 98052, United States
EMail: bernard_aboba@hotmail.com📦 where this page comes from
- ietf: rfc7378 2014-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms